We always had connectivity issues to a particular service as shown in the error below.
KumoMTA internal: failed to connect to any candidate hosts: All failures are related to OpportunisticInsecure STARTTLS. Consider setting enable_tls=Disabled for this site. ResolvedAddress { name: \"mx01.cbsolt.net.\", addr: 185.97.217.85 }:25: EHLO after OpportunisticInsecure STARTTLS handshake status: failed: received fatal alert: HandshakeFailure, ResolvedAddress { name: \"mx02.cbsolt.net.\", addr: 185.97.217.87 }:25: EHLO after OpportunisticInsecure STARTTLS handshake status: failed: received fatal alert: HandshakeFailure
However, we are able to circumvent the issue by specifying the following parameters in the configuration. However, enable_tls is not enough by default, it only works when we specify remember_broken_tls.
The usage of this configuration helps, but there’s a drawback - occasionally, when sending emails to Gmail, I assume there’s a TLS handshake failure and KumoMTA seems to remember that, and then pretty much, the whole queue breaks down because Gmail requires STARTTLS and it seems to remember the handshake failure for 3 days. So some of the emails in the queue fail with the following message:
KumoMTA internal: failed to connect to any candidate hosts: tls policy is Required but STARTTLS was previously found to be broken and remember_broken_tls is set
I’ve removed remember_broken_tls from the configuration, but that doesn’t help. It has solved the issue with Gmail, but I still face issues connecting to the specified service, cbsolt.net. What could be the issue?
Rustls is pretty pedantic. The small DH key could possible be a problem, but I am not sure.
You could potentially try using the OpenSSL option instead. Sorry, I am mobile so that may not be the best answer.
Apparently the use of OpenSSL wrecks havoc on all emails:
KumoMTA internal: failed to connect to any candidate hosts: tls policy is Required but STARTTLS was previously found to be broken and remember_broken_tls is set, tls policy is Required but STARTTLS was previously found to be broken and remember_broken_tls is set, tls policy is Required but STARTTLS was previously found to be broken and remember_broken_tls is set, tls policy is Required but STARTTLS was previously found to be broken and remember_broken_tls is set, tls policy is Required but STARTTLS was previously found to be broken and remember_broken_tls is set
If I set enable_tls to OpportunisticInsecure and set the value of remember_broken_tls to a few days, it works great for some broken sites. However, in rare cases, a connection to Gmail.com can break due to an issue with SSL handshake and that breaks the whole queue because Kumo only attempts to deliver the email without TLS, whereas Gmail expects a TLS only connection, so all emails to Gmail fail with some error that the TLS was previously found broken, but Gmail expects TLS or something like that.
On the other hand, OpenSSL configuration does not work at all.
Tom, I think in this case, Kumo should respect a host’s preference and ignore enable_tls for that particular host. If Gmail only wants a TLS connection, then it must always try for a TLS connection whether the TLS handshake previously worked or not.
gmail publishes an mta-sts policy that requires TLS. If you don’t want to respect their policy, you need to disable mta sts for their domain or that provider
Yeah, I wouldn’t recommend disabling MTA-STS for this. I think that the crux of this issue is that remember_broken_tls is set to an excessively large value for the bigger providers.