**Downgrade attacks are active attacks.**

Active attacks are *much* easier to detect than their passive counterparts.

Opportunistic encryption, such as optional STARTTLS in SMTP, mainly protects against *passive, dragnet surveillance* where traffic is undetectably either analyzed while in transit, or stored for later analysis. You are perfectly correct that opportunistic encryption doesn't protect against active attacks. Opportunistic encryption in general simply doesn't try to protect against an attack where the attacker is able and willing to modify the data in transit; that's outside its scope. Similarly, opportunistic STARTTLS doesn't protect against a rogue mail server passing the data on to a third party; that's outside its scope.

As an example of how a MTA (Mail Transfer Agent, colloquially "mail server") can still *detect* an active attack against a STARTTLS session: a sending MTA can try to send `STARTTLS` and react to the fact that no TLS session begins in response, or that the resulting TLS session does not meet certain criteria. The initiating MTA can then make a policy decision, based on its configuration, as to how to proceed. Certainly some SMTP servers (the rather popular [Postfix being one of them](http://www.postfix.org/postconf.5.html#smtp_tls_security_level)) can be configured to require TLS when sending ([or receiving](http://www.postfix.org/postconf.5.html#smtpd_tls_security_level)) mail, either globally or [manually on a per-MX basis](http://www.postfix.org/postconf.5.html#smtp_tls_policy_maps) for outgoing mail.

While active attacks certainly do happen, there is good reason to believe that passive traffic monitoring is widespread on today's Internet. [Pervasive monitoring is an attack](https://tools.ietf.org/html/bcp188) which often can, and certainly should where possible, be mitigated.

Therefore, **even if opportunistic encryption does nothing whatsoever to protect against active attackers, [it's a win](https://utcc.utoronto.ca/~cks/space/blog/tech/CasualInternetEncryptionWant)** because it prevents passive traffic monitoring and surveillance from learning more than necessary about the data being communicated. The same argument [applies to unauthenticated HTTPS](https://utcc.utoronto.ca/~cks/space/blog/web/EncryptionWithHTTPBenefit) as well, in that even though it isn't perfect, it's still an improvement over communicating entirely in the clear from a communications privacy point of view.

There's a standard, [RFC 8461 *SMTP MTA Strict Transport Security (MTA-STS)*](https://tools.ietf.org/html/rfc8461), which can be used to specify that mail server traffic for a given domain *requires* TLS. That standard is still pretty new (the RFC is dated September 2018), so I would expect support for this to be spotty, but again, as long as everything is set up correctly, publishing a MTA-STS policy will, at worst, not be an improvement from a communications privacy point of view.

In addition, there is a standards track SMTP extension, [REQUIRETLS](https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/), which can be used to specify that transport-layer security should be prioritized over message delivery.

**Even though downgrade attacks are possible with purely opportunistic encryption, that doesn't mean that purely opportunistic encryption is worthless.** It just means that there are threats that purely opportunistic encryption doesn't address; which is no different from the fact that there are threats that *required* encryption doesn't address.