The mailing list for listmasters using Sympa

[address@concealed]

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