[mike-cardwell]

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.