Security – Does Emailing Old Password Prove Plain Text Storage?

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:

1. When sending email, automatically fetch the public key of the recipient to encrypt the messages.
2. 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).
3. 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:

1. 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).
2. 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!

However, to the best of my knowledge, when it comes to mail-server-to-mail-server communications, most emails are still transferred in plain text and not encrypted, making it possible to anybody on the network to read their content.

Correct. SMTP, like HTTP, is plain-text by default.

These days many mail servers support TLS (previously known as SSL) for SMTP. (This includes Gmail.) However, it has the same issues as with HTTP[S]: certificates issued by well-known CAs cost money, and self-signed ones are worthless¹ for protecting against MitM attacks. If your mail server does strict validation of the receiver's certificate (like web browsers do), it might fail to deliver messages to servers that are using self-signed certificates or in-house CAs. If it doesn't, then it cannot be sure that it is talking to the right server and not an impostor.

Also, TLS is a relatively recent addition to SMTP, so even when the recipient's mail server supports TLS, the sender's might not, or it might be disabled by default.

¹ (Unless the sending server supports DANE (TLSA) and the receiving server's admin cares to publish the TLSA records in DNS. This is rarely done and somewhat tedious.)

Are there any technologies that give the user some guarantees that his emails are sent securely from end to end ?

Two most common email security standards:

• OpenPGP, based on web of trust and free to use. The open-source implementation is GnuPG (for Windows, for Thunderbird), and the original PGP has evolved into the commercial PGP Desktop.

  For web-based email clients, FireGPG is a possibility — damn it

• S/MIME, based on X.509 infrastructure. Implemented by most desktop clients (including Outlook, Thunderbird, Mail.app). However, relatively unpopular due to the same authority-based structure as TLS/SSL: signed certificates cost money, and self-signed ones cannot be reliably validated.

In both cases, encryption requires that the recipient must be already using the system and have generated/obtained a keypair. (For signing, the sender's keypair is used. The normal practice is to both sign and encrypt messages.)

Why not let the user know when encryption is not supported and let him choose if he wants his email to be still delivered ?

Usually submitted messages are queued, and neither the user nor the MTA can know whether the next hop supports TLS or not – until the message is being sent, at which point there is no reliable way to ask the user for confirmation. (They may be AFK, offline, asleep, or a script/program. If I sent the message, I want it to be delivered as soon as possible.)

Besides, with SMTP you never know if the next hop is final or if it will just relay the mail somewhere else. It's not uncommon for a backup MX to be on an entirely different network.

Therefore. end-to-end security is only possible when both sides are using OpenPGP or S/MIME.