Re-thinking electronic mail

Lars Wirzenius

2021-10-25 07:36

1 Introduction

I am tired of the existing Internet email system, both as a sender of email, as a recipient, and as an operator of an email server.

There’s rampant spam, scam, and attempts at solving those help making the email system more centralized ways. This essay is about sketching what a good email system would look like, if it were re-designed from scratch, using everything we’ve learned over the decades, and without having to use any part of the existing system.

As an anecdote, I am currently not on any active email discussion lists, or groups, or subscribed to newsletters. I have a few separate email addresses that I give to online shops as contact information. My main address has been used for free and open source software contribution for many years.

I get less than five valid emails a day, usually from friends. Also, a small number of valid notification emails from automated systems. I get on the order of 400 spam and scam emails a day. They vary greatly in how targeted they are. They are all unsolicited and unwelcome. Unfortunately, despite honing my email filters for decades now, sometimes a valid email from a new sender ends up being filtered as spam, and I’m at risk of missing it.

Sometimes those emails are important, such as questions about some of my contributions, or notifications from a purchase I’ve made. If I didn’t skim my spam folder manually I would’ve missed the email about some of my software being used in Africa to provide local people with useful SMS services that would’ve been financially impossible with proprietary software.

There are good aspects the existing Internet email has that are still valuable enough that I continue to use it. I am, however, getting closert o the point that I’d like to make things radically better.

This essay collects my thoughts about email and what a replacement system might look like. I am not in a position to build the new system in my free time, but I can at least try to inspire more people to think about this and maybe the discussion will end up with something good.

1.1 Good aspects to keep

I find the following aspects of the current email system good and valuable and would like a new system to retain them.

1.2 Problems with the existing email system

2 The spam and scam problem

There are a large number of problems. Rather than attacking all of them at once, let’s consider them one at a time, and let’s start with the most obvious problem: spam. As a side effect, the solution proposed below should also solve the scam problem.

2.1 Problem statement

The spam problem can be stated as follows:

Anyone can send email to anyone else. There is practically no cost to the sender for sending many emails. It’s difficult for the recipients to filter unwanted mail away automatically, because it would require the computer to understand human communication as well as humans.

The scam problem can be stated as follows:

Anyone can send email that looks like it comes from someone else, at least sufficiently well that an unobservant recipient is fooled. This can be used to con the recipient to click a link in the email that leads to a fake web shop, for example, or a site that attacks the recipient with malware.

2.2 Overview of solution

The idea for stamps comes to me from (Wroclawski 2019), who seems to have gotten it from Christopher Lemmer Webber and Taler, and who knows where it originated from.

(Godin 2020) also discusses his idea of paid stamps for email, originally from late 1980s or early 1990s, with the idea that low volumes are free, but after that you pay a “penny” per email. I’m not really happy with the exact solution suggested, as it doesn’t provide the recipient from a way to avoid unsolicited junk from arriving, but the podcast is part of a discussion.

2.3 Digital identities

In this approach, each email user can have as many email identities as they want, and each identity is represented by a key pair for public key cryptography. The identities are not necessarily linked, just like personal and work email addresses are not linked. However, they may be linked, so that for example an identity used for open source contributions may be linked to an identity used for publishing poetry or for contributing to Wikipedia.

The key pair, consisting of a public and a private key, is used to identify the email account and messages from the account. Every message sent using an identity is signed with the key for that identity.

This means misrepresenting the sender becomes much harder, reducing the possibility for scam.

Each identity (key pair) can have metadata associated with it, such as a name. There can be digital signatures for the metadata for certifying it, to avoid miscreants faking identities by creating new keys and associating someone else’s name on them. With the metadata signatures, the recipient’s email software can at least attempt to verify correctness of the metadata.

Alternatively, names are handled only on the recipient’s side. If I get a message from you, and I’m sure it’s from you, I can tell my email address book that the key you used to sign the message should have your name. If a miscreant creates a new key, my email software won’t say it’s from you, and the miscreant has to convince me that it’s you. (This needs further thought.)

2.4 Digital signatures

For the purposes of this discussion, assume a way to digitally sign messages that covers the whole message, including its metadata. The details of how that is achieved do not matter: digital signatures have well-known, good solutions and since we are talking about a new system, we don’t have to be compatible with the problems of the existing email system.

For this discussion, assume each message can be securely verified as having been sent by its sender identity. If a message claims to be from an identity, but its signature can’t be verified, the message is rejected by the recipient’s email software.

2.5 On encryption

To solve the problem of surveillance, email encryption is going to be needed. The simple solution is to always encrypt everything.

2.6 Digital stamps

A digital stamp is a digital token issued by a recipient which gives a sender the capability to send one or more messages to the recipient.

A digital stamp is more powerful than a physical, paper stamp. Paper stamps can be transferred (sold, given) without limit. A digital stamp, however, allows more features:

As an extra twist, digital stamps may also be an authorization to someone else to issue stamps on your behalf. Rather than the stamp allowing them to send you an email, it lets them create a stamp that lets a third party send you an email. Your email software can put any and all the constraints it puts on stamps you issue directly on the delegation.

For example, if you and Alfred have a mutual friend, Bruce, you can give Bruce a stamp that authorizes Bruce to issue single-use stamps to other identities. If Bruce thinks you and Alfred should know each other, Bruce can issue Alfred a stamp that lets Alfred send you a single email. If you like Alfred, you can issue further stamps to Alfred.

An employer runs their own email server, and that server determines which stamps it accepts. This lets an employer issue stamps on behalf of each of their employees.

2.7 Receiving email from strangers

In some cases it’s important to be able to receive email from strangers. A stranger here is someone to whom you’ve not given given a digital stamp. Some examples of when this might be important:

Some of these cases can be handled by not using email: bug reports can go into a web-based ticketing system; customers can get a single-use stamp whenever they pay their invoice; etc. However, there will always be cases when you want email from people to whom you’ve not yet given a stamp.

A mail server can, optionally, have a feature where it gives anyone a single-use stamp tied to a specific sender identity. Unfortunately, this could easily be abused by spammers: they’ll automate the step of requesting a stamp before sending the email. To counter that, the mail server can impose conditions on giving out stamps:

The issuing of stamps to strangers is optional, and is meant to be an interactive process. There doesn’t need to be a standard way to do that, or even an enumerated set of standard ways. Each mail server, even each recipient, can invent their own. Flexibility here is important, as spammers will evolve ways to circumvent any common methods.

3 Identities and mail delivery

In the existing email system, your email address is your identity. The address basically specifies where to deliver email meant for you. If you change email providers, the address changes. This makes no sense: you’re you even if you switch Google’s mail service to Microsoft’s.

There are workarounds for this. One can set up automatic forwarding of incoming email from the old address to the new one. One can arrange to have one’s own domain name, and arrange with one’s email provider to use that in the email address, instead of the provider’s domain. These workarounds work, but they add friction and cost.

A better way would be to separate the concepts: keep identity separate from address, as a fundamental building block of the email system. Here’s my thinking:

3.1 Confidentiality and authenticity

Each identity will have an encryption key, for public key cryptography. All emails sent using that identity are digitally signed using the key: this allows others to verify that an email actually comes from a specific person, and that the mail hasn’t been altered along the way.

All email is also encrypted as well as signed. Everything that can be encrypted, will be encrypted. This includes all message metadata (“headers” in the current system). If mail drops or stores need to add metadata, they’ll attach another encrypted part to the message.

All communication between mail clients, stores, and drops are encrypted (a la HTTPS), and may occur over the Tor network. All server components may be provided as Tor onion services, if the server operator so chooses.

4 Implementation thoughts

While I’m not going to be spending my free time to implement this, I can’t help having thoughts about how it would be done. Here is a loose collection of some of them.

5 What next?

Do you think the solution proposed in this essay for spam and scam will help? If not, why not? Can you see a way for a miscreant to circumvent the proposed solution to get their unwanted message delivered to the recipient?

Let me know, preferably via the legacy email system, as a response to this fediverse thread, or using the GitLab issue system. If you want to propose improvements to the essay, feel free to file a merge request or send patches.

6 Other proposals to improve email

There have been a very large number of proposals to improve email over the years. This is an incomplete list of them.

(Bernstein 2000) proposed “Internet Mail 2000” where the central idea is that the sender stores the email, not the recipient. I’m not sure how this would solve the spam problem. (Siebenmann 2020) has an excellent critique of the proposal.

References

Back, Adam. 2002. “Hashcash - a Denial of Service Counter-Measure.”

Bernstein, Daniel J. 2000. “Internet Mail 2000.” https://cr.yp.to/im2000.html.

Godin, Seth. 2020. “Paying for Stamps.” https://overcast.fm/+L0YXXVXfY.

Siebenmann, Chris. 2020. “Daniel J. Bernstein’s Im2000 Email Proposal Is Not a Good Idea.” https://utcc.utoronto.ca/~cks/space/blog/tech/IM2000NotGoodIdea.

Wroclawski, Serge. 2019. “Preventing Spam on the Fediverse.” https://github.com/emacsen/rwot9-prague/blob/ap-unwanted-messages/topics-and-advance-readings/ap-unwanted-messages.md#postage.