On 10/22/01 9:39 AM, "Barry A. Warsaw" <barry@zope.com> wrote:
CVR> Is the Urgent: header stripped as it passes through Mailman? CVR> What happens when a regular user tries to put an Urgent: CVR> header on a message as a non-admin?
Just like an Approved: header, it's always stripped because it contains a password.
Should these be sent to the admin as well as a possible security breach attempt?
Hmm, let me try to untangle a couple of issues.
First, this adaptor API is only for membership-related information.
I'm actually thinking of moving the membership data completely out of Mailman and having mailman act as a slave to an outside system.
Two reasons:
think of a corporate list server, where subscriber lists are created based on organization charts and aren't under the control of the list server completely.
think of an integrated community, where you want a single subscriber interface, but multiple systems, including (but not limited to) a mail list system.
This means that if you supply a different backend implementation for the API, it's all or nothing: you're responsible for the entire API and managing all the member-related data.
Okay, that's where I'm headed. Except I want to go a little further, which is turn off mailman's interface completely, hopefully on a per-list basis. You could, I suppose, make the list private on the mailman side, but there are still issues, such as header/footer data, etc...
One other thing that Control.com sponsored, but which I forgot to add to the NEWS file, was an API for an external process to post messages to a list, and to specify the explicit list of recipients in the posting interaction. What this means is that you could create a list, say "employees@dom.ain". Then when you want to post a message to this list, you simply create the message, and determine what the explicit list of recipients is, then send both to the posting code. With the list-extension mechanism, you could also completely defeat the U/I (I think) so that Mailman would indeed act as a posting slave.
Okay, neat. That seems pretty close to what I'm thinking. Close enough for government work, at least. So you could use extend() to gut mailman's interface, and then write an external that would, say, look thing up out of an LDAP that interfaces to the corprate database...