> Additionally, servers don’t verify certificates by default. […] This is because verifying the certificate adds no security when an active attacker could just fall back to an unencrypted connection.
But surely the eventual goal is encrypted-only, at which time that’s no longer the case. Not verifying certificates feels like it may just slow down the process, because now when it looks okay you may actually find it’s not, the error is just masked for now.
I self-host my email, in part because I wanted to enforce encryption whenever I send. My server does verify the certificate of the target MX, whether it uses MTA-STS or not. Delivery fails if the certificate is invalid, and also fails if the destination (or a man in the middle) downgrades or strips STARTTLS.
In eight years, I’ve seen zero servers that refused STARTTLS, and only two invalid certificates. In both cases, the certificates were from a valid CA and weren’t expired, but the hostname was wrong. Both were due to outdated DNS records, one of which was fixed as soon as I reported it, and the other resolved itself after a few months.
Temporary states go on with a long tail. Look at the v6 transition. We're dual stack for the foreseeable future and it's my guess we'll be in partial deployment of secure mail transport for aeons.
> Additionally, servers don’t verify certificates by default. […] This is because verifying the certificate adds no security when an active attacker could just fall back to an unencrypted connection.
But surely the eventual goal is encrypted-only, at which time that’s no longer the case. Not verifying certificates feels like it may just slow down the process, because now when it looks okay you may actually find it’s not, the error is just masked for now.
I self-host my email, in part because I wanted to enforce encryption whenever I send. My server does verify the certificate of the target MX, whether it uses MTA-STS or not. Delivery fails if the certificate is invalid, and also fails if the destination (or a man in the middle) downgrades or strips STARTTLS.
In eight years, I’ve seen zero servers that refused STARTTLS, and only two invalid certificates. In both cases, the certificates were from a valid CA and weren’t expired, but the hostname was wrong. Both were due to outdated DNS records, one of which was fixed as soon as I reported it, and the other resolved itself after a few months.
Temporary states go on with a long tail. Look at the v6 transition. We're dual stack for the foreseeable future and it's my guess we'll be in partial deployment of secure mail transport for aeons.
Google is easily in a position to force it unilaterally.