SENDMAILTM INSTALLATION AND OPERATION GUIDE Eric Allman Claus Assmann Gregory Neil Shapiro Sendmail, Inc. Version 8.741 For Sendmail Version 8.14 SendmailTM implements a general purpose internetwork mail routing facility under the UNIX(R) operating system. It is not tied to any one transport protocol -- its function may be likened to a crossbar switch, relaying messages from one domain into another. In the process, it can do a lim- ited amount of message header editing to put the message into a format that is appropriate for the receiving domain. All of this is done under the control of a configuration file. Due to the requirements of flexibility for sendmail, the configuration file can seem somewhat unapproachable. However, there are only a few basic configurations for most sites, for which standard configuration files have been sup- plied. Most other configurations can be built by adjusting an existing configuration file incrementally. Sendmail is based on RFC 821 (Simple Mail Transport Protocol), RFC 822 (Internet Mail Headers Format), RFC 974 (MX routing), RFC 1123 (Internet Host Requirements), RFC 1413 (Identification server), RFC 1652 (SMTP 8BITMIME Exten- sion), RFC 1869 (SMTP Service Extensions), RFC 1870 (SMTP SIZE Extension), RFC 1891 (SMTP Delivery Status Notifica- tions), RFC 1892 (Multipart/Report), RFC 1893 (Enhanced Mail System Status Codes), RFC 1894 (Delivery Status Notifica- tions), RFC 1985 (SMTP Service Extension for Remote Message Queue Starting), RFC 2033 (Local Message Transmission Proto- col), RFC 2034 (SMTP Service Extension for Returning ____________________ DISCLAIMER: This documentation is under modification. Sendmail is a trademark of Sendmail, Inc. Sendmail Installation and Operation Guide SMM:08-1 SMM:08-2 Sendmail Installation and Operation Guide Enhanced Error Codes), RFC 2045 (MIME), RFC 2476 (Message Submission), RFC 2487 (SMTP Service Extension for Secure SMTP over TLS), RFC 2554 (SMTP Service Extension for Authen- tication), RFC 2821 (Simple Mail Transfer Protocol), RFC 2822 (Internet Message Format), RFC 2852 (Deliver By SMTP Service Extension), and RFC 2920 (SMTP Service Extension for Command Pipelining). However, since sendmail is designed to work in a wider world, in many cases it can be configured to exceed these protocols. These cases are described herein. Although sendmail is intended to run without the need for monitoring, it has a number of features that may be used to monitor or adjust the operation under unusual circum- stances. These features are described. Section one describes how to do a basic sendmail installation. Section two explains the day-to-day informa- tion you should know to maintain your mail system. If you have a relatively normal site, these two sections should contain sufficient information for you to install sendmail and keep it happy. Section three has information regarding the command line arguments. Section four describes some parameters that may be safely tweaked. Section five con- tains the nitty-gritty information about the configuration file. This section is for masochists and people who must write their own configuration file. Section six describes configuration that can be done at compile time. The appendixes give a brief but detailed explanation of a number of features not described in the rest of the paper. Sendmail Installation and Operation Guide SMM:08-7 1. BASIC INSTALLATION There are two basic steps to installing sendmail. First, you have to compile and install the binary. If sendmail has already been ported to your operating system that should be simple. Second, you must build a run-time configuration file. This is a file that sendmail reads when it starts up that describes the mailers it knows about, how to parse addresses, how to rewrite the message header, and the settings of various options. Although the configuration file can be quite complex, a configura- tion can usually be built using an M4-based configuration language. Assuming you have the standard sendmail dis- tribution, see cf/README for further information. The remainder of this section will describe the installation of sendmail assuming you can use one of the existing configurations and that the standard installa- tion parameters are acceptable. All pathnames and exam- ples are given from the root of the sendmail subtree, normally /usr/src/usr.sbin/sendmail on 4.4BSD-based sys- tems. Continue with the next section if you need/want to compile sendmail yourself. If you have a running binary already on your system, you should probably skip to sec- tion 1.2. 1.1. Compiling Sendmail All sendmail source is in the sendmail subdirec- tory. To compile sendmail, "cd" into the sendmail directory and type ./Build This will leave the binary in an appropriately named subdirectory, e.g., obj.BSD-OS.2.1.i386. It works for multiple object versions compiled out of the same directory. 1.1.1. Tweaking the Build Invocation You can give parameters on the Build command. In most cases these are only used when the obj.* directory is first created. To restart from scratch, use -c. These commands include: -L libdirs A list of directories to search for libraries. -I incdirs A list of directories to search for include SMM:08-8 Sendmail Installation and Operation Guide files. -E envar=value Set an environment variable to an indicated value before compiling. -c Create a new obj.* tree before running. -f siteconfig Read the indicated site configuration file. If this parameter is not specified, Build includes all of the files $BUILD- TOOLS/Site/site.$oscf.m4 and $BUILD- TOOLS/Site/site.config.m4, where $BUILDTOOLS is normally ../devtools and $oscf is the same name as used on the obj.* directory. See below for a description of the site configura- tion file. -S Skip auto-configuration. Build will avoid auto-detecting libraries if this is set. All libraries and map definitions must be speci- fied in the site configuration file. Most other parameters are passed to the make pro- gram; for details see $BUILDTOOLS/README. 1.1.2. Creating a Site Configuration File (This section is not yet complete. For now, see the file devtools/README for details.) See sendmail/README for various compilation flags that can be set. 1.1.3. Tweaking the Makefile Sendmail supports two different formats for the local (on disk) version of databases, notably the aliases database. At least one of these should be defined if at all possible. NDBM The ``new DBM'' format, available on nearly all systems around today. This was the preferred format prior to 4.4BSD. It allows such complex things as multiple databases and closing a currently open database. NEWDB The Berkeley DB package. If you have this, use it. It allows long records, multiple open databases, real in-memory caching, and so forth. You can define this in conjunction with NDBM; if you do, Sendmail Installation and Operation Guide SMM:08-9 old alias databases are read, but when a new database is created it will be in NEWDB format. As a nasty hack, if you have NEWDB, NDBM, and NIS defined, and if the alias file name includes the sub- string "/yp/", sendmail will create both new and old versions of the alias file during a newalias command. This is required because the Sun NIS/YP system reads the DBM version of the alias file. It's ugly as sin, but it works. If neither of these are defined, sendmail reads the alias file into memory on every invocation. This can be slow and should be avoided. There are also several methods for remote database access: LDAP Lightweight Directory Access Protocol. NIS Sun's Network Information Services (for- merly YP). NISPLUS Sun's NIS+ services. NETINFO NeXT's NetInfo service. HESIOD Hesiod service (from Athena). Other compilation flags are set in conf.h and should be predefined for you unless you are porting to a new environment. For more options see send- mail/README. 1.1.4. Compilation and installation After making the local system configuration described above, You should be able to compile and install the system. The script "Build" is the best approach on most systems: ./Build This will use uname(1) to create a custom Makefile for your environment. If you are installing in the standard places, you should be able to install using ./Build install This should install the binary in /usr/sbin and create links from /usr/bin/newaliases and /usr/bin/mailq to /usr/sbin/sendmail. On most SMM:08-10 Sendmail Installation and Operation Guide systems it will also format and install man pages. Notice: as of version 8.12 sendmail will no longer be installed set-user-ID root by default. If you really want to use the old method, you can specify it as target: ./Build install-set-user-id 1.2. Configuration Files Sendmail cannot operate without a configuration file. The configuration defines the mail delivery mechanisms understood at this site, how to access them, how to forward email to remote mail systems, and a number of tuning parameters. This configuration file is detailed in the later portion of this docu- ment. The sendmail configuration can be daunting at first. The world is complex, and the mail configura- tion reflects that. The distribution includes an m4-based configuration package that hides a lot of the complexity. See cf/README for details. Our configuration files are processed by m4 to facilitate local customization; the directory cf of the sendmail distribution directory contains the source files. This directory contains several subdi- rectories: cf Both site-dependent and site-independent descriptions of hosts. These can be literal host names (e.g., "ucbvax.mc") when the hosts are gateways or more general descrip- tions (such as "generic-solaris2.mc" as a general description of an SMTP-connected host running Solaris 2.x. Files ending .mc (``M4 Configuration'') are the input descriptions; the output is in the corre- sponding .cf file. The general structure of these files is described below. domain Site-dependent subdomain descriptions. These are tied to the way your organization wants to do addressing. For example, domain/CS.Berkeley.EDU.m4 is our description for hosts in the CS.Berkeley.EDU subdomain. These are referenced using the DOMAIN m4 macro in the .mc file. feature Definitions of specific features that some particular host in your site might want. Sendmail Installation and Operation Guide SMM:08-11 These are referenced using the FEATURE m4 macro. An example feature is use_cw_file (which tells sendmail to read an /etc/mail/local-host-names file on startup to find the set of local names). hack Local hacks, referenced using the HACK m4 macro. Try to avoid these. The point of having them here is to make it clear that they smell. m4 Site-independent m4(1) include files that have information common to all configuration files. This can be thought of as a "#include" directory. mailer Definitions of mailers, referenced using the MAILER m4 macro. The mailer types that are known in this distribution are fax, local, smtp, uucp, and usenet. For example, to include support for the UUCP-based mailers, use "MAILER(uucp)". ostype Definitions describing various operating system environments (such as the location of support files). These are referenced using the OSTYPE m4 macro. sh Shell files used by the m4 build process. You shouldn't have to mess with these. siteconfig Local UUCP connectivity information. This directory has been supplanted by the mail- ertable feature; any new configurations should use that feature to do UUCP (and other) routing. The use of this directory is deprecated. If you are in a new domain (e.g., a company), you will probably want to create a cf/domain file for your domain. This consists primarily of relay definitions and features you want enabled site-wide: for example, Berkeley's domain definition defines relays for BitNET and UUCP. These are specific to Berkeley, and should be fully-qualified internet-style domain names. Please check to make certain they are reasonable for your domain. Subdomains at Berkeley are also represented in the cf/domain directory. For example, the domain CS.Berkeley.EDU is the Computer Science subdomain, EECS.Berkeley.EDU is the Electrical Engineering and SMM:08-12 Sendmail Installation and Operation Guide Computer Sciences subdomain, and S2K.Berkeley.EDU is the Sequoia 2000 subdomain. You will probably have to add an entry to this directory to be appropriate for your domain. You will have to use or create .mc files in the cf/cf subdirectory for your hosts. This is detailed in the cf/README file. 1.3. Details of Installation Files This subsection describes the files that comprise the sendmail installation. 1.3.1. /usr/sbin/sendmail The binary for sendmail is located in /usr/sbin[1]. It should be set-group-ID smmsp as described in sendmail/SECURITY. For security rea- sons, /, /usr, and /usr/sbin should be owned by root, mode 0755[2]. 1.3.2. /etc/mail/sendmail.cf This is the main configuration file for send- mail[3]. This is one of the two non-library file names compiled into sendmail[4], the other is /etc/mail/submit.cf. The configuration file is normally created using the distribution files described above. If you have a particularly unusual system ____________________ [1]This is usually /usr/sbin on 4.4BSD and newer systems; many systems install it in /usr/lib. I understand it is in /usr/ucblib on System V Release 4. [2]Some vendors ship them owned by bin; this creates a security hole that is not actually related to sendmail. Other important directories that should have restrictive ownerships and permissions are /bin, /usr/bin, /etc, /etc/mail, /usr/etc, /lib, and /usr/lib. [3]Actually, the pathname varies depending on the operat- ing system; /etc/mail is the preferred directory. Some old- er systems install it in /usr/lib/sendmail.cf, and I've also seen it in /usr/ucblib. If you want to move this file, add -D_PATH_SENDMAILCF=\"/file/name\" to the flags passed to the C compiler. Moving this file is not recommended: other pro- grams and scripts know of this location. [4]The system libraries can reference other files; in particular, system library subroutines that sendmail calls probably reference /etc/passwd and /etc/resolv.conf. Sendmail Installation and Operation Guide SMM:08-13 configuration you may need to create a special ver- sion. The format of this file is detailed in later sections of this document. 1.3.3. /etc/mail/submit.cf This is the configuration file for sendmail when it is used for initial mail submission, in which case it is also called ``Mail Submission Pro- gram'' (MSP) in contrast to ``Mail Transfer Agent'' (MTA). Starting with version 8.12, sendmail uses one of two different configuration files based on its operation mode (or the new -A option). For initial mail submission, i.e., if one of the options -bm (default), -bs, or -t is specified, submit.cf is used (if available), for other opera- tions sendmail.cf is used. Details can be found in sendmail/SECURITY. submit.cf is shipped with send- mail (in cf/cf/) and is installed by default. If changes to the configuration need to be made, start with cf/cf/submit.mc and follow the instruction in cf/README. 1.3.4. /usr/bin/newaliases The newaliases command should just be a link to sendmail: rm -f /usr/bin/newaliases ln -s /usr/sbin/sendmail /usr/bin/newaliases This can be installed in whatever search path you prefer for your system. 1.3.5. /usr/bin/hoststat The hoststat command should just be a link to sendmail, in a fashion similar to newaliases. This command lists the status of the last mail transac- tion with all remote hosts. The -v flag will pre- vent the status display from being truncated. It functions only when the HostStatusDirectory option is set. 1.3.6. /usr/bin/purgestat This command is also a link to sendmail. It flushes expired (Timeout.hoststatus) information that is stored in the HostStatusDirectory tree. SMM:08-14 Sendmail Installation and Operation Guide 1.3.7. /var/spool/mqueue The directory /var/spool/mqueue should be cre- ated to hold the mail queue. This directory should be mode 0700 and owned by root. The actual path of this directory is defined by the QueueDirectory option of the sendmail.cf file. To use multiple queues, supply a value end- ing with an asterisk. For example, /var/spool/mqueue/qd* will use all of the directo- ries or symbolic links to directories beginning with `qd' in /var/spool/mqueue as queue directo- ries. Do not change the queue directory structure while sendmail is running. If these directories have subdirectories or symbolic links to directories named `qf', `df', and `xf', then these will be used for the different queue file types. That is, the data files are stored in the `df' subdirectory, the transcript files are stored in the `xf' subdirectory, and all others are stored in the `qf' subdirectory. If shared memory support is compiled in, send- mail stores the available diskspace in a shared memory segment to make the values readily available to all children without incurring system overhead. In this case, only the daemon updates the data; i.e., the sendmail daemon creates the shared memory segment and deletes it if it is terminated. To use this, sendmail must have been compiled with support for shared memory (-DSM_CONF_SHM) and the option SharedMemoryKey must be set. Notice: do not use the same key for sendmail invocations with differ- ent queue directories or different queue group dec- larations. Access to shared memory is not con- trolled by locks, i.e., there is a race condition when data in the shared memory is updated. How- ever, since operation of sendmail does not rely on the data in the shared memory, this does not nega- tively influence the behavior. 1.3.8. /var/spool/clientmqueue The directory /var/spool/clientmqueue should be created to hold the mail queue. This directory should be mode 0770 and owned by user smmsp, group smmsp. The actual path of this directory is defined by the QueueDirectory option of the submit.cf file. Sendmail Installation and Operation Guide SMM:08-15 1.3.9. /var/spool/mqueue/.hoststat This is a typical value for the HostStatusDi- rectory option, containing one file per host that this sendmail has chatted with recently. It is normally a subdirectory of mqueue. 1.3.10. /etc/mail/aliases* The system aliases are held in "/etc/mail/aliases". A sample is given in "send- mail/aliases" which includes some aliases which must be defined: cp sendmail/aliases /etc/mail/aliases edit /etc/mail/aliases You should extend this file with any aliases that are apropos to your system. Normally sendmail looks at a database version of the files, stored either in "/etc/mail/aliases.dir" and "/etc/mail/aliases.pag" or "/etc/mail/aliases.db" depending on which data- base package you are using. The actual path of this file is defined in the AliasFile option of the sendmail.cf file. The permissions of the alias file and the database versions should be 0640 to prevent local denial of service attacks as explained in the top level README in the sendmail distribution. If the permissions 0640 are used, be sure that only trusted users belong to the group assigned to those files. Otherwise, files should not even be group readable. 1.3.11. /etc/rc or /etc/init.d/sendmail It will be necessary to start up the sendmail daemon when your system reboots. This daemon per- forms two functions: it listens on the SMTP socket for connections (to receive mail from a remote sys- tem) and it processes the queue periodically to insure that mail gets delivered when hosts come up. If necessary, add the following lines to "/etc/rc" (or "/etc/rc.local" as appropriate) in the area where it is starting up the daemons on a BSD-base system, or on a System-V-based system in one of the startup files, typically "/etc/init.d/sendmail": SMM:08-16 Sendmail Installation and Operation Guide if [ -f /usr/sbin/sendmail -a -f /etc/mail/sendmail.cf ]; then (cd /var/spool/mqueue; rm -f xf*) /usr/sbin/sendmail -bd -q30m & echo -n ' sendmail' >/dev/console fi The "cd" and "rm" commands insure that all tran- script files have been removed; extraneous tran- script files may be left around if the system goes down in the middle of processing a message. The line that actually invokes sendmail has two flags: "-bd" causes it to listen on the SMTP port, and "-q30m" causes it to run the queue every half hour. Some people use a more complex startup script, removing zero length qf/hf/Qf files and df files for which there is no qf/hf/Qf file. Note this is not advisable. For example, see Figure 1 for an example of a complex script which does this clean up. 1.3.12. /etc/mail/helpfile This is the help file used by the SMTP HELP command. It should be copied from "sendmail/help- file": cp sendmail/helpfile /etc/mail/helpfile The actual path of this file is defined in the HelpFile option of the sendmail.cf file. 1.3.13. /etc/mail/statistics If you wish to collect statistics about your mail traffic, you should create the file "/etc/mail/statistics": cp /dev/null /etc/mail/statistics chmod 0600 /etc/mail/statistics This file does not grow. It is printed with the program "mailstats/mailstats.c." The actual path of this file is defined in the S option of the sendmail.cf file. 1.3.14. /usr/bin/mailq If sendmail is invoked as "mailq," it will simulate the -bp flag (i.e., sendmail will print the contents of the mail queue; see below). This should be a link to /usr/sbin/sendmail. Sendmail Installation and Operation Guide SMM:08-17 ____________________________________________________________ #!/bin/sh # remove zero length qf/hf/Qf files for qffile in qf* hf* Qf* do if [ -r $qffile ] then if [ ! -s $qffile ] then echo -n " " > /dev/console rm -f $qffile fi fi done # rename tf files to be qf if the qf does not exist for tffile in tf* do qffile=`echo $tffile | sed 's/t/q/'` if [ -r $tffile -a ! -f $qffile ] then echo -n " " > /dev/console mv $tffile $qffile else if [ -f $tffile ] then echo -n " " > /dev/console rm -f $tffile fi fi done # remove df files with no corresponding qf/hf/Qf files for dffile in df* do qffile=`echo $dffile | sed 's/d/q/'` hffile=`echo $dffile | sed 's/d/h/'` Qffile=`echo $dffile | sed 's/d/Q/'` if [ -r $dffile -a ! -f $qffile -a ! -f $hffile -a ! -f $Qffile ] then echo -n " " > /dev/console mv $dffile `echo $dffile | sed 's/d/D/'` fi done # announce files that have been saved during disaster recovery for xffile in [A-Z]f* do if [ -f $xffile ] then echo -n " " > /dev/console fi done SMM:08-18 Sendmail Installation and Operation Guide Figure 1 -- A complex startup script ____________________________________________________________ 1.3.15. sendmail.pid sendmail stores its current pid in the file specified by the PidFile option (default is _PATH_SENDMAILPID). sendmail uses TempFileMode (which defaults to 0600) as the permissions of that file to prevent local denial of service attacks as explained in the top level README in the sendmail distribution. If the file already exists, then it might be necessary to change the permissions accordingly, e.g., chmod 0600 /var/run/sendmail.pid Note that as of version 8.13, this file is unlinked when sendmail exits. As a result of this change, a script such as the following, which may have worked prior to 8.13, will no longer work: # stop & start sendmail PIDFILE=/var/run/sendmail.pid kill `head -1 $PIDFILE` `tail -1 $PIDFILE` because it assumes that the pidfile will still exist even after killing the process to which it refers. Below is a script which will work cor- rectly on both newer and older versions: # stop & start sendmail PIDFILE=/var/run/sendmail.pid pid=`head -1 $PIDFILE` cmd=`tail -1 $PIDFILE` kill $pid $cmd This is just an example script, it does not perform any error checks, e.g., whether the pidfile exists at all. 1.3.16. Map Files To prevent local denial of service attacks as explained in the top level README in the sendmail distribution, the permissions of map files created by makemap should be 0640. The use of 0640 implies that only trusted users belong to the group assigned to those files. If those files already exist, then it might be necessary to change the Sendmail Installation and Operation Guide SMM:08-19 permissions accordingly, e.g., cd /etc/mail chmod 0640 *.db *.pag *.dir 2. NORMAL OPERATIONS 2.1. The System Log The system log is supported by the syslogd(8) program. All messages from sendmail are logged under the LOG_MAIL facility[5]. 2.1.1. Format Each line in the system log consists of a timestamp, the name of the machine that generated it (for logging from several machines over the local area network), the word "sendmail:", and a message[6]. Most messages are a sequence of name=value pairs. The two most common lines are logged when a message is processed. The first logs the receipt of a message; there will be exactly one of these per message. Some fields may be omitted if they do not contain interesting information. Fields are: from The envelope sender address. size The size of the message in bytes. class The class (i.e., numeric precedence) of the message. pri The initial message priority (used for queue sorting). nrcpts The number of envelope recipients for this message (after aliasing and forward- ing). msgid The message id of the message (from the header). ____________________ [5]Except on Ultrix, which does not support facilities in the syslog. [6]This format may vary slightly if your vendor has changed the syntax. SMM:08-20 Sendmail Installation and Operation Guide proto The protocol used to receive this message (e.g., ESMTP or UUCP) daemon The daemon name from the DaemonPortOp- tions setting. relay The machine from which it was received. There is also one line logged per delivery attempt (so there can be several per message if delivery is deferred or there are multiple recipients). Fields are: to A comma-separated list of the recipients to this mailer. ctladdr The ``controlling user'', that is, the name of the user whose credentials we use for delivery. delay The total delay between the time this message was received and the current delivery attempt. xdelay The amount of time needed in this deliv- ery attempt (normally indicative of the speed of the connection). mailer The name of the mailer used to deliver to this recipient. relay The name of the host that actually accepted (or rejected) this recipient. dsn The enhanced error code (RFC 2034) if available. stat The delivery status. Not all fields are present in all messages; for example, the relay is usually not listed for local deliveries. 2.1.2. Levels If you have syslogd(8) or an equivalent installed, you will be able to do logging. There is a large amount of information that can be logged. The log is arranged as a succession of levels. At the lowest level only extremely strange situations are logged. At the highest level, even the most mundane and uninteresting events are recorded for posterity. As a convention, log Sendmail Installation and Operation Guide SMM:08-21 levels under ten are considered generally "useful;" log levels above 64 are reserved for debugging pur- poses. Levels from 11-64 are reserved for verbose information that some sites might want. A complete description of the log levels is given in section ``Log Level''. 2.2. Dumping State You can ask sendmail to log a dump of the open files and the connection cache by sending it a SIGUSR1 signal. The results are logged at LOG_DEBUG priority. 2.3. The Mail Queues Mail messages may either be delivered immediately or be held for later delivery. Held messages are placed into a holding directory called a mail queue. A mail message may be queued for these reasons: + If a mail message is temporarily undeliverable, it is queued and delivery is attempted later. If the message is addressed to multiple recipients, it is queued only for those recipients to whom delivery is not immediately possible. + If the SuperSafe option is set to true, all mail messages are queued while delivery is attempted. + If the DeliveryMode option is set to queue-only or defer, all mail is queued, and no immediate deliv- ery is attempted. + If the load average becomes higher than the value of the QueueLA option and the QueueFactor (q) option divided by the difference in the current load average and the QueueLA option plus one is less than the priority of the message, messages are queued rather than immediately delivered. + One or more addresses are marked as expensive and delivery is postponed until the next queue run or one or more address are marked as held via mailer which uses the hold mailer flag. + The mail message has been marked as quarantined via a mail filter or rulesets. + 2.3.1. Queue Groups and Queue Directories There are one or more mail queues. Each mail queue belongs to a queue group. There is always a default queue group that is called ``mqueue'' (which is where messages go by default unless oth- erwise specified). The directory or directories SMM:08-22 Sendmail Installation and Operation Guide which comprise the default queue group are speci- fied by the QueueDirectory option. There are zero or more additional named queue groups declared using the Q command in the configuration file. By default, a queued message is placed in the queue group associated with the first recipient in the recipient list. A recipient address is mapped to a queue group as follows. First, if there is a ruleset called ``queuegroup'', and if this ruleset maps the address to a queue group name, then that queue group is chosen. That is, the argument for the ruleset is the recipient address and the result should be $# followed by the name of a queue group. Otherwise, if the mailer associated with the address specifies a queue group, then that queue group is chosen. Otherwise, the default queue group is chosen. A message with multiple recipients will be split if different queue groups are chosen by the mapping of recipients to queue groups. When a message is placed in a queue group, and the queue group has more than one queue, a queue is selected randomly. If a message with multiple recipients is placed into a queue group with the 'r' option (max- imum number of recipients per message) set to a positive value N, and if there are more than N recipients in the message, then the message will be split into multiple messages, each of which have at most N recipients. Notice: if multiple queue groups are used, do not move queue files around, e.g., into a different queue directory. This may have weird effects and can cause mail not to be delivered. Queue files and directories should be treated as opaque and should not be manipulated directly. 2.3.2. Queue Runs sendmail has two different ways to process the queue(s). The first one is to start queue runners after certain intervals (``normal'' queue runners), the second one is to keep queue runner processes around (``persistent'' queue runners). How to select either of these types is discussed in the appendix ``COMMAND LINE FLAGS''. Persistent queue runners have the advantage that no new processes need to be spawned at certain intervals; they just Sendmail Installation and Operation Guide SMM:08-23 sleep for a specified time after they finished a queue run. Another advantage of persistent queue runners is that only one process belonging to a workgroup (a workgroup is a set of queue groups) collects the data for a queue run and then multiple queue runner may go ahead using that data. This can significantly reduce the disk I/O necessary to read the queue files compared to starting multiple queue runners directly. Their disadvantage is that a new queue run is only started after all queue runners belonging to a group finished their tasks. In case one of the queue runners tries delivery to a slow recipient site at the end of a queue run, the next queue run may be substantially delayed. In general this should be smoothed out due to the distribution of those slow jobs, however, for sites with small number of queue entries this might introduce noticable delays. In general, persistent queue runners are only useful for sites with big queues. 2.3.3. Manual Intervention Under normal conditions the mail queue will be processed transparently. However, you may find that manual intervention is sometimes necessary. For example, if a major host is down for a period of time the queue may become clogged. Although sendmail ought to recover gracefully when the host comes up, you may find performance unacceptably bad in the meantime. In that case you want to check the content of the queue and manipulate it as explained in the next two sections. 2.3.4. Printing the queue The contents of the queue(s) can be printed using the mailq command (or by specifying the -bp flag to sendmail): mailq This will produce a listing of the queue id's, the size of the message, the date the message entered the queue, and the sender and recipients. If shared memory support is compiled in, the flag -bP can be used to print the number of entries in the queue(s), provided a process updates the data. However, as explained earlier, the output might be slightly wrong, since access to the shared memory is not locked. For example, ``unknown number of entries'' might be shown. The internal counters are updated after each queue run to the correct SMM:08-24 Sendmail Installation and Operation Guide value again. 2.3.5. Forcing the queue Sendmail should run the queue automatically at intervals. When using multiple queues, a separate process will by default be created to run each of the queues unless the queue run is initiated by a user with the verbose flag. The algorithm is to read and sort the queue, and then to attempt to process all jobs in order. When it attempts to run the job, sendmail first checks to see if the job is locked. If so, it ignores the job. There is no attempt to insure that only one queue processor exists at any time, since there is no guarantee that a job cannot take forever to process (however, sendmail does include heuristics to try to abort jobs that are taking absurd amounts of time; technically, this violates RFC 821, but is blessed by RFC 1123). Due to the locking algo- rithm, it is impossible for one job to freeze the entire queue. However, an uncooperative recipient host or a program recipient that never returns can accumulate many processes in your system. Unfortu- nately, there is no completely general way to solve this. In some cases, you may find that a major host going down for a couple of days may create a pro- hibitively large queue. This will result in send- mail spending an inordinate amount of time sorting the queue. This situation can be fixed by moving the queue to a temporary place and creating a new queue. The old queue can be run later when the offending host returns to service. To do this, it is acceptable to move the entire queue directory: cd /var/spool mv mqueue omqueue; mkdir mqueue; chmod 0700 mqueue You should then kill the existing daemon (since it will still be processing in the old queue direc- tory) and create a new daemon. To run the old mail queue, issue the following command: /usr/sbin/sendmail -C /etc/mail/queue.cf -q The -C flag specifies an alternate configuration Sendmail Installation and Operation Guide SMM:08-25 file queue.cf which should refer to the moved queue directory O QueueDirectory=/var/spool/omqueue and the -q flag says to just run every job in the queue. You can also specify the moved queue direc- tory on the command line /usr/sbin/sendmail -oQ/var/spool/omqueue -q but this requires that you do not have queue groups in the configuration file, because those are not subdirectories of the moved directory. See the section about ``Queue Group Declaration'' for details; you most likely need a different configu- ration file to correctly deal with this problem. However, a proper configuration of queue groups should avoid filling up queue directories, so you shouldn't run into this problem. If you have a tendency toward voyeurism, you can use the -v flag to watch what is going on. When the queue is finally emptied, you can remove the directory: rmdir /var/spool/omqueue 2.3.6. Quarantined Queue Items It is possible to "quarantine" mail messages, otherwise known as envelopes. Envelopes (queue files) are stored but not considered for delivery or display unless the "quarantine" state of the envelope is undone or delivery or display of quar- antined items is requested. Quarantined messages are tagged by using a different name for the queue file, 'hf' instead of 'qf', and by adding the quar- antine reason to the queue file. Delivery or display of quarantined items can be requested using the -qQ flag to sendmail or mailq. Additionally, messages already in the queue can be quarantined or unquarantined using the new -Q flag to sendmail. For example, sendmail -Qreason -q[!][I|R|S][matchstring] Quarantines the normal queue items matching the criteria specified by the -q[!][I|R|S][matchstring] using the reason given on the -Q flag. Likewise, SMM:08-26 Sendmail Installation and Operation Guide sendmail -qQ -Q[reason] -q[!][I|R|S|Q][matchstring] Change the quarantine reason for the quarantined items matching the criteria specified by the -q[!][I|R|S|Q][matchstring] using the reason given on the -Q flag. If there is no reason, unquarantine the matching items and make them nor- mal queue items. Note that the -qQ flag tells sendmail to operate on quarantined items instead of normal items. 2.4. Disk Based Connection Information Sendmail stores a large amount of information about each remote system it has connected to in mem- ory. It is possible to preserve some of this informa- tion on disk as well, by using the HostStatusDirectory option, so that it may be shared between several invo- cations of sendmail. This allows mail to be queued immediately or skipped during a queue run if there has been a recent failure in connecting to a remote machine. Note: information about a remote system is stored in a file whose pathname consists of the compo- nents of the hostname in reverse order. For example, the information for host.example.com is stored in com./example./host. For top-level domains like com this can create a large number of subdirectories which on some filesystems can exhaust some limits. More- over, the performance of lookups in directory with thousands of entries can be fairly slow depending on the filesystem implementation. Additionally enabling SingleThreadDelivery has the added effect of single-threading mail delivery to a destination. This can be quite helpful if the remote machine is running an SMTP server that is eas- ily overloaded or cannot accept more than a single connection at a time, but can cause some messages to be punted to a future queue run. It also applies to all hosts, so setting this because you have one machine on site that runs some software that is easily overrun can cause mail to other hosts to be slowed down. If this option is set, you probably want to set the MinQueueAge option as well and run the queue fairly frequently; this way jobs that are skipped because another sendmail is talking to the same host will be tried again quickly rather than being delayed for a long time. The disk based host information is stored in a subdirectory of the mqueue directory called .host- Sendmail Installation and Operation Guide SMM:08-27 stat[7]. Removing this directory and its subdirecto- ries has an effect similar to the purgestat command and is completely safe. However, purgestat only removes expired (Timeout.hoststatus) data. The infor- mation in these directories can be perused with the hoststat command, which will indicate the host name, the last access, and the status of that access. An asterisk in the left most column indicates that a sendmail process currently has the host locked for mail delivery. The disk based connection information is treated the same way as memory based connection information for the purpose of timeouts. By default, information about host failures is valid for 30 minutes. This can be adjusted with the Timeout.hoststatus option. The connection information stored on disk may be expired at any time with the purgestat command or by invoking sendmail with the -bH switch. The connection information may be viewed with the hoststat command or by invoking sendmail with the -bh switch. 2.5. The Service Switch The implementation of certain system services such as host and user name lookup is controlled by the service switch. If the host operating system supports such a switch, and sendmail knows about it, sendmail will use the native version. Ultrix, Solaris, and DEC OSF/1 are examples of such systems[8]. If the underlying operating system does not sup- port a service switch (e.g., SunOS 4.X, HP-UX, BSD) then sendmail will provide a stub implementation. The ServiceSwitchFile option points to the name of a file that has the service definitions. Each line has the name of a service and the possible implementations of that service. For example, the file: hosts dns files nis aliases files nis will ask sendmail to look for hosts in the Domain Name System first. If the requested host name is not ____________________ [7]This is the usual value of the HostStatusDirectory op- tion; it can, of course, go anywhere you like in your filesystem. [8]HP-UX 10 has service switch support, but since the APIs are apparently not available in the libraries sendmail does not use the native service switch in this release. SMM:08-28 Sendmail Installation and Operation Guide found, it tries local files, and if that fails it tries NIS. Similarly, when looking for aliases it will try the local files first followed by NIS. Notice: since sendmail must access MX records for correct operation, it will use DNS if it is configured in the ServiceSwitchFile file. Hence an entry like hosts files dns will not avoid DNS lookups even if a host can be found in /etc/hosts. Service switches are not completely integrated. For example, despite the fact that the host entry listed in the above example specifies to look in NIS, on SunOS this won't happen because the system imple- mentation of gethostbyname(3) doesn't understand this. 2.6. The Alias Database After recipient addresses are read from the SMTP connection or command line they are parsed by ruleset 0, which must resolve to a {mailer, host, address} triple. If the flags selected by the mailer include the A (aliasable) flag, the address part of the triple is looked up as the key (i.e., the left hand side) in the alias database. If there is a match, the address is deleted from the send queue and all addresses on the right hand side of the alias are added in place of the alias that was found. This is a recursive opera- tion, so aliases found in the right hand side of the alias are similarly expanded. 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; e.g., eric@prep.ai.MIT.EDU: eric@CS.Berkeley.EDU will not have the desired effect (except on prep.ai.MIT.EDU, and they probably don't want me)[9]. Aliases may be continued by starting any continuation ____________________ [9]Actually, any mailer that has the `A' mailer flag set will permit aliasing; this is normally limited to the local mailer. Sendmail Installation and Operation Guide SMM:08-29 lines with a space or a tab or by putting a backslash directly before the newline. Blank lines and lines beginning with a sharp sign ("#") are comments. The second form is processed by the ndbm(3)[10] or the 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 control of search order is actually set by the service switch. Essentially, the entry O AliasFile=switch:aliases is always added as the first alias entry; also, the first alias file name without a class (e.g., 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 O AliasFile=/etc/mail/aliases and the service switch contains aliases nis files nisplus then aliases will first be searched in the NIS data- base, then in /etc/mail/aliases, then in the NIS+ database. You can also use NIS-based alias files. For example, the specification: O AliasFile=/etc/mail/aliases O AliasFile=nis:mail.aliases@my.nis.domain will first search the /etc/mail/aliases file and then the map named "mail.aliases" in "my.nis.domain". Warning: if you build your own NIS-based alias files, be sure to provide the -l flag to makedbm(8) to map upper case letters in the keys to lower case; other- wise, aliases with upper case letters in their names won't match incoming addresses. Additional flags can be added after the colon exactly like a K line -- for example: ____________________ [10]The gdbm package does not work. SMM:08-30 Sendmail Installation and Operation Guide O AliasFile=nis:-N mail.aliases@my.nis.domain will search the appropriate NIS map and always include null bytes in the key. Also: O AliasFile=nis:-f mail.aliases@my.nis.domain will prevent sendmail from downcasing the key before the alias lookup. 2.6.1. Rebuilding the alias database The hash 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 you have multiple aliases databases speci- fied, the -bi flag rebuilds all the database types it understands (for example, it can rebuild NDBM databases but not NIS databases). 2.6.2. Potential problems 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 inter- rupts 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 unwritable. 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 insure that Sendmail Installation and Operation Guide SMM:08-31 this entry exists[11]. 2.6.3. List owners If an error occurs on sending to a certain address, say "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 main- tenance of the list itself; in this case the list maintainer would be the owner of the list. For example: unix-wizards: eric@ucbarpa, wnj@monet, nosuchuser, sam@matisse owner-unix-wizards: unix-wizards-request unix-wizards-request: eric@ucbarpa would cause "eric@ucbarpa" 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, oth- erwise the name of the alias itself is used. For this reason, and to obey 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. 2.7. User Information Database This option is deprecated, use virtusertable and genericstable instead as explained in cf/README. If you have a version of sendmail with the user informa- tion database compiled in, and you have specified one or more databases using the U option, the databases will be searched for a user:maildrop entry. If found, the mail will be sent to the specified address. 2.8. Per-User Forwarding (.forward Files) As an alternative to the alias database, any user may put a file with the name ".forward" in his or her home directory. If this file exists, sendmail ____________________ [11]The AliasWait option is required in the configuration for this action to occur. This should normally be speci- fied. SMM:08-32 Sendmail Installation and Operation Guide redirects mail for that user to the list of addresses listed in the .forward file. Note that aliases are fully expanded before forward files are referenced. For example, if the home directory for user "mckusick" has a .forward file with contents: mckusick@ernie kirk@calder then any mail arriving for "mckusick" will be redi- rected to the specified accounts. Actually, the configuration file defines a sequence of filenames to check. By default, this is the user's .forward file, but can be defined to be more generally using the ForwardPath option. If you change this, you will have to inform your user base of the change; .forward is pretty well incorporated into the collective subconscious. 2.9. Special Header Lines Several header lines have special interpretations defined by the configuration file. Others have inter- pretations built into sendmail that cannot be changed without changing the code. These built-ins are described here. 2.9.1. Errors-To: If errors occur anywhere during processing, this header will cause error messages to go to the listed addresses. This is intended for mailing lists. The Errors-To: header was created in the bad old days when UUCP didn't understand the distinc- tion between an envelope and a header; this was a hack to provide what should now be passed as the envelope sender address. It should go away. It is only used if the UseErrorsTo option is set. The Errors-To: header is officially deprecated and will go away in a future release. 2.9.2. Apparently-To: RFC 822 requires at least one recipient field (To:, Cc:, or Bcc: line) in every message. If a message comes in with no recipients listed in the message then sendmail will adjust the header based on the "NoRecipientAction" option. One of the pos- sible actions is to add an "Apparently-To:" header Sendmail Installation and Operation Guide SMM:08-33 line for any recipients it is aware of. The Apparently-To: header is non-standard and is both deprecated and strongly discouraged. 2.9.3. Precedence The Precedence: header can be used as a crude control of message priority. It tweaks the sort order in the queue and can be configured to change the message timeout values. The precedence of a message also controls how delivery status notifica- tions (DSNs) are processed for that message. 2.10. IDENT Protocol Support Sendmail supports the IDENT protocol as defined in RFC 1413. Note that the RFC states a client should wait at least 30 seconds for a response. The default Timeout.ident is 5 seconds as many sites have adopted the practice of dropping IDENT queries. This has lead to delays processing mail. Although this enhances identification of the author of an email message by doing a ``call back'' to the originating system to include the owner of a particular TCP connection in the audit trail it is in no sense perfect; a deter- mined forger can easily spoof 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 exam- ple, 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 mislead- ing. The Identification Protocol is not intended as an authorization or access control protocol. At best, it provides some additional auditing infor- mation with respect to TCP connections. At worst, it can provide misleading, incorrect, or maliciously incorrect information. The use of the information returned by this pro- tocol for other than auditing is strongly dis- couraged. Specifically, using Identification Protocol information to make access control deci- sions - either as the primary method (i.e., no SMM:08-34 Sendmail Installation and Operation Guide other checks) or as an adjunct to other methods may result in a weakening of normal host secu- rity. An Identification server may reveal information about users, entities, objects or processes which might normally be considered private. An Identi- fication server provides service which is a rough analog of the CallerID services provided by some phone companies and many of the same privacy con- siderations and arguments that apply to the Cal- lerID service apply to Identification. If you wouldn't run a "finger" server due to privacy considerations you may not want to run this pro- tocol. In some cases your system may not work properly with IDENT support due to a bug in the TCP/IP implementa- tion. The symptoms will be that for some hosts the SMTP connection will be closed almost immediately. If this is true or if you do not want to use IDENT, you should set the IDENT timeout to zero; this will dis- able the IDENT protocol. 3. ARGUMENTS The complete list of arguments to sendmail is described in detail in Appendix A. Some important argu- ments are described here. 3.1. Queue Interval The amount of time between forking a process to run through the queue is defined by the -q flag. If you run with delivery mode set to i or b this can be relatively large, since it will only be relevant when a host that was down comes back up. If you run in q mode it should be relatively short, since it defines the maximum amount of time that a message may sit in the queue. (See also the MinQueueAge option.) RFC 1123 section 5.3.1.1 says that this value should be at least 30 minutes (although that probably doesn't make sense if you use ``queue-only'' mode). Notice: the meaning of the interval time depends on whether normal queue runners or persistent queue runners are used. For the former, it is the time between subsequent starts of a queue run. For the latter, it is the time sendmail waits after a persis- tent queue runner has finished its work to start the next one. Hence for persistent queue runners this interval should be very low, typically no more than Sendmail Installation and Operation Guide SMM:08-35 two minutes. 3.2. Daemon Mode If you allow incoming mail over an IPC connec- tion, you should have a daemon running. This should be set by your /etc/rc file using the -bd flag. The -bd flag and the -q flag may be combined in one call: /usr/sbin/sendmail -bd -q30m An alternative approach is to invoke sendmail from inetd(8) (use the -bs -Am flags to ask sendmail to speak SMTP on its standard input and output and to run as MTA). This works and allows you to wrap send- mail in a TCP wrapper program, but may be a bit slower since the configuration file has to be re-read on every message that comes in. If you do this, you still need to have a sendmail running to flush the queue: /usr/sbin/sendmail -q30m 3.3. Forcing the Queue In some cases you may find that the queue has gotten clogged for some reason. You can force a queue run using the -q flag (with no value). It is enter- taining to use the -v flag (verbose) when this is done to watch what happens: /usr/sbin/sendmail -q -v You can also limit the jobs to those with a par- ticular queue identifier, recipient, sender, quaran- tine reason, or queue group using one of the queue modifiers. For example, "-qRberkeley" restricts the queue run to jobs that have the string "berkeley" somewhere in one of the recipient addresses. Simi- larly, "-qSstring" limits the run to particular senders, "-qIstring" limits it to particular queue identifiers, and "-qQstring" limits it to particular quarantined reasons and only operated on quarantined queue items, and "-qGstring" limits it to a particular queue group. The named queue group will be run even if it is set to have 0 runners. You may also place an ! before the I or R or S or Q to indicate that jobs are limited to not including a particular queue iden- tifier, recipient or sender. For example, "-q!Rseat- tle" limits the queue run to jobs that do not have the SMM:08-36 Sendmail Installation and Operation Guide string "seattle" somewhere in one of the recipient addresses. Should you need to terminate the queue jobs currently active then a SIGTERM to the parent of the process (or processes) will cleanly stop the jobs. 3.4. Debugging There are a fairly large number of debug flags built into sendmail. Each debug flag has a category and a level. Higher levels increase the level of debugging activity; in most cases, this means to print out more information. The convention is that levels greater than nine are "absurd," i.e., they print out so much information that you wouldn't normally want to see them except for debugging that particular piece of code. You should never run a production sendmail server in debug mode. Many of the debug flags will result in debug output being sent over the SMTP channel unless the option -D is used. This will confuse many mail programs. However, for testing purposes, it can be useful when sending mail manually via telnet to the port you are using while debugging. A debug category is either an integer, like 42, or a name, like ANSI. You can specify a range of numeric debug categories using the syntax 17-42. You can specify a set of named debug categories using a glob pattern like "sm_trace_*". At present, only "*" and "?" are supported in these glob patterns. Debug flags are set using the -d option; the syn- tax is: debug-flag: -d debug-list debug-list: debug-option [ , debug-option ]* debug-option: debug-categories [ . debug-level ] debug-categories: integer | integer - integer | category-pattern category-pattern: [a-zA-Z_*?][a-zA-Z0-9_*?]* debug-level: integer where spaces are for reading ease only. For example, -d12 Set category 12 to level 1 -d12.3 Set category 12 to level 3 -d3-17 Set categories 3 through 17 to level 1 -d3-17.4 Set categories 3 through 17 to level 4 -dANSI Set category ANSI to level 1 -dsm_trace_*.3 Set all named categories matching sm_trace_* to level 3 For a complete list of the available debug flags you will have to look at the code and the TRACEFLAGS file Sendmail Installation and Operation Guide SMM:08-37 in the sendmail distribution (they are too dynamic to keep this document up to date). For a list of named debug categories in the sendmail binary, use ident /usr/sbin/sendmail | grep Debug 3.5. Changing the Values of Options Options can be overridden using the -o or -O com- mand line flags. For example, /usr/sbin/sendmail -oT2m sets the T (timeout) option to two minutes for this run only; the equivalent line using the long option name is /usr/sbin/sendmail -OTimeout.queuereturn=2m Some options have security implications. Send- mail allows you to set these, but relinquishes its set-user-ID or set-group-ID permissions there- after[12]. 3.6. Trying a Different Configuration File An alternative configuration file can be speci- fied using the -C flag; for example, /usr/sbin/sendmail -Ctest.cf -oQ/tmp/mqueue uses the configuration file test.cf instead of the default /etc/mail/sendmail.cf. If the -C flag has no value it defaults to sendmail.cf in the current direc- tory. Sendmail gives up set-user-ID root permissions (if it has been installed set-user-ID root) when you use this flag, so it is common to use a publicly writable directory (such as /tmp) as the queue direc- tory (QueueDirectory or Q option) while testing. ____________________ [12]That is, it sets its effective uid to the real uid; thus, if you are executing as root, as from root's crontab file or during system startup the root permissions will still be honored. SMM:08-38 Sendmail Installation and Operation Guide 3.7. Logging Traffic Many SMTP implementations do not fully implement the protocol. For example, some personal computer based SMTPs do not understand continuation lines in reply codes. These can be very hard to trace. If you suspect such a problem, you can set traffic logging using the -X flag. For example, /usr/sbin/sendmail -X /tmp/traffic -bd will log all traffic in the file /tmp/traffic. This logs a lot of data very quickly and should NEVER be used during normal operations. After start- ing up such a daemon, force the errant implementation to send a message to your host. All message traffic in and out of sendmail, including the incoming SMTP traffic, will be logged in this file. 3.8. Testing Configuration Files When you build a configuration table, you can do a certain amount of testing using the "test mode" of sendmail. For example, you could invoke sendmail as: sendmail -bt -Ctest.cf which would read the configuration file "test.cf" and enter test mode. In this mode, you enter lines of the form: rwset address where rwset is the rewriting set you want to use and address is an address to apply the set to. Test mode shows you the steps it takes as it proceeds, finally showing you the address it ends up with. You may use a comma separated list of rwsets for sequential appli- cation of rules to an input. For example: 3,1,21,4 monet:bollard first applies ruleset three to the input "monet:bol- lard." Ruleset one is then applied to the output of ruleset three, followed similarly by rulesets twenty- one and four. If you need more detail, you can also use the "-d21" flag to turn on more debugging. For example, sendmail -bt -d21.99 Sendmail Installation and Operation Guide SMM:08-39 turns on an incredible amount of information; a single word address is probably going to print out several pages worth of information. You should be warned that internally, sendmail applies ruleset 3 to all addresses. In test mode you will have to do that manually. For example, older versions allowed you to use 0 bruce@broadcast.sony.com This version requires that you use: 3,0 bruce@broadcast.sony.com As of version 8.7, some other syntaxes are avail- able in test mode: .Dxvalue defines macro x to have the indicated value. This is useful when debugging rules that use the $&x syntax. .Ccvalue adds the indicated value to class c. =Sruleset dumps the contents of the indicated ruleset. -ddebug-spec is equivalent to the command-line flag. Version 8.9 introduced more features: ? shows a help message. =M display the known mailers. $m print the value of macro m. $=c print the contents of class c. /mx host returns the MX records for `host'. /parse address parse address, returning the value of crack- addr, and the parsed address. /try mailer addr rewrite address into the form it will have when presented to the indicated mailer. /tryflags flags set flags used by parsing. The flags can be `H' for Header or `E' for Envelope, and `S' SMM:08-40 Sendmail Installation and Operation Guide for Sender or `R' for Recipient. These can be combined, `HR' sets flags for header recipients. /canon hostname try to canonify hostname. /map mapname key look up `key' in the indicated `mapname'. /quit quit address test mode. 3.9. Persistent Host Status Information When HostStatusDirectory is enabled, information about the status of hosts is maintained on disk and can thus be shared between different instantiations of sendmail. The status of the last connection with each remote host may be viewed with the command: sendmail -bh This information may be flushed with the command: sendmail -bH Flushing the information prevents new sendmail pro- cesses from loading it, but does not prevent existing processes from using the status information that they already have. 4. 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 the con- figuration file. 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 versions of sendmail prior to 8.7 had single character option names. As of 8.7, options have long (multi-character names). Although old short names are still accepted, most new options do not have short equiv- alents. Sendmail Installation and Operation Guide SMM:08-41 This section only describes the options you are most likely to want to tweak; read section 5 for more details. 4.1. 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 4.1.1. Queue interval The argument to the -q flag specifies how often a sub-daemon will run the queue. This is typically set to between fifteen minutes and one hour. If not set, or set to zero, the queue will not be run automatically. RFC 1123 section 5.3.1.1 recommends that this be at least 30 minutes. Should you need to terminate the queue jobs cur- rently active then a SIGTERM to the parent of the process (or processes) will cleanly stop the jobs. 4.1.2. Read timeouts Timeouts all have option names "Timeout.subop- tion". Most of these control SMTP operations. The recognized suboptions, their default values, and the minimum values allowed by RFC 2821 section 4.5.3.2 (or RFC 1123 section 5.3.2) are: connect The time to wait for an SMTP connection to open (the connect(2) system call) [0, unspecified]. If zero, uses the kernel default. In no case can this option extend the timeout longer than the kernel provides, but it can shorten it. This is to get around kernels that provide an absurdly long connection timeout (90 min- utes in one case). iconnect The same as connect, except it applies only to the initial attempt to connect to a host for a given message [0, unspeci- fied]. The concept is that this should be very short (a few seconds); hosts that are well connected and responsive will SMM:08-42 Sendmail Installation and Operation Guide thus be serviced immediately. Hosts that are slow will not hold up other deliver- ies in the initial delivery attempt. aconnect [0, unspecified] The overall timeout waiting for all connection for a single delivery attempt to succeed. If 0, no overall limit is applied. This can be used to restrict the total amount of time trying to connect to a long list of host that could accept an e-mail for the recipient. This timeout does not apply to FallbackMXhost, i.e., if the time is exhausted, the FallbackMXhost is tried next. initial The wait for the initial 220 greeting message [5m, 5m]. helo The wait for a reply from a HELO or EHLO command [5m, unspecified]. This may require a host name lookup, so five min- utes is probably a reasonable minimum. mail* The wait for a reply from a MAIL command [10m, 5m]. rcpt* The wait for a reply from a RCPT command [1h, 5m]. This should be long because it could be pointing at a list that takes a long time to expand (see below). datainit* The wait for a reply from a DATA command [5m, 2m]. datablock*# The wait for reading a data block (that is, the body of the message). [1h, 3m]. This should be long because it also applies to programs piping input to send- mail which have no guarantee of prompt- ness. datafinal* The wait for a reply from the dot termi- nating a message. [1h, 10m]. If this is shorter than the time actually needed for the receiver to deliver the message, duplicates will be generated. This is discussed in RFC 1047. rset The wait for a reply from a RSET command [5m, unspecified]. Sendmail Installation and Operation Guide SMM:08-43 quit The wait for a reply from a QUIT command [2m, unspecified]. misc The wait for a reply from miscellaneous (but short) commands such as NOOP (no- operation) and VERB (go into verbose mode). [2m, unspecified]. command*# In server SMTP, the time to wait for another command. [1h, 5m]. ident# The timeout waiting for a reply to an IDENT query [5s[13], unspecified]. lhlo The wait for a reply to an LMTP LHLO com- mand [2m, unspecified]. auth The timeout for a reply in an SMTP AUTH dialogue [10m, unspecified]. starttls The timeout for a reply to an SMTP START- TLS command and the TLS handshake [1h, unspecified]. fileopen# The timeout for opening .forward and :include: files [60s, none]. control# The timeout for a complete control socket transaction to complete [2m, none]. hoststatus# How long status information about a host (e.g., host down) will be cached before it is considered stale [30m, unspeci- fied]. resolver.retrans# The resolver's retransmission time inter- val (in seconds) [varies]. Sets both Timeout.resolver.retrans.first and Time- out.resolver.retrans.normal. resolver.retrans.first# The resolver's retransmission time inter- val (in seconds) for the first attempt to deliver a message [varies]. ____________________ [13]On some systems the default is zero to turn the pro- tocol off entirely. SMM:08-44 Sendmail Installation and Operation Guide resolver.retrans.normal# The resolver's retransmission time inter- val (in seconds) for all resolver lookups except the first delivery attempt [varies]. resolver.retry# The number of times to retransmit a resolver query. Sets both Time- out.resolver.retry.first and Time- out.resolver.retry.normal [varies]. resolver.retry.first# The number of times to retransmit a resolver query for the first attempt to deliver a message [varies]. resolver.retry.normal# The number of times to retransmit a resolver query for all resolver lookups except the first delivery attempt [varies]. For compatibility with old configuration files, if no suboption is specified, all the timeouts marked with an asterick (*) are set to the indicated value. All but those marked with a pound sign (#) apply to client SMTP. For example, the lines: O Timeout.command=25m O Timeout.datablock=3h sets the server SMTP command timeout to 25 minutes and the input data block timeout to three hours. 4.1.3. Message timeouts After sitting in the queue for a few days, an undeliverable message will time out. This is to insure that at least the sender is aware of the inability to send a message. The timeout is typi- cally 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 wouldn't want to do this because it wouldn't 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). Sendmail Installation and Operation Guide SMM:08-45 If the message is submitted using the NOTIFY SMTP extension, warning messages will only be sent if NOTIFY=DELAY is specified. The queuereturn and queuewarn timeouts can be further qualified with a tag based on the Precedence: field in the message; they must be one of "urgent" (indicating a positive non-zero precedence), "normal" (indicating a zero precedence), or "non-urgent" (indicating negative precedences). For example, setting "Timeout.queue- warn.urgent=1h" sets the warning timeout for urgent messages only to one hour. The default if no precedence is indicated is to set the timeout for all precedences. If the message has a normal (default) precedence and it is a delivery status notification (DSN), Timeout.queuereturn.dsn and Timeout.queuewarn.dsn can be used to give an alter- native warn and return time for DSNs. The value "now" can be used for -O Timeout.queuereturn to return entries immediately during a queue run, e.g., to bounce messages independent of their time in the queue. Since these options are global, and since you cannot know a priori how long another host outside your domain will be down, a five day timeout 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 email 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. 4.2. Forking During Queue Runs By setting the ForkEachJob (Y) option, sendmail will fork before each individual message while running the queue. This option was used with earlier releases to prevent sendmail from consuming large amounts of memory. It should no longer be necessary with send- mail 8.12. If the ForkEachJob option is not set, sendmail will keep track of hosts that are down during a queue run, which can improve performance dramati- cally. SMM:08-46 Sendmail Installation and Operation Guide If the ForkEachJob option is set, sendmail cannot use connection caching. 4.3. 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 deter- mined 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 mes- sages 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. Since 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-(classxClassFactor)+(nrcptxRecipientFactor) (Remember, higher values for this parameter actually mean that the job will be treated with lower prior- ity.) 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. 4.4. 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 Sendmail Installation and Operation Guide SMM:08-47 divided by the difference in the current load average and the QueueLA option plus one is less than the pri- ority of the message -- that is, the message is queued iff: pri>LQueueFactor_ 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, i.e., mail which is not submitted via SMTP (including incoming UUCP mail), is still accepted. Notice that the MSP submits mail to the MTA via SMTP, and hence mail will be queued in the client queue in such a case. Therefore it is necessary to run the client mail queue periodically. 4.5. Resource Limits Sendmail has several parameters to control resource usage. Besides those mentionted in the pre- vious section, there are at least MaxDaemonChildren, ConnectionRateThrottle, MaxQueueChildren, and MaxRun- nersPerQueue. The latter two limit the number of sendmail processes that operate on the queue. These are discussed in the section ``Queue Group Declara- tion''. The former two can be used to limit the num- ber of incoming connections. Their appropriate values depend on the host operating system and the hardware, e.g., amount of memory. In many situations it might be useful to set limits to prevent to have too many sendmail processes, however, these limits can be abused to mount a denial of service attack. For exam- ple, if MaxDaemonChildren=10 then an attacker needs to open only 10 SMTP sessions to the server, leave them idle for most of the time, and no more connections will be accepted. If this option is set then the timeouts used in a SMTP session should be lowered from their default values to their minimum values as speci- fied in RFC 2821 and listed in section 4.1.2. 4.6. Measures against Denial of Service Attacks Sendmail has some built-in measures against sim- ple denial of service (DoS) attacks. The SMTP server by default slows down if too many bad commands are issued or if some commands are repeated too often within a session. Details can be found in the source file sendmail/srvrsmtp.c by looking for the macro SMM:08-48 Sendmail Installation and Operation Guide definitions of MAXBADCOMMANDS, MAXNOOPCOMMANDS, MAXHE- LOCOMMANDS, MAXVRFYCOMMANDS, and MAXETRNCOMMANDS. If an SMTP command is issued more often than the corre- sponding MAXcmdCOMMANDS value, then the response is delayed exponentially, starting with a sleep time of one second, up to a maximum of four minutes (as defined by MAXTIMEOUT). If the option MaxDaemonChil- dren is set to a value greater than zero, then this could make a DoS attack even worse since it keeps a connection open longer than necessary. Therefore a connection is terminated with a 421 SMTP reply code if the number of commands exceeds the limit by a factor of two and MAXBADCOMMANDS is set to a value greater than zero (the default is 25). 4.7. Delivery Mode There are a number of delivery modes that send- mail can operate in, set by the DeliveryMode (d) con- figuration option. These modes specify how quickly mail will be delivered. Legal modes are: i deliver interactively (synchronously) b deliver in background (asynchronously) q queue only (don't deliver) d defer delivery attempts (don't deliver) There are tradeoffs. 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 lookups in maps including the -D flag from working during the initial queue phase; it is intended for ``dial on demand'' sites where DNS lookups might cost real money. Some simple error mes- sages (e.g., host unknown during the SMTP protocol) will be delayed using this mode. Mode "b" is the usual 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" should not be used by the SMTP server. Sendmail Installation and Operation Guide SMM:08-49 4.8. 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: 0 Minimal logging. 1 Serious system failures and potential security problems. 2 Lost communications (network problems) and proto- col failures. 3 Other serious failures, malformed addresses, transient forward/include errors, connection timeouts. 4 Minor failures, out of date alias databases, con- nection rejections via check_ rulesets. 5 Message collection statistics. 6 Creation of error messages, VRFY and EXPN com- mands. 7 Delivery failures (host or user unknown, etc.). 8 Successful deliveries and alias database rebuilds. 9 Messages being deferred (due to a host being down, etc.). 10 Database expansion (alias, forward, and userdb lookups) and authentication information. 11 NIS errors and end of job processing. 12 Logs all SMTP connections. 13 Log bad user shells, files with improper permis- sions, and other questionable situations. 14 Logs refused connections. 15 Log all incoming and outgoing SMTP commands. 20 Logs attempts to run locked queue files. These are not errors, but can be useful to note if your queue appears to be clogged. SMM:08-50 Sendmail Installation and Operation Guide 30 Lost locks (only if using lockf instead of flock). Additionally, values above 64 are reserved for extremely verbose debugging output. No normal site would ever set these. 4.9. File Modes The modes used for files depend on what function- ality you want and the level of security you require. In many cases sendmail does careful checking of the modes of files and directories to avoid accidental compromise; if you want to make it possible to have group-writable support files you may need to use the DontBlameSendmail option to turn off some of these checks. 4.9.1. To suid or not to suid? Sendmail is no longer installed set-user-ID to root. sendmail/SECURITY explains how to configure and install sendmail without set-user-ID to root but set-group-ID which is the default configuration starting with 8.12. The daemon usually runs as root, unless other measures are taken. At the point where sendmail is about to exec(2) a mailer, it checks to see if the userid is zero (root); if so, it resets the userid and groupid to a default (set by the U= equate in the mailer line; if that is not set, the Default- User option is used). This can be overridden by setting the S flag to the mailer for mailers that are trusted and must be called as root. However, this will cause mail processing to be accounted (using sa(8)) to root rather than to the user send- ing the mail. A middle ground is to set the RunAsUser option. This causes sendmail to become the indi- cated user as soon as it has done the startup that requires root privileges (primarily, opening the SMTP socket). If you use RunAsUser, the queue directory (normally /var/spool/mqueue) should be owned by that user, and all files and databases (including user .forward files, alias files, :include: files, and external databases) must be readable by that user. Also, since sendmail will not be able to change its uid, delivery to programs or files will be marked as unsafe, e.g., undeliver- able, in .forward, aliases, and :include: files. Administrators can override this by setting the Sendmail Installation and Operation Guide SMM:08-51 DontBlameSendmail option to the setting NonRoot- SafeAddr. RunAsUser is probably best suited for firewall configurations that don't have regular user logins. If the option is used on a system which performs local delivery, then the local delivery agent must have the proper permissions (i.e., usually set-user-ID root) since it will be invoked by the RunAsUser, not by root. 4.9.2. Turning off security checks Sendmail is very particular about the modes of files that it reads or writes. For example, by default it will refuse to read most files that are group writable on the grounds that they might have been tampered with by someone other than the owner; it will even refuse to read files in group writable directories. Also, sendmail will refuse to create a new aliases database in an unsafe directory. You can get around this by manually creating the data- base file as a trusted user ahead of time and then rebuilding the aliases database with newaliases. If you are quite sure that your configuration is safe and you want sendmail to avoid these secu- rity checks, you can turn off certain checks using the DontBlameSendmail option. This option takes one or more names that disable checks. In the descriptions that follow, "unsafe directory" means a directory that is writable by anyone other than the owner. The values are: Safe No special handling. AssumeSafeChown Assume that the chown system call is restricted to root. Since some versions of UNIX permit regular users to give away their files to other users on some filesystems, sendmail often cannot assume that a given file was created by the owner, particularly when it is in a writable directory. You can set this flag if you know that file giveaway is restricted on your system. ClassFileInUnsafeDirPath When reading class files (using the F line in the configuration file), allow files that are in unsafe directories. DontWarnForwardFileInUnsafeDirPath Prevent logging of unsafe directory path warn- ings for non-existent forward files. SMM:08-52 Sendmail Installation and Operation Guide ErrorHeaderInUnsafeDirPath Allow the file named in the ErrorHeader option to be in an unsafe directory. FileDeliveryToHardLink Allow delivery to files that are hard links. FileDeliveryToSymLink Allow delivery to files that are symbolic links. ForwardFileInGroupWritableDirPath Allow .forward files in group writable direc- tories. ForwardFileInUnsafeDirPath Allow .forward files in unsafe directories. ForwardFileInUnsafeDirPathSafe Allow a .forward file that is in an unsafe directory to include references to program and files. GroupReadableKeyFile Accept a group-readable key file for STARTTLS. GroupReadableSASLDBFile Accept a group-readable Cyrus SASL password file. GroupWritableAliasFile Allow group-writable alias files. GroupWritableDirPathSafe Change the definition of "unsafe directory" to consider group-writable directories to be safe. World-writable directories are always unsafe. GroupWritableForwardFile Allow group writable .forward files. GroupWritableForwardFileSafe Accept group-writable .forward files as safe for program and file delivery. GroupWritableIncludeFile Allow group wriable :include: files. GroupWritableIncludeFileSafe Accept group-writable :include: files as safe for program and file delivery. Sendmail Installation and Operation Guide SMM:08-53 GroupWritableSASLDBFile Accept a group-writable Cyrus SASL password file. HelpFileInUnsafeDirPath Allow the file named in the HelpFile option to be in an unsafe directory. IncludeFileInGroupWritableDirPath Allow :include: files in group writable direc- tories. IncludeFileInUnsafeDirPath Allow :include: files in unsafe directories. IncludeFileInUnsafeDirPathSafe Allow a :include: file that is in an unsafe directory to include references to program and files. InsufficientEntropy Try to use STARTTLS even if the PRNG for OpenSSL is not properly seeded despite the security problems. LinkedAliasFileInWritableDir Allow an alias file that is a link in a writable directory. LinkedClassFileInWritableDir Allow class files that are links in writable directories. LinkedForwardFileInWritableDir Allow .forward files that are links in writable directories. LinkedIncludeFileInWritableDir Allow :include: files that are links in writable directories. LinkedMapInWritableDir Allow map files that are links in writable directories. This includes alias database files. LinkedServiceSwitchFileInWritableDir Allow the service switch file to be a link even if the directory is writable. MapInUnsafeDirPath Allow maps (e.g., hash, btree, and dbm files) in unsafe directories. This includes alias SMM:08-54 Sendmail Installation and Operation Guide database files. NonRootSafeAddr Do not mark file and program deliveries as unsafe if sendmail is not running with root privileges. RunProgramInUnsafeDirPath Run programs that are in writable directories without logging a warning. RunWritableProgram Run programs that are group- or world-writable without logging a warning. TrustStickyBit Allow group or world writable directories if the sticky bit is set on the directory. Do not set this on systems which do not honor the sticky bit on directories. WorldWritableAliasFile Accept world-writable alias files. WorldWritableForwardfile Allow world writable .forward files. WorldWritableIncludefile Allow world wriable :include: files. WriteMapToHardLink Allow writes to maps that are hard links. WriteMapToSymLink Allow writes to maps that are symbolic links. WriteStatsToHardLink Allow the status file to be a hard link. WriteStatsToSymLink Allow the status file to be a symbolic link. 4.10. 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 and LPC 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, Sendmail Installation and Operation Guide SMM:08-55 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. 4.11. Name Server Access Control of host address lookups is set by the hosts service entry in your service switch file. If you are on a system that has built-in service switch support (e.g., Ultrix, Solaris, or DEC OSF/1) then your system is probably configured properly already. Otherwise, sendmail will consult the file /etc/mail/service.switch, which should be created. Sendmail only uses two entries: hosts and aliases, although system routines may use other services (notably the passwd service for user name lookups by getpwname). However, some systems (such as SunOS 4.X) will do DNS lookups regardless of the setting of the service switch entry. In particular, the system routine geth- ostbyname(3) is used to look up host names, and many vendor versions try some combination of DNS, NIS, and file lookup in /etc/hosts without consulting a service switch. Sendmail makes no attempt to work around this problem, and the DNS lookup will be done anyway. If you do not have a nameserver configured at all, such as at a UUCP-only site, sendmail will get a "connec- tion refused" message when it tries to connect to the name server. If the hosts switch entry has the ser- vice "dns" listed somewhere in the list, sendmail will interpret this to mean a temporary failure and will queue the mail for later processing; otherwise, it ignores the name server data. The same technique is used to decide whether to do MX lookups. If you want MX support, you must have SMM:08-56 Sendmail Installation and Operation Guide "dns" listed as a service in the hosts switch entry. The ResolverOptions (I) option allows you to tweak name server options. The command line takes a series of flags as documented in resolver(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. If NETINET6 is enabled, most libraries default to USE_INET6 as well. You can also include "HasWild- cardMX" to specify that there is a wildcard MX record matching your domain; this turns off MX matching when canonifying names, which can lead to inappropriate canonifications. Use "WorkAroundBrokenAAAA" when faced with a broken nameserver that returns SERVFAIL (a temporary failure) on T_AAAA (IPv6) lookups during hostname canonification. Notice: it might be neces- sary to apply the same (or similar) options to sub- mit.cf too. Version level 1 configurations (see the section about ``Configuration Version Level'') turn DNSRCH and DEFNAMES off when doing delivery lookups, but leave them on everywhere else. Version 8 of sendmail ignores them when doing canonification lookups (that is, when using $[ ... $]), and always does the search. If you don't want to do automatic name extension, don't call $[ ... $]. The search rules for $[ ... $] are somewhat dif- ferent than usual. If the name being looked up has at least one dot, it always tries the unmodified name first. If that fails, it tries the reduced search path, and lastly tries the unmodified name (but only for names without a dot, since names with a dot have already been tried). This allows names such as ``utc.CS'' to match the site in Czechoslovakia rather than the site in your local Computer Science depart- ment. It also prefers A and CNAME records over MX records -- that is, if it finds an MX record it makes note of it, but keeps looking. This way, if you have a wildcard MX record matching your domain, it will not assume that all names match. To completely turn off all name server access on systems without service switch support (such as SunOS 4.X) you will have to recompile with -DNAMED_BIND=0 Sendmail Installation and Operation Guide SMM:08-57 and remove -lresolv from the list of libraries to be searched when linking. 4.12. 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 from a central mail server 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. A truly per- verse site could also search by sender by using $r, $s, or $f. 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 0644. Note that you must use the ForwardFileInUnsafeDirPath and ForwardFileInUnsafeDirPathSafe flags with the DontBlameSendmail option to allow forward files in a world writable directory. This might also be used as a denial of service attack (users could create forward files for other users); a better approach might be to create /var/forward mode 0755 and create empty files for each user, owned by that user, mode 0644. If you do this, you don't have to set the DontBlameSendmail options indicated above. 4.13. 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 filesystem 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. SMM:08-58 Sendmail Installation and Operation Guide Beware of setting this option too high; it can cause rejection of email when that mail would be pro- cessed without difficulty. 4.14. Maximum Message Size To avoid overflowing your system with a large message, the MaxMessageSize option can be set to set an absolute limit on the size of any one message. This will be advertised in the ESMTP dialogue and checked during message collection. 4.15. Privacy Flags The PrivacyOptions (p) option allows you to set certain ``privacy'' flags. Actually, many of them don't give you any extra privacy, rather just insist- ing that client SMTP servers use the HELO command before using certain commands or adding extra headers to indicate possible spoof attempts. 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 com- mand. The flags are detailed in section 5.6. 4.16. Send to Me Too Beginning with version 8.10, sendmail includes by default the (envelope) sender in any list expansions. For example, if "matt" sends to a list that contains "matt" as one of the members he will get a copy of the message. If the MeToo option is set to FALSE (in the configuration file or via the command line), this behavior is changed, i.e., the (envelope) sender is excluded in list expansions. 5. THE WHOLE SCOOP ON THE CONFIGURATION FILE This section describes the configuration file in detail. There is one point that should be made clear immedi- ately: the syntax of the configuration file is designed to be reasonably easy to parse, since this is done every time sendmail starts up, rather than easy for a human to Sendmail Installation and Operation Guide SMM:08-59 read or write. The configuration file should be gener- ated via the method described in cf/README, it should not be edited directly unless someone is familiar with the internals of the syntax described here and it is not pos- sible to achieve the desired result via the default method. The configuration file is organized as a series of lines, each of which begins with a single character defining the semantics for the rest of the line. Lines beginning with a space or a tab are continuation lines (although the semantics are not well defined in many places). Blank lines and lines beginning with a sharp symbol (`#') are comments. 5.1. R and S -- Rewriting Rules The core of address parsing are the rewriting rules. These are an ordered production system. Send- mail scans through the set of rewriting 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. There are several sets of rewriting rules. Some of the rewriting sets are used internally and must have specific semantics. Other rewriting sets do not have specifically assigned semantics, and may be ref- erenced by the mailer definitions or by other rewrit- ing sets. The syntax of these two commands are: Sn Sets the current ruleset being collected to n. If you begin a ruleset more than once it appends to the old definition. Rlhs rhs comments The fields must be separated by at least one tab char- acter; there may be embedded spaces in the fields. The lhs is a pattern that is applied to the input. If it matches, the input is rewritten to the rhs. The comments are ignored. Macro expansions of the form $x are performed when the configuration file is read. A literal $ can be included using $$. Expansions of the form $&x are performed at run time using a somewhat less general algorithm. This is intended only for referencing internally defined macros such as $h that are changed SMM:08-60 Sendmail Installation and Operation Guide at runtime. 5.1.1. The left hand side The left hand side of rewriting rules contains a pattern. Normal words are simply matched directly. Metasyntax is introduced using a dollar sign. The metasymbols are: $* Match zero or more tokens $+ Match one or more tokens $- Match exactly one token $=x Match any phrase in class x $~x Match any word not in class x 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:eric the rule will match, and the values passed to the RHS will be: $1 UCBARPA $2 eric Additionally, the LHS can include $@ to match zero tokens. This is not bound to a $n on the RHS, and is normally only used when it stands alone in order to match the null input. 5.1.2. The right hand side When the left hand side of a rewriting 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: Sendmail Installation and Operation Guide SMM:08-61 $n Substitute indefinite token n from LHS $[name$] Canonicalize name $(map key $@arguments $:default $) Generalized keyed mapping function $>n "Call" ruleset n $#mailer Resolve to mailer $@host Specify host $:user Specify user 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[14]. For example, "$[ftp$]" might become "ftp.CS.Berkeley.EDU" and "$[[128.32.130.2]$]" would become "van- gogh.CS.Berkeley.EDU." Sendmail recognizes its numeric IP address without calling the name server and replaces it with its canonical name. 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 expands everything after the ruleset name to the end of the replacement string and then passes that as the initial input to the ruleset. Recursive calls are allowed. For exam- ple, $>0 $>3 $1 expands $1, passes that to ruleset 3, and then passes the result of ruleset 3 to ruleset 0. The $# syntax should only be used in ruleset zero, a subroutine of ruleset zero, or rulesets ____________________ [14]This is actually completely equivalent to $(host hostname$). In particular, a $: default can be used. SMM:08-62 Sendmail Installation and Operation Guide that return decisions (e.g., check_rcpt). It causes evaluation of the ruleset to terminate imme- diately, and signals to sendmail that the address has completely resolved. The complete syntax for ruleset 0 is: $#mailer $@host $:user This specifies the {mailer, host, user} 3-tuple necessary to direct the mailer. Note: the third element ( user ) is often also called address part. If the mailer is local t