On 27/12/17 13:57, Heiko Schlittermann via Exim-users wrote:
> Sebastian Arcus via Exim-users <exim-users@???> (Mi 27 Dez 2017 13:39:26 CET):
> ….
>> Thank you for the suggestion. I think the following are the relevant lines
>> of output:
>>
>> </snip>
>>
>> processing "drop"
>> 5976 message: Reverse DNS record incorrect or missing
>> 5976 check !condition = ${if eq{$received_port}{587}}
>> 5976 =
>> 5976 check !verify = reverse_host_lookup
>> 5976 looking up host name to force name/address consistency check
>> 5976 drop: condition test deferred in ACL "acl_check_connect"
>> 5976 LOG: connection_reject MAIN REJECT
>> 5976 H=[196.207.181.208]:57629 I=[192.168.15.2]:25 temporarily rejected
>> connection in "connect" ACL: host lookup deferred for reverse lookup check
>> 5888 child 5976 ended: status=0x0
>> 5888 normal exit, 0
>>
>> </snip>
>>
>> I'm not quite following the above - does it mean that the reverse dns lookup
>> fails somewhere, or is it deferred for some reason by the remote end? No
>> mention of the DELAY anywhere, though
>
> The PTR *or* the A lookup seem to be deferred for some reason (I'm not
> sure, if I could tell, which of these two queries fails).
>
> 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?
