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

[Chuq Von Rospach]

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