John Dalbec wrote:
> John Dalbec wrote:
>
>> Nigel Wade wrote:
>>
>>> John Dalbec wrote:
>>>
>>>> John Dalbec wrote:
>>>>
>>>>> Exim 4.50, 4.52:
>>>>> routing seems to work OK, but the delivery process (in some cases)
>>>>> can't seem to
>>>>> talk to LDAP. The search should return no results. OpenLDAP 2.0.x
>>>>> library, Novell eDirectory 8.7.3.4 server.
>>>>>
>>>>> exim -d -M ... yields:
>>>>>
>>>>> after ldap_url_parse: host=... port=636
>>>>> re-using cached connection to LDAP server ...:636
>>>>> Start search
>>>>> search ended by ldap_result yielding -1
>>>>> ldap_result failed
>>>>> ldap_result failed: 81, Can't contact LDAP server
>>>>> lookup deferred: ldap_result failed: 81, Can't contact LDAP server
>>>>> condition check lookup defer
>>>>>
>>>>> Any thoughts?
>>>>> TIA,
>>>>> John
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> By post-hoc reasoning I worked out that a new address rewriting rule
>>>> I had added seemed to be tickling the problem.
>>>>
>>>> ^([a-z]+).([0-9]+)@((?:...)ysu\\.edu)\$ "\
>>>> ${lookup ldap\
>>>> {user=... \
>>>> pass=... \
>>>> ldaps:///...?uid?sub?(uid=${quote_ldap:$1$2})}\
>>>> {$1$2@$3}fail}" Eh
>>>>
>>>> We plan to convert our dotted local parts to undotted local parts.
>>>> This rule is intended to make sure the dotted addresses keep working
>>>> after we change the local parts in LDAP. We won't necessarily be
>>>> able to change them all at once so we have to check the directory to
>>>> see whether the correct local part is dotted or undotted.
>>>>
>>>> Does anyone see a problem with this rule?
>>>> Thanks,
>>>> John
>>>>
>>>
>>> Are you sure the LDAP server is listening on the ldaps (i.e.
>>> encrypted) port 636, and that it and Exim are fully configured for
>>> the encryption handshake (TLS, SSL or whatever is being used)?
>>
>>
>>
>> Yes, I have other LDAP-based rules that work just fine. The rule that
>> I pasted is not actually what fails. The failure occurs in this router:
>>
>> driver = accept
>> check_local_user
>> hide condition = ${lookup ldap\
>> {user=... \
>> pass=... \
>> ldaps:///...?mail?sub?(mail=${quote_ldap:$local_part@...})}\
>> {yes}{no}}
>> domains = ...
>> transport = ...
>>
>> We have (essentially) two virtual domains. Users in domain A have
>> their mailboxes stored in one directory tree; users in domain B (but
>> not in domain A) have their mailboxes stored in another directory
>> tree. We do have some users in both domains, so given an address in
>> domain B, I have to check whether an address in domain A exists with
>> the same local part, and if so, I have to route the e-mail to the
>> domain A transport.
>>
>> This router works fine until I insert the rewriting rule above, and
>> then I get the errors shown above.
>> John
>>
>>
>
> The problem seems to be triggered when Exim routes a recipient address
> in domain B with a .forward file of the form "blah@???,
> \a.b@domainB". Exim runs through the address rewriting rules from the
> top when it processes the .forward file and the LDAP searches start
> failing after the problematic rewriting rule.
>
> I don't think it's an LDAP server issue because I wrote a Perl script to
> perform the same sequence of searches and it worked just fine.
>
> Any ideas?
> Thanks,
> John
>
The problem seems to be related to a non-cached search occurring in a
subprocess. Maybe OpenLDAP or OpenSSL is keeping some state information that
gets lost when the child process ends? Is that possible?
Thanks,
John
