Detalhes

Categoria: Como fazer instalações

Atualização: Domingo, 12 Abril 2009 16:25

Autor: vovó Vicki

Acessos: 14737

Os tutoriais sobre o Postfix anteriores a este consideram apenas um domínio canônico e contas Unix. Acontece que a maioria dos servidores web hospeda mais de um domínio e, para cada um deles, costumam existir dezenas, centenas e até milhares de usuários. Para criar endereços de email para os domínios hospedados e seus usuários existem algumas soluções. Neste tutorial veremos como implementá-las.

Domínios e Classes de Endereços

Antes de botar a mão na massa, alguns conceitos precisam ficar bem claros. Sei que é teoria pura, mas não tem como prosseguir sem ela. A primeira coisa é fazer a distinção entre domínio canônico e domínio hospedado.

Domínio canônico é o primitivo, ou seja, está diretamente associado ao hostname e ao endereço IP da máquina onde o Postfix está instalado. Também podemos considerá-lo como domínio principal ou domínio "chefe da casa". Mantendo o exemplo dos tutoriais anteriores, o domínio canônico será mail.numaboa.com.br com o endereço IP 100.200.300.402, de acordo com o que foi definido no Bind (veja "Arquivos de registros II" no tutorial "Bind na jaula"):

;
; numaboa.com.br.domain
;
...
mail            A               100.200.300.402
                MX              5 mail
...

Domínios hospedados são todos os domínios que convivem com o domínio canônico. Não estão associados ao hostname e, como não são proprietários da casa, podem ser considerados como convidados ou "fila bóia" Digamos que o chefe numaboa.com.br tenha colocado à disposição de numaboa.org seu endereço IP - eles têm o nome numaboa em comum, mas são de famílias diferentes: o chefe tem sobrenome .com.br e o fila bóia tem o sobrenome .org.

Os endereços eletrônicos dos habitantes destes domínios são de classes diferentes. A família do chefe, geralmente, tem endereços da classe domínio local. Já os convidados costumam ter endereços da classe domínio de alias virtual e/ou da classe domínio de mailbox virtual.

A classe domínio local é de contas do tipo Unix cujo destino final é o Postfix. O nome do domínio (e seus aliases) é fornecido pelo parâmetro mydestination, seus endereços são dados pelo parâmetro local_recipient_maps e o transporte é especificado pelo parâmetro local_transport, todos no arquivo de configuração /etc/postfix/main.cf.

A classe domínio virtual com alias atende domínios hospedados onde cada endereço tem um alias local Unix ou um endereço remoto. Os domínios virtuais são listados no parâmetro virtual_alias_domains, todos os endereços precisam ser um alias (apelido) de algum outro endereço (local ou remoto) e não existe um parâmetro para o tipo de transporte.

A classe domínio virtual com caixa postal é o destino final para domínios hospedados onde cada endereço possui uma caixa de correio própria e os destinatários não precisam ter uma conta Unix. Os nomes dos domínios são listados no parâmetro virtual_mailbox_domains, os endereços são fornecidos pelo parâmetro virtual_mailbox_maps e o transporte é especificado através do parâmetro virtual_transport.

Soluções possíveis

De acordo com o tipo de domínio e as classes de endereços, podemos criar vários tipos de solução. As mais comuns estão listadas a seguir:

• Domínio canônico com contas Unix
• Domínios compartilhados com contas Unix
• Domínios separados com contas Unix
• Domínios separados com contas não Unix

Cada uma das soluções será vista em detalhes a seguir.

Domínio canônico + contas Unix

Se você seguiu os tutoriais anteriores a este, a solução de domínio canônico com contas Unix é a configuração do Postfix citada nos tutoriais Slackware + Postfix (formato mailbox) e Slackware + Postfix + Maildir (formato Maildir). Nesta solução, apenas os usuários do sistema podem enviar e receber emails. Já pensou um servidor de email deste tipo com milhares de usuários, onde o administrador do sistema precisa cadastrar cada um deles? Seria de endoidar :nuts:

Só para refrescar a memória, os atuais parâmetros desta configuração são (/etc/postfix/main.cf):

myhostname = mail.numaboa.com.br
mydomain = numaboa.com.br
mydestination = $myhostname, $mydomain, localhost.$mydomain, ns1.$mydomain,
  ns2.$mydomain, www.$mydomain, webmail.$mydomain, ftp.$mydomain
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
local_transport = local:$myhostname
home_mailbox = Maildir/
mail_spool_directory = /home/postfix

Domínios compartilhados + contas Unix

O exemplo mais simples de domínio canônico + domínios hospedados com contas Unix é colocar os domínios hospedados no parâmetro mydestination. São chamados de domínios compartilhados porque compartilham o mesmo destino. Considerando numaboa.org como domínio hospedado, teremos:

myhostname = mail.numaboa.com.br
mydomain = numaboa.com.br
mydestination = $myhostname, $mydomain, localhost.$mydomain, ns1.$mydomain,
  ns2.$mydomain, www.$mydomain, webmail.$mydomain, ftp.$mydomain, numaboa.org
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
local_transport = local:$myhostname
home_mailbox = Maildir/
mail_spool_directory = /home/postfix

Assim como no modelo anterior, esta solução exige que cada usuário tenha uma conta Unix, ou seja, sobra novamente para o administrador do sistema :nuts:

Existe um problema adicional neste tipo de solução. Digamos que exista um usuário local registrado como maria, que queira um endereço adicional como usuário maricota e que toda a correspondência seja entregue na mesma caixa postal. Não tem como fazer! O administrador do sistema vai precisar criar dois usuários locais que terão caixas de correio separadas. Mas a encrenca não pára por aí: o usuário maria vai receber não só os emails que tenham o endereço maria@numaboa.com.br, como também os que tenham o endereço maria@numaboa.org!

Mas nem tudo é desvantagem. Com esta solução, um administrador que tenha vários domínios sob a sua responsabilidade pode, por exemplo, criar um usuário postmaster e, independentemente do domínio que conste no endereço (postmaster@numaboa.com.br, postamaster@numaboa.org, etc), todos os emails enviados para postmaster irão para a mesma caixa postal. Sob este aspecto, isto facilita a vida do administrador. Mesmo assim não vale a pena, pois o trabalho de gerenciar o resto é um tormento.

Domínios separados + contas Unix

Para evitar os problemas de domínios compartilhados, o jeito é separar o domínio canônico dos domínios hospedados declarando os domínios hospedados como domínios virtuais. As contas Unix de usuários de domínios canônicos são encontradas pelo sistema porque estão num mapa próprio (unix:passwd.byname). Quando criamos um domínio virtual, os endereços também são virtuais e precisam ser apontados para usuários locais que tenham contas Unix. É aí que entra um mapa de aliases que fará a "tradução" de endereços para usuários.

Para declarar um domínio como virtual, existe o parâmetro virtual_alias_domains e, para declarar o mapa de aliases, há o parâmetro virtual_alias_maps. Além disso, mais duas coisas devem ser observadas: os domínios virtuais NÃO podem ser listados no parâmetro mydestination porque senão o agente de entrega fica todo embananado e os domínios virtuais NÃO podem constar no parâmetro relay_domains. Veja como fica a configuração em /etc/postfix/main.cf:

myhostname = mail.numaboa.com.br
mydomain = numaboa.com.br
mydestination = $myhostname, $mydomain, localhost.$mydomain, ns1.$mydomain,
  ns2.$mydomain, www.$mydomain, webmail.$mydomain, ftp.$mydomain (não pode ter numaboa.org)
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
local_transport = local:$myhostname
home_mailbox = Maildir/
mail_spool_directory = /home/postfix
virtual_alias_domains = numaboa.org
virtual_alias_maps = hash:/etc/postfix/mapa_virtual

Observe que os dois novos parâmetros estão no plural (domains e maps). Isto significa que podemos declarar vários domínios virtuais e vários mapas virtuais. No parâmetro virtual_alias_maps informamos que o mapa é do tipo hash, está no diretório /etc/postfix/ e se chama mapa_virtual. Se tivermos dois usuários registrados (teste e teste1), um exemplo de mapa de aliases seria:

numaboa.org            DOMÍNIO

info@numaboa.org       teste
contato@numaboa.org    teste

duvidas@numaboa.org    teste1

# Qualquer endereço não resolvido
@numaboa.org           teste1

A primeira linha diz que numaboa.org é um domínio virtual (a porção da direita, DOMÍNIO, é ignorada). Isto parece chover no molhado porque já declaramos numaboa.org como sendo um domínio virtual com alias usando o parâmetro virtual_alias_domains. Acontece que, se esta declaração não existir, as mensagens serão rejeitadas com "relay access denied" ou .

As linhas em branco ou iniciadas com # são ignoradas. Os endereços completos apontam para usuários locais e @numaboa.org é chamado de catch all (pega tudo) porque aponta para um usuário local todos os endereços que não estejam referidos. Não costumo usar o catch all porque acabo recebendo um caminhão de spams, principalmente daqueles engraçadinhos que criam endereços de A a Z para determinado domínio!

O domínio virtual possui seu próprio espaço de nomes de usuários. Isto significa que os nomes dos usuários locais não são visíveis num domínio virtual com alias. Tá complicado? É o seguinte... se enviarmos um email para teste@numaboa.org, este endereço não existe. Isto significa que o usuário local teste não é visível no domínio numaboa.org (e nem em qualquer outro domínio virtual). Se quisermos que este seja um endereço válido, ele precisaria estar declarado no mapa de aliases, ou seja, precisaríamos adicionar a linha

teste@numaboa.org       teste

Caso você tenha mais de um domínio virtual, não é preciso criar um mapa de aliases para cada um deles. Um único mapa de aliases pode declarar vários domínios virtuais e múltiplos endereços para usuários com contas Unix. A desvantagem desta solução continua sendo a criação das contas locais. Já a vantagem é que um mesmo usuário vai poder ter quantos endereços quiser (tanto no domínio canônico quanto nos domínios virtuais), com a correspondência centralizada numa única caixa postal.

Mas ainda falta uma etapa para fazer este modelo funcionar. O mapa de aliases precisa ser transformado num arquivo indexado e o Postfix precisa ser informado das mudanças. Usamos a ferramenta postmap para indexar o mapa_virtual e criar o arquivo mapa_virtual.db.

# postmap /etc/postfix/mapa_virtual
# postfix reload

Para testar esta configuração basta enviar um email para qualquer um dos usuários configurados no mapa usando o mailto ou um cliente de email. Não se esqueça que este email vai parar na caixa postal do usuário local teste ou teste1.

Domínios separados + contas não Unix

Em sistemas com vários domínios virtuais e um montão de usuários o gerenciamento de contas Unix dá um trabalho maluco. Até agora só vimos a atuação do agente de entregas local do Postfix. Mas, se é possível criar domínios virtuais, porque não acionar um agente de entregas virtual? Graças a Deus o Wietse Venema, autor do Postfix, pensou nisso e deu uma solução

Com o agente de entregas virtual, cada endereço pode ter sua própria caixa postal (mailbox) virtual. Ao contrário dos domínios virtuais com alias, os domínios virtuais com mailbox não precisam de traduções e os proprietários da caixa de correio virtual não precisam ter uma conta Unix.

O agente de entrega virtual controla o caminho da caixa postal, a uid (identificação do usuário) e a gid (identificação do grupo) usando tabelas específicas. E aí você pensa... xiiii, com alias só havia uma tabela para controlar, agora são três? Mas garanto que a solução é boa: uma vez que este modelo esteja funcionando com as tabelas, migrar para uma base de dados SQL são dois palitos. Aliás, este será o tema do próximo tutorial.

Bem, então vamos fazer estas tabelas funcionarem. Você se lembra que no modelo anterior usamos alguns parâmetros para informar o Postfix de que queríamos habilitar domínios virtuais com alias. Neste caso, a coisa não é muito diferente. Existem parâmetros específicos para esta solução. Veja o que é preciso adicionar ao /etc/postfix/main.cf:

virtual_mailbox_domains = numaboa.org
virtual_mailbox_base = /home/postfix
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_minimum_uid = 100
virtual_uid_maps = static:1020
virtual_gid_maps = static:1020
virtual_alias_domains =
   (não pode referir numaboa.org)

Com virtual_mailbox_domains = numaboa.org declaramos o domínio numaboa.org como sendo do tipo virtual com mailbox. Todo endereço criado para este domínio irá para um diretório próprio criado em /home/postfix/ e a lista de endereços se encontra no arquivo /etc/postfix/vmailbox. Primeiro algumas considerações sobre o domínio.

Se declaramos o domínio numaboa.org como sendo virtual, ele NÃO pode ser declarado junto com o domínio canônico nos parâmetros mydestination e realy_domains. Mas tem mais: se declaramos o domínio como virtual com mailbox, ele NÃO pode também ser declarado como domínio virtual com alias. Ou bem uma coisa, ou bem outra para não acionar dois agentes de entrega diferentes para realizar a mesma tarefa. Caso você opte por usar domínios virtuais com alias e com mailbox (o que você pode fazer sem problemas com domínios virtuais diferentes), tome muito cuidado para não incluir um coringa de caixa postal de um domínio virtual com mailbox (por exemplo, @numaboa.org) no arquivo de aliases.

Proprietários

Os usuários locais são os proprietários dos seus diretórios (por exemplo, o diretório /home/postfix/teste/ é de teste:users). Como os usuários virtuais não podem ser proprietários de nada, eles precisam de uma espécie de fiador. Para exercer esta função vamos criar o usuário fiador com uid 1020 e o grupo fiador com gid 1020:

# groupadd -g 1020 fiador
# useradd -d /home/postfix -g 1020 -u 1020 -s /bin/false fiador

Este será o fiador para todos os usuários sem contas locais pois foi "empossado" através dos parâmetros virtual_uid_maps = static:1020 e virtual_gid_maps = static:1020.

DICA: lembre-se destas uid e gid porque ainda serão utilizadas em configurações importantes nos tutoriais que fazem parte do pacote Postfix.

No tutorial Slackware + Postfix + Maildir criamos os diretórios base para as caixas de correio, só que usamos a identidade root. Isto fez com que o proprietário destes diretórios ficassem como root:root. Verifique com:

# ls -l /home
drwxr-xr-x  6 root root 168 2006-02-26 17:32 postfix/

Mude o usuário e o grupo e confira:

# chown fiador:fiador /home/postfix
# ls -l /home
drwxr-xr-x  6 fiador fiador 168 2006-02-26 17:32 postfix/

Se não fizermos esta alteração, os arquivos de emails não podem ser salvos nos respectivos diretórios por falta de autorização.

O mapa de dados

Indicamos como fonte de dados o arquivo vmailbox. Este arquivo precisa ser criado com o seguinte formato:

maria@numaboa.org     numaboa.org/maria/
pedro@numaboa.org     numaboa.org/pedro/
teste@numaboa.org     numaboa.org/teste

Cada linha deste arquivo especifica um endereço e o diretório onde deve ser criada sua caixa postal. Observe que os diretórios dos usuários maria e pedro terminam com uma barra (/) e que o do usuário teste termina sem barra. Quando existe a barra no final, os emails serão guardados no formato Maildir (um arquivo para cada email); caso contrário, os emails serão armazenados no formato mailbox (todos os emails num único arquivo).

Observe que há um usuário local teste e um usuário virtual teste. Não há problema algum. As mensagens para teste@numaboa.com.br serão entregues na caixa postal /home/postfix/teste/Maildir/new/ e as para teste@numaboa.org serão entregues na caixa postal /home/postfix/numaboa.org/teste/new/ porque os agentes de entrega são diferentes e trabalham com parâmetros de configuração diferentes. É coisa do tipo carta registrada e Sedex - tudo acontece no correio, mas os sistemas de entrega não se misturam.

Agora só falta indexar o mapa e atualizar o Postfix, ou seja:

# postmap /etc/postfix/vmailbox
# postfix reload

Prontinho! O postmap criou o arquivo vmailbox.db e o Postfix foi avisado das alterações. Agora é cruzar os dedos e partir para os testes. Com tanta coisa, será que ficou algum erro? :bug:

Os testes

Esta última configuração, sem dúvida nenhuma, é a mais versátil e a mais fácil de gerenciar. Juntamente com a configuração do domínio canônico + usuários locais, é a que vai ficar disponível para os próximos tutoriais. Mas vamos aos testes.

Podemos usar o mailto ou um telnet na porta 25 para enviar um email para qualquer um dos usuários configurados em vmailbox. Digamos que o cliente seja o mailto e que o usuário seja maria (não esqueça de terminar o texto com Ctrl-D):

# mailto
   To: maria@numaboa.org
   Subject: Teste
   Teste virtual
EOT

Como este é o primeiro email que maria recebe, os diretórios da caixa postal devem ser criados. Como configuramos o usuário maria com o padrão Maildir, os diretórios criados devem ser:

home ---|
        |--- postfix ---
                       |--- numaboa.org ---
                                          |--- maria ---
                                                       |--- cur
                                                       |--- new
                                                       |--- tmp

O email enviado deve estar em /home/postfix/numaboa.org/maria/new/ identificado com algo parecido com 1142990362.V304I54eM695619.ns2.

# cd /home/postfix/numaboa.org/maria/new
# cat 1142990362.V304I54eM695619.ns2
Return-Path: 
X-Original-To: maria@numaboa.org
Delivered-To: maria@numaboa.org
Received: by mail.numaboa.com.br (Postfix, from userid 0)
        id A38231C690; Tue, 21 Mar 2006 22:19:22 -0300 (BRT)
MIME-Version: 1.0
To: maria@numaboa.org
Subject: Teste
Message-ID: <0_14544_1142990362_1@ns2>
Content-ID: <0_14544_1142990362_2@ns2>
Content-type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 21 Mar 2006 22:19:22 -0300 (BRT)
From: root@numaboa.com.br

Teste virtual

Podemos complementar o teste enviando um email para maria, pedro ou teste usando um cliente externo. O resultado deve ser o mesmo. Caso os testes não funcionem como o esperado, não esqueça de verificar o log do Postfix e do sistema com

# tail /var/log/maillog
# tail /var/log/syslog

Leia com atenção as mensagens para tentar descobrir o tipo e a localização do erro. Vai aqui mais uma dica.

:lapis: DICA: existe mais um arquivo de configuração do Postfix que não citei até agora. É o /etc/postfix/master.cf. Edite este arquivo e aumente o nível de debug do smtp adicionando -v à linha:

smtp      inet  n       -       n       -       -       smtpd -v

Colocando o smtp em verbose (-v), até pensamento é logado! Isto deve ajudar.

Considerações finais

O servidor de emails está ficando cada vez mais parrudo (e versátil também). Mas existem ainda uma porção de brechas. Por exemplo, a única autenticação até o momento é a existência de um usuário local "aliasado" ou de um usuário virtual. Todos têm permissão (relay) para alcançar outros usuários locais e virtuais, mas não têm relay para endereços externos... por enquanto. Mas não há males sem cura. Isto pode ser feito através de uma autenticação SASL - caso o usuário interno (local ou virtual) se autentique, então recebe autorização para relay externo. Este será o tema do tutorial Slackware + Postfix + SASL, mas não vamos dar o passo maior do que a perna. Antes disso falaremos sobre como substituir a base de dados do Postfix (o que acabamos de fazer) por uma base de dados SQL :thumbup: