[Exim] Re: RFC 1485 compliant LDAP DN quoting

Tony,

> > > Have a look at the patch below with introduces a "new" eldap_quote_dn() and
> > > eliminates the special DN encoding part in eldap_quote().
> > >
> > > Please let me know, if I am right with this approach.
> >
> > Well, I'm afraid I don't know. Please can the other LDAP users on this
> > list who know about this stuff take a look and give your views.
>
> I use ldap (actually ldaps) extensively, if not exclusively, for Exim 4.

Us too. Fine.

> I now use SA-Exim 4.14/2.2 and Openldap 2.1.16.

Fine, too.

> /Everything/ in spec.txt and NewStuff works perfectly as it is. There is
> no need to change anything, whatsoever.

Ah. So please help us to get some facts straight:

1) You have some DN in Your directory, that contains leading spaces or some
of the other oddities, that RFC 1485 is targeted to? More precisely, since
"no need to change anything": You a class coverage (to be fair) for each and
every legal character in a DN being matched in a DN lookup successfully?
Right?

2) You can address such a DN (not in the query filter part, in the DN part!)
by using the recent quote_ldap_dn with the backslash encoding?

3) Can You please provide us with (an) example(s) for this success (probably
dapsearch-result(s) and the ldap-lookup). I am eager to know what kind of DN
is told by You to be covered by the current implementation of ldap_quote_dn.

This whole success report puzzles me a bit, because backslashing characters
is part of RFC 2254 and works perfect in this context, but is *not* part of
RFC 1485, where there is *no* way to quote "special" string characters
except for some rather special ones (called <special> in the ABNF). The
Whitespace (except for <CR>) is *not* part of it.

Probably You may want to prove me wrong. As far as I can see, only a
sedecimal encoding is RFC1485 compliant and universal (one class fits all).

You may agree that it would be no good idea to risk our gig order directory
for some experiments with the live cluster, but I'll try to create a test
case on my workstation ASAP. Just for the real truth seekers.

To be precisely: Our current problem is not LDAP data with pathological
characters to be matched, but local parts from nevelope senders with leading
white space (and worse) to be not matched. Eventually this would work with
the current ldap_quote_dn both ways, but ot should do so as implmenetation
of the RFC, not as a side affect, of course.

> With my deepest respect: those who haven't been able to make it work as
> it is with 4.14, and as it has been since 4.04, have neither read the
> docs / consulted the list archives, nor tried things out for themselves,
> sufficiently.

No comment.

<gall>cluster bombing is getting popular these days</gall> (sorry, could not
resist)

- Marian