This commit is contained in:
github-actions[bot] 2023-04-10 13:37:03 +00:00
parent 0eeb91b632
commit b6afb50e7c
25 changed files with 136 additions and 136 deletions

View file

@ -1582,7 +1582,7 @@
<h1>LDAP Authentication</h1>
<h2 id="introduction"><a class="toclink" href="#introduction">Introduction</a></h2>
<p>Getting started with ldap and <code>docker-mailserver</code> we need to take 3 parts in account:</p>
<p>Getting started with ldap and DMS we need to take 3 parts in account:</p>
<ul>
<li><code>postfix</code> for incoming &amp; outgoing email</li>
<li><code>dovecot</code> for accessing mailboxes</li>

View file

@ -1565,7 +1565,7 @@
<h2 id="overview"><a class="toclink" href="#overview">Overview</a></h2>
<p>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 <a href="https://doc.dovecot.org/configuration_manual/fts/">FTS indexing backends</a>.</p>
<p><code>docker-mailserver</code> comes pre-installed with two plugins that can be enabled with a dovecot config file.</p>
<p>DMS comes pre-installed with two plugins that can be enabled with a dovecot config file.</p>
<p>Please be aware that indexing consumes memory and takes up additional disk space.</p>
<h3 id="xapian"><a class="toclink" href="#xapian">Xapian</a></h3>
<p>The <a href="https://github.com/grosjo/fts-xapian">dovecot-fts-xapian</a> plugin makes use of <a href="https://xapian.org/">Xapian</a>. Xapian enables embedding an FTS engine without the need for additional backends.</p>
@ -1648,7 +1648,7 @@ docker-compose up -d
<p>Run the following command in a daily cron job:</p>
<p><div class="highlight"><pre><span></span><code>docker-compose exec mailserver doveadm fts optimize -A
</code></pre></div>
Or like the <a href="../../../faq/#how-can-i-make-spamassassin-better-recognize-spam">Spamassassin example</a> shows, you can instead use <code>cron</code> from within <code>docker-mailserver</code> to avoid potential errors if the mail-server is not running:</p>
Or like the <a href="../../../faq/#how-can-i-make-spamassassin-better-recognize-spam">Spamassassin example</a> shows, you can instead use <code>cron</code> from within DMS to avoid potential errors if the mail server is not running:</p>
</li>
</ol>
<details class="example">

View file

@ -1486,8 +1486,8 @@
<h1>IPv6</h1>
<h2 id="background"><a class="toclink" href="#background">Background</a></h2>
<p>If your container host supports IPv6, then <code>docker-mailserver</code> 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 (<code>172.20.0.1</code> is the gateway).</p>
<p>This can be solved by supporting IPv6 connections all the way to the <code>docker-mailserver</code> container.</p>
<p>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 (<code>172.20.0.1</code> is the gateway).</p>
<p>This can be solved by supporting IPv6 connections all the way to the DMS container.</p>
<h2 id="setup-steps"><a class="toclink" href="#setup-steps">Setup steps</a></h2>
<div class="highlight"><pre><span></span><code><span class="gi">+++ b/serv/docker-compose.yml</span>
<span class="gu">@@ ... @@ services:</span>

View file

@ -1082,10 +1082,10 @@
<li class="md-nav__item">
<a href="#exposing-your-mail-server-to-the-outside-world" class="md-nav__link">
Exposing your Mail-Server to the Outside World
Exposing your Mail Server to the Outside World
</a>
<nav class="md-nav" aria-label="Exposing your Mail-Server to the Outside World">
<nav class="md-nav" aria-label="Exposing your Mail Server to the Outside World">
<ul class="md-nav__list">
<li class="md-nav__item">
@ -1610,10 +1610,10 @@
<li class="md-nav__item">
<a href="#exposing-your-mail-server-to-the-outside-world" class="md-nav__link">
Exposing your Mail-Server to the Outside World
Exposing your Mail Server to the Outside World
</a>
<nav class="md-nav" aria-label="Exposing your Mail-Server to the Outside World">
<nav class="md-nav" aria-label="Exposing your Mail Server to the Outside World">
<ul class="md-nav__list">
<li class="md-nav__item">
@ -1690,10 +1690,10 @@
<h1>Kubernetes</h1>
<h2 id="introduction"><a class="toclink" href="#introduction">Introduction</a></h2>
<p>This article describes how to deploy <code>docker-mailserver</code> to Kubernetes. Please note that there is also a <a href="https://github.com/docker-mailserver/docker-mailserver-helm">Helm chart</a> available.</p>
<p>This article describes how to deploy DMS to Kubernetes. Please note that there is also a <a href="https://github.com/docker-mailserver/docker-mailserver-helm">Helm chart</a> available.</p>
<div class="admonition attention">
<p class="admonition-title">Requirements</p>
<p>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 <code>docker-mailserver</code> before in an easier setup with Docker (Compose).</p>
<p>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).</p>
</div>
<div class="admonition warning">
<p class="admonition-title">About Support for Kubernetes</p>
@ -1737,7 +1737,7 @@
<span class="w"> </span><span class="nt">SSL_CERT_PATH</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">/secrets/ssl/rsa/tls.crt</span>
<span class="w"> </span><span class="nt">SSL_KEY_PATH</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">/secrets/ssl/rsa/tls.key</span>
</code></pre></div>
<p>We can also make use of user-provided configuration files, e.g. <code>user-patches.sh</code>, <code>postfix-accounts.cf</code> and more, to adjust <code>docker-mailserver</code> to our likings. We encourage you to have a look at <a href="https://kustomize.io/">Kustomize</a> for creating <code>ConfigMap</code>s 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.</p>
<p>We can also make use of user-provided configuration files, e.g. <code>user-patches.sh</code>, <code>postfix-accounts.cf</code> and more, to adjust DMS to our likings. We encourage you to have a look at <a href="https://kustomize.io/">Kustomize</a> for creating <code>ConfigMap</code>s 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.</p>
<div class="highlight"><pre><span></span><code><span class="nn">---</span>
<span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">v1</span>
<span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ConfigMap</span>
@ -1813,7 +1813,7 @@
<span class="w"> </span><span class="nt">protocol</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">TCP</span>
</code></pre></div>
<h3 id="deployments"><a class="toclink" href="#deployments">Deployments</a></h3>
<p>Last but not least, the <code>Deployment</code> becomes the most complex component. It instructs Kubernetes how to run the <code>docker-mailserver</code> container and how to apply your <code>ConfigMaps</code>, persisted storage, etc. Additionally, we can set options to enforce runtime security here.</p>
<p>Last but not least, the <code>Deployment</code> becomes the most complex component. It instructs Kubernetes how to run the DMS container and how to apply your <code>ConfigMaps</code>, persisted storage, etc. Additionally, we can set options to enforce runtime security here.</p>
<div class="highlight"><pre><span></span><code><span class="nn">---</span>
<span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">apps/v1</span>
<span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Deployment</span>
@ -1965,7 +1965,7 @@
<span class="w"> </span><span class="nt">emptyDir</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">{}</span>
</code></pre></div>
<h3 id="certificates-an-example"><a class="toclink" href="#certificates-an-example">Certificates - An Example</a></h3>
<p>In this example, we use <a href="https://cert-manager.io/docs/"><code>cert-manager</code></a> to supply RSA certificates. You can also supply RSA certificates as fallback certificates, which <code>docker-mailserver</code> supports out of the box with <code>SSL_ALT_CERT_PATH</code> and <code>SSL_ALT_KEY_PATH</code>, and provide ECDSA as the proper certificates.</p>
<p>In this example, we use <a href="https://cert-manager.io/docs/"><code>cert-manager</code></a> to supply RSA certificates. You can also supply RSA certificates as fallback certificates, which DMS supports out of the box with <code>SSL_ALT_CERT_PATH</code> and <code>SSL_ALT_KEY_PATH</code>, and provide ECDSA as the proper certificates.</p>
<div class="highlight"><pre><span></span><code><span class="nn">---</span>
<span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">cert-manager.io/v1</span>
<span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Certificate</span>
@ -1995,11 +1995,11 @@
<p>For storing OpenDKIM keys, TLS certificates or any sort of sensitive data, you should be using <code>Secret</code>s. You can mount secrets like <code>ConfigMap</code>s and use them the same way.</p>
</div>
<p>The <a href="../../security/ssl/">TLS docs page</a> provides guidance when it comes to certificates and transport layer security. Always provide sensitive information vai <code>Secrets</code>.</p>
<h2 id="exposing-your-mail-server-to-the-outside-world"><a class="toclink" href="#exposing-your-mail-server-to-the-outside-world">Exposing your Mail-Server to the Outside World</a></h2>
<p>The more difficult part with Kubernetes is to expose a deployed <code>docker-mailserver</code> to the outside world. Kubernetes provides multiple ways for doing that; each has downsides and complexity. The major problem with exposing <code>docker-mailserver</code> to outside world in Kubernetes is to <a href="https://kubernetes.io/docs/tutorials/services/source-ip">preserve the real client IP</a>. The real client IP is required by <code>docker-mailserver</code> 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 <a href="../override-defaults/postfix/">Postfix configuration</a> by dropping the line that states: <code>check_policy_service unix:private/policyd-spf</code>.</p>
<p>The easiest approach was covered above, using <code class="highlight"><span class="nt">externalTrafficPolicy</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Local</span></code>, 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. <strong>But</strong> 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.</p>
<h2 id="exposing-your-mail-server-to-the-outside-world"><a class="toclink" href="#exposing-your-mail-server-to-the-outside-world">Exposing your Mail Server to the Outside World</a></h2>
<p>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 <a href="https://kubernetes.io/docs/tutorials/services/source-ip">preserve the real client IP</a>. 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 <a href="../override-defaults/postfix/">Postfix configuration</a> by dropping the line that states: <code>check_policy_service unix:private/policyd-spf</code>.</p>
<p>The easiest approach was covered above, using <code class="highlight"><span class="nt">externalTrafficPolicy</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Local</span></code>, 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. <strong>But</strong> 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.</p>
<h3 id="external-ips-service"><a class="toclink" href="#external-ips-service">External IPs Service</a></h3>
<p>The simplest way is to expose <code>docker-mailserver</code> as a <a href="https://kubernetes.io/docs/concepts/services-networking/service">Service</a> with <a href="https://kubernetes.io/docs/concepts/services-networking/service/#external-ips">external IPs</a>. 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.</p>
<p>The simplest way is to expose DMS as a <a href="https://kubernetes.io/docs/concepts/services-networking/service">Service</a> with <a href="https://kubernetes.io/docs/concepts/services-networking/service/#external-ips">external IPs</a>. 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.</p>
<div class="highlight"><pre><span></span><code><span class="nn">---</span>
<span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">v1</span>
<span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Service</span>
@ -2027,13 +2027,13 @@
<li>requires you to specify the exposed IPs explicitly.</li>
</ul>
<h3 id="proxy-port-to-service"><a class="toclink" href="#proxy-port-to-service">Proxy port to Service</a></h3>
<p>The <a href="https://github.com/kubernetes/contrib/tree/master/for-demos/proxy-to-service">proxy pod</a> 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 <a href="https://kubernetes.io/docs/concepts/architecture/nodes">Node</a> you want to expose <code>docker-mailserver</code> on.</p>
<p>The <a href="https://github.com/kubernetes/contrib/tree/master/for-demos/proxy-to-service">proxy pod</a> 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 <a href="https://kubernetes.io/docs/concepts/architecture/nodes">Node</a> you want to expose DMS on.</p>
<p>This approach</p>
<ul>
<li>does not preserve the real client IP, so SPF check of incoming mail will fail.</li>
</ul>
<h3 id="bind-to-concrete-node-and-use-host-network"><a class="toclink" href="#bind-to-concrete-node-and-use-host-network">Bind to concrete Node and use host network</a></h3>
<p>One way to preserve the real client IP is to use <code>hostPort</code> and <code>hostNetwork: true</code>. This comes at the cost of availability; you can reach <code>docker-mailserver</code> from the outside world only via IPs of <a href="https://kubernetes.io/docs/concepts/architecture/nodes">Node</a> where <code>docker-mailserver</code> is deployed.</p>
<p>One way to preserve the real client IP is to use <code>hostPort</code> and <code>hostNetwork: true</code>. This comes at the cost of availability; you can reach DMS from the outside world only via IPs of <a href="https://kubernetes.io/docs/concepts/architecture/nodes">Node</a> where DMS is deployed.</p>
<div class="highlight"><pre><span></span><code><span class="nn">---</span>
<span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">extensions/v1beta1</span>
<span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Deployment</span>
@ -2062,11 +2062,11 @@
</code></pre></div>
<p>With this approach,</p>
<ul>
<li>it is not possible to access <code>docker-mailserver</code> via other cluster Nodes, only via the Node <code>docker-mailserver</code> was deployed at.</li>
<li>it is not possible to access DMS via other cluster Nodes, only via the Node DMS was deployed at.</li>
<li>every Port within the Container is exposed on the Host side.</li>
</ul>
<h3 id="proxy-port-to-service-via-proxy-protocol"><a class="toclink" href="#proxy-port-to-service-via-proxy-protocol">Proxy Port to Service via PROXY Protocol</a></h3>
<p>This way is ideologically the same as <a href="#proxy-port-to-service">using a proxy pod</a>, but instead of a separate proxy pod, you configure your ingress to proxy TCP traffic to the <code>docker-mailserver</code> pod using the PROXY protocol, which preserves the real client IP.</p>
<p>This way is ideologically the same as <a href="#proxy-port-to-service">using a proxy pod</a>, 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.</p>
<h4 id="configure-your-ingress"><a class="toclink" href="#configure-your-ingress">Configure your Ingress</a></h4>
<p>With an <a href="https://kubernetes.github.io/ingress-nginx">NGINX ingress controller</a>, set <code>externalTrafficPolicy: Local</code> for its service, and add the following to the TCP services config map (as described <a href="https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services">here</a>):</p>
<div class="highlight"><pre><span></span><code><span class="nt">25</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;mailserver/mailserver:25::PROXY&quot;</span>
@ -2135,7 +2135,7 @@
</details>
<p>With this approach,</p>
<ul>
<li>it is not possible to access <code>docker-mailserver</code> via cluster-DNS, as the PROXY protocol is required for incoming connections.</li>
<li>it is not possible to access DMS via cluster-DNS, as the PROXY protocol is required for incoming connections.</li>
</ul>

View file

@ -1530,7 +1530,7 @@
<span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ENABLE_FETCHMAIL=1</span>
<span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">FETCHMAIL_POLL=300</span>
</code></pre></div>
<p>Generate a file called <code>fetchmail.cf</code> and place it in the <code>docker-data/dms/config/</code> folder. Your <code>docker-mailserver</code> folder should look like this example:</p>
<p>Generate a file called <code>fetchmail.cf</code> and place it in the <code>docker-data/dms/config/</code> folder. Your DMS folder should look like this example:</p>
<div class="highlight"><pre><span></span><code>├── docker-data/dms/config
│   ├── dovecot.cf
│   ├── fetchmail.cf

View file

@ -1488,7 +1488,7 @@
<h2 id="add-configuration"><a class="toclink" href="#add-configuration">Add Configuration</a></h2>
<p>The Dovecot default configuration can easily be extended providing a <code>docker-data/dms/config/dovecot.cf</code> file.
<a href="https://doc.dovecot.org/configuration_manual/">Dovecot documentation</a> remains the best place to find configuration options.</p>
<p>Your <code>docker-mailserver</code> folder should look like this example:</p>
<p>Your DMS folder structure should look like this example:</p>
<div class="highlight"><pre><span></span><code>├── docker-data/dms/config
│ ├── dovecot.cf
│ ├── postfix-accounts.cf
@ -1500,7 +1500,7 @@
<div class="highlight"><pre><span></span><code><span class="na">mail_max_userip_connections</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">100</span>
</code></pre></div>
<p>Another important option is the <code>default_process_limit</code> (defaults to <code>100</code>). 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.</p>
<p>This limit is quickly reached if users connect to the <code>docker-mailserver</code> with multiple end devices.</p>
<p>This limit is quickly reached if users connect to DMS with multiple end devices.</p>
<h2 id="override-configuration"><a class="toclink" href="#override-configuration">Override Configuration</a></h2>
<p>For major configuration changes its best to override the dovecot configuration files. For each configuration file you want to override, add a list entry under the <code>volumes</code> key.</p>
<div class="highlight"><pre><span></span><code><span class="nt">services</span><span class="p">:</span>
@ -1521,7 +1521,7 @@ docker<span class="w"> </span>cp<span class="w"> </span>mailserver:/etc/dovecot/
</ul>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p><a href="https://github.com/docker-mailserver/docker-mailserver/blob/master/setup.sh"><code>setup.sh</code></a> is included in the <code>docker-mailserver</code> repository. Make sure to use the one matching your image version release.</p>
<p><a href="https://github.com/docker-mailserver/docker-mailserver/blob/master/setup.sh"><code>setup.sh</code></a> is included in the DMS repository. Make sure to use the one matching your image version release.</p>
</div>
<p>The file <code>docker-data/dms/config/dovecot.cf</code> is copied internally to <code>/etc/dovecot/local.conf</code>. To verify the file content, run:</p>
<div class="highlight"><pre><span></span><code>docker<span class="w"> </span><span class="nb">exec</span><span class="w"> </span>-it<span class="w"> </span>mailserver<span class="w"> </span>cat<span class="w"> </span>/etc/dovecot/local.conf

View file

@ -1408,7 +1408,7 @@
<h1>Modifications via Script</h1>
<p>If you'd like to change, patch or alter files or behavior of <code>docker-mailserver</code>, you can use a script.</p>
<p>If you'd like to change, patch or alter files or behavior of DMS, you can use a script.</p>
<p>In case you cloned this repository, you can copy the file <a href="https://github.com/docker-mailserver/docker-mailserver/blob/master/config-examples/user-patches.sh"><code>user-patches.sh.dist</code> (<em>under <code>config/</code></em>)</a> with <code class="highlight">cp<span class="w"> </span>config/user-patches.sh.dist<span class="w"> </span>docker-data/dms/config/user-patches.sh</code> in order to create the <code>user-patches.sh</code> script.</p>
<p>If you are managing your directory structure yourself, create a <code>docker-data/dms/config/</code> directory and add the <code>user-patches.sh</code> file yourself.</p>
<div class="highlight"><pre><span></span><code><span class="c1"># 1. Either create the docker-data/dms/config/ directory yourself</span>

View file

@ -1609,7 +1609,7 @@
<p>Podman is a daemonless container engine for developing, managing, and running OCI Containers on your Linux System.</p>
<div class="admonition warning">
<p class="admonition-title">About Support for Podman</p>
<p>Please note that Podman <strong>is not</strong> officially supported as <code>docker-mailserver</code> is built and verified on top of the <em>Docker Engine</em>. This content is entirely community supported. If you find errors, please open an issue and provide a PR.</p>
<p>Please note that Podman <strong>is not</strong> officially supported as DMS is built and verified on top of the <em>Docker Engine</em>. This content is entirely community supported. If you find errors, please open an issue and provide a PR.</p>
</div>
<div class="admonition warning">
<p class="admonition-title">About this Guide</p>
@ -1650,7 +1650,7 @@ systemctl<span class="w"> </span><span class="nb">enable</span><span class="w">
<p>Also 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.</p>
<div class="admonition warning">
<p class="admonition-title">Warning</p>
<p>In order to make rootless <code>docker-mailserver</code> 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.</p>
<p>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.</p>
</div>
<p>First, enable <code>podman.socket</code> in systemd's userspace with a non-root user.</p>
<div class="highlight"><pre><span></span><code>systemctl<span class="w"> </span><span class="nb">enable</span><span class="w"> </span>--now<span class="w"> </span>--user<span class="w"> </span>podman.socket

View file

@ -1420,7 +1420,7 @@
<h1 id="auto-discovery-of-services"><a class="toclink" href="#auto-discovery-of-services">Auto-Discovery of Services</a></h1>
<p>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.</p>
<p>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.</p>
<p>Email clients will search for auto-discoverable settings and prefill almost everything when a user enters its email address <img alt="❤" class="twemoji" src="https://cdnjs.cloudflare.com/ajax/libs/twemoji/14.0.2/svg/2764.svg" title=":heart:" /></p>
<p>There exists <a href="https://hub.docker.com/r/monogramm/autodiscover-email-settings/">autodiscover-email-settings</a> 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.</p>

View file

@ -1747,7 +1747,7 @@
</div>
<div class="admonition info">
<p class="admonition-title">Restart required</p>
<p>After restarting <code>docker-mailserver</code>, outgoing mail will now be signed with your new DKIM key(s) <img alt="🎉" class="twemoji" src="https://cdnjs.cloudflare.com/ajax/libs/twemoji/14.0.2/svg/1f389.svg" title=":tada:" /></p>
<p>After restarting DMS, outgoing mail will now be signed with your new DKIM key(s) <img alt="🎉" class="twemoji" src="https://cdnjs.cloudflare.com/ajax/libs/twemoji/14.0.2/svg/1f389.svg" title=":tada:" /></p>
<p>You'll need to repeat this process if you add any new domains.</p>
</div>
<div class="admonition warning">

View file

@ -3345,8 +3345,8 @@
<h5 id="override_hostname"><a class="toclink" href="#override_hostname">OVERRIDE_HOSTNAME</a></h5>
<p>If you can't set your hostname (<em>eg: you're in a container platform that doesn't let you</em>) specify it via this environment variable. It will have priority over <code>docker run --hostname</code>, or the equivalent <code>hostname:</code> field in <code>docker-compose.yml</code>.</p>
<ul>
<li><strong>empty</strong> =&gt; Uses the <code>hostname -f</code> command to get canonical hostname for <code>docker-mailserver</code> to use.</li>
<li>=&gt; Specify an FQDN (fully-qualified domain name) to serve mail for. The hostname is required for <code>docker-mailserver</code> to function correctly.</li>
<li><strong>empty</strong> =&gt; Uses the <code>hostname -f</code> command to get canonical hostname for DMS to use.</li>
<li>=&gt; Specify an FQDN (fully-qualified domain name) to serve mail for. The hostname is required for DMS to function correctly.</li>
</ul>
<h5 id="log_level"><a class="toclink" href="#log_level">LOG_LEVEL</a></h5>
<p>Set the log level for DMS. This is mostly relevant for container startup scripts and change detection event feedback.</p>
@ -3484,7 +3484,7 @@ FAIL2BAN_BLOCKTYPE=drop</li>
<li>1 =&gt; Mail spoofing denied. Each user may only send with his own or his alias addresses. Addresses with <a href="http://www.postfix.org/postconf.5.html#recipient_delimiter">extension delimiters</a> are not able to send messages.</li>
</ul>
<h5 id="enable_srs"><a class="toclink" href="#enable_srs">ENABLE_SRS</a></h5>
<p>Enables the Sender Rewriting Scheme. SRS is needed if <code>docker-mailserver</code> acts as forwarder. See <a href="https://github.com/roehling/postsrsd/blob/master/README.md#sender-rewriting-scheme-crash-course">postsrsd</a> for further explanation.</p>
<p>Enables the Sender Rewriting Scheme. SRS is needed if DMS acts as forwarder. See <a href="https://github.com/roehling/postsrsd/blob/master/README.md#sender-rewriting-scheme-crash-course">postsrsd</a> for further explanation.</p>
<ul>
<li><strong>0</strong> =&gt; Disabled</li>
<li>1 =&gt; Enabled</li>
@ -3732,7 +3732,7 @@ If this is not set and reports are enabled with the old options, logrotate will
</ul>
<div class="admonition note">
<p class="admonition-title">This SpamAssassin setting needs <code>ENABLE_SPAMASSASSIN=1</code></p>
<p>By default, <code>docker-mailserver</code> is configured to quarantine spam emails.</p>
<p>By default, DMS is configured to quarantine spam emails.</p>
<p>If emails are quarantined, they are compressed and stored in a location dependent on the <code>ONE_DIR</code> setting above. To inhibit this behaviour and deliver spam emails, set this to a very high value e.g. <code>100.0</code>.</p>
<p>If <code>ONE_DIR=1</code> (default) the location is <code>/var/mail-state/lib-amavis/virusmails/</code>, or if <code>ONE_DIR=0</code>: <code>/var/lib/amavis/virusmails/</code>. These paths are inside the docker container.</p>
</div>
@ -3779,7 +3779,7 @@ If this is not set and reports are enabled with the old options, logrotate will
<ul>
<li><strong>empty</strong> =&gt; mail.example.com</li>
<li>=&gt; Specify the dns-name/ip-address where the ldap-server is listening, or an URI like <code>ldaps://mail.example.com</code></li>
<li>NOTE: If you going to use <code>docker-mailserver</code> in combination with <code>docker-compose.yml</code> you can set the service name here</li>
<li>NOTE: If you going to use DMS in combination with <code>docker-compose.yml</code> you can set the service name here</li>
</ul>
<h5 id="ldap_search_base"><a class="toclink" href="#ldap_search_base">LDAP_SEARCH_BASE</a></h5>
<ul>

View file

@ -1612,7 +1612,7 @@
</code></pre></div>
<div class="admonition attention">
<p class="admonition-title">Attention</p>
<p><code>docker-mailserver</code> must be launched with the <code>NET_ADMIN</code> capability in order to be able to install the nftables rules that actually ban IP addresses.</p>
<p>DMS must be launched with the <code>NET_ADMIN</code> capability in order to be able to install the nftables rules that actually ban IP addresses.</p>
<p>Thus either include <code>--cap-add=NET_ADMIN</code> in the <code>docker run</code> command, or the equivalent in <code>docker-compose.yml</code>:</p>
<div class="highlight"><pre><span></span><code><span class="nt">cap_add</span><span class="p">:</span>
<span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">NET_ADMIN</span>

View file

@ -1737,12 +1737,12 @@
<p>You could use a <a href="https://en.wikipedia.org/wiki/Wildcard_certificate#Examples">wildcard certificate</a>. This avoids accidentally leaking information to the internet, but keep in mind the <a href="https://gist.github.com/joepie91/7e5cad8c0726fd6a5e90360a754fc568">potential security risks</a> of wildcard certs.</p>
</div>
<h2 id="the-fqdn"><a class="toclink" href="#the-fqdn">The FQDN</a></h2>
<p>An <a href="https://en.wikipedia.org/wiki/Fully_qualified_domain_name">FQDN</a> (<em>Fully Qualified Domain Name</em>) such as <code>mail.example.com</code> is required for <code>docker-mailserver</code> to function correctly, especially for looking up the correct SSL certificate to use.</p>
<p>An <a href="https://en.wikipedia.org/wiki/Fully_qualified_domain_name">FQDN</a> (<em>Fully Qualified Domain Name</em>) such as <code>mail.example.com</code> is required for DMS to function correctly, especially for looking up the correct SSL certificate to use.</p>
<ul>
<li><code>mail.example.com</code> will still use <code>user@example.com</code> as the mail address. You do not need a bare domain for that.</li>
<li>We usually discourage assigning a bare domain (<em>When your DNS MX record does not point to a subdomain</em>) to represent <code>docker-mailserver</code>. However, an FQDN of <a href="../../../faq/#can-i-use-a-nakedbare-domain-ie-no-hostname">just <code>example.com</code> is also supported</a>.</li>
<li>We usually discourage assigning a bare domain (<em>When your DNS MX record does not point to a subdomain</em>) to represent DMS. However, an FQDN of <a href="../../../faq/#can-i-use-a-nakedbare-domain-ie-no-hostname">just <code>example.com</code> is also supported</a>.</li>
<li>Internally, <code>hostname -f</code> will be used to retrieve the FQDN as configured in the below examples.</li>
<li>Wildcard certificates (eg: <code>*.example.com</code>) are supported for <code>SSL_TYPE=letsencrypt</code>. Your configured FQDN below may be <code>mail.example.com</code>, and your wildcard certificate provisioned to <code>/etc/letsencrypt/live/example.com</code> which will be checked as a fallback FQDN by <code>docker-mailserver</code>.</li>
<li>Wildcard certificates (eg: <code>*.example.com</code>) are supported for <code>SSL_TYPE=letsencrypt</code>. Your configured FQDN below may be <code>mail.example.com</code>, and your wildcard certificate provisioned to <code>/etc/letsencrypt/live/example.com</code> which will be checked as a fallback FQDN by DMS.</li>
</ul>
<div class="admonition example">
<p class="admonition-title">Setting the hostname correctly</p>
@ -1759,11 +1759,11 @@ docker<span class="w"> </span>run<span class="w"> </span>--hostname<span class="
</div>
<h2 id="provisioning-methods"><a class="toclink" href="#provisioning-methods">Provisioning methods</a></h2>
<h3 id="lets-encrypt-recommended"><a class="toclink" href="#lets-encrypt-recommended">Let's Encrypt (Recommended)</a></h3>
<p>To enable <em>Let's Encrypt</em> for <code>docker-mailserver</code>, you have to:</p>
<p>To enable <em>Let's Encrypt</em> for DMS, you have to:</p>
<ol>
<li>Get your certificate using the <em>Let's Encrypt</em> client <a href="https://github.com/certbot/certbot">Certbot</a>.</li>
<li>
<p>For your <code>docker-mailserver</code> container:</p>
<p>For your DMS container:</p>
<ul>
<li>Add the environment variable <code>SSL_TYPE=letsencrypt</code>.</li>
<li>Mount <a href="https://certbot.eff.org/docs/using.html#where-are-my-certificates">your local <code>letsencrypt</code> folder</a> as a volume to <code>/etc/letsencrypt</code>.</li>
@ -1774,7 +1774,7 @@ docker<span class="w"> </span>run<span class="w"> </span>--hostname<span class="
<div class="admonition note">
<p class="admonition-title">Note</p>
<p><code>/etc/letsencrypt/live</code> stores provisioned certificates in individual folders named by their FQDN.</p>
<p>Make sure that the entire folder is mounted to <code>docker-mailserver</code> as there are typically symlinks from <code>/etc/letsencrypt/live/mail.example.com</code> to <code>/etc/letsencrypt/archive</code>.</p>
<p>Make sure that the entire folder is mounted to DMS as there are typically symlinks from <code>/etc/letsencrypt/live/mail.example.com</code> to <code>/etc/letsencrypt/archive</code>.</p>
</div>
<div class="admonition example">
<p class="admonition-title">Example</p>
@ -1789,7 +1789,7 @@ docker<span class="w"> </span>run<span class="w"> </span>--hostname<span class="
</code></pre></div>
</div>
<h4 id="example-using-docker-for-lets-encrypt"><a class="toclink" href="#example-using-docker-for-lets-encrypt">Example using Docker for <em>Let's Encrypt</em></a></h4>
<p>Certbot provisions certificates to <code>/etc/letsencrypt</code>. Add a volume to store these, so that they can later be accessed by <code>docker-mailserver</code> container. You may also want to persist Certbot <a href="https://certbot.eff.org/docs/using.html#log-rotation">logs</a>, just in case you need to troubleshoot.</p>
<p>Certbot provisions certificates to <code>/etc/letsencrypt</code>. Add a volume to store these, so that they can later be accessed by DMS container. You may also want to persist Certbot <a href="https://certbot.eff.org/docs/using.html#log-rotation">logs</a>, just in case you need to troubleshoot.</p>
<ol>
<li>
<p>Getting a certificate is this simple! (<em>Referencing: <a href="https://certbot.eff.org/docs/install.html#running-with-docker">Certbot docker instructions</a> and <a href="https://certbot.eff.org/docs/using.html#standalone"><code>certonly --standalone</code> mode</a></em>):</p>
@ -1802,7 +1802,7 @@ docker<span class="w"> </span>run<span class="w"> </span>--rm<span class="w"> </
</code></pre></div>
</li>
<li>
<p>Add a volume for <code>docker-mailserver</code> that maps the <em>local <code>certbot/certs/</code> folder</em> to the container path <code>/etc/letsencrypt/</code>.</p>
<p>Add a volume for DMS that maps the <em>local <code>certbot/certs/</code> folder</em> to the container path <code>/etc/letsencrypt/</code>.</p>
<div class="admonition example">
<p class="admonition-title">Example</p>
<p>Add these additions to the <code>mailserver</code> service in your <a href="https://github.com/docker-mailserver/docker-mailserver/blob/master/docker-compose.yml"><code>docker-compose.yml</code></a>:</p>
@ -1869,7 +1869,7 @@ docker<span class="w"> </span>run<span class="w"> </span>--rm<span class="w"> </
<span class="w"> </span><span class="c1"># Set SSL certificate type.</span>
<span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">SSL_TYPE=letsencrypt</span>
<span class="w"> </span><span class="nt">volumes</span><span class="p">:</span>
<span class="w"> </span><span class="c1"># Mount the cert folder generated by Certbot into mail-server:</span>
<span class="w"> </span><span class="c1"># Mount the cert folder generated by Certbot:</span>
<span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">./docker-data/certbot/certs/:/etc/letsencrypt/:ro</span>
<span class="w"> </span><span class="nt">certbot-cloudflare</span><span class="p">:</span>
@ -1957,7 +1957,7 @@ docker<span class="w"> </span>run<span class="w"> </span>--rm<span class="w"> </
</details>
<h4 id="example-using-nginx-proxy-and-acme-companion-with-docker"><a class="toclink" href="#example-using-nginx-proxy-and-acme-companion-with-docker">Example using <code>nginx-proxy</code> and <code>acme-companion</code> with Docker</a></h4>
<p>If you are running a web server already, port 80 will be in use which Certbot requires. You could use the <a href="https://certbot.eff.org/docs/using.html#webroot">Certbot <code>--webroot</code></a> feature, but it is more common to leverage a <em>reverse proxy</em> that manages the provisioning and renewal of certificates for your services automatically.</p>
<p>In the following example, we show how <code>docker-mailserver</code> can be run alongside the docker containers <a href="https://github.com/nginx-proxy/nginx-proxy"><code>nginx-proxy</code></a> and <a href="https://github.com/nginx-proxy/acme-companion"><code>acme-companion</code></a> (<em>Referencing: <a href="https://github.com/nginx-proxy/acme-companion/blob/main/docs"><code>acme-companion</code> documentation</a></em>):</p>
<p>In the following example, we show how DMS can be run alongside the docker containers <a href="https://github.com/nginx-proxy/nginx-proxy"><code>nginx-proxy</code></a> and <a href="https://github.com/nginx-proxy/acme-companion"><code>acme-companion</code></a> (<em>Referencing: <a href="https://github.com/nginx-proxy/acme-companion/blob/main/docs"><code>acme-companion</code> documentation</a></em>):</p>
<ol>
<li>
<p>Start the <em>reverse proxy</em> (<code>nginx-proxy</code>):</p>
@ -1991,7 +1991,7 @@ docker<span class="w"> </span>run<span class="w"> </span>--detach<span class="w"
<p>Start the rest of your web server containers as usual.</p>
</li>
<li>
<p>Start a <em>dummy container</em> to provision certificates for your FQDN (eg: <code>mail.example.com</code>). <code>acme-companion</code> will detect the container and generate a <em>Let's Encrypt</em> certificate for your domain, which can be used by <code>docker-mailserver</code>:</p>
<p>Start a <em>dummy container</em> to provision certificates for your FQDN (eg: <code>mail.example.com</code>). <code>acme-companion</code> will detect the container and generate a <em>Let's Encrypt</em> certificate for your domain, which can be used by DMS:</p>
<div class="highlight"><pre><span></span><code>docker<span class="w"> </span>run<span class="w"> </span>--detach<span class="w"> </span><span class="se">\</span>
<span class="w"> </span>--name<span class="w"> </span>webmail<span class="w"> </span><span class="se">\</span>
<span class="w"> </span>--env<span class="w"> </span><span class="s1">&#39;VIRTUAL_HOST=mail.example.com&#39;</span><span class="w"> </span><span class="se">\</span>
@ -2015,7 +2015,7 @@ docker<span class="w"> </span>run<span class="w"> </span>--detach<span class="w"
</li>
</ol>
<h4 id="example-using-nginx-proxy-and-acme-companion-with-docker-compose"><a class="toclink" href="#example-using-nginx-proxy-and-acme-companion-with-docker-compose">Example using <code>nginx-proxy</code> and <code>acme-companion</code> with <code>docker-compose</code></a></h4>
<p>The following example is the <a href="https://github.com/nginx-proxy/acme-companion#basic-usage-with-the-nginx-proxy-container">basic setup</a> you need for using <code>nginx-proxy</code> and <code>acme-companion</code> with <code>docker-mailserver</code> (<em>Referencing: <a href="https://github.com/nginx-proxy/acme-companion/blob/main/docs"><code>acme-companion</code> documentation</a></em>):</p>
<p>The following example is the <a href="https://github.com/nginx-proxy/acme-companion#basic-usage-with-the-nginx-proxy-container">basic setup</a> you need for using <code>nginx-proxy</code> and <code>acme-companion</code> with DMS (<em>Referencing: <a href="https://github.com/nginx-proxy/acme-companion/blob/main/docs"><code>acme-companion</code> documentation</a></em>):</p>
<details class="example" open="open">
<summary>Example: <code>docker-compose.yml</code></summary>
<p>You should have an existing <code>docker-compose.yml</code> with a <code>mailserver</code> service. Below are the modifications to add for integrating with <code>nginx-proxy</code> and <code>acme-companion</code> services:</p>
@ -2083,7 +2083,7 @@ docker<span class="w"> </span>run<span class="w"> </span>--detach<span class="w"
</ul>
<p><a href="https://github.com/nginx-proxy/acme-companion/blob/main/docs/Container-configuration.md"><code>acme-companion</code> ENV for default settings</a> that apply to all containers using <code>LETSENCRYPT_HOST</code>:</p>
<ul>
<li><code>DEFAULT_EMAIL</code>: An email address that the CA (<em>eg: Let's Encrypt</em>) 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.</li>
<li><code>DEFAULT_EMAIL</code>: An email address that the CA (<em>eg: Let's Encrypt</em>) 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.</li>
<li><code>CERTS_UPDATE_INTERVAL</code>: If you need to adjust the frequency to check for renewals. 3600 seconds (1 hour) by default.</li>
<li><code>DEBUG=1</code>: Should be helpful when <a href="https://github.com/nginx-proxy/acme-companion/blob/main/docs/Invalid-authorizations.md">troubleshooting provisioning issues</a> from <code>acme-companion</code> logs.</li>
<li><code>ACME_CA_URI</code>: Useful in combination with <code>CA_BUNDLE</code> to use a private CA. To change the default <em>Let's Encrypt</em> endpoint to the staging endpoint, use <code>https://acme-staging-v02.api.letsencrypt.org/directory</code>.</li>
@ -2123,7 +2123,7 @@ docker<span class="w"> </span>run<span class="w"> </span>--detach<span class="w"
</div>
<h4 id="example-using-lets-encrypt-certificates-with-a-synology-nas"><a class="toclink" href="#example-using-lets-encrypt-certificates-with-a-synology-nas">Example using <em>Let's Encrypt</em> Certificates with a <em>Synology NAS</em></a></h4>
<p>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.</p>
<p>Amongst other things, you can use these to secure your mail-server. DSM locates the generated certificates in a folder below <code>/usr/syno/etc/certificate/_archive/</code>.</p>
<p>Amongst other things, you can use these to secure your mail server. DSM locates the generated certificates in a folder below <code>/usr/syno/etc/certificate/_archive/</code>.</p>
<p>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 <code>docker-compose.yml</code> declaration file:</p>
<div class="highlight"><pre><span></span><code><span class="nt">volumes</span><span class="p">:</span>
<span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">/usr/syno/etc/certificate/_archive/&lt;your-folder&gt;/:/tmp/dms/custom-certs/</span>
@ -2220,7 +2220,7 @@ docker<span class="w"> </span>run<span class="w"> </span>--detach<span class="w"
<p><a href="https://github.com/containous/traefik">Traefik</a> is an open-source application proxy using the <a href="https://datatracker.ietf.org/doc/html/rfc8555">ACME protocol</a>. <a href="https://github.com/containous/traefik">Traefik</a> can request certificates for domains and subdomains, and it will take care of renewals, challenge negotiations, etc. We strongly recommend to use <a href="https://github.com/containous/traefik">Traefik</a>'s major version 2.</p>
<p><a href="https://github.com/containous/traefik">Traefik</a>'s storage format is natively supported if the <code>acme.json</code> store is mounted into the container at <code>/etc/letsencrypt/acme.json</code>. The file is also monitored for changes and will trigger a reload of the mail services (Postfix and Dovecot).</p>
<p>Wildcard certificates are supported. If your FQDN is <code>mail.example.com</code> and your wildcard certificate is <code>*.example.com</code>, add the ENV: <code class="highlight"><span class="nv">SSL_DOMAIN</span><span class="o">=</span>example.com</code>.</p>
<p>The mail-server will select it's certificate from <code>acme.json</code> checking these ENV for a matching FQDN (<em>in order of priority</em>):</p>
<p>DMS will select it's certificate from <code>acme.json</code> checking these ENV for a matching FQDN (<em>in order of priority</em>):</p>
<ol>
<li><code class="highlight"><span class="si">${</span><span class="nv">SSL_DOMAIN</span><span class="si">}</span></code></li>
<li><code class="highlight"><span class="si">${</span><span class="nv">HOSTNAME</span><span class="si">}</span></code></li>
@ -2280,10 +2280,10 @@ docker<span class="w"> </span>run<span class="w"> </span>--detach<span class="w"
<li><code>&lt;FQDN&gt;-cert.pem</code></li>
<li><code>demoCA/cacert.pem</code></li>
</ul>
<p>Where <code>&lt;FQDN&gt;</code> is the FQDN you've configured for your <code>docker-mailserver</code> container.</p>
<p>Add <code>SSL_TYPE=self-signed</code> to your <code>docker-mailserver</code> environment variables. Postfix and Dovecot will be configured to use the provided certificate (<em><code>.pem</code> files above</em>) during container startup.</p>
<p>Where <code>&lt;FQDN&gt;</code> is the FQDN you've configured for your DMS container.</p>
<p>Add <code>SSL_TYPE=self-signed</code> to your DMS environment variables. Postfix and Dovecot will be configured to use the provided certificate (<em><code>.pem</code> files above</em>) during container startup.</p>
<h4 id="generating-a-self-signed-certificate"><a class="toclink" href="#generating-a-self-signed-certificate">Generating a self-signed certificate</a></h4>
<p>One way to generate self-signed certificates is with <a href="https://smallstep.com/docs/step-cli">Smallstep's <code>step</code> CLI</a>. This is exactly what <a href="https://github.com/docker-mailserver/docker-mailserver/blob/3b8059f2daca80d967635e04d8d81e9abb755a4d/test/test-files/ssl/example.test/README.md"><code>docker-mailserver</code> does for creating test certificates</a>.</p>
<p>One way to generate self-signed certificates is with <a href="https://smallstep.com/docs/step-cli">Smallstep's <code>step</code> CLI</a>. This is exactly what <a href="https://github.com/docker-mailserver/docker-mailserver/blob/3b8059f2daca80d967635e04d8d81e9abb755a4d/test/test-files/ssl/example.test/README.md">DMS does for creating test certificates</a>.</p>
<p>For example with the FQDN <code>mail.example.test</code>, you can generate the required files by running:</p>
<div class="highlight"><pre><span></span><code><span class="ch">#! /bin/sh</span>
mkdir<span class="w"> </span>-p<span class="w"> </span>demoCA
@ -2333,7 +2333,7 @@ docker<span class="w"> </span>run<span class="w"> </span>--rm<span class="w"> </
<p><code>SSL_ALT_CERT_PATH</code> and <code>SSL_ALT_KEY_PATH</code> 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-<code>ALT</code> versions.</p>
<div class="admonition info">
<p class="admonition-title">Info</p>
<p>You may have to restart <code>docker-mailserver</code> once the certificates change.</p>
<p>You may have to restart DMS once the certificates change.</p>
</div>
<h2 id="testing-a-certificate-is-valid"><a class="toclink" href="#testing-a-certificate-is-valid">Testing a Certificate is Valid</a></h2>
<ul>
@ -2473,7 +2473,7 @@ openssl<span class="w"> </span>s_client<span class="w"> </span><span class="se">
<span class="k">fi</span>
</code></pre></div>
<h2 id="custom-dh-parameters"><a class="toclink" href="#custom-dh-parameters">Custom DH Parameters</a></h2>
<p>By default <code>docker-mailserver</code> uses <a href="https://github.com/internetstandards/dhe_groups"><code>ffdhe4096</code></a> from <a href="https://datatracker.ietf.org/doc/html/rfc7919">IETF RFC 7919</a>. These are standardized pre-defined DH groups and the only available DH groups for TLS 1.3. It is <a href="https://crypto.stackexchange.com/questions/29926/what-diffie-hellman-parameters-should-i-use">discouraged to generate your own DH parameters</a> as it is often less secure.</p>
<p>By default DMS uses <a href="https://github.com/internetstandards/dhe_groups"><code>ffdhe4096</code></a> from <a href="https://datatracker.ietf.org/doc/html/rfc7919">IETF RFC 7919</a>. These are standardized pre-defined DH groups and the only available DH groups for TLS 1.3. It is <a href="https://crypto.stackexchange.com/questions/29926/what-diffie-hellman-parameters-should-i-use">discouraged to generate your own DH parameters</a> as it is often less secure.</p>
<p>Despite this, if you must use non-standard DH parameters or you would like to swap <code>ffdhe4096</code> for a different group (eg <code>ffdhe2048</code>); Add your own PEM encoded DH params file via a volume to <code>/tmp/docker-mailserver/dhparams.pem</code>. This will replace DH params for both Dovecot and Postfix services during container startup.</p>

View file

@ -692,7 +692,7 @@
<li class="md-nav__item">
<a href="#tls-connections-for-a-mail-server-compared-to-web-browsers" class="md-nav__link">
TLS connections for a Mail-Server, compared to web browsers
TLS connections for a Mail Server, compared to web browsers
</a>
</li>
@ -1601,7 +1601,7 @@
<li class="md-nav__item">
<a href="#tls-connections-for-a-mail-server-compared-to-web-browsers" class="md-nav__link">
TLS connections for a Mail-Server, compared to web browsers
TLS connections for a Mail Server, compared to web browsers
</a>
</li>
@ -1676,8 +1676,8 @@
</tbody>
</table>
<ol>
<li>A connection <em>may</em> be secured over TLS when both ends support <code>STARTTLS</code>. On ports 110, 143 and 587, <code>docker-mailserver</code> will reject a connection that cannot be secured. Port 25 is <a href="https://serverfault.com/questions/623692/is-it-still-wrong-to-require-starttls-on-incoming-smtp-messages">required</a> to support insecure connections.</li>
<li>Receives email, <code>docker-mailserver</code> additionally filters for spam and viruses. For submitting email to the server to be sent to third-parties, you should prefer the <em>submission</em> ports (465, 587) - which require authentication. Unless a relay host is configured (eg: SendGrid), outgoing email will leave the server via port 25 (<em>thus outbound traffic must not be blocked by your provider or firewall</em>).</li>
<li>A connection <em>may</em> be secured over TLS when both ends support <code>STARTTLS</code>. On ports 110, 143 and 587, DMS will reject a connection that cannot be secured. Port 25 is <a href="https://serverfault.com/questions/623692/is-it-still-wrong-to-require-starttls-on-incoming-smtp-messages">required</a> to support insecure connections.</li>
<li>Receives email, DMS additionally filters for spam and viruses. For submitting email to the server to be sent to third-parties, you should prefer the <em>submission</em> ports (465, 587) - which require authentication. Unless a relay host is configured (eg: SendGrid), outgoing email will leave the server via port 25 (<em>thus outbound traffic must not be blocked by your provider or firewall</em>).</li>
<li>A <em>submission</em> port since 2018 (<a href="https://tools.ietf.org/html/rfc8314">RFC 8314</a>).</li>
</ol>
<details class="warning">
@ -1717,23 +1717,23 @@
<p>Mail arriving at your server will be processed and stored in a mailbox, or sent outbound to another mail server.</p>
<ul>
<li><strong>Port 25:</strong><ul>
<li>Think of this like a physical mailbox, anyone can deliver mail to you here. Typically most mail is delivered to you on this port.
-<code>docker-mailserver</code> will actively filter email delivered on this port for spam or viruses, and refuse mail from known bad sources.</li>
<li>Think of this like a physical mailbox, anyone can deliver mail to you here. Typically most mail is delivered to you on this port.</li>
<li>DMS will actively filter email delivered on this port for spam or viruses, and refuse mail from known bad sources.</li>
<li>Connections to this port may be secure through STARTTLS, but is not mandatory as <a href="https://serverfault.com/questions/623692/is-it-still-wrong-to-require-starttls-on-incoming-smtp-messages">mail is allowed to arrive via an unencrypted connection</a>.</li>
<li>It is possible for internal clients to submit mail to be sent outbound (<em>without requiring authentication</em>), but that is discouraged. Prefer the <em>submission</em> ports.</li>
</ul>
</li>
<li><strong>Port 465 and 587:</strong><ul>
<li>This is the equivalent of a post office box where you would send email to be delivered on your behalf (<em><code>docker-mailserver</code> is that metaphorical post office, aka the MTA</em>).</li>
<li>This is the equivalent of a post office box where you would send email to be delivered on your behalf (<em>DMS is that metaphorical post office, aka the MTA</em>).</li>
<li>These two ports are known as the <em>submission</em> ports, they enable mail to be sent outbound to another MTA (eg: Outlook or Gmail) but require authentication via a <a href="../../user-management/#accounts">mail account</a>.</li>
<li>For inbound traffic, this is relevant when you send mail from your MUA (eg: ThunderBird). It's also used when <code>docker-mailserver</code> is configured as a mail relay, or when you have a service sending transactional mail (<em>eg: order confirmations, password resets, notifications</em>) through <code>docker-mailserver</code>.</li>
<li>For inbound traffic, this is relevant when you send mail from your MUA (eg: ThunderBird). It's also used when DMS is configured as a mail relay, or when you have a service sending transactional mail (<em>eg: order confirmations, password resets, notifications</em>) through DMS.</li>
<li><em><strong>Prefer port 465</strong></em> over port 587, as 465 provides Implicit TLS.</li>
</ul>
</li>
</ul>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>When submitting mail (inbound) to be sent (outbound), this involves two separate connections to negotiate and secure. There may be additional intermediary connections which <code>docker-mailserver</code> is not involved in, and thus unable to ensure encrypted transit throughout delivery.</p>
<p>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.</p>
</div>
<h4 id="outbound-traffic-on-the-right"><a class="toclink" href="#outbound-traffic-on-the-right">Outbound Traffic (On the Right)</a></h4>
<p>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).</p>
@ -1752,7 +1752,7 @@
</ul>
<div class="admonition tip">
<p class="admonition-title">Tip</p>
<p><code>docker-mailserver</code> can function as a relay too, but professional relay services have a trusted reputation (<em>which increases success of delivery</em>).</p>
<p>DMS can function as a relay too, but professional relay services have a trusted reputation (<em>which increases success of delivery</em>).</p>
<p>An MTA with low reputation can affect if mail is treated as junk, or even rejected.</p>
</div>
<div class="admonition note">
@ -1766,7 +1766,7 @@
<div class="admonition note">
<p class="admonition-title">Note</p>
<ul>
<li>By default, <code>docker-mailserver</code> is configured to reject connections that fail to establish a secure connection (<em>when authentication is required</em>), rather than allow an insecure connection.</li>
<li>By default, DMS is configured to reject connections that fail to establish a secure connection (<em>when authentication is required</em>), rather than allow an insecure connection.</li>
<li>Port 25 does not require authentication. If <code>STARTTLS</code> 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, <a href="https://github.com/EFForg/starttls-everywhere#email-security-database-starttls-policy-list">STARTTLS Policy List</a>, DNSSEC and DANE.</li>
</ul>
</div>
@ -1787,7 +1787,7 @@
<p class="admonition-title">Todo</p>
<p>A related section or page on ciphers used may be useful, although less important for users to be concerned about.</p>
</div>
<h3 id="tls-connections-for-a-mail-server-compared-to-web-browsers"><a class="toclink" href="#tls-connections-for-a-mail-server-compared-to-web-browsers">TLS connections for a Mail-Server, compared to web browsers</a></h3>
<h3 id="tls-connections-for-a-mail-server-compared-to-web-browsers"><a class="toclink" href="#tls-connections-for-a-mail-server-compared-to-web-browsers">TLS connections for a Mail Server, compared to web browsers</a></h3>
<p>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.</p>
<p>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 <code>cleartext</code> connection through interception.</p>

View file

@ -1420,9 +1420,9 @@
<p class="admonition-title">Warning</p>
<p>This script assumes Docker or Podman is used. You will not be able to use <code>setup.sh</code> with other container orchestration tools.</p>
</div>
<p><a href="https://github.com/docker-mailserver/docker-mailserver/blob/master/setup.sh"><code>setup.sh</code></a> is a script that is complimentary to the internal <code>setup</code> command in <code>docker-mailserver</code>.</p>
<p>It mostly provides the convenience of aliasing <code>docker exec -ti &lt;CONTAINER NAME&gt; setup</code>, inferring the container name of a running <code>docker-mailserver</code> instance or running a new instance and bind mounting necessary volumes implicitly.</p>
<p>It is intended to be run from the host machine, <em>not</em> from inside your running container. The latest version of the script is included in the <code>docker-mailserver</code> repository. You may retrieve it at any time by running this command in your console:</p>
<p><a href="https://github.com/docker-mailserver/docker-mailserver/blob/master/setup.sh"><code>setup.sh</code></a> is a script that is complimentary to the internal <code>setup</code> command in DMS.</p>
<p>It mostly provides the convenience of aliasing <code>docker exec -ti &lt;CONTAINER NAME&gt; setup</code>, inferring the container name of a running DMS instance or running a new instance and bind mounting necessary volumes implicitly.</p>
<p>It is intended to be run from the host machine, <em>not</em> 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:</p>
<div class="highlight"><pre><span></span><code>wget<span class="w"> </span>https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master/setup.sh
chmod<span class="w"> </span>a+x<span class="w"> </span>./setup.sh
</code></pre></div>

View file

@ -1501,7 +1501,7 @@
<p class="admonition-title">Attention</p>
<p><strong>Before opening an issue</strong>, read the <a href="https://github.com/docker-mailserver/docker-mailserver/blob/master/README.md"><code>README</code></a> carefully, study the docs for your version (maybe <a href="https://docker-mailserver.github.io/docker-mailserver/latest">latest</a>), the Postfix/Dovecot documentation and your search engine you trust. The issue tracker is not meant to be used for unrelated questions!</p>
</div>
<p>When opening an issue, please provide details use case to let the community reproduce your problem. Please start <code>docker-mailserver</code> with the environment variable <code>LOG_LEVEL</code> set to <code>debug</code> or <code>trace</code> and paste the output into the issue.</p>
<p>When opening an issue, please provide details use case to let the community reproduce your problem. Please start DMS with the environment variable <code>LOG_LEVEL</code> set to <code>debug</code> or <code>trace</code> and paste the output into the issue.</p>
<div class="admonition attention">
<p class="admonition-title">Attention</p>
<p><strong>Use the issue templates</strong> to provide the necessary information. Issues which do not use these templates are not worked on and closed.</p>

View file

@ -1559,7 +1559,7 @@
<p>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.</p>
</div>
<p>This guide is focused on only using <a href="../../../config/security/understanding-the-ports/">SMTP ports (not POP3 and IMAP)</a> with the intent to relay mail received from another service to an external email address (eg: <code>user@gmail.com</code>). It is not intended for mailbox storage of real users.</p>
<p>In this setup <code>docker-mailserver</code> 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.</p>
<p>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.</p>
<div class="admonition tip">
<p class="admonition-title"><code>setup</code></p>
<p>The <code>setup</code> command used below is to be <a href="../../../usage/#get-up-and-running">run inside the container</a>.</p>
@ -1625,7 +1625,7 @@ ufw<span class="w"> </span>allow<span class="w"> </span><span class="m">465</spa
@ IN A 10.11.12.13
mail IN A 10.11.12.13
; mail-server for example.com
; mail server for example.com
@ IN MX 10 mail.example.com.
; Add SPF record
@ -1647,7 +1647,7 @@ mail IN A 10.11.12.13
<p>Get an SSL certificate, <a href="../../../config/security/ssl/#lets-encrypt-recommended">we have a guide for you here</a> (<em>Let's Encrypt</em> is a popular service to get free SSL certificates).</p>
</li>
<li>
<p>Start <code>docker-mailserver</code> and check the terminal output for any errors: <code>docker-compose up</code>.</p>
<p>Start DMS and check the terminal output for any errors: <code>docker-compose up</code>.</p>
</li>
<li>
<p>Create email accounts and aliases:</p>

View file

@ -1408,7 +1408,7 @@
<h1>Blog Posts</h1>
<p>This site lists blog entries that write about the project. If you blogged about <code>docker-mailserver</code> let us know so we can add it here!</p>
<p>This site lists blog entries that write about the project. If you blogged about DMS let us know so we can add it here!</p>
<ul>
<li><a href="https://lowtek.ca/roo/2021/installing-docker-mailserver/">Installing docker-mailserver</a> by <a href="https://github.com/andrewlow">@andrewlow</a></li>
<li><a href="https://www.ifthenel.se/self-hosted-mail-server/">Self hosted mail-server</a> by <a href="https://github.com/matrixes">@matrixes</a></li>

View file

@ -25,7 +25,7 @@
<title>Tutorials | Mail-Server behind a Proxy - Docker Mailserver</title>
<title>Tutorials | Mail Server behind a Proxy - Docker Mailserver</title>
@ -79,7 +79,7 @@
<div data-md-component="skip">
<a href="#using-docker-mailserver-behind-a-proxy" class="md-skip">
<a href="#using-dms-behind-a-proxy" class="md-skip">
Skip to content
</a>
@ -115,7 +115,7 @@
<div class="md-header__topic" data-md-component="header-topic">
<span class="md-ellipsis">
Tutorials | Mail-Server behind a Proxy
Tutorials | Mail Server behind a Proxy
</span>
</div>
@ -1162,11 +1162,11 @@
<ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
<li class="md-nav__item">
<a href="#using-docker-mailserver-behind-a-proxy" class="md-nav__link">
Using docker-mailserver behind a Proxy
<a href="#using-dms-behind-a-proxy" class="md-nav__link">
Using DMS behind a Proxy
</a>
<nav class="md-nav" aria-label="Using docker-mailserver behind a Proxy">
<nav class="md-nav" aria-label="Using DMS behind a Proxy">
<ul class="md-nav__list">
<li class="md-nav__item">
@ -1458,11 +1458,11 @@
<ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
<li class="md-nav__item">
<a href="#using-docker-mailserver-behind-a-proxy" class="md-nav__link">
Using docker-mailserver behind a Proxy
<a href="#using-dms-behind-a-proxy" class="md-nav__link">
Using DMS behind a Proxy
</a>
<nav class="md-nav" aria-label="Using docker-mailserver behind a Proxy">
<nav class="md-nav" aria-label="Using DMS behind a Proxy">
<ul class="md-nav__list">
<li class="md-nav__item">
@ -1511,7 +1511,7 @@
<h1>Mailserver behind Proxy</h1>
<h2 id="using-docker-mailserver-behind-a-proxy"><a class="toclink" href="#using-docker-mailserver-behind-a-proxy">Using <code>docker-mailserver</code> behind a Proxy</a></h2>
<h2 id="using-dms-behind-a-proxy"><a class="toclink" href="#using-dms-behind-a-proxy">Using DMS behind a Proxy</a></h2>
<h3 id="information"><a class="toclink" href="#information">Information</a></h3>
<p>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.</p>
<p>To solve this problem on TCP connections we can make use of the <a href="https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt">proxy protocol</a>. Compared to other workarounds that exist (<code>X-Forwarded-For</code> which only works for HTTP requests or <code>Tproxy</code> that requires you to recompile your kernel) the proxy protocol:</p>
@ -1551,7 +1551,7 @@
<span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="s">&quot;4190:4190&quot;</span>
<span class="p p-Indicator">[</span><span class="nv">...</span><span class="p p-Indicator">]</span>
</code></pre></div>
<p>Truncated list of necessary labels on the <code>docker-mailserver</code> container:</p>
<p>Truncated list of necessary labels on the DMS container:</p>
<div class="highlight"><pre><span></span><code><span class="nt">services</span><span class="p">:</span>
<span class="w"> </span><span class="nt">mailserver</span><span class="p">:</span>
<span class="w"> </span><span class="nt">image</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ghcr.io/docker-mailserver/docker-mailserver:latest</span>

View file

@ -25,7 +25,7 @@
<title>Use Cases | Forward-Only Mail-Server with LDAP - Docker Mailserver</title>
<title>Use Cases | Forward-Only Mail Server with LDAP - Docker Mailserver</title>
@ -115,7 +115,7 @@
<div class="md-header__topic" data-md-component="header-topic">
<span class="md-ellipsis">
Use Cases | Forward-Only Mail-Server with LDAP
Use Cases | Forward-Only Mail Server with LDAP
</span>
</div>
@ -1241,7 +1241,7 @@
<li class="md-nav__item">
<a href="#building-a-forward-only-mail-server" class="md-nav__link">
Building a Forward-Only Mail-Server
Building a Forward-Only Mail Server
</a>
</li>
@ -1439,7 +1439,7 @@
<li class="md-nav__item">
<a href="#building-a-forward-only-mail-server" class="md-nav__link">
Building a Forward-Only Mail-Server
Building a Forward-Only Mail Server
</a>
</li>
@ -1471,8 +1471,8 @@
<h1>Forward-Only Mail-Server with LDAP</h1>
<h2 id="building-a-forward-only-mail-server"><a class="toclink" href="#building-a-forward-only-mail-server">Building a Forward-Only Mail-Server</a></h2>
<p>A <strong>forward-only</strong> 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 <code>docker-mailserver</code> is installed), using as sender any of the alias addresses.</p>
<h2 id="building-a-forward-only-mail-server"><a class="toclink" href="#building-a-forward-only-mail-server">Building a Forward-Only Mail Server</a></h2>
<p>A <strong>forward-only</strong> 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.</p>
<p>The important settings for this setup (on <code>mailserver.env</code>) are these:</p>
<div class="highlight"><pre><span></span><code><span class="na">PERMIT_DOCKER</span><span class="o">=</span><span class="s">host</span>
<span class="na">ENABLE_POP3</span><span class="o">=</span>
@ -1486,7 +1486,7 @@
<div class="highlight"><pre><span></span><code>./setup.sh<span class="w"> </span><span class="nb">alias</span><span class="w"> </span>add<span class="w"> </span>&lt;alias-address&gt;<span class="w"> </span>&lt;external-email-account&gt;
</code></pre></div>
<h2 id="authenticating-with-ldap"><a class="toclink" href="#authenticating-with-ldap">Authenticating with LDAP</a></h2>
<p>If 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 <a href="https://github.com/docker-mailserver/docker-mailserver/issues/1247">this discussion</a>. However if there are many user accounts, it is better to use authentication with LDAP. The settings for this on <code>mailserver.env</code> are:</p>
<p>If 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 <a href="https://github.com/docker-mailserver/docker-mailserver/issues/1247">this discussion</a>. However if there are many user accounts, it is better to use authentication with LDAP. The settings for this on <code>mailserver.env</code> are:</p>
<div class="highlight"><pre><span></span><code><span class="na">ENABLE_LDAP</span><span class="o">=</span><span class="s">1 # with the :edge tag, use ACCOUNT_PROVISIONER</span>
<span class="na">ACCOUNT_PROVISIONER</span><span class="o">=</span><span class="s">LDAP</span>
<span class="na">LDAP_START_TLS</span><span class="o">=</span><span class="s">yes</span>
@ -1513,7 +1513,7 @@
<span class="na">userPassword</span><span class="o">:</span><span class="w"> </span><span class="s">{SSHA}abcdefghi123456789</span>
<span class="na">email</span><span class="o">:</span><span class="w"> </span><span class="s">external-account@gmail.com</span>
</code></pre></div>
<p>This structure is different from what is expected/assumed from the configuration scripts of <code>docker-mailserver</code>, so it doesn't work just by using the <code>LDAP_QUERY_FILTER_...</code> settings. Instead, I had to use a custom configuration (<a href="../../../config/advanced/override-defaults/user-patches/">via <code>user-patches.sh</code></a>). I created the script <code>docker-data/dms/config/user-patches.sh</code>, with content like this:</p>
<p>This structure is different from what is expected/assumed from the configuration scripts of DMS, so it doesn't work just by using the <code>LDAP_QUERY_FILTER_...</code> settings. Instead, I had to use a custom configuration (<a href="../../../config/advanced/override-defaults/user-patches/">via <code>user-patches.sh</code></a>). I created the script <code>docker-data/dms/config/user-patches.sh</code>, with content like this:</p>
<div class="highlight"><pre><span></span><code><span class="ch">#!/bin/bash</span>
rm<span class="w"> </span>-f<span class="w"> </span>/etc/postfix/<span class="o">{</span>ldap-groups.cf,ldap-domains.cf<span class="o">}</span>
@ -1548,11 +1548,11 @@ postfix<span class="w"> </span>reload
<p>You see that besides <code>query_filter</code>, I had to customize as well <code>result_attribute</code> and <code>result_format</code>.</p>
<div class="admonition note">
<p class="admonition-title">See also</p>
<p>For more details about using LDAP see: <a href="https://www.vennedey.net/resources/2-LDAP-managed-mail-server-with-Postfix-and-Dovecot-for-multiple-domains">LDAP managed mail-server with Postfix and Dovecot for multiple domains</a></p>
<p>For more details about using LDAP see: <a href="https://www.vennedey.net/resources/2-LDAP-managed-mail-server-with-Postfix-and-Dovecot-for-multiple-domains">LDAP managed mail server with Postfix and Dovecot for multiple domains</a></p>
</div>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>Another solution that serves as a forward-only mail-server is <a href="https://gitlab.com/docker-scripts/postfix">this</a>.</p>
<p>Another solution that serves as a forward-only mail server is <a href="https://gitlab.com/docker-scripts/postfix">this</a>.</p>
</div>

View file

@ -2050,7 +2050,7 @@ docker-compose<span class="w"> </span>up<span class="w"> </span>-d
<p>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.</p>
</div>
<h3 id="how-to-alter-a-running-dms-instance-without-relaunching-the-container"><a class="toclink" href="#how-to-alter-a-running-dms-instance-without-relaunching-the-container">How to alter a running DMS instance <em>without</em> relaunching the container?</a></h3>
<p><code>docker-mailserver</code> 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.</p>
<p>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.</p>
<p>In order to do so, you'll probably want to push your config updates to your server through a Docker volume (these docs use: <code>./docker-data/dms/config/:/tmp/docker-mailserver/</code>), then restart the sub-service to apply your changes, using <code>supervisorctl</code>. For instance, after editing fail2ban's config: <code>supervisorctl restart fail2ban</code>.</p>
<p>See the <a href="http://supervisord.org/running.html#running-supervisorctl">documentation for <code>supervisorctl</code></a>.</p>
<div class="admonition tip">
@ -2206,7 +2206,7 @@ Few examples of symptoms can be found <a href="https://github.com/docker-mailser
</code></pre></div>
<h3 id="how-to-adjust-settings-with-the-user-patchessh-script"><a class="toclink" href="#how-to-adjust-settings-with-the-user-patchessh-script">How to adjust settings with the <code>user-patches.sh</code> script</a></h3>
<p>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?</p>
<p><code>docker-mailserver</code> has a built-in way to do post-install processes. If you place a script called <strong><code>user-patches.sh</code></strong> 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.</p>
<p>DMS has a built-in way to do post-install processes. If you place a script called <strong><code>user-patches.sh</code></strong> 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.</p>
<p>It is common to use a local directory for config added to <code>docker-mailsever</code> via a volume mount in your <code>docker-compose.yml</code> (eg: <code>./docker-data/dms/config/:/tmp/docker-mailserver/</code>).</p>
<p>Add or create the script file to your config directory:</p>
<div class="highlight"><pre><span></span><code><span class="nb">cd</span><span class="w"> </span>./docker-data/dms/config
@ -2278,7 +2278,7 @@ supervisorctl<span class="w"> </span>update
<span class="c1"># Everyday 2:00AM, learn spam from a specific user</span>
<span class="na">0 2 * * * docker exec mailserver sa-learn --spam /var/mail/example.com/username/.Junk --dbpath /var/mail-state/lib-amavis/.spamassassin</span>
</code></pre></div>
<p>With <code>docker-compose</code> you can more easily use the internal instance of <code>cron</code> within <code>docker-mailserver</code>. This is less problematic than the simple solution shown above, because it decouples the learning from the host on which <code>docker-mailserver</code> is running, and avoids errors if the mail-server is not running.</p>
<p>With <code>docker-compose</code> you can more easily use the internal instance of <code>cron</code> 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.</p>
<p>The following configuration works nicely:</p>
<details class="example">
<summary>Example</summary>

View file

@ -1554,10 +1554,10 @@
<p>If you're completely new to mail servers or you want to read up on them, check out our <a href="./introduction/"><em>Introduction</em> page</a>. If you're new to DMS as a mail server appliance, make sure to read the <a href="./usage/"><em>Usage</em> chapter</a> first. If you want to look at examples for Docker Compose, we have an <a href="./examples/tutorials/basic-installation/"><em>Examples</em> page</a>.</p>
<p>There is also a script - <a href="https://github.com/docker-mailserver/docker-mailserver/blob/master/setup.sh"><code>setup.sh</code></a> - 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 <a href="config/setup.sh/">on a dedicated page</a>.</p>
<h3 id="configuration"><a class="toclink" href="#configuration">Configuration</a></h3>
<p>We have a <a href="config/environment/">dedicated configuration page</a>. It contains most of the configuration and explanation you need to setup <em>your</em> 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.</p>
<p>We have a <a href="config/environment/">dedicated configuration page</a>. It contains most of the configuration and explanation you need to setup <em>your</em> 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.</p>
<div class="admonition important">
<p class="admonition-title">Important</p>
<p>If you'd like to change, patch or alter files or behavior of <code>docker-mailserver</code>, you can use a script. Just place a script called <code>user-patches.sh</code> in your <code>./docker-data/dms/config/</code> folder volume (which is mounted to <code>/tmp/docker-mailserver/</code> inside the container) and it will be run on container startup. See the <a href="faq/#how-to-adjust-settings-with-the-user-patchessh-script">'Modifications via Script' page</a> for additional documentation and an example.</p>
<p>If you'd like to change, patch or alter files or behavior of DMS, you can use a script. Just place a script called <code>user-patches.sh</code> in your <code>./docker-data/dms/config/</code> folder volume (which is mounted to <code>/tmp/docker-mailserver/</code> inside the container) and it will be run on container startup. See the <a href="faq/#how-to-adjust-settings-with-the-user-patchessh-script">'Modifications via Script' page</a> for additional documentation and an example.</p>
</div>
<p>You might also want to check out:</p>
<ol>

View file

@ -515,8 +515,8 @@
</li>
<li class="md-nav__item">
<a href="#how-does-docker-mailserver-help-with-setting-everything-up" class="md-nav__link">
How Does docker-mailserver Help With Setting Everything Up?
<a href="#how-does-dms-help-with-setting-everything-up" class="md-nav__link">
How Does DMS Help With Setting Everything Up?
</a>
</li>
@ -1601,8 +1601,8 @@
</li>
<li class="md-nav__item">
<a href="#how-does-docker-mailserver-help-with-setting-everything-up" class="md-nav__link">
How Does docker-mailserver Help With Setting Everything Up?
<a href="#how-does-dms-help-with-setting-everything-up" class="md-nav__link">
How Does DMS Help With Setting Everything Up?
</a>
</li>
@ -1626,12 +1626,12 @@
<h1 id="an-overview-of-mail-server-infrastructure"><a class="toclink" href="#an-overview-of-mail-server-infrastructure">An Overview of Mail Server Infrastructure</a></h1>
<p>This 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 <code>docker-mailserver</code>.</p>
<p>This 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.</p>
<h2 id="the-anatomy-of-a-mail-server"><a class="toclink" href="#the-anatomy-of-a-mail-server">The Anatomy of a Mail Server</a></h2>
<p>A mail server is only a part of a <a href="https://en.wikipedia.org/wiki/Client%E2%80%93server_model">client-server relationship</a> aimed at exchanging information in the form of <a href="https://en.wikipedia.org/wiki/Email">emails</a>. Exchanging emails requires using specific means (programs and protocols).</p>
<p><code>docker-mailserver</code> provides you with the server portion, whereas the client can be anything from a terminal via text-based software (eg. <a href="https://en.wikipedia.org/wiki/Mutt_(email_client)">Mutt</a>) to a fully-fledged desktop application (eg. <a href="https://en.wikipedia.org/wiki/Mozilla_Thunderbird">Mozilla Thunderbird</a>, <a href="https://en.wikipedia.org/wiki/Microsoft_Outlook">Microsoft Outlook</a>…), to a web interface, etc.</p>
<p>DMS provides you with the server portion, whereas the client can be anything from a terminal via text-based software (eg. <a href="https://en.wikipedia.org/wiki/Mutt_(email_client)">Mutt</a>) to a fully-fledged desktop application (eg. <a href="https://en.wikipedia.org/wiki/Mozilla_Thunderbird">Mozilla Thunderbird</a>, <a href="https://en.wikipedia.org/wiki/Microsoft_Outlook">Microsoft Outlook</a>…), to a web interface, etc.</p>
<p>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.</p>
<p><code>docker-mailserver</code> 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!</p>
<p>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!</p>
<h2 id="components"><a class="toclink" href="#components">Components</a></h2>
<p>The following components are required to create a <a href="https://en.wikipedia.org/wiki/Email_agent_(infrastructure)">complete delivery chain</a>:</p>
<ul>
@ -1644,13 +1644,13 @@
Fetching an email: MUA &lt;--------------------------------- MDA
</code></pre></div>
<p>There may be other moving parts or sub-divisions (for instance, at several points along the chain, specialized programs may be analyzing, filtering, bouncing, editing… the exchanged emails).</p>
<p>In a nutshell, <code>docker-mailserver</code> provides you with the following components:</p>
<p>In a nutshell, DMS provides you with the following components:</p>
<ul>
<li>A MTA: <a href="http://www.postfix.org/">Postfix</a></li>
<li>A MDA: <a href="https://dovecot.org/">Dovecot</a></li>
<li>A bunch of additional programs to improve security and emails processing</li>
</ul>
<p>Here's where <code>docker-mailserver</code>'s toochain fits within the delivery chain:</p>
<p>Here's where DMS's toochain fits within the delivery chain:</p>
<div class="highlight"><pre><span></span><code> docker-mailserver is here:
┏━━━━━━━┓
Sending an email: MUA ---&gt; MTA ---&gt; (MTA relays) ---&gt; ┫ MTA ╮ ┃
@ -1659,16 +1659,16 @@ Fetching an email: MUA &lt;------------------------------ ┫ MDA ╯ ┃
</code></pre></div>
<details class="example">
<summary>An Example</summary>
<p>Let's say Alice owns a Gmail account, <code>alice@gmail.com</code>; and Bob owns an account on a <code>docker-mailserver</code>'s instance, <code>bob@dms.io</code>.</p>
<p>Let's say Alice owns a Gmail account, <code>alice@gmail.com</code>; and Bob owns an account on a DMS instance, <code>bob@dms.io</code>.</p>
<p>Make sure not to conflate these two very different scenarios:
A) Alice sends an email to <code>bob@dms.io</code> =&gt; the email is first submitted to MTA <code>smtp.gmail.com</code>, then relayed to MTA <code>smtp.dms.io</code> where it is then delivered into Bob's mailbox.
B) Bob sends an email to <code>alice@gmail.com</code> =&gt; the email is first submitted to MTA <code>smtp.dms.io</code>, then relayed to MTA <code>smtp.gmail.com</code> and eventually delivered into Alice's mailbox.</p>
<p>In scenario <em>A</em> the email leaves Gmail's premises, that email's <em>initial</em> submission is <em>not</em> handled by your <code>docker-mailserver</code> instance(MTA); it merely receives the email after it has been relayed by Gmail's MTA. In scenario <em>B</em>, the <code>docker-mailserver</code> instance(MTA) handles the submission, prior to relaying.</p>
<p>The main takeaway is that when a third-party sends an email to a <code>docker-mailserver</code> instance(MTA) (or any MTA for that matter), it does <em>not</em> 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.</p>
<p>In scenario <em>A</em> the email leaves Gmail's premises, that email's <em>initial</em> submission is <em>not</em> handled by your DMS instance(MTA); it merely receives the email after it has been relayed by Gmail's MTA. In scenario <em>B</em>, the DMS instance(MTA) handles the submission, prior to relaying.</p>
<p>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 <em>not</em> 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.</p>
</details>
<p>One important thing to note is that MTA and MDA programs may actually handle <em>multiple</em> tasks (which is the case with <code>docker-mailserver</code>'s Postfix and Dovecot).</p>
<p>One important thing to note is that MTA and MDA programs may actually handle <em>multiple</em> tasks (which is the case with DMS's Postfix and Dovecot).</p>
<p>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 <em>mail server</em>). On top of that, Postfix may rely on Dovecot's authentication capabilities.</p>
<p>The exact relationship between all the components and their respective (sometimes shared) responsibilities is beyond the scope of this document. Please explore this wiki &amp; the web to get more insights about <code>docker-mailserver</code>'s toolchain.</p>
<p>The exact relationship between all the components and their respective (sometimes shared) responsibilities is beyond the scope of this document. Please explore this wiki &amp; the web to get more insights about DMS's toolchain.</p>
<h2 id="about-security-ports"><a class="toclink" href="#about-security-ports">About Security &amp; Ports</a></h2>
<h3 id="introduction"><a class="toclink" href="#introduction">Introduction</a></h3>
<p>In the previous section, three components were outlined. Each one of those is responsible for a specific task when it comes to exchanging emails:</p>
@ -1695,16 +1695,16 @@ MUA &lt;---- STARTTLS ------- ┤(143) MDA ╯ |
┗━━━━━━━━━━ Retrieval ━━━━━━━━━━━━━┛
</code></pre></div>
<p>If you're new to email infrastructure, both that table and the schema may be confusing.
Read on to expand your understanding and learn about <code>docker-mailserver</code>'s configuration, including how you can customize it.</p>
Read on to expand your understanding and learn about DMS's configuration, including how you can customize it.</p>
<h3 id="submission-smtp"><a class="toclink" href="#submission-smtp">Submission - SMTP</a></h3>
<p>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 <a href="https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol">SMTP</a> protocol, which makes it capable of handling <em>Submission</em>.</p>
<p>In the case of <code>docker-mailserver</code>, the MTA (SMTP server) is Postfix. The MUA (client) may vary, yet its Submission request is performed as <a href="https://en.wikipedia.org/wiki/Transmission_Control_Protocol">TCP</a> packets sent over the <em>public</em> internet. This exchange of information may be secured in order to counter eavesdropping.</p>
<p>Now let's say I own an account on a <code>docker-mailserver</code> instance, <code>me@dms.io</code>. There are two very different use-cases for Submission:</p>
<p>In the case of DMS, the MTA (SMTP server) is Postfix. The MUA (client) may vary, yet its Submission request is performed as <a href="https://en.wikipedia.org/wiki/Transmission_Control_Protocol">TCP</a> packets sent over the <em>public</em> internet. This exchange of information may be secured in order to counter eavesdropping.</p>
<p>Now let's say I own an account on a DMS instance, <code>me@dms.io</code>. There are two very different use-cases for Submission:</p>
<ol>
<li>I want to send an email to someone</li>
<li>Someone wants to send you an email</li>
</ol>
<p>In the first scenario, I will be submitting my email directly to my <code>docker-mailserver</code> 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.</p>
<p>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.</p>
<p>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".</p>
<p>My MTA will thus have to support two kinds of Submission:</p>
<ul>
@ -1728,26 +1728,26 @@ Me ---------------&gt; ┤ ├ -----------------&gt; ┊
<p>This Submission setup is sometimes referred to as <a href="https://en.wikipedia.org/wiki/SMTPS">SMTPS</a>. Long story short: this is incorrect and should be avoided.</p>
</div>
<p>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 <em>may</em> 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 <a href="https://en.wikipedia.org/wiki/Opportunistic_TLS">STARTTLS</a> that both ends need to implement.</p>
<p>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 <a href="https://security.stackexchange.com/questions/168998/what-happens-if-starttls-dropped-in-smtp">misled by a hacker</a> about STARTTLS not being available), and the server accepts unencrypted (cleartext) mail exchange, which poses a confidentiality threat and, to some extent, spam issues. <a href="https://tools.ietf.org/html/rfc8314#section-3.3">RFC 8314 (section 3.3)</a> recommends for a mail server to support both Implicit and Explicit TLS for Submission, <em>and</em> to enforce TLS-encryption on ports 587 (Explicit TLS) and 465 (Implicit TLS). That's exactly <code>docker-mailserver</code>'s default configuration: abiding by RFC 8314, it <a href="http://www.postfix.org/postconf.5.html#smtpd_tls_security_level">enforces a strict (<code>encrypt</code>) STARTTLS policy</a>, where a denied TLS upgrade terminates the connection thus (hopefully but at the client's discretion) preventing unencrypted (cleartext) Submission.</p>
<p>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 <a href="https://security.stackexchange.com/questions/168998/what-happens-if-starttls-dropped-in-smtp">misled by a hacker</a> about STARTTLS not being available), and the server accepts unencrypted (cleartext) mail exchange, which poses a confidentiality threat and, to some extent, spam issues. <a href="https://tools.ietf.org/html/rfc8314#section-3.3">RFC 8314 (section 3.3)</a> recommends for a mail server to support both Implicit and Explicit TLS for Submission, <em>and</em> 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 <a href="http://www.postfix.org/postconf.5.html#smtpd_tls_security_level">enforces a strict (<code>encrypt</code>) STARTTLS policy</a>, where a denied TLS upgrade terminates the connection thus (hopefully but at the client's discretion) preventing unencrypted (cleartext) Submission.</p>
<ul>
<li><strong><code>docker-mailserver</code>'s default configuration enables and <em>requires</em> Explicit TLS (STARTTLS) on port 587 for Outbound Submission.</strong></li>
<li><strong>DMS's default configuration enables and <em>requires</em> Explicit TLS (STARTTLS) on port 587 for Outbound Submission.</strong></li>
<li>It does not enable Implicit TLS Outbound Submission on port 465 by default. One may enable it through simple custom configuration, either as a replacement or (better!) supplementary mean of secure Submission.</li>
<li>It does not support old MUAs (clients) not supporting TLS encryption on ports 587/465 (those should perform Submission on port 25, more details below). One may relax that constraint through advanced custom configuration, for backwards compatibility.</li>
</ul>
<p>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 <a href="https://tools.ietf.org/html/rfc5321">RFC 5321</a>, <code>docker-mailserver</code> uses port 25 for unencrypted Submission in order to support older clients, but most importantly for unencrypted Transfer/Relay between MTAs.</p>
<p>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 <a href="https://tools.ietf.org/html/rfc5321">RFC 5321</a>, DMS uses port 25 for unencrypted Submission in order to support older clients, but most importantly for unencrypted Transfer/Relay between MTAs.</p>
<ul>
<li><strong><code>docker-mailserver</code>'s default configuration also enables unencrypted (cleartext) on port 25 for Outbound Submission.</strong></li>
<li><strong>DMS's default configuration also enables unencrypted (cleartext) on port 25 for Outbound Submission.</strong></li>
<li>It does not enable Explicit TLS (STARTTLS) on port 25 by default. One may enable it through advanced custom configuration, either as a replacement (bad!) or as a supplementary mean of secure Outbound Submission.</li>
<li>One may also secure Outbound Submission using advanced encryption scheme, such as DANE/DNSSEC and/or MTA-STS.</li>
</ul>
<h4 id="inbound-submission"><a class="toclink" href="#inbound-submission">Inbound Submission</a></h4>
<p>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.</p>
<ul>
<li><strong><code>docker-mailserver</code>'s default configuration enables unencrypted (cleartext) on port 25 for Inbound Submission.</strong></li>
<li><strong>DMS's default configuration enables unencrypted (cleartext) on port 25 for Inbound Submission.</strong></li>
<li>It does not enable Explicit TLS (STARTTLS) on port 25 by default. One may enable it through advanced custom configuration, either as a replacement (bad!) or as a supplementary mean of secure Inbound Submission.</li>
<li>One may also secure Inbound Submission using advanced encryption scheme, such as DANE/DNSSEC and/or MTA-STS.</li>
</ul>
<p>Overall, <code>docker-mailserver</code>'s default configuration for SMTP looks like this:</p>
<p>Overall, DMS's default configuration for SMTP looks like this:</p>
<div class="highlight"><pre><span></span><code> ┏━━━━ Outbound Submission ━━━━┓
┌────────────────────┐ ┌┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
@ -1761,19 +1761,19 @@ Me -- STARTTLS ---&gt; ┤(587) │ ┊
</code></pre></div>
<h3 id="retrieval-imap"><a class="toclink" href="#retrieval-imap">Retrieval - IMAP</a></h3>
<p>A MUA willing to fetch an email from a mail server will most likely communicate with its <a href="https://en.wikipedia.org/wiki/IMAP">IMAP</a> 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 <em>Retrieval</em>.</p>
<p>In the case of <code>docker-mailserver</code>, the IMAP server is Dovecot. The MUA (client) may vary, yet its Retrieval request is performed as <a href="https://en.wikipedia.org/wiki/Transmission_Control_Protocol">TCP</a> packets sent over the <em>public</em> internet. This exchange of information may be secured in order to counter eavesdropping.</p>
<p>In the case of DMS, the IMAP server is Dovecot. The MUA (client) may vary, yet its Retrieval request is performed as <a href="https://en.wikipedia.org/wiki/Transmission_Control_Protocol">TCP</a> packets sent over the <em>public</em> internet. This exchange of information may be secured in order to counter eavesdropping.</p>
<p>Again, as with SMTP described earlier, the IMAP protocol may be secured with either Implicit TLS (aka. <a href="https://en.wikipedia.org/wiki/IMAPS">IMAPS</a> / IMAP4S) or Explicit TLS (using STARTTLS).</p>
<p>The best practice as of 2020 is to enforce IMAPS on port 993, rather than IMAP+STARTTLS on port 143 (see <a href="https://tools.ietf.org/html/rfc8314">RFC 8314</a>); yet the latter is usually provided for backwards compatibility.</p>
<p><strong><code>docker-mailserver</code>'s default configuration enables both Implicit and Explicit TLS for Retrievial, on ports 993 and 143 respectively.</strong></p>
<p><strong>DMS's default configuration enables both Implicit and Explicit TLS for Retrievial, on ports 993 and 143 respectively.</strong></p>
<h3 id="retrieval-pop3"><a class="toclink" href="#retrieval-pop3">Retrieval - POP3</a></h3>
<p>Similarly to IMAP, the older POP3 protocol may be secured with either Implicit or Explicit TLS.</p>
<p>The best practice as of 2020 would be <a href="https://en.wikipedia.org/wiki/POP3S">POP3S</a> on port 995, rather than <a href="https://en.wikipedia.org/wiki/POP3">POP3</a>+STARTTLS on port 110 (see <a href="https://tools.ietf.org/html/rfc8314">RFC 8314</a>).</p>
<p><strong><code>docker-mailserver</code>'s default configuration disables POP3 altogether.</strong> One should expect MUAs to use TLS-encrypted IMAP for Retrieval.</p>
<h2 id="how-does-docker-mailserver-help-with-setting-everything-up"><a class="toclink" href="#how-does-docker-mailserver-help-with-setting-everything-up">How Does <code>docker-mailserver</code> Help With Setting Everything Up?</a></h2>
<p>As a <em>batteries included</em> container image, <code>docker-mailserver</code> 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.</p>
<p><strong>DMS's default configuration disables POP3 altogether.</strong> One should expect MUAs to use TLS-encrypted IMAP for Retrieval.</p>
<h2 id="how-does-dms-help-with-setting-everything-up"><a class="toclink" href="#how-does-dms-help-with-setting-everything-up">How Does DMS Help With Setting Everything Up?</a></h2>
<p>As a <em>batteries included</em> 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.</p>
<ul>
<li>Simple customization is supported through <a href="https://github.com/docker-mailserver/docker-mailserver/blob/master/docker-compose.yml">docker-compose configuration</a> and the <a href="https://github.com/docker-mailserver/docker-mailserver/blob/master/mailserver.env">env-mailserver</a> configuration file.</li>
<li>Advanced customization is supported through providing "monkey-patching" configuration files and/or <a href="https://github.com/docker-mailserver/docker-mailserver/blob/master/Dockerfile">deriving your own image</a> from <code>docker-mailserver</code>'s upstream, for a complete control over how things run.</li>
<li>Advanced customization is supported through providing "monkey-patching" configuration files and/or <a href="https://github.com/docker-mailserver/docker-mailserver/blob/master/Dockerfile">deriving your own image</a> from DMS's upstream, for a complete control over how things run.</li>
</ul>
<p>Eventually, it is up to <em>you</em> 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.</p>

File diff suppressed because one or more lines are too long

View file

@ -1803,7 +1803,7 @@ wget<span class="w"> </span><span class="s2">&quot;</span><span class="si">${</s
<h3 id="advanced-dns-setup-dkim-dmarc-spf"><a class="toclink" href="#advanced-dns-setup-dkim-dmarc-spf">Advanced DNS Setup - DKIM, DMARC &amp; SPF</a></h3>
<p>You will very likely want to configure your DNS with these TXT records: <a href="https://www.cloudflare.com/learning/email-security/dmarc-dkim-spf/">SPF, DKIM, and DMARC</a>. We also ship a <a href="../config/best-practices/dkim_dmarc_spf/">dedicated page in our documentation</a> about the setup of DKIM, DMARC &amp; SPF.</p>
<h3 id="custom-user-changes-patches"><a class="toclink" href="#custom-user-changes-patches">Custom User Changes &amp; Patches</a></h3>
<p>If you'd like to change, patch or alter files or behavior of <code>docker-mailserver</code>, you can use a script. See <a href="../faq/#how-to-adjust-settings-with-the-user-patchessh-script">this part of our documentation</a> for a detailed explanation.</p>
<p>If you'd like to change, patch or alter files or behavior of DMS, you can use a script. See <a href="../faq/#how-to-adjust-settings-with-the-user-patchessh-script">this part of our documentation</a> for a detailed explanation.</p>
<h2 id="testing"><a class="toclink" href="#testing">Testing</a></h2>
<p>Here are some tools you can use to verify your configuration:</p>
<ol>