Very unfortunately: No.
Mail encryption usually means public key encryption. This involves the recipient to have a public key published somewhere - this can be used to encrypt emails. That key then has a secret pair - a private key that can be used to decrypt the emails.
For mail encryption to be practical, the email client would have to be able to:
- When sending email, automatically fetch the public key of the recipient to encrypt the messages.
- When receiving email, fetch the user's private key from a designated server, preferably this would be whoever is providing the email service (usually the ISP).
- When setting up the account, automatically create and store the private key.
But the bigger problem here is the infrastructure. For this to happen, there would have to be:
- A widely used, standard way of publishing a public key associated with an email address (and this method would have to be secured via certificate system so that a third party couldn't mess with it too easily).
- A widely used, standard way of automatically creating a private key for an email address and storing it on a remote server accessible by a standard way. Preferably this server would be part of a normal service from the email provider. This server's address would then be entered as a normal procedure on the account settings of the email client, just as incoming and outgoing email servers are entered nowadays, after which the client could handle all the hassle with keys.
Another problem is that most email clients would have to be able to handle the decryption, and most email providers would have to provide the key service, for the system to be effective. Encryption needs full support at both ends of the communication. But I don't see this as that big of an issue. If an easy and practical standard appears on some clients and servers, they could advertise "we support the secure email standard", and others would probably follow suit.
Also the user would have to be notified about whether a public key is available for the recipient. A good approach would be when adding a recipient, showing a common secure symbol, like the padlock or the blue glow used in SSL/TLS connections with web browsers.
Of course, an alternate private key server, or even just a key file, could be configured to the email client so that the more paranoid user could store his/her own keys wherever he wants. For the rest of us, the email provider could still read the emails as they store the private key - but this would still make communications very secure. After all, security is often about who we can trust.
Honestly, I really don't know why this hasn't happened yet. It's not that complicated. Get on with it already!
@PeterMortensen - why did you make such minor edits to a decade old question? It pushes it to front for no reason. – lx07 – 2019-08-31T18:28:44.233
2Great answer; I think you pretty much nail the reasons why it really isn't widespread now. (Years ago I was much into PGP/GPG, and really liked e.g. KMail's built-in support for it. But even I, as a CS student, had very few people with whom I could have encrypted email exchanges. Like you say, we'd need to have most people using clients that fully support it, etc.) – Jonik – 2009-09-02T10:46:12.053
1Nice answer! "I really don't know why this hasn't happened yet": because most people don't give a damn about privacy. Just look at the internet, where people publish every detail of there life. – Dimitri C. – 2009-09-03T06:50:42.663
@Dimitri: Yeah, unfortunately you are probably right. But even though users don't care, I'd hope the infrastructure and developement people would. The system I detailed would be pretty much transparent to the uninformed user anyway. – Ilari Kajaste – 2009-09-03T07:02:07.400
I think a lot of it is because email is nearly as old as the Internet itself and such a complicated work-around is needed to layer on-top of existing technology. If we moved to delivering messages over something like XMPP we could avoid all of this, and use something similar to SSL for the transfer itself. – salmonmoose – 2009-09-06T23:35:21.047
@salmonmoose: Yeah, email is seriously outdated, and SSL transfer through all links would be a nice addition. However, that would still allow a intermediary mail server to read the emails. By the system I described, only the ISP's at both ends would be able to do that, and even that could be averted within the same system if the recipient goes through the hassle of setting up her own private key file/server. – Ilari Kajaste – 2009-09-07T07:18:48.980
I would like to participate in a design thread on this. My idea is that there would be an email framework that would be used by email clients that would handshake the keys across. No 3rd party key servers. First email to a compatible client would start with a roundtrip public key exchange, then the payload would be encrypted and sent. Subsequent emails to same clients would not require the handshake. Someone must have thought of this? – P a u l – 2009-11-01T23:51:06.310
Paul: But wouldn't that still make it mandatory to exchange the handshake without encryption or validation, in case the two recipients have never "met"? If there's no trusted 3rd party to validate this exchange, how can the exchange itself be trusted? A man-in-the-middle, or rather a malicious email server in the middle, could be presenting themselves as the other party of that handshake, even for both parties, effectively intercepting the communication transparently. Probably couldn't hide very long, since email might take an alternate route, so it's still better than nothing... – Ilari Kajaste – 2009-11-02T11:58:29.460