Are they seriously talking about enforcing TLS on all SMTP? That would break deliverability to a lot of servers, but would be pretty awesome. I assume it wouldn't actually check certs in any meaningful way, though, so only protecting from passive eavesdropping, but it's a big positive step.
I'm increasingly tempted to throw that switch myself, or at least start filtering all my non-TLS'd mail into a special mailbox of "figure out if I actually care if these people become unreachable in 6mo when I actually enforce TLS." Arguably it would be worse to accept the message and then bounce it, since you'd have received the text in the clear, but maybe log and send an informative-to-end-user rejection notice based on envelope, and to me?
Sadly, a client that refuses to attempt TLS negotiation will always leak the sender address of the message it wants to send you. This happens in many protocols when TLS is bolted on as an afterthought. We're actually worse off using the standardized TLS extension to SMTP here than we are with the non-standardized SSL: a connection to port 465, followed by immediate SSL negotiation won't leak anything to a passive eavesdropper.
This only gets you so far however. An active attacker can MITM the connection with ease, since there is no convention for how to verify an SMTP peer's certificate. I don't see this changing until DNSSEC is deployed in every domain you correspond with, and the peer's certificate is somehow authenticated with information from their DNS zone.
Aside: for a protocol that is designed even worse than SMTP with regards to leaking information over insecure channels, look at IMAP:
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS LOGINDISABLED] Dovecot ready.
C: 0 login user@example hunter12
S: BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed.
S: 0 NO [PRIVACYREQUIRED] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.
The stupid protocol design results in the client transmitting the user's credentials in plain text as soon as it connects to the server.
There was the IMAPS (separate port, ssl negotiation first) vs. IMAP + STARTTLS.
I'm also relatively ok with "only run imap (with tls) over a vpn, with the vpn having an endpoint on a network very close to the imap server, or on the imap server". Not really viable for SMTP inter-domain.
I wish Free S/WAN and the idea opportunistic encryption for IPSec hadn't failed to get OE widely deployed at the IP layer. Seeing who connects where, sizes of data flows back and forth, etc. would also leak information to a global passive observer, of course, but a lot less, and padding/cover traffic would be viable.
I'm increasingly tempted to throw that switch myself, or at least start filtering all my non-TLS'd mail into a special mailbox of "figure out if I actually care if these people become unreachable in 6mo when I actually enforce TLS." Arguably it would be worse to accept the message and then bounce it, since you'd have received the text in the clear, but maybe log and send an informative-to-end-user rejection notice based on envelope, and to me?