With the original design of
email protocol, the communication between email servers was in
plain text, which posed a huge
security risk. Over the years, various mechanisms have been proposed to encrypt the communication between email servers. Encryption may occur at the transport level (aka "hop by hop") or end-to-end.
Transport layer encryption is often easier to set up and use; end-to-end encryption provides stronger defenses, but can be more difficult to set up and use.
Transport-level encryption 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 monitoring the communication between mail servers cannot use packet sniffing tools to view 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, 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. Mandatory certificate verification is historically not viable for Internet mail delivery without additional information, because many certificates are not verifiable and few want email delivery to fail in that case. As a result, most email that is delivered over TLS uses only
opportunistic encryption.
DANE is a proposed standard that makes an incremental transition to verified encryption for Internet mail delivery possible. The STARTTLS Everywhere project uses an alternative approach: they support a “preload list” of email servers that have promised to support STARTTLS, which can help detect and prevent
downgrade attacks.
End-to-end encryption In
end-to-end encryption, the data is encrypted and decrypted only at the end points. In other words, an email sent with end-to-end encryption would be encrypted at the source, unreadable to service providers like Gmail in transit, and then decrypted at its endpoint. Crucially, the email would only be decrypted for the end user on their computer and would remain in encrypted, unreadable form to an email service like Gmail, which wouldn't have the keys available to decrypt it. Some email services integrate
end-to-end encryption automatically. Notable
protocols for end-to-end email encryption include: •
Bitmessage •
GNU Privacy Guard (GPG) •
Pretty Good Privacy (PGP) •
S/MIME OpenPGP is a
data encryption standard that allows end-users to encrypt the email contents. There are various software and email-client plugins that allow users to encrypt the message using the recipient's public key before sending it. At its core, OpenPGP uses a
Public Key Cryptography scheme where each email address is associated with a public/private key pair. OpenPGP provides a way for the end users to encrypt the email without any support from the server and be sure that only the intended recipient can read it. However, there are usability issues with OpenPGP — it requires users to set up public/private key pairs and make the public keys available widely. Also, it protects only the content of the email, and not metadata — an untrusted party can still observe who sent an email to whom. A general downside of end to end encryption schemes—where the server does not have decryption keys—is that it makes server side search almost impossible, thus impacting usability. The content of an email can also be end-to-end encrypted by putting it in an encrypted file (using any kind of file encryption tool) and sending that encrypted file as an
email attachment. == Demonstrations ==