"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
Me> Just like an Approved: header, it's always stripped because it
Me> contains a password.
CVR> Should these be sent to the admin as well as a possible
CVR> security breach attempt?I thought about that, but doubt it's worth it. Certainly it could be added with little effort.
CVR> Okay, neat. That seems pretty close to what I'm
CVR> thinking. Close enough for government work, at least. So you
CVR> could use extend() to gut mailman's interface, and then write
CVR> an external that would, say, look thing up out of an LDAP
CVR> that interfaces to the corprate database...Essentially yes. I did an experiment where a list was getting its membership out of a file via FileRecips.py, and I wanted to disable the membership screens (in fact the whole membership item in the admin menu). It was a little hacky, but it worked.
One thing though: while I /think/ the membership api is nicely separated and can be easily replaced, other list configuration variables are not. So you'll still see lots of direct attribute access on MailList objects. Meaning it's much tougher to divert non-membership data to an external source.
That won't change for MM2.1, but it'll likely be the bulk of the work for subsequent versions. In fact, some of the developments in Python 2.2 may make that a whole lot easier. I'm still targetting just Python 2.0 for MM2.1, but there's a possibility we'll up that to Py2.2 for later Mailman releases, especially if it makes stuff like this easy.
-Barry