Dan Mick <dmick@utopia.West.Sun.COM> writes:
It might be that inverting the problem might be the right answer: Mailman 2.1 goes through an API for all "member"-type queries, and so perhaps storing the member info external to config.db via a new "member-adaptor" interface, so that TMDA could also access it through a stable interface, would be the right Mailman/TMDA integration answer? See MemberAdaptor.py and OldStyleMemberships.py.
That would certainly make things easier, but the "integration" is easy enough as it is. TMDA just uses core Python to reach into the config.db or config.pck and extract e-mail addresses from the various attributes.
What I was looking more for was consolidated documentation of what attributes are stored in a MM config "database", what their contents are, and what format they are stored in.
Although, most users who use TMDA to front their MM lists will only
probably need members', digest_members', and `owner' anyway, so I
think I'll be fine.
Interesting, though; just trying out SpamAssassin, and while it's working fairly well right now, the concept of TMDA is interesting now that I've spent some brainpower on out-of-the-box ideas about spam filtering.
Well, nothing against SpamAssassin, but programs like that were why I wrote TMDA. Overly complex, a risk of false-positives, and not effective enough (for me). I talk more about this on the TMDA homepage. Plus, TMDA is written in Python. :-)
It's not very obvious to me that I can use it, though, since I'm not in a position to change my first-line MTAs here at work, and I'd be willing to bet they don't forward the user-extension form of address.
You can use whatever you want as the recipient delimiter including `+' which is the default under Sendmail. I just sent a test message to ``dmick+test@utopia.West.Sun.COM'' and it seems to have gone through fine.
-- (TMDA (http://tmda.sourceforge.net/)) (user-level UCE intrusion prevention)