All forms of signing email are generally solving the wrong problem (a thesis)

August 30, 2020

Modern email is full of forms of signed email. Personally signed email is the old fashioned approach (and wrong), but modern email on the Internet is laced with things like DKIM, which have the sending system sign it to identify at least who sent it. Unfortunately, the more I think about it, the more I feel that signed email is generally solving the wrong problem (and if it's solving the right one, we won't like that solution in the long run).

A while ago I wrote about why email often isn't as good as modern protocols, which is because it's what I described as an anonymous push protocol. An anonymous push protocol necessarily enables spam since it allows anyone to send you things. Describing email as 'anonymous push' makes it sound like the anonymity is the problem, which would make various forms of signing the solution (including DKIM). But this isn't really what you care about with email and requiring email to carry some strong identification doesn't solve the problem, as we've found out with all of the spam email that has perfectly good DKIM signatures for some random new domain.

(This is a version of the two sides of identity. On the Internet people can trivially have multiple identities, so while an identity is useful to only let selected people in, it's not useful to keep someone out.)

I think that what you really care about with modern communication protocols is revocable authorization. With a pull protocol, you have this directly; you tacitly revoke authorization by stopping pulling from the place you no longer like. With a push protocol, you can still require authorization that you grant, which lets you revoke that granted authorization if you wish. The closest email comes to this is having lots of customized email addresses and carefully using a different one for each service (which Apple has recently automated for iOS people).

Obviously, requiring authorization to push things to you has a fundamental conflict with any system that's designed to let arbitrary strangers contact you without prearrangement (which is the fundamental problem of spam). Modern protocols seem to deal with this in two ways (even with revocable authorization); they have some form of gatekeeping (in the form of accounts or access), and then they evolve to provide settings that let you stop or minimize the ability of arbitrary strangers to contact you (for example, Twitter's settings around who can send you Direct Messages).

(The modern user experience of things like Twitter has also evolved to somewhat minimize the impact of strangers trying to contact you; for example, the Twitter website separates new DMs from strangers from DMs from people you've already interacted with. It's possible that email clients could learn some lessons from this, for example by splitting your inbox into 'people and places you've interacted with before' and 'new contacts from strange people'. This would make DKIM signatures and other email source identification useful, apart from the bit where senders today feel free to keep changing where they're sending from.)

PS: In this view, actions like blocking or muting people on Twitter (or the social network of your choice) is a form of revoking their tacit authorization to push things to you.

Comments on this page:

By John Wiersba at 2020-08-31 15:33:26:

Spam is also a matter of scale. Compare to junk pmail (physical mail): For me, junk pmail isn't a problem because:

  1. I get enough useful pmail that I don't mind going to my pmailbox everyday to pick it up.
  2. I only get a few pieces of junk pmail each day and it's relatively easy to distinguish junk pmail from useful pmail, so it's not too much of a burden to separate the junk pmail from the useful pmail each day, and dispose of the junk pmail.

However, if my junk pmail increased in volume 1000-fold, or if my useful pmail decreased 1000-fold, then dealing with junk pmail would become a problem.

Similarly, if I only get a few spam emails a day, it's not a problem. But when the spam starts to overwhelm the useful email, it becomes a problem.

I think the solution (as others have proposed before) is to charge for email, "just as" we charge for pmail. If the cost is balanced so that it's not onerous for useful email senders (say 1 cent per email), but it is too expensive for bulk spammers, then we can keep the spam in check.

This assumes that the entity who actually bears the burden is the spammer, not the owner of an account which has been compromised. Or maybe if the compromised owner is charged, they will have incentive to apply security updates and, at the end of the responsibility chain, the makers of security software and operating systems will be incentivized to write more secure systems (because they will get sued for shoddy security practices).

DJB's Internet Mail 2000 proposal ( ) would have fixed this.

Briefly, this separates mail into two phases. In the first phase, a small set of headers is pushed towards each recipient. In the second phase, which is not expected to follow closely in time, the recipient pulls the email body, probably via HTTPS.

This means that an email server must have longevity, and be operational when the recipient gets around to asking for the message body. Most filtering can work against the headers, and your local server may pre-emptively request bodies for you when they have a high confidence of desirability.

Of course, IM2000 requires a new software stack which could be gatewayed to/from SMTP but is not directly interoperable, so it's pretty unlikely to happen.

I don't see how djb's proposal fixes the spam problem, because the headers are still pushed, and the recipient (me) still has to decide whether or not to retrieve the body. So my email client will be showing me a bunch of headers pushed by spammers and asking me if I want to retrieve the emails, which from my point of view is no better than showing me a list of senders and subject lines of emails from spammers and asking me if I want to read them. And automating the process of screening out headers pushed by spammers doesn't seem any easier to me than automating the process of screening out emails sent by spamemrs--in fact it should be harder since the headers alone contain less information by which to identify spammers than the full emails including the bodies do.

By cks at 2020-08-31 17:37:57:

I disagree that djb's IM2000 would have solved the problem, either in the abstract or in the concrete. In the abstract it's still not revocable authorization, since anyone can initiate sending something to you without prior authorization. In the concrete, I very strongly believe that it would actually make the situation worse for reasons I wrote up here, in the technical problems with 'sender stores email' schemes, and in why it's actually easier for spammers than real mail servers.

(Some of those technical issues are less acute here in 2020 than they were a decade ago, but they're still pretty bad and the situation still strongly favours spammers over real mail servers.)

As far as causing senders to pay for email, I don't think this will do what people want. Any viable costs are peanuts for actual marketing departments, and if people are charging to accept email there are going to be requirements for delivery. Here in 2020, it would also never fly because Google is not paying the costs for all of those outgoing GMail messages, nor Microsoft for Hotmail's (and they certainly aren't going to start charging for GMail and Hotmail accounts).

I agree - DKIM is not enough to combat spam email. You are correct that DKIM signatures can be signed with a selector keypair from a random domain elsewhere. For example, I can send you an email from with a DKIM-Signature from s=selector01, and effectively spoof with a DKIM validated email as the contents and signed headers have not changed.

However, this is not a fault of DKIM. DKIM is fundamentally not an identity protocol - it is an integrity protocol. DKIM by itself will tell you that the message has not been modified since the signature was applied.

DMARC is the protocol that will provide proof of identity. With DMARC, for your DKIM signature to be aligned, your domain and the domain in the From: header must be the same. This is called 'alignment' and it means that you have signed the message with a keypair published in the public DNS for the From: address domain. This provides the proof that you have access to either the private key in that key pair, or the public DNS zone for the From: domain.

I think we should be careful to not ask protocols to fix problems they were not designed to solve.

By cks at 2020-09-03 20:46:54:

Even DMARC alignment doesn't really solve any problems (except very narrow ones), because there is a huge amount of demonstrations that people simply don't notice odd From: addresses. This assumes that their email environment even shows them the address, instead of the human chosen name in the From:; increasingly, email environments don't (which makes sense if people don't find them meaningful and don't pay attention to them).

(Spam and malware often also don't require any particular From: to be potentially convincing, too, which means the attacker can produce perfectly aligned messages.)

By Sphink Orguy at 2020-09-04 21:47:15:

Ah these are really inspiring thoughts. I saw them echoed from the other, non-ivory tower side in the smolnet last month: It's talking about social media, not email, but the point is pretty similar: connection without some sort of gate that gives people control over consent is "inherently toxic"

  • Posting to public timelines by default.
  • Anybody can follow you by default.
  • Your profile contains a hidden RSS feed accessible from the public web.
  • Search engines can index your public posts by default.
  • People can see how popular you are by default.
  • New accounts not only can but are encouraged to follow complete strangers, which rolls out the welcome mat for trolls and spammers.
  • Anybody can reply to your public/unlisted posts or direct message you by default.

Daniel J. Bernstein came to very much the same conclusion about twenty years ago:

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

By nanaya at 2020-09-06 02:37:47:

Some mail providers like Fastmail allow filtering mails by whether or not they're in contacts. That should practically allow selectively whitelist people who can send mails directly to inbox.

The new mail provider "Hey" also literally have that as their prominent feature called email screening.

Written on 30 August 2020.
« An interesting mistake with Go's context package that I (sort of) made
Why we won't like it if signing email is the solution to various email problems »

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

Last modified: Sun Aug 30 22:55:33 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.