In the original email protocol (as described in RFC 821), the communication between two SMTP servers was proposed to be plain text. But, over a period of time, this increased the security risk with this channel. Over the year, many mechanisms were proposed to make it end-to-end encrypted or at least at the transport layer.

Like any other data, the email also requires encryption. The chances of having a vulnerability or stealing information are even higher when it comes to email. This is because, emails are prone to the disclosure of personal information like Name, Bank Balance, confidential conversations and a lot of other important documents. All major mailbox providers like Gmail or Outlook by default encrypt the emails sent from their platform. But this is not true when it comes to some of the other providers. Most of the emails are currently transmitted in clear text without any encryption.

Email encryptions mostly rely on public key-based cryptography, in which the recipients can publish a public key that senders can use to encrypt mail messages to them. The secret private key will remain with the recipient which they can use later to decrypt the received encrypted mail message. The same key can be used by them to digitally encrypt/sign messages they send from their mailbox.

Thanks to our global group of innovators who helped to solve this problem of encryption both at the transport level and at the end-to-end level too. Out of these two, implementing transport-level encryption is fairly easy as compared to end-to-end encryption.

Transport-level encryption

STARTTLS is one of the most commonly used email encryption extension. STARTTLS is actually nothing but a TLS (SSL) layer over the plaintext mail communication.

In this model, both the sender and the receiver server should have the support for TLS encryption. Anyone between these servers can’t really be able to sniff the mail content.

In this encryption model, the encryption actually takes place between the two SMTP relays and not really between the sender and the receiver. One of the biggest pros of this type of encryption implementation is that the user doesn’t have to worry about making any changes to send emails with encryption. Encryption will happen automatically at the transport layer and in fact, the receiving server doesn’t have to be dependent on the user to decrypt the message. As per Google, more than 90% of the GMail’s incoming and outgoing email is encrypted using STARTTLS.

While STARTTLS looks lucrative, but it has its cons too. In case, someone breaches the security of the email system, then they can easily read and edit the emails. In order to avoid this case, end-end encryption is recommended.

End-to-end encryption

This is the most secure encryption for emails. In the case of end-to-end encryption, the data is encrypted at the source and is not readable by anyone on the network neither by your mail service provider Gmail, Yahoo.

Here are a few protocols which help to enable end-to-end encryption:

• Pretty Good Privacy (PGP)
• GNU Privacy Guard (GPG)
• Bitmessage
• S/MIME

While doing end-to-end encryption and decryption seems to be more secure, but when it comes to the usability it fails. It is difficult to use this because the user has to set up public and private key and make the public key available for everyone.

While Gmail has recently become stricter for TLS encryption by implementing a red lock on each email which is received to your Gmail mailbox. In case the email is not TLS encrypted, the lock will be in open state with a message. This encourages the sender to send emails with TLS encryption. While all those good, but it’s been three years and Gmail still doesn’t has any updates on when it can have end-to-end encryption for all of your incoming and outgoing emails.

Implementing end-to-end encryption requires effort from both sender and receiver, so both the parties have to mutually understand its importance and implement.

Different operating systems and mailing servers have different steps to configure a SMTP server. In this section, you will learn how to configure an SMTP server is some of the popular mail applications:

Exchange 2010

When it comes to Windows, MS Exchange is the most popular application to send emails. You can either configure SMTP server in Exchange to deliver email from localhost or by connecting with an external SMTP.

Here are the steps on how to configure a send connector in the Exchange Management console to use localhost or external SMTP:

1. Log into your Exchange server.
2. Go to Start > All Programs > Microsoft Exchange Server 2010 and click the Exchange Management Console item.
3. Open the Organization Configuration list and select Hub Transport.
4. Click New Send Connector in the Actions sidebar.
5. Provide a name to the Send Connector and select Internet for the Intended Use pull-down. It allows for the integration with an authenticated SmartHost and adds the default send permissions required by Exchange 2010 to route messages through an external host that is not a part of the domain forest.
6. Click Next.
7. Click Add.
8. Provide the allowed address to which connector can send mails. If you want to:
   1. Send to anyone on the internet, then insert ‘*’ (asterisk) in the Address box.
   2. Send only to a specific domain, enter the domain.
   3. Allow all sub-domains, then check the box.
9. Click Next.
10. Go to Network Settings page. Select Route mail through the following smart hosts item.
11. Click Add.
12. Select Fully qualified domain name (FQDN), and enter: smtp.pepipost.com
13. Click Next.
14. In the Configure smart host authentication settings page, select the Basic Authentication option and check the Basic Authentication over TLS checkbox. Enter the Pepipost username and password here.
15. Click Next.
16. If you have one Exchange server, it is displayed. If you want to add more server(s) in your domain, click Add to locate the servers you want to allocate to this connector.
17. Click Next.
18. Verify the settings, and if everything is correct, click New.
19. If the configuration is correct, a message is displayed. Click Finish to exit.

Ssmtp

Ssmtp provides an easy setup of an SMTP server. You need to just edit the /etc/ssmtp/ssmtp.conf file and add the following code:

mailhub=smtp.Pepipost.com:587

AuthUser=Pepipostusername

AuthPass=Pepipostpassword

UseSTARTTLS=YES

Restart

Ssmtp

Sendmail

Sendmail is one of the oldest and most popular backend mail applications to send emails. Sendmail requires libsasl library to send authentication requests to any SMTP servers. Below are the steps on how to configure SMTP in Sendmail:

1. Provide the authorization credentials in /etc/mail/access
2. AuthInfo:smtp.Pepipost.com “U:yourUserName” “P:yourPassword” “M:PLAIN” b. Define the Smart Host in /etc/mail/sendmail.mc Add these lines right below the commented #dnl define(‘SMART_HOST’, ‘smtp.your.provider’)dnl line in the file.
3. define(SMART_HOST’,smtp.Pepipost.com’)dnl
   FEATURE(`access_db’)dnl
   define(RELAY_MAILER_ARGS’,TCP $h 587′)dnl
   define(ESMTP_MAILER_ARGS’,TCP $h 587′)dnl
4. Update sendmail.cf and access.db files. You need to run these commands as ‘su’ or ‘root’)
5. $ cd /etc/mail
6. $ m4 sendmail.mc >sendmail.cf
7. $ makemap hash access < access
8. On older distros, you can run restart sendmail as below:
9. $ /etc/init.d/sendmail restart
10. If you are using a newer version of sendmail, do the following to restart: $ service sendmail restart

Security extensions can be used to establish a secure smtp connection between two servers.

TLS which is widely used with the combination of HTTP is one of the most popular protocols for network level security over TCP.

Same TLS also known as SSL is a popular mechanism when it comes to secure communication over SMTP protocol.

There are various vulnerabilities and threats to the basic SMTP protocol like DoS attacks, Malware, Spam/Phishing and Unauthorized access to emails. All of these can be addressed, with the use of various security extensions proposed as a part of SMTP Security Extensions.

SMTP AUTH or SMTP Authentication is an extension of SMTP where the user of the SMTP or the client has to use any of the SMTP supported authentication mechanism to connect with the SMTP server.

STARTTLS

[STARTTLS] is one of the SMTP security extensions which can be used to make a secure connection between two servers.

Here is an example on how the STARTTLS works:

The use of STARTTLS keyword in any SMTP transaction is used to tell the receiver that the SMTP server wants to negotiate the connection using TLS (Transport Layer Security).

Whenever a server makes a STARTTLS command, then the receiver can reply with any one of the below responses:

• 220 Ready to start TLS
• 501 Syntax error
• 454 TLS not available

The response code 454 means that the receiver is not ready for a TLS handshake, and hence the sender should either terminate the connection or try to make a new unsecure connection.

Using a TLS doesn’t mean a end to end security of your email, this is because TLS happens between two servers. But, what if there are more than 2 servers in the entire journey of an email.

You can negotiate a TLS handshake with a server, but what if the receiver server is not the final destination and doesn’t make a TLS handshake with the next server in the hop. This will break your overall objective of making the emails as secure in the transit.

SMTP MTA Strict Transport Security

SMTP MTA Strict Transport Security is a mechanism which mail servers can use to declare whether they have the capability to accept TLS connection or not, and in case of incompatible what the sending server should be doing.

In order to declare your policies for SMTP MTA Strict Transport Security, you need to add view settings in DNS and HTTPS.

DNS related changes

You need to create a MTA-STS TXT record with the following syntax:

_mta-sts.example.com. IN TXT "v=STSv1; id=201546745644545Y;"

The MTA-STS TXT record must be a US_ASCII, semicolons are allowed.

SMTP TLS Reporting

While there are a lot of organisations who have started using TLS, very few seriously flow it completely. SMTP TLS Reporting is one of that functionality defined in RFC and implemented by a very few organisations. Gmail is the first major provider who started support for SMTP TLS Reporting also known as TLS-RPT.

SMTP TLS Reporting is a standard protocol which enables organisations to report the TLS connectivity related problems experienced within their application.

Here is a sample of SMTP TLS Reporting email:

From: tlsrpt@mail.sender.example.com
     Date: Fri, May 09 2017 16:54:30 -0800
     To: mts-sts-tlsrpt@example.net
     Subject: Report Domain: example.net
         Submitter: mail.sender.example.com
         Report-ID: <735ff.e317+bf22029@example.net>
     TLS-Report-Domain: example.net
     TLS-Report-Submitter: mail.sender.example.com
     MIME-Version: 1.0
     Content-Type: multipart/report; report-type="tlsrpt";
         boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00"
     Content-Language: en-us
 
     This is a multipart message in MIME format.
 
     ------=_NextPart_000_024E_01CC9B0A.AFE54C00
     Content-Type: text/plain; charset="us-ascii"
     Content-Transfer-Encoding: 7bit
 
     This is an aggregate TLS report from mail.sender.example.com
 
     ------=_NextPart_000_024E_01CC9B0A.AFE54C00
     Content-Type: application/tlsrpt+gzip
     Content-Transfer-Encoding: base64
     Content-Disposition: attachment;
         filename="mail.sender.example!example.com!
                   10547687685476854.gz"
     
------=_NextPart_000_024E_01CC9B0A.AFE54C00--
...