Re: [exim] LDAP for SMTP auth not working

Top Page
Delete this message
Reply to this message
Author: Phil Pennock
Date:  
To: Paul Muster
CC: exim-users
Subject: Re: [exim] LDAP for SMTP auth not working
On 2013-03-07 at 21:41 +0100, Paul Muster wrote:
> My messages to the list are delayed (by moderation as announced) for
> hours. So the list does not show up-to-date situation. See last
> paragraph and other mails for actual status.


I should remember to check the moderation queue before looking at the
list; I approved your mails and cleared your moderate bit.

> There was no connection. Resolution of "ldap" does not work. Using IP
> address or FQDN of LDAP server works. See my mails dated 20:43 hrs. and
> 21:14hrs. when they appear.


} nslookup and host are successful while dig fails:

You want the +search option to dig(1), to tell it to use the search path
from resolv.conf(5).

Generally, it's best to put the FQDN in, because then you can later add
TLS support and have hostnames verify. Also, it avoids fragility
elsewhere.

Anything setting RES_OPTIONS? RES_OPTIONS=ndots:0 might explain it.

Otherwise, it might be that something is doing a DNS lookup in the
daemon which has done an Exim dns_init() before LDAP is used, and that
has turned off RES_DNSRCH, and that has been persisted to also be used
by LDAP lookups.

I don't believe anything has changed recently about how dns_init() is
called and where; some minor details in how the resolver is accessed and
set, for OS portability (NetBSD made incompatible changes) but the net
effect of those is the same. Unfortunately, the Unix resolver(3)
interface uses a global _res object to hold state, so this sort of
leakage happens. Anything I do to change is likely to cause problems
for someone else.

If so, it's unfortunate behaviour from Exim, making whether resolution
uses a search path for library callouts depend entirely upon whether
it's a real daemon or not, but the most robust fix is to just use fully
qualified hostnames.

If you want to see if this is what has happened, then run a debugging
Exim on a different port (exim -d+lookup -oX 26 -bd) and it will stay
attached to your terminal, emitting log information. If you then
connect to _that_ Exim and authenticate, you should closer match the
normal flow of execution than "-bs" or the like.

Regards,
-Phil