Seven pledges,
written in plain language.

IMAP and SMTP passwords are encrypted with AES-256-GCM under a per-deployment key. They are decrypted in memory only at connection time — never logged, never cached to Redis, never placed in job payloads, never shown in admin views. To rotate, reconnect the mailbox; a dedicated rotation flow is planned.

All user data is protected by PostgreSQL row-level security. Workspace data is scoped to members; one workspace cannot reach another’s mailboxes or messages. Requests are scoped to the person making them. The sync worker is the exception and has to be: it holds a service-role key and lists every connected mailbox on a timer, because that is how it knows what to sync. It reads ids and sync state, not mail, and everything it does with a mailbox afterwards is scoped to that mailbox’s owner.

The admin console shows connection health, sync state, and aggregate counts. Message bodies, subjects, sender and recipient addresses, and credentials are never rendered in admin views — by code, not by policy document.

Email and password sign-in with bcrypt hashing. TOTP two-factor: once you enrol a factor, a code is required on every sign-in, demanded in middleware rather than in a screen that could be walked around. There are no backup codes — the ones that used to be offered could be generated and never redeemed, so they were withdrawn rather than left standing as a promise. Session cookies are SameSite=Lax and are readable by the page’s own JavaScript, because that is how the browser client reads your session; they are not HttpOnly, and we would rather say so than claim a flag we do not set. SSO (SAML/OIDC) and SCIM are planned, not present.

All web traffic is TLS 1.2+ with HTTP redirected to HTTPS. IMAP and SMTP connections use SSL/TLS or STARTTLS, and certificates are verified in production — unless you turn that off. The connect wizard offers a “skip TLS certificate verification” switch when a certificate fails, for people running their own server with a self-signed one; it disables both chain and hostname checking for that mailbox, and it is the only way to reach one of these servers. Nothing turns it on for you. DKIM and SPF live at your domain and provider — TELVRIX sends through your own SMTP, so your existing signing applies.

Received HTML is sanitised and then rendered inside a sandboxed iframe with scripts, forms, popups and navigation withheld by the browser, under a content security policy that permits nothing to load. It cannot read your session, restyle the application around it, or overlay a login box on top of it. Remote images are blocked until you press Load images, so simply opening a message tells the sender nothing.

No compliance certifications are in place during the closed beta. SOC 2 and a formal GDPR review are planned around general availability. Do not use TELVRIX for legally regulated email — PHI, PCI, or similar — until then.