------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1521
--- Comment #4 from Heiko Schlittermann <hs+exim@???> 2014-08-29 14:17:50 ---
(In reply to comment #3)
> 1) Is it more correct (in LDAP terms) to treat the
> x-MailPrimaryAddress and x-MailAlternateAddress as
> being a single attribute, given that the lookup was for "mail"?
> Or as multiple attributes, given that the return from the library
> has multiple attribute structures?
Given that I wanted to get the values of *one* attribute, I'd expect the values
of that attribute (and it's derivatives). And since I asked for *one*
attribute, I'd expect the values only (as specified in the spec file (9.18.)).
This approach fits to the use of inheritance for filters too: given a filter
(mail=*@example.com) I'd expect all objects where mail or it's derivatives
match the given expression. And in fact that's what I see from at least
OpenLDAP.
If I need the attribute names too, I can request more than one attribute with
the query.
${lookup ldap{ldap:///<base>??sub?<filter>}}
or
${lookup ldap{ldap:///<base>?mail,dummy?sub?<filter>}}
Then Exim returns attribute/value pairs as
'x-MailPrimaryAddress="a@???"
x-MailAlternateAddress="b@???,c@???" ...
But in that case we sould ask, if the names of the derived attributes or the
name of the attribute I asked for should be returned. I'd expect the name of
the attribute I asked for. My current patch doesn't handle this case.
> 2) Is it more useful for Exim ldap lookups to work one
> way, or the other - the "other" being a return for
> this example of
>
> x-MailPrimaryAddress=a@???
> x-MailAlternateAddress=b@???,c@???
Hm, not sure. If I aske for *one* attribute in the answer, I'd return the
values of this one only. As Exim did all the time, but adding this missing
comma.
> Are both behaviours useful in different cases (should
> we provide an option switch)?
Not sure. Other opinions?
> 3) How does the initial proposed patch work for the case of a lookup
> requesting two attributes, one of which derives a pair of SUP'd ones?
> Is it dependent on the ordering of attribute structures presented
> by the ldap library? Do all the libraries we support provide
> ordering guarantees for the situation?
The initial patch doesn not change the behaviour for the request of more
attributes. The ldap library returns the attribute/values pairs and Exim
returns these pairs. I don't see any possibility for Exim to know that a
returned x-MailForwardingAddress is derived from 'mail'.
But my view is the view to -d+lookup and to 'ldapsearch' and OpenLDAP. I have
no clue how other LDAP implementations handle this inheritance. I think, Exim
should not care, it just "forwards" the results.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
