Add: first sketch of a new email system

1 files changed, 332 insertions, 0 deletions

diff --git a/email2.md b/email2.md
new file mode 100644
index 0000000..56759f2
--- /dev/null
+++ b/email2.md
@@ -0,0 +1,332 @@
+---
+title: Reinventing electronic mail
+...
+
+Introduction
+=============================================================================
+
+I am fed up with Internet email. 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.
+
+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.
+