Re: [exim] Exim not obeying "delay = " in acl_smtp_connect

Top Page

Reply to this message
Author: Jasen Betts
Date:  
To: exim-users
Subject: Re: [exim] Exim not obeying "delay = " in acl_smtp_connect
On 2017-12-27, Sebastian Arcus via Exim-users <exim-users@???> 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