[Mailman-Users] Throttling output

[Steve Campbell]

Brad, and all,

Firstly, thanks, for all the responses on an OT type question. I have 
learned quite a bit.


----- Original Message ----- 
From: "Brad Knowles" <brad at stop.mail-abuse.org>
To: "Bernd Petrovitsch" <bernd at firmix.at>
Cc: <mailman-users at python.org>
Sent: Tuesday, June 13, 2006 6:36 PM
Subject: Re: [Mailman-Users] Throttling output


> At 11:38 PM +0200 2006-06-13, Bernd Petrovitsch wrote:
>
>>>  I think that this would require a second MTA instance -- the

Does this mean using a second sendmail.cf or more like a second queue 
runner?
>>
>>  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:?).
>
> Mailman can do that, depending on how you configure the MAX_SMTP_RCPTS 
> parameter.

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

But if my list has 22,000 members, isn't that what I am doing? Or is it 
dependent on the MAX_SMTP_RCPTS parameter, as mentioned above? I'm not clear 
on your train of thought.
>
> True.
>
>>  And if you do this "normally", you shouldn't need any throttling or
>>  other special behaviour at all - just enough hardware.

Right now, hardware is fine. This all came about because of mail list 
software (not Mailman) that does a few things it shouldn't be doing. 
Firstly, it's running on a dedicated web server. This was sort of out of my 
control. When the list starts outputting, the web sites suffer, but do not 
fail to respond. Secondly, the mail list software does not seem to handle 
bounce conditions. When the list sends to non-existent members, bounces are 
returned through one of our primary MX gateways, which tend to clog it up. 
Thirdly, a lot of the above bounces are from AOL, Verizon, etc, which have 
deemed the list sort of abusive, and do not accept mail from the list, even 
though this is purely a subscription type mailing, so I wanted to switch to 
Mailman for the bounce handling, and throttle so as not to infuriate the 
AOLs and Verizons. >
> Also true.
>
>>>  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).
>
> Yeah, but so far as I know, none of those mechanisms control the number of 
> messages that are sent per period of time.  They control the number of a 
> given set of processes you can have at any given period of time, but that 
> has only the smallest impact on the number of messages sent per hour.

Does this include the MAX_QUEUE_RUN_SIZE, which I interpret as number of 
envelops to send per queue runner instance?
>
>>>  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.

Another sendmail question - how do you snuff the DSN for a sendmail 
instance? Wouldn't the queueonly delivery method do that, or is there a 
problem after that?
>>
>>  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).
>
> I'm not convinced.  If you've got a list of 22,000 recipients and a limit 
> of 1000 recipients per hour, it's probably going to take a lot longer than 
> four hours to get out all those messages.
>
> I do remain convinced that if you're trying to do throttling because your 
> provider requires it, that you are most definitely using the wrong 
> provider.
>

Our network bandwidth provider does not limit our output, and this is not 
the case at all.

Thanks for all the answers and questions.

Steve

> -- 
> 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
>
>  LOPSA member since December 2005.  See <http://www.lopsa.org/>.
>
>