ARGUMENTS

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

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 flag to ask sendmail to speak SMTP on its standard input and output). 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, sender, or recipient 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 and -qIstring limits it to particular queue identifiers.

Debugging

There are a fairly large number of debug flags built into sendmail. Each debug flag has a number and a level, where higher levels 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. 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-range [ . debug-level ]
debug-range: integer | integer - integer
debug-level: integer
where spaces are for reading ease only. For example,
-d12 Set flag 12 to level 1
-d12.3 Set flag 12 to level 3
-d3-17 Set flags 3 through 17 to level 1
-d3-17.4 Set flags 3 through 17 to level 4
For a complete list of the available debug flags you will have to look at the code (they are too dynamic to keep this documentation up to date).

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 setuid root permissions thereafter[13].

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/sendmail.cf. If the -C flag has no value it defaults to sendmail.cf in the current directory.

Sendmail gives up its setuid root permissions when you use this flag, so it is common to use a publicly writable directory (such as /tmp) as the spool 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 -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:

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 January 4, 1999.


Claus Aßmann Please send comments to: <ca@informatik.uni-kiel.de>