Overview of the Queue
Parts of a Queued Message
A Bogus qf File (V8 only): Qf
Printing the Queue
How the Queue Is Processed
Cause the Queue to Be Processed
Process Alternate Queues
The qf File Internals
Mail messages may either be delivered immediately or be held for later delivery. Held messages are referred to as "queued." They are placed into a holding directory, usually called mqueue, from which they are delivered at a later time. There are many reasons a mail message may be queued:
If a mail message is temporarily undeliverable, it is queued and delivery is attempted later. If the message is addressed to multiple recipients, it is queued only for those recipients to whom delivery is not immediately possible.
s configuration option is set to true, all mail
messages are queued for safety while delivery is attempted.
The message is removed from the queue only if delivery
succeeds. If delivery fails, the message
is left in the queue, and another attempt is made to deliver it
later. This causes the mail to be saved in the unhappy event
of a system crash during processing.
If sendmail is run with the
(see Section 34.8.16, DeliveryMode (d)) set to
defer, all mail is queued, and no immediate
delivery attempt is made. A separate queue run is required
to attempt delivery.
If the load (average number of blocked processes) becomes higher than
the value given to the
x) option (see Section 34.8.50, QueueLA (x)),
sendmail queues messages rather than attempting to deliver
them. A separate queue run is required later to process the queue.
The sendmail queue is implemented by placing held messages
into a directory.
That directory and its name (usually mqueue)
are specified in the configuration file by the
option (see Section 34.8.48, QueueDirectory (Q)):
OQ/var/spool/mqueue pre-V8.7 form O QueueDirectory=/var/spool/mqueue beginning with V8.7
Q) option is missing, the name defaults to
When the location is relative (as
it is relative to the location where
sendmail is run. Since the sendmail daemon is typically started
from an rc file at boot time, such relative locations are usually relative
to the root (
 Of course, if sendmail is started somewhere else or by someone else, the queue directory will be a subdirectory under that other starting directory.
After sendmail has processed its configuration file, it does a chdir(2) into its queue directory and does all the rest of its work from there. This change into the queue directory has two side effects:
Should the sendmail program fault and produce a core dump, the core image is left in the queue directory.
Any relative pathnames that are given to options in the configuration file
are interpreted as relative to the queue directory. (This is not
true for the
F configuration command; see Section 32.1.2, "The F Class Command".
Those files are processed at the same
time as the configuration file, before the chdir.)
The queue directory should be set to have very narrow permissions.
It must be owned by root.
We (and CERT) recommend a mode of 0700.
Prior to V8 sendmail, such narrow permissions would cause
C-shell scripts run from a ~/.forward files to fail.
V8 sendmail lets you specify alternative directories in which
to run programs (see the
D= delivery agent equate, Section 30.4.3, D=).
This allows you to use mode 0700 queue directories
without the associated problems.
As a further precaution, all the components of the path leading to the queue directory should be owned by root and be writable only by root. In the case of our example of /var/spool/mqueue, permissions should look like this:
drwxr-xr-x root / drwxr-xr-x root /var/ drwxr-xr-x root /var/spool/ drwx--- root /var/spool/mqueue/
For additional security, see the
restrictmailq keyword for the
p) option (see Section 34.8.47, PrivacyOptions (p)).
It allows only users in the same group as the group ownership
the queue directory to be able
to print its contents with mailq or
-bp (see Section 23.4, "Printing the Queue").