Thu, 21 Oct 2004

Complexity makes mutt an ugly dog

I’ve been using mutt as my MUA for quite some time and I like it. Originally I used it with my existing MH mail folders, as I had a vast store of mail that I wanted to preserve. One of the reasons for adopting mutt was its inbuilt support for MH folders.

However, I have also been considering switching to Dan Bernstein’s maildir mail storage system to allow safe storage on NFS. Builtin support for maildir was another reason for trying mutt.

Recently, as part of an abortive attempt at using IMAP, I wrote a small utility to convert my MH folders to maildir and I have been working with mutt and maildir for the past couple of weeks. But I have become irritated with some of maildir’s deficiencies and this entry is inspired by that.

As is common with Bernstein’s great ideas, the mechanics of his solution and the solidity of its implementation are hard to fault—but there are gaping holes in the aspects of it that affect the individual user. My principal complaint is in the way he has reserved names that I want to use. Each folder is required to have three sub-directories, named “tmp”, “new” and “cur”. The directories really are needed, but it’s idiotic to steal from the name space that users might want. At the very least, they should be called “.tmp”, “.new” and “.cur”, as the maildir format explicitly suggests that names beginning with a dot be ignored by client programs.

Since I’m going to have to write a working IMAP server from scratch, I thought I might create a gbmaildir format and use that. As a first step, I then thought I might as well make the small change to mutt so that it could work with this updated maildir scheme.

Usually, when I’m about to make a change like this to some existing software, I browse the source code—to get a feel for how it was written and to reach some conclusions about the ease of accomplishing my goals. Since I use mutt every day, and since I entrust it with many tens of thousands of stored messages, I don’t want to introduce any instability into it. And since mutt, like all MUAs that I’ve ever heard about, is full of security bugs, I want my patches to be simple and clean so that I can reapply them easily each time the mutt maintainers issue a new bunch of bug fixes.

It turns out that mutt is huge. There are almost 75,000 lines of C code—enough to fill over 1,000 A4 pages in 9 point Courier and far too much to just read. To put this into context, the entire qmail suite, including daemons, ancillary programs, etc., is only 16,644 lines—including Bernstein’s replacements for most of the standard libraries and my various patches to qmail. Anyway, mutt is far too big to just read. And, once I started looking for the bits that handled maildirs, I discovered that it’s also a total mess.

Imagine that you’re writing a MUA and you know, as you must if you’re awake, that you’ll have to handle multiple mail storage formats, both local and remote. If you’ve got half a clue, you’ll have an abstraction layer between your code that presents messages to the user and the storage component. Then, when new storage schemes appear, you just add some simple code to implement them. With such a design, I could have made my changes in a few minutes and been quite confident that I hadn’t broken anything. But it’s not like that at all. And it’s such a mess that I won’t bother modifying it. Instead, I’ll write my IMAP server and test mutt against it. Let’s hope that it can make a decent fist of that. Yet another piece of open source software that should never have seen the light of day.

Posted at: 20:38

Path: /software/discuss   |  permalink