OSNews

The problem there is that confidential information is frequently transmitted via e-mail. In fact it's pretty standard for things like Passwords and user IDs to be sent this way. Let alone more confidential data sent by users who don't understand the protocol.

Furthermore, it would make a great deal more sense to encrypt as standard at the protocol level rather than add another layer of abstraction at the user level

You're both right, and you're both wrong.

Keeping messages confidential requires encryption at the endpoints. That means clients need to handle it. Servers are not involved. In my opinion, not only should clients make this easy, it really needs to be available for all files regardless of method of delivery. It doesn't matter if you e-mailed it to me, I downloaded it from a web site, or you gave me a thumb drive, we need some way to prove who we are and keep the file secret from everyone else.

TLS does have a role in e-mail, and it's not encryption. TLS provides authentication. Authentication is arguably the largest problem with e-mail. The original protocol simply trusted clients and servers not to lie about who they were, and that's why we have spam. If our servers only accept mail from servers authenticated with certificates, then blocking spam is easy.

Yes, exactly my point! Why then would you trust your post boy (mail server) not to take a peek inside the envelope if it carries sensitive information? That's actually an argument *for* end-to-end encryption!



Because TLS is necessarily two-way and hop-by-hop. You can't establish a TLS session via e-mail itself, the round-trip for salt exchange and other protocol setup would be just terrible. That's why we have things like S/MIME and PGP.

It's even worse in that encrypted SMTP connections only happen between SMTP clients and servers that support it. Meaning, your e-mail client may use TLS to connect to your SMTP server, and your SMTP server may use TLS to connect to the next SMTP server in the chain .. but there's no guarantee that the next SMTP server will support TLS .. meaning the message goes through unencrypted.

TLS, SASL, and other encryption/authentication methods are really only useful if you control *EVERY* SMTP client and server in the chain. Which really only makes it useful for remote workers connecting in to the corporate mail system to send internal mail.



I like using the "postcard in an envelope" analogy when explaining e-mail to people. It really brings home the point that "anyone handling the message en-route can read it".

Even worse, most servers default to accept any certificate from other servers regardless of expiration or validity. You will never know if someone does a MITM attack on your connections.
Server-to-server TLS is rather meaning less, really.



Not at all. TLS is essential for the confidentiality of your login credentials when you send and receive mail from the server.