|author||Lars Wirzenius <firstname.lastname@example.org>||2021-10-25 09:22:25 +0300|
|committer||Lars Wirzenius <email@example.com>||2021-10-25 09:22:25 +0300|
add thoughts on identities, routing, signing, encryption
1 files changed, 66 insertions, 1 deletions
diff --git a/rethinking-email.md b/rethinking-email.md
index e274a69..76a0767 100644
@@ -363,6 +363,71 @@ important, as spammers will evolve ways to circumvent any common
+# 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
+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 vision:
+* 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
+* 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. When a drop sends a notification that an
+ email has arrived, it can send it to a mail store or another mail
+## 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.
# What next?
Do you think the solution proposed in this essay for spam and scam will
@@ -384,7 +449,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.