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…
Just my guesswork.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
