mirror of
https://github.com/docker-mailserver/docker-mailserver.git
synced 2024-01-19 02:48:50 +00:00
docs: renamings (#3242)
This commit is contained in:
Georg Lauterbach
GitHub
parent
34a1fd613f
commit
ddcc1dcc5c
|
|
@ -4,7 +4,7 @@ title: 'Advanced | LDAP Authentication'
|
|||
|
||||
## Introduction
|
||||
|
||||
Getting started with ldap and `docker-mailserver` we need to take 3 parts in account:
|
||||
Getting started with ldap and DMS we need to take 3 parts in account:
|
||||
|
||||
- `postfix` for incoming & outgoing email
|
||||
- `dovecot` for accessing mailboxes
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ title: 'Advanced | Full-Text Search'
|
|||
|
||||
Full-text search allows all messages to be indexed, so that mail clients can quickly and efficiently search messages by their full text content. Dovecot supports a variety of community supported [FTS indexing backends](https://doc.dovecot.org/configuration_manual/fts/).
|
||||
|
||||
`docker-mailserver` comes pre-installed with two plugins that can be enabled with a dovecot config file.
|
||||
DMS comes pre-installed with two plugins that can be enabled with a dovecot config file.
|
||||
|
||||
Please be aware that indexing consumes memory and takes up additional disk space.
|
||||
|
||||
|
|
@ -101,7 +101,7 @@ While indexing is memory intensive, you can configure the plugin to limit the am
|
|||
```
|
||||
docker-compose exec mailserver doveadm fts optimize -A
|
||||
```
|
||||
Or like the [Spamassassin example][docs-faq-sa-learn-cron] shows, you can instead use `cron` from within `docker-mailserver` to avoid potential errors if the mail-server is not running:
|
||||
Or like the [Spamassassin example][docs-faq-sa-learn-cron] shows, you can instead use `cron` from within DMS to avoid potential errors if the mail server is not running:
|
||||
|
||||
??? example
|
||||
|
||||
|
|
|
|||
|
|
@ -4,9 +4,9 @@ title: 'Advanced | IPv6'
|
|||
|
||||
## Background
|
||||
|
||||
If your container host supports IPv6, then `docker-mailserver` will automatically accept IPv6 connections by way of the docker host's IPv6. However, incoming mail will fail SPF checks because they will appear to come from the IPv4 gateway that docker is using to proxy the IPv6 connection (`172.20.0.1` is the gateway).
|
||||
If your container host supports IPv6, then DMS will automatically accept IPv6 connections by way of the docker host's IPv6. However, incoming mail will fail SPF checks because they will appear to come from the IPv4 gateway that docker is using to proxy the IPv6 connection (`172.20.0.1` is the gateway).
|
||||
|
||||
This can be solved by supporting IPv6 connections all the way to the `docker-mailserver` container.
|
||||
This can be solved by supporting IPv6 connections all the way to the DMS container.
|
||||
|
||||
## Setup steps
|
||||
|
||||
|
|
|
|||
|
|
@ -4,11 +4,11 @@ title: 'Advanced | Kubernetes'
|
|||
|
||||
## Introduction
|
||||
|
||||
This article describes how to deploy `docker-mailserver` to Kubernetes. Please note that there is also a [Helm chart] available.
|
||||
This article describes how to deploy DMS to Kubernetes. Please note that there is also a [Helm chart] available.
|
||||
|
||||
!!! attention "Requirements"
|
||||
|
||||
We assume basic knowledge about Kubernetes from the reader. Moreover, we assume the reader to have a basic understanding of mail servers. Ideally, the reader has deployed `docker-mailserver` before in an easier setup with Docker (Compose).
|
||||
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).
|
||||
|
||||
!!! warning "About Support for Kubernetes"
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ data:
|
|||
SSL_KEY_PATH: /secrets/ssl/rsa/tls.key
|
||||
```
|
||||
|
||||
We can also make use of user-provided configuration files, e.g. `user-patches.sh`, `postfix-accounts.cf` and more, to adjust `docker-mailserver` to our likings. We encourage you to have a look at [Kustomize][kustomize] for creating `ConfigMap`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.
|
||||
We can also make use of user-provided configuration files, e.g. `user-patches.sh`, `postfix-accounts.cf` and more, to adjust DMS to our likings. We encourage you to have a look at [Kustomize][kustomize] for creating `ConfigMap`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.
|
||||
|
||||
```yaml
|
||||
---
|
||||
|
|
@ -149,7 +149,7 @@ spec:
|
|||
|
||||
### Deployments
|
||||
|
||||
Last but not least, the `Deployment` becomes the most complex component. It instructs Kubernetes how to run the `docker-mailserver` container and how to apply your `ConfigMaps`, persisted storage, etc. Additionally, we can set options to enforce runtime security here.
|
||||
Last but not least, the `Deployment` becomes the most complex component. It instructs Kubernetes how to run the DMS container and how to apply your `ConfigMaps`, persisted storage, etc. Additionally, we can set options to enforce runtime security here.
|
||||
|
||||
```yaml
|
||||
---
|
||||
|
|
@ -305,7 +305,7 @@ spec:
|
|||
|
||||
### Certificates - An Example
|
||||
|
||||
In this example, we use [`cert-manager`][cert-manager] to supply RSA certificates. You can also supply RSA certificates as fallback certificates, which `docker-mailserver` supports out of the box with `SSL_ALT_CERT_PATH` and `SSL_ALT_KEY_PATH`, and provide ECDSA as the proper certificates.
|
||||
In this example, we use [`cert-manager`][cert-manager] to supply RSA certificates. You can also supply RSA certificates as fallback certificates, which DMS supports out of the box with `SSL_ALT_CERT_PATH` and `SSL_ALT_KEY_PATH`, and provide ECDSA as the proper certificates.
|
||||
|
||||
```yaml
|
||||
---
|
||||
|
|
@ -340,15 +340,15 @@ spec:
|
|||
|
||||
The [TLS docs page][docs-tls] provides guidance when it comes to certificates and transport layer security. Always provide sensitive information vai `Secrets`.
|
||||
|
||||
## Exposing your Mail-Server to the Outside World
|
||||
## Exposing your Mail Server to the Outside World
|
||||
|
||||
The more difficult part with Kubernetes is to expose a deployed `docker-mailserver` to the outside world. Kubernetes provides multiple ways for doing that; each has downsides and complexity. The major problem with exposing `docker-mailserver` to outside world in Kubernetes is to [preserve the real client IP][Kubernetes-service-source-ip]. The real client IP is required by `docker-mailserver` for performing IP-based SPF checks and spam checks. If you do not require SPF checks for incoming mails, you may disable them in your [Postfix configuration][docs-postfix] by dropping the line that states: `check_policy_service unix:private/policyd-spf`.
|
||||
The more difficult part with Kubernetes is to expose a deployed DMS to the outside world. Kubernetes provides multiple ways for doing that; each has downsides and complexity. The major problem with exposing DMS to outside world in Kubernetes is to [preserve the real client IP][Kubernetes-service-source-ip]. The real client IP is required by DMS for performing IP-based SPF checks and spam checks. If you do not require SPF checks for incoming mails, you may disable them in your [Postfix configuration][docs-postfix] by dropping the line that states: `check_policy_service unix:private/policyd-spf`.
|
||||
|
||||
The easiest approach was covered above, using `#!yaml externalTrafficPolicy: Local`, which disables the service proxy, but makes the service local as well (which does not scale). This approach only works when you are given the correct (that is, a public and routable) IP address by a load balancer (like MetalLB). In this sense, the approach above is similar to the next example below. We want to provide you with a few alternatives too. **But** we also want to communicate the idea of another simple method: you could use a load-balancer without an external IP and DNAT the network traffic to the mail-server. After all, this does not interfere with SPF checks because it keeps the origin IP address. If no dedicated external IP address is available, you could try the latter approach, if one is available, use the former.
|
||||
The easiest approach was covered above, using `#!yaml externalTrafficPolicy: Local`, which disables the service proxy, but makes the service local as well (which does not scale). This approach only works when you are given the correct (that is, a public and routable) IP address by a load balancer (like MetalLB). In this sense, the approach above is similar to the next example below. We want to provide you with a few alternatives too. **But** we also want to communicate the idea of another simple method: you could use a load-balancer without an external IP and DNAT the network traffic to the mail server. After all, this does not interfere with SPF checks because it keeps the origin IP address. If no dedicated external IP address is available, you could try the latter approach, if one is available, use the former.
|
||||
|
||||
### External IPs Service
|
||||
|
||||
The simplest way is to expose `docker-mailserver` as a [Service][Kubernetes-network-service] with [external IPs][Kubernetes-network-external-ip]. 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.
|
||||
The simplest way is to expose DMS as a [Service][Kubernetes-network-service] with [external IPs][Kubernetes-network-external-ip]. 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.
|
||||
|
||||
```yaml
|
||||
---
|
||||
|
|
@ -380,7 +380,7 @@ This approach
|
|||
|
||||
### Proxy port to Service
|
||||
|
||||
The [proxy pod][Kubernetes-proxy-service] helps to avoid the necessity of specifying external IPs explicitly. This comes at the cost of complexity; you must deploy a proxy pod on each [Node][Kubernetes-nodes] you want to expose `docker-mailserver` on.
|
||||
The [proxy pod][Kubernetes-proxy-service] helps to avoid the necessity of specifying external IPs explicitly. This comes at the cost of complexity; you must deploy a proxy pod on each [Node][Kubernetes-nodes] you want to expose DMS on.
|
||||
|
||||
This approach
|
||||
|
||||
|
|
@ -388,7 +388,7 @@ This approach
|
|||
|
||||
### Bind to concrete Node and use host network
|
||||
|
||||
One way to preserve the real client IP is to use `hostPort` and `hostNetwork: true`. This comes at the cost of availability; you can reach `docker-mailserver` from the outside world only via IPs of [Node][Kubernetes-nodes] where `docker-mailserver` is deployed.
|
||||
One way to preserve the real client IP is to use `hostPort` and `hostNetwork: true`. This comes at the cost of availability; you can reach DMS from the outside world only via IPs of [Node][Kubernetes-nodes] where DMS is deployed.
|
||||
|
||||
```yaml
|
||||
---
|
||||
|
|
@ -420,12 +420,12 @@ metadata:
|
|||
|
||||
With this approach,
|
||||
|
||||
- it is not possible to access `docker-mailserver` via other cluster Nodes, only via the Node `docker-mailserver` was deployed at.
|
||||
- it is not possible to access DMS via other cluster Nodes, only via the Node DMS was deployed at.
|
||||
- every Port within the Container is exposed on the Host side.
|
||||
|
||||
### Proxy Port to Service via PROXY Protocol
|
||||
|
||||
This way is ideologically the same as [using a proxy pod](#proxy-port-to-service), but instead of a separate proxy pod, you configure your ingress to proxy TCP traffic to the `docker-mailserver` pod using the PROXY protocol, which preserves the real client IP.
|
||||
This way is ideologically the same as [using a proxy pod](#proxy-port-to-service), 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.
|
||||
|
||||
#### Configure your Ingress
|
||||
|
||||
|
|
@ -501,7 +501,7 @@ Then, configure both [Postfix][docs-postfix] and [Dovecot][docs-dovecot] to expe
|
|||
|
||||
With this approach,
|
||||
|
||||
- it is not possible to access `docker-mailserver` via cluster-DNS, as the PROXY protocol is required for incoming connections.
|
||||
- it is not possible to access DMS via cluster-DNS, as the PROXY protocol is required for incoming connections.
|
||||
|
||||
[Helm chart]: https://github.com/docker-mailserver/docker-mailserver-helm
|
||||
[kustomize]: https://kustomize.io/
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ environment:
|
|||
- FETCHMAIL_POLL=300
|
||||
```
|
||||
|
||||
Generate a file called `fetchmail.cf` and place it in the `docker-data/dms/config/` folder. Your `docker-mailserver` folder should look like this example:
|
||||
Generate a file called `fetchmail.cf` and place it in the `docker-data/dms/config/` folder. Your DMS folder should look like this example:
|
||||
|
||||
```txt
|
||||
├── docker-data/dms/config
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ title: 'Override the Default Configs | Dovecot'
|
|||
The Dovecot default configuration can easily be extended providing a `docker-data/dms/config/dovecot.cf` file.
|
||||
[Dovecot documentation](https://doc.dovecot.org/configuration_manual/) remains the best place to find configuration options.
|
||||
|
||||
Your `docker-mailserver` folder should look like this example:
|
||||
Your DMS folder structure should look like this example:
|
||||
|
||||
```txt
|
||||
├── docker-data/dms/config
|
||||
|
|
@ -26,7 +26,7 @@ mail_max_userip_connections = 100
|
|||
|
||||
Another important option is the `default_process_limit` (defaults to `100`). If high-security mode is enabled you'll need to make sure this count is higher than the maximum number of users that can be logged in simultaneously.
|
||||
|
||||
This limit is quickly reached if users connect to the `docker-mailserver` with multiple end devices.
|
||||
This limit is quickly reached if users connect to DMS with multiple end devices.
|
||||
|
||||
## Override Configuration
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ To debug your dovecot configuration you can use:
|
|||
- Or: `docker exec -it mailserver doveconf | grep <some-keyword>`
|
||||
|
||||
!!! note
|
||||
[`setup.sh`][github-file-setupsh] is included in the `docker-mailserver` repository. Make sure to use the one matching your image version release.
|
||||
[`setup.sh`][github-file-setupsh] is included in the DMS repository. Make sure to use the one matching your image version release.
|
||||
|
||||
The file `docker-data/dms/config/dovecot.cf` is copied internally to `/etc/dovecot/local.conf`. To verify the file content, run:
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 'Custom User Changes & Patches | Scripting'
|
||||
---
|
||||
|
||||
If you'd like to change, patch or alter files or behavior of `docker-mailserver`, you can use a script.
|
||||
If you'd like to change, patch or alter files or behavior of DMS, you can use a script.
|
||||
|
||||
In case you cloned this repository, you can copy the file [`user-patches.sh.dist` (_under `config/`_)][github-file-userpatches] with `#!sh cp config/user-patches.sh.dist docker-data/dms/config/user-patches.sh` in order to create the `user-patches.sh` script.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Podman is a daemonless container engine for developing, managing, and running OC
|
|||
|
||||
!!! warning "About Support for Podman"
|
||||
|
||||
Please note that Podman **is not** officially supported as `docker-mailserver` is built and verified on top of the _Docker Engine_. This content is entirely community supported. If you find errors, please open an issue and provide a PR.
|
||||
Please note that Podman **is not** officially supported as DMS is built and verified on top of the _Docker Engine_. This content is entirely community supported. If you find errors, please open an issue and provide a PR.
|
||||
|
||||
!!! warning "About this Guide"
|
||||
|
||||
|
|
@ -67,7 +67,7 @@ Also notice that Podman's rootless mode is not about running as a non-root user
|
|||
|
||||
!!! warning
|
||||
|
||||
In order to make rootless `docker-mailserver` 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.
|
||||
In order to make rootless DMS work we must modify some settings in the Linux system, it requires some basic linux server knowledge so don't follow this guide if you not sure what this guide is talking about. Podman rootfull mode and Docker are still good and security enough for normal daily usage.
|
||||
|
||||
First, enable `podman.socket` in systemd's userspace with a non-root user.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ hide:
|
|||
|
||||
# Auto-Discovery of Services
|
||||
|
||||
Email auto-discovery means a client email is able to automagically find out about what ports and security options to use, based on the mail-server URI. It can help simplify the tedious / confusing task of adding own's email account for non-tech savvy users.
|
||||
Email auto-discovery means a client email is able to automagically find out about what ports and security options to use, based on the mail server URI. It can help simplify the tedious / confusing task of adding own's email account for non-tech savvy users.
|
||||
|
||||
Email clients will search for auto-discoverable settings and prefill almost everything when a user enters its email address :heart:
|
||||
|
||||
|
|
|
|||
|
|
@ -184,7 +184,7 @@ DKIM is currently supported by either OpenDKIM or Rspamd:
|
|||
|
||||
!!! info "Restart required"
|
||||
|
||||
After restarting `docker-mailserver`, outgoing mail will now be signed with your new DKIM key(s) :tada:
|
||||
After restarting DMS, outgoing mail will now be signed with your new DKIM key(s) :tada:
|
||||
|
||||
You'll need to repeat this process if you add any new domains.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,8 +12,8 @@ title: Environment Variables
|
|||
|
||||
If you can't set your hostname (_eg: you're in a container platform that doesn't let you_) specify it via this environment variable. It will have priority over `docker run --hostname`, or the equivalent `hostname:` field in `docker-compose.yml`.
|
||||
|
||||
- **empty** => Uses the `hostname -f` command to get canonical hostname for `docker-mailserver` to use.
|
||||
- => Specify an FQDN (fully-qualified domain name) to serve mail for. The hostname is required for `docker-mailserver` to function correctly.
|
||||
- **empty** => Uses the `hostname -f` command to get canonical hostname for DMS to use.
|
||||
- => Specify an FQDN (fully-qualified domain name) to serve mail for. The hostname is required for DMS to function correctly.
|
||||
|
||||
##### LOG_LEVEL
|
||||
|
||||
|
|
@ -176,7 +176,7 @@ Configures the handling of creating mails with forged sender addresses.
|
|||
|
||||
##### ENABLE_SRS
|
||||
|
||||
Enables the Sender Rewriting Scheme. SRS is needed if `docker-mailserver` acts as forwarder. See [postsrsd](https://github.com/roehling/postsrsd/blob/master/README.md#sender-rewriting-scheme-crash-course) for further explanation.
|
||||
Enables the Sender Rewriting Scheme. SRS is needed if DMS acts as forwarder. See [postsrsd](https://github.com/roehling/postsrsd/blob/master/README.md#sender-rewriting-scheme-crash-course) for further explanation.
|
||||
|
||||
- **0** => Disabled
|
||||
- 1 => Enabled
|
||||
|
|
@ -466,7 +466,7 @@ Note: this SpamAssassin setting needs `ENABLE_SPAMASSASSIN=1`
|
|||
|
||||
!!! note "This SpamAssassin setting needs `ENABLE_SPAMASSASSIN=1`"
|
||||
|
||||
By default, `docker-mailserver` is configured to quarantine spam emails.
|
||||
By default, DMS is configured to quarantine spam emails.
|
||||
|
||||
If emails are quarantined, they are compressed and stored in a location dependent on the `ONE_DIR` setting above. To inhibit this behaviour and deliver spam emails, set this to a very high value e.g. `100.0`.
|
||||
|
||||
|
|
@ -527,7 +527,7 @@ Deprecated. See [`ACCOUNT_PROVISIONER`](#account_provisioner).
|
|||
|
||||
- **empty** => mail.example.com
|
||||
- => Specify the dns-name/ip-address where the ldap-server is listening, or an URI like `ldaps://mail.example.com`
|
||||
- NOTE: If you going to use `docker-mailserver` in combination with `docker-compose.yml` you can set the service name here
|
||||
- NOTE: If you going to use DMS in combination with `docker-compose.yml` you can set the service name here
|
||||
|
||||
##### LDAP_SEARCH_BASE
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,8 @@ Example configuration volume bind:
|
|||
```
|
||||
|
||||
!!! attention
|
||||
`docker-mailserver` must be launched with the `NET_ADMIN` capability in order to be able to install the nftables rules that actually ban IP addresses.
|
||||
|
||||
DMS must be launched with the `NET_ADMIN` capability in order to be able to install the nftables rules that actually ban IP addresses.
|
||||
|
||||
Thus either include `--cap-add=NET_ADMIN` in the `docker run` command, or the equivalent in `docker-compose.yml`:
|
||||
|
||||
|
|
|
|||
|
|
@ -25,12 +25,12 @@ After installation, you can test your setup with:
|
|||
|
||||
## The FQDN
|
||||
|
||||
An [FQDN](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) (_Fully Qualified Domain Name_) such as `mail.example.com` is required for `docker-mailserver` to function correctly, especially for looking up the correct SSL certificate to use.
|
||||
An [FQDN](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) (_Fully Qualified Domain Name_) such as `mail.example.com` is required for DMS to function correctly, especially for looking up the correct SSL certificate to use.
|
||||
|
||||
- `mail.example.com` will still use `user@example.com` as the mail address. You do not need a bare domain for that.
|
||||
- We usually discourage assigning a bare domain (_When your DNS MX record does not point to a subdomain_) to represent `docker-mailserver`. However, an FQDN of [just `example.com` is also supported][docs-faq-baredomain].
|
||||
- We usually discourage assigning a bare domain (_When your DNS MX record does not point to a subdomain_) to represent DMS. However, an FQDN of [just `example.com` is also supported][docs-faq-baredomain].
|
||||
- Internally, `hostname -f` will be used to retrieve the FQDN as configured in the below examples.
|
||||
- Wildcard certificates (eg: `*.example.com`) are supported for `SSL_TYPE=letsencrypt`. Your configured FQDN below may be `mail.example.com`, and your wildcard certificate provisioned to `/etc/letsencrypt/live/example.com` which will be checked as a fallback FQDN by `docker-mailserver`.
|
||||
- Wildcard certificates (eg: `*.example.com`) are supported for `SSL_TYPE=letsencrypt`. Your configured FQDN below may be `mail.example.com`, and your wildcard certificate provisioned to `/etc/letsencrypt/live/example.com` which will be checked as a fallback FQDN by DMS.
|
||||
|
||||
!!! example "Setting the hostname correctly"
|
||||
|
||||
|
|
@ -54,10 +54,10 @@ An [FQDN](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) (_Fully Qua
|
|||
|
||||
### Let's Encrypt (Recommended)
|
||||
|
||||
To enable _Let's Encrypt_ for `docker-mailserver`, you have to:
|
||||
To enable _Let's Encrypt_ for DMS, you have to:
|
||||
|
||||
1. Get your certificate using the _Let's Encrypt_ client [Certbot][certbot::github].
|
||||
2. For your `docker-mailserver` container:
|
||||
2. For your DMS container:
|
||||
|
||||
- Add the environment variable `SSL_TYPE=letsencrypt`.
|
||||
- Mount [your local `letsencrypt` folder][certbot::certs-storage] as a volume to `/etc/letsencrypt`.
|
||||
|
|
@ -68,7 +68,7 @@ You don't have to do anything else. Enjoy!
|
|||
|
||||
`/etc/letsencrypt/live` stores provisioned certificates in individual folders named by their FQDN.
|
||||
|
||||
Make sure that the entire folder is mounted to `docker-mailserver` as there are typically symlinks from `/etc/letsencrypt/live/mail.example.com` to `/etc/letsencrypt/archive`.
|
||||
Make sure that the entire folder is mounted to DMS as there are typically symlinks from `/etc/letsencrypt/live/mail.example.com` to `/etc/letsencrypt/archive`.
|
||||
|
||||
!!! example
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ You don't have to do anything else. Enjoy!
|
|||
|
||||
#### Example using Docker for _Let's Encrypt_ { data-toc-label='Certbot with Docker' }
|
||||
|
||||
Certbot provisions certificates to `/etc/letsencrypt`. Add a volume to store these, so that they can later be accessed by `docker-mailserver` container. You may also want to persist Certbot [logs][certbot::log-rotation], just in case you need to troubleshoot.
|
||||
Certbot provisions certificates to `/etc/letsencrypt`. Add a volume to store these, so that they can later be accessed by DMS container. You may also want to persist Certbot [logs][certbot::log-rotation], just in case you need to troubleshoot.
|
||||
|
||||
1. Getting a certificate is this simple! (_Referencing: [Certbot docker instructions][certbot::docker] and [`certonly --standalone` mode][certbot::standalone]_):
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ Certbot provisions certificates to `/etc/letsencrypt`. Add a volume to store the
|
|||
certbot/certbot certonly --standalone -d mail.example.com
|
||||
```
|
||||
|
||||
2. Add a volume for `docker-mailserver` that maps the _local `certbot/certs/` folder_ to the container path `/etc/letsencrypt/`.
|
||||
2. Add a volume for DMS that maps the _local `certbot/certs/` folder_ to the container path `/etc/letsencrypt/`.
|
||||
|
||||
!!! example
|
||||
|
||||
|
|
@ -172,7 +172,7 @@ Obtain a Cloudflare API token:
|
|||
# Set SSL certificate type.
|
||||
- SSL_TYPE=letsencrypt
|
||||
volumes:
|
||||
# Mount the cert folder generated by Certbot into mail-server:
|
||||
# Mount the cert folder generated by Certbot:
|
||||
- ./docker-data/certbot/certs/:/etc/letsencrypt/:ro
|
||||
|
||||
certbot-cloudflare:
|
||||
|
|
@ -280,7 +280,7 @@ After completing the steps above, your certificate should be ready to use.
|
|||
|
||||
If you are running a web server already, port 80 will be in use which Certbot requires. You could use the [Certbot `--webroot`][certbot::webroot] feature, but it is more common to leverage a _reverse proxy_ that manages the provisioning and renewal of certificates for your services automatically.
|
||||
|
||||
In the following example, we show how `docker-mailserver` can be run alongside the docker containers [`nginx-proxy`][nginx-proxy::github] and [`acme-companion`][acme-companion::github] (_Referencing: [`acme-companion` documentation][acme-companion::docs]_):
|
||||
In the following example, we show how DMS can be run alongside the docker containers [`nginx-proxy`][nginx-proxy::github] and [`acme-companion`][acme-companion::github] (_Referencing: [`acme-companion` documentation][acme-companion::docs]_):
|
||||
|
||||
1. Start the _reverse proxy_ (`nginx-proxy`):
|
||||
|
||||
|
|
@ -314,7 +314,7 @@ In the following example, we show how `docker-mailserver` can be run alongside t
|
|||
|
||||
3. Start the rest of your web server containers as usual.
|
||||
|
||||
4. Start a _dummy container_ to provision certificates for your FQDN (eg: `mail.example.com`). `acme-companion` will detect the container and generate a _Let's Encrypt_ certificate for your domain, which can be used by `docker-mailserver`:
|
||||
4. Start a _dummy container_ to provision certificates for your FQDN (eg: `mail.example.com`). `acme-companion` will detect the container and generate a _Let's Encrypt_ certificate for your domain, which can be used by DMS:
|
||||
|
||||
```sh
|
||||
docker run --detach \
|
||||
|
|
@ -341,7 +341,7 @@ In the following example, we show how `docker-mailserver` can be run alongside t
|
|||
|
||||
#### Example using `nginx-proxy` and `acme-companion` with `docker-compose` { data-toc-label='nginx-proxy with docker-compose' }
|
||||
|
||||
The following example is the [basic setup][acme-companion::basic-setup] you need for using `nginx-proxy` and `acme-companion` with `docker-mailserver` (_Referencing: [`acme-companion` documentation][acme-companion::docs]_):
|
||||
The following example is the [basic setup][acme-companion::basic-setup] you need for using `nginx-proxy` and `acme-companion` with DMS (_Referencing: [`acme-companion` documentation][acme-companion::docs]_):
|
||||
|
||||
???+ example "Example: `docker-compose.yml`"
|
||||
|
||||
|
|
@ -412,7 +412,7 @@ The following example is the [basic setup][acme-companion::basic-setup] you need
|
|||
|
||||
[`acme-companion` ENV for default settings][acme-companion::env-config] that apply to all containers using `LETSENCRYPT_HOST`:
|
||||
|
||||
- `DEFAULT_EMAIL`: An email address that the CA (_eg: Let's Encrypt_) can contact you about expiring certificates, failed renewals, or for account recovery. You may want to use an email address not handled by your mail-server to ensure deliverability in the event your mail-server breaks.
|
||||
- `DEFAULT_EMAIL`: An email address that the CA (_eg: Let's Encrypt_) can contact you about expiring certificates, failed renewals, or for account recovery. You may want to use an email address not handled by your mail server to ensure deliverability in the event your mail server breaks.
|
||||
- `CERTS_UPDATE_INTERVAL`: If you need to adjust the frequency to check for renewals. 3600 seconds (1 hour) by default.
|
||||
- `DEBUG=1`: Should be helpful when [troubleshooting provisioning issues][acme-companion::troubleshooting] from `acme-companion` logs.
|
||||
- `ACME_CA_URI`: Useful in combination with `CA_BUNDLE` to use a private CA. To change the default _Let's Encrypt_ endpoint to the staging endpoint, use `https://acme-staging-v02.api.letsencrypt.org/directory`.
|
||||
|
|
@ -461,7 +461,7 @@ The following example is the [basic setup][acme-companion::basic-setup] you need
|
|||
|
||||
Version 6.2 and later of the Synology NAS DSM OS now come with an interface to generate and renew letencrypt certificates. Navigation into your DSM control panel and go to Security, then click on the tab Certificate to generate and manage letsencrypt certificates.
|
||||
|
||||
Amongst other things, you can use these to secure your mail-server. DSM locates the generated certificates in a folder below `/usr/syno/etc/certificate/_archive/`.
|
||||
Amongst other things, you can use these to secure your mail server. DSM locates the generated certificates in a folder below `/usr/syno/etc/certificate/_archive/`.
|
||||
|
||||
Navigate to that folder and note the 6 character random folder name of the certificate you'd like to use. Then, add the following to your `docker-compose.yml` declaration file:
|
||||
|
||||
|
|
@ -576,7 +576,7 @@ volumes:
|
|||
|
||||
Wildcard certificates are supported. If your FQDN is `mail.example.com` and your wildcard certificate is `*.example.com`, add the ENV: `#!bash SSL_DOMAIN=example.com`.
|
||||
|
||||
The mail-server will select it's certificate from `acme.json` checking these ENV for a matching FQDN (_in order of priority_):
|
||||
DMS will select it's certificate from `acme.json` checking these ENV for a matching FQDN (_in order of priority_):
|
||||
|
||||
1. `#!bash ${SSL_DOMAIN}`
|
||||
2. `#!bash ${HOSTNAME}`
|
||||
|
|
@ -639,13 +639,13 @@ This feature requires you to provide the following files into your [`docker-data
|
|||
- `<FQDN>-cert.pem`
|
||||
- `demoCA/cacert.pem`
|
||||
|
||||
Where `<FQDN>` is the FQDN you've configured for your `docker-mailserver` container.
|
||||
Where `<FQDN>` is the FQDN you've configured for your DMS container.
|
||||
|
||||
Add `SSL_TYPE=self-signed` to your `docker-mailserver` environment variables. Postfix and Dovecot will be configured to use the provided certificate (_`.pem` files above_) during container startup.
|
||||
Add `SSL_TYPE=self-signed` to your DMS environment variables. Postfix and Dovecot will be configured to use the provided certificate (_`.pem` files above_) during container startup.
|
||||
|
||||
#### Generating a self-signed certificate
|
||||
|
||||
One way to generate self-signed certificates is with [Smallstep's `step` CLI](https://smallstep.com/docs/step-cli). This is exactly what [`docker-mailserver` does for creating test certificates][github-file::tls-readme].
|
||||
One way to generate self-signed certificates is with [Smallstep's `step` CLI](https://smallstep.com/docs/step-cli). This is exactly what [DMS does for creating test certificates][github-file::tls-readme].
|
||||
|
||||
For example with the FQDN `mail.example.test`, you can generate the required files by running:
|
||||
|
||||
|
|
@ -709,7 +709,7 @@ The local and internal paths may be whatever you prefer, so long as both `SSL_CE
|
|||
|
||||
!!! info
|
||||
|
||||
You may have to restart `docker-mailserver` once the certificates change.
|
||||
You may have to restart DMS once the certificates change.
|
||||
|
||||
## Testing a Certificate is Valid
|
||||
|
||||
|
|
@ -870,7 +870,7 @@ fi
|
|||
|
||||
## Custom DH Parameters
|
||||
|
||||
By default `docker-mailserver` uses [`ffdhe4096`][ffdhe4096-src] from [IETF RFC 7919][ietf::rfc::ffdhe]. These are standardized pre-defined DH groups and the only available DH groups for TLS 1.3. It is [discouraged to generate your own DH parameters][dh-avoid-selfgenerated] as it is often less secure.
|
||||
By default DMS uses [`ffdhe4096`][ffdhe4096-src] from [IETF RFC 7919][ietf::rfc::ffdhe]. These are standardized pre-defined DH groups and the only available DH groups for TLS 1.3. It is [discouraged to generate your own DH parameters][dh-avoid-selfgenerated] as it is often less secure.
|
||||
|
||||
Despite this, if you must use non-standard DH parameters or you would like to swap `ffdhe4096` for a different group (eg `ffdhe2048`); Add your own PEM encoded DH params file via a volume to `/tmp/docker-mailserver/dhparams.pem`. This will replace DH params for both Dovecot and Postfix services during container startup.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,8 +15,8 @@ Prefer ports with Implicit [TLS][wikipedia-tls] ports, they're more secure than
|
|||
| POP3 | 110 | 995 | Retrieval | No |
|
||||
| IMAP4 | 143 | 993 | Retrieval | Yes |
|
||||
|
||||
1. A connection _may_ be secured over TLS when both ends support `STARTTLS`. On ports 110, 143 and 587, `docker-mailserver` will reject a connection that cannot be secured. Port 25 is [required][ref-port25-mandatory] to support insecure connections.
|
||||
2. Receives email, `docker-mailserver` additionally filters for spam and viruses. For submitting email to the server to be sent to third-parties, you should prefer the _submission_ ports (465, 587) - which require authentication. Unless a relay host is configured (eg: SendGrid), outgoing email will leave the server via port 25 (_thus outbound traffic must not be blocked by your provider or firewall_).
|
||||
1. A connection _may_ be secured over TLS when both ends support `STARTTLS`. On ports 110, 143 and 587, DMS will reject a connection that cannot be secured. Port 25 is [required][ref-port25-mandatory] to support insecure connections.
|
||||
2. 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 _submission_ ports (465, 587) - which require authentication. Unless a relay host is configured (eg: SendGrid), outgoing email will leave the server via port 25 (_thus outbound traffic must not be blocked by your provider or firewall_).
|
||||
3. A _submission_ port since 2018 ([RFC 8314][rfc-8314]).
|
||||
|
||||
??? warning "Beware of outdated advice on port 465"
|
||||
|
|
@ -29,7 +29,6 @@ Prefer ports with Implicit [TLS][wikipedia-tls] ports, they're more secure than
|
|||
|
||||
Understand that port 587 is more broadly supported due to this history and that lots of software in that time has been built or configured with that port in mind. [`STARTTLS` is known to have various CVEs discovered even in recent years][starttls-vulnerabilities], do not be misled by any advice implying it should be preferred over implicit TLS. Trust in more official sources, such as the [config Postfix has][postfix-upstream-config-mastercf] which acknowledges the `submissions` port (465).
|
||||
|
||||
|
||||
### What Ports Should I Use? (SMTP)
|
||||
|
||||
```mermaid
|
||||
|
|
@ -67,18 +66,18 @@ Mail arriving at your server will be processed and stored in a mailbox, or sent
|
|||
|
||||
- **Port 25:**
|
||||
- Think of this like a physical mailbox, anyone can deliver mail to you here. Typically most mail is delivered to you on this port.
|
||||
-`docker-mailserver` will actively filter email delivered on this port for spam or viruses, and refuse mail from known bad sources.
|
||||
- DMS will actively filter email delivered on this port for spam or viruses, and refuse mail from known bad sources.
|
||||
- Connections to this port may be secure through STARTTLS, but is not mandatory as [mail is allowed to arrive via an unencrypted connection][ref-port25-mandatory].
|
||||
- It is possible for internal clients to submit mail to be sent outbound (_without requiring authentication_), but that is discouraged. Prefer the _submission_ ports.
|
||||
- **Port 465 and 587:**
|
||||
- This is the equivalent of a post office box where you would send email to be delivered on your behalf (_`docker-mailserver` is that metaphorical post office, aka the MTA_).
|
||||
- This is the equivalent of a post office box where you would send email to be delivered on your behalf (_DMS is that metaphorical post office, aka the MTA_).
|
||||
- These two ports are known as the _submission_ ports, they enable mail to be sent outbound to another MTA (eg: Outlook or Gmail) but require authentication via a [mail account][docs-accounts].
|
||||
- For inbound traffic, this is relevant when you send mail from your MUA (eg: ThunderBird). It's also used when `docker-mailserver` is configured as a mail relay, or when you have a service sending transactional mail (_eg: order confirmations, password resets, notifications_) through `docker-mailserver`.
|
||||
- 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 (_eg: order confirmations, password resets, notifications_) through DMS.
|
||||
- _**Prefer port 465**_ over port 587, as 465 provides Implicit TLS.
|
||||
|
||||
!!! note
|
||||
|
||||
When submitting mail (inbound) to be sent (outbound), this involves two separate connections to negotiate and secure. There may be additional intermediary connections which `docker-mailserver` is not involved in, and thus unable to ensure encrypted transit throughout delivery.
|
||||
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.
|
||||
|
||||
#### Outbound Traffic (On the Right)
|
||||
|
||||
|
|
@ -94,7 +93,7 @@ Mail being sent from your server is either being relayed through another MTA (eg
|
|||
|
||||
!!! tip
|
||||
|
||||
`docker-mailserver` can function as a relay too, but professional relay services have a trusted reputation (_which increases success of delivery_).
|
||||
DMS can function as a relay too, but professional relay services have a trusted reputation (_which increases success of delivery_).
|
||||
|
||||
An MTA with low reputation can affect if mail is treated as junk, or even rejected.
|
||||
|
||||
|
|
@ -113,7 +112,7 @@ Sometimes a reverse-proxy is involved, but is misconfigured or lacks support for
|
|||
|
||||
!!! note
|
||||
|
||||
- By default, `docker-mailserver` is configured to reject connections that fail to establish a secure connection (_when authentication is required_), rather than allow an insecure connection.
|
||||
- By default, DMS is configured to reject connections that fail to establish a secure connection (_when authentication is required_), rather than allow an insecure connection.
|
||||
- Port 25 does not require authentication. If `STARTTLS` is unsuccessful, mail can be received over an unencrypted connection. You can better secure this port between trusted parties with the addition of MTA-STS, [STARTTLS Policy List][starttls-policy-list], DNSSEC and DANE.
|
||||
|
||||
!!! warning
|
||||
|
|
@ -140,7 +139,7 @@ While Explicit TLS can provide the same benefit (_when `STARTTLS` is successfull
|
|||
|
||||
A related section or page on ciphers used may be useful, although less important for users to be concerned about.
|
||||
|
||||
### TLS connections for a Mail-Server, compared to web browsers
|
||||
### TLS connections for a Mail Server, compared to web browsers
|
||||
|
||||
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,11 +12,11 @@ hide:
|
|||
|
||||
This script assumes Docker or Podman is used. You will not be able to use `setup.sh` with other container orchestration tools.
|
||||
|
||||
[`setup.sh`][github-file-setupsh] is a script that is complimentary to the internal `setup` command in `docker-mailserver`.
|
||||
[`setup.sh`][github-file-setupsh] is a script that is complimentary to the internal `setup` command in DMS.
|
||||
|
||||
It mostly provides the convenience of aliasing `docker exec -ti <CONTAINER NAME> setup`, inferring the container name of a running `docker-mailserver` instance or running a new instance and bind mounting necessary volumes implicitly.
|
||||
It mostly provides the convenience of aliasing `docker exec -ti <CONTAINER NAME> setup`, inferring the container name of a running DMS instance or running a new instance and bind mounting necessary volumes implicitly.
|
||||
|
||||
It is intended to be run from the host machine, _not_ from inside your running container. The latest version of the script is included in the `docker-mailserver` repository. You may retrieve it at any time by running this command in your console:
|
||||
It is intended to be run from the host machine, _not_ from inside your running container. The latest version of the script is included in the DMS repository. You may retrieve it at any time by running this command in your console:
|
||||
|
||||
```sh
|
||||
wget https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master/setup.sh
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ This project is Open Source. That means that you can contribute on enhancements,
|
|||
|
||||
**Before opening an issue**, read the [`README`][github-file-readme] carefully, study the docs for your version (maybe [latest][docs-latest]), the Postfix/Dovecot documentation and your search engine you trust. The issue tracker is not meant to be used for unrelated questions!
|
||||
|
||||
When opening an issue, please provide details use case to let the community reproduce your problem. Please start `docker-mailserver` with the environment variable `LOG_LEVEL` set to `debug` or `trace` and paste the output into the issue.
|
||||
When opening an issue, please provide details use case to let the community reproduce your problem. Please start DMS with the environment variable `LOG_LEVEL` set to `debug` or `trace` and paste the output into the issue.
|
||||
|
||||
!!! attention
|
||||
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ services:
|
|||
|
||||
This guide is focused on only using [SMTP ports (not POP3 and IMAP)][docs-ports] with the intent to relay mail received from another service to an external email address (eg: `user@gmail.com`). It is not intended for mailbox storage of real users.
|
||||
|
||||
In this setup `docker-mailserver` 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.
|
||||
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.
|
||||
|
||||
!!! tip "`setup`"
|
||||
|
||||
|
|
@ -159,7 +159,7 @@ In this setup `docker-mailserver` is not intended to receive email from the outs
|
|||
@ 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
|
||||
|
|
@ -182,7 +182,7 @@ In this setup `docker-mailserver` is not intended to receive email from the outs
|
|||
|
||||
4. Get an SSL certificate, [we have a guide for you here][docs-ssl] (_Let's Encrypt_ is a popular service to get free SSL certificates).
|
||||
|
||||
5. Start `docker-mailserver` and check the terminal output for any errors: `docker-compose up`.
|
||||
5. Start DMS and check the terminal output for any errors: `docker-compose up`.
|
||||
|
||||
6. Create email accounts and aliases:
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 'Tutorials | Blog Posts'
|
||||
---
|
||||
|
||||
This site lists blog entries that write about the project. If you blogged about `docker-mailserver` let us know so we can add it here!
|
||||
This site lists blog entries that write about the project. If you blogged about DMS let us know so we can add it here!
|
||||
|
||||
- [Installing docker-mailserver](https://lowtek.ca/roo/2021/installing-docker-mailserver/) by [@andrewlow](https://github.com/andrewlow)
|
||||
- [Self hosted mail-server](https://www.ifthenel.se/self-hosted-mail-server/) by [@matrixes](https://github.com/matrixes)
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
title: 'Tutorials | Mail-Server behind a Proxy'
|
||||
title: 'Tutorials | Mail Server behind a Proxy'
|
||||
---
|
||||
|
||||
## Using `docker-mailserver` behind a Proxy
|
||||
## Using DMS behind a Proxy
|
||||
|
||||
### Information
|
||||
|
||||
|
|
@ -53,7 +53,7 @@ Feel free to add your configuration if you achieved the same goal using differen
|
|||
[...]
|
||||
```
|
||||
|
||||
Truncated list of necessary labels on the `docker-mailserver` container:
|
||||
Truncated list of necessary labels on the DMS container:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
title: 'Use Cases | Forward-Only Mail-Server with LDAP'
|
||||
title: 'Use Cases | Forward-Only Mail Server with LDAP'
|
||||
---
|
||||
|
||||
## Building a Forward-Only Mail-Server
|
||||
## Building a Forward-Only Mail Server
|
||||
|
||||
A **forward-only** mail-server does not have any local mailboxes. Instead, it has only aliases that forward emails to external email accounts (for example to a Gmail account). You can also send email from the localhost (the computer where `docker-mailserver` is installed), using as sender any of the alias addresses.
|
||||
A **forward-only** mail server does not have any local mailboxes. Instead, it has only aliases that forward emails to external email accounts (for example to a Gmail account). You can also send email from the localhost (the computer where DMS is installed), using as sender any of the alias addresses.
|
||||
|
||||
The important settings for this setup (on `mailserver.env`) are these:
|
||||
|
||||
|
|
@ -27,7 +27,7 @@ We can create aliases with `./setup.sh`, like this:
|
|||
|
||||
## Authenticating with LDAP
|
||||
|
||||
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 [this discussion][github-issue-1247]. However if there are many user accounts, it is better to use authentication with LDAP. The settings for this on `mailserver.env` are:
|
||||
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 [this discussion][github-issue-1247]. However if there are many user accounts, it is better to use authentication with LDAP. The settings for this on `mailserver.env` are:
|
||||
|
||||
```env
|
||||
ENABLE_LDAP=1 # with the :edge tag, use ACCOUNT_PROVISIONER
|
||||
|
|
@ -60,7 +60,7 @@ userPassword: {SSHA}abcdefghi123456789
|
|||
email: external-account@gmail.com
|
||||
```
|
||||
|
||||
This structure is different from what is expected/assumed from the configuration scripts of `docker-mailserver`, so it doesn't work just by using the `LDAP_QUERY_FILTER_...` settings. Instead, I had to use a custom configuration ([via `user-patches.sh`][docs-userpatches]). I created the script `docker-data/dms/config/user-patches.sh`, with content like this:
|
||||
This structure is different from what is expected/assumed from the configuration scripts of DMS, so it doesn't work just by using the `LDAP_QUERY_FILTER_...` settings. Instead, I had to use a custom configuration ([via `user-patches.sh`][docs-userpatches]). I created the script `docker-data/dms/config/user-patches.sh`, with content like this:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
|
@ -99,11 +99,11 @@ You see that besides `query_filter`, I had to customize as well `result_attribut
|
|||
|
||||
!!! note "See also"
|
||||
|
||||
For more details about using LDAP see: [LDAP managed mail-server with Postfix and Dovecot for multiple domains](https://www.vennedey.net/resources/2-LDAP-managed-mail-server-with-Postfix-and-Dovecot-for-multiple-domains)
|
||||
For more details about using LDAP see: [LDAP managed mail server with Postfix and Dovecot for multiple domains](https://www.vennedey.net/resources/2-LDAP-managed-mail-server-with-Postfix-and-Dovecot-for-multiple-domains)
|
||||
|
||||
!!! note
|
||||
|
||||
Another solution that serves as a forward-only mail-server is [this](https://gitlab.com/docker-scripts/postfix).
|
||||
Another solution that serves as a forward-only mail server is [this](https://gitlab.com/docker-scripts/postfix).
|
||||
|
||||
[docs-userpatches]: ../../config/advanced/override-defaults/user-patches.md
|
||||
[github-issue-1247]: https://github.com/docker-mailserver/docker-mailserver/issues/1247
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ As you'll realistically be deploying to production on a Linux host, if you are o
|
|||
|
||||
### How to alter a running DMS instance _without_ relaunching the container?
|
||||
|
||||
`docker-mailserver` 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.
|
||||
DMS aggregates multiple "sub-services", such as Postfix, Dovecot, Fail2ban, SpamAssassin, etc. In many cases, one may edit a sub-service's config and reload that very sub-service, without stopping and relaunching the whole mail server.
|
||||
|
||||
In order to do so, you'll probably want to push your config updates to your server through a Docker volume (these docs use: `./docker-data/dms/config/:/tmp/docker-mailserver/`), then restart the sub-service to apply your changes, using `supervisorctl`. For instance, after editing fail2ban's config: `supervisorctl restart fail2ban`.
|
||||
|
||||
|
|
@ -296,7 +296,7 @@ proxy_interfaces = X.X.X.X (your public IP)
|
|||
|
||||
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?
|
||||
|
||||
`docker-mailserver` has a built-in way to do post-install processes. If you place a script called **`user-patches.sh`** in the config directory it will be run after all configuration files are set up, but before the postfix, amavis and other daemons are started.
|
||||
DMS has a built-in way to do post-install processes. If you place a script called **`user-patches.sh`** in the config directory it will be run after all configuration files are set up, but before the postfix, amavis and other daemons are started.
|
||||
|
||||
It is common to use a local directory for config added to `docker-mailsever` via a volume mount in your `docker-compose.yml` (eg: `./docker-data/dms/config/:/tmp/docker-mailserver/`).
|
||||
|
||||
|
|
@ -405,7 +405,7 @@ Put received spams in `.Junk/` imap folder using `SPAMASSASSIN_SPAM_TO_INBOX=1`
|
|||
0 2 * * * docker exec mailserver sa-learn --spam /var/mail/example.com/username/.Junk --dbpath /var/mail-state/lib-amavis/.spamassassin
|
||||
```
|
||||
|
||||
With `docker-compose` you can more easily use the internal instance of `cron` within `docker-mailserver`. This is less problematic than the simple solution shown above, because it decouples the learning from the host on which `docker-mailserver` is running, and avoids errors if the mail-server is not running.
|
||||
With `docker-compose` you can more easily use the internal instance of `cron` within DMS. This is less problematic than the simple solution shown above, because it decouples the learning from the host on which DMS is running, and avoids errors if the mail server is not running.
|
||||
|
||||
The following configuration works nicely:
|
||||
|
||||
|
|
|
|||
|
|
@ -32,11 +32,11 @@ There is also a script - [`setup.sh`][github-file-setupsh] - supplied with this
|
|||
|
||||
### Configuration
|
||||
|
||||
We have a [dedicated configuration page][docs-environment]. It contains most of the configuration and explanation you need to setup _your_ mail server properly. Be aware that advanced tasks may still require reading through all parts of this documentation; it may also involve inspecting your running container for debugging purposes. After all, a mail-server is a complex arrangement of various programs.
|
||||
We have a [dedicated configuration page][docs-environment]. It contains most of the configuration and explanation you need to setup _your_ mail server properly. Be aware that advanced tasks may still require reading through all parts of this documentation; it may also involve inspecting your running container for debugging purposes. After all, a mail server is a complex arrangement of various programs.
|
||||
|
||||
!!! important
|
||||
|
||||
If you'd like to change, patch or alter files or behavior of `docker-mailserver`, you can use a script. Just place a script called `user-patches.sh` in your `./docker-data/dms/config/` folder volume (which is mounted to `/tmp/docker-mailserver/` inside the container) and it will be run on container startup. See the ['Modifications via Script' page][docs-userpatches] for additional documentation and an example.
|
||||
If you'd like to change, patch or alter files or behavior of DMS, you can use a script. Just place a script called `user-patches.sh` in your `./docker-data/dms/config/` folder volume (which is mounted to `/tmp/docker-mailserver/` inside the container) and it will be run on container startup. See the ['Modifications via Script' page][docs-userpatches] for additional documentation and an example.
|
||||
|
||||
You might also want to check out:
|
||||
|
||||
|
|
|
|||
|
|
@ -4,17 +4,17 @@ title: Introduction
|
|||
|
||||
# An Overview of Mail Server Infrastructure
|
||||
|
||||
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 `docker-mailserver`.
|
||||
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.
|
||||
|
||||
## The Anatomy of a Mail Server
|
||||
|
||||
A mail server is only a part of a [client-server relationship][wikipedia-clientserver] aimed at exchanging information in the form of [emails][wikipedia-email]. Exchanging emails requires using specific means (programs and protocols).
|
||||
|
||||
`docker-mailserver` provides you with the server portion, whereas the client can be anything from a terminal via text-based software (eg. [Mutt][software-mutt]) to a fully-fledged desktop application (eg. [Mozilla Thunderbird][software-thunderbird], [Microsoft Outlook][software-outlook]…), to a web interface, etc.
|
||||
DMS provides you with the server portion, whereas the client can be anything from a terminal via text-based software (eg. [Mutt][software-mutt]) to a fully-fledged desktop application (eg. [Mozilla Thunderbird][software-thunderbird], [Microsoft Outlook][software-outlook]…), to a web interface, etc.
|
||||
|
||||
Unlike the client-side where usually a single program is used to perform retrieval and viewing of emails, the server-side is composed of many specialized components. The mail server is capable of accepting, forwarding, delivering, storing and overall exchanging messages, but each one of those tasks is actually handled by a specific piece of software. All of these "agents" must be integrated with one another for the exchange to take place.
|
||||
|
||||
`docker-mailserver` 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!
|
||||
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!
|
||||
|
||||
## Components
|
||||
|
||||
|
|
@ -33,13 +33,13 @@ Fetching an email: MUA <--------------------------------- MDA
|
|||
|
||||
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).
|
||||
|
||||
In a nutshell, `docker-mailserver` provides you with the following components:
|
||||
In a nutshell, DMS provides you with the following components:
|
||||
|
||||
- A MTA: [Postfix](http://www.postfix.org/)
|
||||
- A MDA: [Dovecot](https://dovecot.org/)
|
||||
- A bunch of additional programs to improve security and emails processing
|
||||
|
||||
Here's where `docker-mailserver`'s toochain fits within the delivery chain:
|
||||
Here's where DMS's toochain fits within the delivery chain:
|
||||
|
||||
```txt
|
||||
docker-mailserver is here:
|
||||
|
|
@ -51,21 +51,21 @@ Fetching an email: MUA <------------------------------ ┫ MDA ╯ ┃
|
|||
|
||||
??? example "An Example"
|
||||
|
||||
Let's say Alice owns a Gmail account, `alice@gmail.com`; and Bob owns an account on a `docker-mailserver`'s instance, `bob@dms.io`.
|
||||
Let's say Alice owns a Gmail account, `alice@gmail.com`; and Bob owns an account on a DMS instance, `bob@dms.io`.
|
||||
|
||||
Make sure not to conflate these two very different scenarios:
|
||||
A) Alice sends an email to `bob@dms.io` => the email is first submitted to MTA `smtp.gmail.com`, then relayed to MTA `smtp.dms.io` where it is then delivered into Bob's mailbox.
|
||||
B) Bob sends an email to `alice@gmail.com` => the email is first submitted to MTA `smtp.dms.io`, then relayed to MTA `smtp.gmail.com` and eventually delivered into Alice's mailbox.
|
||||
|
||||
In scenario *A* the email leaves Gmail's premises, that email's *initial* submission is _not_ handled by your `docker-mailserver` instance(MTA); it merely receives the email after it has been relayed by Gmail's MTA. In scenario *B*, the `docker-mailserver` instance(MTA) handles the submission, prior to relaying.
|
||||
In scenario *A* the email leaves Gmail's premises, that email's *initial* submission is _not_ handled by your DMS instance(MTA); it merely receives the email after it has been relayed by Gmail's MTA. In scenario *B*, the DMS instance(MTA) handles the submission, prior to relaying.
|
||||
|
||||
The main takeaway is that when a third-party sends an email to a `docker-mailserver` instance(MTA) (or any MTA for that matter), it does _not_ establish a direct connection with that MTA. Email submission first goes through the sender's MTA, then some relaying between at least two MTAs is required to deliver the email. That will prove very important when it comes to security management.
|
||||
The main takeaway is that when a third-party sends an email to a DMS instance(MTA) (or any MTA for that matter), it does _not_ establish a direct connection with that MTA. Email submission first goes through the sender's MTA, then some relaying between at least two MTAs is required to deliver the email. That will prove very important when it comes to security management.
|
||||
|
||||
One important thing to note is that MTA and MDA programs may actually handle _multiple_ tasks (which is the case with `docker-mailserver`'s Postfix and Dovecot).
|
||||
One important thing to note is that MTA and MDA programs may actually handle _multiple_ tasks (which is the case with DMS's Postfix and Dovecot).
|
||||
|
||||
For instance, Postfix is both an SMTP server (accepting emails) and a relaying MTA (transferring, ie. sending emails to other MTA/MDA); Dovecot is both an MDA (delivering emails in mailboxes) and an IMAP server (allowing MUAs to fetch emails from the _mail server_). On top of that, Postfix may rely on Dovecot's authentication capabilities.
|
||||
|
||||
The exact relationship between all the components and their respective (sometimes shared) responsibilities is beyond the scope of this document. Please explore this wiki & the web to get more insights about `docker-mailserver`'s toolchain.
|
||||
The exact relationship between all the components and their respective (sometimes shared) responsibilities is beyond the scope of this document. Please explore this wiki & the web to get more insights about DMS's toolchain.
|
||||
|
||||
## About Security & Ports
|
||||
|
||||
|
|
@ -101,20 +101,20 @@ MUA <---- STARTTLS ------- ┤(143) MDA ╯ |
|
|||
```
|
||||
|
||||
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 `docker-mailserver`'s configuration, including how you can customize it.
|
||||
Read on to expand your understanding and learn about DMS's configuration, including how you can customize it.
|
||||
|
||||
### Submission - SMTP
|
||||
|
||||
For a MUA to send an email to an MTA, it needs to establish a connection with that server, then push data packets over a network that both the MUA (client) and the MTA (server) are connected to. The server implements the [SMTP][wikipedia-smtp] protocol, which makes it capable of handling _Submission_.
|
||||
|
||||
In the case of `docker-mailserver`, the MTA (SMTP server) is Postfix. The MUA (client) may vary, yet its Submission request is performed as [TCP][wikipedia-tcp] packets sent over the _public_ internet. This exchange of information may be secured in order to counter eavesdropping.
|
||||
In the case of DMS, the MTA (SMTP server) is Postfix. The MUA (client) may vary, yet its Submission request is performed as [TCP][wikipedia-tcp] packets sent over the _public_ internet. This exchange of information may be secured in order to counter eavesdropping.
|
||||
|
||||
Now let's say I own an account on a `docker-mailserver` instance, `me@dms.io`. There are two very different use-cases for Submission:
|
||||
Now let's say I own an account on a DMS instance, `me@dms.io`. There are two very different use-cases for Submission:
|
||||
|
||||
1. I want to send an email to someone
|
||||
2. Someone wants to send you an email
|
||||
|
||||
In the first scenario, I will be submitting my email directly to my `docker-mailserver` instance/MTA (Postfix), which will then relay the email to its recipient's MTA for final delivery. In this case, Submission is first handled by establishing a direct connection to my own MTA-so at least for this portion of the delivery chain, I'll be able to ensure security/confidentiality. Not so much for what comes next, ie. relaying between MTAs and final delivery.
|
||||
In the first scenario, I will be submitting my email directly to my DMS instance/MTA (Postfix), which will then relay the email to its recipient's MTA for final delivery. In this case, Submission is first handled by establishing a direct connection to my own MTA-so at least for this portion of the delivery chain, I'll be able to ensure security/confidentiality. Not so much for what comes next, ie. relaying between MTAs and final delivery.
|
||||
|
||||
In the second scenario, a third-party email account owner will be first submitting an email to some third-party MTA. I have no control over this initial portion of the delivery chain, nor do I have control over the relaying that comes next. My MTA will merely accept a relayed email coming "out of the blue".
|
||||
|
||||
|
|
@ -145,15 +145,15 @@ When it comes to securing Outbound Submission you should prefer to use _Implicit
|
|||
|
||||
Although a very satisfactory setup, Implicit TLS on port 465 is somewhat "cutting edge". There exists another well established mail Submission setup that must be supported as well, SMTP+STARTTLS on port 587. It uses Explicit TLS: the client starts with a cleartext connection, then the server informs a TLS-encrypted "upgraded" connection may be established, and the client _may_ eventually decide to establish it prior to the Submission. Basically it's an opportunistic, opt-in TLS upgrade of the connection between the client and the server, at the client's discretion, using a mechanism known as [STARTTLS][wikipedia-starttls] that both ends need to implement.
|
||||
|
||||
In many implementations, the mail server doesn't enforce TLS encryption, for backwards compatibility. Clients are thus free to deny the TLS-upgrade proposal (or [misled by a hacker](https://security.stackexchange.com/questions/168998/what-happens-if-starttls-dropped-in-smtp) about STARTTLS not being available), and the server accepts unencrypted (cleartext) mail exchange, which poses a confidentiality threat and, to some extent, spam issues. [RFC 8314 (section 3.3)][rfc-8314-s33] recommends for a mail server to support both Implicit and Explicit TLS for Submission, _and_ to enforce TLS-encryption on ports 587 (Explicit TLS) and 465 (Implicit TLS). That's exactly `docker-mailserver`'s default configuration: abiding by RFC 8314, it [enforces a strict (`encrypt`) STARTTLS policy](http://www.postfix.org/postconf.5.html#smtpd_tls_security_level), where a denied TLS upgrade terminates the connection thus (hopefully but at the client's discretion) preventing unencrypted (cleartext) Submission.
|
||||
In many implementations, the mail server doesn't enforce TLS encryption, for backwards compatibility. Clients are thus free to deny the TLS-upgrade proposal (or [misled by a hacker](https://security.stackexchange.com/questions/168998/what-happens-if-starttls-dropped-in-smtp) about STARTTLS not being available), and the server accepts unencrypted (cleartext) mail exchange, which poses a confidentiality threat and, to some extent, spam issues. [RFC 8314 (section 3.3)][rfc-8314-s33] recommends for a mail server to support both Implicit and Explicit TLS for Submission, _and_ to enforce TLS-encryption on ports 587 (Explicit TLS) and 465 (Implicit TLS). That's exactly DMS's default configuration: abiding by RFC 8314, it [enforces a strict (`encrypt`) STARTTLS policy](http://www.postfix.org/postconf.5.html#smtpd_tls_security_level), where a denied TLS upgrade terminates the connection thus (hopefully but at the client's discretion) preventing unencrypted (cleartext) Submission.
|
||||
|
||||
- **`docker-mailserver`'s default configuration enables and _requires_ Explicit TLS (STARTTLS) on port 587 for Outbound Submission.**
|
||||
- **DMS's default configuration enables and _requires_ Explicit TLS (STARTTLS) on port 587 for Outbound Submission.**
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
A final Outbound Submission setup exists and is akin SMTP+STARTTLS on port 587, but on port 25. That port has historically been reserved specifically for unencrypted (cleartext) mail exchange though, making STARTTLS a bit wrong to use. As is expected by [RFC 5321][rfc-5321], `docker-mailserver` uses port 25 for unencrypted Submission in order to support older clients, but most importantly for unencrypted Transfer/Relay between MTAs.
|
||||
A final Outbound Submission setup exists and is akin SMTP+STARTTLS on port 587, but on port 25. That port has historically been reserved specifically for unencrypted (cleartext) mail exchange though, making STARTTLS a bit wrong to use. As is expected by [RFC 5321][rfc-5321], DMS uses port 25 for unencrypted Submission in order to support older clients, but most importantly for unencrypted Transfer/Relay between MTAs.
|
||||
|
||||
- **`docker-mailserver`'s default configuration also enables unencrypted (cleartext) on port 25 for Outbound Submission.**
|
||||
- **DMS's default configuration also enables unencrypted (cleartext) on port 25 for Outbound Submission.**
|
||||
- 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.
|
||||
- One may also secure Outbound Submission using advanced encryption scheme, such as DANE/DNSSEC and/or MTA-STS.
|
||||
|
||||
|
|
@ -161,11 +161,11 @@ A final Outbound Submission setup exists and is akin SMTP+STARTTLS on port 587,
|
|||
|
||||
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.
|
||||
|
||||
- **`docker-mailserver`'s default configuration enables unencrypted (cleartext) on port 25 for Inbound Submission.**
|
||||
- **DMS's default configuration enables unencrypted (cleartext) on port 25 for Inbound Submission.**
|
||||
- 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.
|
||||
- One may also secure Inbound Submission using advanced encryption scheme, such as DANE/DNSSEC and/or MTA-STS.
|
||||
|
||||
Overall, `docker-mailserver`'s default configuration for SMTP looks like this:
|
||||
Overall, DMS's default configuration for SMTP looks like this:
|
||||
|
||||
```txt
|
||||
┏━━━━ Outbound Submission ━━━━┓
|
||||
|
|
@ -184,13 +184,13 @@ Me -- STARTTLS ---> ┤(587) │ ┊
|
|||
|
||||
A MUA willing to fetch an email from a mail server will most likely communicate with its [IMAP][wikipedia-imap] server. As with SMTP described earlier, communication will take place in the form of data packets exchanged over a network that both the client and the server are connected to. The IMAP protocol makes the server capable of handling _Retrieval_.
|
||||
|
||||
In the case of `docker-mailserver`, the IMAP server is Dovecot. The MUA (client) may vary, yet its Retrieval request is performed as [TCP][wikipedia-tcp] packets sent over the _public_ internet. This exchange of information may be secured in order to counter eavesdropping.
|
||||
In the case of DMS, the IMAP server is Dovecot. The MUA (client) may vary, yet its Retrieval request is performed as [TCP][wikipedia-tcp] packets sent over the _public_ internet. This exchange of information may be secured in order to counter eavesdropping.
|
||||
|
||||
Again, as with SMTP described earlier, the IMAP protocol may be secured with either Implicit TLS (aka. [IMAPS][wikipedia-imaps] / IMAP4S) or Explicit TLS (using STARTTLS).
|
||||
|
||||
The best practice as of 2020 is to enforce IMAPS on port 993, rather than IMAP+STARTTLS on port 143 (see [RFC 8314][rfc-8314]); yet the latter is usually provided for backwards compatibility.
|
||||
|
||||
**`docker-mailserver`'s default configuration enables both Implicit and Explicit TLS for Retrievial, on ports 993 and 143 respectively.**
|
||||
**DMS's default configuration enables both Implicit and Explicit TLS for Retrievial, on ports 993 and 143 respectively.**
|
||||
|
||||
### Retrieval - POP3
|
||||
|
||||
|
|
@ -198,14 +198,14 @@ Similarly to IMAP, the older POP3 protocol may be secured with either Implicit o
|
|||
|
||||
The best practice as of 2020 would be [POP3S][wikipedia-pop3s] on port 995, rather than [POP3][wikipedia-pop3]+STARTTLS on port 110 (see [RFC 8314][rfc-8314]).
|
||||
|
||||
**`docker-mailserver`'s default configuration disables POP3 altogether.** One should expect MUAs to use TLS-encrypted IMAP for Retrieval.
|
||||
**DMS's default configuration disables POP3 altogether.** One should expect MUAs to use TLS-encrypted IMAP for Retrieval.
|
||||
|
||||
## How Does `docker-mailserver` Help With Setting Everything Up?
|
||||
## How Does DMS Help With Setting Everything Up?
|
||||
|
||||
As a _batteries included_ container image, `docker-mailserver` 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.
|
||||
As a _batteries included_ container image, DMS provides you with all the required components and a default configuration to run a decent and secure mail server. One may then customize all aspects of its internal components.
|
||||
|
||||
- Simple customization is supported through [docker-compose configuration][github-file-compose] and the [env-mailserver][github-file-envmailserver] configuration file.
|
||||
- Advanced customization is supported through providing "monkey-patching" configuration files and/or [deriving your own image][github-file-dockerfile] from `docker-mailserver`'s upstream, for a complete control over how things run.
|
||||
- Advanced customization is supported through providing "monkey-patching" configuration files and/or [deriving your own image][github-file-dockerfile] from DMS's upstream, for a complete control over how things run.
|
||||
|
||||
|
||||
Eventually, it is up to _you_ deciding exactly what kind of transportation/encryption to use and/or enforce, and to customize your instance accordingly (with looser or stricter security). Be also aware that protocols and ports on your server can only go so far with security; third-party MTAs might relay your emails on insecure connections, man-in-the-middle attacks might still prove effective, etc. Advanced counter-measure such as DANE, MTA-STS and/or full body encryption (eg. PGP) should be considered as well for increased confidentiality, but ideally without compromising backwards compatibility so as to not block emails.
|
||||
|
|
|
|||
|
|
@ -168,7 +168,7 @@ You will very likely want to configure your DNS with these TXT records: [SPF, DK
|
|||
|
||||
### Custom User Changes & Patches
|
||||
|
||||
If you'd like to change, patch or alter files or behavior of `docker-mailserver`, you can use a script. See [this part of our documentation][docs-user-patches] for a detailed explanation.
|
||||
If you'd like to change, patch or alter files or behavior of DMS, you can use a script. See [this part of our documentation][docs-user-patches] for a detailed explanation.
|
||||
|
||||
[docs-user-patches]: ./faq.md#how-to-adjust-settings-with-the-user-patchessh-script
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue