This documentation is for Dovecot v2.x, see wiki1 for v1.x documentation.

Service configuration

This page describes Dovecot's services comprehensively. Most admins don't need to know these details. The important service settings are described in the example-config/conf.d/10-master.conf file.

Service basics


The binary path to execute and its parameters. If the path doesn't begin with '/', it's relative to base_dir.

Type of this service:
  • "" is the default.
  • "startup" creates one process at startup. For example SSL parameters are generated at startup because of this, instead of only after the first SSL connection arrives.
  • "login" is used by login processes. The login processes have "all processes full" notification fd. It's used by the processes to figure out when no more client connections can be accepted because client and process limits have been reached. The login processes can then kill some of their oldest connections that haven't logged in yet.
  • "log", "config" and "anvil" are treated specially by these specific processes.

If non-empty, this service is enabled only when the protocol name is listed in protocols setting.


If a process doesn't appear to be doing anything after this much time, notify it that it should kill itself if it's not doing anything. process_min_avail setting overrides this. If set to 0, default_idle_kill is used.

Service privileges


UNIX user (UID) which runs this process. default_login_user setting's value should be used for type=login processes and default_internal_user should be used for other processes that don't require root privileges.

The primary UNIX group (GID) which runs this process.
Secondary UNIX groups that this process belongs to.

Secondary UNIX group, which is disabled by default, but can be enabled by the process. This setting is probably never needed directly. mail_privileged_group setting is a more user friendly way to use this setting for mail processes.


The processes are chrooted to this directory at startup. Relative to base_dir.

Drop all privileges after forking, but before executing the binary. This is mainly useful for dumping core files on non-Linux OSes, since the processes are no longer in "setuid" mode. This setting can't be used with non-empty chroot.

Service limits


Maximum number of simultaneous client connections. If set to 0, default_client_limit is used instead.

Number of client connections to handle until the process kills itself. 0 means unlimited.

Maximum number of processes that can exist for this service. If set to 0, default_process_limit is used instead.

Minimum number of processes that always should be available to accept more client connections. For service_count=1 processes this decreases the latency for handling new connections. For service_count!=1 processes it could be set to the number of CPU cores on the system to balance the load among them.

Limit the process's address space (both RLIMIT_DATA and RLIMIT_AS if available). When the space is reached, some memory allocations may start failing with "Out of memory", or the kernel may kill the process with signal 9. This setting is mainly intended to prevent memory leaks from eating up all of the memory, but there can be also legitimate reasons why the process reaches this limit. For example a huge mailbox may not be accessed if this limit is too low. The default value (18446744073709551615 = 2^64-1) sets the limit to default_vsz_limit, while 0 disables the limit entirely.

Service listeners

unix_listeners and fifo_listeners


Path to the file, relative to base_dir setting. This is also used as the section name.

Owner of the file. Defaults to 0 (root).
Group of the file. Defaults to 0 (root/wheel).
Mode of the file. Defaults to 0700. Note that 0700 is an octal value, while 700 is a different decimal value. Setting mode to 0 disables the listener.


Section name of this listener. It is meant to be descriptive for humans (e.g. "imap", "imaps").

Space separated list of IP addresses / host names to listen on. "*" means all IPv4 addresses, "::" means all IPv6 addresses. Defaults to listen setting.

Port number where to listen. 0 disables the listener.
If yes, the listener does an immediate SSL/TLS handshake after accepting a connection. This is needed for the legacy imaps and pop3s ports.
haproxy (v2.2.19+)

If yes, this listener is configured for use with HAProxy. It expects a Proxy Protocol header right after accepting the connection. Connections are aborted immediately when this protocol is violated.

Default services


The anvil process tracks state of users and their connections.


The master auth process. There are 4 types of auth client connections:

  1. client: Only SASL authentication is allowed. This can be safely exposed to entire world.
  2. userdb: userdb lookups and passdb lookups (without the password itself) can be done for any user, and a list of users can be requested. This may or may not be a security issue. Access to userdb lookup is commonly needed by dovecot-lda, doveadm and other tools.
  3. login: Starts a two phase user login by performing authenticating (same as "client" type). Used by login processes.
  4. master: Finishes the two phase user login by performing a userdb lookup (similar to "userdb" type). Used by post-login processes (e.g. imap, pop3).

With UNIX listeners the client type is selected based on the filename after the last "-" in the filename. For example "anything-userdb" is of "userdb" type. The default type is "client" for inet insteners and unrecognized UNIX listeners. You can add as many client and userdb listeners as you want (and you probably shouldn't touch the login/master listeners).


Auth master process connects to auth worker processes. It is mainly used by passdbs and userdbs that do potentially long running lookups. For example MySQL supports only synchronous lookups, so each query is run in a separate auth worker process that does nothing else during the query. PostgreSQL and LDAP supports asynchronous lookups, so those don't use worker processes at all. With some passdbs and userdbs you can select if worker processes should be used.


Config process reads and parses the dovecot.conf file, and exports the parsed data in simpler format to config clients.


Dovecot has a "lib-dict" API for doing simple key-value lookups/updates in various backends (SQL, file, others in future). This is optionally used by things like quota, expire plugin and other things in future. It would be wasteful for each mail process to separately create a connection to SQL, so usually they go through the "proxy" dict backend. These proxy connections are the client connections of dict processes.


Director tracker process, which hooks into all auth-client and auth-userdb connections.


Used by "lib-dns" library to perform asynchronous DNS lookups. The dns-client processes internally use the synchronous gethostbyname() function.


It's possible to run doveadm mail commands via doveadm server processes. This is useful for running doveadm commands for multiple users simultaneously, and it's also useful in a multiserver system where doveadm can automatically connect to the correct backend to run the command.

imap, pop3, managesieve

Post-login process for handling IMAP/POP3/ManageSieve client connections.

imap-login, pop3-login, managesieve-login

See LoginProcess.


Indexer master process, which tracks and prioritizes indexing requests from mail processes. The actual indexing is done by indexer-worker processes. The indexing means both updating Dovecot's internal index and cache files with new messages and more importantly updating full text search indexes (if enabled). The indexer master process guarantees that the FTS index is never modified by more than one process.


Indexer worker process.


IPC hub process.


LMTP process for delivering new mails.


All processes started via Dovecot master process log their messages via the "log" process. This allows some nice features compared to directly logging via syslog.


Build SSL parameters every n days, based on ssl_parameters_regenerate setting.


Mail process statistics tracking. Its behavior is very similar to the anvil process, but anvil's data is of higher importance and lower traffic than stats, so stats are tracked in a separate process.

Services (last edited 2015-09-15 19:31:50 by klara)