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
(or by specifying the
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.
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:
The types are:
The qf file is structured as a series of lines, each beginning with a code letter. The lines are as follows:
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 [18.104.22.168] 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: firstname.lastname@example.org (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 messageThis shows the name of the data file, the person who sent the message, the submission time (in seconds since January 1, 1970), the message priority, the message class, the recipients, and the headers for the message.
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 22.214.171.124 says that this value should be at least 30 minutes (although that probably does not make sense if you use ``queue-only'' mode).
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:
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:
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.