# 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.** ```text 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: ```text remetente destinatário domínio horário aproximado servidor de origem servidor de destino ``` Além disso, se alguém enviar: ```text 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: ```text 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: ```text 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: ```text Data Store Blob Store Search Store In-Memory Store ``` Assim evitamos introduzir: ```text 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**. ```text Pablo │ ├── private key ← nunca sai do computador │ └── public key → enviada ao servidor ``` O Stalwart recebe apenas a chave pública. Quando uma mensagem chega: ```text 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: ```text OpenPGP AES-256 encryptAtRest = true allowSpamTraining = false ``` --- # 7. Três níveis de proteção ## Camada 1: TLS ```text servidor A │ │ TLS ▼ servidor B ``` Protege a mensagem **durante o transporte**. Não impede o servidor de lê-la. ## Camada 2: criptografia em repouso ```text mensagem chega ↓ servidor criptografa ↓ ████████████████ dados no disco ████████████████ ``` Protege o armazenamento. ## Camada 3: E2EE ```text 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: ```text 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: ```text 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: ```text 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 ```text 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 ```text 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: ```text 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. ```text 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: ```text Tailscale SSH tunnel WireGuard ``` Nada de `admin.mail.example.com` público se isso puder ser evitado. --- # 17. SSH ```text PasswordAuthentication no PermitRootLogin no PubkeyAuthentication yes ``` Idealmente com **FIDO2 / hardware key** para administração. --- # 18. Firewall No Gateway público: ```text 25 SMTP 465 Submission TLS, se usado 587 Submission, se usado 443 MTA-STS / endpoints necessários ``` No Vault: ```text nenhuma porta pública ``` Apenas interfaces privadas. --- # 19. DNS Configuração: ```text MX A / AAAA PTR SPF DKIM DMARC MTA-STS TLS-RPT DNSSEC DANE/TLSA ``` Essencial: ```text PTR SPF DKIM DMARC ``` Muito recomendado: ```text MTA-STS TLS-RPT DNSSEC ``` Excelente quando possível: ```text DANE / TLSA ``` --- # 20. DMARC Começar com: ```text p=none ``` Depois: ```text p=quarantine ``` E finalmente: ```text 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: ```text 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: ```text corpo de mensagens anexos credenciais tokens cookies chaves privadas ``` Logs SMTP operacionais: ```text retenção de 24h a 72h ``` Depois: ```text rotate compress delete ``` --- # 23. Nada de analytics Não colocar: ```text Google Analytics Cloudflare Analytics Sentry SaaS PostHog Cloud telemetria externa ``` Se métricas forem necessárias: ```text 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: ```text cliente ↔ infraestrutura ``` mas **não transforma SMTP em protocolo anônimo**. Uma arquitetura realista: ```text 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. ```text LUKS ``` As camadas protegem ameaças diferentes: ```text LUKS → protege disco desligado / roubado OpenPGP por mailbox → protege mensagem mesmo com o sistema de arquivos montado ``` --- # 27. Backups Usaria: ```text restic ``` ou: ```text Borg ``` sempre com criptografia própria. Copiar: ```text RocksDB blobs configuração DKIM keys estado necessário do Stalwart ``` Não copiar: ```text 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. ```text backup diário teste de restore mensal ou trimestral ``` Checklist: ```text 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: ```text 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: ```text 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: ```text 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á: ```text 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: ```text 1 vCPU 1 GB RAM 10 a 20 GB SSD IPv4 dedicado IPv6 ``` ## Vault Aproximadamente: ```text 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: ```text Stalwart binary + systemd ``` Menos camadas, menos imagens, menos volumes e menos coisas para atualizar. --- # 37. Sistema operacional ```text Debian Stable ``` instalação mínima. Somente: ```text Stalwart WireGuard/Tailscale nftables restic ferramentas administrativas básicas ``` Nada de painel de hospedagem. --- # 38. Monitoramento Monitorar saúde, não pessoas. ```text 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: ```text Rust + Tauri ``` ou: ```text 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: ```text pablo@example.email ↓ consulta chave pública ↓ criptografa localmente ↓ envia ↓ servidor nunca vê plaintext ``` Para usuários externos: ```text OpenPGP quando disponível SMTP normal quando não estiver ``` --- # 41. Transparência Publicar uma página chamada: ```text Privacy Architecture ``` explicando claramente: ### O que o servidor consegue ver ```text endereços metadados SMTP horários informações necessárias para roteamento ``` ### O que não consegue ler depois de armazenado ```text corpo anexos conteúdo criptografado ``` ### Quando pode existir plaintext em memória ```text 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: ```text 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 ```text 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 ```text MX ↓ Gateway ↓ WireGuard ↓ Vault ``` ## Fase 5: pseudonimato Adicionar: ```text 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 ```text 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 ```text ┌────────────────────────────┐ │ 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: ```text webmail banco SQL externo Redis painéis analytics serviços SaaS portas públicas dependências ``` e adiciona apenas as fronteiras que realmente importam: ```text 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 * 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/ --- ## 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.