Moon Flower Society > Umbra Mail Privacy Architecture
Posted August 24, 2026. Markdown.
Objetivo: construir um servidor de e-mail interoperável com a Internet normal, leve o bastante para rodar em infraestrutura modesta, mas desenhado desde o início para saber o mínimo possível sobre seus usuários e para tornar o conteúdo armazenado ilegível até mesmo para o administrador do servidor.
Eu não tentaria criar um “Proton caseiro” copiando o Proton.
Eu faria algo mais simples e, em alguns aspectos, mais rigoroso:
um servidor de e-mail dividido em duas camadas, onde a máquina exposta à Internet não guarda caixas postais e a máquina que guarda as caixas não fica exposta à Internet.
INTERNET
│
│ SMTP
▼
┌─────────────────────┐
│ MAIL GATEWAY │
│ │
│ VPS pública mínima │
│ MX / SMTP / DKIM │
│ sem mailbox │
│ sem webmail │
└──────────┬──────────┘
│
WireGuard / Tailscale
│
▼
┌─────────────────────┐
│ MAIL VAULT │
│ │
│ Stalwart │
│ mailboxes │
│ JMAP / IMAP │
│ OpenPGP │
│ RocksDB │
└──────────┬──────────┘
│
│ rede privada
▼
┌─────────────────────┐
│ DISPOSITIVO │
│ │
│ Thunderbird etc. │
│ chave privada PGP │
└─────────────────────┘
A regra mais importante seria:
a chave privada que descriptografa o e-mail nunca entra no servidor.
O servidor recebe somente a chave pública do usuário.
Há quatro problemas diferentes que normalmente são misturados quando alguém fala em “e-mail privado”.
O administrador não deveria conseguir abrir uma mailbox no servidor e simplesmente ler as mensagens.
Se alguém roubar o disco, o backup ou obtiver acesso ao armazenamento, as mensagens deveriam continuar ilegíveis.
O servidor público deveria revelar o mínimo possível sobre a infraestrutura interna e os dispositivos dos usuários.
Uma conta não deveria exigir telefone, nome real, endereço de recuperação ou outros identificadores desnecessários.
É importante não vender uma fantasia.
E-mail SMTP tradicional não é um protocolo anônimo.
Mesmo com uma arquitetura excelente, normalmente ainda existem metadados como:
remetente
destinatário
domínio
horário aproximado
servidor de origem
servidor de destino
Além disso, se alguém enviar:
gmail.com → nosso servidor
sem OpenPGP ou S/MIME, a mensagem chegará em texto legível ao processo do servidor antes de ser criptografada para armazenamento.
Portanto:
criptografia em repouso ≠ criptografia ponta a ponta
A arquitetura deve ser descrita como:
privacy-first e pseudonymous by design
e não como:
“e-mail impossível de rastrear”.
Eu usaria Stalwart Mail Server como núcleo.
Ele já concentra em um único software funções que tradicionalmente exigiriam uma pilha como:
Postfix
Dovecot
Rspamd
Sieve
servidor JMAP
gerenciamento de usuários
DKIM
DMARC
SPF
Isso reduz drasticamente:
Para este projeto, essa simplicidade é uma característica de segurança.
Para uma instalação pequena ou média e de nó único, eu escolheria RocksDB.
A documentação atual do Stalwart recomenda RocksDB para instalações single-node devido à velocidade, confiabilidade e baixo custo operacional.
A ideia seria reutilizar RocksDB para o máximo de funções internas possível:
Data Store
Blob Store
Search Store
In-Memory Store
Assim evitamos introduzir:
PostgreSQL
Redis
Meilisearch
S3
sem necessidade real.
Quanto menos peças existirem, menos coisas precisam ser atualizadas, monitoradas, autenticadas, copiadas e protegidas.
Cada usuário gera sua própria chave OpenPGP no dispositivo pessoal.
Pablo
│
├── private key ← nunca sai do computador
│
└── public key → enviada ao servidor
O Stalwart recebe apenas a chave pública.
Quando uma mensagem chega:
SMTP
↓
Stalwart recebe
↓
filtros necessários
↓
mensagem é criptografada
↓
disco
O conteúdo armazenado passa a ser ilegível sem a chave privada correspondente.
Segundo a documentação atual do Stalwart, a criptografia em repouso pode usar a chave pública OpenPGP ou certificado S/MIME fornecido pelo próprio usuário, e o administrador do sistema não possui a chave necessária para descriptografar a mensagem armazenada.
Eu escolheria:
OpenPGP
AES-256
encryptAtRest = true
allowSpamTraining = false
servidor A
│
│ TLS
▼
servidor B
Protege a mensagem durante o transporte.
Não impede o servidor de lê-la.
mensagem chega
↓
servidor criptografa
↓
████████████████
dados no disco
████████████████
Protege o armazenamento.
Pablo
↓
criptografa localmente
↓
servidores recebem apenas ciphertext
↓
Adam
↓
descriptografa localmente
Esse é o nível ideal.
Quando dois usuários possuem OpenPGP configurado, a mensagem deve ser criptografada antes de sair do dispositivo do remetente.
Eu não instalaria Roundcube, SnappyMail ou outro webmail no início.
Cada aplicação web adicional traz:
sessões
cookies
JavaScript
dependências
upload de arquivos
XSS
CSRF
atualizações
novas superfícies de ataque
Além disso, existe um problema conceitual quando a criptografia acontece no navegador:
Se o mesmo servidor que você não quer que conheça sua chave privada também entrega o JavaScript responsável pela criptografia, um servidor comprometido pode simplesmente entregar JavaScript adulterado.
Por isso, a primeira versão usaria clientes instalados localmente, como Thunderbird.
A máquina pública deveria ser quase descartável.
Ela teria:
IP público
PTR
SMTP
DKIM
SPF
DMARC
MTA-STS
TLS-RPT
DANE, quando possível
rate limiting
fila temporária
Ela não teria mailboxes.
O Vault seria a parte valiosa.
Idealmente:
sem portas públicas
sem IP divulgado no DNS
sem SSH público
sem painel administrativo público
Ele só conversa com Gateway, administrador e dispositivos autorizados por WireGuard ou Tailscale.
Gmail
↓
SMTP/TLS
↓
Gateway público
↓
túnel privado
↓
Mail Vault
↓
Stalwart
↓
criptografia OpenPGP do usuário
↓
RocksDB
O Gateway conhece apenas o necessário para roteamento e entrega, mas não mantém mailbox.
Thunderbird
↓
Tailscale / WireGuard
↓
Mail Vault
↓
Gateway
↓
SMTP/TLS
↓
servidor destinatário
O IP público associado ao serviço será o do Gateway, não o do Mail Vault nem o do dispositivo pessoal.
Se a proposta incluir contas para terceiros, eu evitaria cadastro público irrestrito.
Fluxo:
invite token
↓
escolher username
↓
criar senha
↓
registrar chave pública
↓
conta criada
Não pedir nome, telefone, CPF, data de nascimento, endereço ou recovery email se não houver necessidade.
Não é preciso proteger aquilo que nunca foi coletado.
Privacidade séria tem uma consequência desagradável:
não pode existir um botão mágico que recupere tudo.
Se o administrador possui uma chave capaz de recuperar o conteúdo de todos, então ele também possui uma chave capaz de ler o conteúdo de todos.
Cada usuário deve manter a chave privada em pelo menos dois lugares seguros, um deles offline.
Perdeu a chave privada?
As mensagens continuam existindo, mas não podem mais ser abertas.
Isso não é bug. É consequência da arquitetura.
O projeto deve prever rotação.
O Stalwart permite registrar múltiplas chaves públicas por conta.
key-old
key-new
Durante a transição, mensagens novas usam a nova chave enquanto o usuário ainda preserva localmente a antiga para ler mensagens passadas.
O painel administrativo não deve existir na Internet pública.
Acesso apenas por:
Tailscale
SSH tunnel
WireGuard
Nada de admin.mail.example.com público se isso puder ser evitado.
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
Idealmente com FIDO2 / hardware key para administração.
No Gateway público:
25 SMTP
465 Submission TLS, se usado
587 Submission, se usado
443 MTA-STS / endpoints necessários
No Vault:
nenhuma porta pública
Apenas interfaces privadas.
Configuração:
MX
A / AAAA
PTR
SPF
DKIM
DMARC
MTA-STS
TLS-RPT
DNSSEC
DANE/TLSA
Essencial:
PTR
SPF
DKIM
DMARC
Muito recomendado:
MTA-STS
TLS-RPT
DNSSEC
Excelente quando possível:
DANE / TLSA
Começar com:
p=none
Depois:
p=quarantine
E finalmente:
p=reject
quando SPF e DKIM estiverem comprovadamente corretos.
Não existe maneira compatível com SMTP de esconder todos os metadados.
Mas é possível evitar cabeçalhos inúteis, por exemplo:
X-Originating-IP
X-Mailer
X-Client-IP
O mundo externo deveria enxergar o Gateway, não o dispositivo pessoal.
Política:
logs suficientes para descobrir que algo está quebrado, nunca logs suficientes para reconstruir a vida de alguém.
Não registrar:
corpo de mensagens
anexos
credenciais
tokens
cookies
chaves privadas
Logs SMTP operacionais:
retenção de 24h a 72h
Depois:
rotate
compress
delete
Não colocar:
Google Analytics
Cloudflare Analytics
Sentry SaaS
PostHog Cloud
telemetria externa
Se métricas forem necessárias:
Prometheus local
Grafana local
ou métricas do próprio sistema.
Para pseudonimato mais forte no acesso do usuário, eu ofereceria um Onion Service opcional.
Ele protege melhor:
cliente ↔ infraestrutura
mas não transforma SMTP em protocolo anônimo.
Uma arquitetura realista:
Internet SMTP → Gateway normal
Usuário → Onion / rede privada → Vault
Para uso pessoal ou pequeno grupo:
Tailscale é melhor.
Mais simples, rápido e previsível.
Para um serviço pseudônimo em que a privacidade do IP do usuário seja parte central da proposta:
Tor pode fazer mais sentido.
Eu suportaria ambos, mas começaria com Tailscale.
Mesmo com OpenPGP por usuário, eu ainda usaria criptografia de disco.
LUKS
As camadas protegem ameaças diferentes:
LUKS
→ protege disco desligado / roubado
OpenPGP por mailbox
→ protege mensagem mesmo com o sistema de arquivos montado
Usaria:
restic
ou:
Borg
sempre com criptografia própria.
Copiar:
RocksDB
blobs
configuração
DKIM keys
estado necessário do Stalwart
Não copiar:
logs antigos
cache
temporários
chaves privadas dos usuários
A chave do backup não fica no mesmo servidor.
Backup que nunca foi restaurado é apenas esperança.
backup diário
teste de restore mensal ou trimestral
Checklist:
servidor inicia?
contas aparecem?
mailboxes aparecem?
mensagens criptografadas continuam lá?
cliente com chave privada consegue abrir?
DKIM continua válido?
Fazer o máximo possível no Gateway usando:
reputação de IP
SPF
DKIM
DMARC
DNSBL
rate limits
HELO validation
greylisting, se necessário
A inspeção de conteúdo deve existir apenas quando necessária e nunca gerar cópias plaintext permanentes.
Privacidade não significa permitir abuso.
Se contas de terceiros forem oferecidas:
invite-only
limite diário de envio
limite de destinatários
quota
rate limit
relay fechado
monitoramento de bounce
Isso protege reputação e entregabilidade sem precisar ler mailboxes.
Um formulário aberto para qualquer pessoa destruiria rapidamente a reputação SMTP.
Portanto:
privacidade para usuários legítimos, não anonimato operacional para abuso.
Usar domínio próprio dedicado ao serviço.
Ativar:
WHOIS privacy
2FA
DNSSEC
registry lock, quando disponível
WHOIS privacy esconde dados do público, não do registrador.
O provedor da VPS provavelmente saberá:
quem alugou o servidor
forma de pagamento
IP administrativo
Isso faz parte do threat model.
Se o objetivo for pseudonimato público, tudo bem.
Se o objetivo for anonimato inclusive perante o provedor, e-mail tradicional já deixa de ser uma escolha ideal.
A filosofia central:
“Mesmo que eu queira, eu não deveria possuir a chave necessária.”
Isso é muito melhor do que:
“Confie em mim, eu sou o administrador.”
Aproximadamente:
1 vCPU
1 GB RAM
10 a 20 GB SSD
IPv4 dedicado
IPv6
Aproximadamente:
1 a 2 vCPU
2 GB RAM
SSD de acordo com o volume das caixas
O armazenamento importa muito mais do que CPU.
Para este projeto eu escolheria:
Stalwart binary
+
systemd
Menos camadas, menos imagens, menos volumes e menos coisas para atualizar.
Debian Stable
instalação mínima.
Somente:
Stalwart
WireGuard/Tailscale
nftables
restic
ferramentas administrativas básicas
Nada de painel de hospedagem.
Monitorar saúde, não pessoas.
SMTP responde?
fila está crescendo?
disco está cheio?
certificado vence quando?
DKIM está válido?
DNS está correto?
Vault responde ao Gateway?
Evitar dashboards de comportamento individual.
Depois da infraestrutura madura, aí sim eu faria um cliente próprio.
Possíveis stacks:
Rust + Tauri
ou:
Flutter
usando JMAP.
A chave privada permanece no dispositivo e toda criptografia/descriptografia acontece localmente.
Entre usuários do próprio serviço:
pablo@example.email
↓
consulta chave pública
↓
criptografa localmente
↓
envia
↓
servidor nunca vê plaintext
Para usuários externos:
OpenPGP quando disponível
SMTP normal quando não estiver
Publicar uma página chamada:
Privacy Architecture
explicando claramente:
endereços
metadados SMTP
horários
informações necessárias para roteamento
corpo
anexos
conteúdo criptografado
mensagens externas não-E2EE durante processamento
| Ameaça | Proteção |
|---|---|
| SSD roubado | LUKS + OpenPGP |
| Backup roubado | restic/Borg + OpenPGP |
| Root curioso | OpenPGP por usuário |
| Gateway comprometido | não possui mailboxes |
| Vault descoberto na Internet | não possui exposição pública |
| Sniffing SMTP | TLS + MTA-STS + DANE |
| IP do cliente exposto | Gateway e minimização de headers |
| Conta roubada | senha forte + 2FA |
| Chave privada perdida | backup offline do usuário |
| Spam / abuso | convites + quotas + rate limits |
| Servidor comprometido durante processamento | somente E2EE protege completamente |
| Metadados SMTP | não podem ser totalmente eliminados |
Começar assim:
Debian
↓
Stalwart
↓
RocksDB
↓
OpenPGP encryption-at-rest
↓
Thunderbird
↓
Tailscale para administração
Depois de provar envio, recebimento, deliverability, criptografia, backup e restore, separar Gateway e Vault.
Stalwart
domínio de teste
PTR
SPF
DKIM
DMARC
TLS
uma conta
Thunderbird
Gerar localmente a chave OpenPGP.
Enviar ao servidor apenas a public key.
Ativar criptografia.
Enviar uma mensagem e verificar que o armazenamento não contém o texto em claro.
Configurar restic, executar backup, destruir uma instalação de teste e restaurar em outra máquina.
MX
↓
Gateway
↓
WireGuard
↓
Vault
Adicionar:
invite-only signup
sem recovery email obrigatório
sem telefone
Tor Onion Service opcional
retenção curta de logs
header minimization
JMAP client
OpenPGP local
keyring do sistema
Tauri / Flutter
┌────────────────────────────┐
│ DNS │
│ │
│ SPF DKIM DMARC DNSSEC │
│ MTA-STS TLS-RPT DANE │
└─────────────┬──────────────┘
│
▼
┌───────────────┐
│ MAIL GATEWAY │
│ │
Internet SMTP ───────────►│ Stalwart MTA │
│ public IP │
│ no mailbox │
└───────┬───────┘
│
WireGuard
│
▼
┌────────────────┐
│ MAIL VAULT │
│ │
│ Stalwart │
│ RocksDB │
│ OpenPGP │
│ no public IP │
└───────┬────────┘
│
┌─────────────┴─────────────┐
│ │
Tailscale Tor Onion
│ │
└─────────────┬─────────────┘
│
▼
┌──────────────────┐
│ MAIL CLIENT │
│ │
│ Thunderbird │
│ private PGP key │
└──────────────────┘
O servidor entrega mensagens. O usuário possui as chaves. O administrador possui a infraestrutura, mas não o conteúdo.
Esse deve ser o princípio para todas as decisões futuras.
Ela não tenta resolver privacidade adicionando mais software.
Ela faz o contrário.
Remove:
webmail
banco SQL externo
Redis
painéis
analytics
serviços SaaS
portas públicas
dependências
e adiciona apenas as fronteiras que realmente importam:
Gateway separado
Vault privado
chave privada fora do servidor
criptografia em repouso
E2EE quando possível
logs mínimos
rede administrativa privada
É pequena o suficiente para uma pessoa entender completamente.
E, para infraestrutura de privacidade, ser compreensível é uma propriedade de segurança.
Stalwart, Encryption at Rest
https://stalw.art/docs/encryption/
Stalwart, OpenPGP
https://stalw.art/docs/encryption/pgp/
Stalwart, Encryption Management
https://stalw.art/docs/encryption/manage/
Stalwart, MTA Overview
https://stalw.art/docs/mta/
Stalwart, TLS and DANE
https://stalw.art/docs/mta/outbound/tls/
Stalwart, MTA-STS
https://stalw.art/docs/mta/transport-security/mta-sts/
Stalwart, Storage Backends
https://stalw.art/docs/storage/backends/
Stalwart, RocksDB
https://stalw.art/docs/storage/backends/rocksdb/
Stalwart, Choosing a Database
https://stalw.art/docs/install/store/
A documentação atual do Stalwart confirma que mensagens podem ser criptografadas em repouso usando uma chave pública OpenPGP ou certificado S/MIME fornecido pelo usuário, enquanto a chave privada permanece sob controle do usuário. Ela também recomenda RocksDB para instalações single-node e oferece suporte nativo a DKIM, SPF, DMARC, DANE, MTA-STS e TLS reporting.
A parte que nenhuma arquitetura SMTP convencional consegue eliminar completamente é metadado. Para comunicação realmente confidencial, o conteúdo precisa nascer criptografado no dispositivo do remetente. Para anonimato forte, um protocolo projetado especificamente para anonimato provavelmente será uma escolha melhor do que e-mail tradicional.
View the original Markdown file
Ideas | What changed | RSS | About | Text version
Pablo Murad <pablomurad@pm.me>