When check_pubkey = true; is set, Rspamd will query the DNS record for each DKIM selector, verifying each public key matches the private key configured.
If there is a mismatch, a warning will be omitted to the Rspamd log /var/log/supervisor/rspamd.log.
If there is a mismatch, a warning will be emitted to the Rspamd log /var/log/supervisor/rspamd.log.
Can be used to enable or disable the Hfilter group module. This is used by DMS to adjust the HFILTER_HOSTNAME_UNKNOWN symbol, increasing it's default weight to act similar to Postfix's reject_unknown_client_hostname, without the need to outright reject a message.
Can be used to enable or disable the Hfilter group module. This is used by DMS to adjust the HFILTER_HOSTNAME_UNKNOWN symbol, increasing its default weight to act similar to Postfix's reject_unknown_client_hostname, without the need to outright reject a message.
docker-mailserver!","text":"This Documentation is Versioned
Make sure to select the correct version of this documentation! It should match the version of the image you are using. The default version corresponds to the :latest image tag - the most recent stable release.
This documentation provides you not only with the basic setup and configuration of DMS but also with advanced configuration, elaborate usage scenarios, detailed examples, hints and more.
"},{"location":"#about","title":"About","text":"docker-mailserver, or DMS for short, is a production-ready fullstack but simple mail server (SMTP, IMAP, LDAP, Antispam, Antivirus, etc.). It employs only configuration files, no SQL database. The image is focused around the slogan \"Keep it simple and versioned\".
If you're completely new to mail servers or you want to read up on them, check out our Introduction page. If you're new to DMS as a mail server appliance, make sure to read the Usage chapter first. If you want to look at examples for Docker Compose, we have an Examples page.
There is also a script - setup.sh - supplied with this project. It supports you in configuring and administrating your server. Information on how to get it and how to use it is available on a dedicated page.
We have a dedicated configuration page. It contains most of the configuration and explanation you need to setup your mail server properly. Be aware that advanced tasks may still require reading through all parts of this documentation; it may also involve inspecting your running container for debugging purposes. After all, a mail server is a complex arrangement of various programs.
Important
If you'd like to change, patch or alter files or behavior of DMS, you can use a script. Just place a script called user-patches.sh in your ./docker-data/dms/config/ folder volume (which is mounted to /tmp/docker-mailserver/ inside the container) and it will be run on container startup. See the 'Modifications via Script' page for additional documentation and an example.
You might also want to check out:
Tip
Definitely check out the FAQ for more information and tips! Please do not open an issue before you have checked our documentation for answers, including the FAQ!
"},{"location":"#tests","title":"Tests","text":"DMS employs a variety of tests. If you want to know more about our test suite, view our testing docs.
"},{"location":"#contributing","title":"Contributing","text":"We are always happy to welcome new contributors. For guidelines and entrypoints please have a look at the Contributing section.
"},{"location":"faq/","title":"FAQ","text":""},{"location":"faq/#what-kind-of-database-are-you-using","title":"What kind of database are you using?","text":"None! No database is required. The filesystem is the database. This image is based on config files that can be persisted using bind mounts (default) or Docker volumes, and as such versioned, backed up and so forth.
"},{"location":"faq/#where-are-emails-stored","title":"Where are emails stored?","text":"Mails are stored in /var/mail/${domain}/${username}. Since v9.0.0 it is possible to add custom user_attributes for each accounts to have a different mailbox configuration (See #1792).
INBOX is setup by default with the special IMAP folders Drafts, Sent, Junk and Trash. You can learn how to modify or add your own folders (including additional special folders like Archive) by visiting our docs page Customizing IMAP Folders for more information.
Make sure to read the CHANGELOG before updating to new versions, to be prepared for possible breaking changes.
Then, run the following commands:
docker compose pull\ndocker compose down\ndocker compose up -d\nYou should see the new version number on startup, for example: [ INF ] Welcome to docker-mailserver 11.3.1. And you're done! Don't forget to have a look at the remaining functions of the setup.sh script with ./setup.sh help.
As you'll realistically be deploying to production on a Linux host, if you are on Windows or macOS and want to run the image locally first, it's advised to do so via a VM guest running Linux if you have issues running DMS on your host system.
"},{"location":"faq/#what-are-the-system-requirements","title":"What are the system requirements?","text":""},{"location":"faq/#recommended","title":"Recommended","text":"Warning
ClamAV can consume a lot of memory, as it reads the entire signature database into RAM.
Current figure is about 850M and growing. If you get errors about ClamAV or amavis failing to allocate memory you need more RAM or more swap and of course docker must be allowed to use swap (not always the case). If you can't use swap at all you may need 3G RAM.
"},{"location":"faq/#how-to-alter-a-running-dms-instance-without-relaunching-the-container","title":"How to alter a running DMS instance without relaunching the container?","text":"DMS aggregates multiple \"sub-services\", such as Postfix, Dovecot, Fail2ban, SpamAssassin, etc. In many cases, one may edit a sub-service's config and reload that very sub-service, without stopping and relaunching the whole mail server.
In order to do so, you'll probably want to push your config updates to your server through a Docker volume (these docs use: ./docker-data/dms/config/:/tmp/docker-mailserver/), then restart the sub-service to apply your changes, using supervisorctl. For instance, after editing fail2ban's config: supervisorctl restart fail2ban.
See the documentation for supervisorctl.
Tip
To add, update or delete an email account; there is no need to restart postfix / dovecot service inside the container after using setup.sh script.
For more information, see #1639.
"},{"location":"faq/#how-can-i-sync-the-container-and-host-datetime","title":"How can I sync the container and host date/time?","text":"Share the host's /etc/localtime with the container, e.g. by using a bind mount:
volumes:\n- /etc/localtime:/etc/localtime:ro\nOptionally, you can set the TZ ENV variable; e.g. TZ=Europe/Berlin. Check this list for which values are allowed.
All files are using the Unix format with LF line endings. Please do not use CRLF.
DMS supports multiple domains out of the box, so you can do this:
./setup.sh email add user1@example.com\n./setup.sh email add user1@example.de\n./setup.sh email add user1@server.example.org\nFrom the location of your compose.yaml, create a compressed archive of your docker-data/dms/config/ and docker-data/dms/mail-* folders:
tar --gzip -cf \"backup-$(date +%F).tar.gz\" ./docker-data/dms\nThen to restore docker-data/dms/config/ and docker-data/dms/mail-* folders from your backup file:
tar --gzip -xf backup-date.tar.gz\nAssuming that you use docker-compose and data volumes, you can backup the configuration, emails and logs like this:
# create backup\ndocker run --rm -it \\\n-v \"${PWD}/docker-data/dms/config/:/tmp/docker-mailserver/\" \\\n-v \"${PWD}/docker-data/dms-backups/:/backup/\" \\\n--volumes-from mailserver \\\nalpine:latest \\\ntar czf \"/backup/mail-$(date +%F).tar.gz\" /var/mail /var/mail-state /var/log/mail /tmp/docker-mailserver\n\n# delete backups older than 30 days\nfind \"${PWD}/docker-data/dms-backups/\" -type f -mtime +30 -delete\nSee this part of the documentation for further details and best practice advice, especially regarding security concerns.
"},{"location":"faq/#how-can-i-configure-my-email-client","title":"How can I configure my email client?","text":"Login is full email address (<user>@<domain>).
# IMAP\nusername: <user1@example.com>\npassword: <mypassword>\nserver: <mail.example.com>\nimap port: 143 or 993 with STARTTLS/SSL (recommended)\nimap path prefix: INBOX\n\n# SMTP\nsmtp port: 25 or 587/465 with STARTTLS/SSL (recommended)\nusername: <user1@example.com>\npassword: <mypassword>\nDMS is properly configured for port 587, if possible, we recommend using port 465 for SMTP though. See this section to learn more about ports.
"},{"location":"faq/#can-i-use-a-nakedbare-domain-ie-no-hostname","title":"Can I use a naked/bare domain (i.e. no hostname)?","text":"Yes, but not without some configuration changes. Normally it is assumed that DMS runs on a host with a name, so the fully qualified host name might be mail.example.com with the domain example.com. The MX records point to mail.example.com.
To use a bare domain (where the host name is example.com and the domain is also example.com), change mydestination:
mydestination = $myhostname, localhost.$mydomain, localhostmydestination = localhost.$mydomain, localhostAdd the latter line to docker-data/dms/config/postfix-main.cf. If that doesn't work, make sure that OVERRIDE_HOSTNAME is blank in your mailserver.env file. Without these changes there will be warnings in the logs like:
warning: do not list domain example.com in BOTH mydestination and virtual_mailbox_domains\nPlus of course mail delivery fails.
Also you need to define hostname: example.com in your compose.yaml.
You might not want a bare domain
We encourage you to consider using a subdomain where possible.
user@example.com, that is distinct from your hostname which is identified by a DNS MX record.Considering you want to redirect all incoming e-mails for the domain example.com to user1@example.com, add the following line to docker-data/dms/config/postfix-virtual.cf:
@example.com user1@example.com\nFirst of all, create a special alias named devnull by editing docker-data/dms/config/postfix-aliases.cf:
devnull: /dev/null\nConsidering you want to delete all the e-mails received for baduser@example.com, add the following line to docker-data/dms/config/postfix-virtual.cf:
baduser@example.com devnull\nImportant
If you use a catch-all rule for the main/sub domain, you need another entry in docker-data/dms/config/postfix-virtual.cf:
@mail.example.com hello@example.com\nbaduser@example.com devnull\ndevnull@mail.example.com devnull\nBoth RSA and ECDSA certs are supported. You can provide your own cert files manually, or mount a letsencrypt generated directory (with alternative support for Traefik's acme.json). Check out the SSL_TYPE documentation for more details.
If this migration implies a DNS modification, be sure to wait for DNS propagation before opening an issue. Few examples of symptoms can be found here or here.
This could be related to a modification of your MX record, or the IP mapped to mail.example.com. Additionally, validate your DNS configuration.
If everything is OK regarding DNS, please provide formatted logs and config files. This will allow us to help you.
If we're blind, we won't be able to do anything.
"},{"location":"faq/#connection-refused-or-no-response-at-all","title":"Connection refused or No response at all","text":"You see errors like \"Connection Refused\" and \"Connection closed by foreign host\", or you cannot connect at all? You may not be able to connect with your mail client (MUA)? Make sure to check Fail2Ban did not ban you (for exceeding the number of tried logins for example)! You can run
docker exec <CONTAINER NAME> setup fail2ban\nand check whether your IP address appears. Use
docker exec <CONTAINER NAME> setup fail2ban unban <YOUR IP>\nto unban the IP address.
"},{"location":"faq/#how-can-i-authenticate-users-with-smtp_only1","title":"How can I authenticate users withSMTP_ONLY=1?","text":"See #1247 for an example.
Todo
Write a How-to / Use-Case / Tutorial about authentication with SMTP_ONLY.
warning: connect to Milter service inet:localhost:8893: Connection refused\n# DMARC not running\n# => /etc/init.d/opendmarc restart\n\nwarning: connect to Milter service inet:localhost:8891: Connection refused\n# DKIM not running\n# => /etc/init.d/opendkim restart\n\nmail amavis[1459]: (01459-01) (!)connect to /var/run/clamav/clamd.ctl failed, attempt #1: Can't connect to a UNIX socket /var/run/clamav/clamd.ctl: No such file or directory\nmail amavis[1459]: (01459-01) (!)ClamAV-clamd: All attempts (1) failed connecting to /var/run/clamav/clamd.ctl, retrying (2)\nmail amavis[1459]: (01459-01) (!)ClamAV-clamscan av-scanner FAILED: /usr/bin/clamscan KILLED, signal 9 (0009) at (eval 100) line 905.\nmail amavis[1459]: (01459-01) (!!)AV: ALL VIRUS SCANNERS FAILED\n# Clamav is not running (not started or because you don't have enough memory)\n# => check requirements and/or start Clamav\nUsing user-patches.sh, update the container file /etc/postfix/main.cf to include:
proxy_interfaces = X.X.X.X (your public IP)\nuser-patches.sh script","text":"Suppose you want to change a number of settings that are not listed as variables or add things to the server that are not included?
DMS has a built-in way to do post-install processes. If you place a script called user-patches.sh in the config directory it will be run after all configuration files are set up, but before the postfix, amavis and other daemons are started.
It is common to use a local directory for config added to docker-mailsever via a volume mount in your compose.yaml (eg: ./docker-data/dms/config/:/tmp/docker-mailserver/).
Add or create the script file to your config directory:
cd ./docker-data/dms/config\ntouch user-patches.sh\nchmod +x user-patches.sh\nThen fill user-patches.sh with suitable code.
If you want to test it you can move into the running container, run it and see if it does what you want. For instance:
# start shell in container\n./setup.sh debug login\n\n# check the file\ncat /tmp/docker-mailserver/user-patches.sh\n\n# run the script\n/tmp/docker-mailserver/user-patches.sh\n\n# exit the container shell back to the host shell\nexit\nYou can do a lot of things with such a script. You can find an example user-patches.sh script here: example user-patches.sh script.
We also have a very similar docs page specifically about this feature!
Special use-case - patching the supervisord configuration
It seems worth noting, that the user-patches.sh gets executed through supervisord. If you need to patch some supervisord config (e.g. /etc/supervisor/conf.d/saslauth.conf), the patching happens too late.
An easy workaround is to make the user-patches.sh reload the supervisord config after patching it:
#!/bin/bash\nsed -i 's/rimap -r/rimap/' /etc/supervisor/conf.d/saslauth.conf\nsupervisorctl update\nUse the following command:
./setup.sh fail2ban ban <IP>\nThe default bantime is 180 days. This value can be customized.
"},{"location":"faq/#what-to-do-in-case-of-spfforwarding-problems","title":"What to do in case of SPF/Forwarding problems","text":"If you got any problems with SPF and/or forwarding mails, give SRS a try. You enable SRS by setting ENABLE_SRS=1. See the variable description for further information.
There are many reasons why email might be rejected, common causes are:
DMS does not manage those concerns, verify they are not causing your delivery problems before reporting a bug on our issue tracker. Resources that can help you troubleshoot:
docker-data/dms/config/ Directory?","text":"This documentation and all example configuration files in the GitHub repository use docker-data/dms/config/ to refer to the directory in the host that is mounted (e.g. via a bind mount) to /tmp/docker-mailserver/ inside the container.
Most configuration files for Postfix, Dovecot, etc. are persisted here. Optional configuration is stored here as well.
"},{"location":"faq/#what-about-the-docker-datadmsmail-state-directory","title":"What About thedocker-data/dms/mail-state/ Directory?","text":"This documentation and all example configuration files in the GitHub repository use docker-data/dms/mail-state/ to refer to the directory in the host that is mounted (e.g. via a bind mount) to /var/mail-state/ inside the container.
When you run DMS with the ENV variable ONE_DIR=1 (default), this directory will provide support to persist Fail2Ban blocks, ClamAV signature updates, and the like when the container is restarted or recreated. Service data is relocated to the mail-state folder for the following services: Postfix, Dovecot, Fail2Ban, Amavis, PostGrey, ClamAV, SpamAssassin, Rspamd & Redis.
Antispam rules are managed in docker-data/dms/config/spamassassin-rules.cf.
SA_SPAM_SUBJECT values?","text":"For no subject set SA_SPAM_SUBJECT=undef.
For a trailing white-space subject one can define the whole variable with quotes in compose.yaml:
environment:\n- \"SA_SPAM_SUBJECT=[SPAM] \"\nx-headers not inserted into my subdomain.example.com subdomain emails?","text":"In the default setup, amavis only applies SpamAssassin x-headers into domains matching the template listed in the config file (05-domain_id in the amavis defaults).
The default setup @local_domains_acl = ( \".$mydomain\" ); does not match subdomains. To match subdomains, you can override the @local_domains_acl directive in the amavis user config file 50-user with @local_domains_maps = (\".\"); to match any sort of domain template.
Put received spams in .Junk/ imap folder using SPAMASSASSIN_SPAM_TO_INBOX=1 and MOVE_SPAM_TO_JUNK=1 and add a user cron like the following:
# This assumes you're having `environment: ONE_DIR=1` in the `mailserver.env`,\n# with a consolidated config in `/var/mail-state`\n#\n# m h dom mon dow command\n# Everyday 2:00AM, learn spam from a specific user\n0 2 * * * docker exec mailserver sa-learn --spam /var/mail/example.com/username/.Junk --dbpath /var/mail-state/lib-amavis/.spamassassin\nWith docker-compose you can more easily use the internal instance of cron within DMS. This is less problematic than the simple solution shown above, because it decouples the learning from the host on which DMS is running, and avoids errors if the mail server is not running.
The following configuration works nicely:
ExampleCreate a system cron file:
# in the compose.yaml root directory\nmkdir -p ./docker-data/dms/cron\ntouch ./docker-data/dms/cron/sa-learn\nchown root:root ./docker-data/dms/cron/sa-learn\nchmod 0644 ./docker-data/dms/cron/sa-learn\nEdit the system cron file nano ./docker-data/dms/cron/sa-learn, and set an appropriate configuration:
# This assumes you're having `environment: ONE_DIR=1` in the env-mailserver,\n# with a consolidated config in `/var/mail-state`\n#\n# '> /dev/null' to send error notifications from 'stderr' to 'postmaster@example.com'\n#\n# m h dom mon dow user command\n#\n# Everyday 2:00AM, learn spam from a specific user\n# spam: junk directory\n0 2 * * * root sa-learn --spam /var/mail/example.com/username/.Junk --dbpath /var/mail-state/lib-amavis/.spamassassin > /dev/null\n# ham: archive directories\n15 2 * * * root sa-learn --ham /var/mail/example.com/username/.Archive* --dbpath /var/mail-state/lib-amavis/.spamassassin > /dev/null\n# ham: inbox subdirectories\n30 2 * * * root sa-learn --ham /var/mail/example.com/username/cur* --dbpath /var/mail-state/lib-amavis/.spamassassin > /dev/null\n#\n# Everyday 3:00AM, learn spam from all users of a domain\n# spam: junk directory\n0 3 * * * root sa-learn --spam /var/mail/not-example.com/*/.Junk --dbpath /var/mail-state/lib-amavis/.spamassassin > /dev/null\n# ham: archive directories\n15 3 * * * root sa-learn --ham /var/mail/not-example.com/*/.Archive* --dbpath /var/mail-state/lib-amavis/.spamassassin > /dev/null\n# ham: inbox subdirectories\n30 3 * * * root sa-learn --ham /var/mail/not-example.com/*/cur* --dbpath /var/mail-state/lib-amavis/.spamassassin > /dev/null\nThen with compose.yaml:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\nvolumes:\n- ./docker-data/dms/cron/sa-learn:/etc/cron.d/sa-learn\nOr with Docker Swarm:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\n# ...\nconfigs:\n- source: my_sa_crontab\ntarget: /etc/cron.d/sa-learn\n\nconfigs:\nmy_sa_crontab:\nfile: ./docker-data/dms/cron/sa-learn\nWith the default settings, SpamAssassin will require 200 mails trained for spam (for example with the method explained above) and 200 mails trained for ham (using the same command as above but using --ham and providing it with some ham mails). Until you provided these 200+200 mails, SpamAssassin will not take the learned mails into account. For further reference, see the SpamAssassin Wiki.
By default, SPAM and INFECTED emails are put to a quarantine which is not very straight forward to access. Several config settings are affecting this behavior:
First, make sure you have the proper thresholds set:
SA_TAG=-100000.0\nSA_TAG2=3.75\nSA_KILL=100000.0\nSA_TAG makes sure, that all emails have the SpamAssassin headers included.SA_TAG2 is the actual threshold to set the YES/NO flag for spam detection.SA_KILL needs to be very high, to make sure nothing is bounced at all (SA_KILL superseeds SPAMASSASSIN_SPAM_TO_INBOX)Make sure everything (including SPAM) is delivered to the inbox and not quarantined:
SPAMASSASSIN_SPAM_TO_INBOX=1\nUse MOVE_SPAM_TO_JUNK=1 or create a sieve script which puts spam to the Junk folder:
require [\"comparator-i;ascii-numeric\",\"relational\",\"fileinto\"];\n\nif header :contains \"X-Spam-Flag\" \"YES\" {\n fileinto \"Junk\";\n} elsif allof (\n not header :matches \"x-spam-score\" \"-*\",\n header :value \"ge\" :comparator \"i;ascii-numeric\" \"x-spam-score\" \"3.75\" ) {\n fileinto \"Junk\";\n}\nCreate a dedicated mailbox for emails which are infected/bad header and everything amavis is blocking by default and put its address into docker-data/dms/config/amavis.cf
$clean_quarantine_to = \"amavis\\@example.com\";\n$virus_quarantine_to = \"amavis\\@example.com\";\n$banned_quarantine_to = \"amavis\\@example.com\";\n$bad_header_quarantine_to = \"amavis\\@example.com\";\n$spam_quarantine_to = \"amavis\\@example.com\";\nThis article answers the question \"What is a mail server, and how does it perform its duty?\" and it gives the reader an introduction to the field that covers everything you need to know to get started with DMS.
"},{"location":"introduction/#the-anatomy-of-a-mail-server","title":"The Anatomy of a Mail Server","text":"A mail server is only a part of a client-server relationship aimed at exchanging information in the form of emails. Exchanging emails requires using specific means (programs and protocols).
DMS provides you with the server portion, whereas the client can be anything from a terminal via text-based software (eg. Mutt) to a fully-fledged desktop application (eg. Mozilla Thunderbird, Microsoft Outlook\u2026), to a web interface, etc.
Unlike the client-side where usually a single program is used to perform retrieval and viewing of emails, the server-side is composed of many specialized components. The mail server is capable of accepting, forwarding, delivering, storing and overall exchanging messages, but each one of those tasks is actually handled by a specific piece of software. All of these \"agents\" must be integrated with one another for the exchange to take place.
DMS has made informed choices about those components and their (default) configuration. It offers a comprehensive platform to run a fully featured mail server in no time!
"},{"location":"introduction/#components","title":"Components","text":"The following components are required to create a complete delivery chain:
Here's a schematic view of mail delivery:
Sending an email: MUA ----> MTA ----> (MTA relays) ----> MDA\nFetching an email: MUA <--------------------------------- MDA\nThere may be other moving parts or sub-divisions (for instance, at several points along the chain, specialized programs may be analyzing, filtering, bouncing, editing\u2026 the exchanged emails).
In a nutshell, DMS provides you with the following components:
Here's where DMS's toochain fits within the delivery chain:
docker-mailserver is here:\n \u250f\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2513\nSending an email: MUA ---> MTA ---> (MTA relays) ---> \u252b MTA \u256e \u2503\nFetching an email: MUA <------------------------------ \u252b MDA \u256f \u2503\n \u2517\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u251b\nLet's say Alice owns a Gmail account, alice@gmail.com; and Bob owns an account on a DMS instance, bob@dms.io.
Make sure not to conflate these two very different scenarios: A) Alice sends an email to bob@dms.io => the email is first submitted to MTA smtp.gmail.com, then relayed to MTA smtp.dms.io where it is then delivered into Bob's mailbox. B) Bob sends an email to alice@gmail.com => the email is first submitted to MTA smtp.dms.io, then relayed to MTA smtp.gmail.com and eventually delivered into Alice's mailbox.
In scenario A the email leaves Gmail's premises, that email's initial submission is not handled by your DMS instance(MTA); it merely receives the email after it has been relayed by Gmail's MTA. In scenario B, the DMS instance(MTA) handles the submission, prior to relaying.
The main takeaway is that when a third-party sends an email to a DMS instance(MTA) (or any MTA for that matter), it does not establish a direct connection with that MTA. Email submission first goes through the sender's MTA, then some relaying between at least two MTAs is required to deliver the email. That will prove very important when it comes to security management.
One important thing to note is that MTA and MDA programs may actually handle multiple tasks (which is the case with DMS's Postfix and Dovecot).
For instance, Postfix is both an SMTP server (accepting emails) and a relaying MTA (transferring, ie. sending emails to other MTA/MDA); Dovecot is both an MDA (delivering emails in mailboxes) and an IMAP server (allowing MUAs to fetch emails from the mail server). On top of that, Postfix may rely on Dovecot's authentication capabilities.
The exact relationship between all the components and their respective (sometimes shared) responsibilities is beyond the scope of this document. Please explore this wiki & the web to get more insights about DMS's toolchain.
"},{"location":"introduction/#about-security-ports","title":"About Security & Ports","text":""},{"location":"introduction/#introduction","title":"Introduction","text":"In the previous section, three components were outlined. Each one of those is responsible for a specific task when it comes to exchanging emails:
Postfix handles Submission (and may handle Relay), whereas Dovecot handles Retrieval. They both need to be accessible by MUAs in order to act as servers, therefore they expose public endpoints on specific TCP ports. Those endpoints may be secured, using an encryption scheme and TLS certificates.
When it comes to the specifics of email exchange, we have to look at protocols and ports enabled to support all the identified purposes. There are several valid options and they've been evolving overtime.
"},{"location":"introduction/#overview","title":"Overview","text":"The following picture gives a visualization of the interplay of all components and their respective ports:
\u250f\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501 Submission \u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2513\u250f\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501 Transfer/Relay \u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2513\n\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2510\nMUA ----- STARTTLS ------> \u2524(587) MTA \u256e (25)\u251c <-- cleartext ---> \u250a Third-party MTA \u250a\n ----- implicit TLS --> \u2524(465) \u2502 | \u2514\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2518\n ----- cleartext -----> \u2524(25) \u2502 |\n |\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504|\nMUA <---- STARTTLS ------- \u2524(143) MDA \u256f |\n <---- implicit TLS --- \u2524(993) |\n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\n \u2517\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501 Retrieval \u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u251b\nIf you're new to email infrastructure, both that table and the schema may be confusing. Read on to expand your understanding and learn about DMS's configuration, including how you can customize it.
"},{"location":"introduction/#submission-smtp","title":"Submission - SMTP","text":"For a MUA to send an email to an MTA, it needs to establish a connection with that server, then push data packets over a network that both the MUA (client) and the MTA (server) are connected to. The server implements the SMTP protocol, which makes it capable of handling Submission.
In the case of DMS, the MTA (SMTP server) is Postfix. The MUA (client) may vary, yet its Submission request is performed as TCP packets sent over the public internet. This exchange of information may be secured in order to counter eavesdropping.
Now let's say I own an account on a DMS instance, me@dms.io. There are two very different use-cases for Submission:
In the first scenario, I will be submitting my email directly to my DMS instance/MTA (Postfix), which will then relay the email to its recipient's MTA for final delivery. In this case, Submission is first handled by establishing a direct connection to my own MTA-so at least for this portion of the delivery chain, I'll be able to ensure security/confidentiality. Not so much for what comes next, ie. relaying between MTAs and final delivery.
In the second scenario, a third-party email account owner will be first submitting an email to some third-party MTA. I have no control over this initial portion of the delivery chain, nor do I have control over the relaying that comes next. My MTA will merely accept a relayed email coming \"out of the blue\".
My MTA will thus have to support two kinds of Submission:
\u250f\u2501\u2501\u2501\u2501 Outbound Submission \u2501\u2501\u2501\u2501\u2513\n\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2510\nMe ---------------> \u2524 \u251c -----------------> \u250a \u250a\n \u2502 My MTA \u2502 \u250a Third-party MTA \u250a\n \u2502 \u251c <----------------- \u250a \u250a\n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2514\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2518\n\n \u2517\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501 Inbound Submission \u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u251b\nWhen it comes to securing Outbound Submission you should prefer to use Implicit TLS connection via ESMTP on port 465 (see RFC 8314). Please read our article about Understanding the Ports for more details!
Warning
This Submission setup is sometimes referred to as SMTPS. Long story short: this is incorrect and should be avoided.
Although a very satisfactory setup, Implicit TLS on port 465 is somewhat \"cutting edge\". There exists another well established mail Submission setup that must be supported as well, SMTP+STARTTLS on port 587. It uses Explicit TLS: the client starts with a cleartext connection, then the server informs a TLS-encrypted \"upgraded\" connection may be established, and the client may eventually decide to establish it prior to the Submission. Basically it's an opportunistic, opt-in TLS upgrade of the connection between the client and the server, at the client's discretion, using a mechanism known as STARTTLS that both ends need to implement.
In many implementations, the mail server doesn't enforce TLS encryption, for backwards compatibility. Clients are thus free to deny the TLS-upgrade proposal (or misled by a hacker about STARTTLS not being available), and the server accepts unencrypted (cleartext) mail exchange, which poses a confidentiality threat and, to some extent, spam issues. RFC 8314 (section 3.3) recommends for a mail server to support both Implicit and Explicit TLS for Submission, and to enforce TLS-encryption on ports 587 (Explicit TLS) and 465 (Implicit TLS). That's exactly DMS's default configuration: abiding by RFC 8314, it enforces a strict (encrypt) STARTTLS policy, where a denied TLS upgrade terminates the connection thus (hopefully but at the client's discretion) preventing unencrypted (cleartext) Submission.
A final Outbound Submission setup exists and is akin SMTP+STARTTLS on port 587, but on port 25. That port has historically been reserved specifically for unencrypted (cleartext) mail exchange though, making STARTTLS a bit wrong to use. As is expected by RFC 5321, DMS uses port 25 for unencrypted Submission in order to support older clients, but most importantly for unencrypted Transfer/Relay between MTAs.
Granted it's still very difficult enforcing encryption between MTAs (Transfer/Relay) without risking dropping emails (when relayed by MTAs not supporting TLS-encryption), Inbound Submission is to be handled in cleartext on port 25 by default.
Overall, DMS's default configuration for SMTP looks like this:
\u250f\u2501\u2501\u2501\u2501 Outbound Submission \u2501\u2501\u2501\u2501\u2513\n\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2510\nMe -- cleartext --> \u2524(25) (25)\u251c --- cleartext ---> \u250a \u250a\nMe -- TLS ---> \u2524(465) My MTA \u2502 \u250a Third-party MTA \u250a\nMe -- STARTTLS ---> \u2524(587) \u2502 \u250a \u250a\n \u2502 (25)\u251c <---cleartext ---- \u250a \u250a\n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2514\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2518\n\n \u2517\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501 Inbound Submission \u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u251b\nA MUA willing to fetch an email from a mail server will most likely communicate with its IMAP server. As with SMTP described earlier, communication will take place in the form of data packets exchanged over a network that both the client and the server are connected to. The IMAP protocol makes the server capable of handling Retrieval.
In the case of DMS, the IMAP server is Dovecot. The MUA (client) may vary, yet its Retrieval request is performed as TCP packets sent over the public internet. This exchange of information may be secured in order to counter eavesdropping.
Again, as with SMTP described earlier, the IMAP protocol may be secured with either Implicit TLS (aka. IMAPS / IMAP4S) or Explicit TLS (using STARTTLS).
The best practice as of 2020 is to enforce IMAPS on port 993, rather than IMAP+STARTTLS on port 143 (see RFC 8314); yet the latter is usually provided for backwards compatibility.
DMS's default configuration enables both Implicit and Explicit TLS for Retrievial, on ports 993 and 143 respectively.
"},{"location":"introduction/#retrieval-pop3","title":"Retrieval - POP3","text":"Similarly to IMAP, the older POP3 protocol may be secured with either Implicit or Explicit TLS.
The best practice as of 2020 would be POP3S on port 995, rather than POP3+STARTTLS on port 110 (see RFC 8314).
DMS's default configuration disables POP3 altogether. One should expect MUAs to use TLS-encrypted IMAP for Retrieval.
"},{"location":"introduction/#how-does-dms-help-with-setting-everything-up","title":"How Does DMS Help With Setting Everything Up?","text":"As a batteries included container image, DMS provides you with all the required components and a default configuration to run a decent and secure mail server. One may then customize all aspects of its internal components.
Eventually, it is up to you deciding exactly what kind of transportation/encryption to use and/or enforce, and to customize your instance accordingly (with looser or stricter security). Be also aware that protocols and ports on your server can only go so far with security; third-party MTAs might relay your emails on insecure connections, man-in-the-middle attacks might still prove effective, etc. Advanced counter-measure such as DANE, MTA-STS and/or full body encryption (eg. PGP) should be considered as well for increased confidentiality, but ideally without compromising backwards compatibility so as to not block emails.
"},{"location":"usage/","title":"Usage","text":"This pages explains how to get started with DMS. The guide uses Docker Compose as a reference. In our examples, a volume mounts the host location docker-data/dms/config/ to /tmp/docker-mailserver/ inside the container.
Before you can get started with deploying your own mail server, there are some requirements to be met:
There are a few requirements for a suitable host system:
PTR record for your host; security-hardened mail servers might otherwise reject your mail server as the IP address of your host does not resolve correctly/at all to the DNS name of your server.About the Container Runtime
On the host, you need to have a suitable container runtime (like Docker or Podman) installed. We assume Docker Compose is installed. We have aligned file names and configuration conventions with the latest Docker Compose (currently V2) specification.
If you're using podman, make sure to read the related documentation.
"},{"location":"usage/#minimal-dns-setup","title":"Minimal DNS Setup","text":"The DNS setup is a big and essential part of the whole setup. There is a lot of confusion for newcomers and people starting out when setting up DNS. This section provides an example configuration and supplementary explanation. We expect you to be at least a bit familiar with DNS, what it does and what the individual record types are.
Now let's say you just bought example.com and you want to be able to send and receive e-mails for the address test@example.com. On the most basic level, you will need to
MX record for your domain example.com - in our example, the MX record contains mail.example.comA record that resolves the name of your mail server - in our example, the A record contains 11.22.33.44PTR record that resolves the IP of your mail server - in our example, the PTR contains mail.example.comWe will later dig into DKIM, DMARC & SPF, but for now, these are the records that suffice in getting you up and running. Here is a short explanation of what the records do:
mail.example.com. This does not imply your e-mails will look like test@mail.example.com, the DNS name of your mail server is decoupled of the domain it serves e-mails for. In theory, you mail server could even serve e-mails for test@some-other-domain.com, if the MX record for some-other-domain.com points to mail.example.com.mail.example.com resolves to.11.22.33.44 resolves to.If you setup everything, it should roughly look like this:
$ dig @1.1.1.1 +short MX example.com\nmail.example.com\n$ dig @1.1.1.1 +short A mail.example.com\n11.22.33.44\n$ dig @1.1.1.1 +short -x 11.22.33.44\nmail.example.com\nTo understand which tags you should use, read this section carefully. Our CI will automatically build, test and push new images to the following container registries:
docker.io/mailserver/docker-mailserver)ghcr.io/docker-mailserver/docker-mailserver)All workflows are using the tagging convention listed below. It is subsequently applied to all images.
Event Image Tagspush on master edge push a tag (v1.2.3) 1.2.3, 1.2, 1, latest"},{"location":"usage/#get-all-files","title":"Get All Files","text":"Issue the following commands to acquire the necessary files:
DMS_GITHUB_URL=\"https://github.com/docker-mailserver/docker-mailserver/blob/latest\"\nwget \"${DMS_GITHUB_URL}/compose.yaml\"\nwget \"${DMS_GITHUB_URL}/mailserver.env\"\ncompose.yaml to your likingmail.example.com according to your FQDN../docker-data/dms/config/:/tmp/docker-mailserver/ mount, append -z or -Z.mailserver.env, but keep in mind that:VAR=VAL is supportedOVERRIDE_HOSTNAME=$HOSTNAME.$DOMAINNAME does not workUsing the Correct Commands For Stopping and Starting DMS
Use docker compose up / down, not docker compose start / stop. Otherwise, the container is not properly destroyed and you may experience problems during startup because of inconsistent state.
Using Ctrl+C is not supported either!
For an overview of commands to manage DMS config, run: docker exec -it <CONTAINER NAME> setup help.
setup.sh when no DMS Container Is Running We encourage you to directly use setup inside the container (like shown above). If you still want to use setup.sh, here's some information about it.
If no DMS container is running, any ./setup.sh command will check online for the :latest image tag (the current stable release), performing a docker pull ... if necessary followed by running the command in a temporary container:
$ ./setup.sh help\nImage 'ghcr.io/docker-mailserver/docker-mailserver:latest' not found. Pulling ...\nSETUP(1)\n\nNAME\n setup - 'docker-mailserver' Administration & Configuration script\n...\n\n$ docker run --rm ghcr.io/docker-mailserver/docker-mailserver:latest setup help\nSETUP(1)\n\nNAME\n setup - 'docker-mailserver' Administration & Configuration script\n...\nOn first start, you will need to add at least one email account (unless you're using LDAP). You have two minutes to do so, otherwise DMS will shutdown and restart. You can add accounts by running docker exec -ti <CONTAINER NAME> setup email add user@example.com. That's it! It really is that easy.
You definitely want to setup TLS. Please refer to our documentation about TLS.
"},{"location":"usage/#aliases","title":"Aliases","text":"You should add at least one alias, the postmaster alias. This is a common convention, but not strictly required.
docker exec -ti <CONTAINER NAME> setup alias add postmaster@example.com user@example.com\nYou will very likely want to configure your DNS with these TXT records: SPF, DKIM, and DMARC. We also ship a dedicated page in our documentation about the setup of DKIM, DMARC & SPF.
"},{"location":"usage/#custom-user-changes-patches","title":"Custom User Changes & Patches","text":"If you'd like to change, patch or alter files or behavior of DMS, you can use a script. See this part of our documentation for a detailed explanation.
"},{"location":"usage/#testing","title":"Testing","text":"Here are some tools you can use to verify your configuration:
This page contains valuable information when it comes to resolving issues you encounter.
Contributions Welcome!
Please consider contributing solutions to the FAQ
"},{"location":"config/debugging/#preliminary-information","title":"Preliminary Information","text":""},{"location":"config/debugging/#mail-sent-from-dms-does-not-arrive-at-destination","title":"Mail sent from DMS does not arrive at destination","text":"Some service providers block outbound traffic on port 25. Common hosting providers known to have this issue:
These links may advise how the provider can unblock the port through additional services offered, or via a support ticket request.
"},{"location":"config/debugging/#steps-for-debugging-dms","title":"Steps for Debugging DMS","text":"LOG_LEVEL to debug or trace.docker log <CONTAINER NAME> (or docker logs -f <CONTAINER NAME> if you want to follow the log).To get a shell inside the container run: docker exec -it <CONTAINER NAME> bash.
If you need more flexibility than docker logs offers, within the container /var/log/mail/mail.log and /var/log/supervisor/ are the most useful locations to get relevant DMS logs. Use the tail or cat commands to view their contents.
To install additional software:
apt-get update is needed to update repository metadata.apt-get install <PACKAGE>nano is a good package choice for beginners.Info
Values in bold are the default values. If an option doesn't work as documented here, check if you are running the latest image. The current master branch corresponds to the image ghcr.io/docker-mailserver/docker-mailserver:edge.
If you can't set your hostname (eg: you're in a container platform that doesn't let you) specify it via this environment variable. It will have priority over docker run --hostname, or the equivalent hostname: field in compose.yaml.
hostname -f command to get canonical hostname for DMS to use.Set the log level for DMS. This is mostly relevant for container startup scripts and change detection event feedback.
Valid values (in order of increasing verbosity) are: error, warn, info, debug and trace. The default log level is info.
Here you can adjust the log-level for Supervisor. Possible values are
The log-level will show everything in its class and above.
"},{"location":"config/environment/#one_dir","title":"ONE_DIR","text":"/var/mail-state) to allow persistence using docker volumes. See the related FAQ entry for more information.Configures the provisioning source of user accounts (including aliases) for user queries and authentication by services managed by DMS (Postfix and Dovecot).
User provisioning via OIDC is planned for the future, see this tracking issue.
A second container for the ldap service is necessary (e.g. docker-openldap)
"},{"location":"config/environment/#permit_docker","title":"PERMIT_DOCKER","text":"Set different options for mynetworks option (can be overwrite in postfix-main.cf) WARNING: Adding the docker network's gateway to the list of trusted hosts, e.g. using the network or connected-networks option, can create an open relay, for instance if IPv6 is enabled on the host machine but not in Docker.
docker-compose might use others (e.g. 192.168.0.0/16) use PERMIT_DOCKER=connected-networks in this case.Note: you probably want to set POSTFIX_INET_PROTOCOLS=ipv4 to make it work fine with Docker.
Set the timezone. If this variable is unset, the container runtime will try to detect the time using /etc/localtime, which you can alternatively mount into the container. The value of this variable must follow the pattern AREA/ZONE, i.e. of you want to use Germany's time zone, use Europe/Berlin. You can lookup all available timezones here.
Amavis content filter (used for ClamAV & SpamAssassin)
This page provides information on Amavis' logging statistics.
This enables DNS block lists in Postscreen. If you want to know which lists we are using, have a look at the default main.cf for Postfix we provide and search for postscreen_dnsbl_sites.
A Warning On DNS Block Lists
Make sure your DNS queries are properly resolved, i.e. you will most likely not want to use a public DNS resolver as these queries do not return meaningful results. We try our best to only evaluate proper return codes - this is not a guarantee that all codes are handled fine though.
Note that emails will be rejected if they don't pass the block list checks!
Enables the OpenDKIM service.
Enables the OpenDMARC service.
Enabled policyd-spf in Postfix's configuration. You will likely want to set this to 0 in case you're using Rspamd (ENABLE_RSPAMD=1).
If you enable Fail2Ban, don't forget to add the following lines to your compose.yaml:
cap_add:\n - NET_ADMIN\nOtherwise, nftables won't be able to ban IPs.
In the majority of cases, you want letsencrypt or manual.
self-signed can be used for testing SSL until you provide a valid certificate, note that third-parties cannot trust self-signed certificates, do not use this type in production. custom is a temporary workaround that is not officially supported.
SSL_CERT_PATH and SSL_KEY_PATH ENV vars to be set to the location of the files within the container.SSL_ALT_CERT_PATH and SSL_ALT_KEY_PATH allow providing a 2nd certificate as a fallback for dual (aka hybrid) certificate support. Useful for ECDSA with an RSA fallback. Presently only manual mode supports this feature.None)Please read the SSL page in the documentation for more information.
"},{"location":"config/environment/#tls_level","title":"TLS_LEVEL","text":"Configures the handling of creating mails with forged sender addresses.
Enables the Sender Rewriting Scheme. SRS is needed if DMS acts as forwarder. See postsrsd for further explanation.
In case your network interface differs from eth0, e.g. when you are using HostNetworking in Kubernetes, you can set this to whatever interface you want. This interface will then be used.
eth0Set how many days a virusmail will stay on the server before being deleted
Configure Postfix virtual_transport to deliver mail to a different LMTP client (default is a unix socket to dovecot).
Provide any valid URI. Examples:
lmtp:unix:/var/run/dovecot/lmtp (default, configured in Postfix main.cf)lmtp:unix:private/dovecot-lmtp (use socket)lmtps:inet:<host>:<port> (secure lmtp with starttls)lmtp:<kopano-host>:2003 (use kopano as mailstore)Set the mailbox size limit for all users. If set to zero, the size will be unlimited (default).
See mailbox quota.
"},{"location":"config/environment/#postfix_message_size_limit","title":"POSTFIX_MESSAGE_SIZE_LIMIT","text":"Set the message size limit for all users. If set to zero, the size will be unlimited (not recommended!)
Mails larger than this limit won't be scanned. ClamAV must be enabled (ENABLE_CLAMAV=1) for this.
Check for updates on container start and then once a day. If an update is available, a mail is send to POSTMASTER_ADDRESS.
Customize the update check interval. Number + Suffix. Suffix must be 's' for seconds, 'm' for minutes, 'h' for hours or 'd' for days.
This option has been added in November 2019. Using other format than Maildir is considered as experimental in docker-mailserver and should only be used for testing purpose. For more details, please refer to Dovecot Documentation.
"},{"location":"config/environment/#postfix_reject_unknown_client_hostname","title":"POSTFIX_REJECT_UNKNOWN_CLIENT_HOSTNAME","text":"If enabled, employs reject_unknown_client_hostname to sender restrictions in Postfix's configuration.
Note: More details at http://www.postfix.org/postconf.5.html#inet_protocols
"},{"location":"config/environment/#dovecot_inet_protocols","title":"DOVECOT_INET_PROTOCOLS","text":"Note: More information at https://dovecot.org/doc/dovecot-example.conf
"},{"location":"config/environment/#move_spam_to_junk","title":"MOVE_SPAM_TO_JUNK","text":"When enabled, e-mails marked with the
X-Spam: Yes header added by RspamdX-Spam-Flag: YES header added by SpamAssassin (requires SPAMASSASSIN_SPAM_TO_INBOX=1)will be automatically moved to the Junk folder (with the help of a Sieve script).
Junk folder.Enable or disable Rspamd.
Explicit control over running a Redis instance within the container. By default, this value will match what is set for ENABLE_RSPAMD.
The purpose of this setting is to opt-out of starting an internal Redis instance when enabling Rspamd, replacing it with your own external instance.
Configuring Rspamd for an external Redis instanceYou will need to provide configuration at /etc/rspamd/local.d/redis.conf similar to:
servers = \"redis.example.test:6379\";\nexpand_keys = true;\nControls whether the Rspamd Greylisting module is enabled. This module can further assist in avoiding spam emails by greylisting e-mails with a certain spam score.
When enabled,
Attention
As of now, the spam learning database is global (i.e. available to all users). If one user deliberately trains it with malicious data, then it will ruin your detection rate.
This feature is suitably only for users who can tell ham from spam and users that can be trusted.
Can be used to enable or disable the Hfilter group module. This is used by DMS to adjust the HFILTER_HOSTNAME_UNKNOWN symbol, increasing it's default weight to act similar to Postfix's reject_unknown_client_hostname, without the need to outright reject a message.
Can be used to control the score when the HFILTER_HOSTNAME_UNKNOWN symbol applies. A higher score is more punishing. Setting it to 15 (the default score for rejecting an e-mail) is equivalent to rejecting the email when the check fails.
Default: 6 (which corresponds to the add_header action)
Enables regular Postfix log summary (\"pflogsumm\") mail reports.
This is a new option. The old REPORT options are still supported for backwards compatibility. If this is not set and reports are enabled with the old options, logrotate will be used.
"},{"location":"config/environment/#pflogsumm_recipient","title":"PFLOGSUMM_RECIPIENT","text":"Recipient address for Postfix log summary reports.
Sender address (FROM) for pflogsumm reports (if Postfix log summary reports are enabled).
Interval for logwatch report.
Recipient address for logwatch reports if they are enabled.
Sender address (FROM) for logwatch reports if logwatch reports are enabled.
Defines who receives reports (if they are enabled).
Defines who sends reports (if they are enabled).
mailserver-report@<YOUR DOMAIN>Changes the interval in which log files are rotated.
Note
LOGROTATE_INTERVAL only manages logrotate within the container for services we manage internally.
The entire log output for the container is still available via docker logs mailserver (or your respective container name). If you want to configure external log rotation for that container output as well, : Docker Logging Drivers.
By default, the logs are lost when the container is destroyed (eg: re-creating via docker compose down && docker compose up -d). To keep the logs, mount a volume (to /var/log/mail/).
Note
This variable can also determine the interval for Postfix's log summary reports, see PFLOGSUMM_TRIGGER.
SA_SPAM_SUBJECT.KAM is a 3rd party SpamAssassin ruleset, provided by the McGrail Foundation. If SpamAssassin is enabled, KAM can be used in addition to the default ruleset.
Note: this SpamAssassin setting needs ENABLE_SPAMASSASSIN=1
Note: this SpamAssassin setting needs ENABLE_SPAMASSASSIN=1
This SpamAssassin setting needs ENABLE_SPAMASSASSIN=1
By default, DMS is configured to quarantine spam emails.
If emails are quarantined, they are compressed and stored in a location dependent on the ONE_DIR setting above. To inhibit this behaviour and deliver spam emails, set this to a very high value e.g. 100.0.
If ONE_DIR=1 (default) the location is /var/mail-state/lib-amavis/virusmails/, or if ONE_DIR=0: /var/lib/amavis/virusmails/. These paths are inside the docker container.
Note: this SpamAssassin setting needs ENABLE_SPAMASSASSIN=1. Add the SpamAssassin score to the subject line by inserting the keyword _SCORE_: ***SPAM(_SCORE_)***.
This will uncomment the respective line in /etc/spamassasin/local.cf
Note: activate this only if you are confident in your bayes database for identifying spam.
"},{"location":"config/environment/#sa_shortcircuit_bayes_ham","title":"SA_SHORTCIRCUIT_BAYES_HAM","text":"This will uncomment the respective line in /etc/spamassasin/local.cf
Note: activate this only if you are confident in your bayes database for identifying ham.
"},{"location":"config/environment/#fetchmail","title":"Fetchmail","text":""},{"location":"config/environment/#enable_fetchmail","title":"ENABLE_FETCHMAIL","text":"fetchmail disabledfetchmail enabledfetchmail The number of seconds for the interval0 => fetchmail runs with a single config file /etc/fetchmailrc 1 => /etc/fetchmailrc is split per poll entry. For every poll entry a separate fetchmail instance is started to allow having multiple imap idle configurations defined.
Note: The defaults of your fetchmailrc file need to be at the top of the file. Otherwise it won't be added correctly to all separate fetchmail instances.
Deprecated. See ACCOUNT_PROVISIONER.
ldaps://mail.example.comcompose.yaml you can set the service name here(&(mail=%s)(mailEnabled=TRUE))(&(mailGroupMember=%s)(mailEnabled=TRUE))(&(mailAlias=%s)(mailEnabled=TRUE))(&(|(mail=*@%s)(mailalias=*@%s)(mailGroupMember=*@%s))(mailEnabled=TRUE))(|($LDAP_QUERY_FILTER_USER)($LDAP_QUERY_FILTER_ALIAS)($LDAP_QUERY_FILTER_GROUP))The following variables overwrite the default values for /etc/dovecot/dovecot-ldap.conf.ext.
LDAP_SEARCH_BASEou=people,dc=domain,dc=com)SSHALDAP_BIND_DNcn=admin,dc=domain,dc=com)LDAP_BIND_PWDOVECOT_DN.LDAP_SERVER_HOSTldap:// will be used.DOVECOT_HOSTS (as it didn't allow to use LDAPS), which is currently still supported for backwards compatibility.(&(objectClass=PostfixBookMailAccount)(uniqueIdentifier=%n))homeDirectory=home,qmailUID=uid,qmailGID=gid,mailMessageStore=mail(&(objectClass=PostfixBookMailAccount)(uniqueIdentifier=%n))DOVECOT_USER_FILTERuid=user,userPassword=passwordpostgrey is disabledpostgrey is enabledNote: This postgrey setting needs ENABLE_POSTGREY=1
Note: This postgrey setting needs ENABLE_POSTGREY=1
Note: This postgrey setting needs ENABLE_POSTGREY=1
Note: This postgrey setting needs ENABLE_POSTGREY=1
saslauthd is disabledsaslauthd is enabledldap => authenticate against ldap servershadow => authenticate against local user dbmysql => authenticate against mysql dbrimap => authenticate against imap serverLDAP_SERVER_HOSTnoyes => Enable ldap_start_tls optionnoyes => Enable ldap_tls_check_peer optionPath to directory with CA (Certificate Authority) certificates.
ldap_tls_cacert_dir optionFile containing CA (Certificate Authority) certificate(s).
ldap_tls_cacert_file optionLDAP_BIND_DNLDAP_BIND_PWLDAP_SEARCH_BASE(&(uniqueIdentifier=%u)(mailEnabled=TRUE))(&(sAMAccountName=%U)(objectClass=person))(&(uid=%U)(objectClass=person))Specify what password attribute to use for password verification.
userPassword by default.ldap_password_attr optionbind will be used as a default valuefastbind => The fastbind method is usedcustom => The custom method uses userPassword attribute to verify the passwordSpecify the authentication mechanism for SASL bind.
ldap_mech optionAn email has an \"envelope\" sender (indicating the sending server) and a \"header\" sender (indicating who sent it). More strict SPF policies may require you to replace both instead of just the envelope sender.
More info.
dd if=/dev/urandom bs=24 count=1 2>/dev/null | base64OVERRIDE_HOSTNAME, $DOMAINNAME (internal), or the container's hostname[example.com]:587 (don't forget the brackets if you need this to be compatible with $RELAY_USER and $RELAY_PASSWORD, explained below).If you want to use POP3(S), you have to add the ports 110 and/or 995 (TLS secured) and the environment variable ENABLE_POP3 to your compose.yaml:
mailserver:\nports:\n- \"25:25\" # SMTP (explicit TLS => STARTTLS)\n- \"143:143\" # IMAP4 (explicit TLS => STARTTLS)\n- \"465:465\" # ESMTP (implicit TLS)\n- \"587:587\" # ESMTP (explicit TLS => STARTTLS)\n- \"993:993\" # IMAP4 (implicit TLS)\n- \"110:110\" # POP3\n- \"995:995\" # POP3 (with TLS)\nenvironment:\n- ENABLE_POP3=1\nNote
setup.sh is not required. We encourage you to use docker exec -ti <CONTAINER NAME> setup instead.
Warning
This script assumes Docker or Podman is used. You will not be able to use setup.sh with other container orchestration tools.
setup.sh is a script that is complimentary to the internal setup command in DMS.
It mostly provides the convenience of aliasing docker exec -ti <CONTAINER NAME> setup, inferring the container name of a running DMS instance or running a new instance and bind mounting necessary volumes implicitly.
It is intended to be run from the host machine, not from inside your running container. The latest version of the script is included in the DMS repository. You may retrieve it at any time by running this command in your console:
wget https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master/setup.sh\nchmod a+x ./setup.sh\nFor more information on using the script run: ./setup.sh help.
Users (email accounts) are managed in /tmp/docker-mailserver/postfix-accounts.cf. The best way to manage accounts is to use the reliable setup command inside the container. Just run docker exec <CONTAINER NAME> setup help and have a look at the section about subcommands, specifically the email subcommand.
setup inside the container","text":"You can add an account by running docker exec -ti <CONTAINER NAME> setup email add <NEW ADDRESS>. This method is strongly preferred.
Warning
This method is discouraged!
Alternatively, you may directly add the full email address and its encrypted password, separated by a pipe. To generate a new mail account data, directly from your host, you could for example run the following:
docker run --rm -it \\\n--env MAIL_USER=user1@example.com \\\n--env MAIL_PASS=mypassword \\\nghcr.io/docker-mailserver/docker-mailserver:latest \\\n/bin/bash -c \\\n'echo \"${MAIL_USER}|$(doveadm pw -s SHA512-CRYPT -u ${MAIL_USER} -p ${MAIL_PASS})\" >>docker-data/dms/config/postfix-accounts.cf'\nYou will then be asked for a password, and be given back the data for a new account entry, as text. To actually add this new account, just copy all the output text in docker-data/dms/config/postfix-accounts.cf file of your running container.
The result could look like this:
user1@example.com|{SHA512-CRYPT}$6$2YpW1nYtPBs2yLYS$z.5PGH1OEzsHHNhl3gJrc3D.YMZkvKw/vp.r5WIiwya6z7P/CQ9GDEJDr2G2V0cAfjDFeAQPUoopsuWPXLk3u1\nimap-quota is enabled and allow clients to query their mailbox usage.The best way to manage aliases is to use the reliable setup script inside the container. Just run docker exec <CONTAINER NAME> setup help and have a look at the section about subcommands, specifically the alias-subcommand.
You may read Postfix's documentation on virtual aliases first. Aliases are managed in /tmp/docker-mailserver/postfix-virtual.cf. An alias is a full email address that will either be:
/tmp/docker-mailserver/postfix-accounts.cfAlias and target are space separated. An example on a server with example.com as its domain:
# Alias delivered to an existing account\nalias1@example.com user1@example.com\n\n# Alias forwarded to an external email address\nalias2@example.com external-account@gmail.com\nAdditional regexp aliases can be configured by placing them into docker-data/dms/config/postfix-regexp.cf. The regexp aliases get evaluated after the virtual aliases (container path: /tmp/docker-mailserver/postfix-virtual.cf). For example, the following docker-data/dms/config/postfix-regexp.cf causes all email sent to \"test\" users to be delivered to qa@example.com instead:
/^test[0-9][0-9]*@example.com/ qa@example.com\nPostfix supports so-called address tags, in the form of plus (+) tags - i.e. address+tag@example.com will end up at address@example.com. This is configured by default and the (configurable!) separator is set to +. For more info, see Postfix's official documentation.
Note
If you do decide to change the configurable separator, you must add the same line to both docker-data/dms/config/postfix-main.cf and docker-data/dms/config/dovecot.cf, because Dovecot is acting as the delivery agent. For example, to switch to -, add:
recipient_delimiter = -\nGetting started with ldap and DMS we need to take 3 parts in account:
postfix for incoming & outgoing emaildovecot for accessing mailboxessaslauthd for SMTP authentication (this can also be delegated to dovecot)Have a look at the ENV page for information on the default values.
"},{"location":"config/advanced/auth-ldap/#ldap_query_filter_","title":"LDAP_QUERY_FILTER_*","text":"Those variables contain the LDAP lookup filters for postfix, using %s as the placeholder for the domain or email address in question. This means that...
DOMAIN filter (see virtual_alias_domains).USER, ALIAS and GROUP filters.USER filter specifies personal mailboxes, for which only one should exist per address, for example (mail=%s) (also see virtual_mailbox_maps)ALIAS filter specifies aliases for mailboxes, using virtual_alias_maps, for example (mailAlias=%s)GROUP filter specifies the personal mailboxes in a group (for emails that multiple people shall receive), using virtual_alias_maps, for example (mailGroupMember=%s).ALIAS and GROUP, but ideally you should use ALIAS for personal aliases for a singular person (like ceo@example.org) and GROUP for multiple people (like hr@example.org).SENDERS filter, and only if the authenticated user is one of the returned entries, the email can be sent.SPOOF_PROTECTION=1.SENDERS filter is missing, the USER, ALIAS and GROUP filters will be used in in a disjunction (OR).admin group to spoof any sender email address, and to force everyone else to only use their personal mailbox address for outgoing email, you can use something like this: (|(memberOf=cn=admin,*)(mail=%s))A really simple LDAP_QUERY_FILTER configuration, using only the user filter and allowing only admin@* to spoof any sender addresses.
- ENABLE_LDAP=1 # with the :edge tag, use ACCOUNT_PROVISIONER\n- LDAP_START_TLS=yes\n- ACCOUNT_PROVISIONER=LDAP\n- LDAP_SERVER_HOST=ldap.example.org\n- LDAP_SEARCH_BASE=dc=example,dc=org\"\n- LDAP_BIND_DN=cn=admin,dc=example,dc=org\n- LDAP_BIND_PW=mypassword\n- SPOOF_PROTECTION=1\n\n- LDAP_QUERY_FILTER_DOMAIN=(mail=*@%s)\n- LDAP_QUERY_FILTER_USER=(mail=%s)\n- LDAP_QUERY_FILTER_ALIAS=(|) # doesn't match anything\n- LDAP_QUERY_FILTER_GROUP=(|) # doesn't match anything\n- LDAP_QUERY_FILTER_SENDERS=(|(mail=%s)(mail=admin@*))\nDOVECOT_*_FILTER & DOVECOT_*_ATTRS","text":"These variables specify the LDAP filters that dovecot uses to determine if a user can log in to their IMAP account, and which mailbox is responsible to receive email for a specific postfix user.
This is split into the following two lookups, both using %u as the placeholder for the full login name (see dovecot documentation for a full list of placeholders). Usually you only need to set DOVECOT_USER_FILTER, in which case it will be used for both filters.
DOVECOT_USER_FILTER is used to get the account details (uid, gid, home directory, quota, ...) of a user.DOVECOT_PASS_FILTER is used to get the password information of the user, and is in pretty much all cases identical to DOVECOT_USER_FILTER (which is the default behaviour if left away).If your directory doesn't have the postfix-book schema installed, then you must change the internal attribute handling for dovecot. For this you have to change the pass_attr and the user_attr mapping, as shown in the example below:
- DOVECOT_PASS_ATTRS=<YOUR_USER_IDENTIFIER_ATTRIBUTE>=user,<YOUR_USER_PASSWORD_ATTRIBUTE>=password\n- DOVECOT_USER_ATTRS=<YOUR_USER_HOME_DIRECTORY_ATTRIBUTE>=home,<YOUR_USER_MAILSTORE_ATTRIBUTE>=mail,<YOUR_USER_MAIL_UID_ATTRIBUTE>=uid,<YOUR_USER_MAIL_GID_ATTRIBUTE>=gid\nNote
For DOVECOT_*_ATTRS, you can replace ldapAttr=dovecotAttr with =dovecotAttr=%{ldap:ldapAttr} for more flexibility, like for example =home=/var/mail/%{ldap:uid} or just =uid=5000.
A list of dovecot attributes can be found in the dovecot documentation.
Defaults- DOVECOT_USER_ATTRS=mailHomeDirectory=home,mailUidNumber=uid,mailGidNumber=gid,mailStorageDirectory=mail\n- DOVECOT_PASS_ATTRS=uniqueIdentifier=user,userPassword=password\n- DOVECOT_USER_FILTER=(&(objectClass=PostfixBookMailAccount)(uniqueIdentifier=%n))\nSetup for a directory that has the qmail-schema installed and uses uid:
- DOVECOT_PASS_ATTRS=uid=user,userPassword=password\n- DOVECOT_USER_ATTRS=homeDirectory=home,qmailUID=uid,qmailGID=gid,mailMessageStore=mail\n- DOVECOT_USER_FILTER=(&(objectClass=qmailUser)(uid=%u)(accountStatus=active))\nThe LDAP server configuration for dovecot will be taken mostly from postfix, other options can be found in the environment section in the docs.
"},{"location":"config/advanced/auth-ldap/#dovecot_auth_bind","title":"DOVECOT_AUTH_BIND","text":"Set this to yes to enable authentication binds (more details in the dovecot documentation). Currently, only DN lookup is supported without further changes to the configuration files, so this is only useful when you want to bind as a readonly user without the permission to read passwords.
SASLAUTHD_LDAP_FILTER","text":"This filter is used for saslauthd, which is called by postfix when someone is authenticating through SMTP (assuming that SASLAUTHD_MECHANISMS=ldap is being used). Note that you'll need to set up the LDAP server for saslauthd separately from postfix.
The filter variables are explained in detail in the LDAP_SASLAUTHD file, but unfortunately, this method doesn't really support domains right now - that means that %U is the only token that makes sense in this variable.
When to use this and how to avoid it
Using a separate filter for SMTP authentication allows you to for example allow noreply@example.org to send email, but not log in to IMAP or receive email: (&(mail=%U@example.org)(|(memberOf=cn=email,*)(mail=noreply@example.org)))
If you don't want to use a separate filter for SMTP authentication, you can set SASLAUTHD_MECHANISMS=rimap and SASLAUTHD_MECH_OPTIONS=127.0.0.1 to authenticate against dovecot instead - this means that the DOVECOT_USER_FILTER and DOVECOT_PASS_FILTER will be used for SMTP authentication as well.
saslauthd - ENABLE_SASLAUTHD=1\n- SASLAUTHD_MECHANISMS=ldap\n- SASLAUTHD_LDAP_FILTER=(mail=%U@example.org)\nTo enable LDAPS, all you need to do is to add the protocol to LDAP_SERVER_HOST, for example ldaps://example.org:636.
To enable LDAP over StartTLS (on port 389), you need to set the following environment variables instead (the protocol must not be ldaps:// in this case!):
- LDAP_START_TLS=yes\n- DOVECOT_TLS=yes\n- SASLAUTHD_LDAP_START_TLS=yes\nIn addition to LDAP explanation above, when Docker Mailserver is intended to be used with Active Directory (or the equivalent implementations like Samba4 AD DC) the following points should be taken into consideration:
sAMAccountName.proxyAddresses can be used to store email aliases of single users. The convention is to prefix the email aliases with smtp: (e.g: smtp:some.name@example.com).uidNumber, gidNumber instead of the typical uid. Assigning different owner to email folders can also be done in this approach, nevertheless there is a bug at the moment in Docker Mailserver that overwrites all permissions when starting the container. Either a manual fix is necessary now, or a temporary workaround to use a hard-coded ldap:uidNumber that equals to 5000 until this issue is fixed.user-patches.sh script to modify ldap-groups.cf so that it includes leaf_result_attribute = mail and special_result_attribute = member. This can be achieved simply by:The configuration shown to get the Group to work is from here and here.
# user-patches.sh\n\n...\ngrep -q '^leaf_result_attribute = mail$' /etc/postfix/ldap-groups.cf || echo \"leaf_result_attribute = mail\" >> /etc/postfix/ldap-groups.cf\ngrep -q '^special_result_attribute = member$' /etc/postfix/ldap-groups.cf || echo \"special_result_attribute = member\" >> /etc/postfix/ldap-groups.cf\n...\n/etc/ldap/ldap.conf, if the TLS_REQCERT is demand / hard (default), the CA certificate used to verify the LDAP server certificate must be recognized as a trusted CA. This can be done by volume mounting the ca.crt file and updating the trust store via a user-patches.sh script:# user-patches.sh\n\n...\ncp /MOUNTED_FOLDER/ca.crt /usr/local/share/ca-certificates/\nupdate-ca-certificates\n...\nThe changes on the configurations necessary to work with Active Directory (only changes are listed, the rest of the LDAP configuration can be taken from the other examples shown in this documentation):
# If StartTLS is the chosen method to establish a secure connection with Active Directory.\n- LDAP_START_TLS=yes\n- SASLAUTHD_LDAP_START_TLS=yes\n- DOVECOT_TLS=yes\n\n- LDAP_QUERY_FILTER_USER=(&(objectclass=person)(mail=%s))\n- LDAP_QUERY_FILTER_ALIAS=(&(objectclass=person)(proxyAddresses=smtp:%s))\n# Filters Active Directory groups (mail lists). Additional changes on ldap-groups.cf are also required as shown above.\n- LDAP_QUERY_FILTER_GROUP=(&(objectClass=group)(mail=%s))\n- LDAP_QUERY_FILTER_DOMAIN=(mail=*@%s)\n# Allows only Domain admins to send any sender email address, otherwise the sender address must match the LDAP attribute `mail`.\n- SPOOF_PROTECTION=1\n- LDAP_QUERY_FILTER_SENDERS=(|(mail=%s)(proxyAddresses=smtp:%s)(memberOf=cn=Domain Admins,cn=Users,dc=*))\n\n- DOVECOT_USER_FILTER=(&(objectclass=person)(sAMAccountName=%n))\n# At the moment to be able to use %{ldap:uidNumber}, a manual bug fix as described above must be used. Otherwise %{ldap:uidNumber} %{ldap:uidNumber} must be replaced by the hard-coded value 5000.\n- DOVECOT_USER_ATTRS==uid=%{ldap:uidNumber},=gid=5000,=home=/var/mail/%Ln,=mail=maildir:~/Maildir\n- DOVECOT_PASS_ATTRS=sAMAccountName=user,userPassword=password\n- SASLAUTHD_LDAP_FILTER=(&(sAMAccountName=%U)(objectClass=person))\nservices:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\nhostname: mail.example.com\n\nports:\n- \"25:25\"\n- \"143:143\"\n- \"587:587\"\n- \"993:993\"\n\nvolumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/mail-state/:/var/mail-state/\n- ./docker-data/dms/mail-logs/:/var/log/mail/\n- ./docker-data/dms/config/:/tmp/docker-mailserver/\n- /etc/localtime:/etc/localtime:ro\n\nenvironment:\n- ENABLE_SPAMASSASSIN=1\n- ENABLE_CLAMAV=1\n- ENABLE_FAIL2BAN=1\n- ENABLE_POSTGREY=1\n\n# >>> Postfix LDAP Integration\n- ENABLE_LDAP=1 # with the :edge tag, use ACCOUNT_PROVISIONER\n- ACCOUNT_PROVISIONER=LDAP\n- LDAP_SERVER_HOST=ldap.example.org\n- LDAP_BIND_DN=cn=admin,ou=users,dc=example,dc=org\n- LDAP_BIND_PW=mypassword\n- LDAP_SEARCH_BASE=dc=example,dc=org\n- LDAP_QUERY_FILTER_DOMAIN=(|(mail=*@%s)(mailAlias=*@%s)(mailGroupMember=*@%s))\n- LDAP_QUERY_FILTER_USER=(&(objectClass=inetOrgPerson)(mail=%s))\n- LDAP_QUERY_FILTER_ALIAS=(&(objectClass=inetOrgPerson)(mailAlias=%s))\n- LDAP_QUERY_FILTER_GROUP=(&(objectClass=inetOrgPerson)(mailGroupMember=%s))\n- LDAP_QUERY_FILTER_SENDERS=(&(objectClass=inetOrgPerson)(|(mail=%s)(mailAlias=%s)(mailGroupMember=%s)))\n- SPOOF_PROTECTION=1\n# <<< Postfix LDAP Integration\n\n# >>> Dovecot LDAP Integration\n- DOVECOT_USER_FILTER=(&(objectClass=inetOrgPerson)(mail=%u))\n- DOVECOT_PASS_ATTRS=uid=user,userPassword=password\n- DOVECOT_USER_ATTRS==home=/var/mail/%{ldap:uid},=mail=maildir:~/Maildir,uidNumber=uid,gidNumber=gid\n# <<< Dovecot LDAP Integration\n\n# >>> SASL LDAP Authentication\n- ENABLE_SASLAUTHD=1\n- SASLAUTHD_MECHANISMS=ldap\n- SASLAUTHD_LDAP_FILTER=(&(mail=%U@example.org)(objectClass=inetOrgPerson))\n# <<< SASL LDAP Authentication\n\n- SSL_TYPE=letsencrypt\n- PERMIT_DOCKER=host\n\ncap_add:\n- NET_ADMIN\nservices:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\nhostname: mail.example.com\n\nports:\n- \"25:25\"\n- \"143:143\"\n- \"587:587\"\n- \"993:993\"\n\nvolumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/mail-state/:/var/mail-state/\n- ./docker-data/dms/config/:/tmp/docker-mailserver/\n\nenvironment:\n# We are not using dovecot here\n- SMTP_ONLY=1\n- ENABLE_SPAMASSASSIN=1\n- ENABLE_CLAMAV=1\n- ENABLE_FAIL2BAN=1\n- ENABLE_POSTGREY=1\n- SASLAUTHD_PASSWD=\n\n# >>> SASL Authentication\n- ENABLE_SASLAUTHD=1\n- SASLAUTHD_LDAP_FILTER=(&(sAMAccountName=%U)(objectClass=person))\n- SASLAUTHD_MECHANISMS=ldap\n# <<< SASL Authentication\n\n# >>> Postfix Ldap Integration\n- ENABLE_LDAP=1 # with the :edge tag, use ACCOUNT_PROVISIONER\n- ACCOUNT_PROVISIONER=LDAP\n- LDAP_SERVER_HOST=<yourLdapContainer/yourLdapServer>\n- LDAP_SEARCH_BASE=dc=mydomain,dc=loc\n- LDAP_BIND_DN=cn=Administrator,cn=Users,dc=mydomain,dc=loc\n- LDAP_BIND_PW=mypassword\n- LDAP_QUERY_FILTER_USER=(&(objectClass=user)(mail=%s))\n- LDAP_QUERY_FILTER_GROUP=(&(objectclass=group)(mail=%s))\n- LDAP_QUERY_FILTER_ALIAS=(&(objectClass=user)(otherMailbox=%s))\n- LDAP_QUERY_FILTER_DOMAIN=(&(|(mail=*@%s)(mailalias=*@%s)(mailGroupMember=*@%s))(mailEnabled=TRUE))\n# <<< Postfix Ldap Integration\n\n# >>> Kopano Integration\n- POSTFIX_DAGENT=lmtp:kopano:2003\n# <<< Kopano Integration\n\n- SSL_TYPE=letsencrypt\n- PERMIT_DOCKER=host\n\ncap_add:\n- NET_ADMIN\nA dovecot master account is able to login as any configured user. This is useful for administrative tasks like hot backups.
"},{"location":"config/advanced/dovecot-master-accounts/#configuration","title":"Configuration","text":"It is possible to create, update, delete and list dovecot master accounts using setup.sh. See setup.sh help for usage.
This feature is presently not supported with LDAP.
"},{"location":"config/advanced/dovecot-master-accounts/#logging-in","title":"Logging in","text":"Once a master account is configured, it is possible to connect to any users mailbox using this account. Log in over POP3/IMAP using the following credential scheme:
Username: <EMAIL ADDRESS>*<MASTER ACCOUNT NAME>
Password: <MASTER ACCOUNT PASSWORD>
Full-text search allows all messages to be indexed, so that mail clients can quickly and efficiently search messages by their full text content. Dovecot supports a variety of community supported FTS indexing backends.
DMS comes pre-installed with two plugins that can be enabled with a dovecot config file.
Please be aware that indexing consumes memory and takes up additional disk space.
"},{"location":"config/advanced/full-text-search/#xapian","title":"Xapian","text":"The dovecot-fts-xapian plugin makes use of Xapian. Xapian enables embedding an FTS engine without the need for additional backends.
The indexes will be stored as a subfolder named xapian-indexes inside your local mail-data folder (/var/mail internally). With the default settings, 10GB of email data may generate around 4GB of indexed data.
While indexing is memory intensive, you can configure the plugin to limit the amount of memory consumed by the index workers. With Xapian being small and fast, this plugin is a good choice for low memory environments (2GB) as compared to Solr.
"},{"location":"config/advanced/full-text-search/#setup","title":"Setup","text":"To configure fts-xapian as a dovecot plugin, create a file at docker-data/dms/config/dovecot/fts-xapian-plugin.conf and place the following in it:
mail_plugins = $mail_plugins fts fts_xapian\n\nplugin {\n fts = xapian\n fts_xapian = partial=3 full=20 verbose=0\n\n fts_autoindex = yes\n fts_enforced = yes\n\n # disable indexing of folders\n # fts_autoindex_exclude = \\Trash\n\n # Index attachements\n # fts_decoder = decode2text\n}\n\nservice indexer-worker {\n # limit size of indexer-worker RAM usage, ex: 512MB, 1GB, 2GB\n vsz_limit = 1GB\n}\n\n# service decode2text {\n# executable = script /usr/libexec/dovecot/decode2text.sh\n# user = dovecot\n# unix_listener decode2text {\n# mode = 0666\n# }\n# }\nadjust the settings to tune for your desired memory limits, exclude folders and enable searching text inside of attachments
Update compose.yaml to load the previously created dovecot plugin config file:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\nhostname: mail.example.com\nenv_file: mailserver.env\nports:\n- \"25:25\" # SMTP (explicit TLS => STARTTLS)\n- \"143:143\" # IMAP4 (explicit TLS => STARTTLS)\n- \"465:465\" # ESMTP (implicit TLS)\n- \"587:587\" # ESMTP (explicit TLS => STARTTLS)\n- \"993:993\" # IMAP4 (implicit TLS)\nvolumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/mail-state/:/var/mail-state/\n- ./docker-data/dms/mail-logs/:/var/log/mail/\n- ./docker-data/dms/config/:/tmp/docker-mailserver/\n- ./docker-data/dms/config/dovecot/fts-xapian-plugin.conf:/etc/dovecot/conf.d/10-plugin.conf:ro\n- /etc/localtime:/etc/localtime:ro\nrestart: always\nstop_grace_period: 1m\ncap_add:\n- NET_ADMIN\nRecreate containers:
docker compose down\ndocker compose up -d\nInitialize indexing on all users for all mail:
docker compose exec mailserver doveadm index -A -q \\*\nRun the following command in a daily cron job:
docker compose exec mailserver doveadm fts optimize -A\ncron from within DMS to avoid potential errors if the mail server is not running: Create a system cron file:
# in the compose.yaml root directory\nmkdir -p ./docker-data/dms/cron # if you didn't have this folder before\ntouch ./docker-data/dms/cron/fts_xapian\nchown root:root ./docker-data/dms/cron/fts_xapian\nchmod 0644 ./docker-data/dms/cron/fts_xapian\nEdit the system cron file nano ./docker-data/dms/cron/fts_xapian, and set an appropriate configuration:
# Adding `MAILTO=\"\"` prevents cron emailing notifications of the task outcome each run\nMAILTO=\"\"\n#\n# m h dom mon dow user command\n#\n# Everyday 4:00AM, optimize index files\n0 4 * * * root doveadm fts optimize -A\nThen with compose.yaml:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\nvolumes:\n- ./docker-data/dms/cron/fts_xapian:/etc/cron.d/fts_xapian\nThe dovecot-solr Plugin is used in conjunction with Apache Solr running in a separate container. This is quite straightforward to setup using the following instructions.
Solr is a mature and fast indexing backend that runs on the JVM. The indexes are relatively compact compared to the size of your total email.
However, Solr also requires a fair bit of RAM. While Solr is highly tuneable, it may require a bit of testing to get it right.
"},{"location":"config/advanced/full-text-search/#setup_1","title":"Setup","text":"compose.yaml:
solr:\nimage: lmmdock/dovecot-solr:latest\nvolumes:\n- ./docker-data/dms/config/dovecot/solr-dovecot:/opt/solr/server/solr/dovecot\nrestart: always\n\nmailserver:\ndepends_on:\n- solr\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\n...\nvolumes:\n...\n- ./docker-data/dms/config/dovecot/10-plugin.conf:/etc/dovecot/conf.d/10-plugin.conf:ro\n...\n./docker-data/dms/config/dovecot/10-plugin.conf:
mail_plugins = $mail_plugins fts fts_solr\n\nplugin {\nfts = solr\nfts_autoindex = yes\nfts_solr = url=http://solr:8983/solr/dovecot/\n}\nRecreate containers: docker compose down ; docker compose up -d
Flag all user mailbox FTS indexes as invalid, so they are rescanned on demand when they are next searched: docker compose exec mailserver doveadm fts rescan -A
See #905
"},{"location":"config/advanced/ipv6/","title":"Advanced | IPv6","text":""},{"location":"config/advanced/ipv6/#background","title":"Background","text":"If your container host supports IPv6, then DMS will automatically accept IPv6 connections by way of the docker host's IPv6. However, incoming mail will fail SPF checks because they will appear to come from the IPv4 gateway that docker is using to proxy the IPv6 connection (172.20.0.1 is the gateway).
This can be solved by supporting IPv6 connections all the way to the DMS container.
"},{"location":"config/advanced/ipv6/#setup-steps","title":"Setup steps","text":"+++ b/serv/compose.yaml\n@@ ... @@ services:\n\n+ ipv6nat:\n+ image: robbertkl/ipv6nat\n+ restart: always\n+ network_mode: \"host\"\n+ cap_add:\n+ - NET_ADMIN\n+ - SYS_MODULE\n+ volumes:\n+ - /var/run/docker.sock:/var/run/docker.sock:ro\n+ - /lib/modules:/lib/modules:ro\n\n@@ ... @@ networks:\n\n+ default:\n+ driver: bridge\n+ enable_ipv6: true\n+ ipam:\n+ driver: default\n+ config:\n+ - subnet: fd00:0123:4567::/48\n+ gateway: fd00:0123:4567::1\nSee #1438
"},{"location":"config/advanced/kubernetes/","title":"Advanced | Kubernetes","text":""},{"location":"config/advanced/kubernetes/#introduction","title":"Introduction","text":"This article describes how to deploy DMS to Kubernetes. Please note that there is also a Helm chart available.
Requirements
We assume basic knowledge about Kubernetes from the reader. Moreover, we assume the reader to have a basic understanding of mail servers. Ideally, the reader has deployed DMS before in an easier setup with Docker (Compose).
About Support for Kubernetes
Please note that Kubernetes is not officially supported and we do not build images specifically designed for it. When opening an issue, please remember that only Docker & Docker Compose are officially supported.
This content is entirely community-supported. If you find errors, please open an issue and provide a PR.
"},{"location":"config/advanced/kubernetes/#manifests","title":"Manifests","text":""},{"location":"config/advanced/kubernetes/#configuration","title":"Configuration","text":"We want to provide the basic configuration in the form of environment variables with a ConfigMap. Note that this is just an example configuration; tune the ConfigMap to your needs.
---\napiVersion: v1\nkind: ConfigMap\n\nmetadata:\nname: mailserver.environment\n\nimmutable: false\n\ndata:\nTLS_LEVEL: modern\nPOSTSCREEN_ACTION: drop\nOVERRIDE_HOSTNAME: mail.example.com\nFAIL2BAN_BLOCKTYPE: drop\nPOSTMASTER_ADDRESS: postmaster@example.com\nUPDATE_CHECK_INTERVAL: 10d\nPOSTFIX_INET_PROTOCOLS: ipv4\nONE_DIR: '1'\nENABLE_CLAMAV: '1'\nENABLE_POSTGREY: '0'\nENABLE_FAIL2BAN: '1'\nAMAVIS_LOGLEVEL: '-1'\nSPOOF_PROTECTION: '1'\nMOVE_SPAM_TO_JUNK: '1'\nENABLE_UPDATE_CHECK: '1'\nENABLE_SPAMASSASSIN: '1'\nSUPERVISOR_LOGLEVEL: warn\nSPAMASSASSIN_SPAM_TO_INBOX: '1'\n\n# here, we provide an example for the SSL configuration\nSSL_TYPE: manual\nSSL_CERT_PATH: /secrets/ssl/rsa/tls.crt\nSSL_KEY_PATH: /secrets/ssl/rsa/tls.key\nWe can also make use of user-provided configuration files, e.g. user-patches.sh, postfix-accounts.cf and more, to adjust DMS to our likings. We encourage you to have a look at Kustomize for creating ConfigMaps from multiple files, but for now, we will provide a simple, hand-written example. This example is absolutely minimal and only goes to show what can be done.
---\napiVersion: v1\nkind: ConfigMap\n\nmetadata:\nname: mailserver.files\n\ndata:\npostfix-accounts.cf: |\ntest@example.com|{SHA512-CRYPT}$6$someHashValueHere\nother@example.com|{SHA512-CRYPT}$6$someOtherHashValueHere\nStatic Configuration
With the configuration shown above, you can not dynamically add accounts as the configuration file mounted into the mail server can not be written to.
Use persistent volumes for production deployments.
"},{"location":"config/advanced/kubernetes/#persistence","title":"Persistence","text":"Thereafter, we need persistence for our data. Make sure you have a storage provisioner and that you choose the correct storageClassName.
---\napiVersion: v1\nkind: PersistentVolumeClaim\n\nmetadata:\nname: data\n\nspec:\nstorageClassName: local-path\naccessModes:\n- ReadWriteOnce\nresources:\nrequests:\nstorage: 25Gi\nA Service is required for getting the traffic to the pod itself. The service is somewhat crucial. Its configuration determines whether the original IP from the sender will be kept. More about this further down below.
The configuration you're seeing does keep the original IP, but you will not be able to scale this way. We have chosen to go this route in this case because we think most Kubernetes users will only want to have one instance.
---\napiVersion: v1\nkind: Service\n\nmetadata:\nname: mailserver\nlabels:\napp: mailserver\n\nspec:\ntype: LoadBalancer\n\nselector:\napp: mailserver\n\nports:\n# Transfer\n- name: transfer\nport: 25\ntargetPort: transfer\nprotocol: TCP\n# ESMTP with implicit TLS\n- name: esmtp-implicit\nport: 465\ntargetPort: esmtp-implicit\nprotocol: TCP\n# ESMTP with explicit TLS (STARTTLS)\n- name: esmtp-explicit\nport: 587\ntargetPort: esmtp-explicit\nprotocol: TCP\n# IMAPS with implicit TLS\n- name: imap-implicit\nport: 993\ntargetPort: imap-implicit\nprotocol: TCP\nLast but not least, the Deployment becomes the most complex component. It instructs Kubernetes how to run the DMS container and how to apply your ConfigMaps, persisted storage, etc. Additionally, we can set options to enforce runtime security here.
---\napiVersion: apps/v1\nkind: Deployment\n\nmetadata:\nname: mailserver\n\nannotations:\nignore-check.kube-linter.io/run-as-non-root: >-\n'mailserver' needs to run as root\nignore-check.kube-linter.io/privileged-ports: >-\n'mailserver' needs privilegdes ports\nignore-check.kube-linter.io/no-read-only-root-fs: >-\nThere are too many files written to make The\nroot FS read-only\n\nspec:\nreplicas: 1\nselector:\nmatchLabels:\napp: mailserver\n\ntemplate:\nmetadata:\nlabels:\napp: mailserver\n\nannotations:\ncontainer.apparmor.security.beta.kubernetes.io/mailserver: runtime/default\n\nspec:\nhostname: mail\ncontainers:\n- name: mailserver\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\nimagePullPolicy: IfNotPresent\n\nsecurityContext:\nallowPrivilegeEscalation: false\nreadOnlyRootFilesystem: false\nrunAsUser: 0\nrunAsGroup: 0\nrunAsNonRoot: false\nprivileged: false\ncapabilities:\nadd:\n# file permission capabilities\n- CHOWN\n- FOWNER\n- MKNOD\n- SETGID\n- SETUID\n- DAC_OVERRIDE\n# network capabilities\n- NET_ADMIN # needed for F2B\n- NET_RAW # needed for F2B\n- NET_BIND_SERVICE\n# miscellaneous capabilities\n- SYS_CHROOT\n- KILL\ndrop: [ALL]\nseccompProfile:\ntype: RuntimeDefault\n\n# You want to tune this to your needs. If you disable ClamAV,\n# you can use less RAM and CPU. This becomes important in\n# case you're low on resources and Kubernetes refuses to\n# schedule new pods.\nresources:\nlimits:\nmemory: 4Gi\ncpu: 1500m\nrequests:\nmemory: 2Gi\ncpu: 600m\n\nvolumeMounts:\n- name: files\nsubPath: postfix-accounts.cf\nmountPath: /tmp/docker-mailserver/postfix-accounts.cf\nreadOnly: true\n\n# PVCs\n- name: data\nmountPath: /var/mail\nsubPath: data\nreadOnly: false\n- name: data\nmountPath: /var/mail-state\nsubPath: state\nreadOnly: false\n- name: data\nmountPath: /var/log/mail\nsubPath: log\nreadOnly: false\n\n# certificates\n- name: certificates-rsa\nmountPath: /secrets/ssl/rsa/\nreadOnly: true\n\n# other\n- name: tmp-files\nmountPath: /tmp\nreadOnly: false\n\nports:\n- name: transfer\ncontainerPort: 25\nprotocol: TCP\n- name: esmtp-implicit\ncontainerPort: 465\nprotocol: TCP\n- name: esmtp-explicit\ncontainerPort: 587\n- name: imap-implicit\ncontainerPort: 993\nprotocol: TCP\n\nenvFrom:\n- configMapRef:\nname: mailserver.environment\n\nrestartPolicy: Always\n\nvolumes:\n# configuration files\n- name: files\nconfigMap:\nname: mailserver.files\n\n# PVCs\n- name: data\npersistentVolumeClaim:\nclaimName: data\n\n# certificates\n- name: certificates-rsa\nsecret:\nsecretName: mail-tls-certificate-rsa\nitems:\n- key: tls.key\npath: tls.key\n- key: tls.crt\npath: tls.crt\n\n# other\n- name: tmp-files\nemptyDir: {}\nIn this example, we use cert-manager to supply RSA certificates. You can also supply RSA certificates as fallback certificates, which DMS supports out of the box with SSL_ALT_CERT_PATH and SSL_ALT_KEY_PATH, and provide ECDSA as the proper certificates.
---\napiVersion: cert-manager.io/v1\nkind: Certificate\n\nmetadata:\nname: mail-tls-certificate-rsa\n\nspec:\nsecretName: mail-tls-certificate-rsa\nisCA: false\nprivateKey:\nalgorithm: RSA\nencoding: PKCS1\nsize: 2048\ndnsNames: [mail.example.com]\nissuerRef:\nname: mail-issuer\nkind: Issuer\nAttention
You will need to have cert-manager configured. Especially the issue will need to be configured. Since we do not know how you want or need your certificates to be supplied, we do not provide more configuration here. The documentation for cert-manager is excellent.
Sensitive Data
For storing OpenDKIM keys, TLS certificates or any sort of sensitive data, you should be using Secrets. You can mount secrets like ConfigMaps and use them the same way.
The TLS docs page provides guidance when it comes to certificates and transport layer security. Always provide sensitive information vai Secrets.
The more difficult part with Kubernetes is to expose a deployed DMS to the outside world. Kubernetes provides multiple ways for doing that; each has downsides and complexity. The major problem with exposing DMS to outside world in Kubernetes is to preserve the real client IP. The real client IP is required by DMS for performing IP-based SPF checks and spam checks. If you do not require SPF checks for incoming mails, you may disable them in your Postfix configuration by dropping the line that states: check_policy_service unix:private/policyd-spf.
The easiest approach was covered above, using externalTrafficPolicy: Local, which disables the service proxy, but makes the service local as well (which does not scale). This approach only works when you are given the correct (that is, a public and routable) IP address by a load balancer (like MetalLB). In this sense, the approach above is similar to the next example below. We want to provide you with a few alternatives too. But we also want to communicate the idea of another simple method: you could use a load-balancer without an external IP and DNAT the network traffic to the mail server. After all, this does not interfere with SPF checks because it keeps the origin IP address. If no dedicated external IP address is available, you could try the latter approach, if one is available, use the former.
The simplest way is to expose DMS as a Service with external IPs. This is very similar to the approach taken above. Here, an external IP is given to the service directly by you. With the approach above, you tell your load-balancer to do this.
---\napiVersion: v1\nkind: Service\n\nmetadata:\nname: mailserver\nlabels:\napp: mailserver\n\nspec:\nselector:\napp: mailserver\nports:\n- name: smtp\nport: 25\ntargetPort: smtp\n# ...\n\nexternalIPs:\n- 80.11.12.10\nThis approach
The proxy pod helps to avoid the necessity of specifying external IPs explicitly. This comes at the cost of complexity; you must deploy a proxy pod on each Node you want to expose DMS on.
This approach
One way to preserve the real client IP is to use hostPort and hostNetwork: true. This comes at the cost of availability; you can reach DMS from the outside world only via IPs of Node where DMS is deployed.
---\napiVersion: extensions/v1beta1\nkind: Deployment\n\nmetadata:\nname: mailserver\n\n# ...\nspec:\nhostNetwork: true\n\n# ...\ncontainers:\n# ...\nports:\n- name: smtp\ncontainerPort: 25\nhostPort: 25\n- name: smtp-auth\ncontainerPort: 587\nhostPort: 587\n- name: imap-secure\ncontainerPort: 993\nhostPort: 993\n# ...\nWith this approach,
This way is ideologically the same as using a proxy pod, but instead of a separate proxy pod, you configure your ingress to proxy TCP traffic to the DMS pod using the PROXY protocol, which preserves the real client IP.
"},{"location":"config/advanced/kubernetes/#configure-your-ingress","title":"Configure your Ingress","text":"With an NGINX ingress controller, set externalTrafficPolicy: Local for its service, and add the following to the TCP services config map (as described here):
25: \"mailserver/mailserver:25::PROXY\"\n465: \"mailserver/mailserver:465::PROXY\"\n587: \"mailserver/mailserver:587::PROXY\"\n993: \"mailserver/mailserver:993::PROXY\"\nHAProxy
With HAProxy, the configuration should look similar to the above. If you know what it actually looks like, add an example here.
"},{"location":"config/advanced/kubernetes/#configure-the-mailserver","title":"Configure the Mailserver","text":"Then, configure both Postfix and Dovecot to expect the PROXY protocol:
HAProxy Examplekind: ConfigMap\napiVersion: v1\nmetadata:\nname: mailserver.config\nlabels:\napp: mailserver\ndata:\npostfix-main.cf: |\npostscreen_upstream_proxy_protocol = haproxy\npostfix-master.cf: |\nsmtp/inet/postscreen_upstream_proxy_protocol=haproxy\nsubmission/inet/smtpd_upstream_proxy_protocol=haproxy\nsubmissions/inet/smtpd_upstream_proxy_protocol=haproxy\ndovecot.cf: |\n# Assuming your ingress controller is bound to 10.0.0.0/8\nhaproxy_trusted_networks = 10.0.0.0/8, 127.0.0.0/8\nservice imap-login {\ninet_listener imap {\nhaproxy = yes\n}\ninet_listener imaps {\nhaproxy = yes\n}\n}\n# ...\n---\n\nkind: Deployment\napiVersion: extensions/v1beta1\nmetadata:\nname: mailserver\nspec:\ntemplate:\nspec:\ncontainers:\n- name: docker-mailserver\nvolumeMounts:\n- name: config\nsubPath: postfix-main.cf\nmountPath: /tmp/docker-mailserver/postfix-main.cf\nreadOnly: true\n- name: config\nsubPath: postfix-master.cf\nmountPath: /tmp/docker-mailserver/postfix-master.cf\nreadOnly: true\n- name: config\nsubPath: dovecot.cf\nmountPath: /tmp/docker-mailserver/dovecot.cf\nreadOnly: true\nWith this approach,
To enable the fetchmail service to retrieve e-mails set the environment variable ENABLE_FETCHMAIL to 1. Your compose.yaml file should look like following snippet:
environment:\n- ENABLE_FETCHMAIL=1\n- FETCHMAIL_POLL=300\nGenerate a file called fetchmail.cf and place it in the docker-data/dms/config/ folder. Your DMS folder should look like this example:
\u251c\u2500\u2500 docker-data/dms/config\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 dovecot.cf\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 fetchmail.cf\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 postfix-accounts.cf\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 postfix-virtual.cf\n\u251c\u2500\u2500 compose.yaml\n\u2514\u2500\u2500 README.md\nA detailed description of the configuration options can be found in the online version of the manual page.
"},{"location":"config/advanced/mail-fetchmail/#imap-configuration","title":"IMAP Configuration","text":"Example
poll 'imap.gmail.com' proto imap\n user 'username'\n pass 'secret'\n is 'user1@example.com'\n ssl\nExample
poll 'pop3.gmail.com' proto pop3\n user 'username'\n pass 'secret'\n is 'user2@example.com'\n ssl\nCaution
Don\u2019t forget the last line! (eg: is 'user1@example.com'). After is, you have to specify an email address from the configuration file: docker-data/dms/config/postfix-accounts.cf.
More details how to configure fetchmail can be found in the fetchmail man page in the chapter \u201cThe run control file\u201d.
"},{"location":"config/advanced/mail-fetchmail/#polling-interval","title":"Polling Interval","text":"By default the fetchmail service searches every 5 minutes for new mails on your external mail accounts. You can override this default value by changing the ENV variable FETCHMAIL_POLL:
environment:\n- FETCHMAIL_POLL=60\nYou must specify a numeric argument which is a polling interval in seconds. The example above polls every minute for new mails.
"},{"location":"config/advanced/mail-fetchmail/#debugging","title":"Debugging","text":"To debug your fetchmail.cf configuration run this command:
./setup.sh debug fetchmail\nFor more informations about the configuration script setup.sh read the corresponding docs.
Here a sample output of ./setup.sh debug fetchmail:
fetchmail: 6.3.26 querying outlook.office365.com (protocol POP3) at Mon Aug 29 22:11:09 2016: poll started\nTrying to connect to 132.245.48.18/995...connected.\nfetchmail: Server certificate:\nfetchmail: Issuer Organization: Microsoft Corporation\nfetchmail: Issuer CommonName: Microsoft IT SSL SHA2\nfetchmail: Subject CommonName: outlook.com\nfetchmail: Subject Alternative Name: outlook.com\nfetchmail: Subject Alternative Name: *.outlook.com\nfetchmail: Subject Alternative Name: office365.com\nfetchmail: Subject Alternative Name: *.office365.com\nfetchmail: Subject Alternative Name: *.live.com\nfetchmail: Subject Alternative Name: *.internal.outlook.com\nfetchmail: Subject Alternative Name: *.outlook.office365.com\nfetchmail: Subject Alternative Name: outlook.office.com\nfetchmail: Subject Alternative Name: attachment.outlook.office.net\nfetchmail: Subject Alternative Name: attachment.outlook.officeppe.net\nfetchmail: Subject Alternative Name: *.office.com\nfetchmail: outlook.office365.com key fingerprint: 3A:A4:58:42:56:CD:BD:11:19:5B:CF:1E:85:16:8E:4D\nfetchmail: POP3< +OK The Microsoft Exchange POP3 service is ready. [SABFADEAUABSADAAMQBDAEEAMAAwADAANwAuAGUAdQByAHAAcgBkADAAMQAuAHAAcgBvAGQALgBlAHgAYwBoAGEAbgBnAGUAbABhAGIAcwAuAGMAbwBtAA==]\nfetchmail: POP3> CAPA\nfetchmail: POP3< +OK\nfetchmail: POP3< TOP\nfetchmail: POP3< UIDL\nfetchmail: POP3< SASL PLAIN\nfetchmail: POP3< USER\nfetchmail: POP3< .\nfetchmail: POP3> USER user1@outlook.com\nfetchmail: POP3< +OK\nfetchmail: POP3> PASS *\nfetchmail: POP3< +OK User successfully logged on.\nfetchmail: POP3> STAT\nfetchmail: POP3< +OK 0 0\nfetchmail: No mail for user1@outlook.com at outlook.office365.com\nfetchmail: POP3> QUIT\nfetchmail: POP3< +OK Microsoft Exchange Server 2016 POP3 server signing off.\nfetchmail: 6.3.26 querying outlook.office365.com (protocol POP3) at Mon Aug 29 22:11:11 2016: poll completed\nfetchmail: normal termination, status 1\nSieve allows to specify filtering rules for incoming emails that allow for example sorting mails into different folders depending on the title of an email. There are global and user specific filters which are filtering the incoming emails in the following order:
Global filters are applied to EVERY incoming mail for EVERY email address. To specify a global Sieve filter provide a docker-data/dms/config/before.dovecot.sieve or a docker-data/dms/config/after.dovecot.sieve file with your filter rules. If any filter in this filtering chain discards an incoming mail, the delivery process will stop as well and the mail will not reach any following filters(e.g. global-before stops an incoming spam mail: The mail will get discarded and a user-specific filter won't get applied.)
To specify a user-defined Sieve filter place a .dovecot.sieve file into a virtual user's mail folder e.g. /var/mail/example.com/user1/.dovecot.sieve. If this file exists dovecot will apply the filtering rules.
It's even possible to install a user provided Sieve filter at startup during users setup: simply include a Sieve file in the docker-data/dms/config/ path for each user login that needs a filter. The file name provided should be in the form <user_login>.dovecot.sieve, so for example for user1@example.com you should provide a Sieve file named docker-data/dms/config/user1@example.com.dovecot.sieve.
An example of a sieve filter that moves mails to a folder INBOX/spam depending on the sender address:
Example
require [\"fileinto\", \"reject\"];\n\nif address :contains [\"From\"] \"spam@spam.com\" {\n fileinto \"INBOX.spam\";\n} else {\n keep;\n}\nWarning
That folders have to exist beforehand if sieve should move them.
Another example of a sieve filter that forward mails to a different address:
Example
require [\"copy\"];\n\nredirect :copy \"user2@not-example.com\";\nJust forward all incoming emails and do not save them locally:
Example
redirect \"user2@not-example.com\";\nYou can also use external programs to filter or pipe (process) messages by adding executable scripts in docker-data/dms/config/sieve-pipe or docker-data/dms/config/sieve-filter. This can be used in lieu of a local alias file, for instance to forward an email to a webservice. These programs can then be referenced by filename, by all users. Note that the process running the scripts run as a privileged user. For further information see Dovecot's wiki.
require [\"vnd.dovecot.pipe\"];\npipe \"external-program\";\nFor more examples or a detailed description of the Sieve language have a look at the official site. Other resources are available on the internet where you can find several examples.
"},{"location":"config/advanced/mail-sieve/#automatic-sorting-based-on-subaddresses","title":"Automatic Sorting Based on Subaddresses","text":"It is possible to sort subaddresses such as user+mailing-lists@example.com into a corresponding folder (here: INBOX/Mailing-lists) automatically.
require [\"envelope\", \"fileinto\", \"mailbox\", \"subaddress\", \"variables\"];\n\nif envelope :detail :matches \"to\" \"*\" {\n set :lower :upperfirst \"tag\" \"${1}\";\n if mailboxexists \"INBOX.${1}\" {\n fileinto \"INBOX.${1}\";\n } else {\n fileinto :create \"INBOX.${tag}\";\n }\n}\nThe Manage Sieve extension allows users to modify their Sieve script by themselves. The authentication mechanisms are the same as for the main dovecot service. ManageSieve runs on port 4190 and needs to be enabled using the ENABLE_MANAGESIEVE=1 environment variable.
Example
# compose.yaml\nports:\n- \"4190:4190\"\nenvironment:\n- ENABLE_MANAGESIEVE=1\nAll user defined sieve scripts that are managed by ManageSieve are stored in the user's home folder in /var/mail/example.com/user1/sieve. Just one sieve script might be active for a user and is sym-linked to /var/mail/example.com/user1/.dovecot.sieve automatically.
Note
ManageSieve makes sure to not overwrite an existing .dovecot.sieve file. If a user activates a new sieve script the old one is backuped and moved to the sieve folder.
The extension is known to work with the following ManageSieve clients:
This is a list of all configuration files and directories which are optional or automatically generated in your docker-data/dms/config/ directory.
setup.sh config dkim. (Docs: DKIM)SSL_TYPE is set to self-signed or custom. (Docs: SSL)${login}.dovecot.sieve filter. (Docs: Sieve)${login}.dovecot.sieve filter. (Docs: Sieve)setup.sh email script.setup.sh email restrict.setup.sh email restrict.setup.sh alias.<username>:<password>. Modify via setup.sh relay add-auth <domain> <username> [<password>]. (Docs: Relay-Hosts Auth)setup.sh relay add-domain and setup.sh relay exclude-domain. (Docs: Relay-Hosts Senders)virtual_mailbox_maps. See the setup-stack.sh script.virtual_alias_maps. See the setup-stack.sh script.virtual_alias_maps. See the setup-stack.sh script.virtual_mailbox_domains. See the setup-stack.sh script.fail2ban.cf. (Docs: Fail2Ban)/etc/amavis/conf.d/50-user file/etc/dovecot/local.conf. (Docs: Override Dovecot Defaults)user-patches.sh script)Podman is a daemonless container engine for developing, managing, and running OCI Containers on your Linux System.
About Support for Podman
Please note that Podman is not officially supported as DMS is built and verified on top of the Docker Engine. This content is entirely community supported. If you find errors, please open an issue and provide a PR.
About this Guide
This guide was tested with Fedora 34 using systemd and firewalld. Moreover, it requires Podman version >= 3.2. You may be able to substitute dnf - Fedora's package manager - with others such as apt.
About Security
Running podman in rootless mode requires additional modifications in order to keep your mailserver secure. Make sure to read the related documentation.
"},{"location":"config/advanced/podman/#installation-in-rootfull-mode","title":"Installation in Rootfull Mode","text":"While using Podman, you can just manage docker-mailserver as what you did with Docker. Your best friend setup.sh includes the minimum code in order to support Podman since it's 100% compatible with the Docker CLI.
The installation is basically the same. Podman v3.2 introduced a RESTful API that is 100% compatible with the Docker API, so you can use Docker Compose with Podman easily. Install Podman and Docker Compose with your package manager first.
sudo dnf install podman docker-compose\nThen enable podman.socket using systemctl.
systemctl enable --now podman.socket\nThis will create a unix socket locate under /run/podman/podman.sock, which is the entrypoint of Podman's API. Now, configure docker-mailserver and start it.
export DOCKER_HOST=\"unix:///run/podman/podman.sock\"\ndocker compose up -d mailserver\ndocker compose ps\nYou should see that docker-mailserver is running now.
"},{"location":"config/advanced/podman/#self-start-in-rootfull-mode","title":"Self-start in Rootfull Mode","text":"Podman is daemonless, that means if you want docker-mailserver self-start while boot up the system, you have to generate a systemd file with Podman CLI.
podman generate systemd mailserver > /etc/systemd/system/mailserver.service\nsystemctl daemon-reload\nsystemctl enable --now mailserver.service\nRunning rootless containers is one of Podman's major features. But due to some restrictions, deploying docker-mailserver in rootless mode is not as easy compared to rootfull mode.
~/.configAlso notice that Podman's rootless mode is not about running as a non-root user inside the container, but about the mapping of (normal, non-root) host users to root inside the container.
Warning
In order to make rootless DMS work we must modify some settings in the Linux system, it requires some basic linux server knowledge so don't follow this guide if you not sure what this guide is talking about. Podman rootfull mode and Docker are still good and security enough for normal daily usage.
First, enable podman.socket in systemd's userspace with a non-root user.
systemctl enable --now --user podman.socket\nThe socket file should be located at /var/run/user/$(id -u)/podman/podman.sock. Then, modify compose.yaml to make sure all ports are bindings are on non-privileged ports.
services:\nmailserver:\nports:\n- \"10025:25\" # SMTP (explicit TLS => STARTTLS)\n- \"10143:143\" # IMAP4 (explicit TLS => STARTTLS)\n- \"10465:465\" # ESMTP (implicit TLS)\n- \"10587:587\" # ESMTP (explicit TLS => STARTTLS)\n- \"10993:993\" # IMAP4 (implicit TLS)\nThen, setup your mailserver.env file follow the documentation and use Docker Compose to start the container.
export DOCKER_HOST=\"unix:///var/run/user/$(id -u)/podman/podman.sock\"\ndocker compose up -d mailserver\ndocker compose ps\nIn rootless mode, podman resolves all incoming IPs as localhost, which results in an open gateway in the default configuration. There are two workarounds to fix this problem, both of which have their own drawbacks.
"},{"location":"config/advanced/podman/#enforce-authentication-from-localhost","title":"Enforce authentication from localhost","text":"The PERMIT_DOCKER variable in the mailserver.env file allows to specify trusted networks that do not need to authenticate. If the variable is left empty, only requests from localhost and the container IP are allowed, but in the case of rootless podman any IP will be resolved as localhost. Setting PERMIT_DOCKER=none enforces authentication also from localhost, which prevents sending unauthenticated emails.
The second workaround is slightly more complicated because the compose.yaml has to be modified. As shown in the fail2ban section the slirp4netns network driver has to be enabled. This network driver enables podman to correctly resolve IP addresses but it is not compatible with user defined networks which might be a problem depending on your setup.
Rootless Podman requires adding the value slirp4netns:port_handler=slirp4netns to the --network CLI option, or network_mode setting in your compose.yaml.
You must also add the ENV NETWORK_INTERFACE=tap0, because Podman uses a hard-coded interface name for slirp4netns.
Example
services:\nmailserver:\nnetwork_mode: \"slirp4netns:port_handler=slirp4netns\"\nenvironment:\n- NETWORK_INTERFACE=tap0\n...\nNote
podman-compose is not compatible with this configuration.
Generate a systemd file with the Podman CLI.
podman generate systemd mailserver > ~/.config/systemd/user/mailserver.service\nsystemctl --user daemon-reload\nsystemctl enable --user --now mailserver.service\nSystemd's user space service is only started when a specific user logs in and stops when you log out. In order to make it to start with the system, we need to enable linger with loginctl
loginctl enable-linger <username>\nRemember to run this command as root user.
"},{"location":"config/advanced/podman/#port-forwarding","title":"Port Forwarding","text":"When it comes to forwarding ports using firewalld, see https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/securing_networks/using-and-configuring-firewalld_securing-networks#port-forwarding_using-and-configuring-firewalld for more information.
firewall-cmd --permanent --add-forward-port=port=<25|143|465|587|993>:proto=<tcp>:toport=<10025|10143|10465|10587|10993>\n...\n\n# After you set all ports up.\nfirewall-cmd --reload\nNotice that this will only open the access to the external client. If you want to access privileges port in your server, do this:
firewall-cmd --permanent --direct --add-rule <ipv4|ipv6> nat OUTPUT 0 -p <tcp|udp> -o lo --dport <25|143|465|587|993> -j REDIRECT --to-ports <10025|10143|10465|10587|10993>\n...\n# After you set all ports up.\nfirewall-cmd --reload\nJust map all the privilege port with non-privilege port you set in compose.yaml before as root user.
"},{"location":"config/advanced/mail-forwarding/aws-ses/","title":"Mail Forwarding | AWS SES","text":"Amazon SES (Simple Email Service) is intended to provide a simple way for cloud based applications to send email and receive email. For the purposes of this project only sending email via SES is supported. Older versions of docker-mailserver used AWS_SES_HOST and AWS_SES_USERPASS to configure sending, this has changed and the setup is mananged through Configure Relay Hosts.
You will need to create some Amazon SES SMTP credentials. The SMTP credentials you create will be used to populate the RELAY_USER and RELAY_PASSWORD environment variables.
The RELAY_HOST should match your AWS SES region, the RELAY_PORT will be 587.
If all of your email is being forwarded through AWS SES, DEFAULT_RELAY_HOST should be set accordingly.
Example:
DEFAULT_RELAY_HOST=[email-smtp.us-west-2.amazonaws.com]:587\nNote
If you set up AWS Easy DKIM you can safely skip setting up DKIM as the AWS SES will take care of signing your outgoing email.
To verify proper operation, send an email to some external account of yours and inspect the mail headers. You will also see the connection to SES in the mail logs. For example:
May 23 07:09:36 mail postfix/smtp[692]: Trusted TLS connection established to email-smtp.us-east-1.amazonaws.com[107.20.142.169]:25:\nTLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)\nMay 23 07:09:36 mail postfix/smtp[692]: 8C82A7E7: to=<someone@example.com>, relay=email-smtp.us-east-1.amazonaws.com[107.20.142.169]:25,\ndelay=0.35, delays=0/0.02/0.13/0.2, dsn=2.0.0, status=sent (250 Ok 01000154dc729264-93fdd7ea-f039-43d6-91ed-653e8547867c-000000)\nRather than having Postfix deliver mail directly, you can configure Postfix to send mail via another mail relay (smarthost). Examples include Mailgun, Sendgrid and AWS SES.
Depending on the domain of the sender, you may want to send via a different relay, or authenticate in a different way.
"},{"location":"config/advanced/mail-forwarding/relay-hosts/#basic-configuration","title":"Basic Configuration","text":"Basic configuration is done via environment variables:
RELAY_HOST: default host to relay mail through, empty (aka '', or no ENV set) will disable this featureRELAY_PORT: port on default relay, defaults to port 25RELAY_USER: username for the default relayRELAY_PASSWORD: password for the default userSetting these environment variables will cause mail for all sender domains to be routed via the specified host, authenticating with the user/password combination.
Warning
For users of the previous AWS_SES_* variables: please update your configuration to use these new variables, no other configuration is required.
Sender dependent authentication is done in docker-data/dms/config/postfix-sasl-password.cf. You can create this file manually, or use:
setup.sh relay add-auth <domain> <username> [<password>]\nAn example configuration file looks like this:
@domain1.com relay_user_1:password_1\n@domain2.com relay_user_2:password_2\nIf there is no other configuration, this will cause Postfix to deliver email through the relay specified in RELAY_HOST env variable, authenticating as relay_user_1 when sent from domain1.com and authenticating as relay_user_2 when sending from domain2.com.
Note
To activate the configuration you must either restart the container, or you can also trigger an update by modifying a mail account.
"},{"location":"config/advanced/mail-forwarding/relay-hosts/#sender-dependent-relay-host","title":"Sender-dependent Relay Host","text":"Sender dependent relay hosts are configured in docker-data/dms/config/postfix-relaymap.cf. You can create this file manually, or use:
setup.sh relay add-domain <domain> <host> [<port>]\nAn example configuration file looks like this:
@domain1.com [relay1.org]:587\n@domain2.com [relay2.org]:2525\nCombined with the previous configuration in docker-data/dms/config/postfix-sasl-password.cf, this will cause Postfix to deliver mail sent from domain1.com via relay1.org:587, authenticating as relay_user_1, and mail sent from domain2.com via relay2.org:2525 authenticating as relay_user_2.
Note
You still have to define RELAY_HOST to activate the feature
If you want mail sent from some domains to be delivered directly, you can exclude them from being delivered via the default relay by adding them to docker-data/dms/config/postfix-relaymap.cf with no destination. You can also do this via:
setup.sh relay exclude-domain <domain>\nExtending the configuration file from above:
@domain1.com [relay1.org]:587\n@domain2.com [relay2.org]:2525\n@domain3.com\nThis will cause email sent from domain3.com to be delivered directly.
Docker images are handy but it can become a hassle to keep them updated. Also when a repository is automated you want to get these images when they get out.
One could setup a complex action/hook-based workflow using probes, but there is a nice, easy to use docker image that solves this issue and could prove useful: watchtower.
A Docker Compose example:
services:\nwatchtower:\nrestart: always\nimage: containrrr/watchtower:latest\nvolumes:\n- /var/run/docker.sock:/var/run/docker.sock\nFor more details, see the manual
"},{"location":"config/advanced/maintenance/update-and-cleanup/#automatic-cleanup","title":"Automatic Cleanup","text":"When you are pulling new images in automatically, it would be nice to have them cleaned up as well. There is also a docker image for this: spotify/docker-gc.
A Docker Compose example:
services:\ndocker-gc:\nrestart: always\nimage: spotify/docker-gc:latest\nvolumes:\n- /var/run/docker.sock:/var/run/docker.sock\nFor more details, see the manual
Or you can just use the --cleanup option provided by containrrr/watchtower.
The Dovecot default configuration can easily be extended providing a docker-data/dms/config/dovecot.cf file. Dovecot documentation remains the best place to find configuration options.
Your DMS folder structure should look like this example:
\u251c\u2500\u2500 docker-data/dms/config\n\u2502 \u251c\u2500\u2500 dovecot.cf\n\u2502 \u251c\u2500\u2500 postfix-accounts.cf\n\u2502 \u2514\u2500\u2500 postfix-virtual.cf\n\u251c\u2500\u2500 compose.yaml\n\u2514\u2500\u2500 README.md\nOne common option to change is the maximum number of connections per user:
mail_max_userip_connections = 100\nAnother important option is the default_process_limit (defaults to 100). If high-security mode is enabled you'll need to make sure this count is higher than the maximum number of users that can be logged in simultaneously.
This limit is quickly reached if users connect to DMS with multiple end devices.
"},{"location":"config/advanced/override-defaults/dovecot/#override-configuration","title":"Override Configuration","text":"For major configuration changes it\u2019s best to override the dovecot configuration files. For each configuration file you want to override, add a list entry under the volumes key.
services:\nmailserver:\nvolumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/config/dovecot/10-master.conf:/etc/dovecot/conf.d/10-master.conf\nYou will first need to obtain the configuration from the running container (where mailserver is the container name):
mkdir -p ./docker-data/dms/config/dovecot\ndocker cp mailserver:/etc/dovecot/conf.d/10-master.conf ./docker-data/dms/config/dovecot/10-master.conf\nTo debug your dovecot configuration you can use:
./setup.sh debug login doveconf | grep <some-keyword>docker exec -it mailserver doveconf | grep <some-keyword>Note
setup.sh is included in the DMS repository. Make sure to use the one matching your image version release.
The file docker-data/dms/config/dovecot.cf is copied internally to /etc/dovecot/local.conf. To verify the file content, run:
docker exec -it mailserver cat /etc/dovecot/local.conf\nOur default Postfix configuration can easily be extended to add parameters or modify existing ones by providing a docker-data/dms/config/postfix-main.cf. This file uses the same format as Postfix main.cf does (See official docs for all parameters and syntax rules).
Example
One can easily increase the backwards-compatibility level and set new Postscreen options:
# increase the compatibility level from 2 (default) to 3\ncompatibility_level = 3\n# set a threshold value for Spam detection\npostscreen_dnsbl_threshold = 4\nHow are your changes applied?
The custom configuration you supply is appended to the default configuration located at /etc/postfix/main.cf, and then postconf -nf is run to remove earlier duplicate entries that have since been replaced. This happens early during container startup before Postfix is started.
Similarly, it is possible to add a custom docker-data/dms/config/postfix-master.cf file that will override the standard master.cf. Note: Each line in this file will be passed to postconf -P, i.e. the file is not appended as a whole to /etc/postfix/master.cf like docker-data/dms/config/postfix-main.cf! The expected format is <service_name>/<type>/<parameter>, for example:
# adjust the submission \"reject_unlisted_recipient\" option\nsubmission/inet/smtpd_reject_unlisted_recipient=no\nAttention
There should be no space between the parameter and the value.
Run postconf -Mf in the container without arguments to see the active master options.
If you'd like to change, patch or alter files or behavior of DMS, you can use a script.
In case you cloned this repository, you can copy the file user-patches.sh.dist (under config/) with cp config/user-patches.sh.dist docker-data/dms/config/user-patches.sh in order to create the user-patches.sh script.
If you are managing your directory structure yourself, create a docker-data/dms/config/ directory and add the user-patches.sh file yourself.
# 1. Either create the docker-data/dms/config/ directory yourself\n# or let docker-mailserver create it on initial startup\n/tmp $ mkdir -p docker-data/dms/config/ && cd docker-data/dms/config/\n\n# 2. Create the user-patches.sh file and edit it\n/tmp/docker-data/dms/config $ touch user-patches.sh\n/tmp/docker-data/dms/config $ nano user-patches.sh\nThe contents could look like this:
#!/bin/bash\n\ncat >/etc/amavis/conf.d/50-user << \"END\"\nuse strict;\n\n$undecipherable_subject_tag = undef;\n$admin_maps_by_ccat{+CC_UNCHECKED} = undef;\n\n#------------ Do not modify anything below this line -------------\n1; # ensure a defined return\nEND\nAnd you're done. The user patches script runs right before starting daemons. That means, all the other configuration is in place, so the script can make final adjustments.
Note
Many \"patches\" can already be done with the Docker Compose-/Stack-file. Adding hostnames to /etc/hosts is done with the extra_hosts: section, sysctl commands can be managed with the sysctls: section, etc.
Email auto-discovery means a client email is able to automagically find out about what ports and security options to use, based on the mail server URI. It can help simplify the tedious / confusing task of adding own's email account for non-tech savvy users.
Email clients will search for auto-discoverable settings and prefill almost everything when a user enters its email address
There exists autodiscover-email-settings on which provides IMAP/POP/SMTP/LDAP autodiscover capabilities on Microsoft Outlook/Apple Mail, autoconfig capabilities for Thunderbird or kmail and configuration profiles for iOS/Apple Mail.
"},{"location":"config/best-practices/dkim_dmarc_spf/","title":"DKIM, DMARC & SPF","text":"Cloudflare has written an article about DKIM, DMARC and SPF that we highly recommend you to read to get acquainted with the topic.
Rspamd vs Individual validators
With v12.0.0, Rspamd was integrated into DMS. It can perform validations for DKIM, DMARC and SPF as part of the spam-score-calculation for an email. DMS provides individual alternatives for each validation that can be used instead of deferring to Rspamd:
opendkim is used as a milter (like Rspamd)opendmarc is used as a milter (like Rspamd)policyd-spf is used in Postfix's smtpd_recipient_restrictionsIn a future release Rspamd will become the default for these validations, with a deprecation notice issued prior to the removal of the above alternatives.
We encourage everyone to prefer Rspamd via ENABLE_RSPAMD=1.
DNS Caches & Propagation
While modern DNS providers are quick, it may take minutes or even hours for new DNS records to become available / propagate.
"},{"location":"config/best-practices/dkim_dmarc_spf/#dkim","title":"DKIM","text":"What is DKIM
DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in email (email spoofing), a technique often used in phishing and email spam.
Source
When DKIM is enabled:
DKIM requires a public/private key pair to enable signing (via private key) your outgoing mail, while the receiving end must query DNS to verify (via public key) that the signature is trustworthy.
"},{"location":"config/best-practices/dkim_dmarc_spf/#generating-keys","title":"Generating Keys","text":"You should have:
RSA Key Sizes >= 4096 Bit
Keys of 4096 bits could be denied by some mail servers. According to RFC 6376, keys are preferably between 512 and 2048 bits.
DKIM is currently supported by either OpenDKIM or Rspamd:
OpenDKIMRspamdOpenDKIM is currently enabled by default.
The command docker exec <CONTAINER NAME> setup config dkim help details supported config options, along with some examples.
Creating a DKIM key
Generate the DKIM files with:
docker exec -ti <CONTAINER NAME> setup config dkim\nYour new DKIM key(s) and OpenDKIM config files have been added to /tmp/docker-mailserver/opendkim/.
The command is unable to infer the domains from LDAP user accounts, you must specify them:
setup config dkim domain 'example.com,example.io'\nThe private key presently defaults to RSA-4096. To create an RSA 2048-bit key run:
setup config dkim keysize 2048\nRestart required
After restarting DMS, outgoing mail will now be signed with your new DKIM key(s)
You'll need to repeat this process if you add any new domains.
Opt-in via ENABLE_RSPAMD=1 (and disable the default OpenDKIM: ENABLE_OPENDKIM=0).
Rspamd provides DKIM support through two separate modules:
Creating DKIM Keys
You can simply run
docker exec -ti <CONTAINER NAME> setup config dkim help\nwhich provides you with an overview of what the script can do. Just running
docker exec -ti <CONTAINER NAME> setup config dkim\nwill execute the helper script with default parameters.
About the Helper Script
The script will persist the keys in /tmp/docker-mailserver/rspamd/dkim/. Hence, if you are already using the default volume mounts, the keys are persisted in a volume. The script also restarts Rspamd directly, so changes take effect without restarting DMS.
The script provides you with log messages along the way of creating keys. In case you want to read the complete log, use -v (verbose) or -vv (very verbose).
In case you have not already provided a default DKIM signing configuration, the script will create one and write it to /etc/rspamd/override.d/dkim_signing.conf. If this file already exist, it will not be overwritten. When you're already using the rspamd/override.d/ directory, the file is created inside your volume and therefore persisted correctly. If you are not using rspamd/override.d/, you will need to persist the file yourself (otherwise it is lost on container restart).
An example of what a default configuration file for DKIM signing looks like can be found by expanding the example below.
DKIM Signing Module Configuration ExamplesA simple configuration could look like this:
# documentation: https://rspamd.com/doc/modules/dkim_signing.html\n\nenabled = true;\n\nsign_authenticated = true;\nsign_local = true;\n\nuse_domain = \"header\";\nuse_redis = false; # don't change unless Redis also provides the DKIM keys\nuse_esld = true;\n\ncheck_pubkey = true; # you wan't to use this in the beginning\n\ndomain {\nexample.com {\npath = \"/tmp/docker-mailserver/rspamd/dkim/mail.private\";\nselector = \"mail\";\n}\n}\nAs shown next:
domain { ... } section.selectors [ ... ] array.# ...\n\ndomain {\nexample.com {\nselectors [\n{\npath = \"/tmp/docker-mailserver/rspamd/dkim/example.com/rsa.private\";\nselector = \"dkim-rsa\";\n},\n{\npath = /tmp/docker-mailserver/rspamd/example.com/ed25519.private\";\nselector = \"dkim-ed25519\";\n}\n]\n}\nexample.org {\nselectors [\n{\npath = \"/tmp/docker-mailserver/rspamd/dkim/example.org/rsa.private\";\nselector = \"dkim-rsa\";\n},\n{\npath = \"/tmp/docker-mailserver/rspamd/dkim/example.org/ed25519.private\";\nselector = \"dkim-ed25519\";\n}\n]\n}\n}\nThis modern elliptic curve is supported by Rspamd, but support by third-parties for verifying Ed25519 DKIM signatures is unreliable.
If you sign your mail with this key type, you should include RSA as a fallback, like shown in the above example.
Let Rspamd Check Your KeysWhen check_pubkey = true; is set, Rspamd will query the DNS record for each DKIM selector, verifying each public key matches the private key configured.
If there is a mismatch, a warning will be omitted to the Rspamd log /var/log/supervisor/rspamd.log.
When mail signed with your DKIM key is sent from your mail server, the receiver needs to check a DNS TXT record to verify the DKIM signature is trustworthy.
Configuring DNS - DKIM record
When you generated your key in the previous step, the DNS data was saved into a file <selector>.txt (default: mail.txt). Use this content to update your DNS via Web Interface or directly edit your DNS Zone file:
Create a new record:
Field Value TypeTXT Name <selector>._domainkey (default: mail._domainkey) TTL Use the default (otherwise 3600 seconds is appropriate) Data File content within ( ... ) (formatted as advised below) When using Rspamd, the helper script has already provided you with the contents (the \"Data\" field) of the DNS record you need to create - you can just copy-paste this text.
<selector>.txt is already formatted as a snippet for adding to your DNS Zone file.
Just copy/paste the file contents into your existing DNS zone. The TXT value has been split into separate strings every 255 characters for compatibility.
<selector>.txt - Formatting the TXT record value correctly This file was generated for use within a DNS zone file. DNS TXT records values that are longer than 255 characters need to be split into multiple parts. This is why the public key has multiple parts wrapped within double-quotes between ( and ).
A DNS web-interface may handle this internally instead, while others may not, but expect the input as a single line_). You'll need to manually format the value as described below.
Your DNS record file (eg: mail.txt) should look similar to this:
mail._domainkey IN TXT ( \"v=DKIM1; k=rsa; \"\n\"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqQMMqhb1S52Rg7VFS3EC6JQIMxNDdiBmOKZvY5fiVtD3Z+yd9ZV+V8e4IARVoMXWcJWSR6xkloitzfrRtJRwOYvmrcgugOalkmM0V4Gy/2aXeamuiBuUc4esDQEI3egmtAsHcVY1XCoYfs+9VqoHEq3vdr3UQ8zP/l+FP5UfcaJFCK/ZllqcO2P1GjIDVSHLdPpRHbMP/tU1a9mNZ\"\n\"5QMZBJ/JuJK/s+2bp8gpxKn8rh1akSQjlynlV9NI+7J3CC7CUf3bGvoXIrb37C/lpJehS39KNtcGdaRufKauSfqx/7SxA0zyZC+r13f7ASbMaQFzm+/RRusTqozY/p/MsWx8QIDAQAB\"\n) ;\nTake the content between ( ... ), and combine all the quote wrapped content and remove the double-quotes including the white-space between them. That is your TXT record value, the above example would become this:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqQMMqhb1S52Rg7VFS3EC6JQIMxNDdiBmOKZvY5fiVtD3Z+yd9ZV+V8e4IARVoMXWcJWSR6xkloitzfrRtJRwOYvmrcgugOalkmM0V4Gy/2aXeamuiBuUc4esDQEI3egmtAsHcVY1XCoYfs+9VqoHEq3vdr3UQ8zP/l+FP5UfcaJFCK/ZllqcO2P1GjIDVSHLdPpRHbMP/tU1a9mNZ5QMZBJ/JuJK/s+2bp8gpxKn8rh1akSQjlynlV9NI+7J3CC7CUf3bGvoXIrb37C/lpJehS39KNtcGdaRufKauSfqx/7SxA0zyZC+r13f7ASbMaQFzm+/RRusTqozY/p/MsWx8QIDAQAB\nTo test that your new DKIM record is correct, query it with the dig command. The TXT value response should be a single line split into multiple parts wrapped in double-quotes:
$ dig +short TXT dkim-rsa._domainkey.example.com\n\"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqQMMqhb1S52Rg7VFS3EC6JQIMxNDdiBmOKZvY5fiVtD3Z+yd9ZV+V8e4IARVoMXWcJWSR6xkloitzfrRtJRwOYvmrcgugOalkmM0V4Gy/2aXeamuiBuUc4esDQEI3egmtAsHcVY1XCoYfs+9VqoHEq3vdr3UQ8zP/l+FP5UfcaJFCK/ZllqcO2P1GjIDVSHLdPpRHbMP/tU1a9mNZ5QMZBJ/JuJK/s+2bp8gpxKn8rh1akSQjlynlV9NI+7J3CC7CUf3bGvoXIrb37C/lpJehS39\" \"KNtcGdaRufKauSfqx/7SxA0zyZC+r13f7ASbMaQFzm+/RRusTqozY/p/MsWx8QIDAQAB\"\nMxToolbox has a DKIM Verifier that you can use to check your DKIM DNS record(s).
When using Rspamd, we recommend you turn on check_pubkey = true; in dkim_signing.conf. Rspamd will then check whether your private key matches your public key, and you can check possible mismatches by looking at /var/log/supervisor/rspamd.log.
With DMS, DMARC is pre-configured out of the box. You may disable extra and excessive DMARC checks when using Rspamd via ENABLE_OPENDMARC=0.
The only thing you need to do in order to enable DMARC on a \"DNS-level\" is to add new TXT. In contrast to DKIM, DMARC DNS entries do not require any keys, but merely setting the configuration values. You can either handcraft the entry by yourself or use one of available generators (like this one).
Typically something like this should be good to start with:
_dmarc.example.com. IN TXT \"v=DMARC1; p=none; sp=none; fo=0; adkim=4; aspf=r; pct=100; rf=afrf; ri=86400; rua=mailto:dmarc.report@example.com; ruf=mailto:dmarc.report@example.com\"\nOr a bit more strict policies (mind p=quarantine and sp=quarantine):
_dmarc.example.com. IN TXT \"v=DMARC1; p=quarantine; sp=quarantine; fo=0; adkim=r; aspf=r; pct=100; rf=afrf; ri=86400; rua=mailto:dmarc.report@example.com; ruf=mailto:dmarc.report@example.com\"\nThe DMARC status may not be displayed instantly due to delays in DNS (caches). Dmarcian has a few tools you can use to verify your DNS records.
"},{"location":"config/best-practices/dkim_dmarc_spf/#spf","title":"SPF","text":"What is SPF
Sender Policy Framework (SPF) is a simple email-validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain comes from a host authorized by that domain's administrators.
Source
Disabling policyd-spf?
As of now, policyd-spf cannot be disabled. This is WIP.
To add a SPF record in your DNS, insert the following line in your DNS zone:
example.com. IN TXT \"v=spf1 mx ~all\"\nThis enables the Softfail mode for SPF. You could first add this SPF record with a very low TTL. SoftFail is a good setting for getting started and testing, as it lets all email through, with spams tagged as such in the mailbox.
After verification, you might want to change your SPF record to v=spf1 mx -all so as to enforce the HardFail policy. See http://www.open-spf.org/SPF_Record_Syntax for more details about SPF policies.
In any case, increment the SPF record's TTL to its final value.
"},{"location":"config/best-practices/dkim_dmarc_spf/#backup-mx-secondary-mx-for-policyd-spf","title":"Backup MX & Secondary MX forpolicyd-spf","text":"For whitelisting an IP Address from the SPF test, you can create a config file (see policyd-spf.conf) and mount that file into /etc/postfix-policyd-spf-python/policyd-spf.conf.
Example: Create and edit a policyd-spf.conf file at docker-data/dms/config/postfix-policyd-spf.conf:
debugLevel = 1\n#0(only errors)-4(complete data received)\n\nskip_addresses = 127.0.0.0/8,::ffff:127.0.0.0/104,::1\n\n# Preferably use IP-Addresses for whitelist lookups:\nWhitelist = 192.168.0.0/31,192.168.1.0/30\n# Domain_Whitelist = mx1.not-example.com,mx2.not-example.com\nThen add this line to compose.yaml:
volumes:\n- ./docker-data/dms/config/postfix-policyd-spf.conf:/etc/postfix-policyd-spf-python/policyd-spf.conf\nWhat is Fail2Ban (F2B)?
Fail2ban is an intrusion prevention software framework. Written in the Python programming language, it is designed to prevent against brute-force attacks. It is able to run on POSIX systems that have an interface to a packet-control system or firewall installed locally, such as [NFTables] or TCP Wrapper.
Source
"},{"location":"config/security/fail2ban/#configuration","title":"Configuration","text":"Warning
DMS must be launched with the NET_ADMIN capability in order to be able to install the NFTables rules that actually ban IP addresses. Thus, either include --cap-add=NET_ADMIN in the docker run command, or the equivalent in the compose.yaml:
cap_add:\n- NET_ADMIN\nRunning Fail2Ban on Older Kernels
DMS configures F2B to use NFTables, not IPTables (legacy). We have observed that older systems, for example NAS systems, do not support the modern NFTables rules. You will need to configure F2B to use legacy IPTables again, for example with the fail2ban-jail.cf, see the section on configuration further down below.
DMS will automatically ban IP addresses of hosts that have generated 6 failed attempts over the course of the last week. The bans themselves last for one week. The Postfix jail is configured to use mode = extra in DMS.
What is docker-data/dms/config/?
This following configuration files inside the docker-data/dms/config/ volume will be copied inside the container during startup
fail2ban-jail.cf is copied to /etc/fail2ban/jail.d/user-jail.localfail2ban-fail2ban.cf is copied to /etc/fail2ban/fail2ban.localWhen just running
setup fail2ban\nthe script will show all banned IP addresses.
"},{"location":"config/security/fail2ban/#managing-bans","title":"Managing Bans","text":"You can manage F2B with the setup script. The usage looks like this:
docker exec <CONTAINER NAME> setup fail2ban [<ban|unban> <IP>]\ndocker exec <CONTAINER NAME> setup fail2ban log\nRootlessKit is the fakeroot implementation for supporting rootless mode in Docker and Podman. By default, RootlessKit uses the builtin port forwarding driver, which does not propagate source IP addresses.
It is necessary for F2B to have access to the real source IP addresses in order to correctly identify clients. This is achieved by changing the port forwarding driver to slirp4netns, which is slower than the builtin driver but does preserve the real source IPs.
For rootless mode in Docker, create ~/.config/systemd/user/docker.service.d/override.conf with the following content:
Danger
This changes the port driver for all rootless containers managed by Docker. Per container configuration is not supported, if you need that consider Podman instead.
[Service]\nEnvironment=\"DOCKERD_ROOTLESS_ROOTLESSKIT_PORT_DRIVER=slirp4netns\"\nAnd then restart the daemon:
$ systemctl --user daemon-reload\n$ systemctl --user restart docker\nRootless Podman requires adding the value slirp4netns:port_handler=slirp4netns to the --network CLI option, or network_mode setting in your compose.yaml:
Example
services:\nmailserver:\nnetwork_mode: \"slirp4netns:port_handler=slirp4netns\"\nenvironment:\n- ENABLE_FAIL2BAN=1\n- NETWORK_INTERFACE=tap0\n...\nYou must also add the ENV NETWORK_INTERFACE=tap0, because Podman uses a hard-coded interface name for slirp4netns. slirp4netns is not compatible with user-defined networks!
Info
The Mail crypt plugin is used to secure email messages stored in a Dovecot system. Messages are encrypted before written to storage and decrypted after reading. Both operations are transparent to the user.
In case of unauthorized access to the storage backend, the messages will, without access to the decryption keys, be unreadable to the offending party.
There can be a single encryption key for the whole system or each user can have a key of their own. The used cryptographical methods are widely used standards and keys are stored in portable formats, when possible.
Official Dovecot documentation: https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/
"},{"location":"config/security/mail_crypt/#single-encryption-key-global-method","title":"Single Encryption Key / Global Method","text":"Create 10-custom.conf and populate it with the following:
# Enables mail_crypt for all services (imap, pop3, etc)\nmail_plugins = $mail_plugins mail_crypt\nplugin {\n mail_crypt_global_private_key = </certs/ecprivkey.pem\n mail_crypt_global_public_key = </certs/ecpubkey.pem\n mail_crypt_save_version = 2\n}\nShutdown your mailserver (docker compose down)
You then need to generate your global EC key. We named them /certs/ecprivkey.pem and /certs/ecpubkey.pem in step #1.
The EC key needs to be available in the container. I prefer to mount a /certs directory into the container:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\nvolumes:\n. . .\n- ./certs/:/certs\n. . .\nWhile you're editing the compose.yaml, add the configuration file:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\nvolumes:\n. . .\n- ./config/dovecot/10-custom.conf:/etc/dovecot/conf.d/10-custom.conf\n- ./certs/:/certs\n. . .\nStart the container, monitor the logs for any errors, send yourself a message, and then confirm the file on disk is encrypted:
[root@ip-XXXXXXXXXX ~]# cat -A /mnt/efs-us-west-2/maildata/awesomesite.com/me/cur/1623989305.M6v\ufffdz\ufffd@\ufffd\ufffd m}\ufffd\ufffd,\ufffd\ufffd9\ufffd\ufffd\ufffd\ufffdB*\ufffd247.us-west-2.compute.inE\ufffd\ufffd\\Ck*\ufffd@7795,W=7947:2,\nT\ufffd9\ufffd8t\ufffd6\ufffd\ufffd t\ufffd\ufffd\ufffde\ufffdW\ufffd\ufffdS `\ufffdH\ufffd\ufffdC\ufffd\u06a4 \ufffdyeY\ufffd\ufffdXZ\ufffd\ufffd^\ufffdd\ufffd/\ufffd\ufffd+\ufffdA\nThis should be the minimum required for encryption of the mail while in storage.
"},{"location":"config/security/rspamd/","title":"Security | Rspamd","text":""},{"location":"config/security/rspamd/#about","title":"About","text":"Rspamd is a \"fast, free and open-source spam filtering system\". DMS integrates Rspamd like any other service. We provide a very simple but easy to maintain setup of Rspamd.
If you want to have a look at the default configuration files for Rspamd that DMS packs, navigate to target/rspamd/ inside the repository. Please consult the section \"The Default Configuration\" section down below for a written overview.
AMD64 vs ARM64
We are currently doing a best-effort installation of Rspamd for ARM64 (from the Debian backports repository for Debian 11). The current version difference as of 23rd Apr 2023: AMD64 is at version 3.5 | ARM64 is at version 3.4.
"},{"location":"config/security/rspamd/#related-environment-variables","title":"Related Environment Variables","text":"The following environment variables are related to Rspamd:
ENABLE_RSPAMDENABLE_RSPAMD_REDISRSPAMD_GREYLISTINGRSPAMD_HFILTERRSPAMD_HFILTER_HOSTNAME_UNKNOWN_SCORERSPAMD_LEARNMOVE_SPAM_TO_JUNKWith these variables, you can enable Rspamd itself and you can enable / disable certain features related to Rspamd.
"},{"location":"config/security/rspamd/#the-default-configuration","title":"The Default Configuration","text":""},{"location":"config/security/rspamd/#mode-of-operation","title":"Mode of Operation","text":"The proxy worker operates in self-scan mode. This simplifies the setup as we do not require a normal worker. You can easily change this though by overriding the configuration by DMS.
DMS does not set a default password for the controller worker. You may want to do that yourself. In setups where you already have an authentication provider in front of the Rspamd webpage, you may want to set the secure_ip option to \"0.0.0.0/0\" for the controller worker to disable password authentication inside Rspamd completely.
When Rspamd is enabled, we implicitly also start an instance of Redis in the container. Redis is configured to persist it's data via RDB snapshots to disk in the directory /var/lib/redis (which is a symbolic link to /var/mail-state/lib-redis/ when ONE_DIR=1 and a volume is mounted to /var/mail-state/). With the volume mount the snapshot will restore the Redis data across container restarts, and provide a way to keep backup.
Redis uses /etc/redis/redis.conf for configuration. We adjust this file when enabling the internal Redis service. If you have an external instance of Redis to use, the internal Redis service can be opt-out via setting the ENV ENABLE_RSPAMD_REDIS=0 (link also details required changes to the DMS rspamd config).
Rspamd provides a web interface, which contains statistics and data Rspamd collects. The interface is enabled by default and reachable on port 11334.
"},{"location":"config/security/rspamd/#dns","title":"DNS","text":"DMS does not supply custom values for DNS servers to Rspamd. If you need to use custom DNS servers, which could be required when using DNS-based black/whitelists, you need to adjust options.inc yourself.
Making DNS Servers Configurable
If you want to see an environment variable (like RSPAMD_DNS_SERVERS) to support custom DNS servers for Rspamd being added to DMS, please raise a feature request issue.
Danger
While we do not provide values for custom DNS servers by default, we set soft_reject_on_timeout = true; by default. This setting will cause a soft reject if a task (presumably a DNS request) timeout takes place.
This setting is enabled to not allow spam to proceed just because DNS requests did not succeed. It could deny legitimate e-mails to pass though too in case your DNS setup is incorrect or not functioning properly.
"},{"location":"config/security/rspamd/#modules","title":"Modules","text":"You can find a list of all Rspamd modules on their website.
"},{"location":"config/security/rspamd/#disabled-by-default","title":"Disabled By Default","text":"DMS disables certain modules (clickhouse, elastic, neural, reputation, spamassassin, url_redirector, metric_exporter) by default. We believe these are not required in a standard setup, and they would otherwise needlessly use system resources.
"},{"location":"config/security/rspamd/#anti-virus-clamav","title":"Anti-Virus (ClamAV)","text":"You can choose to enable ClamAV, and Rspamd will then use it to check for viruses. Just set the environment variable ENABLE_CLAMAV=1.
The RBL module is enabled by default. As a consequence, Rspamd will perform DNS lookups to a variety of blacklists. Whether an RBL or a DNSBL is queried depends on where the domain name was obtained: RBL servers are queried with IP addresses extracted from message headers, DNSBL server are queried with domains and IP addresses extracted from the message body [source].
Rspamd and DNS Block Lists
When the RBL module is enabled, Rspamd will do a variety of DNS requests to (amongst other things) DNSBLs. There are a variety of issues involved when using DNSBLs. Rspamd will try to mitigate some of them by properly evaluating all return codes. This evaluation is a best effort though, so if the DNSBL operators change or add return codes, it may take a while for Rspamd to adjust as well.
If you want to use DNSBLs, try to use your own DNS resolver and make sure it is set up correctly, i.e. it should be a non-public & recursive resolver. Otherwise, you might not be able (see this Spamhaus post) to make use of the block lists.
"},{"location":"config/security/rspamd/#providing-custom-settings-overriding-settings","title":"Providing Custom Settings & Overriding Settings","text":"DMS brings sane default settings for Rspamd. They are located at /etc/rspamd/local.d/ inside the container (or target/rspamd/local.d/ in the repository).
What is docker-data/dms/config/?
If you want to overwrite the default settings and / or provide your own settings, you can place files at docker-data/dms/config/rspamd/override.d/ (a directory that is linked to /etc/rspamd/override.d/, if it exists) to override Rspamd and DMS default settings.
Clashing Overrides
Note that when also using the rspamd-commands file, files in override.d may be overwritten in case you adjust them manually and with the help of the file.
DMS provides the ability to do simple adjustments to Rspamd modules with the help of a single file. Just place a file called custom-commands.conf into docker-data/dms/config/rspamd/. If this file is present, DMS will evaluate it. The structure is very simple. Each line in the file looks like this:
COMMAND ARGUMENT1 ARGUMENT2 ARGUMENT3\nwhere COMMAND can be:
disable-module: disables the module with name ARGUMENT1enable-module: explicitly enables the module with name ARGUMENT1set-option-for-module: sets the value for option ARGUMENT2 to ARGUMENT3 inside module ARGUMENT1set-option-for-controller: set the value of option ARGUMENT1 to ARGUMENT2 for the controller workerset-option-for-proxy: set the value of option ARGUMENT1 to ARGUMENT2 for the proxy workerset-common-option: set the option ARGUMENT1 that defines basic Rspamd behaviour to value ARGUMENT2add-line: this will add the complete line after ARGUMENT1 (with all characters) to the file /etc/rspamd/override.d/<ARGUMENT1>An Example Is Shown Down Below
File Names & Extensions
For command 1 - 3, we append the .conf suffix to the module name to get the correct file name automatically. For commands 4 - 6, the file name is fixed (you don't even need to provide it). For command 7, you will need to provide the whole file name (including the suffix) yourself!
You can also have comments (the line starts with #) and blank lines in custom-commands.conf - they are properly handled and not evaluated.
Adjusting Modules This Way
These simple commands are meant to give users the ability to easily alter modules and their options. As a consequence, they are not powerful enough to enable multi-line adjustments. If you need to do something more complex, we advise to do that manually!
"},{"location":"config/security/rspamd/#examples-advanced-configuration","title":"Examples & Advanced Configuration","text":""},{"location":"config/security/rspamd/#a-very-basic-configuration","title":"A Very Basic Configuration","text":"You want to start using Rspamd? Rspamd is disabled by default, so you need to set the following environment variables:
ENABLE_RSPAMD=1\nENABLE_OPENDKIM=0\nENABLE_OPENDMARC=0\nENABLE_POLICYD_SPF=0\nENABLE_AMAVIS=0\nENABLE_SPAMASSASSIN=0\nThis will enable Rspamd and disable services you don't need when using Rspamd.
"},{"location":"config/security/rspamd/#adjusting-and-extending-the-very-basic-configuration","title":"Adjusting and Extending The Very Basic Configuration","text":"Rspamd is running, but you want or need to adjust it? First, create a file named custom-commands.conf under docker-data/dms/config/rspamd (which translates to /tmp/docker-mailserver/rspamd/ inside the container). Then add you changes:
set-option-for-controller secure_ip \"0.0.0.0/0\".set-option-for-module classifier-bayes autolearn true.disable-module chartable.Here is what the file looks like in the end:
# See 1.\n# ATTENTION: this disables authentication on the website - make sure you know what you're doing!\nset-option-for-controller secure_ip \"0.0.0.0/0\"\n\n# See 2.\nset-option-for-module classifier-bayes autolearn true\n\n# See 3.\ndisable-module chartable\nThere is a dedicated section for setting up DKIM with Rspamd in our documentation.
"},{"location":"config/security/rspamd/#abusix-integration","title":"Abusix Integration","text":"This subsection gives information about the integration of Abusix, \"a set of blocklists that work as an additional email security layer for your existing mail environment\". The setup is straight-forward and well documented:
<APIKEY> to your private API keyWe recommend mounting the files directly into the container, as they are rather big and not manageable with the modules script. If mounted to the correct location, Rspamd will automatically pick them up.
While Abusix can be integrated into Postfix, Postscreen and a multitude of other software, we recommend integrating Abusix only into a single piece of software running in your mail server - everything else would be excessive and wasting queries. Moreover, we recommend the integration into suitable filtering software and not Postfix itself, as software like Postscreen or Rspamd can properly evaluate the return codes and other configuration.
"},{"location":"config/security/ssl/","title":"Security | TLS (aka SSL)","text":"There are multiple options to enable SSL (via SSL_TYPE):
After installation, you can test your setup with:
checktls.comtestssl.shExposure of DNS labels through Certificate Transparency
All public Certificate Authorities (CAs) are required to log certificates they issue publicly via Certificate Transparency. This helps to better establish trust.
When using a public CA for certificates used in private networks, be aware that the associated DNS labels in the certificate are logged publicly and easily searchable. These logs are append only, you cannot redact this information.
You could use a wildcard certificate. This avoids accidentally leaking information to the internet, but keep in mind the potential security risks of wildcard certs.
"},{"location":"config/security/ssl/#the-fqdn","title":"The FQDN","text":"An FQDN (Fully Qualified Domain Name) such as mail.example.com is required for DMS to function correctly, especially for looking up the correct SSL certificate to use.
mail.example.com will still use user@example.com as the mail address. You do not need a bare domain for that.example.com is also supported.hostname -f will be used to retrieve the FQDN as configured in the below examples.*.example.com) are supported for SSL_TYPE=letsencrypt. Your configured FQDN below may be mail.example.com, and your wildcard certificate provisioned to /etc/letsencrypt/live/example.com which will be checked as a fallback FQDN by DMS.Setting the hostname correctly
Change mail.example.com below to your own FQDN.
# CLI:\ndocker run --hostname mail.example.com\nor
# compose.yaml\nservices:\nmailserver:\nhostname: mail.example.com\nTo enable Let's Encrypt for DMS, you have to:
For your DMS container:
SSL_TYPE=letsencrypt.letsencrypt folder as a volume to /etc/letsencrypt.You don't have to do anything else. Enjoy!
Note
/etc/letsencrypt/live stores provisioned certificates in individual folders named by their FQDN.
Make sure that the entire folder is mounted to DMS as there are typically symlinks from /etc/letsencrypt/live/mail.example.com to /etc/letsencrypt/archive.
Example
Add these additions to the mailserver service in your compose.yaml:
services:\nmailserver:\nhostname: mail.example.com\nenvironment:\n- SSL_TYPE=letsencrypt\nvolumes:\n- /etc/letsencrypt:/etc/letsencrypt\nCertbot provisions certificates to /etc/letsencrypt. Add a volume to store these, so that they can later be accessed by DMS container. You may also want to persist Certbot logs, just in case you need to troubleshoot.
Getting a certificate is this simple! (Referencing: Certbot docker instructions and certonly --standalone mode):
# Requires access to port 80 from the internet, adjust your firewall if needed.\ndocker run --rm -it \\\n-v \"${PWD}/docker-data/certbot/certs/:/etc/letsencrypt/\" \\\n-v \"${PWD}/docker-data/certbot/logs/:/var/log/letsencrypt/\" \\\n-p 80:80 \\\ncertbot/certbot certonly --standalone -d mail.example.com\nAdd a volume for DMS that maps the local certbot/certs/ folder to the container path /etc/letsencrypt/.
Example
Add these additions to the mailserver service in your compose.yaml:
services:\nmailserver:\nhostname: mail.example.com\nenvironment:\n- SSL_TYPE=letsencrypt\nvolumes:\n- ./docker-data/certbot/certs/:/etc/letsencrypt\nThe certificate setup is complete, but remember it will expire. Consider automating renewals.
Renewing Certificates
When running the above certonly --standalone snippet again, the existing certificate is renewed if it would expire within 30 days.
Alternatively, Certbot can look at all the certificates it manages, and only renew those nearing their expiry via the renew command:
# This will need access to port 443 from the internet, adjust your firewall if needed.\ndocker run --rm -it \\\n-v \"${PWD}/docker-data/certbot/certs/:/etc/letsencrypt/\" \\\n-v \"${PWD}/docker-data/certbot/logs/:/var/log/letsencrypt/\" \\\n-p 80:80 \\\n-p 443:443 \\\ncertbot/certbot renew\nThis process can also be automated via cron or systemd timers.
Using a different ACME CA
Certbot does support alternative certificate providers via the --server option. In most cases you'll want to use the default Let's Encrypt.
certbot-dns-cloudflare with Docker","text":"If you are unable get a certificate via the HTTP-01 (port 80) or TLS-ALPN-01 (port 443) challenge types, the DNS-01 challenge can be useful (this challenge can additionally issue wildcard certificates). This guide shows how to use the DNS-01 challenge with Cloudflare as your DNS provider.
Obtain a Cloudflare API token:
Click \"Create Token\", and choose the Edit zone DNS template (Certbot requires the ZONE:DNS:Edit permission).
Only include the necessary Zone resource configuration
Be sure to configure \"Zone Resources\" section on this page to Include -> Specific zone -> <your zone here>.
This restricts the API token to only this zone (domain) which is an important security measure.
Store the API token you received in a file cloudflare.ini with content:
dns_cloudflare_api_token = YOUR_CLOUDFLARE_TOKEN_HERE\nAs this is sensitive data, you should restrict access to it with chmod 600 and chown 0:0.
docker-data/certbot/secrets/.Your compose.yaml should include the following:
services:\nmailserver:\nenvironments:\n# Set SSL certificate type.\n- SSL_TYPE=letsencrypt\nvolumes:\n# Mount the cert folder generated by Certbot:\n- ./docker-data/certbot/certs/:/etc/letsencrypt/:ro\n\ncertbot-cloudflare:\nimage: certbot/dns-cloudflare:latest\ncommand: certonly --dns-cloudflare --dns-cloudflare-credentials /run/secrets/cloudflare-api-token -d mail.example.com\nvolumes:\n- ./docker-data/certbot/certs/:/etc/letsencrypt/\n- ./docker-data/certbot/logs/:/var/log/letsencrypt/\nsecrets:\n- cloudflare-api-token\n\n# Docs: https://docs.docker.com/engine/swarm/secrets/#use-secrets-in-compose\n# WARNING: In compose configs without swarm, the long syntax options have no effect,\n# Ensure that you properly `chmod 600` and `chown 0:0` the file on disk. Effectively treated as a bind mount.\nsecrets:\ncloudflare-api-token:\nfile: ./docker-data/certbot/secrets/cloudflare.ini\nAlternative using the docker run command (secrets feature is not available):
docker run \\\n--volume \"${PWD}/docker-data/certbot/certs/:/etc/letsencrypt/\" \\\n--volume \"${PWD}/docker-data/certbot/logs/:/var/log/letsencrypt/\" \\\n--volume \"${PWD}/docker-data/certbot/secrets/:/tmp/secrets/certbot/\"\ncertbot/dns-cloudflare \\\ncertonly --dns-cloudflare --dns-cloudflare-credentials /tmp/secrets/certbot/cloudflare.ini -d mail.example.com\nRun the service to provision a certificate:
docker compose run certbot-cloudflare\nYou should see the following log output:
Saving debug log to /var/log/letsencrypt/letsencrypt. log | Requesting a certificate for mail.example.com\nWaiting 10 seconds for DNS changes to propagate\nSuccessfully received certificate.\nCertificate is saved at: /etc/letsencrypt/live/mail.example.com/fullchain.pem\nKey is saved at: /etc/letsencrypt/live/mail.example.com/privkey.pem\nThis certificate expires on YYYY-MM-DD.\nThese files will be updated when the certificate renews.\nNEXT STEPS:\n- The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal structions.\nAfter completing the steps above, your certificate should be ready to use.
Renewing a certificate (Optional)We've only demonstrated how to provision a certificate, but it will expire in 90 days and need to be renewed before then.
In the following example, add a new service (certbot-cloudflare-renew) into compose.yaml that will handle certificate renewals:
services:\ncertbot-cloudflare-renew:\nimage: certbot/dns-cloudflare:latest\ncommand: renew --dns-cloudflare --dns-cloudflare-credentials /run/secrets/cloudflare-api-token\nvolumes:\n- ./docker-data/certbot/certs/:/etc/letsencrtypt/\n- ./docker-data/certbot/logs/:/var/log/letsencrypt/\nsecrets:\n- cloudflare-api-token\nYou can manually run this service to renew the cert within 90 days:
docker compose run certbot-cloudflare-renew\nYou should see the following output (The following log was generated with --dry-run options)
Saving debug log to /var/log/letsencrypt/letsencrypt.log\n\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\nProcessing /etc/letsencrypt/renewal/mail.example.com.conf\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\nAccount registered.\nSimulating renewal of an existing certificate for mail.example.com\nWaiting 10 seconds for DNS changes to propagate\n\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\nCongratulations, all simulated renewals succeeded:\n /etc/letsencrypt/live/mail.example.com/fullchain.pem (success)\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\nIt is recommended to automate this renewal via a task scheduler like a systemd timer or in crontab (crontab example: Checks every day if the certificate should be renewed)
0 0 * * * docker compose -f PATH_TO_YOUR_DOCKER_COMPOSE_YML up certbot-cloudflare-renew\nnginx-proxy and acme-companion with Docker","text":"If you are running a web server already, port 80 will be in use which Certbot requires. You could use the Certbot --webroot feature, but it is more common to leverage a reverse proxy that manages the provisioning and renewal of certificates for your services automatically.
In the following example, we show how DMS can be run alongside the docker containers nginx-proxy and acme-companion (Referencing: acme-companion documentation):
Start the reverse proxy (nginx-proxy):
docker run --detach \\\n--name nginx-proxy \\\n--restart always \\\n--publish 80:80 \\\n--publish 443:443 \\\n--volume \"${PWD}/docker-data/nginx-proxy/html/:/usr/share/nginx/html/\" \\\n--volume \"${PWD}/docker-data/nginx-proxy/vhost.d/:/etc/nginx/vhost.d/\" \\\n--volume \"${PWD}/docker-data/acme-companion/certs/:/etc/nginx/certs/:ro\" \\\n--volume '/var/run/docker.sock:/tmp/docker.sock:ro' \\\nnginxproxy/nginx-proxy\nThen start the certificate provisioner (acme-companion), which will provide certificates to nginx-proxy:
# Inherit `nginx-proxy` volumes via `--volumes-from`, but make `certs/` writeable:\ndocker run --detach \\\n--name nginx-proxy-acme \\\n--restart always \\\n--volumes-from nginx-proxy \\\n--volume \"${PWD}/docker-data/acme-companion/certs/:/etc/nginx/certs/:rw\" \\\n--volume \"${PWD}/docker-data/acme-companion/acme-state/:/etc/acme.sh/\" \\\n--volume '/var/run/docker.sock:/var/run/docker.sock:ro' \\\n--env 'DEFAULT_EMAIL=admin@example.com' \\\nnginxproxy/acme-companion\nStart the rest of your web server containers as usual.
Start a dummy container to provision certificates for your FQDN (eg: mail.example.com). acme-companion will detect the container and generate a Let's Encrypt certificate for your domain, which can be used by DMS:
docker run --detach \\\n--name webmail \\\n--env 'VIRTUAL_HOST=mail.example.com' \\\n--env 'LETSENCRYPT_HOST=mail.example.com' \\\n--env 'LETSENCRYPT_EMAIL=admin@example.com' \\\nnginx\nYou may want to add --env LETSENCRYPT_TEST=true to the above while testing, to avoid the Let's Encrypt certificate generation rate limits.
Make sure your mount path to the letsencrypt certificates directory is correct. Edit your compose.yaml for the mailserver service to have volumes added like below:
volumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/mail-state/:/var/mail-state/\n- ./docker-data/dms/config/:/tmp/docker-mailserver/\n- ./docker-data/acme-companion/certs/:/etc/letsencrypt/live/:ro\nThen from the compose.yaml project directory, run: docker compose up -d mailserver.
nginx-proxy and acme-companion with docker-compose","text":"The following example is the basic setup you need for using nginx-proxy and acme-companion with DMS (Referencing: acme-companion documentation):
compose.yaml You should have an existing compose.yaml with a mailserver service. Below are the modifications to add for integrating with nginx-proxy and acme-companion services:
services:\n# Add the following `environment` and `volumes` to your existing `mailserver` service:\nmailserver:\nenvironment:\n# SSL_TYPE: Uses the `letsencrypt` method to find mounted certificates.\n# VIRTUAL_HOST: The FQDN that `nginx-proxy` will configure itself to handle for HTTP[S] connections.\n# LETSENCRYPT_HOST: The FQDN for a certificate that `acme-companion` will provision and renew.\n- SSL_TYPE=letsencrypt\n- VIRTUAL_HOST=mail.example.com\n- LETSENCRYPT_HOST=mail.example.com\nvolumes:\n- ./docker-data/acme-companion/certs/:/etc/letsencrypt/live/:ro\n\n# If you don't yet have your own `nginx-proxy` and `acme-companion` setup,\n# here is an example you can use:\nreverse-proxy:\nimage: nginxproxy/nginx-proxy\ncontainer_name: nginx-proxy\nrestart: always\nports:\n# Port 80: Required for HTTP-01 challenges to `acme-companion`.\n# Port 443: Only required for containers that need access over HTTPS. TLS-ALPN-01 challenge not supported.\n- \"80:80\"\n- \"443:443\"\nvolumes:\n# `certs/`: Managed by the `acme-companion` container (_read-only_).\n# `docker.sock`: Required to interact with containers via the Docker API.\n- ./docker-data/nginx-proxy/html/:/usr/share/nginx/html/\n- ./docker-data/nginx-proxy/vhost.d/:/etc/nginx/vhost.d/\n- ./docker-data/acme-companion/certs/:/etc/nginx/certs/:ro\n- /var/run/docker.sock:/tmp/docker.sock:ro\n\nacme-companion:\nimage: nginxproxy/acme-companion\ncontainer_name: nginx-proxy-acme\nrestart: always\nenvironment:\n# When `volumes_from: [nginx-proxy]` is not supported,\n# reference the _reverse-proxy_ `container_name` here:\n- NGINX_PROXY_CONTAINER=nginx-proxy\nvolumes:\n# `html/`: Write ACME HTTP-01 challenge files that `nginx-proxy` will serve.\n# `vhost.d/`: To enable web access via `nginx-proxy` to HTTP-01 challenge files.\n# `certs/`: To store certificates and private keys.\n# `acme-state/`: To persist config and state for the ACME provisioner (`acme.sh`).\n# `docker.sock`: Required to interact with containers via the Docker API.\n- ./docker-data/nginx-proxy/html/:/usr/share/nginx/html/\n- ./docker-data/nginx-proxy/vhost.d/:/etc/nginx/vhost.d/\n- ./docker-data/acme-companion/certs/:/etc/nginx/certs/:rw\n- ./docker-data/acme-companion/acme-state/:/etc/acme.sh/\n- /var/run/docker.sock:/var/run/docker.sock:ro\nOptional ENV vars worth knowing about
Per container ENV that acme-companion will detect to override default provisioning settings:
LETSENCRYPT_TEST=true: Recommended during initial setup. Otherwise the default production endpoint has a rate limit of 5 duplicate certificates per week. Overrides ACME_CA_URI to use the Let's Encrypt staging endpoint.LETSENCRYPT_EMAIL: For when you don't use DEFAULT_EMAIL on acme-companion, or want to assign a different email contact for this container.LETSENCRYPT_KEYSIZE: Allows you to configure the type (RSA or ECDSA) and size of the private key for your certificate. Default is RSA 4096.LETSENCRYPT_RESTART_CONTAINER=true: When the certificate is renewed, the entire container will be restarted to ensure the new certificate is used.acme-companion ENV for default settings that apply to all containers using LETSENCRYPT_HOST:
DEFAULT_EMAIL: An email address that the CA (eg: Let's Encrypt) can contact you about expiring certificates, failed renewals, or for account recovery. You may want to use an email address not handled by your mail server to ensure deliverability in the event your mail server breaks.CERTS_UPDATE_INTERVAL: If you need to adjust the frequency to check for renewals. 3600 seconds (1 hour) by default.DEBUG=1: Should be helpful when troubleshooting provisioning issues from acme-companion logs.ACME_CA_URI: Useful in combination with CA_BUNDLE to use a private CA. To change the default Let's Encrypt endpoint to the staging endpoint, use https://acme-staging-v02.api.letsencrypt.org/directory.CA_BUNDLE: If you want to use a private CA instead of Let's Encrypt.Alternative to required ENV on mailserver service
While you will still need both nginx-proxy and acme-companion containers, you can manage certificates without adding ENV vars to containers. Instead the ENV is moved into a file and uses the acme-companion feature Standalone certificates.
This requires adding another shared volume between nginx-proxy and acme-companion:
services:\nreverse-proxy:\nvolumes:\n- ./docker-data/nginx-proxy/conf.d/:/etc/nginx/conf.d/\n\nacme-companion:\nvolumes:\n- ./docker-data/nginx-proxy/conf.d/:/etc/nginx/conf.d/\n- ./docker-data/acme-companion/standalone.sh:/app/letsencrypt_user_data:ro\nacme-companion mounts a shell script (standalone.sh), which defines variables to customize certificate provisioning:
# A list IDs for certificates to provision:\nLETSENCRYPT_STANDALONE_CERTS=('mail')\n\n# Each ID inserts itself into the standard `acme-companion` supported container ENV vars below.\n# The LETSENCRYPT_<ID>_HOST var is a list of FQDNs to provision a certificate for as the SAN field:\nLETSENCRYPT_mail_HOST=('mail.example.com')\n\n# Optional variables:\nLETSENCRYPT_mail_TEST=true\nLETSENCRYPT_mail_EMAIL='admin@example.com'\n# RSA-4096 => `4096`, ECDSA-256 => `ec-256`:\nLETSENCRYPT_mail_KEYSIZE=4096\nUnlike with the equivalent ENV for containers, changes to this file will not be detected automatically. You would need to wait until the next renewal check by acme-companion (every hour by default), restart acme-companion, or manually invoke the service loop:
docker exec nginx-proxy-acme /app/signal_le_service
Version 6.2 and later of the Synology NAS DSM OS now come with an interface to generate and renew letencrypt certificates. Navigation into your DSM control panel and go to Security, then click on the tab Certificate to generate and manage letsencrypt certificates.
Amongst other things, you can use these to secure your mail server. DSM locates the generated certificates in a folder below /usr/syno/etc/certificate/_archive/.
Navigate to that folder and note the 6 character random folder name of the certificate you'd like to use. Then, add the following to your compose.yaml declaration file:
volumes:\n- /usr/syno/etc/certificate/_archive/<your-folder>/:/tmp/dms/custom-certs/\nenvironment:\n- SSL_TYPE=manual\n- SSL_CERT_PATH=/tmp/dms/custom-certs/fullchain.pem\n- SSL_KEY_PATH=/tmp/dms/custom-certs/privkey.pem\nDSM-generated letsencrypt certificates get auto-renewed every three months.
"},{"location":"config/security/ssl/#caddy","title":"Caddy","text":"For Caddy v2 you can specify the key_type in your server's global settings, which would end up looking something like this if you're using a Caddyfile:
{\n debug\n admin localhost:2019\n http_port 80\n https_port 443\n default_sni example.com\n key_type rsa4096\n}\nIf you are instead using a json config for Caddy v2, you can set it in your site's TLS automation policies:
Caddy v2 JSON example snippet{\n\"apps\": {\n\"http\": {\n\"servers\": {\n\"srv0\": {\n\"listen\": [\n\":443\"\n],\n\"routes\": [\n{\n\"match\": [\n{\n\"host\": [\n\"mail.example.com\",\n]\n}\n],\n\"handle\": [\n{\n\"handler\": \"subroute\",\n\"routes\": [\n{\n\"handle\": [\n{\n\"body\": \"\",\n\"handler\": \"static_response\"\n}\n]\n}\n]\n}\n],\n\"terminal\": true\n},\n]\n}\n}\n},\n\"tls\": {\n\"automation\": {\n\"policies\": [\n{\n\"subjects\": [\n\"mail.example.com\",\n],\n\"key_type\": \"rsa2048\",\n\"issuer\": {\n\"email\": \"admin@example.com\",\n\"module\": \"acme\"\n}\n},\n{\n\"issuer\": {\n\"email\": \"admin@example.com\",\n\"module\": \"acme\"\n}\n}\n]\n}\n}\n}\n}\nThe generated certificates can then be mounted:
volumes:\n- ${CADDY_DATA_DIR}/certificates/acme-v02.api.letsencrypt.org-directory/mail.example.com/mail.example.com.crt:/etc/letsencrypt/live/mail.example.com/fullchain.pem\n- ${CADDY_DATA_DIR}/certificates/acme-v02.api.letsencrypt.org-directory/mail.example.com/mail.example.com.key:/etc/letsencrypt/live/mail.example.com/privkey.pem\nTraefik is an open-source application proxy using the ACME protocol. Traefik can request certificates for domains and subdomains, and it will take care of renewals, challenge negotiations, etc. We strongly recommend to use Traefik's major version 2.
Traefik's storage format is natively supported if the acme.json store is mounted into the container at /etc/letsencrypt/acme.json. The file is also monitored for changes and will trigger a reload of the mail services (Postfix and Dovecot).
Wildcard certificates are supported. If your FQDN is mail.example.com and your wildcard certificate is *.example.com, add the ENV: SSL_DOMAIN=example.com.
DMS will select it's certificate from acme.json checking these ENV for a matching FQDN (in order of priority):
${SSL_DOMAIN}${HOSTNAME}${DOMAINNAME}This setup only comes with one caveat: The domain has to be configured on another service for Traefik to actually request it from Let's Encrypt, i.e. Traefik will not issue a certificate without a service / router demanding it.
Example CodeHere is an example setup for docker-compose:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\nhostname: mail.example.com\nvolumes:\n- ./docker-data/traefik/acme.json:/etc/letsencrypt/acme.json:ro\nenvironment:\nSSL_TYPE: letsencrypt\nSSL_DOMAIN: mail.example.com\n# for a wildcard certificate, use\n# SSL_DOMAIN: example.com\n\nreverse-proxy:\nimage: docker.io/traefik:latest #v2.5\ncontainer_name: docker-traefik\nports:\n- \"80:80\"\n- \"443:443\"\ncommand:\n- --providers.docker\n- --entrypoints.http.address=:80\n- --entrypoints.http.http.redirections.entryPoint.to=https\n- --entrypoints.http.http.redirections.entryPoint.scheme=https\n- --entrypoints.https.address=:443\n- --entrypoints.https.http.tls.certResolver=letsencrypt\n- --certificatesresolvers.letsencrypt.acme.email=admin@example.com\n- --certificatesresolvers.letsencrypt.acme.storage=/acme.json\n- --certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=http\nvolumes:\n- ./docker-data/traefik/acme.json:/acme.json\n- /var/run/docker.sock:/var/run/docker.sock:ro\n\nwhoami:\nimage: docker.io/traefik/whoami:latest\nlabels:\n- \"traefik.http.routers.whoami.rule=Host(`mail.example.com`)\"\nWarning
Use self-signed certificates only for testing purposes!
This feature requires you to provide the following files into your docker-data/dms/config/ssl/ directory (internal location: /tmp/docker-mailserver/ssl/):
<FQDN>-key.pem<FQDN>-cert.pemdemoCA/cacert.pemWhere <FQDN> is the FQDN you've configured for your DMS container.
Add SSL_TYPE=self-signed to your DMS environment variables. Postfix and Dovecot will be configured to use the provided certificate (.pem files above) during container startup.
One way to generate self-signed certificates is with Smallstep's step CLI. This is exactly what DMS does for creating test certificates.
For example with the FQDN mail.example.test, you can generate the required files by running:
#! /bin/sh\nmkdir -p demoCA\n\nstep certificate create \"Smallstep Root CA\" \"demoCA/cacert.pem\" \"demoCA/cakey.pem\" \\\n--no-password --insecure \\\n--profile root-ca \\\n--not-before \"2021-01-01T00:00:00+00:00\" \\\n--not-after \"2031-01-01T00:00:00+00:00\" \\\n--san \"example.test\" \\\n--san \"mail.example.test\" \\\n--kty RSA --size 2048\n\nstep certificate create \"Smallstep Leaf\" mail.example.test-cert.pem mail.example.test-key.pem \\\n--no-password --insecure \\\n--profile leaf \\\n--ca \"demoCA/cacert.pem\" \\\n--ca-key \"demoCA/cakey.pem\" \\\n--not-before \"2021-01-01T00:00:00+00:00\" \\\n--not-after \"2031-01-01T00:00:00+00:00\" \\\n--san \"example.test\" \\\n--san \"mail.example.test\" \\\n--kty RSA --size 2048\nIf you'd rather not install the CLI tool locally to run the step commands above; you can save the script above to a file such as generate-certs.sh (and make it executable chmod +x generate-certs.sh) in a directory that you want the certs to be placed (eg: docker-data/dms/custom-certs/), then use docker to run that script in a container:
# '--user' is to keep ownership of the files written to\n# the local volume to use your systems User and Group ID values.\ndocker run --rm -it \\\n--user \"$(id -u):$(id -g)\" \\\n--volume \"${PWD}/docker-data/dms/custom-certs/:/tmp/step-ca/\" \\\n--workdir \"/tmp/step-ca/\" \\\n--entrypoint \"/tmp/step-ca/generate-certs.sh\" \\\nsmallstep/step-ca\nYou can also provide your own certificate files. Add these entries to your compose.yaml:
volumes:\n- ./docker-data/dms/custom-certs/:/tmp/dms/custom-certs/:ro\nenvironment:\n- SSL_TYPE=manual\n# Values should match the file paths inside the container:\n- SSL_CERT_PATH=/tmp/dms/custom-certs/public.crt\n- SSL_KEY_PATH=/tmp/dms/custom-certs/private.key\nThis will mount the path where your certificate files reside locally into the read-only container folder: /tmp/dms/custom-certs.
The local and internal paths may be whatever you prefer, so long as both SSL_CERT_PATH and SSL_KEY_PATH point to the correct internal file paths. The certificate files may also be named to your preference, but should be PEM encoded.
SSL_ALT_CERT_PATH and SSL_ALT_KEY_PATH are additional ENV vars to support a 2nd certificate as a fallback. Commonly known as hybrid or dual certificate support. This is useful for using a modern ECDSA as your primary certificate, and RSA as your fallback for older connections. They work in the same manner as the non-ALT versions.
Info
You may have to restart DMS once the certificates change.
"},{"location":"config/security/ssl/#testing-a-certificate-is-valid","title":"Testing a Certificate is Valid","text":"From your host:
docker exec mailserver openssl s_client \\\n-connect 0.0.0.0:25 \\\n-starttls smtp \\\n-CApath /etc/ssl/certs/\nOr:
docker exec mailserver openssl s_client \\\n-connect 0.0.0.0:143 \\\n-starttls imap \\\n-CApath /etc/ssl/certs/\nAnd you should see the certificate chain, the server certificate and: Verify return code: 0 (ok)
In addition, to verify certificate dates:
docker exec mailserver openssl s_client \\\n-connect 0.0.0.0:25 \\\n-starttls smtp \\\n-CApath /etc/ssl/certs/ \\\n2>/dev/null | openssl x509 -noout -dates\nWarning
Not recommended for purposes other than testing.
Add this to docker-data/dms/config/dovecot.cf:
ssl = yes\ndisable_plaintext_auth=no\nThese options in conjunction mean:
If you have another source for SSL/TLS certificates you can import them into the server via an external script. The external script can be found here: external certificate import script.
This is a community contributed script, and in most cases you will have better support via our Change Detection service (automatic for SSL_TYPE of manual and letsencrypt) - Unless you're using LDAP which disables the service.
Script Compatibility
/etc/dms/tls/cert and /etc/dms/tls/key intended for internal use only.fullchain.key + privkey.pem as your mounted file names. That may not align with your provisioning method.ALT fallback certificates (for supporting dual/hybrid, RSA + ECDSA).The steps to follow are these:
./docker-data/dms/custom-certs/ (volume mounted to: /tmp/ssl/)fullchain.key and privkey.pem./docker-data/dms/config/ (volume mounted to: /tmp/docker-mailserver/)chmod +x tomav-renew-certs.sh)docker exec mailserver /tmp/docker-mailserver/tomav-renew-certs.shIf an error occurs the script will inform you. If not you will see both postfix and dovecot restart.
After the certificates have been loaded you can check the certificate:
openssl s_client \\\n-servername mail.example.com \\\n-connect 192.168.0.72:465 \\\n2>/dev/null | openssl x509\n\n# or\n\nopenssl s_client \\\n-servername mail.example.com \\\n-connect mail.example.com:465 \\\n2>/dev/null | openssl x509\nOr you can check how long the new certificate is valid with commands like:
export SITE_URL=\"mail.example.com\"\nexport SITE_IP_URL=\"192.168.0.72\" # can also use `mail.example.com`\nexport SITE_SSL_PORT=\"993\" # imap port dovecot\n\n##works: check if certificate will expire in two weeks\n#2 weeks is 1209600 seconds\n#3 weeks is 1814400\n#12 weeks is 7257600\n#15 weeks is 9072000\n\ncertcheck_2weeks=`openssl s_client -connect ${SITE_IP_URL}:${SITE_SSL_PORT} \\\n-servername ${SITE_URL} 2> /dev/null | openssl x509 -noout -checkend 1209600`\n\n####################################\n#notes: output could be either:\n#Certificate will not expire\n#Certificate will expire\n####################\nWhat does the script that imports the certificates do:
/tmp/ssl.You can of course run the script by cron once a week or something. In that way you could automate cert renewal. If you do so it is probably wise to run an automated check on certificate expiry as well. Such a check could look something like this:
# This script is run inside docker-mailserver via 'docker exec ...', using the 'mail' command to send alerts.\n## code below will alert if certificate expires in less than two weeks\n## please adjust varables!\n## make sure the 'mail -s' command works! Test!\n\nexport SITE_URL=\"mail.example.com\"\nexport SITE_IP_URL=\"192.168.2.72\" # can also use `mail.example.com`\nexport SITE_SSL_PORT=\"993\" # imap port dovecot\n# Below can be from a different domain; like your personal email, not handled by this docker-mailserver:\nexport ALERT_EMAIL_ADDR=\"external-account@gmail.com\"\n\ncertcheck_2weeks=`openssl s_client -connect ${SITE_IP_URL}:${SITE_SSL_PORT} \\\n-servername ${SITE_URL} 2> /dev/null | openssl x509 -noout -checkend 1209600`\n\n####################################\n#notes: output can be\n#Certificate will not expire\n#Certificate will expire\n####################\n\n#echo \"certcheck 2 weeks gives $certcheck_2weeks\"\n\n##automated check you might run by cron or something\n## does the certificate expire within two weeks?\n\nif [ \"$certcheck_2weeks\" = \"Certificate will not expire\" ]; then\necho \"all is well, certwatch 2 weeks says $certcheck_2weeks\"\nelse\necho \"Cert seems to be expiring pretty soon, within two weeks: $certcheck_2weeks\"\necho \"we will send an alert email and log as well\"\nlogger Certwatch: cert $SITE_URL will expire in two weeks\n echo \"Certwatch: cert $SITE_URL will expire in two weeks\" | mail -s \"cert $SITE_URL expires in two weeks \" $ALERT_EMAIL_ADDR\nfi\nBy default DMS uses ffdhe4096 from IETF RFC 7919. These are standardized pre-defined DH groups and the only available DH groups for TLS 1.3. It is discouraged to generate your own DH parameters as it is often less secure.
Despite this, if you must use non-standard DH parameters or you would like to swap ffdhe4096 for a different group (eg ffdhe2048); Add your own PEM encoded DH params file via a volume to /tmp/docker-mailserver/dhparams.pem. This will replace DH params for both Dovecot and Postfix services during container startup.
Prefer ports with Implicit TLS ports, they're more secure than ports using Explicit TLS, and if you use a Reverse Proxy should be less hassle.
"},{"location":"config/security/understanding-the-ports/#overview-of-email-ports","title":"Overview of Email Ports","text":"Protocol Explicit TLS1 Implicit TLS Purpose Enabled by Default ESMTP 25 N/A Transfer2 Yes ESMTP 587 4653 Submission Yes POP3 110 995 Retrieval No IMAP4 143 993 Retrieval YesSTARTTLS. On ports 110, 143 and 587, DMS will reject a connection that cannot be secured. Port 25 is required to support insecure connections.There is a common misconception of this port due to it's history detailed by various communities and blogs articles on the topic (including by popular mail relay services).
Port 465 was briefly assigned the role of SMTPS in 1997 as an secure alternative to Port 25 between MTA exchanges. Then RFC 2487 (STARTTLS) while still in a draft status in late 1998 had IANA revoke the SMTPS assignment. The draft history was modified to exclude all mention of port 465 and SMTPS.
In 2018 RFC 8314 was published which revives Port 465 as an Implicit TLS alternative to Port 587 for mail submission. It details very clearly that gaining adoption of 465 as the preferred port will take time. IANA reassigned port 465 as the submissions service. Any unofficial usage as SMTPS is legacy and has been for over two decades.
Understand that port 587 is more broadly supported due to this history and that lots of software in that time has been built or configured with that port in mind. STARTTLS is known to have various CVEs discovered even in recent years, do not be misled by any advice implying it should be preferred over implicit TLS. Trust in more official sources, such as the config Postfix has which acknowledges the submissions port (465).
flowchart LR\n subgraph your-server [\"Your Server\"]\n in_25(25) --> server\n in_465(465) --> server\n server((\"docker-mailserver<br/>hello@world.com\"))\n server --- out_25(25)\n server --- out_465(465)\n end\n\n third-party(\"Third-party<br/>(sending you email)\") ---|\"Receive email for<br/>hello@world.com\"| in_25\n\n subgraph clients [\"Clients (MUA)\"]\n mua-client(Thunderbird,<br/>Webmail,<br/>Mutt,<br/>etc)\n mua-service(Backend software<br/>on another server)\n end\n clients ---|\"Send email as<br/>hello@world.com\"| in_465\n\n out_25(25) -->|\"Direct<br/>Delivery\"| tin_25\n out_465(465) --> relay(\"MTA<br/>Relay Server\") --> tin_25(25)\n\n subgraph third-party-server[\"Third-party Server\"]\n third-party-mta(\"MTA<br/>friend@example.com\")\n tin_25(25) --> third-party-mta\n endMail arriving at your server will be processed and stored in a mailbox, or sent outbound to another mail server.
Note
When submitting mail (inbound) to be sent (outbound), this involves two separate connections to negotiate and secure. There may be additional intermediary connections which DMS is not involved in, and thus unable to ensure encrypted transit throughout delivery.
"},{"location":"config/security/understanding-the-ports/#outbound-traffic-on-the-right","title":"Outbound Traffic (On the Right)","text":"Mail being sent from your server is either being relayed through another MTA (eg: SendGrid), or direct to an MTA responsible for an email address (eg: Gmail).
Tip
DMS can function as a relay too, but professional relay services have a trusted reputation (which increases success of delivery).
An MTA with low reputation can affect if mail is treated as junk, or even rejected.
Note
At best, you can only ensure a secure connection between the MTA you directly connect to. The receiving MTA may relay that mail to another MTA (and so forth), each connection may not be enforcing TLS.
"},{"location":"config/security/understanding-the-ports/#explicit-vs-implicit-tls","title":"Explicit vs Implicit TLS","text":""},{"location":"config/security/understanding-the-ports/#explicit-tls-aka-opportunistic-tls-opt-in-encryption","title":"Explicit TLS (aka Opportunistic TLS) - Opt-in Encryption","text":"Communication on these ports begin in cleartext. Upgrading to an encrypted connection must be requested explicitly through the STARTTLS protocol and successfully negotiated.
Sometimes a reverse-proxy is involved, but is misconfigured or lacks support for the STARTTLS negotiation to succeed.
Note
STARTTLS is unsuccessful, mail can be received over an unencrypted connection. You can better secure this port between trusted parties with the addition of MTA-STS, STARTTLS Policy List, DNSSEC and DANE.Warning
STARTTLS continues to have vulnerabilities found (Nov 2021 article), as per RFC 8314 (Section 4.1) you are encouraged to prefer Implicit TLS where possible.
Support for STARTTLS is not always implemented correctly, which can lead to leaking credentials (like a client sending too early) prior to a TLS connection being established. Third-parties such as some ISPs have also been known to intercept the STARTTLS exchange, modifying network traffic to prevent establishing a secure connection.
Communication on these ports are always encrypted (enforced, thus implicit), avoiding the potential risks with STARTTLS (Explicit TLS).
While Explicit TLS can provide the same benefit (when STARTTLS is successfully negotiated), Implicit TLS more reliably avoids concerns with connection manipulation and compatibility.
Todo
This section should provide any related configuration advice, and probably expand on and link to resources about DANE, DNSSEC, MTA-STS and STARTTLS Policy list, with advice on how to configure/setup these added security layers.
Todo
A related section or page on ciphers used may be useful, although less important for users to be concerned about.
"},{"location":"config/security/understanding-the-ports/#tls-connections-for-a-mail-server-compared-to-web-browsers","title":"TLS connections for a Mail Server, compared to web browsers","text":"Unlike with HTTP where a web browser client communicates directly with the server providing a website, a secure TLS connection as discussed below does not provide the equivalent safety that HTTPS does when the transit of email (receiving or sending) is sent through third-parties, as the secure connection is only between two machines, any additional machines (MTAs) between the MUA and the MDA depends on them establishing secure connections between one another successfully.
Other machines that facilitate a connection that generally aren't taken into account can exist between a client and server, such as those where your connection passes through your ISP provider are capable of compromising a cleartext connection through interception.
When refactoring, writing or altering scripts or other files, adhere to these rules:
shellcheck to check your scripts! Your contributions are checked by GitHub Actions too, so you will need to do this. You can lint your work with make lint to check against all targets..editorconfig file./bin/bash instead of /bin/sh in scriptsYou will need to have Docker installed. Navigate into the docs/ directory. Then run:
docker run --rm -it -p 8000:8000 -v \"${PWD}:/docs\" squidfunk/mkdocs-material\nThis serves the documentation on your local machine on port 8000. Each change will be hot-reloaded onto the page you view, just edit, save and look at the result.
This project is Open Source. That means that you can contribute on enhancements, bug fixing or improving the documentation.
"},{"location":"contributing/issues-and-pull-requests/#opening-an-issue","title":"Opening an Issue","text":"Attention
Before opening an issue, read the README carefully, study the docs for your version (maybe latest), the Postfix/Dovecot documentation and your search engine you trust. The issue tracker is not meant to be used for unrelated questions!
When opening an issue, please provide details use case to let the community reproduce your problem. Please start DMS with the environment variable LOG_LEVEL set to debug or trace and paste the output into the issue.
Attention
Use the issue templates to provide the necessary information. Issues which do not use these templates are not worked on and closed.
By raising issues, I agree to these terms and I understand, that the rules set for the issue tracker will help both maintainers as well as everyone to find a solution.
Maintainers take the time to improve on this project and help by solving issues together. It is therefore expected from others to make an effort and comply with the rules.
"},{"location":"contributing/issues-and-pull-requests/#pull-requests","title":"Pull Requests","text":"Motivation
You want to add a feature? Feel free to start creating an issue explaining what you want to do and how you're thinking doing it. Other users may have the same need and collaboration may lead to better results.
"},{"location":"contributing/issues-and-pull-requests/#submit-a-pull-request","title":"Submit a Pull-Request","text":"The development workflow is the following:
git clone --recurse-submodules ... or run git submodule update --init --recursive after you cloned your forkmaster. Please use the pull-request template to provide a minimum of contextual information and make sure to meet the requirements of the checklist.Pull requests are automatically tested against the CI and will be reviewed when tests pass. When your changes are validated, your branch is merged. CI builds the new :edge image immediately and your changes will be includes in the next version release.
Program testing can be used to show the presence of bugs, but never to show their absence!
\u2013 Edsger Wybe Dijkstra
"},{"location":"contributing/tests/#introduction","title":"Introduction","text":"DMS employs a variety of unit and integration tests. All tests and associated configuration is stored in the test/ directory. If you want to change existing functionality or integrate a new feature into DMS, you will probably need to work with our test suite.
Can I use macOS?
We do not support running linting, tests, etc. on macOS at this time. Please use a Linux VM, Debian/Ubuntu is recommended.
"},{"location":"contributing/tests/#about","title":"About","text":"We use BATS (Bash Automated Testing System) and additional support libraries. BATS is very similar to Bash, and one can easily and quickly get an understanding of how tests in a single file are run. A test file template provides a minimal working example for newcomers to look at.
"},{"location":"contributing/tests/#structure","title":"Structure","text":"The test/ directory contains multiple directories. Among them is the bats/ directory (which is the BATS git submodule) and the helper/ directory. The latter is especially interesting because it contains common support functionality used in almost every test. Actual tests are located in test/tests/.
Test suite undergoing refactoring
We are currently in the process of restructuring all of our tests. Tests will be moved into test/tests/parallel/ and new tests should be placed there as well.
There are many functions that aid in writing tests. We urge you to use them! They will not only ease writing a test but they will also do their best to ensure there are no race conditions or other unwanted side effects. To learn about the functions we provide, you can:
test/helper/ directory which contains all files that can (and will) be loaded in test filesWe encourage you to try both of the approaches mentioned above. To make understanding and using the helper functions easy, every function contains detailed documentation comments. Read them carefully!
"},{"location":"contributing/tests/#how-are-tests-run","title":"How Are Tests Run?","text":"Tests are split into two categories:
test/tests/parallel/: Multiple test files are run concurrently to reduce the required time to complete the test suite. A test file will presently run it's own defined test-cases in a sequential order.test/tests/serial/: Each test file is queued up to run sequentially. Tests that are unable to support running concurrently belong here.Parallel tests are further partitioned into smaller sets. If your system has the resources to support running more than one of those sets at a time this is perfectly ok (our CI runs tests by distributing the sets across multiple test runners). Care must be taken not to mix running the serial tests while a parallel set is also running; this is handled for you when using make tests.
To run the test suite, you will need to:
jq and (GNU) parallel (under Ubuntu, use sudo apt-get -y install jq parallel)git submodule update --init --recursive if you haven't already initialized the git submodulesWe use make to run commands.
make build to create or update the local mailserver-testing:ci Docker image (using the projects Dockerfile)make clean testsmake clean generate-accounts test/<TEST NAME WITHOUT .bats SUFFIX>make clean generate-accounts test/<TEST NAME WITHOUT .bats SUFFIX>,<TEST NAME WITHOUT .bats SUFFIX> (just add a , and then immediately write the new test name)make clean generate-accounts tests/parallel/setX where X is the number of the set or make clean generate-accounts tests/serialIf your machine is capable, you can increase the amount of tests that are run simultaneously by prepending the make clean all command with BATS_PARALLEL_JOBS=X (i.e. BATS_PARALLEL_JOBS=X make clean all). This wil speed up the test procedure. You can also run all tests in serial by setting BATS_PARALLEL_JOBS=1 this way.
The default value of BATS_PARALLEL_JOBS is 2. This can be increased if your system has the resources spare to support running more jobs at once to complete the test suite sooner.
Test Output when Running in Parallel
When running tests in parallel (with make clean generate-accounts tests/parallel/setX), BATS will delay outputting the results until completing all test cases within a file.
This likewise delays the reporting of test-case failures. When troubleshooting parallel set tests, you may prefer to run specific tests you're working on serially (as demonstrated in the example below).
When writing tests, ensure that parallel set tests still pass when run in parallel. You need to account for other tests running in parallel that may interfere with your own tests logic.
"},{"location":"contributing/tests/#an-example","title":"An Example","text":"In this example, you've made a change to the Rspamd feature support (or adjusted it's tests). First verify no regressions have been introduced by running it's specific test file:
$ make clean generate-accounts test/rspamd\nrspamd.bats\n \u2713 [Rspamd] Postfix's main.cf was adjusted [12]\n \u2713 [Rspamd] normal mail passes fine [44]\n \u2713 [Rspamd] detects and rejects spam [122]\n \u2713 [Rspamd] detects and rejects virus [189]\nAs your feature work progresses your change for Rspamd also affects ClamAV. As your change now spans more than just the Rspamd test file, you could run multiple test files serially:
$ make clean generate-accounts test/rspamd,clamav\nrspamd.bats\n \u2713 [Rspamd] Postfix's main.cf was adjusted [12]\n \u2713 [Rspamd] normal mail passes fine [44]\n \u2713 [Rspamd] detects and rejects spam [122]\n \u2713 [Rspamd] detects and rejects virus [189]\nclamav.bats\n \u2713 [ClamAV] log files exist at /var/log/mail directory [68]\n \u2713 [ClamAV] should be identified by Amavis [67]\n \u2713 [ClamAV] freshclam cron is enabled [76]\n \u2713 [ClamAV] env CLAMAV_MESSAGE_SIZE_LIMIT is set correctly [63]\n \u2713 [ClamAV] rejects virus [60]\nYou're almost finished with your change before submitting it as a PR. It's a good idea to run the full parallel set those individual tests belong to (especially if you've modified any tests):
$ make clean generate-accounts tests/parallel/set1\ndefault_relay_host.bats\n \u2713 [Relay] (ENV) 'DEFAULT_RELAY_HOST' should configure 'main.cf:relayhost' [88]\nspam_virus/amavis.bats\n \u2713 [Amavis] SpamAssassin integration should be active [1165]\nspam_virus/clamav.bats\n \u2713 [ClamAV] log files exist at /var/log/mail directory [73]\n \u2713 [ClamAV] should be identified by Amavis [67]\n \u2713 [ClamAV] freshclam cron is enabled [76]\n...\nEven better, before opening a PR run the full test suite:
$ make clean tests\n...\nThis example provides you only with a basic example of what a minimal setup could look like. We strongly recommend that you go through the configuration file yourself and adjust everything to your needs. The default compose.yaml can be used for the purpose out-of-the-box, see the Usage chapter.
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\n# Provide the FQDN of your mail server here (Your DNS MX record should point to this value)\nhostname: mail.example.com\nports:\n- \"25:25\"\n- \"465:465\"\n- \"587:587\"\n- \"993:993\"\nvolumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/mail-state/:/var/mail-state/\n- ./docker-data/dms/mail-logs/:/var/log/mail/\n- ./docker-data/dms/config/:/tmp/docker-mailserver/\n- /etc/localtime:/etc/localtime:ro\nenvironment:\n- ENABLE_RSPAMD=1\n- ENABLE_CLAMAV=1\n- ENABLE_FAIL2BAN=1\ncap_add:\n- NET_ADMIN # For Fail2Ban to work\nrestart: always\nNote There are currently no LDAP maintainers. If you encounter issues, please raise them in the issue tracker, but be aware that the core maintainers team will most likely not be able to help you. We would appreciate and we encourage everyone to actively participate in maintaining LDAP-related code by becoming a maintainer!
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\n# Provide the FQDN of your mail server here (Your DNS MX record should point to this value)\nhostname: mail.example.com\nports:\n- \"25:25\"\n- \"465:465\"\n- \"587:587\"\n- \"993:993\"\nvolumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/mail-state/:/var/mail-state/\n- ./docker-data/dms/mail-logs/:/var/log/mail/\n- ./docker-data/dms/config/:/tmp/docker-mailserver/\n- /etc/localtime:/etc/localtime:ro\nenvironment:\n- ACCOUNT_PROVISIONER=LDAP\n- LDAP_SERVER_HOST=ldap # your ldap container/IP/ServerName\n- LDAP_SEARCH_BASE=ou=people,dc=localhost,dc=localdomain\n- LDAP_BIND_DN=cn=admin,dc=localhost,dc=localdomain\n- LDAP_BIND_PW=admin\n- LDAP_QUERY_FILTER_USER=(&(mail=%s)(mailEnabled=TRUE))\n- LDAP_QUERY_FILTER_GROUP=(&(mailGroupMember=%s)(mailEnabled=TRUE))\n- LDAP_QUERY_FILTER_ALIAS=(|(&(mailAlias=%s)(objectClass=PostfixBookMailForward))(&(mailAlias=%s)(objectClass=PostfixBookMailAccount)(mailEnabled=TRUE)))\n- LDAP_QUERY_FILTER_DOMAIN=(|(&(mail=*@%s)(objectClass=PostfixBookMailAccount)(mailEnabled=TRUE))(&(mailGroupMember=*@%s)(objectClass=PostfixBookMailAccount)(mailEnabled=TRUE))(&(mailalias=*@%s)(objectClass=PostfixBookMailForward)))\n- DOVECOT_PASS_FILTER=(&(objectClass=PostfixBookMailAccount)(uniqueIdentifier=%n))\n- DOVECOT_USER_FILTER=(&(objectClass=PostfixBookMailAccount)(uniqueIdentifier=%n))\n- ENABLE_SASLAUTHD=1\n- SASLAUTHD_MECHANISMS=ldap\n- SASLAUTHD_LDAP_SERVER=ldap\n- SASLAUTHD_LDAP_BIND_DN=cn=admin,dc=localhost,dc=localdomain\n- SASLAUTHD_LDAP_PASSWORD=admin\n- SASLAUTHD_LDAP_SEARCH_BASE=ou=people,dc=localhost,dc=localdomain\n- SASLAUTHD_LDAP_FILTER=(&(objectClass=PostfixBookMailAccount)(uniqueIdentifier=%U))\n- POSTMASTER_ADDRESS=postmaster@localhost.localdomain\nrestart: always\nInfo
This was originally a community contributed guide. Please let us know via a Github Issue if you're having any difficulty following the guide so that we can update it.
This guide is focused on only using SMTP ports (not POP3 and IMAP) with the intent to relay mail received from another service to an external email address (eg: user@gmail.com). It is not intended for mailbox storage of real users.
In this setup DMS is not intended to receive email from the outside world, so no anti-spam or anti-virus software is needed, making the service lighter to run.
setup
The setup command used below is to be run inside the container.
Open Relays
Adding the docker network's gateway to the list of trusted hosts (eg: using the network or connected-networks option), can create an open relay. For instance if IPv6 is enabled on the host machine, but not in Docker.
Create the file compose.yaml with a content like this:
Example
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\n# Provide the FQDN of your mail server here (Your DNS MX record should point to this value)\nhostname: mail.example.com\nports:\n- \"25:25\"\n- \"587:587\"\n- \"465:465\"\nvolumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/mail-state/:/var/mail-state/\n- ./docker-data/dms/mail-logs/:/var/log/mail/\n- ./docker-data/dms/config/:/tmp/docker-mailserver/\n- /etc/localtime:/etc/localtime:ro\nenvironment:\n- ENABLE_FAIL2BAN=1\n# Using letsencrypt for SSL/TLS certificates:\n- SSL_TYPE=letsencrypt\n# Allow sending emails from other docker containers:\n# Beware creating an Open Relay: https://docker-mailserver.github.io/docker-mailserver/latest/config/environment/#permit_docker\n- PERMIT_DOCKER=network\n# You may want to enable this: https://docker-mailserver.github.io/docker-mailserver/latest/config/environment/#spoof_protection\n# See step 6 below, which demonstrates setup with enabled/disabled SPOOF_PROTECTION:\n- SPOOF_PROTECTION=0\ncap_add:\n- NET_ADMIN # For Fail2Ban to work\nrestart: always\nThe docs have a detailed page on Environment Variables for reference.
Firewalled portsIf you have a firewall running, you may need to open ports 25, 587 and 465.
For example, with the firewall ufw, run:
ufw allow 25\nufw allow 587\nufw allow 465\nCaution: This may not be sound advice.
Configure your DNS service to use an MX record for the hostname (eg: mail) you configured in the previous step and add the SPF TXT record.
If you manually manage the DNS zone file for the domain
It would look something like this:
$ORIGIN example.com\n@ IN A 10.11.12.13\nmail IN A 10.11.12.13\n\n; mail server for example.com\n@ IN MX 10 mail.example.com.\n\n; Add SPF record\n@ IN TXT \"v=spf1 mx -all\"\nThen don't forget to change the SOA serial number, and to restart the service.
Generate DKIM keys for your domain via setup config dkim.
Copy the content of the file docker-data/dms/config/opendkim/keys/example.com/mail.txt and add it to your DNS records as a TXT like SPF was handled above.
I use bind9 for managing my domains, so I just paste it on example.com.db:
mail._domainkey IN TXT ( \"v=DKIM1; h=sha256; k=rsa; \"\n \"p=MIIBIjANBgkqhkiG9w0BAQEFACAQ8AMIIBCgKCAQEAaH5KuPYPSF3Ppkt466BDMAFGOA4mgqn4oPjZ5BbFlYA9l5jU3bgzRj3l6/Q1n5a9lQs5fNZ7A/HtY0aMvs3nGE4oi+LTejt1jblMhV/OfJyRCunQBIGp0s8G9kIUBzyKJpDayk2+KJSJt/lxL9Iiy0DE5hIv62ZPP6AaTdHBAsJosLFeAzuLFHQ6USyQRojefqFQtgYqWQ2JiZQ3\"\n \"iqq3bD/BVlwKRp5gH6TEYEmx8EBJUuDxrJhkWRUk2VDl1fqhVBy8A9O7Ah+85nMrlOHIFsTaYo9o6+cDJ6t1i6G1gu+bZD0d3/3bqGLPBQV9LyEL1Rona5V7TJBGg099NQkTz1IwIDAQAB\" ) ; ----- DKIM key mail for example.com\nGet an SSL certificate, we have a guide for you here (Let's Encrypt is a popular service to get free SSL certificates).
Start DMS and check the terminal output for any errors: docker compose up.
Create email accounts and aliases:
With SPOOF_PROTECTION=0
setup email add admin@example.com passwd123\nsetup email add info@example.com passwd123\nsetup alias add admin@example.com external-account@gmail.com\nsetup alias add info@example.com external-account@gmail.com\nsetup email list\nsetup alias list\nAliases make sure that any email that comes to these accounts is forwarded to your third-party email address (external-account@gmail.com), where they are retrieved (eg: via third-party web or mobile app), instead of connecting directly to docker-mailserer with POP3 / IMAP.
With SPOOF_PROTECTION=1
setup email add admin.gmail@example.com passwd123\nsetup email add info.gmail@example.com passwd123\nsetup alias add admin@example.com admin.gmail@example.com\nsetup alias add info@example.com info.gmail@example.com\nsetup alias add admin.gmail@example.com external-account@gmail.com\nsetup alias add info.gmail@example.com external-account@gmail.com\nsetup email list\nsetup alias list\nThis extra step is required to avoid the 553 5.7.1 Sender address rejected: not owned by user error (the accounts used for submitting mail to Gmail are admin.gmail@example.com and info.gmail@example.com)
Send some test emails to these addresses and make other tests. Once everything is working well, stop the container with ctrl+c and start it again as a daemon: docker compose up -d.
This site lists blog entries that write about the project. If you blogged about DMS let us know so we can add it here!
You'll need to retrieve the git submodules prior to building your own Docker image. From within your copy of the git repo run the following to retrieve the submodules and build the Docker image:
git submodule update --init --recursive\ndocker build -t <YOUR CUSTOM IMAGE NAME> .\nOr, you can clone and retrieve the submodules in one command:
git clone --recurse-submodules https://github.com/docker-mailserver/docker-mailserver\nWe make use of build-features that require a recent version of Docker. Depending on your distribution, please have a look at the official installation documentation for Docker to get the latest version. Otherwise, you may encounter issues, for example with the --link flag for a COPY command.
If you are not using make to build the image, note that you will need to provide DOCKER_BUILDKIT=1 to the docker build command for the build to succeed.
The Dockerfile takes additional, so-called build arguments. These are
VCS_VERSION: the image version (default = edge)VCS_REVISION: the image revision (default = unknown)When using make to build the image, these are filled with proper values. You can build the image without supplying these arguments just fine though.
If you are hiding your container behind a proxy service you might have discovered that the proxied requests from now on contain the proxy IP as the request origin. Whilst this behavior is technical correct it produces certain problems on the containers behind the proxy as they cannot distinguish the real origin of the requests anymore.
To solve this problem on TCP connections we can make use of the proxy protocol. Compared to other workarounds that exist (X-Forwarded-For which only works for HTTP requests or Tproxy that requires you to recompile your kernel) the proxy protocol:
There is only one condition: both endpoints of the connection MUST be compatible with proxy protocol.
Luckily dovecot and postfix are both Proxy-Protocol ready softwares so it depends only on your used reverse-proxy / loadbalancer.
The configuration depends on the used proxy system. I will provide the configuration examples of traefik v2 using IMAP and SMTP with implicit TLS.
Feel free to add your configuration if you achieved the same goal using different proxy software below:
Traefik v2Truncated configuration of traefik itself:
services:\nreverse-proxy:\nimage: docker.io/traefik:latest # v2.5\ncontainer_name: docker-traefik\nrestart: always\ncommand:\n- \"--providers.docker\"\n- \"--providers.docker.exposedbydefault=false\"\n- \"--providers.docker.network=proxy\"\n- \"--entrypoints.web.address=:80\"\n- \"--entryPoints.websecure.address=:443\"\n- \"--entryPoints.smtp.address=:25\"\n- \"--entryPoints.smtp-ssl.address=:465\"\n- \"--entryPoints.imap-ssl.address=:993\"\n- \"--entryPoints.sieve.address=:4190\"\nports:\n- \"25:25\"\n- \"465:465\"\n- \"993:993\"\n- \"4190:4190\"\n[...]\nTruncated list of necessary labels on the DMS container:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\nhostname: mail.example.com\nrestart: always\nnetworks:\n- proxy\nlabels:\n- \"traefik.enable=true\"\n- \"traefik.tcp.routers.smtp.rule=HostSNI(`*`)\"\n- \"traefik.tcp.routers.smtp.entrypoints=smtp\"\n- \"traefik.tcp.routers.smtp.service=smtp\"\n- \"traefik.tcp.services.smtp.loadbalancer.server.port=25\"\n- \"traefik.tcp.services.smtp.loadbalancer.proxyProtocol.version=1\"\n- \"traefik.tcp.routers.smtp-ssl.rule=HostSNI(`*`)\"\n- \"traefik.tcp.routers.smtp-ssl.tls=false\"\n- \"traefik.tcp.routers.smtp-ssl.entrypoints=smtp-ssl\"\n- \"traefik.tcp.routers.smtp-ssl.service=smtp-ssl\"\n- \"traefik.tcp.services.smtp-ssl.loadbalancer.server.port=465\"\n- \"traefik.tcp.services.smtp-ssl.loadbalancer.proxyProtocol.version=1\"\n- \"traefik.tcp.routers.imap-ssl.rule=HostSNI(`*`)\"\n- \"traefik.tcp.routers.imap-ssl.entrypoints=imap-ssl\"\n- \"traefik.tcp.routers.imap-ssl.service=imap-ssl\"\n- \"traefik.tcp.services.imap-ssl.loadbalancer.server.port=10993\"\n- \"traefik.tcp.services.imap-ssl.loadbalancer.proxyProtocol.version=2\"\n- \"traefik.tcp.routers.sieve.rule=HostSNI(`*`)\"\n- \"traefik.tcp.routers.sieve.entrypoints=sieve\"\n- \"traefik.tcp.routers.sieve.service=sieve\"\n- \"traefik.tcp.services.sieve.loadbalancer.server.port=4190\"\n[...]\nKeep in mind that it is necessary to use port 10993 here. More information below at dovecot configuration.
dovecot and postfix)","text":"The following changes can be achieved completely by adding the content to the appropriate files by using the projects function to overwrite config files.
Changes for postfix can be applied by adding the following content to docker-data/dms/config/postfix-main.cf:
postscreen_upstream_proxy_protocol = haproxy\nand to docker-data/dms/config/postfix-master.cf:
submission/inet/smtpd_upstream_proxy_protocol=haproxy\nsubmissions/inet/smtpd_upstream_proxy_protocol=haproxy\nChanges for dovecot can be applied by adding the following content to docker-data/dms/config/dovecot.cf:
haproxy_trusted_networks = <your-proxy-ip>, <optional-cidr-notation>\nhaproxy_timeout = 3 secs\nservice imap-login {\ninet_listener imaps {\nhaproxy = yes\nssl = yes\nport = 10993\n}\n}\nNote
Port 10993 is used here to avoid conflicts with internal systems like postscreen and amavis as they will exchange messages on the default port and obviously have a different origin then compared to the proxy.
A forward-only mail server does not have any local mailboxes. Instead, it has only aliases that forward emails to external email accounts (for example to a Gmail account). You can also send email from the localhost (the computer where DMS is installed), using as sender any of the alias addresses.
The important settings for this setup (on mailserver.env) are these:
PERMIT_DOCKER=host\nENABLE_POP3=\nENABLE_CLAMAV=0\nSMTP_ONLY=1\nENABLE_SPAMASSASSIN=0\nENABLE_FETCHMAIL=0\nSince there are no local mailboxes, we use SMTP_ONLY=1 to disable dovecot. We disable as well the other services that are related to local mailboxes (POP3, ClamAV, SpamAssassin, etc.)
We can create aliases with ./setup.sh, like this:
./setup.sh alias add <alias-address> <external-email-account>\nIf you want to send emails from outside the mail server you have to authenticate somehow (with a username and password). One way of doing it is described in this discussion. However if there are many user accounts, it is better to use authentication with LDAP. The settings for this on mailserver.env are:
ENABLE_LDAP=1 # with the :edge tag, use ACCOUNT_PROVISIONER\nACCOUNT_PROVISIONER=LDAP\nLDAP_START_TLS=yes\nLDAP_SERVER_HOST=ldap.example.org\nLDAP_SEARCH_BASE=ou=users,dc=example,dc=org\nLDAP_BIND_DN=cn=mailserver,dc=example,dc=org\nLDAP_BIND_PW=pass1234\n\nENABLE_SASLAUTHD=1\nSASLAUTHD_MECHANISMS=ldap\nSASLAUTHD_LDAP_SERVER=ldap.example.org\nSASLAUTHD_LDAP_START_TLS=yes\nSASLAUTHD_LDAP_BIND_DN=cn=mailserver,dc=example,dc=org\nSASLAUTHD_LDAP_PASSWORD=pass1234\nSASLAUTHD_LDAP_SEARCH_BASE=ou=users,dc=example,dc=org\nSASLAUTHD_LDAP_FILTER=(&(uid=%U)(objectClass=inetOrgPerson))\nMy LDAP data structure is very basic, containing only the username, password, and the external email address where to forward emails for this user. An entry looks like this:
add uid=username,ou=users,dc=example,dc=org\nuid: username\nobjectClass: inetOrgPerson\nsn: username\ncn: username\nuserPassword: {SSHA}abcdefghi123456789\nemail: external-account@gmail.com\nThis structure is different from what is expected/assumed from the configuration scripts of DMS, so it doesn't work just by using the LDAP_QUERY_FILTER_... settings. Instead, I had to use a custom configuration (via user-patches.sh). I created the script docker-data/dms/config/user-patches.sh, with content like this:
#!/bin/bash\n\nrm -f /etc/postfix/{ldap-groups.cf,ldap-domains.cf}\n\npostconf \\\n\"virtual_mailbox_domains = /etc/postfix/vhost\" \\\n\"virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf texthash:/etc/postfix/virtual\" \\\n\"smtpd_sender_login_maps = ldap:/etc/postfix/ldap-users.cf\"\n\nsed -i /etc/postfix/ldap-users.cf \\\n-e '/query_filter/d' \\\n-e '/result_attribute/d' \\\n-e '/result_format/d'\ncat <<EOF >> /etc/postfix/ldap-users.cf\nquery_filter = (uid=%u)\nresult_attribute = uid\nresult_format = %s@example.org\nEOF\n\nsed -i /etc/postfix/ldap-aliases.cf \\\n-e '/domain/d' \\\n-e '/query_filter/d' \\\n-e '/result_attribute/d'\ncat <<EOF >> /etc/postfix/ldap-aliases.cf\ndomain = example.org\nquery_filter = (uid=%u)\nresult_attribute = mail\nEOF\n\npostfix reload\nYou see that besides query_filter, I had to customize as well result_attribute and result_format.
See also
For more details about using LDAP see: LDAP managed mail server with Postfix and Dovecot for multiple domains
Note
Another solution that serves as a forward-only mail server is this.
"},{"location":"examples/use-cases/imap-folders/","title":"Mailboxes (aka IMAP Folders)","text":"INBOX is setup as the private inbox namespace. By default target/dovecot/15-mailboxes.conf configures the special IMAP folders Drafts, Sent, Junk and Trash to be automatically created and subscribed. They are all assigned to the private inbox namespace (which implicitly provides the INBOX folder).
These IMAP folders are considered special because they add a \"SPECIAL-USE\" attribute, which is a standardized way to communicate to mail clients that the folder serves a purpose like storing spam/junk mail (\\Junk) or deleted mail (\\Trash). This differentiates them from regular mail folders that you may use for organizing.
See target/dovecot/15-mailboxes.conf for existing mailbox folders which you can modify or uncomment to enable some other common mailboxes. For more information try the official Dovecot documentation.
The Archive special IMAP folder may be useful to enable. To do so, make a copy of target/dovecot/15-mailboxes.conf and uncomment the Archive mailbox definition. Mail clients should understand that this folder is intended for archiving mail due to the \\Archive \"SPECIAL-USE\" attribute.
With the provided compose.yaml example, a volume bind mounts the host directory docker-data/dms/config/ to the container location /tmp/docker-mailserver/. Config file overrides should instead be mounted to a different location as described in Overriding Configuration for Dovecot:
volumes:\n- ./docker-data/dms/config/dovecot/15-mailboxes.conf:/etc/dovecot/conf.d/15-mailboxes.conf:ro\nHandling of newly added mailbox folders can be inconsistent across mail clients:
SPECIAL-USE attributes","text":"Not all mail clients support the SPECIAL-USE attribute for mailboxes (defined in RFC 6154). These clients will treat the mailbox folder as any other, using the name assigned to it instead.
Some clients may still know to treat these folders for their intended purpose if the mailbox name matches the common names that the SPECIAL-USE attributes represent (eg Sent as the mailbox name for \\Sent).
Usually the mail client will know via context such as the SPECIAL-USE attribute or common English mailbox names, to provide a localized label for the users preferred language.
Take care to test localized names work well as well.
"},{"location":"examples/use-cases/imap-folders/#email-clients-support","title":"Email Clients Support","text":"SPECIAL-USE attribute enabled for archives:Archives folder on the server.Archive.SPECIAL-USE attribute is enabled for archives:Windows Mail
Windows Mail has been said to ignore SPECIAL-USE attribute and look only at the mailbox folder name assigned.
Needs citation
This information is provided by the community.
It presently lacks references to confirm the behaviour. If any information is incorrect please let us know!
"}]} \ No newline at end of file +{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Welcome to the Documentation fordocker-mailserver!","text":"This Documentation is Versioned
Make sure to select the correct version of this documentation! It should match the version of the image you are using. The default version corresponds to the :latest image tag - the most recent stable release.
This documentation provides you not only with the basic setup and configuration of DMS but also with advanced configuration, elaborate usage scenarios, detailed examples, hints and more.
"},{"location":"#about","title":"About","text":"docker-mailserver, or DMS for short, is a production-ready fullstack but simple mail server (SMTP, IMAP, LDAP, Antispam, Antivirus, etc.). It employs only configuration files, no SQL database. The image is focused around the slogan \"Keep it simple and versioned\".
If you're completely new to mail servers or you want to read up on them, check out our Introduction page. If you're new to DMS as a mail server appliance, make sure to read the Usage chapter first. If you want to look at examples for Docker Compose, we have an Examples page.
There is also a script - setup.sh - supplied with this project. It supports you in configuring and administrating your server. Information on how to get it and how to use it is available on a dedicated page.
We have a dedicated configuration page. It contains most of the configuration and explanation you need to setup your mail server properly. Be aware that advanced tasks may still require reading through all parts of this documentation; it may also involve inspecting your running container for debugging purposes. After all, a mail server is a complex arrangement of various programs.
Important
If you'd like to change, patch or alter files or behavior of DMS, you can use a script. Just place a script called user-patches.sh in your ./docker-data/dms/config/ folder volume (which is mounted to /tmp/docker-mailserver/ inside the container) and it will be run on container startup. See the 'Modifications via Script' page for additional documentation and an example.
You might also want to check out:
Tip
Definitely check out the FAQ for more information and tips! Please do not open an issue before you have checked our documentation for answers, including the FAQ!
"},{"location":"#tests","title":"Tests","text":"DMS employs a variety of tests. If you want to know more about our test suite, view our testing docs.
"},{"location":"#contributing","title":"Contributing","text":"We are always happy to welcome new contributors. For guidelines and entrypoints please have a look at the Contributing section.
"},{"location":"faq/","title":"FAQ","text":""},{"location":"faq/#what-kind-of-database-are-you-using","title":"What kind of database are you using?","text":"None! No database is required. The filesystem is the database. This image is based on config files that can be persisted using bind mounts (default) or Docker volumes, and as such versioned, backed up and so forth.
"},{"location":"faq/#where-are-emails-stored","title":"Where are emails stored?","text":"Mails are stored in /var/mail/${domain}/${username}. Since v9.0.0 it is possible to add custom user_attributes for each accounts to have a different mailbox configuration (See #1792).
INBOX is setup by default with the special IMAP folders Drafts, Sent, Junk and Trash. You can learn how to modify or add your own folders (including additional special folders like Archive) by visiting our docs page Customizing IMAP Folders for more information.
Make sure to read the CHANGELOG before updating to new versions, to be prepared for possible breaking changes.
Then, run the following commands:
docker compose pull\ndocker compose down\ndocker compose up -d\nYou should see the new version number on startup, for example: [ INF ] Welcome to docker-mailserver 11.3.1. And you're done! Don't forget to have a look at the remaining functions of the setup.sh script with ./setup.sh help.
As you'll realistically be deploying to production on a Linux host, if you are on Windows or macOS and want to run the image locally first, it's advised to do so via a VM guest running Linux if you have issues running DMS on your host system.
"},{"location":"faq/#what-are-the-system-requirements","title":"What are the system requirements?","text":""},{"location":"faq/#recommended","title":"Recommended","text":"Warning
ClamAV can consume a lot of memory, as it reads the entire signature database into RAM.
Current figure is about 850M and growing. If you get errors about ClamAV or amavis failing to allocate memory you need more RAM or more swap and of course docker must be allowed to use swap (not always the case). If you can't use swap at all you may need 3G RAM.
"},{"location":"faq/#how-to-alter-a-running-dms-instance-without-relaunching-the-container","title":"How to alter a running DMS instance without relaunching the container?","text":"DMS aggregates multiple \"sub-services\", such as Postfix, Dovecot, Fail2ban, SpamAssassin, etc. In many cases, one may edit a sub-service's config and reload that very sub-service, without stopping and relaunching the whole mail server.
In order to do so, you'll probably want to push your config updates to your server through a Docker volume (these docs use: ./docker-data/dms/config/:/tmp/docker-mailserver/), then restart the sub-service to apply your changes, using supervisorctl. For instance, after editing fail2ban's config: supervisorctl restart fail2ban.
See the documentation for supervisorctl.
Tip
To add, update or delete an email account; there is no need to restart postfix / dovecot service inside the container after using setup.sh script.
For more information, see #1639.
"},{"location":"faq/#how-can-i-sync-the-container-and-host-datetime","title":"How can I sync the container and host date/time?","text":"Share the host's /etc/localtime with the container, e.g. by using a bind mount:
volumes:\n- /etc/localtime:/etc/localtime:ro\nOptionally, you can set the TZ ENV variable; e.g. TZ=Europe/Berlin. Check this list for which values are allowed.
All files are using the Unix format with LF line endings. Please do not use CRLF.
DMS supports multiple domains out of the box, so you can do this:
./setup.sh email add user1@example.com\n./setup.sh email add user1@example.de\n./setup.sh email add user1@server.example.org\nFrom the location of your compose.yaml, create a compressed archive of your docker-data/dms/config/ and docker-data/dms/mail-* folders:
tar --gzip -cf \"backup-$(date +%F).tar.gz\" ./docker-data/dms\nThen to restore docker-data/dms/config/ and docker-data/dms/mail-* folders from your backup file:
tar --gzip -xf backup-date.tar.gz\nAssuming that you use docker-compose and data volumes, you can backup the configuration, emails and logs like this:
# create backup\ndocker run --rm -it \\\n-v \"${PWD}/docker-data/dms/config/:/tmp/docker-mailserver/\" \\\n-v \"${PWD}/docker-data/dms-backups/:/backup/\" \\\n--volumes-from mailserver \\\nalpine:latest \\\ntar czf \"/backup/mail-$(date +%F).tar.gz\" /var/mail /var/mail-state /var/log/mail /tmp/docker-mailserver\n\n# delete backups older than 30 days\nfind \"${PWD}/docker-data/dms-backups/\" -type f -mtime +30 -delete\nSee this part of the documentation for further details and best practice advice, especially regarding security concerns.
"},{"location":"faq/#how-can-i-configure-my-email-client","title":"How can I configure my email client?","text":"Login is full email address (<user>@<domain>).
# IMAP\nusername: <user1@example.com>\npassword: <mypassword>\nserver: <mail.example.com>\nimap port: 143 or 993 with STARTTLS/SSL (recommended)\nimap path prefix: INBOX\n\n# SMTP\nsmtp port: 25 or 587/465 with STARTTLS/SSL (recommended)\nusername: <user1@example.com>\npassword: <mypassword>\nDMS is properly configured for port 587, if possible, we recommend using port 465 for SMTP though. See this section to learn more about ports.
"},{"location":"faq/#can-i-use-a-nakedbare-domain-ie-no-hostname","title":"Can I use a naked/bare domain (i.e. no hostname)?","text":"Yes, but not without some configuration changes. Normally it is assumed that DMS runs on a host with a name, so the fully qualified host name might be mail.example.com with the domain example.com. The MX records point to mail.example.com.
To use a bare domain (where the host name is example.com and the domain is also example.com), change mydestination:
mydestination = $myhostname, localhost.$mydomain, localhostmydestination = localhost.$mydomain, localhostAdd the latter line to docker-data/dms/config/postfix-main.cf. If that doesn't work, make sure that OVERRIDE_HOSTNAME is blank in your mailserver.env file. Without these changes there will be warnings in the logs like:
warning: do not list domain example.com in BOTH mydestination and virtual_mailbox_domains\nPlus of course mail delivery fails.
Also you need to define hostname: example.com in your compose.yaml.
You might not want a bare domain
We encourage you to consider using a subdomain where possible.
user@example.com, that is distinct from your hostname which is identified by a DNS MX record.Considering you want to redirect all incoming e-mails for the domain example.com to user1@example.com, add the following line to docker-data/dms/config/postfix-virtual.cf:
@example.com user1@example.com\nFirst of all, create a special alias named devnull by editing docker-data/dms/config/postfix-aliases.cf:
devnull: /dev/null\nConsidering you want to delete all the e-mails received for baduser@example.com, add the following line to docker-data/dms/config/postfix-virtual.cf:
baduser@example.com devnull\nImportant
If you use a catch-all rule for the main/sub domain, you need another entry in docker-data/dms/config/postfix-virtual.cf:
@mail.example.com hello@example.com\nbaduser@example.com devnull\ndevnull@mail.example.com devnull\nBoth RSA and ECDSA certs are supported. You can provide your own cert files manually, or mount a letsencrypt generated directory (with alternative support for Traefik's acme.json). Check out the SSL_TYPE documentation for more details.
If this migration implies a DNS modification, be sure to wait for DNS propagation before opening an issue. Few examples of symptoms can be found here or here.
This could be related to a modification of your MX record, or the IP mapped to mail.example.com. Additionally, validate your DNS configuration.
If everything is OK regarding DNS, please provide formatted logs and config files. This will allow us to help you.
If we're blind, we won't be able to do anything.
"},{"location":"faq/#connection-refused-or-no-response-at-all","title":"Connection refused or No response at all","text":"You see errors like \"Connection Refused\" and \"Connection closed by foreign host\", or you cannot connect at all? You may not be able to connect with your mail client (MUA)? Make sure to check Fail2Ban did not ban you (for exceeding the number of tried logins for example)! You can run
docker exec <CONTAINER NAME> setup fail2ban\nand check whether your IP address appears. Use
docker exec <CONTAINER NAME> setup fail2ban unban <YOUR IP>\nto unban the IP address.
"},{"location":"faq/#how-can-i-authenticate-users-with-smtp_only1","title":"How can I authenticate users withSMTP_ONLY=1?","text":"See #1247 for an example.
Todo
Write a How-to / Use-Case / Tutorial about authentication with SMTP_ONLY.
warning: connect to Milter service inet:localhost:8893: Connection refused\n# DMARC not running\n# => /etc/init.d/opendmarc restart\n\nwarning: connect to Milter service inet:localhost:8891: Connection refused\n# DKIM not running\n# => /etc/init.d/opendkim restart\n\nmail amavis[1459]: (01459-01) (!)connect to /var/run/clamav/clamd.ctl failed, attempt #1: Can't connect to a UNIX socket /var/run/clamav/clamd.ctl: No such file or directory\nmail amavis[1459]: (01459-01) (!)ClamAV-clamd: All attempts (1) failed connecting to /var/run/clamav/clamd.ctl, retrying (2)\nmail amavis[1459]: (01459-01) (!)ClamAV-clamscan av-scanner FAILED: /usr/bin/clamscan KILLED, signal 9 (0009) at (eval 100) line 905.\nmail amavis[1459]: (01459-01) (!!)AV: ALL VIRUS SCANNERS FAILED\n# Clamav is not running (not started or because you don't have enough memory)\n# => check requirements and/or start Clamav\nUsing user-patches.sh, update the container file /etc/postfix/main.cf to include:
proxy_interfaces = X.X.X.X (your public IP)\nuser-patches.sh script","text":"Suppose you want to change a number of settings that are not listed as variables or add things to the server that are not included?
DMS has a built-in way to do post-install processes. If you place a script called user-patches.sh in the config directory it will be run after all configuration files are set up, but before the postfix, amavis and other daemons are started.
It is common to use a local directory for config added to docker-mailsever via a volume mount in your compose.yaml (eg: ./docker-data/dms/config/:/tmp/docker-mailserver/).
Add or create the script file to your config directory:
cd ./docker-data/dms/config\ntouch user-patches.sh\nchmod +x user-patches.sh\nThen fill user-patches.sh with suitable code.
If you want to test it you can move into the running container, run it and see if it does what you want. For instance:
# start shell in container\n./setup.sh debug login\n\n# check the file\ncat /tmp/docker-mailserver/user-patches.sh\n\n# run the script\n/tmp/docker-mailserver/user-patches.sh\n\n# exit the container shell back to the host shell\nexit\nYou can do a lot of things with such a script. You can find an example user-patches.sh script here: example user-patches.sh script.
We also have a very similar docs page specifically about this feature!
Special use-case - patching the supervisord configuration
It seems worth noting, that the user-patches.sh gets executed through supervisord. If you need to patch some supervisord config (e.g. /etc/supervisor/conf.d/saslauth.conf), the patching happens too late.
An easy workaround is to make the user-patches.sh reload the supervisord config after patching it:
#!/bin/bash\nsed -i 's/rimap -r/rimap/' /etc/supervisor/conf.d/saslauth.conf\nsupervisorctl update\nUse the following command:
./setup.sh fail2ban ban <IP>\nThe default bantime is 180 days. This value can be customized.
"},{"location":"faq/#what-to-do-in-case-of-spfforwarding-problems","title":"What to do in case of SPF/Forwarding problems","text":"If you got any problems with SPF and/or forwarding mails, give SRS a try. You enable SRS by setting ENABLE_SRS=1. See the variable description for further information.
There are many reasons why email might be rejected, common causes are:
DMS does not manage those concerns, verify they are not causing your delivery problems before reporting a bug on our issue tracker. Resources that can help you troubleshoot:
docker-data/dms/config/ Directory?","text":"This documentation and all example configuration files in the GitHub repository use docker-data/dms/config/ to refer to the directory in the host that is mounted (e.g. via a bind mount) to /tmp/docker-mailserver/ inside the container.
Most configuration files for Postfix, Dovecot, etc. are persisted here. Optional configuration is stored here as well.
"},{"location":"faq/#what-about-the-docker-datadmsmail-state-directory","title":"What About thedocker-data/dms/mail-state/ Directory?","text":"This documentation and all example configuration files in the GitHub repository use docker-data/dms/mail-state/ to refer to the directory in the host that is mounted (e.g. via a bind mount) to /var/mail-state/ inside the container.
When you run DMS with the ENV variable ONE_DIR=1 (default), this directory will provide support to persist Fail2Ban blocks, ClamAV signature updates, and the like when the container is restarted or recreated. Service data is relocated to the mail-state folder for the following services: Postfix, Dovecot, Fail2Ban, Amavis, PostGrey, ClamAV, SpamAssassin, Rspamd & Redis.
Antispam rules are managed in docker-data/dms/config/spamassassin-rules.cf.
SA_SPAM_SUBJECT values?","text":"For no subject set SA_SPAM_SUBJECT=undef.
For a trailing white-space subject one can define the whole variable with quotes in compose.yaml:
environment:\n- \"SA_SPAM_SUBJECT=[SPAM] \"\nx-headers not inserted into my subdomain.example.com subdomain emails?","text":"In the default setup, amavis only applies SpamAssassin x-headers into domains matching the template listed in the config file (05-domain_id in the amavis defaults).
The default setup @local_domains_acl = ( \".$mydomain\" ); does not match subdomains. To match subdomains, you can override the @local_domains_acl directive in the amavis user config file 50-user with @local_domains_maps = (\".\"); to match any sort of domain template.
Put received spams in .Junk/ imap folder using SPAMASSASSIN_SPAM_TO_INBOX=1 and MOVE_SPAM_TO_JUNK=1 and add a user cron like the following:
# This assumes you're having `environment: ONE_DIR=1` in the `mailserver.env`,\n# with a consolidated config in `/var/mail-state`\n#\n# m h dom mon dow command\n# Everyday 2:00AM, learn spam from a specific user\n0 2 * * * docker exec mailserver sa-learn --spam /var/mail/example.com/username/.Junk --dbpath /var/mail-state/lib-amavis/.spamassassin\nWith docker-compose you can more easily use the internal instance of cron within DMS. This is less problematic than the simple solution shown above, because it decouples the learning from the host on which DMS is running, and avoids errors if the mail server is not running.
The following configuration works nicely:
ExampleCreate a system cron file:
# in the compose.yaml root directory\nmkdir -p ./docker-data/dms/cron\ntouch ./docker-data/dms/cron/sa-learn\nchown root:root ./docker-data/dms/cron/sa-learn\nchmod 0644 ./docker-data/dms/cron/sa-learn\nEdit the system cron file nano ./docker-data/dms/cron/sa-learn, and set an appropriate configuration:
# This assumes you're having `environment: ONE_DIR=1` in the env-mailserver,\n# with a consolidated config in `/var/mail-state`\n#\n# '> /dev/null' to send error notifications from 'stderr' to 'postmaster@example.com'\n#\n# m h dom mon dow user command\n#\n# Everyday 2:00AM, learn spam from a specific user\n# spam: junk directory\n0 2 * * * root sa-learn --spam /var/mail/example.com/username/.Junk --dbpath /var/mail-state/lib-amavis/.spamassassin > /dev/null\n# ham: archive directories\n15 2 * * * root sa-learn --ham /var/mail/example.com/username/.Archive* --dbpath /var/mail-state/lib-amavis/.spamassassin > /dev/null\n# ham: inbox subdirectories\n30 2 * * * root sa-learn --ham /var/mail/example.com/username/cur* --dbpath /var/mail-state/lib-amavis/.spamassassin > /dev/null\n#\n# Everyday 3:00AM, learn spam from all users of a domain\n# spam: junk directory\n0 3 * * * root sa-learn --spam /var/mail/not-example.com/*/.Junk --dbpath /var/mail-state/lib-amavis/.spamassassin > /dev/null\n# ham: archive directories\n15 3 * * * root sa-learn --ham /var/mail/not-example.com/*/.Archive* --dbpath /var/mail-state/lib-amavis/.spamassassin > /dev/null\n# ham: inbox subdirectories\n30 3 * * * root sa-learn --ham /var/mail/not-example.com/*/cur* --dbpath /var/mail-state/lib-amavis/.spamassassin > /dev/null\nThen with compose.yaml:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\nvolumes:\n- ./docker-data/dms/cron/sa-learn:/etc/cron.d/sa-learn\nOr with Docker Swarm:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\n# ...\nconfigs:\n- source: my_sa_crontab\ntarget: /etc/cron.d/sa-learn\n\nconfigs:\nmy_sa_crontab:\nfile: ./docker-data/dms/cron/sa-learn\nWith the default settings, SpamAssassin will require 200 mails trained for spam (for example with the method explained above) and 200 mails trained for ham (using the same command as above but using --ham and providing it with some ham mails). Until you provided these 200+200 mails, SpamAssassin will not take the learned mails into account. For further reference, see the SpamAssassin Wiki.
By default, SPAM and INFECTED emails are put to a quarantine which is not very straight forward to access. Several config settings are affecting this behavior:
First, make sure you have the proper thresholds set:
SA_TAG=-100000.0\nSA_TAG2=3.75\nSA_KILL=100000.0\nSA_TAG makes sure, that all emails have the SpamAssassin headers included.SA_TAG2 is the actual threshold to set the YES/NO flag for spam detection.SA_KILL needs to be very high, to make sure nothing is bounced at all (SA_KILL superseeds SPAMASSASSIN_SPAM_TO_INBOX)Make sure everything (including SPAM) is delivered to the inbox and not quarantined:
SPAMASSASSIN_SPAM_TO_INBOX=1\nUse MOVE_SPAM_TO_JUNK=1 or create a sieve script which puts spam to the Junk folder:
require [\"comparator-i;ascii-numeric\",\"relational\",\"fileinto\"];\n\nif header :contains \"X-Spam-Flag\" \"YES\" {\n fileinto \"Junk\";\n} elsif allof (\n not header :matches \"x-spam-score\" \"-*\",\n header :value \"ge\" :comparator \"i;ascii-numeric\" \"x-spam-score\" \"3.75\" ) {\n fileinto \"Junk\";\n}\nCreate a dedicated mailbox for emails which are infected/bad header and everything amavis is blocking by default and put its address into docker-data/dms/config/amavis.cf
$clean_quarantine_to = \"amavis\\@example.com\";\n$virus_quarantine_to = \"amavis\\@example.com\";\n$banned_quarantine_to = \"amavis\\@example.com\";\n$bad_header_quarantine_to = \"amavis\\@example.com\";\n$spam_quarantine_to = \"amavis\\@example.com\";\nThis article answers the question \"What is a mail server, and how does it perform its duty?\" and it gives the reader an introduction to the field that covers everything you need to know to get started with DMS.
"},{"location":"introduction/#the-anatomy-of-a-mail-server","title":"The Anatomy of a Mail Server","text":"A mail server is only a part of a client-server relationship aimed at exchanging information in the form of emails. Exchanging emails requires using specific means (programs and protocols).
DMS provides you with the server portion, whereas the client can be anything from a terminal via text-based software (eg. Mutt) to a fully-fledged desktop application (eg. Mozilla Thunderbird, Microsoft Outlook\u2026), to a web interface, etc.
Unlike the client-side where usually a single program is used to perform retrieval and viewing of emails, the server-side is composed of many specialized components. The mail server is capable of accepting, forwarding, delivering, storing and overall exchanging messages, but each one of those tasks is actually handled by a specific piece of software. All of these \"agents\" must be integrated with one another for the exchange to take place.
DMS has made informed choices about those components and their (default) configuration. It offers a comprehensive platform to run a fully featured mail server in no time!
"},{"location":"introduction/#components","title":"Components","text":"The following components are required to create a complete delivery chain:
Here's a schematic view of mail delivery:
Sending an email: MUA ----> MTA ----> (MTA relays) ----> MDA\nFetching an email: MUA <--------------------------------- MDA\nThere may be other moving parts or sub-divisions (for instance, at several points along the chain, specialized programs may be analyzing, filtering, bouncing, editing\u2026 the exchanged emails).
In a nutshell, DMS provides you with the following components:
Here's where DMS's toochain fits within the delivery chain:
docker-mailserver is here:\n \u250f\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2513\nSending an email: MUA ---> MTA ---> (MTA relays) ---> \u252b MTA \u256e \u2503\nFetching an email: MUA <------------------------------ \u252b MDA \u256f \u2503\n \u2517\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u251b\nLet's say Alice owns a Gmail account, alice@gmail.com; and Bob owns an account on a DMS instance, bob@dms.io.
Make sure not to conflate these two very different scenarios: A) Alice sends an email to bob@dms.io => the email is first submitted to MTA smtp.gmail.com, then relayed to MTA smtp.dms.io where it is then delivered into Bob's mailbox. B) Bob sends an email to alice@gmail.com => the email is first submitted to MTA smtp.dms.io, then relayed to MTA smtp.gmail.com and eventually delivered into Alice's mailbox.
In scenario A the email leaves Gmail's premises, that email's initial submission is not handled by your DMS instance(MTA); it merely receives the email after it has been relayed by Gmail's MTA. In scenario B, the DMS instance(MTA) handles the submission, prior to relaying.
The main takeaway is that when a third-party sends an email to a DMS instance(MTA) (or any MTA for that matter), it does not establish a direct connection with that MTA. Email submission first goes through the sender's MTA, then some relaying between at least two MTAs is required to deliver the email. That will prove very important when it comes to security management.
One important thing to note is that MTA and MDA programs may actually handle multiple tasks (which is the case with DMS's Postfix and Dovecot).
For instance, Postfix is both an SMTP server (accepting emails) and a relaying MTA (transferring, ie. sending emails to other MTA/MDA); Dovecot is both an MDA (delivering emails in mailboxes) and an IMAP server (allowing MUAs to fetch emails from the mail server). On top of that, Postfix may rely on Dovecot's authentication capabilities.
The exact relationship between all the components and their respective (sometimes shared) responsibilities is beyond the scope of this document. Please explore this wiki & the web to get more insights about DMS's toolchain.
"},{"location":"introduction/#about-security-ports","title":"About Security & Ports","text":""},{"location":"introduction/#introduction","title":"Introduction","text":"In the previous section, three components were outlined. Each one of those is responsible for a specific task when it comes to exchanging emails:
Postfix handles Submission (and may handle Relay), whereas Dovecot handles Retrieval. They both need to be accessible by MUAs in order to act as servers, therefore they expose public endpoints on specific TCP ports. Those endpoints may be secured, using an encryption scheme and TLS certificates.
When it comes to the specifics of email exchange, we have to look at protocols and ports enabled to support all the identified purposes. There are several valid options and they've been evolving overtime.
"},{"location":"introduction/#overview","title":"Overview","text":"The following picture gives a visualization of the interplay of all components and their respective ports:
\u250f\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501 Submission \u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2513\u250f\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501 Transfer/Relay \u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2513\n\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2510\nMUA ----- STARTTLS ------> \u2524(587) MTA \u256e (25)\u251c <-- cleartext ---> \u250a Third-party MTA \u250a\n ----- implicit TLS --> \u2524(465) \u2502 | \u2514\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2518\n ----- cleartext -----> \u2524(25) \u2502 |\n |\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504|\nMUA <---- STARTTLS ------- \u2524(143) MDA \u256f |\n <---- implicit TLS --- \u2524(993) |\n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\n \u2517\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501 Retrieval \u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u251b\nIf you're new to email infrastructure, both that table and the schema may be confusing. Read on to expand your understanding and learn about DMS's configuration, including how you can customize it.
"},{"location":"introduction/#submission-smtp","title":"Submission - SMTP","text":"For a MUA to send an email to an MTA, it needs to establish a connection with that server, then push data packets over a network that both the MUA (client) and the MTA (server) are connected to. The server implements the SMTP protocol, which makes it capable of handling Submission.
In the case of DMS, the MTA (SMTP server) is Postfix. The MUA (client) may vary, yet its Submission request is performed as TCP packets sent over the public internet. This exchange of information may be secured in order to counter eavesdropping.
Now let's say I own an account on a DMS instance, me@dms.io. There are two very different use-cases for Submission:
In the first scenario, I will be submitting my email directly to my DMS instance/MTA (Postfix), which will then relay the email to its recipient's MTA for final delivery. In this case, Submission is first handled by establishing a direct connection to my own MTA-so at least for this portion of the delivery chain, I'll be able to ensure security/confidentiality. Not so much for what comes next, ie. relaying between MTAs and final delivery.
In the second scenario, a third-party email account owner will be first submitting an email to some third-party MTA. I have no control over this initial portion of the delivery chain, nor do I have control over the relaying that comes next. My MTA will merely accept a relayed email coming \"out of the blue\".
My MTA will thus have to support two kinds of Submission:
\u250f\u2501\u2501\u2501\u2501 Outbound Submission \u2501\u2501\u2501\u2501\u2513\n\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2510\nMe ---------------> \u2524 \u251c -----------------> \u250a \u250a\n \u2502 My MTA \u2502 \u250a Third-party MTA \u250a\n \u2502 \u251c <----------------- \u250a \u250a\n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2514\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2518\n\n \u2517\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501 Inbound Submission \u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u251b\nWhen it comes to securing Outbound Submission you should prefer to use Implicit TLS connection via ESMTP on port 465 (see RFC 8314). Please read our article about Understanding the Ports for more details!
Warning
This Submission setup is sometimes referred to as SMTPS. Long story short: this is incorrect and should be avoided.
Although a very satisfactory setup, Implicit TLS on port 465 is somewhat \"cutting edge\". There exists another well established mail Submission setup that must be supported as well, SMTP+STARTTLS on port 587. It uses Explicit TLS: the client starts with a cleartext connection, then the server informs a TLS-encrypted \"upgraded\" connection may be established, and the client may eventually decide to establish it prior to the Submission. Basically it's an opportunistic, opt-in TLS upgrade of the connection between the client and the server, at the client's discretion, using a mechanism known as STARTTLS that both ends need to implement.
In many implementations, the mail server doesn't enforce TLS encryption, for backwards compatibility. Clients are thus free to deny the TLS-upgrade proposal (or misled by a hacker about STARTTLS not being available), and the server accepts unencrypted (cleartext) mail exchange, which poses a confidentiality threat and, to some extent, spam issues. RFC 8314 (section 3.3) recommends for a mail server to support both Implicit and Explicit TLS for Submission, and to enforce TLS-encryption on ports 587 (Explicit TLS) and 465 (Implicit TLS). That's exactly DMS's default configuration: abiding by RFC 8314, it enforces a strict (encrypt) STARTTLS policy, where a denied TLS upgrade terminates the connection thus (hopefully but at the client's discretion) preventing unencrypted (cleartext) Submission.
A final Outbound Submission setup exists and is akin SMTP+STARTTLS on port 587, but on port 25. That port has historically been reserved specifically for unencrypted (cleartext) mail exchange though, making STARTTLS a bit wrong to use. As is expected by RFC 5321, DMS uses port 25 for unencrypted Submission in order to support older clients, but most importantly for unencrypted Transfer/Relay between MTAs.
Granted it's still very difficult enforcing encryption between MTAs (Transfer/Relay) without risking dropping emails (when relayed by MTAs not supporting TLS-encryption), Inbound Submission is to be handled in cleartext on port 25 by default.
Overall, DMS's default configuration for SMTP looks like this:
\u250f\u2501\u2501\u2501\u2501 Outbound Submission \u2501\u2501\u2501\u2501\u2513\n\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2510\nMe -- cleartext --> \u2524(25) (25)\u251c --- cleartext ---> \u250a \u250a\nMe -- TLS ---> \u2524(465) My MTA \u2502 \u250a Third-party MTA \u250a\nMe -- STARTTLS ---> \u2524(587) \u2502 \u250a \u250a\n \u2502 (25)\u251c <---cleartext ---- \u250a \u250a\n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2514\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2504\u2518\n\n \u2517\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501 Inbound Submission \u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u251b\nA MUA willing to fetch an email from a mail server will most likely communicate with its IMAP server. As with SMTP described earlier, communication will take place in the form of data packets exchanged over a network that both the client and the server are connected to. The IMAP protocol makes the server capable of handling Retrieval.
In the case of DMS, the IMAP server is Dovecot. The MUA (client) may vary, yet its Retrieval request is performed as TCP packets sent over the public internet. This exchange of information may be secured in order to counter eavesdropping.
Again, as with SMTP described earlier, the IMAP protocol may be secured with either Implicit TLS (aka. IMAPS / IMAP4S) or Explicit TLS (using STARTTLS).
The best practice as of 2020 is to enforce IMAPS on port 993, rather than IMAP+STARTTLS on port 143 (see RFC 8314); yet the latter is usually provided for backwards compatibility.
DMS's default configuration enables both Implicit and Explicit TLS for Retrievial, on ports 993 and 143 respectively.
"},{"location":"introduction/#retrieval-pop3","title":"Retrieval - POP3","text":"Similarly to IMAP, the older POP3 protocol may be secured with either Implicit or Explicit TLS.
The best practice as of 2020 would be POP3S on port 995, rather than POP3+STARTTLS on port 110 (see RFC 8314).
DMS's default configuration disables POP3 altogether. One should expect MUAs to use TLS-encrypted IMAP for Retrieval.
"},{"location":"introduction/#how-does-dms-help-with-setting-everything-up","title":"How Does DMS Help With Setting Everything Up?","text":"As a batteries included container image, DMS provides you with all the required components and a default configuration to run a decent and secure mail server. One may then customize all aspects of its internal components.
Eventually, it is up to you deciding exactly what kind of transportation/encryption to use and/or enforce, and to customize your instance accordingly (with looser or stricter security). Be also aware that protocols and ports on your server can only go so far with security; third-party MTAs might relay your emails on insecure connections, man-in-the-middle attacks might still prove effective, etc. Advanced counter-measure such as DANE, MTA-STS and/or full body encryption (eg. PGP) should be considered as well for increased confidentiality, but ideally without compromising backwards compatibility so as to not block emails.
"},{"location":"usage/","title":"Usage","text":"This pages explains how to get started with DMS. The guide uses Docker Compose as a reference. In our examples, a volume mounts the host location docker-data/dms/config/ to /tmp/docker-mailserver/ inside the container.
Before you can get started with deploying your own mail server, there are some requirements to be met:
There are a few requirements for a suitable host system:
PTR record for your host; security-hardened mail servers might otherwise reject your mail server as the IP address of your host does not resolve correctly/at all to the DNS name of your server.About the Container Runtime
On the host, you need to have a suitable container runtime (like Docker or Podman) installed. We assume Docker Compose is installed. We have aligned file names and configuration conventions with the latest Docker Compose (currently V2) specification.
If you're using podman, make sure to read the related documentation.
"},{"location":"usage/#minimal-dns-setup","title":"Minimal DNS Setup","text":"The DNS setup is a big and essential part of the whole setup. There is a lot of confusion for newcomers and people starting out when setting up DNS. This section provides an example configuration and supplementary explanation. We expect you to be at least a bit familiar with DNS, what it does and what the individual record types are.
Now let's say you just bought example.com and you want to be able to send and receive e-mails for the address test@example.com. On the most basic level, you will need to
MX record for your domain example.com - in our example, the MX record contains mail.example.comA record that resolves the name of your mail server - in our example, the A record contains 11.22.33.44PTR record that resolves the IP of your mail server - in our example, the PTR contains mail.example.comWe will later dig into DKIM, DMARC & SPF, but for now, these are the records that suffice in getting you up and running. Here is a short explanation of what the records do:
mail.example.com. This does not imply your e-mails will look like test@mail.example.com, the DNS name of your mail server is decoupled of the domain it serves e-mails for. In theory, you mail server could even serve e-mails for test@some-other-domain.com, if the MX record for some-other-domain.com points to mail.example.com.mail.example.com resolves to.11.22.33.44 resolves to.If you setup everything, it should roughly look like this:
$ dig @1.1.1.1 +short MX example.com\nmail.example.com\n$ dig @1.1.1.1 +short A mail.example.com\n11.22.33.44\n$ dig @1.1.1.1 +short -x 11.22.33.44\nmail.example.com\nTo understand which tags you should use, read this section carefully. Our CI will automatically build, test and push new images to the following container registries:
docker.io/mailserver/docker-mailserver)ghcr.io/docker-mailserver/docker-mailserver)All workflows are using the tagging convention listed below. It is subsequently applied to all images.
Event Image Tagspush on master edge push a tag (v1.2.3) 1.2.3, 1.2, 1, latest"},{"location":"usage/#get-all-files","title":"Get All Files","text":"Issue the following commands to acquire the necessary files:
DMS_GITHUB_URL=\"https://github.com/docker-mailserver/docker-mailserver/blob/latest\"\nwget \"${DMS_GITHUB_URL}/compose.yaml\"\nwget \"${DMS_GITHUB_URL}/mailserver.env\"\ncompose.yaml to your likingmail.example.com according to your FQDN../docker-data/dms/config/:/tmp/docker-mailserver/ mount, append -z or -Z.mailserver.env, but keep in mind that:VAR=VAL is supportedOVERRIDE_HOSTNAME=$HOSTNAME.$DOMAINNAME does not workUsing the Correct Commands For Stopping and Starting DMS
Use docker compose up / down, not docker compose start / stop. Otherwise, the container is not properly destroyed and you may experience problems during startup because of inconsistent state.
Using Ctrl+C is not supported either!
For an overview of commands to manage DMS config, run: docker exec -it <CONTAINER NAME> setup help.
setup.sh when no DMS Container Is Running We encourage you to directly use setup inside the container (like shown above). If you still want to use setup.sh, here's some information about it.
If no DMS container is running, any ./setup.sh command will check online for the :latest image tag (the current stable release), performing a docker pull ... if necessary followed by running the command in a temporary container:
$ ./setup.sh help\nImage 'ghcr.io/docker-mailserver/docker-mailserver:latest' not found. Pulling ...\nSETUP(1)\n\nNAME\n setup - 'docker-mailserver' Administration & Configuration script\n...\n\n$ docker run --rm ghcr.io/docker-mailserver/docker-mailserver:latest setup help\nSETUP(1)\n\nNAME\n setup - 'docker-mailserver' Administration & Configuration script\n...\nOn first start, you will need to add at least one email account (unless you're using LDAP). You have two minutes to do so, otherwise DMS will shutdown and restart. You can add accounts by running docker exec -ti <CONTAINER NAME> setup email add user@example.com. That's it! It really is that easy.
You definitely want to setup TLS. Please refer to our documentation about TLS.
"},{"location":"usage/#aliases","title":"Aliases","text":"You should add at least one alias, the postmaster alias. This is a common convention, but not strictly required.
docker exec -ti <CONTAINER NAME> setup alias add postmaster@example.com user@example.com\nYou will very likely want to configure your DNS with these TXT records: SPF, DKIM, and DMARC. We also ship a dedicated page in our documentation about the setup of DKIM, DMARC & SPF.
"},{"location":"usage/#custom-user-changes-patches","title":"Custom User Changes & Patches","text":"If you'd like to change, patch or alter files or behavior of DMS, you can use a script. See this part of our documentation for a detailed explanation.
"},{"location":"usage/#testing","title":"Testing","text":"Here are some tools you can use to verify your configuration:
This page contains valuable information when it comes to resolving issues you encounter.
Contributions Welcome!
Please consider contributing solutions to the FAQ
"},{"location":"config/debugging/#preliminary-information","title":"Preliminary Information","text":""},{"location":"config/debugging/#mail-sent-from-dms-does-not-arrive-at-destination","title":"Mail sent from DMS does not arrive at destination","text":"Some service providers block outbound traffic on port 25. Common hosting providers known to have this issue:
These links may advise how the provider can unblock the port through additional services offered, or via a support ticket request.
"},{"location":"config/debugging/#steps-for-debugging-dms","title":"Steps for Debugging DMS","text":"LOG_LEVEL to debug or trace.docker log <CONTAINER NAME> (or docker logs -f <CONTAINER NAME> if you want to follow the log).To get a shell inside the container run: docker exec -it <CONTAINER NAME> bash.
If you need more flexibility than docker logs offers, within the container /var/log/mail/mail.log and /var/log/supervisor/ are the most useful locations to get relevant DMS logs. Use the tail or cat commands to view their contents.
To install additional software:
apt-get update is needed to update repository metadata.apt-get install <PACKAGE>nano is a good package choice for beginners.Info
Values in bold are the default values. If an option doesn't work as documented here, check if you are running the latest image. The current master branch corresponds to the image ghcr.io/docker-mailserver/docker-mailserver:edge.
If you can't set your hostname (eg: you're in a container platform that doesn't let you) specify it via this environment variable. It will have priority over docker run --hostname, or the equivalent hostname: field in compose.yaml.
hostname -f command to get canonical hostname for DMS to use.Set the log level for DMS. This is mostly relevant for container startup scripts and change detection event feedback.
Valid values (in order of increasing verbosity) are: error, warn, info, debug and trace. The default log level is info.
Here you can adjust the log-level for Supervisor. Possible values are
The log-level will show everything in its class and above.
"},{"location":"config/environment/#one_dir","title":"ONE_DIR","text":"/var/mail-state) to allow persistence using docker volumes. See the related FAQ entry for more information.Configures the provisioning source of user accounts (including aliases) for user queries and authentication by services managed by DMS (Postfix and Dovecot).
User provisioning via OIDC is planned for the future, see this tracking issue.
A second container for the ldap service is necessary (e.g. docker-openldap)
"},{"location":"config/environment/#permit_docker","title":"PERMIT_DOCKER","text":"Set different options for mynetworks option (can be overwrite in postfix-main.cf) WARNING: Adding the docker network's gateway to the list of trusted hosts, e.g. using the network or connected-networks option, can create an open relay, for instance if IPv6 is enabled on the host machine but not in Docker.
docker-compose might use others (e.g. 192.168.0.0/16) use PERMIT_DOCKER=connected-networks in this case.Note: you probably want to set POSTFIX_INET_PROTOCOLS=ipv4 to make it work fine with Docker.
Set the timezone. If this variable is unset, the container runtime will try to detect the time using /etc/localtime, which you can alternatively mount into the container. The value of this variable must follow the pattern AREA/ZONE, i.e. of you want to use Germany's time zone, use Europe/Berlin. You can lookup all available timezones here.
Amavis content filter (used for ClamAV & SpamAssassin)
This page provides information on Amavis' logging statistics.
This enables DNS block lists in Postscreen. If you want to know which lists we are using, have a look at the default main.cf for Postfix we provide and search for postscreen_dnsbl_sites.
A Warning On DNS Block Lists
Make sure your DNS queries are properly resolved, i.e. you will most likely not want to use a public DNS resolver as these queries do not return meaningful results. We try our best to only evaluate proper return codes - this is not a guarantee that all codes are handled fine though.
Note that emails will be rejected if they don't pass the block list checks!
Enables the OpenDKIM service.
Enables the OpenDMARC service.
Enabled policyd-spf in Postfix's configuration. You will likely want to set this to 0 in case you're using Rspamd (ENABLE_RSPAMD=1).
If you enable Fail2Ban, don't forget to add the following lines to your compose.yaml:
cap_add:\n - NET_ADMIN\nOtherwise, nftables won't be able to ban IPs.
In the majority of cases, you want letsencrypt or manual.
self-signed can be used for testing SSL until you provide a valid certificate, note that third-parties cannot trust self-signed certificates, do not use this type in production. custom is a temporary workaround that is not officially supported.
SSL_CERT_PATH and SSL_KEY_PATH ENV vars to be set to the location of the files within the container.SSL_ALT_CERT_PATH and SSL_ALT_KEY_PATH allow providing a 2nd certificate as a fallback for dual (aka hybrid) certificate support. Useful for ECDSA with an RSA fallback. Presently only manual mode supports this feature.None)Please read the SSL page in the documentation for more information.
"},{"location":"config/environment/#tls_level","title":"TLS_LEVEL","text":"Configures the handling of creating mails with forged sender addresses.
Enables the Sender Rewriting Scheme. SRS is needed if DMS acts as forwarder. See postsrsd for further explanation.
In case your network interface differs from eth0, e.g. when you are using HostNetworking in Kubernetes, you can set this to whatever interface you want. This interface will then be used.
eth0Set how many days a virusmail will stay on the server before being deleted
Configure Postfix virtual_transport to deliver mail to a different LMTP client (default is a unix socket to dovecot).
Provide any valid URI. Examples:
lmtp:unix:/var/run/dovecot/lmtp (default, configured in Postfix main.cf)lmtp:unix:private/dovecot-lmtp (use socket)lmtps:inet:<host>:<port> (secure lmtp with starttls)lmtp:<kopano-host>:2003 (use kopano as mailstore)Set the mailbox size limit for all users. If set to zero, the size will be unlimited (default).
See mailbox quota.
"},{"location":"config/environment/#postfix_message_size_limit","title":"POSTFIX_MESSAGE_SIZE_LIMIT","text":"Set the message size limit for all users. If set to zero, the size will be unlimited (not recommended!)
Mails larger than this limit won't be scanned. ClamAV must be enabled (ENABLE_CLAMAV=1) for this.
Check for updates on container start and then once a day. If an update is available, a mail is send to POSTMASTER_ADDRESS.
Customize the update check interval. Number + Suffix. Suffix must be 's' for seconds, 'm' for minutes, 'h' for hours or 'd' for days.
This option has been added in November 2019. Using other format than Maildir is considered as experimental in docker-mailserver and should only be used for testing purpose. For more details, please refer to Dovecot Documentation.
"},{"location":"config/environment/#postfix_reject_unknown_client_hostname","title":"POSTFIX_REJECT_UNKNOWN_CLIENT_HOSTNAME","text":"If enabled, employs reject_unknown_client_hostname to sender restrictions in Postfix's configuration.
Note: More details at http://www.postfix.org/postconf.5.html#inet_protocols
"},{"location":"config/environment/#dovecot_inet_protocols","title":"DOVECOT_INET_PROTOCOLS","text":"Note: More information at https://dovecot.org/doc/dovecot-example.conf
"},{"location":"config/environment/#move_spam_to_junk","title":"MOVE_SPAM_TO_JUNK","text":"When enabled, e-mails marked with the
X-Spam: Yes header added by RspamdX-Spam-Flag: YES header added by SpamAssassin (requires SPAMASSASSIN_SPAM_TO_INBOX=1)will be automatically moved to the Junk folder (with the help of a Sieve script).
Junk folder.Enable or disable Rspamd.
Explicit control over running a Redis instance within the container. By default, this value will match what is set for ENABLE_RSPAMD.
The purpose of this setting is to opt-out of starting an internal Redis instance when enabling Rspamd, replacing it with your own external instance.
Configuring Rspamd for an external Redis instanceYou will need to provide configuration at /etc/rspamd/local.d/redis.conf similar to:
servers = \"redis.example.test:6379\";\nexpand_keys = true;\nControls whether the Rspamd Greylisting module is enabled. This module can further assist in avoiding spam emails by greylisting e-mails with a certain spam score.
When enabled,
Attention
As of now, the spam learning database is global (i.e. available to all users). If one user deliberately trains it with malicious data, then it will ruin your detection rate.
This feature is suitably only for users who can tell ham from spam and users that can be trusted.
Can be used to enable or disable the Hfilter group module. This is used by DMS to adjust the HFILTER_HOSTNAME_UNKNOWN symbol, increasing its default weight to act similar to Postfix's reject_unknown_client_hostname, without the need to outright reject a message.
Can be used to control the score when the HFILTER_HOSTNAME_UNKNOWN symbol applies. A higher score is more punishing. Setting it to 15 (the default score for rejecting an e-mail) is equivalent to rejecting the email when the check fails.
Default: 6 (which corresponds to the add_header action)
Enables regular Postfix log summary (\"pflogsumm\") mail reports.
This is a new option. The old REPORT options are still supported for backwards compatibility. If this is not set and reports are enabled with the old options, logrotate will be used.
"},{"location":"config/environment/#pflogsumm_recipient","title":"PFLOGSUMM_RECIPIENT","text":"Recipient address for Postfix log summary reports.
Sender address (FROM) for pflogsumm reports (if Postfix log summary reports are enabled).
Interval for logwatch report.
Recipient address for logwatch reports if they are enabled.
Sender address (FROM) for logwatch reports if logwatch reports are enabled.
Defines who receives reports (if they are enabled).
Defines who sends reports (if they are enabled).
mailserver-report@<YOUR DOMAIN>Changes the interval in which log files are rotated.
Note
LOGROTATE_INTERVAL only manages logrotate within the container for services we manage internally.
The entire log output for the container is still available via docker logs mailserver (or your respective container name). If you want to configure external log rotation for that container output as well, : Docker Logging Drivers.
By default, the logs are lost when the container is destroyed (eg: re-creating via docker compose down && docker compose up -d). To keep the logs, mount a volume (to /var/log/mail/).
Note
This variable can also determine the interval for Postfix's log summary reports, see PFLOGSUMM_TRIGGER.
SA_SPAM_SUBJECT.KAM is a 3rd party SpamAssassin ruleset, provided by the McGrail Foundation. If SpamAssassin is enabled, KAM can be used in addition to the default ruleset.
Note: this SpamAssassin setting needs ENABLE_SPAMASSASSIN=1
Note: this SpamAssassin setting needs ENABLE_SPAMASSASSIN=1
This SpamAssassin setting needs ENABLE_SPAMASSASSIN=1
By default, DMS is configured to quarantine spam emails.
If emails are quarantined, they are compressed and stored in a location dependent on the ONE_DIR setting above. To inhibit this behaviour and deliver spam emails, set this to a very high value e.g. 100.0.
If ONE_DIR=1 (default) the location is /var/mail-state/lib-amavis/virusmails/, or if ONE_DIR=0: /var/lib/amavis/virusmails/. These paths are inside the docker container.
Note: this SpamAssassin setting needs ENABLE_SPAMASSASSIN=1. Add the SpamAssassin score to the subject line by inserting the keyword _SCORE_: ***SPAM(_SCORE_)***.
This will uncomment the respective line in /etc/spamassasin/local.cf
Note: activate this only if you are confident in your bayes database for identifying spam.
"},{"location":"config/environment/#sa_shortcircuit_bayes_ham","title":"SA_SHORTCIRCUIT_BAYES_HAM","text":"This will uncomment the respective line in /etc/spamassasin/local.cf
Note: activate this only if you are confident in your bayes database for identifying ham.
"},{"location":"config/environment/#fetchmail","title":"Fetchmail","text":""},{"location":"config/environment/#enable_fetchmail","title":"ENABLE_FETCHMAIL","text":"fetchmail disabledfetchmail enabledfetchmail The number of seconds for the interval0 => fetchmail runs with a single config file /etc/fetchmailrc 1 => /etc/fetchmailrc is split per poll entry. For every poll entry a separate fetchmail instance is started to allow having multiple imap idle configurations defined.
Note: The defaults of your fetchmailrc file need to be at the top of the file. Otherwise it won't be added correctly to all separate fetchmail instances.
Deprecated. See ACCOUNT_PROVISIONER.
ldaps://mail.example.comcompose.yaml you can set the service name here(&(mail=%s)(mailEnabled=TRUE))(&(mailGroupMember=%s)(mailEnabled=TRUE))(&(mailAlias=%s)(mailEnabled=TRUE))(&(|(mail=*@%s)(mailalias=*@%s)(mailGroupMember=*@%s))(mailEnabled=TRUE))(|($LDAP_QUERY_FILTER_USER)($LDAP_QUERY_FILTER_ALIAS)($LDAP_QUERY_FILTER_GROUP))The following variables overwrite the default values for /etc/dovecot/dovecot-ldap.conf.ext.
LDAP_SEARCH_BASEou=people,dc=domain,dc=com)SSHALDAP_BIND_DNcn=admin,dc=domain,dc=com)LDAP_BIND_PWDOVECOT_DN.LDAP_SERVER_HOSTldap:// will be used.DOVECOT_HOSTS (as it didn't allow to use LDAPS), which is currently still supported for backwards compatibility.(&(objectClass=PostfixBookMailAccount)(uniqueIdentifier=%n))homeDirectory=home,qmailUID=uid,qmailGID=gid,mailMessageStore=mail(&(objectClass=PostfixBookMailAccount)(uniqueIdentifier=%n))DOVECOT_USER_FILTERuid=user,userPassword=passwordpostgrey is disabledpostgrey is enabledNote: This postgrey setting needs ENABLE_POSTGREY=1
Note: This postgrey setting needs ENABLE_POSTGREY=1
Note: This postgrey setting needs ENABLE_POSTGREY=1
Note: This postgrey setting needs ENABLE_POSTGREY=1
saslauthd is disabledsaslauthd is enabledldap => authenticate against ldap servershadow => authenticate against local user dbmysql => authenticate against mysql dbrimap => authenticate against imap serverLDAP_SERVER_HOSTnoyes => Enable ldap_start_tls optionnoyes => Enable ldap_tls_check_peer optionPath to directory with CA (Certificate Authority) certificates.
ldap_tls_cacert_dir optionFile containing CA (Certificate Authority) certificate(s).
ldap_tls_cacert_file optionLDAP_BIND_DNLDAP_BIND_PWLDAP_SEARCH_BASE(&(uniqueIdentifier=%u)(mailEnabled=TRUE))(&(sAMAccountName=%U)(objectClass=person))(&(uid=%U)(objectClass=person))Specify what password attribute to use for password verification.
userPassword by default.ldap_password_attr optionbind will be used as a default valuefastbind => The fastbind method is usedcustom => The custom method uses userPassword attribute to verify the passwordSpecify the authentication mechanism for SASL bind.
ldap_mech optionAn email has an \"envelope\" sender (indicating the sending server) and a \"header\" sender (indicating who sent it). More strict SPF policies may require you to replace both instead of just the envelope sender.
More info.
dd if=/dev/urandom bs=24 count=1 2>/dev/null | base64OVERRIDE_HOSTNAME, $DOMAINNAME (internal), or the container's hostname[example.com]:587 (don't forget the brackets if you need this to be compatible with $RELAY_USER and $RELAY_PASSWORD, explained below).If you want to use POP3(S), you have to add the ports 110 and/or 995 (TLS secured) and the environment variable ENABLE_POP3 to your compose.yaml:
mailserver:\nports:\n- \"25:25\" # SMTP (explicit TLS => STARTTLS)\n- \"143:143\" # IMAP4 (explicit TLS => STARTTLS)\n- \"465:465\" # ESMTP (implicit TLS)\n- \"587:587\" # ESMTP (explicit TLS => STARTTLS)\n- \"993:993\" # IMAP4 (implicit TLS)\n- \"110:110\" # POP3\n- \"995:995\" # POP3 (with TLS)\nenvironment:\n- ENABLE_POP3=1\nNote
setup.sh is not required. We encourage you to use docker exec -ti <CONTAINER NAME> setup instead.
Warning
This script assumes Docker or Podman is used. You will not be able to use setup.sh with other container orchestration tools.
setup.sh is a script that is complimentary to the internal setup command in DMS.
It mostly provides the convenience of aliasing docker exec -ti <CONTAINER NAME> setup, inferring the container name of a running DMS instance or running a new instance and bind mounting necessary volumes implicitly.
It is intended to be run from the host machine, not from inside your running container. The latest version of the script is included in the DMS repository. You may retrieve it at any time by running this command in your console:
wget https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master/setup.sh\nchmod a+x ./setup.sh\nFor more information on using the script run: ./setup.sh help.
Users (email accounts) are managed in /tmp/docker-mailserver/postfix-accounts.cf. The best way to manage accounts is to use the reliable setup command inside the container. Just run docker exec <CONTAINER NAME> setup help and have a look at the section about subcommands, specifically the email subcommand.
setup inside the container","text":"You can add an account by running docker exec -ti <CONTAINER NAME> setup email add <NEW ADDRESS>. This method is strongly preferred.
Warning
This method is discouraged!
Alternatively, you may directly add the full email address and its encrypted password, separated by a pipe. To generate a new mail account data, directly from your host, you could for example run the following:
docker run --rm -it \\\n--env MAIL_USER=user1@example.com \\\n--env MAIL_PASS=mypassword \\\nghcr.io/docker-mailserver/docker-mailserver:latest \\\n/bin/bash -c \\\n'echo \"${MAIL_USER}|$(doveadm pw -s SHA512-CRYPT -u ${MAIL_USER} -p ${MAIL_PASS})\" >>docker-data/dms/config/postfix-accounts.cf'\nYou will then be asked for a password, and be given back the data for a new account entry, as text. To actually add this new account, just copy all the output text in docker-data/dms/config/postfix-accounts.cf file of your running container.
The result could look like this:
user1@example.com|{SHA512-CRYPT}$6$2YpW1nYtPBs2yLYS$z.5PGH1OEzsHHNhl3gJrc3D.YMZkvKw/vp.r5WIiwya6z7P/CQ9GDEJDr2G2V0cAfjDFeAQPUoopsuWPXLk3u1\nimap-quota is enabled and allow clients to query their mailbox usage.The best way to manage aliases is to use the reliable setup script inside the container. Just run docker exec <CONTAINER NAME> setup help and have a look at the section about subcommands, specifically the alias-subcommand.
You may read Postfix's documentation on virtual aliases first. Aliases are managed in /tmp/docker-mailserver/postfix-virtual.cf. An alias is a full email address that will either be:
/tmp/docker-mailserver/postfix-accounts.cfAlias and target are space separated. An example on a server with example.com as its domain:
# Alias delivered to an existing account\nalias1@example.com user1@example.com\n\n# Alias forwarded to an external email address\nalias2@example.com external-account@gmail.com\nAdditional regexp aliases can be configured by placing them into docker-data/dms/config/postfix-regexp.cf. The regexp aliases get evaluated after the virtual aliases (container path: /tmp/docker-mailserver/postfix-virtual.cf). For example, the following docker-data/dms/config/postfix-regexp.cf causes all email sent to \"test\" users to be delivered to qa@example.com instead:
/^test[0-9][0-9]*@example.com/ qa@example.com\nPostfix supports so-called address tags, in the form of plus (+) tags - i.e. address+tag@example.com will end up at address@example.com. This is configured by default and the (configurable!) separator is set to +. For more info, see Postfix's official documentation.
Note
If you do decide to change the configurable separator, you must add the same line to both docker-data/dms/config/postfix-main.cf and docker-data/dms/config/dovecot.cf, because Dovecot is acting as the delivery agent. For example, to switch to -, add:
recipient_delimiter = -\nGetting started with ldap and DMS we need to take 3 parts in account:
postfix for incoming & outgoing emaildovecot for accessing mailboxessaslauthd for SMTP authentication (this can also be delegated to dovecot)Have a look at the ENV page for information on the default values.
"},{"location":"config/advanced/auth-ldap/#ldap_query_filter_","title":"LDAP_QUERY_FILTER_*","text":"Those variables contain the LDAP lookup filters for postfix, using %s as the placeholder for the domain or email address in question. This means that...
DOMAIN filter (see virtual_alias_domains).USER, ALIAS and GROUP filters.USER filter specifies personal mailboxes, for which only one should exist per address, for example (mail=%s) (also see virtual_mailbox_maps)ALIAS filter specifies aliases for mailboxes, using virtual_alias_maps, for example (mailAlias=%s)GROUP filter specifies the personal mailboxes in a group (for emails that multiple people shall receive), using virtual_alias_maps, for example (mailGroupMember=%s).ALIAS and GROUP, but ideally you should use ALIAS for personal aliases for a singular person (like ceo@example.org) and GROUP for multiple people (like hr@example.org).SENDERS filter, and only if the authenticated user is one of the returned entries, the email can be sent.SPOOF_PROTECTION=1.SENDERS filter is missing, the USER, ALIAS and GROUP filters will be used in in a disjunction (OR).admin group to spoof any sender email address, and to force everyone else to only use their personal mailbox address for outgoing email, you can use something like this: (|(memberOf=cn=admin,*)(mail=%s))A really simple LDAP_QUERY_FILTER configuration, using only the user filter and allowing only admin@* to spoof any sender addresses.
- ENABLE_LDAP=1 # with the :edge tag, use ACCOUNT_PROVISIONER\n- LDAP_START_TLS=yes\n- ACCOUNT_PROVISIONER=LDAP\n- LDAP_SERVER_HOST=ldap.example.org\n- LDAP_SEARCH_BASE=dc=example,dc=org\"\n- LDAP_BIND_DN=cn=admin,dc=example,dc=org\n- LDAP_BIND_PW=mypassword\n- SPOOF_PROTECTION=1\n\n- LDAP_QUERY_FILTER_DOMAIN=(mail=*@%s)\n- LDAP_QUERY_FILTER_USER=(mail=%s)\n- LDAP_QUERY_FILTER_ALIAS=(|) # doesn't match anything\n- LDAP_QUERY_FILTER_GROUP=(|) # doesn't match anything\n- LDAP_QUERY_FILTER_SENDERS=(|(mail=%s)(mail=admin@*))\nDOVECOT_*_FILTER & DOVECOT_*_ATTRS","text":"These variables specify the LDAP filters that dovecot uses to determine if a user can log in to their IMAP account, and which mailbox is responsible to receive email for a specific postfix user.
This is split into the following two lookups, both using %u as the placeholder for the full login name (see dovecot documentation for a full list of placeholders). Usually you only need to set DOVECOT_USER_FILTER, in which case it will be used for both filters.
DOVECOT_USER_FILTER is used to get the account details (uid, gid, home directory, quota, ...) of a user.DOVECOT_PASS_FILTER is used to get the password information of the user, and is in pretty much all cases identical to DOVECOT_USER_FILTER (which is the default behaviour if left away).If your directory doesn't have the postfix-book schema installed, then you must change the internal attribute handling for dovecot. For this you have to change the pass_attr and the user_attr mapping, as shown in the example below:
- DOVECOT_PASS_ATTRS=<YOUR_USER_IDENTIFIER_ATTRIBUTE>=user,<YOUR_USER_PASSWORD_ATTRIBUTE>=password\n- DOVECOT_USER_ATTRS=<YOUR_USER_HOME_DIRECTORY_ATTRIBUTE>=home,<YOUR_USER_MAILSTORE_ATTRIBUTE>=mail,<YOUR_USER_MAIL_UID_ATTRIBUTE>=uid,<YOUR_USER_MAIL_GID_ATTRIBUTE>=gid\nNote
For DOVECOT_*_ATTRS, you can replace ldapAttr=dovecotAttr with =dovecotAttr=%{ldap:ldapAttr} for more flexibility, like for example =home=/var/mail/%{ldap:uid} or just =uid=5000.
A list of dovecot attributes can be found in the dovecot documentation.
Defaults- DOVECOT_USER_ATTRS=mailHomeDirectory=home,mailUidNumber=uid,mailGidNumber=gid,mailStorageDirectory=mail\n- DOVECOT_PASS_ATTRS=uniqueIdentifier=user,userPassword=password\n- DOVECOT_USER_FILTER=(&(objectClass=PostfixBookMailAccount)(uniqueIdentifier=%n))\nSetup for a directory that has the qmail-schema installed and uses uid:
- DOVECOT_PASS_ATTRS=uid=user,userPassword=password\n- DOVECOT_USER_ATTRS=homeDirectory=home,qmailUID=uid,qmailGID=gid,mailMessageStore=mail\n- DOVECOT_USER_FILTER=(&(objectClass=qmailUser)(uid=%u)(accountStatus=active))\nThe LDAP server configuration for dovecot will be taken mostly from postfix, other options can be found in the environment section in the docs.
"},{"location":"config/advanced/auth-ldap/#dovecot_auth_bind","title":"DOVECOT_AUTH_BIND","text":"Set this to yes to enable authentication binds (more details in the dovecot documentation). Currently, only DN lookup is supported without further changes to the configuration files, so this is only useful when you want to bind as a readonly user without the permission to read passwords.
SASLAUTHD_LDAP_FILTER","text":"This filter is used for saslauthd, which is called by postfix when someone is authenticating through SMTP (assuming that SASLAUTHD_MECHANISMS=ldap is being used). Note that you'll need to set up the LDAP server for saslauthd separately from postfix.
The filter variables are explained in detail in the LDAP_SASLAUTHD file, but unfortunately, this method doesn't really support domains right now - that means that %U is the only token that makes sense in this variable.
When to use this and how to avoid it
Using a separate filter for SMTP authentication allows you to for example allow noreply@example.org to send email, but not log in to IMAP or receive email: (&(mail=%U@example.org)(|(memberOf=cn=email,*)(mail=noreply@example.org)))
If you don't want to use a separate filter for SMTP authentication, you can set SASLAUTHD_MECHANISMS=rimap and SASLAUTHD_MECH_OPTIONS=127.0.0.1 to authenticate against dovecot instead - this means that the DOVECOT_USER_FILTER and DOVECOT_PASS_FILTER will be used for SMTP authentication as well.
saslauthd - ENABLE_SASLAUTHD=1\n- SASLAUTHD_MECHANISMS=ldap\n- SASLAUTHD_LDAP_FILTER=(mail=%U@example.org)\nTo enable LDAPS, all you need to do is to add the protocol to LDAP_SERVER_HOST, for example ldaps://example.org:636.
To enable LDAP over StartTLS (on port 389), you need to set the following environment variables instead (the protocol must not be ldaps:// in this case!):
- LDAP_START_TLS=yes\n- DOVECOT_TLS=yes\n- SASLAUTHD_LDAP_START_TLS=yes\nIn addition to LDAP explanation above, when Docker Mailserver is intended to be used with Active Directory (or the equivalent implementations like Samba4 AD DC) the following points should be taken into consideration:
sAMAccountName.proxyAddresses can be used to store email aliases of single users. The convention is to prefix the email aliases with smtp: (e.g: smtp:some.name@example.com).uidNumber, gidNumber instead of the typical uid. Assigning different owner to email folders can also be done in this approach, nevertheless there is a bug at the moment in Docker Mailserver that overwrites all permissions when starting the container. Either a manual fix is necessary now, or a temporary workaround to use a hard-coded ldap:uidNumber that equals to 5000 until this issue is fixed.user-patches.sh script to modify ldap-groups.cf so that it includes leaf_result_attribute = mail and special_result_attribute = member. This can be achieved simply by:The configuration shown to get the Group to work is from here and here.
# user-patches.sh\n\n...\ngrep -q '^leaf_result_attribute = mail$' /etc/postfix/ldap-groups.cf || echo \"leaf_result_attribute = mail\" >> /etc/postfix/ldap-groups.cf\ngrep -q '^special_result_attribute = member$' /etc/postfix/ldap-groups.cf || echo \"special_result_attribute = member\" >> /etc/postfix/ldap-groups.cf\n...\n/etc/ldap/ldap.conf, if the TLS_REQCERT is demand / hard (default), the CA certificate used to verify the LDAP server certificate must be recognized as a trusted CA. This can be done by volume mounting the ca.crt file and updating the trust store via a user-patches.sh script:# user-patches.sh\n\n...\ncp /MOUNTED_FOLDER/ca.crt /usr/local/share/ca-certificates/\nupdate-ca-certificates\n...\nThe changes on the configurations necessary to work with Active Directory (only changes are listed, the rest of the LDAP configuration can be taken from the other examples shown in this documentation):
# If StartTLS is the chosen method to establish a secure connection with Active Directory.\n- LDAP_START_TLS=yes\n- SASLAUTHD_LDAP_START_TLS=yes\n- DOVECOT_TLS=yes\n\n- LDAP_QUERY_FILTER_USER=(&(objectclass=person)(mail=%s))\n- LDAP_QUERY_FILTER_ALIAS=(&(objectclass=person)(proxyAddresses=smtp:%s))\n# Filters Active Directory groups (mail lists). Additional changes on ldap-groups.cf are also required as shown above.\n- LDAP_QUERY_FILTER_GROUP=(&(objectClass=group)(mail=%s))\n- LDAP_QUERY_FILTER_DOMAIN=(mail=*@%s)\n# Allows only Domain admins to send any sender email address, otherwise the sender address must match the LDAP attribute `mail`.\n- SPOOF_PROTECTION=1\n- LDAP_QUERY_FILTER_SENDERS=(|(mail=%s)(proxyAddresses=smtp:%s)(memberOf=cn=Domain Admins,cn=Users,dc=*))\n\n- DOVECOT_USER_FILTER=(&(objectclass=person)(sAMAccountName=%n))\n# At the moment to be able to use %{ldap:uidNumber}, a manual bug fix as described above must be used. Otherwise %{ldap:uidNumber} %{ldap:uidNumber} must be replaced by the hard-coded value 5000.\n- DOVECOT_USER_ATTRS==uid=%{ldap:uidNumber},=gid=5000,=home=/var/mail/%Ln,=mail=maildir:~/Maildir\n- DOVECOT_PASS_ATTRS=sAMAccountName=user,userPassword=password\n- SASLAUTHD_LDAP_FILTER=(&(sAMAccountName=%U)(objectClass=person))\nservices:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\nhostname: mail.example.com\n\nports:\n- \"25:25\"\n- \"143:143\"\n- \"587:587\"\n- \"993:993\"\n\nvolumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/mail-state/:/var/mail-state/\n- ./docker-data/dms/mail-logs/:/var/log/mail/\n- ./docker-data/dms/config/:/tmp/docker-mailserver/\n- /etc/localtime:/etc/localtime:ro\n\nenvironment:\n- ENABLE_SPAMASSASSIN=1\n- ENABLE_CLAMAV=1\n- ENABLE_FAIL2BAN=1\n- ENABLE_POSTGREY=1\n\n# >>> Postfix LDAP Integration\n- ENABLE_LDAP=1 # with the :edge tag, use ACCOUNT_PROVISIONER\n- ACCOUNT_PROVISIONER=LDAP\n- LDAP_SERVER_HOST=ldap.example.org\n- LDAP_BIND_DN=cn=admin,ou=users,dc=example,dc=org\n- LDAP_BIND_PW=mypassword\n- LDAP_SEARCH_BASE=dc=example,dc=org\n- LDAP_QUERY_FILTER_DOMAIN=(|(mail=*@%s)(mailAlias=*@%s)(mailGroupMember=*@%s))\n- LDAP_QUERY_FILTER_USER=(&(objectClass=inetOrgPerson)(mail=%s))\n- LDAP_QUERY_FILTER_ALIAS=(&(objectClass=inetOrgPerson)(mailAlias=%s))\n- LDAP_QUERY_FILTER_GROUP=(&(objectClass=inetOrgPerson)(mailGroupMember=%s))\n- LDAP_QUERY_FILTER_SENDERS=(&(objectClass=inetOrgPerson)(|(mail=%s)(mailAlias=%s)(mailGroupMember=%s)))\n- SPOOF_PROTECTION=1\n# <<< Postfix LDAP Integration\n\n# >>> Dovecot LDAP Integration\n- DOVECOT_USER_FILTER=(&(objectClass=inetOrgPerson)(mail=%u))\n- DOVECOT_PASS_ATTRS=uid=user,userPassword=password\n- DOVECOT_USER_ATTRS==home=/var/mail/%{ldap:uid},=mail=maildir:~/Maildir,uidNumber=uid,gidNumber=gid\n# <<< Dovecot LDAP Integration\n\n# >>> SASL LDAP Authentication\n- ENABLE_SASLAUTHD=1\n- SASLAUTHD_MECHANISMS=ldap\n- SASLAUTHD_LDAP_FILTER=(&(mail=%U@example.org)(objectClass=inetOrgPerson))\n# <<< SASL LDAP Authentication\n\n- SSL_TYPE=letsencrypt\n- PERMIT_DOCKER=host\n\ncap_add:\n- NET_ADMIN\nservices:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\nhostname: mail.example.com\n\nports:\n- \"25:25\"\n- \"143:143\"\n- \"587:587\"\n- \"993:993\"\n\nvolumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/mail-state/:/var/mail-state/\n- ./docker-data/dms/config/:/tmp/docker-mailserver/\n\nenvironment:\n# We are not using dovecot here\n- SMTP_ONLY=1\n- ENABLE_SPAMASSASSIN=1\n- ENABLE_CLAMAV=1\n- ENABLE_FAIL2BAN=1\n- ENABLE_POSTGREY=1\n- SASLAUTHD_PASSWD=\n\n# >>> SASL Authentication\n- ENABLE_SASLAUTHD=1\n- SASLAUTHD_LDAP_FILTER=(&(sAMAccountName=%U)(objectClass=person))\n- SASLAUTHD_MECHANISMS=ldap\n# <<< SASL Authentication\n\n# >>> Postfix Ldap Integration\n- ENABLE_LDAP=1 # with the :edge tag, use ACCOUNT_PROVISIONER\n- ACCOUNT_PROVISIONER=LDAP\n- LDAP_SERVER_HOST=<yourLdapContainer/yourLdapServer>\n- LDAP_SEARCH_BASE=dc=mydomain,dc=loc\n- LDAP_BIND_DN=cn=Administrator,cn=Users,dc=mydomain,dc=loc\n- LDAP_BIND_PW=mypassword\n- LDAP_QUERY_FILTER_USER=(&(objectClass=user)(mail=%s))\n- LDAP_QUERY_FILTER_GROUP=(&(objectclass=group)(mail=%s))\n- LDAP_QUERY_FILTER_ALIAS=(&(objectClass=user)(otherMailbox=%s))\n- LDAP_QUERY_FILTER_DOMAIN=(&(|(mail=*@%s)(mailalias=*@%s)(mailGroupMember=*@%s))(mailEnabled=TRUE))\n# <<< Postfix Ldap Integration\n\n# >>> Kopano Integration\n- POSTFIX_DAGENT=lmtp:kopano:2003\n# <<< Kopano Integration\n\n- SSL_TYPE=letsencrypt\n- PERMIT_DOCKER=host\n\ncap_add:\n- NET_ADMIN\nA dovecot master account is able to login as any configured user. This is useful for administrative tasks like hot backups.
"},{"location":"config/advanced/dovecot-master-accounts/#configuration","title":"Configuration","text":"It is possible to create, update, delete and list dovecot master accounts using setup.sh. See setup.sh help for usage.
This feature is presently not supported with LDAP.
"},{"location":"config/advanced/dovecot-master-accounts/#logging-in","title":"Logging in","text":"Once a master account is configured, it is possible to connect to any users mailbox using this account. Log in over POP3/IMAP using the following credential scheme:
Username: <EMAIL ADDRESS>*<MASTER ACCOUNT NAME>
Password: <MASTER ACCOUNT PASSWORD>
Full-text search allows all messages to be indexed, so that mail clients can quickly and efficiently search messages by their full text content. Dovecot supports a variety of community supported FTS indexing backends.
DMS comes pre-installed with two plugins that can be enabled with a dovecot config file.
Please be aware that indexing consumes memory and takes up additional disk space.
"},{"location":"config/advanced/full-text-search/#xapian","title":"Xapian","text":"The dovecot-fts-xapian plugin makes use of Xapian. Xapian enables embedding an FTS engine without the need for additional backends.
The indexes will be stored as a subfolder named xapian-indexes inside your local mail-data folder (/var/mail internally). With the default settings, 10GB of email data may generate around 4GB of indexed data.
While indexing is memory intensive, you can configure the plugin to limit the amount of memory consumed by the index workers. With Xapian being small and fast, this plugin is a good choice for low memory environments (2GB) as compared to Solr.
"},{"location":"config/advanced/full-text-search/#setup","title":"Setup","text":"To configure fts-xapian as a dovecot plugin, create a file at docker-data/dms/config/dovecot/fts-xapian-plugin.conf and place the following in it:
mail_plugins = $mail_plugins fts fts_xapian\n\nplugin {\n fts = xapian\n fts_xapian = partial=3 full=20 verbose=0\n\n fts_autoindex = yes\n fts_enforced = yes\n\n # disable indexing of folders\n # fts_autoindex_exclude = \\Trash\n\n # Index attachements\n # fts_decoder = decode2text\n}\n\nservice indexer-worker {\n # limit size of indexer-worker RAM usage, ex: 512MB, 1GB, 2GB\n vsz_limit = 1GB\n}\n\n# service decode2text {\n# executable = script /usr/libexec/dovecot/decode2text.sh\n# user = dovecot\n# unix_listener decode2text {\n# mode = 0666\n# }\n# }\nadjust the settings to tune for your desired memory limits, exclude folders and enable searching text inside of attachments
Update compose.yaml to load the previously created dovecot plugin config file:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\nhostname: mail.example.com\nenv_file: mailserver.env\nports:\n- \"25:25\" # SMTP (explicit TLS => STARTTLS)\n- \"143:143\" # IMAP4 (explicit TLS => STARTTLS)\n- \"465:465\" # ESMTP (implicit TLS)\n- \"587:587\" # ESMTP (explicit TLS => STARTTLS)\n- \"993:993\" # IMAP4 (implicit TLS)\nvolumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/mail-state/:/var/mail-state/\n- ./docker-data/dms/mail-logs/:/var/log/mail/\n- ./docker-data/dms/config/:/tmp/docker-mailserver/\n- ./docker-data/dms/config/dovecot/fts-xapian-plugin.conf:/etc/dovecot/conf.d/10-plugin.conf:ro\n- /etc/localtime:/etc/localtime:ro\nrestart: always\nstop_grace_period: 1m\ncap_add:\n- NET_ADMIN\nRecreate containers:
docker compose down\ndocker compose up -d\nInitialize indexing on all users for all mail:
docker compose exec mailserver doveadm index -A -q \\*\nRun the following command in a daily cron job:
docker compose exec mailserver doveadm fts optimize -A\ncron from within DMS to avoid potential errors if the mail server is not running: Create a system cron file:
# in the compose.yaml root directory\nmkdir -p ./docker-data/dms/cron # if you didn't have this folder before\ntouch ./docker-data/dms/cron/fts_xapian\nchown root:root ./docker-data/dms/cron/fts_xapian\nchmod 0644 ./docker-data/dms/cron/fts_xapian\nEdit the system cron file nano ./docker-data/dms/cron/fts_xapian, and set an appropriate configuration:
# Adding `MAILTO=\"\"` prevents cron emailing notifications of the task outcome each run\nMAILTO=\"\"\n#\n# m h dom mon dow user command\n#\n# Everyday 4:00AM, optimize index files\n0 4 * * * root doveadm fts optimize -A\nThen with compose.yaml:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\nvolumes:\n- ./docker-data/dms/cron/fts_xapian:/etc/cron.d/fts_xapian\nThe dovecot-solr Plugin is used in conjunction with Apache Solr running in a separate container. This is quite straightforward to setup using the following instructions.
Solr is a mature and fast indexing backend that runs on the JVM. The indexes are relatively compact compared to the size of your total email.
However, Solr also requires a fair bit of RAM. While Solr is highly tuneable, it may require a bit of testing to get it right.
"},{"location":"config/advanced/full-text-search/#setup_1","title":"Setup","text":"compose.yaml:
solr:\nimage: lmmdock/dovecot-solr:latest\nvolumes:\n- ./docker-data/dms/config/dovecot/solr-dovecot:/opt/solr/server/solr/dovecot\nrestart: always\n\nmailserver:\ndepends_on:\n- solr\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\n...\nvolumes:\n...\n- ./docker-data/dms/config/dovecot/10-plugin.conf:/etc/dovecot/conf.d/10-plugin.conf:ro\n...\n./docker-data/dms/config/dovecot/10-plugin.conf:
mail_plugins = $mail_plugins fts fts_solr\n\nplugin {\nfts = solr\nfts_autoindex = yes\nfts_solr = url=http://solr:8983/solr/dovecot/\n}\nRecreate containers: docker compose down ; docker compose up -d
Flag all user mailbox FTS indexes as invalid, so they are rescanned on demand when they are next searched: docker compose exec mailserver doveadm fts rescan -A
See #905
"},{"location":"config/advanced/ipv6/","title":"Advanced | IPv6","text":""},{"location":"config/advanced/ipv6/#background","title":"Background","text":"If your container host supports IPv6, then DMS will automatically accept IPv6 connections by way of the docker host's IPv6. However, incoming mail will fail SPF checks because they will appear to come from the IPv4 gateway that docker is using to proxy the IPv6 connection (172.20.0.1 is the gateway).
This can be solved by supporting IPv6 connections all the way to the DMS container.
"},{"location":"config/advanced/ipv6/#setup-steps","title":"Setup steps","text":"+++ b/serv/compose.yaml\n@@ ... @@ services:\n\n+ ipv6nat:\n+ image: robbertkl/ipv6nat\n+ restart: always\n+ network_mode: \"host\"\n+ cap_add:\n+ - NET_ADMIN\n+ - SYS_MODULE\n+ volumes:\n+ - /var/run/docker.sock:/var/run/docker.sock:ro\n+ - /lib/modules:/lib/modules:ro\n\n@@ ... @@ networks:\n\n+ default:\n+ driver: bridge\n+ enable_ipv6: true\n+ ipam:\n+ driver: default\n+ config:\n+ - subnet: fd00:0123:4567::/48\n+ gateway: fd00:0123:4567::1\nSee #1438
"},{"location":"config/advanced/kubernetes/","title":"Advanced | Kubernetes","text":""},{"location":"config/advanced/kubernetes/#introduction","title":"Introduction","text":"This article describes how to deploy DMS to Kubernetes. Please note that there is also a Helm chart available.
Requirements
We assume basic knowledge about Kubernetes from the reader. Moreover, we assume the reader to have a basic understanding of mail servers. Ideally, the reader has deployed DMS before in an easier setup with Docker (Compose).
About Support for Kubernetes
Please note that Kubernetes is not officially supported and we do not build images specifically designed for it. When opening an issue, please remember that only Docker & Docker Compose are officially supported.
This content is entirely community-supported. If you find errors, please open an issue and provide a PR.
"},{"location":"config/advanced/kubernetes/#manifests","title":"Manifests","text":""},{"location":"config/advanced/kubernetes/#configuration","title":"Configuration","text":"We want to provide the basic configuration in the form of environment variables with a ConfigMap. Note that this is just an example configuration; tune the ConfigMap to your needs.
---\napiVersion: v1\nkind: ConfigMap\n\nmetadata:\nname: mailserver.environment\n\nimmutable: false\n\ndata:\nTLS_LEVEL: modern\nPOSTSCREEN_ACTION: drop\nOVERRIDE_HOSTNAME: mail.example.com\nFAIL2BAN_BLOCKTYPE: drop\nPOSTMASTER_ADDRESS: postmaster@example.com\nUPDATE_CHECK_INTERVAL: 10d\nPOSTFIX_INET_PROTOCOLS: ipv4\nONE_DIR: '1'\nENABLE_CLAMAV: '1'\nENABLE_POSTGREY: '0'\nENABLE_FAIL2BAN: '1'\nAMAVIS_LOGLEVEL: '-1'\nSPOOF_PROTECTION: '1'\nMOVE_SPAM_TO_JUNK: '1'\nENABLE_UPDATE_CHECK: '1'\nENABLE_SPAMASSASSIN: '1'\nSUPERVISOR_LOGLEVEL: warn\nSPAMASSASSIN_SPAM_TO_INBOX: '1'\n\n# here, we provide an example for the SSL configuration\nSSL_TYPE: manual\nSSL_CERT_PATH: /secrets/ssl/rsa/tls.crt\nSSL_KEY_PATH: /secrets/ssl/rsa/tls.key\nWe can also make use of user-provided configuration files, e.g. user-patches.sh, postfix-accounts.cf and more, to adjust DMS to our likings. We encourage you to have a look at Kustomize for creating ConfigMaps from multiple files, but for now, we will provide a simple, hand-written example. This example is absolutely minimal and only goes to show what can be done.
---\napiVersion: v1\nkind: ConfigMap\n\nmetadata:\nname: mailserver.files\n\ndata:\npostfix-accounts.cf: |\ntest@example.com|{SHA512-CRYPT}$6$someHashValueHere\nother@example.com|{SHA512-CRYPT}$6$someOtherHashValueHere\nStatic Configuration
With the configuration shown above, you can not dynamically add accounts as the configuration file mounted into the mail server can not be written to.
Use persistent volumes for production deployments.
"},{"location":"config/advanced/kubernetes/#persistence","title":"Persistence","text":"Thereafter, we need persistence for our data. Make sure you have a storage provisioner and that you choose the correct storageClassName.
---\napiVersion: v1\nkind: PersistentVolumeClaim\n\nmetadata:\nname: data\n\nspec:\nstorageClassName: local-path\naccessModes:\n- ReadWriteOnce\nresources:\nrequests:\nstorage: 25Gi\nA Service is required for getting the traffic to the pod itself. The service is somewhat crucial. Its configuration determines whether the original IP from the sender will be kept. More about this further down below.
The configuration you're seeing does keep the original IP, but you will not be able to scale this way. We have chosen to go this route in this case because we think most Kubernetes users will only want to have one instance.
---\napiVersion: v1\nkind: Service\n\nmetadata:\nname: mailserver\nlabels:\napp: mailserver\n\nspec:\ntype: LoadBalancer\n\nselector:\napp: mailserver\n\nports:\n# Transfer\n- name: transfer\nport: 25\ntargetPort: transfer\nprotocol: TCP\n# ESMTP with implicit TLS\n- name: esmtp-implicit\nport: 465\ntargetPort: esmtp-implicit\nprotocol: TCP\n# ESMTP with explicit TLS (STARTTLS)\n- name: esmtp-explicit\nport: 587\ntargetPort: esmtp-explicit\nprotocol: TCP\n# IMAPS with implicit TLS\n- name: imap-implicit\nport: 993\ntargetPort: imap-implicit\nprotocol: TCP\nLast but not least, the Deployment becomes the most complex component. It instructs Kubernetes how to run the DMS container and how to apply your ConfigMaps, persisted storage, etc. Additionally, we can set options to enforce runtime security here.
---\napiVersion: apps/v1\nkind: Deployment\n\nmetadata:\nname: mailserver\n\nannotations:\nignore-check.kube-linter.io/run-as-non-root: >-\n'mailserver' needs to run as root\nignore-check.kube-linter.io/privileged-ports: >-\n'mailserver' needs privilegdes ports\nignore-check.kube-linter.io/no-read-only-root-fs: >-\nThere are too many files written to make The\nroot FS read-only\n\nspec:\nreplicas: 1\nselector:\nmatchLabels:\napp: mailserver\n\ntemplate:\nmetadata:\nlabels:\napp: mailserver\n\nannotations:\ncontainer.apparmor.security.beta.kubernetes.io/mailserver: runtime/default\n\nspec:\nhostname: mail\ncontainers:\n- name: mailserver\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\nimagePullPolicy: IfNotPresent\n\nsecurityContext:\nallowPrivilegeEscalation: false\nreadOnlyRootFilesystem: false\nrunAsUser: 0\nrunAsGroup: 0\nrunAsNonRoot: false\nprivileged: false\ncapabilities:\nadd:\n# file permission capabilities\n- CHOWN\n- FOWNER\n- MKNOD\n- SETGID\n- SETUID\n- DAC_OVERRIDE\n# network capabilities\n- NET_ADMIN # needed for F2B\n- NET_RAW # needed for F2B\n- NET_BIND_SERVICE\n# miscellaneous capabilities\n- SYS_CHROOT\n- KILL\ndrop: [ALL]\nseccompProfile:\ntype: RuntimeDefault\n\n# You want to tune this to your needs. If you disable ClamAV,\n# you can use less RAM and CPU. This becomes important in\n# case you're low on resources and Kubernetes refuses to\n# schedule new pods.\nresources:\nlimits:\nmemory: 4Gi\ncpu: 1500m\nrequests:\nmemory: 2Gi\ncpu: 600m\n\nvolumeMounts:\n- name: files\nsubPath: postfix-accounts.cf\nmountPath: /tmp/docker-mailserver/postfix-accounts.cf\nreadOnly: true\n\n# PVCs\n- name: data\nmountPath: /var/mail\nsubPath: data\nreadOnly: false\n- name: data\nmountPath: /var/mail-state\nsubPath: state\nreadOnly: false\n- name: data\nmountPath: /var/log/mail\nsubPath: log\nreadOnly: false\n\n# certificates\n- name: certificates-rsa\nmountPath: /secrets/ssl/rsa/\nreadOnly: true\n\n# other\n- name: tmp-files\nmountPath: /tmp\nreadOnly: false\n\nports:\n- name: transfer\ncontainerPort: 25\nprotocol: TCP\n- name: esmtp-implicit\ncontainerPort: 465\nprotocol: TCP\n- name: esmtp-explicit\ncontainerPort: 587\n- name: imap-implicit\ncontainerPort: 993\nprotocol: TCP\n\nenvFrom:\n- configMapRef:\nname: mailserver.environment\n\nrestartPolicy: Always\n\nvolumes:\n# configuration files\n- name: files\nconfigMap:\nname: mailserver.files\n\n# PVCs\n- name: data\npersistentVolumeClaim:\nclaimName: data\n\n# certificates\n- name: certificates-rsa\nsecret:\nsecretName: mail-tls-certificate-rsa\nitems:\n- key: tls.key\npath: tls.key\n- key: tls.crt\npath: tls.crt\n\n# other\n- name: tmp-files\nemptyDir: {}\nIn this example, we use cert-manager to supply RSA certificates. You can also supply RSA certificates as fallback certificates, which DMS supports out of the box with SSL_ALT_CERT_PATH and SSL_ALT_KEY_PATH, and provide ECDSA as the proper certificates.
---\napiVersion: cert-manager.io/v1\nkind: Certificate\n\nmetadata:\nname: mail-tls-certificate-rsa\n\nspec:\nsecretName: mail-tls-certificate-rsa\nisCA: false\nprivateKey:\nalgorithm: RSA\nencoding: PKCS1\nsize: 2048\ndnsNames: [mail.example.com]\nissuerRef:\nname: mail-issuer\nkind: Issuer\nAttention
You will need to have cert-manager configured. Especially the issue will need to be configured. Since we do not know how you want or need your certificates to be supplied, we do not provide more configuration here. The documentation for cert-manager is excellent.
Sensitive Data
For storing OpenDKIM keys, TLS certificates or any sort of sensitive data, you should be using Secrets. You can mount secrets like ConfigMaps and use them the same way.
The TLS docs page provides guidance when it comes to certificates and transport layer security. Always provide sensitive information vai Secrets.
The more difficult part with Kubernetes is to expose a deployed DMS to the outside world. Kubernetes provides multiple ways for doing that; each has downsides and complexity. The major problem with exposing DMS to outside world in Kubernetes is to preserve the real client IP. The real client IP is required by DMS for performing IP-based SPF checks and spam checks. If you do not require SPF checks for incoming mails, you may disable them in your Postfix configuration by dropping the line that states: check_policy_service unix:private/policyd-spf.
The easiest approach was covered above, using externalTrafficPolicy: Local, which disables the service proxy, but makes the service local as well (which does not scale). This approach only works when you are given the correct (that is, a public and routable) IP address by a load balancer (like MetalLB). In this sense, the approach above is similar to the next example below. We want to provide you with a few alternatives too. But we also want to communicate the idea of another simple method: you could use a load-balancer without an external IP and DNAT the network traffic to the mail server. After all, this does not interfere with SPF checks because it keeps the origin IP address. If no dedicated external IP address is available, you could try the latter approach, if one is available, use the former.
The simplest way is to expose DMS as a Service with external IPs. This is very similar to the approach taken above. Here, an external IP is given to the service directly by you. With the approach above, you tell your load-balancer to do this.
---\napiVersion: v1\nkind: Service\n\nmetadata:\nname: mailserver\nlabels:\napp: mailserver\n\nspec:\nselector:\napp: mailserver\nports:\n- name: smtp\nport: 25\ntargetPort: smtp\n# ...\n\nexternalIPs:\n- 80.11.12.10\nThis approach
The proxy pod helps to avoid the necessity of specifying external IPs explicitly. This comes at the cost of complexity; you must deploy a proxy pod on each Node you want to expose DMS on.
This approach
One way to preserve the real client IP is to use hostPort and hostNetwork: true. This comes at the cost of availability; you can reach DMS from the outside world only via IPs of Node where DMS is deployed.
---\napiVersion: extensions/v1beta1\nkind: Deployment\n\nmetadata:\nname: mailserver\n\n# ...\nspec:\nhostNetwork: true\n\n# ...\ncontainers:\n# ...\nports:\n- name: smtp\ncontainerPort: 25\nhostPort: 25\n- name: smtp-auth\ncontainerPort: 587\nhostPort: 587\n- name: imap-secure\ncontainerPort: 993\nhostPort: 993\n# ...\nWith this approach,
This way is ideologically the same as using a proxy pod, but instead of a separate proxy pod, you configure your ingress to proxy TCP traffic to the DMS pod using the PROXY protocol, which preserves the real client IP.
"},{"location":"config/advanced/kubernetes/#configure-your-ingress","title":"Configure your Ingress","text":"With an NGINX ingress controller, set externalTrafficPolicy: Local for its service, and add the following to the TCP services config map (as described here):
25: \"mailserver/mailserver:25::PROXY\"\n465: \"mailserver/mailserver:465::PROXY\"\n587: \"mailserver/mailserver:587::PROXY\"\n993: \"mailserver/mailserver:993::PROXY\"\nHAProxy
With HAProxy, the configuration should look similar to the above. If you know what it actually looks like, add an example here.
"},{"location":"config/advanced/kubernetes/#configure-the-mailserver","title":"Configure the Mailserver","text":"Then, configure both Postfix and Dovecot to expect the PROXY protocol:
HAProxy Examplekind: ConfigMap\napiVersion: v1\nmetadata:\nname: mailserver.config\nlabels:\napp: mailserver\ndata:\npostfix-main.cf: |\npostscreen_upstream_proxy_protocol = haproxy\npostfix-master.cf: |\nsmtp/inet/postscreen_upstream_proxy_protocol=haproxy\nsubmission/inet/smtpd_upstream_proxy_protocol=haproxy\nsubmissions/inet/smtpd_upstream_proxy_protocol=haproxy\ndovecot.cf: |\n# Assuming your ingress controller is bound to 10.0.0.0/8\nhaproxy_trusted_networks = 10.0.0.0/8, 127.0.0.0/8\nservice imap-login {\ninet_listener imap {\nhaproxy = yes\n}\ninet_listener imaps {\nhaproxy = yes\n}\n}\n# ...\n---\n\nkind: Deployment\napiVersion: extensions/v1beta1\nmetadata:\nname: mailserver\nspec:\ntemplate:\nspec:\ncontainers:\n- name: docker-mailserver\nvolumeMounts:\n- name: config\nsubPath: postfix-main.cf\nmountPath: /tmp/docker-mailserver/postfix-main.cf\nreadOnly: true\n- name: config\nsubPath: postfix-master.cf\nmountPath: /tmp/docker-mailserver/postfix-master.cf\nreadOnly: true\n- name: config\nsubPath: dovecot.cf\nmountPath: /tmp/docker-mailserver/dovecot.cf\nreadOnly: true\nWith this approach,
To enable the fetchmail service to retrieve e-mails set the environment variable ENABLE_FETCHMAIL to 1. Your compose.yaml file should look like following snippet:
environment:\n- ENABLE_FETCHMAIL=1\n- FETCHMAIL_POLL=300\nGenerate a file called fetchmail.cf and place it in the docker-data/dms/config/ folder. Your DMS folder should look like this example:
\u251c\u2500\u2500 docker-data/dms/config\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 dovecot.cf\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 fetchmail.cf\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 postfix-accounts.cf\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 postfix-virtual.cf\n\u251c\u2500\u2500 compose.yaml\n\u2514\u2500\u2500 README.md\nA detailed description of the configuration options can be found in the online version of the manual page.
"},{"location":"config/advanced/mail-fetchmail/#imap-configuration","title":"IMAP Configuration","text":"Example
poll 'imap.gmail.com' proto imap\n user 'username'\n pass 'secret'\n is 'user1@example.com'\n ssl\nExample
poll 'pop3.gmail.com' proto pop3\n user 'username'\n pass 'secret'\n is 'user2@example.com'\n ssl\nCaution
Don\u2019t forget the last line! (eg: is 'user1@example.com'). After is, you have to specify an email address from the configuration file: docker-data/dms/config/postfix-accounts.cf.
More details how to configure fetchmail can be found in the fetchmail man page in the chapter \u201cThe run control file\u201d.
"},{"location":"config/advanced/mail-fetchmail/#polling-interval","title":"Polling Interval","text":"By default the fetchmail service searches every 5 minutes for new mails on your external mail accounts. You can override this default value by changing the ENV variable FETCHMAIL_POLL:
environment:\n- FETCHMAIL_POLL=60\nYou must specify a numeric argument which is a polling interval in seconds. The example above polls every minute for new mails.
"},{"location":"config/advanced/mail-fetchmail/#debugging","title":"Debugging","text":"To debug your fetchmail.cf configuration run this command:
./setup.sh debug fetchmail\nFor more informations about the configuration script setup.sh read the corresponding docs.
Here a sample output of ./setup.sh debug fetchmail:
fetchmail: 6.3.26 querying outlook.office365.com (protocol POP3) at Mon Aug 29 22:11:09 2016: poll started\nTrying to connect to 132.245.48.18/995...connected.\nfetchmail: Server certificate:\nfetchmail: Issuer Organization: Microsoft Corporation\nfetchmail: Issuer CommonName: Microsoft IT SSL SHA2\nfetchmail: Subject CommonName: outlook.com\nfetchmail: Subject Alternative Name: outlook.com\nfetchmail: Subject Alternative Name: *.outlook.com\nfetchmail: Subject Alternative Name: office365.com\nfetchmail: Subject Alternative Name: *.office365.com\nfetchmail: Subject Alternative Name: *.live.com\nfetchmail: Subject Alternative Name: *.internal.outlook.com\nfetchmail: Subject Alternative Name: *.outlook.office365.com\nfetchmail: Subject Alternative Name: outlook.office.com\nfetchmail: Subject Alternative Name: attachment.outlook.office.net\nfetchmail: Subject Alternative Name: attachment.outlook.officeppe.net\nfetchmail: Subject Alternative Name: *.office.com\nfetchmail: outlook.office365.com key fingerprint: 3A:A4:58:42:56:CD:BD:11:19:5B:CF:1E:85:16:8E:4D\nfetchmail: POP3< +OK The Microsoft Exchange POP3 service is ready. [SABFADEAUABSADAAMQBDAEEAMAAwADAANwAuAGUAdQByAHAAcgBkADAAMQAuAHAAcgBvAGQALgBlAHgAYwBoAGEAbgBnAGUAbABhAGIAcwAuAGMAbwBtAA==]\nfetchmail: POP3> CAPA\nfetchmail: POP3< +OK\nfetchmail: POP3< TOP\nfetchmail: POP3< UIDL\nfetchmail: POP3< SASL PLAIN\nfetchmail: POP3< USER\nfetchmail: POP3< .\nfetchmail: POP3> USER user1@outlook.com\nfetchmail: POP3< +OK\nfetchmail: POP3> PASS *\nfetchmail: POP3< +OK User successfully logged on.\nfetchmail: POP3> STAT\nfetchmail: POP3< +OK 0 0\nfetchmail: No mail for user1@outlook.com at outlook.office365.com\nfetchmail: POP3> QUIT\nfetchmail: POP3< +OK Microsoft Exchange Server 2016 POP3 server signing off.\nfetchmail: 6.3.26 querying outlook.office365.com (protocol POP3) at Mon Aug 29 22:11:11 2016: poll completed\nfetchmail: normal termination, status 1\nSieve allows to specify filtering rules for incoming emails that allow for example sorting mails into different folders depending on the title of an email. There are global and user specific filters which are filtering the incoming emails in the following order:
Global filters are applied to EVERY incoming mail for EVERY email address. To specify a global Sieve filter provide a docker-data/dms/config/before.dovecot.sieve or a docker-data/dms/config/after.dovecot.sieve file with your filter rules. If any filter in this filtering chain discards an incoming mail, the delivery process will stop as well and the mail will not reach any following filters(e.g. global-before stops an incoming spam mail: The mail will get discarded and a user-specific filter won't get applied.)
To specify a user-defined Sieve filter place a .dovecot.sieve file into a virtual user's mail folder e.g. /var/mail/example.com/user1/.dovecot.sieve. If this file exists dovecot will apply the filtering rules.
It's even possible to install a user provided Sieve filter at startup during users setup: simply include a Sieve file in the docker-data/dms/config/ path for each user login that needs a filter. The file name provided should be in the form <user_login>.dovecot.sieve, so for example for user1@example.com you should provide a Sieve file named docker-data/dms/config/user1@example.com.dovecot.sieve.
An example of a sieve filter that moves mails to a folder INBOX/spam depending on the sender address:
Example
require [\"fileinto\", \"reject\"];\n\nif address :contains [\"From\"] \"spam@spam.com\" {\n fileinto \"INBOX.spam\";\n} else {\n keep;\n}\nWarning
That folders have to exist beforehand if sieve should move them.
Another example of a sieve filter that forward mails to a different address:
Example
require [\"copy\"];\n\nredirect :copy \"user2@not-example.com\";\nJust forward all incoming emails and do not save them locally:
Example
redirect \"user2@not-example.com\";\nYou can also use external programs to filter or pipe (process) messages by adding executable scripts in docker-data/dms/config/sieve-pipe or docker-data/dms/config/sieve-filter. This can be used in lieu of a local alias file, for instance to forward an email to a webservice. These programs can then be referenced by filename, by all users. Note that the process running the scripts run as a privileged user. For further information see Dovecot's wiki.
require [\"vnd.dovecot.pipe\"];\npipe \"external-program\";\nFor more examples or a detailed description of the Sieve language have a look at the official site. Other resources are available on the internet where you can find several examples.
"},{"location":"config/advanced/mail-sieve/#automatic-sorting-based-on-subaddresses","title":"Automatic Sorting Based on Subaddresses","text":"It is possible to sort subaddresses such as user+mailing-lists@example.com into a corresponding folder (here: INBOX/Mailing-lists) automatically.
require [\"envelope\", \"fileinto\", \"mailbox\", \"subaddress\", \"variables\"];\n\nif envelope :detail :matches \"to\" \"*\" {\n set :lower :upperfirst \"tag\" \"${1}\";\n if mailboxexists \"INBOX.${1}\" {\n fileinto \"INBOX.${1}\";\n } else {\n fileinto :create \"INBOX.${tag}\";\n }\n}\nThe Manage Sieve extension allows users to modify their Sieve script by themselves. The authentication mechanisms are the same as for the main dovecot service. ManageSieve runs on port 4190 and needs to be enabled using the ENABLE_MANAGESIEVE=1 environment variable.
Example
# compose.yaml\nports:\n- \"4190:4190\"\nenvironment:\n- ENABLE_MANAGESIEVE=1\nAll user defined sieve scripts that are managed by ManageSieve are stored in the user's home folder in /var/mail/example.com/user1/sieve. Just one sieve script might be active for a user and is sym-linked to /var/mail/example.com/user1/.dovecot.sieve automatically.
Note
ManageSieve makes sure to not overwrite an existing .dovecot.sieve file. If a user activates a new sieve script the old one is backuped and moved to the sieve folder.
The extension is known to work with the following ManageSieve clients:
This is a list of all configuration files and directories which are optional or automatically generated in your docker-data/dms/config/ directory.
setup.sh config dkim. (Docs: DKIM)SSL_TYPE is set to self-signed or custom. (Docs: SSL)${login}.dovecot.sieve filter. (Docs: Sieve)${login}.dovecot.sieve filter. (Docs: Sieve)setup.sh email script.setup.sh email restrict.setup.sh email restrict.setup.sh alias.<username>:<password>. Modify via setup.sh relay add-auth <domain> <username> [<password>]. (Docs: Relay-Hosts Auth)setup.sh relay add-domain and setup.sh relay exclude-domain. (Docs: Relay-Hosts Senders)virtual_mailbox_maps. See the setup-stack.sh script.virtual_alias_maps. See the setup-stack.sh script.virtual_alias_maps. See the setup-stack.sh script.virtual_mailbox_domains. See the setup-stack.sh script.fail2ban.cf. (Docs: Fail2Ban)/etc/amavis/conf.d/50-user file/etc/dovecot/local.conf. (Docs: Override Dovecot Defaults)user-patches.sh script)Podman is a daemonless container engine for developing, managing, and running OCI Containers on your Linux System.
About Support for Podman
Please note that Podman is not officially supported as DMS is built and verified on top of the Docker Engine. This content is entirely community supported. If you find errors, please open an issue and provide a PR.
About this Guide
This guide was tested with Fedora 34 using systemd and firewalld. Moreover, it requires Podman version >= 3.2. You may be able to substitute dnf - Fedora's package manager - with others such as apt.
About Security
Running podman in rootless mode requires additional modifications in order to keep your mailserver secure. Make sure to read the related documentation.
"},{"location":"config/advanced/podman/#installation-in-rootfull-mode","title":"Installation in Rootfull Mode","text":"While using Podman, you can just manage docker-mailserver as what you did with Docker. Your best friend setup.sh includes the minimum code in order to support Podman since it's 100% compatible with the Docker CLI.
The installation is basically the same. Podman v3.2 introduced a RESTful API that is 100% compatible with the Docker API, so you can use Docker Compose with Podman easily. Install Podman and Docker Compose with your package manager first.
sudo dnf install podman docker-compose\nThen enable podman.socket using systemctl.
systemctl enable --now podman.socket\nThis will create a unix socket locate under /run/podman/podman.sock, which is the entrypoint of Podman's API. Now, configure docker-mailserver and start it.
export DOCKER_HOST=\"unix:///run/podman/podman.sock\"\ndocker compose up -d mailserver\ndocker compose ps\nYou should see that docker-mailserver is running now.
"},{"location":"config/advanced/podman/#self-start-in-rootfull-mode","title":"Self-start in Rootfull Mode","text":"Podman is daemonless, that means if you want docker-mailserver self-start while boot up the system, you have to generate a systemd file with Podman CLI.
podman generate systemd mailserver > /etc/systemd/system/mailserver.service\nsystemctl daemon-reload\nsystemctl enable --now mailserver.service\nRunning rootless containers is one of Podman's major features. But due to some restrictions, deploying docker-mailserver in rootless mode is not as easy compared to rootfull mode.
~/.configAlso notice that Podman's rootless mode is not about running as a non-root user inside the container, but about the mapping of (normal, non-root) host users to root inside the container.
Warning
In order to make rootless DMS work we must modify some settings in the Linux system, it requires some basic linux server knowledge so don't follow this guide if you not sure what this guide is talking about. Podman rootfull mode and Docker are still good and security enough for normal daily usage.
First, enable podman.socket in systemd's userspace with a non-root user.
systemctl enable --now --user podman.socket\nThe socket file should be located at /var/run/user/$(id -u)/podman/podman.sock. Then, modify compose.yaml to make sure all ports are bindings are on non-privileged ports.
services:\nmailserver:\nports:\n- \"10025:25\" # SMTP (explicit TLS => STARTTLS)\n- \"10143:143\" # IMAP4 (explicit TLS => STARTTLS)\n- \"10465:465\" # ESMTP (implicit TLS)\n- \"10587:587\" # ESMTP (explicit TLS => STARTTLS)\n- \"10993:993\" # IMAP4 (implicit TLS)\nThen, setup your mailserver.env file follow the documentation and use Docker Compose to start the container.
export DOCKER_HOST=\"unix:///var/run/user/$(id -u)/podman/podman.sock\"\ndocker compose up -d mailserver\ndocker compose ps\nIn rootless mode, podman resolves all incoming IPs as localhost, which results in an open gateway in the default configuration. There are two workarounds to fix this problem, both of which have their own drawbacks.
"},{"location":"config/advanced/podman/#enforce-authentication-from-localhost","title":"Enforce authentication from localhost","text":"The PERMIT_DOCKER variable in the mailserver.env file allows to specify trusted networks that do not need to authenticate. If the variable is left empty, only requests from localhost and the container IP are allowed, but in the case of rootless podman any IP will be resolved as localhost. Setting PERMIT_DOCKER=none enforces authentication also from localhost, which prevents sending unauthenticated emails.
The second workaround is slightly more complicated because the compose.yaml has to be modified. As shown in the fail2ban section the slirp4netns network driver has to be enabled. This network driver enables podman to correctly resolve IP addresses but it is not compatible with user defined networks which might be a problem depending on your setup.
Rootless Podman requires adding the value slirp4netns:port_handler=slirp4netns to the --network CLI option, or network_mode setting in your compose.yaml.
You must also add the ENV NETWORK_INTERFACE=tap0, because Podman uses a hard-coded interface name for slirp4netns.
Example
services:\nmailserver:\nnetwork_mode: \"slirp4netns:port_handler=slirp4netns\"\nenvironment:\n- NETWORK_INTERFACE=tap0\n...\nNote
podman-compose is not compatible with this configuration.
Generate a systemd file with the Podman CLI.
podman generate systemd mailserver > ~/.config/systemd/user/mailserver.service\nsystemctl --user daemon-reload\nsystemctl enable --user --now mailserver.service\nSystemd's user space service is only started when a specific user logs in and stops when you log out. In order to make it to start with the system, we need to enable linger with loginctl
loginctl enable-linger <username>\nRemember to run this command as root user.
"},{"location":"config/advanced/podman/#port-forwarding","title":"Port Forwarding","text":"When it comes to forwarding ports using firewalld, see https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/securing_networks/using-and-configuring-firewalld_securing-networks#port-forwarding_using-and-configuring-firewalld for more information.
firewall-cmd --permanent --add-forward-port=port=<25|143|465|587|993>:proto=<tcp>:toport=<10025|10143|10465|10587|10993>\n...\n\n# After you set all ports up.\nfirewall-cmd --reload\nNotice that this will only open the access to the external client. If you want to access privileges port in your server, do this:
firewall-cmd --permanent --direct --add-rule <ipv4|ipv6> nat OUTPUT 0 -p <tcp|udp> -o lo --dport <25|143|465|587|993> -j REDIRECT --to-ports <10025|10143|10465|10587|10993>\n...\n# After you set all ports up.\nfirewall-cmd --reload\nJust map all the privilege port with non-privilege port you set in compose.yaml before as root user.
"},{"location":"config/advanced/mail-forwarding/aws-ses/","title":"Mail Forwarding | AWS SES","text":"Amazon SES (Simple Email Service) is intended to provide a simple way for cloud based applications to send email and receive email. For the purposes of this project only sending email via SES is supported. Older versions of docker-mailserver used AWS_SES_HOST and AWS_SES_USERPASS to configure sending, this has changed and the setup is mananged through Configure Relay Hosts.
You will need to create some Amazon SES SMTP credentials. The SMTP credentials you create will be used to populate the RELAY_USER and RELAY_PASSWORD environment variables.
The RELAY_HOST should match your AWS SES region, the RELAY_PORT will be 587.
If all of your email is being forwarded through AWS SES, DEFAULT_RELAY_HOST should be set accordingly.
Example:
DEFAULT_RELAY_HOST=[email-smtp.us-west-2.amazonaws.com]:587\nNote
If you set up AWS Easy DKIM you can safely skip setting up DKIM as the AWS SES will take care of signing your outgoing email.
To verify proper operation, send an email to some external account of yours and inspect the mail headers. You will also see the connection to SES in the mail logs. For example:
May 23 07:09:36 mail postfix/smtp[692]: Trusted TLS connection established to email-smtp.us-east-1.amazonaws.com[107.20.142.169]:25:\nTLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)\nMay 23 07:09:36 mail postfix/smtp[692]: 8C82A7E7: to=<someone@example.com>, relay=email-smtp.us-east-1.amazonaws.com[107.20.142.169]:25,\ndelay=0.35, delays=0/0.02/0.13/0.2, dsn=2.0.0, status=sent (250 Ok 01000154dc729264-93fdd7ea-f039-43d6-91ed-653e8547867c-000000)\nRather than having Postfix deliver mail directly, you can configure Postfix to send mail via another mail relay (smarthost). Examples include Mailgun, Sendgrid and AWS SES.
Depending on the domain of the sender, you may want to send via a different relay, or authenticate in a different way.
"},{"location":"config/advanced/mail-forwarding/relay-hosts/#basic-configuration","title":"Basic Configuration","text":"Basic configuration is done via environment variables:
RELAY_HOST: default host to relay mail through, empty (aka '', or no ENV set) will disable this featureRELAY_PORT: port on default relay, defaults to port 25RELAY_USER: username for the default relayRELAY_PASSWORD: password for the default userSetting these environment variables will cause mail for all sender domains to be routed via the specified host, authenticating with the user/password combination.
Warning
For users of the previous AWS_SES_* variables: please update your configuration to use these new variables, no other configuration is required.
Sender dependent authentication is done in docker-data/dms/config/postfix-sasl-password.cf. You can create this file manually, or use:
setup.sh relay add-auth <domain> <username> [<password>]\nAn example configuration file looks like this:
@domain1.com relay_user_1:password_1\n@domain2.com relay_user_2:password_2\nIf there is no other configuration, this will cause Postfix to deliver email through the relay specified in RELAY_HOST env variable, authenticating as relay_user_1 when sent from domain1.com and authenticating as relay_user_2 when sending from domain2.com.
Note
To activate the configuration you must either restart the container, or you can also trigger an update by modifying a mail account.
"},{"location":"config/advanced/mail-forwarding/relay-hosts/#sender-dependent-relay-host","title":"Sender-dependent Relay Host","text":"Sender dependent relay hosts are configured in docker-data/dms/config/postfix-relaymap.cf. You can create this file manually, or use:
setup.sh relay add-domain <domain> <host> [<port>]\nAn example configuration file looks like this:
@domain1.com [relay1.org]:587\n@domain2.com [relay2.org]:2525\nCombined with the previous configuration in docker-data/dms/config/postfix-sasl-password.cf, this will cause Postfix to deliver mail sent from domain1.com via relay1.org:587, authenticating as relay_user_1, and mail sent from domain2.com via relay2.org:2525 authenticating as relay_user_2.
Note
You still have to define RELAY_HOST to activate the feature
If you want mail sent from some domains to be delivered directly, you can exclude them from being delivered via the default relay by adding them to docker-data/dms/config/postfix-relaymap.cf with no destination. You can also do this via:
setup.sh relay exclude-domain <domain>\nExtending the configuration file from above:
@domain1.com [relay1.org]:587\n@domain2.com [relay2.org]:2525\n@domain3.com\nThis will cause email sent from domain3.com to be delivered directly.
Docker images are handy but it can become a hassle to keep them updated. Also when a repository is automated you want to get these images when they get out.
One could setup a complex action/hook-based workflow using probes, but there is a nice, easy to use docker image that solves this issue and could prove useful: watchtower.
A Docker Compose example:
services:\nwatchtower:\nrestart: always\nimage: containrrr/watchtower:latest\nvolumes:\n- /var/run/docker.sock:/var/run/docker.sock\nFor more details, see the manual
"},{"location":"config/advanced/maintenance/update-and-cleanup/#automatic-cleanup","title":"Automatic Cleanup","text":"When you are pulling new images in automatically, it would be nice to have them cleaned up as well. There is also a docker image for this: spotify/docker-gc.
A Docker Compose example:
services:\ndocker-gc:\nrestart: always\nimage: spotify/docker-gc:latest\nvolumes:\n- /var/run/docker.sock:/var/run/docker.sock\nFor more details, see the manual
Or you can just use the --cleanup option provided by containrrr/watchtower.
The Dovecot default configuration can easily be extended providing a docker-data/dms/config/dovecot.cf file. Dovecot documentation remains the best place to find configuration options.
Your DMS folder structure should look like this example:
\u251c\u2500\u2500 docker-data/dms/config\n\u2502 \u251c\u2500\u2500 dovecot.cf\n\u2502 \u251c\u2500\u2500 postfix-accounts.cf\n\u2502 \u2514\u2500\u2500 postfix-virtual.cf\n\u251c\u2500\u2500 compose.yaml\n\u2514\u2500\u2500 README.md\nOne common option to change is the maximum number of connections per user:
mail_max_userip_connections = 100\nAnother important option is the default_process_limit (defaults to 100). If high-security mode is enabled you'll need to make sure this count is higher than the maximum number of users that can be logged in simultaneously.
This limit is quickly reached if users connect to DMS with multiple end devices.
"},{"location":"config/advanced/override-defaults/dovecot/#override-configuration","title":"Override Configuration","text":"For major configuration changes it\u2019s best to override the dovecot configuration files. For each configuration file you want to override, add a list entry under the volumes key.
services:\nmailserver:\nvolumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/config/dovecot/10-master.conf:/etc/dovecot/conf.d/10-master.conf\nYou will first need to obtain the configuration from the running container (where mailserver is the container name):
mkdir -p ./docker-data/dms/config/dovecot\ndocker cp mailserver:/etc/dovecot/conf.d/10-master.conf ./docker-data/dms/config/dovecot/10-master.conf\nTo debug your dovecot configuration you can use:
./setup.sh debug login doveconf | grep <some-keyword>docker exec -it mailserver doveconf | grep <some-keyword>Note
setup.sh is included in the DMS repository. Make sure to use the one matching your image version release.
The file docker-data/dms/config/dovecot.cf is copied internally to /etc/dovecot/local.conf. To verify the file content, run:
docker exec -it mailserver cat /etc/dovecot/local.conf\nOur default Postfix configuration can easily be extended to add parameters or modify existing ones by providing a docker-data/dms/config/postfix-main.cf. This file uses the same format as Postfix main.cf does (See official docs for all parameters and syntax rules).
Example
One can easily increase the backwards-compatibility level and set new Postscreen options:
# increase the compatibility level from 2 (default) to 3\ncompatibility_level = 3\n# set a threshold value for Spam detection\npostscreen_dnsbl_threshold = 4\nHow are your changes applied?
The custom configuration you supply is appended to the default configuration located at /etc/postfix/main.cf, and then postconf -nf is run to remove earlier duplicate entries that have since been replaced. This happens early during container startup before Postfix is started.
Similarly, it is possible to add a custom docker-data/dms/config/postfix-master.cf file that will override the standard master.cf. Note: Each line in this file will be passed to postconf -P, i.e. the file is not appended as a whole to /etc/postfix/master.cf like docker-data/dms/config/postfix-main.cf! The expected format is <service_name>/<type>/<parameter>, for example:
# adjust the submission \"reject_unlisted_recipient\" option\nsubmission/inet/smtpd_reject_unlisted_recipient=no\nAttention
There should be no space between the parameter and the value.
Run postconf -Mf in the container without arguments to see the active master options.
If you'd like to change, patch or alter files or behavior of DMS, you can use a script.
In case you cloned this repository, you can copy the file user-patches.sh.dist (under config/) with cp config/user-patches.sh.dist docker-data/dms/config/user-patches.sh in order to create the user-patches.sh script.
If you are managing your directory structure yourself, create a docker-data/dms/config/ directory and add the user-patches.sh file yourself.
# 1. Either create the docker-data/dms/config/ directory yourself\n# or let docker-mailserver create it on initial startup\n/tmp $ mkdir -p docker-data/dms/config/ && cd docker-data/dms/config/\n\n# 2. Create the user-patches.sh file and edit it\n/tmp/docker-data/dms/config $ touch user-patches.sh\n/tmp/docker-data/dms/config $ nano user-patches.sh\nThe contents could look like this:
#!/bin/bash\n\ncat >/etc/amavis/conf.d/50-user << \"END\"\nuse strict;\n\n$undecipherable_subject_tag = undef;\n$admin_maps_by_ccat{+CC_UNCHECKED} = undef;\n\n#------------ Do not modify anything below this line -------------\n1; # ensure a defined return\nEND\nAnd you're done. The user patches script runs right before starting daemons. That means, all the other configuration is in place, so the script can make final adjustments.
Note
Many \"patches\" can already be done with the Docker Compose-/Stack-file. Adding hostnames to /etc/hosts is done with the extra_hosts: section, sysctl commands can be managed with the sysctls: section, etc.
Email auto-discovery means a client email is able to automagically find out about what ports and security options to use, based on the mail server URI. It can help simplify the tedious / confusing task of adding own's email account for non-tech savvy users.
Email clients will search for auto-discoverable settings and prefill almost everything when a user enters its email address
There exists autodiscover-email-settings on which provides IMAP/POP/SMTP/LDAP autodiscover capabilities on Microsoft Outlook/Apple Mail, autoconfig capabilities for Thunderbird or kmail and configuration profiles for iOS/Apple Mail.
"},{"location":"config/best-practices/dkim_dmarc_spf/","title":"DKIM, DMARC & SPF","text":"Cloudflare has written an article about DKIM, DMARC and SPF that we highly recommend you to read to get acquainted with the topic.
Rspamd vs Individual validators
With v12.0.0, Rspamd was integrated into DMS. It can perform validations for DKIM, DMARC and SPF as part of the spam-score-calculation for an email. DMS provides individual alternatives for each validation that can be used instead of deferring to Rspamd:
opendkim is used as a milter (like Rspamd)opendmarc is used as a milter (like Rspamd)policyd-spf is used in Postfix's smtpd_recipient_restrictionsIn a future release Rspamd will become the default for these validations, with a deprecation notice issued prior to the removal of the above alternatives.
We encourage everyone to prefer Rspamd via ENABLE_RSPAMD=1.
DNS Caches & Propagation
While modern DNS providers are quick, it may take minutes or even hours for new DNS records to become available / propagate.
"},{"location":"config/best-practices/dkim_dmarc_spf/#dkim","title":"DKIM","text":"What is DKIM
DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in email (email spoofing), a technique often used in phishing and email spam.
Source
When DKIM is enabled:
DKIM requires a public/private key pair to enable signing (via private key) your outgoing mail, while the receiving end must query DNS to verify (via public key) that the signature is trustworthy.
"},{"location":"config/best-practices/dkim_dmarc_spf/#generating-keys","title":"Generating Keys","text":"You should have:
RSA Key Sizes >= 4096 Bit
Keys of 4096 bits could be denied by some mail servers. According to RFC 6376, keys are preferably between 512 and 2048 bits.
DKIM is currently supported by either OpenDKIM or Rspamd:
OpenDKIMRspamdOpenDKIM is currently enabled by default.
The command docker exec <CONTAINER NAME> setup config dkim help details supported config options, along with some examples.
Creating a DKIM key
Generate the DKIM files with:
docker exec -ti <CONTAINER NAME> setup config dkim\nYour new DKIM key(s) and OpenDKIM config files have been added to /tmp/docker-mailserver/opendkim/.
The command is unable to infer the domains from LDAP user accounts, you must specify them:
setup config dkim domain 'example.com,example.io'\nThe private key presently defaults to RSA-4096. To create an RSA 2048-bit key run:
setup config dkim keysize 2048\nRestart required
After restarting DMS, outgoing mail will now be signed with your new DKIM key(s)
You'll need to repeat this process if you add any new domains.
Opt-in via ENABLE_RSPAMD=1 (and disable the default OpenDKIM: ENABLE_OPENDKIM=0).
Rspamd provides DKIM support through two separate modules:
Creating DKIM Keys
You can simply run
docker exec -ti <CONTAINER NAME> setup config dkim help\nwhich provides you with an overview of what the script can do. Just running
docker exec -ti <CONTAINER NAME> setup config dkim\nwill execute the helper script with default parameters.
About the Helper Script
The script will persist the keys in /tmp/docker-mailserver/rspamd/dkim/. Hence, if you are already using the default volume mounts, the keys are persisted in a volume. The script also restarts Rspamd directly, so changes take effect without restarting DMS.
The script provides you with log messages along the way of creating keys. In case you want to read the complete log, use -v (verbose) or -vv (very verbose).
In case you have not already provided a default DKIM signing configuration, the script will create one and write it to /etc/rspamd/override.d/dkim_signing.conf. If this file already exist, it will not be overwritten. When you're already using the rspamd/override.d/ directory, the file is created inside your volume and therefore persisted correctly. If you are not using rspamd/override.d/, you will need to persist the file yourself (otherwise it is lost on container restart).
An example of what a default configuration file for DKIM signing looks like can be found by expanding the example below.
DKIM Signing Module Configuration ExamplesA simple configuration could look like this:
# documentation: https://rspamd.com/doc/modules/dkim_signing.html\n\nenabled = true;\n\nsign_authenticated = true;\nsign_local = true;\n\nuse_domain = \"header\";\nuse_redis = false; # don't change unless Redis also provides the DKIM keys\nuse_esld = true;\ncheck_pubkey = true; # you want to use this in the beginning\n\ndomain {\nexample.com {\npath = \"/tmp/docker-mailserver/rspamd/dkim/mail.private\";\nselector = \"mail\";\n}\n}\nAs shown next:
domain { ... } section.selectors [ ... ] array.# ...\n\ndomain {\nexample.com {\nselectors [\n{\npath = \"/tmp/docker-mailserver/rspamd/dkim/example.com/rsa.private\";\nselector = \"dkim-rsa\";\n},\n{\npath = /tmp/docker-mailserver/rspamd/example.com/ed25519.private\";\nselector = \"dkim-ed25519\";\n}\n]\n}\nexample.org {\nselectors [\n{\npath = \"/tmp/docker-mailserver/rspamd/dkim/example.org/rsa.private\";\nselector = \"dkim-rsa\";\n},\n{\npath = \"/tmp/docker-mailserver/rspamd/dkim/example.org/ed25519.private\";\nselector = \"dkim-ed25519\";\n}\n]\n}\n}\nThis modern elliptic curve is supported by Rspamd, but support by third-parties for verifying Ed25519 DKIM signatures is unreliable.
If you sign your mail with this key type, you should include RSA as a fallback, like shown in the above example.
Let Rspamd Check Your KeysWhen check_pubkey = true; is set, Rspamd will query the DNS record for each DKIM selector, verifying each public key matches the private key configured.
If there is a mismatch, a warning will be emitted to the Rspamd log /var/log/supervisor/rspamd.log.
When mail signed with your DKIM key is sent from your mail server, the receiver needs to check a DNS TXT record to verify the DKIM signature is trustworthy.
Configuring DNS - DKIM record
When you generated your key in the previous step, the DNS data was saved into a file <selector>.txt (default: mail.txt). Use this content to update your DNS via Web Interface or directly edit your DNS Zone file:
Create a new record:
Field Value TypeTXT Name <selector>._domainkey (default: mail._domainkey) TTL Use the default (otherwise 3600 seconds is appropriate) Data File content within ( ... ) (formatted as advised below) When using Rspamd, the helper script has already provided you with the contents (the \"Data\" field) of the DNS record you need to create - you can just copy-paste this text.
<selector>.txt is already formatted as a snippet for adding to your DNS Zone file.
Just copy/paste the file contents into your existing DNS zone. The TXT value has been split into separate strings every 255 characters for compatibility.
<selector>.txt - Formatting the TXT record value correctly This file was generated for use within a DNS zone file. DNS TXT records values that are longer than 255 characters need to be split into multiple parts. This is why the public key has multiple parts wrapped within double-quotes between ( and ).
A DNS web-interface may handle this internally instead, while others may not, but expect the input as a single line_). You'll need to manually format the value as described below.
Your DNS record file (eg: mail.txt) should look similar to this:
mail._domainkey IN TXT ( \"v=DKIM1; k=rsa; \"\n\"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqQMMqhb1S52Rg7VFS3EC6JQIMxNDdiBmOKZvY5fiVtD3Z+yd9ZV+V8e4IARVoMXWcJWSR6xkloitzfrRtJRwOYvmrcgugOalkmM0V4Gy/2aXeamuiBuUc4esDQEI3egmtAsHcVY1XCoYfs+9VqoHEq3vdr3UQ8zP/l+FP5UfcaJFCK/ZllqcO2P1GjIDVSHLdPpRHbMP/tU1a9mNZ\"\n\"5QMZBJ/JuJK/s+2bp8gpxKn8rh1akSQjlynlV9NI+7J3CC7CUf3bGvoXIrb37C/lpJehS39KNtcGdaRufKauSfqx/7SxA0zyZC+r13f7ASbMaQFzm+/RRusTqozY/p/MsWx8QIDAQAB\"\n) ;\nTake the content between ( ... ), and combine all the quote wrapped content and remove the double-quotes including the white-space between them. That is your TXT record value, the above example would become this:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqQMMqhb1S52Rg7VFS3EC6JQIMxNDdiBmOKZvY5fiVtD3Z+yd9ZV+V8e4IARVoMXWcJWSR6xkloitzfrRtJRwOYvmrcgugOalkmM0V4Gy/2aXeamuiBuUc4esDQEI3egmtAsHcVY1XCoYfs+9VqoHEq3vdr3UQ8zP/l+FP5UfcaJFCK/ZllqcO2P1GjIDVSHLdPpRHbMP/tU1a9mNZ5QMZBJ/JuJK/s+2bp8gpxKn8rh1akSQjlynlV9NI+7J3CC7CUf3bGvoXIrb37C/lpJehS39KNtcGdaRufKauSfqx/7SxA0zyZC+r13f7ASbMaQFzm+/RRusTqozY/p/MsWx8QIDAQAB\nTo test that your new DKIM record is correct, query it with the dig command. The TXT value response should be a single line split into multiple parts wrapped in double-quotes:
$ dig +short TXT dkim-rsa._domainkey.example.com\n\"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqQMMqhb1S52Rg7VFS3EC6JQIMxNDdiBmOKZvY5fiVtD3Z+yd9ZV+V8e4IARVoMXWcJWSR6xkloitzfrRtJRwOYvmrcgugOalkmM0V4Gy/2aXeamuiBuUc4esDQEI3egmtAsHcVY1XCoYfs+9VqoHEq3vdr3UQ8zP/l+FP5UfcaJFCK/ZllqcO2P1GjIDVSHLdPpRHbMP/tU1a9mNZ5QMZBJ/JuJK/s+2bp8gpxKn8rh1akSQjlynlV9NI+7J3CC7CUf3bGvoXIrb37C/lpJehS39\" \"KNtcGdaRufKauSfqx/7SxA0zyZC+r13f7ASbMaQFzm+/RRusTqozY/p/MsWx8QIDAQAB\"\nMxToolbox has a DKIM Verifier that you can use to check your DKIM DNS record(s).
When using Rspamd, we recommend you turn on check_pubkey = true; in dkim_signing.conf. Rspamd will then check whether your private key matches your public key, and you can check possible mismatches by looking at /var/log/supervisor/rspamd.log.
With DMS, DMARC is pre-configured out of the box. You may disable extra and excessive DMARC checks when using Rspamd via ENABLE_OPENDMARC=0.
The only thing you need to do in order to enable DMARC on a \"DNS-level\" is to add new TXT. In contrast to DKIM, DMARC DNS entries do not require any keys, but merely setting the configuration values. You can either handcraft the entry by yourself or use one of available generators (like this one).
Typically something like this should be good to start with:
_dmarc.example.com. IN TXT \"v=DMARC1; p=none; sp=none; fo=0; adkim=4; aspf=r; pct=100; rf=afrf; ri=86400; rua=mailto:dmarc.report@example.com; ruf=mailto:dmarc.report@example.com\"\nOr a bit more strict policies (mind p=quarantine and sp=quarantine):
_dmarc.example.com. IN TXT \"v=DMARC1; p=quarantine; sp=quarantine; fo=0; adkim=r; aspf=r; pct=100; rf=afrf; ri=86400; rua=mailto:dmarc.report@example.com; ruf=mailto:dmarc.report@example.com\"\nThe DMARC status may not be displayed instantly due to delays in DNS (caches). Dmarcian has a few tools you can use to verify your DNS records.
"},{"location":"config/best-practices/dkim_dmarc_spf/#spf","title":"SPF","text":"What is SPF
Sender Policy Framework (SPF) is a simple email-validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain comes from a host authorized by that domain's administrators.
Source
Disabling policyd-spf?
As of now, policyd-spf cannot be disabled. This is WIP.
To add a SPF record in your DNS, insert the following line in your DNS zone:
example.com. IN TXT \"v=spf1 mx ~all\"\nThis enables the Softfail mode for SPF. You could first add this SPF record with a very low TTL. SoftFail is a good setting for getting started and testing, as it lets all email through, with spams tagged as such in the mailbox.
After verification, you might want to change your SPF record to v=spf1 mx -all so as to enforce the HardFail policy. See http://www.open-spf.org/SPF_Record_Syntax for more details about SPF policies.
In any case, increment the SPF record's TTL to its final value.
"},{"location":"config/best-practices/dkim_dmarc_spf/#backup-mx-secondary-mx-for-policyd-spf","title":"Backup MX & Secondary MX forpolicyd-spf","text":"For whitelisting an IP Address from the SPF test, you can create a config file (see policyd-spf.conf) and mount that file into /etc/postfix-policyd-spf-python/policyd-spf.conf.
Example: Create and edit a policyd-spf.conf file at docker-data/dms/config/postfix-policyd-spf.conf:
debugLevel = 1\n#0(only errors)-4(complete data received)\n\nskip_addresses = 127.0.0.0/8,::ffff:127.0.0.0/104,::1\n\n# Preferably use IP-Addresses for whitelist lookups:\nWhitelist = 192.168.0.0/31,192.168.1.0/30\n# Domain_Whitelist = mx1.not-example.com,mx2.not-example.com\nThen add this line to compose.yaml:
volumes:\n- ./docker-data/dms/config/postfix-policyd-spf.conf:/etc/postfix-policyd-spf-python/policyd-spf.conf\nWhat is Fail2Ban (F2B)?
Fail2ban is an intrusion prevention software framework. Written in the Python programming language, it is designed to prevent against brute-force attacks. It is able to run on POSIX systems that have an interface to a packet-control system or firewall installed locally, such as [NFTables] or TCP Wrapper.
Source
"},{"location":"config/security/fail2ban/#configuration","title":"Configuration","text":"Warning
DMS must be launched with the NET_ADMIN capability in order to be able to install the NFTables rules that actually ban IP addresses. Thus, either include --cap-add=NET_ADMIN in the docker run command, or the equivalent in the compose.yaml:
cap_add:\n- NET_ADMIN\nRunning Fail2Ban on Older Kernels
DMS configures F2B to use NFTables, not IPTables (legacy). We have observed that older systems, for example NAS systems, do not support the modern NFTables rules. You will need to configure F2B to use legacy IPTables again, for example with the fail2ban-jail.cf, see the section on configuration further down below.
DMS will automatically ban IP addresses of hosts that have generated 6 failed attempts over the course of the last week. The bans themselves last for one week. The Postfix jail is configured to use mode = extra in DMS.
What is docker-data/dms/config/?
This following configuration files inside the docker-data/dms/config/ volume will be copied inside the container during startup
fail2ban-jail.cf is copied to /etc/fail2ban/jail.d/user-jail.localfail2ban-fail2ban.cf is copied to /etc/fail2ban/fail2ban.localWhen just running
setup fail2ban\nthe script will show all banned IP addresses.
"},{"location":"config/security/fail2ban/#managing-bans","title":"Managing Bans","text":"You can manage F2B with the setup script. The usage looks like this:
docker exec <CONTAINER NAME> setup fail2ban [<ban|unban> <IP>]\ndocker exec <CONTAINER NAME> setup fail2ban log\nRootlessKit is the fakeroot implementation for supporting rootless mode in Docker and Podman. By default, RootlessKit uses the builtin port forwarding driver, which does not propagate source IP addresses.
It is necessary for F2B to have access to the real source IP addresses in order to correctly identify clients. This is achieved by changing the port forwarding driver to slirp4netns, which is slower than the builtin driver but does preserve the real source IPs.
For rootless mode in Docker, create ~/.config/systemd/user/docker.service.d/override.conf with the following content:
Danger
This changes the port driver for all rootless containers managed by Docker. Per container configuration is not supported, if you need that consider Podman instead.
[Service]\nEnvironment=\"DOCKERD_ROOTLESS_ROOTLESSKIT_PORT_DRIVER=slirp4netns\"\nAnd then restart the daemon:
$ systemctl --user daemon-reload\n$ systemctl --user restart docker\nRootless Podman requires adding the value slirp4netns:port_handler=slirp4netns to the --network CLI option, or network_mode setting in your compose.yaml:
Example
services:\nmailserver:\nnetwork_mode: \"slirp4netns:port_handler=slirp4netns\"\nenvironment:\n- ENABLE_FAIL2BAN=1\n- NETWORK_INTERFACE=tap0\n...\nYou must also add the ENV NETWORK_INTERFACE=tap0, because Podman uses a hard-coded interface name for slirp4netns. slirp4netns is not compatible with user-defined networks!
Info
The Mail crypt plugin is used to secure email messages stored in a Dovecot system. Messages are encrypted before written to storage and decrypted after reading. Both operations are transparent to the user.
In case of unauthorized access to the storage backend, the messages will, without access to the decryption keys, be unreadable to the offending party.
There can be a single encryption key for the whole system or each user can have a key of their own. The used cryptographical methods are widely used standards and keys are stored in portable formats, when possible.
Official Dovecot documentation: https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/
"},{"location":"config/security/mail_crypt/#single-encryption-key-global-method","title":"Single Encryption Key / Global Method","text":"Create 10-custom.conf and populate it with the following:
# Enables mail_crypt for all services (imap, pop3, etc)\nmail_plugins = $mail_plugins mail_crypt\nplugin {\n mail_crypt_global_private_key = </certs/ecprivkey.pem\n mail_crypt_global_public_key = </certs/ecpubkey.pem\n mail_crypt_save_version = 2\n}\nShutdown your mailserver (docker compose down)
You then need to generate your global EC key. We named them /certs/ecprivkey.pem and /certs/ecpubkey.pem in step #1.
The EC key needs to be available in the container. I prefer to mount a /certs directory into the container:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\nvolumes:\n. . .\n- ./certs/:/certs\n. . .\nWhile you're editing the compose.yaml, add the configuration file:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\nvolumes:\n. . .\n- ./config/dovecot/10-custom.conf:/etc/dovecot/conf.d/10-custom.conf\n- ./certs/:/certs\n. . .\nStart the container, monitor the logs for any errors, send yourself a message, and then confirm the file on disk is encrypted:
[root@ip-XXXXXXXXXX ~]# cat -A /mnt/efs-us-west-2/maildata/awesomesite.com/me/cur/1623989305.M6v\ufffdz\ufffd@\ufffd\ufffd m}\ufffd\ufffd,\ufffd\ufffd9\ufffd\ufffd\ufffd\ufffdB*\ufffd247.us-west-2.compute.inE\ufffd\ufffd\\Ck*\ufffd@7795,W=7947:2,\nT\ufffd9\ufffd8t\ufffd6\ufffd\ufffd t\ufffd\ufffd\ufffde\ufffdW\ufffd\ufffdS `\ufffdH\ufffd\ufffdC\ufffd\u06a4 \ufffdyeY\ufffd\ufffdXZ\ufffd\ufffd^\ufffdd\ufffd/\ufffd\ufffd+\ufffdA\nThis should be the minimum required for encryption of the mail while in storage.
"},{"location":"config/security/rspamd/","title":"Security | Rspamd","text":""},{"location":"config/security/rspamd/#about","title":"About","text":"Rspamd is a \"fast, free and open-source spam filtering system\". DMS integrates Rspamd like any other service. We provide a very simple but easy to maintain setup of Rspamd.
If you want to have a look at the default configuration files for Rspamd that DMS packs, navigate to target/rspamd/ inside the repository. Please consult the section \"The Default Configuration\" section down below for a written overview.
AMD64 vs ARM64
We are currently doing a best-effort installation of Rspamd for ARM64 (from the Debian backports repository for Debian 11). The current version difference as of 23rd Apr 2023: AMD64 is at version 3.5 | ARM64 is at version 3.4.
"},{"location":"config/security/rspamd/#related-environment-variables","title":"Related Environment Variables","text":"The following environment variables are related to Rspamd:
ENABLE_RSPAMDENABLE_RSPAMD_REDISRSPAMD_GREYLISTINGRSPAMD_HFILTERRSPAMD_HFILTER_HOSTNAME_UNKNOWN_SCORERSPAMD_LEARNMOVE_SPAM_TO_JUNKWith these variables, you can enable Rspamd itself and you can enable / disable certain features related to Rspamd.
"},{"location":"config/security/rspamd/#the-default-configuration","title":"The Default Configuration","text":""},{"location":"config/security/rspamd/#mode-of-operation","title":"Mode of Operation","text":"The proxy worker operates in self-scan mode. This simplifies the setup as we do not require a normal worker. You can easily change this though by overriding the configuration by DMS.
DMS does not set a default password for the controller worker. You may want to do that yourself. In setups where you already have an authentication provider in front of the Rspamd webpage, you may want to set the secure_ip option to \"0.0.0.0/0\" for the controller worker to disable password authentication inside Rspamd completely.
When Rspamd is enabled, we implicitly also start an instance of Redis in the container. Redis is configured to persist it's data via RDB snapshots to disk in the directory /var/lib/redis (which is a symbolic link to /var/mail-state/lib-redis/ when ONE_DIR=1 and a volume is mounted to /var/mail-state/). With the volume mount the snapshot will restore the Redis data across container restarts, and provide a way to keep backup.
Redis uses /etc/redis/redis.conf for configuration. We adjust this file when enabling the internal Redis service. If you have an external instance of Redis to use, the internal Redis service can be opt-out via setting the ENV ENABLE_RSPAMD_REDIS=0 (link also details required changes to the DMS rspamd config).
Rspamd provides a web interface, which contains statistics and data Rspamd collects. The interface is enabled by default and reachable on port 11334.
"},{"location":"config/security/rspamd/#dns","title":"DNS","text":"DMS does not supply custom values for DNS servers to Rspamd. If you need to use custom DNS servers, which could be required when using DNS-based black/whitelists, you need to adjust options.inc yourself.
Making DNS Servers Configurable
If you want to see an environment variable (like RSPAMD_DNS_SERVERS) to support custom DNS servers for Rspamd being added to DMS, please raise a feature request issue.
Danger
While we do not provide values for custom DNS servers by default, we set soft_reject_on_timeout = true; by default. This setting will cause a soft reject if a task (presumably a DNS request) timeout takes place.
This setting is enabled to not allow spam to proceed just because DNS requests did not succeed. It could deny legitimate e-mails to pass though too in case your DNS setup is incorrect or not functioning properly.
"},{"location":"config/security/rspamd/#modules","title":"Modules","text":"You can find a list of all Rspamd modules on their website.
"},{"location":"config/security/rspamd/#disabled-by-default","title":"Disabled By Default","text":"DMS disables certain modules (clickhouse, elastic, neural, reputation, spamassassin, url_redirector, metric_exporter) by default. We believe these are not required in a standard setup, and they would otherwise needlessly use system resources.
"},{"location":"config/security/rspamd/#anti-virus-clamav","title":"Anti-Virus (ClamAV)","text":"You can choose to enable ClamAV, and Rspamd will then use it to check for viruses. Just set the environment variable ENABLE_CLAMAV=1.
The RBL module is enabled by default. As a consequence, Rspamd will perform DNS lookups to a variety of blacklists. Whether an RBL or a DNSBL is queried depends on where the domain name was obtained: RBL servers are queried with IP addresses extracted from message headers, DNSBL server are queried with domains and IP addresses extracted from the message body [source].
Rspamd and DNS Block Lists
When the RBL module is enabled, Rspamd will do a variety of DNS requests to (amongst other things) DNSBLs. There are a variety of issues involved when using DNSBLs. Rspamd will try to mitigate some of them by properly evaluating all return codes. This evaluation is a best effort though, so if the DNSBL operators change or add return codes, it may take a while for Rspamd to adjust as well.
If you want to use DNSBLs, try to use your own DNS resolver and make sure it is set up correctly, i.e. it should be a non-public & recursive resolver. Otherwise, you might not be able (see this Spamhaus post) to make use of the block lists.
"},{"location":"config/security/rspamd/#providing-custom-settings-overriding-settings","title":"Providing Custom Settings & Overriding Settings","text":"DMS brings sane default settings for Rspamd. They are located at /etc/rspamd/local.d/ inside the container (or target/rspamd/local.d/ in the repository).
What is docker-data/dms/config/?
If you want to overwrite the default settings and / or provide your own settings, you can place files at docker-data/dms/config/rspamd/override.d/ (a directory that is linked to /etc/rspamd/override.d/, if it exists) to override Rspamd and DMS default settings.
Clashing Overrides
Note that when also using the rspamd-commands file, files in override.d may be overwritten in case you adjust them manually and with the help of the file.
DMS provides the ability to do simple adjustments to Rspamd modules with the help of a single file. Just place a file called custom-commands.conf into docker-data/dms/config/rspamd/. If this file is present, DMS will evaluate it. The structure is very simple. Each line in the file looks like this:
COMMAND ARGUMENT1 ARGUMENT2 ARGUMENT3\nwhere COMMAND can be:
disable-module: disables the module with name ARGUMENT1enable-module: explicitly enables the module with name ARGUMENT1set-option-for-module: sets the value for option ARGUMENT2 to ARGUMENT3 inside module ARGUMENT1set-option-for-controller: set the value of option ARGUMENT1 to ARGUMENT2 for the controller workerset-option-for-proxy: set the value of option ARGUMENT1 to ARGUMENT2 for the proxy workerset-common-option: set the option ARGUMENT1 that defines basic Rspamd behaviour to value ARGUMENT2add-line: this will add the complete line after ARGUMENT1 (with all characters) to the file /etc/rspamd/override.d/<ARGUMENT1>An Example Is Shown Down Below
File Names & Extensions
For command 1 - 3, we append the .conf suffix to the module name to get the correct file name automatically. For commands 4 - 6, the file name is fixed (you don't even need to provide it). For command 7, you will need to provide the whole file name (including the suffix) yourself!
You can also have comments (the line starts with #) and blank lines in custom-commands.conf - they are properly handled and not evaluated.
Adjusting Modules This Way
These simple commands are meant to give users the ability to easily alter modules and their options. As a consequence, they are not powerful enough to enable multi-line adjustments. If you need to do something more complex, we advise to do that manually!
"},{"location":"config/security/rspamd/#examples-advanced-configuration","title":"Examples & Advanced Configuration","text":""},{"location":"config/security/rspamd/#a-very-basic-configuration","title":"A Very Basic Configuration","text":"You want to start using Rspamd? Rspamd is disabled by default, so you need to set the following environment variables:
ENABLE_RSPAMD=1\nENABLE_OPENDKIM=0\nENABLE_OPENDMARC=0\nENABLE_POLICYD_SPF=0\nENABLE_AMAVIS=0\nENABLE_SPAMASSASSIN=0\nThis will enable Rspamd and disable services you don't need when using Rspamd.
"},{"location":"config/security/rspamd/#adjusting-and-extending-the-very-basic-configuration","title":"Adjusting and Extending The Very Basic Configuration","text":"Rspamd is running, but you want or need to adjust it? First, create a file named custom-commands.conf under docker-data/dms/config/rspamd (which translates to /tmp/docker-mailserver/rspamd/ inside the container). Then add you changes:
set-option-for-controller secure_ip \"0.0.0.0/0\".set-option-for-module classifier-bayes autolearn true.disable-module chartable.Here is what the file looks like in the end:
# See 1.\n# ATTENTION: this disables authentication on the website - make sure you know what you're doing!\nset-option-for-controller secure_ip \"0.0.0.0/0\"\n\n# See 2.\nset-option-for-module classifier-bayes autolearn true\n\n# See 3.\ndisable-module chartable\nThere is a dedicated section for setting up DKIM with Rspamd in our documentation.
"},{"location":"config/security/rspamd/#abusix-integration","title":"Abusix Integration","text":"This subsection gives information about the integration of Abusix, \"a set of blocklists that work as an additional email security layer for your existing mail environment\". The setup is straight-forward and well documented:
<APIKEY> to your private API keyWe recommend mounting the files directly into the container, as they are rather big and not manageable with the modules script. If mounted to the correct location, Rspamd will automatically pick them up.
While Abusix can be integrated into Postfix, Postscreen and a multitude of other software, we recommend integrating Abusix only into a single piece of software running in your mail server - everything else would be excessive and wasting queries. Moreover, we recommend the integration into suitable filtering software and not Postfix itself, as software like Postscreen or Rspamd can properly evaluate the return codes and other configuration.
"},{"location":"config/security/ssl/","title":"Security | TLS (aka SSL)","text":"There are multiple options to enable SSL (via SSL_TYPE):
After installation, you can test your setup with:
checktls.comtestssl.shExposure of DNS labels through Certificate Transparency
All public Certificate Authorities (CAs) are required to log certificates they issue publicly via Certificate Transparency. This helps to better establish trust.
When using a public CA for certificates used in private networks, be aware that the associated DNS labels in the certificate are logged publicly and easily searchable. These logs are append only, you cannot redact this information.
You could use a wildcard certificate. This avoids accidentally leaking information to the internet, but keep in mind the potential security risks of wildcard certs.
"},{"location":"config/security/ssl/#the-fqdn","title":"The FQDN","text":"An FQDN (Fully Qualified Domain Name) such as mail.example.com is required for DMS to function correctly, especially for looking up the correct SSL certificate to use.
mail.example.com will still use user@example.com as the mail address. You do not need a bare domain for that.example.com is also supported.hostname -f will be used to retrieve the FQDN as configured in the below examples.*.example.com) are supported for SSL_TYPE=letsencrypt. Your configured FQDN below may be mail.example.com, and your wildcard certificate provisioned to /etc/letsencrypt/live/example.com which will be checked as a fallback FQDN by DMS.Setting the hostname correctly
Change mail.example.com below to your own FQDN.
# CLI:\ndocker run --hostname mail.example.com\nor
# compose.yaml\nservices:\nmailserver:\nhostname: mail.example.com\nTo enable Let's Encrypt for DMS, you have to:
For your DMS container:
SSL_TYPE=letsencrypt.letsencrypt folder as a volume to /etc/letsencrypt.You don't have to do anything else. Enjoy!
Note
/etc/letsencrypt/live stores provisioned certificates in individual folders named by their FQDN.
Make sure that the entire folder is mounted to DMS as there are typically symlinks from /etc/letsencrypt/live/mail.example.com to /etc/letsencrypt/archive.
Example
Add these additions to the mailserver service in your compose.yaml:
services:\nmailserver:\nhostname: mail.example.com\nenvironment:\n- SSL_TYPE=letsencrypt\nvolumes:\n- /etc/letsencrypt:/etc/letsencrypt\nCertbot provisions certificates to /etc/letsencrypt. Add a volume to store these, so that they can later be accessed by DMS container. You may also want to persist Certbot logs, just in case you need to troubleshoot.
Getting a certificate is this simple! (Referencing: Certbot docker instructions and certonly --standalone mode):
# Requires access to port 80 from the internet, adjust your firewall if needed.\ndocker run --rm -it \\\n-v \"${PWD}/docker-data/certbot/certs/:/etc/letsencrypt/\" \\\n-v \"${PWD}/docker-data/certbot/logs/:/var/log/letsencrypt/\" \\\n-p 80:80 \\\ncertbot/certbot certonly --standalone -d mail.example.com\nAdd a volume for DMS that maps the local certbot/certs/ folder to the container path /etc/letsencrypt/.
Example
Add these additions to the mailserver service in your compose.yaml:
services:\nmailserver:\nhostname: mail.example.com\nenvironment:\n- SSL_TYPE=letsencrypt\nvolumes:\n- ./docker-data/certbot/certs/:/etc/letsencrypt\nThe certificate setup is complete, but remember it will expire. Consider automating renewals.
Renewing Certificates
When running the above certonly --standalone snippet again, the existing certificate is renewed if it would expire within 30 days.
Alternatively, Certbot can look at all the certificates it manages, and only renew those nearing their expiry via the renew command:
# This will need access to port 443 from the internet, adjust your firewall if needed.\ndocker run --rm -it \\\n-v \"${PWD}/docker-data/certbot/certs/:/etc/letsencrypt/\" \\\n-v \"${PWD}/docker-data/certbot/logs/:/var/log/letsencrypt/\" \\\n-p 80:80 \\\n-p 443:443 \\\ncertbot/certbot renew\nThis process can also be automated via cron or systemd timers.
Using a different ACME CA
Certbot does support alternative certificate providers via the --server option. In most cases you'll want to use the default Let's Encrypt.
certbot-dns-cloudflare with Docker","text":"If you are unable get a certificate via the HTTP-01 (port 80) or TLS-ALPN-01 (port 443) challenge types, the DNS-01 challenge can be useful (this challenge can additionally issue wildcard certificates). This guide shows how to use the DNS-01 challenge with Cloudflare as your DNS provider.
Obtain a Cloudflare API token:
Click \"Create Token\", and choose the Edit zone DNS template (Certbot requires the ZONE:DNS:Edit permission).
Only include the necessary Zone resource configuration
Be sure to configure \"Zone Resources\" section on this page to Include -> Specific zone -> <your zone here>.
This restricts the API token to only this zone (domain) which is an important security measure.
Store the API token you received in a file cloudflare.ini with content:
dns_cloudflare_api_token = YOUR_CLOUDFLARE_TOKEN_HERE\nAs this is sensitive data, you should restrict access to it with chmod 600 and chown 0:0.
docker-data/certbot/secrets/.Your compose.yaml should include the following:
services:\nmailserver:\nenvironments:\n# Set SSL certificate type.\n- SSL_TYPE=letsencrypt\nvolumes:\n# Mount the cert folder generated by Certbot:\n- ./docker-data/certbot/certs/:/etc/letsencrypt/:ro\n\ncertbot-cloudflare:\nimage: certbot/dns-cloudflare:latest\ncommand: certonly --dns-cloudflare --dns-cloudflare-credentials /run/secrets/cloudflare-api-token -d mail.example.com\nvolumes:\n- ./docker-data/certbot/certs/:/etc/letsencrypt/\n- ./docker-data/certbot/logs/:/var/log/letsencrypt/\nsecrets:\n- cloudflare-api-token\n\n# Docs: https://docs.docker.com/engine/swarm/secrets/#use-secrets-in-compose\n# WARNING: In compose configs without swarm, the long syntax options have no effect,\n# Ensure that you properly `chmod 600` and `chown 0:0` the file on disk. Effectively treated as a bind mount.\nsecrets:\ncloudflare-api-token:\nfile: ./docker-data/certbot/secrets/cloudflare.ini\nAlternative using the docker run command (secrets feature is not available):
docker run \\\n--volume \"${PWD}/docker-data/certbot/certs/:/etc/letsencrypt/\" \\\n--volume \"${PWD}/docker-data/certbot/logs/:/var/log/letsencrypt/\" \\\n--volume \"${PWD}/docker-data/certbot/secrets/:/tmp/secrets/certbot/\"\ncertbot/dns-cloudflare \\\ncertonly --dns-cloudflare --dns-cloudflare-credentials /tmp/secrets/certbot/cloudflare.ini -d mail.example.com\nRun the service to provision a certificate:
docker compose run certbot-cloudflare\nYou should see the following log output:
Saving debug log to /var/log/letsencrypt/letsencrypt. log | Requesting a certificate for mail.example.com\nWaiting 10 seconds for DNS changes to propagate\nSuccessfully received certificate.\nCertificate is saved at: /etc/letsencrypt/live/mail.example.com/fullchain.pem\nKey is saved at: /etc/letsencrypt/live/mail.example.com/privkey.pem\nThis certificate expires on YYYY-MM-DD.\nThese files will be updated when the certificate renews.\nNEXT STEPS:\n- The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal structions.\nAfter completing the steps above, your certificate should be ready to use.
Renewing a certificate (Optional)We've only demonstrated how to provision a certificate, but it will expire in 90 days and need to be renewed before then.
In the following example, add a new service (certbot-cloudflare-renew) into compose.yaml that will handle certificate renewals:
services:\ncertbot-cloudflare-renew:\nimage: certbot/dns-cloudflare:latest\ncommand: renew --dns-cloudflare --dns-cloudflare-credentials /run/secrets/cloudflare-api-token\nvolumes:\n- ./docker-data/certbot/certs/:/etc/letsencrtypt/\n- ./docker-data/certbot/logs/:/var/log/letsencrypt/\nsecrets:\n- cloudflare-api-token\nYou can manually run this service to renew the cert within 90 days:
docker compose run certbot-cloudflare-renew\nYou should see the following output (The following log was generated with --dry-run options)
Saving debug log to /var/log/letsencrypt/letsencrypt.log\n\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\nProcessing /etc/letsencrypt/renewal/mail.example.com.conf\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\nAccount registered.\nSimulating renewal of an existing certificate for mail.example.com\nWaiting 10 seconds for DNS changes to propagate\n\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\nCongratulations, all simulated renewals succeeded:\n /etc/letsencrypt/live/mail.example.com/fullchain.pem (success)\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\nIt is recommended to automate this renewal via a task scheduler like a systemd timer or in crontab (crontab example: Checks every day if the certificate should be renewed)
0 0 * * * docker compose -f PATH_TO_YOUR_DOCKER_COMPOSE_YML up certbot-cloudflare-renew\nnginx-proxy and acme-companion with Docker","text":"If you are running a web server already, port 80 will be in use which Certbot requires. You could use the Certbot --webroot feature, but it is more common to leverage a reverse proxy that manages the provisioning and renewal of certificates for your services automatically.
In the following example, we show how DMS can be run alongside the docker containers nginx-proxy and acme-companion (Referencing: acme-companion documentation):
Start the reverse proxy (nginx-proxy):
docker run --detach \\\n--name nginx-proxy \\\n--restart always \\\n--publish 80:80 \\\n--publish 443:443 \\\n--volume \"${PWD}/docker-data/nginx-proxy/html/:/usr/share/nginx/html/\" \\\n--volume \"${PWD}/docker-data/nginx-proxy/vhost.d/:/etc/nginx/vhost.d/\" \\\n--volume \"${PWD}/docker-data/acme-companion/certs/:/etc/nginx/certs/:ro\" \\\n--volume '/var/run/docker.sock:/tmp/docker.sock:ro' \\\nnginxproxy/nginx-proxy\nThen start the certificate provisioner (acme-companion), which will provide certificates to nginx-proxy:
# Inherit `nginx-proxy` volumes via `--volumes-from`, but make `certs/` writeable:\ndocker run --detach \\\n--name nginx-proxy-acme \\\n--restart always \\\n--volumes-from nginx-proxy \\\n--volume \"${PWD}/docker-data/acme-companion/certs/:/etc/nginx/certs/:rw\" \\\n--volume \"${PWD}/docker-data/acme-companion/acme-state/:/etc/acme.sh/\" \\\n--volume '/var/run/docker.sock:/var/run/docker.sock:ro' \\\n--env 'DEFAULT_EMAIL=admin@example.com' \\\nnginxproxy/acme-companion\nStart the rest of your web server containers as usual.
Start a dummy container to provision certificates for your FQDN (eg: mail.example.com). acme-companion will detect the container and generate a Let's Encrypt certificate for your domain, which can be used by DMS:
docker run --detach \\\n--name webmail \\\n--env 'VIRTUAL_HOST=mail.example.com' \\\n--env 'LETSENCRYPT_HOST=mail.example.com' \\\n--env 'LETSENCRYPT_EMAIL=admin@example.com' \\\nnginx\nYou may want to add --env LETSENCRYPT_TEST=true to the above while testing, to avoid the Let's Encrypt certificate generation rate limits.
Make sure your mount path to the letsencrypt certificates directory is correct. Edit your compose.yaml for the mailserver service to have volumes added like below:
volumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/mail-state/:/var/mail-state/\n- ./docker-data/dms/config/:/tmp/docker-mailserver/\n- ./docker-data/acme-companion/certs/:/etc/letsencrypt/live/:ro\nThen from the compose.yaml project directory, run: docker compose up -d mailserver.
nginx-proxy and acme-companion with docker-compose","text":"The following example is the basic setup you need for using nginx-proxy and acme-companion with DMS (Referencing: acme-companion documentation):
compose.yaml You should have an existing compose.yaml with a mailserver service. Below are the modifications to add for integrating with nginx-proxy and acme-companion services:
services:\n# Add the following `environment` and `volumes` to your existing `mailserver` service:\nmailserver:\nenvironment:\n# SSL_TYPE: Uses the `letsencrypt` method to find mounted certificates.\n# VIRTUAL_HOST: The FQDN that `nginx-proxy` will configure itself to handle for HTTP[S] connections.\n# LETSENCRYPT_HOST: The FQDN for a certificate that `acme-companion` will provision and renew.\n- SSL_TYPE=letsencrypt\n- VIRTUAL_HOST=mail.example.com\n- LETSENCRYPT_HOST=mail.example.com\nvolumes:\n- ./docker-data/acme-companion/certs/:/etc/letsencrypt/live/:ro\n\n# If you don't yet have your own `nginx-proxy` and `acme-companion` setup,\n# here is an example you can use:\nreverse-proxy:\nimage: nginxproxy/nginx-proxy\ncontainer_name: nginx-proxy\nrestart: always\nports:\n# Port 80: Required for HTTP-01 challenges to `acme-companion`.\n# Port 443: Only required for containers that need access over HTTPS. TLS-ALPN-01 challenge not supported.\n- \"80:80\"\n- \"443:443\"\nvolumes:\n# `certs/`: Managed by the `acme-companion` container (_read-only_).\n# `docker.sock`: Required to interact with containers via the Docker API.\n- ./docker-data/nginx-proxy/html/:/usr/share/nginx/html/\n- ./docker-data/nginx-proxy/vhost.d/:/etc/nginx/vhost.d/\n- ./docker-data/acme-companion/certs/:/etc/nginx/certs/:ro\n- /var/run/docker.sock:/tmp/docker.sock:ro\n\nacme-companion:\nimage: nginxproxy/acme-companion\ncontainer_name: nginx-proxy-acme\nrestart: always\nenvironment:\n# When `volumes_from: [nginx-proxy]` is not supported,\n# reference the _reverse-proxy_ `container_name` here:\n- NGINX_PROXY_CONTAINER=nginx-proxy\nvolumes:\n# `html/`: Write ACME HTTP-01 challenge files that `nginx-proxy` will serve.\n# `vhost.d/`: To enable web access via `nginx-proxy` to HTTP-01 challenge files.\n# `certs/`: To store certificates and private keys.\n# `acme-state/`: To persist config and state for the ACME provisioner (`acme.sh`).\n# `docker.sock`: Required to interact with containers via the Docker API.\n- ./docker-data/nginx-proxy/html/:/usr/share/nginx/html/\n- ./docker-data/nginx-proxy/vhost.d/:/etc/nginx/vhost.d/\n- ./docker-data/acme-companion/certs/:/etc/nginx/certs/:rw\n- ./docker-data/acme-companion/acme-state/:/etc/acme.sh/\n- /var/run/docker.sock:/var/run/docker.sock:ro\nOptional ENV vars worth knowing about
Per container ENV that acme-companion will detect to override default provisioning settings:
LETSENCRYPT_TEST=true: Recommended during initial setup. Otherwise the default production endpoint has a rate limit of 5 duplicate certificates per week. Overrides ACME_CA_URI to use the Let's Encrypt staging endpoint.LETSENCRYPT_EMAIL: For when you don't use DEFAULT_EMAIL on acme-companion, or want to assign a different email contact for this container.LETSENCRYPT_KEYSIZE: Allows you to configure the type (RSA or ECDSA) and size of the private key for your certificate. Default is RSA 4096.LETSENCRYPT_RESTART_CONTAINER=true: When the certificate is renewed, the entire container will be restarted to ensure the new certificate is used.acme-companion ENV for default settings that apply to all containers using LETSENCRYPT_HOST:
DEFAULT_EMAIL: An email address that the CA (eg: Let's Encrypt) can contact you about expiring certificates, failed renewals, or for account recovery. You may want to use an email address not handled by your mail server to ensure deliverability in the event your mail server breaks.CERTS_UPDATE_INTERVAL: If you need to adjust the frequency to check for renewals. 3600 seconds (1 hour) by default.DEBUG=1: Should be helpful when troubleshooting provisioning issues from acme-companion logs.ACME_CA_URI: Useful in combination with CA_BUNDLE to use a private CA. To change the default Let's Encrypt endpoint to the staging endpoint, use https://acme-staging-v02.api.letsencrypt.org/directory.CA_BUNDLE: If you want to use a private CA instead of Let's Encrypt.Alternative to required ENV on mailserver service
While you will still need both nginx-proxy and acme-companion containers, you can manage certificates without adding ENV vars to containers. Instead the ENV is moved into a file and uses the acme-companion feature Standalone certificates.
This requires adding another shared volume between nginx-proxy and acme-companion:
services:\nreverse-proxy:\nvolumes:\n- ./docker-data/nginx-proxy/conf.d/:/etc/nginx/conf.d/\n\nacme-companion:\nvolumes:\n- ./docker-data/nginx-proxy/conf.d/:/etc/nginx/conf.d/\n- ./docker-data/acme-companion/standalone.sh:/app/letsencrypt_user_data:ro\nacme-companion mounts a shell script (standalone.sh), which defines variables to customize certificate provisioning:
# A list IDs for certificates to provision:\nLETSENCRYPT_STANDALONE_CERTS=('mail')\n\n# Each ID inserts itself into the standard `acme-companion` supported container ENV vars below.\n# The LETSENCRYPT_<ID>_HOST var is a list of FQDNs to provision a certificate for as the SAN field:\nLETSENCRYPT_mail_HOST=('mail.example.com')\n\n# Optional variables:\nLETSENCRYPT_mail_TEST=true\nLETSENCRYPT_mail_EMAIL='admin@example.com'\n# RSA-4096 => `4096`, ECDSA-256 => `ec-256`:\nLETSENCRYPT_mail_KEYSIZE=4096\nUnlike with the equivalent ENV for containers, changes to this file will not be detected automatically. You would need to wait until the next renewal check by acme-companion (every hour by default), restart acme-companion, or manually invoke the service loop:
docker exec nginx-proxy-acme /app/signal_le_service
Version 6.2 and later of the Synology NAS DSM OS now come with an interface to generate and renew letencrypt certificates. Navigation into your DSM control panel and go to Security, then click on the tab Certificate to generate and manage letsencrypt certificates.
Amongst other things, you can use these to secure your mail server. DSM locates the generated certificates in a folder below /usr/syno/etc/certificate/_archive/.
Navigate to that folder and note the 6 character random folder name of the certificate you'd like to use. Then, add the following to your compose.yaml declaration file:
volumes:\n- /usr/syno/etc/certificate/_archive/<your-folder>/:/tmp/dms/custom-certs/\nenvironment:\n- SSL_TYPE=manual\n- SSL_CERT_PATH=/tmp/dms/custom-certs/fullchain.pem\n- SSL_KEY_PATH=/tmp/dms/custom-certs/privkey.pem\nDSM-generated letsencrypt certificates get auto-renewed every three months.
"},{"location":"config/security/ssl/#caddy","title":"Caddy","text":"For Caddy v2 you can specify the key_type in your server's global settings, which would end up looking something like this if you're using a Caddyfile:
{\n debug\n admin localhost:2019\n http_port 80\n https_port 443\n default_sni example.com\n key_type rsa4096\n}\nIf you are instead using a json config for Caddy v2, you can set it in your site's TLS automation policies:
Caddy v2 JSON example snippet{\n\"apps\": {\n\"http\": {\n\"servers\": {\n\"srv0\": {\n\"listen\": [\n\":443\"\n],\n\"routes\": [\n{\n\"match\": [\n{\n\"host\": [\n\"mail.example.com\",\n]\n}\n],\n\"handle\": [\n{\n\"handler\": \"subroute\",\n\"routes\": [\n{\n\"handle\": [\n{\n\"body\": \"\",\n\"handler\": \"static_response\"\n}\n]\n}\n]\n}\n],\n\"terminal\": true\n},\n]\n}\n}\n},\n\"tls\": {\n\"automation\": {\n\"policies\": [\n{\n\"subjects\": [\n\"mail.example.com\",\n],\n\"key_type\": \"rsa2048\",\n\"issuer\": {\n\"email\": \"admin@example.com\",\n\"module\": \"acme\"\n}\n},\n{\n\"issuer\": {\n\"email\": \"admin@example.com\",\n\"module\": \"acme\"\n}\n}\n]\n}\n}\n}\n}\nThe generated certificates can then be mounted:
volumes:\n- ${CADDY_DATA_DIR}/certificates/acme-v02.api.letsencrypt.org-directory/mail.example.com/mail.example.com.crt:/etc/letsencrypt/live/mail.example.com/fullchain.pem\n- ${CADDY_DATA_DIR}/certificates/acme-v02.api.letsencrypt.org-directory/mail.example.com/mail.example.com.key:/etc/letsencrypt/live/mail.example.com/privkey.pem\nTraefik is an open-source application proxy using the ACME protocol. Traefik can request certificates for domains and subdomains, and it will take care of renewals, challenge negotiations, etc. We strongly recommend to use Traefik's major version 2.
Traefik's storage format is natively supported if the acme.json store is mounted into the container at /etc/letsencrypt/acme.json. The file is also monitored for changes and will trigger a reload of the mail services (Postfix and Dovecot).
Wildcard certificates are supported. If your FQDN is mail.example.com and your wildcard certificate is *.example.com, add the ENV: SSL_DOMAIN=example.com.
DMS will select it's certificate from acme.json checking these ENV for a matching FQDN (in order of priority):
${SSL_DOMAIN}${HOSTNAME}${DOMAINNAME}This setup only comes with one caveat: The domain has to be configured on another service for Traefik to actually request it from Let's Encrypt, i.e. Traefik will not issue a certificate without a service / router demanding it.
Example CodeHere is an example setup for docker-compose:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\nhostname: mail.example.com\nvolumes:\n- ./docker-data/traefik/acme.json:/etc/letsencrypt/acme.json:ro\nenvironment:\nSSL_TYPE: letsencrypt\nSSL_DOMAIN: mail.example.com\n# for a wildcard certificate, use\n# SSL_DOMAIN: example.com\n\nreverse-proxy:\nimage: docker.io/traefik:latest #v2.5\ncontainer_name: docker-traefik\nports:\n- \"80:80\"\n- \"443:443\"\ncommand:\n- --providers.docker\n- --entrypoints.http.address=:80\n- --entrypoints.http.http.redirections.entryPoint.to=https\n- --entrypoints.http.http.redirections.entryPoint.scheme=https\n- --entrypoints.https.address=:443\n- --entrypoints.https.http.tls.certResolver=letsencrypt\n- --certificatesresolvers.letsencrypt.acme.email=admin@example.com\n- --certificatesresolvers.letsencrypt.acme.storage=/acme.json\n- --certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=http\nvolumes:\n- ./docker-data/traefik/acme.json:/acme.json\n- /var/run/docker.sock:/var/run/docker.sock:ro\n\nwhoami:\nimage: docker.io/traefik/whoami:latest\nlabels:\n- \"traefik.http.routers.whoami.rule=Host(`mail.example.com`)\"\nWarning
Use self-signed certificates only for testing purposes!
This feature requires you to provide the following files into your docker-data/dms/config/ssl/ directory (internal location: /tmp/docker-mailserver/ssl/):
<FQDN>-key.pem<FQDN>-cert.pemdemoCA/cacert.pemWhere <FQDN> is the FQDN you've configured for your DMS container.
Add SSL_TYPE=self-signed to your DMS environment variables. Postfix and Dovecot will be configured to use the provided certificate (.pem files above) during container startup.
One way to generate self-signed certificates is with Smallstep's step CLI. This is exactly what DMS does for creating test certificates.
For example with the FQDN mail.example.test, you can generate the required files by running:
#! /bin/sh\nmkdir -p demoCA\n\nstep certificate create \"Smallstep Root CA\" \"demoCA/cacert.pem\" \"demoCA/cakey.pem\" \\\n--no-password --insecure \\\n--profile root-ca \\\n--not-before \"2021-01-01T00:00:00+00:00\" \\\n--not-after \"2031-01-01T00:00:00+00:00\" \\\n--san \"example.test\" \\\n--san \"mail.example.test\" \\\n--kty RSA --size 2048\n\nstep certificate create \"Smallstep Leaf\" mail.example.test-cert.pem mail.example.test-key.pem \\\n--no-password --insecure \\\n--profile leaf \\\n--ca \"demoCA/cacert.pem\" \\\n--ca-key \"demoCA/cakey.pem\" \\\n--not-before \"2021-01-01T00:00:00+00:00\" \\\n--not-after \"2031-01-01T00:00:00+00:00\" \\\n--san \"example.test\" \\\n--san \"mail.example.test\" \\\n--kty RSA --size 2048\nIf you'd rather not install the CLI tool locally to run the step commands above; you can save the script above to a file such as generate-certs.sh (and make it executable chmod +x generate-certs.sh) in a directory that you want the certs to be placed (eg: docker-data/dms/custom-certs/), then use docker to run that script in a container:
# '--user' is to keep ownership of the files written to\n# the local volume to use your systems User and Group ID values.\ndocker run --rm -it \\\n--user \"$(id -u):$(id -g)\" \\\n--volume \"${PWD}/docker-data/dms/custom-certs/:/tmp/step-ca/\" \\\n--workdir \"/tmp/step-ca/\" \\\n--entrypoint \"/tmp/step-ca/generate-certs.sh\" \\\nsmallstep/step-ca\nYou can also provide your own certificate files. Add these entries to your compose.yaml:
volumes:\n- ./docker-data/dms/custom-certs/:/tmp/dms/custom-certs/:ro\nenvironment:\n- SSL_TYPE=manual\n# Values should match the file paths inside the container:\n- SSL_CERT_PATH=/tmp/dms/custom-certs/public.crt\n- SSL_KEY_PATH=/tmp/dms/custom-certs/private.key\nThis will mount the path where your certificate files reside locally into the read-only container folder: /tmp/dms/custom-certs.
The local and internal paths may be whatever you prefer, so long as both SSL_CERT_PATH and SSL_KEY_PATH point to the correct internal file paths. The certificate files may also be named to your preference, but should be PEM encoded.
SSL_ALT_CERT_PATH and SSL_ALT_KEY_PATH are additional ENV vars to support a 2nd certificate as a fallback. Commonly known as hybrid or dual certificate support. This is useful for using a modern ECDSA as your primary certificate, and RSA as your fallback for older connections. They work in the same manner as the non-ALT versions.
Info
You may have to restart DMS once the certificates change.
"},{"location":"config/security/ssl/#testing-a-certificate-is-valid","title":"Testing a Certificate is Valid","text":"From your host:
docker exec mailserver openssl s_client \\\n-connect 0.0.0.0:25 \\\n-starttls smtp \\\n-CApath /etc/ssl/certs/\nOr:
docker exec mailserver openssl s_client \\\n-connect 0.0.0.0:143 \\\n-starttls imap \\\n-CApath /etc/ssl/certs/\nAnd you should see the certificate chain, the server certificate and: Verify return code: 0 (ok)
In addition, to verify certificate dates:
docker exec mailserver openssl s_client \\\n-connect 0.0.0.0:25 \\\n-starttls smtp \\\n-CApath /etc/ssl/certs/ \\\n2>/dev/null | openssl x509 -noout -dates\nWarning
Not recommended for purposes other than testing.
Add this to docker-data/dms/config/dovecot.cf:
ssl = yes\ndisable_plaintext_auth=no\nThese options in conjunction mean:
If you have another source for SSL/TLS certificates you can import them into the server via an external script. The external script can be found here: external certificate import script.
This is a community contributed script, and in most cases you will have better support via our Change Detection service (automatic for SSL_TYPE of manual and letsencrypt) - Unless you're using LDAP which disables the service.
Script Compatibility
/etc/dms/tls/cert and /etc/dms/tls/key intended for internal use only.fullchain.key + privkey.pem as your mounted file names. That may not align with your provisioning method.ALT fallback certificates (for supporting dual/hybrid, RSA + ECDSA).The steps to follow are these:
./docker-data/dms/custom-certs/ (volume mounted to: /tmp/ssl/)fullchain.key and privkey.pem./docker-data/dms/config/ (volume mounted to: /tmp/docker-mailserver/)chmod +x tomav-renew-certs.sh)docker exec mailserver /tmp/docker-mailserver/tomav-renew-certs.shIf an error occurs the script will inform you. If not you will see both postfix and dovecot restart.
After the certificates have been loaded you can check the certificate:
openssl s_client \\\n-servername mail.example.com \\\n-connect 192.168.0.72:465 \\\n2>/dev/null | openssl x509\n\n# or\n\nopenssl s_client \\\n-servername mail.example.com \\\n-connect mail.example.com:465 \\\n2>/dev/null | openssl x509\nOr you can check how long the new certificate is valid with commands like:
export SITE_URL=\"mail.example.com\"\nexport SITE_IP_URL=\"192.168.0.72\" # can also use `mail.example.com`\nexport SITE_SSL_PORT=\"993\" # imap port dovecot\n\n##works: check if certificate will expire in two weeks\n#2 weeks is 1209600 seconds\n#3 weeks is 1814400\n#12 weeks is 7257600\n#15 weeks is 9072000\n\ncertcheck_2weeks=`openssl s_client -connect ${SITE_IP_URL}:${SITE_SSL_PORT} \\\n-servername ${SITE_URL} 2> /dev/null | openssl x509 -noout -checkend 1209600`\n\n####################################\n#notes: output could be either:\n#Certificate will not expire\n#Certificate will expire\n####################\nWhat does the script that imports the certificates do:
/tmp/ssl.You can of course run the script by cron once a week or something. In that way you could automate cert renewal. If you do so it is probably wise to run an automated check on certificate expiry as well. Such a check could look something like this:
# This script is run inside docker-mailserver via 'docker exec ...', using the 'mail' command to send alerts.\n## code below will alert if certificate expires in less than two weeks\n## please adjust varables!\n## make sure the 'mail -s' command works! Test!\n\nexport SITE_URL=\"mail.example.com\"\nexport SITE_IP_URL=\"192.168.2.72\" # can also use `mail.example.com`\nexport SITE_SSL_PORT=\"993\" # imap port dovecot\n# Below can be from a different domain; like your personal email, not handled by this docker-mailserver:\nexport ALERT_EMAIL_ADDR=\"external-account@gmail.com\"\n\ncertcheck_2weeks=`openssl s_client -connect ${SITE_IP_URL}:${SITE_SSL_PORT} \\\n-servername ${SITE_URL} 2> /dev/null | openssl x509 -noout -checkend 1209600`\n\n####################################\n#notes: output can be\n#Certificate will not expire\n#Certificate will expire\n####################\n\n#echo \"certcheck 2 weeks gives $certcheck_2weeks\"\n\n##automated check you might run by cron or something\n## does the certificate expire within two weeks?\n\nif [ \"$certcheck_2weeks\" = \"Certificate will not expire\" ]; then\necho \"all is well, certwatch 2 weeks says $certcheck_2weeks\"\nelse\necho \"Cert seems to be expiring pretty soon, within two weeks: $certcheck_2weeks\"\necho \"we will send an alert email and log as well\"\nlogger Certwatch: cert $SITE_URL will expire in two weeks\n echo \"Certwatch: cert $SITE_URL will expire in two weeks\" | mail -s \"cert $SITE_URL expires in two weeks \" $ALERT_EMAIL_ADDR\nfi\nBy default DMS uses ffdhe4096 from IETF RFC 7919. These are standardized pre-defined DH groups and the only available DH groups for TLS 1.3. It is discouraged to generate your own DH parameters as it is often less secure.
Despite this, if you must use non-standard DH parameters or you would like to swap ffdhe4096 for a different group (eg ffdhe2048); Add your own PEM encoded DH params file via a volume to /tmp/docker-mailserver/dhparams.pem. This will replace DH params for both Dovecot and Postfix services during container startup.
Prefer ports with Implicit TLS ports, they're more secure than ports using Explicit TLS, and if you use a Reverse Proxy should be less hassle.
"},{"location":"config/security/understanding-the-ports/#overview-of-email-ports","title":"Overview of Email Ports","text":"Protocol Explicit TLS1 Implicit TLS Purpose Enabled by Default ESMTP 25 N/A Transfer2 Yes ESMTP 587 4653 Submission Yes POP3 110 995 Retrieval No IMAP4 143 993 Retrieval YesSTARTTLS. On ports 110, 143 and 587, DMS will reject a connection that cannot be secured. Port 25 is required to support insecure connections.There is a common misconception of this port due to it's history detailed by various communities and blogs articles on the topic (including by popular mail relay services).
Port 465 was briefly assigned the role of SMTPS in 1997 as an secure alternative to Port 25 between MTA exchanges. Then RFC 2487 (STARTTLS) while still in a draft status in late 1998 had IANA revoke the SMTPS assignment. The draft history was modified to exclude all mention of port 465 and SMTPS.
In 2018 RFC 8314 was published which revives Port 465 as an Implicit TLS alternative to Port 587 for mail submission. It details very clearly that gaining adoption of 465 as the preferred port will take time. IANA reassigned port 465 as the submissions service. Any unofficial usage as SMTPS is legacy and has been for over two decades.
Understand that port 587 is more broadly supported due to this history and that lots of software in that time has been built or configured with that port in mind. STARTTLS is known to have various CVEs discovered even in recent years, do not be misled by any advice implying it should be preferred over implicit TLS. Trust in more official sources, such as the config Postfix has which acknowledges the submissions port (465).
flowchart LR\n subgraph your-server [\"Your Server\"]\n in_25(25) --> server\n in_465(465) --> server\n server((\"docker-mailserver<br/>hello@world.com\"))\n server --- out_25(25)\n server --- out_465(465)\n end\n\n third-party(\"Third-party<br/>(sending you email)\") ---|\"Receive email for<br/>hello@world.com\"| in_25\n\n subgraph clients [\"Clients (MUA)\"]\n mua-client(Thunderbird,<br/>Webmail,<br/>Mutt,<br/>etc)\n mua-service(Backend software<br/>on another server)\n end\n clients ---|\"Send email as<br/>hello@world.com\"| in_465\n\n out_25(25) -->|\"Direct<br/>Delivery\"| tin_25\n out_465(465) --> relay(\"MTA<br/>Relay Server\") --> tin_25(25)\n\n subgraph third-party-server[\"Third-party Server\"]\n third-party-mta(\"MTA<br/>friend@example.com\")\n tin_25(25) --> third-party-mta\n endMail arriving at your server will be processed and stored in a mailbox, or sent outbound to another mail server.
Note
When submitting mail (inbound) to be sent (outbound), this involves two separate connections to negotiate and secure. There may be additional intermediary connections which DMS is not involved in, and thus unable to ensure encrypted transit throughout delivery.
"},{"location":"config/security/understanding-the-ports/#outbound-traffic-on-the-right","title":"Outbound Traffic (On the Right)","text":"Mail being sent from your server is either being relayed through another MTA (eg: SendGrid), or direct to an MTA responsible for an email address (eg: Gmail).
Tip
DMS can function as a relay too, but professional relay services have a trusted reputation (which increases success of delivery).
An MTA with low reputation can affect if mail is treated as junk, or even rejected.
Note
At best, you can only ensure a secure connection between the MTA you directly connect to. The receiving MTA may relay that mail to another MTA (and so forth), each connection may not be enforcing TLS.
"},{"location":"config/security/understanding-the-ports/#explicit-vs-implicit-tls","title":"Explicit vs Implicit TLS","text":""},{"location":"config/security/understanding-the-ports/#explicit-tls-aka-opportunistic-tls-opt-in-encryption","title":"Explicit TLS (aka Opportunistic TLS) - Opt-in Encryption","text":"Communication on these ports begin in cleartext. Upgrading to an encrypted connection must be requested explicitly through the STARTTLS protocol and successfully negotiated.
Sometimes a reverse-proxy is involved, but is misconfigured or lacks support for the STARTTLS negotiation to succeed.
Note
STARTTLS is unsuccessful, mail can be received over an unencrypted connection. You can better secure this port between trusted parties with the addition of MTA-STS, STARTTLS Policy List, DNSSEC and DANE.Warning
STARTTLS continues to have vulnerabilities found (Nov 2021 article), as per RFC 8314 (Section 4.1) you are encouraged to prefer Implicit TLS where possible.
Support for STARTTLS is not always implemented correctly, which can lead to leaking credentials (like a client sending too early) prior to a TLS connection being established. Third-parties such as some ISPs have also been known to intercept the STARTTLS exchange, modifying network traffic to prevent establishing a secure connection.
Communication on these ports are always encrypted (enforced, thus implicit), avoiding the potential risks with STARTTLS (Explicit TLS).
While Explicit TLS can provide the same benefit (when STARTTLS is successfully negotiated), Implicit TLS more reliably avoids concerns with connection manipulation and compatibility.
Todo
This section should provide any related configuration advice, and probably expand on and link to resources about DANE, DNSSEC, MTA-STS and STARTTLS Policy list, with advice on how to configure/setup these added security layers.
Todo
A related section or page on ciphers used may be useful, although less important for users to be concerned about.
"},{"location":"config/security/understanding-the-ports/#tls-connections-for-a-mail-server-compared-to-web-browsers","title":"TLS connections for a Mail Server, compared to web browsers","text":"Unlike with HTTP where a web browser client communicates directly with the server providing a website, a secure TLS connection as discussed below does not provide the equivalent safety that HTTPS does when the transit of email (receiving or sending) is sent through third-parties, as the secure connection is only between two machines, any additional machines (MTAs) between the MUA and the MDA depends on them establishing secure connections between one another successfully.
Other machines that facilitate a connection that generally aren't taken into account can exist between a client and server, such as those where your connection passes through your ISP provider are capable of compromising a cleartext connection through interception.
When refactoring, writing or altering scripts or other files, adhere to these rules:
shellcheck to check your scripts! Your contributions are checked by GitHub Actions too, so you will need to do this. You can lint your work with make lint to check against all targets..editorconfig file./bin/bash instead of /bin/sh in scriptsYou will need to have Docker installed. Navigate into the docs/ directory. Then run:
docker run --rm -it -p 8000:8000 -v \"${PWD}:/docs\" squidfunk/mkdocs-material\nThis serves the documentation on your local machine on port 8000. Each change will be hot-reloaded onto the page you view, just edit, save and look at the result.
This project is Open Source. That means that you can contribute on enhancements, bug fixing or improving the documentation.
"},{"location":"contributing/issues-and-pull-requests/#opening-an-issue","title":"Opening an Issue","text":"Attention
Before opening an issue, read the README carefully, study the docs for your version (maybe latest), the Postfix/Dovecot documentation and your search engine you trust. The issue tracker is not meant to be used for unrelated questions!
When opening an issue, please provide details use case to let the community reproduce your problem. Please start DMS with the environment variable LOG_LEVEL set to debug or trace and paste the output into the issue.
Attention
Use the issue templates to provide the necessary information. Issues which do not use these templates are not worked on and closed.
By raising issues, I agree to these terms and I understand, that the rules set for the issue tracker will help both maintainers as well as everyone to find a solution.
Maintainers take the time to improve on this project and help by solving issues together. It is therefore expected from others to make an effort and comply with the rules.
"},{"location":"contributing/issues-and-pull-requests/#pull-requests","title":"Pull Requests","text":"Motivation
You want to add a feature? Feel free to start creating an issue explaining what you want to do and how you're thinking doing it. Other users may have the same need and collaboration may lead to better results.
"},{"location":"contributing/issues-and-pull-requests/#submit-a-pull-request","title":"Submit a Pull-Request","text":"The development workflow is the following:
git clone --recurse-submodules ... or run git submodule update --init --recursive after you cloned your forkmaster. Please use the pull-request template to provide a minimum of contextual information and make sure to meet the requirements of the checklist.Pull requests are automatically tested against the CI and will be reviewed when tests pass. When your changes are validated, your branch is merged. CI builds the new :edge image immediately and your changes will be includes in the next version release.
Program testing can be used to show the presence of bugs, but never to show their absence!
\u2013 Edsger Wybe Dijkstra
"},{"location":"contributing/tests/#introduction","title":"Introduction","text":"DMS employs a variety of unit and integration tests. All tests and associated configuration is stored in the test/ directory. If you want to change existing functionality or integrate a new feature into DMS, you will probably need to work with our test suite.
Can I use macOS?
We do not support running linting, tests, etc. on macOS at this time. Please use a Linux VM, Debian/Ubuntu is recommended.
"},{"location":"contributing/tests/#about","title":"About","text":"We use BATS (Bash Automated Testing System) and additional support libraries. BATS is very similar to Bash, and one can easily and quickly get an understanding of how tests in a single file are run. A test file template provides a minimal working example for newcomers to look at.
"},{"location":"contributing/tests/#structure","title":"Structure","text":"The test/ directory contains multiple directories. Among them is the bats/ directory (which is the BATS git submodule) and the helper/ directory. The latter is especially interesting because it contains common support functionality used in almost every test. Actual tests are located in test/tests/.
Test suite undergoing refactoring
We are currently in the process of restructuring all of our tests. Tests will be moved into test/tests/parallel/ and new tests should be placed there as well.
There are many functions that aid in writing tests. We urge you to use them! They will not only ease writing a test but they will also do their best to ensure there are no race conditions or other unwanted side effects. To learn about the functions we provide, you can:
test/helper/ directory which contains all files that can (and will) be loaded in test filesWe encourage you to try both of the approaches mentioned above. To make understanding and using the helper functions easy, every function contains detailed documentation comments. Read them carefully!
"},{"location":"contributing/tests/#how-are-tests-run","title":"How Are Tests Run?","text":"Tests are split into two categories:
test/tests/parallel/: Multiple test files are run concurrently to reduce the required time to complete the test suite. A test file will presently run it's own defined test-cases in a sequential order.test/tests/serial/: Each test file is queued up to run sequentially. Tests that are unable to support running concurrently belong here.Parallel tests are further partitioned into smaller sets. If your system has the resources to support running more than one of those sets at a time this is perfectly ok (our CI runs tests by distributing the sets across multiple test runners). Care must be taken not to mix running the serial tests while a parallel set is also running; this is handled for you when using make tests.
To run the test suite, you will need to:
jq and (GNU) parallel (under Ubuntu, use sudo apt-get -y install jq parallel)git submodule update --init --recursive if you haven't already initialized the git submodulesWe use make to run commands.
make build to create or update the local mailserver-testing:ci Docker image (using the projects Dockerfile)make clean testsmake clean generate-accounts test/<TEST NAME WITHOUT .bats SUFFIX>make clean generate-accounts test/<TEST NAME WITHOUT .bats SUFFIX>,<TEST NAME WITHOUT .bats SUFFIX> (just add a , and then immediately write the new test name)make clean generate-accounts tests/parallel/setX where X is the number of the set or make clean generate-accounts tests/serialIf your machine is capable, you can increase the amount of tests that are run simultaneously by prepending the make clean all command with BATS_PARALLEL_JOBS=X (i.e. BATS_PARALLEL_JOBS=X make clean all). This wil speed up the test procedure. You can also run all tests in serial by setting BATS_PARALLEL_JOBS=1 this way.
The default value of BATS_PARALLEL_JOBS is 2. This can be increased if your system has the resources spare to support running more jobs at once to complete the test suite sooner.
Test Output when Running in Parallel
When running tests in parallel (with make clean generate-accounts tests/parallel/setX), BATS will delay outputting the results until completing all test cases within a file.
This likewise delays the reporting of test-case failures. When troubleshooting parallel set tests, you may prefer to run specific tests you're working on serially (as demonstrated in the example below).
When writing tests, ensure that parallel set tests still pass when run in parallel. You need to account for other tests running in parallel that may interfere with your own tests logic.
"},{"location":"contributing/tests/#an-example","title":"An Example","text":"In this example, you've made a change to the Rspamd feature support (or adjusted it's tests). First verify no regressions have been introduced by running it's specific test file:
$ make clean generate-accounts test/rspamd\nrspamd.bats\n \u2713 [Rspamd] Postfix's main.cf was adjusted [12]\n \u2713 [Rspamd] normal mail passes fine [44]\n \u2713 [Rspamd] detects and rejects spam [122]\n \u2713 [Rspamd] detects and rejects virus [189]\nAs your feature work progresses your change for Rspamd also affects ClamAV. As your change now spans more than just the Rspamd test file, you could run multiple test files serially:
$ make clean generate-accounts test/rspamd,clamav\nrspamd.bats\n \u2713 [Rspamd] Postfix's main.cf was adjusted [12]\n \u2713 [Rspamd] normal mail passes fine [44]\n \u2713 [Rspamd] detects and rejects spam [122]\n \u2713 [Rspamd] detects and rejects virus [189]\nclamav.bats\n \u2713 [ClamAV] log files exist at /var/log/mail directory [68]\n \u2713 [ClamAV] should be identified by Amavis [67]\n \u2713 [ClamAV] freshclam cron is enabled [76]\n \u2713 [ClamAV] env CLAMAV_MESSAGE_SIZE_LIMIT is set correctly [63]\n \u2713 [ClamAV] rejects virus [60]\nYou're almost finished with your change before submitting it as a PR. It's a good idea to run the full parallel set those individual tests belong to (especially if you've modified any tests):
$ make clean generate-accounts tests/parallel/set1\ndefault_relay_host.bats\n \u2713 [Relay] (ENV) 'DEFAULT_RELAY_HOST' should configure 'main.cf:relayhost' [88]\nspam_virus/amavis.bats\n \u2713 [Amavis] SpamAssassin integration should be active [1165]\nspam_virus/clamav.bats\n \u2713 [ClamAV] log files exist at /var/log/mail directory [73]\n \u2713 [ClamAV] should be identified by Amavis [67]\n \u2713 [ClamAV] freshclam cron is enabled [76]\n...\nEven better, before opening a PR run the full test suite:
$ make clean tests\n...\nThis example provides you only with a basic example of what a minimal setup could look like. We strongly recommend that you go through the configuration file yourself and adjust everything to your needs. The default compose.yaml can be used for the purpose out-of-the-box, see the Usage chapter.
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\n# Provide the FQDN of your mail server here (Your DNS MX record should point to this value)\nhostname: mail.example.com\nports:\n- \"25:25\"\n- \"465:465\"\n- \"587:587\"\n- \"993:993\"\nvolumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/mail-state/:/var/mail-state/\n- ./docker-data/dms/mail-logs/:/var/log/mail/\n- ./docker-data/dms/config/:/tmp/docker-mailserver/\n- /etc/localtime:/etc/localtime:ro\nenvironment:\n- ENABLE_RSPAMD=1\n- ENABLE_CLAMAV=1\n- ENABLE_FAIL2BAN=1\ncap_add:\n- NET_ADMIN # For Fail2Ban to work\nrestart: always\nNote There are currently no LDAP maintainers. If you encounter issues, please raise them in the issue tracker, but be aware that the core maintainers team will most likely not be able to help you. We would appreciate and we encourage everyone to actively participate in maintaining LDAP-related code by becoming a maintainer!
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\n# Provide the FQDN of your mail server here (Your DNS MX record should point to this value)\nhostname: mail.example.com\nports:\n- \"25:25\"\n- \"465:465\"\n- \"587:587\"\n- \"993:993\"\nvolumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/mail-state/:/var/mail-state/\n- ./docker-data/dms/mail-logs/:/var/log/mail/\n- ./docker-data/dms/config/:/tmp/docker-mailserver/\n- /etc/localtime:/etc/localtime:ro\nenvironment:\n- ACCOUNT_PROVISIONER=LDAP\n- LDAP_SERVER_HOST=ldap # your ldap container/IP/ServerName\n- LDAP_SEARCH_BASE=ou=people,dc=localhost,dc=localdomain\n- LDAP_BIND_DN=cn=admin,dc=localhost,dc=localdomain\n- LDAP_BIND_PW=admin\n- LDAP_QUERY_FILTER_USER=(&(mail=%s)(mailEnabled=TRUE))\n- LDAP_QUERY_FILTER_GROUP=(&(mailGroupMember=%s)(mailEnabled=TRUE))\n- LDAP_QUERY_FILTER_ALIAS=(|(&(mailAlias=%s)(objectClass=PostfixBookMailForward))(&(mailAlias=%s)(objectClass=PostfixBookMailAccount)(mailEnabled=TRUE)))\n- LDAP_QUERY_FILTER_DOMAIN=(|(&(mail=*@%s)(objectClass=PostfixBookMailAccount)(mailEnabled=TRUE))(&(mailGroupMember=*@%s)(objectClass=PostfixBookMailAccount)(mailEnabled=TRUE))(&(mailalias=*@%s)(objectClass=PostfixBookMailForward)))\n- DOVECOT_PASS_FILTER=(&(objectClass=PostfixBookMailAccount)(uniqueIdentifier=%n))\n- DOVECOT_USER_FILTER=(&(objectClass=PostfixBookMailAccount)(uniqueIdentifier=%n))\n- ENABLE_SASLAUTHD=1\n- SASLAUTHD_MECHANISMS=ldap\n- SASLAUTHD_LDAP_SERVER=ldap\n- SASLAUTHD_LDAP_BIND_DN=cn=admin,dc=localhost,dc=localdomain\n- SASLAUTHD_LDAP_PASSWORD=admin\n- SASLAUTHD_LDAP_SEARCH_BASE=ou=people,dc=localhost,dc=localdomain\n- SASLAUTHD_LDAP_FILTER=(&(objectClass=PostfixBookMailAccount)(uniqueIdentifier=%U))\n- POSTMASTER_ADDRESS=postmaster@localhost.localdomain\nrestart: always\nInfo
This was originally a community contributed guide. Please let us know via a Github Issue if you're having any difficulty following the guide so that we can update it.
This guide is focused on only using SMTP ports (not POP3 and IMAP) with the intent to relay mail received from another service to an external email address (eg: user@gmail.com). It is not intended for mailbox storage of real users.
In this setup DMS is not intended to receive email from the outside world, so no anti-spam or anti-virus software is needed, making the service lighter to run.
setup
The setup command used below is to be run inside the container.
Open Relays
Adding the docker network's gateway to the list of trusted hosts (eg: using the network or connected-networks option), can create an open relay. For instance if IPv6 is enabled on the host machine, but not in Docker.
Create the file compose.yaml with a content like this:
Example
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\n# Provide the FQDN of your mail server here (Your DNS MX record should point to this value)\nhostname: mail.example.com\nports:\n- \"25:25\"\n- \"587:587\"\n- \"465:465\"\nvolumes:\n- ./docker-data/dms/mail-data/:/var/mail/\n- ./docker-data/dms/mail-state/:/var/mail-state/\n- ./docker-data/dms/mail-logs/:/var/log/mail/\n- ./docker-data/dms/config/:/tmp/docker-mailserver/\n- /etc/localtime:/etc/localtime:ro\nenvironment:\n- ENABLE_FAIL2BAN=1\n# Using letsencrypt for SSL/TLS certificates:\n- SSL_TYPE=letsencrypt\n# Allow sending emails from other docker containers:\n# Beware creating an Open Relay: https://docker-mailserver.github.io/docker-mailserver/latest/config/environment/#permit_docker\n- PERMIT_DOCKER=network\n# You may want to enable this: https://docker-mailserver.github.io/docker-mailserver/latest/config/environment/#spoof_protection\n# See step 6 below, which demonstrates setup with enabled/disabled SPOOF_PROTECTION:\n- SPOOF_PROTECTION=0\ncap_add:\n- NET_ADMIN # For Fail2Ban to work\nrestart: always\nThe docs have a detailed page on Environment Variables for reference.
Firewalled portsIf you have a firewall running, you may need to open ports 25, 587 and 465.
For example, with the firewall ufw, run:
ufw allow 25\nufw allow 587\nufw allow 465\nCaution: This may not be sound advice.
Configure your DNS service to use an MX record for the hostname (eg: mail) you configured in the previous step and add the SPF TXT record.
If you manually manage the DNS zone file for the domain
It would look something like this:
$ORIGIN example.com\n@ IN A 10.11.12.13\nmail IN A 10.11.12.13\n\n; mail server for example.com\n@ IN MX 10 mail.example.com.\n\n; Add SPF record\n@ IN TXT \"v=spf1 mx -all\"\nThen don't forget to change the SOA serial number, and to restart the service.
Generate DKIM keys for your domain via setup config dkim.
Copy the content of the file docker-data/dms/config/opendkim/keys/example.com/mail.txt and add it to your DNS records as a TXT like SPF was handled above.
I use bind9 for managing my domains, so I just paste it on example.com.db:
mail._domainkey IN TXT ( \"v=DKIM1; h=sha256; k=rsa; \"\n \"p=MIIBIjANBgkqhkiG9w0BAQEFACAQ8AMIIBCgKCAQEAaH5KuPYPSF3Ppkt466BDMAFGOA4mgqn4oPjZ5BbFlYA9l5jU3bgzRj3l6/Q1n5a9lQs5fNZ7A/HtY0aMvs3nGE4oi+LTejt1jblMhV/OfJyRCunQBIGp0s8G9kIUBzyKJpDayk2+KJSJt/lxL9Iiy0DE5hIv62ZPP6AaTdHBAsJosLFeAzuLFHQ6USyQRojefqFQtgYqWQ2JiZQ3\"\n \"iqq3bD/BVlwKRp5gH6TEYEmx8EBJUuDxrJhkWRUk2VDl1fqhVBy8A9O7Ah+85nMrlOHIFsTaYo9o6+cDJ6t1i6G1gu+bZD0d3/3bqGLPBQV9LyEL1Rona5V7TJBGg099NQkTz1IwIDAQAB\" ) ; ----- DKIM key mail for example.com\nGet an SSL certificate, we have a guide for you here (Let's Encrypt is a popular service to get free SSL certificates).
Start DMS and check the terminal output for any errors: docker compose up.
Create email accounts and aliases:
With SPOOF_PROTECTION=0
setup email add admin@example.com passwd123\nsetup email add info@example.com passwd123\nsetup alias add admin@example.com external-account@gmail.com\nsetup alias add info@example.com external-account@gmail.com\nsetup email list\nsetup alias list\nAliases make sure that any email that comes to these accounts is forwarded to your third-party email address (external-account@gmail.com), where they are retrieved (eg: via third-party web or mobile app), instead of connecting directly to docker-mailserer with POP3 / IMAP.
With SPOOF_PROTECTION=1
setup email add admin.gmail@example.com passwd123\nsetup email add info.gmail@example.com passwd123\nsetup alias add admin@example.com admin.gmail@example.com\nsetup alias add info@example.com info.gmail@example.com\nsetup alias add admin.gmail@example.com external-account@gmail.com\nsetup alias add info.gmail@example.com external-account@gmail.com\nsetup email list\nsetup alias list\nThis extra step is required to avoid the 553 5.7.1 Sender address rejected: not owned by user error (the accounts used for submitting mail to Gmail are admin.gmail@example.com and info.gmail@example.com)
Send some test emails to these addresses and make other tests. Once everything is working well, stop the container with ctrl+c and start it again as a daemon: docker compose up -d.
This site lists blog entries that write about the project. If you blogged about DMS let us know so we can add it here!
You'll need to retrieve the git submodules prior to building your own Docker image. From within your copy of the git repo run the following to retrieve the submodules and build the Docker image:
git submodule update --init --recursive\ndocker build -t <YOUR CUSTOM IMAGE NAME> .\nOr, you can clone and retrieve the submodules in one command:
git clone --recurse-submodules https://github.com/docker-mailserver/docker-mailserver\nWe make use of build-features that require a recent version of Docker. Depending on your distribution, please have a look at the official installation documentation for Docker to get the latest version. Otherwise, you may encounter issues, for example with the --link flag for a COPY command.
If you are not using make to build the image, note that you will need to provide DOCKER_BUILDKIT=1 to the docker build command for the build to succeed.
The Dockerfile takes additional, so-called build arguments. These are
VCS_VERSION: the image version (default = edge)VCS_REVISION: the image revision (default = unknown)When using make to build the image, these are filled with proper values. You can build the image without supplying these arguments just fine though.
If you are hiding your container behind a proxy service you might have discovered that the proxied requests from now on contain the proxy IP as the request origin. Whilst this behavior is technical correct it produces certain problems on the containers behind the proxy as they cannot distinguish the real origin of the requests anymore.
To solve this problem on TCP connections we can make use of the proxy protocol. Compared to other workarounds that exist (X-Forwarded-For which only works for HTTP requests or Tproxy that requires you to recompile your kernel) the proxy protocol:
There is only one condition: both endpoints of the connection MUST be compatible with proxy protocol.
Luckily dovecot and postfix are both Proxy-Protocol ready softwares so it depends only on your used reverse-proxy / loadbalancer.
The configuration depends on the used proxy system. I will provide the configuration examples of traefik v2 using IMAP and SMTP with implicit TLS.
Feel free to add your configuration if you achieved the same goal using different proxy software below:
Traefik v2Truncated configuration of traefik itself:
services:\nreverse-proxy:\nimage: docker.io/traefik:latest # v2.5\ncontainer_name: docker-traefik\nrestart: always\ncommand:\n- \"--providers.docker\"\n- \"--providers.docker.exposedbydefault=false\"\n- \"--providers.docker.network=proxy\"\n- \"--entrypoints.web.address=:80\"\n- \"--entryPoints.websecure.address=:443\"\n- \"--entryPoints.smtp.address=:25\"\n- \"--entryPoints.smtp-ssl.address=:465\"\n- \"--entryPoints.imap-ssl.address=:993\"\n- \"--entryPoints.sieve.address=:4190\"\nports:\n- \"25:25\"\n- \"465:465\"\n- \"993:993\"\n- \"4190:4190\"\n[...]\nTruncated list of necessary labels on the DMS container:
services:\nmailserver:\nimage: ghcr.io/docker-mailserver/docker-mailserver:latest\ncontainer_name: mailserver\nhostname: mail.example.com\nrestart: always\nnetworks:\n- proxy\nlabels:\n- \"traefik.enable=true\"\n- \"traefik.tcp.routers.smtp.rule=HostSNI(`*`)\"\n- \"traefik.tcp.routers.smtp.entrypoints=smtp\"\n- \"traefik.tcp.routers.smtp.service=smtp\"\n- \"traefik.tcp.services.smtp.loadbalancer.server.port=25\"\n- \"traefik.tcp.services.smtp.loadbalancer.proxyProtocol.version=1\"\n- \"traefik.tcp.routers.smtp-ssl.rule=HostSNI(`*`)\"\n- \"traefik.tcp.routers.smtp-ssl.tls=false\"\n- \"traefik.tcp.routers.smtp-ssl.entrypoints=smtp-ssl\"\n- \"traefik.tcp.routers.smtp-ssl.service=smtp-ssl\"\n- \"traefik.tcp.services.smtp-ssl.loadbalancer.server.port=465\"\n- \"traefik.tcp.services.smtp-ssl.loadbalancer.proxyProtocol.version=1\"\n- \"traefik.tcp.routers.imap-ssl.rule=HostSNI(`*`)\"\n- \"traefik.tcp.routers.imap-ssl.entrypoints=imap-ssl\"\n- \"traefik.tcp.routers.imap-ssl.service=imap-ssl\"\n- \"traefik.tcp.services.imap-ssl.loadbalancer.server.port=10993\"\n- \"traefik.tcp.services.imap-ssl.loadbalancer.proxyProtocol.version=2\"\n- \"traefik.tcp.routers.sieve.rule=HostSNI(`*`)\"\n- \"traefik.tcp.routers.sieve.entrypoints=sieve\"\n- \"traefik.tcp.routers.sieve.service=sieve\"\n- \"traefik.tcp.services.sieve.loadbalancer.server.port=4190\"\n[...]\nKeep in mind that it is necessary to use port 10993 here. More information below at dovecot configuration.
dovecot and postfix)","text":"The following changes can be achieved completely by adding the content to the appropriate files by using the projects function to overwrite config files.
Changes for postfix can be applied by adding the following content to docker-data/dms/config/postfix-main.cf:
postscreen_upstream_proxy_protocol = haproxy\nand to docker-data/dms/config/postfix-master.cf:
submission/inet/smtpd_upstream_proxy_protocol=haproxy\nsubmissions/inet/smtpd_upstream_proxy_protocol=haproxy\nChanges for dovecot can be applied by adding the following content to docker-data/dms/config/dovecot.cf:
haproxy_trusted_networks = <your-proxy-ip>, <optional-cidr-notation>\nhaproxy_timeout = 3 secs\nservice imap-login {\ninet_listener imaps {\nhaproxy = yes\nssl = yes\nport = 10993\n}\n}\nNote
Port 10993 is used here to avoid conflicts with internal systems like postscreen and amavis as they will exchange messages on the default port and obviously have a different origin then compared to the proxy.
A forward-only mail server does not have any local mailboxes. Instead, it has only aliases that forward emails to external email accounts (for example to a Gmail account). You can also send email from the localhost (the computer where DMS is installed), using as sender any of the alias addresses.
The important settings for this setup (on mailserver.env) are these:
PERMIT_DOCKER=host\nENABLE_POP3=\nENABLE_CLAMAV=0\nSMTP_ONLY=1\nENABLE_SPAMASSASSIN=0\nENABLE_FETCHMAIL=0\nSince there are no local mailboxes, we use SMTP_ONLY=1 to disable dovecot. We disable as well the other services that are related to local mailboxes (POP3, ClamAV, SpamAssassin, etc.)
We can create aliases with ./setup.sh, like this:
./setup.sh alias add <alias-address> <external-email-account>\nIf you want to send emails from outside the mail server you have to authenticate somehow (with a username and password). One way of doing it is described in this discussion. However if there are many user accounts, it is better to use authentication with LDAP. The settings for this on mailserver.env are:
ENABLE_LDAP=1 # with the :edge tag, use ACCOUNT_PROVISIONER\nACCOUNT_PROVISIONER=LDAP\nLDAP_START_TLS=yes\nLDAP_SERVER_HOST=ldap.example.org\nLDAP_SEARCH_BASE=ou=users,dc=example,dc=org\nLDAP_BIND_DN=cn=mailserver,dc=example,dc=org\nLDAP_BIND_PW=pass1234\n\nENABLE_SASLAUTHD=1\nSASLAUTHD_MECHANISMS=ldap\nSASLAUTHD_LDAP_SERVER=ldap.example.org\nSASLAUTHD_LDAP_START_TLS=yes\nSASLAUTHD_LDAP_BIND_DN=cn=mailserver,dc=example,dc=org\nSASLAUTHD_LDAP_PASSWORD=pass1234\nSASLAUTHD_LDAP_SEARCH_BASE=ou=users,dc=example,dc=org\nSASLAUTHD_LDAP_FILTER=(&(uid=%U)(objectClass=inetOrgPerson))\nMy LDAP data structure is very basic, containing only the username, password, and the external email address where to forward emails for this user. An entry looks like this:
add uid=username,ou=users,dc=example,dc=org\nuid: username\nobjectClass: inetOrgPerson\nsn: username\ncn: username\nuserPassword: {SSHA}abcdefghi123456789\nemail: external-account@gmail.com\nThis structure is different from what is expected/assumed from the configuration scripts of DMS, so it doesn't work just by using the LDAP_QUERY_FILTER_... settings. Instead, I had to use a custom configuration (via user-patches.sh). I created the script docker-data/dms/config/user-patches.sh, with content like this:
#!/bin/bash\n\nrm -f /etc/postfix/{ldap-groups.cf,ldap-domains.cf}\n\npostconf \\\n\"virtual_mailbox_domains = /etc/postfix/vhost\" \\\n\"virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf texthash:/etc/postfix/virtual\" \\\n\"smtpd_sender_login_maps = ldap:/etc/postfix/ldap-users.cf\"\n\nsed -i /etc/postfix/ldap-users.cf \\\n-e '/query_filter/d' \\\n-e '/result_attribute/d' \\\n-e '/result_format/d'\ncat <<EOF >> /etc/postfix/ldap-users.cf\nquery_filter = (uid=%u)\nresult_attribute = uid\nresult_format = %s@example.org\nEOF\n\nsed -i /etc/postfix/ldap-aliases.cf \\\n-e '/domain/d' \\\n-e '/query_filter/d' \\\n-e '/result_attribute/d'\ncat <<EOF >> /etc/postfix/ldap-aliases.cf\ndomain = example.org\nquery_filter = (uid=%u)\nresult_attribute = mail\nEOF\n\npostfix reload\nYou see that besides query_filter, I had to customize as well result_attribute and result_format.
See also
For more details about using LDAP see: LDAP managed mail server with Postfix and Dovecot for multiple domains
Note
Another solution that serves as a forward-only mail server is this.
"},{"location":"examples/use-cases/imap-folders/","title":"Mailboxes (aka IMAP Folders)","text":"INBOX is setup as the private inbox namespace. By default target/dovecot/15-mailboxes.conf configures the special IMAP folders Drafts, Sent, Junk and Trash to be automatically created and subscribed. They are all assigned to the private inbox namespace (which implicitly provides the INBOX folder).
These IMAP folders are considered special because they add a \"SPECIAL-USE\" attribute, which is a standardized way to communicate to mail clients that the folder serves a purpose like storing spam/junk mail (\\Junk) or deleted mail (\\Trash). This differentiates them from regular mail folders that you may use for organizing.
See target/dovecot/15-mailboxes.conf for existing mailbox folders which you can modify or uncomment to enable some other common mailboxes. For more information try the official Dovecot documentation.
The Archive special IMAP folder may be useful to enable. To do so, make a copy of target/dovecot/15-mailboxes.conf and uncomment the Archive mailbox definition. Mail clients should understand that this folder is intended for archiving mail due to the \\Archive \"SPECIAL-USE\" attribute.
With the provided compose.yaml example, a volume bind mounts the host directory docker-data/dms/config/ to the container location /tmp/docker-mailserver/. Config file overrides should instead be mounted to a different location as described in Overriding Configuration for Dovecot:
volumes:\n- ./docker-data/dms/config/dovecot/15-mailboxes.conf:/etc/dovecot/conf.d/15-mailboxes.conf:ro\nHandling of newly added mailbox folders can be inconsistent across mail clients:
SPECIAL-USE attributes","text":"Not all mail clients support the SPECIAL-USE attribute for mailboxes (defined in RFC 6154). These clients will treat the mailbox folder as any other, using the name assigned to it instead.
Some clients may still know to treat these folders for their intended purpose if the mailbox name matches the common names that the SPECIAL-USE attributes represent (eg Sent as the mailbox name for \\Sent).
Usually the mail client will know via context such as the SPECIAL-USE attribute or common English mailbox names, to provide a localized label for the users preferred language.
Take care to test localized names work well as well.
"},{"location":"examples/use-cases/imap-folders/#email-clients-support","title":"Email Clients Support","text":"SPECIAL-USE attribute enabled for archives:Archives folder on the server.Archive.SPECIAL-USE attribute is enabled for archives:Windows Mail
Windows Mail has been said to ignore SPECIAL-USE attribute and look only at the mailbox folder name assigned.
Needs citation
This information is provided by the community.
It presently lacks references to confirm the behaviour. If any information is incorrect please let us know!
"}]} \ No newline at end of file diff --git a/edge/sitemap.xml b/edge/sitemap.xml index 3c37d362..23964631 100644 --- a/edge/sitemap.xml +++ b/edge/sitemap.xml @@ -2,202 +2,202 @@