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
- Tried it for five minutes. No external editor, mail submission only via SMTP.
- Balsa
-
Nevermind that Balsa first segfaulted on me because it did not
like the
trashfile, 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
- IMAP Client Coding HOWTO
- Mark Crispin's Ten Commandments of How to Write an IMAP client
- RFC2683 (IMAP4 Implementation Recommendations)
- Intrinsic IMAP issues
- IMAP ACL Summary
