Mailman 3 January 2002 - Mailman-Developers

Re: [Mailman-Developers] documentation for config.pck elements?
by Dan Mick 11 Jan '02

11 Jan '02

> >>>>> "DM" == Dan Mick <dmick(a)utopia.West.Sun.COM> writes: > > DM> The thing we've been talking about. The thing virtclassed in > DM> MemberAdaptor.py and derived/instantiated in > DM> OldStyleMemberships.py. The thing that implements the > DM> membership-management API. > > Except that I think TDMA wants to be a client of MemberAdaptor, not a > backend implementation of it, unless I'm confused. I dunno. The thing that occurred to me was: TMDA could provide a TMDAMembership.py that: 1) used its own backend store for membership info, and 2) was usable directly by TMDA, either by reusing that file, or by virtue of the fact that *IT* defines the storage format, so other TMDA-private modules can use that same format. i.e. config.db no longer holds the membership info; TMDA.db does. or whatever; it's a functional interface; whatever glue works, works. Being a client of MemberAdaptor means that TMDA would have to run a lot of Mailman code to deal with addresses; if, instead, it were only in charge of the plugin, then it could run even if Mailman weren't available; the synchronization point is the datastore.

1 0

Re: [Mailman-Developers] documentation for config.pck elements?
by Dan Mick 11 Jan '02

11 Jan '02

> > what I'm suggesting is that TMDF > > TMDA == ``Tagged Message Delivery Agent'' sorry. > > implement and supply a Mailman membership-management plugin for just > > this purpose. > > You've lost me. What is a Mailman membership-management plugin? The thing we've been talking about. The thing virtclassed in MemberAdaptor.py and derived/instantiated in OldStyleMemberships.py. The thing that implements the membership-management API. > > Granted, it's more work than you wanted to do, but it doesn't have > > to be that much more, as you too can use a Python marshal for > > persistence; the upside is it's a promised interface. > > Mmmm.. Promised interface..

3 2

Re: [Mailman-Developers] documentation for config.pck elements?
by Dan Mick 11 Jan '02

11 Jan '02

> Dan Mick <dmick(a)utopia.West.Sun.COM> writes: > > > "ease" wasn't the point; the point is that "reaching into config.db" > > is unsupported, whereas "plugin membership module" *is* intended to > > be supported, and therefore stable interface. Then, since you've > > got your choice of storage formats, the world's your oyster as far > > as sharing between Mailman and TMDA. > > Sounds good to me, all I'm saying is that until this is implemented, > I'm still in business. I think you still must misunderstand; what I'm suggesting is that TMDF implement and supply a Mailman membership-management plugin for just this purpose. Granted, it's more work than you wanted to do, but it doesn't have to be that much more, as you too can use a Python marshal for persistence; the upside is it's a promised interface. Then again, maybe Barry's already promised enough of config.db so you don't need it. I'm a Public Interfaces Only zealot. > I'd imagine my wanting access to the `member' addresses from another > application isn't all that uncommon. Mine just happens to be written > in Python which made this easy. It might be nice to optionally be > able to "separate" attributes like `member', and store them along > side in a more universal format like text or DBM, rather than keeping > them locked up inside config.pck where non-Python apps have a hard > time getting at them. Right. That is the purpose of the member plugin (well, that and to make member lookups presumably "better" in some generic-dbm-type way, e.g. to share them with other authentication/dictionary databases, etc.) The TMDF usage is sort of a bending, but still a way to use what's meant to be public rather than piggybacking on something private.

2 1

Re: [Mailman-Developers] First big Mailing
by Dan Mick 11 Jan '02

11 Jan '02

What version? > I'm doing my first big mailing with Mailman/Exim to deliver effector for the > Electronic Frontier Foundation. The list is about 20,000 names. > > Anyhow - started out moving right along, maybe too well - saturated the T1 > pretty quick and the system slowed down. But the email logs were really going > fast. This went on for about 45 minutes. > > During this time I saw a number of errors. Messages indicating the I had too > many files open (running tail on the exim logs). A few messages that looked > like something couldn't open something.db or something like that. > > Then ..... > > The delivery slowed down as it it were done. System load dropped back to low > normal levels. This lasted a while - then things started back up again really > delivering messages. These deliveries come in spurts. > > Anyhow - even though Exim is delivering other email. Messages sent to mailman > are getting "stuck". It's as if nothing in mailman is working. I see messages > being sent to mailman. But mailman isn't responding. I don't know if something > is holding these messages and this is waiting in some queue - or if Mailman > has crashed and is eating messages - or someing is corrupt or locked or > overloaded or what. > > Anyhow - I'd like some general feedback on what might be happening. The > newsletter contains an important story about Norway inditing Jon Johansen > criminally. He's the guy who wrote the DVD code. > > Anyhow - the future of the planet is at stake here - so I'd like to know this > is going to work and what I need to do to fine tune the system. > > Marc Perkel > /root > EFF > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers(a)python.org > http://mail.python.org/mailman/listinfo/mailman-developers

2 1

How do you tell if DB is corrupt?
by Marc Perkel 11 Jan '02

11 Jan '02

I think I have a problem. The html interface into mailman is working - the email quit. I have a frowing number of python processes stacking up. I had just started sending to a list of 20,000 for the first time. I think something is locked up dealing with mail delivery and subscribing with mailman. What do I do to figure out if a database is corrupt - locked - or whatever is wrong. Marc Perkel /root EFF

1 0

Re: [Mailman-Developers] documentation for config.pck elements?
by Dan Mick 11 Jan '02

11 Jan '02

> Dan Mick <dmick(a)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. "ease" wasn't the point; the point is that "reaching into config.db" is unsupported, whereas "plugin membership module" *is* intended to be supported, and therefore stable interface. Then, since you've got your choice of storage formats, the world's your oyster as far as sharing between Mailman and TMDA. Granted, it's a lot more work, but it's a blessed interface as opposed to "looking under the hood", which is almost certainly going to break sometime in the future. > > 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. :-) Yeah, I read that, which is why I said the concept was interesting... although SA is working pretty well for me right now. The integration with my mail system was a lot easier to grok, if not do. > > 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. Under relatively-recent Sendmail, yeah, but I wasn't willing to believe that all our various mailhosts were relatively-recent. > I just sent a test message to > ``dmick+test(a)utopia.West.Sun.COM'' and it seems to have gone through > fine. I did just get that message, though. Hmm. Well, anyway, my use of TMDF is not exactly on-topic for mm-devel. Um...what's your email address? (d'oh! :) (never mind, I have it.)

3 2

2.1a4: outgoing messages lack 'Date:' header under qmail
by Jason R. Mastaler 11 Jan '02

11 Jan '02

When using SMTPDirect as the DELIVERY_MODULE on qmail systems, messages are not sent with a 'Date:' header. Thus, the receiving MTA will most likely add one, but this is sort of confusing. RFC2822 also says this header must be present. I think Message.UserNotification.send() should also add a 'Date' header just as it adds 'Message-ID' (which I'm glad to see it now does!). Accordingly, I've submitted a patch (#500670) to the patch manager at sourceforge. Cheers. -- (TMDA (http://tmda.sourceforge.net/)) (user-level UCE intrusion prevention)

2 2

Minor Feature Request - Rename List
by Marc Perkel 11 Jan '02

11 Jan '02

The first option under General is: The public name of this list (make case-changes only). If this were done right - changing this field would cause the list to be renamed.

2 1

Re: [Mailman-Developers] documentation for config.pck elements?
by Dan Mick 11 Jan '02

11 Jan '02

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.

3 4

RFE: turn off Bounce Disable notifications
by Dan Mick 11 Jan '02

11 Jan '02

these are unconditional right now, and should be a GUI-selectable item. If I can find the time I'll try to hack up a patch.

1 0