Dovecot:Main Page Dovecot

From Open-Xchange
Revision as of 08:39, 16 February 2017 by Khgras (talk | contribs)

Dovecot

Product Information/Overview

DOVECOT PRO

Dovecot Pro Overview

Dovecot Pro provides a reliable and scalable Mail solution to customers with enterprise level stability and scalability on top of the open source version. This product is built based on the experience the Dovecot Team has made by working for many years with the largest ISPs of the world. Dovecot Pro license enables Object Storage Plugins supports various object storages.

Dovecot Pro supports easy change from many existing IMAP and POP3 servers by allowing transparent migration of users in to Dovecot platform.

Dovecot Pro Product Components

Main Dovecot Pro Product components are:

  • Dovecot Pro Mail
  • Dovecot Object Storage
  • Dovecot Full Text Search
  • Dovecot Pro Vault
  • Dovecot Migration Framework

Dovecot Pro Mail

Overview

Depending the size of the installation Dovecot mail system contains servers in different roles: Proxies, Directors, Backends. Stateless design in Dovecot allows any of the components to be lost, shut down for maintenance or upgrade, without affecting the service availability. All the users on the same site will still receive service, only capacity providing the service is diminished, meaning that some speed of the service might be lost if system is under heavy load at that time. Dovecot architecture is possible to scale horizontally and vertically. The recommended network topology has:

  • Dovecot Proxy in public network,
  • Dovecot Director and Dovecot Backend in private network,
  • Object storage typically in Storage network.

Backends can use independent local storages or extensible-shared storage, like NFS or object storage. All Dovecot components include the same application but are configured to become different components. The Dovecot components are explained below in more detail.

Dovecot Proxy

Dovecot Proxies act as a frontend IMAP/POP3/LMTP servers for client connections. Dovecot Proxies make the user database lookup to LDAP to validate the user and to lookup the user parameters. In multi-site installations, Dovecot Proxy servers’ main function is to forward user to the load balancer in front of the Dovecot Director of the site where the user is located. Dovecot proxy also decrypts TLS/SSL sessions, which are more CPU consuming than the user lookup and traffic forwarding.

Dovecot Director

Directors listen to IMAP/POP3/LMTP protocols and balance load and provide high-availability for the Dovecot Backends.

The main difference between a regular load balancer and Dovecot Director is that the director makes sure that a single user is never accessed by different Backends at the same time. This is needed in order to avoid user data corruption. Dovecot Directors are taking care of this as they are sharing information of the users and user sessions while the user sessions are active. Each Dovecot Director knows which Backend is taking care of existing user session for any user. In front of Dovecot Directors there needs to be a load balancer to provide High Availability (HA) for them. Dovecot Directors are stateless meaning that any one of them can be switched off for maintenance without user noticing. This also makes updating procedures for the Dovecot components possible without interrupting the user session, thus making the operation transparent to user.

Dovecot Backend

Dovecot Backend does all the hard work of reading and writing mails to storage and handling all of the IMAP/POP3/LMTP protocols. Dovecot Backend is connected to mail storage, typically filesystem or cloud storage, where user mails and mail indexes are stored.

As an user is connecting to Dovecot for reading the mails the user’s mail indexes are fetched from the mail storage. The mail indexes are updated as long as the session is valid. This makes fetching of the user’s mail perform fast. As the session validity expires or the user logs off, the updated index is stored back to storage waiting for the next login. Dovecot Backends are stateless, making it possible for user connections to be connected to any Backend.

Dovecot Object Storage

Overview

Dovecot Pro supports mail storage to several object storage solutions.  These solutions include the ability to host on a managed cloud storage service such as Amazon S3 or to locally hosted object storage solutions such as Scality.  

If mails are stored to Object Storage, they can be accessed from any Backend, which are totally stateless as well as the other servers. All sessions of the same user are directed to the same Backend by Dovecot Director to prevent data corruption. As the user session reaches the Dovecot Backend the user’s indexes are loaded from object storage to local cache of the Backend. As the session is over, the indexes are loaded back to object storage. In the unlucky event of Backend failure the next Backend can continue where the other Backend left off since there are no locking problems (in comparison to NFS) and the indexes can be merged and updated by Dovecot Backend as soon as the servers are back on-line.

NFS storage is also supported, but this does not require Dovecot Object Storage plug-in.

Object Storage Advantages

The obox plugin is optimized for cloud technologies by enabling long-term email data storage into cloud storage solutions. The obox plugin tracks which index files have been altered or are needed locally and uploads / downloads them to object storage only as necessary.  This usage pattern most efficiently leverages the object storage paradigm, as opposed to a more traditional black storage strategy. The obox plugin consists of three major components. The first component is a sdbox-like mailbox format.  Each message is stored in its own “file” (a discrete object)I.  Indexes are bundled into separate discrete objects stored in objects storage. The second component is a collection of drivers, that implement support for various object storages, such as Amazon S3 and Scality sproxyd.  There is additionally a "fscache" driver that implements a local filesystem cache for mail objects. The third component is metadata storage for index files and and other metadata, such as Sieve scripts. It synchronizes these files between a local cache and the object storage.

Dovecot Full Text Search

Overview

As the amount and importance of information stored in email messages is increasing in people’s everyday lives, searching through those messages is becoming ever more important. At the same time mobile clients add their own restrictions for what can be done on the client side.

The ever-diversifying client software also tests the limits of the IMAP protocol and current server implementations. When an indexing Backend is not present, searches fall back on slow sequential searches through all message headers or text. Thus efficient and feature rich server side searching has grown in importance.

A two-part reimplementation of the Dovecot indexing and search architecture has been designed. This is to provide more customizability for searching and a more unified range of features for all existing FTS plugins. Additionally a renewed Dovecot native implementation of the full FTS stack is provided for better performance and scaling for large mail volumes.

Full text indexing and search

Triggers for Full Text Search (FTS) indexing are configurable. It can be started on demand when searching, automatically when new messages arrive or as a batch job. Full text search has the following features:

  • Indexes can be stored in the Object Storage
  • Smaller indexes compared to all current search Backends to improve search

performance

  • Avoid indexing duplicate data by using word stemming and normalization and skipping

bad character and stop words

  • Part of Dovecot mail server Backend, no 3rd party software needed
  • No extra java virtual machine needed for search sing word stemming and normalizat
  • Substring search for partial word search

Dovecot's standard IMAP SEARCH TEXT/BODY parameters use the FTS indexes. Searches through message headers benefit from Dovecot's fast message index cache implementation, which often contains the necessary information. Optionally header searches can also be done from FTS indexes.

Search Parameters

The following are specified as the search parameters to be used in the webmail User Interface to be passed on to the Dovecot Search Backend:

Details of the possible search queries can be found from here: http://wiki.dovecot.org/Tools/Doveadm/SearchQuery

Dovecot Pro Vault

Overview

The storage for Dovecot Vault is based on an existing cluster based on Obox. Emails are stored in a read-only namespace. Apart from the regular Obox configuration of the storage cluster, the namespace is configured as hidden and the containing mailbox is automatically created.

Read-only access to Vault e-mails

All mails stored in the archive namespace have to be read only. This is achieved using the “ACL” plugin to prevent deleting emails.

Incoming e-mails

Incoming e-mails are delivered to Dovecot via LMTP. The “Vault” plugin performs the job of storing the emails in the archive namespace first, and if that succeeds it begins the actual mail delivery, including running any Sieve scripts.

Outgoing e-mails

The SMTP submission server (e.g. Postfix) is used to catch outgoing e-mails and then BCCed to Dovecot’s LMTP via another port. LMTP will, then, deliver these e-mails to the archive namespace, as usual. The LMTP service for the outgoing e-mails will be configured to execute a sieve filtering script to store the email to the archive namespace and add the “\Seen” flag to it.

Vault Encryption

Emails stored in the archive namespace can be encrypted using the “mail-crypt” plugin. Encryption will be done using Elliptic Curve Cryptography.

Dovecot Migration Framework

Overview

Dovecot migration framework is a framework of controlling mailbox content migration from a centralized management system. Framework provides centralized repository to limit number of Backends running mailbox dsync processes and number of parallel dsync processes each Backend is allowed to run. It also gathers statistics from each Backend. Framework provides JSON/RESTAPI interface for integration into customers existing environment and management tools. Framework also optionally sends statistics information to Graphite server for progress visualisation.

The Migration Framework can be used for both Content and User Migration phases.

Key features

  • Queuing and distribution of accounts to migrate with locking for multiple Backends running the actual migration.
  • Centralized status display
  • Centralized statistics collection
  • Centralized control of number of Backends doing the actual content copy
  • Centralized control on number of parallel copies each Backend is allowed to run
  • Centralized log collection
  • Progress visualization with 3rd party Graphite possible

API status: In Development

Dovecot Advanced Documentation

PLEASE NOTE: This documentation is in production mode. Not finalized yet

Dovecot Pro Backend Configuration

See dovecot-backend.conf for the full example configuration file. This document explains the settings grouped to logical sections.

Note that this is not an exhaustive list of options that may need to be set for a Backend.

Generic Settings

protocols = imap pop3 smtp sieve

Protocols to enable.

verbose_proctitle = yes

Show state information in process titles (in “ps” output).

mail_log_prefix = "%s(%u)<%{session}>: "

Include the session string in all log messages to make it easier to match log lines together.

Authentication

Note that Proxy or Director already verifies the authentication (in the reference Dovecot architecture; password has been switched to a master password at this point), so we don’t really need to do it again. We could, in fact, even avoid the password checking entirely, but for extra security it’s still done in this document.

'auth_mechanisms = plain login

Enables the PLAIN and LOGIN authentication mechanisms. The LOGIN mechanism is obsolete, but still used by old Outlooks and some Microsoft phones.

service anvil {

  unix_listener anvil-auth-penalty {

    mode = 0

  }

}

Disable authentication penalty. Proxy/Director already handled this.

auth_cache_size = 100M

Specifies the amount of memory used for authentication caching (passdband userdb lookups).

login_trusted_networks = 10.0.0.0/24

Space-separated list of IP/network ranges that contain the Dovecot Directors. This setting allows Directors to forward the client’s original IP address and session ID to the Backends.

mail_max_userip_connections = 10

Maximum number of simultaneous IMAP/POP3 connections allowed for the same user from the same IP address (10 = 10 IMAP + 10 POP3)

ssl = no

disable_plaintext_auth = no

Proxy/Director already decrypted the SSL connections. The Backends will always see only plaintext connections.

LDAP Authentication

See http://wiki.dovecot.org/AuthDatabase/LDAP for more details.

passed {

  args = /etc/dovecot/dovecot-ldap.conf.ext

  driver = ldap

}

userdb {

  driver = prefetch

}

userdb {

  args = /etc/dovecot/dovecot-ldap.conf.ext

  driver = ldap

}

These enable LDAP to be used as passdb and userdb. The userdb prefetch allows IMAP/POP3 logins to do only a single LDAP lookup by returning the userdb information already in the passdb lookup. http://wiki.dovecot.org/UserDatabase/Prefetch has more details on the prefetch userdb. 

LDAP Backend Configuration

The included dovecot-ldap-backend.conf.ext can be used as template for the /etc/dovecot/dovecot-ldap.conf.ext. Its most important settings are:

hosts = ldap.example.com

dn = cn=admin,dc=example,dc=com

dnpass = secret

base = dc=example,dc=com

Configure how the LDAP server is reached.

auth_bind = yes

Use LDAP authentication binding for verifying users’ passwords.

blocking = yes

Use auth worker processes to perform LDAP lookups in order to use multiple concurrent LDAP connections. Otherwise only a single LDAP connection is used.

'pass_attrs = \

  =user=%{ldap:mailRoutingAddress}, \

  =password=%{ldap:userPassword}, \

  =userdb_quota_rule=*:storage=%{ldap:messageQuotaHard}k

Normalize the username to exactly the mailRoutingAddress field’s value regardless of how the pass_filter found the user. The userdb_quota_rule is used by userdb prefetch to return the userdb values. If other userdb fields are wanted, they must be placed to both user_attrs (without “userdb_” prefix) and pass_attrs (with “userdb_” prefix).

user_attrs = \

  =user=%{ldap:mailRoutingAddress}, \

  =quota_rule=*:storage=%{ldap:messageQuotaHard}

Returns userdb fields when prefetch userdb wasn’t used (LMTP & doveadm). The username is again normalized in case user_filter found it via some other means.

pass_filter = (mailRoutingAddress=%u)

user_filter = (mailRoutingAddress=%u)

How to find the user for passdb lookup.

iterate_attrs = mailRoutingAddress=user

iterate_filter = (objectClass= smiMessageRecipient)

How to iterate through all the valid usernames.

Mail Location Settings (Object Storage)

See http://wiki.dovecot.org/MailLocation for more details.

Note: these settings are assuming that message data is being stored in object storage (obox mailbox).  These settings should not be used if a block storage driver (e.g. mdbox) is being used. 

mail_home = /var/vmail/%2Mu/%u

Specifies the location for the local mail cache directory. This will contain Dovecot index files and it needs to be high performance (e.g. SSD storage).  Alternatively, if there is enough memory available to hold all concurrent users’ data at once, a tmpfs would work as well. The “%2Mu” takes the first 2 chars of the MD5 hash of the username so everything isn’t in one directory.

mail_uid = email

mail_gid = email

UNIX UID & GID which are used to access the local cache mail files.

mail_fsync = never

We can disable fsync()ing for better performance. It’s not a problem if locally cached index file modifications are lost.

mail_temp_dir = /tmp

Directory where downloaded/uploaded mails are temporarily stored to. Ideally all of these would stay in memory and never hit the disk, but in some situations the mails may have to be kept for a somewhat longer time and it ends up in disk. So there should be enough disk space available in the temporary filesystem.

mailbox_list_index = yes

Enable mailbox list indexes. This is required with obox format.

Namespace Settings

See http://wiki.dovecot.org/Namespaces for more details.

namespace inbox {

  prefix =

  separator = /

  inbox = yes

}

Configure the INBOX namespace with specified IMAP namespace prefix and separator. When migrating from an existing system the prefix and separator must match exactly what the old system used. Otherwise clients may download all mails again or become otherwise confused.

namespace inbox {

  mailbox Drafts {

    special_use = \Drafts

    auto = create

  }

mailbox Junk {

    special_use = \Junk

    auto = create   }

  mailbox Trash {

    special_use = \Trash

    auto = create

  }

  mailbox Sent {

    special_use = \Sent

    auto = create

  }

}

These can be used to automatically create some default folders for all users with auto=create settings. The autocreated folders aren’t automatically subscribed though, that can be done with auto=subscribe setting. The autocreated/autosubscribed folders can’t be deleted/unsubscribed by the users.

The special_use setting specifies the IMAP SPECIAL-USE (RFC 6154) flags for the folders. Some newer IMAP clients can use these to automatically configure themselves to use the server-provided default folder names. See http://imapwiki.org/SpecialUse

Obox Settings

mail_plugins = $mail_plugins box

Enable obox plugin.

mail_prefetch_count = 10

How many mails to download in parallel from object storage. A higher number improves the performance, but also increases the local disk usage and number of used file descriptors. This setting is also the default for obox_max_parallel_* settings below.

plugin {

  # Store object IDs to Dovecot indexes (will become default later)

  obox_use_object_ids = yes

  # How much disk space metacache can use before old data is cleaned up.   # This should usually fill up most of the available disk space.

  metacache_max_space = 200G

  # Avoid uploading indexes at the cost of more GETs on failures

  # (will become default later)

metacache_delay_uploads = yes

  # How often to upload modified indexes to object storage?   # This is done on background. Default 5 min.

  #metacache_upload_interval = 5min

  # If delayed index uploads are enabled, upload indexes anyway   # after this many mails have been saved. Default 10.

  #obox_max_rescan_mail_count = 10

  # Override mail_prefetch_count setting for write, copy and delete   # operations.

  #obox_max_parallel_writes = $mail_prefetch_count

  #obox_max_parallel_copies = $mail_prefetch_count

  #obox_max_parallel_deletes = $mail_prefetch_count

  # If user’s index cache was accessed max this many seconds ago, assume    # it’s up-to-date and there’s no need to refresh them from object storage.   # Default 2 seconds.

  metacache_close_delay = 2s

  # If activated, when an unexpected 404 is found when retrieving a   # message from object storage, Dovecot will rescan the mailbox by   # listing its objects.  If the 404-object is still listed in this query,   # Dovecot issues a HEAD to determine if the message actually exists.   # If this HEAD request returns a 404, the message is dropped from   # the index. The message object is not removed from the object   # storage.  THIS SHOULD NORMALLY NOT BE ACTIVATED.

  # obox_autofix_storage = no

}

The rest of the obox settings are specific to the object storage backend that is used.

fscache

plugin {

  obox_fs = fscache:1G:/var/cache/mails:…

}

All of the object storage Backends should be set up to use fscache with at least some amount of disk space, otherwise some operations will be very inefficient (such as IMAP client downloading a mail in small pieces). The fscache is also ideally large enough that when a mail is delivered, any IMAP and POP3 client that is actively downloading the mails should download it from the cache.

Other than that, the fscache doesn’t usually need to be very large. It’s more useful to give the extra disk space to metacache (obox_fs setting).

Note that if fscache sees cache write failures (e.g. out of disk space) those will cause client-visible errors. The disk space usage also isn’t strictly enforced due to race conditions, so if you set fscache limit to 1 GB it may temporarily grow above it. So make sure that the fscache always has some extra disk space available for writing (e.g. a 1 GB fscache mounted on a 1.1 GB mount point).

compress

plugin {

  obox_index_fs = compress:gz:6:…

}

All of the object storage backends should be set up to compress index bundle objects. This commonly shrinks the indexes down to 20-30% of the original size with gzip -6 compression. It’s possible to use also other compression algorithms. The level parameter must be between 1..9. See http://wiki.dovecot.org/Plugins/Zlib for the current list of supported algorithms.

Note: Currently, there is no compression auto-detection for index bundles.  Therefore, all index bundles must either be compressed (or uncompressed) in object storage; mixing and matching compressed index bundles is not possible automatically.

Email object (a/k/a message blob data) compression should be done with the zlib plugin instead of via the “compress” fs wrapper.  Example:

# See http://wiki.dovecot.org/Plugins/Zlib

mail_plugins = $mail_plugins lib

plugin {

  zlib_save = gz

  zlib_save_level = 6

}

Compression status of email object data is auto-detected.  Therefore, zlib_save may safely be added to a currently existing system; existing non-compressed mail objects will be identified correctly.

HTTP-based object storages

The HTTP-based object storages use an HTTP URL to specify how the object storage is accessed. The parameters are specified as URL-style parameters, such as http://url/?param1=value1&param2=value2. The parameters common to all object storages include:

  • connect_timeout_msecs=<ms>: Timeout for establishing a TCP connection (default: 5s)
  • max_connect_retries=<n>: Number of connect retries (default: 2)
  • timeout_msecs=<ms>: Timeout for receiving a HTTP response (default: 10s)
  • max_retries=<n>: Max number of HTTP request retries (default: 4)
  • addhdr=<name>:<value>: Add the specified header to all HTTP requests. This can only be specified once. This may be useful for load balancing purposes.

Scality CDMI

mail_location = obox:%2Mu/%2.3Mu/%u:INDEX=~/:CONTROL=~/

We’ll use 2 + 3 chars of the MD5 of the username at the beginning of each object path to improve performance. These directories should be pre-created to CDMI. The index and control dirs have to point to the user’s home directory.

plugin {

  obox_fs = fscache:1G:/var/cache/mails:scality:http://scality-url/mails/?addhdr=X-Dovecot-

Hash:%2Mu/%2.3Mu&bulk_delete=1&bulk_link=1

  obox_index_fs = compress:gz:6:scality:http://scality-url/mails/?addhdr=X-Dovecot-

Hash:%2Mu/%2.3Mu&bulk_delete=1&bulk_link=1

  # With bulk-delete and bulk-link enabled, these can be large:

  obox_max_parallel_copies = 100

  obox_max_parallel_deletes = 100

}

The X-Dovecot-Hash header is important for CDMI load balancer stickiness.

Amazon S3

mail_location = obox:%2Mu/%2.3Mu/%u:INDEX=~/:CONTROL=~/

We’ll use 2 + 3 chars of the MD5 of the username at the beginning of each object path to improve performance. The index and control dirs have to point to the user’s home directory.

plugin {

  obox_fs = fscache:1G:/var/cache/mails:s3: https://ACCESSKEY:SECRET@BUCKETNAME.s3.amazonaws.com/

  obox_index_fs = compress:gz:6:s3: https://ACCESSKEY:SECRET@BUCKETNAME.s3.amazonaws.com/

}

Get ACCESSKEY and SECRET from http://aws.amazon.com/ -> My account -> Security credentials -> Access credentials. Create the BUCKETNAME from AWS Management Console -> S3 -> Create Bucket.

If the ACCESSKEY or SECRET contains any special characters, they can be %hex-encoded. Note that dovecot.conf handles %variable expansion internally as well, so % needs to be escaped as %% and ‘:’ needs to be escaped as %%3A.

Mail Event Logging

See http://wiki.dovecot.org/Plugins/MailLog for more details.

mail_plugins = $mail_plugins notify mail_log

Enable the mail_log plugin.

plugin {

  mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename

  mail_log_fields = uid box msgid size from

}

Log a line about events that may cause message to be deleted. This is commonly useful when debugging why users have lost messages.

Quota

See http://wiki.dovecot.org/Quota/Configuration for more details.

mail_plugins = $mail_plugins quota

Enable quota plugin for tracking and enforcing the quota.

protocol map {

  mail_plugins = $mail_plugins map_quota

}

Enable the IMAP QUOTA extension, allowing IMAP clients to ask for the current quota usage.

plugin {

  quota = count:User quota

Track the current quota usage in Dovecot’s index files.

  quota_vsizes = yes

Required by quota=count backend. Indicates that the quota plugin should use “virtual sizes” rather than “physical sizes” when calculating message sizes. 

  quota_warning = storage=100%% quota-warning 100 %u

  quota_warning2 = storage=95%% quota-warning 95 %u

  quota_warning3 = -storage=100%% quota-warning below %u

Configure quota warning scripts to be triggered at specific sizes. Note that %% needs to be written twice to avoid %variable expansion. For example, at 95% usage a warning email could be sent to user. At 100% an external SMTP database could be updated to reject mails directly. At -100% user allow mails again. The “quota-warning” means to connect to the quota-warning UNIX socket, which is a Dovecot script service described below. }

service quota-warning {

  executable = script /usr/local/bin/quota-warning.sh

  user = email

  unix_listener quota-warning {

  }

}

Example quota-warning service which executes quota-warning.sh script.

You may also want to use quota_clone plugin to keep track of all the users’ quotas in an efficient database. (It’s very slow to query every user’s quota from the index files directly.) See http://wiki.dovecot.org/Plugins/QuotaClone 

IMAP

imap_client_workarounds = tb-extra-mailbox-sep tb-lsub-flags

Enable some workarounds for Thunderbird.

POP3

See http://wiki.dovecot.org/POP3Server for more details.

pop3_no_flag_updates = yes

Improve performance by not updating the IMAP \Seen flag whenever downloading mails via POP3.

pop3_client_workarounds = outlook-no-nuls oe-ns-eoh

Enable some workarounds for Outlook clients so they won’t hang on unexpected data.

pop3_uidl_format = %g

Use message GUID as POP3 UIDL. For old mails their UIDLs must be migrated using the migration scripts.

LMTP & Sieve

postmaster_address = postmaster@%d

Email address to use in the From: field for outgoing email rejections. The %d variable expands to the recipient domain.

submission_host = smtp-out.example.com:25

SMTP server which is used for sending email rejects, Sieve forwards, vacations, etc. Alternatively, sendmail_path setting can be used to send mails using the sendmail binary.

protocol smtp {

  mail_plugins = $mail_plugins sieve

}

Enable Sieve plugin.

Dovecot Pro Director Configuration

Generic Settings

protocols = imap pop3 smtp sieve

Protocols to enable.

verbose_proctitle = yes

Show state information in process titles (in “ps” output).

Authentication

See http://wiki2.dovecot.org/Authentication for more details.

auth_mechanisms = plain login

Enables the PLAIN and LOGIN authentication mechanisms. The LOGIN mechanism is obsolete, but still used by old Outlooks and some Microsoft phones.

auth_verbose = yes

Log a line for each authentication attempt failure.

auth_verbose_passwords = shall:6

Log the password hashed and truncated for failed authentication attempts. For example the SHA1 hash for “pass” is 9d4e1e23bd5b727046a9e3b4b7db57bd8d6ee684 but because of :6 we only log “9d4e1e”. This can be useful for detecting brute force authentication attempts without logging the users’ actual passwords.

service anvil {

  unix_listener anvil-auth-penalty {

    mode = 0

  }

}

Disable authentication penalty. This is explained in http://wiki2.dovecot.org/Authentication/Penalty

auth_cache_size = 100M

Specifies the amount of memory used for authentication caching (passdb and userdb lookups).

LDAP Authentication

See http://wiki2.dovecot.org/AuthDatabase/LDAP for more details. Note that a director proxy doesn’t need userdb configuration (unlike backends).

passed {

  args = /etc/dovecot/dovecot-ldap.conf.ext

  driver = ldap

}

This enables LDAP to be used as passdb.

The included dovecot-ldap-director.conf.ext can be used as template for the /etc/dovecot/dovecot-ldap.conf.ext. Its most important settings are:

hosts = ldap.example.com

dn = cn=admin,dc=example,dc=com

dnpass = secret

base = dc=example,dc=com

Configure how the LDAP server is reached.

auth_bind = yes

Use LDAP authentication binding for verifying users’ passwords.

blocking = yes

Use auth worker processes to perform LDAP lookups in order to use multiple concurrent LDAP connections. Otherwise only a single LDAP connection is used.

pass_attrs = \

  =proxy=y, \

  =proxy_timeout=10, \

  =user=%{ldap:mailRoutingAddress}, \

  =password=%{ldap:userPassword}

Normalize the username to exactly the mailRoutingAddress field’s value regardless of how the pass_filter found the user.

pass_filter = (mailRoutingAddress=%u)

iterate_attrs = mailRoutingAddress=user

iterate_filter = (objectClass= messageStoreRecipient)

How to iterate through all the valid usernames.

Director Configuration

See http://wiki2.dovecot.org/Director for more details.

director_mail_servers = dovecot-backends.example.com

This setting contains a space-separated list of Dovecot backends’ IP addresses or DNS names. One DNS entry may contain multiple IP addresses (which is maybe the simplest way to configure them).

director_servers = dovecot-directors.example.com

This setting contains a space-separated list of Dovecot directors’ IP addresses or DNS names. One DNS entry may contain multiple IP addresses (which is maybe the simplest way to configure them).

director_consistent_hashing = yes

This setting enables consistent hashing to director. This reduces users being moved around when doing backend changes. This will be the default setting in v2.3.

auth_socket_path = director-userdb

service director {

  fifo_listener login/proxy-notify {

    mode = 0600

    user = $default_login_user

  }

  net_listener {

    port = 9090

  }

  unix_listener director-userdb {

    mode = 0600

  }

  unix_listener login/director {

    mode = 0666

  }

  unix_listener director-admin {

    mode = 0600

  }

}

service pic {

  unix_listener pic {

    user = dovecot

  }

}

service imap-login {

  executable = imap-login director

}

service pop3-login {

  executable = pop3-login director

}

service managesieve-login {

  executable = managesieve-login director

}

All these settings configure the Dovecot director. They don’t usually need to be modified, except the TCP port 9090 may be changed. It is used for the directors’ internal communication.

You’ll also need to install poolmon (or equivalent) monitor script: https://github.com/brandond/poolmon 

Dovecot Proxy Configuration

See http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/Proxy for more details.

login_trusted_networks = 10.0.0.0/8

Include Dovecot Proxy’s IP addresses/network so they can pass through the session ID and the client’s original IP address. If Open-Xchange is connecting to Dovecot Directors, it’s also useful to provide OX’s IPs/network here for passing through its session ID and the web browser’s original IP address.

lmtp_proxy = yes

Enable LMTP to do proxying by doing passdb lookups (instead of only userdb lookups). login_proxy_max_disconnect_delay = 30 secs This setting is used to avoid load spikes caused by reconnecting clients after a backend server has died or been restarted. Instead of disconnecting all the clients at the same time, the disconnections are spread over longer time period. (v2.2.19+)

#doveadm_password =   This configures the doveadm server’s password. It can be used to access users’ mailboxes and do various other things, so it should be kept secret.

doveadm_port = 24245

service doveadm {

  net_listener {

    port = 24245

  }

}

These settings configure the doveadm port when acting as doveadm client and doveadm server.

service smtp {

  inet_listener smtp {

    port = 24

  }

}

This setting configures the LMTP port to use.

service imap-login {

  service_count = 0

  process_min_avail = 4

  process_limit = 4

}

These 3 settings configure the imap-login process to be in “high performance mode” as explained in http://wiki2.dovecot.org/LoginProcess. The 4 should be changed to the number of CPU cores on the server.

service pop3-login { 

service_count = 0

  process_min_avail = 4

  process_limit = 4

}

Enable high performance mode for POP3 as well (as explained above).

SSL Configuration

See http://wiki2.dovecot.org/SSL for more details.

disable_plaintext_auth = no

Should we allow plaintext authentication or require clients to always use SSL/TLS?

ssl_cert = </etc/dovecot/dovecot.crt

ssl_key = </etc/dovecot/dovecot.key

SSL certificate and SSL secret key files. You must use the “<” prefix so Dovecot reads the cert/key from the file. (Without “<” Dovecot assumes that the certificate is directly included in the dovecot.conf.)

For using different SSL certificates for different IP addresses you can put them inside local {} blocks:

local 10.0.0.1 {

  ssl_cert = </etc/dovecot/dovecot.crt

  ssl_key = </etc/dovecot/dovecot.key

}

local 10.0.0.2 {

  ssl_cert = </etc/dovecot/dovecot2.crt

  ssl_key = </etc/dovecot/dovecot2.key

}

If you need different SSL certificates for IMAP and POP3 protocols, you can put them inside protocol {} blocks :

local 10.0.0.1 {

  protocol map {

    ssl_cert = </etc/dovecot/dovecot-imap.crt

    ssl_key = </etc/dovecot/dovecot-imap.key

  }

  protocol pop3 {

    ssl_cert = </etc/dovecot/dovecot-pop3.crt

    ssl_key = </etc/dovecot/dovecot-pop3.key

  }

}

Dovecot supports also using TLS SNI extension for giving different SSL certificates based on the server name when using only a single IP address, but the TLS SNI isn’t yet supported by all clients so that may not be very useful. It’s anyway possible to configure it by using local_name imap.example.com {} blocks.

Dovemon monitoring tool

Dovemon is a backend monitoring tool for director hosts. It monitors backend responses and disables/enables backends if they stop responding. (Requires Dovecot v2.2.19 or later. For older versions use poolmon.)

Configuration file: /etc/dovecot/dovemon/config.yml:

loglevel: 4

syslog_facility: local5

director_admin_socket: /var/run/dovecot/director-admin

poll_imap: yes

poll_pop3: no

poll_lmtp: no

imap_ssl: no

pop3_ssl: no

lmtp_ssl: no

interval: 10

timeout: 3

retry_count: 3

logelevel:  0-4 syslog_facility: local5

  • Syslog facility to use when logging

director_admin_socket: /var/run/dovecot/director-admin

  • director-admin unix socket used for director admin communication. director-admin unix listener service needs to be configured in dovecot.conf

poll_imap: yes/no

  • use imap connection to poll backend

poll_pop3: yes/no                                                                   

  • use pop3 connection to poll backend

poll_lmtp: yes/no

  • use lmtp connection to poll backend

imap_ssl: yes/no

  • use ssl connection for map poll

pop3_ssl: yes/no

  • use ssl connection for pop3 poll

lmtp_ssl: yes/no

  • use ssl connection for lmtp poll

interval: 0-n

  • poll interval in seconds

timeout: 0-n

  • timeout in seconds for each poll

retry_count: 0-n

  • number of failed polls before issuing HOST-DOWN for the backend

Test accounts file: /etc/dovecot/dovemon/test.accounts.yml

10.2.2.75:

        username: user0001

        password: tosivaikeasalasana

10.2.2.76:

        username: user0002

        password: tosivaikeasalasana

This file allows configuring a separate test account for each backend. The backend must be specified using the same IP address as what “doveadm director status” shows for it.

dovemon issues HOST-DOWN on backend upon 3 (retry_count in config) consecutive failed polls. And issues HOST-UP on backend upon first successful poll if backend is already marked down.

OS Configuration

The default Linux configurations are usually quite good. The only thing needed for large installations is to increase /proc/sys/net/ipv4/ip_local_port_range to provide more local ports in case they run out when proxying. For example “1025 65000” could be a good value to more than double the available ports. If this is not enough, you need to use multiple local IP addresses and list them in login_source_ps setting.

Retrieved from "https://wiki.open-xchange.com/wiki/index.php?title=Dovecot:Main_Page_Dovecot&oldid=22931"