What is MH?
MH is a Message Handling system originally developed at RAND, then
improved and widely distributed by the University of California at
Irvine. MH is an MUA designed
with the UNIX
philosophy of ``create lots of small tools that do simple things
well, and provide a flexible way to put them together to do things.''
This tool philosophy is very different from the
application philosophy that some people have, in which just
one program should do everything.
MH is for people who understand why UNIX is the way it is and like it.
If you hate UNIX and wish you were just using a Mac or something else,
forget MH; use Elm or something else.
Why might I consider MH?
MH offers a variety of features, many of them not present (or not as
flexible) in other user agents.
- Non-monolithicity
- Most mailers are monolithic; you ``get into'' the mailer and then
do stuff within it. MH commands are generally issued directly from
the shell; thus all the normal flexibility and power of shell features
(e.g. aliases, functions, history) are still available.
- Modularity
- MH consists of several small programs which perform various
primitive message handling tasks. Naturally, if monolithicity is
desired, it is simple to build a conventional mail application on top
of these tools; mh-e is one that runs
inside Emacs, exmh runs in X under
Tcl/Tk, and many others are discussed in the
MH FAQ.
- Ease of expandability
- Monolithic applications typically work well as long as the task
desired was one anticipated by the application designer, but adding
novel functionality is much simpler in a modular system. It is no
accident, for instance, that MH offered the first (and, thus far,
still the best) support for MIME among
mailers used here, or that MH had the first (and still has the best)
clean interface with implementations of PEM.
- Customizability
- MH offers a real
customization language, not just a screen full of options (most of
them mere chrome) which may be
toggled on or off. You get all the shell power of macros, functions,
etc. as well as a full language for specifying mail processing. You
don't have to learn much of this just to use MH, but all that power is
there if you need it later.
- Non-interactive use
- It is possible (often pretty easy) to perform MH processing in a
batch environment (say, from a shell script.) Most other mailers only
allow simple sending of mail non-interactively.
- Compliance with standards
- MH works with MIME and meets earlier specifications on message
format, message encapsulation, and the like. Some other mailers pay
less mind to such things; for example, it has been eight years since
forwarding standards were
adopted, but Elm still isn't compliant with them. For that
matter, Elm violates some sections of RFC 822.
- Annotations
- When messages are replied to, forwarded or redistributed, an
annotation recording that event may automatically be attached to the
message in question for future reference.
- File-per-message storage
- The silly concept of a ``mailbox'' with many messages is replaced
with a proper directory. This makes MH typically much faster at
handling
folders with large numbers of messages (unlike Elm, where you get to
watch while it counts up the number of messages in your inbox.) Using
ordinary UNIX file manipulation techniques also becomes trivial.
If all that sounds complicated, note that you really only need to
learn 5 commands to start using MH for your mail:
- inc(1)
- Incorporates newly delivered mail into your inbox
- scan(1)
- Lists messages in a folder
- show(1)
- Displays messages
- comp(1)
- Composes new messages
- repl(1)
- Replies to existing messages
So how can I find out more?
Good luck, and happy MHing!
Marc V 12-93