Each release of sendmail offers more and better ways to handle queue problems. They are mostly implemented as options. Table 24-7 in Section 24.7.2 lists all options that affect the queue. Of special interest are the MaxQueueRunSize, Timeout.queuereturn, and Timeout.queuewarn options. Whenever you upgrade to a new sendmail release, be sure to read the RELEASE_NOTES for information about new ways to solve queueing problems.
The queue directory should never be shared among machines. Such sharing can make detection of orphaned locks impossible. Bugs in network-locking daemons can lead to race conditions in which neither of two machines can generate a queue identifier.
In old versions of sendmail it was possible for an lf file to be left in place even though its corresponding mail message was not being processed. Such spurious files prevented the message from ever being delivered unless they were removed by hand. Spurious lock files could be detected by watching the syslog(5) file for frequent locked warnings.
Homespun programs and shell scripts for delivery of local mail can fail and lose mail by exiting with the wrong value. In the case of a recoverable error (a full disk, for example) they should exit with EX_OSERR or EX_TEMPFAIL. Both of these exit values are defined in <sysexits.h> and cause the message to be re-queued.
Because sendmail does a chdir(2) into its queue directory, you should avoid removing and re-creating that directory while the sendmail daemon is running. When processing the queue, sendmail tries to read the queue directory by doing an opendir(3) of the current directory. When the queue directory is removed, sendmail fails that open and syslog(3)s the following warning:
orderq: cannot open "/usr/spool/mqueue" as ".": No such file or directory
Some very old versions of sendmail had a bug in handling the queue that could cause a message to be lost when that message was the last in a queue run to be processed. This, among other reasons, is good cause to always make sure you are running the latest version of sendmail.
The sendmail program assumes that only it and other trusted root programs will place files into the queue directory. Consequently, it trusts everything it finds there that is correctly formatted and has the correct ownership and permissions. The queue directory must be protected from other users and untrusted programs.
If the queue directory is on a disk mounted separately from / and /usr, be certain to mount that disk before starting the sendmail daemon. If you reverse these steps, the sendmail daemon will chdir(2) into the queue before the mount. One effect of the reversal is that incoming mail will use a directory different from that used by outgoing mail. Another effect is that incoming queued mail will be invisible. Yet another effect is that the outgoing queue will never be processed by the daemon.
When using multiple queues, it might be possible to umount a directory while sendmail is still running, but you should avoid this temptation. Never mount or umount queue disks while sendmail is running. Stop sendmail first, do your maintenance, then restart sendmail.