Customizing Dovecot

How to change SSL/TLS/cipher lists in dovecot

Every system has different requirements. From supporting older clients to enforcing new PCI rules, there is no single answer.

With DirectAdmin setups, we like to lean towards functionality first, and then admins can tighten things up if they need to (knowing it will alienate some clients).

First of all, please check the Current SSL cipher lists article.

With dovecot, the SSL settings are stored in /etc/dovecot/conf/ssl.conf, but do note that this file shouldn't be edited directly. You have to follow the general customization steps.

  1. To make a custom change to this file, use the CustomBuild custom directory, like this:
cd /usr/local/directadmin/custombuild
mkdir -p custom/dovecot/conf
cp configure/dovecot/conf/ssl.conf custom/dovecot/conf/ssl.conf
  1. Edit the copied file:
vi custom/dovecot/conf/ssl.conf

At the time of this writing (July 2018), the issue at hand is PCI compliance vs mail client support.

  1. We've changed the default to support the mail clients, so to enforce tighter TLS settings to be PCI compliant, you'd edit the custom ssl.conf, and change the ssl_min_protocol line to look like this:
ssl_min_protocol = TLSv1.1

where you'd change TLSv1 to TLSv1.1.

This file is also where you can change your cipher settings, if you need to do so.

Once you're happy with the settings in the custom/dovecot/conf/ssl.conf, you'd write it by typing:

./build dovecot_conf

This command installs the default configs, and then overwrites them with whatever is in the custom/dovecot/conf folder, thus installing your custom ssl.conf file.

How to force SSL encryption with Dovecot for IMAPS/POPS

These days it's best to force clients to use SSL encryption to authenticate with dovecot (imap/pop). Dovecot has a simple option for this:


which you can add to a /etc/dovecot/conf.d/force_ssl.conf new file and then restart dovecot:

service dovecot restart

Note: non-encrypted logins are still allowed on localhost addresses, in case you're confused why it's still allowing it.

To test, use a remote server, and test like this: IP: Username: user Password: password

telnet 143

and run command

01 LOGIN username password

You should see a message like this:

* BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed.
01 NO [PRIVACYREQUIRED] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.

If you're still connected, you can logout/close the telnet connection with:


Remote dovecot proxy server for clients SMTP, IMAP and POP

Lets say you have multiple DA boxes.

You want all of your clients to use one centralized mail server to connect to for sending SMTP emails with SMTP auth, webmail access, as well as IMAP/POP access to their inboxes.


  • Box A will be defined as the main hosting box where DirectAdmin and email data is all stored
  • Box B is the proxy server which does not require DA. It has a copy of the /etc/virtual/ file for proxying things back to box A.
  • Email to outside server, (eg: still leaves from box A.
  • Clients connect to box B for sending with SMTP, and downloading IMAP/POP, even though they could in theory still use A if they needed to (just omit that info from them to avoid confusion).
  • This is not "Mail Clustering" which would do everything on box B, data saved on B. Mail Clustering would be where DA on A manages accounts/passwords through DA on B, and exim/dovecot on B do everything. Clients only connect to B. Mail Clustering is not what this guide is for, only "Dovecot Proxy", where it's a single front-end (B) for other DA boxes (A1, A2, A3, etc).


Sound good? Here's how:

Box A

We need the main host box to be changed slightly:

  1. Relating to this featureopen in new window which adds the system "username" account to the virtual passwd files, add this to the directadmin.conf:
  1. Relating to this featureopen in new window which adds extra proxy info into the virtual password files, add this to the directadmin.conf :
  1. Rewrite all email passwd files to have the new settings, run this as root:
echo "action=rewrite&value=email_passwd" >> /usr/local/directadmin/data/task.queue
  1. Add the IP of your Box B to /etc/virtual/proxy_hosts_ip, update the exim configuration, and make sure eximconf_release is set to at least 4.5 because only 4.5.15 started to support the dovecot proxy feature:
cd /usr/local/directadmin/custombuild
./build update
./build set eximconf yes
./build eximconf

Backup your current /etc/dovecot directory from box A, as we'll copy it over to B:

cd /etc
tar cvzf /var/www/html/secretfile.tar.gz dovecot --exclude='dovecot/conf/sni'

Don't forget to delete this file when you've done everything.

  1. Allow proxy IP to be overwritten with a real client IP in Dovecot:
login_trusted_networks=PROXY_SERVER_IP > /etc/dovecot/conf.d/99-trusted-ips.conf
service dovecot restart

This will enable proper formatting of the virtual user files, so that they could be interpreted by dovecot and the connections would be forwarded to a correct host.

Box B

A clean OS without a DA installation could be used. Add an official Dovecot repository and install Dovecot using yum/apt-get/pkg. Ensure that at least version 2.3 of dovecot is installed. If your repo does not provide this or a later release, follow the guidelines to add the required repo to your package manager: https://repo.dovecot.orgopen in new window

  1. Backup existing dovecot configuration directory:
mv /etc/dovecot /etc/dovecot_conf_orig
  1. Copy /etc/dovecot configuration directory from any DA server, let's use the one we created from step (4) above:
cd /etc
tar xvzf secretfile.tar.gz
  1. Ensure that 'submission' is amongst the enabled protocols in /etc/dovecot/conf/protocols.conf:
protocols = imap pop3 lmtp submission
  1. Copy additional config files from the original dovecot:
cp -n /etc/dovecot_conf_orig/conf.d/20-submission.conf /etc/dovecot/conf.d/
  1. Modify /etc/dovecot/conf.d/20-submission.conf:
submission_relay_host =
submission_relay_port = 10025
submission_relay_ssl = starttls
submission_relay_ssl_verify = no
  1. Copy or create SSL certificate/key:
  1. Enable/restart the dovecot service like so:
systemctl daemon-reload
systemctl enable dovecot.service
service dovecot start
  1. To enable submission on ports 25/465 (if needed, because it listens on port 587 by default), add the following to /etc/dovecot/dovecot.conf:
auth_mechanisms = plain login
service submission-login {
  inet_listener submission_25 {
    port = 25
inet_listener submission_465 {
  port = 465
  ssl = yes
  1. If an outbound firewall is enabled, please allow access to 10025/TCP.

Box A

Now we need to sync the /etc/virtual/*/passwd files from every DA server to the proxy server (the proxy server can fetch it from the DA server(s) as well, but it's more secure to do it vice-versa).

For example, we could use the following cronjob:

rsync -avt --include "*/" --include="passwd" --exclude="*" --prune-empty-dirs /etc/virtual/ root@PROXY_SERVER_IP:/etc/virtual/

The proxy server just needs the /etc/virtual/ rsync to work, so that overwritten domains/domainowners files will not cause any problems.

How to change the ports in dovecot

By default, dovecot runs pop, imap, pop3 and imaps on the following ports:

110: pop
143: imap
995: pop3s
993: imaps

If you wish to change the port values in dovecot, edit the file /etc/dovecot/dovecot.conf. For this example, we'll increase the port numbers by 1, but you can adjust the values as desired.

Find the code:

service imap-login {
   process_min_avail = 16
   user = dovecot
service pop3-login {
   process_min_avail = 16
   user = dovecot

and change it to look like:

service imap-login {
   process_min_avail = 16
   user = dovecot

   inet_listener imap {
      port = 144
   inet_listener imaps {
      port = 994
      ssl = yes
service pop3-login {
   process_min_avail = 16
   user = dovecot

   inet_listener pop3 {
      port = 111
   inet_listener pop3s {
      port = 996
      ssl = yes

Save/Exit, and restart dovecot:

service dovecot restart

View multiple E-Mail accounts from one master

Say you have account @ and you want to be able to login to this account, and have sub-directories for several other accounts on the same domain. This would allow you to login to, and by simply clicking on IMAP sub-folders, you can see the E-Mails in the other accounts.

Let's call the sub-account

The domain is owned by User .

You can setup the sub-directory under the master account by typing:

cd "/home/username/imap/"
ln -s "../../worker/Maildir" "./.worker"
chown -h "username:mail" "./.worker"
echo "worker" >> subscriptions

Then login to to confirm it works.

Repeat this for each different sub account you want to show up in the master account.

Note: this only shows the INBOX of the account. You'd need to add the other sub-folders you might want, e.g.,

echo "worker.Sent" >> subscriptions

keeping in mind that some webmail clients may be able to actually see the available folders to subscribe to.

Dovecot Full Text Search (FTS) with fts-xapian

CustomBuild 2.0 now supports fts-xapian, which allows for a very speedy full-text search of your emails.

To install fts-xapian, run:

cd /usr/local/directadmin/custombuild
./build update
./build dovecot
./build fts-xapian

Note, you may experience a short period of higher than average load while all emails get indexed for searching.

To disable/remove it:

cd /usr/local/directadmin/custombuild
rm -f /usr/lib64/dovecot/lib21_fts_xapian_plugin*
rm -f /etc/dovecot/conf.d/90-fts-xapian.conf
./build dovecot_conf

Depending on your OS, fts_xapian_plugin files might be located in the following path instead /usr/lib64/dovecot/lib21_fts_xapian_plugin*

Related forum post: in new window

How to enable email compression

Enabling email compression for new emails

CustomBuild 2 features the option to compress new emails, which can result in much less disk space used on busy mail servers. It prioritizes zstd compression if it is available and resorts to using gzip compression if not. To enable email compression, you should use dovecot and dovecot_conf as provided by CustomBuild (dovecot=yes and dovecot_conf=yes settings in the /usr/local/directadmin/custombuild/options.conf), and then issue the following commands:

cd /usr/local/directadmin/custombuild
./build set mail_compress yes
./build dovecot_conf

This adds the /etc/dovecot/conf.d/90-zlib.conf file, which defines Dovecot's zlib plugin compression rules. When completed, all new emails will be compressed.

If you need to first enable dovecot and dovecot_conf, use these commands:

cd /usr/local/directadmin/custombuild
./build set dovecot yes
./build set dovecot_conf yes
./build dovecot
./build dovecot_conf

If you need to build zstd compression with CustomBuild, you can do so using these commands:

cd /usr/local/directadmin/custombuild
./build zstd

You may also check to confirm that zstd is enabled via DirectAdmin (in case you want to use zstd for compression/decompression of your backups/restores or in the File Manager in addition to Dovecot emails):

/usr/local/directadmin/directadmin config| grep zstd

Enabling email compression for existing emails

DirectAdmin also provides a script to compress existing emails, The process is time-consuming (it can run for a day or more depending on the amount to data to compress/decompress) so it's better to launch it in screen:


You can compress or decompress all or just a certain email account's mail:

/usr/local/directadmin/scripts/ /home/user/imap/
/usr/local/directadmin/scripts/ all
/usr/local/directadmin/scripts/ /home/user/imap/ decompress
/usr/local/directadmin/scripts/ decompress_all

It's also safe to run the script more than once if needed.

Last Updated: