[Mailman-Users] Throttling output

[Bernd Petrovitsch]

On Tue, 2006-06-13 at 10:18 -0500, Brad Knowles wrote:
> At 3:17 PM +0200 2006-06-13, Bernd Petrovitsch wrote:
> 
> >  On Tue, 2006-06-13 at 09:06 -0400, Steve Campbell wrote:
> >  [...]
> >>  Does anyone have a suggestion for throttling?
> >
> >  Just store the 22.000 outgoing mails in the mail queue (every decent MTA
> >  should be able to do that unconditionally) and wait for the next queue
> >  run?
> 
> 	I think that this would require a second MTA instance -- the 

You want that probably anyway since you probably don't want your MTA
accept 22.000 emails on a public interface in one rush (and I actually
don't remember out of my head how mailman really inject mails. 1 mail
with a long list of rcpt-to:?).

> first instance of sendmail (or whatever MTA) would simply take 
> everything that Mailman gives it and then store that in the queue. 
> This would be different from a normal sendmail (or other MTA) 
> configuration, where immediate delivery would normally be attempted.

Yes. But "normally" you don't throw 22.000 emails at once on your MTA.
And if you do this "normally", you shouldn't need any throttling or
other special behaviour at all - just enough hardware.

> 	Then, additional queue runners are called to start processing 
> that queue and pushing those messages out, but they go through an 
> additional instance of sendmail, where the throttling milter is used.

Just limit/throttle the MTA itself (sendmail has several options for
this like "number of proceses", etc. and I assume that other MTAs like
postfix, exim, qmail allow this too in similar ways).

> 	You would also need to make sure that the first instance of 
> sendmail (or whatever MTA) is not configured to generate Delivery 
> Status Notices (DSNs) for delayed messages, because you know for a 
> fact that some messages are going to be delayed for a significant 
> period of time, and you don't want those kinds of warnings clouding 
> the picture for Mailman.

Of course. But the standard/usual delay of 4 hours or so should be large
enough though (and I don't see a problem in raising that limit).

> 	And I'm sure there are other factors or issues to be considered, 
> although I haven't thought of any others off the top of my head.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services