Easy solution: don't permit STARTTLS. Only allow email clients to connect over 993 and 465 using end to end SSL. That's what Fastmail does and I now understand why.
The article is about end clients on residential and/or business lines. There is no reason for client-to-server communication to rely on STARTTLS on port 25.
There's also no reason to discount server-to-server SMTP on residential or business lines. Especially since this is part of the larger net neutrality discussion.
I worked at an ISP and no, net neutrality aside, SMTP on residential is bad bad bad. It should be permitted only at the customer's request, but probably won't fix the fact that their subnet is on a global spam blacklist.
The point of NN is that the ISP shouldn't get to make that decision. Even "allow on request" is very problematic because it's a slippery slope. Many people run SMTP at home mostly to receive mail, because the ISP is legally obligated to retain mail logs for law enforcement etc. (EU data retention law)
Port 465 (SSMTP) is deprecated and the port number has been reassigned. The standard says to use SMTP on port 25 (with STARTTLS) for server-to-server communcation and Submission on port 587 (with STARTTLS) for client mail submission.
That's incorrect. Mail submission using SSL on port 465 is no more secure than using STARTTLS on port 587. If my client connects to my server on port 587 and does an EHLO and sees no mention of STARTTLS in the response, or can't negotiate encryption for any other reason, then it will not continue, not authenticate, and not send email. That is normal behaviour for mail clients that have been configred to use encryption. I'm not aware of any mail clients which will automatically downgrade to not use encryption when configured to use encryption.
It's also worth pointing out that if its your mail _server_ then you can also configure similar.
My exim setup doesn't even present the user with LOGIN options until after they've started TLS, so even with a bad client its impossible for them to leak their credentials.
Not quite. When the MITM strips out "STARTTLS" from the EHLO response, they could also add "AUTH PLAIN", causing your theoretical "bad client" to attempt authentication.
We were talking about a theoretical bad client. No client I have ever used to talk to port 587 would behave that way. They would all encrypt or fail. Regardless of if "AUTH PLAIN" was inserted prior to encryption and/or STARTTLS removed.
