>>>>> "JRM" == Jason R Mastaler <[EMAIL PROTECTED]> writes:
JRM> Some users will not want to use a shared whitelist, but in my
JRM> experience, the vast majority will. I predict that if you
JRM> add the feature without this sub-feature, it will become a
JRM> nagging FAQ.
JRM> Think about a site with 1000 mailing lists. User jdoe is
JRM> subscribed to 2 of these lists, but over time starts posting
JRM> to others. He'll get very tired of confirming his message
JRM> upwards of 998 times. And this assumes he only uses a single
JRM> e-mail address.
JRM> It's also more difficult from a management perspective.
JRM> Instead of having one data-store to prune, you have 1000.
It's a persuasive argument. I'm already dreading the integration
problem when you try to federate the member databases of those 1000
lists. Adding another list of addresses that need to be collated
could be another headache. OTOH, since the whitelist is /only/ a list
of addresses, a simple union would probably suffice (you don't have
the same problem with unioning member database since non-members don't
have option flags and other data).
JRM> I can't actually think of a good reason why you'd ever NOT
JRM> want to utilize a shared whitelist. The goal is to keep
JRM> spammers out, not to impede legitimate senders. In a perfect
JRM> universe, you'd have a global whitelist containing the
JRM> address of every non-spammer on the planet. :-)
So when are you going to start collating the whitelists from all the
TMDA sites and sell the opt-inside-out lists? :)
-Barry
_______________________________________________
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman-21/listinfo/mailman-developers
