It's worth also mentioning MTA-STS [1], currently a draft. It provides a mechanism for domains to declare a STARTTLS requirement via a file at https://<domain>/.well-known/mta-sts.txt. It's backwards compatible and opt-in. There seems to be some testing already going on [2].
I am curious as for why they would use https for that. It sounds like something that should be better stored in DNS. Unencrypted but your MX entries are not more encrypted.
Agree and I am not saying it’s good. Just saying that you pulled the MX domain you are connecting to from an unsecure DNS entry so if DNS is mitm-ed, the attacker might as well make you submit the email to its own server then deliver it to the recipient.
[edit] actually looking at the RFC it relies on a TXT record before the https policy is even fetched.
You're requesting https://<domain>/.well-known/mta-sts.txt. If you've got that info, then A dns record was correct and you must use STARTTLS on MX record. Even if attacker replaced MX record, he can't MITM TLS session, so connection is safe. I think that it's pretty secure setup. But yes, so much hoops instead of deploying dnssec everywhere, it's a shame. DNS is hierarchical and it's very natural to use cryptography there.
Port 465 is for mail submission. It's there for authenticated communication between clients and servers. It has never been used for communication from server to server and was never intended to be. Port 587 has the same purpose (mail submission), but has a plain text protocol specific negotiation at the beginning which matches that for server to server mail transfer on port 25.
Port 465 is unnecessary once STARTTLS was invented. It has exactly the same upside / downside but it wastes an entire TCP port and an entire RTT plus maybe a timeout to signal (non-)availability.
So it makes sense to deprecate this use of port 465 and just tell people to use STARTTLS.
Additionally, MTA-STS has recently been approved as Proposed Standard, so we may see increased support for it in the near future. [1]
The key advantage of MTA-STS is that it can be deployed quickly, without almost any disruption of the already-deployed infrastructure. Of course DNSSEC and DANE already solve the same problem, but MTA-STS is the designed by and for people who don't want to use DNSSEC.
The EFF's efforts are complementary to MTA-STS. As schoen mentioned elsewhere on this thread, in the early days it's probably useful to have a preload list. (That said, I am not sure why they feel it necessary to cast MTA-STS in negative light: "[...] so the sender will never know the recipient supports STARTTLS." [2] They should explain that there MTA-STS is trust on first use and has a memory effect, exactly like the well-accepted HTTP Strict Transport Security.)
We added support for MTA-STS testing to Hardenize just today, along with a blog post that explains the background and explains how to deploy it. [3] (Disclaimer: Hardenize founder.)
This is interesting, I have been wondering for a while if I could disable plaintext email delivery on port 25 and just leave encrypted submission on port 465.. Would I be losing mail ?
Yes, unfortunately you'd be losing email. Port 465 has been deprecated a while back (1997).
I guess that's the problem - there is no practical way to disable plaintext email from the start. You may always need to accept the connection, see if the client will STARTTLS, disconnect if they do not and hope they don't re-try and keep hammering your servers with the same message, the error message "hey, i'm not accepting plaintext" will most likely get ignored.
You need to have a correctly formatted DNS TXT record at _mta-sts.example.com first. They'll check for that, and only if it exists will they bother attempting to fetch your mta-sts policy from https://mta-sts.example.com/.well-known/mta-sts.txt