Connectivity Issues to a Particular Service (TLS)

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.

kumo.on('get_egress_path_config', function(domain, source_name, site_name)
    return kumo.make_egress_path {
        enable_tls = 'OpportunisticInsecure',
        remember_broken_tls = '3 days',
    }
end)

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?

AFAIK, the TLS setup at cbsolt is not a problem. Looks OK

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.

You could also add a separate shaping entry for cbsolt.net to override the Gmail setting

Just following up on this..

kumo.on('get_egress_path_config', function(domain, source_name, site_name)
    return kumo.make_egress_path {
        enable_tls = 'OpportunisticInsecure',
        remember_broken_tls = '5 minutes',
    rset_timeout = '10s',
        tls_prefer_openssl = true,
        openssl_options = "ALL|ALLOW_UNSAFE_LEGACY_RENEGOTIATION",
        openssl_cipher_list = "DEFAULT:@SECLEVEL=0",
        openssl_cipher_suites = "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256",
        skip_hosts = { '::/0' },
    }

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

I could not even restart the MTA after. I had to use SIGKILL

I tried once again with just tls_prefer_openssl = true and it didn’t make any difference.

There’s something cursed about that function

It just freezes the whole MTA

I removed enable_tls and enabled tls_prefer_openssl and it started showing the following:

KumoMTA internal: failed to connect to any candidate hosts: TLS handshake with ResolvedAddress { name: \"mx00.mail.com.\", addr: 74.208.5.20 }:25 failed: error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1883:, TLS handshake with ResolvedAddress { name: \"mx01.mail.com.\", addr: 74.208.5.22 }:25 failed: error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1883:

Using openssl s_client -connect mx00.mail.com:25 -starttls smtp -bind xxxxx has no issues

Here’s the problem:

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.

This setting is a bit dangerous because it blocks the SMTP traffic to major hosts even if it was a one-off handshake error

Hmmm. Warrants some testing.

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

you probably also want a shorter duration for remember broken tls; a few minutes is probably desirable for a big provider like gmail

FWIW, a fair number of MBPs have an “enforce” policy for MTA-STS

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.

Changed it to 10 mins, so it allows broken emails to through and doesn’t block a queue for very long.

What could be the issue with OpenSSL setup tho?