Author: Joe 'Zonker' Brockmeier
In compiling my list of test candidates, I tried to be as complete as possible while including packages that are still maintained and require less than heroic efforts to obtain and use. Mail User Agents (MUA) that require exotic dependencies and too much hand-tweaking to compile were out. I left out Elmo because it has not been updated since 2004, its Web site is clearly unmaintained, and I received no response to email I sent to the developers about Elmo’s continued development. That’s a pity, because Elmo looked like a promising mailer. Elm‘s development seems questionable as well; I couldn’t find packages for any of the distros I use regularly, and the configuration script is arcane and tedious to the point of frustration.
Pine
I started off with Pine, since I had experience with it in the past, and I thought I’d see how it stacks up now. Pine was created at the Computing & Communications department at the University of Washington in 1989.
Pine ships with its own editor, Pico, and filesystem browser, Pilot. Pico and Pilot are standalone applications, so you can opt to use them outside of Pine if you wish.
Pine is reasonably easy to use for a text email application. Each of its screens has a helpful menu that sets out the options that you’d want to use. You can configure Pine using setup menus — which are less intuitive than they could be, but they at least provide a full listing of Pine’s configuration options. Other text mode mailers tend to require poking through man pages and online manuals just to figure out what options are available, and tweaking the requisite configuration file with a text editor.
But some things are harder to configure with Pine than with other mailers. Pine works great when you’re using it on the same system that you’re sending messages from, but setting up SMTP authentication can be non-trivial.
Pine also doesn’t offer any obvious way to set up encryption, though I have found a few HOWTOs and addons to provide GnuPG functionality when using Pine.
Because Pine is not available under a “free” license, many Linux distros no longer ship Pine packages. However, compiling Pine isn’t difficult, and the license is free enough for many end users — if not for vendors and projects that have to worry about patches and security updates.
A new Pine-based mailer called Alpine is under development. To get access to the alpha at this time, you have to join the “Alpine-alpha” mailing list. The developers are only posting information about Alpine to the list as far as I can tell, and even the archives are subscriber-only. I tried the first release, which came out on November 29, but was unable to get it to compile on Ubuntu or Debian.
The good news is that Alpine is being released under version 2.0 of the Apache License. I don’t see any reason why the university couldn’t release Pine itself under the Apache license now, and then release Alpine whenever it’s ready. It would be nice for loyal Pine users if Debian, Ubuntu, Fedora, and other distros could ship an Apache-licensed version without having to wait for Alpine to stabilize.
Cone
The Console Newsreader and Emailer (Cone) is a text-based client that resembles Pine. Its menu layout and keybindings are similar, though different enough to be frustrating for experienced Pine users. Cone uses the Leaf text editor, which is similar to Pico and Nano.
As text-mode mailers go, Cone is full-featured. It includes IMAP support, built-in support for mail signing and encryption, support for multiple accounts, autosave for mail, mail tags, and a set of tutorials for using the mailer.
Cone’s SSL support isn’t perfect, though. For instance, when you attempt to connect to IMAP over SSL, Cone complains that you can’t initialize the encrypted connection because the root authority certificates are not installed, and gives the option of aborting the connection or appending “/novalidate-cert” to the server name and using the server without validation. It’d be a Good Thing™ if Cone actually gave a useful error message and told the user what would be required to install the root authority certificates.
Cone is another text mailer that you’ll probably have to compile from source, as it’s not included in most Linux distros. Unlike Pine, its GPL licensing is not objectionable to free distros, but it’s not popular enough to make it into Debian, Ubuntu, and other distros.
Mutt
These days, Mutt is probably the most popular text-based MUA for Linux distributions and *BSD variants. The reasons for its popularity aren’t hard to discern. It’s GPLed, so there’s no licensing issue as with Pine. It’s full-featured, and has support for IMAP and POP3, several mailbox formats, control over mail headers, PGP and MIME support, and much more.
Mutt’s flexibility also offers a lot for an audience that’s likely to want to use a text mode mailer. Mutt’s keybindings can be configured via the .muttrc configuration file, and you can create macros to reduce the number of keystrokes it takes to do something (like saving a message or switching between folders) or send messages to external programs such as Bogofilter.
Like Pine, Mutt displays a menu of options at each screen, so you can see the most common options. Mutt lists only a few options on each screen; to see the rest of the contextual options, you can press ?. This screen isn’t newbie-friendly, because it throws a gob of options at the user all at once, and sorting through them can be a challenge. However, Mutt does seem to have a lot more options than Pine, which is an upside in the long run.
The downside to Mutt, when compared to Pine or Cone, is that it doesn’t offer any internal configuration utilities. If you want to set up an IMAP account or change your From headers, you have to do all the tweaking in the .muttrc file. This means that new Mutt users have some pain in store in the short term, but Mutt can help them be more productive in the long term by customizing the application.
nmh and MH-E
The New Mail Handling System, or nmh, offers an unusual way of managing email. Typical MUAs like Mutt present a single interface, and you fire up the program, read mail, send mail, file messages, and do any other mail management from within that interface.
Nmh, on the other hand, is a collection of programs that perform different tasks. You don’t run nmh and receive a mail interface; you use show to display a message, next to display the next message, prev to display the previous message, comp to compose a message, and the list goes on. Nmh has more than 30 individual commands for dealing with mail.
A typical example of using nmh to read mail might be running inc to incorporate mail from the mail spool into your mail folder, then running show to display mail, prev to see a previous message, and then repl to reply to a message. This is all done from within the user’s normal shell, rather than from within a mail program.
Nmh assumes that you’ll be pulling email in from the local spool, so you’ll need to use Fetchmail, Getmail, or another tool to grab mail and deliver it to your local system if you’re reading mail from a remote location.
I can’t really recommend nmh as a mail client. It’s seriously non-intuitive and not likely to appeal to many users who aren’t already familiar with the original Message Handling utilities. but if you happen to use another MUA with MH mailboxes, then you might want to look into nmh’s utilities for use working with messages in scripts.
If you’re an Emacs user, you might try MH-E. MH-E is an Emacs interface to MH, which provides a slightly simpler way to interact with the MH system. I say “slightly,” because in my short experiments with MH-E, it seemed almost as unintuitive as using nmh utilities directly.
After test driving all the different MUAs, I decided to stick with Mutt. By configuring Mutt to use the MH-style mailboxen, I can use Mutt and Sylpheed with the same set of mail folders and not have to give up a GUI mailer entirely to also use Mutt.
