Hi Tony,
Hi Philip,
> Well, it forced me to spend a useless morning reading really old and
> somewhat newer x500 and ldap rfcs I'd really rather not know about
> (since simple quote_ldap works for me with Relative Domain Components -
> RDNs - like "cn=frigg+uid=xizzy" together with Exim 4.14.) At least I
> know that rfc1485 from 1993 exists, is obsolete and was replaced by
> rfc1779 from 1995, which essentially says the same, only a little more
> of it.
That's too bad, but thank You nevertheless for the pointer. I'll check it of
course.
> If (Exim 4.14, Openldap 2.1.16, which is LDAPv3 with v2 allowed in my
> setup) I do 'exim -bt xizzy', Exim knows it's really Frigg (an ldap user
> and my pedigree Norwegian Forest, NFO) and where to send his mail.
>
> Killing two birds and replying both to Marian's and your posting:
>
> Marian's obviously tried and quote_ldap_dn doesn't work for him/her. But
> quote_ldap_dn and quote_ldap do different things. So maybe he/she would
> like to try again with quote_ldap and see what happens. I have no idea
> what basic LDAP he/she is using, nor how it reacts to Exim's parsing.
Basically it is openldap 2.1.5 we use, just because it is suitable (after a
couple of patches like with all it's predecessors) until now. The next
update will come sooner or later :-/
Since there is trouble with my quoting recommendation, I withdraw it and
examine the gory details within the openldap source.
In fact, the lattice-scheme does not work like expected. In a test server I
have something like this
dn: cn=EMO,dc=addressbook,o=mehome
givenName: EMO
cn: EMO
objectClass: top
objectClass: person
Ok, but I cannot address it in ldapsearch using the lattice-attribute-form:
ldapsearch -h localhost -p 22040 -b 'cn=#454D4F,dc=addressbook,o=mehome'
The result will be "no such object".
Sorry for the trouble. Probably we'll see a clean solution.
--
Mit freundlichen Gruessen / Yours sincerely
Marian Eichholz
