See https://starttls.info/check/fripost.org (ok, only one server has a D score, but still ;-))
I’m not sure what the metric is worth exactly but the tool was advertised by the EFF
Fun facts: Fripost is still doing better than chalmers.se, gu.se and goteborg.se but riseup.net does better than gmail.com!
Last modified | History | Source | Preferences
I’m all for ubiquitous encryption, but note that without TLSA records and DNSSEC, any MX is trivially vulnerable to downgrade attacks: an adversary sitting in the middle can easily strip the STARTTLS EHLO/HELO response, and force the communication to happen in the clear :-P
But I guess in this case either side could decide to stop the communication. Either because you have some add-hoc list or a heuristic like connection to @foobar.com was encrypted last time so I expect it to be encrypted forever
Doing so would violate the SMTP protocol, so it’s unlikely to be implemented on non-private MTAs. (And end users typically don’t talk directly to a MX.)
Furthermore, while ad-hoc lists are very useful on a local MTA (list the fingerprints of all known SMTPSA servers to defeat MITM attacks) or to specify an encryption policy within a given Email Service Provider (which is what we’re doing by the way), they don’t really scale. Like the heuristic you described, they also fail to properly address key rotation and/or expiration. (If the certificate has changed, how to determine if it was done by the MTA operator or if the connection is being MITM’ed? By relying on the CA model? Should the client decide to bounce the message or to send it in the clear?) Also, what if the service operator suddenly decide to remove TLS support? As far as SMTP is concerned this is perfectly fine since STARTLS is optional.
On the other hand, by publishing some (signed) TLSA records a site operator can broadcast their certificate fingerprint or signing CAs. Clients no longer have to guess a heuristic since they can rely on the information provided by site operators themselves. This is what we get when not-security-focused 30 years-old protocols are being patched up to meet today’s standards: fixes come with yet another RFC extension. And care must be taken to defeat downgrade attacks.