summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLars Wirzenius <liw@liw.fi>2021-10-25 09:22:25 +0300
committerLars Wirzenius <liw@liw.fi>2021-10-25 09:22:25 +0300
commit69e7a495069faafdc838b91df1a573b31d3a7fd5 (patch)
tree8970c37cdb3e5e97fde78505b1f9f75d05b1d93c
parentf5bffa94328b71cc2bad9c3ee22c15c9826b612a (diff)
downloadideas-69e7a495069faafdc838b91df1a573b31d3a7fd5.tar.gz
add thoughts on identities, routing, signing, encryption
Sponsored-by: author
-rw-r--r--rethinking-email.md67
1 files changed, 66 insertions, 1 deletions
diff --git a/rethinking-email.md b/rethinking-email.md
index e274a69..76a0767 100644
--- a/rethinking-email.md
+++ b/rethinking-email.md
@@ -363,6 +363,71 @@ 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 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
+ reflects.
+
+* 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
+ 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.
+
# 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.