você está aqui: Home → Colunistas → Sysadmin
Por Rubens Queiroz de Almeida
Data de Publicação: 06 de Agosto de 2007
Qualquer sistema de correio eletrônico possui uma forte relação com os serviços providos por servidores de nomes. Da mesma forma que nos referimos a computadores por meio de seu nome, que precisam ser traduzidos por um servidor de nomes em endereços IP válidos para que a comunicação efetivamente comece, também o correio eletrônico faz uso deste serviço. Endereços eletrônicos possuem dois componentes: o nome do usuário e o domínio onde possui uma conta, como em pedro@example.com.br.
É claro que para uma mensagem chegar em Pedro o servidor de correio eletrônico precisa antes determinar quem é responsável pelo recebimento de mensagens destinadas ao domínio example.com.br. Justamente neste ponto recorremos novamente ao bom e velho DNS.
Para simplificar esta explicação, tomaremos por base um serviço de correio eletrônico baseado no sendmail, que ainda hoje é o software mais utilizado mundo afora.
Uma implementação correta de gerenciamento de mensagens requer uma coordenação precisa entre o DNS e o sendmail. Para processar uma mensagem o Sendmail envia uma pergunta ao servidor DNS local e solicita os registros MX (Mail Exchanger) para aquele domínio. Por exemplo, para enviar uma mensagem para pedro@example.com.br, o Sendmail irá procurar registros MX para o domínio example.com.br.
O servidor DNS irá responder com todos os registros MX que encontrar para aquele domínio, frequentemente mais de um e em média dois. Caso o recipiente não possua registros MX o Sendmail solicitará então registros do tipo CNAME ou A de maneira a poder conectar-se à máquina destino.
Podem ser definidos vários registros MX para um domínio. Um registro MX contém um campo que indica, dentre os servidores de email disponíveis (Mail eXchangers), a preferência que deve ser obedecida para a entrega de mensagens.
Tomemos mais uma vez o exemplo do nosso velho conhecido Pedro. O endereço do Pedro é pedro@example.com.br. Não existe (embora seja possível, não é recomendável) um computador denominado example.com.br. Para se realizar entrega de mensagens para endereços como o de Pedro é necessário que o programa sendmail interaja com o DNS para obter nomes de computadores reais que façam a entrega destas mensagens.
Vejamos como isto ocorre no DNS:
% $ host -t mx example.br unicamp.br mail is handled by 5 smtp.example.com.br. unicamp.br mail is handled by 0 terra.example.com.br
O comando acima indica que eu quero obter do servidor DNS apenas registros do tipo MX.
O domínio example.com.br possui dois servidores que podem atendê-lo, smtp.example.com.br e terra.example.com. A cada um destes servidores está associado um número. Este número indica a prioridade que cada um dos servidores possui. Quanto mais baixo o número mais alta a prioridade.
Todas as mensagens enviadas para determinado domínio possuem uma ordem de precedência quanto ao computador que irá recebê-las. Desta forma, mensagens enviadas para o domínio example.com.br devem ser entregues primeiramente à maquina terra.example.com.br (valor 0). Caso esta máquina esteja fora do ar, as mensagens devem então ser entregues à máquina smtp.example.com.br (valor 5).
O fato de que eu tenha dois servidores que possam receber mensagens endereçadas a um domínio como example.com.br não implica no fato de que os usuários tenham contas nas duas máquinas.
Quando alguém manda uma mensagem para pedro@example.com.br, o programa sendmail que irá fazer a entrega da mensagem primeiramente faz uma consulta ao DNS pedindo os registros MX associados ao domínio example.com.br. De posse das respostas, ele tentará entrar em contato com o servidor especificado no registro MX de mais alta prioridade (valor mais baixo). Este servidor, o de prioridade mais alta, normalmente é o servidor onde as pessoas possuem suas contas. Ou seja, se este servidor estiver no ar e funcionando perfeitamente, o programa sendmail deste servidor irá aceitar a conexão, receber a mensagem, e gravá-la na mailbox do usuário pedro.
Caso ele não esteja funcionando, o programa sendmail tentará então entrar em contato com o servidor especificado no registro MX seguinte. O usuário pedro não possui conta neste segundo servidor. O que ocorre então? A mensagem é recebida e, ao invés de ser gravada na caixa postal do usuário (que não existe neste equipamento), é mantida na área de armazenamento (spool) de mensagens. Esta mensagem ficará então na fila e de tempos em tempos o sendmail tentará se conectar com a máquina destino, para fazer a entrega da mensagem.
Sistemas de correio eletrônico baseados no sendmail adotam como padrão um prazo de cinco dias para a entrega de mensagens. Caso não se consiga entregar a mensagem neste prazo é enviada uma mensagem de erro ao usuário comunicando o ocorrido, informando que o destinatário está inacessível. Vejamos um exemplo de erro.
Diagnostic-Code: X-Postfix; [zong.com.br]: Name or service not known
Ao enviar uma mensagem de teste para este domínio geramos um erro, onde o programa de correio eletrônico reclama que o nome ou serviço de destino não existe. O DNS também emite uma mensagem de erro:
host -t mx zong.com.br Host zong.com.br not found: 2(SERVFAIL)
Alguns pontos importantes a serem lembrados. Os servidores MX de determinado domínio devem residir em redes diferentes, o mais afastadas possível. Caso residam em redes diferentes mas compartilhem a mesma linha de comunicação para acesso à Internet, a mesma tomada elétrica, etc., não adianta muita coisa. Se o canal de comunicação falhar, as duas ou mais máquinas ficam inacessíveis e a mensagem não será entregue. Se possível, coloque os servidores MX de seu domínio em redes diferentes, como por exemplo, uma delas no tronco da Rede Nacional de Pesquisa (RNP) da Internet Brasil e outra no tronco Embratel. Desta forma você garante que mensagens enviadas para o seu domínio sempre cheguem.
A escolha de um servidor MX secundário deve ser feita em comum acordo entre os administradores dos dois sistemas. Até pouco tempo atrás o programa sendmail tinha como configuração padrão aceitar mensagens de outros domínios. Frequentemente administradores configuravam seus registros MX apontando para servidores cujos administradores nem mesmo conheciam. O pior de tudo é que, devido à configuração aberta do sendmail naqueles tempos, tudo funcionava e ninguém desconfiava de nada. Hoje em dia, com a indústria do spam cada vez mais vigorosa, tais descuidos não são mais possíveis ou recomendáveis. Máquinas com servidores de correio eletrônico permissivas, que aceitam tudo que aparecer, em pouco tempo estarão distribuindo mensagens de spam para os quatro cantos do mundo. Recomendamos que a escolha do seu servidor secundário seja muito bem acertada com alguém que conheça e que poderá lhe ajudar em caso de problemas.
Suponhamos então que seu servidor principal de correio eletrônico tenha um problema e o reparo demore muito. Contacte o administrador do seu servidor MX secundário e peça a ele salvar as mensagens destinadas ao seu domínio em uma área alternativa. Desta forma economizamos tempo de processamento do servidor secundário visto que ele não ficará tentando entregar, a intervalos normalmente definidos em uma hora, mensagens que não podem ser entregues.
Nunca se esqueça de avisar o administrador do servidor MX secundário quando houverem problemas com o servidor primário, especialmente se o seu domínio recebe muitas mensagens. Se o servidor secundário for uma máquina com poucos recursos de armazenamento, problemas sérios poderão ocorrer. Se a partição onde as mensagens são armazenadas se encher, mensagens para o domínio que o servidor secundário atende também serão devolvidas e teremos dois problemas ao invés de um. Como estas coisas de um ser servidor secundário de outro geralmente funcionam no favor, não é bom complicar a vida de quem está te ajudando.
Uma vez que a sua máquina voltar a funcionar, o administrador do servidor MX secundário poderá invocar o sendmail para processar especificamente a fila de mensagens para o seu domínio.
Suponhamos que isto tenha sido feito movendo-se as mensagens para o diretório /var/spool/example.back. Para invocar o sendmail fazendo com que ele utilize este diretório basta invocá-lo com as seguintes opções abaixo:
# /usr/sbin/sendmail -OQueueDirectory=/var/spool/example.back -q -v
Uma outra alternativa é gravar em fita ou CDROM todas as mensagens acumuladas no período de problemas e entregá-las ao administrador do sistema primário, para que o próprio sendmail de seu equipamento faça a entrega final.
Uma consideração final, todas as precauções sugeridas para os servidores MX secundários se aplicam também aos servidores DNS secundários. Para ficar garantido, coloque o seu servidor primário no Brasil e um secundário na Austrália. Só para garantir, se possível, é claro.