------- 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 <[email protected]> 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="[email protected]" x-MailAlternateAddress="[email protected],[email protected]" ... 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 > > [email protected] > [email protected],[email protected] 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
