Re: Sendmail 8.10.0 vs. LDAP

[Julio Sanchez <j_sanchez@stl.es>]

Les Barstow <lbarstow@vr1.com> writes:

> (which I should: defining the map on its own vs. using it directly in
> the AliasFile option is just a semantics thing - the map definition is
> exactly the same...).

I am not sure, Booker Bense had comments to the effect that it would
work in a sequence, but would not work by itself.  Has something to do
with internal map-flags in sendmail: an LDAP map could not be used for
aliases, while a sequence could.  So wrapping a sequence around the
LDAP map fooled sendmail.

But this may be obsolete, the code in sendmail has evolved a lot.

> What really irks me is that this worked (with ldapx) under Sendmail
> beta10.

You are not using a development version of OpenLDAP, are you?  Look in
the -devel archives for a recent thread I started with respect to this
(its subject is "Detecting errors from ldap_get_values" or somesuch.

The "decoding error" you get is the standard error code that sendmail
will produce while processing the results from the directory.  There
are a number of functions in the API that return NULL when either data
is exhausted or an error happens (ldap_get_values, ldap_first_entry,
ldap_next_entry, etc.).  If a NULL is returned, sendmail tries to
check the error code value.  However, it is not guaranteed to be clear
when data is exhausted and, thus, it decides there is an error while
there was none (some prior operation did produce an error of some
kind, possibly harmless).

Apparently, the API implementation they have been testing with does
clear the error code on success, while OpenLDAP doesn't.  I raised the
question on ietf-ldapext but no one, besides Kurt Zeilenga, commented
on this.  The question was essentially whether the API caller
(sendmail in this case) must clear the error before calling a function
that returns the same value both on error and on some other condition
or whether the API implementor must guarantee that the error code is
set to LDAP_SUCCESS on success.  Literal reading of the draft spec
suggests that the latter is incorrect.

You may be suffering this problem.  I settled for patching sendmail,
since it seemed the most sensible thing, but the jury is still out on
this.  You may be seeing the same or a related problem.

The reason why this problem is not very visible with OpenLDAP 1.2.x is
that sendmail clears the error in this case.  However, it does not do
it robustly, so the problem may be latent there as well.  On the other
hand, on the development versions of OpenLDAP the problem manifests
itself immediately.

Julio