On Fri, Nov 25, 2016 at 12:21:01AM +0100, Heiko Schlittermann wrote: > The first smarthost mailhub1 refused right after the TCP connect with
> 4xx. The second refused right after the TCP connect with 5xx.
>
> Now Exim gave up and sent a bounce (actually didn't send a bounce,
> because this should have sent via the smarthost too, but that doesn't
> matter).
>
> This behaviour I didn't expect, did you? Because I'd assume 5xx on a
> server right after TCP connect handled the same way as TCP reset,
> considered as a host problem, that is recoverable.
No, SMTP status codes carry the application-level information, but
in some cases they MAY reflect state of networking, storage, etc.
For example, in your case each relay may verify client's ip address
in RBL. Suppose that first relay do not receive DNS response from RBL
and answers with 4xx as "temporary failure", second relay get "reject"
response and and answers 5xx as "permanent error" to SMTP client.
Mail should be rejected because relay explicitly stated 5xx.
Other errors, such as TCP connection reset with RST, or closing connection
just after open, and timeouts should be treated as temporary problems,
becase they do not provide information for application level.
--
Eugene Berdnikov
