[Mailman-Users] Mail Stuck in Mail Queue
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
> 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
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