On Thu, 13 Sep 2001, Reena John wrote:
> i want to thank Philip for his prompt reply. However, I find that our the
> return value from our ldap lookup does not conform to the exim
> documentation.
> alias=JohnS ou="Engineering" ou="Engineering" mail=*** mail=***
> telephonenumber="***" cn="John Smith" cn="John P Smith" cn="JSmith" cn=""
> alias=JohnR ou="Engineering" mail=*** telephonenumber="***" cn="Reena John"
> cn="Reena Philipos John" cn="Reena P John"
>
> You can see that the multiple values for cn and ou are not separated by
> commas.
That's two entries you've got there, right? Otherwise I'm worried about
the list of ou and cn attributes not being contiguous.
On re-reading the documentation, I can see that it can be interpreted in
more than one way. It says "If you specify multiple attributes, they are
returned as space-separated strings, quoted if necessary, preceded by
the attribute name." Hmm. For a start, it omits to say that the name is
followed by "=". It doesn't really say anything about the case with
multiple attributes when an attribute has multiple values.
One might assume, as I think you have, that you would get comma
separated multiple values, e.g.
cn="John Smith", "John P Smith", JSmith, "" alias="....
Or, you might take it literally, and assume that each value is preceded
by the attribute name, as you actually got.
Looking at the code, it certainly appears to taken the latter approach.
I will enquire of the person who supplied it whether this was his
intention. I don't want to make any changes that break what other sites
are actually using.
It seems to me that both forms could be useful.
Whatever happens, I've made a note to get the document more explicit
(with examples) for the next edition.
Incidentally, looking at the current code, I see that when it got
changed, the old behaviour was supposedly preserved. If you put
#define OLD_LDAP_BEHAVIOUR
at the start of the file lookups/ldap.c, it is supposed to compile code
that behaves as before. However, I would not really recommend doing this
unless you are desperate, because it means you will have this problem
for every new release. (And I can't guarantee that it is going to work!)
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
