Each time sendmail starts up, it reads a configuration file that specifies the operations of that instance of sendmail. A sendmail configuration file includes:
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''.
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.
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.
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:
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:
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
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.
The mailaddr(ADMN) manual page and the following text provide brief overviews of the RFC 822 format.
Parentheses, angle brackets, and double quotes must be properly balanced and nested. The rewriting rules control remaining parsing.
sendmail applies the following special processing to mail intended for the ``local'' mailer:
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:
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:
email@example.comThen 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:
The syntax for including a file is:
:include: pathnameWhen 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/userlistIt 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.
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.
To conform to RFC 822, the header must be a series of lines of the form:
field-name: field-valueA 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.
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.
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.
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.
If the mailer returns a
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.
``Viewing the mail queue''
for more information on the mail queue.