summaryrefslogtreecommitdiff
path: root/rethinking-email.md
diff options
context:
space:
mode:
Diffstat (limited to 'rethinking-email.md')
-rw-r--r--rethinking-email.md523
1 files changed, 0 insertions, 523 deletions
diff --git a/rethinking-email.md b/rethinking-email.md
deleted file mode 100644
index db4e521..0000000
--- a/rethinking-email.md
+++ /dev/null
@@ -1,523 +0,0 @@
----
-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 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, 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 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
-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
-
-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. 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
- projects, but also to allow people all over the world to easily
- self-organize to build a better world in general.
-
-* Distributed: sender and recipient don't need to use the same server.
- Anyone can set up their own server, assuming time, know-how, and a
- little money.
-
-* Standardized: there are many implementations and they're mostly
- inter-operable.
-
-* Supports off-line use. Not everyone can, or wants to, be online all
- the time.
-
-
-## Problems with the existing email system
-
-* Spam, or unsolicited bulk messages. Worse, anti-spam measures drive
- centralization, and are still ineffective, especially for those not
- using one of the huge centralized providers. End result: you either
- sacrifice privacy or you get tons of spam.
-
- - Spam is a result of the desirable feature that anyone can email
- anyone, combined with the fact that sending an email costs
- approximately nothing, even if you send millions of emails, and
- aggravated by the fact that spamming has de-facto no real financial
- or legal repercussions.
-
-* Scam, or trying to convince people to do something that they shouldn't
- or that's harmful to them or others. 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 they're not
- great, and the big providers of email software or service tend not
- to support them, or support them badly.
-
-* Becoming centralized 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 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
- accident, sometimes due to nefarious policies.
-
-* 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. It's difficult to hide who is sending email to whom.
-
-* HTML email is not well standardized, and is 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 issues (the image
- hosting service will be notified when you view the email, see
- tracking pixels).
-
- There are moves to restrict this, but the problems have been known
- since HTML email was introduced, and the problems continue to exist.
- Some problems (such as embedding remote images) have gotten at least
- partial solutions, but the problems shouldn't exist at all.
-
-* 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, are not ubiquitous, and people
- mostly don't use them routinely.
-
-* There is no good support for group discussions. Massive dumps of
- forwarded discussions are commonplace in most large organizations.
- 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.
-
- - Email threads work, technically, but tend to result in surprisingly
- little communication happening, in the general case. People mix
- topics in threads, split the same topic into new threads, and
- generally don't use threads as intended. This is not the fault of
- people, but the technology.
-
-* 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
- the servers secure.
-
-
-# The spam and scam problem
-
-There are a large number of problems. Rather than attacking all of them
-at once, let's consider them one at a time, and let's start with the
-most obvious problem: spam. As a side effect, the solution proposed
-below should also solve the scam problem.
-
-
-## Problem statement
-
-The spam problem can be stated as follows:
-
-> 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:
-
-> Anyone can send email that looks like it comes from someone else, at
-> least sufficiently well that an unobservant recipient is fooled. This
-> can be used to con the recipient to click a link in the email that
-> leads to a fake web shop, for example, or a site that attacks the
-> recipient with malware.
-
-
-## Overview of solution
-
-* Every email user has one or more identities, represented by
- cryptographic keys.
-
-* All email is digitally signed using the cryptographic keys.
-
-* No email is delivered unless it carries a digital stamp issued by the
- recipient, or someone authorized to issue one on behalf of the
- recipient.
-
-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.
-
-[@godinstamps] also discusses his idea of paid stamps for email,
-originally from late 1980s or early 1990s, with the idea that low
-volumes are free, but after that you pay a "penny" per email. I'm not
-really happy with the exact solution suggested, as it doesn't provide
-the recipient from a way to avoid unsolicited junk from arriving, but
-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. 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
-sent using an identity is signed with the key for that identity.
-
-This means misrepresenting the sender becomes much harder, reducing the
-possibility for scam.
-
-Each identity (key pair) can have metadata associated with it, such as a
-name. There can be digital signatures for the metadata for certifying
-it, to avoid miscreants faking identities by creating new keys and
-associating someone else's name on them. With the metadata signatures,
-the recipient's email software can at least attempt to verify
-correctness of the metadata.
-
-Alternatively, names are handled only on the recipient's side. If I get
-a message from you, and I'm sure it's from you, I can tell my email
-address book that the key you used to sign the message should have your
-name. If a miscreant creates a new key, my email software won't say it's
-from you, and the miscreant has to convince me that it's you. (This
-needs further thought.)
-
-
-## Digital signatures
-
-For the purposes of this discussion, assume a way to digitally sign
-messages that covers the whole message, including its metadata. The
-details of how that is achieved do not matter: digital signatures have
-well-known, good solutions and since we are talking about a new system,
-we don't have to be compatible with the problems of the existing email
-system.
-
-For this discussion, assume each message can be securely verified as
-having been sent by its sender identity. If a message claims to be from
-an identity, but its signature can't be verified, the message is
-rejected by the recipient's email software.
-
-
-## On encryption
-
-To solve the problem of surveillance, email encryption is going to be
-needed. The simple solution is to always encrypt everything.
-
-
-## Digital stamps
-
-A digital stamp is a digital token issued by a recipient which gives a
-sender the capability to send one or more messages to the recipient.
-
-A digital stamp is more powerful than a physical, paper stamp. Paper
-stamps can be transferred (sold, given) without limit. A digital stamp,
-however, allows more features:
-
-* only the recipient can decide if it's still valid: the recipient can
- invalidate otherwise valid stamps
-
-* 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? 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
- them another, longer-lived stamp, you won't get further email from
- them
-
- - for example, I might order a mug from an online shop and give them
- two single-use stamps: one for sending me the order confirmation and
- another for sending me a notification of shipment
-
-* digital stamps may be valid only for a specific sender: I might issue
- a stamp to a shop and if they sell my contact information to a
- spammer, the spammer can't use the stamp to send me email; further, I
- will know the shop gave the stamp to the spammer
-
-As an extra twist, digital stamps may also be an authorization to
-someone else to issue stamps on your behalf. Rather than the stamp
-allowing them to send you an email, it lets them create a stamp that
-lets a third party send you an email. Your email software can put any
-and all the constraints it puts on stamps you issue directly on the
-delegation.
-
-For example, if you and Alfred have a mutual friend, Bruce, you can give
-Bruce a stamp that authorizes Bruce to issue single-use stamps to other
-identities. If Bruce thinks you and Alfred should know each other, Bruce
-can issue Alfred a stamp that lets Alfred send you a single email. If
-you like Alfred, you can issue further stamps to Alfred.
-
-An employer runs their own email server, and that server determines
-which stamps it accepts. This lets an employer issue stamps on behalf of
-each of their employees.
-
-
-## Receiving email from strangers
-
-In some cases it's important to be able to receive email from
-strangers. A stranger here is someone to whom you've not given given a
-digital stamp. Some examples of when this might be important:
-
-* you're an open source developer and you wish to receive bug reports
- from strangers
-* you work in a customer-facing role in a company and your customers
- need to be able to reach you
-* you've saved a dog from a tree and journalists need to be able to
- reach to set up interviews
-* someone you went to school with wants to congratulate you on your
- marriage, birthday, newborn child, or other life event
-* a former co-worker wants to ask if you want a new job with their new
- employer
-
-Some of these cases can be handled by not using email: bug reports can
-go into a web-based ticketing system; customers can get a single-use
-stamp whenever they pay their invoice; etc. However, there will always
-be cases when you want email from people to whom you've not yet given
-a stamp.
-
-A mail server can, optionally, have a feature where it gives anyone a
-single-use stamp tied to a specific sender identity. Unfortunately,
-this could easily be abused by spammers: they'll automate the step of
-requesting a stamp before sending the email. To counter that, the mail
-server can impose conditions on giving out stamps:
-
-* In the simplest case, the server might never give out stamps; this
- prevents spam at the cost of all desired email from strangers.
- Whether that's an acceptable compromise is up to each recipient.
-
-* The server might require the putative sender to solve a [CAPTCHA][]
- of some kind. The CAPTCHA might be a puzzle that is infeasible to
- solve automatically.
-
-* 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
- computing resources it becomes infeasible. (See also [@hashcash] for
- an early suggestion.)
-
-* The server could require a very small payment. (This is troublesome
- in international communication, when "very small" is a irrelevant to
- someone working in a rich country, but a sizable fraction of the
- annual earnings of someone living in a poor country.)
-
-[CAPTCHA]: https://en.wikipedia.org/wiki/CAPTCHA
-[proof of work]: https://en.wikipedia.org/wiki/Proof_of_work
-
-The issuing of stamps to strangers is optional, and is meant to be an
-interactive process. There doesn't need to be a standard way to do
-that, or even an enumerated set of standard ways. Each mail server,
-even each recipient, can invent their own. Flexibility here is
-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
-help? If not, why not? Can you see a way for a miscreant to circumvent
-the proposed solution to get their unwanted message delivered to the
-recipient?
-
-Let me know, preferably via the legacy email system, as a response to
-this [fediverse thread][], or using the [GitLab issue system][]. If
-you want to propose improvements to the essay, feel free to file a
-merge request or send patches.
-
-[fediverse thread]: https://toot.liw.fi/@liw/103984861489499836
-[GitLab issue system]: https://gitlab.com/larswirzenius/ideas/-/issues
-
-
-# Other proposals to improve email
-
-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
-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.
-
-
-
-# References