mirror of
https://github.com/mailscope/kumomta.git
synced 2026-08-25 13:48:18 +00:00
Wez Furlong
b0c6b1cf6a
Some sites are non-conforming in their behavior when they have a policy that issues a transient failure and then snips the connection without explicitly issuing a 421. This can cause "splash damage" where a message is transiently failed and the connection snipped "disgracefully" and a subsequent message that is due to go out on that same established connection encounters a transport error when the RSET part of the pipeline is sent. This commit provides methods on the ClientError and Response types to help reason about whether the response might be specifically about the message being delivered, vs. more of a transport error. The gist of this check is that timeouts and transport level stuff where there is no protocol level response are not considered to be due to the message. Protocol level responses prior to MAIL FROM are similarly considered to be more like transport errors. The functional change in this commit is: * If we get a transport-ish error and we have more candidate hosts available in the connection plan, then after logging a TransientFailure for the error we just encountered, we'll push back the message to be tried again on the next connection that we open in the current session. * For timeout errors specifically, this behavior is gated behind a try_next_host_on_timeout boolean option.