Ten Truths About Email

Almost every argument about private email starts in the wrong place. It starts with a feature, a country, a cryptographic buzzword, or a comparison chart, and never with the thing underneath all of it: what email is, and what it therefore cannot be made into.

There are ten things that are true of every email service on earth. They are true of the free ones, the paid ones, the ones with the strongest marketing, and the ones you have never heard of. They are true of ours. Once you hold them clearly, most of the noise in this market falls away, and a much smaller set of real questions is left standing.

A provider cannot change what email is. It can only change what it does with your mail, how long it keeps it, and how much control it hands back to you.

The Ten Truths

1. Email was not designed with privacy in mind. It was designed to work everywhere.

SMTP is a delivery protocol from an era when the network was small and everyone on it was assumed to be trustworthy. Its design goal was universal interoperability, and by that measure it is one of the most successful protocols ever written. Any address can reach any other address, across any two systems, forever. Privacy was simply not a requirement of the specification, and every privacy property email has today was bolted on afterward by someone working around the protocol rather than with it.

2. No service can protect you from law enforcement. It can only reduce what it holds.

Any provider that operates lawfully in any country will respond to lawful process. That is not a moral failing or a marketing weakness, it is what operating a business means. The only variable that actually matters is how much there is to hand over when the request arrives. A service that stores less, retains for a shorter time, and cannot read what it stores has less to produce. A service that keeps everything forever in readable form has everything to produce. Any provider claiming to be immune is telling you something about its marketing, not its architecture.

3. Jurisdiction is often less important than people think.

Countries have had cooperation mechanisms for a very long time. Mutual legal assistance treaties, intelligence-sharing arrangements, and direct police-to-police channels all move requests across borders routinely. Just as importantly, nearly every country writes one set of rules for its own citizens and a weaker set for foreign traffic. Choosing a jurisdiction usually means choosing which country treats you as the foreigner with fewer protections. Jurisdiction is a real factor, but it is one input among many, and it is nowhere near the trump card it is sold as. We take this apart in detail in The Myth of Jurisdictional Privacy, and if you want to check any specific country rather than take our word for it, our Privacy Law Directory covers the data-protection regimes, surveillance powers, and intelligence-sharing arrangements jurisdiction by jurisdiction, with the enforcement record for each.

4. Nearly all of your email is sent and received in plain text, whatever service you use.

Connections between mail servers are usually encrypted in transit, which protects the message from someone watching the wire. That is not the same as the message being encrypted. TLS is hop by hop, not end to end. Each server in the path opens the connection, reads the message in full, and opens a fresh connection to the next one. The protection exists only in the gaps between machines, and never at the machines themselves.

This is the part that catches people out, because it means the encryption on your side does not decide how your mail travels. Your correspondent does. Your provider can hold your stored mail under the strongest at-rest encryption that exists, quantum-resistant algorithms and all, and none of it changes what happens when you write to somebody using ordinary mail. The message is composed as plain text, handed to your provider as plain text, and sent onward inside a TLS connection that the receiving server terminates the moment it arrives. That server now holds your message in the clear, writes it to its own storage in whatever form it likes, and hands it to the recipient as plain text. The same is true in reverse for everything sent to you.

So at each end it is ordinary readable text: readable by the sending system, readable by the receiving system, readable by anyone with lawful or unlawful access to either. State-of-the-art storage encryption is genuinely worth having, because it protects the copy that sits in your mailbox for years, which is the copy most likely to be breached or demanded. It simply has no authority over the wire. This is true no matter whose logo is on your mailbox, because the other side of nearly every conversation you have is an ordinary mail system doing ordinary things.

5. Most of that mail already knows exactly who you are.

Think about what actually arrives in a mailbox. Bank statements, medical results and appointment reminders, legal correspondence, insurance, tax documents, school and government notices, receipts for everything you buy, job applications and the interviews that follow, and the daily traffic of family and friends. That mail carries your full legal name, your address, your account numbers, your health, your finances, and your relationships. The identifying content is not incidental to email, it is most of what email is for.

6. You have no control over the people you write to.

You can secure your own side completely and still have every message you send end up in a mailbox that is scanned, indexed, archived indefinitely, or eventually breached. Your correspondent chose their provider, their client, their backup habits, and their forwarding rules, and none of those choices are yours to make. Every message you send is a copy that leaves your control the moment it is delivered. You can only protect your side, so protect it well, and treat that as the whole of what is achievable rather than a failure to reach further.

7. Anyone can use end-to-end encryption, on any provider, including Gmail.

PGP, S/MIME, and encrypted attachments are open standards implemented in widely available software. They work over ordinary SMTP, which is the entire point of them. Nothing about them requires a special provider, a special app, or a subscription, and a Gmail user with a PGP key and a mail client is doing exactly the same cryptography as anyone paying a premium for it. When a service presents end-to-end encryption as its own invention or its exclusive property, what is usually being sold is convenience wrapped around a public standard, and often a version of it that only works when both people are inside the same walled garden. See The Walled Garden Approach.

8. Encrypted content still carries more than enough metadata.

Encrypt the body perfectly and the envelope still says who wrote to whom, at what time, from which address and often which network, with what subject line in many configurations, at what size, in reply to which earlier message, and with what frequency over what period. That is a social graph, a daily routine, a set of relationships, and a timeline. Investigators have said plainly for years that this is frequently more useful than content. We wrote a whole article on it: Metadata Is Enough.

9. That metadata cannot be encrypted, or the mail will not deliver.

This is the part people most want to be untrue. The routing information has to be readable, because the systems in the path have to read it to do their job. A message whose envelope is encrypted is a message that cannot be delivered. No provider can fix this, no protocol extension has fixed it, and any claim to have eliminated email metadata should be read as a claim to have eliminated email.

10. Once decrypted, the content is out of your hands again.

Encryption protects a message in flight and at rest. It does not follow the message into the recipient's life. When they decrypt it, they hold plain text, and what happens next belongs to them and to whatever software and service they use. They can forward it, quote it, screenshot it, sync it to a cloud backup, or open it in a client that indexes it. Cryptography ends where the other person's judgement begins.

What Those Ten Truths Leave

Read together, they rule out a great deal of what is currently sold as email privacy. No provider can make email private by nature, immunise you from legal process, encrypt the envelope, or govern the far end of your conversations. Anyone marketing a solution to one of those is either confused or counting on you to be.

What the ten truths do not rule out is substantial, and it is where the real decisions live. Everything below is genuinely a choice, and every one of them is a choice a provider makes on your behalf unless you make it yourself.

The Questions Worth Asking

Start with what happens to your mail once it is sitting on someone else's disk.

Do you want your email used to train AI systems?

Not in the abstract. Your mail specifically: your finances, your medical results, your legal correspondence, your family conversations, your purchase history, your job search. That corpus has commercial value, and the value accrues to the company, not to you. It is a fair question whether you want to supply it.

Note which mail that actually is. It is overwhelmingly the mail you receive, not the mail you send. The bank statement, the lab result, the invoice, the legal letter, the tax notice, and the offer of employment are all things other people wrote and sent to you, and they are the valuable part of the mailbox by a wide margin. Your own outgoing mail is a thin slice by comparison, and where a particular message needs protecting you can always encrypt it yourself with PGP or S/MIME, or send the sensitive part as an encrypted attachment or a Secure Link.

The useful thing is that received mail can be protected too, even though you had no say in how it was written or sent. Once a message reaches your mailbox it is yours, and it can be encrypted to your public key on arrival, before it is ever written to storage, so it sits there readable only by you. Everything after that follows: a breach yields ciphertext, a legal demand yields ciphertext, and the provider has nothing to read even if it wanted to. You did not control the sender, but you do control what happens the moment their message lands. That is auto-encryption, and it is the single most useful thing you can do about the pile of mail other people send you.

Do you want that data shared, sold, or otherwise distributed?

Business models differ, and so do privacy policies, but the operative question is simple: when the mail is in their hands, is it an asset they may monetise, or a deposit they are holding for you? The answer is usually written down somewhere, and it is usually not on the marketing page.

Do you want it kept forever, or do you want to be the one who deletes it?

Deletion is a real technical and policy question, not a checkbox. Does a deleted message actually leave storage, and on what timescale, or does it move somewhere you cannot see and stay there? A provider that genuinely deletes on your instruction is a provider with less to lose and less to hand over later.

Do you want your data protected at rest if the provider is breached?

Breaches happen to competent organisations. The question is not whether one will occur, it is what an attacker finds when it does. Mail stored encrypted at rest, where the keys are not simply sitting beside it, produces a very different incident than a copy of everyone's mailbox in readable form.

What You Should Be Able to Ask For

Those first questions are about harm reduction. The next ones are about what you actually get.

Would you rather be the only one holding the key?

There is a genuine trade-off here, and it deserves to be stated rather than sold. If you alone hold the key, nobody can read your stored mail without you, and nobody can be compelled to. If you lose the key, the mail is gone, and no support ticket will bring it back. If the provider also holds a copy, recovery becomes possible, and so does everything else that a held key makes possible. Neither answer is wrong, but it should be your answer, made knowingly. Our position on where keys should live is in Why You Should Never Let a Provider Generate or Store Your Private Key.

Would you like more from your mail than you currently have?

Privacy services have a habit of shipping a thin client and calling the missing features a security posture. Filtering, sieve rules, aliases, calendars and contacts that sync properly, notes, folder management, real search, and support for whichever client you already like are not luxuries. Losing them is a cost, and it should be counted as one.

The trade-off is also largely false. Nothing about not selling your data requires shipping less software, and the reverse is closer to the truth: a service paid for by subscription answers to the people using it, while a service paid for by your data answers to someone else. You should expect a privacy service to offer more than the free mailbox you left, not less. That is the standard we hold ourselves to, and the feature list runs past a hundred entries, including a good many the large providers do not offer at all. Privacy is the reason to come. It should not be the excuse for what is missing when you arrive.

Would you like to give every correspondent a different address?

This one deserves emphasis, because it is the single most effective anti-spam technique available and almost nobody uses it. Give each company, each site, and each service its own address. When one of them leaks, sells, or gets breached, you know precisely who did it, and you switch that one address off. Nothing else in your mail is affected.

The alternative is the situation most people are in. One address, or only a few, given to everyone or many, now circulating on lists you cannot see. Filtering that is a game of whack-a-mole you cannot win, because you are fighting an endless supply of senders over an address you cannot retire. Per-correspondent addresses let you win by ending the game instead of playing it. We wrote about the mechanics in Breaking the Chain of Online Vulnerability.

Would you like all of it to work with what you already use?

Control and interoperability are constantly sold as opposites, and they are not. IMAP, SMTP, CalDAV, CardDAV, and WebDAV are open standards, and a service built on them works with the mail client, calendar app, and phone you already own. The interesting question is whether privacy can be added to those standards without breaking the interoperability that makes them worth using. It can, and our own mail and sync credentials are the worked example.

Start with mail itself. Connecting a phone or a desktop client over IMAP, POP3, or SMTP normally means giving that device your account password, the same one that opens everything you have. Every device holds a full copy of it, a stolen laptop hands over the account rather than the mailbox, and changing it breaks every other device at once. So we do not use it. Each client gets its own app password, a randomly generated login and password pair that exists only for that device. You set what it is allowed to do, whether it may fetch mail or send it or both, you can restrict it to particular addresses or networks, you can give it an expiry date, and you can revoke it on its own without touching anything else. A lost phone is one credential deleted. Nothing else notices.

Ordinary CalDAV and CardDAV are built around your identity. You log in with your account name, and every device you sync presents that name on every request, into a URL path that contains it. That is the account name written into server logs, over and over, by every phone, tablet, and laptop you own, permanently linking all of them to each other and to you. Nothing in the specification requires this, it is just how everyone implemented it.

We rebuilt that layer. Each device you connect gets its own credential pair, a random login and a separate random token, generated independently and meaning nothing on their own. Neither is your mailbox name, and neither carries a prefix, a pattern, or anything else derived from your account. The sync address the device uses is derived cryptographically from that pair, so the paths are unguessable, they are different for every device, and regenerating a credential retires the old address with it. Two devices belonging to the same person present as two unrelated users, and the account name behind them never appears at all.

Each credential is also scoped. You decide which calendars, task lists, contacts, or notes a given device may see, and whether it may create, read, update, and/or delete. And calendar, tasklist, and notes names are anonymized in the path, too. Revocation works exactly as it does for mail, one credential removed while everything else carries on. It is the same idea as giving every correspondent their own address, applied to devices instead of senders. Credentials may be edited on the fly, for example you can instantly change a more permissive caledar, tasklist, contacts, or notes to read only, or any combination.

All of it is served over TLS and nothing else, and all of it is still standard CalDAV and CardDAV. Apple's built-in calendar and contacts on iOS and macOS, Thunderbird, DAVx⁵ on Android, Evolution, and anything else that speaks the protocol connect to it directly, with no plugin, no extension, and no application of ours anywhere on your device. The privacy sits in how the protocol is served, which is the only place it can sit without costing you the ability to use your own software. Setup for each platform is in the CalDAV and CardDAV setup guide.

Some of you should ask yourself: Why am I paying extra for a bridge to get this functionality back in a limited way? ...and I won't even make a selling a bridge analogy.

Would you like a human being to answer when something breaks?

Mail is infrastructure. When it fails, it fails in the middle of something that matters, and the difference between a person who knows the system and a ticket queue is the difference between an afternoon and a week.

How to Choose

Services that do these things exist, and several have been doing them for decades. They cost money, because running mail properly costs money and because a service that does not sell your data has to be paid by you instead. The amounts involved are small next to what the mailbox holds.

Choose by starting with the ten truths. If a service markets itself as the solution to any of them, think twice. Nobody has fixed SMTP, nobody is beyond the reach of legal process, nobody has encrypted the envelope, and nobody controls what your correspondent's provider does. A company that claims otherwise has told you something useful about how it will describe everything else.

Then evaluate on what is actually real. How many aliases you get and how easily you can create and retire them. Whether the features you need are present rather than described. How long the service has existed and what its record looks like. Whether it works with your existing client or demands its own. Whether the answers about deletion, retention, and encryption at rest are specific rather than reassuring.

And then try it. A month of actual use will tell you more than every comparison chart ever written, because it answers the only question that finally matters, which is whether the service works the way you need it to work.

Email will never be private by nature. It can be handled by someone who has decided not to make it worse, and who hands you the controls. That is the whole of what is on offer, from anyone. The rest is marketing.

That decision is the one thing a provider genuinely gets to make, so here is ours, stated plainly. In 27 years of continuous operation we have never shared your data, never sold it, never handed it to a broker, and never fed it to any AI. We never will. The only thing your data is ever used for is running the service you are paying us to run. It is stored encrypted at rest, you decide what is kept and what is deleted, you can hand out a different address to every correspondent and switch any of them off, and you can hold the only key if you want to. You are in full control, which is the point.