On 2017-12-27, Sebastian Arcus via Exim-users <[email protected]> wrote:
>
>>
>> A deferral is no final decision. So the ACL condition doesn't know if it
>> should return failure or success. It helps itself by returning the
>> deferral (4xx), which in turn aborts the ACL processing and returns 4xx
>> to the client
>>
>> drop message = …
>> ! verify = reverse_host_lookup/defer_ok
>> delay = 600s
>>
>> … would change it, but probably it is not your intention. I think, we do
>> not have a /defer_fail option, do we? And I'm not sure if this wouldn't
>> induce another source of trouble…
>
> Yes, a way to turn a defer into a hard fail is what I would need in this
> case. Am I correct in thinking that when the defer happens and the ACL
> processing is aborted, the DELAY gets skipped? If that is the case, is
> there any way to still process the DELAY?
the way I handle dns_again is to run the test in a warn block
and set a variable after the test,
a defer in a warn block skips to the next ACL verb
something like this:
## drop on defer
warn
set acl_c_dnsfail=yes
verify=reverse_host_lookup
set acl_c_dnsfail=no
drop
condition=$acl_c_dnsfail
## continue on defer
warn
set acl_c_dnsfail=no
!verify=reverse_host_lookup
set acl_c_dnsfail=yes
drop
condition=$acl_c_dnsfail
--
This email has not been checked by half-arsed antivirus software
--
## 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/
