Re: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use)
On Mon, 29 Jul 2002 10:47:02 -0600 Jason R Mastaler <Jason> wrote:
J C Lawrence <claw@kanga.nu> writes:
Given that the TMDA python product carries almost all the needed payload, I wonder if a TMDA-plugin rooted in the TMDA product doesn't make more sense.
I'm comfortable with this as well, and don't mind making modifications to TMDA that would make this easier if that proves necessary.
<nod>
Not speaking for Barry, but there are large advantages to leveraging code that other people maintain vs increasing the code and maintenance load of Mailman.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
J C Lawrence <claw@kanga.nu> writes:
Not speaking for Barry, but there are large advantages to leveraging code that other people maintain vs increasing the code and maintenance load of Mailman.
True. Another benefit is that folks don't have to wait until MM 2.2 to add this functionality.
-- (http://tmda.net/)
>> I'm comfortable with this as well, and don't mind making
>> modifications to TMDA that would make this easier if that
>> proves necessary.
JCL> Not speaking for Barry, but there are large advantages to
JCL> leveraging code that other people maintain vs increasing the
JCL> code and maintenance load of Mailman.Absolutely, but I see this one as requiring very little extra new code so I /think/ we'd get it almost for free. Lemme see what a few hours of hacking tonight can produce.
-Barry
barry@python.org (Barry A. Warsaw) writes:
Absolutely, but I see this one as requiring very little extra new code so I /think/ we'd get it almost for free.
Minus access to a shared confirmed senders list.
This is surely better than nothing, but the shared list is a pretty integral feature IMO. I don't think I'd use the MM built-in support until this was available in some form.
-- (http://tmda.net/)
"JRM" == Jason R Mastaler <jason@mastaler.com> writes:
>> Absolutely, but I see this one as requiring very little extra
>> new code so I /think/ we'd get it almost for free.
JRM> Minus access to a shared confirmed senders list.
JRM> This is surely better than nothing, but the shared list is a
JRM> pretty integral feature IMO. I don't think I'd use the MM
JRM> built-in support until this was available in some form.I have to defer to you and others who have actually started using this arrangement. If what you say is the case -- builtin support isn't terribly useful without the shared whitelist -- then maybe it does make sense to defer until a later Mailman version. If MM+TMDA does the job, then that's probably good enough.
-Barry
barry@python.org (Barry A. Warsaw) writes:
If what you say is the case -- builtin support isn't terribly useful without the shared whitelist -- then maybe it does make sense to defer until a later Mailman version.
Some users will not want to use a shared whitelist, but in my experience, the vast majority will. I predict that if you add the feature without this sub-feature, it will become a nagging FAQ.
Think about a site with 1000 mailing lists. User jdoe is subscribed to 2 of these lists, but over time starts posting to others. He'll get very tired of confirming his message upwards of 998 times. And this assumes he only uses a single e-mail address.
It's also more difficult from a management perspective. Instead of having one data-store to prune, you have 1000.
I can't actually think of a good reason why you'd ever NOT want to utilize a shared whitelist. The goal is to keep spammers out, not to impede legitimate senders. In a perfect universe, you'd have a global whitelist containing the address of every non-spammer on the planet. :-)
-- (http://tmda.net/)
"JRM" == Jason R Mastaler <jason@mastaler.com> 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
barry@python.org (Barry A. Warsaw) writes:
So when are you going to start collating the whitelists from all the TMDA sites and sell the opt-inside-out lists? :)
You want in? <wink>
-- (http://tmda.net/)
At 21:02 -0600 7/29/2002, Jason R. Mastaler wrote:
In a perfect universe, you'd have a global whitelist containing the address of every non-spammer on the planet.
In a perfect universe, there would be no spammers on the planet. ;-)
--John
John W. Baxter Port Ludlow, WA, USA set emptyRecord to {behindTheCurtain: "Pay no attention to the string behind the curtain!"}
On Mon, 29 Jul 2002 20:37:21 -0400 Barry A Warsaw <barry@python.org> wrote:
I have to defer to you and others who have actually started using this arrangement. If what you say is the case -- builtin support isn't terribly useful without the shared whitelist -- then maybe it does make sense to defer until a later Mailman version. If MM+TMDA does the job, then that's probably good enough.
Given your prior comments and a brief review on this end of the relevant effort required:
Have we now spent more time and effort on discussing this than would have been required to just do it?
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
"JCL" == J C Lawrence <claw@kanga.nu> writes:
JCL> Given your prior comments and a brief review on this end of
JCL> the relevant effort required:
JCL> Have we now spent more time and effort on discussing this
JCL> than would have been required to just do it?Yes, but I would have done it wrong. :)
-Barry
On Mon, 29 Jul 2002 20:37:21 -0400 Barry A Warsaw <barry@python.org> wrote:
If MM+TMDA does the job, then that's probably good enough.
While I like the idea of TMDA-like features built into MM, I like the plugin model even more. Among the deciding factors for me is tht I'd like to expose some of the other TMDA-features like dated addresses, sender address etc into Mailman lists (eg the prior commentary on lists which hide poster addresses with TMDA-based dated addresses). It suspect would be significantly easier to bolt that atop a TMDA-based Mailman plugin than it would be to bolt it onto Mailman+TMDA-like features.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
participants (4)
-
barry＠python.org -
J C Lawrence -
Jason R. Mastaler -
John W Baxter