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.