[Mailman-Users] Mailman Stalls for Outgoing Emalis
brad at stop.mail-abuse.org
Wed Aug 9 07:42:28 CEST 2006
At 12:33 AM -0400 2006-08-09, Kevin A. McGrail wrote:
> FAQ 6.6 mentions SMTP_MAX_RCPTS = 10 but 6.3 mentions 2-5. I'm using VERP
> so I believe this is irrelevant to my installation but it might be good to
> clarify for consistency.
FAQ 6.6 is probably a little older, and appears to need to be
updated. You are correct, that if you are VERPing everything, then
this particular parameter is not relevant to your site.
> Also FAQ 6.6 mentions changes because mailman didn't used to use a FIFO
> queue. The FAQ specifies this was a target for 2.1.X mailman and to my
> knowledge QRUNNER_PROCESS_LIFETIME & QRUNNER_MAX_MESSAGES were remove
> from Default.py.
I'm not familiar with the code at that depth, so I would have to
leave those modifications to the FAQ to someone who could answer
Mark, are you listening?
> The box is an incoming mail server as well so while we can tweak things
> to make running out of child daemons minimal, with the dictionary
> attacks+spammers+normal mail traffic, I see no way that I can guarantee
> that the box will not run out of connections available. Am I correct that
> if this occurs, the qfile/out runner will stall?
For a large site, you want to split incoming and outgoing mail
services onto separate clusters of machines.
Moreover, if you're doing any amount of anti-spam processing or
anti-virus scanning, then you'll probably want to run multiple
different instances of your MTA on your machines. The primary
instance would be running on port 25 on all interfaces, with all
scanning intact. The secondary instance would be listening to some
other port only on the loopback (127.0.0.1) interface, and would be
used exclusively for outbound e-mail from that server. You would
want to make sure that all output from Mailman was directed at this
second instance of your MTA, so that you don't go through all that
scanning a second time, for all outbound mail as well as all your
inbound mail. On this second instance, you also generally want to
remove any kind of resource limiting that you may have in place,
because you have presumably done all that sort of stuff on the
IIRC, these issues are discussed in the FAQ under the respective
"performance tuning" sections, but I may be wrong. If so, please let
me know I'll try to update the relevant FAQ entry to be more
Even after you've done all of this, there is still the chance that
your MTA may run out of available connections. If that happens, I
don't see any other way to resolve this issue than to monitor the
server(s) closely (using tools like rrdtool, munin, bb4, nagios,
etc...), and to use mailmanctl to restart mailman itself and any
stalled queue runners.
Brad Knowles, <brad at stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
Founding Individual Sponsor of LOPSA. See <http://www.lopsa.org/>.
More information about the Mailman-Users