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, relay=e.mx.mail.yahoo.com. [67.195.168.230], dsn=4.0.0, stat=Deferred: Connection timed out with e.mx.mail.yahoo.com.
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, relay=mx2.hotmail.com. [65.54.188.94], dsn=4.0.0, stat=Deferred: Connection timed out with mx2.hotmail.com.
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, relay=c.mx.mail.yahoo.com. [206.190.54.127], dsn=4.0.0, stat=Deferred: Connection timed out with c.mx.mail.yahoo.com.
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, relay=alt4.gmail-smtp-in.l.google.com. [74.125.79.114], dsn=4.0.0, stat=Deferred: Connection timed out with alt4.gmail-smtp-in.l.google.com.
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?
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):
rm /var/spool/mqueue/*
rm /var/spool/mqueue-client/*
.This will clear our your queue folder(s) until the system receives another message. You can double check by running
mailq
(both queue folders), orsendmail -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.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 consultmailq
's output because it also shows whether a message is active/currently being processed. E.g.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 IDoBAEMuV8000429
useA 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
Then, at the beginning of the sub routine "wanted" add a check to skip active messages, e.g. with
HTH. And, remember to make backups :-)
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/*
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.I managed to do this by using this bash script