The AuthOptions option (24.9.6[3ed]) provides a list of general tuning parameters that affect authentication. It is declared like this:

O AuthOptions=string                      
               
               
                configuration file (V8.10 and later) 
-OAuthOptions=string                      
               
               
                command-line file (V8.10 and later) 
define(`confAUTH_OPTIONS´, `string
               ´)       
               
                 mc configuration (V8.10 and later) 

The argument, of type string, is a list of characters selected from those shown in Table 24-1, where each character sets a particular tuning parameter. If more than one character is listed, each must be separated from the next by either a comma or a space. As of V8.13, a new m parameter has been added.

Some sites have developed delivery agents that receive messages using SMTP over the standard input/output. They have done so by making use of the P=[LPC] equate (20.5.11^[3ed]).

Beginning with V8.13, sendmail enables connection caching (24.7.5^[3ed]) for such delivery agents, thereby increasing delivery performance. If your site has a delivery agent that uses the P=[LPC] equate, note that the ConnectionCacheSize option (24.9.19^[3ed]) and the ConnectionCacheTimeout option (24.9.20^[3ed]) will now affect the performance of that delivery agent.

When a single email message is sent to many recipients (those on a mailing list, for example), a single sendmail process handles all the recipients—but should that sendmail process die or be killed halfway through processing, for example, there will be no record that the first half of the mailing list was delivered. As a result, when the queue is later reprocessed, the recipients in that first half will receive the message a second time.

The FastSplit option (24.9.46^[3ed]) and this CheckpointInterval option (24.9.13^[3ed]) can limit that duplication. The CheckpointInterval option tells sendmail to rewrite (checkpoint) its qf file (which contains the list of recipients; see 11.2.5^[3ed]) after each group of a specified number of recipients has been delivered. Recipients who have already received mail are deleted from the list, and that list is rewritten to the qf file.

Prior to V8.13, the CheckpointInterval option could have its value raised by anyone using the command line. But beginning with V8.13, only the trusted user, as defined by the TrustedUser option (24.9.112^[3ed]), may raise this value on the command line.

The sendmail program can run in two connection modes: as a daemon, accepting connections; or as a client, making connections. Each mode can connect to a port to do its work. The tuning for the client port is set by the ClientPortOptions option (24.9.17^[3ed]). The tuning for the daemon is set by the DaemonPortOptions option (24.9.24^[3ed]). The format for declaring the DaemonPortOptions option in the mc configuration file looks like this:

DAEMON_OPTIONS(``pair,pair,pair
               ´Â´)

The list of pair items must be enclosed in double half-quote pairs because the list contains commas. Each pair is an equate of the form:

item=value

The new InputMailFilters= equate is used to list the Milters that should be called, and the order in which they must be called. This list overrides the setting of the InputMailFilters option (24.9.54^[3ed]) and, indeed, may contain Milters not declared in that option. This InputMailFilters= equate lists one or more Milters each separated from the next by a colon (not a comma):

DAEMON_OPTIONS(``N=inMTA, I=milterA:milterB´Â´)

Note, as with all DaemonPortOptions option items, only the first character of each is needed. That is, both of the following produce the same effect:

               I
               =
               milterA:milterB
               InputMailFilters=
               milterA:milterB

This item can be useful when you have multiple network interfaces. One interface, for example, might be connected only to the internal network where a Milter records all outbound email. Another might be connected to the external network where a Milter can screen for viruses and spam email.

Beginning with V8.10 sendmail, you can modify selected characteristics of the port. Modification is done by listing selected letters from Table 24-2 following the Modify=. Note that the letters are case-sensitive (X is different from x). As of V8.13, a new s modifier has been added which tells sendmail to speak SMTP over SSL.

One problem with scripts that start and stop sendmail is that they are difficult to write in a manner that allows them to be rerun benignly a second time after sendmail stops. For example, the following script abstract will stop sendmail once:

SERVER_PID_FILE="/var/run/sendmail.pid"
[ -f $SERVER_PID_FILE ] && kill `head -1 $SERVER_PID_FILE`

But if this script is run a second time after sendmail stops, an error such as the following will be reported:

4591: No such process

To prevent this sort of error, V8.13 sendmail removes its PID file when it exits. Once the file is gone, the above script fragment can be run a second time without producing an error.

However, be aware that existing scripts of your design, or those included with your operating system, may break under this new scheme. Consider, for example, the following script whose purpose is to restart sendmail:

SERVER_PID_FILE="/var/run/sendmail.pid"
kill `head -1 $SERVER_PID_FILE`
`tail -1 $SERVER_PID_FILE`

Recall (24.9.78^[3ed]) that the first line of sendmail’s PID file contains the process-ID of the currently running sendmail, and that the second and last line of the PID file contains the command line originally used to run sendmail. Here, the head -1 captures the process-ID needed to kill sendmail, and the tail -1 captures the command line needed to re-execute sendmail. This has worked fine until now, but, beginning with V8.13 sendmail, the second script command (the tail -1) will fail because sendmail has removed the PID file.

One correct way to rewrite such a script might look like this:

SERVER_PID_FILE="/var/run/sendmail.pid"
PID_NUM=`head -1 $SERVER_PID_FILE`
CMD_LINE=`tail -1 $SERVER_PID_FILE`
kill $PID_NUM
$CMD_LINE

The idea here is to capture and save the head -1 and tail -1 information from the PID file before killing sendmail, thereby avoiding the error of trying to read the file after it is removed. Naturally, such a simple script should not be used in production. With full error detection, a much more careful script might look like the following:

SERVER_PID_FILE="/var/run/sendmail.pid"
if [ -f /etc/mail/sendmail.cf ]; then
        SERVER_PID_FILE=`grep "^O PidFile" /etc/mail/sendmail.cf | 
                sed -e ´s/O PidFile=//´`
        if [ $? != 0 -o "$SERVER_PID_FILE" = "" ]; then
                SERVER_PID_FILE="/var/run/sendmail.pid"
        fi
fi

if [ -f $SERVER_PID_FILE ]; then
        PID_NUM=`head -1 $SERVER_PID_FILE`
        if [ $? != 0 -o "$PID_NUM" = "" ]; then 
                echo "Could not read PID in $SERVER_PID_FILE"
                exit 1
        fi
        CMD_LINE=`tail -1 $SERVER_PID_FILE`
        if [ $? != 0 -o "$CMD_LINE" = "" ]; then 
                echo "Could not read command in $SERVER_PID_FILE"
                exit 1
        fi
        if [ "$PID_NUM" = "$CMD_LINE" ]; then 
                # Only one line in the file
                echo "$SERVER_PID_FILE is malformed"
                exit 1
        fi
        kill $PID_NUM
        $CMD_LINE
fi

Prior to V8.7 sendmail, mail messages in the queue were sorted by priority when the queue was processed. Under V8.7, an enhanced sort can be implemented with the QueueSortOrder option, the forms of which are as follows:

O QueueSortOrder=how                       
               
               
                configuration file (V8.7 and later) 
-OQueueSortOrder=how                       
               
               
                command line (V8.7 and later) 
define(`confQUEUE_SORT_ORDER´, `how
               ´)       
               
                mc configuration (V8.7 and later) 

The argument how is of type character.^[36] It can be a P or p (for priority), which causes sendmail to emulate its old (sort by priority) behavior. It can be an H or h (for host), which causes sendmail to perform an enhanced sort. Beginning with V8.8 sendmail, it can be T or t (for time), which sorts by submission time; beginning with V8.10 sendmail, it can be F or f (for file), which sorts by filename; beginning with V8.12 sendmail, it can be R or r (for random), which randomizes the list of hosts, or M or m, which sorts based on file modification time; and beginning with V8.13 sendmail, it can be N or n (for none), which skips the sort altogether.

Prior to V8.13, the authentication realm passed to the Cyrus SASL library was always the value of the $j macro. Beginning with V8.13, the new AuthRealm option allows you to specify a different authentication realm:

O AuthRealm=realm                          
               
               
                configuration file (V8.13 and later)
-OAuthRealm=realm                          
               
               
                command-line (V8.13 and later)
define(`confAUTH_REALM´,`realm´)           
               
                mc configuration (V8.13 and later)

Here, realm is of type string and specifies the authentication realm to use in place of the $j macro’s value. If realm is missing, the effect is the same as if the entire option was omitted—that is, the value of $j is used.

The AuthRealm option is not safe. If specified from the command line, it can cause sendmail to relinquish its special privileges.

Beginning with V8.13, sendmail now supports use of the certificate revocation lists available with OpenSSL^[37] Version 0.9.7 and above. The new CRLFile option allows you to declare the location and name of a certificate revocation list file.

When sendmail receives an inbound connection, and when the connecting host requests a secure session by giving the STARTTLS command, the local sendmail (by way of the OpenSSL library) uses the information in CRLFile to determine whether the connecting host’s certificate should be accepted or rejected.

The file specified by the CRLFile option is created using the openssl(1) command. After the file has been created, you need to declare its location like this:

O CRLFile=/path/file                     
               
               
                configuration file (V8.13 and later)
-OCRLFile=/path/file                     
               
               
                command-line (V8.13 and later)
define(`confCRL´,`/path/file´)           
               
                mc configuration (V8.13 and later)

Here, /path/file is of type string and specifies the full-path location of the certificate revocation list file. If the file is declared with this CRLFile option, but does not exist, is unreadable, or has bad permissions, all STARTTLS commands are disallowed by sendmail. The /path/file may contain sendmail macros, and those macros will be expanded as the configuration file is read. By default, the CRLFile option is not declared.

If your version of OpenSSL is too old, the following warning will print when you try to declare the CRLFile option, and that option will be ignored:

Warning: Option: CRLFile requires at least OpenSSL 0.9.7

The file referenced by the CRLFile option is created using the openssl(1) command. For example, if you are using your own CA, the following can be used to create a file named /etc/ssl/crl.pem:^[38]

openssl ca -revoke certificate-file
                   
                
               first revoke the certificate 
openssl ca -gencrl -out crl.pem       
               
                 then create the revocation list

If you need DER format in your revocation list file, you can use the following command after the second line above:

openssl crl -in crl.pem -outform der -out crl.der

Note that these examples are an over-simplification for illustrative purposes only. See the OpenSSL documentation for more details.

The CRLFile option is not safe. If specified from the command line, it can cause sendmail to relinquish its special privileges.

At sites with poor (connect-on-demand) or unreliable network connections, SMTP connections can often fail. In such situations, it might not be desirable for each workstation to queue the mail locally for a later attempt. Prior to V8.13 sendmail, the FallbackMXhost option (24.9.45^[3ed]) was used to provide a final, alternative method for getting a message out the door by specifying the name of a mail exchanger machine (MX record) of last resort.

The trouble with this strategy is that the FallbackMXhost option works only if the recipient’s hostname can be looked up in the first place. If the hostname cannot be found, not even the FallbackMXhost is tried.

For most well-managed sites, this is not a problem. Machines can still look up hosts on the Internet, even if they are on an internal business LAN or behind a firewall. But not all sites are well managed, and some sites disallow external lookups as a matter of policy. For such sites, the FallbackMXhost option will not do.

Beginning with V8.13, the FallbackSmartHost option has been added to solve this particular problem. Even if the recipient’s host cannot be found, the fallback host specified with this new option will still be tried.

The FallbackSmartHost option is declared like this:

O FallbackSmartHost=host.domain                    
               
               
                config file (V8.13 and later)
-OFallbackSmartHost=host.domain                    
               
               
                command-line (V8.13 and later)
define(`confFALLBACK_SMARTHOST´, `host.domain´)    
               
                mc config (V8.13 and later)

Here, host.domain is the canonical name to which the host will fallback. If this option is entirely omitted (the default), no fallback smart-host is defined. If the hostname is an empty string or is the name of a nonexistent host, mail forwarded to that host fails. The host.domain may contain sendmail macros; if so, those macros will be expanded just before the attempt is made to connect to the host.

Note that the hostname specified for this FallbackSmartHost option must not exist in the class $=w (22.6.16^[3ed]). If it does, it will be silently ignored.

Another use for this new FallbackSmartHost option presents itself at sites that have unreliable FallbackMXhost servers. When that FallbackMXhost goes down, this FallBackSmartHost is tried, thus allowing outbound mail to still flow.

The FallbackSmartHost option is not safe. If specified from the command line, it can cause sendmail to relinquish its special privileges.

Prior to V8.13, whenever the load level on a machine became greater than the setting for the RefuseLA option (24.9.90^[3ed]), further inbound connections would be refused, and the following warning message would be logged:

rejecting connections on daemon name: load average=load

Beginning with V8.13 sendmail, you may specify how often additional warnings should be logged. Note that the same message is logged when refusing begins—but if connections continue to be refused, you will be notified with a different message, to aid you in taking corrective actions.

The RejectLogInterval option tells sendmail how often (at what intervals) it should log a message saying that connections are still being refused. The RejectLogInterval option is declared like this:

O RejectLogInterval=interval                 
                
               
                configuration file (V8.13 and later)
-ORejectLogInterval=interval                  
               
               
                command-line (V8.13 and later)
define(`confREJECT_LOG_INTERVAL´, `interval´) 
               
                mc configuration (V8.13 and later)

Here, interval is of type time. The default (if this option is omitted) is three hours. The default units are hours. For example, both of following set the periodic logging interval to one hour:

define(`confREJECT_LOG_INTERVAL´, `60m´)
define(`confREJECT_LOG_INTERVAL´, `1´)

When connections are first refused because the load level is too high, the following warning is logged, as before:

rejecting connections on daemon name: 
               load average=load

Thereafter, for as long as the load continues to be too high, the following warning message is logged once per RejectLogInterval interval:

have been rejecting connections on daemon name for duration

Here, name is the name of the listening daemon (e.g., MTA-v4), and duration is the total amount of time that has elapsed since connections were first refused.

The RejectLogInterval option is not safe. If specified from the command line, it can cause sendmail to relinquish its special privileges.

Some versions of Unix (or implementations of disk I/O) do not support immediate updates of directories when their data changes. For these versions, the REQUIRES_DIR_FSYNC compile-time macro (3.4.47^[3ed]) must set to true, causing sendmail to fsync(2) the directory every time it is updated.

If your operating system is one of these, and if you need to avoid the overhead of this forced directory updating,^[39] you may do so by defining the RequiresDirfsync option. It is declared like this:

O RequiresDirfsync=bool                          
               
               
                configuration file (V8.13 and later)
-O RequiresDirfsync=bool                         
               
               
                command-line (V8.13 and later)
define(`confREQUIRES_DIR_FSYNC´,  `bool´)        
               
                mc configuration (V8.13 and later)

Here, bool is of type boolean. If this option is omitted, the default is true (that is directory fsync(2) is required if REQUIRES_DIR_FSYNC was defined at compile time). If this option is defined as false, however, directory fsync(2) is disabled even if REQUIRES_DIR_FSYNC was defined at compile time.

The RequiresDirfsync option is not safe. If specified from the command line, it can cause sendmail to relinquish its special privileges.

Under V8.13, two new sendmail macros, called ${client_rate} (Section 21.1.4 ^[V8.13]) and ${total_rate} (Section 21.1.9 ^[V8.13]), are available to control the number of simultaneous connections allowed. They are used by the new conncontrol (Section 4.1.8 ^[V8.13]) and ratecontrol (Section 4.1.7 ^[V8.13]) features, which perform the same service via the access database. This new ConnectionRateWindowSize option sets the size of the window of time that is used to measure these rates. It is declare like this:

O ConnectionRateWindowSize=secs
                                   
               
                configuration file (V8.13 and later)
-O ConnectionRateWindowSize=secs
                                  
               
                command line (V8.13 and later)
define(`confCONNECTION_RATE_WINDOW_SIZE´, `secs´)  
               
                mc configuration (V8.13 and later)

Here, secs is of type time. If this option is omitted, the default for the window of time is 60 seconds. If this option is defined, but the time units are omitted, the default units are seconds.

We recommend you only change the default if you have not already made connection limiting entries in your access database. If you make those entries first, then later change this setting, you will inadvertently change the meaning of those access database entries.

The ConnectionRateWindowSize option is not safe. If specified from the command line, it can cause sendmail to relinquish its special privileges.

The sendmail program is flexible in its handling of delivery errors. By selecting from five possible modes with the ErrorMode option, you can tailor notification of delivery errors to suit many needs.

The possible settings are listed in Table 24-3. As of V8.13, the w (for write) setting has been deprecated and removed. If you have used this mode in the past and still need to use it, you may still do so under V8.13 by building sendmail with -DUSE_TTYPATH=1 defined in your Build configuration file.

This queuereturn keyword (24.9.109.18[3ed]) to the Timeout option is used to set the amount of time a message must wait in the queue before it is bounced as nondeliverable. It comes in three basic forms:

O Timeout.queuereturn=timeout
                                            
               
                configuration file (V8.7 and later) 
-OTimeout.queuereturn=timeout
                                            
               
                command line (V8.7 and later) 
define(`confTO_QUEUERETURN´, `timeout
               ´)                  
               
                mc configuration (V8.7 and later) 

Going further, the Queuereturn keyword can tune on the basis of three possible levels of priority that a mail message can have. The above forms set all three levels at once, whereas the following forms tune each level independently:

O Timeout.queuereturn.urgent=timeout
                                     
               
                configuration file (V8.7 and later) 
O Timeout.queuereturn.normal=timeout
                                     
               
                configuration file (V8.7 and later) 
O Timeout.queuereturn.non-urgent=timeout
                                   
               
                configuration file (V8.7 and later) 
-OTimeout.queuereturn.urgent=timeout
                                     
               
                command line (V8.7 and later) 
-OTimeout.queuereturn.normal=timeout
                                     
               
                command line (V8.7 and later) 
-OTimeout.queuereturn.non-urgent=timeout
                                   
               
                command line (V8.7 and later) 
define(`confTO_QUEUERETURN_URGENT´,`timeout´)            
               
                mc config (V8.7 and later) 
define(`confTO_QUEUERETURN_NORMAL´,`timeout´)            
               
                mc config (V8.7 and later) 
define(`confTO_QUEUERETURN_NONURGENT´,`timeout´)            
               
                mc config (V8.7 and later) 

The default for the mc configuration technique is to bounce all messages that remain in the queue for more than five days.

The keywords urgent, normal, and non-urgent correspond to the levels of priority indicated in the Precedence: header of the mail message. When the numeric equivalent of the Precedence: header (as translated from the P line of the configuration file; see 25.10^[3ed]) is negative, the message is classified as non-urgent. When it is greater than zero, the message is classified as urgent. Otherwise, it is normal.

As of V8.7, a Priority: header is also available (see 25.12.28^[3ed]) to directly specify the message priority and thereby bypass the need to set the value using the Precedence: header.

Beginning with V8.10, in addition to an interval specification, you can use the literal term now to force an immediate bounce.

Beginning with V8.13, a new keyword, dsn, has been added to the priorities of urgent, normal, and non-urgent. If the precedence of the message is normal (zero), and if the message is a return DSN message, the timeout defined by this new keyword is used:

O Timeout.queuereturn.dsn=timeout
                                    
               
                configuration file (V8.13 and later)
-OTimeout.queuereturn.dsn=timeout
                                    
               
                command line (V8.13 and later)
define(`confTO_QUEUERETURN_DSN´,`timeout
               ´)           
               
                mc config (V8.13 and later)

One handy use for this new keyword is to return DSN messages sooner than normal mail. But note that when you return a bounce message, you create a double-bounce that is sent to the address specified by the DoubleBounceAddress option (24.9.41^[3ed]).

When an email message is queued for longer than a predetermined time, sendmail sends a message to the sender explaining that, although the original message could not be delivered right away, sendmail will keep trying. The amount of time to wait before sending this message is set by the Timeout.Queuewarn option (24.9.109.19^[3ed]).

Beginning with V8.13, it is possible to set a separate wait for DSN messages. This wait is set with the dsn keyword:

O Timeout.queuewarn.dsn=wait
                                    
               
                configuration file (V8.13 and later)
-OTimeout.queuewarn.dsn=wait
                                    
               
                command line (V8.13 and later)
define(`confTO_QUEUEWARN_DSN´,`wait
               ´)           
               
                mc config (V8.13 and later)

One handy use for this dsn keyword would be to prevent warnings from being sent for DSN mail. You can do this by setting this warning timeout greater than the return timeout for regular mail:

define(`confTO_QUEUERETURN´,  `5d´)
define(`confTO_QUEUEWARN_DSN´, `7d´)

Here, normal mail will be returned (bounced) after five days, but because DSN mail won’t issue a warning until after seven days, no warnings will be sent.

Beginning with V8.13, the new Milter.macros.eom option defines a list of macros to be passed to a Milter’s end-of-message handling routine. It is declared like this:

O Milter.macros.eom=list                      
               
               
                configuration file (V8.13 and later) 
-OMilter.macros.eom=list                      
               
               
                command line (V8.13 and later)
define(`confMILTER_MACROS_EOM´,`list´)        
               
                mc configuration (V8.13 and later) 

The Milter.macros.eom option is of type string. The list is a sequence of macro names, each separated from the next with a comma and each stripped of its leading $ prefix—that is, {nbadrcpts}, not ${nbadrcpts}.

The default macro passed to the Milter’s end-of-message routine is the ${msg_id} macro (Section 21.1.5 ^[V8.13]). If you wish to add other macros to the default list, you may do so using your mc configuration file like this:

define(`confMILTER_MACROS_EOM´, confMILTER_MACROS_EOM``,{nbadrcpts}´Â´)

Here, we added the ${nbadrcpts} macro (Section 21.1.6 ^[V8.13]) to the default list of macros. Note the use of double half quotes. They are needed because the added macro contains a comma (recall that the list of macros must be delimited with commas).

The Milter.macros.eom option is not safe. If specified from the command line, it can cause sendmail to relinquish its special privileges.