Daniel J. Bernstein's IM2000 email proposal is not a good idea

September 6, 2020

A long time ago, Daniel J. Bernstein wrote a proposal for a new generation of Internet email he called IM2000, although it never went anywhere. Ever since then, a significant number of people have idealized it as the great white 'if only' hope of email (especially as the solution to spam), in much the same way that people idealized Sun's NeWS as the great 'if only' alternative to X11. Unfortunately, IM2000 is not actually a good idea.

The core of IM2000 is summarized by Bernstein as follows:

IM2000 is a project to design a new Internet mail infrastructure around the following concept: Mail storage is the sender's responsibility.

The first problem with this is that it doesn't remove the fundamental problem of email, which is (depending on how you phrase it) that email is an anonymous push protocol or that it lacks revocable authorization to send you things. In IM2000, random strangers on the Internet are still allowed to push to you, they just push less data than they currently do with (E)SMTP mail.

The idea that IM2000 will deal with spam rests on the idea that forcing senders to store mail is difficult for spammers. Even a decade ago this was a questionable assumption, but today it is clearly false. A great deal of serving capacity is yours for the asking (and someone's credit card) in AWS, GCP, Azure, OVH, and any number of other VPS and serverless computing places. In addition many spammers will have a relatively easy time with 'storing' their email, because their spam is already generated from templates and so in IM2000 could be generated on the fly whenever you asked for it from them. We now have a great deal of experience with web servers that generate dynamic content on demand and it's clear that they can run very efficiently and scale very well, provided that they're designed competently.

(I wrote about this a long time ago here, and things have gotten much easier for spammers since then.)

At the same time, IM2000 is catastrophic for your email privacy. People complain vociferously about 'tracking pixels' in HTML email that betray when you open and read the email from someone; well, IM2000 is one giant tracking pixel that reliably reports when and where you read that email message. IM2000 would also be a terrible email reading experience, because it's like a version of IMAP where message retrieval has random delays and sometimes fails entirely.

(As far as spam filtering your incoming IM2000 messages goes, IM2000 gives you far less up front information than you currently get with SMTP email. I wrote up this and other issues a long time ago in an entry about the technical problems of such schemes. Some of those problems are no longer really an issue more than a decade later, but some continue to be.)

At a broader 'technical choices have social impacts' level, IM2000 would create a very different experience than today's email systems if implemented faithfully, one where 'your' email was actually not yours but was mostly other people's because other people are storing it. Those other people can mostly retract individual messages by deleting them from their servers (you would still have the basic headers that are pushed to you), and they can wipe out large sections of your email by deleting entire accounts (and the sent messages associated with them), or even by going out of business or having a data loss incident. Imagine a world where an ISP getting out of the mail business means that all email that its customers have sent from their ISP email accounts over the years just goes away, from everyone's mailbox.

(If 'ISP' sounds abstract here, substitute 'Yahoo'. Or 'GMail'.)

In addition, in some potential realizations of IM2000, email would become mutable in practice (even if you weren't supposed to in theory), because once again the sender is storing the message and is in a position to alter that stored copy. Expect that capability to be used sooner or later, just as people silently revise things posted on the web (including official statements, perhaps especially including them).

Some of these social effects can be partially avoided by storing your own local copies of IM2000 messages when you read them, but there are two issues. The first is pragmatic; the more you store your own copies and the earlier you make them, the more IM2000 is SMTP in a bad disguise. The second is social; in the IM2000 world the server holds the authoritative copy of the message, not you, so if you say the message says one thing (based on your local copy) and the server operator says it says something else (or doesn't exist), the server operator likely wins unless you have very strong evidence.

In general, I think that IM2000 or anything like it would create an 'email' experience that was far more like the web, complete with the experience of link rot and cool messages changing, than today's email (where for better or worse you keep your own full record of what you received, read and reread it at your leisure, and know that it's as immutable as you want it to be). And it would still have the problem that people can push stuff in front of you, unlike the web where you usually at least have to go looking for things.

Written on 06 September 2020.
« Some notes on what the CyberPower UPS 'Powerpanel' software reports to you
URL query parameters and how laxness creates de facto requirements on the web »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Sep 6 00:39:01 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.