Bug#543325: exim4-daemon-heavy: ldap lookup with multiple filter statement failed

[Andreas Metzler]

On 2009-08-24 Tamas Bagyal <bagyi at mail.fmkorhaz.hu> wrote:
> Subject: exim4-daemon-heavy: ldap lookup with multiple filter statement failed
> Package: exim4-daemon-heavy
> Version: 4.69-9
> Severity: normal


[...]
> The next ldap lookup this gave me '-7, bad search filter' :

> 2009-08-19 16:14:16 1MdlvS-0001tR-TG == jschilling at mail.fmxxxxx.hu  
> <jano at mail.fmxxxxx.hu> R=ldap_user defer (-1):
>  failed to expand "${extract {uid}{${lookup ldap { 
> user="uid=smtp,ou=Special Users,dc=fmxxxx,dc=hu" pass=xxxxxxxx  
> ldap://192.168.1.6/ou=People,dc=fmxxxx,dc=hu??sub?(& (mail=${local_part}) 
> (host=mail.fmxxxx.hu))
>  } } } }": lookup of "user="uid=smtp,ou=Special Users,dc=fmxxxx,dc=hu"  
> pass=xxxxxx ldap://192.168.1.6/ou=People,dc=fmxxxx,dc=hu??sub?(&  
> (mail=jschilling) (host=mail.fmxxxx.hu))
>  " gave DEFER: ldap_search failed: -7, Bad search filter

> The ldap query is working fine if only _one_ statement is in the lookup. 
> (eg.: filter only mail attrib and not any other).


> This lookup (with multiple filter statement) is working on debian etch, 
> exim4 is from backports.org:

> ii  exim4		4.69-9~bpo40+1	metapackage to ease Exim MTA (v4) installati
> ii  exim4-base		4.69-9~bpo40+1	support files for all Exim MTA (v4) packages
> ii  exim4-config	4.69-9~bpo40+1	configuration for the Exim MTA (v4)
> ii  exim4-daemon-heavy	4.69-9~bpo40+1	Exim MTA (v4) daemon with extended features,

> I'm using 'apt-get dist-upgrade' to upgrade from Etch to Lenny, and the 
> query not working on the upgraded system.
[...]


Hello,

I am not completely following here: Do you experience the error with
4.69-9 while 4.69-9~bpo40+1 was working fine or are you experiencing
the error in 4.69-9~bpo40+1 but are reporting this against 4.69-9?

Could you show the respective line the (generated) configuration file
/var/lib/exim4/config.autogenerated that is triggering the error?

I am not familar with ldap beyond the very basics but I could
*imagine* that perhaps libldap itself has changed and now requires
correct quoting, where it previously was more lenient.

There has beenn a upstream report about a similar issue
http://bugs.exim.org/show_bug.cgi?id=590 which was closed with "This
appears to be an issue with what the underlying LDAP code accepts.
Closing as not an exim issue."

http://inodes.org/blog/2008/05/15/hardy-exim4-smtp-auth-and-ldap-or-debian-openssl-causes-pain/
also seems to suggest something like this.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'