It is not just bad MX records, many DNS irregularities are responsible
for this behaviour. It is because sendmail considers unavailable
domain resolutions potential SPAM.
The sendmail configuration parameter
governs how long sendmail will try to resolve a RCPT. It can be
significantly shortened without too much difficulty. However, setting
it too short will result in non-delivery to legitimate addresses that
are behind slow, busy, or intermittent links. See the sendmail docs.
Alternatively, you can set sendmail to queue incoming messages rather
than trying immediate delivery by putting this in your .mc file:
Then sendmail will accept and try to deliver these, and bounce them
back if undelivered after the usual delay. The bounces are then
processed by Mailman to clean the list.
Note that circumventing the anti-SPAM measures may have undesireable
effects on publically-available MTAs. However, in practice, I haven't
run into serious problems doing it.
If you do this, there are other operational tunings that you may want
to investigate including limiting the number of daemons sendmail is
Of course, after customizing your .mc file you have to re-generate
your sendmail.cf and restart sendmail.
If you don't want to change your sendmail configuration, the only
alternative is to manually delete the hanging messages from
~mailman/qfiles. Each message is represented by two files, the
message itself (*.msg) and a control file (*.db). The
~mailman/bin/dumpdb program will show the contents of the control
file. You should turn off qrunner while you are manipulating the
Finally, if you do nothing, eventually the qfiles will time out and be
deleted. There is a parameter in ~mailman/Mailman/Defaults.py that
controls how long this is. But this will make delivery logy for
legitimate recipients and bounce processing is not performed. Other
parameters can be adjusted (e.g. shortening the time qrunner has to
deliver) as well.
I've tried all these, you get the most mileage out of configuring
sendmail to defer delivery.
Glen Foster <gfoster at gfoster.com>
Richard Martin writes:
I am refining the definition of the problem 'Can not check MX records'
Apparently there is a bad address in the users list, bad in the respect
that the destination server has a broken MX record. consequently, the
posted message is patiently waiting in queue, hitting a brick wall every
How can I flush out or delete messages queued by Mailman? I have looked
thorough the directories and archives, but I can't seem to locate much
on this one.
Austin, TX 78703