Every time sendmail starts up, it reads sendmail.cf. For this reason, the syntax of the sendmail.cf commands is designed to be easy for sendmail to parse - not necessarily easy for humans to read. As a consequence, sendmail commands are very terse, even by UNIX standards.
The configuration command is not separated from its variable or value by any spaces. This "run together" format makes the commands hard to read. Figure 10.2 illustrates the format of a command. In the figure, a define macro command assigns the value nuts.com to the macro D.
Starting with version 8 of sendmail, variable names are no longer restricted to a single character. Long variable names, enclosed in braces, are now acceptable. For example, the define macro shown in Figure 10.2 could be written:
However, a quick check of the sendmail.cf delivered with my Linux system shows that not a single long variable name was used. The traditional, short variable names are still the most common. This terse syntax can be very hard to decipher, but it helps to remember that the first character on the line is always the command. From this single character you can determine what the command is and therefore its structure. Table 10.1 lists the sendmail.cf commands and their syntax.
|Version Level||V||Specify version level.|
|Define Macro||D||Set macro |
|Define Class||C||Set class |
|Define Class||F||Load class |
|Set Option||O||Set |
|Trusted Users||T||Trusted users are |
|Set Precedence||P||Set |
|Define Mailer||M||Define mailer |
|Define Header||H[?||Set header format.|
|Set Ruleset||S||Start ruleset number |
|Define Rule||R||Rewrite |
|Key File||K||Define database |
The version level command is an optional command not found in all sendmail.cf files. You don't add a V command to the sendmail.cf file or change one if it is already there. The V command is inserted into the configuration file when it is first built from m4 macros or by the vendor.
level number on the V command line indicates the
version level of the configuration syntax. V1 is the oldest
configuration syntax and V7 is the version supported by
sendmail V8.8.5. Every level in between adds some feature extensions.
vendor part of the V command identifies if any vendor
is supported. The default
vendor value for the
sendmail distribution is "Berkeley".
The V command tells the sendmail executable the level of syntax and commands required to support this configuration. If the sendmail program cannot support the requested commands and syntax, it displays the following error message:
# /usr/lib/sendmail -Ctest.cf test.cf: line 63: Bad V line: Only V1/sun syntax is supported in this release
The error message shown above indicates that this sendmail program supports level 1 configuration files with Sun syntax extensions.  The example was produced on a Solaris 2.5.1 running the sendmail program that came with the operating system. In the example we attempted to read a sendmail.cf that was created by the m4 macros that came with sendmail 8.8.5. The syntax and functions needed by the sendmail.cf file are not available in the sendmail program. To use this configuration file, we would have to compile a newer version of the sendmail program. See Appendix E for an example of compiling sendmail.
 See Table 10-4 for Sun-specific syntax.
The define macro command (D) defines a macro and stores a value in it. Once the macro is defined, it is used to provide the stored value to other sendmail.cf commands and directly to sendmail itself. This allows sendmail configurations to be shared by many systems, simply by modifying a few system-specific macros.
A macro name can be any single ASCII character or, as of sendmail V8, a word enclosed in curly braces. User-created macros use uppercase letters as names. sendmail's own internal macros use lowercase letters and special characters as names. This does not mean that you won't be called upon to define a value for a macro with a lowercase name. A few of these internal macros are sometimes defined in the sendmail.cf file. Table 10.2 provides a complete list of sendmail's internal macros.
|a||Origination date in RFC 822 format|
|b||Current date in RFC 822 format|
|d||Date in UNIX (ctime) format|
|e||SMTP entry message|
|f||Sender \(lqfrom\(rq address|
|g||Sender address relative to the recipient|
|j||Fully qualified domain name (host plus domain)|
|k||UUCP node name|
|l||Format of the UNIX from line|
|m||Name of this domain (domain only)|
|n||Name of the daemon (for error messages)|
|o||Set of "operators" in addresses|
|q||Default format of sender address|
|t||Numeric representation of the current time|
|v||Version number of sendmail|
|w||Hostname of this site (host only)|
|x||Full name of the sender|
|z||Home directory of the recipient|
|-||Validated sender address|
 Obsolete in sendmail V8.
To retrieve the value stored in a macro, reference it as $x, where x is the macro name. Macros are expanded when the sendmail.cf file is read. A special syntax, $&x, is used to expand macros when they are referenced. The $&x syntax is only used with certain internal macros that change at runtime.
The code below defines the macros R, M, and Q. After this code executes, $R returns almond, $M returns nuts.com, and $Q returns almond.nuts.com. This sample code defines Q as containing the value of R ($R), plus a literal dot, plus the value of M ($M).
DRalmond DMnuts.com DQ$R.$M
If you customize your sendmail.cf file, it will probably be necessary to modify some macro definitions. The macros that usually require modification define site-specific information, such as hostnames and domain names.
D is the define macro command;
X is the macro
being defined; and
$g says to use the value stored in macro
g. But what does "
$?x ($x)$." mean? The construct
$?x is a conditional. It tests whether macro
x has a value
set. If the macro has been set, the text following the conditional is
$. construct ends the conditional.
Given this, the assignment of macro X is interpreted as follows: X is assigned the value of g; and if x is set, it is also assigned a literal blank, a literal left parenthesis, the value of x, and a literal right parenthesis.
So if g contains email@example.com and x contains Craig Hunt, X will contain:
firstname.lastname@example.org (Craig Hunt)
This is interpreted as:
x is set;
end if (
Two commands, C and F, define sendmail classes. A class is similar to an array of values. Classes are used for anything with multiple values that are handled in the same way, such as multiple names for the local host or a list of uucp hostnames. Classes allow sendmail to compare against a list of values, instead of against a single value. Special pattern matching symbols are used with classes. The $= symbol matches any value in a class, and the $~ symbol matches any value not in a class. (More on pattern matching later.)
Like macros, classes usually have single-character names, and user-created classes use uppercase letters for names. Class values can be defined on a single line, on multiple lines, or loaded from a file. For example, class w is used to define all of the hostnames by which the local host is known. To assign class w the values goober and pea, you can enter the values on a single line:
Or you can enter the values on multiple lines:
You can also use the F command to load the class values from a file. The F command reads a file and stores the words found there in a class variable. For example, to define class w and assign it all of the strings found in /etc/sendmail.cw, use:
You may need to modify a few class definitions when creating your sendmail.cf file. Frequently information relating to uucp, to alias hostnames, and to special domains for mail routing is defined in class statements. If your system has a uucp connection as well as a TCP/IP connection, pay particular attention to the class definitions. But in any case, check the class definitions carefully and make sure they apply to your configuration.
Here we grep the Linux sample configuration file for lines beginning with C or F:
grep '^[CF]' linux.smtp.cfCwlocalhost CP. CO @ % C.. CE root
This grep shows that linux.smtp.cf defines classes w, P, O, ., and E. w contains the host's alias hostnames. P holds pseudo-domains used for mail routing. O stores operators that cannot be part of a valid username. The class . (dot) is primarily of interest because it shows that variable names do not have to be alphabetic characters. E lists the usernames that should always be associated with the local host's fully qualified domain name, even if simplified email addresses are being used for all other users. (More on simplified addresses later.) In our sample file, the variables are all assigned default values.
Remember that your system will be different. The uppercase letters used for some of these class names mean that they are user-created classes. These same class names may be used for other purposes on your system, and are only presented here as an example. Carefully read the comments in your sendmail.cf file for guidance as to how classes and macros are used in your configuration.
The class names that are lowercase letters or special characters are reserved for internal sendmail use. All internal classes defined in sendmail versions after 8.8 are shown in Appendix E. Most of these can be ignored. Only class w, which defines all of the hostnames the system will accept as its own, is commonly modified in the sendmail.cf file.
The set option commands (O) command is used to define the sendmail environment. Use the O command to set values appropriate for your installation. The value assigned to an option is a string, an integer, a Boolean, or a time interval, as appropriate for the individual option. All options define values used directly by sendmail.
There are no user-created options. The meaning of each sendmail option is defined within sendmail itself. Appendix E lists the meaning and use of each option, and there are plenty of them.
A few sample options from the linux.smtp.cf file are shown below. The AliasFile option defines the name of the sendmail aliases file as /etc/aliases. If you want to put the aliases file elsewhere, change this option. The TempFileMode option defines the default file mode as 0600 for temporary files created by sendmail in /var/spool/mqueue. The Timeout.queuereturn option sets the timeout interval for undeliverable mail, here set to five days (5d). These options show the kind of general configuration parameters set by the option command.
# location of alias file O AliasFile=/etc/aliases # temporary file mode O TempFileMode=0600 # default timeout interval O Timeout.queuereturn=5d
The syntax of the option command shown in this example and in Table 10.1 was introduced in sendmail version 8.7.5. Prior to that the option command used a syntax more like the other sendmail commands. The old syntax is: Oovalue, where O is the command, o is the single character option name, and value is the value assigned to the option. The options shown in the previous discussion, if written in the old syntax, would be:
# location of alias file OA/etc/aliases # temporary file mode OF0600 # default timeout interval OT5d
Appendix E contains a full listing of the old options as well as the new options.
Most of the options defined in a sample file don't require modification. People change options settings because they want to change the sendmail environment, not because they have to. The options in your configuration file are almost certainly correct for your system.
The T command defines a list of users who are trusted to override the sender address using the mailer -f flag.  Normally the trusted users are defined as root, uucp, and daemon. Trusted users can be specified as a list of usernames on a single command line, or on multiple command lines. The users must be valid usernames from the /etc/passwd file.
 Mailer flags are listed in Appendix E.
The most commonly defined trusted users are:
Troot Tdaemon Tuucp
Most sites do not need to modify this list.
Precedence is one of the factors used by sendmail to assign priority to messages entering its queue. The P command defines the message precedence values available to sendmail users. The higher the precedence number, the greater the precedence of the message. The default precedence of a message is 0. Negative precedence numbers indicate especially low-priority mail. Error messages are not generated for mail with a negative precedence number, making low priorities attractive for mass mailings. Some commonly used precedence values are:
Pfirst-class=0 Pspecial-delivery=100 Plist=-30 Pbulk=-60 Pjunk=-100
To specify the precedence he desires, a user adds a Precedence header to his message. He uses the text name from the P command in the Precedence header to set the specific precedence of the message. Given the precedence definitions shown above, a user who wanted to avoid receiving error messages for a large mailing could select a message precedence of -60 by including the following header line in his mail:
The H command defines the format of header lines that sendmail inserts into messages. The format of the header command is the H command, optional header flags enclosed in question marks, a header name, a colon, and a header template. The header template is a combination of literals and macros that are included in the header line. Macros in the header template are expanded before the header is inserted in a message. The same conditional syntax used in macro definitions can be used in header templates, and it functions in exactly the same way: it allows you to test whether a macro is set and to use another value if it is not set.
The header flags often arouse more questions than they merit. The function of the flags is very simple. The header flags control whether or not the header is inserted into mail bound for a specific mailer. If no flags are specified, the header is used for all mailers. If a flag is specified, the header is used only for a mailer that has the same flag set in the mailer's definition. (Mailer flags are listed in Appendix E.) Header flags only control header insertion. If a header is received in the input, it is passed to the output, regardless of the flag settings.
Some sample header definitions from the linux.smtp.cf sample file are:
H?P?Return-Path: $g H?D?Date: $a H?F?From: $?x$x <$g>$|$g$. H?x?Full-Name: $x HSubject: H?M?Message-Id: <$t.$i@$j>
The headers provided in your system's sendmail.cf are sufficient for most installations. It's unlikely you'll ever need to change them.
name is an arbitrary name used internally by sendmail
to refer to this mailer. The name doesn't matter as long as it is used
consistently within the sendmail.cf file to refer to this
mailer. For example, the mailer used to deliver SMTP mail within the
local domain might be called smtp on one system, and it might be
called ether on another system. The function of both mailers is
the same, only the names are different.
There are a few exceptions to this freedom of choice. The mailer that delivers local mail to users on the same machine must be called local, and a mailer named local must be defined in the sendmail.cf file. Three other special mailer names are:
Delivers mail to programs.
Sends mail to files.
Directs mail to
Of these, only the prog mailer must be defined in the sendmail.cf file. The other two are defined internally by sendmail.
The mailer name is followed by a comma-separated list of field=value pairs that define the characteristics of the mailer. Table 10.3 shows the single character field identifiers and the contents of the value field associated with each of them. Most mailers don't require all of these fields.
|P||Path||Path of the mailer||P=/bin/mail|
|F||Flags||sendmail flags for this mailer||F=lsDFMe|
|S||Sender||Rulesets for sender addresses||S=10|
|R||Recipient||Rulesets for recipient addresses||R=20|
|A||Argv||The mailer's argument vector||A=sh -c $u|
|E||Eol||End-of-line string for the mailer||E=\r\n|
|M||Maxsize||Maximum message length||M=100000|
|L||Linelimit||Maximum line length||L=990|
|D||Directory||prog mailer's execution directory||D=$z:/|
|U||Userid||User and group ID used to run mailer||U=uucp:wheel|
|N||Nice||nice value used to run mailer||N=10|
|C||Charset||Content-type for 8-bit MIME characters||C=iso8859-1|
|T||Type||Type information for MIME errors||T=dns/rfc822/smtp|
The Path (P) fields contain either the path to the mail delivery program or the literal string [IPC]. Mailer definitions that specify P=[IPC] use sendmail to deliver mail via SMTP.  The path to a mail delivery program varies from system to system depending on where the systems store the programs. Make sure you know where the programs are stored before you modify the Path field. If you use a sample configuration from another computer, such as the samples we use in this chapter, make sure that the mailer paths are valid for your system.
 Sun systems use [TCP] as well as [IPC].
The Flags (F) field contains the sendmail flags used for this mailer. These are the mailer flags referenced earlier in this chapter under "Defining Mail Headers," but mailer flags do more than just control header insertion. There are a large number of flags. Appendix E describes all of them and their functions.
The Sender (S) and the Recipient (R) fields identify the rulesets used to rewrite the sender and recipient addresses for this mailer. Each ruleset is identified by its number. We'll have more to say about rulesets later in this chapter, and we will refer to the S and R values when troubleshooting the sendmail configuration.
The Argv (A) field defines the argument vector passed to the mailer. It contains, among other things, macro expansions that provide the recipient username (which is $u),  the recipient hostname ($h), and the sender's from address ($f). These macros are expanded before the argument vector is passed to the mailer.
 In the prog mailer definition, $u actually passes a program name in the argument vector.
The End-of-line (E) field defines the characters used to mark the end of a line. A carriage return and a line feed (CRLF) is the default for SMTP mailers.
Linelimit (L) defines, in bytes, the maximum length of a line that can be contained in a message handled by this mailer. This mailer field was introduced in sendmail V8. Previous versions of sendmail limited lines to 80 characters because this was the limit for SMTP mail before MIME mail was introduced.
The Directory (D) field specifies the working directory for the prog mailer. More than one directory can be specified for the directory field by separating the directory paths with colons. The example in Table 10.3 tells prog to use the recipient's home directory, which is the value returned by the internal macro $z. If that directory is not available, it should use the root (/) directory.
Specify the default user and the group ID used to execute the mailer with the Userid (U) field. The example U=uucp:wheel says that the mailer should be run under the user ID uucp and the group ID wheel. If no value is specified for the Userid field, the value defined by the DefaultUser option is used.
Use Nice (N) to change the nice value for the execution of the mailer. This allows you to change the scheduling priority of the mailer. This is rarely used. If you're interested, see the nice manpage for appropriate values.
The last two fields are used only for MIME mail. Charset (C) defines the character set used in the Content-type header when an 8-bit message is converted to MIME. If Charset is not defined, the value defined in the DefaultCharset option is used. If that option is not defined, unknown-8bit is used as the default value.
The Type (T) field defines the type information used in MIME error messages. MIME-type information defines the mailer transfer agent type, the mail address type, and the error code type. The default is dns/rfc822/smtp.
Mlocal, P=/usr/bin/procmail, F=lsDFMAw5:/|@ShP, S=10/30, R=20/40, T=DNS/RFC822/X-Unix, A=procmail -a $h -d $u Mprog, P=/bin/sh, F=lsDFMoeu, S=10/30, R=20/40, D=$z:/, T=X-Unix, A=sh -c $u Msmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990, T=DNS/RFC822/SMTP, A=IPC $h Mesmtp, P=[IPC], F=mDFMuXa, S=11/31, R=21, E=\r\n, L=990, T=DNS/RFC822/SMTP, A=IPC $h Msmtp8, P=[IPC], F=mDFMuX8, S=11/31, R=21, E=\r\n, L=990, T=DNS/RFC822/SMTP, A=IPC $h Mrelay, P=[IPC], F=mDFMuXa8, S=11/31, R=61, E=\r\n, L=2040, T=DNS/RFC822/SMTP, A=IPC $h
This example contains the following mailer definitions:
A definition for local mail delivery, always called local. This definition is required by sendmail.
A definition for delivering mail to programs, always called prog. This definition is found in most configurations.
A definition for TCP/IP mail delivery, here called smtp.
A definition for an Extended SMTP mailer, here called esmtp.
A definition for an SMTP mailer that handles unencoded 8-bit data, here called smtp8.
A definition for a mailer that relays TCP/IP mail through an external mail relay host, here called relay.
A close examination of the fields in one of these mailer entries, for example the entry for the smtp mailer, shows the following:
A mailer, arbitrarily named smtp, is being defined.
The path to the program used for this mailer is [IPC], which means deliver of this mail is handled internally by sendmail.
The sendmail flags for this mailer say that this mailer can send to multiple recipients at once; that Date, From, and Message-Id headers are needed; that uppercase should be preserved in hostnames and user names; and that lines beginning with a dot have an extra dot prepended. Refer to Appendix E for more details.
The sender address in the mail "envelope" is processed through ruleset 11 and the sender address in the message is processed through ruleset 31. More on this later.
All recipient addresses are processed through ruleset 21.
Lines are terminated with a carriage return and a line feed.
This mailer will handle lines up to 990 bytes long.
The MIME-type information for this mailer says that DNS is used for hostnames, RFC 822 email addresses are used, and SMTP error codes are used.
The meaning of each option in an argument vector is exactly as defined on the manpage for the command; see the local mailer as an example. In the case of the smtp mailer, however, the argument refers to an internal sendmail process. The macro $h is expanded to provide the recipient host ($h) address.
Despite this long discussion, don't worry about mailer definitions. The sample configuration file that comes with your operating system contains the correct mailer definitions to run sendmail in a TCP/IP network environment. You shouldn't need to modify any mailer definitions.