Operando seu próprio servidor de e-mail como em 1984
(maxadamski.com)- Operar seu próprio servidor de e-mail permite gerenciar automações e listas de e-mail com baixo custo
- Problemas de confiabilidade de entrega existem na prática, e pode haver falhas no envio e recebimento com grandes serviços
- Apenas com a configuração de Postfix e OpenDKIM já é possível montar um sistema básico de SMTP e envio de e-mails autenticados
- Certificado SSL e configurações de DKIM, SPF e DMARC podem melhorar a confiabilidade do e-mail e a segurança da transmissão
- Com a configuração até de um registro PTR (DNS reverso), é possível esperar melhor entregabilidade para grandes serviços de e-mail
Visão geral
Operar seu próprio servidor de e-mail é útil para automações como listas de e-mail, newsletters e APIs de autenticação por e-mail
No entanto, o maior desafio prático é a confiabilidade da entrega, já que existe o risco de o e-mail não chegar corretamente ou falhar no recebimento
O autor aplica essa abordagem em projetos pessoais assumindo esses riscos
A vantagem de operar por conta própria é que quase não há custo adicional, pois basta instalar o software em um site já existente, e o consumo de armazenamento e energia também é muito baixo
Parecia que operar um servidor de e-mail seria muito difícil, mas na prática a complexidade não é tão diferente da configuração de um serviço de e-mail em modelo SaaS
Para facilitar a configuração e simplificar tudo, webmail e ambiente multiusuário foram deixados de fora por enquanto, eliminando a necessidade de configurar contas de usuário, banco de dados e interface web
Nesta configuração, o foco é adequado para operar com uma única conta e, se necessário, enviar e receber e-mails via SSH usando mailx, sendmail, mutt etc.
No futuro, também é possível considerar expansão e a adição de webmail conforme a necessidade
Postfix
Basicamente, basta abrir a porta 25 e instalar/configurar Postfix e OpenDKIM para montar um servidor SMTP básico
Para entregar e-mails com estabilidade à maioria dos serviços de e-mail (como Gmail), o OpenDKIM (autenticação de e-mail) é necessário
O autor manteve o master.cf com os valores padrão, e no exemplo da configuração principal (main.cf) aparecem apenas os pontos essenciais, como criptografia TLS e integração com DKIM
POP3/IMAP não foram configurados, simplificando tudo para que, se necessário, seja possível acessar o servidor diretamente por SSH e enviar/receber e-mails com comandos como mailx
TLS (criptografia de transporte)
O certificado SSL é necessário para criptografar a transmissão de dados com o servidor SMTP
Não é preciso emitir certificados para vários domínios; basta ter um certificado para o host único onde o servidor de e-mail está localizado (usado no registro MX)
Por exemplo, se o registro MX for mx.example.com, basta obter e aplicar um certificado gratuito do Let’s Encrypt apenas para esse domínio
O TLS criptografa apenas o trecho de envio e recebimento entre servidores, sendo algo separado da autenticação do nome de domínio real do remetente
Por isso, no cabeçalho From do endereço de e-mail, é possível definir livremente o valor desejado
DKIM, SPF, DMARC
DKIM é usado para comprovar que o e-mail realmente veio do seu domínio, ajudando a garantir a confiabilidade da mensagem
Com o OpenDKIM, cria-se um par de chaves para cada domínio e registra-se a chave pública como um registro TXT no DNS
As chaves não expiram automaticamente, mas é recomendável rotacioná-las periodicamente
Também é possível adicionar registros TXT de SPF e DMARC no DNS para definir quais hosts podem enviar e-mails e qual política DMARC aplicar (por exemplo, rejeitar em caso de falha na autenticação)
Nos arquivos de exemplo (opendkim.conf, KeyTable, SigningTable, TrustedHosts), é possível verificar claramente como configurar cada item
No DNS, basta adicionar os registros relacionados a MX, SPF, DKIM e DMARC
DNS reverso (PTR)
O registro PTR (DNS reverso) aumenta a confiabilidade do servidor de e-mail e reduz a chance de a mensagem ser bloqueada por grandes serviços (como Gmail)
É necessário entrar em contato com o ISP para solicitar a configuração do registro PTR para o servidor de e-mail
Em um ambiente real de implantação, mesmo sem o registro PTR, Gmail, GMX e Outlook receberam as mensagens normalmente, e o servidor obteve nota 10/10 no mail-tester.com
Houve perda de pontos pela ausência do PTR, mas também houve pontuação positiva por ser um "trusted relay"
Como o IP de envio também não estava em blacklist, a confiabilidade do IP remetente era boa
Teste de envio para o Gmail
Foi enviado um e-mail de teste (mensagem HTML) para o Gmail usando o comando sendmail
No Gmail, a mensagem chegou imediatamente, e a criptografia TLS foi confirmada
Ao abrir "Show original", foi possível verificar que SPF, DKIM e DMARC passaram na autenticação
Também é possível conferir o conteúdo recebido localmente (no servidor) usando mailx
Se houver problemas de configuração, é preciso revisar novamente o DNS, o certificado e as permissões de acesso à chave DKIM; em especial, os arquivos de configuração do OpenDKIM são sensíveis a erros de digitação
Próximos passos
No próximo texto, será apresentado como criar um aplicativo de e-mail em Python
Se houver dúvidas ou opiniões, é possível entrar em contato pelo e-mail max@idx.cy
1 comentários
Comentários do Hacker News
Tenho orgulho de hospedar meu próprio e-mail há mais de 20 anos e pretendo continuar assim. Enquanto isso, governos e órgãos relacionados mal conseguem operar seus próprios sistemas de e-mail, e só o departamento nacional de segurança faz hospedagem própria. Talvez por sorte, quase nunca tive problema para enviar mensagens; o único caso recente de que me lembro foi a Microsoft engolindo meus e-mails, por causa de uma incompatibilidade de autenticação TLS entre um exim antigo e o Outlook. Resolvi ajustando uma configuração. A manutenção não dá tanto trabalho assim, então sempre trato cada mudança como uma oportunidade de aprender algo novo. Este ano troquei o Debian jessie por Arch Linux e migrei totalmente os jobs de cron para timers do systemd. Quando envio e-mails importantes, sempre verifico os logs do servidor, e acho que isso também é um bom hábito de administração. Se eu puder dar um conselho, é este: encare a hospedagem própria como um hobby e aprenda a gostar disso. E, por fim, quem bolou a configuração do Exim no Debian me fez desperdiçar muito tempo. Se você for configurar Exim no Debian, a resposta é trocar pela configuração oficial upstream e personalizá-la para o seu caso
Hoje em dia as redes sociais vivem se gabando de serem “descentralizadas” ou “abertas”, mas a verdade é que já temos ferramentas que nos permitem ser totalmente independentes e autossuficientes. Na tentativa de melhorar a UX, muita gente deixa passar que o controle do usuário está desaparecendo. No fim, se nos acostumarmos demais com sistemas simplificados demais, vamos acabar num futuro em que nem instalar um app será possível sem que alguém, do outro lado do mundo, autorize a “transação”
Usei e-mail pela primeira vez na universidade, antes da WWW, e depois acabei rodando meu próprio servidor porque minha conta no ISP tinha pouquíssimo espaço e só suportava POP. Como eu nem sempre estava conectado à internet, recebia e-mails com relay e DNS dinâmico. Hoje recebo e armazeno tudo em um servidor doméstico, passando por um VPS. Ao longo dos anos, já precisei pedir desbloqueio de IP ou domínio em serviços grandes como o Outlook, mas isso não foi tão frequente. Não quero viver num mundo em que duas ou três empresas dominam o e-mail do planeta, então vejo essa hospedagem própria como uma pequena forma de resistência
Queria ter nem que fosse 1% da motivação que eu tinha 20 anos atrás. Hoje, com trabalho em tempo integral e família — esposa e filho —, simplesmente não tenho tempo para esse tipo de coisa
Eu também me afastei da hospedagem própria por um tempo, mas estou pensando se não vale a pena voltar agora que a relação tempo/custo mudou. Minha maior preocupação com hospedagem de e-mail é o gerenciamento de spam. Como isso está hoje em dia? Se alguém tiver dicas, agradeço
Para mim, e-mail é um serviço muito importante. Depois de 15 anos hospedando por conta própria, parei por três motivos: 1) não estava conseguindo fazer bem backup/restauração e monitoramento regulares, 2) sem um plano de recuperação de desastre, isso saía mais caro do que outros serviços, e 3) eu não conseguia manter a segurança sempre em dia. O servidor de um amigo foi atingido por ransomware e ele perdeu tudo, mas eu escapei porque usava FreeBSD — não era um alvo. Em geral, a manutenção não é tão complicada, mas quando algo dá errado, pode virar um sofrimento enorme e até ser catastrófico
Eu mesmo hospedava meu e-mail antigamente, mas desisti não por causa de reputação, e sim porque é impossível escapar da exigência de 100% de disponibilidade, o que traz risco de perder mensagens ou acabar em blacklist. Em teoria, o protocolo de e-mail é resiliente a downtime, mas, na prática, grandes provedores de e-mail rejeitam a mensagem assim que há um problema e não tentam de novo. O GitHub antigamente, por exemplo, marcava como “não entregável” após um único bounce e depois simplesmente não enviava mais nada. Melhorou hoje, mas os sistemas modernos de e-mail partem do pressuposto de “sempre online”
Meu servidor de e-mail usa de propósito graylisting e rejeita a primeira tentativa de entrega. Já recebi incontáveis mensagens assim e nunca houve um caso sequer de e-mail legítimo não entregue. Reenvio faz parte do padrão do e-mail, então, se isso te preocupa, basta adicionar um servidor receptor de backup e fazer backhaul via LMTP. O próprio sistema de e-mail foi projetado numa época em que não se assumia conexão 24 horas por dia
Isso é exagero. No meu caso, quando um e-mail não chegava, ele costumava aparecer de novo algumas horas ou um dia depois, e normalmente não há como saber onde o problema aconteceu. Se a autenticação estiver certa — por exemplo, dkim e spf —, hospedagem própria também consegue mais de 99% de chance de entrega. Não precisa se intimidar com a complexidade. De quebra, dá até para usar caldav em privado
Não entendo por que alguém se preocuparia com “perda de e-mail” se o servidor ficasse fora do ar por algumas horas. O meu está com 219 dias seguidos de uptime. Comparado com o que fazemos no dia a dia, operar um servidor de e-mail é realmente fácil
Quando vejo os sistemas de e-mail de hoje, a sensação é mesmo de “o que fizeram com meu filho?”
Meu conselho para quem quer começar a hospedar o próprio e-mail: primeiro use um endereço próprio só para cadastro de contas. Não precisa começar usando para comunicação pessoal. Com “Mail-in-a-box” https://mailinabox.email./, se você seguir o guia de instalação, dá para deixar tudo funcionando em poucas horas. Use por 1 ou 2 anos e, só quando estiver realmente confortável, aí sim migre os contatos pessoais
Recomendo o Stalwart https://github.com/stalwartlabs/stalwart. É um serviço de e-mail completo em um único binário, sem dependências, e instalar/atualizar é fácil demais. Já testei vários outros projetos, mas o Stalwart foi o mais simples e roda sem nenhum problema
Opero o MIAB na nuvem há anos. Se a reputação do IP estiver limpa, o envio funciona sem problemas, mas, quando o Outlook não recebe mensagens, resolvo falando direto com o postmaster da Microsoft. É ótimo para aprender DKIM/SPF/DMARC e afins, por isso recomendo. Mas receber e-mails de cadastro é realmente difícil. O graylisting do MIAB rejeita remetentes novos e espera nova tentativa, só que muitos sites legítimos nem tentam de novo. Mensagens de verificação e códigos de 2FA acabam demorando muito para chegar, e também não há um jeito simples de desligar temporariamente o filtro de spam
Hoje em dia até e-mails fornecidos por ISP e até o Google Gmail às vezes falham em filtragem de spam e coisas do tipo. Ex.: quando faço um pedido via Shopify, os e-mails da Shopify continuam indo para spam no Gmail. Passam em DMARC, SPF e DKIM e mesmo assim não dá para entender por que são filtrados. Enviar e receber e-mail em si não é tecnicamente tão difícil, e nenhum serviço é 100% perfeito. Há tantos usuários maliciosos — spammers — que já é impressionante esse sistema funcionar tão bem quanto funciona
DMARC, SPF, DKIM etc. são apenas configurações de autenticação; não têm relação direta com ser spam ou não. Existe lixo muito bem autenticado e existe mensagem valiosa sem autenticação
Os e-mails da Shopify acabam indo para spam porque muita gente marca mensagens da Shopify como spam, ou porque há usuários com má reputação no mesmo servidor de e-mail compartilhado. Mesmo que eu marque repetidamente como “não é spam”, se a reputação geral do remetente for ruim demais, aquilo não sai da caixa de spam
Hospedo meu próprio e-mail há uns 20 anos. Durante 10 a 15 anos encaminhei tudo para o Gmail, mas cansei do filtro de spam apagar até mensagens importantes e passei a rodar meu próprio imapd. Se você configurar corretamente SPF e afins, hospedagem própria parece muito melhor
Esse tipo de política de filtragem é justamente o problema. Se você hospeda por conta própria ou usa um serviço pequeno de e-mail, a chance de bloqueio — especialmente pelos filtros rígidos do Gmail e afins — costuma ser bem menor. O Google insiste em políticas de filtragem frequentes mesmo tendo um monte de usuários do Gmail que são uma grande fonte de spam
Hoje o filtro de spam do Gmail está sensível demais com e-mails de marketing. Dez anos atrás o problema era o contrário, mas agora tanta coisa vai para spam que chega a irritar. Na verdade, boa parte do spam atual são cold emails vindos de endereços pequenos e novos. O recurso de “cancelar inscrição” funciona bem para e-mails de marketing no Gmail, mas é inútil contra esse tipo de cold mail
Se você quer uma configuração completa e um servidor IMAP compatível com vários clientes, o guia https://workaround.org/ispmail-bookworm/ é mais adequado. Eu opero de forma simples, com arquivos de texto puro em vez de banco de dados. Se só você for usuário, isso funciona bem, e o guia também escala tranquilamente para uso corporativo de grande porte
Jabá próprio: estamos beta testando o Hyvor Relay https://github.com/hyvor/relay, uma alternativa self-hosted. O foco é visibilidade, com monitoramento de DKIM/SPF e automação de DNS. Com um
docker compose up, já dá para colocar em produção https://relay.hyvor.com/hosting/deploy-easyHá 10 a 15 anos faço auto-hospedagem de e-mail em uma caixa kimsufi barata com opensmtp, dovecot e rspamd. Nunca tive grandes problemas; uma vez o servidor foi bloqueado pela telekom.de, mas expliquei por e-mail formal e eles me colocaram na whitelist logo depois. Talvez por eu ter o mesmo IP há muito tempo, nunca senti esses problemas que todo mundo menciona. Mas o servidor e o IP estão no meu nome
Compartilho em alemão um texto sobre auto-hospedagem de e-mail com base em Debian trixie em https://krei.se/Doc. Quando você monta isso direito por conta própria, é realmente prazeroso. Recebo relatórios diários de status por e-mail com atualizações automáticas, reinicializações e systemd personalizado. Por 2 ou 3 anos — ou até 5, no caso do trixie —, não preciso mexer em nada. O software de servidor de e-mail já está maduro o suficiente. Recomendo hospedagem própria. A autonomia, a tranquilidade e o controle direto valem muito
Hospedo meu próprio e-mail há mais de 10 anos e até deixei links para comentários antigos no HN (por exemplo: 39891262, 38471262). Como o IP da Digital Ocean estava marcado como malicioso, substituí o envio por Amazon SES e uso o Gmail como treinador gratuito de spam para alimentar meus próprios filtros (38843288). Como muitos já disseram, graylisting ajuda bastante. Servidores legítimos sempre tentam de novo, então, embora seja inconveniente para 2FA e afins, é algo confiável no nível do sistema. Mesmo que haja downtime por alguns dias, não me preocupo, e separar servidor de recebimento e de armazenamento facilita backups (38512732). Para e-mails de 2FA, também uso junto https://github.com/stevejenkins/postwhite, mas, sinceramente, não gosto da ideia de usar e-mail para 2FA (isso exigiria uma discussão à parte)
Recentemente deixei de receber um e-mail importante enviado via Amazon SES por causa da lista de bloqueio de spam
bl.spamcop.net. A Amazon tentou de novo por vários IPs e, ao encontrar graylisting, acabou tendo uma rejeição definitiva numa das tentativas. Talvez em envio entre grandes operadores (de MX para MX) isso não seja um problema tão comum, mas essa estrutura também não é uma solução 100% perfeitaNo fim das contas, por mais que se fale bastante, a conclusão parece ser: é melhor simplesmente usar um serviço grande como o Gmail
Onde está o UUCP, por que o endereço não é bang path e o que aconteceu com o sendmail.cf?
Exato. Se você tentar fazer hospedagem própria “ao estilo 1984” — e-mail clássico —, vai acabar com um open relay retransmitindo tudo e exposto a várias vulnerabilidades, o que é perigoso
Falando daquela época, tenho lembranças da universidade: em um laboratório com seis workstations Unix, dava para sentir os e-mails indo de um servidor para outro pelo barulho dos discos
Eu também li o título e pensei em bang path e no endereço “killer!jolet!”. Que saudade daqueles tempos
Concordo. Entrei atraído pelo título “1984”, mas me decepcionei ao ver que no fim era só conversa sobre “configuração de postfix”