The bug still exists and it appears in real-world situations:
- using libnss-ldap
- configuring sendmail to do smtp auth as client
First, libnss-ldap will call sasl_client_init() providing a global
callback function list; it will also call more sasl functions
Much later sendmail wants to authenticate and calls sasl_client_init()
again with a different global callback list. This new callback list is
of course important... The code in sasl_client_init() looks like this in
2.1.22.dfsg1 (and also in 2.1.19):
if(_sasl_client_active) {
/* We're already active, just increase our refcount */
/* xxx do something with the callback structure? */
_sasl_client_active++;
return SASL_OK;
}
So the problem is known.
Anyway, trying to use sendmail with smtp auth as client on a machine
with libnss_ldap will not work. Worse, the reason will be completely in
the dark since auth.log says
Nov 16 00:24:19 localhost sm-mta[9890]: No worthy mechs found
and mail.log says
Nov 16 00:24:19 localhost sm-mta[9890]: kAEFnQqh004922: AUTH=client,
available mechanisms do not fulfill requirements
which is both *very* misleading.
Moritz Both
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
