[Mailman-Developers] AOL's requirements for spam complaints

[Barry Warsaw]

On Fri, 2004-01-30 at 08:52, Kevin McCann wrote:

> Why is it, then, that Lyris can send personalized messages to lists with 
> hundreds of thousands of members with no problem?  I don't personally 
> have any lists that are nearly that big but I can tell you that my Lyris 
> box sends messages to my lists with a few thousand members extremely 
> quickly. 

And I think we can make Mailman clear its queue of a message very
quickly, even with full personalization turned on.  How Mailman 2.1 does
personalization is not as efficient as it could be, for technical
reasons I won't go into right now.  I believe we can make Mailman more
efficient here.

We've made the decision to not assimilate the MTA into Mailman.  The big
advantage here is that writing MTAs is hard, takes huge amount of
resources we don't have, and we can leverage the many good open source
MTAs out there.  The disadvantage is that we're going to pay for
personalization in MTA disk i/o.  Mailman 2.1 won't get clobbered here
(see my previous messages on the subject, and remember that during the
betas, MM2.1 /did/ queue each personal message to disastrous results),
and Mailman 3 will be better.

I totally buy that personalization improves the user experience, even
for discussion lists.  I think it's basically a no brainer, all other
things being equal.  I believe we're making the right choice here
because we can support a wide range of system configurations.  Small
sites that can't afford even moderate increase in cpu or bandwidth (they
turn off personalization), or that can and doesn't worry about i/o
because their traffic is light.  Larger sites can afford fast disks, mta
smurf farms, and other measures to mitigate the i/o requirements of the
mta.  Huge sites can write their own special Python delivery module to
speak WPMP (Wizzy Personalized Mail Protocol) to their custom in-house
blindingly fast weave-it-on-the-wire mail server.

> Having personalization as a *choice* is the best thing. Then, 
> those who worry about disk I/O or whatever can live with 
> non-personalized delivery (at the expense of the users, of course), and 
> those who want to move forward into the 21st century can do so with 
> personalized delivery.

Exactly.

> Mailing list communities want more now. Especially in Communities of 
> Practice. Our most recent request was to tack on a person's professional 
> profile (from another datasource) on the end of each message he or she 
> sends. Feasible? 

Yes.

> Maybe, maybe not. But people do want this kind of 
> thing. And I get paid to deliver what is needed. The fact is that Lyris 
> does personalization just fine. So why continue to let Mailman lag behind?
> 
> Barry and others will be (or are) working on Mailman 3. I think that 
> he/they should take a long hard look at the commercial MLM success story 
> (Lyris) and take a few pages out of that book. They spent millions of 
> dollars on R&D and made decisions base on it. Why not tap into that? 
> Personalized delivery is just one thing. Don't get me started on SQL 
> issues and the need for vastly improved logging for forensic purposes.

So Kevin, you coming to PyconII?  I still don't have (m)any volunteers
joining me in a Mailman 3 sprint. :(

-Barry