Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a pretty annoying problem here. I have been testing an application and have created some test e-mails to bogus e-mail addresses (not to mention that my server isn't really set up to send e-mail anyway). Of course, sendmail is not able to send these messages and they have been getting stuck in the sendmail queue. I want to manually delete the messages that have been building up in the queue instead of waiting the 5 days that sendmail usually takes to stop retrying.

I am using Ubuntu 10.04 and /var/spool/mqueue/ is the directory in which every how-to I have read says the e-mails that are queued up are kept. When I delete the files in this directory, sendmail stops trying to process the e-mails until what appears to be a cron script runs and re-populates this directory with the messages I don't want sent. Here are some lines from my syslog:

Jun  2 17:35:19 sajo-laptop sm-mta[9367]: o530SlbK009365: to=, ctladdr= (33/33), delay=00:06:27, xdelay=00:06:22, mailer=esmtp, pri=120418, [], dsn=4.0.0, stat=Deferred: Connection timed out with
Jun  2 17:35:48 sajo-laptop sm-mta[9149]: o4VHn3cw003597: to=, ctladdr= (33/33), delay=2+06:46:45, xdelay=00:34:12, mailer=esmtp, pri=3540649, [], dsn=4.0.0, stat=Deferred: Connection timed out with
Jun  2 17:39:02 sajo-laptop CRON[9510]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm)
Jun  2 17:39:43 sajo-laptop sm-mta[9372]: o52LHK4s007585: to=, ctladdr= (33/33), delay=03:22:18, xdelay=00:06:28, mailer=esmtp, pri=1470404, [], dsn=4.0.0, stat=Deferred: Connection timed out with
Jun  2 17:39:50 sajo-laptop sm-mta[9149]: o51I8ieV004377: to=, ctladdr= (33/33), delay=1+06:31:06, xdelay=00:03:57, mailer=esmtp, pri=6601668, [], dsn=4.0.0, stat=Deferred: Connection timed out with
Jun  2 17:40:01 sajo-laptop CRON[9523]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)

Does anyone know how I can get rid of these messages permanently? As a side note, I'd also like to know if there is a way to set up sendmail to "fake" sending e-mail. Is there?

share|improve this question
Well, I still haven't found any solution to this problem. It definitely looks like it's some sort of cron script that is causing it to happen, but I can't figure out where it is storing the queued messages... – Steven Oxley Jun 4 '10 at 17:41
up vote 17 down vote accepted

Queued messages are stored in /var/spool/mqueue.

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

  • Stop sendmail
  • rm -rf /var/spool/mqueue/* (might be called mqueue-client on Ubuntu)
  • Start sendmail
share|improve this answer
He said he had already done this, but messages re-appeared... – Massimo Jun 9 '10 at 13:33
But without stopping sendmail first, that's the point. – weeheavy Jun 9 '10 at 13:40
Well, it appears that you may have struck upon the step that I missed. – Steven Oxley Jun 10 '10 at 17:06
On Fedora 19, I see /var/spool/clientmqueue (as well as /var/spool/mqueue) – TomG Dec 7 '13 at 16:23
For some reason even with sudo this wouldn't work for me (it would say no matches found). So I chmoded the folders to 777 and was then able to delete the contents. – Sridhar-Sarnobat May 2 '14 at 0:43

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 <
                 (Deferred: 450-4.2.1 The user you are trying to contact is re)
oBAEMuV8000429     1058 Fri Dec 10 15:22 <
                 (Deferred: 450-4.2.1 The user you are trying to contact is re)

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";

HTH. And, remember to make backups :-)

share|improve this answer

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/*

share|improve this answer

I don't think this is the work of a cron script, it's more likely to be an application issue, or something related to sendmail itself; anyway, to rule out any cron job doing this, you can just stop crond for a while and see if this keeps happening.

share|improve this answer

I managed to do this by using this bash script

for i in `sudo ls /var/spool/mqueue`
    sudo rm -rv `echo /var/spool/mqueue/$i`
share|improve this answer
So you open a subshell just to invoke echo and retrieve the output of said echo for use as a parameter to rm. Even ignoring the gratuitous forks of sudo and rm, this subshelling is plain wasteful. – Felix Frank Dec 23 '14 at 10:04
Well, if you have a more 'acceptable' solution, it wont be a waste of time to explain your solution instead of just showing how useless a comment can be. Thanks in advance – Shu Hikari Jun 30 '15 at 20:32
Sorry if this came across offensive and arrogant. A more economic approach would be sudo find /var/spool/mqueue -maxdepth 1 -delete. I did find it important to point out what is problematic with your script in particular. Apologies for the lack of tact. – Felix Frank Jul 1 '15 at 13:59
Yep, but now you explained your point and I completely understood it. And apologies accepted, don't worry. Thanks :D – Shu Hikari Jul 17 '15 at 12:38

For the case when you only want to delete messages from or to a specific e-mail address (here, this command works for me:

mailq | \
  tail -n +2 | \
  awk 'BEGIN { RS = "" } / mail@example\.com$/ { print $1 }' | \
  tr -d '*!' | \
  postsuper -d -

Taken from a comment on See there for related solutions and the command in one line. (I used bash line continuation for readability).

A very similar command that allows to make deletion dependent on whether teh address appears as sender, recipient etc. is found in man postsuper, where it says about -d:

For example, to delete all mail with exactly one recipient

mailq | tail -n +2 | grep -v '^ *(' | awk  ´BEGIN { RS = "" }
    # $7=sender, $8=recipient1, $9=recipient2
    { if ($8 == "" && $9 == "")
        print $1 }
´ | tr -d '*!' | postsuper -d -

(I changed the quote to use tail -n +2, since their tail +2 does not work any more, at least on some modern systems.)

share|improve this answer
Yes, but this question is about sendmail. postsuper is postfix specific. (Which I would pick over sendmail any day, but that is beside the issue ;-) – Felix Frank Dec 23 '14 at 10:06

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.