Skip to Content.
Sympa Menu

en - [sympa-users] mail attributes and private scenarios

Subject: The mailing list for listmasters using Sympa

List archive

Chronological Thread  
  • From: Jeff Abbott <address@concealed>
  • To: address@concealed
  • Subject: [sympa-users] mail attributes and private scenarios
  • Date: Tue, 30 May 2006 10:52:22 -0400

Sympaers,

I've been trying to figure out a good solution to this problem -- maybe there isn't one, and users are just going to have to deal with it -- and I'm hoping others might have solved similar problems in the past. Most of our lists default to private sending scenarios to prevent spam, abusive external users, etc. Duke users also tend to have multiple addresses, with many users electing to use a full name alias (e.g. I use address@concealed) but also equally able to use their user ID (e.g. address@concealed). The former is often what's set as the user's mail attribute in the directory, but many of them send messages using the latter. This means, of course, their messages get rejected, they get confused, and I get email.

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?

Thanks,
Jeff



Archive powered by MHonArc 2.6.19+.

Top of Page