← back to the garden

MD

Umbra Mail Privacy Architecture

Umbra Mail

Arquitetura de e-mail self-hosted focada em privacidade, pseudonimato e leveza

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.

1. A ideia central

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.

2. O que este projeto tenta proteger

Há quatro problemas diferentes que normalmente são misturados quando alguém fala em “e-mail privado”.

Privacidade do conteúdo

O administrador não deveria conseguir abrir uma mailbox no servidor e simplesmente ler as mensagens.

Privacidade contra comprometimento do servidor

Se alguém roubar o disco, o backup ou obtiver acesso ao armazenamento, as mensagens deveriam continuar ilegíveis.

Privacidade de rede

O servidor público deveria revelar o mínimo possível sobre a infraestrutura interna e os dispositivos dos usuários.

Pseudonimato

Uma conta não deveria exigir telefone, nome real, endereço de recuperação ou outros identificadores desnecessários.

3. O que ele NÃO promete

É 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”.

4. Componente principal: Stalwart

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:

  • número de processos;
  • quantidade de configurações;
  • superfície operacional;
  • dependências;
  • pontos de falha.

Para este projeto, essa simplicidade é uma característica de segurança.

5. Armazenamento: RocksDB

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.

6. O coração da privacidade: OpenPGP por usuário

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

7. Três níveis de proteção

Camada 1: TLS

servidor A
   │
   │ TLS
   ▼
servidor B

Protege a mensagem durante o transporte.

Não impede o servidor de lê-la.

Camada 2: criptografia em repouso

mensagem chega
      ↓
servidor criptografa
      ↓
████████████████
dados no disco
████████████████

Protege o armazenamento.

Camada 3: E2EE

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.

8. Sem webmail na primeira versão

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.

9. Mail Gateway público

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.

10. Mail Vault privado

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.

11. Fluxo de entrada

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.

12. Fluxo de saída

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.

13. Pseudonimato de usuários

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.

14. Recuperação de conta

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.

15. Rotação de chaves

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.

16. Administração

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.

17. SSH

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

Idealmente com FIDO2 / hardware key para administração.

18. Firewall

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.

19. DNS

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

20. DMARC

Começar com:

p=none

Depois:

p=quarantine

E finalmente:

p=reject

quando SPF e DKIM estiverem comprovadamente corretos.

21. Metadados

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.

22. Logs

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

23. Nada de analytics

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.

24. Tor como camada opcional

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

25. Tailscale versus Tor

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.

26. Disco

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

27. Backups

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.

28. Teste de restauração

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?

29. Antispam sem destruir privacidade

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.

30. Controle de abuso

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.

31. Por que não permitir cadastro público anônimo

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.

32. Registrador e domínio

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.

33. O provedor ainda sabe coisas

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.

34. O servidor também não deve confiar no administrador

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.”

35. Recursos necessários

Gateway

Aproximadamente:

1 vCPU
1 GB RAM
10 a 20 GB SSD
IPv4 dedicado
IPv6

Vault

Aproximadamente:

1 a 2 vCPU
2 GB RAM
SSD de acordo com o volume das caixas

O armazenamento importa muito mais do que CPU.

36. Native > Docker

Para este projeto eu escolheria:

Stalwart binary
+
systemd

Menos camadas, menos imagens, menos volumes e menos coisas para atualizar.

37. Sistema operacional

Debian Stable

instalação mínima.

Somente:

Stalwart
WireGuard/Tailscale
nftables
restic
ferramentas administrativas básicas

Nada de painel de hospedagem.

38. Monitoramento

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.

39. Futuro cliente próprio

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.

40. Comunicação interna realmente privada

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

41. Transparência

Publicar uma página chamada:

Privacy Architecture

explicando claramente:

O que o servidor consegue ver

endereços
metadados SMTP
horários
informações necessárias para roteamento

O que não consegue ler depois de armazenado

corpo
anexos
conteúdo criptografado

Quando pode existir plaintext em memória

mensagens externas não-E2EE durante processamento

42. Threat model resumido

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

43. MVP recomendado

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.

44. Fases do projeto

Fase 1: laboratório

Stalwart
domínio de teste
PTR
SPF
DKIM
DMARC
TLS
uma conta
Thunderbird

Fase 2: zero-access storage

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.

Fase 3: disaster recovery

Configurar restic, executar backup, destruir uma instalação de teste e restaurar em outra máquina.

Fase 4: separar Gateway e Vault

MX
 ↓
Gateway
 ↓
WireGuard
 ↓
Vault

Fase 5: pseudonimato

Adicionar:

invite-only signup
sem recovery email obrigatório
sem telefone
Tor Onion Service opcional
retenção curta de logs
header minimization

Fase 6: cliente próprio

JMAP client
OpenPGP local
keyring do sistema
Tauri / Flutter

45. Checklist de produção

  • Mail recebido de Gmail.
  • Mail recebido de Outlook.
  • Mail enviado para Gmail corretamente.
  • SPF válido.
  • DKIM válido.
  • DMARC válido.
  • PTR correto.
  • TLS funcional.
  • MTA-STS publicado.
  • TLS-RPT publicado.
  • OpenPGP encryption-at-rest comprovada.
  • Private key inexistente no servidor.
  • Backup restaurado com sucesso.
  • Vault inacessível pela Internet pública.
  • Admin UI inacessível pela Internet pública.
  • Gateway não contém mailboxes.
  • Nenhum relay aberto.
  • Logs possuem retenção definida.
  • Nenhuma analytics externa.
  • Quotas e rate limits ativos.

46. Arquitetura final

                    ┌────────────────────────────┐
                    │           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  │
                       └──────────────────┘

47. A frase que resume o projeto

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.

48. Por que essa arquitetura é boa

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.

Referências oficiais consultadas

Nota final

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.