Your editor's desktop system is currently running Fedora Core 2,
mostly as a result of that distribution's combination of near-bleeding-edge
software and the x86_64 architecture. There is much that is good about
Fedora, but your editor was more than disconcerted to find out
that nmh, the current form of the MH mail client, was no longer included.
This is not an isolated point of view; a threat
to write a Grumpy Editor column on this topic still yields an occasional
message of support. This is, indeed, an ideal topic for such a column; the
MH mailer, which was first put together in the late 1970's, still has
lessons to offer the current crop of mail clients.
Your editor will have to request some patience, however. A proper review
of mail clients will take more than one column, along with a significant
amount of time. Those wanting an instant review of bleeding-edge graphical
mailers will have to wait a while; this column, instead, will attempt to
provide an introduction to the topic by looking at the standards set by MH.
MH was, at the outset, different from any other mail client out there, and
it remains different. Mail clients tend to be classic examples of monolithic
design; everything (one hopes) that a user might want to do with electronic
mail is built in to one single, large application. The designers of MH
concluded that this design did not fit well with the Unix way of doing
things, which is to have a relatively large number of small programs, each
of which does one thing well. As a consequence, MH is not one program, but
many: the current nmh distribution contains 39 separate utilities.
When dealing with MH at this level, the user is never "in" the mail system;
instead, all commands are typed directly to the regular shell. The
brings in new mail; scan lists a folder; show,
next, and prev display individual messages; repl
generates a reply; rmm, refile, and others dispose of
messages; and so on. There is a command (pick) which can perform
complicated searches through folders. All of these commands (and many not
mentioned) manipulate a global state, giving the full set the feel of a
single, integrated application.
MH folders, incidentally, are also unique: they are simply directories
containing each message in a separate file. A number of modern mailers
support MH folders, though usually not as the preferred format.
The result of this organization is that it is possible to build software on
top of the MH primitives with great ease. Over the years, developers have
created numerous interfaces for MH, including xmh (an old graphical
interface still shipped with XFree86), exmh (a Tk-based graphical client),
and MH-E (an emacs-based
interface favored by your editor). The scriptability of the MH primitives
also makes it easy to integrate the mail client into any other
task-oriented software that the user may need to run.
The availability of multiple interfaces to the same mail system is nicer
than one might think. A fancy, graphical interface may be useful when one
is in the office and near to the mail system. When one is stuck behind a
slow network connection (a GPRS link from a nearby mountain, say), the
command line interface may be the only way to work through a batch of mail
quickly and with minimum pain. There is great value in not being locked
into a single mode of interaction with the mail system.
Unfortunately, MH is showing its age in a big way. The nmh effort appears to have stalled
for lack of developers; it shows no commits to its repository since 2003;
the 1.0.4 release - the latest available - came out in April, 2000. A 1.1
release candidate was posted in January, but nothing has happened since
is support for MIME in nmh, but that support is awkward at best. The exmh
front end does MIME, but there has not been an exmh release in over a
year; it, too, is getting harder to find in distributions. MH works with
POP, but there is no IMAP implementation in sight. In general, MH is old,
unmaintained, and fading from the scene.
This is a shame, because MH got some things right decades ago that modern
mail client developers still seem to miss. Your editor does not want to
funnel his email into a single-interface black box. He wants to be able to
manipulate mail from his desktop, over a modem link, or running through
mindterm on a Windows "email garden" system in a remote place.
It should be possible
to do anything with email - even things that the developer of the mail
client might not have thought of. It must be possible to make connections
between the mail client and the LWN site code. It should be possible to
manipulate messages and folders with shell scripts and programs without
great pain. The client should be a powerful tool for working with
electronic mail, but it should be just the beginning point, rather than the
Your editor is now shopping for an email client which can replace MH. This
process could be a long one; understanding a mail client well enough to
write about it takes a significant amount of effort. The process may also
require delving into other parts of the larger email system, such as IMAP
servers. Watch for a series of upcoming articles over the (northern
hemisphere) summer as this journey unfolds.
As a down payment, here is a quick look at the MH-E interface. Your editor
has used MH-E for years; it does a nice job of combining the power of MH
with an efficient keyboard interface and the usual benefits of integration
with the editor itself. Your editor has long assumed that MH-E has
suffered the same fate as MH; the version shipped with the current
GNU emacs distribution dates from 2000. This version of MH-E has many
shortcomings; it does not even deal with simple things like mail in the
quoted-printable encoding correctly.
So it was interesting to find out that that MH-E hackers have, in fact,
been quite busy recently. Version 7.4.3, currently available from the MH-E site, includes a number of
new features. It performs threading, has proper MIME support (see
screenshot, right), indexed searching, and more. It uses the capabilities
of modern versions of emacs to display images and such within the editor
itself. There is also a general interface to spam filtering systems,
allowing the user to easily train the bayesian filter of his or her
It is, in general, a vastly superior implementation of MH-E, and the upgrade is
easy; if you are an MH-E user, you probably want to look at the current
On the down side, enough commands have been changed to drive a long-time
MH-E user nuts for a while, and the documentation is, um, missing. The
default colors show a distinct lack of restraint or concern for human
factors. It also
has adopted the gnus habit of replacing smileys and such with its own
built-in icons - behavior which is amusing for about two messages before
you realize you'd rather just see what the other person wrote.
Fortunately, this behavior is easily turned off with a configuration
The new MH-E is apparently slated for inclusion in emacs 21.4. It is good
to see that significant work is going into this mail interface; MH-E is too
good to allow to slip into obscurity and decay. The fact remains, however,
that MH-E is built on a foundation which has not seen any significant
maintenance in years.
(For more information on the history and philosophy behind MH, see the
classic (if quaintly titled) paper "MH: How to process 200 messages a day
and still get some real work done," available in PostScript format).
to post comments)