--- title: Reinventing electronic mail ... 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. Good aspects ----------------------------------------------------------------------------- * Ubiquitous. Approximately everyone on the Internet has email, or can get it. * Anyone can email anyone. This lowers barriers for communication, globally. It's especially important for free and open source projects, but also to allow people all over the world to easily self-organise to build a better world in general. * Distributed: sender and recipient don't need to use the same server. * Standardised, with many (many!) inter-operable implementations. * Supports off-line use. Not everyone can, or wants to, be online all the time. Problems with the existing email system ----------------------------------------------------------------------------- * Spam. Worse, anti-spamming measures drive centralisation, and are still ineffective, especially for those not using the huge providers. End result: you either sacrifice privacy or you get tons of spam. - This is a result of the desirable feature that anyone can email anyone, combined with the fact that sending an email costs approximately nothing, and that sending a million email also costs approximately nothing, and aggravated by the fact that spamming has de facto no real financial or legal repercussions. * Scam. There is no widely used method to digitally sign email, and thus criminals can easily fake messages to look like they come from, say, Amazon, Netflix, Paypal, or other companies the recipient is likely to use. Everyone needs to be constantly on their toes to avoid mistakes. - There are standards for digitally signed email, but * Becoming centralised to a few huge providers. This is bad for privacy and can be catastrophic for security. If one of the big providers gets breached, up to hundreds of millions of people's communications are at risk. - We're moving towards a future where if you host email yourself, you're suspicious. It's already the case that it can be difficult for a self-hosted email server to reach people on Gmail. * No real privacy, even if you self-host. Email is by default in clear text, and while there are standards for encryption, they are not widely used, and tend to also leave metadata (headers) unencrypted. * HTML email is not well standardised, and is a security and privacy risk. Different email clients implement HTML in different ways, and the web standards are not followed very closely. - Worse, there's an assumption that HTML emails can embed images from the Internet, which results in more security problems (images are complicated data provided by a potential attacker, and just viewing them is a security risk), and privacy issues (the image hoster will be notified when you view the email, see tracking pixels). There are moves to restrict this, but the problems have been known since soon after HTML email was introduced, and at least some of the problems still exist. * Attachments fill disks. Email is commonly used to share files, because it's easy and ubiquitous, even if it's not very good at it. There are services that make this better, but they are mostly proprietary, and require extra effort. * There is no good support for group discussions. Massive dumps of forwarded discussions are commonplace in most large organisations. Mailing list managers exist, but they tend to be clunky, and tend to not be great for having discussions among large groups of people. They're better at sending out announcements and newsletters. * The technologies and standards for email are getting ridiculously complicated. Email was originally designed for relatively short messages in English only. To support non-English languages in a backwards compatible manner, email has gained whole extended families of ways to encode text and data: uuencode, base64, quoted-printable, and header encoding, to start with. The email tech stack is getting so hard to understand that it's difficult to even use, never mind implement correctly. Never mind that the complexity results in more effort to operate and keep secure the servers. Possible solutions ============================================================================= This document tries to outline a possible solution to all the problems above. Overview ----------------------------------------------------------------------------- The shape of a possible solution might be something like this: * everyone has any number of "email identities", which are roughly like email addresses; it's easy to create new identities, and to optionally link them together; each identity has cryptographic keys for encryption and digital signatures * all email is encrypted to the recipient(s), and signed by the sending identity 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: * anyone can send email to anyone * sending any amount of email is basically free of cost * there are no real consequences from sending unwanted email, except for the sender's reputation What we want from the solution: * anyone can send email to anyone who wants to receive it * sending email should be basically free of cost, if the recipient wants it * sending email without prior arrangement does not need to be free of cost A possible solution might be a kind of digital stamps. * Alice can give Bob a stamp to allow Bob to send email to Alice * Alice can give her friends permission to give out stamps on her behalf, to allow friends to introduce new people to Alice - as a variation, Alice might give permission to her employer to give out stamps on her behalf to co-workers * If Bob doesn't have a stamp, but still wants to reach Alice, his email software can ask Alice's server for one, and this can be made "costly" in some way so that it's hard for spammers to automate When Bob sends an email to Alice, the email will come with a stamp to allow Alice's response to reach Bob. 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: * might be used any number of times, or only once * might be valid indefinitely, or only for a specific time span * might be valid for any sender, or only for a specific sender, or require specific keywords in the email, or have other filtering rules * might not allow sending an email, but instead might delegate the power to issue stamps to someone else; the delegation might constrain the kind of stamps the delegate can issue * might be cancelled by its issuer at any time 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. 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. * stamp issuing might be rate limited - per server, or per group of collaborating server; possibly a group based on the social graph of the issuer * the requester might need to do some work to raise the cost of stamps: solve a cryptographic puzzle, or do some similar task; this would be easy enough that it's not expensive enough if it happens occasionally, but enough that it stops spammers from doing it en masse 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). 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: * one or more names * for each name, zero or more certificates from other identities * zero or more other identities for the same person (optional) - FIXME: give rationale for this * one or more public key pairs for encryption, certificates, authentication Each message is signed by at least one certification key of the sender, and encrypted with every public key of every recipient. 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. FIXME ============================================================================= All of this needs to be thought about. Routing messages ----------------------------------------------------------------------------- FIXME: this needs to be solved in some way. The SSB approach probably doesn't scale. Message format ---------------------------------------------------------------------------- FIXME: this needs to be sketched. For now, assume something that's roughly on par with RFC2822, but with simplicity. Possibly JSON. Group discussions, mailing lists, signing up for services ------------------------------------------------------------------ FIXME: this needs to be sketched. Withdrawing or removing sent messages ----------------------------------------------------------------------------- Remove sent messages? At least to groups? 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? 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. 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. SEE ALSO ============================================================================= Links to more information, sources, etc. * Preventing spam on the Fediverse. Serge Wroclawski. Suggests stamps. Idea via Christopher Lemmer Webber from Taler, and it might not have originated there. - - * Hashcash is a system where the sender proves they do some work before the recipient accepts a message. - http://hashcash.org/