[Mailman-Users] Mailman Stalls for Outgoing Emalis

[Brad Knowles]

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 
those questions.

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 
primary instance.

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 
correct/up-to-date.


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/>.