How do I permanently delete e-mail messages in the sendmail queue and keep them from coming back?

Solution 1:

The messages that have been sent or are trying to be sent are stored in /var/spool/mqueue. Messages that Sendmail has not tried to queue yet can be found in /var/spool/mqueue-client.

So try this (I assume you want to get rid of all messages in the queue):

• Stop sendmail
• rm /var/spool/mqueue/*
• If you want to remove messages in waiting, rm /var/spool/mqueue-client/*.
• Start sendmail

This will clear our your queue folder(s) until the system receives another message. You can double check by running mailq (both queue folders), or sendmail -bp (only the queue folder).

NOTE: With most Linux distributions you can start/stop services with with service sendmail <start|stop|restart> or /etc/init.d/sendmail <start|stop|restart>. Both options have many other status flags which can be observed by typing in the command and service without the status flags.

Solution 2:

You will often find the suggestion to remove files from Sendmail's mqueue directory with for instance rm /var/spool/mqueue/* or worse (rm -rf etc.). IMHO, this is plain dangerous. It will work in many cases but I recommend to fasten your seat belts. Simply removing all files from mqueue might delete legitimate messages.

To stop Sendmail before removing queued messages is good advice especially if many messages need to be removed. However, if only a few messages are to be removed or if the queue is cleaned up on a regular basis e.g. by means of a cron job there is actually no need to stop Sendmail. In the worst case one of the messages will be re-queued which will almost certainly be removed when you try again.

On the contrary, stopping Sendmail (e.g. in Ubuntu with service sendmail stop) might not be sufficient. Even when stopped some (child) processes might still be running. One would have to wait until they finished (recommended) or kill them.

In order to safely remove messages from mqueue you need the messages' queue IDs. The IDs are shown in the log after "sm-mta[...]:". The IDs from your log excerpt are o530SlbK009365, o4VHn3cw003597, ... For each of the IDs 2 files are stored in mqueue, one starting with "qf", the other starting with "df".

mailq is generally used to list the queue's content. It shows the IDs in the first column. Furthermore, you should consult mailq's output because it also shows whether a message is active/currently being processed. E.g.

-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient----------
oBDDuKAB023946*    1058 Mon Dec 13 14:56 <[email protected]
                 (Deferred: 450-4.2.1 The user you are trying to contact is re)
                                         <[email protected]>
oBAEMuV8000429     1058 Fri Dec 10 15:22 <[email protected]
                 (Deferred: 450-4.2.1 The user you are trying to contact is re)
                                         <[email protected]>

In this example the message with ID oBDDuKAB023946 is currently being processed, shown by the appended asterisk. Other messages are safe to be removed. For example, in order to remove the message with ID oBAEMuV8000429 use

rm /var/spool/mqueue/{d,q}foBAEMuV8000429

A more versatile approach to remove queued messages is provided by Brandon Hutchinson in Deleting mail from the mail queue. Brandon also includes scripts to remove messages based on the domain part, email address etc.. Brandon's scripts are very helpful for regular cleanup or mass removal.

Nevertheless, even Brandon's scripts are not taking care of the messages' status. However, it's easy to add. Include at the beginning of his scripts

# Get current mailq status
my $mailq = `mailq`;

Then, at the beginning of the sub routine "wanted" add a check to skip active messages, e.g. with

# skip if file is currently processed by MTA
if ($mailq =~ /\n$queue_id\*/) {
   $debug && print "$queue_id is locked.\n";
   last;
}

HTH. And, remember to make backups :-)

Solution 3:

I had this same problem and found that there were 2 folders with queued messages. The folder /var/spool/clientmqueue/ had messages that were ending up in /var/spool/mqueue/ if they failed to be delivered. Deleting the files from both folders were necessary to solve the problem.

rm -f /var/spool/clientmqueue/* rm -f /var/spool/mqueue/*