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.
-
If the
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
DeliveryMode
(
d
) option
(see
Section 34.8.16, DeliveryMode (d)
) set to
queue-only
or
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
QueueLA
(
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
QueueDirectory
(
Q
)
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
If the
QueueDirectory
(
Q
) option is missing, the name defaults to
mqueue
.
When the location is relative (as
mqueue
),
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
(
/
) directory.
[1]
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
PrivacyOptions
(
p
) option (see
Section 34.8.47, PrivacyOptions (p)
).
It allows only users in the same group as the group ownership
of
the queue directory to be able
to print its contents with
mailq
or
-bp
(see
Section 23.4, "Printing the Queue"
).