Re: [Mailman-Developers] documentation for config.pck elements?
DM> It might be that inverting the problem might be the right DM> answer: Mailman 2.1 goes through an API for all "member"-type DM> queries, and so perhaps storing the member info external to DM> config.db via a new "member-adaptor" interface, so that TMDA DM> could also access it through a stable interface, would be the DM> right Mailman/TMDA integration answer? See MemberAdaptor.py DM> and OldStyleMemberships.py.That's definitely on the plate for post-MM2.1. Separating out the storage and representation issues and providing an abstract interface to the data model affords all kinds of benefits.
Actually, I was semi-proposing that MemberAdaptor was mature enough to be drop-in-replaced by something that TMDA supplies, but I can't quite tell if you're disagreeing or not.
DM> Interesting, though; just trying out SpamAssassinNeat! Are you integrating it with Mailman? I'd love to hear about your results (you may have already posted about it, I'm trying to catch up on the list). It looks like a neat thing to try to marry to Mailman. So is TDMA. Thanks for posting that link Jason.
No, I'm not trying any marriage, nor any realtime lookups, just using its prewired heuristics (from a .forward file, as I don't own my mailserver). It's a "look at the message and try to intuit if it's spam" solution, so it doesn't use any whitelisting really (well, there's dynamic whitelisting, in that some of its heuristics are "have I ever noted non-spam from this address before?")
I love it so far; it's instantly cut my spam to almost nil (from ~30-40 a day) with very few errors.
"DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes:
DM> Actually, I was semi-proposing that MemberAdaptor was mature
DM> enough to be drop-in-replaced by something that TMDA supplies,
DM> but I can't quite tell if you're disagreeing or not.MemberAdaptor, yes, I think it's mature enough to use!
>> Neat! Are you integrating it with Mailman? I'd love to hear
>> about your results (you may have already posted about it, I'm
>> trying to catch up on the list). It looks like a neat thing to
>> try to marry to Mailman. So is TDMA. Thanks for posting that
>> link Jason.
DM> No, I'm not trying any marriage, nor any realtime lookups,
DM> just using its prewired heuristics (from a .forward file, as I
DM> don't own my mailserver). It's a "look at the message and try
DM> to intuit if it's spam" solution, so it doesn't use any
DM> whitelisting really (well, there's dynamic whitelisting, in
DM> that some of its heuristics are "have I ever noted non-spam
DM> from this address before?")
DM> I love it so far; it's instantly cut my spam to almost nil
DM> (from ~30-40 a day) with very few errors.I lost track, SpamAssassin or TDMA? I read about SA briefly and it looks like you could run it in a client/server arrangement. If the on-the-wire protocol were simple enough, you could probably write a pure-Python client and then integrate that into Mailman's handler pipeline. If it's too complex, you might be able to wrap SA's C API in a Python extension module.
-Barry
participants (2)
-
barry＠zope.com -
Dan Mick