Introducao ao Mundo do Postfix

29/10/2008 14:45

Introducao ao Mundo do Postfix

Deives Michellis "thefallen"

 

 

 

 

 

Resumo

Introducao ao Mundo do Postfix - Uma abordagem dos fundamentos e recursos deste MTA, que hoje eh um dos mais populares na Internet: as facilidades de configuracao e Fine-Tuning do servico; Fontes de Dados e Backends: flexibilidade levada a serio; por que ele tem sido uma das maiores armas na Guerra Santa contra o Infiel Spam; e algumas aplicacoes no mundo real corporativo.

Introducao

O Que Eh

A ideia primaria do Postfix era produzir um substituto para o Sendmail, que fosse rapido, facil de administrar e seguro. Trata-se de um projeto Open Source bancado pela IBM, criado e mantido por Wietse Venema.

Uma instalacao padrao do Postfix pode substituir facilmente o famigerado Sendmail sem alteracoes significativas no sistema, e transparentemente para o usuario final. As bases de usuarios e bases de correio sao as mesmas (por default).

Os arquivos de configuracao sao simples e objetivos, preparados para que as variaves e opcoes de configuracoes sejam bastante intuitivas e faceis de entender.

E, a melhor parte de tudo, sem a "agradavel" surpresa do "Bug do Mes" que o nosso amigo mais antigo sempre nos trazia.

Autor e colaboradores

O autor deste software eh Wietse Venema, Ph.D. em Fisica pela Groningen University na Holanda. Ha diversos colaboradores que enviam "patches" e outras contribuicoes para a lista de discussao. Em especial, Viktor Duchovni e Ralf Hildebrandt se destacam nas contribuicoes para o desenvolvimento do Postfix.

Licenciamento

Um dos pontos que talvez mais contribua para a nao-adocao do Postfix como servidor de email padrao eh a licenca um tanto quanto confusa que a IBM usa - "IBM PUBLIC LICENSE VERSION 1.0 - SECURE MAILER"

Trata-se de uma versao modificada da licenca BSD. Para se protegerem de possiveis processos (como a palhacada da SCO; afinal, a IBM tem grana), a IBM adicionou clausulas quanto a distribuicao em forma binaria e "patcheada" do Postfix. Ha clausulas que dizem que quem distribui versoes pre-compiladas ou patcheadas (como o Debian, por exemplo, que aplica patches no Makefile e algumas partes do codigo) se torna automaticamente um "parceiro legal" da IBM no caso de um eventual processo. No caso do Postfix ser uma parte independente ou adicional do sistema, essas clausulas nao se aplicam.

Um exemplo bastante direto disso eh a nao-inclusao do Postfix no OpenBSD. Uma vez que ha patches no Makefile e adicao de alguns scripts de inicializacao proprios do OpenBSD para compilacao nos "ports", eles preferem nao inclui-lo.

1. Como funciona

Basicamente, a arquitetura interna do sistema funciona sem um conceito muito rigido sobre processos "pai-filho", mas com a ideia de processos cooperativos. Basicamente, as tarefas que o Postfix roda sao independentes, e proveem servicos umas as outras (por exemplo, ha uma tarefa que prove reescrita/traducao de enderecos para todos os outros processos do Postfix).

Ha um processo principal (o "master"), que nao faz nada a nao ser administrar os outros daemons do Postfix: carregar o "smtpd" quando ha necessidade de atender a porta SMTP, manter o "trivial-rewrite" rodando para fazer a manipulacao dos enderecos de correio, chamar o "qmgr" para gerenciar a fila de emails ainda nao entregues, chamar o "pickup" que pega novas mensagens e as joga na fila para entrega, etc.

O "master" tambem se encarrega de manter uma especie de cache dos daemons que ja foram iniciados, reutilizando processos ou removendo-os depois de um tempo especifico em ociosidade. Isso diminui bastante o tempo e esforco despendido na maneira mais tradicional, chamando o processo e removendo-o logo que este acabe sua tarefa. Ha sempre um tempo que leva pra carrega um processo e todas as suas bibliotecas do disco, alocar memoria, etc. Da maneira como o "master" gerencia isso, esse tempo eh praticamente nulo, uma vez que o processo ja esta no ar; ao mesmo tempo, o "master" mantem o sistema sob controle, nao deixando processos inuteis ocupando recursos da maquina.

O "master" eh o unico processo que tem privilegios de root, uma vez que apenas o root tem poderes para mudar de usuario (pra chamar um agente de entrega que roda como o usuario XYZ, por exemplo), ou para ouvir a porta 25 (na maioria dos sistemas, portas abaixo de 1024 sao privilegiadas, e apenas o root pode ouvi-las).

Eh interessante notar que o processo "master" nao tem contato direto com nenhum outro processo ou com o mundo exterior; seu unico objetivo eh descartar privilegios e chamar o processo necessario, ja em um ambiente desprivilegiado.

1.1. Permissoes / Usuarios / Seguranca

Todos os subprocessos internos do Postfix rodam sobre as permissoes do usuario "postfix" e grupo "postdrop" (pode ser modificado no arquivo de configuracao /etc/postfix/main.cf).

O grupo "postdrop" existe para fazer a separacao de privilegios e permitir que outros processos alem dos internos do Postfix possam injetar emails na fila. O diretorio /var/spool/postfix/maildrop permite que o grupo "postdrop" escreva la (mas nao permite que ele leia, garantindo a privacidade dos emails), e o programa que injeta os emails la (/usr/sbin/postdrop) possui flags setgid para o grupo "postdrop". Eh interessante notar que Postfix se recusa a funcionar se o usuario privilegiado "postfix" fizer parte do grupo "postdrop".

Um outro ponto a favor da seguranca com Postfix eh a facilidade de colocar partes dele (ou o Postfix inteiro) dentro de um ambiente chroot. Basta mudar um flag no arquivo de configuracao, e o processo ja sera iniciado fechado dentro do diretorio de spool. (Nota - "chroot" seria como "enjaular" um processo dentro de um diretorio, impedindo que ele acesse quaisquer arquivos fora dele)

Note tambem que, a despeito de todas as permissoes, os subprocessos do Postfix nao confiam nos dados que recebem ou na estrutura das mensagens na fila; isso quer dizer que ha uma verificacao da integridade/correcao da mensagem e das informacoes internas que o Postfix usa antes de manusear a mensagem. Isso torna o sistema mais estavel e previne de forma bastante efetiva contra crashes e buffer overflows por arquivos corrompidos no disco ou submetidos por usuarios maliciosos.

Seguem abaixo as permissoes do diretorio de spool e tambem do injetor de emails:

  drwx------   18 postfix  root         4096 Jul  4  2003 active/
  drwx------   18 postfix  root         4096 Jul 19  2003 bounce/
  drwx------    2 postfix  root         4096 Jul  3  2003 corrupt/
  drwx------   18 postfix  root         4096 Aug 13  2003 defer/
  drwx------   18 postfix  root         4096 Aug 13  2003 deferred/
  drwx------    6 postfix  root         4096 Nov 11 05:57 flush/
  drwx------    2 postfix  root         4096 Jul  3  2003 hold/
  drwx------   18 postfix  root         4096 Apr  6 08:23 incoming/
  drwx-wx---    2 postfix  postdrop   200704 Apr  6 08:23 maildrop/
  drwxr-xr-x    2 root     root         4096 Nov 21 16:09 pid/
  drwx------    2 postfix  root         4096 Apr  6 17:02 private/
  drwx--x---    2 postfix  postdrop     4096 Apr  6 17:02 public/
  drwx------    2 postfix  root         4096 Jul  4  2003 saved/

  -rwxr-sr-x    1 root     postdrop   723708 Sep 22  2003 /usr/sbin/postdrop

1.2. Sub-Processos

Como ja mencionado, o Postfix eh composto por uma porcao de pequenos daemons, cada um com um tarefa especifica, controlados pelo processo "master". Aqui estao listados alguns dos mais importantes sub-processos do Postfix e o que cada um dele faz

smtpd - eh o responsavel por tratar requisicoes SMTP e aplicar as primeiras filtragens no nivel do protocolo SMTP em si (remetentes, destinatarios, relays, blacklists, etc.)

smtp - eh a parte client que faz a entrega de mensagens via SMTP para outros hosts

qmgr - (queue manager) eh a parte do Postfix que controla a fila de mensagens, dizendo quais devem tentar ser entregues, quais dominios tem prioridade na entrega, e assim por diante. Eh chamado de 5 em 5 minutos para efetuar essas operacoes. Emails em transito "normal", ou seja, que acabaram de ser injetados na fila, nao necessariamente passam pelo qmgr; elas tentam ser entregues assim que sao injetados na fila, seja via "smtpd" ou pelo "postdrop"

pickup - eh responsavel por pegar mensagens injetadas na fila pelo "postdrop" e repassa-las para o "cleanup"

trivial-rewrite - cuida das tarefas de resolucao/canonizacao/re-escrita de enderecos de correio. Apelidos de email e outros tipos de mapeamentos e transportes sao tratados por esse sub-processo.

cleanup - faz verificacoes de integridade na mensagem, e ocasionais correcoes/alteracoes de cabecalhos ou enderecos necessarios. Eh este sub-processo tambem quem aplica regras de cabecalho/corpo da mensagem e mantem o ambiente da fila interna de correio "nos conformes"

1.2.1. pipe

Este sub-processo eh o verdadeiro "pulo do gato" do Postfix. Ele permite que se envie uma mensagem da fila do Postfix para um processo externo ao servico. Com ele, eh extremamente simples montar filtros de conteudo, anti-virus, anti-spams, agentes de entrega de mensagem personalizados, e qualquer coisa que se possa imaginar, permitindo total controle sobre o processo "pipeado", sem precisar aplicar nenhum patch no Postfix.

Eh atraves do "pipe" que se consegue usar o "maildrop" do Courier, ou o servico de storage/IMAP do Cyrus, UUCP e outros, incluindo a maioria dos filtros de conteudo e similares operando hoje no Postfix.

Voce vai observar mais abaixo que o "pipe" permite diversas flags na hora de chamar o comando. Podem haver algumas variacoes das opcoes de versao pra versao do Postfix; consulte a man-page do pipe pra detalhes atualizados.

2. Configuracoes

Quem ja configurou um Sendmail sabe o trabalho que da editar um arquivo de configuracao criptografico, e, muitas vezes, confuso. Quem ja trabalha a bastante tempo com ele talvez ja se sinta a vontade com os comandos muitas vezes estranhos do sendmail.cf, ou as macros m4 tambem muitas vezes igualmente criptograficas.

Alguns outros MTA's talvez nao trabalhem com 1 unico arquivo de configuracao, mas com uma duzia de arquivinhos, cada um com um pedacinho da configuracao.

O Postfix mostra-se bastante organizado nesse sentido. Ha basicamente 2 arquivos de configuracao, permitindo tambem que se usem diversos arquivos separados para partes da configuracao.

Um desses arquivos de configuracao, o "/etc/postfix/master.cf", controla o funcionamento do processo "master", dizendo a ele como tratar e gerenciar os outros sub-processos do Postfix.

O "/etc/postfix/main.cf" controla o funcionamento do sistema de correio, restricoes, relays, e etc.

2.1. master.cf

O arquivo master.cf eh basicamente uma tabela que o processo "master" le para comandar os outros subprocessos. Sua estrutura eh a seguinte:

  # ==========================================================================
  # service type  private unpriv  chroot  wakeup  maxproc command + args
  #               (yes)   (yes)   (yes)   (never) (50)
  # ==========================================================================

Eh interessante notarmos a facilidade de fazer chroot em um processo. Basta mudarmos o flag "chroot" para "y" e ja temos o processo preso dentro do diretorio de spool.

A coluna "maxproc" nos permite limitar o numero maximo de instancias simultanes de um processo que podem estar rodando. Podemos observar a possibilidade de aumentar ou diminuir o limite de um tipo especifico de subprocesso de acordo com nossas necessidades. Por padrao, ele vem preparado pra nao atrapalhar a performance geral da maquina, ao mesmo tempo que mantem um limite razoavel de processos para acomodar um servidor mediano (50 instancias de cada processo, no maximo). Nota: quando for alterar esta opcao, faca com aumentos progressivos; isso vai lhe permitir ver ate onde o seu sistema pode aguentar antes de acabarem-se os file descriptors ou descritores de arquivos. Coisas engracadas podem acontecer quando um inocente "ls" retorna um erro de "Too many open files" :)

A coluna "unpriv" diz se o processo roda como "postfix" (desprivilegiado) ou "root" (privilegiado).

A coluna "wakeup" serve para sub-processos que rodam em base regular, independente de eventos no sistema.

A "private" diz se mais de um processo pode acessar a mesma instancia do servico. Note que sub-processos "private" nao sao ativados por eventos do sistema de correio; sao ou agendados com tempo, ou respondem a uma solicitacao do usuario (o showq, por exemplo, responde ao comando "mailq").

Aqui vai o resto do master.cf:

  smtp      inet  n       -       n       -       -       smtpd
  #       -o content_filter=filter:filter
  pickup    fifo  n       -       n       60      1       pickup
  cleanup   unix  n       -       n       -       0       cleanup
  qmgr      fifo  n       -       n       300     1       qmgr
  rewrite   unix  -       -       n       -       -       trivial-rewrite
  bounce    unix  -       -       n       -       0       bounce
  defer     unix  -       -       n       -       0       bounce
  flush     unix  n       -       n       1000?   0       flush
  smtp      unix  -       -       n       -       -       smtp
  showq     unix  n       -       n       -       -       showq
  error     unix  -       -       n       -       -       error
  local     unix  -       n       n       -       -       local
  virtual   unix  -       n       n       -       -       virtual
  lmtp      unix  -       -       n       -       -       lmtp
  proxymap  unix  -       -       n       -       -       proxymap
  #
  # Interfaces to non-Postfix software. Be sure to examine the manual
  # pages of the non-Postfix software to find out what options it wants.
  # The Cyrus deliver program has changed incompatibly.
  #
  #cyrus    unix  -       n       n       -       -       pipe
  #  flags=R user=cyrus argv=/cyrus/bin/deliver -e -m ${extension} ${user}
  #uucp     unix  -       n       n       -       -       pipe
  #  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
  filter    unix  -       n       n       -       -       pipe
    flags=Rq user=preproc argv=/opt/blablabla/filter -f ${sender}  --  ${recipient}
  relay     unix  -       -       n       -       -       smtp

Uma estacao de trabalho, por exemplo, nao vai necessitar do "smtpd". Podemos comentar essa linha do master.cf e economizar recursos. Para um servidor de envio de newsletters ou maillist, por exemplo, podemos subir o limite de processos "smtp" para agilizar a entrega.

Outro fato interessante eh a facilidade de "debug" destes processos. Para a maioria deles, basta acrescentar "-v" ao comando e ele ja gerara uma quantidade consideravel de informacoes sobre o que acontece internamente com ele (muito util ao debugar problemas com Cyrus-SASL ou setups complexos de LDAP/MySQL, por exemplo).

2.2. main.cf

Quando se instala o servico Postfix, a unica alteracao necessaria no main.cf eh a opcao "myhostname". Ela define o hostname que aparecera em requisicoes, banners do SMTP, mensagens de erro, alem do dominio usado na autenticacao Cyrus-SASL.

A sintaxe do arquivo de configuracao eh bastante simples. Alem dos valores explicitos (como VARIAVEL = VALOR), podemos referenciar arquivos contendo esses valores. Veja um exemplo:

  myhostname = postfix1.algumlugar.com
  mydestination = /etc/postfix/mydomains

O arquivo "mydomains" contem uma lista de dominios atendidos pelo servidor. Pode ser um dominio por linha, ou separados por virgulas.

Vamos ver mais adiante o signficado das principais variaveis de configuracao do main.cf.

2.2.1. Macros

Alem da facilidade de podermos referenciar um arquivo contendo dados, podemos criar macros dentro do main.cf, englobando diversas configuracoes de acesso de uma vez soh. Por exemplo:

  fecha_relay = permit_mynetworks, permit_sasl_authenticated, reject_unauth_pipelining, reject_unauth_destination

  smtpd_recipient_restrictions = $fecha_relay

2.2.2. Sobreposicao de variaveis no master.cf

Eh possivel sobrepormos o valor de alguma variavel diretamente na chamada do servico no "master.cf". Isso mostra-se muito util quando temos mais de uma instancia de um processo rodando, ou quando queremos mudar uma variavel global de forma que ela soh exista neste processo em particular.

Por exemplo, podemos ter mais de uma instancia do processo "smtp" (no caso, o "smtp" e o "relay"), e queremos passar uma variavel dizendo ao "relay" para usar apenas a interface com o IP 192.168.0.200. Ou, num exemplo bastante comum, termos um filtro de conteudo atuando apenas no processo "smtpd"; as outras partes do sistema rodam normalmente sem utilizar um filtro de conteudo.

Para isso, basta adicionarmos "-o variavel=valor" na chamada do processo no "master.cf" (no exemplo acima, o filtro de conteudo esta comentado). Ou poderiamos ter 2 instancias do "smtpd", uma utilizando a porta 25 com filtragem de conteudo, e outra na porta 1025 operando sem filtragem de conteudo.

3. Backends/Fontes de Dados/Mapeamentos e Macros

Um dos recursos mais interessantes do Postfix sao os mapeamentos, tambem chamados de backends ou fontes de dados. Eh a habilidade de lidar com uma grande variedade de tipos de mapeamentos, das mais diversas formas, que confere uma incrivel flexibilidade ao Postfix. Macros sao pequenas partes de programas que manuseiam os resultados fornecidos pelos mapeamentos.

3.1. Macros mais comuns

Algumas macros bastante usadas em configuracoes do smtpd:

  • check_client_access mapeamento:/blabla - verifica o IP/Hostname do MTA conectado ao smtpd

     

  • check_recipient_access mapeamento:/blabla - verifica o acesso ao destinatario

     

  • check_sender_access mapeamento:/blabla - verifica se o remetente tem acesso ao sistema

     

  • reject_unknown_sender_domain - rejeita remetentes com dominios desconhecidos

     

  • reject_unknown_recipient_domain - idem, para destinatarios com dominios desconhecidos

     

  • permit_sasl_authenticated - permite usuarios que se autenticaram no smtpd pelo mecanismo SASL

     

  • permit_mynetworks - permite o acesso por clientes de email nas redes incluidas na definicao do "mynetworks"

     

  • reject_unauth_destination - nega acesso a nao ser para os dominios que o Postfix recebe emails, incluindo rejeicao de relays

3.2. O que sao Mapeamentos

Mapeamentos sao, basicamente, macros onde passamos um valor e obtemos uma resposta. Os valores podem ser enderecos de remetentes, destinatarios, IPs, hostnames, dominios, ids, enderecos de Mail eXchangers (MX), ou qualquer outra coisa. As repostas podem ser uma das macros primitivas OK, REJECT, DISCARD, HOLD ou vazio, um valor arbitrario, ou uma outra macro pre-definida, que por sua vez contera mapeamentos que responderao com uma das macros primitivas, um valor arbitrario, ou uma outra macro pre-definida, que por sua vez...

As macros primitivas OK e REJECT tem seu significado bastante obvio; a macro DISCARD faz com que a mensagem seja silenciosamente descartada da fila sem notificar o remetente; HOLD coloca-a numa fila de inspecao (visualizada com o comando "postcat"), onde ela aguarda liberacao com o comando "postsuper". Uma resposta vazia faz com que se passe para a proxima macro na sequencia de verificacoes, ou, se for a ultima, encerra com um OK.

Por exemplo, eu posso usar a macro "check_client_access hash:/etc/postfix/ips-spammers" dentro do smtpd_client_restrictions; eu estaria perguntando para o backend hash usando o arquivo /etc/postfix/ips-spammers algo mais ou menos como: "e o IP 200.200.200.200? Deixo passar?" "REJECT com a mensagem Sai fora, spammer" ou "e o IP 10.10.10.10?" "Pesquise a macro VERIFICA_INTERNO"

3.3. Backends mais comuns

Quando se compila o Postfix sem nenhuma opcao especial, ele ja vem com os backends padroes: static, nis, regexp, environ, proxy, btree, unix, hash. Dependendo da versao da Berkeley DB e do sistema operacional, pode haver o backend dbm ou similares, sobrepondo o hash. Vale lembrar que mapeamentos baseados na Berkeley DB precisam ser "compilados" com o comando "postmap /algum/lugar/arquivo"; esse comando gera os indices e outras estruturas necessarias dentro do "/algum/lugar/arquivo.db".

Ha tambem os backends para MySQL e LDAP (bastante estaveis e robustos), que precisam ser explicitamente solicitados no momento da compilacao.

Adicionalmente, ha patches para os backends Postgre e TCP (estes nao sao tao estaveis e robustos ainda, embora funcionem bem). Falou-se um pouco na lista de discussao sobre patches que adicionem Oracle na lista de backends; este, no entanto, parece ser mais uma lenda urbana do que uma realidade solida e palpavel :)

3.4. Alguns Exemplos

HASH -

  /etc/postfix/remetentes_lixo:
  hotmail.com	REJECT Keep your junk mail
  hahaha@sexyfun.net	REJECT No, thanks

LDAP -

  dentro do main.cf:
  basedn = o=blablabla, c=br
  ldaphost = 10.10.0.2
  ldapmbox_timeout = 30
  ldapmbox_search_base = $basedn
  ldapmbox_server_host = $ldaphost
  ldapmbox_server_port = 389
  ldapmbox_query_filter = (mail=%s)
  ldapmbox_result_attribute = maildir
  ldapmbox_scope = sub
  ldapmbox_dereference = 0

REGEXP -

  /etc/postfix/client_dsl_ban:
  /.*dsl\..*/	REJECT No DSL allowed

3.5. Interoperacao de macros

A tarefa "smtpd" eh especialmente sensivel quanto a interoperacao de macros quando efetua suas verificacoes. Para evitar confusoes em ambiente pre/pos-chroot, e manter suas tabelas internas organizadas, ele se utiliza da configuracao "smtpd_restriction_classes" para saber quais macros nao-padrao serao aceitas dentro das verificacoes.

Assim, se pretendemos usar alguma de nossas macros dentro de verificacoes do smtpd, podemos declara-las como fazendo parte das restriction classes (embora nao seja obrigatoriamente necessario com versoes mais recentes do Postfix, ajuda a manter o smtpd organizado).

Os outros processos funcionam normalmente com o uso de macros.

4. Transportes

Eh possivel forcar alguns roteamentos de mensagens dentro das filas do Postfix. Quando se especifica um caminho diferente do que o sistema usaria normalmente, estamos criano um mapeamento de transporte.

Um transporte nao se refere apenas ao destinatario final da mensagem, a ser entregue via smtp; podemos criar mapementos de transporte para dentro de outros sub-processos do Postfix.

Por exemplo, podemos querer que o dominio zazazaza.net tenha suas mensagens entregues para uma base Cyrus, o bliblibli.org tera suas mensagens entregues via "maildrop" do Courier, mas um usuario fulano@bliblibli.org sera entregue em um mailbox padrao do sistema, no esquema tradicional do Sendmail. Ja emails para o dominio nerds.net sera repassado via SMTP para o servidor 10.10.10.10. Nota: Estes servicos precisam estar pre-definidos no master.cf para podermos usa-los.

Basta criarmos um mapeamento de transporte com a estrutura a seguir (exemplo usando o backend hash:) e referenciarmos dentro da diretiva "transport_maps" no main.cf (transport_maps = hash:/etc/postfix/transport)

  /etc/postfix/transport:
  fulano@bliblibli.org	local:
  zazazaza.net	cyrus-deliver:
  bliblibli.org	courier-maildrop:
  nerds.net	smtp:[10.10.10.10]

Um fato interessante a respeito do transporte "smtp:" - os colchetes [] dizem ao SMTP que entregue a mensagem ao destino especificado, sem procurar pelo MX do hostname/ip passado. Se tivessemos colocar "smtp:smtp.nerds.org", a tarefa "smtp", ao tentar fazer a entrega, procuraria pelo registro MX do host smtp.nerds.org ao inves de entregar diretamente ao host smtp.nerds.org.

5. Agentes

Alguns sub-processos do Postfix podem ser encarados como Agentes; eles serao responsaveis por entregar uma mensagem para algum lugar fora do Postfix.

5.1. Delivery Agents

Delivery Agents (como o proprio nome ja diz) sao agentes de entrega de mensagens. Alguns dos principais Delivery Agents dentro do Postfix sao:

local - emula o comportamento do nosso velho amigo Sendmail; entrega as mensagens no /var/spool/mail/USUARIO, le o /etc/aliases, aceita pipes nos aliases, passa pelo procmail, etc.

procmail - ele, por default, nao eh um Delivery Agent valido; ele faz parte do local delivery agent.

maildrop - esse faz parte das extensoes do Postfix, que nao fazem necessariamente parte dos comandos default. Voce precisa configura-lo no master.cf (ele usa o comando "pipe" do Postfix para repassar a mensagem para o maildrop); o Maildrop faz parte dos utilitarios do Courier.

lmtp - o Local Mail Transfer Protocol eh uma extensao do protocolo (E)SMTP; tem basicamente os mesmo comandos, embora seja desenhado para situacoes em que o recebedor nao gerencia fila (para funcionar como um Mail Delivery Agent, sem "queue")

virtual - eh o agente de entrega de correio que entende dominios virtuais. Com o local delivery agent, apenas o username (e nao username@dominio) eh considerado na hora de fazer uma entrega local. Ja com o virtual, podemos ter um mesmo username em dominios distintos com caixas de correio distintas. Por exemplo, agora podemos ter webmaster@meudominio1.com e webmaster@meudominio2.com (para quem faz hosting, isso eh um recurso indispensavel, uma vez que todo site hospedado quer ter seu proprio endereco de webmaster).

pipe - ja considerado anteriormente; abre as portas para qualquer agente externo de entrega (como o maildrop, por exemplo)

5.1.1. Maildir/Mailbox

Ja que estamos falando de Delivery, nada mais justo que comentarmos um pouco sobre os 2 formatos basicos de armazenamento de caixas de correio reconhecidos nativamente pelo Postfix.

O formato Mailbox eh aquele que guarda todas as suas mensagens num unico arquivo de spool. O formato Maildir utiliza uma estrutura de diretorios e arquivos independentes para arquivar mensagens.

O formato Maildir consiste em tratar cada mensagem como um arquivo independente dentro de um diretorio (por isso MAIL+DIR). Esse formato eh bastante interessante porque agrega muitas vantagens:

 

  • dispensa o uso de LockFiles para travar a Mailbox para que soh um processo escreva por vez, permitindo ter N programas escrevendo no mesmo Maildir sem problemas;

     

  • nao ha problemas com indexacao do mailbox;

     

  • desnecessario abrir e indexar o mailbox inteiro pra extrair uma unica mensagem;

     

  • nao ha corrupcao do mailbox, uma vez que eh um diretorio; o maximo que pode ocorrer eh uma mensagem se corromper;

Voce talvez esteja pensando: se Maildir tem tantas vantagens sobre Mailbox, por que nao se usou Maildir desde o inicio dos tempos?

Uma desvantagem que o Maildir causa eh quando se tem muitas mensagens pequenas. Dependendo do seu filesystem, cada arquivo vai ocupar blocos multiplos de 4k no disco (isso eh definido na hora da formatacao do filesystem). Isso quer dizer que mensagens com 1k irao ocupar 4k no disco, mensagens com 4.1k irao ocupar 8k, e assim por diante. Se houver 1000 mensagens com 1k ou 4.1k, por exemplo, teriamos um desperdicio de aproximadamente 3Mbytes.

No inicio da era da computacao, cada kbyte de disco rigido era defendido a unhas e dentes, uma vez que o custo de uma unidade de maior capacidade era bastante alto. O formato Mailbox promove uma melhor utilizacao do espaco em disco. Fora isso, normalmente se esperava que o usuario fizesse o download das mensagens e limpasse a caixa depois disso; nao se imaginava que seriam necessarios esquemas mais poderosos de indexacao de mensagens (para o uso com IMAP, por exemplo), uma vez que isso aconteceria no cliente de email, e nao no server.

Quem tem uma caixa de 100Mbytes arquivada no servidor, e que precisa ser acessada via IMAP, por exemplo, vai perceber a diferenca brutal de velocidade entre os 2 formatos ja na hora de indexacao. Num ambiente corporativo, sao razoavelmente comuns caixas de 200M, 500M ou mesmo 1Gbyte de emails, todos eles contendo informacoes importantes para a corporacao. Imagine agora como seria para apagar uma mensagem do "meio" da mailbox; todo o conteudo teria q ser copiado para um local temporario, excluindo aquele registro especifico, e depois copiado de volta do temporario para o Mailbox.

6. UCE/SPAM

UCE eh a abreviacao para Unsolicited Commercial Email, ou mensagem comercial nao-solicitada, tambem conhecido como o SPAM nosso odiado de cada dia. O Postfix conta com diversas regras e macros para ajudar no combate a SPAM.

Essas restricoes e macros tem se mostrado bastante efetivas. Note que a maioria dos grandes provedores brasileiros usa o Postfix em suas estrategias de combate a SPAM.

Vamos considerar algumas dessas restricoes:

6.1. Deteccao de clientes/MTAs "mal educados"

A maioria dos softwares de mailing normalmente pula algumas etapas da negociacao SMTP para agilizar o processo de entrega de SPAM. Outras vezes, quem escreveu o software de mailing possui um conhecimento superficial sobre o protocolo SMTP e nao implementa algumas regras pelo fato de desconhece-las. Essas violacoes de especificacoes do protocolo SMTP podem ser usadas na deteccao e combate a SPAM. Algumas das macros disponiveis sao:

 

  • check_helo_access, check_client_access, check_recipient_acccess, check_sender_access - Verificam a respectiva informacao (identificacao de maquina ou HELO, endereco IP ou hostname, destinatarios e remetentes) numa fonte de dados/mapeamento;

     

  • reject_unknown_sender_domain, reject_unknown_recipient_domain - Verificam se o dominio do remetente ou destinatario existem (possuem um registro DNS A ou MX);

     

  • reject_non_fqdn_sender/recipient - Impede o uso de "Abreviacoes" para remetentes e destinatarios; por padrao, o servidor adicionaria seu hostname quando o dominio do remetente/destinatario esta em branco;

     

  • reject_unknown_client - Impede que clientes sem registro de "reverso" (PTR) acessem o servidor;

     

  • reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_hostname - Forcam o uso de comandos HELO/EHLO validos no inicio da sessao SMTP; mostram-se bastante uteis no combate a "mailers", uma vez que a maioria deles usa hostnames falsos ou nao-completamente-qualificados (non_fqdn) no comando HELO. No mundo real, o "reject_unknown_hostname" causa mais dano do que beneficio, pois ele procura o endereco fornecido no DNS. Eh impressionante a quantidade de servidores (validos) usados nomes internos ou que nao podem ser resolvidos. Por exemplo, o nome DNS do servidor de e-mail pode ser mail.dominio.com, mas a maquina pode estar configurada para enviar emails como smtp.dominio.com;

Eh possivel tambem detectar ou forcar o uso de sintaxes especificadas em RFCs. As configuracoes possiveis no main.cf sao:

 

  • strict_rfc821_envelopes = yes - Exige que o endereco informado na sessao seja um endereco de email valido e contido entre <>. Por exemplo, seriam opcoes invalidas: MAIL FROM: teste@dominio.com , MAIL FROM: Email Teste <teste@dominio.com>; Apenas a forma MAIL FROM: <teste@dominio.com> seria valida.

     

  • smtpd_helo_required = yes - Exige que se passe um comando HELO/EHLO antes de passar os dados da sessao.

6.2. RBLs

RBLs (Real-time Black List - criadas em 1997 por Paul Vixie no projeto MAPS) durante muito tempo foram nossa unica arma contra sistemas mal-configurados (os Open Relays) ou contra spammers. A tecnica consiste em, de alguma forma, consultar uma lista que diz se o endereco IP pode ou nao acessar o servico.

A forma mais comum de RBL sao as DNSRBL (DNS RBL), onde a consulta eh feita via DNS. Por exemplo, supondo que estamos usando a RBL "relays.ordb.org" para saber se o IP 127.0.0.2 esta bloqueado ou nao. O endereco IP deve ser invertido para a consulta. Isso facilita termos no servidor DNS algo do tipo *.0.0.127. Fariamos uma consulta assim:

 

  $ host -t A 2.0.0.127.relays.ordb.org
  2.0.0.127.relays.ordb.org has address 127.0.0.2

Se o comando retornar um endereco IP, isso significa que o host esta bloqueado. Adicionalmente, pode haver tambem um registro TXT que informa o motivo do bloqueio. Por exemplo:

 

  $ host -t txt 2.0.0.127.relays.ordb.org
  2.0.0.127.relays.ordb.org text "Listed by ORDB - for testing purposes only"

Esse tipo de bloqueio tem se deteriorado bastante ultimamente; as RBLs funcionavam bem quando tinhamos "poucos" servidores de email. A tarefa de enviar email ficava sempre com o SMTP do provedor, pois as linhas discadas eram lentas e instaveis demais para se fazer o envio direto. Logo, os provedores prezavam seu nome; ter um servidor numa blacklist era uma desonra e uma desgraca para o SysOp do provedor. No entanto, com o aumento das conexoes "caseiras" de alta velocidade, associado a "anonimicidade" que os IPs dinamicos proveem, tem feito com que qualquer pessoa seja capaz de mandar toneladas de spam no conforto e seguranca de seu lar. Uma vez que seu IP dinamico atual foi bloqueado, voce simplesmente desconecta e pega outro IP e continua sua tarefa infame de envio de spam.

Para usar RBLs no Postfix, basta adicionarmos as macros "reject_rbl_client dominio.da.rbl" na configuracao smtpd_client_restrictions.

6.2.1. rhsbl

Uma evolucao das RBLs convencionais sao as RHSBL (Right-Hand-Side Blackhole List). Essas RBLs destinam-se a verificar a "parte da direita" dos enderecos. Ate o momento se usam 2 tipos de RHSBL, para dominios e para hostnames (ao inves de IPs).

As macros usadas pelo Postfix sao "reject_rhsbl_sender dominio.da.rbl" e "reject_rhsbl_client dominio.da.rbl" nas configuracoes de smtpd_sender_restrictions e smtpd_client_restrictions respectivamente.

6.3. SPF

SPF (Sender Policy Framework) eh uma especificacao adicional ao SMTP que esta em fase de publicacao em RFCs e apreciacao pela IETF. Basicamente, trata-se de uma maneira de dizer aos outros servidores na Internet de onde emails validos do seu dominio vem. Voce publica um registro no DNS do seu dominio especificando qual servidores podem enviar emails @seudominio.com.

Uma especificacao dessa impediria, por exemplo, a falsificacao de remetentes de correio, ou a acao de virus que mandam emails com remetentes randomicos.

O processo de adicionar o registro no DNS eh bastante simples de ser feito. Ha ate um wizard no site oficial do SPF - https://spf.pobox.com/

A partir da versao 2.1 do Postfix ja ha suporte ao SPF atravez do Policy Daemon. O Policy Daemon permite que voce chame tenha um servico externo ao Postfix fazendo verificacoes. No proprio site do SPF ha uma documentacao sobre integracao com Postfix.

6.4. Listas de palavras por cabecalho/corpo/anexos

Eh possivel usar filtros de conteudo simples com o Postfix, para efetuar uma filtragem basica de cabecalhos e corpo da mensagem. Trata-se das opcoes de configuracao header_checks e body_checks no main.cf. Por exemplo, podemos adicionar a linha "header_checks = regexp:/etc/postfix/regras_header", para usarmos o mapeamento de regular expressions para verificar os cabecalhos de acordo com regras no arquivo /etc/postfix/regras_header.

Esse tipo de filtragem permite que se barre mensagems na sessao SMTP, antes mesmo da mensagem passar para a fila. Embora isso possa ser vantajoso no sentido de nao ser necessario enviar uma mensagem de bounce ou retorno quando a mensagem nao eh aceita, pode trazer problemas serios de performance para o servidor, uma vez que a mensagem toda TEM que ser analisada e filtrada ANTES de se dar o "OK" na sessao SMTP.

Os filtros mais eficientes sao feitos com as opcoes de filtros de conteudo externos.

6.5. "Anvil" Service - deteccao automatica de DoS/Bulk Mailing

Esta eh uma feature do Postfix 2.1, ainda em estagio experimental (nao eh incluida na compilacao "default"). Trata-se de um servico do Postfix que mantem estatisticas sobre o numero de conexoes/minuto e o numero total de conexoes que um determinado host faz ao servidor SMTP.

O servico "anvil" eh capaz de bloquear um cliente se este comecar a fazer muitas conexoes de uma vez, ou muitas conexoes seguidas. Quem ja teve algum spammer tentando fazer bulk mailling no seu servidor sabe como isso pode ser incomodo.

Suas variaveis principais de configuracao sao:

 

  • smtpd_client_connection_count_limit - Numero maximo de conexoes por host

     

  • smtpd_client_connection_rate_limit - Numero maximo de conexoes/minuto que um host pode fazer

     

  • smtpd_client_connection_limit_exceptions - Hosts que podem "escapar" da restricao; normalmente, os hosts contidos em mynetworks.

7. LDAP no Postfix

O Postfix permite o uso de mapeamentos LDAP (ele nao eh compilado por default; de uma lida no LDAP_README - nao sao necessarios patches).

Com o LDAP, eh possivel montar uma infinidade de aplicacoes diferentes, interconectando com diferentes hosts ao mesmo tempo. Podemos acessar address books de servidores Lotus Notes, Microsoft Exchange, e outros.

A estrutura dos dados LDAP tende a ser mais flexivel que qualquer outra, inclusive bancos de dados MySQL, PostgreSQL e similares. A possibilidade de aplicar filtros nos resultados (com o _result_filter) abre muitas possibilidades interessantes, como a ideia do Mail Hub a seguir. Alem disso, bases LDAP sao facilmente replicaveis, permitindo a montagem de servidores de email com recursos de Fail Over (com Fail Over para os dados LDAP tambem, conforme mostrado a seguir)

7.1. Mail Hubs

Mail hubs sao concentradores de correio. Na verdade, o plano eh fazer com que varios Postfix possam entregar correio dentro de um mesmo dominio, mas com usuarios em servidores diferentes. Queremos que o usuario "fulano@meudominio.com" receba emails no servidor mail1.meudominio.com. Ja o usuario "beltrano@meudominio.com" deve recebe-los no servidor "mail2.meudominio.com". O "ciclano@meudominio.com" deve recebe-los num servidor XYZ. Isso tudo sem re-escrever o endereco do usuario (como mudar fulano@meudominio.com para fulano@mail1.meudominio.com).

Podemos fazer isso usando mapeamentos LDAP para a opcao "transport_maps". Um mapeamento de email pode ser algo parecido com isso:

  transport_maps = ldap:ldaptransport, hash:/etc/postfix/transport

  basedn = o=MinhaEmpresa
  ldaphost = localhost
  ldaptransport_timeout = 30
  ldaptransport_search_base = $basedn
  ldaptransport_server_host = $ldaphost
  ldaptransport_server_port = 389
  ldaptransport_query_filter = (&(mail=%s)(mailhost=*)(!(mailhost=$myhostname)))
  ldaptransport_result_attribute = mailhost
  ldaptransport_result_filter = smtp:[%s]
  ldaptransport_scope = sub
  ldaptransport_dereference = 0

Assim, teriamos uma entrada no LDAP similar a esta:

  dn: mail=fulano@meudominio.com, o=MinhaEmpresa
  objectClass: VirtualMailUser
  mail: fulano@meudominio.com
  homedirectory: /var/spool/vmail/fulano@meudominio/
  mailquota: 50000000
  mailhost: mail1.meudominio.com

  dn: mail=beltrano@meudominio.com, o=MinhaEmpresa
  objectClass: VirtualMailUser
  mail: beltrano@meudominio.com
  homedirectory: /var/spool/vmail/beltrano@meudominio/
  mailquota: 50000000
  mailhost: mail2.meudominio.com

  dn: mail=ciclano@meudominio.com, o=MinhaEmpresa
  objectClass: VirtualMailUser
  mail: ciclano@meudominio.com
  mailhost: xyz.meudominio.com

Nesse esquema, todos os servidores Postfix sao capazes de trocar mensagens com usuarios dentro do mesmo dominio, gracas as configuracoes de transporte de mensagem. Basta replicarmos os diretorios LDAP entre os multiplos servidores e ja montamos um esquema de mail hub usando Postfix e LDAP.

7.2. Verificando destinatarios em outros LDAPs

Podemos configurar nosso Postfix, por exemplo, como o MX de um dominio para depois repassar as mensagens para um servidor Exchange ou Notes. Seria interessante ja descartarmos mensagens para usuarios desconhecidos ja no Postfix, ao inves de repassar a mensagem para o Exchange ou Notes para que esses depois facam o bounce.

Podemos criar um mapeamento para o AD do Windows ou para o servidor LDAP do Notes assim:

  local_recipient_maps = ldap:ldapNotes

  ldapNotes_timeout = 30
  ldapNotes_search_base = o=CertificadorDoNotes
  ldapNotes_server_host = servidorLotusNotes
  ldapNotes_server_port = 389
  ldapNotes_query_filter = (mail=%s)
  ldapNotes_result_attribute = mail
  ldapNotes_scope = sub
  ldapNotes_dereference = 0

Da mesma forma poderiamos estar usando um Exchange, ou qualquer outra base LDAP disponivel.

7.3. Fail-Over de Fontes de Dados

Eh extremamente simples montar um Fail Over com servidores LDAP ou MySQL. Basta adicionar mais hosts no campo host da configuracao. Por exemplo:

  ldaptransport_server_host = servidor_ldap1 servidor_ldap2 servidor_ldap3 ...
  hosts = host1.dominio.com host2.dominio.com unix:/file/name

Note que adicionar hosts em um mapeamento LDAP eh diferente de adicionar mais mapeamentos LDAP pra hosts redundantes. Por exemplo, a configuracao a seguir NAO implementa mecanismos de Fail Over:

  virtual_mailbox_maps = ldap:ldapMailbox1, ldap:ldapMailbox2, ldap:ldapMailbox3

8. Conclusao

Espero ter conseguido passar um pouco da ideia do que o Postfix eh capaz de fazer. Existem muitos recursos a disposicao, e que podem ser combinados para criar outros recursos ainda mais poderosos. Tem principios robustos de funcionamento, e tem se mostrado bastante versatil e flexivel quando necessario.

Talvez a enorme quantidade de opcoes seja o Grande Trunfo e tambem a pior fraqueza do Postfix. Muitos usuarios novatos se perdem nos recursos e possibilidades da ferramenta.

Bom, era isso. Muito obrigado por ter acompanhado ate aqui!

9. Bibliografia

 

Voltar