Why email is often not as good as modern communication protocols

August 5, 2018

I was recently reading Git is already federated & decentralized (via). To summarize the article, it's a reaction to proposals to decentralize large git servers (of the Github/Gitlab variety) by having them talk to each other with ActivityPub. Drew DeVault ntes that notes that Git can already be used in a distributed way over email, describes how git forges could talk to each other via email, and contrasts it with ActivityPub. In the process of this article, Drew DeVault proposes using email not just between git forges but between git forges and users, and this is where my sysadmin eyebrows went up.

The fundamental problem with email as a protocol, as compared to more modern ones, is that standard basic email is an 'anonymous push' protocol. You do not poll things you're interested in, they push data to you, and you can be pushed to with no form of subscription on your part required; all that's needed is a widely shared identifier in the form of your email address. This naturally and necessarily leads to spam. An anonymous push protocol is great if you want to get contacted by arbitrary strangers, but that necessarily leads to arbitrary strangers being able to contact you whether or not you're actually interested in what they have to say.

This susceptibility to spam is not desired (to put it one way) in a modern protocol, a protocol that is designed to survive and prosper on today's Internet. Unless you absolutely need the ability to be contacted by arbitrary strangers, a modern protocol should be either pull-based or require some form of explicit and verifiable subscription, such that pushes without the subscription information automatically fail.

(One form of explicit verification is to make the push endpoint different for each 'subscription' by incorporating some kind of random secret in eg the web-hook URL that notifications are POSTed to.)

It's possible to use email as the transport to implement a protocol that doesn't allow anonymous push; you can require signed messages, for example, and arrange to automatically reject or drop unsigned or badly signed ones. But this requires an additional layer of software on top of email; it is not simple, basic email by itself, and that means that it can't be used directly by people with just a straightforward mail address and mail client. As a result, I think that Drew DeVault's idea of using email as the transport mechanism between git forges is perfectly fine (although you're going to want to layer message signatures and other precautions on top), but the idea of extending that to directly involving people's email boxes is not really the right way to go, or at least not the right way to go by itself.

(To be blunt, one of the great appeals of Github to me is that I can to a large extent participate in Github without spraying my email address around to all and sundry. It still leaks out and I still get spam due to participating in Github, but it's a lot less than I would if all Github activity took place in mailing lists that were as public as eg Github issues are.)


Comments on this page:

By Mike at 2018-08-09 02:36:19:

I think most people who use email heavily (me included) implement "pull" model on top of email via mail filters and IMAP directories. Where "anonymous" stuff from strangers lands in a catch-all "INBOX", while e.g. github or cron notifications have their dedicated "subscription" folders (which IMAP actually allows to subscribe/unsubscribe for).

It's indeed special software like procmal, sieve/managesieve or advanced MUAs, and not exactly "verifiable" (though rarely exploited, due to ad-hoc setup nature), but have been used like that for ages.

In one previous dayjob (local ISP), seen whole company operating via single email entry point on old windows machine which had The Bat sitting there and filtering mail into dedicated folders for diff people via incredibly complex filter-layers piled-on since 90s.

Written on 05 August 2018.
« Firefox now implements its remote control partly over D-Bus
Some more notes on Firefox 63 and perhaps later media autoplay settings »

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

Last modified: Sun Aug 5 00:03:11 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.