- O e-mail é, por natureza, um sistema aberto e, em 2026, é possível operá-lo em casa ou em um VPS, gerenciando problemas de entrega e spam, sem entregar seu correio a um pequeno número de grandes empresas
- Para operar em casa, é necessário ter um IPv4 fixo que não esteja em blocklists, não usar CGNAT, ter permissão para alterar o registro PTR e manter abertas as portas
25·143·465·587·993; se essas condições não forem atendidas, um VPS é mais adequado
- É preciso configurar corretamente SPF·DKIM·DMARC·MX·PTR e verificar o estado de entrega com o mail-tester.com; mesmo que ocorra uma breve falha de internet, o servidor remetente tentará entregar novamente
- Combinando o plugin GPT do Rspamd com o modelo local
Gemma 4 12B QAT, é possível gerar a probabilidade de spam e o motivo da classificação sem enviar e-mails pessoais para uma API externa de LLM
- docker-mailserver e clientes como Thunderbird e webmail podem reduzir a barreira de implantação, mas o operador assume diretamente a responsabilidade por backup·recuperação·acesso remoto·atualizações e deve testar o procedimento de recuperação ao menos uma vez
Escolhendo entre casa e VPS
- Em geral, recomenda-se um VPS, mas, se a internet residencial atender a todas as condições abaixo, também é possível operar um servidor de e-mail em casa
- Endereço IPv4 fixo que não esteja em blocklists
- Conexão que não esteja atrás de CGNAT
- Permissão para alterar o registro PTR do IP, por exemplo via suporte do ISP
- Ambiente em que seja possível abrir as portas comuns de servidor de e-mail
25, 143, 465, 587, 993
- Mesmo que o servidor fique fora do ar por um curto período, o servidor de e-mail do remetente tentará entregar novamente, portanto os e-mails recebidos não serão perdidos imediatamente
- Se o tempo de queda da internet ao longo do dia for inferior a 40%, pode funcionar normalmente
Software de servidor de e-mail
Domínio e configuração de DNS
- Assim como o IP, o domínio também deve primeiro ser verificado quanto à presença em blocklists de spam
- Para envio e recebimento normais, são necessários os seguintes registros DNS
- SPF: especifica quais servidores podem enviar e-mail em nome do domínio; como valor comum, pode-se usar
v=spf1 mx a ~all
- DKIM: adiciona uma assinatura criptográfica aos cabeçalhos dos e-mails enviados; o nome e a chave pública informados pelo servidor são registrados no domínio
- DMARC: estende SPF e DKIM para evitar falsificação de domínio; se não houver certeza sobre o valor, é possível usar um gerador de DMARC
- MX: especifica para onde outros servidores devem entregar e-mails. O método comum é apontar o registro A de
mail.yourdomain.com para o IP do servidor e definir esse hostname como o valor do MX com prioridade 10
- O registro PTR só pode ser configurado pelo ISP ou provedor de VPS, e o IP do servidor deve resolver reversamente para um hostname real de servidor de e-mail, como
mail.yourdomain.com
- Alguns servidores recomendam registros adicionais para descoberta automática de serviços, mas SPF·DKIM·DMARC·MX·PTR compõem a configuração básica
- Após a implantação, recomenda-se verificar os registros, o funcionamento do servidor e o estado de entrega de e-mails em mail-tester.com
Bloqueio de spam com LLM local
- As soluções open source tradicionais de bloqueio de spam dependiam de blocklists de IP e domínio, serviços externos como Spamhaus e busca por palavras-chave; como a eficácia era baixa, isso foi uma das principais causas de abandono da hospedagem própria
- Nos últimos dois anos, a classificação por LLM local surgiu como uma opção capaz de resolver o problema de spam em ambientes self-hosted
- Rspamd permite classificar e-mails como spam ou não por meio de um LLM usando o plugin GPT, além de blocklists, verificações de IP·DNS e detecção por palavras-chave
- Em vez de enviar e-mails pessoais para uma API externa de LLM, executa-se localmente o Gemma 4 12B QAT
- Pode ser executado em GPU ou CPU e requer no mínimo 7 GB de RAM ou VRAM
- Suporta vários idiomas e pode ser usado para classificação de e-mails
Execução do modelo local e conexão com o Rspamd
- Se estiver configurando um LLM local pela primeira vez, é possível consultar o guia de llama.cpp da Unsloth para Windows·Linux·macOS
- No Linux e no macOS, instale o
llama.cpp com o comando abaixo
curl -LsSf https://llama.app/install.sh | sh
- No Windows, use o comando abaixo
winget install llama.cpp
- O servidor do modelo é executado da seguinte forma, e a interface de chat pode ser acessada em
localhost:8080
llama serve -hf unsloth/gemma-4-12B-it-qat-GGUF:UD-Q4_K_XL --reasoning off -fa on -c 16000 --temp 0.7
- Em
/etc/rspamd/local.d/gpt.conf do Rspamd, ao definir type = "openai" e o endpoint local /v1, é possível conectar o modelo por meio de uma interface compatível com OpenAI
- O modelo deve ser configurado como
unsloth/gemma-4-12B-it-qat-GGUF:UD-Q4_K_XL
- O máximo de tokens de saída deve ser
100, a temperatura 0.1 e o tempo limite 30 segundos
- Em um servidor de LLM sem GPU, o tempo limite pode ser aumentado
- A resposta é interpretada como JSON e exige a chave
probability, não spam
- O prompt instrui a analisar cabeçalhos, assunto e corpo e retornar apenas JSON com a probabilidade de spam entre
0.0~1.0 e uma breve justificativa da classificação
- O recurso de contexto de conversa por destinatário armazena no Redis os rótulos dos e-mails recentes, principais remetentes e um resumo de 512 caracteres, e inclui isso no prompt de classificação quando houver 5 ou mais itens
- O escopo é
user, a caixa de correio por destinatário
- O período de retenção dos resumos de mensagens é de
14 dias, e a vida útil das chaves no Redis é de 30 dias
- Funciona localmente, sem chamadas externas
- Para e-mails de spam, pode retornar uma probabilidade alta com base em marketing baseado em medo, conteúdo comercial indesejado, domínios internacionalizados suspeitos etc.
- Para e-mails técnicos legítimos de teste, pode retornar uma probabilidade baixa por não haver links suspeitos nem linguagem promocional
- Na interface web do Rspamd, é possível conferir gráficos e dados e colar um e-mail para testar o resultado de classificação previsto
Escolha do cliente de e-mail
- No desktop, Thunderbird é um cliente open source com muitos recursos que pode substituir o Outlook
- Oferece os recursos básicos necessários e uma busca suficientemente boa
- Também oferece um app para Android
- Foi usado por 3 anos sem problemas
- Se for necessário webmail, é possível usar as seguintes opções
Manutenção e responsabilidades operacionais
- Soluções modernas de servidor de e-mail, como docker-mailserver, são projetadas levando em conta correções de segurança e atualizações automáticas que não quebrem ambientes de produção
- A hospedagem própria oferece controle sobre os dados, mas devolve ao operador a responsabilidade por backup, recuperação, acesso remoto e atualizações
- Sem backups, todos os dados podem ser perdidos; portanto, é preciso preparar um plano de backup adequado e testar o procedimento de recuperação ao menos uma vez
- Se for possível atender às condições e assumir as responsabilidades operacionais, é possível manter o e-mail funcionando mesmo com breves interrupções do servidor, e usuários que valorizam soberania dos dados podem experimentar a hospedagem própria
1 comentários
Comentários no Lobste.rs
Uso o Fastmail e evito todos os incômodos. Foi divertido ler quais incômodos estou evitando.
Se for uma caixa de entrada importante, há excelentes serviços de caixa de e-mail hospedada como Migadu, Simplymail e Fastmail, então não penso em operar uma por conta própria. Para algo divertido ou sem importância, até dá.
Como prova do problema da dependência do Gmail, atualmente o Gmail está bloqueando como spam os e-mails de redefinição de senha do Lobsters.
Nos logs aparece: “Gmail has detected that this message is likely 550-5.7.1 unsolicited mail. To reduce the amount of spam sent to Gmail, this 550-5.7.1 message has been blocked.” Fico curioso para saber como informar isso ao Google.
Achei que o gateway da lista de discussão tivesse quebrado do lado do lobste.rs e cancelei a inscrição, mas de todo modo eu não lia com frequência e agora prefiro o site.
A ideia de operar o próprio e-mail em casa é boa, mas a questão é quando você se muda. E-mails importantes chegam mesmo durante uma mudança, então só um MX de backup não basta.
Deve ser possível implementar, mas a mudança em si já é bastante estressante, e não quero colocar um procedimento de migração de e-mail na lista de verificação da mudança. Nesse meio-tempo, tudo bem se o blog ou um mestre DNS oculto ficarem fora do ar.
Há cerca de 15 anos migrei o servidor de e-mail para uma VM barata e, desde então, ele segue rodando de forma estável. Se você puder usar um IP fixo que não esteja em listas de bloqueio e uma conexão de nível empresarial no lugar onde se estabeleceu, deve ser viável.
Além disso, o SMTP inclui novas tentativas no próprio protocolo; se um servidor parar de tentar novamente antes de 24 horas, ele não está em conformidade com as especificações relevantes. Diferentemente de casos em que o servidor rejeita explicitamente, como quando não há caixa postal ou a capacidade foi excedida, o SMTP é mais robusto do que parece.
A parte difícil de operar o próprio e-mail não é o spam recebido, mas o fato de grandes provedores de e-mail classificarem as mensagens enviadas como spam mesmo depois de você tomar todas as medidas necessárias para envio.
Com o volume de envio de uma pessoa ou de uma casa, o IP não acumula reputação positiva, então, se suas mensagens começarem a não entrar nas caixas de entrada do Gmail e afins, isso se torna praticamente impossível de resolver.
Dito isso, se você retransmitir por um serviço como o Amazon SES, a configuração pode ser fácil e os problemas de entrega podem desaparecer. Se você opera por conta própria por motivos políticos ou de soberania de dados, talvez seja uma solução difícil de aceitar.
A melhor coisa de um servidor de e-mail próprio é que não preciso fazer filtragem de spam. De vez em quando chega lixo eletrônico, mas prefiro a certeza de que qualquer pessoa pode me enviar e-mail.
Verificar a pasta de spam não é suficiente. Grandes empresas de tecnologia às vezes descartam e-mails silenciosamente sem grande motivo, e a taxa de sucesso de recebimento do Gmail é de cerca de 90%, então até 10% dos e-mails enviados por outros grandes provedores desaparecem. Meu e-mail auto-hospedado nunca falhou ao receber.
Por outro lado, para enviar e-mails a contas de outros grandes serviços, ainda é preciso ter uma conta lá, mas como contato sempre forneço meu endereço auto-hospedado. Quero testar se é possível usar um grande provedor apenas para envio e apontar o MX para meu próprio servidor.
https://xmox.nl foi muito fácil de configurar.
Opero por conta própria a lista de discussão do site. Há apenas alguns assinantes, mas os e-mails são entregues normalmente.
Não tenho intenção de operar também meu e-mail pessoal por conta própria.
Há alguns anos instalei https://modoboa.org/ em um VPS da Hetzner, mas depois de falhar várias vezes em upgrades, basicamente desisti. Ainda mantenho porque a maior parte continua funcionando, mas não é uma configuração sustentável no longo prazo, e ainda não decidi qual será a próxima escolha.
Alguns códigos de autenticação em duas etapas, como os da Steam, chegam tarde demais à caixa de entrada. Não consegui descobrir a causa, então nesses casos uso uma conta do Gmail que quase nunca uso.
Um pouco de spam também passa, mas para spam recebido não há solução perfeita. Um LLM projetado para processamento de linguagem natural talvez se encaixe bem nessa tarefa, então tenho curiosidade sobre o desempenho real, mas também parece possível que o uso de recursos fique absurdo.