switch is used both to cause the queue to be processed and to
specify the interval between queue runs.
A typical invocation of the
daemon looks like this:
/usr/lib/sendmail -bd -q1h
program is placed into listening mode with
command-line switch. The
switch tells it to process the queue once each hour.
Note that either switch puts
into the background
as a daemon. The
switch just allows
listen for incoming SMTP connections. Consider the following:
This runs two daemons simultaneously. The first listens for incoming
SMTP connections. The second processes the queue once per hour.
At small sites, where mail messages are rarely queued, the time interval
chosen may be small, to ensure that all mail is delivered promptly.
An interval of
(15 minutes) may be appropriate.
At many sites an interval of one hour is probably best.
It is short enough to ensure that delays in delivery remain tolerable,
yet long enough to ensure that queue processing does not overlap.
At large sites with huge amounts of mail and at sites that send
a great deal of international mail, the interval has
to be carefully tuned by observing how long it takes
to process the
queue and what causes that process
to take a long time. Points to consider are the following:
Network delays or delays at the receiving host may cause
delivery to that host to time out.
Timeouts are set with the
Each such timeout is logged at LOG_NOTICE with a message
timeout waiting for input from
is the name of the other host, and
specifies which timeout triggered the message (such as
"client HELO for
). In general,
timeouts should be large
to ensure that mail to busy sites and to large
mailing lists does not time out improperly. In observing the queue
processing, you may find that
all messages but one process swiftly. That one, you may find, takes
over an hour because of a long SMTP timeout. A possible solution
to this problem
is to make all timeouts short so that most queue runs are processed
Then, for example, the following command
could be run a few times each night to specifically
flush those long jobs:
/usr/lib/sendmail -or2h -q
The queue can take a long time to process because too many messages
are being queued unnecessarily. Several options affect the placement
of mail messages into the queue. The
to queue, rather than deliver, a message if the machine load is too
high. Fewer messages will be queued if
the value of that option is increased. The
Section 34.8.67, SuperSafe (s)
to queue all messages for safety.
If your machine "never" crashes, this may not be necessary.
Section 34.8.29, HoldExpensive (c)
messages to "expensive" delivery agents (those with the
flag set; see
Section 30.8.18, F=e
) rather than delivering them.
If the queue is routinely filled with messages to expensive sites,
you should reconsider your reasons for marking those sites
The queue can fill with messages because
run with the
command-line switch (see
). At sites that
receive a great deal of UUCP mail for forwarding, the
program is often set up to run
in "queue only" mode
command-line switch. If UUCP mail is clogging
your normal mail services, you should consider queueing it to
a separate queue directory. You can then process that other directory
with a separate queue run of
. (Use of separate
queue directories is discussed in
Section 23.7, "Process Alternate Queues"
A slow machine can clog the queue. When a single machine is
set up to handle the bulk of a site's mail, that machine should
be as swift as possible. In general, a dedicated mail
server should have a fast CPU with lots of memory. It should
never allow users to log in to it, and it should run its own
name server daemon.
command-line switch, invoked without
a time interval argument, is used
in queue-processing mode. In this mode,
processes the queue once and then exits.
This mode can be run interactively from the command-line or
in the background via
Other command-line switches can be combined with
refine the way the queue is processed.
(verbose) switch causes
to print information about each message it is processing. The
(debugging) switch may be used to produce additional
information about the queue. We'll discuss the
switch as it applies to the queue later in this chapter. Those
debugging switches appropriate to the queue can be found in
Section 37.5, "Reference in Numerical Order"
allows variations on
allows you to specify a specific message identifier for processing;
allows you to specify specific recipient addresses for processing;
allows you to specify specific sender
addresses for processing.
command-line switch, without an interval argument,
to process the queue once, then exit.
As such, this switch is a handy administrative tool.
When the queue fills unexpectedly between queue runs of the
daemon, for example, the
command-line switch can be used to
force an immediate queue run:
On machines that do not run the
command-line switch can be used in conjunction with
to periodically process the queue.
(5) file entry, for example,
to be run
once per hour, at
five minutes past
the hour, to silently process the queue and exit:
5 * * * * /usr/lib/sendmail -q >/dev/null 2>&1
When used in conjunction with other switches (shown below), the
switch allows many queue problems to be conveniently handled.
switch without an argument
in the background and detaching from its controlling terminal.
But it also runs silently.
To see what is going on, use the
in combination with the
/usr/lib/sendmail -v -q
to print a step-by-step description of what
it is doing.
To illustrate, consider the following output produced by using
Running MAA20989 (sequence 1 of 2)
<email@example.com>... Connecting to dc.gov via ddn...
Trying 188.8.131.52... Connection timed out during user open with DC.GOV
<firstname.lastname@example.org>... Deferred: Host DC.GOV is down
Running MAA27002 (sequence 2 of 2)
<email@example.com>... Connecting to irs.dc.gov via ddn...
Trying 184.108.40.206... connected.
220 irs.dc.gov Sendmail 5.57/3.0 ready at Mon, 27 Jan 92 09:16:38 -0400
Here, two queued messages are being processed. The first
fails because of a connection timeout and is requeued for a later
queue run. The second succeeds (we omit the full
SMTP dialogue). After its delivery is complete, it is removed
from the queue.
you can process a subset of all queued messages.
You can select which to process based on queue identifier, recipient
address, or sender address:
variation is followed by a queue identifier such as
followed by the address of a recipient. The
by the address of a sender.
In all three variations there must be no space between the uppercase
letter and the identifier or address.
These variations are used to limit the selection of queued files
that are processed. For example:
/usr/lib/sendmail -qSroot -qRbiff@here
Here, the queue is processed once. Only messages from
are processed. Of those, only messages that have
as one of the recipients are processed.
In all three variations a partial specification of
is viewed by V8
as a substring. For example,
matches mail from all of the following:
The last line further illustrates that the substring match is a
case-insensitive one. The substring match is literal. Wildcard
characters (such as
) and regular expressions (such as
won't work and may confuse the shell from which you run
Multiple specifications may be combined on the command line (as shown
above), but they all AND together:
/usr/lib/sendmail -qI123 -qSroot -qR@host.edu
Here, the queue is processed only for messages with the number
123 anywhere in the message identifier
that are also from
and that are also addressed
to anyone at
You can use the
command to preview the effect
of these switches. For example, the following command will list (but not send)
the messages that would be processed by the above command line:
mailq -qI123 -qSroot -qR@host.edu
The ESMTP ETRN command, based on RFC1985,
causes V8.8 and above
to asynchronously process its
queue in a manner similar to the
command line switch
Section 220.127.116.11, "Process by identifier/recipient/sender: -q[ISR]"
This new command allows dial-on-demand sites to make an SMTP
connection and to force the other side to process and send any
mail that is queued for them.
The form of this ESMTP command looks like this:
If the host is missing, this error message will be returned:
550 Parameter required
Otherwise, the queue will be processed just as if the following
command line argument were given:
In both cases a
file will be processed
if it has a host named
anywhere in the host part
) of one of its
lines. The only
difference here is that the former (the ETRN) operates
asynchronously. That is,
forks a copy of itself, and
the forked child processes the queue.
One way to use
is with a simple Bourne shell script:
echo "etrn $OURSITE" | $TELNET $MAILSERVER $PORT
If run on a dial-on-demand host, this script will force a dial-up network connection
to be made. The mail server's
is then forced, with ETRN,
to process the queue and transport back any mail destined for the local host over the
just-created network connection.