How to set up a mail server on your Arch Linux VPS (Part Two)

What is IMAP/POP3? * The IMAP and POP3 server, Dovecot * The Dovecot LDA * SMTP authentication with SASL * Sending and receiving mail with IMAP/POP3 * SSL and TLS * Dovecot and SSL/TLS * Postfix and SSL/TLS


Having already completed Part One, you have the basics of a mail server up and running. Without complicating things too much more, you can add IMAP and POP3 support to your server and thereby access your mail remotely from a Mail User Agent (MUA) such as Thunderbird, Apple Mail or Outlook, rather than have to log in to your VPS through an SSH terminal.

If you have no desire to enable IMAP or POP3 support and intend to only allow access to your mail server via webmail, add the following line to /etc/postfix/

inet_interfaces = loopback-only

This will tell Postfix to listen only for mail coming from a local resource on the server (for example, a webmail server). Your server resources can still send mail, but the service is unavailable to the outside world. You'll need to restart Postfix.


What is IMAP/POP3?

IMAP and POP3 are the two common protocols used by MUAs to communicate with mail storage servers.

The Post Office Protocol version 3 (POP3) is commonly used by users who do not have a high-speed connection to the mail server. One of POP3's basic principles is that MUAs download mail and store it locally (on the user's computer) - and then delete the mail from the server.

The Internet Message Access Protocol (IMAP) is intended for LANs and high-speed connections. The intent of IMAP is to contact the server each time a given message needs to be read (apart from MUA-specific caching). The email lives on the server. When reading an email, it is temporarily downloaded but not really stored on the device you are using. IMAP therefore allows multiple clients to manage the same mailbox.

Be careful with IMAP. Unless the mail storage and searching algorithms on the server are carefully implemented, a client can potentially consume large amounts of server resources when searching massive mailboxes.

Mail Server Overview


The IMAP and POP3 server, Dovecot

Dovecot is an open source IMAP and POP3 email server written with security primarily in mind. It's fast, simple to set up, requires no special administration and it uses very little memory. Dovecot has a number of optimizations for IMAP that make it an exceptionally good performer for most IMAP scenarios.

As an IMAP and POP3 server, Dovecot provides a way for MUAs to access their mail. So when a user's MUA contacts the mail server, the software which answers that request is Dovecot. IMAP and POP3 servers take requests from MUAs and answer those requests by accessing email messages stored on the server and feeding them out to the MUA using IMAP or POP3.

In addition, Dovecot provides functionality for final message delivery with the Dovecot LDA (Local Delivery Agent). The LDA is responsible for storing email messages into the message store. Local delivery can be carried out by the MTA itself (Postfix), or by a separate Mail Delivery Agent (MDA), or using the Dovecot LDA. (The two terms MDA and LDA are synonyms.) The choice is made according to the requirements of the particular server installation.

Note that Dovecot is NOT responsible for receiving mail from other servers. This is the job of the MTA, Postfix. Dovecot only handles messages coming out of the local message store, going out to IMAP and POP3 clients. If configured to use the Dovecot LDA, Dovecot will also handle messages which have already been received by the MTA and are to be stored into the local message store.

The local message store may be real or virtual mailboxes, which will be covered later.

Install Dovecot:

sudo pacman -S dovecot

Dovecot's configuration files don't exist yet in the /etc/dovecot/ directory. However, there are included example configuration files in /usr/share/doc/dovecot/example-config/. You can just copy these over.

sudo cp -r /usr/share/doc/dovecot/example-config/* /etc/dovecot/

/etc/dovecot/ should now contain multiple config files and a conf.d subdirectory containing even more config files. Because the configuration file was getting too big, the people behind Dovecot decided to split it up into bite-sized chunks.

The default configuration starts from dovecot.conf, which contains an !include conf.d/*.conf statement to read the rest of the configuration files in the conf.d directory. These files are nicely grouped into related settings. Don't be put off by the filenames beginning with numbers - these are just to put the files in some kind of order. This split of configuration files isn't a requirement to use, and it doesn't really matter which .conf file you add any particular setting to, just as long as it isn't overridden in another file.

You will need to modify only some of the example configuration files. Dovecot configuration primarily consists of: mail storage type and location; user list; and password list. To set the mail storage type and location, modify the file called 10-mail.conf.

sudo nano /etc/dovecot/conf.d/10-mail.conf

Uncomment the line:

mail_location = maildir:~/Maildir

Dovecot will now use Maildir format instead of mbox. Save and exit.

Now for user authentication. Dovecot currently supports a variety of user & password sources, including *NIX passwd, shadow, PAM, LDAP, SQL, and vpopmail. It's usually best to select a source supported by all the parts of your overall mail solution, including your MTA, MDA and Dovecot. We'll get to this shortly.

Admins often wish to use different passwords for IMAP and POP3 than for other services (e.g. SSH), because MUAs often send the password unencrypted over the internet without bothering to warn users. Dovecot supports non-system passwords for system users, which is what you will do here.

First modify the 10-auth.conf file as follows, uncommenting as necessary:

disable_plaintext_auth = no
auth_mechanisms = plain login

Set disable_plaintext_auth to "no" to allow plaintext authentication.

The simplest authentication mechanism is PLAIN. The client simply sends the password unencrypted to Dovecot. Obviously there's the problem that anyone listening on the network can steal the password. For that reason (and some others), further mechanisms were implemented.

There is however no problem in sending unencrypted passwords inside SSL secured connections. As you'll be configuring SSL shortly, you won't need to worry about anything other than the PLAIN mechanism.

Another plaintext mechanism is LOGIN. It's typically used only by SMTP servers to let Microsoft Outlook clients perform SMTP authentication. Therefore add "login" to auth_mechanisms.

Scroll down to the bottom of the 10-auth.conf file and comment out !include auth-system.conf.ext by adding a hash #. This will prevent Dovecot from using PAM (Pluggable Authentication Modules). Dovecot uses PAM to authenticate system users by default. As this guide will determine a virtual users setup later, for now it's easier to create a simple passwd-like file to make sure that the authentication will work. Uncomment !include auth-passwdfile.conf.ext. You'll soon modify auth-passwdfile.conf.ext to tell Dovecot about your passwd-file.

#!include auth-system.conf.ext
#!include auth-sql.conf.ext
#!include auth-ldap.conf.ext
!include auth-passwdfile.conf.ext
#!include auth-checkpassword.conf.ext
#!include auth-vpopmail.conf.ext
#!include auth-static.conf.ext

Save and exit. Now open auth-passwdfile.conf.ext and make it look like this:

passdb {
  driver = passwd-file
  args = scheme=PLAIN username_format=%n /etc/dovecot/users
userdb {
  driver = passwd-file
  args = username_format=%n /etc/dovecot/users

This tells Dovecot where to find the passwd-file (called "users"), which doesn't exist yet. So create this temporary password file and move it into Dovecot's main directory.

echo "$USER:{PLAIN}password:$UID:$GID::$HOME" > users
sudo mv users /etc/dovecot/

Replace "password" with whatever password you wish, but don't use any important password here as you'll be logging in with insecure authentication until SSL is configured.

Verify that your configuration is correct using the doveconf -n command:

dovecot -n

This command will list your configuration parameters, as well as inform you of any issues that require attention. Check there's only one passdb and one userdb section. If everything is okay, start Dovecot:

sudo systemctl start dovecot.service

To have Dovecot automatically start on boot:

sudo systemctl enable dovecot.service


The Dovecot LDA

Dovecot works best when email is delivered using the Dovecot LDA which, if used, needs to be "plugged in" to the MTA so that the MTA knows how to correctly pass messages to the Dovecot LDA. Optionally, an existing delivery configuration can be used without using the Dovecot LDA, using Dovecot purely as an IMAP and/or POP3 server. However, in such cases care needs to be taken to ensure that the MDA and Dovecot cooperate properly (for example, when using mbox it is crucial that a compatible mbox-locking strategy is used to avoid corruption of mbox files). For our purposes, the Dovecot LDA is the way to go.

Tell Postfix to use Dovecot LDA. Open Postfix's main config file:

sudo nano /etc/postfix/

Scroll down (CTRL+v) and set mailbox_command to point to dovecot-lda:

mailbox_command = /usr/lib/dovecot/dovecot-lda

Note that in Dovecot version 1, "dovecot-lda" was known simply as "deliver". (You may be confused if you come across this when googling or reading outdated Dovecot or Postfix documentation.)

Reload Postfix:

sudo postfix reload

Basic Configuration
Dovecot LDA with Postfix


SMTP authentication with SASL

This is where things start to get a bit more complicated...

SMTP servers (MTAs) need to decide whether an SMTP client is authorised to send mail to remote destinations, or only to destinations that the server itself is responsible for. Usually, MTAs readily accept mail to remote destinations when the client's IP address is in the "same network" as the server's IP address. SMTP clients outside the mail server's network need a different way to get "same network" privileges. To address this need, Postfix supports SASL authentication.

Simple Authentication and Security Layer (SASL) is nothing more than a list of requirements for authentication mechanisms and protocols. An implementation of SASL allows users who are authenticated with their login email address and password to use the SMTP server to send mail, without turning the mail server into an open relay.

With SASL, a remote SMTP client can authenticate to the Postfix SMTP server and the Postfix SMTP client can authenticate to a remote SMTP server. Once a client is authenticated, a server can give it "same network" privileges.

Note that Postfix does not implement SASL itself, but instead uses existing implementations as building blocks.

Many people confuse SASL with one specific SASL implementation: the Cyrus SASL library. However, Dovecot has its own configuration to authenticate POP/IMAP clients. When the Postfix SMTP server uses Dovecot SASL, it reuses parts of this configuration.

Check that your installation of Postfix supports Dovecot SASL by running the command:

postconf -a

Look for "dovecot" in the output:

$ postconf -a

You may find that you also have Cyrus available, but let's keep things in-house and just use Dovecot SASL.

Successful authentication in the Postfix SMTP server requires a functional SASL framework. So you need to configure Dovecot SASL before configuring Postfix itself. Open the Dovecot configuration file 10-master.conf:

sudo nano /etc/dovecot/conf.d/10-master.conf

Scroll down and find the section "service auth {". Comment out unix_listener like so:

#unix_listener auth-userdb {
  #mode = 0666
  #user =
  #group =

Proceed to edit the next section, uncommenting and adding the parameters as appropriate. It should read like this:

# Postfix smtp-auth
  unix_listener /var/spool/postfix/private/auth {
   mode = 0660
   # Assuming the default Postfix user and group
   user = postfix
   group = postfix

The above configuration places the Dovecot SASL socket in /var/spool/postfix/private/auth, and limits read+write permissions to user and group "postfix" only.

Now configure Postfix:

sudo nano /etc/postfix/

Add the following lines to the end:

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

By default the Postfix SMTP server uses the Cyrus SASL implementation. smtpd_sasl_type tells Postfix to use the Dovecot SASL implementation instead.

smtpd_sasl_path is the relative path previously defined in Dovecot's 10-master.conf file. (/var/spool/postfix/private/auth).

Regardless of the SASL implementation, enabling SMTP authentication in the Postfix SMTP server always requires setting the smtpd_sasl_auth_enable option.

smtpd_recipient_restrictions tells Postfix that it's ok to accept both mail coming from the "same network" and "foreign" SASL-authenticated mail.

Reload both Dovecot and Postfix to effect the changes:

sudo Dovecot reload
sudo Postfix reload


Sending and receiving mail with IMAP/POP3

You can now try sending and receiving emails from your MUA of choice. Remember that you have yet to secure transmission using SSL, so don't send anything top secret just yet.

Here are example connection parameters for setting up an IMAP account in Apple Mail (Thunderbird and Outlook should be fairly similar to configure):

  Account type: IMAP
  Description: John's Email Account
  Email address:
  Full name: John Doe
  Incoming mail server:
  User name: john
  Password: password (as defined above in /etc/dovecot/users)

The outgoing SMTP mail server parameters would be something like:

  Server name:
  Description: John's SMTP server   Use default ports (25, 465, 587): yes
  Use SSL: no
  Authentication: Password
  User name: john
  Password: password (as defined above in /etc/dovecot/users)

If everything works, you can move on to configure secure mail.

Problems? Try troubleshooting here.

Postfix And Dovecot SASL
Postfix SASL Howto



SSL and TLS are basically one and the same. TLS (Transport Layer Security) replaced the SSL (Secure Sockets Layer) protocol, but nowadays many people still refer to what is actually TLS as SSL.

By using SSL certificates to secure a connection, the data passed between your MUA and mail server will be encrypted. Not only are user authentication details secured, but the contents of the relayed email messages too.

SSL certificates can either be: self-signed certificates generated for immediate use; certificates signed by an organisational root certificate authority (RCA); or certificates signed by a third-party RCA.


Dovecot and SSL/TLS

Self-signed SSL certificates are the easiest (and cheapest) way to get your SSL server working. If you've previously set up an FTP server as described here, then you already created a self-signed certificate using the openssl command. It's a good idea to use different certificates for FTP and mail applications. Dovecot includes a script to build self-signed SSL certificates using OpenSSL. So for the sake of completeness, this is how to use it...

By default the certificate is created to /etc/ssl/certs/dovecot.pem and the private key file is created to /etc/ssl/private/dovecot.pem. Also by default the certificate will expire in 365 days. If you wish to change any of these settings, modify the script:

sudo nano /usr/share/doc/dovecot/

Also check that the following line has the correct path to the config file:

OPENSSLCONFIG=${OPENSSLCONFIG- /usr/share/doc/dovecot/dovecot-openssl.cnf}

Save and exit Now edit the config file that will use to generate your self-signed SSL certificate:

sudo nano /usr/share/doc/dovecot/dovecot-openssl.cnf

Save and exit dovecot-openssl.cnf. Now run using the sh command to generate your SSL certificate:

sudo sh /usr/share/doc/dovecot/

You should find a dovecot.pem file in each of the following directories:

ls /etc/ssl/private
ls /etc/ssl/certs

You'll need to tell Dovecot to use SSL and the certificate you just created. This is done in the 10-ssl.conf file:

sudo nano /etc/dovecot/conf.d/10-ssl.conf

Check that the following three lines are uncommented and read as follows:

ssl = yes
ssl_cert = </etc/ssl/certs/dovecot.pem
ssl_key = </etc/ssl/private/dovecot.pem

Save and exit, then reload Dovecot. Try it out by executing:

openssl s_client -connect

You should see a lot of text ending in:

+OK Dovecot ready.

Type quit to exit openssl. Dovecot is now configured to use SSL. Because you previously defined Dovecot as your LDA, Dovecot handles all local mail delivery. You could now change the settings of your MUA to use SSL and still receive mail. However, the SMTP server Postfix is responsible for outgoing mail and therefore also needs to be configured.

Dovecot SSL Certificate Creation
Dovecot SSL Configuration


Postfix and SSL/TLS

Open Postfix's file:

sudo nano /etc/postfix/

Add the following lines to the end of Postfix's file:

smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/dovecot.pem
smtpd_tls_key_file = /etc/ssl/private/dovecot.pem
smtpd_tls_loglevel = 0

By default, TLS is disabled in the Postfix SMTP server, so no difference to plain Postfix is visible. The first line above explicitly switches it on with "smtpd_tls_security_level = may". With this, the Postfix SMTP server announces STARTTLS support to remote SMTP clients, but does not require that clients use TLS encryption.

The second line configures Postfix to require that a secure connection be established before any authentication details are received.

The paths to the certificate and private key can be the same as the SSL certificate that you created to use with Dovecot.

The final line keeps clutter in the log file to a minimum. A level of 0 means that Dovecot will only log a summary message on TLS handshake completion. That should be enough.

Save and exit. Reload Postfix:

sudo postfix reload

To test that you mail server now supports SSL, issue the following commands from a fresh terminal (i.e. not logged into your VPS):

telnet localhost 25

Here you are telnetting into your VPS' port 25 (SMTP) from your local machine. You should get output like:
250-SIZE 10240000
250 DSN

Note the presence of STARTTLS in the output. In effect, your mail server is now offering STARTTLS as an authentication mechanism, rather than PLAIN or LOGIN. It's basically a command to initiate a TLS session. Type quit to exit telnet.


Configure your email client to use SSL/TLS

There's a lot of confusion regarding STARTTLS and SSL/TLS. Are they one and the same? Nearly, except that STARTTLS uses the standard SMTP port 25 to initiate the connection. Once the server returns with a TLS "handshake", the secure SSL/TLS connection is initiated. Unfortunately, different MUAs treat STARTTLS and SSL/TLS differently.

If you're using Apple Mail, configuring it is simply a case of checking the box "use SSL" under the "Advanced" tab of "Accounts". Likewise for the outgoing mail (SMTP) server. Apple Mail seems to take care of all the rest. That's maybe not such a good thing (keep reading).

Thunderbird is a bit different. Here you must specify either STARTTLS or SSL/TLS. So, set Thunderbird to receive mail using SSL/TLS (using the default port 993 for IMAPS or 995 for POP3S) with "Normal password" as the authentication method. Try doing the same for the outgoing server (default is port 465 using SSL/TLS). Check you can send and receive emails.

If you can't receive mail, select the STARTTLS option using port 143 for IMAP or 110 for POP3 and try again.

If the problem is in sending mail, try STARTTLS with port 587 for the outgoing SMTP server.

It's preferable to try to first configure Thunderbird to use SSL/TLS rather than STARTTLS just in case Thunderbird can't get STARTTLS to work and then tries to connect anyway by sending your password in plaintext via standard SMTP. Other MUAs do this without you even knowing about it. But as long as you configured Postfix to disallow plaintext authentication, this shouldn't be a problem.

You may be wondering if it's ok to use "Normal password" rather than "Encrypted". The answer is yes, because authentication takes place only after the TLS session has been initiated, i.e. your password is passed through the encrypted channel along with everything else.

If everything is working, you're ready to move on to Part Three. Otherwise, check the mail log to see what's going on:

sudo nano /var/log/mail.log
Postfix TLS Support
Dovecot SSL
Configuring Postfix to use TLS