Why are email transfers between mail servers often not encrypted?

Users can often choose if they want to access their email provider (such as Gmail) using a secure channel (e.g. using HTTPS).

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.

Are there any technologies that give the user some guarantees that his emails are sent securely from end to end ? Why not let the user know when encryption is not supported and let him choose if he wants his email to be still delivered ?

Solution 1:

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.

Solution 2:

Actual email traffic is often encrypted (TLS) but there are several other problems:

• Some webmail clients that show HTML-messages may be insecure although they use HTTPS, there is no hard separation between code and data in HTML for example (visual elements and javascript -> injection attacks)

  • webmail also keeps email on the server instead of downloading and storing it to the local computer

• You have no way of knowing whether TLS/SSL has been used between every step, very small servers DO NOT HAVE proper certificates

  • sender should be at least able to specify whether to accept or fail sending the email using insecure channel

• Emails lay on servers unencrypted or crypted by the server

  • you will have to trust EVERY server between you and the recipient

• Emails maybe transferred using any route, you cannot specify which servers you trust (ip address ranges, ASes, countries, domains..)

• Large email servers don't use multiple different certificates and do not change them often enough (?)

  • it is maybe worth/possible to brute force them (like USA/UK etc have tried?)

• by following traffic they know when email has been sent and something about the recipient (which servers communicate between each other)

  • darknets hide these correlations

• openssl implementation was/is a mess

  • there maybe bugs

• you have to trust to the certificate authorities signing the certificates

Solution 3:

It is 2021 and the problem basically does not exist any more. Emails are now transferred almost always encrypted and no longer sent in plain text.

This answer is based on Wikipedia Email encryption. According to the article:

One of the most commonly used email encryption extensions is STARTTLS. It is a TLS (SSL) layer over the plaintext communication, allowing email servers to upgrade their plaintext communication to encrypted communication. Assuming that the email servers on both the sender and the recipient side support encrypted communication, an eavesdropper snooping on the communication between the mail servers cannot use a sniffer to see the email contents. Similar STARTTLS extensions exist for the communication between an email client and the email server (see IMAP4 and POP3, as stated by RFC 2595). STARTTLS may be used regardless of whether the email's contents are encrypted using another protocol.

The encrypted message is revealed to, and can be altered by, intermediate email relays. In other words, the encryption takes place between individual SMTP relays, not between the sender and the recipient. This has both good and bad consequences. A key positive trait of transport layer encryption is that users do not need to do or change anything; the encryption automatically occurs when they send email. In addition, since receiving organizations can decrypt the email without cooperation of the end user, receiving organizations can run virus scanners and spam filters before delivering the email to the recipient. However, it also means that the receiving organization and anyone who breaks into that organization's email system (unless further steps are taken) can easily read or modify the email. If the receiving organization is considered a threat, then end-to-end encryption is necessary.

The Electronic Frontier Foundation encourages the use of STARTTLS, and has launched the 'STARTTLS Everywhere' initiative to "make it simple and easy for everyone to help ensure their communications (over email) aren’t vulnerable to mass surveillance." Support for STARTTLS has become quite common; Google reports that on GMail 90% of incoming email and 90% of outgoing email was encrypted using STARTTLS by July 24, 2018.

In 2018 the situation was that 90% of email seen by Gmail was encrypted. In January 2021 the Google Transparency Report - Email encryption in transit has these statistics:

Outbound email encryption: 91%
Inbound email encryption: 93%

The vast majority of mail-servers are already using encrypted communications, and this number is increasing every year.

STARTTLS solved the problem and works without forcing all email clients to encrypt their emails. Communications between servers are now almost always secure, even if client-to-server communications are not always encrypted.

Solution 4:

They are. Or very often they are.

Either through SSL, or TLS.

--- 220 mail.ovalpowered.com ESMTP Exim 4.72 Sun, 20 Mar 2011 17:09:56 +0000
+++ EHLO test
--- 250-mail.ovalpowered.com Hello vpnhub.sqsol.co.uk [213.229.101.173]
--- 250-SIZE 52428800
--- -PIPELINING
--- -AUTH PLAIN LOGIN
--- -STARTTLS
--- HELP
+++ STARTTLS
--- 220 TLS go ahead

Or if you're really paranoid there's PGP or GPG.