Mail and Sendmail Administration: Part 1
Bruce H. Hunter
Mail has two sides -- the obvious front ends like the
commands and the mysterious mechanisms that get mail
of what goes on in UNIX is a mystery to the users, but
in the case
of mail, and particularly sendmail, the mystery may
even extend to
the systems staff. Let's see if we can shed a little
light on what
makes mail work.
From the user perspective, mail starts with the mail
commands, which are programs in their own right. The
first, and most
familiar, of the mail commands is /usr/ucb/mail (most
just use mail, but in fact they are using the Berkeley
The AT&T version, /bin/mail, is still extant, but
lacks some of the features we have all come to love
in the Berkeley
versions, relatively few people use it. Both of these
mail and (seem to) deliver mail, though actual delivery
separate, I will explain later.
Mail at its simplest is intended for mail collection
on a local system. The need for a more sophisticated
arose when UUCP appeared. With UUCP the issue of address
had to be taken care of. There were now addresses like
% mail jaeger!bhunter
With the form system!user, the "!" or
bang character separated the system name from the user
name (in that
But UUCP is a switched network, which means that it
uses the telephone
lines. Very soon users were using mail hops, sending
mail by way of
other systems to keep down the cost of transmission.
One system would
send to another and that one to another until the message
be delivered or time out and get erased. Now the form
Berkeley added new dimensions and problems to mail.
programs are readily customizable, both for the user
and at system
level. The customizing is usually done with special
files, and mail
is no exception.
A user's mail command gets customized in the users $HOME/.mailrc.
rc stands for run command, and mailrc is the run command
that tells mail how to behave. It is here that aliases
set up and features are defined. Options that can be
the use of vi as the editor within mail, mail notification
(biff), and a dozen or so others like cc and subject
lines. Here is a very simple .mailrc file.
17% cat .mailrc
set append dot autoprint
alias george gsmith@flsm1
alias dave dhill@flsm1
alias chad email@example.com.ORG
alias thegroup chad,dave,george
The set commands set such attributes as append,
which appends new mail to end of the user's mail file;
which indicates that a period on a line (by itself)
is the EOF; and
autoprint, which prints each file to the screen as fast
the last is erased.
Another innovative Berkeley file, the ~/.forward
file, forwards user mail. The file only need contain
the next name-address
pair in standard UNIX firstname.lastname@example.org_name.org_ext format.
The Constituents of a Mail Message
Mail comes and goes in two parts, the message and the
like surface mail. The message is what the user types
in, the envelope
is what we see as header information, plus a little
more. If you are
fast enough, you can occasionally catch an undelivered
piece of mail
in /var/spool/mqueue. In the mqueue directory are two
files for a given message: in the df* file is the message
(data), while in the qf* file is the queue information
The following is a sample of the contents of an mqueue
mfg# file dfAA07738 qfAA07738
dfAA07738: English text
qfAA07738: ascii text
Figure 1 shows a sample qf file. Notice the prefixes
to the header lines:
D the data file name
M message (printed by mailq command)
S sender address
H header definition
E error address
And here's the sample:
mfg# cat dfAA07738
WARNING WARNING WARNING
AUSSIE File Server svr05 down 5-6PM Monday
downtime 60 minutes to add DISK SPACE
And surprise of surprises there is no magic -- just
the message. The two make up the mail message with some
or all of
the header information prepending the message when it
winds up in
[var | usr]/spool/mail/user_name.
The mail agent has two functions: it collects mail and
makes the final
delivery. Some mail agents in current use include /usr/ucb/mail
(the most familiar, BSD mail); /bin/mail (AT&T mail,
original); mailx; mailtool; elm; and mh.
If a mail agent can deliver mail locally, it will, but
computing paradigm almost always involves the Internet
To get mail the through the network requires a mail
such as sendmail, mmdf, or smail. The most well-known,
of course, is sendmail, which originated at UCB and
by Eric Allman.
Once past the mail agent, the message still needs media
in order to be delivered. Mail delivery agents at this
Ethernet-TCP/IP (SMTP); UUCP (circuit switched lines
and /bin/mail (for local delivery).
Basic Mail Files
Mail, like most facilities in UNIX, has several files
The repository for delivered mail is /var/spool/mail/*.
directory includes a file for each user (by the user's
contains the header information followed by the message.
message is appended to the file, and each starts with
"From." As noted earlier, a queuing place
for mail is /var/spool/mqueue.
The error message file is usually here as well.
The Basic sendmail System
All systems but one in a mail "domain" have
a very simple
sendmail (configuration) file. Each will try, without
itself, to deliver the mail to a known host. If sendmail
clearly see that it must use the network for delivery
or if it can't
figure out how to make the delivery, it sends the mail
on to the one
different system, the mail master. The mail master has
a very complex
sendmail.cf file capable of performing the address translation
required for getting mail to a relay host if need be.
Relay hosts have direct connections to the Internet.
the Internet for deliverey are routed to the relay host,
and the relay
host sends it on its way. The relay host works in the
also, receiving and forwarding incoming mail from the
Mail Working with DNS
Maintaining organization-wide host tables became a nightmare
time ago, so most sites have begun to use DNS. With
DNS each local
domain takes care of its own host files and the DNS
merges all the local host files to maintain a virtual
table that is accurate and up-to-date. sendmail has
with the times and can take advantage of DNS to effect
An Introduction to sendmail.cf
The key to sendmail is the configuration file(s) sendmail.cf,
which routes mail by analyzing mail addresses and rewriting
final delivery. Given the universe of possible addressing
used now and in the past, this is no small task. Most
of us have gotten
used to seeing the format
but how about those UUCP addresses like
The ordering is different and so are the delimiters.
It's the mail delimiters like "@" and "!"
and "::" that make it difficult to go from
scheme to another. sendmail manages this through the
typically found at the beginning of sendmail.cf files.
delimiters definition is one of the first and serves
to show how definitions
work. The single-character mnemonic operator D is a
What is defined is called a macro and the macro for
o. Therefore in sendmail.cf the definition of the o
delimiter macro is:
Note the lack of white space -- there is nothing
to make this easy to read; parsing is done by having
only one character
for each mnemonic.
To reiterate, mail is sent in two parts, the message
and the envelope.
The header information must deal with addressing schemes
must do the address transformations. Table 1 shows a
few of the
many possible addressing schemes as well as the format
they must be transformed in order to work on UNIX and
and other mail and routing agents.
Performing these address transformations is not a simple
process involves dozens of macros and definitions, several
governing how the transformations take place, and a
score or so of
mnemonics and variables, as well as a few constructs
One observant system programmer noted to me that sendmail.cf's
notations, rules, and rule sets are not unlike a make
Internal Names (Canonical Form) and "Focus"
Mail addresses must have a consistent form while internal
In addition, a "focus" -- represented by the
operators -- is added to underscore, in a virtual sense,
the address. The following are internal names with focus
the domain part of the name, leaving the user and host
names and the
token @ unfocused.
The form represented here is called canonical form.
form is required by one of the sendmail rulesets, ruleset
for message delivery.
Mail Routing Made Sane
Before plunging any deeper into sendmail.cf, I want
at the mail agents again and discuss some of their functions.
do not always know the domain name of the person to
whom they want
to send mail -- and even if they do, they are not likely
the hostname of the recipient's machine. If there are
in an organization, how is one to learn the full email@example.com
name? Part of the problem can be resolved by the company's
domain name service and well known aliases.
If I am in an organization and know the name or acronym
of a department,
why can't I use it to get mail to a user in that organization?
the design tool group is known as CAD, for example,
I should be able
to get to John Smith in that group. This is done, at
least in part, with aliasing. The mail master, a computer
the final gathering and delivery of mail, would have
an alias of cad.
In the host's files it would look like
220.127.116.11 svr08 cad
Now all systems can find cad even though no machine
by that name really exists. Should the mail master move
only the alias would have to be changed (on all systems)
to make it
Mail Aliasing and Mail Groups
Mail aliasing also works at the user's level in the
mail setup files
like ~/.mailrc. These aliases are used to set up mailing
Mail forwarding is done by way of the users .forward
file and through aliases. The ~/.forward file simply
the firstname.lastname@example.org where the mail is to be forwarded.
Aliases may also be used for alternate names (hunter,
A domain-wide list of user aliases can be maintained
via NIS with a single central aliases file that is used
by mail. Traditionally,
this file is /etc/aliases, but if you replace that file
a YP map, mail delivery gets much simpler and more effective.
example, if I have a machine called jaeger, few people
know that name and fewer still will know the name of
the mail master,
svr04. I can use aliases to tie in the two:
To simplify even further, don't have a /var/spool/mail
directory on every machine. Instead, set up one huge
on one server and NFS-mount it to all the domain's systems.
of this aliased to the domain's organizational name
or TLA (three-letter
acronym), all of the following will work:
Mail Setup for Server and Workstations
Mail was originally intended to exist on one system
which would service
all users. Almost all mail was for local delivery, and
any, came in from the outside. Today's paradigm is tens
of workstations using several servers, all to form a
Larger organizations will require several domains. Within
mail could exist with each system having its own mail
spool area (like
usr/spool/mail or /var/spool/mail), but this would create
many problems, among them delivering mail to users whose
are unknown or who move from workstation to workstation;
the domain without knowing the system name; keeping
the /var or
/usr areas from filling up with unread mail; and being
to spool error messages in a single place where they
can be acted
It is easier in the long run to have a single mail server
a system that not only is the mail master but also has
all the mail
on a single disk partition, disk pack, or concatenated
With that system's name aliased to the domain or organization
addressing mail from the outside is painless. That one
has access to the YP aliases map and therefore can find
All that remains is to mount the master's mail directory
on each workstation.
Keeping the directory names simple helps make the mount
mount mlsvr:/var/spool/mail /var/spool/mail
Mail Debugging with mqueue
A large central mail server makes tracking down delivery
easier because it puts all the error messages in one
place in the
mqueue directory. If the master has a problem delivering
message, it will register its complaint in the logfile
(see Figure 2). If a user has problems getting or sending
you know there's no problem with his/her sendmail configuration
check /var/spool/mqueue for error messages. Look at
required to complete the deliveries as an indicator
of potential problems.
Generally speaking, mail delivery is stopped or hampered
recipient system is not up or not on the network; addressing
the wrong user name is used (a solid argument for first
name user naming conventions); or the user-name/address/aliases
combination is not correct in the mail aliases file.
In the next issue (March/April 1993), I'll deal in more
sendmail administration and related issues.
About the Author
Bruce H. Hunter is the co-author, with Karen Hunter,
of UNIX Systems
Advanced Administration and Management Handbook (Macmillan: