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

donal.hunt2@mail.dcu.ie donal.hunt2@mail.dcu.ie
Mon, 22 Oct 2001 18:39:17 +0100

comments from a LDAP POV below...

Date: Sun, 21 Oct 2001 23:37:02 -0700
From: Chuq Von Rospach <chuqui@plaidworks.com>
To: "Barry A. Warsaw" <barry@zope.com>, <mailman-developers@python.org>
Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1
alpha 3

>On 10/21/01 11:17 PM, "Barry A. Warsaw" <barry@zope.com> wrote:
>> http://sourceforge.net/project/shownotes.php?release_id=3D58074


>> - Membership Adaptors
>> o Internally, mailing list memberships are accessed through a
>> MemberAdaptor interface. This would allow for integrating
>> membership databases with external sources (e.g. Zope or
>> LDAP),
>Given that, if someone wants to write a fully external authenticator, is=

>possible to completely disable mailman's interface for a given list (or
>lists?) Including things like monthly password reminders?


>From working with porting Mailman 2.0.2 to using LDAP for (part) authenti=
I found I had to do a quick check and see if the user was being stored in=

LDAP or in the Mailman structure.  If it was a LDAP authenticated user,
the generated webpage told them that the password for the specific user
was unavailable (due to being stored in LDAP).  The user got a similar re=
if the request was via email.

But users were still able to change options like "nomail", "digest", etc
by using their LDAP attributes for authentication/storage.

However this involved severe hacking of the Mailman modules (more than I
liked) and from what I've read so far Mailman 2.1 won't need this hacking=

- I'm still waiting for resources to be assigned so I can start working
on an LDAP authenticator for 2.1 (next day or two hopefully).

The source for the 2.0.2 hack is available, but I want to finish cleaning=

it up before I give it to people (again I'm waiting for resources). :(

Hope that gives an insight into what I'ld be looking for.  One of these
would be  the possibilty of authenticating against one or more data sourc=
- eg LDAP for local users and a Python pickle or marshal for remote users=
 For example all details for all the users in a university (in my case)
would already be in a directory server, but remote users (members of list=
hosted by the university for example) would be stored seperately.  Of cou=
we could make authentication a "per-list" setting.  This is rapidly getti=
into Mailman v3 territory so i'll stop here.


Donal Hunt