|
|
The complete list of arguments to sendmail is described in detail in Appendix A. Some important arguments are described here.
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 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.
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:
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:
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:
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:
Options can be overridden using the -o or -O command line flags. For example,
Some options have security implications. Sendmail allows you to set these, but relinquishes its set-user-ID or set-group-ID permissions thereafter[14].
An alternative configuration file can be specified using the -C flag; for example,
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.
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,
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.
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:
If you need more detail, you can also use the -d21 flag to turn on more debugging. For example,
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
As of version 8.7, some other syntaxes are available in test mode:
Version 8.9 introduced more features:
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: