>>>>> "Giuliano" == Giuliano Gavazzi <eximlists@???> writes:
>> Not tested explicitly, though I use some similar but more complex
>> constructs:
>>
>> acl_callout_test:
>> warn set acl_c0 = defer
>> accept verify = sender/callout
>> set acl_c0 = accept
>> warn set acl_c0 = deny
>> deny
>>
>> Then in your real ACL (acl_check_mail, say):
>>
>> acl_check_mail:
>> ...other stuff...
>> warn acl = acl_callout_test
>> # at this point acl_c0 is set to "defer" "deny" or "accept"
>>
>> This should be a useful general method of wrapping any ACL condition
>> test in order to handle deferrals without having to use the condition
>> more than once.
Giuliano> ooh! you mean that the whole acl_callout_test will return
Giuliano> as soon as the sender callout defers?
Yes. Any DEFER return from an ACL condition on any verb other than a
"warn" causes the enclosing ACL to defer immediately. Where it's a
nested ACL, that means that the acl = whatever condition then returns
DEFER itself, with the same effect unless it is on a "warn" verb (as
it is in this case).
Giuliano> I guess that the final verb in acl_callout_test could be an
Giuliano> accept, after all the returned value seems irrelevant.
Well, you can expand on the idea:
acl_check_mail:
warn !acl = acl_callout_test
message = X-Warning: sender verify callout failed
# other stuff that might check acl_c0 to assign a score, or whatever
Here, the "message =" modifier applies only if the callout test returned
"deny", and not if it returned "accept" or "defer". In practice, a lot of
the "subroutine" ACLs I use in my own configs are written to always accept
and simply set variables to indicate the actual result, but sometimes it's
convenient to keep the accept/deny logic too.
--
Andrew, Supernews
http://www.supernews.com
