We've recently begun seeing a very odd error suddenly start occuring in
our mailserver. It basically started happening pretty much out of the
blue on a certain day (17th Oct).

The error is that we intermittently get the following message when
trying to deliver messages:
----
SYSERR(root): Error getting LDAP results in map domaintable: Can't
contact LDAP server
----

Quick summary of setup:
- Debian Sarge system
- sendmail 8.13.4 (8.13.4-3sarge3) but also tried 8.13.8 (8.13.8-2)
- openldap/slapd 2.2.23 (deb: 2.2.23-8) but also tried 2.3.27
(2.3.27-1)

The system is not actually setup to do the full LDAP routing feature,
but rather taking advantage of LDAP based maps (ie: for domaintable,
mailertable, virtusertable). It has been running quite happily for
about 1.5 years until now.

The problem/error occurs probably 1 in 10 messages, and it does vary as
to which map it gets the error on (sometimes domaintable, sometimes
mailertable), which makes sense if it is intermittant, as it could be
on any of the multiple queries the server(s) do to do mail delivery.

The initial problem looked simple - either slapd had ran out of
connections or sendmail/slapd had ran out of file descriptors or
something similar. Turns out it's none of these, and further debugging
has caused the problem to be very weird indeed.

Basic summary is this:

1) LDAP errors are ONLY from sendmail and cannot be reproduced anywhere
else (POP3/IMAP auth is also off LDAP via dovecot, and it's fine).
Manual hitting of the LDAP server using ldapsearch from local/remote
cannot cause the error.

2) The problem is not network related, as it happens locally to
localhost.

3) If bounced through a TCP proxy, there is NO connection attempt (or
at least, no failing one) for these supposed 'Cannot contact server'
messages.

4) If the multiple LDAP host option is turned on for sendmail (using
the -h "server1 server2 etc") type options, sendmail never attempts the
secondary/tertiary hosts after the initial "failure".

5) Enabling LDAP debugging has so far shown no errors or oddities
coming up - there are simply no query or log entries for the "failed"
attempts.

We suspected this may be due to some oddity in the actual LDAP DB, so
setup a completely new LDAP server on a separate host, with a new
version of openldap/slapd (as mentioned above) AND a completely new
mailserver with a new version of sendmail.

We then trimmed down the DB to a single domain/entry in mailertable
only (no virtusertab or domaintable entries) and directed mail traffic
towards it. Sure enough, the same errors started occuring almost
instantly.

Interestingly, in the mqueue, there are many instances of
deferred/queued mail with the deferred reason being the EXACT same
error as we are getting, ie:
------
Oct 20 15:54:37 mail01 sm-mta[17965]: k9I8BQt2024259: MCI@0x818dbdc:
flags=6087c<CACHED,ESMTP,EXPN,SIZE,8BITMIME,DSN,EN HSTAT,PIPELINED>,
errno=0, herrno=0, exitstat=75, state=0, pid=0, maxsize=0, phase=client
EHLO, mailer=esmtp, status=4.3.5, rstatus=451 4.3.5 Error getting LDAP
results in map access: Can't contact LDAP server,
host=smail-cal.shawcable.com., lastuse=Fri Oct 20 14:51:47 2006
------

On inspecting these servers, they're all running sendmail (it is a
sendmail error after all), but on various different platforms/etc
including Sun ONE Messaging Server.

I've got to the stage where I've been attempting to do some fairly low
level debugging/playing round with source, but without much luck so
far. Wondering if anyone has experienced the same and/or has any
suggestions as to where to proceed from here.

very much appreciated,

Cheers,

Fenn.

fenn.bailey@gmail.com wrote:
*snippetry*

Have you considered using pam_ldap? That's what we do here, and it
seems to work just fine.

If this is a moronic suggestion, please lart accordingly.

--
Jay Chandler
Modern Day Folk Hero