Reinventing electronic mail

2020-04-02 08:28

1 Introduction

I am fed up with the existing Internet email system. There’s spam, and the email system is getting centralised in all sorts of bad ways. This idea is about sketching what a good email system would look like, if it were re-designed from scratch, using everything we’ve learnt over the decades, and not necessarily using any part of the existing system.

1.1 Good aspects

1.2 Problems with the existing email system

2 Possible solutions

This document tries to outline a possible solution to all the problems above.

2.1 Overview

The shape of a possible solution might be something like this:

2.2 Spam

Spam, or unsolicited bulk email, is probably the first problem to solve, as the solution will likely constrain other aspects of the system.

The reason current email has a spam problem is three-fold:

What we want from the solution:

A possible solution might be a kind of digital stamps.

When Bob sends an email to Alice, the email will come with a stamp to allow Alice’s response to reach Bob.

2.3 Stamps

Digital stamps are not exactly like paper stamps. Paper stamps cost money, and can only be used once. A digital stamp can be more versatile:

Stamps can be created manually via the mail user interface, automatically when sending email, or when joining a mailing list or signing up for a service.

The format of stamps is open, for now. However, they should probably be compact enough that they can easily be communicated manually. QR codes might be useful.

2.4 Generating stamps to reach someone else

Each email server can issue stamps for an identity hosted on the server, if the identity has delegated the server that power. This would probably be a web service provided by the server to someone requesting a stamp.

2.5 Signing up for newsletters and services

Currently, the operator of a newsletter can add any email addresses to their mailing list. It’s more of a convention than a technical requirement that the recipient must confirm they want the newsletter. This is abused often by the less scrupulous operators.

With the stamp model, the recipient would create a stamp (possibly single-use, or limited to a time period) and provide it to the operator to be added to the mailing list. The recipient can get off the mailing list by cancelling the stamp. The mailing list doesn’t need to even have an unsubscription feature. Without a valid stamp, the newsletter doesn’t reach the recipient. Rejecting a stampless message can be made cheap enough that it’s not a problem.

Likewise, when using a service (buying tickets to an event? flights? stuff from an online shop?) that may need to send a message, the customer would provide the service with a stamp for such information messages. Such a stamp might be time-limited, and might delegate the power to, say, issue additional stamps to a third party necessary for providing the service (e.g., Amazon might issue stamps to the courier to let them reach the customer).

2.6 Email identities

An email identity is not an address. Email addresses are tied to locations (servers, domains). This makes it difficult to move one’s email to another location.

An identity in the new system is a large randomly generated number (UUID4). Routing messages is an unsolved problem.

Each user can have any number of identities they like.

To an identity some metadata is attached:

Each message is signed by at least one certification key of the sender, and encrypted with every public key of every recipient.

2.7 Names

All names attached to an identity are decided by the identity’s owner. Others can certify that they believe the identity and name belong together. This is similar to the Secure Scuttlebutt pet name system.


All of this needs to be thought about.

3.1 Routing messages

FIXME: this needs to be solved in some way. The SSB approach probably doesn’t scale.

3.2 Message format

FIXME: this needs to be sketched. For now, assume something that’s roughly on par with RFC2822, but with simplicity. Possibly JSON.

3.3 Group discussions, mailing lists, signing up for services

FIXME: this needs to be sketched.

3.4 Withdrawing or removing sent messages

Remove sent messages? At least to groups?

3.5 Encryption

Allow rotation of keys. Allow multiple keys per identity, at least one per device. Allow future versions to change encryption algos etc.

Perfect forward security?

Revoke sent message?

3.6 Mobile as a first class citizen

About half the people using the Internet now are using mobile only. A new email system should take that into account.

That said, desktop/laptop computers are still hugely important and can’t be neglected.

Ideally it would be easy to implement the client software in any platform, to allow maximum diversity.

3.7 Specifications, conformance

All aspects of protocols and messages should be specified in sufficient detail and clarity to allow independent, inter-operable implementations. There should probably be a common test suite for conformance, and some dedicated interoperability testing.


Links to more information, sources, etc.