mirror of
https://github.com/KumoCorp/kumomta.git
synced 2026-09-12 16:01:21 +00:00
Wez Furlong
360850dc67
The introduction of the `opportunistic_tls_reconnect_on_failed_handshake` option resulted in this regression, which is because I misread the `match` statement for this case as being only for the opportunistic case, but it also encompasses the required case. The issue is: * A site has an MTA-STS policy enforcing Required tls * The handshake with that site fails (for reasons unknown and irrelevant) * We would unconditionally (wrt. Required vs. Opportunistic) respect opportunistic_tls_reconnect_on_failed_handshake and re-queue the current address for the next connection attempt * Ordinarily, opportunistic_tls_reconnect_on_failed_handshake + the remembered broken state would cause that next attempt to downgrade to clear text, but MTA-STS forces the policy to Require * Goto step 2 (modulated by connection rate throttling) The fix is simply to only apply opportunistic_tls_reconnect_on_failed_handshake when the policy is actually opportunistic.