O e-mail é algo tão presente no nosso dia a dia que
poucas vezes paramos para pensar em toda a complexidade que está
envolvida por trás do funcionamento desse serviço. É muito semelhante a
outros serviços básicos, como energia elétrica, por exemplo. Alguém já
parou pra pensar sobre os meios geração, produção, transporte e
distribuição de energia elétrica? E de e-mails? Às vezes parece que
funciona por mágica e a intenção é que os usuários realmente pensem
assim, mas a coisa não é tão simples, na prática.
E não é difícil imaginar que haja muita magia de verdade
envolvida na configuração de um servidor de e-mail, especialmente quando
você precisa configurar um deles para enviar e-mails autênticos. São
muitas variáveis envolvidas e algumas formas de trabalho diferentes
entre cada tipo de servidor de e-mail, o que dificulta um pouco as
coisas. Mas alguns conceitos importantes nós devemos conhecer a fundo,
pois serão úteis em qualquer ambiente e com qualquer aplicação de
servidor de e-mail.
Apenas uma observação: eu não sou especialista em
administração de servidores, muito menos em servidores de e-mails, as
dicas a seguir são fruto de muito estudo, tentativas, erros e acertos
até chegar numa configuração e num conhecimento que estão me atendendo.
O host, hostname e domain
Você sabe (sem consultar) qual o FQDN (Fully Qualified Domain
Name) da sua máquina? E dos servidores que você usa e/ou
administra? É comum que você não saiba, principalmente se não forem
servidores de e-mail ou web.
O FQDN nada mais é do que o nome do host (hostname) junto com o nome
do domínio (DNS). Na maioria dos servidores, especialmente os de
desenvolvimento, a maior importância do hostname é a possibilidade de
dar nomes personalizados para as máquinas, mas em produção isso tem uma
importância bem grande.
A configuração e validação por SPF
SPF Sender Policy Framework é uma tentativa para
controlar a quantidade de e-mails forjados que circulam na internet.
Como encontramos no FAQ
do SPF: “SPF não é anti-spam da mesma forma que a farinha não é
comida, é parte da solução”. O SPF é um das configurações mais
importantes para a maioria dos seus e-mails serem entregues com sucesso,
especialmente se você quiser entregar e-mail para os servidores do
gmail.
Citando um pouco o FAQ do SPF: “O SPF é um protocolo desenvolvido
por um grupo de voluntários, motivados e unidos por um desejo em comum
de melhorar o funcionamento da internet. Não é um produto comercial
oferecido por uma empresa com fins lucrativos”. O protocolo SPF
está sendo adotado por um número crescente de servidores de hospedagem e
ISPs Internet Service Providers, tornando-se cada vez mais
importante e essencial para o funcionamento correto de um servidor de
e-mails.
Na configuração do DNS do domínio, o SPF aparece como uma entrada TXT
comum, com esta aparência:
v=spf1 a mx ...
Para consultar as entradas TXT de um domínio, use: dig txt dominio.com.
Um exemplo completo de configuração de SPF:
v=spf1 a mx ip4:192.168.1.2
include:aspmx.googlemail.com include:google.com include:_spf.google.com
-all
Nessa configuração, estou dizendo que, para o domínio em questão
(imaginando o jeveaux.com), o IP 192.168.1.2 é um IP válido para enviar
e-mails utilizando o domínio jeveaux.com. Além disso, estou incluindo os domínios de envio do Google para que possam também enviar
e-mails utilizando o meu domínio (nesse caso, através do google apps).
É importante reparar um detalhe no final: -all. Esta cláusula está
informando que qualquer outro IP (all) deverá ser negado (-), mas pode
ser configurado de outras maneiras se você precisar, usando o -all
ou diretamente um IP:
- -all Fail Recusa qualquer e-mail partindo de outros IPs
que não estiverem na configuração do SPF - +all Pass Significa que todo IPs (todo mundo) está
autorizado a enviar e-mails em nome do seu domínio - ~all SoftFail Intermediário entre o Fail (-) e
o Pass (+). Geralmente usado em transições de domínios ou
servidores de domínios - ?all Neutral O dono do domínio não tem como ou não quer
definir quem está autorizado a enviar e-mails em nome do seu domínio
Mais informações e
detalhes sobre o SPF aqui no Antispam.br.
MX ou A records?
Essa é uma dúvida que eu já tive diversas vezes e sempre precisei
pensar e repensar a mesma coisa várias e várias vezes. Mas é muito mais
simples do que parece, vejamos por necessidade:
- O servidor de e-mails em questão funciona apenas como SMTP (envio)
ou também é utilizado como POP/IMAP (recebimento)?
Se a resposta for SIM, o seu servidor de e-mails
apenas envia e-mails, esqueça a configuração dos MX Records, pois elas
não lhe serão úteis, preocupe-se apenas com que exista um registro do
tipo A no seu domínio contendo o nome (o hostname visto acima) do seu
servidor associado com o IP do mesmo.
Se a resposta for NÃO, o seu servidor de e-mails
também receberá e-mails, então lembre-se também de configurar
corretamente os registros MX no seu domínio. Mas como neste artigo estou
focando apenas no envio, não entrarei em detalhes na configuração do MX. Para mais informações, siga
por aqui.
DNS Reverso
DNS o quê!? Reverso!? Pois é, DNS reverso. Pense num domínio: é um
nome que encaminha você até um determinado servidor IP. Agora pense de
maneira reversa, ao contrário: a partir de um determinado servidor ou
IP, como chego ao domínio? Pois é isso que faz a configuração do DNS
reverso, ela permite que outros servidores verifiquem a identidade do
seu servidor comparando se um determinado IP bate com o IP informado no
servidor de DNS.
Exemplo: Verificando o IP de um domínio através da resolução de DNS.
jeveaux@valakas ~ $ host giran.com.br
giran.com.br has address 109.74.206.147
E agora fazendo a resolução reversa, de um IP para o domínio.
jeveaux@valakas ~ $ host 109.74.206.147
147.206.74.109.in-addr.arpa domain name pointer giran.com.br.
Na maioria dos casos, essa configuração será até fácil, basta pedir ao
responsável pelo seu servidor de DNS que o faça. Exceto se você for o
responsável também pelo servidor de DNS, então você terá que fazer a
configuração do DNS reverso também. Se você precisar configurar
manualmente o seu DNS reverso, precisará saber um pouco sobre o BIND,
recomendo este
tutorial do Dicas-L.
Resumindo o que é importante lembrar
Se você quiser enviar e entregar e-mails corretamente para todos os
servidores ou o máximo possível, lembre-se de configurar
corretamente:
- O hostname e domínio do seu servidor de e-mail
- O DNS do domínio com uma entrada válida no SPF para o IP do servidor
de e-mails - O DNS reverso no servidor de DNS da rede do servidor para o nome
configurado no registro A (próximo passo) - O DNS do domínio com um registro do A apontando para o IP do seu
servidor de e-mails
Alguns servidores de e-mail farão apenas a verificação por SPF ou
DNS, por isso, configure sempre os dois, não custa nada e vai poupar
algumas dores de cabeça e muitas falhas na entrega dos e-mails.
Um cenário fictício baseado no meu cenário real
Basicamente omiti apenas os nomes e os endereços IP dos hosts por
outros que não são válidos, mas que são suficientes para exemplificar.
Vamos ao exemplo:
O domínio jeveaux.com.br, registrado no registro.br, está usando os
servidores de DNS da Linode. Imaginando uma situação onde temos uma
infra-estrutura grande e que uma determinada aplicação precise enviar
muitos e-mails, o site ficará num servidor (srv1) e o servidor de
e-mails ficará em outro servidor (srv2), logo, teremos dois IPs diferentes.
- srv1:
apenas servidor web (o site, apache), IP 192.168.1.1 - srv2:
apenas servidor de e-mail (postfix, sendmail, etc), IP 192.168.1.2
Servidores configurados, tudo funciona. Então vem o primeiro
problema: meus e-mails não estão nem caindo como spam, eles sequer são
entregues, e agora?
A primeira coisa a se verificar é a configuração do domínio. Como
está o SPF? O domínio jeveaux.com.br está dizendo explicitamente que o
IP do srv2
pode enviar e-mails por este domínio?
Configure o SPF, algumas mensagens começarão a ser
entregues, mas não são todas, e agora? Será comum encontrar no log estas
mensagens de erro:
550 5.7.1 Client host rejected: cannot find your hostname, [xxx.xxx.xxx.xx]
450 5.7.1 Client host rejected: cannot find your reverse hostname, [xxx.xxx.xxx.xx]
Vamos ao mais fácil: depois de configurar o SPF, vamos configurar
o DNS reverso, você pode solicitar ao seu datacenter, ou no
caso do Linode fazer diretamente no painel de controle. Com o DNS
reverso configurado agora quase todas as mensagens já são entregues, mas
nem todas. O que ainda está faltando?
Configurar um apontamento válido no domínio para o
endereço do seu servidor srv2, uma entrada do tipo A
na configuração do domínio será suficiente. Mas qual o hostname – não
falei que seria importante!? – completo do seu servidor?
No meu servidor srv2 eu vou executar o comando hostname -f e
ver o retorno:
user@srv2 ~ $ hostname -f
mail.jeveaux.com.br
O que isso quer dizer? Quer dizer que esse nome é o nome que é
utilizado para
iniciar uma conversão entre o seu servidor de e-mails e o servidor de
e-mails que você pretende entregar uma mensagem. É (literalmente)
assim:
Server: 220 mail.jeveaux.com.br ESMTP Postfix
Client: HELO mail.jeveaux.com.br
Ocorre que, quando o cliente (o servidor que você quer entregar um
e-mail) for verificar o IP de mail.jeveaux.com.br, ele não encontrará
nada, ou talvez até encontre o IP do srv1, dependendo de como
estiver a configuração do seu domínio, levando o cliente a concluir que
este remetente não é válido. Isso pode fazer seus e-mails irem para a
caixa de spam ou diretamente recusados.
Crie então uma entrada do tipo A com o nome mail
dentro do domínio jeveaux.com.br apontando para o IP do srv2.
Com essas configurações, você terá as credenciais suficientes para
entregar e-mails com autenticidade em qualquer servidor de e-mails. É
claro que isso não lhe concederá garantias de que o e-mail passará como não
sendo spam com qualquer conteúdo que você enviar, isso é completamente
diferente. Mas ao menos você preencheu os requisitos essenciais para
identificar o seu servidor e validá-lo como um servidor autorizado
dentro do seu domínio.
Existem muitas outras maneiras de fazer essa configuração, seja
através de ajustes no seu servidor de e-mail, no DNS, etc. As que eu
expliquei aqui são as que eu faço e utilizo e que consegui compreender
com clareza até hoje.