Michael Weber: Random Bits and Pieces

Gah. Why do email clients suck so much? Let me explain what I am looking for.

From the top of my head, here's a list of features I would like to see in a MUA (yes, I am blue-skying here):

  • Must run at least under Linux and *BSD operating systems on various processors.
  • Must support IMAP, including advanced features like server-side searching, partial message download, etc.
    Nevermind that IMAP is actually a pretty involved protocol and not very easy to get right, this is what I am currently stuck with. Maybe SMAP will be better (under some metric), but that remains to be seen.

  • Must support external editors.
    A MUA should handle the network protocol part of email handling and message display, everything else (and in particular editing) is somebody else's problem.

    For various reasons I like to edit text in GNU/Emacs, so why should I be satisfied with some simplish, less configurable editor?

  • Must be able to handle large amounts of email fast.
    I would like to be able to access at least the current year's worth of email without much hassle, without long periods of waiting. Access includes searching (by sender, recipient, date, keywords, etc.) and sorting.

  • Must be standards-compliant.
  • Must support Unicode and various charsets correctly.
    This affects message display and searching, mostly.

  • Must support encrypted email.
    This includes PGP/MIME and S/MIME.

  • Must support various means of sending mails.
    I do not want to run an SMTP server on my laptop, if I can hand off email to some MSA like /usr/sbin/sendmail instead. If not the sendmail interface, at least RFC 2476 should be supported.

  • Must support offline reading capabilities.
    Already downloaded emails should be cached, so that I can read, manage and answer them while disconnected. Upon reconnect, the offline state is synchronized.

  • Must be lightweight.
    Writing emails is not a main task, at least for me, so the client should be unobtrusive and not take up all the resources by itself.

  • Must be able to actually print emails in a sensible way, where sensible means to decode and print attachments if I desire so, instead of dumping base64 encodings or worse onto the printer.
  • Should support virtual folders.
  • Should support ACAP

Already tested email clients:

Mutt
Mutt has been my email client of choice for a couple of years now. I am mostly happy with it. However, its IMAP capabilities are not satisfying. Offline capabilities are non-existent, and the modal interface is quite limiting: if while writing one email I want to refer to another one, I either have to start another instance of mutt or postpone the message, do the lookup and resume writing.
Sylpheed-Claws
Tried it for five minutes. Mail submission only via SMTP.
Balsa
Nevermind that Balsa first segfaulted on me because it did not like the trash file, I installed a new version and then it started working. It seemed fast, but does not support an external editor. Mail submission only via SMTP.
Mozilla Mail
Mozilla Thunderbird
Not happy. Details later.
Opera Mail
Delayed Header download (good!), header cache (good!), fast enough even with big mailbox, learning filter/sorting. On the downside: no external editor, mail submission only via SMTP.
Wanderlust
Fast, but clunky. An editor is not an email client. Also, SMTP seems to be the only way to submit email.
VM
I used VM a long time ago on XEmacs. I stopped using it when my email volume increased. VM was just too slow.
GNUS
The same applies as for most Emacs MUAs: clunky and slow.
etPan!
I tried version 0.6.1 on Debian and it segfaulted in various situations. Also, SASL is not yet supported. I will keep etPan! on my watch list, though.
KMail
[321]% sudo apt-get install kmail
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
[...]
Need to get 21.8MB/21.9MB of archives.
After unpacking 69.2MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.
    
Thanks, but no thanks.
Polymer
Slow, and under heavy development. I experienced some freezes and exceptions thrown. I like that it supports ACAP. Unfortunately too sluggish for large mailboxes.

So, dear reader, which email client are you using, and where do you compromise? Write me!

Apparently, Brian Nelson seems to agree with me on this one. Others have similar griefs about email clients.

UPDATE 2005-10-05: Hints to IMAP client authors

UPDATE 2008-11-03: Out of Date

I am seeing a lot of Google referers coming in to this article. Perhaps I should point out that some of the information is outdated. I am using Apple's Mail.app at the moment. It works decently in most everyday situations and has decent (off-line) IMAP capabilities. However, it sucks in other exciting ways.

Having said that, why not add some more possibly outdated information. I came across a description of the BikINI protocol, a proposed replacement for IMAP. The project appears to be on hold at the moment, but might be resurrected in the future.