[Mailman-Users] Mail Stuck in Mail Queue

Mark Sapiro msapiro at value.net
Fri Oct 12 08:02:39 CEST 2007

David Boothe wrote:

>Hey guys I am running MailMan version 2.1.9.cp2 on a RHEL 4 box with cPanel 11.  One of my cleints has a list with about 10,000 subscribers.  It is set up as a news list (only the owner sends mail oue to the subscribers) that gets an email sent about 3-4 times a year.  I have noticed that when the owner sends out an email, several emaisl get 'stuck' in the mail queue with about 500 recipients per mail.  I have nothing set on the server to limit any user in the amount of mail they can send.  The mail was sent out 2 days ago and stil about 19 emails with up to 500 recipients are in the queue.  I have noticed that among the recipients are addresses that have already received the mailing from the owner.  I guess I have a few questions...
>  1) Is this 'normal' activity?

For mailman to batch the sends in chunks of 500, yes. For the MTA (I'm
assuming these are queued in the MTA) maybe?

>  2) Why does the mail stay in the queue even for recipients that have already received the mail?

Because not all recipients of that message (chunk) have been delivered
or rejected.

>  3) Is there a setting within MailMan that can control this?

You can control the size of the chunks with SMTP_MAX_RCPTS in mm_cfg.py.

>  4) Any suggestions based on the described activity that will help the lists run better?

I suspect there are one or more addresses in each chunk that are
'delayed' because the MTA that serves the recipient domain is off
line, unreachable or non-existent or returns some 'retryable' error.
These 'delays' don't turn into 'failures' for a period of time
configured in your MTA (usually 5 days).

Suggestion 1) set automated bounce processing appropriately for this
list's post frequency so bouncing addresses get removed. In
particular, set bounce_score_threshold to 1 or maybe to 2 if
bounce_info_stale_after is set to say 100 or more (so you can get a
second bounce before the first one is stale). Note that if you set the
threshold to 1 now, cron/disabled will disable all members who have
ever bounced the next time it runs.

Suggestion 2) set
(or maybe 5) in mm_cfg.py. This will reduce the probability that a
chunk contains an address whose delivery will be delayed, thuse
reducing the number of chunks (messages) hanging around for days in
the MTA. You could also consider setting
or better still set
so each recipient will be sent an individual message (with a VERP like
envelope in the latter case for better bounce detection), and only
those messages for users with delayed delivery will remain in the
queue (but this may be a significant number).

Suggestion 3) be sure to set bounce_unrecognized_goes_to_list_owner to
yes to send unrecognized bounces to the list owner so the owner can
manually remove them if necessary.

Mark Sapiro <msapiro at value.net>       The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

More information about the Mailman-Users mailing list