The complete list of arguments to sendmail is described in detail in Appendix A. Some important arguments are described here.

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

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

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. You may also place an ! before the I or R or S to indicate that jobs are limited 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.


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.

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 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 TRACEFLAGS 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

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[14].

Trying a Different Configuration File

An alternative configuration file can be specified using the -C flag; for example,

/usr/sbin/sendmail -oQ/tmp/mqueue
uses the configuration file instead of the default /etc/mail/ If the -C flag has no value it defaults to 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.

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

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
which would read the configuration file 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

This version requires that you use:

As of version 8.7, some other syntaxes are available in test mode:

defines macro x to have the indicated value. This is useful when debugging rules that use the $& x syntax.
adds the indicated value to class c.
dumps the contents of the indicated ruleset.
is equivalent to the command-line flag.

Version 8.9 introduced more features:

shows a help message.
display the known mailers.
print the value of macro m.
print the contents of class c.
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.
try to canonify hostname.
look up `key' in the indicated `mapname'.
quit address test mode.

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 processes from loading it, but does not prevent existing processes from using the status information that they already have.

[Contents] [Previous] [Next]
This document was translated by troff2html v0.21 on October 10, 2001.

Claus Aßmann Please send comments to: <ca at>