Links

Ben Laurie blathering


Modern Mail Clients

Way back when, I used to use Pine to read my email. After it had marked everything I read as unread again once too many times (admittedly not entirely its fault, but it did leave everything ’til the last minute), I switched to, well, something else. I don’t remember exactly what. But after a long series of experiments I ended up with Thunderbird, which I mostly like – or at least hate less than all other clients I’ve tried.

But, it really doesn’t handle big mailboxes very well. I’m lazy when it comes to tidying up, as my wife will testify, and so I tend to find myself with 100,000 read messages lying around and a similar number unread.

Thunderbird can read mailboxes like that (which is an improvement – earlier versions couldn’t), but it really doesn’t handle deleting them very well. Select even a small number, like a thousand or so, and hit delete, and watch Thunderbird go away for a very long sleep.

In the end I had to go back to Pine to tidy my mailbox. Incidentally, I tried mutt, but it couldn’t handle more than a few thousand messages at a time. Pine seems to manage whatever I throw at it, though its UI can only be described as arcane.

So, my question to the lazyweb: is there an answer to this? A modern open source client that can do graphical stuff, is nice to use and can handle big IMAP mailboxes? Or is my Thunderbird/Pine hybrid as good as it gets?

14 Comments

  1. Mutt is usually quite good at handling big local mailboxes; however, it’s pretty clear that pine wins for IMAP.

    Comment by tlr — 21 May 2008 @ 13:12

  2. One of the mysteries of the internet is why after all this time, nobody has managed to create an email client that doesn’t suck.

    I’ve toyed with the idea of writing my own, but the pain of doing that is usually higher than just dealing with the issue using existing tools.

    Comment by Charles Darke — 21 May 2008 @ 13:18

  3. Likewise, for me too. I use Thunderbird on XP, but will be experimenting with Mail.app soon on my shiny new MacBook.

    Seriously: why isn’t there a well-known non-expensive-commercial GUI mail client that uses something besides flat text files to store messages? Or am I missing something? Admittedly, I’m only mucking about with hundreds of messages at once typically, but I still feel nervous about Thunderbird’s performance and stability with my whole IMAP directory…

    I often just set Thunderbird to doing something, and then work elsewhere for a while. Sigh.

    http://simile.mit.edu/seek/ is pretty magical for searching your Thunderbird, however.

    Comment by Shane Curcuru — 21 May 2008 @ 13:56

  4. mutt works fine for me – in my case it handles large IMAP folders definitely faster than thunderbird. you just might have to tweak the muttrc to do so, like using ‘set header_cache’ and a few other directives. still, opening tenthousands of headers via IMAP just takes some time, whichever client you use.

    Comment by iso — 21 May 2008 @ 15:16

  5. I use alpine, which is the rework and rerelease of pine under a real open source license (Apache 2). I’m no so lazy as you, so I only have several thousand messages in my mailboxes, but it performs quite well. It coping probably has much to do with the backend though: I use Maildirs with the Dovecot IMAP server, which maintains indices on top of the Maildirs for better performance.

    Comment by djm — 21 May 2008 @ 17:35

  6. if you enable the header and body caching in mutt, it really speeds up its operation for large mailboxes. my 2007 archive mailbox has 17,455 messages in it and mutt can open it over imap in about 4 seconds. switching between my normal mailboxes that have hundreds or even 2000 messages in them open almost instantly.

    Comment by joshua — 21 May 2008 @ 17:45

  7. I think it’s as good as it gets, but I’m curious to see answers. I’ve started switching secondary accounts over to google apps, but my primary mess is still a dog slow thunderbird with a pine backup. One thing I’ve started doing is running an archive script which takes everything 6 months or older and shoves it into a .folder (by year) that I just don’t subscribe to in thunderbird. Helps a little, but still sucks. When can we officially stick a fork in email and call it done?

    Comment by Matt Westervelt — 21 May 2008 @ 18:13

  8. #4: Actually, Pine (and Alpine, which I just switched to) load a mailbox with 200k messages in it instantly. Pretty cool.

    Comment by Ben — 21 May 2008 @ 19:16

  9. Ben, I used to have the same (long-time) problem with TB, it recently went away with a Fedora update (I’m running fedora 7). I don’t know exactly when, because I had to keep pine around and got into the habit of not even trying to do any heavy stuff with TB. It may be a bugfix in upstream TB source, or a local patch of the fedora team. Well, now I can’t say it’s a speed monster, but at least it’s usable.

    Pine is so fast because it’s the smartest IMAP client, being the most “stupid” at the same time: it never tries to do client-side what the server can do on the server side. It doesn’t cache headers, it doesn’t fetch all headers to sort (or scroll) them. It fetches just what it needs to display the message list screen (about 20 messages headers, more if your terminal window is taller than 24, but still a small fraction of the whole message list). When you scroll, it just fetches more.

    In order to achieve that, a GUI-based reader should develop a specialized widget, whose scrollbar is tied to the server list and not to another local widget, as usual. That is completely different from the usual GUI technique, that is, create a big window (the message list), put it inside a container that display a part of it, tie scrollbar to change what part is displayed. Now, smart toolkits don’t render the whole underlying window, just the needed part, but yet the whole message list has to be loaded and connected somehow to that window, at least in order to determine its size (which in turn is needed to display the scrollbar correctly). That’s why almost every GUI client I know of fetches all headers for each mailbox it opens, often going thru the trouble of caching them (evolution local cache for example can grow quite big for large mailboxes).

    I think a solution is possible (although one should enter the scary async + GUI realm I’m afraid), just most email client developers deem large (200k+ messages) mailboxes either rare or of the user-actively-seeking-for-troubles kind.

    Comment by Marco Colombo — 22 May 2008 @ 11:46

  10. One reason may be the format of the mailbox (I assume working locally). Thunderbird supports only MBOX (or has this changed?), which makes deleting a complicated operation. Actually, it doesn’t work well with anything for large mailboxes, that’s why every modern mail client has to add some additional indexing on top of it.
    If you can, try to use something better suited, like maildir. For instance, with kmail you can use either MBOX or maildir.

    Comment by Harry — 22 May 2008 @ 16:01

  11. Some (perhaps even most) of issue you describe is covered by bug 296453, which has a couple of pending patches, so this is likely to get better in upcoming versions.

    Comment by Dan Mosedale — 22 May 2008 @ 22:44

  12. The Opera browser does come with a mail client that I find fast and very convenient to use.

    Comment by Chick — 15 Jun 2008 @ 1:24

  13. I switched to evolution about a year ago, before that I was using mutt for about 6 years.

    First off, mutt *can* handle large imap mailboxes well. Some of my mailing list folders easily reached into the 50k+ ballpark and mutt opened them in reasonable time. Be sure to enable the caching options as Joshua pointed out. Mutt will never be as fast as pine with imap but I found it to be fast enough, even for huge folders.

    My reasons to finally switch away from mutt had nothing to do with IMAP performance. My job at that time required me to deal a lot with PDF attachments and the occassional HTML-mail (stupid customers!). Well, as we all know, those are the two things that console clients can’t do well – no matter how hard they try.

    Thus I went out to see what the graphical clients had to offer and, boy, was I in for a ride…
    There we have:

    sylpheed[-claws]:
    Fast and zippy GUI, I wanted to love this one. What broke it for me were some awkward UI decisions (display of multipart mails was wierd, to say the least) and bad (read: no) handling of HTML mail.

    thunderbird:
    Feels like a webbrowser that wants to be a mail-client, maybe because that’s what it is. Too slow, unusable for me.

    balsa:
    Buggy. Couldn’t get it to work properly.

    tkrat:
    This is a fun one, I actually used it a while way back before I went for mutt. The UI is really wierd (as the whole thing is written in TCL/TK) but at the same time it’s *very* fast. Anyways, it’s nothing I would seriously recommend for everyday use to anyone today – but can still interesting to play around with on a lazy afternoon. If only for the “Doh!”-effect.

    opera imap client:
    I actually liked this one a bit but the whole opera integration felt wrong to me because I’m not normally using the opera browser. If you *are* using the opera browser then the integrated mail-client is definately worth a look.

    kmail:
    The closest contender to evolution for me but I couldn’t get used to the UI and fonts. Too many bright colors, ugly icons, and not customizable where I wanted to customize. Most importantly I found no way to customize the actual message-view and message-composer to my preferences, both remained with too much visual clutter for me to get comfortable. Anyways, if you like the UI then you might prefer kmail over evolution.

    evolution:
    Well, here I finally settled. It somehow manages to get everything “just right” (for me). Everything is in the right place, the search works as expected (without the UI clutter of kmail), the imap handling is fast and robust, PGP support is just wonderful and, well, the whole thing just *looks* good out of the box.
    My one pet peeve with evolution is that it doesn’t let you change your “from”-address on the fly when composing a Mail. This can be a hassle when dealing with adhoc identities (e.g. for mailing lists) but they promised to fix that in a future version.

    Anyways, I strongly suggest you give evolution and kmail a spin. In my opinion these two are the only two serious contenders in the “graphical, IMAP capable mail client” department today.

    Comment by Moe — 17 Aug 2008 @ 14:32

  14. Mutt dev versions cache headers and bodies… and should scale much better to large mailboxes.

    Otherwise a fetchmail cache or elm on the remote server are good solutions too.

    Comment by Stephen Paul Weber — 20 Aug 2008 @ 13:02

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress