The boring pages, written plainly.

1. The control that matters most

Sortmail has nowhere to store the contents of your mail. There is no database column for a body, a snippet, an attachment or a raw subject line, and an automated test fails our build if anyone adds one.

A message body exists in memory for the fraction of a second that classification takes — or, when you open the message in Sortmail, for as long as it takes to pass it to your browser — and is then discarded. What remains is a fingerprint: who sent it, the domain, a keyed hash of the subject, a handful of true/false characteristics, the category we chose, and why.

This is worth stating plainly because it changes what a breach of Sortmail would mean. An attacker who took our entire database would learn who emails you and roughly how much, and would not be able to read a single message, because the messages are not there.

2. What we ask your mail provider for

One Gmail permission: gmail.modify. It lets us read a message in order to classify it, and add or remove labels. We ask for it because moving mail is the product.

• Sortmail never emails anyone as you. On Outlook, the permission we hold cannot send mail. On Gmail, the only permission that can label and archive (gmail.modify) could also send, so there the guarantee is our code: it calls no send, draft or trash endpoint, and an automated test that reads the provider code fails the build if one is added.
• We do not ask for mail.google.com, so we cannot permanently delete anything.
• We do not ask for contacts, Drive or calendar.
• We ask for the Gmail permission only at the step where you turn sorting on, not at sign-in, so you can create an account and look around first.
• If you later remove a permission, we pause that mailbox and tell you, rather than failing silently on every message.

3. Encryption and key handling

• TLS 1.2 minimum for every connection, TLS 1.3 preferred, with HSTS set to two years and preloaded. Weak ciphers are disabled and we test this externally.
• The database and its backups are encrypted at rest.
• OAuth refresh tokens are encrypted with AES-256-GCM using a per-mailbox data key, itself wrapped by a key held in a managed key service. That key is separate from the database encryption key and is rotated annually and on suspicion.
• Access tokens are never written to disk or to the queue. They live only in the worker's memory, for less than their own lifetime, and are cleared when it stops.
• The web tier has no permission to decrypt OAuth tokens. Only the worker tier does. This is enforced by cloud IAM and verified by a test that asserts the web role is denied.
• All tokens, salts and identifiers come from a cryptographically secure random source. We write no cryptography of our own.

4. Sign-in and sessions

• There are no passwords anywhere in Sortmail. You sign in with Google, with Microsoft, or with a single-use emailed link. We cannot leak a password database because there is not one.
• Magic links carry 128 bits of entropy, are stored only as a hash, expire in 15 minutes, work once, and are rate-limited per address and per network.
• Sessions are server-side records referenced by an opaque 256-bit cookie token, set HttpOnly, Secure, SameSite=Lax and with the __Host- prefix. Tokens rotate when your privileges change.
• Sessions last a maximum of 30 days, or 14 days idle. Signing out invalidates the session server-side; signing out everywhere revokes all of them.
• Changing your sign-in address, disconnecting a mailbox, exporting your data and deleting your account each require you to re-authenticate first.
• State-changing requests carry a double-submitted CSRF token and are checked against Origin and Sec-Fetch-Site. We do not rely on SameSite alone.

5. Who can reach production

• Production access — the servers, the database and the key service — is limited to one person, the founder.
• The administrative console sits behind Cloudflare Access, which requires a hardware security key, and the application itself checks Cloudflare's signed assertion and an allowlist of addresses on every request. Every admin page view and action is written to the audit log.
• The admin tools show accounts' addresses, statuses and counts only — never a message, a subject line or a sender.
• No one at Sortmail can read your mail: it is not stored, and nothing fetches it for anyone but you. Support never opens a message on your behalf.

6. How the software is built

• Every input crossing a trust boundary — HTTP bodies, query strings, webhook payloads, queue jobs, provider responses — is parsed against a strict schema that rejects unknown fields.
• Database access is parameterised. A lint rule forbids building SQL by string concatenation.
• Rendered message content is sanitised server-side against a strict allowlist, stripped of scripts, styles and event handlers, and displayed in a sandboxed frame with its own content security policy. Remote images are blocked by default and proxied when you allow them. We test this against a corpus of hostile messages.
• Outbound fetches to addresses that come from data are defended against server-side request forgery: allowlisted schemes, DNS resolved and private or internal addresses refused, the connection pinned to the address that was checked, every redirect checked again, short timeouts and size caps.
• The application sets a content security policy that loads scripts only from our own origin (and, on the sign-in and waitlist forms, from Cloudflare’s bot check), blocks eval, plugins and framing, and restricts where a page can send data. It does not yet use per-request nonces, because the framework does not support them, so inline scripts are permitted; escaping, sanitising and the hostile-message tests are what keep script from being injected. No third-party scripts load on signed-in pages.
• Sortmail accepts no file uploads. That removes an entire category of risk rather than mitigating it.
• Static analysis, dependency and vulnerability scanning, secret scanning across full history, container and infrastructure scanning, and authenticated dynamic scanning all run in continuous integration, and a build fails on a finding tied to a high-likelihood weakness.

7. Logging and retention

• Logs are structured and pass through an allowlist: only fields known to be safe are written. Email addresses are hashed, and subjects and bodies cannot be logged at all.
• A unit test asserts that logging a message object emits no subject and no body.
• Operational logs are kept 30 days. The audit trail is kept 90 days, in append-only storage with restricted access.
• Errors return a correlation id to you and the detail stays server-side.

8. Availability and recovery

• Point-in-time recovery on the database, encrypted backups, a snapshot before every migration, and a restore drill recorded at least once a year.
• A recovery point objective of 1 hour and a recovery time objective of 4 hours.
• Provider failures are absorbed by queueing with exponential backoff and a circuit breaker; mail is sorted late rather than lost.
• Kill switches exist to pause all sorting, pause a single mailbox, disable the model provider and fall back to rules, or disable new signups.

9. Google’s security assessment

Google requires every app that uses a restricted Gmail permission to complete an annual security assessment (CASA). Sortmail’s letter of assessment has not been issued yet. When it is, we will publish it on this page.

10. Reporting a vulnerability

Write to [email protected]. We acknowledge within one business day and aim to give you a remediation timeline within five.

We will not take legal action against researchers acting in good faith who give us reasonable time to fix an issue, avoid privacy violations and service degradation, and do not access accounts other than their own.

We do not currently pay bounties. We do credit researchers who want to be credited.