MTA: Requiring encryption even when Recipients Lack MTA-STS records

[stellarpower]

Hi,

I'm trying to get my head around the security options for target.remote, and it's possible I am misunderstanding how this all works, but I'm a bit confused on the architecture.

My config file for target.remote is in essence the same as in the example.

With this setup, some outgoing messages fail, and my users then are annoyed with me that email isn't being sent. It seems a common issue is that the recipient's server hasn't published MTA-STS records - I am running this server for a small organisation, often communicating with other small organisations, so not having appropriate records set happens often.

I may be wrong, but as I see it, it's 2025, so pretty much all email servers should be supporting STARTTLS by now. However the chances that the appropriate records mandating it are not published are still quite high. So basically I would like to configure Maddy never to send out messages unencrypted. If there's a STRIPTLS attempt, or the certificate does not match the host that has been dialled, then it should cancel delivery. If MTA-STS records are published, and the checks against those fail, then it should also fail. However, if the MTA-STS records are absent, I'd still like it to try to send the message encrypted, rather than treat it as a fall back to unencrypted/not authenticated, and then either consider resorting to plaintext if needed or reject it if the message headers require TLS.

This line is what I'm not understanding. The message requires TLS, but we bounce it back if MTA-STS checks fail. And simply not publishing an MTA-STS record would be one reason for this. But this does not prevent us from still checking the certificate of the remote server, right(?). And MTA-STS is vulnerable to DNS poisoning anyway, so ignoring caching for a minute, it would be just as easy to strip the STS record as it would be to spoof the MX entry(?).

Analogously it would seem unusual for my web browser to stop me from connecting to a website using HTTPS just because the site doesn't add the HSTS header. The purpose of the header is because end users don't think to type HTTPS and so they could be MITMed there. However this enforces the use of encryptio - but the lack of the enforcement doesn't prevent me from connecting securely if I ask my browser to. And I can configure my browser never to use unencrypted connections. I know this isn't a perfect analogy and the two technologies are quite different, but in a similar way, I'd like to configure Maddy to require encryption, independently of whether or not the recipient has published explicitly that they also require it. This may require changes in emersion/smtp, but would it be possible to consider MTA-STS more like the SPF and consider it as failure, neutral, and okay? I.e. at a high level,

• Look up MTA-STS records
• Connect to the server and try STARTTLS
  • If the connection upgrade does not happen, fail
  • If the certificate does not match the MX server, fail
• If the MTA-STS records were published:
  • If the certificate does not match against the MTA-STS, maybe if there was a syntaxerror in the records, or if otherwise it cannot be verified, fail
  • Else, okay - checks passed the published records
• else there were no records found, neutral - connection is secure to the domain the MX record advertises, but we have one fewer validation of that.

Are there any thoughts on this? I am not sure how the local policy ties in with the other parts of mx_auth, but my min_tls_level is set to encrypted, not authenticated, so it feels like having established a secure channel should tick that. But with requireTLS on the message being a boolean, it is needing both, when the MTA-STS check seems to me like it should be more of an authentication thing than an encryption thing. Or even if I am not totally correct here, ultimately I need to find a compromise for my users. I am not happy about any possibility of sending messages out unencrypted, as of right now I would prefer a hard bounceback in that case. However, given that MTA-STS is not itself watertight and that I can't expect everyone to be using DNSSEC, I think I can live with not passing this check.

Thanks