The Sendmail Utility

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 programs that create, route, and deliver the message. It is usually not seen directly by either the sender or the 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 receives messages through any of the following methods:

How Sendmail Routes Messages

Sendmail routes messages as follows:

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

After 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 the rules defined in the Sendmail configuration file, /etc/mail/sendmail.cf.

Sendmail invokes a separate delivery agent 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 HP supports for use with 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. Instead, Sendmail opens a TCP/IP connection to the SMTP server on the specified host and transmits the message using SMTP.

Figure 1-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 can 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 expanding all the aliases, Sendmail routes mail that is addressed to a local user to the local mailer (/usr/bin/rmail), which deposits the message in the user’s mailbox.

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:

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

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 2822-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 mail exchanger (MX) records for the remote host. If there are any, it attempts to deliver the mail to each of them, in the order of preference, 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 1-3 “How Sendmail Resolves Addresses with Mixed Operators”.

Table 1-3 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

 

Mail Exchanger (MX) Records

The BIND name server, if it is in use on your host, provides MX records. These can be used to notify 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 HP-UX IP address and Client Management Guide at the URL http://www.docs.hp.com/hpux/netcom/index.html#Internet%20Services.

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 answer, Sendmail sorts them in preference order, highest preference (lowest number) first. If the local host appears in the list, the local host 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 one host backup by receiving mail for the host when it is down

• To arrange the 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.

Normally, 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 bling 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 are relayed to the host gw.dcc.nz. HP recommends 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.

  If the query fails temporarily (that is, h_errno is set to TRY_AGAIN) the message is 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 is 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 is 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.

How Sendmail Improves Mail Queue Performance

Mail queue performance is impacted by the number of entries in the queue directories. Multiple Queue Directories improves mail queue performance in Sendmail. This feature facilitates the parallel processing of mail by spreading process loads across multiple disks, thereby improving the queue performance. UNIX files take a long time to open when entries in the directories exceed 100.

In order to use multiple directories, you must supply the QueueDirectory option in the sendmail.cf file with a value ending with *.

For example, if you specify the following in the configuration file, all the directories or links to directories that begin with g will be used:

O QueueDirectory=/var/spool/mqueue/g*

If there are five directories, g1, g2, g3, g4, and g5, Sendmail uses all five directories when the Sendmail daemon is restarted. Mail is randomly assigned to the queue directories. Do not change the queue directory structure when Sendmail is running.

You can flush individual mail queues by specifying the following on the command line:

sendmail -q -O QueueDirectory=/var/spool/mqueue/g1

sendmail -q -O QueueDirectory=/var/spool/mqueue/g3

You can use the mailq command to display the mail queue, as shown in the following example:

#mailq
   /var/spool/mqueue/g1 is empty
   /var/spool/mqueue/g2 (1 request)
--Q-ID--- -Size- --Q-Time-- ----------Sender/Recipient--
 gBJ2va   02544    5 Wed Dec 18 21:57   root root 	
   /var/spool/mqueue/g2 is empty
   /var/spool/mqueue/g3 is empty
 Total Requests: 0

An efficient queue file-naming system is also being provided in this release. The algorithm used to name files ensures that the names will be unique for 60 years. The queued items can be moved between queues with ease.

Default Client/Server Operation

This section describes the operation of Sendmail servers and clients. Figure 1-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 1-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; you specify this by setting 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. 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.

Because 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 the intervention 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, an error message connection refused displayed while 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 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.

While 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 preprocessed 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.