Table of Contents
Introduction
Dovecot is a popular open source IMAP and POP3 server designed to provide secure, fast, and standards compliant access to email stored on a server. In a typical Linux mail stack, SMTP software such as Postfix or Exim is responsible for receiving and sending mail, while Dovecot handles users reading and managing their messages using IMAP or POP3 clients.
This chapter focuses on what is specific to IMAP and POP3 access using Dovecot, including basic architecture, configuration highlights, common mailbox formats, authentication approaches, and practical examples. It assumes that SMTP and general Postfix configuration are handled elsewhere in the course.
IMAP vs POP3 in Practice
IMAP and POP3 both provide remote access to email but they encourage different workflows.
IMAP keeps the canonical copy of the mailbox on the server. The client synchronizes state such as read flags and folders. This model works well for modern use cases where users access the same mailbox from many devices. IMAP supports server side folders, flagging messages, server side search, and partial message retrieval.
POP3 is simpler. It was originally designed for clients to download messages from the server and optionally delete them afterward. POP3 generally does not know about folders beyond the default inbox and does not synchronize state between devices. Some clients support leaving messages on the server for a certain time, but concurrent multi device access remains limited.
In most modern deployments Dovecot is used primarily as an IMAP server, with POP3 enabled only when required for legacy clients or constrained environments. Dovecot supports running both protocols at the same time with separate configuration blocks.
Dovecot Architecture Overview
Dovecot is modular. Understanding its main components helps you read and adjust its configuration.
A main dovecot master process starts on boot. It launches protocol specific services for IMAP and POP3, typically named imap-login, pop3-login, imap, and pop3. The login processes handle the initial connection, including TLS negotiation and authentication. After authentication, they hand the connection over to worker processes that access mailboxes and perform the requested actions.
Dovecot authenticates users through the authentication subsystem, configured in 10-auth.conf and related files. The auth service can use system users, virtual users stored in files, SQL databases, LDAP, or custom backends. After successful authentication Dovecot needs to map the logical mail user to a local user id (uid), group id (gid), and home or mail directory. This mapping is the responsibility of the user database (userdb).
Messages are stored in a specific mailbox format and location chosen in the mail storage configuration. The mail process accesses these files or directories using the configured system user and group, so permission design is important in a production setup.
Installing Dovecot
On most distributions you install Dovecot from the standard repositories. Package names are often split into a base package and protocol specific subpackages.
On Debian and Ubuntu you might use:
sudo apt install dovecot-imapd dovecot-pop3dOn Fedora and similar systems:
sudo dnf install dovecot
After installation, the main configuration file is usually /etc/dovecot/dovecot.conf. This file often includes other configuration snippets from directories such as /etc/dovecot/conf.d/. Distribution packages usually enable both IMAP and POP3 by default, but the final behavior is controlled by the protocols setting.
You can confirm that Dovecot is running with:
systemctl status dovecot
and verify which ports it listens on with commands such as ss or netstat.
Core Configuration Structure
Dovecot uses a central configuration that includes modular fragments. Typical layouts use a main dovecot.conf that contains top level directives and a series of files in conf.d with filenames like 10-auth.conf, 10-mail.conf, 10-master.conf, 10-ssl.conf, and 20-imap.conf. The numeric prefixes help define loading order.
The central entry point frequently looks like this:
!include_try /usr/share/dovecot/protocols.d/*.protocol
protocols = imap pop3 lmtp
!include conf.d/*.conf
!include_try local.conf
The protocols line decides what Dovecot actually serves. If you want to disable POP3 entirely, you can set:
protocols = imapor to run both:
protocols = imap pop3
Within conf.d, protocol specific files such as 20-imap.conf and 20-pop3.conf allow you to fine tune behavior only for one protocol, while shared settings live in the 10-* files.
Dovecot shows the effective configuration in a normalized form when you run:
dovecot -nThis is useful for troubleshooting, since it prints only non default settings.
Mailbox Storage Formats
Dovecot supports several mailbox formats. The format affects performance, disk usage, and compatibility with other tools.
The most common formats are mbox, Maildir, and mdbox. Dovecot can also work with sdbox and some legacy variants but these are less frequently used.
mbox stores all messages for a folder in a single file, with messages appended one after the other. While mbox is compatible with some older tools, it can be slower and more fragile. Concurrent access is difficult because the entire file must be locked when writing, so large mailboxes can become a bottleneck.
Maildir stores each message as a separate file in a structured directory tree. Folders correspond to directories, and message metadata can be encoded in filenames. Maildir handles concurrent access more gracefully and generally performs better with large mailboxes, because adding or deleting a single message only changes one file. Many modern MTAs and IMAP servers use Maildir as a default.
mdbox is a Dovecot specific format that stores multiple messages per file but uses an index and mapping scheme to reduce fragmentation and allow efficient compaction. It can reduce the number of filesystem inodes and improve performance for very large mailboxes. It is often used in enterprise setups but is less intuitive to inspect by hand.
The mail storage format and location are primarily configured in 10-mail.conf using the mail_location directive. A typical Maildir setup might look like:
mail_location = maildir:~/Maildir
So if a user has home directory /home/alice, her mail lives in /home/alice/Maildir. An mdbox example might be:
mail_location = mdbox:/var/mail/%u
Here %u expands to the username, so Dovecot stores user alice mail under /var/mail/alice.
Always choose and fix the mailbox format at the start of a deployment. Changing formats later requires a planned migration using tools such as doveadm sync or export and import procedures.
Basic IMAP and POP3 Service Configuration
IMAP and POP3 share much of the core configuration but also have protocol specific options. These are usually defined in 20-imap.conf and 20-pop3.conf.
For IMAP, the configuration block may appear as:
protocol imap {
mail_max_userip_connections = 10
}
The mail_max_userip_connections setting limits how many simultaneous IMAP connections a single user can open from one IP address. This helps prevent abuse from overly aggressive clients.
For POP3, a minimal block might be:
protocol pop3 {
pop3_uidl_format = %08Xu%08Xv
}
The pop3_uidl_format controls the unique identifiers that POP3 clients use to track which messages they have already downloaded. Changing this in an existing deployment can confuse clients, so it should be chosen early and then left alone.
To run only IMAP or only POP3, adjust the protocols line in the main configuration. To change ports or add SSL only variants, you configure service blocks in 10-master.conf. A simplified example for standard submission might be:
service imap-login {
inet_listener imap {
port = 143
}
inet_listener imaps {
port = 993
ssl = yes
}
}
For POP3 you would have service pop3-login with listeners on ports 110 and 995 for SSL. These determine the network endpoints that Dovecot will expose.
Authentication and User Databases
Dovecot separates how users prove their identity from how they are mapped to system resources. The auth subsystem configures the accepted authentication mechanisms and the passdb and userdb backends.
In 10-auth.conf, you decide which authentication mechanisms IMAP and POP3 will accept. For example:
disable_plaintext_auth = yes
auth_mechanisms = plain loginIn practice you should combine plain text mechanisms only with TLS so that passwords are not exposed on the network.
The passdb defines where passwords are stored and how they are verified. For system accounts you can use:
passdb {
driver = pam
}so Dovecot uses the system PAM configuration. For virtual users, you might use a file, SQL, or LDAP. A flat file example:
passdb {
driver = passwd-file
args = scheme=SHA512-CRYPT /etc/dovecot/passwd
}
The userdb defines users mail related attributes such as uid, gid, and home directory. For system users you can use:
userdb {
driver = passwd
}
which reads /etc/passwd. For virtual users you might define a static mapping like:
userdb {
driver = static
args = uid=vmail gid=vmail home=/var/mail/%u
}
This tells Dovecot to run mail processes as the vmail user, with user home directories under /var/mail/username.
If you use virtual users, do not store passwords in plain text. Always use secure password schemes such as SHA512-CRYPT or BLF-CRYPT, and ensure the files containing them are readable only by root and the Dovecot auth service.
TLS and Secure Access
Modern IMAP and POP3 deployments should use TLS to encrypt traffic. Dovecot handles TLS configuration centrally in 10-ssl.conf.
At minimum you need to specify a certificate and private key:
ssl = required
ssl_cert = </etc/letsencrypt/live/mail.example.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.example.com/privkey.pem
The < syntax tells Dovecot to read the file contents. With ssl = required Dovecot will only accept encrypted connections on the ports that support TLS. By default, Dovecot supports both STARTTLS on the plain ports and implicit TLS on the SSL ports if you configure the corresponding listeners.
You can also adjust allowed TLS protocols and ciphers for security hardening. For example, to disable old SSL versions:
ssl_min_protocol = TLSv1.2Mail clients must be configured to trust the certificate authority that issued your server certificate. For public servers, using ACME certificates from services like Let us Encrypt provides compatibility with most clients.
Integrating Dovecot with Postfix Mailboxes
In a typical mail server setup, Postfix delivers messages to local mailboxes, and Dovecot provides IMAP and POP3 access to those same mailboxes. You must ensure that mail_location and user mappings in Dovecot match the mailbox layout used by Postfix.
If Postfix delivers mail using the Maildir format under ~/Maildir, you configure:
home_mailbox = Maildir/on the Postfix side, and:
mail_location = maildir:~/Maildir
on the Dovecot side. Both programs then agree that user alice stores mail in /home/alice/Maildir.
In a virtual user setup, Postfix often uses virtual_mailbox_maps and a virtual_mailbox_base such as /var/mail/vhosts. Dovecot then uses the same directory tree: