Message Delivery

For each unique mailer and host in the recipient list, sendmail calls the appropriate mailer. Each mailer invocation sends the message to all users receiving it on one host. Mailers that accept only one recipient at a time are handled properly.

The message is sent to the mailer using one of the same three interfaces used to submit a message to sendmail. Each copy of the message has a customized header added to the beginning of the message. The mailer status code is caught and checked and a suitable error message is given, if appropriate. The exit code must conform to a system standard or the generic message Service unavailable is given.

Retransmission Queuing

When the mailer returns a status indicating that it might be able to handle the mail later, sendmail queues the mail and tries again later.

Return to Sender

When errors occur during processing, sendmail returns the message to the sender for retransmission. The letter can be mailed back (when the mail comes from a different site) or written to the dead.letter file in the sender's home directory.

Message-Header Editing

The sendmail program does some editing of the message header automatically. Header lines can be inserted under control of the configuration file. Some lines may be merged; for example, a From: and a Full-name: line may be merged under certain circumstances. A Received header is added to the header lines.

Configuration File

Almost all configuration information is read at runtime from a text file:

•  Macro definitions (defining the value of macros used internally) are encoded.

•  Header declarations (the format of header lines that are specially processed, and lines that are added or reformatted) are embedded.

•  Mailer definitions (with information such as the location and characteristics of each mailer) are included.

•  Name-rewriting rules (a limited pattern-matching system used to rewrite names) are defined.

How sendmail Is Implemented

The following sections provide an overview of the syntax used in sendmail and describe some implementation details.

You can follow flag arguments with recipient name arguments unless you run in SMTP mode. In brief, the format of recipient names is

•  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 writes names in the form of username <system-name> and sends to the electronic system-name rather than to the human username.

•  Double quotes (") denote phrases; backslashes (\) denote characters. Backslashes 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 (that is, used in pairs) and nested. The rewriting rules control the rest of the needed processing.

Mail to Files and Programs

Files and programs are legitimate message recipients. Files provide archival storage of messages, which are useful for project administration and history. Programs are useful as recipients in a variety of situations — for example, to use mailsort to sort mail or to have the vacation program respond with an informational message when users are away.

Any name passing through the initial parsing algorithm as a local name is scanned for two special cases:

•  If the prefix is a vertical bar (|), the rest of the name is processed as a shell command.

•  If the username begins with a slash (/), the name is used as a filename, instead of a login name.

Message Collection

After all of the recipient names are parsed and verified, the message is collected. The message comes in two parts: a message header and a message body. The header and the body are separated by a blank line. The header is formatted as a series of lines of the form:

field-name:field-value

For example, a sample header might be

From: John Smith <Smith@Podunk.edu>

Field-value can be split across lines by starting the subsequent lines with a space or a Tab. Some header fields have special internal meaning and have appropriate special processing. Other headers are simply passed through. Some header fields, such as time stamps, may be added automatically.

The body is a series of text lines. It is completely uninterpreted and untouched, except that lines beginning with a dot have the dot doubled when transmitted over an SMTP channel. This extra dot is then stripped by the receiver.

Message Delivery

The send queue is grouped by the receiving host before transmission to implement message batching. An argument list is built as the scan proceeds. Mail to files is detected during the scan of the send list. The interface to the mailer is performed using one of the techniques described in "Overview of sendmail Functions," earlier in this chapter.

After a connection is established, sendmail makes the per-mailer changes to the header and sends the result to the mailer. If any mail is rejected by the mailer, a flag is set to invoke the return-to-sender function after all delivery is complete.

Queued Messages

If the mailer returns a Temporary failure exit status, the message is queued. A control file describes the recipients as well as 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 parameter of the message. The header of the message is stored in the control file so that the associated data file that is in the queue is simply the original temporary file.

Configuration Overview

Configuration is controlled primarily by a configuration file read at startup. Adding mailers or changing the rewriting or routing information does not require that you recompile sendmail. The configuration file encodes macro definitions, header declarations, mailer definitions, rewriting rules, and options.

Macros

Macros can be used in various ways. Certain macros transmit unstructured textual information into the mail system, such as the name that sendmail uses to identify itself in error messages. Other macros are unused internally and can be used as shorthand in the configuration file.