Table des matières

Part 2 - IMAP and TLS Setup

This is part 2 of building your own secure email server on Debian from scratch tutorial series. In previous part, we showed you how to set up a basic Postfix SMTP server. In this tutorial, we are going to configure the email server so that we can receive and send emails using a desktop email client like Mozilla Thunderbird or Microsoft Outlook.

To be able to send emails using a desktop email client, we need to enable the submission service in Postfix. To receive emails using a desktop email client, we can install an open-source IMAP server named Dovecot on the Debian server. And to encrypt our communications, we can install a free TLS certificate issued by Let’s Encrypt.

This part is focused only on Canonical users (use only local OS user as mailbox login)

Open Ports in Firewall

Debian doesn’t enable firewall by default. If you have enabled the UFW firewall, then you need to run the following command to open email related ports in firewall.

sudo ufw allow 80,443,587,465,993/tcp

If you use POP3 to fetch emails (I personally don’t), then also open port 110 and 995, you may also open unsecure IMAP port 143 (I personnaly don't).

sudo ufw allow 110,143,995/tcp

Ports ID and description

Port TCP/UDP Description
80 TCP Web Server HTTP
443 TCP Web Server HTTPS
587 TCP SMTP
465 TCP SMTP-SSL
143 TCP IMAP
993 TCP IMAP-SSL
110 TCP POP3
995 TCP POP3-SSL

Securing Email Server Traffic with TLS Certificate

When we configure our desktop email clients, It’s always a good idea to enable TLS encryption to prevent hackers from snooping on our emails. We can easily obtain a free TLS certificate from Let’s Encrypt. Issue the following commands to install Let’s Encrypt client (certbot) on Debian server from the default software repository.

sudo apt update
 
sudo apt dist-upgrade
 
sudo apt install certbot

If you don’t have a web server running yet, I recommend you install one (Apache or Nginx), because it’s easier to obtain and install TLS certificate with a web server than using other methods. And in a later tutorial, I will show you how to set up webmail, which requires running a web server.

If you choose to use Apache web server, you need to install the Apache plugin. (The following command will install Apache web server if it’s not already installed on your system.)

sudo apt install python3-certbot-apache

If you choose use Nginx web server, then install the Nginx plugin. (The following command will install Nginx web server if it’s not already installed on your system.)

sudo apt install python3-certbot-nginx

Obtaining TLS Certificate with Apache Web Server

We create an Apache virtual host for mail.example.com before obtaining Let’s Encrypt TLS certificate. Create the virtual host file:

sudo nano /etc/apache2/sites-available/mail.example.com.conf

Then paste the following text into the file.

<VirtualHost *:80>        
        ServerName mail.example.com
 
        DocumentRoot /var/www/html/
</VirtualHost>

Save and close the file. Enable this virtual host.

sudo a2ensite mail.example.com.conf

Then disable the default virtual host, because it might interfere with other virtual hosts.

sudo a2dissite 000-default

Reload Apache for the changes to take effect.

sudo systemctl reload apache2

Once the virtual host is created and enabled, run the following command to obtain Let’s Encrypt TLS certificate.

sudo certbot certonly -a apache --agree-tos --no-eff-email --staple-ocsp --email you@example.com -d mail.example.com

Where:

certonly obtain the TLS certificate but don’t install it in the web server
–apache Use the Apache plugin for authentication
–agree-tos Agree to terms of service.
–no-eff-email Don’t receive emails from EFF foundation.
–staple-ocsp Enables OCSP Stapling. A valid OCSP response is stapled to the certificate that the server offers during TLS connection.
–email Enter your email address, which is used for important notifications and account recovery.
-d domain, aka your mail server hostname.

Substitute the “example.com” fields with your actual data. You should see the following which means the certificate is successfully obtained. You can also see the directory under which your cert is stored.

Obtaining TLS Certificate with Nginx Web Server

We create an Nginx virtual host for mail.example.com before obtaining Let’s Encrypt TLS certificate. Create the virtual host file:

sudo nano /etc/nginx/conf.d/mail.example.com.conf

Next, paste the following text into the file.

server {
      listen 80;
      listen [::]:80;
      server_name mail.example.com;
 
      root /usr/share/nginx/html/;
 
      location ~ /.well-known/acme-challenge {
         allow all;
      }
}

Save and close the file. Make sure the /usr/share/nginx/html/ directory exists on your server.

sudo mkdir -p /usr/share/nginx/html/

Reload Nginx for the changes to take effect.

sudo systemctl reload nginx

Once the virtual host is created and enabled, run the following command to obtain Let’s Encrypt certificate with Nginx plugin.

sudo certbot certonly -a nginx --agree-tos --no-eff-email --staple-ocsp --email you@example.com -d mail.example.com

Where:

certonly obtain the TLS certificate but don’t install it in the web server.
–nginx Use the Nginx plugin for authentication
–agree-tos Agree to terms of service.
–no-eff-email -Don’t receive emails from EFF foundation.
–staple-ocsp Enables OCSP Stapling. A valid OCSP response is stapled to the certificate that the server offers during TLS connection.
–email Enter your email address, which is used for important notifications and account recovery.
-d domain, aka your mail server hostname.

You should see the following which means the certificate is successfully obtained. You can also see the directory under which your cert is stored.

Enable Submission Service in Postfix

To send emails from a desktop email client, we need to enable the submission service of Postfix so that the email client can submit emails to Postfix SMTP server. Edit the master.cf file.

sudo nano /etc/postfix/master.cf

In submission section, uncomment or add the following lines. Please allow at least one whitespace (tab or spacebar) before each -o. In postfix configurations, a preceding whitespace character means that this line is continuation of the previous line. (By default the submission section is commented out. You can copy the following lines and paste them into the file, so you don’t have to manually uncomment or add new text.)

submission     inet     n    -    y    -    -    smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_tls_wrappermode=no
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
  -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth

Some explainations

parameter descr
syslog_name specify the 'sub service' name logged into the syslog : 2022-07-21T16:33:15.138206+02:00 servername postfix/submission/smtpd[PID]: lost connection after AUTH from xxxxxxx
smtpd_tls_security_level The SMTP TLS security level for the Postfix SMTP server; (none 1), may 2), encrypt 3))
smtpd_tls_wrappermode Run the Postfix SMTP server in TLS “wrapper” mode, instead of using the STARTTLS command.
smtpd_relay_restrictions Access restrictions for mail relay control that the Postfix SMTP server applies in the context of the RCPT TO command, before smtpd_recipient_restrictions.
smtpd_recipient_restrictions Optional restrictions that the Postfix SMTP server applies in the context of a client RCPT TO command, after smtpd_relay_restrictions.
smtpd_sasl_type The SASL plug-in type that the Postfix SMTP server should use for authentication.
smtpd_sasl_path Implementation-specific information that the Postfix SMTP server passes through to the SASL plug-in implementation that is selected with smtpd_sasl_type. Typically this specifies the name of a configuration file or rendezvous point.

An alternative is to be more restrictive on what your 'trusted' network can do.

1)
TLS will not be used.
2)
Opportunistic TLS: announce STARTTLS support to remote SMTP clients, but do not require that clients use TLS encryption.
3)
Mandatory TLS encryption: announce STARTTLS support to remote SMTP clients, and reject all plaintext commands except HELO, EHLO, XCLIENT, STARTTLS, NOOP, QUIT, and HELP. According to RFC 2487 this MUST NOT be applied in case of a publicly-referenced SMTP server. Instead, this should be used on dedicated servers, for example submission (port 587).