[devereaux]

I'm sorry, but the problem is more complicated than that.

SSL is not mandatory on either port 25 or 587, and SSL can not be made mandatory if you follow the RFCs (it can be made mandatory if you tweak your MTA, but you may lose some mail). Advertising for SSL over DNS means you trust the DNS records - which you shouldn't without DNSSEC. Even with it, there can be workarounds that in practice will allow MITMs.

The only real solution is making SSL mandatory, and doing SMTP over SSL as in the good old days of using stunnel on port 465 to decrypt, then netcat to forward the output to the MTA running on localhost:25

But that is not standard. Maybe the efforts would be better invested by changing the standards to have a port where SMTP can not happen at all without SSL - just like port 465 was, over 10 years ago.

[schoen]

> SSL is not mandatory on either port 25 or 587, and can not be made mandatory if you follow the RFCs.

I'm well-aware of the RFC difficulty, but I don't think that the current approach of STARTTLS Everywhere is really a problem because it's effectively opt-in on both ends. The enforcement is requested by the receiving side and then implemented by the sending side.

* The receiving MTA has to proactively choose to be listed.

* The sending MTA has to proactively choose to make use of the list.

So, with the current version of STARTTLS Everywhere, only sites that deliberately choose to enforce STARTTLS will do so, and they will only do it when communicating with sites that have specifically asked them to enforce it! This would only be an RFC violation if we thought that the RFC meant to categorically forbid sites from separately agreeing to a stricter security policy.

This approach might have its scalability limitations, but I won't try to speak for my colleagues about any future steps.

[devereaux]

I agree with you, STARTTLS Everywhere is not "a problem". It is not a solution either - at best a minor improvement.

The problem is not the MTA who will chose to be listed, but those who won't be listed - the immense majority. "Scalability limitation" is certainly a more polite way to say that.

I'm sorry if my message was too blunt, but I am not sure it was worth downvoting my technical explanation just for this.

[pde3]

We think we can make a huge difference even by listing a few dozen or a few hundred of the highest-traffic email domains.

[schoen]

I didn't downvote you; I'm sorry someone else did.

The HSTS preload list also has a huge scalability problem, but it's also improved the situation about HTTPS downgrades a lot!