This page is an HTML mirror of the original gemini page.
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).
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., ). (Just to be clear, this does rule out Electron-based MUAs for me.)
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 . 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.
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  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"  and "choose extend over embed" . Don't app me in, if I may say so.
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).
Subscribe to my RSS feed.