They can. Use strong point-to-point encryption. Of course, doing this over email/IM requires special setup that can be pretty clunky and certain habits which require discipline to maintain, and you can not rely on any third-party providers, but in principle that is possible. It's just inconvenient.
Well, it is possible. They'd need to write an IMAP proxy which can run on the end users machine which sits inbetween the client and the server and handles the encryption/decryption transparently.
I assume the person to whom you are replying was thinking more along the lines of end-to-end encryption. Email is very rarely end-to-end encrypted, and none of its standards relate to end-to-end encryption so you have to do it with other methods which are notoriously difficult to use correctly.
it's an interesting question, but i think the "right" answer here would be that the emails should (in the rfc sense of the word) be end-to-end encrypted, thus there wouldn't be a way to do this at all
There are ways that they could know. It's not terribly easy, but I think it would be ingenuous to say it is impossible. With SMTP (which could easily be part of the delivery of email), it's in plaintext going over the public network :-)
Yes. And ProtonMail could also, if they desire it (if that functionality isn't there already). Email is plaintext, if you don't want something to be read you need to encrypt it before it goes out the wire.
Email does work fine. We have a similar solution for encryption: PGP. If you do the encryption yourself instead of relying on your email client to handle it, it works fine. Type your text, encrypt it, then put it in an email; get a response, decrypt it, and read it — it's easy, and it works. People who say PGP is too hard to use are usually relying on a plugin for their email client, or some other unreliable, "encryption magic" tool that tries to hide how PGP works behind an incompatible abstraction.
Simple tools that do one thing well are almost always best.
How does that work with encrypted transport? Yahoo, Microsoft, Google and of course many others, all provide IMAP over TLS so sending email to them and receiving from them doesn't go in the clear.
Emails aren't encrypted, because there is no good way to manage trust between users at this point. PGP exists, but it's key management sucks in many ways. But look at a lot of large corporations where the trust can be bound to one service and encryption will be just one click away. S/MIME is a widely adopted standard (https://en.wikipedia.org/wiki/S/MIME) in email and works well.
Yeah, that would be a problem. I'm thinking it could just send the first part of the email address (before the @ sign) or instead just license an encrypted blob to the company which they can run.
Email can be made secure, it's just that by default it's insecure and there isn't a Google/Mozilla/Microsoft/Apple conglomerate to penalize SMTP servers by showing "Insecure" in an email display/etc.
* Most mail transport agents can require connections to use TLS, but nobody does because they're afraid of denying incoming messages and because it can be difficult to install a certificate for an MTA, so smaller providers just don't. There should be a LetsEncrypt for mail servers and by default the various package managers and distributions should not install a mail agent that allows non-TLS connections.
* It is possible to store mail messages encrypted at rest, but only by using an encrypted filesystem-- I'm not aware of any MTA that will do this itself. Obviously that needs to change.
* Providers can force TLS connections for IMAP. This is surprisingly easier these days given that most end user mail clients will auto-negotiate these connections.
There's your E2E encryption. This doesn't get you encryption on the final destination, but that's a separate issue.
I was actually thinking more the standard model, where you encrypt the email to a person's PGP key. This only works if the other person has a PGP key, though. It's the usual security <-> convenience tradeoff, unfortunately.
I think AirDrop works without a third party, but email passes through numerous hops - often in plaintext on the open Internet - before arriving at an inbox.
Maybe encrypted messaging like Signal is a better analogy. Yeah, it still passes through a third party, but they can't read it.
Very well if you use one of the many popular email or messaging services which does not use end-to-end encryption to send it or one of the popular cloud service providers that does not encrypt to data on your computer first to store it.
Not if the server admins of both sides are even remotely competent. A good "email server" will at least allow, if not enforce encryption client<->server and (if supported by the other party) server<->recipients_server.
reply