Phil Hazel wrote:
> I don't think Brian meant that. My interpretation was that the Exim code
> should fish out this pseudo-attribute, and itself return the DN (which
> it has available in any case - that's how it implements "ldapdn").
That is indeed what I meant, but I've reconsidered.
I think it would be better to avoid bastardising the LDAP URL itself, which
is a standard after all. It would cause confusion since most other LDAP
applications don't support this method of retrieving the DN.
So, perhaps a better idea is for Exim just to put the DN of the most recent
ldap search into a variable, say $ldapdn.
Then you can do:
${lookup ldap {....(uid=${quote_ldap:$local_part@$domain)}}} # whatever
... process the returned attributes
${if ldapauth {user=$ldapdn pass="$2" ldap:///}{yes}{no}
If you wanted to keep this information as a pseudo-attribute, say in
address_data, then you could tack it on yourself:
address_data = ${lookup ldap ...} dn="$ldapdn"
As a side effect, the 'ldapdn' lookup type would become fairly obsolete,
since the following two expressions would be equivalent:
${lookup ldapdn {...}{$value}fail}
${lookup ldap {...}{$ldapdn}fail}
Regards,
Brian.
P.S. Leaving the DN in $ldapdn does seem reasonably consistent with other
Exim behaviour, for example $runrc works in this way.
