From my understanding, this is pretty much the same thing as the HSTS preload list[1], except for SMTP servers instead of HTTPS servers. It has two main goals. First, encourage cert validations. If you don't validate a cert, it means nothing. Second, help prevent MITM downgrade attacks. If your server is on the list, it means it should always use a secure cert. If it isnt, then don't connect. Same thing as HSTS preload list.
You write that "If you don't validate a cert, it means nothing". I should clarify that in this situation you get opportunistic encryption. I think you understood that, but the way it's phrased isn't clear. The situation is that we get secrecy, but we don't actually know who we're talking to since we didn't validate the cert. This genuinely is better than nothing.
If we were talking to a bad guy then we're screwed. But if we are talking to our intended recipient, even if their cert is bogus, our connection is protected from bad guys on the path. The bad guys can't choose later to access that communication after all, their only opportunity is to guess we're doing opportunistic encryption and intercept the original connection to play MitM, and if they guessed wrong their hand is shown by doing that.
This situation is unpalatable even for nation state adversaries like the NSA, because they would prefer not to be seen to be meddling. Even for something like the FSB, which scarcely cares if it's seen to be meddling, it does force them to make a decision they'd rather leave until after the fact. MitM everybody (and be known to do it) or leave them alone and maybe regret that later.
> If we were talking to a bad guy then we're screwed. But if we are talking to our intended recipient, even if their cert is bogus, our connection is protected from bad guys on the path.
You acknowledge that you don't know who you are talking to. That alone proves my point. If the cert is bogus/unvalidated then its trivial for the bad guy to intercept and supply their own bogus cert instead. You are correct that its encrypted, but that means nothing when you do not know who you are talking to. It could even be a string of bad guys all capturing and injecting another bad cert. Encryption without validation means nothing.
> they would prefer not to be seen to be meddling
Time and time again ISPs have been caught injecting javascript/cookies/html inside unencrypted traffic. If ISPs are willing to do that, then why should nation states be afraid to? The point of 'bad guys' is that they can't be trusted to not do bad things.
Besides the point that bogus/unvalidated certs do nothing, it would be easier to just perform a downgrade attack if the client isn't doing any validations. Downgrade to unencrypted and easily see everything. That is why they are creating a list of services that should only allow valid encrypted connections.
Under 'about', the rationale for STARTTLS is listed, which includes, but isn't exclusive to the HSTS like list:
- Increase STARTTLS adoption
- Increase the number of mailservers that actually validate certificates
- Maintain a STARTTLS Policy List to help prevent downgrade attacks on email services.
[1] https://hstspreload.org/