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
--
韓家標
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
