How is TLS enforced on the receiving client of an email

Question

I am writing an application that must send encrypted email to recipients. The state agency I work for recently installed a feature for outgoing email. If #secure# appears anywhere in the subject, the email will be sent via TLS.

I spent the morning reading about this. What I found says TLS applies between servers, but not between client and server. For instance if I send an email and it is flagged as TLS, my SMTP server will not send the email to the destination server unless that server accepts a TLS connection. That's good. But what about the client who connects to the destination server to download email or read online?

I do not read any enforcement exists for that. Unless I can find such exists I cannot take advantage of the email feature my state agency has installed and I will need to encrypt using zip file attachments. Is there any such enforcement?

Answer 1

There's none that i'm aware of. There's really even no guarantee that the recipient's mail server even supports SSL or TLS. As far as I know, most services that send encrypted email use a 3rd party encrypted mail service. Credit card companies and banks, for example, usually tell you to log into your account and use their built in mail service. If they want to communicate with you, they'll send you a plaintext email telling you to log into your account and check their secured message. Another way to do it is to encrypt the message using a program like OpenPGP before sending it. The recipients would then have to decrypt the message using the same. Of course, that is pretty cumbersome and unwieldy. http://www.pcworld.com/article/2472771/how-to-use-openpgp-to-encrypt-your-email-messages-and-files-in-the-cloud.html

Answer 2

"Encrypted email" typically refers to end-to-end encryption of the message itself, using something like S/MIME or PGP. This ensures that the message can only be read by the recipient — not by any of the SMTP servers involved in delivering it. (However, this means that the recipient is responsible for decrypting it, and to encrypt the message you need to have something like a PKI certificate or PGP key or password that corresponds to the intended recipient.)

TLS, in contrast, only protects a TCP connection against third-party eavesdropping; it doesn't hide the data from the computers at each end of the connection. Once your employer's SMTP server delivers a message to a remote SMTP server — even using TLS — that remote server can do anything it wants to with the message: it can forward it somewhere else without TLS, or send a copy to a government agency, or publish it on the Internet, or even change the message's content before delivering it to the recipient. Every SMTP server has to trust other SMTP servers to do the right thing.

TLS protects an individual connection between two computers. End-to-end encryption (i.e. S/MIME or PGP, or sending password-protected ZIP files) protects the entire communication path between a message sender and message recipient. It sounds like the former is what your employer's SMTP server is providing (because that's the best it can do, being just an intermediary rather than an endpoint), but the latter is what you really want.

Answer 3

You can't enforce how an SMTP message is handled beyond your own servers. Anything beyond your scope is not your responsibility and I assume that your state agency understands this. I suspect that this a CYA requirement and they can't care less what happens to the message after it has left your servers.