Essa será uma longa jornada. Já vou contar o final: você terá o seu próprio servidor de email, calendários e contatos. Pelo tamanho da nuvem de tags deste artigo que abre a série dá pra sacar a amplitude dos temas que vamos abordar.

Eu chamo isso de 'um guia grandão' porque, bem, ele é gigante e eu não gosto de marketing. Ele não é 'definitivo', 'super', 'master' ou 'blaster'. Muito menos é 'completo'. Um serviço de emails é um tema tão complexo que nem a minha megalomania redacional me permite sequer arranhar a ponta do iceberg. Junte a isso o serviço de agendas integrado e a quizumba tá armada.

Lá na frente, quando você tiver terminado de ler e executar toda esta série de artigos, você terá o suficiente para se ver livre dos Gmail, Google Apps for Work, Outlook.com, Yahoo Mail, o novíssimo Amazon WorkMail ou qualquer coisa do gênero.

Você terá feito algo concreto para deixar de ser observado. Dará adeus aos anúncios, ao spam, à mania horrorosa e gananciosa que os serviços de email, gratuitos e pagos, têm de ler suas mensagens para 'fornecer produtos, serviços e propagandas de acordo com as suas preferências'.

Eu não vou dizer, como costumava dizer no passado nada distante, que 'se você não está pagando, você é o produto'. Devo reconhecer que mudei minha opinião sobre o tema. Esse argumento é ingênuo e completamente equivocado. Mas uma coisa é certa: a estarrecedora maioria das ofertas de serviços online, gratuitos ou pagos, estão passando dos limites quanto aos termos de serviço impostos aos seus usuários.

Não tema! Você pode reverter isso e o que vou mostrar aqui é um bom começo. Você terá lá no final o seu próprio servidor de emails e agendas, como os bons e velhos administradores de rede faziam no passado e que aos poucos, com o popularização desses serviços gratuitos, foi deixando de ser a prática para se tornar a exceção. Eu prezo pelas exceções.

As questões relacionadas a sua privacidade e práticas duvidosas dos serviços online em geral são a parte feia da motivação desta série de artigos. A parte bonita é o conhecimento. Estabelecer e manter o seu próprio serviço de correio eletrônico é uma aventura!

A primeira mensagem de texto escrita em um computador por um homo sapiens e enviada para outro homo sapiens, em outro computador, cuja conexão física entre os dois era apenas o chão e uma rede de dados, data de 1971! Apenas umas quatro ou cinco tecnologias tidas como base para internet são mais antigas que isso, mas nenhuma delas continua em uso hoje em dia como o email. Em termos de idade o TCP/IP, o protocolo que viabiliza essa porra toda, é geração Y: 1982.

Por uns bons anos depois da internet se tornar pública, primeiro no meio acadêmico em 1986, o email foi algo muito respeitado. Enquanto as cabeças pensantes eram as únicas a usá-lo, só haviam as folclóricas 'flame wars'. O pau comia nas discussões e era isso. Em 1978 um cara chamado Gary Thuerk enviou uma mesma mensagem de propaganda para 393 pessoas. Ele foi duramente repreendido pelo feito e isso não voltou a ocorrer por um bom tempo.

Até que em 1990 a internet se tornou comercial. Com isso as cabeças pensantes foram dando lugar aos bolsos sem fundo do mercado. Apenas quatro anos depois, um casal de advogados (por que isso não me impressiona?) faria o primeiro spam. De lá pra cá a coisa degringolou.

O que era algo limpo, extremamente funcional e incrivelmente simples e elegante tornou-se uma das tarefas mais complexas e caras dos serviços em rede. Por causa do spam, que hoje representa 64% (!!!!!) de todos os emails que trafegam na internet (dados de maio de 2014), manter um servidor de email na internet pública é uma tarefa para estômagos preparados.

Exatamente por isso vale cada segundo de esforço. Como não bastasse o prazer de combater os abusos dos ISPs e serviços gratuitos de email, acrescente na conta a delícia inenarrável que é presenciar o seu servidor de email responder isso para os spammers filhos duma puta:

NOQUEUE: reject: RCPT from [90.165.236.120]:53728: 550 5.7.1 Service unavailable;

Mas não fica só nisso. Você também vai obter um serviço em geral muito mais rápido, eficiente e privado que os disponíveis por aí. Além disso, você vai controlar o seu próprio serviço e fazer dele o que bem entender, na hora em que quiser fazer e aonde quiser que ele esteja.

Pessoalmente, o melhor motivo de todos para mim é esse: faço porque sei e posso. Nada é mais poderoso que isso.

Cai dentro, mizifi!

Tio, o que eu vou ter que fazer?

Uma penca de coisas! Muitas, muitas mesmo. O processo todo é longo, demorado, sujeito a (muitos) erros e (muitas) frustrações.

Em termos simples, vamos encaixar uma série de peças para formar um todo. As peças são as abaixo, todas obviamente FOSS:

  1. nginx: o servidor de email rapidão e levinho.
  2. MariaDB: o banco de dados que veio salvar o que havia de bom no MySQL.
  3. ViMbAdmin: uma interface web para administração de domínios e contas de email virtuais.
  4. Postfix: um servidor de email moderno, poderoso e fácil de manter.
  5. Dovecot: um servidor de POP3 e IMAP seguro e flexível.
  6. DKIMproxy: um utilitário que implementa o padrão DomainKeys Identified Mail para assinatura de mensagens.
  7. SpamAssassin: um utilitário inteligente para anti-spam.
  8. Sieve: uma linguagem e serviço para filtros de mensagens que rodam no servidor.
  9. Horde: um framework completo para aplicações colaborativas. Sobre ele rodarão o Kronolith, o Nag e o Turba, que por sua vez serão nossos servidores de calendários, tarefas e contatos (CalDAV e CardDAV, respectivamente).

É um montão! E não se engane: quase todas são complicadas. Mas no fim, todas elas conversarão entre si de modo absolutamente transparente e seguro. Se você já usou o Gmail, tudo isso aí em cima vai funcionar quase igual, onde o mesmo login controla o seu acesso a todo os serviços disponíveis.

Aliás, essa é uma grande vantagem se você pretende usar essa solução em um ambiente corporativo: contas unificadas para serviços diferentes. As URLs são diferentes para cada coisa (como no Gmail), mas a conta é a mesma (como no Gmail). Isso faz toda a diferença do ponto de vista administrativo (só uma base de usuários para manter) e de conveniência (só uma senha para lembrar).

É bom dizer logo: a minha abordagem traz coisas que você não tem no Gmail e vai passar a ter (Sieve) e coisas que você tem no Gmail e vai passar a não ter (webmail, antivírus, IMAP não seguro e POP3).

'Perá lá! Sem webmail e antivírus?!? WTF!', você brada. 'Sim!', eu respondo. Sem webmail. Sem antivírus.

As duas coisas são aberrações que o povo preguiçoso inventou de rodar nos servidores, mas que nunca pertenceu a esse lugar.

Web é web, email é email. Web não pode ser email, email não pode ser web. Não existe um RFC que junte as duas coisas, e como não há RFC, não há padrão. Por isso é incrivelmente mais eficiente e simples utilizar um cliente de email, em oposição ao navegador, para receber e ler mensagens de email. Existem dezenas de bons clientes de email para computadores e, com a propagação dos smartphones, você também já tem isso no seu telefone. Não há porque existir um serviço de webmail nos dias de hoje. Na verdade nunca houve, mas sabe como é a burrice quando encontra a preguiça, né?

'Ah! Mas o povo do comercial quer webmail!', você insiste. Se eles vendem bem, dê para eles um laptop fodão com uma bateria de caminhão e quatro celulares, um de cada operadora, com um planão de dados, uma carretinha e um engate instalado no carro. Ou procure você mesmo os meios de implantar o serviço de webmail. Isso eu não vou mostrar aqui. Fim de papo.

Quanto ao antivírus, um vírus dentro de um email só tem potencial de atacar o cliente que recebeu e abriu o email. Logo, antivírus também é coisa para rodar na ponta, no cliente de email, não no servidor. Se o servidor recebe um email virulento para um determinado destinatário, o dono da mensagem é quem deve tratá-la. Não é problema nem função do servidor olhar para esse tipo de coisa. Se você quer ter isso, também terá que procurar por aí, pois não será objeto desta série.

Já sobre o IMAP não seguro e POP3, bem, não carece muita explicação a inutilidade desses dois, né?

Estamos entendidos? Excelente! Circulando.

Pré-requisitos

Antes de começar, você precisa providenciar algumas coisas sem as quais não há como continuar. São elas:

  1. Uma instância novinha e limpa com sistema operacional baseado em Linux rodando em algum VPS. Durante toda a série, usarei como base o Slackware 14.1 rodando no AWS EC2 conforme descrevo aqui. Você pode usar qualquer VPS e qualquer distribuição que desejar. A adaptação das instruções para o seu ambiente particular fica ao seu critério.
  2. As ferramentas do AWS para Linux (awscli) instaladas, configuradas e prontas para uso. Se você seguiu o meu guia acima, já terá isso pronto.
  3. Dois volumes de armazenamento: um para o sistema operacional (óbvio) e outro para os emails dos usuários montado em /var/spool/mail/vmail. Eu vou mostrar como criar esse filesystem adicional lá na frente.
  4. Um IPv4 quente (válido) na internet pública para o servidor. Tudo funciona também com IPv6, mas como o EC2 não suporta IPv6, então vou tratar apenas o IPv4.
  5. Um DNS (próprio ou gerenciado) que suporte registros do tipo MX, TXT e SRV.
  6. Uma zona de DNS reverso (registros PTR).
  7. Um certificado SSL: precisa ser emitido para o servidor acima (ou wildcard para todo o seu domínio) por uma entidade certificadora pública. Duas sugestões que fornecem certificados gratuitos são: StartSSL e CAcert (o CAcert é menos suportado pelas distribuições Linux em geral).
  8. Conhecimento genérico de sistemas operacionais baseados em Linux: ter desenvoltura com bash, configurações do /etc, se encontrar no filesystem, usar vim ou emacs, alguma coisa genérica sobre programação e banco de dados.

Exceto se apontei o contrário, nenhum desses pré-requisitos serão tratados nesta série. Apenas presumo que você já os tenha.

Existe um outro pré-requisito, mas esse vou explicar aqui: você precisa conhecer os papéis de cada componente de um serviço de email. São eles:

  • MX: mail exchanger, é um tipo de registro do DNS que declara qual é o MTA para um domínio.
  • MTA: message transfer agent, é o serviço de troca de mensagens entre um servidor e outro. O Postfix é um MTA. O MTA implementa o protocolo SMTP e roda na porta 25.
  • MDA: mail delivery agent, é o serviço que faz a entrega das mensagens aos destinatários. O Dovecot é um MDA. O MDA implementa os protocolos LDA (local delivery agent) ou LMTP (local mail transfer protocol), ou ambos. Esses serviços fazem a entrega final de uma mensagem recebida de fora para o usuário de destino dentro do domínio. Por sua vez as mensagens se tornam disponíveis aos usuários pelos protocolos IMAP e POP, também implementados pelo MDA e que rodam nas portas 110 (POP3), 143 (IMAP), 993 (IMAPS) e 995 (POP3S).
  • MUA: mail user agent, é o cliente de email. Thunderbird, KMail, Alpine, Mail do OS X e o aplicativo E-mail do Android são todos MUAs. Usam o MDA para receberem mensagens e o MSA para enviarem.
  • MSA: mail submission agent, é o serviço usado pelos MUAs para enviar mensagens para MTAs de outros domínios. O Postfix também é um MSA. O MSA implementa o protocolo SMTP e roda na porta 587.
  • MHS: message handling service, que engloba todos os serviços relativos ao email. MX+MTA+(LDA+LMTP+IMAP+POP=)MDA+MUA+MSA=MHS.

Dinheiros: quanto morre?

Como dito acima, vou usar uma instância do AWS. Ela será uma t1.micro, a menor instância disponível no EC2. Apesar da capacidade super limitada da t1.micro, ela será suficiente para atender até 20 usuários com tudo o que será descrito nessa série. Se você precisar de mais usuários, use uma instância maior.

A série também utiliza outros serviços do AWS: Route53 para o DNS, S3 para o backup, EBS para armazenamento, EIP para os IPs e por aí vai. Cada um deles gera uma despesinha mensal.

Com base nessas premissas, um servidor de email e calendário para até 20 usuários, onde cada usuário terá 5GB de armazenamento, custará por mês aproximadamente US$ 32,00 no AWS. Isso equivale a US$ 1,60 por usuário, por mês.

Compare isso com o AWS WorkMail, que oferece exatamente a mesma coisa que vamos ter: email e calendário. Nele, cada usuário custa US$ 4,00. 20 usuários custarão US$ 80,00. O WorkMail fornece 50GB de armazenamento por usuário. Nosso servidor fornecerá inicialmente 5GB/usuário.

Mesmo que você queira equiparar o armazenamento, fornecendo 50GB/usuário logo de cara, o custo mensal total subirá para US$ 103,93 (incluindo backup e DNS), cerca de 30% mais caro se comparado ao WorkMail. Mas por que alocar esse 1TB total agora se você pode escalar somente quando precisar?

Aliás, essa é mais uma das vantagens de rodar um serviço de email usando seus próprios recursos na nuvem: escalar quando precisar. Você economiza a partir do momento inicial, mas tende a existir uma desvantagem de custo quando você opera perto dos limites superiores da capacidade alocada. Mas mesmo essa desvantagem financeira e compensada pelo maior controle e privacidade que o seu próprio serviço oferece.

Esses custos não contém o calor humano necessário para manter o seu novo servidor. Se quiser fazer esse cálculo, saiba que você utilizará cerca de 6h/mês para tarefas administrativas rotineiras, o que inclui a atualização do SO e software, treinamento do anti-spam e contemplação de logs. Tudo isso são coisas que podem ser automatizadas, fazendo esse tempo cair para cerca de 2h/mês.

Em resumo: com a ocupação ótima da capacidade alocada, sai mais barato ter seu próprio serviço de email e agendas na nuvem do que pagar por algo equivalente na internet. Quanto aos serviços gratuitos, US$ 32,00/mês é um valor bastante razoável a ser pago - supondo que você será o único usuário - em troca de não ter sua vida digital completamente devassada.

Uma palavra sobre segurança

O nosso servidor de email será tão seguro e privado quanto possível. Por 'quanto possível' entenda o seguinte: o tráfego de emails será inteiramente criptografado, mas o armazenamento não terá qualquer tipo de criptografia.

Por que sem criptografia no armazenamento? Leia isso para entender o motivo.

Se é absolutamente necessário para você possuir criptografia no armazenamento e pretende rodar o seu servidor em um VPS, então use a ferramenta que o VPS povê para isso. Se o seu VPS não fornece nenhuma ferramenta de criptografia de sistema de arquivos pronta, então deixe sem criptografar mesmo e boa.

Não caia na bobagem de criptografar os seus volumes usando as ferramentas do sistema operacional, tipicamente dm-crypt, eCryptFS ou EncFS. Eles não adicionarão qualquer valor à solução. Lembre-se: a memória da sua instância no VPS estará disponível sem qualquer criptografia para o dono do servidor físico. Você não tem controle sobre isso.

No caso do AWS, você pode usar o KMS para esta finalidade. Se você optar por utilizá-lo, então esteja atento para o fato de que a menor instância que suporta criptografia via KMS em volumes EBS é a m3.medium, bem mais cara (US$ 50,40 por mês) que uma t1.micro (US$ 14,40).

Se você seguir meus conselhos sobre a criptografia de volumes, em linhas gerais este serviço ficará mais caro por usuário e mais seguro do que qualquer serviço pago (ex.: Google Apps for Work, Outlook, Kolab Now ou AWS WorkMail). Por outro lado, ele será mais barato por usuário e menos seguro do que se hospedado em sua própria máquina física.

Outra dica que afeta a segurança: se for utilizar o AWS, evite utilizar as regiões US em função das questões legais.

Em qualquer caso, não conte apenas com a criptografia do tráfego e do sistema de arquivos. Use GPG para criptografia de ponta a ponta, o que vale mesmo pra quem não tem seu próprio servidor de email.

Só para ficar bem claro: o objetivo da série é fornecer um servidor apenas tão seguro quanto possível na nuvem, e não completamente seguro. Esse último tipo não existe.

Referências

Para produzir esta série eu usei como referências principais duas séries de artigos:

Também obtive informações em inúmeras fontes como a documentação do software que vamos utilizar, artigos em blogs diversos, mensagens em fóruns etc. Infelizmente não fui cuidadoso o suficiente para registrar todos. De qualquer modo deixo a minha gratidão a esses autores anônimos.

Vamos começar a meter a mão na massa? No próximo artigo da série. Vem comigo!