RSi Solutions Ltd

Why Mutt

``All mail clients suck. This one just sucks less.''
- Michael Elkins (Mutt author), circa 1995

Skip the waffle and find out all about Mutt.

Mail clients that suck

• Netscape Mail sucks because the GUI is so badly designed, the operation obscure and the performance as bad as the rest of Netscape. It also allows clueless newbies to easily translate their messages into HTML, attach "v-cards" that are no use to anyone else, include attachments multiple times and send multiple copies of their badly-formed messages, all without flagging how much this is going to irritate the recipients. (See also Netscape News.)
• MH always sucked. It's designed for thick biology students at universities and drives any half-competent person up the wall.
• I used elm briefly eight years ago when I was young and easily impressed by programs that tried to turn ttys into GUIs. But it got to me eventually.
• If you must use a GUI mailer, Eudora on the Mac is a gorgeous, sexy client.
• Rmail/VMail suck because you'd have to be an Emacs user to appreciate them. Not bad if you are though.
• DTmail isn't bad because it supports MIME and turns URLs into active links. But it isn't very configurable and CDE as a whole sucks.

Mail clients I've used

I started out with Berkeley mail, because no one offered me anything else. Hence I was forced to get used to all those single key commands and obscure tilde escapes, which wasn't a bad thing. Later versions of BSD mail, such as the one in SunOS, at least let you change the indent prefix to something other than TAB (unlike the Ultrix one, feh).

Then the Computer Unit at Aber decided, in the wisdom, to change everything to MMDF format, and the mandated - only - way to access your mail was via POP. Which would have been fine, except there were no decent POP clients for Unix. They tried to ram MH down everyones' throats, or even XMH (Satan's favourite mailer), with Eudora for Windows elsewhere (at the time, the Win version was used to promote Macs, ahem). This was before Fetchmail; the POP snafflers then available were fairly limited things that wanted your password stored in a config file.

At this point, I found MUSH. Mush was like a supercharged Berkeley Mail - worked the same way but much, much more configurable. Unfortunately, the POP support in it was limited and mostly bust, and the program itself was now largely unsupported (the authors moved on to the commercial, GUI version, Zmailer, which they then flogged to NetManage). So I used the PP forwarding mechanism to send everything to a nasty little csh script which copied it to my home directory in good ol' mbox format. It wasn't pretty, it probably had holes through which 5Mb messages could quietly vanish (messages that size are probably bad news anyway), but it worked the whole time I was at Aber.

(Incidentally, SVR4 Mailx isn't bad either, but still not as configurable as Mush.)

Chance, and the lack of anyone to tell me better, allowed me to carry on using Mush at Elsevier, thankfully without the POP shenanigans. During this period, its shortcomings started to become more obvious:

1. Its MIME support was rather shallow, being an afterthought based around Metamail, which itself is rather long in the tooth.
2. There was one annoying bug which I couldn't track down - may have been connected with my version - where the headers on outgoing mail would be corrupted and duplicated further down, randomly.

Time for a new mail client

Nevertheless, I continued to use Mush in lieu of anything better. But the growth of the Web meant that it was being overtaken by events. Mail messages were now more likely than ever to include MIME attachments and URLs, for which I had to exit Mush and start DTmail.

Then, by chance, I came across Mutt. In the interim, someone had finally started work on a new Unix mail client. This one claimed to be a hybrid of Pine (yuk), Elm (yuk) and ... Mush. With decent MIME support and facilities for URL handling. Only in alpha, but still, worth trying, I thought.

Mutt, the mail client

Go straight to the Mutt home page if you're mad for it.

If you're used to tty-based mailers (what else are you going to use via telnet?), Mutt is cool. Unfortunately, it's heavily curses-based rather than command line driven, but you can live with it. Initially, I thought maybe I'd keep Mutt around for the MIME stuff and stick with Mush. But after I'd played with it long enough to configure it more or less as I wanted, I thought, why waste the effort? It does everything Mush ever did, but it has the mod cons and it's under active development.

I'm not going to list all the features here (they're on the web page), but the ones I like are:

• Full MIME support, at hand.
• Adequate POP3 support, although I barely use it.
• Full configuration of reply attributions, headers, etc.
• Mailrc-style config.
• Small, fast and light.

Regrets

1. Mutt is probably too configurable. The sample muttrc is huge, and there are variables and options for everything (right down to what it does after paging a message). Most of them have sensible defaults, but you still have to spend an hour or two settings things up exactly how you want. Also, because Mutt is still alpha, you often need to adjust adjust your configuration for new releases; however, this is often because the duplication and obfuscation is being weeded out.
   There's probably scope here for some sort of curses-based (help me) config tool that gives quick access to all the configurable options, at least for initial setup.
2. There's a basic Muttrc which supposedly emulates Mush, but it provides only a few commands, mostly the ones I never used. I think this is something I'll have to tackle myself, but I suspect it will involve changing most of the default key bindings.
3. POP support probably isn't Mutt's job when there are multi-protocol handlers like Fetchmail around, so it might as well be ripped out and replaced with hooks to run something external at user-initiated or regular intervals.
4. It would be nice to see basic xterm support ala Tin. I think this may have been in Mutt at one time, but was removed for some reason. Still handy now and then though.
5. The worst thing about non-GUI tools: the lack of visual help while learning. Command completion? Some sort of persistent command line entry mode? Quick, pop-up curses menus of contextual options? Maybe a help mode where pressing each key produces a description of its action without triggering it.
6. The manual needs work; much of the information is scattered across the pages rather than being cross-referenced appropriately. For example, finding out how to stop MIME attachments being recorded in the outgoing file took a while (fcc_attach variable) because the info wasn't in the MIME section.
7. Facility to call an external pager for messages longer than a certain limit. The internal pager is painful for more than two pages.

Conclusion

Note