SENDMAIL^TM

INSTALLATION AND OPERATION GUIDE

Eric Allman
Gregory Neil Shapiro
Claus Assmann
Sendmail, Inc.

Version 1.21

For Sendmail Version 8.12

Sendmail^TM implements a general purpose internetwork mail routing facility under the UNIXŽ 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 limited 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 unap- proachable. However, there are only a few basic configurations for most sites, for which standard con- figuration files have been supplied. Most other configurations can be built by adjusting an existing config- uration 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 Extension), RFC 1869 (SMTP Service Extensions), RFC 1870 (SMTP SIZE Extension), RFC 1891 (SMTP Delivery Status Notifications), RFC 1892 (Multi- part/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 Protocol), RFC 2034 (SMTP Service Extension for Returning 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 Authentication), 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 send- mail 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 circumstances. These features are described.

Section one describes how to do a basic sendmail installation. Section two explains the day-to-day information 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 contains 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

DISCLAIMER: This documentation is under modification.

Sendmail is a trademark of Sendmail, Inc.

SMM:08-2 Sendmail Installation and Operation Guide

Sendmail Installation and Operation Guide SMM:08-3 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-71. 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 configuration can usually be built using an M4-based configuration language. Assuming you have the standard sendmail distribu- tion, 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 installation parameters are acceptable. All path- names and examples are given from the root of the sendmail subtree, normally /usr/src/usr.sbin/send- mail on 4.4BSD-based systems.

Continue with the next section if you need/want to compile sendmail yourself. If you have a run- ning binary already on your system, you should probably skip to section 1.2.

1.1. Compiling Sendmail

All sendmail source is in the sendmail subdirectory. 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 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 $BUILDTOOLS/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
configuration file.

-S Skip auto-configuration. Build will avoid auto-detecting libraries if this is set. All
libraries and map definitions must be specified in the site configuration file.

Most other parameters are passed to the make program; for details see $BUILD-
TOOLS/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.

SMM:08-8 Sendmail Installation and Operation Guide

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, 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 substring ``/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 (formerly 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 sendmail/README.

1.1.4. Compilation and installation

After making the local system configuration described above, You should be able to com-
pile 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 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 deliv-
ery 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 document.

The sendmail configuration can be daunting at first. The world is complex, and the mail con-
figuration 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 lit-
eral host names (e.g., ``ucbvax.mc'') when the hosts are gateways or more

Sendmail Installation and Operation Guide SMM:08-9

general descriptions (such as ``generic-solaris2.mc'' as a general description of
an SMTP-connected host running Solaris 2.x. Files ending .mc (``M4 Configura-
tion'') are the input descriptions; the output is in the corresponding .cf file. The
general structure of these files is described below.

	domain		Site-dependent subdomain descriptions. These are tied to the way your organiza- tion 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. 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 configu- ration 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 loca- tion of support files). These are referenced using the
			OSTYPE m4 macro.
	sh siteconfig		Shell files used by the m4 build process. You shouldn't have to mess with these. Local UUCP connectivity information. This directory has been supplanted by the mailertable 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 Elec-
trical Engineering and 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¹. It should be set-group-ID smmsp as

described in sendmail/SECURITY. For security reasons, /, /usr, and /usr/sbin should be owned

1This 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.

SMM:08-10 Sendmail Installation and Operation Guide

by root, mode 0755².

	1.3.2. /etc/mail/sendmail.cf This is the main configuration file for sendmail³. This is one of the two non-library file
	names compiled into sendmail⁴, 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 configuration you may need to create a special version. 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 Program'' (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 operations sendmail.cf is used. Details can be found in sendmail/SECURITY. submit.cf is shipped with sendmail (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 transaction with all remote hosts. The -v flag will prevent the status display from being truncated. It functions only when the HostStatusDirec- tory option is set. 1.3.6. /usr/bin/purgestat This command is also a link to sendmail. It flushes expired (Timeout.hoststatus) informa- tion that is stored in the HostStatusDirectory tree. 1.3.7. /var/spool/mqueue The directory /var/spool/mqueue should be created 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 ending with an asterisk. For example, /var/spool/mqueue/qd* will use all of the directories or symbolic links to directories beginning with `qd' in /var/spool/mqueue as queue directories. Do not change the queue directory struc-

ture while sendmail is running.

2Some vendors ship them owned by bin; this creates a security hole that is not actually related to sendmail. Other impor- tant directories that should have restrictive ownerships and permissions are /bin, /usr/bin, /etc, /etc/mail, /usr/etc, /lib, and /usr/lib.

3Actually, the pathname varies depending on the operating system; /etc/mail is the preferred directory. Some older sys- tems 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_SENDMAIL- CF=\"/file/name\" to the flags passed to the C compiler. Moving this file is not recommended: other programs and scripts know of this location.

4The system libraries can reference other files; in particular, system library subroutines that sendmail calls probably refer- ence /etc/passwd and /etc/resolv.conf.

Sendmail Installation and Operation Guide SMM:08-11

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, sendmail 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 different queue directories or different queue group declarations. Access to shared mem-
ory is not controlled by locks, i.e., there is a race condition when data in the shared memory is
updated. However, since operation of sendmail does not rely on the data in the shared memory,
this does not negatively 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.

1.3.9. /var/spool/mqueue/.hoststat

This is a typical value for the HostStatusDirectory 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 database 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 dae-
mon performs two functions: it listens on the SMTP socket for connections (to receive mail from
a remote system) 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-12 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

The ``cd'' and ``rm'' commands insure that all transcript files have been removed; extraneous
transcript files may be left around if the system goes down in the middle of processing a mes-
sage. 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 files and df files
for which there is no qf file. 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 ``send-
mail/helpfile'':

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.

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 per-
missions 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

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 permissions accordingly, e.g.,

cd /etc/mail
chmod 0640 *.db *.pag *.dir

2. NORMAL OPERATIONS

Sendmail Installation and Operation Guide SMM:08-13

#!/bin/sh
# remove zero length qf files
for qffile in qf*
do

done

if [ -r $qffile ]
then
if [ ! -s $qffile ]
then
echo -n " <zero: $qffile>" > /dev/console
rm -f $qffile
fi
fi

# 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 " <recovering: $tffile>" > /dev/console mv $tffile $qffile else if [ -f $tffile ] then echo -n " <extra: $tffile>" > /dev/console rm -f $tffile fi fi
done

# remove df files with no corresponding qf files
for dffile in df*

do
		qffile=`echo $dffile \| sed 's/d/q/'` if [ -r $dffile -a ! -f $qffile ] then echo -n " <incomplete: $dffile>" > /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 " <panic: $xffile>" > /dev/console fi
done

Figure 1 -- A complex startup script

2.1. The System Log

SMM:08-14 Sendmail Installation and Operation Guide

The system log is supported by the syslogd (8) program. All messages from sendmail are

logged under the _{LOG_MAIL} facility⁵.

2.1.1. Format

Each line in the system log consists of a timestamp, the name of the machine that gener-
ated it (for logging from several machines over the local area network), the word ``sendmail:'',

and a message⁶. 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 omit-
ted 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 for-
warding).

msgid The message id of the message (from the header).

proto The protocol used to receive this message (e.g., ESMTP or UUCP)

daemon The daemon name from the DaemonPortOptions 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 deliv-
ery 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 delivery 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 levels
under ten are considered generally ``useful;'' log levels above 64 are reserved for debugging

purposes. Levels from 11-64 are reserved for verbose information that some sites might want.

5Except on Ultrix, which does not support facilities in the syslog.

6This format may vary slightly if your vendor has changed the syntax.

Sendmail Installation and Operation Guide SMM:08-15

A complete description of the log levels is given in section 4.7.

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 mes-
sages 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
delivery 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.

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 otherwise specified). The directory or directories which comprise the default queue
group are specified 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 recipi-
ent 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 (maxi-
mum 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 dif-
ferent 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 run-
ner processes around (``persistent'' queue runners). How to select either of these types is

SMM:08-16 Sendmail Installation and Operation Guide

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 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 substan-
tially 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 grace-
fully 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 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 ini-
tiated 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 algorithm, 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. Unfortunately, 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 prohibitively large queue. This will result in sendmail 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 ser-
vice.

To do this, it is acceptable to move the entire queue directory:

Sendmail Installation and Operation Guide SMM:08-17

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 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
directory 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 configuration 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.4. Disk Based Connection Information

Sendmail stores a large amount of information about each remote system it has connected to
in memory. It is possible to preserve some of this information on disk as well, by using the HostSta-
tusDirectory option, so that it may be shared between several invocations of sendmail. This
allows mail to be queued immediately or skipped during a queue run if there has been a recent fail-
ure in connecting to a remote machine.

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 easily 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 Min-
QueueAge 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

.hoststat⁷. Removing this directory and its subdirectories has an effect similar to the purgestat

command and is completely safe. However, purgestat only removes expired (Timeout.hoststatus) data. The information 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

7This is the usual value of the HostStatusDirectory option; it can, of course, go anywhere you like in your filesystem.

SMM:08-18 Sendmail Installation and Operation Guide

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 con- trolled 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⁸.
	If the underlying operating system does not support 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 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 implementation 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) into 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 operation, 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)⁹.
	Aliases may be continued by starting any continuation 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)¹⁰ 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

8HP-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.

9Actually, any mailer that has the `A' mailer flag set will permit aliasing; this is normally limited to the local mailer.

10The gdbm package does not work.

Sendmail Installation and Operation Guide SMM:08-19

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 database, 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; otherwise, 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: 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 com- mand newaliases This is equivalent to giving sendmail the -bi flag: /usr/sbin/sendmail -bi If you have multiple aliases databases specified, 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 interrupts while rebuilding the database; this avoids the problem of someone aborting the process leaving a partially rebuilt database. Second, it locks the database source file during the rebuild -- but that may not work over NFS or if the file is 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

SMM:08-20 Sendmail Installation and Operation Guide

this entry exists¹¹.

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 maintenance 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-wiz-
ards due to the inclusion of ``nosuchuser'' on the list.

List owners also cause the envelope sender address to be modified. The contents of the
owner alias are used if they point to a single user, otherwise the name of the alias itself is used.
For this reason, and to 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 information 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 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 con-
tents:

mckusick@ernie
kirk@calder

then any mail arriving for ``mckusick'' will be redirected 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 incor-
porated into the collective subconscious.

2.9. Special Header Lines

Several header lines have special interpretations defined by the configuration file. Others
have interpretations 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

distinction between an envelope and a header; this was a hack to provide what should now be

11The AliasWait option is required in the configuration for this action to occur. This should normally be specified.

Sendmail Installation and Operation Guide SMM:08-21

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 possible actions is to add an ``Appar-
ently-To:'' header line for any recipients it is aware of.

The Apparently-To: header is non-standard and is both deprecated and strongly discour-
aged.

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 notifications (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 process-
ing 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 determined forger can easily spoof the IDENT protocol. The follow-
ing description is excerpted from RFC 1413:

6. Security Considerations

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

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

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

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

In some cases your system may not work properly with IDENT support due to a bug in the TCP/IP
implementation. 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 disable the IDENT protocol.

SMM:08-22 Sendmail Installation and Operation Guide3. ARGUMENTS

The complete list of arguments to sendmail is described in detail in Appendix A. Some important arguments 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 rele-
vant 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 persis-
tent 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 persistent 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 two minutes.

3.2. Daemon Mode

If you allow incoming mail over an IPC connection, 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 sendmail in a TCP wrapper program, but may be a bit slower since the configu-
ration 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 entertaining 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 particular queue identifier, recipient, sender, 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. Similarly,
``-qSstring'' limits the run to particular senders, ``-qIstring'' limits it to particular queue identifiers,
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 to indicate that jobs are lim-
ited to not including a particular queue identifier, recipient or sender. For example, ``-q!Rseattle''
limits the queue run to jobs that do not have the 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 cate-
gory 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

Sendmail Installation and Operation Guide SMM:08-23

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. This will confuse many mail pro-
grams. 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 cate-
gories 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 syntax 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 TRACE-
FLAGS file 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 command 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. Sendmail allows you to set these, but relinquishes

its set-user-ID or set-group-ID permissions thereafter¹².

3.6. Trying a Different Configuration File

An alternative configuration file can be specified 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 directory.

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

directory (QueueDirectory or Q option) while testing.

12That 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-24 Sendmail Installation and Operation Guide3.7. Logging Traffic

Many SMTP implementations do not fully implement the protocol. For example, some per-
sonal 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 starting 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 application of rules to an input. For
example:

3,1,21,4 monet:bollard

first applies ruleset three to the input ``monet:bollard.'' 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

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 available in test mode:

.D x value defines macro x to have the indicated value. This is useful when debugging rules
that use the $&x syntax.

.C c value adds the indicated value to class c.

=S ruleset dumps the contents of the indicated ruleset.

-d debug-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.

Sendmail Installation and Operation Guide SMM:08-25

$=c print the contents of class c.

	/mx host /parse address /try mailer addr /tryflags flags		returns the MX records for `host'. parse address, returning the value of crackaddr, and the parsed address. rewrite address into the form it will have when presented to the indicated mailer. set flags used by parsing. The flags can be `H' for Header or `E' for Envelope, and `S' 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 con-
nection 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 processes 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 configuration file. For example, the line ``O Timeout.queuereturn=5d'' sets option ``Timeout.queuereturn'' to the value ``5d'' (five days).

Most of these options have appropriate defaults for most sites. Howev