Auto-hospedagem de e-mail do jeito difícil: começando com um bloco IPv4 roteável próprio
(anil.recoil.org)- A infraestrutura de e-mail da Recoil, operada desde 1997, foi atualizada para uma pilha auto-hospedada que combina bloco IPv4
/24dedicado, Postfix, Dovecot, rspamd, Roundcube e outros, processando diretamente recebimento, envio e acesso - Operar o próprio e-mail oferece controle de acesso aos dados e valor educacional, mas em um SMTP com pouca base de confiança é preciso gerenciar diretamente reputação de IP, registros DNS e defesa contra spam
- O caminho de recebimento passa por postscreen, DNSBL, greylisting, ClamAV, filtragem bayesiana, LMTP e Sieve, em uma estrutura que reduz gradualmente tráfego de bots e e-mails maliciosos
- A confiabilidade do envio depende de SPF, DKIM, DMARC e SRS; se configurados incorretamente, e-mails podem ser marcados como spam ou descartados silenciosamente por verificações de destinatários como Gmail e Outlook
- Em 2026, auto-hospedar e-mail ainda é possível, mas exige obtenção de IPv4, vários registros DNS, atualizações de segurança e defesa em profundidade contra exploração de vulnerabilidades com IA
Por que operar seu próprio e-mail
- Operar seu próprio servidor é uma experiência educacional de sistemas e redes, além de um caminho para entender como a internet funciona e participar de projetos open source
- Em um cenário em que a web se consolida em torno de poucos provedores, a auto-hospedagem se torna uma forma de manter acesso soberano aos próprios dados
- Uma análise de 2023 avaliou que, em geral, os atores capazes de ler o tráfego de e-mail acabam sendo Google e Microsoft
- Como o e-mail está ligado à redefinição de senha de muitas contas online, uma invasão de conta ou phishing pode comprometer o acesso a outros serviços
- Operar o próprio e-mail exige manutenção de longo prazo, além de hospedagem em internet mais estável que uma rede doméstica e acúmulo de reputação
Estrutura de recebimento de e-mail
- Um domínio na internet especifica, via registro DNS MX, qual servidor SMTP recebe os e-mails; em
recoil.org,pork.recoil.orgprocessa o correio - O SMTP surgiu de um projeto dos anos 1980 baseado em mais confiança e, por padrão, não consegue provar a identidade do remetente; o remetente de um e-mail recebido pode ser facilmente falsificado
- A resposta da IETF evoluiu para empilhar várias verificações de identidade, e configurações erradas nessas verificações reduzem a confiabilidade da entrega
- Listas de bloqueio baseadas em DNS agregam informações sobre botnets, hosts comprometidos e spammers, permitindo que servidores de e-mail consultem RBLs para filtrar IPs suspeitos
- A reputação de e-mail se acumula no endereço IP, não no domínio; assim, endereços reutilizados na nuvem ou IPs vizinhos no mesmo bloco podem afetar essa reputação
-
Obtenção e roteamento de um bloco IPv4 dedicado
- A Recoil obteve um bloco de endereços IPv4 dedicado
185.33.27.0/24, permitindo construir reputação de e-mail de forma independente - O RIPE NCC esgotou o espaço IPv4 não alocado em novembro de 2019, e desde então a alocação direta é tratada por meio de uma lista de espera para pequenos blocos
/24 - O bloco
/24foi alocado após cerca de 6 meses de espera e, para solicitar diretamente na Europa, é preciso pagar a taxa de associação do RIPE NCC e abrir uma conta LIR - O bloco IPv4 alocado recebe uma ROA de RPKI para definir a autorização de roteamento, e o bloco da Recoil está ligado ao Mythic Beasts AS44684
- O DNS reverso também pode ser controlado diretamente, e
185.33.27.128é mapeado parapork.recoil.org, servindo como sinal de reputação de e-mail
- A Recoil obteve um bloco de endereços IPv4 dedicado
Defesa contra bots e spam
- Conseguir um bloco IPv4 limpo não basta; a maior parte das conexões TCP que chegam à porta 25 serve para entrega de spam, varredura de open relay, tentativa de adivinhar credenciais ou coleta de dados para treinamento de IA
- O Postfix
postscreenfica na frente da porta 25, fazendo consultas DNSBL em paralelo, atraso pre-greet e verificações de pipelining e comandos não SMTP - O
postscreensó encaminha aosmtpdreal clientes que parecem legítimos, enquanto clientes incorretos são encerrados com falha temporária para permitir nova tentativa em caso de falso positivo - As listas Spamhaus, Spamcop e Barracuda são combinadas com pesos, com configuração para rejeitar em caso de Spamhaus sozinho ou de duas listas fracas simultaneamente
- O pool de MX de envio do Apple iCloud não tenta novamente a partir do mesmo IP, o que entra em conflito com a lista de permissão do postscreen; por isso, todo o bloco
17.0.0.0/8é liberado com prioridade para contornar isso -
Greylisting e inspeção de conteúdo
- O greylisting devolve uma falha temporária a remetentes inéditos e libera a passagem quando um MTA legítimo tenta novamente alguns minutos depois
- Botnets de uso único costumam partir para o próximo alvo após a falha, o que as diferencia de remetentes legítimos que mantêm fila de reenvio
- Depois de passar por postscreen e greylisting, mais de 99% do tráfego original de bots é bloqueado com baixo custo de CPU
- O rspamd inspeciona todas as mensagens via protocolo milter e, em vez de aceitar e depois devolver bounce para e-mails suspeitos, rejeita ou atrasa enquanto o servidor remetente ainda está conectado
- O ClamAV verifica anexos com vírus conhecidos e rejeita imediatamente mensagens infectadas, enquanto o classificador bayesiano do rspamd pontua mensagens com base em corpora de spam e ham armazenados no Redis
Entrega local, armazenamento e filtragem
- As mensagens recebidas passam por postscreen, greylisting, rspamd, ClamAV e classificador bayesiano antes de serem entregues ao Dovecot
- Em vez de o Postfix gravar diretamente no diretório home do usuário, ele entrega via LMTP ao Dovecot, que assume indexação, cotas, busca full-text e filtragem Sieve
virtual_alias_mapsconverte endereços comoanything@recoil.orgem endereços entregáveis localmente- O formato de armazenamento é Maildir, usado desde 1998, que salva cada e-mail como um arquivo único em
~/Maildirdo usuário - O Maildir usa três subdiretórios,
tmp/,new/ecur/, além derenameatômico do POSIX, para entregar novas mensagens sem travar toda a mailbox -
Índice de busca e Sieve
- Servidores de e-mail modernos como Stalwart também foram avaliados, mas não foram adotados porque não suportam Maildir e exigem armazenamento em banco de dados próprio, como RocksDB
- O Dovecot separa armazenamento Maildir e desempenho de busca por meio do Flatcurve, um índice full-text separado
- O Flatcurve é um wrapper para Xapian; ele mantém índices Xapian por mailbox em
~/Maildir/fts-flatcurvee os atualiza automaticamente quando novos e-mails chegam - Sieve é uma linguagem declarativa dedicada à filtragem de e-mail, e o plugin Pigeonhole Sieve do Dovecot executa filtros de usuário no momento da entrega
- Scripts Sieve globais movem para
Junkmensagens marcadas pelo rspamd, enquanto scripts por usuário tratam classificação em pastas, regras de férias, prioridade e edição de cabeçalhos
Envio confiável de e-mail
- Para enviar e-mails com confiabilidade, a autenticação de saída é tão importante quanto a defesa de entrada; se qualquer verificação de grandes destinatários falhar, a mensagem pode ir para a pasta de spam ou ser descartada silenciosamente
- SPF é um registro DNS TXT na raiz do domínio que declara quais endereços IP podem afirmar enviar como
@recoil.org - O SPF da Recoil é
v=spf1 a mx -all, de modo que apenaspork.recoil.org, apontado pelo MX derecoil.org, é considerado remetente válido - Em hosts com vários IPs, o Postfix usa
smtp_bind_addressesmtp_bind_address6para fixar um endereço de origem específico e evitar que o kernel escolha um endereço arbitrário - DKIM adiciona uma assinatura criptográfica sobre uma forma canonizada do corpo da mensagem e de cabeçalhos selecionados, e coloca a chave pública de verificação em
<selector>._domainkey.<domain>no DNS -
DMARC e SRS
- O DMARC verifica se o domínio autenticado por SPF e DKIM corresponde ao cabeçalho
From:visível ao usuário e informa ao destinatário como tratar falhas - A política DMARC da Recoil é
p=quarantine, e relatórios agregados são recebidos em um endereçorua=para depurar problemas de entregabilidade - Grandes destinatários enviam aproximadamente uma vez por dia relatórios XML resumindo mensagens que alegaram ter sido enviadas por
recoil.org; entre eles estão Google, Microsoft, Yahoo e Fastmail - E-mails encaminhados podem acabar saindo do IP da Recoil com o domínio original do remetente, o que pode fazer o SPF falhar
- O SRS reescreve o endereço de envelope do remetente para algo como
SRS0=…=example.com=original@recoil.org, permitindo que a verificação SPF no destino seja avaliada com base no domínio da Recoil
- O DMARC verifica se o domínio autenticado por SPF e DKIM corresponde ao cabeçalho
Acesso do usuário e webmail
- Usuários podem acessar o servidor Dovecot com clientes IMAP normais ou abrir um webmail auto-hospedado no navegador
- O Dovecot gerencia o acesso às mailboxes em
porke criptografa os listeners com TLS para evitar que e-mails ou senhas em texto puro passem por redes públicas - Os certificados usam LetsEncrypt, e vários aliases de host como
imap.recoil.orgesmtp.recoil.orgsão atendidos via SNI - O Dovecot também funciona como backend SASL do Postfix, permitindo que usuários usem a mesma senha para acesso IMAP e envio SMTP
- O Roundcube roda como serviço Docker Compose atrás de um proxy reverso TLS Caddy e se conecta ao
porkpor TLS/IMAP como um cliente comum -
Plugins do Roundcube
- O plugin
managesievedo Roundcube usa o protocolo ManageSieve para permitir editar filtros Sieve no navegador - O plugin
markasjunktransforma o botão “Junk” do webmail em uma movimentação para a pasta Junk, fazendo com que o treinamento de classificação ham/spam ocorra sem aparecer ao usuário - A interface ManageSieve do Roundcube não expõe a DSL bruta do Sieve
- O plugin
Trabalho restante e o significado da auto-hospedagem
- A configuração atual tem se mostrado bastante sólida no uso diário nas últimas semanas, mas ainda há trabalho a fazer
recoil.orgcombina registros DNS como MX, A/AAAA, PTR, SPF TXT, DKIM TXT e DMARC TXT para compor recebimento, envio e verificação de e-mail- O MTA-STS informa a outros servidores de e-mail que a comunicação deve ocorrer apenas por TLS com certificado válido, mitigando ataques de downgrade em STARTTLS
- O DANE/TLSA usa hashes de certificado TLS fixados no DNS em vez de HTTPS, mas ainda não foi implantado porque exige uma zona DNS assinada com DNSSEC
- O SRS foi implantado parcialmente, mas ainda não é validado em todos os caminhos de encaminhamento; falhas ligadas à INRIA preocupam por possível impacto em falhas de DMARC e reputação de domínio
-
JMAP, segurança e o futuro da auto-hospedagem
- O JMAP é um protocolo de acesso a e-mail que usa HTTPS e JSON, mais adequado a clientes de rede modernos do que o IMAP
- O Dovecot não oferece suporte nativo a JMAP, e os servidores JMAP independentes avaliados exigem abandonar o Maildir e adotar armazenamento próprio de mailbox
- Um plano em consideração é colocar uma implementação JMAP em OCaml na frente do Dovecot como proxy de tradução, mapeando requisições JMAP para chamadas IMAP e devolvendo respostas JSON
- Em 2026, operar um servidor de e-mail exige acertar com precisão pelo menos seis registros DNS, e obter um bloco IPv4 pelo RIPE leva quase um ano
- O intervalo entre a divulgação de CVEs e o uso de exploits reais contra listeners SMTP/IMAP talvez já seja medido em horas, não semanas, exigindo defesa em profundidade com fixação de endereços específicos, isolamento do contêiner de webmail, greylisting e DNSBL
1 comentários
Comentários do Lobste.rs
Continuo vendo gatekeepers afirmarem categoricamente que é impossível fazer algo que se faz há décadas
Na prática, sigo dizendo que basta configurar reverse DNS, SPF, DMARC e MTA-STS, e que isso não custa muito nem é difícil
Exemplo de servidor de e-mail: https://poofydoof.zia.io/
Hoje uso uma combinação de Debian + Postfix, Dovecot e rspamd, e tenho mais problemas com o Google Workspace do trabalho do que com a minha configuração
Dizer que basta configurar reverse DNS, SPF, DMARC e MTA-STS está 100% correto para domínios e endereços IP que já têm boa reputação
Se você adiciona um novo domínio a um servidor de e-mail que já é confiável para os grandes provedores, a reputação se acumula rápido; se você move um domínio existente para o IP de um novo servidor de e-mail e ainda configura DKIM, também tende a funcionar bem
Mas ouvi dizer que a situação é bem diferente quando se começa do zero com um novo domínio e um novo IP de servidor de e-mail, e que há grande chance de ele ser tratado automaticamente como spam até que os sistemas de aprendizado de máquina dos grandes provedores fiquem satisfeitos
Parece que costuma funcionar quando usuários desses sistemas enviam e-mails para o meu domínio e depois tiram as respostas da pasta de spam
Em vez de gastar tempo correndo atrás disso, acho melhor pagar uns 5 dólares por mês e deixar isso na mão de alguém
https://dmesgd.nycbug.org/dmesgd?do=view&id=8929
Queria saber mais detalhes sobre essa configuração
O Mango Pi MQ-Pro parece difícil de encontrar, então também queria saber se há outros dispositivos ultrabaratos com bom suporte a NetBSD/Linux
Outro motivo para operar seu próprio servidor de e-mail é que você pode descobrir que alguém já está enviando spam com o seu domínio
Quando um dos meus domínios foi migrado para a Squarespace por causa da venda do Google Domains, a Squarespace adicionou automaticamente registros DNS MX/SPF/DKIM do Mailgun, embora eu não tivesse conta no Mailgun
Alguém tomou posse dessa conta no Mailgun e me enviou spam como se tivesse sido enviado do meu domínio
Obrigado, Google
A parte da alocação de IPv4 é especialmente interessante
Para fazer isso por conta própria na Europa, dizem para pagar a anuidade do RIPE NCC e abrir uma conta de registro local de internet (LIR), o que, segundo https://www.ripe.net/membership/payment/ , custa 1800 euros por ano
Dói bastante, mas se fosse mais barato os spammers provavelmente abusariam com mais facilidade
A diversão de escrever um servidor BGP em OCaml não tem preço :-)
Fico me perguntando se IPv6 pode ser usado de forma realista para enviar e receber e-mails
Dei uma olhada ao escrever o texto, mas como deixei o IPv6 desativado no meu servidor de e-mail há alguns anos, resolvi adiar isso até ganhar mais experiência
Segundo https://dn.org/ipv6-and-domain-reputation-in-anti-spam-filters , provedores de e-mail como Gmail, Microsoft e Yahoo usam filtros antispam próprios que atribuem pesos diferentes à reputação do domínio e à reputação do IP, e o suporte a IPv6 ainda está amadurecendo
O Gmail exige PTR válido, SPF e DKIM para e-mails em IPv6, e também recomenda fortemente o uso de DMARC
Sem esses elementos, e-mails enviados por IPv6 frequentemente vão para a pasta de spam ou sofrem atraso
O sistema de filtragem da Microsoft inclui IPv6 nos programas SNDS e JMRP, mas pode limitar ou atrasar e-mails em IPv6 se a reputação do remetente não for conhecida
No fim, IPv6 é mais um ponto de falha, e provavelmente não é uma boa ideia montar um domínio de envio misto IPv4/IPv6 logo no começo
Ainda não encontrei endpoints SMTP somente IPv6