Files Reference

sendmail.cf File

Purpose

Contains the configuration information for the sendmail command.

Description

The /etc/mail/sendmail.cf configuration file contains the configuration information for the sendmail command. Information contained in this file includes such items as the host name and domain, and the sendmail rule sets.

The /etc/mail/sendmail.cf file:

• Stores information about the type of mailer programs running.
• Defines how the sendmail command rewrites addresses in messages.
• Defines how the sendmail command operates in the following environments:
  • Local mail delivery
  • Local area network delivery using TCP/IP
  • Remote delivery using Basic Utilities Network (BNU).

If your environment includes only these types of mail delivery, you can use the supplied /etc/mail/sendmail.cf file with few, if any, changes.

Control Lines

The /etc/mail/sendmail.cf file consists of a series of control lines, each of which begins with a single character defining how the rest of the line is used. Lines beginning with a space or a tab are continuation lines. Blank lines and lines beginning with a # (pound sign) are comments. Control lines are used for defining:

• Macros and classes for use within the configuration file
• Message headings
• Mailers
• Options for the sendmail command

Each of these control line types are discussed in detail below.

Rewrite Rules

The sendmail command receives addresses in a number of different formats because different mailers use different formats to deliver mail messages. The sendmail command changes the addresses to the format needed to route the message for the mailer program being used. To perform this translation, the sendmail command uses a set of rewrite rules, or rule sets, that are defined in the /etc/mail/sendmail.cf configuration file. Rewrite rules have the following format:

Snumber
Rbefore          after

where number is a integer greater than or equal to zero indicating which rule set this is, and before and after are symbolic expressions representing a particular pattern of characters. The line beginning with R means rewrite the expression before so that it has the same format as the expression after. Sendmail scans through the set of rewrite rules looking for a match on the left-hand side (LHS) of the rule. When a rule matches, the address is replaced by the right-hand side (RHS) of the rule.

The /etc/mail/sendmail.cf file installed with the sendmail command contains enough rules to perform the translation for BNU and TCP/IP networks using a domain address structure. You should not have to change these rules unless connecting to a system that uses a different addressing scheme.

Macro expansions of the form $x are performed when the configuration file is read. Expansions of the form $&x are performed at run time, using a somewhat less general algorithm. This form is intended only for referencing internally defined macros such as $h that are changed at runtime.

Left-Hand Side (LHS) of Rewrite Rules

The left-hand side of rewrite rules contains a pattern. Normal words are simply matched directly. Metasyntax is introduced using a dollar sign. The metasymbols are:

If any of these match, they are assigned to the symbol $n for replacement on the right-hand side, where n is the index in the LHS. For example, if the LHS:

$-:$+

is applied to the input:

UCBARPA:linda

the rule will match, and the values passed to the RHS will be:

$1  UCBARPA
$2  linda

Right-Hand Side (RHS) of Rewrite Rules

When the left-hand side of a rewrite rule matches, the input is deleted and replaced by the right-hand side. Tokens are copied directly from the RHS unless they begin with a dollar sign. Metasymbols are:

The $n syntax substitutes the corresponding value from a $+, $-, $*, $=, or $~ match on the LHS. It may be used anywhere.

A host name enclosed between $[ and $] is looked up in the host database(s) and replaced by the canonical name. For example, $[merlin] might become merlin.magician and $[[128.32.130.2]$] would become king.arthur.

The $( ... $) syntax is a more general form of lookup; it uses a named map instead of an implicit map. If no lookup is found, the indicated default is inserted; if no default is specified and no lookup matches, the value is left unchanged. The arguments are passed to the map for possible use.

The $>n syntax causes the remainder of the line to be substituted as usual and then passed as the argument to ruleset n. The final value of ruleset n then becomes the substitution for this rule. The $> syntax can only be used at the beginning of the right hand side; it can be only be preceded by $@ or $:.

The $# syntax should only be used in ruleset zero or a subroutine of ruleset zero. It causes evaluation of the ruleset to terminate immediately, and signals to sendmail that the address has completely resolved. The complete syntax is:

$#mailer $@host $:user

This specifies the {mailer, host, user} 3-tuple necessary to direct the mailer. If the mailer is local, the host part may be omitted. The mailer must be a single word, but the host and user may be multi-part. If the mailer is the built-in IPC mailer, the host may be a colon-separated list of hosts that are searched in order for the first working address, exactly like MX (machine exchange) records. The user is later rewritten by the mailer-specific envelope rewrite set and assigned to the $u macro. As a special case, if the value to $# is "local" and the first character of the $: value is "@", the "@" is stripped off, and a flag is set in the address descriptor that causes sendmail to not do ruleset 5 processing.

Normally, a rule that matches is retried, that is, the rule loops until it fails. An RHS may also be preceded by a $@ or a $: to change this behavior. A $@ prefix causes the ruleset to return with the remainder of the RHS as the value. A $: prefix causes the rule to terminate immediately, but the ruleset to continue; this can be used to avoid continued application of a rule. The prefix is stripped before continuing.

The $@ and $: prefixes may precede a $> spec. For example:

R$+  $: $>7 $1

matches anything, passes that to ruleset seven, and continues; the $: is necessary to avoid an infinite loop.

Substitution occurs in the order described; that is, parameters from the LHS are substituted, host names are canonicalized, "subroutines" are called, and finally $#, $@, and $: are processed.

Semantics of Rewrite Rule Sets

There are five rewrite sets that have specific semantics.

Ruleset three should turn the address into "canonical form." This form should have the basic syntax:

local-part@host-domain-spec

Ruleset three is applied by sendmail before doing anything with any address.

If no "@" sign is specified, then the host-domain-spec may be appended (box "D" in "Rewrite Set Semantics") from the sender address (if the C flag is set in the mailer definition corresponding to the sending mailer).

Ruleset zero is applied after ruleset three to addresses that are going to actually specify recipients. It must resolve to a {mailer, host, user} triple. The mailer must be defined in the mailer definitions from the configuration file. The host is defined into the $h macro for use in the argv expansion of the specified mailer.

IPC Mailers

Some special processing occurs if the ruleset zero resolves to an IPC mailer (that is, a mailer that has "[IPC]" listed as the Path in the M configuration line. The host name passed after "$@" has MX expansion performed; this looks the name up in DNS to find alternate delivery sites.

The host name can also be provided as a dotted quad in square brackets; for example:

[128.32.149.78]

This causes direct conversion of the numeric value to a TCP/IP host address.

The host name passed in after the "$@" may also be a colon-separated list of hosts. Each is separately MX expanded and the results are concatenated to make (essentially) one long MX list. The intent here is to create "fake" MX records that are not published in DNS for private internal networks.

As a final special case, the host name can be passed in as a text string in square brackets:

[any.internet.addr]

This form avoids the MX mapping if the F=0 flag is set for the selected delivery agent.

Macros in the sendmail.cf File

Macros in the /etc/mail/sendmail.cf file are interpreted by the sendmail command. A macro is a symbol that represents a value or string. A macro is defined by a D command in the /etc/mail/sendmail.cf file.

D -- Define Macro

Macros are named with a single character or with a word in {braces}. Single-character names may be selected from the entire ASCII set, but user-defined macros should be selected from the set of uppercase letters only. Lowercase letters and special symbols are used internally. Long names beginning with a lowercase letter or a punctuation character are reserved for use by sendmail, so user-defined long macro names should begin with an uppercase letter.

The syntax for macro definitions is:

Dxval

where x is the name of the macro (which may be a single character or a word in braces) and val is the value it should have. There should be no spaces given that do not actually belong in the macro value.

Macros are interpolated using the construct $x, where x is the name of the macro to be interpolated. This interpolation is done when the configuration file is read, except in M lines. The special construct $&x can be used in R lines to get deferred interpolation.

Conditionals can be specified using the syntax:

$?x text1 $| text2 $.

This interpolates text1 if the macro $x is set, and text2 otherwise. The "else" ($|) clause may be omitted.

Lowercase macro names are reserved to have special semantics, used to pass information in or out of sendmail, and special characters are reserved to provide conditionals, and so on. Uppercase names (that is, $A through $Z) are specifically reserved for configuration file authors.

The following macros are defined and/or used internally by sendmail for interpolation into argv's for mailers or for other contexts. The ones marked - are information passed into sendmail, the ones marked = are information passed both in and out of sendmail, and the unmarked macros are passed out of sendmail but are not otherwise used internally:

There are three types of dates that can be used. The $a and $b macros are in RFC 822 format; $a is the time as extracted from the "Date:" line of the message (if there was one), and $b is the current date and time (used for postmarks). If no "Date:" line is found in the incoming message, $a is set to the current time also. The $d macro is equivalent to the $b macro in UNIX (ctime) format. The $t macro is the current time in seconds.

The macros $w, $j, and $m are set to the identity of this host. Sendmail tries to find the fully qualified name of the host if at all possible; it does this by calling gethostname(2) to get the current hostname and then passing that to gethostbyname(3) which is supposed to return the canonical version of that host name. Assuming this is successful, $j is set to the fully qualified name, and $m is set to the domain part of the name (everything after the first dot). The $w macro is set to the first word (everything before the first dot) if you have a level 5 or higher configuration file; otherwise, it is set to the same value as $j. If the canonicalization is not successful, it is imperative that the config file set $j to the fully qualified domain name.

The $f macro is the ID of the sender as originally determined; when mailing to a specific host, the $g macro is set to the address of the sender relative to the recipient. For example, if a user sends to king@castle.com from the machine vangogh.painter.com, the $f macro will be vincent and the $g macro will be vincent@vangogh.painter.com.

The $x macro is set to the full name of the sender. This can be determined in several ways. It can be passed as flag to sendmail. It can be defined in the NAME environment variable. The third choice is the value of the "Full-Name:" line in the header if it exists, and the fourth choice is the comment field of a "From:" line. If all of these fail, and if the message is being originated locally, the full name is looked up in the /etc/passwd file.

When sending, the $h, $u, and $z macros get set to the host, user, and home directory (if local) of the recipient. The first two are set from the $@ and $: part of the rewrite rules, respectively.

The $p and $t macros are used to create unique strings (for example, for the "Message-Id:" field). The $i macro is set to the queue ID on this host; if put into the timestamp line, it can be useful for tracking messages. The $v macro is set to be the version number of sendmail; this is normally put in timestamps and has been proven useful for debugging.

The $c field is set to the "hop count," that is, the number of times this message has been processed. This can be determined by the -h flag on the command line or by counting the timestamps in the message.

The $r and $s fields are set to the protocol used to communicate with sendmail and the sending hostname. They can be set together using the -p command line flag or separately using the -M or -oM flags.

The $_ is set to a validated sender host name. If the sender is running an RFC 1413 compliant IDENT server and the receiver has the IDENT protocol turned on, it will include the user name on that host.

The $(client_name), $(client_addr), and $(client_port) macros are set to the name, address, and port number of the connecting host who is invoking sendmail as a server. These can be used in the check_* rulesets (using the $& deferred evaluation form).

Changing the Domain Name Macro

The domain name macro, DD, specifies the full domain name of your local group of hosts. The format of the domain name macro is DD followed by, at most, four period-separated names, for example:

DDname1.name2.name3.name4

This macro can be set automatically through the hostname command. The sendmail command reads what has been set with the hostname command and uses it to initialize the host and domain macros and classes. The configuration file macros only need to be changed if you want the sendmail host and domain names to be different from those set by the hostname command.

To change the domain name macro:

1. Enter the command:

   vi /etc/mail/sendmail.cf

2. Find the line beginning with DD.
3. Replace what follows DD with your domain name. For example, if your domain name is newyork.abc.com, enter:

   DDnewyork.abc.com

4. Save the file and exit the editor.

Changing the Host Name Macro

The host name macro, Dw, specifies the name of your host system used in the return address of all messages you generate. The format of the host name macro is Dw followed by the hostname of this machine, for example:

Dwhostname

By default, the sendmail command reads what has been set with the hostname command and uses it to initialize the host and domain name macros and classes. Change the configuration file macros only if you want the sendmail command host and domain names to be different from those set by the hostname command.

To change the host name macro:

1. Enter the command:

   vi /etc/mail/sendmail.cf

2. Find the line beginning with Dw.
3. Replace what follows Dw with your hostname. For example, if your hostname is brown, enter:

   Dwbrown

4. Save the file and exit the editor.
   Note
   If the Dw macro is defined, you must also define the CW (hostname) class.

Modifying the sendmail.cf File

Before you modify the /etc/mail/sendmail.cf file, make a backup copy. Do this by executing the following command:

cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.working

If the changes you make cause the mail system not to work properly, you can return to using a copy of the /etc/mail/sendmail.cf file that you know works.

You can modify the /etc/mail/sendmail.cf file by using your favorite text editor. However, some editors store tabs as the number of spaces they represent, not the tab character itself. This can cause unexpected results if the tab character is defined as the field-separator character in rule sets. Use the vi editor to avoid this problem, or change the field-separator character with the J option. (For ease of reference, this discussion assumes you use the vi editor to modify the /etc/mail/sendmail.cf file.)

After changing any information in the /etc/mail/sendmail.cf file, you must instruct the daemon to reread the file. See section, Making the sendmail Daemon Reread the Configuration Information for those instructions.

Making the sendmail Daemon Reread the Configuration Information

After you have made changes to the sendmail.cf file, instruct the daemon to reread the file. If you started the sendmail command using the startsrc command, enter the command:

refresh -s sendmail

Or, if you started the sendmail daemon using the /usr/sbin/sendmail command, enter the command:

kill -1 `cat /etc/mail/sendmail.pid`

Both of these commands cause the daemon to reread the /etc/mail/sendmail.cf file, the /etc/mail/aliases file, and the /etc/sendmail.nl file.

Alias Database

The alias database exists in two forms. One is a text form, maintained in the file /etc/mail/aliases. The aliases are of the form:

name: name1, name2, ...

Only local names may be aliased. For example:

linda@cloud.ai.acme.org: linda@CS.

has the desired effect. Aliases may be continued by starting any continuation lines with a space or a tab. Blank lines and lines beginning with a pound sign (#) are comments.

The second form is processed by the new database manager (NDBM) or Berkeley DB library. This form is in the file /etc/mail/aliases.db (if using NEWDB) or /etc/mail/aliases.dir and /etc/mail/aliases.pag (if using NDBM). This is the form that sendmail actually uses to resolve aliases. This technique is used to improve performance.

The service switch sets the control of search order. The following entry

AliasFile=switch:aliases

is always added as the first alias entry. The first alias file name without a class (for example, without nis on the front) will be used as the name of the file for a "files" entry in the aliases switch. For example, if the configuration file contains

AliasFile=/etc/mail/aliases

and the service switch contains

aliases nis files nisplus

then aliases will first be searched in the NIS database, then in /etc/mail/aliases, and finally in the NIS+ database.

Rebuilding the Alias Database

The DB or DBM version of the database may be rebuilt explicitly by executing the command:

newaliases

This is equivalent to giving sendmail the -bi flag:

/usr/sbin/sendmail -bi

If the RebuildAliases option is specified in the configuration, sendmail will rebuild the alias database automatically if possible when it is out of date. Auto-rebuild can be dangerous on heavily loaded machines with large alias files. If it might take more than the rebuild time-out (option AliasWait, which is normally five minutes) to rebuild the database, there is a chance that several processes will start the rebuild process simultaneously.

If you have multiple aliases databases specified, the -bi flag rebuilds all the database types. II understands, for example, it can rebuild NDBM databases, but not NIS databases.

Potential Problems with the Alias Database

There are a number of problems that can occur with the alias database. They all result from a sendmail process accessing the DBM version while it is only partially built. This can happen under two circumstances: One process accesses the database while another process is rebuilding it, or the process rebuilding the database dies (due to being killed or a system crash) before completing the rebuild.

Sendmail has three techniques to try to relieve these problems. First, it ignores interrupts while rebuilding the database; this avoids the problem of someone aborting the process leaving a partially rebuilt database. Second, it locks the database source file during the rebuild, but that may not work over NFS or if the file is not writable. Third, at the end of the rebuild, it adds an alias of the form:

@: @

(which is not normally legal). Before sendmail will access the database, it checks to ensure that this entry exists.

List Owners

If an error occurs on sending to a certain address, x, sendmail will look for an alias of the form owner-x to receive the errors. This is typically useful for a mailing list where the submitter of the list has no control over the maintenance of the list itself. In this case, the list maintainer would be the owner of the list. For example:

unix-wizards: linda@paintbox, wnj@monet, nosuchuser,
 sam@matisse
owner-unix-wizards: unix-wizards-request
unix-wizards-request: linda@paintbox

would cause linda@paintbox to get the error that will occur when someone sends to unix-wizards due to the inclusion of nosuchuser on the list.

List owners also cause the envelope sender address to be modified. The contents of the owner alias are used if they point to a single user. Otherwise, the name of the alias itself is used. For this reason, and to conform to Internet conventions, the "owner-" address normally points at the "-request" address; this causes messages to go out with the typical Internet convention of using "list-request" as the return address.

Per-User Forwarding (.forward Files)

As an alternative to the alias database, users may put a file with the name ".forward" in their home directory. If this file exists, sendmail redirects mail for that user to the list of addresses listed in the .forward file. For example, if the home directory for user "kenly" has a .forward file with contents:

kenly@ernie
joel@renoir

then any mail arriving for "kenly" will be redirected to the specified accounts.

The configuration file defines a sequence of file names to check. By default, this is the user's .forward file, but can be defined to be more general using the ForwardPath (J) option. If you change this option, you must inform your user base of the change.

IDENT Protocol Support

UCB sendmail supports the IDENT protocol as defined in RFC 1413. Although this enhances identification of the author of an e-mail message by doing a "callback" to the originating system to include the owner of a particular TCP connection in the audit trail, it is in no sense perfect; a determined forger can easily violate the security of the IDENT protocol.

The following description is excerpted from RFC 1413:

6. Security Considerations

The information returned by this protocol is at most as trustworthy as the host providing it OR the organization operating the host. For example, a PC in an open lab has few if any controls on it to prevent a user from having this protocol return any identifier the user wants. Likewise, if the host has been compromised the information returned may be completely erroneous and misleading.

The Identification Protocol is not intended as an authorization or access control protocol. At best, it provides some additional auditing information with respect to TCP connections. At worst, it can provide misleading, incorrect, or maliciously incorrect information.

The use of the information returned by this protocol for other than auditing is strongly discouraged. Specifically, using Identification Protocol information to make access control decisions, either as the primary method (that is, no other checks) or as an adjunct to other methods may result in a weakening of normal host security.

An Identification server may reveal information about users, entities, objects or processes which might normally be considered private. An Identification server provides service which is a rough analog of the CallerID services provided by some phone companies and many of the same privacy considerations and arguments that apply to the CallerID service apply to Identification. If you would not run a "finger" server due to privacy considerations you may not want to run this protocol.

Tuning

There are a number of configuration parameters you may want to change, depending on the requirements of your site. Most of these are set using an option in sendmail.cf. For example, the line "O Time-out.queuereturn=5d" sets option "Timeout.queuereturn" to the value "5d" (five days).

Most of these options have appropriate defaults for most sites. However, sites having very high mail loads may find they need to tune them as appropriate for their mail load. In particular, sites experiencing a large number of small messages, many of which are delivered to many recipients, may find that they need to adjust the parameters dealing with queue priorities.

All prior versions of sendmail had single-character option names. Although old short names are still accepted, most new options do not have short equivalents.

Timeouts

All time intervals are set using a scaled syntax. For example, "10m" represents ten minutes, whereas "2h30m" represents two and a half hours. The full set of scales is:

s

seconds

m

minutes

h

hours

d

days

w

weeks

Read Timeouts

Timeouts all have option names "Time-out.suboption". The recognized suboptions, their default values, and the minimum values allowed by RFC 1123 section 5.3.2 are:

For compatibility with old configuration files, if no suboption is specified, all the timeouts marked with - are set to the indicated value.

Message Timeouts

After sitting in the queue for a few days, a message will time out. This is to ensure that at least the sender is aware of the inability to send a message. The time-out is typically set to five days. It is sometimes considered convenient to also send a warning message if the message is in the queue longer than a few hours (assuming you normally have good connectivity; if your messages normally took several hours to send, you would not want to do this because it would not be an unusual event). These timeouts are set using the Timeout.queuereturn and Timeout.queuewarn options in the configuration file (previously both were set using the T option).

Because these options are global and you cannot know how long another host outside your domain will be down, a five-day time-out is recommended. This allows a recipient to fix the problem even if it occurs at the beginning of a long weekend. RFC 1123 section 5.3.1.1 says that this parameter should be "at least 4-5 days".

The Timeout.queuewarn value can be piggybacked on the T option by indicating a time after which a warning message should be sent; the two timeouts are separated by a slash. For example, the line:

OT5d/4h

causes e-mail to fail after five days, but a warning message will be sent after four hours. This should be large enough that the message will have been tried several times.

Queue interval

The argument to the -q flag specifies how often a subdaemon will run the queue. This is typically set to between fifteen minutes and one hour. RFC 1123, section 5.3.1.1 recommends this be at least 30 minutes.

Forking During Queue Runs

By setting the ForkEachJob (Y) option, sendmail will fork before each individual message while running the queue. This will prevent sendmail from consuming large amounts of memory, so it may be useful in memory-poor environments. However, if the ForkEachJob option is not set, sendmail will keep track of hosts that are down during a queue run, which can improve performance dramatically.

If the ForkEachJob option is set, sendmail cannot use connection caching.

Queue Priorities

Every message is assigned a priority when it is first instantiated, consisting of the message size (in bytes) offset by the message class (which is determined from the Precedence: header) times the "work class factor" and the number of recipients times the "work recipient factor." The priority is used to order the queue. Higher numbers for the priority mean that the message will be processed later when running the queue.

The message size is included so that large messages are penalized relative to small messages. The message class allows users to send "high priority" messages by including a "Precedence:" field in their message; the value of this field is looked up in the P lines of the configuration file. Because the number of recipients affects the amount of load a message presents to the system, this is also included into the priority.

The recipient and class factors can be set in the configuration file using the RecipientFactor (y) and ClassFactor (z) options respectively. They default to 30000 (for the recipient factor) and 1800 (for the class factor). The initial priority is:

pri = msgsize - (class times bold ClassFactor) + (nrcpt times bold 
RecipientFactor)

(Remember that higher values for this parameter actually mean that the job will be treated with lower priority.)

The priority of a job can also be adjusted each time it is processed (that is, each time an attempt is made to deliver it) using the "work time factor," set by the RetryFactor(Z) option. This is added to the priority, so it normally decreases the precedence of the job, on the grounds that jobs that have failed many times will tend to fail again in the future. The RetryFactor option defaults to 90000.

Load Limiting

Sendmail can be asked to queue (but not deliver) mail if the system load average gets too high using the QueueLA (x) option. When the load average exceeds the value of the QueueLA option, the delivery mode is set to q (queue only) if the QueueFactor (q) option divided by the difference in the current load average and the QueueLA option plus one exceeds the priority of the message; that is, the message is queued if:

pri > { bold QueueFactor } over { LA - { bold QueueLA } + 1 }

The QueueFactor option defaults to 600000, so each point of load average is worth 600000 priority points (as described above).

For drastic cases, the RefuseLA (X) option defines a load average at which sendmail will refuse to accept network connections. Locally generated mail (including incoming UUCP mail) is still accepted.

Delivery Mode

There are a number of delivery modes that sendmail can operate in, set by the DeliveryMode (d) configuration option. These modes specify how quickly mail will be delivered. Legal modes are:

There are trade-offs. Mode i gives the sender the quickest feedback, but may slow down some mailers and is hardly ever necessary. Mode b delivers promptly, but can cause large numbers of processes if you have a mailer that takes a long time to deliver a message. Mode q minimizes the load on your machine, but means that delivery may be delayed for up to the queue interval. Mode d is identical to mode q except that it also prevents all the early map lookups from working; it is intended for "dial on demand" sites where DNS lookups might be very expensive. Some simple error messages (for example, host unknown during the SMTP protocol) will be delayed using this mode. Mode b is the default.

If you run in mode q (queue only), d (defer), or b (deliver in background), sendmail will not expand aliases and follow .forward files upon initial receipt of the mail. This speeds up the response to RCPT commands. Mode i cannot be used by the SMTP server.

Log Level

The level of logging can be set for sendmail. The default using a standard configuration table is level 9. The levels are as follows:

File Modes

The modes used for files depend on what functionality you want and the level of security you require.

The database that sendmail actually uses is represented by the following file:

/etc/mail/aliases.db

Berkeley DB database

The mode on these files should match the mode of /etc/mail/aliases. If aliases is writable and the files are not, users will be unable to reflect their desired changes through to the actual database. However, if aliases is read-only and DBM files are writable, a slightly sophisticated user can arrange to steal mail anyway.

If your DBM files are not writable, or you do not have auto-rebuild enabled (with the AutoRebuildAliases option), then you must be careful to reconstruct the alias database each time you change the text version:

newaliases

If this step is ignored or forgotten, any intended changes will be lost.

Connection Caching

When processing the queue, sendmail will try to keep the last few open connections open to avoid startup and shutdown costs. This only applies to IPC connections.

When trying to open a connection, the cache is first searched. If an open connection is found, it is probed to see if it is still active by sending a RSET command. It is not an error if this fails; instead, the connection is closed and reopened.

Two parameters control the connection cache. The ConnectionCacheSize (k) option defines the number of simultaneous open connections that will be permitted. If it is set to zero, connections will be closed as quickly as possible. The default is one. This should be set as appropriate for your system size; it will limit the amount of system resources that sendmail will use during queue runs. Never set this higher than 4.

The ConnectionCacheTimeout (K) option specifies the maximum time that any cached connection will be permitted to idle. When the idle time exceeds this value, the connection is closed. This number should be small (under ten minutes) to prevent you from grabbing too many resources from other hosts. The default is five minutes.

Name Server Access

If you want machine exchange (MX) support, you must be using Domain Name Services (DNS).

The ResolverOptions(I) option allows you to tweak name server options. The command line takes a series of flags as documented inresolver(3) (with the leading "RES_" deleted). Each can be preceded by an optional `+' or `-'. For example, the line:

O ResolverOptions=+AAONLY -DNSRCH

turns on the AAONLY (Accept Authoritative Answers only) and turns off the DNSRCH (search the domain path) options. Most resolver libraries default DNSRCH, DEFNAMES, and RECURSE flags on and all others off. You can also include "HasWildcardMX" to specify that there is a wildcard MX record matching your domain; this turns off MX matching when canonicalizing names, which can lead to inappropriate canonicalizations.

Moving the Per-User Forward Files

Some sites mount each user's home directory from a local disk on their workstation, so that local access is fast. However, the result is that .forward file lookups are slow. In some cases, mail can even be delivered on machines inappropriately because of a file server being down. The performance can be especially bad if you run the automounter.

The ForwardPath (J) option allows you to set a path of forward files. For example, the config file line:

O ForwardPath=/var/forward/$u:$z/.forward.$w

would first look for a file with the same name as the user's login in /var/forward. If that is not found (or is inaccessible), the file ".forward.machinename" in the user's home directory is searched.

If you create a directory such as /var/forward, it should be mode 1777 (that is, the sticky bit should be set). Users should create the files mode 644.

Free Space

On systems that have one of the system calls in the statfs(2) family (including statvfs and ustat), you can specify a minimum number of free blocks on the queue file system using the MinFreeBlocks (b) option. If there are fewer than the indicated number of blocks free on the filesystem on which the queue is mounted, the SMTP server will reject mail with the 452 error code. This invites the SMTP client to try again later.

Maximum Message Size

To avoid overflowing your system with a large message, the MaxMessageSize option can set an absolute limit on the size of any one message. This will be advertised in the ESMTP dialogue and checked during message collection.

Privacy Flags

The PrivacyOptions (p) option allows you to set certain "privacy" flags. Actually, many of them do not give you any extra privacy, rather just insisting that client SMTP servers use the HELO command before using certain commands or adding extra headers to indicate possible security violations.

The option takes a series of flag names; the final privacy is the inclusive or of those flags. For example:

O PrivacyOptions=needmailhelo, noexpn

insists that the HELO or EHLO command be used before a MAIL command is accepted and disables the EXPN command.

The flags are detailed in RFC 1123 S 5.1.6.

Send to Me Too

Normally, sendmail deletes the (envelope) sender from any list expansions. For example, if "linda" sends to a list that contains "linda" as one of the members, she will not get a copy of the message. If the -m (me too) command line flag, or if the MeToo (m) option is set in the configuration file, this behavior is suppressed.

C and F -- Define Classes

Classes of phrases may be defined to match on the left hand side of rewrite rules, where a "phrase" is a sequence of characters that do not contain space characters. For example, a class of all local names for this site might be created so that attempts to send to oneself can be eliminated. These can either be defined directly in the configuration file or read in from another file. Classes are named as a single letter or a word in {braces}. Class names beginning with lowercase letters and special characters are reserved for system use. Classes defined in config files may be given names from the set of uppercase letters for short names or beginning with an uppercase letter for long names.

Ccphrase1 phrase2...
Fcfile

The first form defines the class c to match any of the named words. It is permissible to split them among multiple lines; for example, the two forms:

CHmonet ucbmonet

and

CHmonet
CHucbmonet

are equivalent. The "F" form reads the elements of the class c from the named file.

Elements of classes can be accessed in rules using $= or $~. The $~ (match entries not in class) only matches a single word; multi-word entries in the class are ignored in this context.

The class $=w is set to be the set of all names this host is known by. This can be used to match local host names.

The class $=k is set to be the same as $k, that is, the UUCP node name.

The class $=m is set to the set of domains by which this host is known, initially just $m.

The class $=t is set to the set of trusted users by the T configuration line. If you want to read trusted users from a file, use Ft/file/name.

The class $=n can be set to the set of MIME body types that can never be eight to seven bit encoded. It defaults to "multipart/signed". Message types "message/*" and "multipart/*" are never encoded directly. Multipart messages are always handled recursively. The handling of message/* messages are controlled by class $=s. The class $=e contains the Content-Transfer-Encodings that can be 8->7 bit encoded. It is predefined to contain "7bit", "8bit", and "binary". The class $=s contains the set of subtypes of message that can be treated recursively. By default it contains only "rfc822". Other "message/*" types cannot be 8->7 bit encoded. If a message containing eight-bit data is sent to a seven-bit host, and that message cannot be encoded into seven bits, it will be stripped to 7 bits.

The three classes $=U, $=Y, and $=Z are defined to describe the hosts requiring the use of a uucp mailer. Specifically, $=U should contain all hosts requiring the uucp-old mailer. $=Y should contain all hosts requiring the uucp-new mailer. Finally, $=Z should contain all hosts requiring the uucp-uudom mailer. Each uucp host should belong to one of these classes.

Sendmail can be compiled to allow a scanf(3) string on the F line. This lets you do simplistic parsing of text files. For example, to read all the user names in your system /etc/passwd file into a class, use:

FL/etc/passwd %[^:]

which reads every line up to the first colon.

Changing the Host Name

Cw contains all the possible names for the local host. It defines aliases. Cw specifies the name and all aliases for your host system. If your system uses different names for two different network connections, enter both names as part of the host name class. If you do not define both names, mail sent to the undefined name is returned to the sender.

CwCw alias aliasn... 

By default, the sendmail command reads what has been set with the hostname command and uses it to initialize the host and domain name macros and classes. Change the configuration file macros only if you want the sendmail host and domain names to be different from those set by the hostname command.

To change the host name:

1. Enter the command:

   vi /etc/mail/sendmail.cf

2. Find the lines beginning with Dj and Dw. Dj and Dw override the host and domain names set with "hostname".
3. Replace Dj and Dw with the new hostname information. For example, if your hostname is brown.newyork.abc.com, and you have one alias, brown2, enter:
4. Save the file and exit the editor.

Creating a Class Using a File

To define a class whose members are listed in an external file (one member per line), use a control line that begins with the letter F. The syntax for the F class definition is:

FClass FileName [Format]

Class is the name of the class that matches any of the words listed in FileName. Filename is the full path name of file (for convenience, you may wish to put the file in the /etc/mail directory). Format is an optional scanf subroutine format specifier that indicates the format of the elements of the class in FileName. The Format specifier can contain only one conversion specification.

M -- Define Mailer

Programs and interfaces to mailers are defined in this line. The format is:

Mname, {field=value}*

where name is the name of the mailer (used internally only) and the "field=name" pairs define attributes of the mailer. Fields are:

Only the first character of the field name is checked.

The flags in the following list may be set in the mailer description. Any other flags may be used freely to conditionally assign headers to messages destined for particular mailers. Flags marked with - are not interpreted by the sendmail binary; these are conventionally used to correlate to the flags portion of the H line. Flags marked with = apply to the mailers for the sender address rather than the usual recipient mailers.

From: usera@hosta
To: userb@hostb, userc

From: usera@hosta
To: userb@hostb, userc@hosta

The mailer with the special name "error" can be used to generate a user error. The (optional) host field is an exit status to be returned, and the user field is a message to be printed. The exit status may be numeric or one of the values USAGE, NOUSER, NOHOST, UNAVAILABLE, SOFTWARE, TEMPFAIL, PROTOCOL, or CONFIG to return the corresponding EX_ exit code. For example, the entry:

$#error $@ NOHOST $: Host unknown in this domain

on the RHS of a rule will cause the specified error to be generated and the "Host unknown" exit status to be returned if the LHS matches. It is always available for use in O, S, and check_ ... rulesets and it cannot be defined with M commands.

The mailer named "local" must be defined in every configuration file. This is used to deliver local mail, and is treated specially in several ways. Additionally, three other mailers named "prog", "*file*", and "*include*" may be defined to tune the delivery of messages to programs, files, and :include: lists respectively. They default to:

Mprog, P=/bin/sh, F=lsoDq9, T=DNS/RFC822/X-Unix, A=sh -c $u
M*file*, P=[FILE], F=lsDFMPEuq9, T=DNS/RFC822/X-Unix, A=FILE $u
M*include*, P=/dev/null, F=su, A=INCLUDE $u

The Sender and Recipient rewrite sets may either be a simple ruleset ID or may be two IDs separated by a slash If so, the first rewrite set is applied to envelope addresses, and the second is applied to headers. Setting any value to zero disables the corresponding mailer-specific rewriting.

The Directory field is a path of directories to try. For example, the definition D=$z:/ tries to execute the recipient's home directory, but if that is not available, it tries to execute in the root of the filesystem. Use this on the prog mailer only, because some shells (e.g., csh) do not execute if they cannot read the home directory. Because the queue directory usually cannot be read by unauthorized users, csh scripts can fail if they are used as recipients.

The Userid field specifies the default user and group ID to run. It overrides the DefaultUser option q.v. If the S mailer flag is also specified, the user and group ID will run in all circumstances. Use the form user:group to set both the user and group ID. Either of these variables may be an integer or a symbolic name that is looked up in the passwd and group files respectively.

The Charset field is used when converting a message to MIME. It is the character set used in the Content-Type: header. If it is not set, the DefaultCharset option is used. If the DefaultCharset is not set, the value unknown-8bit is used. The Charset field applies to the sender's mailer; not the recipient's mailer. For example: if the envelope sender address is on the local network and the recipient is on an external network, the character set is set from the Charset= field for the local network mailer, not the external network mailer.

The Type field sets the type of information used in MIME error messages (as defined by RFC 1984). It contains three values that are separated by slashes: the MTA type (a description of how hosts are named), address type (a description of e-mail addresses), and diagnostic type (a description of error diagnostic codes). Each must be a registered value or begin with X-. The default is dns/rfc822/smtp.

Mailer Specifications Examples

1. To specify a local delivery mailer enter:

   Mlocal, P=/usr/bin/bellmail, F=lsDFMmn, S=10, R=20, A=mail $u

   The mailer is called local. Its path name is /usr/bin/bellmail. The mailer uses the following flags:

   l	Specifies local delivery.
   s	Strips quotation marks from addresses.
   DFM	Requires Date:, From:, and Message-ID: fields.
   m	Delivers to multiple users.
   n	Does not need an operating system From line at the start of the message.

   Rule set 10 should be applied to sender addresses in the message. Rule set 20 should be applied to recipient addresses. Additional information sent to the mailer in the A field is the word mail and words containing the recipient's name.

H -- Define Header

The format of the header lines that sendmail inserts into the message are defined by the H line. The syntax of this line is one of the following:

Hhname:htemplate

H[?mflags?]hname: htemplate

H[?${macro}?hname:htemplate

Continuation lines in this spec are reflected directly into the outgoing message. The htemplate is macro expanded before insertion into the message. If the mflags (surrounded by question marks) are specified, at least one of the specified flags must be stated in the mailer definition for this header to be automatically output. If one of these headers is in the input, it is reflected to the output regardless of these flags.

Some headers have special semantics that will be described later.

A secondary syntax allows validation of headers as they being read. To enable validation, use:

HHeader: $>Ruleset
HHeader: $>+Ruleset

The indicated Ruleset is called for the specified Header. Like other check_* rulesets, it can return $#error to reject the message or $#discard to discard the message. The header is treated as a structured field, so comments (in parentheses) are deleted before processing, unless the second form $>+ is used.

For example, the following configuration lines:

HMessage-Id: $>CheckMessageId

SCheckMessageId
R<$+@$+> $@OK
R$*      $#error $: Illegal Message-Id header

would refuse any message header that had a Message-Id: header of any of the following forms:

Message-Id: <>
Message-Id: some text
Message-Id: <legal test@domain> extra text

Message Headings in the sendmail.cf File

Lines in the configuration file that begin with a capital letter H, define the format of the headers used in messages. The format of the H command is:

Lines in the configuration file that begin with a capital letter H, define the format of the headers used in messages. The format of the H control line is:

H[?MailerFlags?]FieldName: Content

The variable parameters are defined as:

These example lines are from a typical /etc/mail/sendmail.cf file:

HReceived: $?sfrom $s 
   $.by $j ($v/$Z) 
   id $i; $b

O -- Set Option

There are several global options that can be set from a configuration file. The syntax of this line is:

O option=value

This sets option equal to value. The options supported are listed in the following table.

 host:user

groupname: member1, member2, ... memberN;

nodename::user

<@relay:user@host>