How UNIX Email Works

In general, each UNIX computer has two kinds of programs that handle mail:

There are lots of user agent programs and there are several common transfer agents. The Figure How a mail message gets from A to B is a diagram that shows what happens when you send a message. Your user agent collects the message and gives it to your computer's transfer agent. Your transfer agent either delivers the message if you're sending it to someone on your computer or sends the message across a network to another computer's transfer agent. Then the person you sent the message to runs a user agent to bring in the message from the system mailbox, read it (view graphics, hear sounds, and so on) -- and maybe also print the message, reply to it, delete it, etc.

Figure: How a mail message gets from A to B

hammgfat.jpg

Email Transfer Agents

Mail transfer agents (MTAs) are complicated programs. They have to understand all kinds of nasty details about message addressing, networks, error handling, and other functions. Some typical MTAs are sendmail and MMDF. This book doesn't cover transfer agents.

Email User Agents

If you send and receive only a few email messages, you probably don't need to learn much. Almost any user agent will do (and there are a lot of them). MH and xmh are fine for beginners: there are just a few basic concepts and commands to learn.

But when you start to do more with email, you'll want a user agent that saves you time, lets you organize messages the way you want to, and helps you find messages you've stored. You'll probably want to automate routine work. You might even customize your email setup so it works exactly the way you'd like it to. This is where advanced, flexible systems like MH stand out.

Here's a quick comparison of user agents.

Monolithic Mail Agents

Most user mail agents are monolithic: you're in the mail program until you quit out of it. To start the program, you type its name, like mail, at a shell prompt. (The shell prompt is shown as a percent sign (%) here; your prompt may be a dollar sign ($) or something else.) Then that program takes over -- it reads and executes all the commands you type until you use its quit command.

For example, here's how you would read, print, and delete two mail messages with the standard UNIX program named mail:

    % mail
    Date: Mon, 09 Jan 1995 07:53:55 EST
    From: nancyo (Nancy O'Leary)
    To: jdpeek
    Subject:  meeting

    I'm free at 3 today.  Is that okay?

    ? s toprint
    Date: Mon, 09 Jan 1995 08:54:22 EST
    From: biffj (Biff Jameson)
    To: jdpeek
    Subject: the meeting

    I can be there at 11 or 3 today.

    ? s toprint
    % lpr toprint
    % rm toprint
    
You show the first message on the screen. At the first prompt (which is a question mark (?) in this program), you give the command to save the message in a file named toprint, which also automatically deletes the message. (You're saving to a file because you can't print directly from this particular mail program.) You read and save the next message in the same file toprint. The mail agent automatically quits because it's given you all the messages. Then you print the messages you saved and delete the toprint file.

Most mail agents have more commands built in. For instance, many have a command for printing a message directly. A lot can send a reply to or a copy of a message. Some let you organize messages into groups. Most also let you type a single UNIX command without leaving the mail agent: that's called a shell escape.

Monolithic mail agents keep all of the messages in your system mailbox or a file in your account named something like mbox. These are single files which hold all mail messages together. The messages are separated in one of several ways. The mail agent knows how to parse (split) them into separate messages, but this format makes it harder to do complex things like rearranging the order of the messages.

MH

Here's the same example using MH. (nmh, the new MH, works the same way.) Because MH commands aren't part of a monolithic mail agent, you type all the commands at the shell prompt:

    % inc
    Incorporating new mail into inbox...
       1+ 01/09 Nancy O'Leary      Meeting<<I'm free at 3 today.  Is that
       2  01/09 Biff Jameson       the meeting<<I can be there at 11 or 3
    % show
    (Message inbox:1)
    Date: Mon, 09 Jan 1995 07:53:55 EST
    From: nancyo (Nancy O'Leary)
    To: jdpeek
    Subject: meeting

    I'm free at 3 today.  Is that okay?
    % next
    (Message inbox:2)
    Date: Mon, 09 Jan 1995 08:54:22 EST
    From: biffj (Biff Jameson)
    To: jdpeek
    Subject: the meeting

    I can be there at 11 or 3 today.
    % show 1 2 | lpr
    % rmm 1 2
    
Because MH commands aren't part of a monolithic mail system, you can use them at any time; you don't have to start or quit the mail agent. It's fine to mix other UNIX commands between your MH commands, to leave your mail for a while and do something else, and to work at several terminals at the same time. Because you use MH commands from a shell prompt, you can use all the power of the shell. For instance, I used a pipe to send the output of the show command to the printer directly. I removed the two messages after sending them to the printer.

If your shell has time-saving aliases or functions (and most do), you'll be able to use them with MH. And because MH isn't a monolithic mail agent, you can use MH commands in UNIX shell scripts or call them from programs in languages like C or perl.

Unlike most mail agents, MH keeps each message in a separate file. The filename is the message number. To rearrange the messages, MH just changes the filenames. MH can use standard UNIX filesystem operations such as removing, copying, and linking on its messages. The message files are grouped into one or more folders, which are actually UNIX directories.

The MH setup has a lot of advantages. A significant disadvantage is that it takes more filesystem space to store the messages. See the Chapter Key Parts of the UNIX Filesystem for an overview.

nmh, The New MH

After almost twenty years, development of MH seems to have stopped. Most activity is with nmh, the "new MH". Although nmh is mostly backward-compatible with MH, its user interface is evolving. And the nmh internals are becoming a lot different than MH: old limitations are being removed, security is improved, and installation is much easier.

This book explains differences between MH and nmh at the place that seems the most logical to me--usually in the general introduction to a command or feature. For a concise list of user interface changes, read the file DIFFERENCES in the top-level directory of the nmh source tree. (You can also compare the MH and nmh manual pages for a particular command. But the nmh manpages tend to be more complete--and to document MH features that weren't well-documented before.) The ChangeLog file in the top-level directory of the nmh source tree has a fairly detailed list of changes, version by version, as nmh evolved.

Front Ends to MH

The xmh, MH-E and exmh programs are something like a monolithic mail agent; they each have an interface with a limited set of commands. But they actually run MH commands for you; if you need to do something that you can't do with the interface, you can always use the MH command instead. MH-E, exmh, and xmh are examples of what I call a front end. A front end is a program or set of programs that is an interface to MH commands. They let you do some of the most common things you need from MH, usually by pressing a single key, clicking a button, or using a menu. In fact, if you know how to write a program in some UNIX programming language -- such as the Bourne shell, Perl, or Tcl -- you can write a front end to MH. One Chapter of this book has tips for programming with MH.

The Figure below shows typical sessions with MH, xmh, MH-E, and exmh. If you decide that a front end to MH (like xmh) is right for you, it's still a good idea to get familiar with the rest of the MH commands and features. That's because there's a lot in MH that you might need -- to make your email use easier or more efficient -- that your front end may not let you do easily, if at all.

Figure: MH and front-ends

mhfroend.jpg

[Here is a more-detailed (higher resolution) version of the figure above.]

xmh comes with the X Window System from the X Consortium. It's built with standard parts of X. If you're familiar with X and know how to customize the X Toolkit, you'll feel right at home with xmh. Even if you don't want to customize xmh, the "out of the box" design makes it easy to use MH commands without using the UNIX command line.

If you use the GNU Emacs editor, or you use a terminal that doesn't "do windows," MH-E can be a great choice for an MH front end. It gives you all the power of GNU Emacs -- including the ability to divide a standard non-windowing terminal into multiple windows. Many of the commands take only a single character.

The exmh interface looks something like xmh. It also runs under the X Window System. But instead of the X Toolkit, exmh is built with Tcl/Tk. By default, exmh is far more powerful than xmh. One major difference is that exmh can read and send MIME multimedia mail. But, while xmh is stable and hasn't changed much in the last two major releases of X, exmh is evolving quickly. If you aren't interested in being on the "bleeding edge" of email technology and updating your software fairly often (as bug fixes and new versions are announced), exmh may be worth watching from a short distance away.

There are many other interfaces to MH as well -- too many to mention here. You can read brief summaries about them in the FAQ, the Frequently Asked Questions document that is posted regularly to the Usenet newsgroup comp.mail.mh. In fact, the FAQ contains so much good information that it could be a part of this book. But, because the FAQ changes so often, we thought it would be better just to tell you how to get it.