Micha Lenk wrote:
> Hi Bill,
>
> On 08/30/2011 07:33 PM CEST +02:00, W B Hacker wrote:
>> Micha Lenk wrote:
>>> I would like to use a warn ACL to set an ACL variable depending on the
>>> result of a LDAP lookup using ${lookup ldapm{...}}. I use something
>>> similar like this:
>>>
>>> warn condition = ${lookup ldapm{...}}
>>> set acl_c0 = 1
>>>
>>> This works just fine, except for one thing: In case the lookup fails for
>>> some reason (e.g. the LDAP server is currently unreachable), I would
>>> like the entire ACL to return defer and *not* continue with the next
>>> ACL. How do I achieve that?
>>
>> A 'warn' verb ordinarily makes a log entry or sets a marker - it
>> doesn't, in and of itself, otherwise affect the flow of the smtp
>> session. Exim WILL continue to the next acl regardless.
>>
>> So ... to achieve the next part of your goal some SUBSEQUENT acl - not
>> necessarily the next immediate one - would need to be a 'defer' based on
>> whatever the warn had set into [ the | a | several] variable(s).
>
> Yes, but that is where my problem starts. If I use
>
> warn set acl_c_ad_lookup_ok = ${lookup ldapm{...}{1}{0}}
>
> then I get acl_c_ad_lookup_ok set to 0 as soon as either the LDAP server
> is unreachable, or the lookup fails to match. So, in a later 'defer'
> ACL, I cannot distinguish between temporary errors and lookup mismatches.
>
>> There can be tests for either/both fail-to-match and fail-to-access LDAP.
>
> This seems to be the problem I fail to solve at the moment. Can you
> please elaborate these tests a little bit more?
>
> Thanks in advance,
> Micha
>
You presently have a simple 'IF' of an OR situation, wherein a 'naked'
lookup, as noted, returns only pass/fail for EITHER match OR access.
As you wish to deny/accept on *match* (in available LDAP DB) OR defer on
fail to *access* the db...
- for direct use, you would need:
- a 'deny/accept' class verb (for match result)
- WITH a 'defer_ok' in the clause it heads (for access failure).
BTW - even w/o the defer_ok this seems to be inherent with SQL calls.
Ex: If the PostgreSQL engine is not up, or the sockets pool is
exhausted, Exim will issue a 'defer' with 'temporary local failure..' at
the first SQL call it hits, regardless of the specific language within
the call.
If that does not also work automagically for LDAP, (never tried it here)
then EITHER:
-run two tests. First to confirm DB is up, second to check for match.
- Optionally use variable(s) in addition to acl_c_ad_lookup_ok, as a
warn can set many variables in one go.
Look also at preloading before the lookup, and over-writing afterwards
based on the lookup return / NOT.
Bill
--
韓家標
