How SipherMail is built for speed and privacy

This is an engineering post about the foundations under SipherMail: who runs the mail service, the protocol our apps speak, and what that means for you. We describe the guarantees, not the machines.

Why we run our own mail service#

We run our own mail service instead of building on a hosted email API. Mail is the product, and the service decides who can deliver to you, how messages are stored, how filtering works and what is logged. Handing those decisions to a third-party service would make some of our privacy statements depend on someone else’s policies.

Running it ourselves has costs. We carry the operational work: deliverability, abuse handling, upgrades, capacity and backups. We took that trade because it lets us describe, accurately, where your mail lives.

What this gives you#

• Modern protocols, built in. Our apps use JMAP, and other apps can use IMAP and SMTP.
• Abuse stopped early. Our application can check an incoming message before the server accepts it, so abusive senders can be rejected at the SMTP stage.
• Accounts and app passwords managed by us. There is no outside provisioning service in the middle.
• A clear owner for your mail. The mail service stores your mail. Our application keeps metadata and app-specific fields, such as preferences. Keeping these separate means the mail store has one owner.

Why JMAP is the main protocol#

JMAP is a protocol for mail, contacts and calendars over HTTP and JSON. Our web and mobile apps use it as their main way to talk to the mail service.

Compared with IMAP, it fits modern apps better:

• Batching. One request can ask for a mailbox list, a page of messages and their thread information together. Fewer round trips matters on mobile networks.
• Stateless over HTTP. Requests are ordinary HTTPS calls, with no per-account session to keep open.
• Push. The service can tell an app that something changed, so the inbox updates without constant polling.
• Structured data. Messages, threads and mailboxes come back as JSON that apps can use directly.

We still use other protocols where they are the right tool.

IMAP and SMTP for your other apps#

Not everyone wants our apps, and you should not have to. Third-party mail apps connect to SipherMail over IMAP and SMTP:

You sign in with an app password, which you generate in your account and can revoke at any time. It is separate from your login password. See app passwords.

SMTP is also how mail moves between servers, so it is the protocol of the whole internet’s email whichever app you use.

Where it runs#

SipherMail is hosted in Europe, on servers we operate. Traffic between our internal systems travels over a private network, not the public internet, which keeps internal calls off public routes.

TLS and storage#

Connections from your device to SipherMail use TLS, and so do the IMAP and SMTP connections described above. TLS protects mail in transit between you and us.

TLS in transit is not the same as end-to-end encryption. Mail the service receives from other services, and normal messages you send, can be read by the service. Only encrypted messages are unreadable to us. We explain the difference in how end-to-end encryption works.

Stored IMAP passwords for your mailbox are encrypted at rest with AES-256-GCM.

Backups#

Backups are automated, encrypted and kept away from the servers they protect, not just on a second disk in the same machine. A backup on the same server does not help if the server is lost, so keeping them elsewhere is the point.

We will not make claims here about recovery times or retention periods, because we would rather not promise numbers in a blog post. Check the status page if you want to see how the service is doing.

What this means for you#

You get fast apps on a protocol designed for them, standard IMAP and SMTP when you want another client, and a clear answer to where your mail lives: on servers we run, in Europe.

If you want to point a mail app at SipherMail, see third-party clients.