Viewing the mail queue

The mail queue should be processed transparently. However, you may find that manual intervention is sometimes necessary. For example, if a major host is down for a period of time the queue may become clogged. Although sendmail ought to recover gracefully when the host comes up, you may find performance unacceptably bad in the meantime.

The contents of the queue can be printed using the mailq command (or by specifying the -bp flag to sendmail):

mailq

This produces a listing of the queue identifiers, the size of the message, the date the message entered the queue, and the sender and recipients.

Format of sendmail queue files

sendmail queue files live in the directory defined by the Q option in the /usr/lib/sendmail.cf file, usually /usr/spool/mqueue. The individual qf, df, and xf files may be stored in separate if they are present in the queue directory.

To use multiple queues, supply a value ending with an asterisk. For example, /var/spool/mqueue/q* will use all of the directories or symbolic links to directories beginning with `q' in /var/spool/mqueue as queue directories. New messages will be randomly placed into one of the queues. Do not change the queue directory structure while sendmail is running.

All queue files have the name xfYMDhmsNPPPPP where YMDhmsNPPPPP is the id for this message and the x is a type. The individual letters in the id are:

Y

Encoded year

M

Encoded month

D

Encoded day

h

Encoded hour

m

Encoded minute

s

Encoded second

N

Envelope number

PPPPP

First five digits of the process ID

The types are:

d

data file. The message body (excluding the header) is kept in this file.

q

queue control file. This file contains the information necessary to process the job.

t

temporary file. This is an image of the qf file when it is being rebuilt. It should be renamed to a qf file very quickly.

x

transcript file, existing during the life of a session, showing everything that happens during that session

The qf file is structured as a series of lines, each beginning with a code letter. The lines are as follows:

A

The information given by the AUTH= parameter of the "MAIL FROM:" command or $f@$j if sendmail has been called directly.

D

name of the data file. There can only be one of these lines.

H

header definition. There can be any number of these lines. The order is important: it represents the order in the final message. This uses the same syntax as header definitions in the configuration file.

C

controlling address. The syntax is ``localuser:aliasname''. Recipient addresses following this line will be flagged so that deliveries will be run as the localuser (a user name from the /etc/passwd file); aliasname is the name of the alias that expanded to this address (used for printing messages).

Q

The ``original recipient'', specified by the ORCPT= field in an ESMTP transaction. Used exclusively for Delivery Status Notifications. It applies only to the immediately following `R' line.

R

recipient address. This is normally completely aliased, but is actually re-aliased when the job is processed. There is one line for each recipient. Version 1 qf files also include a leading colon-terminated list of flags, which can be `S' to return a message on successful final delivery, `F' to return a message on failure, `D' to return a message if the message is delayed, `B' to indicate that the body should be returned, `N' to suppress returning the body, and `P' to declare this as a ``primary'' (command line or SMTP-session) address.

S

sender address. There can only be one of these lines.

E

error address. If any such lines exist, they represent the addresses that should receive error messages.

T

job creation time. This computes how long a job remains in the queue undelivered, before being returned to the sender.

P

current message priority. This orders the queue. Higher numbers mean lower priorities. The priority changes as the message sits in the queue. The initial priority depends on the message class and the size of the message.

M

message. This line is printed by the mailq command, and is generally used to store status information. It can contain any text.

F

flag bits, represented as one letter per flag. Defined flag bits are r indicating that this is a response message and w indicating that a warning message has been sent announcing that the mail has been delayed.

N

The total number of delivery attempts.

K

The time (as seconds since January 1, 1970) of the last delivery attempt.

OI

The i-number of the data file; this can be used to recover your mail queue after a disastrous disk crash.

$

a macro definition. The values of certain macros (as of this writing, only $r and $s ) are passed through to the queue run phase.

B

the body type. The remainder of the line is a text string defining the body type. If this field is missing, the body type is assumed to be ``undefined'' and no special processing is attempted. Legal values are 7BIT and 8BITMIME. LI Z The original envelope id (from the ESMTP transaction). For Deliver Status Notifications only.

As an example, the following is a queue file sent to ``eric@mammoth.Berkeley.EDU'' and ``bostic@okeeffe.CS.Berkeley.EDU''. (This example is contrived and probably inaccurate for your environment. Glance over it to get an idea; nothing can replace looking at what your own system generates.)

   P835771
   T404261372
   DdfAAA13557
   Seric
   Eowner-sendmail@vango.CS.Berkeley.EDU
   Ceric:sendmail@vango.CS.Berkeley.EDU
   Reric@mammoth.Berkeley.EDU
   Rbostic@okeeffe.CS.Berkeley.EDU
   H?P?return-path: <owner-sendmail@vango.CS.Berkeley.EDU>
   Hreceived: by vango.CS.Berkeley.EDU (5.108/2.7) id AAA06703;
   	Fri, 17 Jul 92 00:28:55 -0700
   Hreceived: from mail.CS.Berkeley.EDU by vango.CS.Berkeley.EDU (5.108/2.7)
   	id AAA06698; Fri, 17 Jul 92 00:28:54 -0700
   Hreceived: from [128.32.31.21] by mail.CS.Berkeley.EDU (5.96/2.5)
   	id AA22777; Fri, 17 Jul 92 03:29:14 -0400
   Hreceived: by foo.bar.baz.de (5.57/Ultrix3.0-C)
   	id AA22757; Fri, 17 Jul 92 09:31:25 GMT
   H?F?from: eric@foo.bar.baz.de (Eric Allman)
   H?x?full-name: Eric Allman
   Hmessage-id: <9207170931.AA22757@foo.bar.baz.de>
   HTo: sendmail@vango.CS.Berkeley.EDU
   Hsubject: this is an example message

Queue interval

The amount of time between forking a process to run through the queue is defined by the -q flag. If you run sendmail in delivery mode i or b, this can be relatively large, because it is only relevant when a host that was down comes back up. If you run sendmail in delivery mode q, it should be relatively short, because it defines the amount of time that a message may sit in the queue before sendmail tries to deliver it. The delivery mode is a configuration option. (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 does not make sense if you use ``queue-only'' mode).

Forcing the queue

The sendmail program should run the queue automatically at intervals. The algorithm is to read and sort the queue, then to attempt to process all jobs in order. When using multiple queues, a separate process will be created to run each of the queues unless the queue run is initiated by a user with the verbose flag. When it attempts to run the job, sendmail first checks to see if the job is locked. If so, it ignores the job.

There is no attempt to ensure that only one queue processor exists at any time, because there is no guarantee that a job cannot take forever to process (however, sendmail does include heuristics to try to abort jobs that are taking absurd amounts of time; technically, this violates RFC 821, but is blessed by RFC 1123). Due to the locking algorithm, it is impossible for one job to freeze the queue. However, an uncooperative recipient host or a program recipient that never returns can accumulate many processes in your system. Unfortunately, there is no completely general way to resolve this.

In some cases, you may find that if a major host goes down for a couple of days, this can create a prohibitively large queue. This situation causes sendmail to spend an inordinate amount of time sorting the queue. This situation can be fixed by moving the queue to a temporary place and creating a new queue. The old queue can be run later, when the offending host returns to service.

To do this, it is acceptable to move the entire queue directory:

cd /usr/spool
mv mqueue omqueue; mkdir mqueue; chmod 700 mqueue

You should then kill the existing daemon (because it is still processing in the old queue directory) and create a new daemon. To kill the existing daemon and create a new daemon, reboot the system.

To run the old mail queue, run the following command:

/usr/lib/sendmail -oQ/usr/spool/omqueue -q

The -oQ flag specifies an alternate queue directory, and the -q flag says just to run every job in the queue. Use the -v flag to view what is going on.

When the queue is finally emptied, you can remove the directory:

rmdir /usr/spool/omqueue

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, -qSsender limits the run to a particular sender and -qIidentifier limits it to a particular queue identifier.