"Linux Gazette...making Linux just a little more fun!"

There are many packages that can supply standard mail services under Linux. Basically the UNIX/Linux e-mail model involves MTA (mail transport agents), MSA (mail storage/access agents) and MUAs (mail user agents). There are also a variety of utilities that don't really quite fit in any of these categories.

Under Linux there are several MTAs including sendmail, the most common across most forms of UNIX; and D.J. Bernstein's qmail and Wietse Venema's Postfix. These accept and relay mail. This sounds quite simple, but in practice it can be quite complex. There are a number of routing and masquerading options that can be set by administrative policy --- and these amount to programming languages that filter and modify the headers of each message as it is relayed. In addition the process of routing mail and finding user mail boxes (mail stores) can involve arbitrarily complex interactions with various directory services (DNS, passwd files, NIS, LDAP alias/dbm files, and all manner of custom databases).

These days MTAs also have to implement anti-spam features that amount to access control lists and rules about the address formats (to and from headers) that are allowed from specific domains and address ranges. (Those generally also involve queries on tables or directory services, including those like Paul Vixie's RBL (real-time blackhole list: or MAPS, mail abuse prevention system) and it's ilk, like Dorkslayer/ORBS. Recently, MTAs are being increasing required to enforce other policies and implement anti-virus/anti-worm features.

The most common cases are easy enough to install and configure. However, all that power and flexibility comes at a price. As your organization chooses to tailor its MTA to meet your special routing, nomenclature, security and anti-spam requirements you'll require more sophisticated configuration options and many of those will involve choreographing complex relationships between your MTA and various other subsystems (such as any LDAP and DNS servers you use).

Once you've selected, installed and configured an MTA you generally will also need to go through the same process for an MSA. Most organizations these days don't deliver mail directly to desktop client systems. They store the mail on servers and have the users fetch their mail via POP or IMAP. There are various protocols for managing a mail store but the only two that really count these days are POP3 and IMAP4 (there are also older versions of each of these protocols, of course). As with the MTAs there are a number of programs (daemons) can can provide each of these services. Most MSAs can work with any common MTA. In addition these systems usually do locking and/or use other mechanisms so that multiple MSAs can be concurrently in use without conflict.

That means that you can have some users who access their mail via POP, while others use IMAP and others might even log in and use a local MUA (such as pine, mutt, or elm). Individual users can swith from what mail access method to another, usually without requiring any sysadmin intervention. Clever users can often bypass the normal MSA/MUA tools and use normal UNIX commands (like cp, and mv) and FTP or rsync to move their mail around. (This is generally too clunky for normal use, but can be quite handy when fixing corrupted mailboxes, etc).

The first time I was ever called upon to set up a POP server on an existing general purpose Linux server, I was surprised to find that there was no work required. A POP daemon had been installed and enabled when I did the initial OS installation; I had disabled it (commenting out a line in the /etc/inetd.conf file) during my routine system hardening. So "setting" up the service simply require that I uncomment one line in one file, and restart one service/daemon.

IMAP is similar. Where POP generally transfers mail to the client system and removes it from the server, IMAP allows one to store the mail on server side folder, and the copies on client systems are essentially a cache or "working copy" --- this usually costs more server storage space, but it allows the IT teams to focus on server backup/recovery and allows the client systems to be considered more-or-less disposable. IMAP can be used just like POP (where the mail is expunged from the server by the clients after delivery). Operationally, there isn't much difference. Both services are normally started by inetd (the network dispatcher service; Linux's "receptionist" if you will).

A POP or IMAP server can run for years, serving hundreds, even thousands of mailboxes and users without ever requiring any special attention. Usually you're users or their e-mail correspondents will occasionally do something stupid, or some software they run will exhibit some bug that will require the system administrator to go in and do some troubleshooting or cleanup.

For example, one time I had some complaining that his POP e-mail was broken. I found out that one of his customers had sent him a bit of e-mail with a 100Mb file attachment! (It was a Netware crash dump image). This was bumping into some diskspace and speed/capacity limits on the old 32Mb 486 what we were using to serve mail to him and the other 50 people in the department. I fixed it in a few minutes with some shell commands, used some command line tools to uudecode the attachment back into a file which I put in the user's home directory. I tossed together a quick throwaway script to extract the rest of his e-mail by building a new mailbox for him. (mbox files under UNIX are simple text files. qmail mail stores are directories with individual small text files, one for each message). Any competent intermediate system administrator could have done the same thing.

So most of the problems you might encounter with MSAs and MTAs can be fixed with text editors and common UNIX filters and utilities.

There are many MUAs that will work with POP and IMAP servers, including Microsoft's Outlook. Under Linux many people use 'fetchmail' to fetch their mail to a local mail spool (mailbox). Then they can use any MUA (elm, pine, mutt, MH/exmh, EMACS' rmail, vmail, mh-e, gnus, and the plethora of GUIs like Balsa, Mahogany, etc). Many other Linux users choose Netscape Communicator's built-in mail client.

Under Linux and UNIX there are other tools like procmail, vacation, biff, and fetchmail which, as I said before, don't fall into any of the three classic categories (MTA, MSA, MUA) that I describe earlier.

procmail is usually used as a "local delivery agent" and as a mail processing agent. It's generally used to filter the part of the final delivery of a message to its end recipients. This allows a user to write scripts to automatically refile, reject, respond to, forward or otherwise work with selected bits of mail as they are received. (It can also be used to post process mailboxes and as a more general e-mail programming language/library).

(vacation is an old program that can be used to simply provide an automated response to e-mail upon reciept. It was originally used to warn correspondents that the recipient was "on vacation." This can be also done with a simple two line procmail recipe).

biff is a utility to notify a user that mail has arrived. (There are various similar utilities for doing this in GUIs, displaying icons, animations, emitting music or vocal announcements, relaying biff notifications over a network and using various backend MSA protocols, etc).

Copyright © 2000, Jim Dennis
Published in Issue 56 of Linux Gazette, August 2000