Animado para começar? Mas que tal, antes disso, visualizarmos o que vamos fazer no melhor estilo 'entendeu ou quer que eu desenhe'? Isso vai ajudar a nos localizarmos daqui pra frente.

O gráfico abaixo mostra a arquitetura e as correlações entre todos os serviços que vamos implementar. Ele não pretende ser preciso quanto a protocolos, topologia e outros detalhes. Ao invés disso, ele mostra de onde as coisas vêm, pra onde vão e como elas se encaixam do ponto de vista lógico.

Arquitetura do servidor de email e agendas.

Note que cada serviço está separado por cores. Não é difícil deduzir que eles podem ser separados a qualquer tempo, cada um rodando em um servidor distinto, desde que eles se comuniquem como mostrado na figura. Assim, se você precisar escalar, esse é o caminho natural: separar os serviços em servidores diferentes. Essa arquitetura provê uma escalabilidade praticamente infinita ao sistema.

Outra coisa que é fácil deduzir a partir da arquitetura: além das contas normais de email, esse servidor poderá atender outros servidores que precisem enviar ou receber emails em sua(s) rede(s) locais (ou VPCs diferentes no caso do AWS).

Também não é necessária muita astúcia para notar que há muitos componentes nessa arquitetura que são comuns a qualquer servidor web. Como esta série será dividida em partes bastante especificas a cada componente, você pode aproveitar coisas para fazer o que desejar com os componentes distintos.

Agora que sabemos pra onde vamos, nesta parte da série vamos começar a dar forma ao nosso servidor de emails e agendas, começando pela segurança no acesso ao servidor para trabalharmos em paz e pelo batismo do servidor.

Seguro morreu de velho

Vamos precisar fazer algumas configurações primárias no servidor em si. A primeira delas é ter acesso ao servidor via SSH, e isso eu deixo por sua conta junto com um aviso: um servidor SSH com as configurações padrão não é algo seguro. Ao longo da série efetuaremos diversas operações que manipulam dados críticos para a segurança de todo o sistema. Se a segurança do nosso método primário de acesso ao servidor é negligenciada, então a segurança do sistema como um todo também será.

Por isso recomendo com veemência que você torne o seu servidor e cliente SSH mais seguros seguindo as instruções desse excelente artigo: Secure Secure Shell, de autoria do @stribika. Não é estritamente necessário que você use o Tor para acessar o seu servidor durante o curso desta série, até porque esse método é muito lento para a quantidade de coisas que temos que fazer. Use o Tor depois que estiver em produção, para tarefas rotineiras.

Outra coisa MUITO importante sobre segurança: use autenticação de dois fatores (two-factor auth) em tudo. No lugar que o seu domínio está registrado (registro.br, por exemplo) e no AWS, isso é essencial. Não negligencie isso.

Nome ao boi

Uma vez que você esteja conectado de modo seguro ao servidor via SSH, a primeira coisa a configurar é o nome e o domínio do servidor. Precisamos analisar isso um pouco mais detalhadamente.

Na primeira parte eu disse:

Durante toda a série, usarei como base o Slackware 14.1 rodando no AWS EC2...

Isso impõe duas premissas:

  1. A instância estará em uma rede local (chamada VPC no jargão do AWS).
  2. Haverá um NAT de um IP quente (chamado de Elastic IP pelo AWS) para o IP da instância no VPC.

Por força dessas premissas, eu uso o Route53 do AWS para criar duas zonas distintas: a zona convencional de DNS (forward, que traduz nome para IP) e uma reversa (reverse, que traduz IP para nome). A mesma coisa pode ser feita com o Bind sem muito esforço. Fica a seu critério a implementação do DNS, o importante é existirem essas duas zonas de DNS.

Vamos então nomear o servidor. Os nomes que usarei durante toda a série são apenas exemplos. Você deve alterá-los para os seus domínios interno e externo, este último devidamente registrado e válido, uma vez que ele deve existir para a internet pública.

$ sudo -i
# cd /etc
# vi HOSTNAME

Batize o servidor com o seguinte conteúdo:

mail.exemplo.localdomain

Salve o arquivo e edite o /etc/hosts para que o conteúdo dele se pareça com isso:

127.0.0.1  localhost localhost.localdomain
172.16.1.5 mail mail.exemplo.localdomain
54.94.2.1  mail.exemplo.com exemplo.com

Vamos entender o que foi feito aqui.

Primeiro, a linha 127.0.0.1 define o nome do servidor para a interface loopback, ou lo. Esses são os nomes pelo quais o servidor conhece a si mesmo.

Na linha 172.16.1.5 definimos o nome pelo qual este servidor será conhecido dentro da rede local. Outros servidores em nossa rede local, e somente dentro dela, usarão estes nomes para se referir ao nosso servidor. O nome mail.exemplo.localdomain deve possuir uma entrada correspondente nas zonas de DNS normal e reversa da rede interna.

Já a linha 54.94.2.1 define o nome pelo qual o servidor será reconhecido na internet. Esse IP é um exemplo para o IP quente que você recebeu. O nome mail.exemplo.com deve possuir uma entrada correspondente nas zonas de DNS normal e reversa do seu domínio público exemplo.com.

Agora confira o /etc/resolv.conf. Ele deve ser parecido com isso:

# Generated by dhcpcd from eth0
# /etc/resolv.conf.head can replace this line
domain localdomain
nameserver 172.16.0.2
# /etc/resolv.conf.tail can replace this line

É absolutamente essencial que o seu servidor de email possua uma DNS reverso resolvendo o IP válido para exatamente o mesmo nome definido para este servidor em seu domínio público. Um servidor de email bem configurado (o nosso será um deles) rejeita emails de outros servidores que não resolvem o DNS reverso para o mesmo nome do servidor no DNS normal.

Para ilustrar, você precisa ser capaz de fazer isso com o seu domínio público:

$ dig mail.exemplo.com +short
54.94.2.1
$ dig -x 54.94.2.1 +short
mail.exemplo.com.

E isso com o seu domínio interno:

$ dig mail.exemplo.localdomain +short
172.16.1.5
$ dig -x 172.16.1.5 +short
mail.exemplo.localdomain.

Se você estiver usando o AWS, não terá controle sobre o DNS reverso do IP válido por motivos de 'ele não é seu'. Por isso você precisa preencher este formulário do AWS e aguardar uns dois ou três dias em média para que eles atendam (ou não) o seu pedido. Dica para ser atendido: prometa que jamais fará spam e cumpra a promessa.

Você pode fazer isso agora se está feliz com o IP e o nome que possui, mas pode aguardar mais um pouco caso deseje mudar alguma coisa. Só faça a requisição ao AWS quando estiver satisfeito com o IP e nome que deu ao seu servidor.

Depois que seu servidor estiver devidamente batizado, reboot nele para que as configurações sejam aplicadas. Quando você fizer o login depois do boot, seu prompt deverá aparecer assim:

you@mail:~$

Na próxima parte as coisas começam a ficar mais emocionantes. Até lá.