Introduction
This document describes the design of an improved email system. The goal is to create a simple yet secure email system which does not suffer from the many problems of the current email system.
This is a work in progress as I figure out the issues involved in designing an improved email system.
Motivation
The current email system is horribly broken. It is based on a bunch of design decisions which made sense 50 years ago, but which really don't work today.
Problem 1: The email system does not verify senders. It is easy to forge sender addresses. It is impossible to verify with certainty that the sender is real. This made sense back when everyone on the email system knew each other an a small amount of social pressure was all that was needed to stop anti-social behavior. Because there is no way to verify a sender many anti-social behaviors are common over email, the worst being:
SPAM: The email system is overloaded with unsolicited, low quality marketing messages.
PHISHING: Criminals and pranksters impersonate trusted institutions in order to defraud people.
Problem 2: The email system routes messages unencrypted. Generally the user does not even have control over which systems the email is routed over. Messages can be scanned by anyone at the routing nodes. There is evidence that this had resulted in both government and corporate projects to filter and read private email communications. While encryption methods exist they require that both the sender and the recipient install the same encryption software ( like PGP ) and manually exchange keys ahead of time. Since you cannot rely on remote parties having the encryption software, this solution is not practical.
Problem 3: Since email is routed over a number of email relays, it is possible for any relay to reject, delete or modify a message. These isn't even a guarantee that either the sender or recipient will be notified of the changes. For example many relay will routinely reject or destroy messages which are too large. Some servers will remove attachments which they believe may be dangerous ( such as .zip or .exe files ). There is evidence that some ISP's delete messages which mention competitors products and services or which are critical of the ISP.
Problem 4: There is no way for a user to refuse to receive email messages from a certain party. If you subscribe to an email list, you cannot unsubscribe yourself. Instead you must send a request for the sender to unsubscribe you. They may be unable or unwilling to do so. The user is left with only the option of deleting those messages as they are received - based on the name of the sender or the content. Further, once you give your email address to another party, it may get circulated by them to others who you do not wish to communicate with. The user is forced to filter messages from these other parties as they come in. Users should be able to give out temporary email addresses or email addresses which specify a 'channel' so that the user is in full control of the channel and can close a 'poisoned' channel at any time.
Problem 5: It is difficult for users to set up their own email server. Email servers require that users create an MX record, and have access to the network of email relay servers. Setting this up is too complex for most users. Yet anyone can set up an instant message or voip client that both sends and receives messages. It should be just as easy to set up an email server.
Design Goals
1. User controls who may contact him.
a. It should be easy for the user to limit who may contact him.
b. Allows the user to set contact policy from full open, to allowing only contact from a whitelist. Or where the sender may opt to receive the message only after the sender solves a computationally expensive problem.
2. Trivial for user to create limited time email addresses, or to shut down any email address which is being abused.
3. No routing. All email is delivered directly from the sender to the email server.
4. Trivial for the user to set up their own email server if they desire.
5. Email transmitted encrypted by default. Either sender or server should be able to require an encrypted channel.
6. Impossible for the sender to forge their address.
7. Interoperability with legacy email system. Should be possible to install a client as a plugin for modern email viewers like thuderbird.
Goal 7: Interoperability with legacy email.
The SSES email addres is of the following form:
name+channel!@domain name!@domain
The nice thing about these email addresses is that they will be accepted by the legacy email system.
Here is a matrix of how messages get passed depending on the availability of SSES at the source and destination of the message:
Sender has SSES:
Recipient has SSES:
Sender parses recipient's address to see if it is a SSES address. It is, so the message is sent over the SSES email system. Sender uses a SSES reply address. All SSES features available.
Recipient has no SSES:
Sender parses recipient's address to see if it is a SSES address. It is not a SSES address so the message is sent over legacy email system. If the sender has configured their legacy email server to accept SSES addresses over the legacy email system, then the sender may enter a SSES reply address. If not sender uses a legacy reply address.
If the sender has a legacy email address, but the recipient actually has SSES, then in the reply from the recipient may contain a SSES reply address and further communication can be over the SSES channel.
Sender has no SSES, but has a SSES reply address:
It doesn't matter if recipient has SSES or not. If the recipient's legacy email server supports SSES addresses the email will transmitted. If not the message will bounce.
Sender has no SSES, and has a non-SSES reply address:
It doesn't matter if recipient has SSES or not. The message will be transmitted over the legacy email system.
A SSES user receiving email over the legacy email system will still have to deal with spam. They will need to put heavy handed restrictions on this insecure channel. Perhaps requiring the sender to verify their address. The verification message may indicate the availability of the SSES channel.
Interoperatbility with current email clients. The SSES client would be a plugin for an email client like thunderbird that would send and receive messages using the SSES protocol. Further, the SSES email server would be have a POP port for downloading email. So in a simple implementation the client does not need to support SSES for getting email, just sending it. Its not clear that we would ever need to have a separate SSES protocol for downloading email from the SSES server.
Goal 1: Abuse and Control:
User gives out SSES address.
Spammers try to send spam through the legacy channel. They can't send it because it requires address confirmation.
Spammers try to send spam through the SSES channel. Their address cannot be forged, and is identified from a global spam black list, or from the users black list. Mail is deleted.
Spammers create a new identity for each mailing. New contacts require solving a computationally expensive problem. Cost of spamming becomes too high. User sets the computational threshold, so as computers become more powerful user can raise the initial contact threshold.
User gives out SSES address with channel
For example user registers for a service with a channelized address. Initially contacts from that address are desired, but eventually the user decides to stop receiving the messages. This may be due to abuse by the sender, or simply a time limited channel.
Sender tries to use a non-channel address. Sender will be required to go through the initial contact process.
Or the user may opt to black list any address from which it receives a channelized message. This way once the user has assigned a sender to a channel that sender must use the channel or the message will be rejected.
User gives out a SSES address without channel but wishes to channelize after initial contact
User can do this. Say a source contacts the user from the main public SSES address. User decides to continue contact, and assigns the sender a channel. A SSES message is sent from the user to the original sender assigning the channel. Subsequent contacts will be rejected unless they are on the approved channel.