[Mailman-Users] Throttling output

[Brad Knowles]

At 8:58 AM -0400 2006-06-14, Steve Campbell wrote:

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

	Maybe, but not necessarily.

>                                                                 Or is
>  it dependent on the MAX_SMTP_RCPTS parameter, as mentioned above?

	Yes, it is.  If you have VERP and/or personalization turned on, 
then you are actually sending a unique copy of each message to each 
recipient, and the MAX_SMTP_RCPTS parameter does not come into play.

>                        Secondly, the mail list software does not seem to
>  handle bounce conditions.

	That's bad news.  Really bad.

>                            When the list sends to non-existent members,
>  bounces are returned through one of our primary MX gateways, which tend
>  to clog it up.

	Mailing list traffic should be independent of your main mail 
servers.  If the recipient machines are acting correctly, none of 
their bounces should be going back to the main mail servers, and 
mailing list traffic should not affect them.

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

	If your mailing list software is not handling bounces properly, 
then I think I would have probably declared it to be spam-ish myself. 
That said, now that you've annoyed AOL and others, you're not going 
to get on their good side just by switching to Mailman.  You'll also 
need to get on their "whitelist" system.

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

	Yes, but if each envelope is to 500 people (or less), then you'll 
need to set your MAX_QUEUE_RUN_SIZE to an appropriately small number. 
More importantly, you'll need to make sure that you never allow more 
than one queue runner to be running at a time, and no more than one 
queue runner to be run per hour (or whatever).

	This is not likely to clear your mail queues in a reasonable 
period of time, and the actual amount of mail throughput per hour 
will be exceptionally bursty.  Even then, it will only approximate 
the real controls that you want, which is the number of recipients 
that are delivered per hour, and only in the vaguest possible manner.


	Trust me, if you're actually going to do throttling, you need to 
do it in a better and more controlled way.

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

	The best way to do that is to change the period of time after 
which sendmail would generate a DSN for a given message based on how 
long that message has been in the queue.  You do this by changing the 
sendmail.cf.

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

	In that case, with a more intelligent configuration and a better 
mailing list manager, I don't think you're going to need throttling.

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