• Home
  • Blog
  • Email clients... do they all suck?

Email clients... do they all suck?

Vincent Danen

May 22, 2006

Really... it is 2006 right? Email's been around for ages, so why are email clients still so crappy?

Last August I switched from the OS X Mail.app (in Tiger) to mutt because Tiger's Mail.app was too stinking slow. I get lots of mail... I mean lots of mail. My incoming mbox for this month so far is 102MB. The number of messages in that mbox? 8427. That's roughly 400 messages a day. Tiger's Mail was dying under that load (when Panther's Mail didn't... it's due to Mail now using individual files for each message rather than an mbox (thanks, Spotlight)).

mutt was so nice... so fast... so nice... like an old friend. I looked at most of the available OS X mail clients, and all of them were lacking something.. some lacked threading support (WTF? are you kidding me?!?), some worked only with PGP and not GnuPG, some just plain old sucked.

Well, recently due to some problems at the colo with a bad switch, mail deliveries from here have been somewhat problematic and I was getting hit by the default OS X maximum-number-of-processes-per-user issue (only 100 procs per user), which was quickly being eaten by silly little sendmail processes (using postfix here to relay the mail from the local machine through the colo, for it to deliver to the end recipient). So, I figured... it's been a year, I'll see how some things look. Well, the obvious first choice was Thunderbird. The one major drawback to Thunderbird is the lack of integration with the OS X address book (and keychain). But I was willing to look past that. Well, having played with an imported my mail and everything into Thunderbird over the last day, I can tell you that it sucks far more than just lack of AB integration. What an awfully slow, strange, and (quite frankly) ugly program! Ick.

So I've cranked up my maximum procs from 100 to 512 (softlimit) and 2048 (hardlimit). If nothing else, those sendmail threads won't be wrecking my terminal sessions. And it's back to mutt. I don't even have the patience to try anything else.

Thunderbird may work great on Windows, considering it's major competition is outlook which is even worse, but on OS X it's rather awful. And don't even start with the "Linux has better mail clients" because it doesn't... kmail is an awful program (and it inherits the rather distastful KDE look-n-feel), and Evolution while being ok, just doesn't do it for me. Been a while, so maybe it's better, but I really don't feel like reading mail on my laptop... I'd rather use my desktop machine.

Maybe next year there will be better mail clients. I just don't get how a CLI client like mutt is so far superior to all these new/new-ish email clients that are out there. Is it that hard to write a good GUI client that isn't slower than... well... I won't say. Anyways, it's slow. I'll take my fetchmail/procmail/SpamAssassin/postfix/mutt setup any day over what's currently available. It just astounds me as to what people are willing to settle for. I guess if you don't deal with email that much you probably don't care, but email is my connection to the world and work (can't really pick up the phone to call fcrozat to ask him something about a firefox security issue). It has to work and it has to be a no-brainer and it has to be fast.

I have yet to find a good GUI client to fill that criteria. The only GUI mail client that I've ever really liked was PMMail/2 for OS/2... now that was a damn fine email client.

Oh, and if you're on OS X (Tiger) and ever see a message on the console or terminal about not being able to fork and "resource temporarily unavailable", wander over to here and read this: http://ruminate.net/pdm/mt/os_x_tips/os_x_tiger_104_process_limits_solution.html . Very good.

The basic jist of it is to use "launchctl" to determine what your limits are set to (ie. "launchctl limit") and then create a /etc/launchd.conf file that contains:

limit maxproc 512 2048

which will bump up the softlimit and hardlimit respectively to 512 and 2048.

Leave a Comment

Comments use MarkDown. Need help? MarkDown Cheatsheet