Skip to content
Security

What we promise about your mail.

blamepost is built around one default: every mailbox byte is sealed before it touches disk, with post-quantum crypto on every listener. This page summarizes the posture and tells you how to report a problem.

Sealed at rest

Your bytes don't live in plaintext.

  • Every mailbox column except indexes, timestamps, foreign-key IDs, and derived-hash columns is sealed before it touches disk.
  • The seal key never leaves the vault; it's derived per-tenant via HKDF-SHA3-512, so two tenants on the same database can't read each other's ciphertext.
  • A stolen storage volume — or an attacker who exploits a read-only path in the app — gets ciphertext, not headers, subjects, recipients, or bodies.
  • Backups are sealed with the same envelope and stored in the same region as the source data.

Crypto posture

Key exchangeML-KEM-1024 + P-384 hybrid (post-quantum + classical)
Symmetric cipherXChaCha20-Poly1305
Key derivationSHAKE256 + HKDF-SHA3-512
HashSHA3-512
Password hashingArgon2id (memory-hard)
SignaturesSLH-DSA-SHAKE-256f (post-quantum)
TLS1.3 minimum on every listener
How the seal works

Per-tenant keys derived inside your region.

The encryption key for your mailbox is never copied; it's derived on demand from a vault root that lives in sealed form on disk and is unsealed only at process boot. Two customers on the same database can't read each other's mail, because they don't share a derived key.

Vault root

Sealed on disk via the operator passphrase. Unsealed once at process boot; never persisted in unsealed form.

Per-tenant key

Derived per account from the vault root + your tenant ID.

HKDF-SHA3-512
Per-row key

Derived per message column from the tenant key + table + row ID + column name.

HKDF-SHA3-512
Sealed bytes

Authenticated-encryption envelope written to disk. AAD-bound; tampering invalidates the tag.

XChaCha20-Poly1305
What happens to your mail

Inbound message, end to end.

From the moment a message hits the MX port to the moment it's stored on disk, every part is parsed, validated, and sealed individually so an attacker who steals one row can't read the rest of the mailbox by knowing anything about how mail works.

Wire

TLS 1.3 minimum. Post-quantum hybrid where the peer supports it. Smuggling defenses at the parser.

Verify

DMARC / SPF / DKIM / ARC checked against your domain's published policy. Failing senders quarantined.

Seal

Body, subject, from/to, attachments, trace headers, and search index each sealed with their own per-row key before disk write.

Region residency

Your data stays in the region you pick.

  • You pick a region at signup. EU domains land on EU-Central by default.
  • Ciphertext is not replicated outside the region you select.
  • The 12 regional MX clusters terminate TLS regionally; mail enters the platform encrypted on the wire.
  • Per-tenant derived seal keys mean an export from one region can't be decrypted by infrastructure in another region.
Authentication

Who's allowed in your mailbox.

  • Passkeys (WebAuthn) for sign-in; TOTP fallback for accounts that prefer it.
  • Per-device application passwords for IMAP and JMAP clients, scoped per protocol and revocable independently.
  • DPoP-bound access tokens on the JMAP API so a stolen token can't be replayed from a different client.
  • Sessions sealed at rest; a database read can't enumerate active logins.
Deliverability

We watch the auth-results so you don't.

  • DKIM signed on every outbound message with both ed25519 and RSA.
  • DMARC + ARC verified on every inbound message; failing-DMARC senders are quarantined per published policy.
  • MTA-STS published for every domain you add; TLS-RPT aggregate reports parsed + surfaced in the admin console.
  • REQUIRETLS honored when senders ask for it; SMTP smuggling defenses (CVE-2023-51764 / -51765 / -51766) applied at the parser.
Reporting a vulnerability

Found a problem?

Email security@blamepost.com with a description of the finding and a reproduction recipe. We acknowledge every report; if the report represents a real vulnerability, we coordinate on a disclosure timeline with you. Coordination follows ISO 29147 / 30111 norms.

What the program doesn't cover: network-layer denial-of-service against the public mail listeners (front-end rate-limiting is best-effort, not a guarantee); findings that require admin access we issued you; findings against third-party services blamepost uses (those go to the upstream provider).