Why We Need to Rethink Email, and How

We all know, email can be a pain. And – let’s be honest – more often than not, it is a pain; big time. I am not talking about the sheer volume, although that would warrant a series of posts of its own. The aspect I’d like to focus on in this post, is how email clients have grown convoluted over time, how this has shaped our mental model of email, and how it is hampering our productivity. Effectively, it seems to me as if we were caught in the 1990s when it comes to email. Not only in terms of productivity, but also in terms of security, as the Efail.de scam (also see my previous post) has shown.

Why do I say we are “caught in the 1990s when it comes to email”? Well, let’s first take a brief look at where we are today, and a short tour of history to see where we came from, before .

Up front, at the risk of appearing pedantic (haha, just as if I could still avoid that), a brief recap on terminology, so you know what I’m talking about. Quoting from section 2 “Terminology” of RFC 5068:

The Internet email architecture distinguishes four message-handling

• Mail User Agents (MUAs)
• Mail Submission Agents (MSAs)
• Mail Transfer Agents (MTAs)
• Mail Delivery Agents (MDAs)

At the origination end, an MUA works on behalf of end users to create
a message and perform initial "submission" into the transmission
infrastructure, via an MSA. An MSA accepts the message submission,
performs any necessary preprocessing on the message, and relays the
message to an MTA for transmission. MTAs 'relay' messages to other
MTAs, in a sequence reaching a destination MDA that, in turn,
'delivers' the email to the recipient's inbox. The inbox is part of
the recipient-side MUA that works on behalf of the end user to process
received mail.

These architectural components are often compressed, such as having
the same software do MSA, MTA and MDA functions. However the
requirements for each of these components of the architecture are
becoming more extensive, so that their software and even physical
platform separation is increasingly common.

As you see, MSAs, MTAs, and MDAs usually are part of your server infrastructure. They deal with the nitty gritty details of the store-and-forward processing of your messages after you’ve sent them off, and before they reach the recipient(s). This is the boring part, and although these pieces of software have evolved considerably since the first /usr/bin/sendmail which shipped with BSD 4.1c back in 1983, they still work well today. The rest of this post will therefore focus on the Mail User Agents (MUAs), i.e. the software we all use every day to read and send email messages, and which keeps getting in our way time again. Encrypted messages will play their role, too.

Where We Are Today, and How We Got There

There is a marvellous graphical history chart of email apps, which covers the entire history from the mid 1970s until today. Far from complete, probably, but still an impressive research work and result. Looking at the sheer number of client apps, you will notice that after a slow start (which is not surprising, given the limited availability of Internet at the time), there was a first spree of new apps in the second half of the 1990s, after which growth was slowing down until ca. 2010, from which onwards it started growing exponentially (not to say exploding). The late-1990s growth is likely liked with the growing commercial success of dial-in Internet services like AOL, CompuServe, The Source, Prodigy, Delphi, etc. due to the falling computer hardware prices. How to explain the “2010 explosion” on the other hand? My hypothesis is, that this is an indication of digital communications tools making it to the mainstream; not only on the business side of things (where this has likely happened earlier), but for human society as a whole. We are emailing with friends, family, colleagues, clients, suppliers, janitors, dog walkers, you name it. For many of us, email has be come the predominant means of communication. I haven’t found any statistics of how much time we spend on email vs. how much time we spend in phone calls, but I’d expect it to be at least ten times as much for most of us. Email has become an everyday commodity like frozen food, so people saw a business case in making microwave ovens (and blessed us with ever more email client apps).

Looking at the mental models on which these MUAs are built, little has changed since the first graphical MUAs, and in fact even since the first MUAs ever, MH and Elm.

Where I Think We Should Be Heading

Instead of one-big-lump-doing-all monsters as our daily email workhorse app, we should have something that follows the one-thing-well mantra, and which gets less in our ways and lets us shape our workflows more freely.

How to translate these findings to desktop email clients? One of the things I have been learning (and still am) when it comes to things I use all day every day, is customisation. Customisation was available in abundance in the early days of email. But these were command line UIs, and in 2021, when every laptop has a graphics subsystem that easily dwarfs an SGI Onyx Reality Engine performance-wise, users expect some eye candy. Eye candy, on the other hand, is available in abundance in today’s MUAs; but at the cost of no, or little, customisation options.

Thus, a middle ground is needed, that does not feel alien in a graphical desktop environment, but still provides the much needed modularity and configurability under the hood.

Further Reading