How sendmail Works

sendmail acts as a post office to which all messages can be submitted for routing. sendmail can interpret both Internet-style addressing (that is, user @domain) and UUCP-style addressing (that is, host !user). How addresses are interpreted is controlled by the sendmail configuration file. sendmail can rewrite message addresses to conform to standards on many common target networks.

This section discusses the following topics:

Message Structure

A message has three parts: an envelope, a message header, and a message body.

The envelope consists of the sender address, recipient address, and routing information shared by the programs that create, route, and deliver the message. It is usually not seen directly by either the sender or recipients of the message.

The message header consists of a series of standard text lines used to incorporate address, routing, date, and other information into the message. Header lines may be part of the original message and may also be added or modified by the various mail programs that process the message. Header lines may or may not be used by these programs as envelope information.

By default, the first blank line in the message terminates the message header. Everything that follows is the message body and is passed uninterpreted from the sender to the recipient.

How sendmail Collects Messages

sendmail can receive messages from any of the following:

A user agent that calls sendmail to route a piece of mail. User agents that are supported by HP for use with HP-UX 11.0 sendmail include elm, mail, mailx, and rmail.
A sendmail daemon or other mail program that calls sendmail to route a piece of mail received from the network or the mail queue.
A user that calls sendmail directly from the command line.

How sendmail Routes Messages

To route the message, sendmail does the following:

Rewrites the recipient and sender addresses given to it to conform to the standards of the target network.
If necessary, adds lines to the message header so that the recipient is able to reply.
Passes the mail to one of several specialized delivery agents for delivery.

Figure 4-1 “Flow of Mail Through sendmail” outlines the flow of messages through sendmail.

Once sendmail collects a message, it routes the message to each of the specified recipient addresses. In order to route a message to a particular address, sendmail must resolve that address to a {delivery agent, host, user} triple. This resolution is based on rules defined in the sendmail configuration file, /etc/mail/sendmail.cf.

A separate delivery agent is invoked for each host to which messages are being routed. Some delivery agents can accept multiple users in a given invocation. Others must be invoked separately for each recipient. Delivery agents that are supported by HP for use with HP-UX 11.0 sendmail include SMTP, UUCP, X.400, and OpenMail.

To invoke a delivery agent, sendmail constructs a command line according to a template in the configuration file.

If the delivery agent is specified as IPC, sendmail does not invoke an external delivery agent but instead opens a TCP/IP connection to the SMTP server on the specified host and transmits the message using SMTP.

Figure 4-1 Flow of Mail Through sendmail

If an address resolves to the local mailer, sendmail looks up the address in its alias database and expands it appropriately if it is found.

The aliasing facility or a user's .forward file may be used to route mail to programs and to files. (sendmail does not mail directly to programs or files.) Mail to programs is normally piped to the prog mailer (/usr/bin/sh -c), which executes the command specified in the alias or .forward file definition. (You can restrict the programs that can be run through the aliases or .forward files. See “Security” for more information.) Mail to a file is directly appended to the file by sendmail if certain conditions of ownership and permission are met.

After all alias expansion is complete, mail that is addressed to a local user name is routed to the local mailer (/usr/bin/rmail), which deposits the message in the user's mailbox.

The Default Routing Configuration

The installed configuration file, if unmodified, routes mail depending on the syntax of the recipient addresses as described in the following sections.

Local Addresses

The following forms are recognized as local addresses and are delivered locally:

user
user@localhost
user@localhost.localdomain
user@alias
user@alias.localdomain
user@[local_host's_internet_address]
localhost!user
localhost!localhost!user
user@localhost.uucp

UUCP Addresses

Where host is not the local host name, addresses of the following forms are recognized as UUCP addresses:

host!user
host!host!user
user@host.uucp

If your host has a direct UUCP connection to the next host in the path, the mail is delivered to that host through UUCP. If not, the message is returned with an error. The supplied configuration file provides detailed instructions for arranging to relay such mail through hosts to which you can connect.

SMTP Addresses

RFC 822-style addresses in any of the following forms, where host is not the local host name, are routed by SMTP over TCP/IP:

user@host
user@host.domain
<@host,@host2,@host3:user@host4>
user@[remote_host's_internet_address]

If the name server is in use, sendmail requests MX (mail exchanger) records for the remote host. If there are any, it attempts to deliver the mail to each of them, in preference order, until delivery succeeds.

Otherwise, sendmail connects directly to the recipient host and delivers the message.

Mixed Addresses

The supplied configuration file interprets address operators with the following precedence:

@, !, %

This means that recipient addresses using mixtures of these operators are resolved as shown in Table 4-2 “How sendmail Resolves Addresses with Mixed Operators”.

Table 4-2 How sendmail Resolves Addresses with Mixed Operators

Address	Mailer	Host	User	Recipient
`user%hostA@hostB`	TCP	hostB	`user%hostA@hostB`	`user@hostA`
`user!hostA@hostB`	TCP	hostB	`hostA!user@hostB`	`hostA!user`
`hostA!user%hostB`	UUCP	hostA	`user@hostB`	`user@hostB`

MX Records

The BIND name server, if it is in use on your host, provides MX (Mail Exchanger) records. These can be used to inform sendmail that mail for a particular host can be relayed by another host, if the addressed host is temporarily down or otherwise inaccessible. For information on creating MX records, see Chapter 3 “Configuring and Administering the BIND Name Service”.

MX records are used only if a message address resolves to an IPC mailer (that is, one that uses SMTP over sockets to perform delivery.) Instead of attempting to connect directly to the recipient host, sendmail first queries the name server, if it is running, for MX records for that host. If the name server returns any, sendmail sorts them in preference order, highest preference (lowest number) first. If the local host appears in the list, it and any MX hosts with lower preference (higher numbers) are removed from the list. If any MX hosts remain, sendmail then tries to connect to each MX host in the list in order, and it delivers the message to the first MX host to which it successfully connects. If that MX host is not the final destination for the message, it is expected that the host will relay the message to its final destination.

If sendmail tries all the MX hosts in the list and fails, the message is returned to the sender with an error message. If you want sendmail to try to connect to the host to which the message is addressed, uncomment the following line in the /etc/mail/sendmail.cf file:

TryNullMXList

sendmail then tries to connect to the host to which the message is addressed, if any of the following conditions occur:

The name server returns no MX records.
The name server is not running.
The local host is the highest preference mail exchanger in the list.

At log level 11 and above, sendmail logs in the system log the name and internet address of the MX host (if any) to which it delivered (or attempted to deliver) a message.

MX records are used for two main purposes:

To arrange that one host "back up" another by receiving mail for it when it is down.
To arrange that mail addressed to remote networks be relayed through the appropriate gateways.

In the following example, the name server serving the domain paf.edu has the following MX records configured to provide backup for host bling:

;name  ttl      class      MX  preference      mail exchanger
 
bling           IN         MX  0               bling.paf.edu.
                IN         MX  20              wheo.paf.edu.
                IN         MX  30              munch.pag.edu.

Ordinarily, mail for bling will go directly to bling. However, if bling is down, or if the sending host cannot connect to bling, sendmail will route mail for it to wheo. If wheo is also down or unreachable, sendmail will route the mail to munch. Naturally, for this to be useful, wheo and munch must be able to route mail to bling.

Assuming that the host and its mail exchangers see the same MX data from the name server, each host that has MX records should have an MX record for itself, and the preference on its own record should be the highest (that is, the lowest number) in the list.

The following example relays messages through a gateway:

;name  ttl      class      MX  preference      mail exchanger
 
*.nz.           IN         MX  0               gw.dcc.nz.

Messages addressed to hosts in the nz domain will be relayed to the host gw.dcc.nz. Courtesy suggests that you seek permission from the administrators of hosts not under your own control before relaying mail through them.

MX Failures

Several possible failures are associated with MX configuration:

The name server query for MX records fails.
The query fails because no MX records exist for the target host or because the name server is not running. You can set the TryNullMXList option in the /etc/mail/sendmail.cf file if you want sendmail to always try to connect to the host to which the message is addressed (see “MX Records”).
If the query fails temporarily (that is, h_errno is set to TRY_AGAIN) the message will be queued. The possible values of h_errno are documented in the header file /usr/include/netdb.h.
Connection attempts to the hosts in the MX list all fail.
sendmail reports the failure attempting to connect to the last MX host (that is, the highest preference value) in the list that it tried. For example, with mail exchangers configured as in the paf.edu example earlier, if the attempts to connect to bling and wheo result in temporary failures, but the attempt to connect to munch fails permanently, the message will be returned as an error. If the attempts to connect to bling and wheo result in permanent failures, but the attempt to connect to munch fails temporarily, the message will be queued.
A host cannot deliver a message to another host for which it is a mail exchanger.
This failure is handled as a normal delivery failure, either by the mail exchanger host or by the host sending to the mail exchanger.

Default Client-Server Operation

This section describes the operation of sendmail servers and clients. This section assumes that sendmail is installed as described earlier in this chapter.

Figure 4-2 “sendmail Client-Server Operation” shows a sendmail server called mailserv and a sendmail client called mailclient in the company.com domain. On mailclient, the SENDMAIL_SERVER_NAME in the /etc/rc.config.d/mailservs file is set to mailserv.company.com. user1 is a user on mailclient.

Figure 4-2 sendmail Client-Server Operation

Outgoing mail from user1 can be "local" mail that is intended for any user on mailclient. Local mail is forwarded to mailserv; this is specified by the setting of the DH macro entry in the /etc/mail/sendmail.cf file on mailclient. (The sendmail installation script sets the DH macro value to the host specified by SENDMAIL_SERVER_NAME.) Outgoing mail that is not local is sent by mailclient to the remote host using MX records. Note that because the DM macro entry in the /etc/mail/sendmail.cf file on mailclient is set to mailserv.company.com, mail from user1 appears to be from user1@mailserv.company.com.

Since mail sent to remote hosts from user1 is sent from user1@mailserv.company.com, replies to user1's messages are returned to mailserv. On mailserv, when sendmail receives mail for user1, it looks up user1 in the aliases database and redirects mail for user1 to user1@mailclient.

You can modify sendmail server and client operations. Most modifications involve changing or re-creating the /etc/mail/sendmail.cf file on the server or client systems. For example, you can define the DM macro on a mail server system. You can also modify the /etc/mail/sendmail.cf file so that the clients relay all outbound mail to the server; this is described in “Modifying the Default sendmail Configuration File”.

How sendmail Handles Errors

By default sendmail immediately reports to standard output any errors that occur during the routing or delivery of a message. sendmail distinguishes between "temporary failures" and "permanent failures."

Permanent failures are mail transactions that are unlikely to succeed without some intervention on the part of the sender or a system administrator. For example, mailing to an unknown user is a permanent failure. A delivery failure of the local mailer because the file system is full is also a permanent failure.

Temporary failures are mail transactions that might succeed if retried later. For example, "connection refused" when attempting to connect to a remote SMTP server is a temporary failure, since it probably means that the server is temporarily not running on the remote host.

How sendmail Handles "Permanent" Failures

Permanent failures include the following:

Temporary failures that have remained in the mail queue for the queue timeout period (set with the Timeout.queuereturn option in the /etc/mail/sendmail.cf file), which is normally five days.
Local recipient user unknown.
The recipient address cannot be resolved by the configuration file.
Permanent delivery agent (mailer) failures.
Inability to find an internet address for a remote host.
A remote SMTP server reports during the SMTP transaction that an address is undeliverable.

In most cases, if message delivery fails permanently on a remote system, mail that includes a transcript of the failed delivery attempt and the undelivered message is returned to the sender. This transcript includes any standard error output from the delivery agent that failed.

If sendmail tries all MX hosts in its preference list and fails to deliver a message, the message is returned to the sender with an error message. For more information, see “MX Records”.

If delivery failed on an alias, and an owner is configured for that alias in the aliases database, sendmail returns the message and transcript to the alias owner.

If there is an Errors-To: header line in the message header, sendmail returns the message and transcript to the address on the Errors-To: line instead of to the sender.

If the Postmaster Copy option (option P) is set to a valid address, sendmail sends a copy of the transcript and failed message (with the message body deleted) to the Postmaster Copy address.

If the attempt to return the failed message itself fails, sendmail returns the message and transcript to the alias postmaster on the local system. The postmaster alias in the default alias file (/usr/newconfig/etc/mail/aliases) resolves to root.

If sendmail is unable to return the message to any of the addresses described above, as a last resort it appends the error transcript and returned message to the file /var/tmp/dead.letter.

Finally, if this fails, sendmail logs the failure and leaves the original failed message in the mail queue so that a future queue-processing daemon will try to send it, fail, and try again to return an error message.

How sendmail Handles "Temporary" Failures

Messages that fail temporarily are saved in the mail queue and retried later. By default, the mail queue is stored in the directory /var/spool/mqueue. sendmail saves the message components in two files created in the mail queue directory. The message body is saved in a "data" file, and the envelope information, the header lines, and the name of the data file are saved in a "queue control" file.

Typically, the sendmail daemon is run with the -q time_interval option, as in the following example:

/usr/sbin/sendmail -bd -q30m

In this example, every 30 minutes, sendmail processes any messages currently in the queue.

When processing the queue, sendmail first creates and sorts a list of the messages in the queue. sendmail reads the queue control file for each message to collect the pre-processed envelope information, the header lines, and the name of the data file containing the message body. sendmail then processes the message just as it did when it was originally collected.

If sendmail detects, from the time stamp in a queued message, that the message has been in the mail queue longer than the queue timeout, it returns the message to the sender. The queue timeout is set with the Timeout.queuereturn option in the /etc/mail/sendmail.cf file and, by default, is five days.