is scattered throughout the file, you might forget to change it in some places. Also, if important information is centralized, you can comment it extensively in a single place. Because configuration files tend to be obscure at best, a liberal dose of comments is a good antidote to that sinking feeling you get when, six months later, you wonder why you made a change.

The H Operator—Header Definitions

You probably won't want to change the header definitions given in the V8 sendmail configuration files because they already follow accepted standards. Here are some sample headers:

H?D?Date: $a

H?F?Resent-From: $q

H?F?From: $q

H?x?Full-Name: $x

Note that header definitions can use macros, which are expanded, when inserted into a letter. For example, the $x macro used in the preceding Full-Name: header definition expands to the full name of the sender.

The optional ?mailerflag? construct tells sendmail to insert a header only if the chosen mailer has that mailer flag set. (See "The M Operator—Mailer Definitions" later in this chapter.)

Suppose that the definition of your local mailer has a flag Q, and sendmail selects that mailer to deliver a letter. If your configuration file contains a header definition like the following one, sendmail will insert that header into letters delivered through the local mailer, substituting the value of the macro $F:

H?Q?X-Fruit-of-the-day: $F

Why would you use the ?mailerflag? feature? Different protocols can require different mail headers. Because they also need different mailers, you can define appropriate mailer flags for each in the mailer definition and use the ?mailerflag? construct in the header definition to tell sendmail whether to insert the header.

The O Operator—Setting Options

sendmail has many options that change its operation or tell it the location of files it uses. Most of them can be given either on the command line or in the configuration file. For example, you can specify the location of the aliases file in either place. To specify the aliases file on the command line, you use the -o option:

$ sendmail -oA/etc/aliases [other arguments...]

To do the same thing in the configuration file, you include a line like this:

OA/etc/aliases

Either use is equivalent, but options such as the location of the aliases file rarely change, and most people set them in sendmail.cf. The V8 sendmail options are fully described in the SIOG.

The P Operator—Mail Precedence

Users can include mail headers indicating the relative importance of their mail, and sendmail can use those headers to decide the priority of competing letters. Precedences for V8 sendmail are given as follows:

Pspecial-delivery=100

Pfirst-class=0

Plist=-30

Pbulk=-60

Pjunk=-100

If users who run large mailing lists include the header Precedence: bulk in their letters, sendmail gives them a lower priority than letters with the header Precedence: first-class.

The V Operator—sendmail.cf Version Levels

As V8 sendmail evolves, its author adds new features. The V operator lets V8 sendmail know what features it should expect to find in your configuration file. Older versions of sendmail don't understand this command. The SIOG explains the different configuration file version levels in detail.

The K Operator—Key Files

sendmail has always used keyed databases—for example, the aliases databases. Given the key postmaster, sendmail looks up the data associated with that key and returns the names of the accounts to which the postmaster's mail should be delivered. V8 sendmail extends this concept to arbitrary databases, including NIS maps (Sun's Network Information Service, formerly known as Yellow Pages or YP; see Chapter 13 for details). The K operator tells sendmail the location of the database, its class, and how to access it. V8 sendmail supports the following classes of user-defined databases: dbm, btree, hash, and NIS. The default used when compiling under Linux is the dbm format. See the SIOG for the lowdown on key files.

The M Operator—Mailer Definitions

Mailers are either MTAs or final delivery agents. Recall that the aliases file allows you to send mail to a login name (which might be aliased to a remote user), a program, or a file. A special mailer can be defined for each purpose. And even though the SMTP MTA is built in, it must have a mailer definition to tailor sendmail's SMTP operations.

Mailer definitions are important because all recipient addresses must resolve to a mailer in ruleset 0. Resolving to a mailer is just another name for sendmail's main function, mail routing. For example, resolving to the local mailer routes the letter to a local user via the final delivery agent defined in that mailer (such as /bin/mail) and resolving to the SMTP mailer routes the letter to another host via sendmail's built-in SMTP transport, as defined in the SMTP mailer. A concrete example of a mailer definition will make this information clearer. Because sendmail requires a local mailer definition, look at the following:

Mlocal, P=/bin/mail, F=lsDFMfSn, S=10, R=20, A=mail -d $u

All mailer definitions begin with the M operator and the name of the mailer—in this case, local. Other fields follow, separated by commas. Each field consists of a field name and its value, separated by an equal sign (=). The allowable fields are explained in section 5.1.4 of the SIOG.

In the preceding local mailer definition, the P= equivalence gives the pathname of the program to run to deliver the mail, /bin/mail. The F= field gives the sendmail flags for the local mailer. (See also "The H Operator—Header Definitions" earlier in the chapter.) These flags are not passed to the command mentioned in the P= field but are used by sendmail to modify its operation depending on the mailer it chooses. For example, sendmail usually drops its superuser status before invoking mailers, but you can use the S mailer flag to tell sendmail to retain this status for certain mailers.

The S= and R= fields specify rulesets for sendmail to use in rewriting sender and recipient addresses. Because you can give different R= and S= flags for each mailer you define, you can rewrite addresses differently for each mailer. For example, if one of your UUCP neighbors runs obsolete software that doesn't understand domain addressing, you might declare a special mailer just for that site and write mailer-specific rulesets to convert addresses into a form its mailer could understand.

The S= and R= fields can also specify different rulesets to rewrite the envelope and header addresses. (See "Header and Envelope Addresses" earlier in this chapter.) A specification like S=21/31 tells sendmail to use ruleset 21 to rewrite sender envelope addresses and ruleset 31 to rewrite sender header addresses. This capability comes in handy for mailers that require addresses to be presented differently in the envelope and the headers.

The A= field gives the argument vector (command line) for the program that will be run—in this case, /bin/mail. In this example, sendmail runs the command as mail -d $u, expanding the $u macro to the name of the user to whom the mail should be delivered:

/bin/mail -d joe

You could type this exact same command to your shell at a command prompt.

You might want to use many other mailer flags to tune mailers—for example, to limit the maximum message size on a per-mailer basis. These flags are all documented in section 5.1.4 of the SIOG.