The mailing list for listmasters using Sympa

[address@concealed]

At Case we have the problem of each user having up to 8 variations of  
their email "name" (first.last, uid, preferred first.last, and up to  
5 personal aliases).  In addition, we recently switched from  
@CWRU.Edu to @Case.Edu so we have to maintain both domains as local  
to prevent old published addresses from no longer working.  And to  
make it even worse we have to support a dozen or so old legacy hosts  
as  local mail addresses.  So each user can have up to 100 variations  
on their email address.

Our solution was to create a "getCanonicalEmail" function that does  
the following.  It takes as its arguments an email address and an  
optional full name.  It then checks the domain part of the email  
address and does the necessary conversion on that. [this is highly  
Case specific so my code may not translate well to a general case but  
a simple list of local domains and one canonical domain would work in  
most cases]  Then, if the resulting domain part is a local domain, we  
do an LDAP lookup of the address@concealed and retrieve the  
LDAP mail attribute and the users full name.  If there was a match in  
LDAP then we return the email address as found in the LDAP mail  
attribute and either the fullname passed as an argument, or the  
fullname returned by LDAP, or undef.  If there was no match then we  
return the original arguments.  I also allowed the use of uid's  
instead of email addresses.

That was the easy part.  The hard part was finding all the places in  
Sympa where an email address is entered or read and running it  
through the canonicalization function. [Note: do NOT canonicalize  
when dealing with internally stored email addresses, like deleting a  
subscriber from the database]

By modifying the code wherever an  email address was entered or read  
I was able to simplify the user experience.  For example, when  
subscribing a user or adding an owner in the web forms, all the user  
has to enter is the uid (in my case "emr") and Sympa will expand that  
to "address@concealed" and also fill in the Full Name field with  
"Edward Rynes".  Sympa will now recognize all kinds of different  
email addresses as being me. (address@concealed, address@concealed,  
address@concealed, address@concealed, address@concealed, etc....)


On May 31, 2006, at 1:18 AM, address@concealed wrote:

> Jeff Abbott wrote:
>
> > What I was hoping is that there were a way to, for instance, run  
> > an  LDAP query, the results of which are then compared against the  
> > sender  list.  All users have both address@concealed and  
> > address@concealed  listed as values in mailAlternateAddress, and it  
> > seems like there  should be a way to leverage this.  Like, for  
> > each incoming message run:
> >
> >   (mailAlternateAddress=[sender])
> >
> > returning the mail attribute, and then looking to see if that   
> > returned value fits in is_subscriber.  I was looking at the  
> > search  condition for scenarios, but that appears to only be able  
> > to check  what's in the directory, not compare it against anything  
> > or use any  returned attributes in comparison for other  
> > conditions.   mailAlternateAddress is indexed in our directory,  
> > and queries take  less than .02 seconds including connecting and  
> > disconnecting, so I  don't believe performance would be a problem.
> >
> > I'd be willing to try adding such support to Sympa, provided we  
> > could  come up with a general enough use case that wasn't so  
> > specific to the  way we do things here at Duke.  Or perhaps  
> > there's already a  workaround that I simply don't know about.   
> > Thoughts?  Questions?
>
> There is already some "alternative email feature" in the web  
> interface. Forgot it : it's really not well done and fact should  
> not be used. Alternate email is something we want to introduce from  
> scratch in Sympa : http://www.sympa.org/wiki/doku.php? 
> id=project_direction#alternate_email_addresses
>
> We will introduce more data about users in Sympa database, probably  
> with a some new columns in user_table (alternative solution is to  
> add a new table were alternative email would be a key). The  
> database structure is not allready decided and it's the first step  
> in that direction. The second step is to define our the new  
> attributes will be provisionned : by end user himself and via some  
> LDAP directory or shibboleth attribute.
>
> For the mail interface, it will not be a problem search in the  
> database alternative email for each incomming message. For web  
> interface, we must not perform this search for each hit. We will  
> use the session table. The session table will be introduce when we  
> will change Sympa login system to introduce a real sessionning :  
> http://www.sympa.org/wiki/doku.php? 
> id=project_direction#sessionning . Sessionning will use a new  
> session table (may be using one more  RDBMS table or may be using  
> 'memcached' opensource product). The session table will contain all  
> user attibutes so after tje initial login, we will not need to  
> search alternative email but just fetch them from the session table.
>
> At the end alternative email will be availible in scenario so you  
> will be able to define a private list that accept message from  
> anyone if the sender email is a alternative email of one of the  
> subscribers. (idem for sympa action).
>
> If you want to contribute, please submit first a description of  
> your project starting with a definition of data-structure.
>
> Regards
> Serge

Attachment: smime.p7s
Description: S/MIME cryptographic signature