[Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3

Barry A. Warsaw barry@zope.com
Sat, 27 Oct 2001 12:17:27 -0400

>>>>> "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