[Mailman-Users] Mail Stuck in Mail Queue

[Mark Sapiro]

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
SMTP_MAX_RCPTS = 10
(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
SMTP_MAX_RCPTS = 1
or better still set
VERP_DELIVERY_INTERVAL =1
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