💾 Archived View for halfbigdata.eu › 20220214-sad-state-email.gmi captured on 2022-03-01 at 15:04:22. Gemini links have been rewritten to link to archived content

View Raw

More Information

-=-=-=-=-=-=-

Is the state of mail software really that sad?

I have the impression that the state of mail user agents is rather depressing. I recently posted on Hackernews about it, but since I now have this capsule, I'd like to post a revised edition on here as well. This is it.

A lot has been said about how and why e-mail is broken (such as [1, 2]) and how encrypted e-mail is a lost cause (such as [3, 4]). This is all true and sad enough. My gripe (both current and perennial), however, pertains to Mail User Agents (MUAs).

[1] Dead letters (Cory Doctorow)

[2] The monstrosity e-mail has become (Ploum)

[2] Same, WWW version

[3] Stop using encrypted mail (Latacora)

[4] I'm giving up on long-term PGP (Filippo Valsorda)

First off, we have to state that many people don't even use a MUA at all, but instead rely on Gmail and other webmail, which runs in the browser, and the problems with modern browsers are beyond the scope of this post; suffice it to say that I deem `modern web applications' too bloated, much like Drew DeVault and others (see, i.a., [5]). (Just to be clear, this does rule out Electron-based MUAs for me.)

[5] Web browsers need to stop (Drew DeVault)

I used to use Thunderbird for almost forever, until I found that it had inexplicably high CPU usage every now and then (not caused by the search index, mind you), and it was a bit tedious to configure for plain-text mail [6]. Besides, Mozilla has threatened to drop this project more than once. So I tried a few other clients (such as Geary and Evolution) and switched to Claws mail.

[6] useplaintext.email

Claws mail does have outstanding performance. But its source code was not very convincing (mixing several layers of abstraction, including GUI, in the same place). Besides, it's a GTK program.

I just can't help it — I find GTK very hard to configure:

Speaking of plain-text mail (as I did a few paragraphs ago), the website [6] I mentioned above does list quite a few clients with textual user interface or command-line interface. I tried aerc, because it was fresh, written in Go, and it has a really cool intro video done by Drew DeVault. But I found that the UX was not to my liking, and I don't quite understand why a MUA should include a terminal emulator. Or why it should be a self-contained application altogether. [Let me just add, because it's not that obvious: An alternative MUA would consist of a set of small programs and thus be integrated with the shell, which you would never quite leave.]

This whole idea of a self-contained MUA application goes against the general UNIX-y paradigm of "no application" [7] and "choose extend over embed" [8]. Don't app me in, if I may say so.

[7] No application (C2 wiki)

[8] Embed vs. extend (C2 wiki)

Other MUAs, such as nmh/mmh or neatmail do in fact follow these paradigms. But their adoption seems very weak, and:

Now, in order to use these UNIX-y programs, I imagine (though I didn't check) one also needs dedicated programs for communicating with mail servers, i.e., for receiving and sending mail. So I read up a bit on sendmail, postfix, qmail, fetchmail, getmail, and fdm. And we seem to be treading buffer-overflow territory once again (or deprecated Python 2 in the case of getmail). I find this rather sad.

Am I missing something? Is the state of MUAs and e-mail in general really this bad/sad?

[In a comment below my HN post, I later listed] the following desiderata regarding a MUA:

I think the case can be made that re-inventing the wheel can sometimes be beneficial. And e-mail to me seems rather `underexposed' (maybe because most people think it has been a solved problem since at least Gmail).