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).
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 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:
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, 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.
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:
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 setuid root permissions thereafter[10].
An alternative configuration file can be specified using the -C flag; for example,
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.
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: