summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLars Wirzenius <liw@liw.fi>2021-10-25 07:33:27 +0000
committerLars Wirzenius <liw@liw.fi>2021-10-25 07:33:27 +0000
commitef17fc6ae2eb112c4b07fe33fca76f21f82bb352 (patch)
tree871aebde5fe9240383c805b4e38d3f0c3e417754
parentf5bffa94328b71cc2bad9c3ee22c15c9826b612a (diff)
parent374111aadffb125e9dfba7803e400af8d699e911 (diff)
downloadideas-ef17fc6ae2eb112c4b07fe33fca76f21f82bb352.tar.gz
Merge branch 'email' into 'main'
add thoughts on identities, routing, signing, encryption See merge request larswirzenius/ideas!12
-rw-r--r--rethinking-email.md232
1 files changed, 172 insertions, 60 deletions
diff --git a/rethinking-email.md b/rethinking-email.md
index e274a69..db4e521 100644
--- a/rethinking-email.md
+++ b/rethinking-email.md
@@ -1,41 +1,61 @@
+---
+title: "Re-thinking electronic mail"
+author: Lars Wirzenius
+abstract: |
+ There are many problems with the existing Internet email system,
+ such as spam, scam, surveillance, insecurity, centralization, and
+ complexity. The problems are starting to outweigh
+ the benefits of the system. Fixing the problems by evolving the
+ current system seems overwhelmingly difficult. This essay examines
+ some solutions to the problems on the assumption that a completely
+ new, parallel email system can be built.
+
+ This is not a proposal for a new system, but an exploration of the
+ solution space, meant to provoke constructive discussion.
+bibliography: email.bib
+...
+
# Introduction
I am tired of the existing Internet email system, both as a sender of
email, as a recipient, and as an operator of an email server.
-There's spam, scam, and the email system is getting centralized in all
-sorts of bad ways. This essay is about sketching what a good email
-system would look like, if it were re-designed from scratch, using
-everything we've learned over the decades, and not necessarily using any
-part of the existing system.
-
-As an anecdote, I am currently not on any active email discussion lists,
-or groups, or subscribed to newsletters. I have a separate email address
-that I give to online shops as contact information. My main address has
-been used for free and open source software contribution for many years.
-
-I get less than two valid emails a day, usually from friends. Also, a
-small number of notification emails from my own automated systems. I get
-on the order of 400 spam and scam emails a day. They vary greatly in how
-targeted they are. They are all unsolicited and unwelcome.
+There's rampant spam, scam, and attempts at solving those help making
+the email system more centralized ways. This essay is about sketching
+what a good email system would look like, if it were re-designed from
+scratch, using everything we've learned over the decades, and without
+having to use any part of the existing system.
+
+As an anecdote, I am currently not on any active email discussion
+lists, or groups, or subscribed to newsletters. I have a few separate
+email addresses that I give to online shops as contact information. My
+main address has been used for free and open source software
+contribution for many years.
+
+I get less than five valid emails a day, usually from friends. Also, a
+small number of valid notification emails from automated systems. I
+get on the order of 400 spam and scam emails a day. They vary greatly
+in how targeted they are. They are all unsolicited and unwelcome.
Unfortunately, despite honing my email filters for decades now,
sometimes a valid email from a new sender ends up being filtered as
spam, and I'm at risk of missing it.
-Sometimes those emails are important, such as questions about some of my
-contributions. If I didn't skim my spam folder manually I would've
-missed the email about some of my software being used in Africa to
-provide local people with useful SMS services that would've been
-financially impossible with proprietary software.
+Sometimes those emails are important, such as questions about some of
+my contributions, or notifications from a purchase I've made. If I
+didn't skim my spam folder manually I would've missed the email about
+some of my software being used in Africa to provide local people with
+useful SMS services that would've been financially impossible with
+proprietary software.
There are good aspects the existing Internet email has that are still
-valuable enough that I continue to use it. I am, however, getting closer
-to the point that I'd like to make things radically better.
+valuable enough that I continue to use it. I am, however, getting closert
+o the point that I'd like to make things radically better.
This essay collects my thoughts about email and what a replacement
-system might look like. I am not in a position to build the new system,
-but I can at least try to inspire more people to think about this and
-maybe the discussion will end up with something good.
+system might look like. I am not in a position to build the new system
+in my free time, but I can at least try to inspire more people to
+think about this and maybe the discussion will end up with something
+good.
## Good aspects to keep
@@ -44,7 +64,7 @@ I find the following aspects of the current email system good and
valuable and would like a new system to retain them.
* Ubiquitous. Approximately everyone on the Internet has email, or can
- get it.
+ get it. Any replacement should be easy for anyone to start using.
* Anyone can email anyone. This lowers barriers for communication,
globally. It's especially important for free and open source software
@@ -91,9 +111,10 @@ valuable and would like a new system to retain them.
providers gets breached, up to hundreds of millions of people's
communications are at risk.
- - We're moving towards a future where hosting email yourself makes you
- suspicious. It's already the case that it can be difficult for a
- self-hosted email server to reach people on Gmail.
+ - We're moving towards a future where hosting email yourself makes
+ you suspicious. It's already the case that it is difficult for a
+ self-hosted email server to reach people on Gmail. Also, the rules
+ keep changing.
- Worse, all the big email service providers have track records of
closing people's accounts with no warning. Sometimes this happens by
@@ -163,10 +184,11 @@ below should also solve the scam problem.
The spam problem can be stated as follows:
-> Anyone can send email to anyone else. There is practically no cost to
-> sending many emails. It's difficult for the recipients to filter
-> unwanted mail away automatically, because it would require the
-> computer to understand human communication as well as humans.
+> Anyone can send email to anyone else. There is practically no cost
+> to the sender for sending many emails. It's difficult for the
+> recipients to filter unwanted mail away automatically, because it
+> would require the computer to understand human communication as well
+> as humans.
The scam problem can be stated as follows:
@@ -190,7 +212,7 @@ The scam problem can be stated as follows:
The idea for stamps comes to me from [@fedispam], who seems to have
gotten it from Christopher Lemmer Webber and Taler, and who knows where
-it originated from.
+it originated from.
[@godinstamps] also discusses his idea of paid stamps for email,
originally from late 1980s or early 1990s, with the idea that low
@@ -203,9 +225,12 @@ the podcast is part of a discussion.
## Digital identities
In this approach, each email user can have as many email identities as
-they want, and each identity is represented by a key pair for public key
-cryptography. The identities are not necessarily linked, just like
-personal and work email addresses are not linked.
+they want, and each identity is represented by a key pair for public
+key cryptography. The identities are not necessarily linked, just like
+personal and work email addresses are not linked. However, they may be
+linked, so that for example an identity used for open source
+contributions may be linked to an identity used for publishing poetry
+or for contributing to Wikipedia.
The key pair, consisting of a public and a private key, is used to
identify the email account and messages from the account. Every message
@@ -247,9 +272,7 @@ rejected by the recipient's email software.
## On encryption
To solve the problem of surveillance, email encryption is going to be
-needed. However, it doesn't seem to be necessary for solving the spam
-and scam problem, so it's not discussed, for now. A future version of
-this essay may address that.
+needed. The simple solution is to always encrypt everything.
## Digital stamps
@@ -266,7 +289,7 @@ however, allows more features:
* digital stamps can have a complicated validity time: perhaps
they're only valid for three months? or only on Mondays? or only
- during office hours?
+ during office hours? It's up to the recipient to decide.
* digital stamps may be indefinitely usable, or single-use: you might
give someone new a stamp they can use only once, and if you don't give
@@ -340,7 +363,7 @@ server can impose conditions on giving out stamps:
* The server might require the sender to write a short sentence of why
they want to reach the recipient. If that contains keywords chosen
by the recipient, the server issues the stamp.
-
+
* The server might require some sort of [proof of work][]. This can be
cheap enough that it doesn't matter for rare occasions, but
expensive enough that a spammer would need to expend so much
@@ -363,6 +386,112 @@ important, as spammers will evolve ways to circumvent any common
methods.
+# Identities and mail delivery
+
+In the existing email system, your email _address_ is your identity.
+The address basically specifies where to deliver email meant for you.
+If you change email providers, the address changes. This makes no
+sense: you're you even if you switch Google's mail service to
+Microsoft's.
+
+There are workarounds for this. One can set up automatic forwarding of
+incoming email from the old address to the new one. One can arrange to
+have one's own domain name, and arrange with one's email provider to
+use that in the email address, instead of the provider's domain. These
+workarounds work, but they add friction and cost.
+
+A better way would be to separate the concepts: keep identity separate
+from address, as a fundamental building block of the email system.
+Here's my thinking:
+
+* You, the person, can have any number of _identities_. You can keep
+ your work persona separate from your school persona. You can further
+ separate you as a spouse and a family member from your public
+ persona as an open source developer, blogger, and so on. This is
+ similar to having many email addresses, but it can be made to be a
+ normal thing, and not involve any hassle.
+
+ An identity is a random string, but it can have a number of
+ attributes intended for people: names, photos, links to web pages,
+ etc. The attributes are meant to help other people understand whose
+ identity it is, and what role or aspect of that person the identity
+ reflects. Attributes may carry certifications from others, and your
+ email client will make it obvious if an attribute is certified by
+ someone you trust or not.
+
+* Each of your identities uses an _mail store_, which is where all the
+ email for that identity is stored. The mail store may be on your
+ computer, perhaps as part of your mail client, or it may be on a
+ server somewhere. You may run the store yourself, or someone may run
+ it for you, based on an agreement between you and them. The mail
+ store has an address, and it can do things on your behalf,
+ automatically, such as issue stamps, or forward the mail to one or
+ more recipients.
+
+* When email is sent, it's sent to an _mail drop_. The drop may be
+ part of the same server where the store is, or it can be a separate
+ server. The drop will accept emails based on stamps: a stamp will
+ include an authorization to use that drop for a the intended
+ recipient. You need to arrange with a drop that it accepts mail for
+ you, and this gives you the authorization to include in your stamp.
+ The arrangement also includes telling the drop what to do with an
+ email it has accepted: how and whom to notify of its arrival. It
+ further includes telling the drop how long to store an email.
+
+ Drops will store the emails they accept until either a store or
+ another drop fetches them, or they expire. When a drop sends a
+ notification that an email has arrived, it can send it to a mail
+ store or another mail drop.
+
+## Confidentiality and authenticity
+
+Each identity will have an encryption key, for public key
+cryptography. All emails sent using that identity are digitally signed
+using the key: this allows others to verify that an email actually
+comes from a specific person, and that the mail hasn't been altered
+along the way.
+
+All email is also encrypted as well as signed. Everything that can be
+encrypted, will be encrypted. This includes all message metadata
+("headers" in the current system). If mail drops or stores need to add
+metadata, they'll attach another encrypted part to the message.
+
+All communication between mail clients, stores, and drops are
+encrypted (a la HTTPS), and may occur over the Tor network. All server
+components may be provided as Tor onion services, if the server
+operator so chooses.
+
+# Implementation thoughts
+
+While I'm not going to be spending my free time to implement this, I
+can't help having thoughts about how it would be done. Here is a loose
+collection of some of them.
+
+* Build on top of HTTPS. Avoid inventing new protocols at that level.
+ I'd favor RESTful APIs, myself.
+
+* Express message text as something similar to the Pandoc abstract
+ syntax tree, rather than specifying a specific language, such as
+ HTML or Markdown. Languages require trickier parsing. Having just
+ one way to represent messages should simplify interoperability. The
+ representation should avoid supporting arbitrary sender-provided
+ code to run as that would a big security risk.
+
+* The abstract syntax tree should have a way to explicitly mark text
+ as a quote from another message, and that new text is a direct
+ response to the quoted part.
+
+* I'd favor building the encryption on top of OpenPGP, given it's a
+ proven framework. I'm not a cryptographic engineer, though, so wiser
+ heads need to do that work.
+
+* Instead of large attachments, it may be preferable to have a mail
+ store provide the attachments on demand, attaching an authorization
+ token in the email for downloading the attachment instead. The
+ recipient's mail store can do the downloading automatically for
+ trusted senders.
+
+
# What next?
Do you think the solution proposed in this essay for spam and scam will
@@ -384,7 +513,7 @@ merge request or send patches.
There have been a very large number of proposals to improve email over
the years. This is an incomplete list of them.
-[@djbim2000} proposed "Internet Mail 2000" where the central idea is
+[@djbim2000] proposed "Internet Mail 2000" where the central idea is
that the sender stores the email, not the recipient. I'm not sure how
this would solve the spam problem. [@siebenmann2020] has an excellent
critique of the proposal.
@@ -392,20 +521,3 @@ critique of the proposal.
# References
-
----
-title: "Re-thinking electronic mail"
-author: Lars Wirzenius
-abstract: |
- There are many problems with the existing Internet email system,
- such as spam, scam, surveillance, insecurity, centralization, and
- complexity. The problems are starting to outweigh
- the benefits of the system. Fixing the problems by evolving the
- current system seems overwhelmingly difficult. This essay examines
- some solutions to the problems on the assumption that a completely
- new, parallel email system can be built.
-
- This is not a proposal for a new system, but an exploration of the
- solution space, meant to provoke constructive discussion.
-bibliography: email.bib
-...