Docker Mailserver selbst betreiben | ein Erfahrungsbericht

This page is also available in English

Mithilfe eines geeigneten Docker-Images ist es relativ einfach einen Mailserver selbst zu betreiben. Ursprünglich habe ich den integrierten Mailserver des Host Europe vServers (Plesk) verwendet und bin bei der Suche nach einem Ersatz auf einen sehr einfachen Docker-Container gestoßen. Der schlanke Container liefert einen Mailserver ohne grafische Verwaltungsoberfläche, kann aber mit wenigen einfachen Befehlen verwaltet werden. Für das Senden und Empfangen der Mails kann ein beliebiger E-Mail-Client verwendet werden, dazu wird POP3 oder IMAP für das Empfangen und SMTP für das Versenden angeboten. Ob die Mails des eigenen Servers empfangen und zugestellt werden können, hängt neben dem Setup, von den richtigen DNS-Einstellungen ab. 

SoftwareDocker-mailserver
GitHubhttps://github.com/docker-mailserver/docker-mailserver
aktuelle Version 11.1.0
gefunden 25.06.2022
 

Docker Basics

Docker ermöglicht es, Applikationen per Befehl in einem sogenannten Container zu starten.
Ein Container ist eine vom Betriebssystem (OS) unabhängige isolierte Umgebung:
Das OS spielt also keine Rolle, vorausgesetzt Docker lässt sich installieren.
Beim ersten Start eines Containers, lädt Docker selbstständig alle notwendigen Quellen
aus dem Internet.
Docker kann unter Windows, macOS oder einer Linux-Distribution installiert werden,
siehe auch: Docker

Voraussetzung

Vorab habe ich Docker installiert, siehe: topic/docker und für die SSL-Zertifikate den nginx-proxy-companion im Einsatz: Traefik-Reverse-Proxy.

Mailserver Inbetriebnahme

Als Mailserver habe ich das folgende Git-Repository geklont:

git clone https://github.com/docker-mailserver/docker-mailserver.git mailserver
cd mailserver
wget -O .env https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master/compose.env

Vor dem ersten Start sollte dann noch die .env Datei angepasst werden: Darin habe ich den Host-, Domain- und Container-Namen angepasst:

HOSTNAME=mailserver
DOMAINNAME=mailserver
CONTAINER_NAME=mailserver

Damit wäre der Server grundsätzlich einsatzbereit und könnte bereits gestartet werden. Könnte, denn für zusätzliche Einstellungen sollte auch noch kurz die Datei mailserver.env durchgesehen werden und darin benötigte Features aktiviert oder deaktiviert werden. Die Datei ist relativ gut kommentiert und dadurch weitestgehend selbsterklärend. Damit das Zustellen und Empfangen der Mails klappt, müssen zudem entsprechende DNS-Einträge erstellt werden.

Der Start des Containers erfolgt dann mit dem Befehl „docker-compose up“.

mailserver.env

Folgende Einstellungen habe ich in der mailserver.env – Datei angepasst:

OVERRIDE_HOSTNAME=domain.tld
POSTMASTER_ADDRESS=postmaster@domain.tld
ENABLE_FAIL2BAN=1
ENABLE_MANAGESIEVE=1
SSL_TYPE=letsencrypt
REPORT_RECIPIENT=1
ENABLE_SPAMASSASSIN=1
SRS_SENDER_CLASSES=envelope_sender,header_sender
ONE_DIR=1
POSTFIX_MESSAGE_SIZE_LIMIT=300000000

Für SSL_TYPE=letsencrypt, siehe: ssl

Für ENABLE_MANAGESIEVE=1, siehe: SIEVE

Zu ENABLE_SPAMASSASSIN, siehe SpamAssassin

Per Standardeinstellung ist die Größe der Mails auf 10 MB limitiert, durch das Setzen der Variablen „POSTFIX_MESSAGE_SIZE_LIMIT“ kann das Limit erhöht werden.

Administration

Neue E-Mail-Adressen oder Weiterleitungen können mithilfe des Setup-Skripts erstellt werden. Seit Version 10.2 befindet sich das Skript im Docker-Container, entsprechend erfolgt der Aufruf über „docker exec“. Die Hilfe kann wie folgt angezeigt werden:

docker exec mailserver setup help

„mailserver“ steht in dem Befehl für den Namen des Docker-Containers, hier die angezeigte Hilfe für Version 10.3

[+]
root@ubuntu:/var/mailserver# docker exec mailserver setup help
NAME
    setup - 'docker-mailserver' Administration & Configuration script

SYNOPSIS
    ./setup [ OPTIONS... ] COMMAND [ help | ARGUMENTS... ]

    COMMAND := { email | alias | quota | config | relay | debug } SUBCOMMAND

DESCRIPTION
    This is the main administration script that you use for all your interactions with
    'docker-mailserver'. Setup, configuration and much more is done with this script.

    Please note that this script executes most of its commands inside the container itself.
    If it cannot find a running 'docker-mailserver' container, it will attempt to run one using
    any available tags which include 'label=org.opencontainers.image.title="docker-mailserver"'
    and then run the necessary commands. If the tag for the container is not found, this script
    will pull the ':latest' tag of 'docker.io/mailserver/docker-mailserver'.
    This tag refers to the latest release, see the tagging convention in the README under:
    https://github.com/docker-mailserver/docker-mailserver/blob/master/README.md

    You will be able to see detailed information about the script you're invoking and their
    arguments by appending 'help' after your command. Currently, this does not work with all scripts.

[SUB]COMMANDS
    COMMAND email :=
        /usr/local/bin/setup email add <EMAIL ADDRESS> [<PASSWORD>]
        /usr/local/bin/setup email update <EMAIL ADDRESS> [<PASSWORD>]
        /usr/local/bin/setup email del [ OPTIONS... ] <EMAIL ADDRESS> [ <EMAIL ADDRESS>... ]
        /usr/local/bin/setup email restrict <add|del|list> <send|receive> [<EMAIL ADDRESS>]
        /usr/local/bin/setup email list

    COMMAND alias :=
        /usr/local/bin/setup alias add <EMAIL ADDRESS> <RECIPIENT>
        /usr/local/bin/setup alias del <EMAIL ADDRESS> <RECIPIENT>
        /usr/local/bin/setup alias list

    COMMAND quota :=
        /usr/local/bin/setup quota set <EMAIL ADDRESS> [<QUOTA>]
        /usr/local/bin/setup quota del <EMAIL ADDRESS>

    COMMAND config :=
        /usr/local/bin/setup config dkim [ ARGUMENTS... ]

    COMMAND relay :=
        /usr/local/bin/setup relay add-domain <DOMAIN> <HOST> [<PORT>]
        /usr/local/bin/setup relay add-auth <DOMAIN> <USERNAME> [<PASSWORD>]
        /usr/local/bin/setup relay exclude-domain <DOMAIN>

    COMMAND debug :=
        /usr/local/bin/setup debug fetchmail
        /usr/local/bin/setup debug fail2ban [unban <IP>]
        /usr/local/bin/setup debug show-mail-logs
        /usr/local/bin/setup debug inspect
        /usr/local/bin/setup debug login <COMMANDS>

EXAMPLES
    ./setup.sh email add test@example.com
        Add the email account test@example.com. You will be prompted
        to input a password afterwards since no password was supplied.

    ./setup.sh config dkim keysize 2048 domain 'example.com,not-example.com'
        Creates keys of length 2048 but in an LDAP setup where domains are not known to
        Postfix by default, so you need to provide them yourself in a comma-separated list.

    ./setup.sh config dkim help
        This will provide you with a detailed explanation on how to use the
        config dkim command, showing what arguments can be passed and what they do.

Mail-Adressen anlegen

docker exec mailserver setup email add email@domain password

Nach dem ersten Anlegen einer E-Mail-Adresse für eine neue Domain, kann der DKIM-Key für den DNS-Eintrag erstellt werden, siehe DKIM.

Alias anlegen (Weiterleitung)

docker exec mailserver setup alias add email@domain.tld weiterleitung@mail-adresse.ok

DKIM

Nachdem die ersten Mail-Adressen oder Weiterleitungen am System angelegt wurden, können mit folgendem Befehl DKIM Keys erzeugt werden:

docker exec mailserver setup config dkim

Die Keys werden für alle Domänen für die eine E-Mail-Adresse oder Weiterleitung angelegt wurde in folgendem Ordner abgelegt: config/opendkim/keys/domain.tld/mail.txt. Die Keys sollten dann für den DNS-Eintrag verwendet werden:

DNS-Einträge

Für den Betrieb eines Mailservers sollte neben dem A- und MX-Record der DKIM-Key, ein SPF-Eintrag und eine DMARC-Policy im DNS erstellt werden. Der Domänenname: domain.tld  steht in folgenden Beispielen repräsentativ für die eigene Domäne. Die folgenden Einträge müssen in die DNS-Zone für domain.tld hinzugefügt werden:

A-Record

Type Name Value
A mail.domain.tld IP-Adresse des Webservers

Als Servername sollte, in der Reverse-Lookup-Zone zudem mail.domain.tld hinterlegt werden, damit die IP-Adresse des Webservers auch auf mail.domain.tld auflöst. Bei einem vServer oder Cloud-Server eines Providers kann der Servername in der Admin-Oberfläche des Providers festgelegt werden.

MX

Type Name Value Priorität
MX mail.domain.tld IP-Adresse des Webservers  

Der MX-Record ist für das Zustellen der Mails zuständig. Alle Mails die @domain.tld als Domäne haben, werden an diesen Server zugestellt. Bei mehreren Mailservern wird der Server mit der niedrigsten Priorität verwendet.

Der zuvor erstellte DKIM Key:

Type Name Value
TXT mail._domainkey.domain.tld „v=DKIM1; h=sha256; k=rsa; p=Inhalt-von-config/opendkim/keys/domain.tld/mail.txt 

DKIM (DomainKeys Identified Mail) ist eine Signatur, die den Mails hinzugefügt wird, um das Fälschen des Absenders zu erschweren. DKIM wird für das Versenden von Mails verwendet.

SPF-Eintrag

Type Name Value
TXT @ „v=spf1 ip4:IP-Adresse-des-Webservers -all"

Um die ip4-Einstellung einer anderen Domäne zu verwenden, kann der SPF-Eintrag wie folgt umgeleitet werden. Wichtig ist dabei, dass der Parameter -all nicht verwendet wird: 

Type Name Value
TXT @ „v=spf1 redirect=server.domain.tld"

Auch der SPF-Eintrag (Sender Policy Framework) ist eine Maßnahme um das Fälschen von E-Mail-Adressen zu erschweren. Der SPF-Eintrag gibt vor welche Server für das Senden der Emails berechtigt sind, in dem Beispiel die IP-Adresse unseres Mailservers.

DMARC

Type Name Value
TXT _dmarc.domain.tld „v=DMARC1; p=reject; rua=mailto:report@domain.tld"

DMARC baut auf SPF und DKIM auf und gibt vor, wie der Server an dem eine Mail geschickt wird, das Email authentifizieren soll.

DNS überprüfen

Am einfachsten können die DNS-Einträge auf der Seite mxtoolbox.com getestet werden: mxtoolbox.com/MXLookup.aspx

Als Beispiel für die Domain: domain.tld

MX Lookup

Der MX-Lookup auf der Seite mxtoolbox sollte ca. so aussehen:

Pref Hostname IP Address TTL  
10 mail.domain.tld xxx.xxx.xxx.xxx 24 hrs Blacklist Check      SMTP Test
  Test Result
DMARC Record Published DMARC Record found
DMARC Policy Not Enabled DMARC Quarantine/Reject policy enabled
DNS Record Published DNS Record found

SMTP Test

Hier ein SMTP-Test auf mxtoolbox:

smtp:IP-AdresseMailserver

220 mail.domain.tld ESMTP

  Test Result
SMTP Reverse DNS Mismatch OK - xxx.xxx.xxx.xxx resolves to domain.tld
SMTP Valid Hostname OK - Reverse DNS is a valid Hostname
SMTP Banner Check OK - Reverse DNS matches SMTP Banner
SMTP TLS OK - Supports TLS.
SMTP Connection Time 0.303 seconds - Good on Connection time
SMTP Open Relay OK - Not an open relay.
SMTP Transaction Time 1.006 seconds - Good on Transaction Time

E-Mail an eine Google-Adresse

Als Beispiel kann das E-Mail vom eigenen Webserver auch an ein Google-Konto gesendet werden:

Auch hier taucht unter „Original anzeigen“ dann ein Status zu SPF, DKIM und DMARC auf:

Originalnachricht

Nachrichten-ID <xxxxxx.xxxxxx.xxxx.xxxx@mx.google.com>
Erstellt am: 29. März 2021 um 17:55 (Nach 2 Sekunden zugestellt)
Von: Vorname Nachname <user@domain.tld>
An: „Vorname Nachname (gmailuser@gmail.com)“ <gmailuser@gmail.com>
Betreff: test - dns
SPF: PASS mit IP-Adresse xxx.xxx.xxx.xxx 
DKIM: 'PASS' mit Domain domain.tld
DMARC: 'PASS'

SSL-Zertifikate

Als Setup für SSL-Zertifikate verwende ich Let's Encrypt und einen Reverse Proxy, siehe: Traefik-Reverse-Proxy. Damit die Zertifikatsverwaltung vom Reverse Proxy verwendet werden kann, habe ich das docker-compose.yml-File wie folgt angepasst:

[+]
version: '3.8'

services:
  mailserver:
    image: docker.io/mailserver/docker-mailserver:latest
    hostname: ${HOSTNAME}
    domainname: ${DOMAINNAME}
    container_name: ${CONTAINER_NAME}
    env_file: mailserver.env
    ports:
      - "25:25"
      - "143:143"
      - "587:587"
      - "993:993"  
      - "4190:4190"
    volumes:
      - ./docker-data/dms/maildata:/var/mail
      - ./docker-data/dms/mailstate:/var/mail-state
      - ./docker-data/dms/maillogs:/var/log/mail
      - ./docker-data/dms/config/:/tmp/docker-mailserver/${SELINUX_LABEL}
      - ./docker-data/dms/cron/sa-learn:/etc/cron.d/sa-learn
      - ../traefik/letsencrypt/acme.json:/etc/letsencrypt/acme.json:ro 
      - /etc/localtime:/etc/localtime:ro
    restart: always
    cap_add: [ "NET_ADMIN", "SYS_PTRACE" ]
  cert-companion:
    image: nginx
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.mailserver.rule=Host(`${HOSTNAME}`)"   
      - "traefik.http.routers.mailserver.entrypoints=web"
      - "traefik.http.routers.mailserver.entrypoints=websecure"
      - "traefik.http.routers.mailserver.tls.certresolver=myresolver"  
    networks:
      - proxy-tier
    restart: always

networks:
   proxy-tier:
           external:
                   name: webproxy

Der Pfad zum nginx-data-Ordner des Webproxy unter „Volumes“ muss natürlich entsprechend angepasst werden. Zudem habe ich, anders als beim originalen docker-compose-File, die anderen Volumes in das Dateisystem umgeleitet. 

SpamAssassin Spamfilter learn

Um der Flut an Spam-Mails Herr zu werden, habe ich SpamAssassin mit dem sa-learn-Befehl trainiert: SpamAssassin kann neben Blacklists und anderen Spamprüfungen von bestehenden Mails aus der Inbox und dem Junk-Ordner lernen. Der Befehl sa-learn untersucht dazu beide Ordner und merkt sich bestimmte Muster von Spam und Nicht-Spam Mails (Ham). Wird also ein Mail falsch erkannt und dann über den Mail-Client in den Spam-Ordner verschoben, kann SpamAssassin daraus lernen und ein ähnliches Mail beim nächsten Mal ev. gleich in den Spam-Ordner geben.

Der sa-learn-Befehl kann wie folgt im Docker-Container gestartet werden:

root@server:~# docker exec mailserver sa-learn --ham /var/mail/*/*/cur* --dbpath /var/mail-state/lib-amavis/.spamassassin
Learned tokens from 0 message(s) (1375 message(s) examined)
root@server:~# docker exec mailserver sa-learn --spam /var/mail/*/*/.Junk --dbpath /var/mail-state/lib-amavis/.spamassassin
Learned tokens from 22 message(s) (705 message(s) examined)

/var/*/*/cur* durchsucht dabei alle Posteingänge und deren Unterordner, /var/mail/*/*/.Junk alle Spam-Ordner aller Mailboxen.

Damit der Lern-Befehl regelmäßig gestartet wird, kann der im Container integrierte Cron-Service verwendet und dazu folgende Datei angelegt werden:

docker-data/dms/cron/sa-learn

0  2 * * * root  sa-learn --ham /var/mail/*/*/cur* --dbpath /var/mail-state/lib-amavis/.spamassassin
0  3 * * * root  sa-learn --spam /var/mail/*/*/.Junk --dbpath /var/mail-state/lib-amavis/.spamassassin

SIEVE - Filterregeln

Mit Hilfe von Sieve-Filtern ist es möglich bestimmte Regeln auf die Inbox anzuwenden, z. B. bestimmte Absender in einen Ordner zu verschieben. Hier ein Beispiel, meiner in NextCloud verwendeten Filterregeln:

[+]
require ["fileinto", "mailbox","envelope","reject"];
if anyof (address :contains "From" [
          "@spamdomain1.tld",
          "@spamdomain2.tld"
    ],
    header :contains "Subject" [
          "Viagra",
          "other SPAM-Keyword",
    ]
    )
{
     fileinto :create "Junk";
}
elsif anyof (address :matches "From" [
     "noreply@domain.tld",
     "newsletter@domain.tld"
    ]
    )
{
     fileinto :create "Newsletter";
}

Damit Sieve über die Filterregeln über den Mail-Client geändert werden können, muss der Port 4190 in docker-compose hinterlegt werden.

FetchMail – Mails von anderen Konten holen

Um regelmäßig E-Mails von einem anderen Konto abzuholen, kann in der Datei mailserver.env „ENABLE_FETCHMAIL“ aktiviert werden:

# –––––––––––––––––––––––––––––––––––––––––––––––
# ––– Fetchmail Section –––––––––––––––––––––––––
# –––––––––––––––––––––––––––––––––––––––––––––––

ENABLE_FETCHMAIL=1

# The interval to fetch mail in seconds
FETCHMAIL_POLL=300

Der Standardwert für das Abholen ist alle 5 Minuten.

Die Kontodaten für das Abholen können dann in folgender Config-Datei hinterlegt werden: docker-data/dms/config/fetchmail.cf

## Example configuration: IMAP
poll imap.domain.tld with proto IMAP
	user 'ccc@gmx.at' there with
	password 'pwd'
	is 'mailboxOnDockerMailserver@domain.tld'
	here ssl

Debug - Fail2ban

Sollte der Service Fail2ban aktiviert sein, werden fehlgeschlagene Anmeldeversuche bestraft, in dem der Absender für einige Zeit blockiert wird. Die blockierten IP-Adressen können wie folgt angezeigt und wieder freigegeben werden:

docker exec mailserver setup debug fail2ban
Banned in dovecot: xxx.xxx.xxx.xxx
Banned in postfix-sasl: 60.171.17.185, 61.182.227.245, 117.50.65.112, 116.196.112.146, 119.62.142.225, 113.31.104.89
root@ubuntu-4gb-nbg1-2:/var/web/mailserver# ./setup.sh debug fail2ban unban xxx.xxx.xxx.xxx
Unbanned IP from dovecot: xxx.xxx.xxx.xxx
root@ubuntu:/var/web/mailserver# 

Log-Ausgabe

Wie auch für anderen Docker-Container kann mit „docker logs“ angezeigt werden, was der Container gerade so treibt: 

docker logs -f mailserver

Troubleshooting: DNS-Einträge

Policy Reasons

Mail Delivery Subsystem 

Returned mail: see transcript for details

This message was created automatically by mail delivery software.

Deny to deliver the message you sent to one or more recipients.

Reasons for deny are as follows:



REASONS: Policy Reasons



RECIPIENTS:
xxx@xxx.xx

Mögliche Ursache: fehlender SPF-Record

Domain unbekannt

Ein E-Mail an eine unbekannte Domain wird ca. so vom Mail Delivery Subsystem präsentiert:

Mail Delivery Subsystem 

Returned mail: see transcript for details

Undelivered Mail Returned to Sender

This is the mail system at host mail.domain.tld.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<gibts-nicht@ungültige.domain
Zitierter Text
>: Host or domain name not found. Name service error
    for name=ungültige.domain type=AAAA: Host not found

Delivery report

postmaster@xxx.xxx.xxx

Delivery report

Hello, this is the mail server on xxx.xxx.xxx



I am sending you this message to inform you on the delivery status of a

message you previously sent.  Immediately below you will find a list of

the affected recipients;  also attached is a Delivery Status Notification

(DSN) report in standard format, as well as the headers of the original

message.



  <user@xxx.xxx.xxx

Zitierter Text

>  delivery failed; will not continue trying

Upgrade

Wie für Docker üblich, können neue Versionen mit einem pull geladen werden:

docker-compose pull
docker-compose up -d

Fazit

Zugegeben, die Verwaltung über Befehle im Terminal ist sicher nicht jedermanns Sache. Der Vorteil dieses Setups ist aber, dass sich die Konfiguration und die Daten des kompletten Mailservers dank Docker in einem Ordner befinden und der Server somit ganz einfach auf einen anderen Server kopiert und dort gestartet werden kann, siehe auch: topic/docker

positive Bewertung({{pro_count}})
Beitrag bewerten:
{{percentage}} % positiv
negative Bewertung({{con_count}})

DANKE für deine Bewertung!


Top-Artikel in diesem Bereich

Preview ioBroker installieren - Docker

ioBroker installieren - Docker

geändert: 12.11.2020 von Bernhard (Erstveröffentlichung: 06.11.2020)

Mit ioBroker können verschiedene Automatisierungslösungen oder Geräte in einem System zusammengefasst werden. Um bestimmte Gateways oder Geräte ansprechen zu können, werden in ioBroker verschiedene Adapter verwendet.  ... weiterlesen

Preview Home-Assistant Docker Conbee 2 und Zigbee2MQTT / deCONZ

Home-Assistant Docker Conbee 2 und Zigbee2MQTT / deCONZ

geändert: 10.08.2022 von Bernhard (Erstveröffentlichung: 06.11.2020)

Dank zahlreicher Integrationsmöglichkeiten ist Home-Assistant eine einfache Plattform für das Steuern verschiedenster Smart-Home Geräte. Im Vergleich zu ioBroker ist mir der Start mit Home Assistant wesentlich einfacher gefallen. Während ich für ioBroker noch am Suchen war, welches Frontend ich für meine Dashboards verwenden könnte, hatte ich mit Home-Assistant out of the box ein fertig eingerichtetes System. Die Lovelance Dashboards von Home Assistant können einfach in der GUI zusammengeklickt... ... weiterlesen

Bitwarden in Docker betreiben - Setup Schritt für Schritt

Bitwarden in Docker betreiben - Setup Schritt für Schritt

geändert: 10.08.2022 von Bernhard (Erstveröffentlichung: 28.02.2022)

Bitwarden ist ein webbasierter Passwort-Manager, ähnlich LastPass, aber Open Source und der Möglichkeit diesen selbst zu betreiben (hosten). Wie sich Bitwarden im Vergleich zu anderen Passwort-Managern einordnet, habe ich auf folgender Seite überlegt: Passwort-Manager sicher? KeePass vs. LastPass vs. Bitwarden. ... weiterlesen


Fragen / Kommentare


Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu Mehr Details