Using SSL/TLS with Postfix SMTP and Courier POP3/IMAP

Why should I use SSL/TLS to secure our mail servers?

In previous sections we mentioned that, due to the fact we are storing our passwords in encrypted form in our database, some of the more advanced authentication methods such as DIGEST-MD5 were unavailable to us. This resulted in us being forced to use authentication methods which require plain text passwords to be transmitted over the network, which in a hostile environment such as the Internet is probably not a very wise idea. At the time we rather glossed over this fact, mainly because we are going to address it in this section in a manner which is far more secure than any of the authentication methods currently supported by the common standard mail protocols.

Obtaining certificates for use with Postfix and Courier

Before we can secure either Postfix or Courier using SSL/TLS we need to obtain some certificates. These can either be self-signed test-certificates generated for immediate use, certificates signed by an organisational root certificate authority or certificates signed by a third-party root certificate authority. Whichever type of certificate you decide to use we shall assume that you have the relevant certificate and private-key files installed in /etc/ssl/ as usual.

As the purpose of this guide is the installation and configuration of a mail server, and not a guide to SSL certificates, certificate authorities or certificate manipulation operations, we shall not be covering this here. If you require more information regarding these matters then you may be interested in the Securing network traffic using SSL/TLS guide.

Configuring Postfix to use TLS

Once we have obtained our signed certificates we can configure Postfix to use them to secure all user communications with our server so that not only are user authentication details secured but the contents of the relayed email messages are also secured. To enable TLS in Postfix we need to add the following lines to our configuration file.

smtpd_use_tls = yes
smtpd_tls_auth_only = yes
smtpd_tls_received_header = yes

smtpd_tls_cert_file = /etc/ssl/misc/mail.cert.pem
smtpd_tls_key_file = /etc/ssl/private/mail.key.pem

smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_loglevel = 3
tls_random_source = dev:/dev/urandom

As usual we have broken down our configuration into logical blocks to aid description. The effect of the first block in our example configuration should be obvious. The first line is trivial and merely enables the use of TLS. The second line configures Postfix to require that a secure connection be established before any authentication details are received. The final line indicates that we wish to include a received header in our messages to indicate that they were received over a secure link.

The second block of our example configuration provides the path to the certificate file and the private key file respectively. Postfix expects these the certificate and private key to be contained in separate files however if they have been made into a combined certificate and key then both configuration entries should point to the same file.

The final block in our example sets the timeout for the TLS session cache, which can provide a marginal performance improvement, the level of logging for TLS negotiations and the source of random numbers to use for the cryptographic operations associated with TLS. We have decided to use /dev/urandom as our random number source as the /dev/random source can become quickly exhausted on a busy mail server.

With the certificate and private key in place and sufficient configuration added to the Postfix configuration file all that remains is to instruct the Postfix daemon to reload its configuration so that our changes take effect. This can be performed using the reload option of the init script as shown below.

Testing our Postfix TLS configuration

Once we have reloaded the Postfix configuration we can test that it has worked using the telnet application as in previous sections. As you can see from the example session shown below we have again issued an EHLO greeting although this time, instead of being offered the option to authenticate using the PLAIN or LOGIN methods, we are being offered the STARTTLS option.

Trying 127.0.0.1... 

Connected to mail.hacking.co.uk. 

Escape character is '^]'. 

220 mail.hacking.co.uk ESMTP Postfix 

EHLO client.example.com 

250-mail.localdomain 

250-PIPELINING 

250-SIZE 10240000 

250-VRFY 

250-ETRN 

250-STARTTLS 

250-ENHANCEDSTATUSCODES 

250-8BITMIME 

250 DSN 

QUIT 

221 2.0.0 Bye 

Connection closed by foreign host. 

Assuming your test session produced similar output to that shown in the above example then your Postfix server is correctly configured to use TLS for authenticated transactions and will refuse to authenticate unless a TLS session has been started.

Configuring Courier POP3 and IMAP to use SSL/TLS

Unlike the Postfix daemon the Courier POP3 and IMAP daemons require the certificate and key to have been combined into a single file. We can combine the certificate and private key we used earlier into a single file using the commands below. Remember that this file now contains private information and should not be readable by anyone other than the root user.

The above commands are sufficient if you are using the default RSA encryption routines however if you are using the less common DSA standard you will need to add a set of Diffie-Hellman parameters to the combined key using the command below. If you do not know which type of cryptography you are using it is safe to run this command on either type of certificate.

Generating DH parameters, 1024 bit long safe prime, generator 2 

This is going to take a long time 

Now that we have combined our certificate and key files, and appended Diffie-Hellman parameters if required, we can configure the Courier POP3 daemon. The listing below shows which lines will need to be modified in the default configuration to enable the Courier POP3 daemon to locate the SSL certificate and require that TLS is negotiated before any authentication details are exchanged.

POP3_TLS_REQUIRED=0
POP3_TLS_REQUIRED=1

TLS_CERTFILE=/etc/courier-imap/pop3d.pem
TLS_CERTFILE=/etc/ssl/private/mail.combined.pem

Now that we have configured the Courier POP3 daemon to require TLS security we need to restart it before we can perform a basic test to ensure that our configuration is working as expected. As usual the init script provides a restart function which can be used as shown below.

As before, when we tested TLS on the Postfix daemon, we shall use the telnet application to ensure that we are being forced to use TLS before submitting any authentication details and also that the TLS can be started successfully.

Trying 127.0.0.1... 

Connected to mail.hacking.co.uk. 

Escape character is '^]'. 

+OK Hello there. 

USER spamcatcher@hacking.co.uk 

-ERR TLS required to log in. 

STLS 

+OK Begin SSL/TLS negotiation now. 

QUIT 

Connection closed by foreign host. 

The Courier POP3 daemon can also offer a secure connection from the start of communications using the SSL standard. If you wish to offer this service then you will need to start the Courier POP3-SSL service and add it to the default run level as shown in the example below.

We can configure the Courier IMAP daemon to require the use of TLS before authentication information will be accepted in a similar way. The changes required to the default configuration file are outlined in the listing below.

IMAP_TLS_REQUIRED=0
IMAP_TLS_REQUIRED=1

TLS_CERTFILE=/etc/courier-imap/imapd.pem
TLS_CERTFILE=/etc/ssl/private/mail.combined.pem

Once you have made the above modifications to the Courier IMAP configuration files you will need to restart the service for those changes to take effect. This can be done using the command shown below.

Just like the Courier POP3 daemon the Courier IMAP daemon can also offer a secure connection from the start of communications using the SSL standard. If you wish to offer this service then you will need to start the Courier IMAP-SSL service and add it to the default run level as shown in the example below.