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.
Case 1: SMTP client that knows nothing about TLS
Case 2: ESMTP client that knows nothing about TLS 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:
The stupid protocol design results in the client transmitting the user's credentials in plain text as soon as it connects to the server.