Once an email leaves the mail server, it essentially travels through a public network (Internet cloud) to reach the recipient server. Most organisations would like to ensure that this information travels in an encrypted form so that it cannot be tampered with or viewed by unauthorised agents.
There are three ways to do this:
1. Encrypt the channel between the sending server and receiving server:
Most MTAs are capable of using installed digital certificates to encrypt mail while sending and similarly most MTAs can receive encrypted mail. However since the mails can travel virtually anywhere in the world and can be received by a wide variety of unknown servers its not possible to enforce this encryption.
The sending server requests the recipient server for an encrypted connection and if it gets an affirmative reply, the channel is secured by appropriate handshakes. However if the recipient server is incapable of receiving encrypted traffic (rare in today’s environments), the mail is sent in plain text itself.
Essentially we are securing the SMTP traffic between the servers over port 25.
This requires that the sending server install a trusted digital certificate and do the necessary configuration to enable the MTA to send encrypted mail.
2. Encrypt the mail between two or more users.
This is a more involved and complicated method which requires the procurement and installation of PKI certificates for each user who wants to send encrypted mail. This is essentially a client function and the server has no role to play in this.
Essentially it’s a one to one encryption of the email flow, where the sender (user) composes a mail and selects the “digitally sign” and “digitally encrypt” option in the email client software (like Outlook, Thunderbird etc). The client uses the private key of the sender to encrypt and sign the mail before sending it. On the recipient end, the client uses the sender’s public key (stored in the recipients address book by an initial handshake) to decrypt the email.
This method is useful for sending highly classified information between a group of users (like scientists, labs, government agencies etc) on an ongoing and regular basis.
3. Encrypt the client to server communication
We can take this a step further and also encrypt the connections between the clients and the server since its quite possible that the clients will access the server over a public network.
For this the sending and receiving protocols are configured to work over TLS (Transport level security).
Digital certificates can be deployed on the server and the following protocols can be secured
- SMTP (so that desktop clients like Outlook, Thunderbird, etc will connect to the server over an encrypted channel)
- IMAPS (Secured IMAP)
- POPS (Secured POP)
- HTTPS (Secured web access)