path: root/email2.md

---
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 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 issued (the image
    hoster will be notified when you view the email, see tracking
    pixels).

    There's 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 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
  encryption and digial 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
* there is 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, if the receipient wants it
* sending email without prior arrangement does not need to be free

A possible solution might be a kind of digtial 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 it's 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 requestor 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 receipient 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
rougly 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 interoperatibility 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.
  - <https://github.com/emacsen/rwot9-prague/blob/ap-unwanted-messages/topics-and-advance-readings/ap-unwanted-messages.md#postage>
  - <https://podbay.fm/podcast/252333772/e/1503662400>

* Hashcash is a system where the sender proves they do some work
  before the recipient accepts a message.
  - http://hashcash.org/