Remember broken TLS not working

Hi!

We’re seeing issues with a receiving party, they have a BadSignature:
KumoMTA internal: failed to connect to any candidate hosts: All failures are related to OpportunisticInsecure STARTTLS. Consider setting enable_tls=Disabled for this site. mail.xxxx.x.\/xxxxxxx:25: EHLO after OpportunisticInsecure STARTTLS handshake status: failed: invalid peer certificate: BadSignature

Even though we have remember_broken_tls set to the default 3 days, it appears to fail to deliver.

Is there anything we might have missed for a case like this?

One thing you can do is to evaluate if that shaping is in effect for that domain using resolve-shaping-domain

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

I use this and it seems to work for all providers. Keep remember_broken_tls to a smaller value because sometimees you might have issues connecting to big providers like Gmail and it will pretty much stop the queue as they enforce TLS. With a 10 minute value, it will only block the queue for a maximum of 10 minutes.

Ahh also a good one to keep in mind, thanks :slightly_smiling_face:

I see it seems to have worked; is it possibly the case that it only remembers broken TLS per egress IP?

It seems to be applied to this domain, but only after the second failure it succeeded and when looking at the events, it went from:
IP A > fails
IP B > fails
IP A > succeeds

All shaping is based on the queue which is typically a compilation of domain or MX, source ip, and other factors. The behaviour you noted is expected

Ahh check

I think I just found the solution :grinning_face_with_smiling_eyes:

opportunistic_tls_reconnect_on_failed_handshake set to true is possibly the best option here?

At least according to the docs it sounds like it is

This might be helpful

Queues - KumoMTA Docs Queues - KumoMTA Docs

Do you have any tips on how to use it? Did it resolve your issue?

Yea, in our case it is more important to deliver. In practice we only see this at some self-hosted servers or those of shared hostingproviders where the SSL certificates do no match the hostname people provide. So setting it to true fixed it :slightly_smiling_face: