Where Does Email Sovereignty Live?

When people talk about wanting sovereignty over their email, running the server themselves seems like a reasonable place to start. It’s your computer, your software, your messages. But when you follow what it takes to keep the thing working, you may find that the sovereignty we want is somewhere else in the system. And we have taken on quite a lot of work getting there.

Email has an interesting economic arrangement. Most of us get it for free, and there are business reasons for companies to offer that. Your email account becomes the account you use for their other products, and eventually there may be something they can charge you for. There are also providers whose arrangement is more boring: you pay them for email. In both cases, the cost of maintaining the infrastructure is spread across many people. Once someone is already operating the service, another personal mailbox is a relatively small addition. If you do it yourself, you are now operating a service for one person. ;)

This is mostly economies of scale and specialization. There is a comparative advantage argument too, when you consider what else you could be doing with the time. You may know how to run a mail server, but the provider already has people, systems, and experience devoted to it. Even if you enjoy the initial setup, you should probably count the maintenance you won’t enjoy six months later when something stops working at an inconvenient time.

Let’s say we do it anyway. We need a domain name, an IP address, and a computer with CPU, memory, and storage. Rent a machine, install the mail software, configure the domain, and we can get something running. But we want the email to work when the computer doesn’t. Machines go down, hosting companies do maintenance, and sometimes we are the maintenance problem ourselves. An upgrade can break the configuration. A disk can fail. Other mail servers may retry delivery during an outage, but meanwhile we still want to read our messages and send replies.

So we might want another machine. Preferably somewhere that won’t go down for the same reason as the first one. Now we have to keep the necessary state consistent between them, and we still need backups because replication will quite efficiently replicate our mistakes too. If you delete something and the deletion reaches the other server, you have two computers agreeing that the thing is gone. What you wanted was a way to recover it. That needs a different arrangement, and you should probably try restoring from it before depending on it.

Then there’s the part where everyone else has to accept our email. A server can be configured correctly and still have trouble reaching someone’s inbox. The receiving service makes its own judgment about the sender, including the reputation of the IP address and domain. It doesn’t owe us an inbox placement because we followed the installation instructions. People talk about warming up an address, but the complete decision process inside these services is not transparent, and sending a thousand emails cannot simply mean we have manufactured trust. We are running one end of a system that requires other people’s cooperation.

And all this software has a half-life. We have to follow security updates, understand what an upgrade changes, and know how to recover when it fails. This is where paying an email provider begins to look quite reasonable. They get to spread this work across their customers, while you get to stop thinking about whether your inbox is going to survive the weekend. It is easy to compare the subscription with the price of a small server and forget that you are supplying the rest of the service yourself.

But maybe you are willing to pay that price because you want sovereignty. Okay, where is the machine running? If it’s on a cloud provider, you are still depending on a company that can interrupt your access to the infrastructure. If you lose that account, where are your backups? Hopefully not exclusively inside the same account. Can you rent another machine and restore the service? Do you have the configuration, the messages, and access to the domain? Will the replacement server be able to deliver mail successfully? There is a recovery process here, and owning the installation doesn’t mean you have prepared for it.

You could put the computer in your house. Now you are depending on your electricity, internet connection, hardware, and the physical security of the house. For a lot of ordinary uses this may be fine. But if you are an investigative journalist concerned about authorities in the country you live in, bringing the server into your basement could be a curious interpretation of protecting it. The people you are worried about may now be able to reach the computer more easily. Hosting it somewhere else introduces another jurisdiction, another provider, and another set of relationships to consider. We started with an email address and have arrived at a small foreign policy exercise.

This is where it helps to ask what we actually want to remain in control of. If you want to keep your address when a provider stops working for you, a domain you control gives you a way to move the mailbox elsewhere. If you want to retain your old messages, you can keep independent copies in a form you can use again. The migration will still take work, and you are still depending on the domain registration, but you have made the email provider replaceable. That gives you a meaningful amount of power without operating the servers yourself.

A personal domain also shows how these requirements can disagree with one another. You might want people to recognize the same address for twenty years. Or you might want to make it difficult to connect an address to your identity. Registration, payment, and how you use the domain can create connections that matter in the second case. Maintaining an identity and concealing one are different problems, even though both can appear in a conversation about sovereignty. A single hosting recommendation is unlikely to resolve them together.

Then there is privacy over the contents. Suppose you run your own server and send an ordinary email to someone using Gmail. Google’s system still receives that message. This doesn’t mean your choice was pointless; receiving that conversation is different from hosting your entire mailbox. But it does mean the person on the other side is part of the privacy arrangement. You cannot decide where all the readable copies exist by moving your own copy to a computer you operate.

If you want only the participants to be able to read a conversation, you need encryption that extends between those participants. Encrypting a disk helps with a different problem from encrypting a network connection, and neither alone establishes that the services handling the message cannot read it. Eventually you have to ask who has the keys, how we exchange them, and where the messages become readable. Then you arrive at the laptop in front of you. What happens if someone gets access to it while the messages are available? What happens if you lose it and it contains your only usable key? Keeping a recovery copy helps with the second problem, but now you have another thing to protect.

Search is part of this too. You don’t keep years of email because you want to open every message one by one until you find an attachment. You remember half a sentence, or the person, or approximately when something happened, and you expect the software to help you. If the server cannot read the contents, search has to work within that constraint. We could download the messages and build an index on the device. Now we need storage, synchronization across devices, protection for that index, and a way to rebuild it after losing the computer. These are engineering problems we can work on, but they belong in the experience we are promising people. Wanting privacy doesn’t make finding an old train ticket optional.

An email interface with the kind of conversational privacy people expect from Signal could be useful. Long messages, asynchronous replies, attachments, and a searchable archive are all things you want to keep. But the moment we want to communicate with ordinary email, we have to decide what happens to the protection at that boundary. Does the other person need compatible software? Do they read the message through a separate interface? Or do we send something with weaker protection? Whichever arrangement we choose, people should understand what happened. Making it look like email doesn’t make that decision disappear.

Part of what makes email valuable is that you can write to someone without asking them to join your service first. That reach depends on dealing with systems whose behavior you don’t control. Self-hosting gives you more choices about your end, but it doesn’t remove the relationship. This brings us back to the original question: operating the infrastructure and getting the protection you want are related, but you still have to explain how one produces the other.

You might self-host email because you want to understand it, or because you have some particular requirement that makes the work worthwhile. As a general route to sovereignty, the case is less convincing. You would first want a recoverable archive, a way to replace the provider, and a clear understanding of who can read the conversations you care about. Some of that may involve a domain, some may involve encryption, and some conversations may be better served by another tool. After working through those requirements, you might still want your own mail server. At least then you would know what you are maintaining it for.