Andre Oppermann <[EMAIL PROTECTED]> writes: > Are the CommonName variants stored as such in the X.500 or LDAP > directory? Or do you put every possible combination into 'mail' and > 'alternateMailAddress' fields in the ldap entry?
I pull CommonNames from X.500 then populate qmail-ldap's LDAP with email equivalents. > Probably the best way to handle such a situation is to make an account > '[EMAIL PROTECTED]' which will catch all email to unknown users. > It could then do a program delivery with an expanded lookup with > extented attributes. Ah, that seems pretty clean. If the username portion matched a (ambiguous) firstname or lastname, it could send a bounce with full-name info based on LDAP attribute query. If it didn't match, it would send a "no such user" message. It would be more efficient, however, if it could distinguish between no match at all, and an ambiguous match -- like on a common last name like [EMAIL PROTECTED] In the first case, I can send a bounce immediately, not having to go to a catch-all account. If I can detect ambiguity then I can do the additional LDAP queries and generate a helpful bounce message. I'd hate to have to do that extra LDAP work for every bogus probe address some spammer hits us with! > Is such a reply generated every time when not the unique email address > is used? Or is it delivering with all the variants if there is no > conflict? "Helpful" bounce is generated when a non-unique address is specified -- e.g., using only the last name which would match multiple users. If the username portion matches only one user -- even it it might later become ambiguous -- it's delivered to them. In other words, mail to "[EMAIL PROTECTED]" gets to me now because I'm the only one, but if my brother starts working here, it will start bouncing with a helpful list of both our real addresses. Mail to "[EMAIL PROTECTED]" bounces now because there are many. (In my testing just now, mail to "[EMAIL PROTECTED]" bounces with user unknown, so it looks like the X.500 system is not trying to match on FirstName -- but is on all CN variants plus SN. Sorry this is so complicated :-( > For this variant some sort of alias user should be invoked when search > hits > 1. Then same story with program delivery and extended lookup. Yeah, that would be great. > Hmm... Should be not too hard to put a such a handler into qmail-ldap. > Will have look at that tomorrow with Claudio. Would be helpful if you > could answer the questions until then. My current X.500 import needs to create a SN variant in the qldap mailAlternateAddress, in addition to the CN variants -- then I think I'll match like our existing system does. It would be great if qmail-ldap could distinguish between no matches and multiple matches, and react differently: the former would bounce, the latter would do additional work and send information in the bounce. Many thanks.
