> An email users, using a desktop, mobile or webmail client, doesn't have > any way to know if his email messages, already received or going to be > sent, will be encrypted in-transit with SMTP STARTTLS.
If you're serious about email security, do not use a webmail client or a webmail service. Do not use a mobile client. Do not use Windows, MacOS, or Android. Do not use a GUI client. Because if you make these very poor choices, then you will not be rescued from their adverse consequences by TLS. I recommend using mutt on OpenBSD; this provides a combination of a highly attack-resistant, fast, full-featured client (that's really quite superior to GUI clients) with one of the better-hardened operating systems. Anyone who will not make the *minimal* effort required to equip themselves with a reasonably secure mail client/OS combination is going to completely undercut any external security that's in place anyway, thus there is no point in even attempting to help them. > We are missing the ability for end-user to: > - KNOW if emails being received from Mr. X has been in-transit encrypted. > - KNOW if emails he's going to send to Mr. X are likely going to be > in-transit encrypted While a mail client can discern whether mail submission is done over an encrypted connection, it can't tell whether mail transmission is or isn't. Once a mail client hands off mail to a server for queueing and delivery, the connection is terminated and the client has no visibility into the ensuing outbound connection made by that server. Similarly, a client on the receiving side which is accesssing mail (say, via IMAPS) can certainly ensure that the connection it's currently using is encrypted, but it can have no visibility into whether or not the connection used to deliver mail to that mailbox was encrypted. Yes, in the second case, a client *could* perform header analysis, and if the MTA software in play is such that it notes the use of encryption in the "Received" headers, it could parse those and report their state. However, (a) this is after-the-fact: that is, the message has to be received in order to do this (b) the message may have passed through multiple MTAs (c) any of which could have sent it over an unencrypted connection and (d) any of which could simply fabricate the headers should they be configured to do so. (d) is quite familiar to all experienced email practitioners, as spammers have been using it for many years in order to create partially or entirely fake headers in attempts to confound analysis. But it also turns up in misconfigured or broken mail systems, which are very common. And (e) if any of the MTAs used in transit has been compromised or if the host they're running on has been compromised or if they're in the cloud, then all bets are off. This is also quite common, unfortunately. Moreover, past history is not indicative of future performance: even if we draw the entirely unjustified conclusion that a message *was* encrypted during each transmission hop (based on what we see in the headers at the receiving MUA) there is no guarantee that a second message sent a minute later will also be, or that a reply will be. Encryption negotation might fail. A certificate might expire. A different receiving MX or sending system might be used. A configuration error may occur. And so on. In other words, what you're asking for is impossible in a MUA, because it can neither observe (with high confidence) nor influence what goes in between MTAs. Encrypting message content, of course, provides some insulation against this. But it still facilitates traffic analysis and I presume that everyone here is painfully well aware that metadata is often as revealing, sometimes more so, than data. (This is one of many reasons to assiduously avoid freemail/webmail/cloud-based services, as there can be little remaining doubt that they divide into two categories: those which have already been quite thoroughly compromised, and those which are going to be.) In case it's not clear, I'm not arguing against increased email security. But until people stop making the obvious and major mistakes I outlined in the first paragraph, there is little point in applying any effort to it...since efforts like trying to assure encrypted transport throughout merely wallpaper over the underlying problems and don't address them. ---rsk -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
