Table of Contents for

sendmail, 4th Edition

The sendmail program is not the only MTA on the block. Others have existed for some time, and new MTAs appear on the scene every once in a while. Here we describe a few of the other major MTAs:

Many other MTAs exist, some good and some not so good. We mention only five here because, after all, this is a book about the open source sendmail.

In its simplest role, that of transporting mail from a user on one machine to another user on the same machine, sendmail is almost trivial. All vendors supply a sendmail (and a configuration file) that will accomplish this. But as your needs increase, the job of sendmail becomes more complicated, and its configuration file becomes more complex. On hosts that are connected to the Internet, for example, sendmail should use the Domain Name System (DNS) to translate hostnames into network addresses. Machines with UUCP connections, on the other hand, need to have sendmail run the uux program.

The sendmail program needs to transport mail between a wide variety of machines. Consequently, its configuration file is designed to be very flexible. This concept allows a single binary to be distributed to many machines, where the configuration file can be customized to suit particular needs. This configurability contributes to making sendmail complex.

When mail needs to be delivered to a particular user, for example, the sendmail program decides on the appropriate delivery method based on its configuration file. The decision process might include the following steps:

The configuration file contains all the information sendmail needs to do its job. Within it you provide information, such as file locations, permissions, and modes of operation.

Rewriting rules and rule sets also appear in the configuration file. They transform a mail address into another form that might be required for delivery. They are perhaps the single most confusing aspect of the configuration file. Because the configuration file is designed to be fast for sendmail to read and parse, rules can look cryptic to humans:

R $+ @ $+             $: $1 < @ $2 >       focus on domain
R $+ < $+ @ $+ >      $1 $2 < @ $3 >       move gaze right

But what appears to be complex is really just succinct. The R at the beginning of each line, for example, labels a rewrite rule. And the $+ expressions mean to match one or more parts of an address. With experience, such expressions (and indeed the configuration file as a whole) soon become meaningful.

Fortunately, you don’t need to learn the details of rule sets to configure and install sendmail. The mc form of configuration insulates you from such details, and allows you to perform very complex tasks easily.

Not all mail messages can be delivered immediately. When delivery is delayed, sendmail must be able to save messages for later transmission. The sendmail queue comprises one or more directories that hold mail until it can be delivered. A mail message can be queued:

Aliases allow mail that is sent to one address to be redirected to another address. They also allow mail to be appended to files or piped through programs, and form the basis of mailing lists. The heart of aliasing is the aliases(5) file (often stored in database format for swifter lookups). Aliasing is also available to the individual user via a file called ~/.forward in the user’s home directory.

Most users do not run sendmail directly. Instead, they use one of many MUAs to compose a mail message. Those programs invisibly pass the mail message to sendmail, creating the appearance of instantaneous transmission. The sendmail program then takes care of delivery in its own seemingly mysterious fashion.

Although most users don’t run sendmail directly, it is perfectly legal to do so. You, like many system managers, might need to do this to track down and solve mail problems.

Here’s a demonstration of one way to run sendmail by hand. First create a file named sendstuff with the following contents:

This is a one-line message.

Second, mail this file to yourself with the following command line, where you is your login name:

% /usr/sbin/sendmail you <sendstuff

Here, you run sendmail directly by specifying its full pathname.^[5] When you run sendmail, any command-line arguments that do not begin with a - character are considered to be the names of the people to whom you are sending the mail message.

The <sendstuff sequence causes the contents of the file that you have created (sendstuff) to be redirected into the sendmail program. The sendmail program treats everything it reads from its standard input (up to the end of the file) as the mail message to transmit.^[6]

Now view the mail message you just sent. How you do this will vary. Many users just type mail to view their mail. Others use the mh(1) package and type inc to receive and show to view their mail. No matter how you normally view your mail, save the mail message you just received to a file. It will look something like this:

From you@Here.US.EDU  Fri Dec 14 08:11:44 2007
Received: (from you@localhost)
       by Here.US.EDU (8.12.7/8.12.7)
       id d8BILug12835 for you; Fri, 14 Dec 2007 08:11:44 −0600 (MDT)
Date: Fri, 14 Dec 2007 08:11:43
From: you@Here.US.EDU (Your Full Name)
Message-Id: 200712141548.d872mLW24467@Here.US.EDU>
To: you                              ← might be something else (see §24.9.81 on
page 1060)

This is a one-line message.

The first thing to note is that this file begins with seven lines of text that were not in your original message. Those lines were added by sendmail and your local delivery program and are called the header.

The last line of the file is the original line from your sendstuff file. It is separated from the header by one blank line. The body of a mail message comes after the header and consists of everything that follows the first blank line (see Figure 1-1).

Figure 1-1. Every mail message is composed of a header and a body

Ordinarily, when you send mail with your MUA, the MUA adds a header and feeds both the header and the body to sendmail. This time, however, you ran sendmail directly and supplied only a body; the header was added by sendmail.

Let’s examine the header in more detail:

From you@Here.US.EDU  Fri Dec 14 08:11:44 2007
Received: (from you@localhost)
       by Here.US.EDU (8.12.7/8.12.7)
       id d8BILug12835 for you; Fri, 14 Dec 2007 08:11:44 −0600 (MDT)
Date: Fri, 14 Dec 2007 08:11:43
From: you@Here.US.EDU (Your Full Name)
Message-Id: 200712141511.d872mLW24467@Here.US.EDU>
To: you                              ← might be something else (see §24.9.81 on
page 1060)

Notice that most header lines start with a word followed by a colon. Each word tells what kind of information the rest of the line contains. Many types of header lines can appear in a mail message. Some are mandatory, some are optional, and some can appear many times. Those that appeared in the message you mailed to yourself were all mandatory.^[7] That’s why sendmail added them to your message. The line starting with the five characters "From " (the fifth character is a space) is added by some programs (such as /bin/mail) but not by others (such as mh).

A Received: line is added each time a machine receives the mail message. (If there are too many such lines, the mail message will bounce—because it is probably in a loop—and will be returned to the sender as failed mail.) The indented line is a continuation of the line above, the Received: line. The Date: line gives the date and time when the message was originally sent. The From: line lists the email address and the full name of the sender. The Message-ID: line is like a serial number in that it is guaranteed to uniquely identify the mail message. And the To:^[8] line shows a list of one or more recipients. (Multiple recipients would be separated with commas.)

A complete list of all header lines that are of importance to sendmail is presented in Chapter 25 on page 1120. The important concept here is that the header precedes, and is separate from, the body in all mail messages.

The body of a mail message consists of everything following the first blank line to the end of the file. When you sent your sendstuff file, it contained only a body. Now, edit the file sendstuff and add a small header:

Subject: a test             ← add
                                                   ← add
This is a one-line message.

The Subject: header line is optional. The sendmail program passes it through as is. Here, the Subject: line is followed by a blank line and then the message text, forming a header and a body. Note that a blank line must be truly blank. If you put space or tab characters in it, thus forming an “empty-looking” line, the header will not be separated from the body as intended.

Send this file to yourself again, running sendmail by hand as you did before:

% /usr/sbin/sendmail you <sendstuff

Notice that our Subject: header line was carried through without change:

From you@Here.US.EDU  Fri Dec 14 08:11:44 2007
Received: (from you@localhost)
       by Here.US.EDU (8.12.7/8.12.7)
       id d8BILug12835 for you; Fri, 14 Dec 2007 08:11:44 −0600 (MDT)
Date: Fri, 14 Dec 2007 08:11:43
From: you@Here.US.EDU (Your Full Name)
Message-Id: 200712141511.d9BMTuX29709@Here.US.EDU>
Subject: a test                                                  ← note
To: you

This is a one-line message.

So that it can more easily handle delivery to diverse recipients, the sendmail program uses the concept of an envelope. This envelope is analogous to the physical envelopes that are used for post office mail. Imagine you want to send two copies of a document, one to your friend in the office next to yours and one to a friend across the country:

To: friend1, friend2@remote

After you photocopy the document, you stuff each copy into a separate envelope. You hand one envelope to a clerk, who carries it next door and hands it to friend1 in the next office. This is like delivery on your local machine. The clerk drops the other copy in the slot at the corner mailbox, and the post office forwards that envelope across the country to friend2@remote. This is like sendmail transporting a mail message to a remote machine.

To illustrate what an envelope is, consider one way in which sendmail might run /usr/lib/mail.local, a program that performs local delivery:

                       deliver to friend1's mailbox
                    ↓
/usr/lib/mail.local -d friend1         ← sendmail runs
                          ↑
                           the envelope recipient

Here sendmail runs /usr/lib/mail.local with a -d, which tells /usr/lib/mail.local to append the mail message to friend1’s mailbox.

Information that describes the sender or recipient, but is not part of the message header, is considered envelope information. The two might or might not contain the same information (a point we’ll gloss over for now). In the case of /usr/lib/mail.local, the email message shows two recipients in its header:

To: friend1, friend2@remote        ← the header

But the envelope information that is given to /usr/lib/mail.local shows only one (the one appropriate to local delivery):

-d friend1                    ← specifies the envelope

Now consider the envelope of a message transported over the network. When sending network mail, sendmail must give the remote site the envelope-sender address and a list of recipients separate from and before it sends the mail message (header and body). Figure 1-2 shows this in a greatly simplified conversation between the local sendmail and the remote machine’s sendmail.

Figure 1-2. A simplified conversation

The local sendmail tells the remote machine’s sendmail that there is mail from you (the envelope-sender) and for friend2@remote. It conveys this envelope-sender and recipient information separate from and before it transmits the mail message that contains the header. Because this information is conveyed separately from the message header, it is called the envelope.

Only one recipient is listed in the envelope, whereas two were listed in the message header:

To: friend1, friend2@remote

The remote machine should not need to know about the local user, friend1, so that bit of recipient information is excluded from the envelope.

A given mail message can be sent by using many different envelopes (like the two here), but the header will be common to them all. Note that the headers of a message don’t necessarily reflect the actual envelope. You witness such mismatches whenever you receive a message from a mailing list or receive a spam message.

The sendmail program’s role (position) in the local filesystem hierarchy can be viewed as an inverted tree (see Figure 1-3).

Figure 1-3. The sendmail.cf file leads to everything else

When sendmail is run, it first reads the /etc/mail/sendmail.cf configuration file. Among the many items contained in that file are the locations of all the other files and directories that sendmail needs.

Files and directories listed in sendmail.cf are usually specified as full pathnames for security (such as /var/spool/mqueue rather than mqueue). As the first step in our tour of those files, run the following command to gather a list of them:^[9]

% grep =/ /etc/mail/sendmail.cf

The output produced by the grep(1) command might appear something like the following:^[10]

O AliasFile=/etc/mail/aliases
#O ErrorHeader=/etc/mail/error-header
O HelpFile=/etc/mail/helpfile
O QueueDirectory=/var/spool/mqueues/q.*
O StatusFile=/etc/mail/statistics
#O UserDatabaseSpec=/etc/mail/userdb
#O ServiceSwitchFile=/etc/mail/service.switch
#O HostsFile=/etc/hosts
#O SafeFileEnvironment=/arch
#O DeadLetterDrop=/var/tmp/dead.letter
O ControlSocketName=/var/spool/mqueues/.control
#O PidFile=/var/run/sendmail.pid
#O DefaultAuthInfo=/etc/mail/default-auth-info
Mlocal,       P=/usr/lib/mail.local, F=lsDFMAw5:/|@qPSXfmnz9, S=EnvFromSMTP/HdrFromL,
Mprog,        P=/bin/sh, F=lsDFMoqeu9, S=EnvFromL/HdrFromL, R=EnvToL/HdrToL, D=$z:/,

Notice that some lines begin with an O character, some with an M, and others with a #. The O marks a line as a configuration option. The word following the O is the name of the option. The options in the preceding output show the location of the files that sendmail uses. AliasFile, for example, defines the location of the aliases(5) database. The lines that begin with M define delivery agents. The lines that begin with a # are comments.

First we will examine the files in the O option lines. Then we will discuss local delivery and the files in the M delivery agent lines.

Aliasing is the process of converting one recipient name into another. One use is to convert a generic name (such as root) into a real username. Another is to convert one name into a list of many names (for mailing lists).

Take a few moments to examine your aliases file. Its location is determined by the AliasFile option in your sendmail.cf file. For example:

O AliasFile=/etc/mail/aliases

Compare what you find in your aliases file to the brief example of an aliases file listed here:

# Mandatory aliases.
postmaster:     bob
MAILER-DAEMON:  postmaster
abuse:          postmaster

# The five forms of aliases
John_Adams:     adamj
xpres:          ford,carter,reagan,clinton
oldlist:        :include:/usr/local/oldguys
nobody:         /dev/null
ftphelp:        |/usr/local/bin/sendhelp

Your aliases file is probably far more complex, but even so, note that the example shows all the possible forms of aliases.

Lines that begin with # are comments. Empty lines are ignored. As the first comment indicates, three aliases are mandatory in every aliases file. They are the simplest form of alias: a name and what to change that name into. The name on the left of the : is changed into the name on the right. Names are not case-sensitive. For example, POSTMASTER, Postmaster, and postmaster are all the same.^[11]

For every envelope that lists a local user as a recipient, sendmail looks up that recipient’s name in the aliases file. (A local user is any address that would normally be delivered on the local machine. That is, postmaster is local, whereas postmaster@remote might not be.) When sendmail is processing the envelope, and when it matches the recipient to one of the names on the left of the aliases file, it replaces that recipient name with the text to the right of the : character. For example, the envelope recipient postmaster becomes the new envelope recipient bob.

After a name is substituted, the new name is then looked up, and the process is repeated until no more matches are found. The name MAILER-DAEMON is first changed to postmaster. Then postmaster is looked up again and changed to bob. Because there is no entry for bob in the aliases file, the mail message is delivered into bob’s mailbox.

Every aliases file must have an alias for postmaster that will expand to the name of a real user.^[12] Mail about mail problems is always sent to postmaster both by mail-related programs and by users who are having trouble sending mail.

When mail is bounced (returned because it could not be delivered), it is always sent from MAILER-DAEMON. That alias is needed because users might reply to bounced mail. Without it, replies to bounced mail would themselves bounce.

The five types of lines in an aliases file are as follows:

John_Adams:    adamj
xpres:         ford,carter,reagan,clinton
oldlist:       :include:/usr/local/oldguys
nobody:        /dev/null
ftphelp:       |/usr/local/bin/sendhelp

You have already seen the first line (it was the form used to convert postmaster to bob). In the previous example, mail sent to John_Adams is delivered to the user whose login name is adamj.

The xpres: line shows how one name can be expanded into a list of many names. Each new name becomes a new name for further alias processing. If a name can’t be further expanded, a copy of the mail message is delivered to it.

The oldlist: line shows how a mailing list can be read from a file. The expression :include: tells sendmail to read a specific file and to use the names in that file as the list of recipients.

The nobody: line shows how a name can be aliased to a file. The mail message is appended to the file. The /dev/null file listed here is a special one. That file is an empty hole into which the mail message simply vanishes.

The ftphelp: line shows how a name can be replaced by the name of a program. The | character causes sendmail to pipe the mail message through the program whose full pathname follows (in this case, we specified the full pathname as /usr/local/bin/sendhelp).

The aliases file can become very complex. It can be used to solve many special mail problems. The aliases file is covered in greater detail in Chapter 12 on page 460.

A mail message can be temporarily undeliverable for a wide variety of reasons, such as when a remote machine is down or has a temporary disk problem. To ensure that such a message is eventually delivered, sendmail stores it in a queue directory until the message can be delivered successfully.

The QueueDirectory option in your configuration file tells sendmail where to find its queue directory:

O QueueDirectory=/var/spool/mqueue

The location of that directory must be a full pathname. Its exact location varies from vendor to vendor, but you can always find it by looking for the QueueDirectory option in your configuration file.

Beginning with V8.10, sendmail allows multiple queue directories to be used. Such a declaration can look like this:

O QueueDirectory=/var/spool/queues/q.*

Here, sendmail will use the subdirectories in /var/spool/queues that begin with the name q. for storage of messages. Such directories might be called, for example, q.00 and q.01.

If you have permission, take a look at a sendmail queue directory. It might be empty if no mail is waiting to be sent. If it is not empty, it will contain files such as these:

dfg17NVhbh002596 dfg1BHotav010793 qfg17NVhbh002596 qfg1BHotav010793

When a mail message is queued, it is split into two parts, each part being saved in a separate file. The header information is saved in a file whose name begins with the characters qf. The body of the mail message is saved in a file whose name begins with the characters df.

The previous example shows two queued mail messages. One is identified by the unique string g17NVhbh002596 and the other by g1BHotav010793.

The internals of the queue files and the processing of those files are covered in Chapter 11 on page 394.

Another role of the sendmail program is to deliver mail messages to local users. A local user is one who has a mailbox on the local filesystem. Delivering local mail is done by appending a message to the user’s mailbox, by feeding the mail message to a program, or by appending the message to a file other than the user’s mailbox.

In general, sendmail does not put mail messages directly into files. You saw the exception in the aliases file, in which you could specifically tell sendmail to append mail to a file. This is the exception, not the rule. Usually, sendmail calls other programs to perform delivery. Those other programs are called delivery agents.^[13]

In your sendmail.cf file you found two lines that defined local delivery agents, the ones that sendmail uses to deliver mail to the local filesystem:

Mlocal,  P=/usr/lib/mail.local, F=lsDFMAw5:/|@qPSXfmnz9, S=EnvFromSMTP/HdrFromL,
Mprog,   P=/bin/sh, F=lsDFMoqeu9, S=EnvFromL/HdrFromL, R=EnvToL/HdrToL, D=$z:/,

The /usr/lib/mail.local program is used to append mail to the user’s mailbox. The /bin/sh program is used to run other programs that handle delivery.

The configuration file line that begins with Mlocal defines how mail is appended to a user’s mailbox file. That program is usually /usr/lib/mail.local (or with older systems, /bin/mail) but can easily be a program such as deliver(1) or procmail(1).

Under Unix, a user’s mailbox is a single file that contains a series of mail messages. The usual Unix convention (but not the only possibility) is that each message in a mailbox begins with a line that starts with the five characters "From " (the fifth is a blank space) and ends with a blank line.

The sendmail program neither knows nor cares what a user’s mailbox looks like. All it cares about is the name of the program that it must run to add mail messages to that mailbox. In the example, that program is /usr/lib/mail.local. The M configuration lines that define delivery agents are covered in detail in Chapter 20 on page 711.

Mail addresses that begin with a | character are the names of programs to run. You saw one such address in the example aliases file:

ftphelp:       |/usr/local/bin/sendhelp

Here, mail sent to the address ftphelp is transformed via an alias into the new address |/usr/local/bin/sendhelp. The | character at the start of this new address tells sendmail that this is a program to run rather than a file to append to. The intention here is that the program will receive the mail and do something useful with it.

The sendmail program doesn’t run mail delivery programs directly. Instead, it runs a shell and tells that shell to run the program. The name of the shell is listed in the configuration file in a line^[14] that begins with Mprog:

Mprog,   P=/bin/sh, F=lsDFMoqeu9, S=EnvFromL/HdrFromL, R=EnvToL/HdrToL, D=$z:/,

In this example, the shell is the /bin/sh(1). Other programs can appear in this line, such as /bin/ksh(1), the Korn Shell, or smrsh(1), the sendmail restricted shell that is supplied with the source distribution.

Another role of sendmail is that of transporting mail to other machines. A message is transported when sendmail determines that the recipient is not local. The following lines from a typical configuration file define delivery agents for transporting mail to other machines:

Msmtp,   P=[IPC], F=mDFMuX, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP/HdrFromSMTP,
Muucp,   P=/usr/bin/uux, F=DFMhuUd, S=FromU, R=EnvToU/HdrToU, M=100000,

The actual lines in your file might differ. The name smtp in the preceding example might appear in your file as ether or ddn or something else. The name uucp might appear as suucp or uucp-dom. There might be more such lines than we’ve shown here. The important point for now is that some delivery agents deal with local delivery, whereas others deal with delivery over a network.

The sendmail program has the internal ability to transport mail over only one kind of network, one that uses TCP/IP; the following line instructs sendmail to do this:

Msmtp,   P=[IPC], F=mDFMuX, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP/HdrFromSMTP,

The [IPC] might appear as [TCP], but note that, beginning with V8.10 sendmail, the expression [TCP] is deprecated, and it has been dropped entirely in V8.12.

When sendmail transports mail on a TCP/IP network, it first sends the envelope-sender’s address to the other site. If the other site accepts the sender’s address as legal, the local sendmail then sends the list of envelope-recipient addresses. The other site accepts or rejects each recipient address one by one. If any recipient addresses are accepted, the local sendmail sends the message (header and body together). This kind of transaction for sending email is called SMTP and is defined in RFC2821.

UUCP is an old-style means of moving email between machines that are only connected with dial-up modems. The line in the configuration file that tells sendmail how to transport over UUCP might look, in part, like this:

Muucp,   P=/usr/bin/uux, F=DFMhuUd, S=12, R=22/42, M=10000000,

This line tells sendmail to send UUCP network mail by running the /usr/bin/uux (UNIX to UNIX eXecute) program.

sendmail can use many other kinds of network protocols to transport email. Some of them might have shown up when you ran grep earlier. Other common possibilities might look, in part, like one of these:

Mfax,    P=/usr/local/bin/faxmail, F=DFMhu, S=14, R=24, M=100000,
Mmail11, P=/usr/etc/mail11, F=nsFx, S=Mail11From, R=Mail11To,
Mmac,    P=/usr/bin/macmail, F=CDFMmpsu, S=MailMacFrom, R=MailMacTo, A=macmail -t $u

The Mfax line defines one of the many possible ways to send a fax using sendmail. A fax machine transports images of documents over telephone lines. In the preceding configuration line, the /usr/local/bin/faxmail program is run, and a mail message is fed to it for conversion to and transmission as a fax image.

The Mmail11 line defines a way of using the mail11(1) program to transport email over a DECnet network, used mostly by the Open VMS operating system (formerly by Digital Equipment Corporation).

The Mmac line defines a way to transport mail to Macintosh machines that are connected on an AppleTalk network.

In all these examples, note that sendmail sends email over other networks by running programs that are tailored specifically for that use. Remember that the only network sendmail can use directly is a TCP/IP-based network.^[15]

Just as sendmail can transport mail messages over a TCP/IP-based network, it can also receive mail that is sent to it over the network. To do this, it must be run in daemon mode. A daemon is a program that runs in the background independent of terminal control.

As a daemon, sendmail is started once, usually when your machine is booted. Whenever an email message is sent to your machine, the sending machine talks to the sendmail daemon that is listening on your machine.

% grep sendmail /etc/rc*          ←BSD-based systems
% grep sendmail /etc/init.d/*     ←SysV-based systems
% grep sendmail /etc/*rc          ←HP-UX systems (prior to HP-UX 10.0)

One typical example of what you will find is:

/etc/rc.local:if [ -f /usr/lib/sendmail -a -f /etc/mail/sendmail.cf ]; then
/etc/rc.local:   /usr/lib/sendmail -bd -q1h; echo -n ' sendmail'

The second line in this example shows that sendmail is run at boot time with a command line of:

/usr/lib/sendmail -bd -q1h

The -bd command-line switch tells sendmail to run in daemon mode. The -q1h command-line switch tells sendmail to wake up once per hour and process the queue. Command-line switches are covered in Chapter 6 on page 220.

One way to run sendmail is to provide it with the name of a recipient as the only command-line argument. For example, the following sends a mail message to george:

% /usr/lib/sendmail george

Multiple recipients can also be given. For example, the following sends a mail message to george, truman, and teddy:

% /usr/lib/sendmail george,truman,teddy

The sendmail program accepts two different kinds of command-line arguments. Arguments that do not begin with a - character (such as george) are assumed to be recipients. Arguments that do begin with a - character are taken as switches that determine the behavior of sendmail. The recipients must always follow all the switched arguments. Any switched arguments that follow recipients will be interpreted as recipient addresses, potentially causing bounced mail.

In this chapter, we will cover only a few of these switch-style command-line arguments (see Table 1-1). The complete list of command-line switches, along with an explanation of each, is presented in Chapter 6 on page 220.

/usr/sbin/sendmail -bd -q1h

Killing and restarting the sendmail daemon became easier beginning with V8.7. A single command^[16] will kill and restart the daemon. In the following command, you might need to replace the path /var/run with one appropriate to your operating system (such as /etc/mail):

% kill -HUP `head −1 /var/run/sendmail.pid'

This single command has the same effect as the two commands shown for V8.6 in the following sections.

% kill −15 `head −1 /etc/mail/sendmail.pid'

% `tail −1 /etc/mail/sendmail.pid'

% ps ax | grep sendmail | grep -v grep
   99    ?  IW    0:07 /usr/lib/sendmail -bd -q1h
% kill −15 99

% ps -ae | grep sendmail
   99 ?         0:01 sendmail
% kill −15 99

...
getrequests: cannot bind: Address already in use
getrequests: cannot bind: Address already in use
getrequests: cannot bind: Address already in use
getrequests: cannot bind: Address already in use
getrequests: cannot bind: Address already in use
getrequests: cannot bind: Address already in use
opendaemonsocket: server SMTP socket wedged: exiting

The sendmail program can also display the contents of its queue directories. It can do this in two ways: by running as a program named mailq or by being run as sendmail with the -bp command-line switch. Whichever way you run it, the contents of the queue are printed. If the queue is empty, sendmail prints the following:

/var/spool/mqueue is empty

If, on the other hand, mail is waiting in the queue, the output is far more verbose, possibly containing lines similar to these:

                /var/spool/mqueue (1 requests)
--Q-ID------ --Size-- ----Q-Time------ ------------Sender/Recipient------------
d8BJXvF13031*     702 Fri Dec  14 16:51 <you@here.us.edu>
              Deferred: Host fbi.dc.gov is down
                                       <george@fbi.dc.gov>

Here, the output produced with the -bp switch shows that only one mail message is in the queue. If there were more, each entry would look pretty much the same as this. Each message results in at least two lines of output.

The first line shows details about the message and the sender. The d8BJXvF13031 identifies this message in the queue directory /var/spool/mqueue. The * shows that this message is locked and currently being processed. The 702 is the size of the message body in bytes (the size of the df file as mentioned in Role in Queue Management on page 14). The date shows when this message was originally queued. The address shown is the name of the sender.

A second line might appear giving a reason for failure (if there was one). A message can be queued intentionally or because it couldn’t immediately be delivered.

The third and possibly subsequent lines show the addresses of the recipients.

If there is more than one queue, each queue will print the preceding information, and the last queue’s information will be followed by a line that looks like this:

Total Requests: num

Here, beginning with V8.10, the num will be the total number of messages stored in all the queue directories.

The output produced by the -bp switch is covered more fully in Chapter 11 on page 394.

Because sendmail might have to search through thousands of names in the aliases file, a version of the file is stored in a separate dbm(3) or db(3) database format file. The use of a database significantly improves lookup speed.

Although early versions of sendmail can automatically update the database whenever the aliases file is changed, that is no longer possible with modern versions.^[18] Now, you need to rebuild the database yourself, either by running sendmail using the command newaliases or with the -bi command-line switch. Both do the same thing:

% newaliases
% /usr/lib/sendmail -bi

There will be a delay while sendmail rebuilds the aliases database; then a summary of what it did is printed:

/etc/mail/aliases: 859 aliases, longest 615 bytes, 28096 bytes total

This line shows that the database was successfully rebuilt. Beginning with V8.6 sendmail, multiple alias files became possible, so each line (and there might be many) begins with the name of an alias file. The information then displayed is the number of aliases processed, the size of the biggest entry to the right of the : in the aliases file, and the total number of bytes entered into the database. Any mistakes in an alias file will also be printed here.

The aliases file and how to manipulate it are covered in Chapter 12 on page 460.

A handy tool for checking aliases is the -bv command-line switch. It causes sendmail to recursively look up an alias and report the ultimate real name that it found.

To illustrate, consider the following aliases file:

animals:      farmanimals,wildanimals
bill-eats:    redmeat
birds:        farmbirds,wildbirds
bob-eats:     seafood,whitemeat
farmanimals:  pig,cow
farmbirds:    chicken,turkey
fish:         cod,tuna
redmeat:      animals
seafood:      fish,shellfish
shellfish:    crab,lobster
ted-eats:     bob-eats,bill-eats
whitemeat:    birds
wildanimals:  deer,boar
wildbirds:    quail

Although you can figure out what the name ted-eats ultimately expands to, it is far easier to have sendmail do it for you. By using sendmail, you have the added advantage of being assured accuracy, which is especially important in large and complex aliases files.

In addition to expanding aliases, the -bv switch performs another important function. It verifies whether the expanded aliases are, in fact, deliverable. Consider the following one-line aliases file:

root:       fred,larry

Assume that the user fred is the system administrator and has an account on the local machine. The user larry, however, has left, and his account has been removed. You can run sendmail with the -bv switch to find out whether both names are valid:

% /usr/lib/sendmail -bv root

This tells sendmail to verify the name root from the aliases file. Because larry (one of root’s aliases) doesn’t exist, the output produced looks like this:

larry... User unknown
fred... deliverable: mailer local, user fred

The -v command-line switch tells sendmail to run in verbose mode. In that mode, sendmail prints a blow-by-blow^[19] description of all the steps it takes in delivering a mail message. To watch sendmail run in verbose mode, send mail to yourself as you did in Run sendmail by Hand on page 6, but this time add a -v switch:

% /usr/lib/sendmail -v you <sendstuff

The output produced shows that sendmail delivers your mail locally:

you... Connecting to local...
you... Sent

When sendmail forwards mail to another machine over a TCP/IP network, it communicates with that other machine using the SMTP protocol. To see what SMTP looks like, run sendmail again, but this time, instead of using you as the recipient, give sendmail your address on another machine:

% /usr/lib/sendmail -v you@remote.domain <sendstuff

The output produced by this command line will look similar to the following:

you@remote.domain... Connecting to remote.domain via smtp...
220 remote.Domain ESMTP Sendmail 8.14.1/8.14.1 ready at Fri, 14 Dec 2007 06:36:12
−080
0
>>> EHLO here.us.edu
250-remote.domain Hello here.us.edu [123.45.67.89], pleased to meet you
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
>>> MAIL From:<you@here.us.edu>  SIZE=4537
250 2.1.0 <you@here.us.edu> ... Sender ok
>>> RCPT To:<you@remote.domain>
250 2.1.5 <you@remote.domain> ... Recipient ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 d9L29Nj20475 Message accepted for delivery
you@remote.domain... Sent (d9L29Nj20475 Message accepted for delivery)
Closing connection to remote.domain
>>> QUIT
221 remote.domain closing connection

The lines that begin with numbers and the lines that begin with >>> characters constitute a record of the SMTP conversation. We’ll discuss those shortly. The other lines are sendmail on your local machine telling you what it is trying to do and what it has successfully done:

you@remote.domain... Connecting to remote.domain via smtp...
...
you@remote.domain... Sent (d9L29Nj20475 Message accepted for delivery)
Closing connection to remote.domain

The first line shows to whom the mail is addressed and that the machine remote.domain is on the network. The last two lines show that the mail message was successfully sent.

In the SMTP conversation, your local machine displays what it is saying to the remote host by preceding each line with >>> characters. The messages (replies) from the remote machine are displayed with leading numbers. We now explain that conversation.

220 remote.Domain ESMTP Sendmail 8.14.1/8.14.1 ready at Fri, 14 Dec 2007 06:36:12
−080
0

Once your sendmail has connected to the remote machine, your sendmail waits for the other machine to initiate the conversation. The other machine says it is ready by sending the number 220 and its fully qualified hostname (the only required information). If the other machine is running sendmail, it may also say the program name is sendmail and state the version. It may also state that it is ready and gives its idea of the local date and time.

The ESMTP means that the remote site understands Extended SMTP.

If sendmail waits too long for a connection without receiving this initial message, it prints “Connection timed out” and queues the mail message for later delivery.

Next, the local sendmail sends (the >>>) the word EHLO, for Extended Hello, and its own hostname:

>>> EHLO here.us.edu
250-remote.domain Hello here.us.edu [123.45.67.89], pleased to meet you
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP

The E of the EHLO says that the local sendmail speaks ESMTP too. The remote machine replies with 250, then lists the ESMTP services that it supports. All but the last reply line contain a dash following the 250. That dash signals that an additional reply line will follow. The last line, the HELP line, lacks a dash, and so completes the reply.

One problem that could occur is your machine sending a short hostname (“here”) in the EHLO message. This would cause an error because the remote machine wouldn’t find here in its domain remote.domain. This is one reason why it is important for your sendmail to always use your machine’s fully qualified hostname. A fully qualified name is one that begins with the host’s name, followed by a dot, then the entire DNS domain.

If all has gone well so far, the local machine sends the name of the sender of the mail message and the size of the message in bytes:

>>> MAIL From:<you@here.us.edu>  SIZE=4537
250 2.1.0 <you@here.us.edu> ... Sender ok

Here, that sender address was accepted by the remote machine, and the size was not too large.

Next, the local machine sends the name of the recipient:

>>> RCPT To:<you@remote.domain>
250 2.1.5 <you@remote.domain> ... Recipient ok

If the user you were not known on the remote machine, it might reply with an error of “User unknown.” Here, the recipient is ok. Note that ok does not necessarily mean that the address is good. It can still be bounced later. The ok means only that the address is acceptable.

After the envelope information has been sent, your sendmail attempts to send the mail message (header and body combined):

>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .

DATA tells the remote host to “get ready.” The remote machine says to send the message, and the local machine does so. (The message is not printed as it is sent.) A dot on a line by itself is used to mark the end of a mail message. This is a convention of the SMTP protocol. Because mail messages can contain lines that begin with dots as a valid part of the message, sendmail doubles any dots at the beginning of lines before they are sent.^[20] For example, consider what happens when the following text is sent through the mail:

My results matched yours at first:
126.71
126.72
...
126.79
But then the numbers suddenly jumped high, looking like
noise saturated the line.

To prevent any of these lines from being wrongly interpreted as the end of the mail message, sendmail inserts an extra dot at the beginning of any line that begins with a dot, so the actual text transferred is:

My results matched yours at first:
126.71
126.72
....                              ← note extra dot
126.79
But then the numbers suddenly jumped high, looking like
noise saturated the line.

The SMTP-server program running at the receiving end (for example, another sendmail) strips those extra dots when it receives the message.

The remote sendmail shows the queue identification number that it assigned to the mail it accepted:

250 2.0.0 d9L29Nj20475 Message accepted for delivery
 . . .
>>> QUIT
221 remote.domain closing connection

The local sendmail sends QUIT to say it is all done. The remote machine acknowledges by closing the connection.

Note that the -v (verbose) switch for sendmail is most useful with mail sent to remote machines. It allows you to watch SMTP conversations as they occur and can help in tracking down why a mail message fails to reach its destination.

The sendmail program can also produce debugging output. The sendmail program is placed in debugging mode by using the -d command-line switch. That switch produces far more information than -v does. To see for yourself, enter the following command line, but substitute your own login name in place of the you:

% /usr/lib/sendmail -d you < /dev/null

This command line produces a great deal of output. We won’t explain this output because it is explained in Chapter 15 on page 530. For now, just remember that the sendmail program’s debugging output can produce a great deal of information.

In addition to producing lots of debugging information, the -d switch can be modified to display specific debugging information. By adding a numeric argument to the -d switch, output can be limited to one specific aspect of the sendmail program’s behavior.

Type in this command line, but change you to your own login name:

% /usr/lib/sendmail -d0 you < /dev/null

Here, the -d0 is the debugging switch with a category of 0. That category limits sendmail’s program output to information about how sendmail was compiled. A detailed explanation of that output is covered in -d0.4 on page 542.

In addition to a category, a level can also be specified. The level adjusts the amount of output produced. A low level produces little output; a high level produces greater and more complex output. The string following the -d has the form:

category.level

For example, enter the following command line:

% /usr/lib/sendmail -d0.1 -bp

The -d0 instructs sendmail to produce general debugging information. The level .1 limits sendmail to its minimal output. That level could have been omitted because a level .1 is the default. Recall that -bp causes sendmail to print the contents of its queue. The output produced looks something like the following:

Version 8.14.1
 Compiled with: LOG NAMED_BIND NDBM NETINET NETUNIX NIS SCANF
                XDEBUG

==  ==  ==  ==  ==  == SYSTEM IDENTITY (after readcf) ==  ==  ==  ==  ==  ==
      (short domain name) $w = here
  (canonical domain name) $j = here.us.edu
         (subdomain name) $m = us.edu
              (node name) $k = here
==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==
==  ==  ==  ==  ==  ==

/var/spool/mqueue is empty

Here, the -d0.1 switch causes sendmail to print its version, some information about how it was compiled, and how it interpreted your host (domain) name. Now run the same command line again, but change the level from .1 to .11:

% /usr/lib/sendmail -d0.11 -bp

The increase in the level causes sendmail to print more information:

Version 8.14.1
 Compiled with: LOG NAMED_BIND NDBM NETINET NETUNIX NIS SCANF
                XDEBUG
    OS Defines: HASFLOCK HASGETUSERSHELL HASINITGROUPS HASLSTAT
                HASSETREUID HASSETSID HASSETVBUF HASUNAME IDENTPROTO
                IP_SRCROUTE
   Config file: /etc/mail/sendmail.cf
      Pid file: /etc/mail/sendmail.pid
canonical name: here.us.edu
 UUCP nodename: here
        a.k.a.: [123.45.67.89]

==  ==  ==  ==  ==  == SYSTEM IDENTITY (after readcf) ==  ==  ==  ==  ==  ==
      (short domain name) $w = here
  (canonical domain name) $j = here.us.edu
         (subdomain name) $m = us.edu
              (node name) $k = here
==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==  ==
==  ==  ==  ==  ==  ==

/var/spool/mqueue is empty

The sendmail.cf configuration file is line-oriented. A configuration command, composed of a single letter, begins each line:

V10/Berkeley                       ← good
V10/Berkeley                       ← bad, does not begin a line
V10/Berkeley Fw/etc/mail/mxhosts   ← bad, two commands on one line
Fw/etc/mail/mxhosts                ← good

Each configuration command is followed by parameters that are specific to it. For example, the V command is followed by an ASCII representation of an integer value, a slash, and a vendor name. Whereas the F command is followed by a letter (a w in the example), then the full pathname of a file. The complete list of configuration commands^[21] is shown in Table 1-4.

Some commands, such as V, should appear only once in your sendmail.cf file. Others, such as R, can appear often.

Blank lines and lines that begin with the # character are considered comments and are ignored. A line that begins with either a tab or a space character is a continuation of the preceding line:

# a comment
V10
     /Berkeley  ← continuation of V line above
  ↑ tab

Note that anything other than a command, a blank line, a space, a tab, or a # character causes an error. If the sendmail program finds such a character, it prints the following warning, ignores that line, and continues to read the configuration file:

/etc/mail/sendmail.cf: line 15: unknown configuration line "v9"

Here, sendmail found a line in its sendmail.cf file that began with the letter v. Because a lowercase v is not a legal command, sendmail printed a warning. The line number in the warning is that of the line in the sendmail.cf file that began with the illegal character.

An example of each kind of command is illustrated in the following sections.

To prevent older versions of sendmail from breaking when reading new-style sendmail.cf files, a V (for version) command was introduced beginning with V.1. The form for the version command looks like this:

V10/Berkeley

The V must begin the line. The version number that follows must be 10 to enable all the new features of V.14 sendmail.cf. The number 10 indicates that the syntax of the sendmail.cf file has undergone 10 major changes over the years, the tenth being the current and most recent. The meaning of each version is detailed in The V Configuration Command on page 580.

The Berkeley tells sendmail that this is the pure open source version. Other vendor names can appear here too. Sun, for example, would be listed on Sun Solaris platforms and would cause the Sun Microsystems version of sendmail to recognize the Sun configuration file extensions.

Comments help other people understand your configuration file. They can also remind you about something you might have done months ago and forgotten. They slow down sendmail by only the tiniest amount, so don’t be afraid to use them. As was mentioned earlier, when the # character begins a line in the sendmail.cf file, that entire line is treated as a comment and ignored. For example, the entire following line is ignored by the sendmail program:

# This is a comment

Besides beginning a line, comments can also follow commands.^[22] That is:

V10/Berkeley                   # this is another comment

The other commands in a configuration file tend to be more complex than the version command you just saw (so complex, in fact, that whole chapters in this book are dedicated to most of them). Here, we present a quick tour of each command—just enough to give you the flavor of a configuration file but in small enough bites to be easily digested.

Mlocal,         P=/usr/lib/mail.local, F=lsDFMAw5:/|@qPSXfmnz9,
                S=EnvFromL/HdrFromL, R=EnvToL/HdrToL,
                T=DNS/RFC822/SMTP,
                A=mail.local -l

DRmail.us.edu           ← a single letter
D{REMOTE}mail.us.edu    ← multiple characters (beginning with V8.7)

R$-      $@ $1 @ $R     user ->  user @ remote

R$-                        # If a plain username
      $@ $1 @ ${REMOTE}    #    append "@" remote host

S3

SHubset

CW localhost fontserver             ← a single letter
C{MY_NAMES} localhost fontserver    ←  multiple characters (beginning with V8.7)

FW/etc/mail/mynames
F{MY_NAMES}/etc/mail/mynames          ← multiple characters (beginning with V8.7)

FM|/bin/shownames
F{MY_NAMES}|/bin/shownames       ← multiple characters (beginning with V8.7)

FM@ldap:-k (&(objectClass=virtHosts)(host=*)) -v host
F{MY_NAMES}@ldap:-k (&(objectClass=virtHosts)(host=*)) -v host

OQ/var/spool/mqueue
O QueueDirectory=/var/spool/mqueue      ← beginning with V8.7

HReceived: $?sfrom $s $.by $j ($v/$Z)$?r with $r$. id $i$?u for $u$.; $b

Pjunk= −100

Troot daemon uucp

Kuucp hash /etc/mail/uucphosts

EPOSTGRESHOME=/home/postgres

Qslowsite, P=/var/spool/mqueue/slowdir, I=2h

Xfilter1, S=local:/var/run/f1.sock, F=R