É chegado o momento de coroar a nossa empreitada. Vamos colocar nosso servidor de emails e agendas em produção. Se alguma coisa der errado agora, é possível reverter. Mas não queremos que nada dê errado, certo?

Antes de atacar o DNS e efetivar a virada, há um pequeno passo a ser dado. Tomamos o maior cuidado ao longo de toda a série com diversos aspectos ligados a segurança para que nosso servidor seja o mais seguro que ele pode ser em um serviço de nuvem. Também tomamos diversos cuidados relativos a aderência aos padrões, especialmente os que são RFC. Não é agora que vamos patinar em uma coisinha tão boba: os endereços especiais.

RFC

Existem quatro endereços especiais especificados pelo RFC 2142. Conforme a descrição do Antispam.br:

A RFC 2142 (Mailbox Names for Common Services, Roles and Functions) prevê um conjunto de endereços especiais, que devem ser configurados como aliases para os e-mails do pessoal responsável pelas áreas específicas.

Para a correta administração de um domínio de correio eletrônico é necessário ter os endereços previstos nas seções 4 e 5 da RFC 2142, que são:

  1. abuse: para tratar de comportamento inapropriado ou abusivo, como envio de spam;
  2. noc (Network Operations Center): para questões sobre infra-estrutura operacional;
  3. security: para questões relacionadas a segurança;
  4. postmaster: funcionalidade definida nas RFCs 5321 e 5322.

Nosso ViMbAdmin cai como uma luva para configurarmos isso. Acesse-o e vá direto na aba 'Aliases'. Clique no ícone '+' e crie os aliases abaixo. Adapte os destinos conforme a sua necessidade. Fique a vontade para colocar mais de um destino caso você queira direcionar esses emails a uma equipe. Só tome cuidado para adicionar cada destino em sua própria linha (clique no '+' ao lado da caixa de texto para incluir destinos).

  • abuse@exemplo.com Goto (vai para) eumesmo@exemplo.com
  • noc@exemplo.com Goto eumesmo@exemplo.com
  • security@exemplo.com Goto eumesmo@exemplo.com
  • postmaster@exemplo.com Goto eumesmo@exemplo.com

Prontinho! Nem doeu!

DNS

Finalmente! Agora é ele!

Para fins de esclarecimento, como toda série é baseada nos serviços do AWS, o DNS que me baseio para mostrar os registros é o Route53. No entanto, esses registros todos entram no Bind ou em qualquer outro servidor de DNS que se preze bem felizes.

Vamos precisar criar vários registros no DNS. Alguns servem aos serviços de emails, outros servem às agendas. Alguns são complicadas de criar, outros são simples. Por último, e somente por último, vamos configurar o registro MX. Depois que esse registro for configurado e propagado, o seu servidor passa a responder como O servidor de emails do seu domínio. Qualquer um, qualquer pessoa ou sistema na internet, que enviar uma mensagem para qualquer endereço que termine em @exemplo.com chegará no seu servidor, e somente nele. Esse é o ponto do qual não queremos que haja retorno.

Vamos começar pelos registros mais simples.

SRV

Alguns clientes de emails, calendários e contatos são capazes de se autoconfigurar mediante apenas o nome do usuário. Isso é possível caso o nome do usuário esteja no formato nome@domínio.com. Neste caso, o cliente utiliza a informação do domínio para buscar no DNS do domínio a informação do serviço que o usuário está tentando configurar.

Alguns clientes de email (MUAs) para Linux, OS X e Android são capazes de se autoconfigurar tanto para o envio (submission) quanto para o recebimento (IMAP) de mensagens. Para que isso seja possível nesses clientes, os seguintes registros SRV são necessários. Esses registros são especificados pelo RFC 6186.

_submission._tcp.exemplo.com.  SRV  0 1 587 mail.exemplo.com.
_imaps._tcp.exemplo.com.       SRV  0 1 993 mail.exemplo.com.

Quando consultadas, essas entradas informam, por exemplo, que o serviço IMAP existe no domínio exemplo.com, é seguro (note o s no nome do serviço), roda na porta TCP 993 do servidor mail.exemplo.com, tem a maior prioridade (0) e peso (1).

Note que o registro submission não possui o s no final. Isso ocorre porque segundo o RFC 6186, seção 3.1, esse registro serve tanto para conexões seguras quanto as inseguras.

Não me preocupei em apresentar os registros SRV para POP porque, bem, não temos POP.

De modo análogo, esse método é útil para autoconfigurar os aplicativos Calendário e Contatos do OS X e para alguns aplicativos de calendários e contatos do Android.

Para que a autoconfiguração funcione nesses aplicativos, precisamos adicionar mais alguns registros do tipo SRV no DNS. Esses registros são especificados pelo RFC 6764.

_caldavs._tcp.exemplo.com.     SRV  0 1 8443 mail.exemplo.com.
_carddavs._tcp.exemplo.com.    SRV  0 1 8443 mail.exemplo.com.
_ischedules._tcp.exemplo.com.  SRV  0 1 8443 mail.exemplo.com.

Note que o serviço ischedules não faz parte do RFC 6764. Ele é especificado na seção 4 do rascunho 4871 do IETF. Mesmo assim ele é usado por alguns aplicativos, notadamente o antigo iCal do Mac OS X. Se você não precisa dar suporte a este aplicativo, você pode ignorar esse registro.

SPF

O SPF (Sender Policy Framework) não é um tipo de registro de DNS em si. Ele é uma tecnologia de combate a spam para prevenir que o endereço do remetente seja forjado. Isso é útil para evitar que pessoas ou sistemas, usando outros servidores que não sejam o seu, tentem se passar por alguém que possui autoridade para enviar emails a partir do seu domínio, seus usuários no caso.

Apesar da implementação da tecnologia SPF em si ser bastante complexa, sua implementação no DNS é simples. Primeiro você deve criar a política SPF para o seu domínio. Esse gerador online te ajudará com isso.

Em geral, você adicionará um registro TXT no DNS com esse conteúdo:

exemplo.com.  TXT  "v=spf1 mx a ~all"

Esse registro expressa que somente o servidor designado pelo registro MX (mx) e o site designado pelo registro A (a) podem enviar emails em nome do domínio exemplo.com. Ele também informa que as mensagens que vierem de outros locais que não os designados devem ser marcadas como spam (softfail) pelo MTA que a recebeu (~all).

DKIM

O DKIM também não é um registro do DNS. Assim como o SPF, ele é uma tecnologia expressa em um registro TXT. Mas diferente do SPF, que expressa em uma política quais servidores podem enviar mensagens em nome de um domínio, o DKIM autentica as mensagens provenientes de um ou mais servidores e provê as ferramentas para que outros servidores possam verificar essa autenticação e confirmar que uma mensagem de fato veio de onde ela diz que veio.

Ou seja, o DKIM é mais uma arma no arsenal antispam.

Para configurar o registro TXT que contém as informações do DKIM também há um gerador online. Para usá-lo você vai precisar da chave pública que geramos lá na parte oito desta série. Veja bem, você precisa da chave pública, não da privada!!! A chave privada nunca deve deixar o seu servidor.

A chave que queremos está no arquivo /etc/dkimproxy/exemplo.com_dkim_public.key. De posse dela, vá para o gerador de DKIM e preencha os campos de acordo com a sua necessidade. Em geral, o seu registro TXT para o DKIM ficará assim:

mail._domainkey.exemplo.com.  TXT  "v=DKIM1; h=sha256; k=rsa; p=<chave PÚBLICA>; t=s"

Esse registro diz que o seletor do DKIM disponível para este servidor é mail, que estamos usando uma chave RSA disponível em p, que o hash de verificação deve ser feito com o algoritmo SHA256 e que subdomínios não são permitidos para este seletor (t=s). Ou vem de exemplo.com ou é não é autêntico, mesmo que venha de www.campanha.exemplo.com.

O registro TXT do DKIM será usado pelos servidores que receberem mensagens do seu servidor para verificarem se a mensagem partiu mesmo dele. Isso é feito através do cabeçalho DKIM-Signature que o DKIMproxy insere em todas as mensagens que saem do nosso servidor. De posse dessas informações do cabeçalho, o servidor de destino consulta o nosso DNS, obtém a chave e os outros parâmetros e faz a verificação de autenticidade. Se as duas coisas baterem, a mensagem é autêntica e veio do nosso servidor. Se não batem, é spam.

Eis a importância da sua chave privada do DKIMproxy jamais deixar o seu servidor. Qualquer um que colocar as mãos nela poderá assinar mensagens como se fosse o seu servidor.

Agora uma curiosidade: o Google usa DKIM, mas ele mudou o cabeçalho padrão do DKIM, que é DKIM-Signature, para X-Google-DKIM-Signature. Com isso o nosso servidorzinho não consegue (e nem ninguém exceto o próprio Google) verificar a autenticidade de nenhuma mensagem enviada a partir de lá, mas o Google consegue verificar a autenticidade das nossas mensagens porque nós estamos no padrão. Aquele papinho deles de 'don't be evil'? Conversa mole pra boi dormir. Tudo puto!

Com o SPF e o DKIM devidamente configurados, a probabilidade de um email gerado pelo seu servidor ser considerado spam é praticamente nula. É claro que isso muda rapidinho se você de fato fizer spam. As listas negras estão de olho e a última coisa que eu faria é te ensinar a sair de uma delas, mesmo porque isso é muitas vezes um processo bem burocrático. Acho é pouco se você cair numa delas se deu motivo pra isso! Queima lá por toda a eternidade!

O processo inverso, quando o nosso servidor verifica o DKIM e o SPF de outros domínios, é feito da mesma forma descrita acima. Quem faz esse trabalho do nosso lado é o SpamAssassin.

Rufem os tambores! É chegado o grande momento!

MX

exemplo.com.  MX  10 mail.exemplo.com.

Assim, direto e reto! Sem emoção nenhuma!

Substitua o registro MX que porventura existir no seu domínio ou crie-o se não existir. Publique o registro MX.

Assim que você publicar esse registro e o DNS propagar (pode levar até 3 dias), rode um tail -f /var/log/maillog, corra numa conta de email em outro serviço qualquer, e envie um email para eumesmo@exemplo.com. Assista o log rolar e comemore!

Seu servidor de email está em produção!!! <3

Ah, é bom tomar nota do seu registro MX antigo caso você tenha que fazer um rollback. Mas se você foi um bom leitor, isso não vai acontecer.

Na próxima parte eu ia ensinar você a configurar os clientes de email e agenda. Até disse que faria isso em algum lugar que não lembro mais onde foi e que estou com preguiça de procurar pra desdizer. Mas pensando melhor, não vou fazer isso. Meu! Você colocou um servidor de email inteiro no ar, do nada! Putaquepariucaraleo se você não der conta de configurar uns bosta duns clientinhos sem vergonha de email e agenda! Se vira!

Então, para encerrar a série, vou te mostrar #comofaz pra manter o nosso servidorzinho sempre com boa saúde. É a hora do carinho.