Agree and I am not saying it’s good. Just saying that you pulled the MX domain you are connecting to from an unsecure DNS entry so if DNS is mitm-ed, the attacker might as well make you submit the email to its own server then deliver it to the recipient.
[edit] actually looking at the RFC it relies on a TXT record before the https policy is even fetched.
You're requesting https://<domain>/.well-known/mta-sts.txt. If you've got that info, then A dns record was correct and you must use STARTTLS on MX record. Even if attacker replaced MX record, he can't MITM TLS session, so connection is safe. I think that it's pretty secure setup. But yes, so much hoops instead of deploying dnssec everywhere, it's a shame. DNS is hierarchical and it's very natural to use cryptography there.
Port 465 is for mail submission. It's there for authenticated communication between clients and servers. It has never been used for communication from server to server and was never intended to be. Port 587 has the same purpose (mail submission), but has a plain text protocol specific negotiation at the beginning which matches that for server to server mail transfer on port 25.
True, but the underlying question is still interesting: why isn't there a similar TLS-only port for MTA-MTA and we all agree to try to connect there first
Port 465 is unnecessary once STARTTLS was invented. It has exactly the same upside / downside but it wastes an entire TCP port and an entire RTT plus maybe a timeout to signal (non-)availability.
So it makes sense to deprecate this use of port 465 and just tell people to use STARTTLS.
The STARTTLS vulnerability to downgrade attacks is a significant downside that port 465 doesn't have (if using modern TLS protocols at least). My opinion is that perhaps the severity of the STARTTLS downgrade attack wasn't that much considered when port 465 was deprecated.
Downgrade attacks are no easier for STARTTLS than for TLS-on-connect. If you were deploying TLS-on-connect you'd have to do it in one of two ways:
1. Senders should first try TLS-on-connect, and if it's not available, fall back to STARTTLS.
2. Senders should only do TLS-on-connect with no fallback
If you do #1, then a downgrade attack still exists because an attacker can just block port 465 and then interfere with the traffic on port 25 (or put a fake SMTP server on that port if one doesn't exist).
If you do #2, that's no easier than just mandating that STARTTLS on port 25 is required.
The alternative to all of this is to find some out of band method for a receiver to state that TLS should be available (TLSA / MTA-STS), and if it's not then something is being tampered with. That way, a sender can look up that information and then choose to do #2 for that particular receiver. Again, in that scenario it makes no difference if we're talking TLS-on-connect or STARTTLS. Given we can't make the whole World switch to "must always be encrypted" at the same time, this is the only practical way forward.
I wrote "It has exactly the same upside / downside" and yet almost immediately I get a reply in which the author with no self-reflection has imagined there are additional downsides to STARTTLS.
As others have explained an on-path adversary who'd be able to rewrite packets in order to stop STARTTLS can even more trivially block port 465 altogether. In fact cheap appliances can do the latter but can't do the former, so if anything STARTTLS very slightly improves this.
If you are imagining "Well I could have a policy of only using port 465" well, sure, but you could just as easily have a policy of requiring STARTTLS. In both cases an adversary can deny you, and your only options are to re-think your policy or give up and not deliver email.
The only (weak) argument I can find is that since servers that had a port 465 open also had to keep a port 25 open for compatibility, you could perform the same downgrade attack by blocking connections to port 465, which would result in a submission to the port 25. But that's a "if it's broken let's make sure it remains broken" kind of argument.
[edit] actually looking at the RFC it relies on a TXT record before the https policy is even fetched.