[Mailman3-dev] Re: Umbrella Lists --> CMS

Ian A B Eiloart iane at sussex.ac.uk
Thu Mar 18 11:13:21 EST 2004


--On Thursday, March 18, 2004 9:30 am -0500 Barry Warsaw <barry at python.org> 
wrote:

> On Thu, 2004-03-18 at 08:37, Ian A B Eiloart wrote:
>> --On Wednesday, March 17, 2004 5:01 pm -0500 Barry Warsaw
>> <barry at python.org> wrote:
>>
>> >
>> > The way I'm thinking about is that there would be an interface for
>> > asking about additional profile information about a recipient (probably
>> > using the email address as a key).  That way, information about
>> > addresses kept outside Mailman's databases could still be supplied to,
>> > say the mail-merge facility.
>>
>> Oh, no. Please don't use the email address as the key. I have many email
>> addresses. Three supplied by my employer, PLUS all the email addresses
>> in  my personal domain.
>
> I should have been more precise.  I'm thinking that the email address
> will probably the login, but that internally, there will be a member id
> that's the key.  The member id may be an integer or it may be a hash
> generated at the time the member registered.  There will probably also
> be a mapping from member id to email addresses and vice versa to
> facilitate logins, etc.
>
> The tricky part will be trying to manage a confederation of membership
> management with multiple external storages, each of which has their own
> notion of "a member id".  Right now, I'm not sure how to do that.
>
> -Barry


OK, that's good. Let me give you a scenario that might help if you can 
generalise from it. I guess you're familiar with a lot of what we want to 
do, by now...

A user logs in to our mailing list web site. What they present may be a 
username, or an email address. Let's assume that "@" is not a valid 
character in a username.

USERNAME: mailman searches our LDAP server for a user with that username. 
If found, it attempts to authenticate against the server. If not found, 
mailman moves on to the next highest priority external storage - probably 
an sql database. If found, and authenticated, mailman logs me in, and 
fetches my email aliases from the ldap server. If found and authentication 
fails, then mailman represents the login.

EMAIL ADDRESS: mailman searches our LDAP server for a mail alias, if found, 
it substitutes the associated username and attempts to authenticate. 
Failures follow the pattern above.

All this is simplified if we make certain assumptions:
    1. usernames don't contain "@".
    2. usernames are unique across all storage containers.
    3. there is an ordered list of priority for storage containers.

Assumption (2) might be relaxed by allowing the user to specify a 
container. For example, we could ask them if they are using a SUSSEX.AC.UK 
email address. Or we may use a cookie. This might allow us, for example, to 
host lists for another institution.

In that case, you might want a partially ordered list of containers (think 
MX priorities). Imagine that we were hosting lists for the University of 
Brighton, for example. We can't guarantee to have distinct usernames, so we 
would have to check BOTH containers (say, our LDAP server, and theirs) for 
username. If we find the username on both, we can give the user the 
opportunity to pick which user s/he is *before* proceeding to authenticate 
- this avoids the possibility that a user stumbles across their 
doppleganger's password.

If the username is not found on either LDAP server, we can move on to check 
(say) an sql database for other users.

We might express this thus:

container   priority
SUSSEX_LDAP     10
BRIGHTON_LDAP   10
MISC_SQL        20

-- 
Ian Eiloart
Servers Team
Sussex University ITS




More information about the Mailman3-Dev mailing list