sendmail administration

sendmail execution

Each time sendmail starts up, it reads a configuration file that specifies the operations of that instance of sendmail. A sendmail configuration file includes:

definitions of mailers sendmail can use to route mail
rules for parsing addresses
definitions for rewriting message headers
settings of various options

User information database

The user database allows sendmail to rewrite sender and recipient addresses under control of an external database file. It is used to locate the default maildrop at a site, but allow you to override this by sending to a specific host. If the user database is enabled, a local address is looked up in that database after aliasing and before forwarding. For more information on the user database see ``Creating a user information database''.

Using options and flags

sendmail options control operations such as whether sendmail delivers mail immediately after processing or queues the mail for delivery when the queue is next processed. Options set in the configuration file can also be overridden by passing options to sendmail as arguments.

Flags determine things such as the interval at which sendmail processes the mail queue and whether to use an alternate configuration file for this instance of sendmail.

These options and flags alter sendmail's processes of address parsing, message collection, and storage. Part of the address parsing process is the rewriting of addresses. Some additional rewriting may also take place during sendmail's delivery phase.

For a complete list of options see ``O--set option''. Command-line flags, different from the options and passed to sendmail as arguments, also influence processing. See the sendmail(ADMN) manual page for a description of these flags.

Configuration file priority

sendmail looks in two places for its configuration file and uses the highest priority file available. The highest priority is a filename passed as a flag argument to the sendmail daemon. If a filename is passed to sendmail using the -C flag, sendmail reads this file for configuration information and ignores all others.

If the -C flag is not specified on the command line, sendmail reads /usr/lib/sendmail.cf. This is the standard configuration file created by default when initializing sendmail.

Mailers

sendmail hands off mail by executing a mailer with arguments as defined in the mailer definition in the configuration file.

The mailers in the standard sendmail configuration are:

smtp: used to route mail via the Internet by calling the SMTP server on the recipient machine of the mail recipient.
uucp: used to route mail via UUCP by executing uux(C).
local: used to deliver mail to recipients on the local host by executing lmail(ADMN). lmail delivers the mail to the recipient's mailbox file called recipient_name at the location /usr/spool/mail/recipient_name. The recipient extracts the mail from this file using an MUA such as mail.
prog: used to deliver mail to a program (using an invocation of the shell). This is explained further in ``Mail to files and programs''.
x400: used to deliver X.400-style addressed mail from the local system to the X.400 gateway machine specified in the configuration file. In the standard sendmail configuration, this mailer calls the program /usr/lib/sendxmail on the X.400 gateway machine.

If a mailer returns a status that indicates it cannot handle the message now but might be able to handle it later, sendmail puts the message in the mail queue and tries again to deliver it the next time the mail queue is processed. If a message is not deliverable (which can be caused by unknown recipients, a delivery timeout, a destination mailer that refuses to accept the message, or errors during processing), sendmail notifies the sender and returns the message. The notification includes an error code when possible.

Recipient address parsing

Recipient addresses are passed to sendmail as arguments or via the SMTP RCPT command depending on the interface to sendmail. Each address is parsed in order to build a recipient list for the message being processed. Parsing involves resolving each address to an internally used form that identifies the mailer to be used. If the mailer identified for any address is the ``local'' mailer, the following additional processing occurs:

sendmail checks to see if the address matches an entry in the alias database; if so, it expands the alias and appends the new address to the recipient list.
If no alias is found (or if the alias points back to the same address), sendmail appends ``:maildrop'' to the addressee name to form a lookup key and then searches the user information database. If a match in the database is found, sendmail appends the new address to the recipient list.
If no match in the user information database occurs (or if the maildrop points to the same address), sendmail checks to see if the user has a $HOME/.forward file. If so, sendmail appends the new addresses found there to the recipient list.

When new recipient addresses are appended to the recipient list through special ``local'' mailer address processing, the old name is retained in the list and a flag is set that tells the delivery phase to ignore the old name. In this way the recipient list is kept free from duplicates, preventing alias loops and duplicate messages from being delivered to the same recipient, as might occur if a person is in two groups.

At this stage, before the message is collected, the address syntax has been checked and local addresses verified; detailed checking of host names and host addresses, however, is deferred until message delivery.

Address format

Before sendmail can deliver a message, it must interpret the address. sendmail expects addresses to conform, or be convertible, to a format defined in RFC 822. sendmail passes each recipient address through a set of filters called ``rewriting rules'' to determine whether it understands the address and can deliver to that address via one of its known mailers.

NOTE: sendmail also recognizes mail addresses in X.400 format, but will not try to interpret or deliver mail to them. Instead, sendmail will forward such mail to an X.400 mail gateway, if such a gateway is defined in the configuration file.

The mailaddr(ADMN) manual page and the following text provide brief overviews of the RFC 822 format.

Anything in parentheses is thrown away (as a comment).
Anything in angle brackets ( ``<>'' ) is preferred over anything else. This rule implements the Internet standard that addresses of this form will send to the electronic machine-address rather than the human user name:

user name <machine-address>
Double quotes ( " ) quote phrases; backslashes quote characters. Backslashes are more powerful because they cause otherwise equivalent phrases to compare differently - for example, user and "user" are equivalent, but \user is different from either of them.

Parentheses, angle brackets, and double quotes must be properly balanced and nested. The rewriting rules control remaining parsing.

Special ``local'' mailer address processing

sendmail applies the following special processing to mail intended for the ``local'' mailer:

Aliasing and user information database lookups apply across the entire system. Forwarding allows all users to redirect incoming mail destined for their accounts. Inclusion directs sendmail to read a file for a list of addresses. Inclusion is normally used in conjunction with aliasing.

Aliasing

Aliasing expands recipient names into address lists using a system-wide text file that associates a recipient name with a list of addresses. Only names that parse as local are allowed as aliases. This guarantees a unique key. The identity of the alias text file is configured through the sendmail configuration file and is configured to be /usr/lib/mail/aliases by the standard configuration. sendmail indexes this file to speed access. For more information on the alias files see the following:

Forwarding

After aliasing and a user information database lookup, local and valid recipients are checked for the existence of a .forward file in their home directory. If one exists, the message is not sent to that user, but rather to the list of users in that file. Often, this list contains a single address and is used only for network mail forwarding. For example, suppose user dbaker has a .forward file in $HOME with contents:

   dbaker@scribe.npr.com

Then any mail arriving for dbaker would be directed to dbaker's account on scribe.npr.com.

Forwarding also permits a user to specify a private incoming mailer. For example, this forwarding line defines a different incoming mailer:

   "|/usr/local/newmail myname"

Including

The syntax for including a file is:

   :include: pathname

When sendmail sees an address in this form, it reads the file specified by pathname and sends to all users listed in that file.

The intention is not to support direct use of this feature, but rather to use this as a subset of aliasing. In the following example, use of the ``include'' address format allows a project with the mail alias projectC to maintain a project mailing list without interaction with the system administration, even if the alias file is protected.

   projectC: :include:/usr/project/userlist

It is not necessary to rebuild the index on the alias database when a list of this type is changed. All that is needed is to edit the include file to reflect the changes. In this example, the include file is /usr/project/userlist.

Message collection and storage

Once all recipient addresses are parsed and verified, sendmail collects the message. To simplify the program interface, the message is collected even if no addresses are valid; in this case the message is then returned to the sender with an error.

The message format must conform to RFC 822, which means it must consist of two parts: a message header and a message body, separated by a blank line. Further, RFC 822 requires that the header be in a format shown below. The header is parsed and stored in memory, and the body of the message is saved in a temporary file.

Message header

To conform to RFC 822, the header must be a series of lines of the form:

   field-name: field-value

A field-value can be split across lines by starting the lines that follow with a space or a tab. Some header fields have special internal meaning, in which case sendmail may perform special processing on them. Other headers are simply passed through. Some header fields, such as time stamps, may be added automatically under control of the configuration file. Some lines can be merged. For example, a ``From:'' line and a ``Full-name:'' line can be merged under certain circumstances. Additional editing of a header may take place during the delivery phase to customize the header to meet mailer requirements.

Message body

No RFC 822 formatting requirements are imposed on the message body, except that they must be lines of text; binary data is not allowed. It is completely uninterpreted and untouched by sendmail, except that lines beginning with a dot have the dot doubled when transmitted over an SMTP channel. This extra dot is stripped by the receiver. (SMTP uses lines beginning with a dot to signal the end of the message.) The message body is stored in a separate file from the header information.

Message delivery

sendmail can be configured to deliver a message at the time it receives the message (immediate delivery) or to queue the message for delivery when the mail queue is processed. Immediate delivery can be configured to happen synchronously or asynchronously (in the background). This section on message delivery applies to all of the above.

The result of the recipient address parsing is a triple consisting of ``mailer, host, user'' for each recipient. The mailer is one of the defined mailers in the configuration file; host is the destination host; and user is the recipient on that host.

For each unique ``mailer,host'' pairing in the recipient list, sendmail calls the appropriate mailer. sendmail will try to batch deliver the message to all recipients on the same host in one invocation of the receiving mailer. Mailers that only accept one recipient at a time are handled accordingly. After a connection with the mailer is established, sendmail customizes the message header as necessary for correct interpretation by the recipient mailer and sends the result to the mailer.

The receiving mailer status code is caught and checked. If any mail is rejected by the mailer, a flag is set to invoke the return-to-sender function after all delivery completes. An exit code from the receiving mailer must conform to a system standard; otherwise, sendmail forwards a generic message such as Service unavailable to the originator of the mail.

If the mailer returns a status code indicating that the message should be sent later, sendmail puts the mail on the queue and tries again later.

Return to sender

If errors occur during processing, sendmail returns the message to the sender for retransmission. If the user agent (mail) detects the error, then it is put in the dead.letter file located in the sender's home directory. If a sendmail server is connecting with a sendmail client on another machine, then the user is presumed to have become detached from the transaction, and so the message is mailed back to them.

Queued messages

If the mailer returns a temporary failure exit status, the message is queued. A control file for the message describes the recipients to be sent to and various other parameters. This control file is formatted as a series of lines, each describing a sender, a recipient, the time of submission, or some other significant parameter of the message. The header of the message is stored in the control file, so that the associated data file in the queue is just the temporary message file that was originally collected. See ``Viewing the mail queue'' for more information on the mail queue.