Efficient final message disposition (was Re: [Mailman-Developers] Requirements for a new archiver)

[Chuq Von Rospach]

On Oct 30, 2003, at 7:48 AM, Brad Knowles wrote:

> 		"Tuning Sendmail for Large Mailing Lists"
> 		http://tinyurl.com/t09c
>

400K/day aggregate max

> 		"Drinking from the Fire(walls) Hose:
> 		http://tinyurl.com/t09k

380K/day aggregate max

(yawn. My server's bored. snicker)

but seriously, both of them are built around pre sendmail 8.12  
environments. there's some interesting stuff there, but it's now fairly  
dated, since sendmail 8.12 really changes the landscape. And all of  
those other environments....

> 	Or, you could just have Chuq solve this problem for you, as he  
> mentioned in  
> <http://mail.python.org/pipermail/mailman-developers/2000-May/ 
> 006820.html>. ;-)

gack.

>
>>  So what can we do here to improve matters?
>
> 	Sounds to me like you want to externalize this whole process. Problem  
> is, bulk_mailer is the only tool

Because pretty much every MLM has internalized the process. By the end  
of november, I'll have completely retired any use of bulk_mailer on my  
systems for other solutions.

One big reason: increasing spam blocking (stupid or otherwise) of  
non-individually addressed email. The old list server setup of:

to: subscribers of list <list at foo>
bcc: bulk_drop at of.subscribes

is increasingly risky as far as delivery is concerned. I also don't  
think it allows for the kind of personalization that's needed for your  
general audiences (help URLs, unsub URls, etc).

And with sendmail 8.12, queue groups and envelope splitting, frankly,  
bulk_mailer does more harm to the delivery stream than good. Just stuff  
it into sendmail, tune sendmail to split intelligently. bulk_mailer is  
obsolete... and much to my amusement, a few sites block based on its  
use in headers (idiots), which is why my copy identifies itself as  
ulkbay_ailermay.