1 pontos por GN⁺ 15 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • A infraestrutura de e-mail da Recoil, operada desde 1997, foi atualizada para uma pilha auto-hospedada que combina bloco IPv4 /24 dedicado, 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.org processa 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 /24 foi 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 para pork.recoil.org, servindo como sinal de reputação de e-mail

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 postscreen fica na frente da porta 25, fazendo consultas DNSBL em paralelo, atraso pre-greet e verificações de pipelining e comandos não SMTP
  • O postscreen só encaminha ao smtpd real 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_maps converte endereços como anything@recoil.org em endereços entregáveis localmente
  • O formato de armazenamento é Maildir, usado desde 1998, que salva cada e-mail como um arquivo único em ~/Maildir do usuário
  • O Maildir usa três subdiretórios, tmp/, new/ e cur/, além de rename atô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-flatcurve e 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 Junk mensagens 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 apenas pork.recoil.org, apontado pelo MX de recoil.org, é considerado remetente válido
  • Em hosts com vários IPs, o Postfix usa smtp_bind_address e smtp_bind_address6 para 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ço rua= 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

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 pork e 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.org e smtp.recoil.org sã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 pork por TLS/IMAP como um cliente comum
  • Plugins do Roundcube

    • O plugin managesieve do Roundcube usa o protocolo ManageSieve para permitir editar filtros Sieve no navegador
    • O plugin markasjunk transforma 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

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.org combina 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/

    • Opero e-mail auto-hospedado desde por volta de 2008, e ainda me surpreende que tanta gente diga que isso é impossível
      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
    • Acho que a parte central é “algo que se faz há décadas”
      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
    • Depois de operar um servidor de e-mail por cerca de 3 anos, diria que a parte difícil não é configurar DNS, SPF, DMARC ou MTA-STS, mas sim evitar listas de bloqueio ao enviar e-mails transacionais e não conseguir entrar em listas de permissão de alguns provedores de e-mail
      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
    • O servidor de e-mail de exemplo é ótimo, e isto aqui também é muito bom
      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

    • Não é barato, mas dá cerca de 12 libras por endereço por ano, então, se você dividir isso entre serviços locais para amigos e família, não parece tão ruim
      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

    • Boa pergunta
      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