On 27/12/17 13:57, Heiko Schlittermann via Exim-users wrote:
Sebastian Arcus via Exim-users <[email protected]> (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?
--
## 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/
