Re: [Mailman-Developers] documentation for config.pck elements?
They're rapidly changing, so probably not. Barry adds new things all the time, and changes functions of them, etc. In other words, I wouldn't call Mailman's MailList object (which is really what that file contains) a public API.
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.
(of course Barry will chime in too.)
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. 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.
Are the contents of a Mailman configuration "database" (config.db/config.pck) documented anywhere?
In particular, the various keys. Keys such as "members", "digest_members", and "owner" are obvious, but others aren't so. I can probably figure them out with some digging, but I'd like to have some sort of reference to point TMDA users to.
TMDA has recently been trained to grok MM config databases (see http://mla.libertine.org/tmda-workers/200201/msg00050.html).
Thanks.
"DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes:
DM> They're rapidly changing, so probably not. Barry adds new
DM> things all the time, and changes functions of them, etc.
DM> In other words, I wouldn't call Mailman's MailList object
DM> (which is really what that file contains) a public API.Me neither. :)
The intent though is that once I go to beta (next release), those attributes and their semantics will be frozen through the MM2.1 release. At the moment they're only documented in the code.
All the "public" attributes appear in two places, in the mixin classes that are the bases for MailList, and in the web gui components that are used to present the data in the admin screens. There's actually a lot more documentation in the latter (see the Mailman/Gui subdir). Unfortunately the attributes are spread over many files, but I think you can find them all there.
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.
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.
-Barry
barry@zope.com (Barry A. Warsaw) writes:
The intent though is that once I go to beta (next release), those attributes and their semantics will be frozen through the MM2.1 release.
Right now TMDA assumes attributes containing e-mail addresses will either be lists, or dictionaries in which the addresses are the keys. This seems to hold true for both MM 2.0 and 2.1a.
-- (TMDA (http://tmda.sourceforge.net/)) (user-level UCE intrusion prevention)
"JRM" == Jason R Mastaler <jason-list-mailman-developers@mastaler.com> writes:
JRM> Right now TMDA assumes attributes containing e-mail addresses
JRM> will either be lists, or dictionaries in which the addresses
JRM> are the keys. This seems to hold true for both MM 2.0 and
JRM> 2.1a.Yup, that shouldn't change for MM2.1.
-Barry
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)
participants (3)
-
barry＠zope.com -
Dan Mick -
Jason R. Mastaler