[Mailman-Users] Bounces Issue - Revisit II

Dan Busarow dan at dpcsys.com
Fri Dec 17 19:23:26 CET 1999


On Fri, 17 Dec 1999, J C Lawrence wrote:
> On Fri, 17 Dec 1999 09:04:45 -0800 (PST) 
> Dan Busarow <dan at dpcsys.com> wrote:
> > On Thu, 16 Dec 1999, J C Lawrence wrote:
> >> Consider: *ANYBODY*, right now, can bring your server to its
> >> knees with a mail storm.  Bad ju jus.  Configure your MTA to
> >> protect itself and your system.  Let your secondary MX'es, who
> >> are similarly configured, absorb peak loads.  Let the originating
> >> sites hold the mail in normal SMTP fashion until the peak has
> >> smoothed out a bit.
> 
> > This volume isn't particularly high for straight sendmail/procmail
> > delivery.  We see higher during large spam runs.  But throw python
> > in the picture and things go down hill fast.  
> 
> Ahh.  Yes, that it would.  You said 100's -- just how large are you
> talking?  While my current mail server is a little heftier than
> yours (dual P-333 with 512Meg RAM, Ultra-SCSI III disks and
> configured for 30 queue runners) even with an inbound rate of ~500
> messages per minute all of them headed to MailMan in some fashion
> (list posts or bounces) I haven't seen the system load go over 16.

100's is misleading, should have been "over a 100" based on top.
The system (FreeBSD 3.3) was still running but had hit a threshold
where new pythons would fail during the exec.  Just a memory
starvation issue.

> If you need limit to a smaller number without limiting your
> incomings, then a simple procmail rule inserted in front of the
> bounce wrapper to serialise or at least limit parallelism for
> bounces would probably do it.

That's a really good idea, I'll do that.  But I don't think we'll
be seeing this problem going forward.  Like I said, this was a really 
dirty list with 3 or more years of neglected mainenance.  Between
mailman requiring confirmation for new subs plus "normal" bounce
handling during regular operation I don't think this list will
ever get into as bad of shape as it was.  This was the last of
our listproc lists to convert so I won't have the dirty list
problem anytime soon.  KOW

Thanks,
Dan
-- 
 Dan Busarow                                                  949 443 4172
 Dana Point Communications, Inc.                            dan at dpcsys.com
 Dana Point, California  83 09 EF 59 E0 11 89 B4   8D 09 DB FD E1 DD 0C 82





More information about the Mailman-Users mailing list