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

[donal.hunt2@mail.dcu.ie]

comments from a LDAP POV below...

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

 <snip>

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

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

 <snip>

>From working with porting Mailman 2.0.2 to using LDAP for (part) authenti=
cation,
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=
ply
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=
es
- 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=
s
hosted by the university for example) would be stored seperately.  Of cou=
rse
we could make authentication a "per-list" setting.  This is rapidly getti=
ng
into Mailman v3 territory so i'll stop here.

Regards 

Donal Hunt

--__--__--