Will man einen eigenen Mailserver mit Docker installieren, erfordert dieses Vorhaben dank Software wie Docker Mailserver keinen großen Aufwand und ist recht schnell und einfach getan. Das Docker-Image kombiniert viele der benötigten Dienste, um einen eigenen E-Mail-Server aufzusetzen und nach seinen Wünschen anzupassen. So beinhaltet Docker Mailserver beispielsweise Dienste, die automatisch Spam erkennen, E-Mails mit schädlichen Anhängen filtern, Angreifer blockieren und viele weitere.
Inhaltsverzeichnis
Voraussetzungen
- Linux als Betriebssystem
- Server (z.B. von netcup; kontaktiert mich gerne für Gutschein im Wert eines Gratis-Monats oder im Wert von 5€)
- Docker (Tutorial)
- Docker-compose (Tutorial)
- Mindestens:
- 512 MB Arbeitsspeicher
- 1 vCore
- Empfohlen:
- 2 GB Arbeitsspeicher
- 1 Core
Vorbereitung
Generell
Ordner anlegen
Zunächst legen wir uns einen Ordner an, in dem wir unsere Konfigurationsdateien ablegen wollen und navigieren in diesen. In meinem Beispiel nutzen wir hierfür das Verzeichnis /opt/containers/.
mkdir /opt/containers/mailserver/
cd /opt/containers/mailserver/Konfigurationsdateien herunterladen
Nun besorgen wir uns eine Konfigurationsdatei, die wir für unseren Server benötigen.
Um die Datei herunterzuladen, führen wir die nachfolgenden Befehle aus:
wget "https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master/mailserver.env"Mailserver installieren
Docker Container erstellen
Die docker-compose.yml, die unseren Docker-Container erzeugen wird, erstellen wir mit nano (oder einem anderen Texteditor eurer Wahl):
nano docker-compose.ymlAnschließend fügen wir folgenden Inhalt ein:
services:
mailserver:
image: ghcr.io/docker-mailserver/docker-mailserver:12
container_name: mailserver
hostname: mail.meinserver.de
env_file: mailserver.env
ports:
- "25:25" # SMTP (explicit TLS => STARTTLS)
- "143:143" # IMAP4 (explicit TLS => STARTTLS)
- "465:465" # ESMTP (implicit TLS)
- "587:587" # ESMTP (explicit TLS => STARTTLS)
- "993:993" # IMAP4 (implicit TLS)
volumes:
- ./docker-data/dms/mail-data/:/var/mail/
- ./docker-data/dms/mail-state/:/var/mail-state/
- ./docker-data/dms/mail-logs/:/var/log/mail/
- ./docker-data/dms/config/:/tmp/docker-mailserver/
- /etc/localtime:/etc/localtime:ro
- ./letsencrypt:/etc/letsencrypt
restart: always
stop_grace_period: 1m
cap_add:
- NET_ADMIN
dns:
- 8.8.8.8
- 8.8.4.4
healthcheck:
test: "ss --listening --tcp | grep -P 'LISTEN.+:smtp' || exit 1"
timeout: 3s
retries: 0
depends_on:
- certbot
Hierbei muss meinserver.de in der Zeile „hostname“ durch eure jeweilige Domain ersetzt werden. Es ist generell eine Best-Practice den Mailserver unter der Subdomain mail laufen zu lassen.
SSL / TLS-Zertifikate installieren
Mithilfe eines SSL- bzw. TLS-Zertifikates ermöglichen wir es unserem Mailserver, verschlüsselt mit anderen Servern kommunizieren. Dies ist notwendig, damit unsere E-Mails nicht im Klartext durch das Internet versendet werden. Zudem würden unsere versendeten E-Mails ohne ein gültiges Zertifikat von den allermeisten Mailservern wie beispielsweise WEB.DE, Gmail, GMX, usw. abgelehnt werden.
Zur automatischen Austellung und Erneuerung der Zertifikate nutzen wir in diesem Beispiel certbot, welches die kostenlosen Zertifikate bei Let’s Encrypt anfordert. Damit Certbot funktioniert, benötigt Certbot den Port 80 zum Anfordern der Zertifikate. Hierzu wird ebenfalls ein Docker Container verwendet. In die docker-compose.yml fügen wir nun ganz ans Ende noch folgenden Inhalt ein:
certbot:
image: certbot/certbot
container_name: certbot
ports:
- "80:80"
volumes:
- ./letsencrypt:/etc/letsencrypt
- ./certbot/logs:/var/log/letsencrypt/
command: certonly --standalone --keep-until-expiring --email mail@meinemail.de -d mail.meinserver.de --agree-tos
Hierbei muss wieder meinserver.de durch eure jeweilige Domain ersetzt werden und die E-Mail angepasst werden.
Gespeichert wird das Dokument mit STRG + O und verlassen mit STRG + X.
Damit die Zertifikate regelmäßig erneuert werden, muss ein Cronjob eingereichtet werden. Dazu wird der Befehl crontab -e als root-User (oder ein anderer für das Starten von Docker-Containern berechtige User) verwendet. Anschließend wird die folgende Zeile an das Ende der Crontab-Datei hinzugefügt: 0 0 1 */2 * /usr/local/bin/docker-compose -f /pfad/zu/deiner/docker-compose.yml up certbot
Docker Container konfigurieren
In der mailserver.env befinden sich einige Parameter, mit denen wir unseren Docker Mailserver nach Wunsch anpassen können. Zu jedem Parameter steht in der Datei eine kleine Erklärung zu dessen Funktion.
Nutzung der Zertifikate
Zunächst konfigurieren wir die Nutzung der zuvor erstellen SSL-/TLS-Zertifikate.
Die Datei öffnen wir mit:
nano mailserver.envNun suchen wir nach den Zeilen:
SSL_TYPE=
SSL_CERT_PATH=
SSL_KEY_PATH=und ersetzen diese durch die folgenden:
SSL_TYPE=letsencrypt
SSL_DOMAIN=mail.meinserver.de
#SSL_CERT_PATH=
#SSL_KEY_PATH=Hierbei ersetzen wir natürlich wieder meinserver.de durch unsere eigene Domain.
Spamschutz aktivieren
Damit unser Mailserver richtig mit Spam umgeht, suchen wir die Zeilen:
ENABLE_OPENDKIM=1
ENABLE_OPENDMARC=1
ENABLE_POLICYD_SPF=1
ENABLE_CLAMAV=0
ENABLE_RSPAMD=0
RSPAMD_LEARN=0
RSPAMD_GREYLISTING=0und ersetzen diese mit:
ENABLE_OPENDKIM=0
ENABLE_OPENDMARC=0
ENABLE_POLICYD_SPF=0
ENABLE_CLAMAV=1
ENABLE_RSPAMD=1
RSPAMD_LEARN=1
RSPAMD_GREYLISTING=1OpenDKIM, OpenDMARC und SPF sind veraltet und werden in Zukunft standardmäßig in Docker-Mailserver deaktiviert sein. Der Ersatz für diese drei Dienste ist rspamd. ClamAV ist der integrierte Virenscanner und sollte nur aktiviert werden, wenn der Mailserver mindestens 2GB RAM zur Verfügung hat. RSPAMD_LEARN=1 sorgt dafür, dass der Mailserver dazulernt, wenn man Mails in den Spam-Order verschiebt. RSPAMD_GREYLISTING=1 weist Mails, die nach Spam aussehen zunächst zurück. Während Spam-Mails häufig nur ein Mal zugestellt werden, versucht ein vertrauenswüriger Mailserver es einige Male mehr, eine Mail korrekt zuzustellen. Durch diese Einstellung können aber Mails bestimmter Absender die ersten Male um einige Minuten verzögert sein.
Mailserver konfigurieren
Docker Mailserver starten
Für die weitere Konfiguration muss unser Docker Mailserver gestartet werden:
docker-compose up -dDer Befehl sorgt dafür, dass im aktuellen Verzeichnis /opt/containers/mailserver/ im Hintergrund ein Docker-Container gestartet wird. In unserem Fall ist das der Mailserver.
Nachdem wir den Docker-Container nun einmal händisch gestartet haben, muss dieser im Normalfall nicht mehr von hand gestartet werden. Tritt beispielsweise ein Fehler im Mailserver auf, startet dieser wieder von alleine. Selbst nach einem Neustart des gesamten System startet der Container von selbst.
E-Mail-Adressen anlegen
Nachdem im vorherigen Schritt unser eigener Mailserver gestartet wurde, können nun die E-Mail-Adressen angelegt werden. Hierzu müssen wir einige Befehle in dem Docker-Container ausführen.
Zunächst muss die E-Mail-Adresse postmaster angelegt werden:
docker exec -ti mailserver setup email add postmaster@meinserver.de meinSuperGeheimesPasswort123Weitere Adressen werden nach dem gleichen Schema angelegt:
docker exec -ti mailserver setup email add kontakt@meinserver.de meinZweitesSuperGeheimesPasswort321Darüber hinaus können auch E-Mail-Weiterleitungen festgelegt werden. Dieses Beispiel bewirkt, dass alle E-Mails die an hallo@meinserver.de gesendet werden, an kontakt@meinserver.de weitergeleitet werden.
docker exec -ti mailserver setup alias add hallo@meinserver.de kontakt@meinserver.deDomain richtig konfigurieren
Damit unser Mailserver E-Mails korrekt senden und empfangen kann, müssen wir unsere Domain entsprechend konfigurieren.
rDNS
Der Server, auf dem der Mailserver betrieben wird, sollte eine Möglichkeit bieten, einen rDNS-Eintrag zu setzen. Dies bewirkt, dass über die IP-Adresse des Server auch unsere Domain ermittelt werden kann.
Bei Netcup findet sich diese Option in eurem Hosting-Produkt unter dem Reiter rDNS:
Dort tragen wir als Hostnamen die Domain unseres Servers ein.
DNS-Einträge erstellen
Jede Domain besitzt sogenannte DNS-Einträge. Diese lassen sich über den eigenen Hoster konfigurieren.
Bei Netcup befindet sich diese Option in den Einstellungen eurer Domain unter DNS.
MX-Eintrag
Um anderen Servern mitzuteilen, wo unser Mailserver liegt, müssen wir einen MX-Eintrag vornehmen:
- Host: @
- Typ: MX
- Priorität: 10
- Ziel: mail.meinserver.de
A-Eintrag
Die Subdomain mail muss nun ebenfalls noch eingetragen werden:
- Host: mail
- Typ: A
- Ziel: IP-Adresse des Servers
SPF-Eintrag
Der SPF-Eintrag ist eine Sicherheitsmaßnahme und teilt anderen Mailservern mit, dass wir auch wirklich die Berechtigung haben, E-Mails über unsere Domain zu versenden:
- Host: @
- Typ: TXT
- Ziel: v=spf1 a mx ~all
CAA-Eintrag
Dieser Eintrag ist eine weitere Sicherheitsmaßnahme. Er definiert von welchem Zertifizierer unser SSL-/TLS-Zertifikat ausgestellt wird.
- Host: @
- Typ: CAA
- Ziel: 0 issue „letsencrypt.org“
DMARC-Eintrag
Dieser Eintrag informiert andere Mailserver darüber, dass unser Server DKIM und SPF einsetzt. Zudem können wir Berichte über den Missbrauch unserer E-Mail-Adressen empfangen.
- Host: _dmarc
- Typ: TXT
- Ziel: v=DMARC1; p=quarantine; rua=mailto:postmaster@meinserver.de; ruf=mailto:postmaster@meinserver.de; sp=none; ri=86400
DKIM-Eintrag
Mithilfe dieses Eintrages stellen andere Mailserver fest, dass eine E-Mail, die wir versenden, auch wirklich von unserem Server stammt.
Um diesen Eintrag vornehmen zu können, generieren wir zuerst einen DKIM-Schlüssel:
docker exec -ti mailserver setup config dkimDann sollte ein Text, der in etwa so aussieht, auf der Kommandozeile ausgegeben werden (verkürztes Beispiel):
v=DKIM1; k=rsa; p=gef2EmXQlgtJVSv/JKL3mTGRZcIYT8+ww2BRduuwERQRolxqP1/pvvAmYOvTsOSJeMhDuexXzyQ9ls87==Diesen riesigen Text müssen wir nun ebenfalls als DNS-Eintrag hinterlegen:
- Host: mail._domainkey
- Typ: TXT
- Ziel: v=DKIM1; k=rsa; p=gef2EmXQlgtJVSv/JKL3mTGRZcIYT8+ww2BRduuwERQRolxqP1/pvvAmYOvTsOSJeMhDuexXzyQ9ls87==
DNS-Einträge übernehmen
Zu guter letzt darf natürlich nicht vergessen werden, die vorgenommenen DNS-Einstellungen zu speichern. Nach der Speicherung dauert es wieder bis zu einer Stunde, bis die Einstellungen übernommen wurden.
Sobald die Änderungen aktiv sind, können mit dem Mailserver bereits problemlos E-Mails gesendet und empfangen werden.
Mailserver nutzen und testen
IMAP und SMTP
E-Mails können ganz einfach per IMAP von unserem E-Mail-Server abgeholt werden und per SMTP versendet. Im eigenen E-Mail-Programm (z.B. Thunderbird) findet der Login ganz normal mit einer bereits erstellen E-Mail-Adresse sowie dem dazugehörigen Passwort statt.
Sollte das E-Mail-Programm auf der eigenen Domain (wie z.B. meinserver.de) keine IMAP/SMTP-Dienste finden, kann als Server auch imap.meinserver.de bzw. smtp.meinserver.de eingetragen werden. Diese Subdomains haben wir eigentlich nicht explizit erstellt. Der Host, den wir in unserem MX-Eintrag als @ eingetragen haben, fungiert als ein Wildcard. Dies bedeutet also, dass unser Mailserver unter jeder Subdomain unserer Domain lauscht.
Fordert das E-Mail-Programm einen Benutzernamen, entspricht dieser einfach der E-Mail-Adresse.
Korrekte Konfiguration des Mailservers testen
Damit wir sicherstellen können, dass wir unseren Mailserver korrekt installiert und konfiguriert haben, lassen wir die Qualität unser versendeten E-Mails bewerten. Auf der Webseite mail-tester.com erhalten wir eine E-Mail angezeigt, an die wir unsere Test-E-Mail senden werden. Wir schreiben zudem ein paar wenige Worte in den Betreff und den Inhalt der E-Mail und senden diese ab.
Klicken wir nun auf den Button der Webseite, sollte bei korrekter Einstellung unsere Test-E-Mail mit einem Score von 10 von 10 bewertet werden.
Wenn du deinen Mailserver erfolgreich mit Docker installiert hast, ist es wichtig, dass du ihn auch regelmäßig aktualisierst, um Sicherheitslücken zu schließen und die Performance zu verbessern. Um diesen Prozess zu automatisieren, kannst du dir den Beitrag Docker Container automatisch aktualisieren anschauen.
Quellen
https://github.com/docker-mailserver/docker-mailserver
Updates
20.09.2023: Anleitung auf Docker-Mailserver Version 12 geupdatet; Verwendung von rspamd
Hallo Christian,
eine super Anleitung hast du dort geschrieben. Mit deiner Hilfe bin ich jetzt weiter gekommen als je zuvor. Einzig alleine die DKIM Geschichte verursacht noch Probleme. Hier passen meine Schlüssel nicht überein.
Schöner Blog. Weiter so.
Moin PixelTrace,
wie genau meinst du, dass die Schlüssel nicht passen?
Wenn der Kommandozeilenbefehl zur Generierung der DKIM-Keys ausgeführt wird, muss bereits ein E-Mail-Konto bestehen. Diese Reihenfolge wird mit dem Tutorial aber eigentlich auch eingehalten.
Ist der DNS-Eintrag korrekt gesetzt?
Viele Grüße!
Hallo, schöne, übersichtliche Anleitung.
Mein Webmailer quittiert mir den Sende-Versuch mit:
Das Senden der Nachricht an folgende Empfänger ist fehlgeschlagen: [„…“ ] (550 – 550 5.1.1 host v2202112163575172935.hotsrv.de [185.232.70.86] said: : Recipient address rejected: User unknown in local recipient table (H-BADRCPT)
)
Der User/Empfänger wurde aber auf dem Mail-Server korrekt angelegt.
Weiß jemand was da falsch läuft?
Für mich klingt das so, als ob der Mailserver nicht gefunden wird.
Kannst du mal folgendes kontrollieren:
– Deine DNS Records
– Ist in deiner docker-compose.yml „hostname“ korrekt gesetzt?
Falls beides korrekt eingestellt ist, versuch mal folgendes:
Suche in der mailserver.env nach dem Eintrag „OVERRIDE_HOSTNAME“. Falls nicht vorhanden, einfach hinzufügen.
Sollte dann in etwa so aussehen: OVERRIDE_HOSTNAME=meinedomain.de
Danke, sehr schöne und gut strukturierte Anleitung.
Alle Schritte haben soweit funktioniert.
Super Tutorial.
Ich habe die Zertifikatsgeschichte etwas anders gelöst, trotzdem hat alles super funktioniert! 🙂
Weiter so
Hallo Christian,
danke für Deine ausführliche und klare Anleitung. Ich habe sie mit der gegenwärtigen Version 12.1 ausgeführt und leider scheine ich ein ähnliches Problem zu haben, wie es der User „Jan“ beschreibt. Wenn ich mit einem anderen Mailaccount an postmaster@.de ein Mail zustellen will, kommt ein 550 Unknown user. Ich kann aber mit den Setup-Script die User auflisten, da erscheint dann der postmaster-Account. Auch das Verzeichnis für die Mailbox ist angelegt.
Das nächste Phänomen ist, dass der Docker-Mailserver via Port 465 ein Mail an einen anderen Account annimmt. Das Protokoll z.B. in Thunderbird zeigt einen vollständigen Ablauf zum Abliefern des Mails. Das Mail kommt aber nie an der Zieladresse an.
Ich habe, wie von Dir vorgeschlagen, OVERRIDE_HOSTNAME definiert, aber das hat ebenso nichts gebracht. Nun wäre die Frage, ob sich seit der V. 10.x, die Du benutzt hast, etwas geändert hat, das ich vielleicht berücksichtigen muss.
Beste Grüße
MM
Moin!
Versuch mal bitte in der mailserver.env „SPOOF_PROTECTION“ abzuändern auf:
SPOOF_PROTECTION=
Ich aktualisiere die Anleitung gerade auch, da sie mit der neuen Version nicht mehr reibungslos funktioniert.
Viele Grüße!
Danke für die gute Anleitung. Ich hatte ein Problem beim eigenen Setup: „setup config dkim“ legt zwar /etc/rspamd.d/override.d/dkim_signing.conf an, aber nicht eine entsprechende Datei unter /tmp/docker-mailserver/rspamd/override.d. Nach dem Neustart des Containers wurden deshalb keine Signaturen mehr erzeugt.
Versuch mal folgendes unter deinen Volumes in der docker-compose.yml mit aufzunehmen:
– ./docker-data/dms/config/rspamd/override.d/:/etc/rspamd/override.d/
Gib gerne bescheid ob das funktioniert, dann nehme ich das mit in den Beitrag auf.
Laut Dokumentation von Docker-Mailserver sollte der Inhalt von /tmp/docker-mailserver/rspamd/override.d/ automatisch in /etc/rspamd.d/override.d/ landen, was es anscheinend nicht tut.
Danke!
Korrektur:
„`
Konfigurationsdateien herunterladen
Nun besorgen … aus …
wget „https://raw.githubusercontent.com …
########## —>
chmod a+x ./setup.sh
########## <—
„`
###
Das manuelle Script wird nicht mehr benötigt, sondern ist direkt im Docker-Container zu finden. Ich habe die Anleitung entsprechend aktualisiert.
„E-Mail-Adressen anlegen:
Nachdem im vorherigen Schritt unser eigener Mailserver gestartet wurde, können nun die E-Mail-Adressen angelegt werden. Hier kommt das zu Beginn heruntergeladene Skript setup.sh zum Einsatz.“
Ich habe diese Anleitung nun 4 mal durchgelesen, und finde kein setup.sh, die in der Anleitung angelegt wurde.
Könnte mir das jemand erklären?
Ich hatte die Anleitung vor einigen tagen angepasst und das wohl übersehen. Habe ich korrigiert, danke!
Im Abschnitt „E-Mail-Adressen anlegen“ sind nun die aktualisierten Befehle zu finden.
Eine Super Anleitung aber mit einem Bösen Bug.
Der certbot Container läuft einmal an, besorgt sich die Zertifikate und beendet sich danache.
Die Dockerengine sorgt für einen Restart nach 100ms, danach nach 200ms, 400ms, 800ms usw. bis max. 1 Minute und ab dann immer wieder nach einer Minute.
Der Zertbot wird also regelmäßig gestartet und das immer mit dem Parameter –force-renewal.
Hier spielt aber let’s Encrypt nach dem 10 Mal nicht mehr mit und es kommt die Fehlermeldung dass man zu viele Anfragen in den vergangenen 168 Stunden gemacht hat.
Besser ist es den Parameter –keep-until-expiring zu nutzen.
Macht man das nicht, wird man nach Ablauf des Zertifikates kein neues bekommen, weil man sich auf Grund der häufigen renews bei let’s Encrypt permanent selber aussperrt.
Danke für die Korrigierung! Das war mir gar nicht aufgefallen.
Bis jetzt habe ich zwar immer ein neues Zertifikat bekommen, werde das aber direkt anpassen.
Eine super Anleitung – vielen Dank dafür!
Ein Problem habe ich allerdings noch.
Bei mir klappt die DKIM-Signierung von ausgehenden Mails nicht. Und ich finde einfach nicht heraus, woran es liegt.
Eine /tmp/docker-mailserver/rspamd/override.d/dkim_signing.conf mit Inhalt ist vorhanden, das habe ich auf der Console des Containers geprüft. Das Schlüsselmaterial liegt auch unter /tmp/docker-mailserver/rspamd/dkim/.
Eingehend prüft rspamd alles prima.
Was sollte ich noch prüfen, bzw. wie kann ich am besten debuggen?
Viele Grüße
Daniel
Moin Daniel,
ist dein DNS-Eintrag korrekt gesetzt?
Ist eventuell der domainkey bei dir anders?
Mach mal ein cat auf die xxx-domain.de.public.txt, die im ../rspamd/dkim/ Ordner liegt.
Sollte im Standardfall sowas sein wie: mail._domainkey.
Das ist dann auch der Text, der in deinem TXT-Eintrag im DNS unter „Host“ kommt.
Den „Ziel“-Teil kannst du dir nochmal korrekt formatiert aus der die xxx-domain.de.public.dns.txt kopieren.
Viele Grüße!
Hallo Christian,
vielen Dank für das schnelle Feedback!
Meiner Meinung nach passt das alles.
Ich habe mal ein paar Daten zusammengesammelt. Nur an den Stellen wo hier „meinemaildomain“ steht, steht bei mir natürlich meine wirkliche Maildomain. Die wollte ich hier nicht unbedingt öffentlich posten.
außerhalb des Containers:
root@vserver:/data/docker-container/mailserver# dig +short -t TXT 2023-11._domainkey.meinemaildomain.srv64.de
„v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr8mOWmr/emYRQ5PiCRXlNVMxsOkS39bZPVXtXS74DXqiDwKCb4VfUPYhMLsdTKNlM3HHOk5ly48SuM0+Y9i1ckpEH2zuny6qWaZhqSdxQnRcOJCyQOsX9mO5lSvHovdn6P/re3aDHwKtZwhXPeZhRKzzSSuq3JWP+AIQIXm91ibCLymCsMq2gP+8Gv5SnnZB1“ „UcQ7ixVf6nRGs/7Nxr8nkIU/AY3O7PCtn4GqQjZZ9hELabkkbN9Xj5mz1saPR5y5BVM73e5Kb4j6lYA9KSDJAghbetimxw7GG2afP06Ov+6RC2b+nZufVFt2EwQekN57BSII4c6IGYcoAULD+0ehQIDAQAB“
—————————————————————————————————-
root@vserver:/data/docker-container/mailserver# docker exec -ti mailserver /bin/bash
innerhalb des Containers:
root@mail:/# ls -l /tmp/docker-mailserver/rspamd/dkim/
total 12
-rw-r—– 1 _rspamd _rspamd 1704 Nov 16 14:56 rsa-2048-2023-11-meinemaildomain.srv64.de.private.txt
-rw-r–r– 1 root root 411 Nov 16 14:56 rsa-2048-2023-11-meinemaildomain.srv64.de.public.dns.txt
-rw-r–r– 1 root root 454 Nov 16 14:56 rsa-2048-2023-11-meinemaildomain.srv64.de.public.txt
—————————————————————————————————-
root@mail:/# cat /tmp/docker-mailserver/rspamd/dkim/rsa-2048-2023-11-meinemaildomain.srv64.de.public.txt
2023-11._domainkey IN TXT ( „v=DKIM1; k=rsa; “
„p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr8mOWmr/emYRQ5PiCRXlNVMxsOkS39bZPVXtXS74DXqiDwKCb4VfUPYhMLsdTKNlM3HHOk5ly48SuM0+Y9i1ckpEH2zuny6qWaZhqSdxQnRcOJCyQOsX9mO5lSvHovdn6P/re3aDHwKtZwhXPeZhRKzzSSuq3JWP+AIQIXm91ibCLymCsMq2gP+8Gv5SnnZB1UcQ7ixVf6nRGs/7N“
„xr8nkIU/AY3O7PCtn4GqQjZZ9hELabkkbN9Xj5mz1saPR5y5BVM73e5Kb4j6lYA9KSDJAghbetimxw7GG2afP06Ov+6RC2b+nZufVFt2EwQekN57BSII4c6IGYcoAULD+0ehQIDAQAB“
) ;
—————————————————————————————————-
root@mail:/# cat /tmp/docker-mailserver/rspamd/override.d/dkim_signing.conf
# documentation: https://rspamd.com/doc/modules/dkim_signing.html
enabled = true;
sign_authenticated = true;
sign_local = true;
use_domain = „header“;
use_redis = false; # don’t change unless Redis also provides the DKIM keys
use_esld = true;
check_pubkey = true; # you wan’t to use this in the beginning
domain {
meinemaildomain.srv64.de {
path = „/tmp/docker-mailserver/rspamd/dkim/rsa-2048-2023-11-meinemaildomain.srv64.de.private.txt“;
selector = „2023-11“;
}
}
—————————————————————————————————-
root@mail:/# ls -l /etc/rspamd/
total 88
-rw-r–r– 1 root root 1213 Mar 19 2023 actions.conf
-rw-r–r– 1 root root 365 Mar 19 2023 cgp.inc
-rw-r–r– 1 root root 1318 Mar 19 2023 common.conf
-rw-r–r– 1 root root 6607 Mar 19 2023 composites.conf
-rw-r–r– 1 root root 5154 Mar 19 2023 groups.conf
drwxr-xr-x 1 root root 4096 Nov 18 16:11 local.d
-rw-r–r– 1 root root 1186 Mar 19 2023 logging.inc
drwxr-xr-x 2 root root 4096 May 3 2023 maps.d
-rw-r–r– 1 root root 921 Mar 19 2023 metrics.conf
-rw-r–r– 1 root root 703 Mar 19 2023 modules.conf
drwxr-xr-x 2 root root 4096 May 3 2023 modules.d
-rw-r–r– 1 root root 2020 Mar 19 2023 options.inc
lrwxrwxrwx 1 root root 41 Nov 18 16:11 override.d -> /tmp/docker-mailserver/rspamd/override.d/
-rw-r–r– 1 root root 2523 Mar 19 2023 rspamd.conf
drwxr-xr-x 2 root root 4096 May 3 2023 scores.d
-rw-r–r– 1 root root 1799 Mar 19 2023 settings.conf
-rw-r–r– 1 root root 2169 Mar 19 2023 statistic.conf
-rw-r–r– 1 root root 618 Mar 19 2023 worker-controller.inc
-rw-r–r– 1 root root 654 Mar 19 2023 worker-fuzzy.inc
-rw-r–r– 1 root root 525 Mar 19 2023 worker-normal.inc
-rw-r–r– 1 root root 1363 Mar 19 2023 worker-proxy.inc
—————————————————————————————————-
root@mail:/# ps -ef | grep rspamd
root 568 7 0 16:11 ? 00:00:01 rspamd: main process
_rspamd 670 568 0 16:11 ? 00:00:00 rspamd: rspamd_proxy process (127.0.0.1:11332)
_rspamd 671 568 0 16:11 ? 00:00:00 rspamd: rspamd_proxy process (127.0.0.1:11332)
_rspamd 672 568 0 16:11 ? 00:00:00 rspamd: controller process (0.0.0.0:11334)
_rspamd 673 568 0 16:11 ? 00:00:00 rspamd: hs_helper process
root 2313 2293 0 16:26 pts/0 00:00:00 grep rspamd
Der rspamd läuft also und lauscht auch auf 127.0.0.1:11332.
Bei eingehenden Mails sind auch entsprechende Header-Zeilen zu sehen.
Kann man dem rspamd noch irgendwie Log-Informationen entlocken? Wenn ich eine Mail sende, ist in /var/log/mail.log nichts vom rspamd zu sehen. Auch das Verzeichnis /var/log/rspamd/ ist leer.
An welchem Punkt der Verarbeitungskette einer ausgehenden Mail (von Thunderbird via Port 587 übergeben) erfolgteigentlich die DKIM-Signierung durch den rspamd?
Grüße
Daniel
Moin Daniel,
für mich sieht das auch alles richtig aus.
Spontan paar Sachen die mir jetzt einfallen:
– Prüfen ob in der mailserver.env ENABLE_OPENDKIM=0 steht.
– Prüfen ob dein DNS Selector auch 2023-11 ist.
– Container einmal komplett runterfahren und wieder starten.
Das rspamd-Log-Verzeichnis ist bei mir auch leer. Anscheinend landen die Logs (entgegen der Informationen aus der Doku) hier: /var/log/supervisor/rspamd.log
Das Log-Level könntest du versuchen in der mailserver.env hochzuschreiben mit LOG_LEVEL=trace.
Die Signierung findet meines Verständnisses nach statt, sobald der SMTP-Server (in diesem Fall Postfix) seinen Krams geprüft hat und kurz bevor die Mail an den Empfänger-SMTP-Server sendet.
Sollte das alles passen bin ich auch etwas überfragt.
Hi Christian,
danke für den Hinweis auf das Logfile des rspamd.
Da habe ich jetzt tatsächlich was gefunden:
2023-11-18 23:14:58 #671(rspamd_proxy) ; proxy; dkim_module_load_key_format: cannot load dkim key /var/lib/rspamd/dkim/srv64.de.dkim.key: cannot stat key file: ‚/var/lib/rspamd/dkim/srv64.de.dkim.key‘ No such file or directory
Ich werde der Sache mal nachgehen.
Eigenartig, was er da sucht – sowohl das Directory als auch der Key selbst scheinen mir irgendwie komisch.
Was meinst Du?
Grüße
Daniel
Ich habe jetzt auch noch folgendes probiert:
root@vserver:/data/docker-container/mailserver# docker exec -ti mailserver rspamadm configdump dkim_signing
*** Section dkim_signing ***
try_fallback = true;
use_redis = false;
key_prefix = „DKIM_KEYS“;
check_pubkey = true;
use_domain = „header“;
allow_hdrfrom_mismatch = false;
allow_username_mismatch = false;
sign_authenticated = true;
domain {
meinemaildomain.srv64.de {
path = „/tmp/docker-mailserver/rspamd/dkim/rsa-2048-2023-11-meinemaildomain.srv64.de.private.txt“;
selector = „2023-11“;
}
}
enabled = true;
use_esld = true;
sign_networks [
„127.2.4.7“,
]
symbol = „DKIM_SIGNED“;
allow_envfrom_empty = true;
allow_hdrfrom_multiple = false;
selector = „dkim“;
sign_local = true;
*** End of section dkim_signing ***
Das sieht doch eigentlich auch danach aus, als wenn rspamd wissen müsste, wo für meine Domain Keys etc. zu suchen sind.
Trotzdem sucht er irgendwas in /var/lib/rspamd… Komisch.
Hast du mal die Berechtigungen der einzelnen Dateien geprüft? Bei mir sehen die wie folgt aus:
root@mailserver:~/mailserver/docker-data# ls -la dms/config/rspamd/total 16
drwxr-xr-x 4 root root 4096 Oct 21 14:53 .
drwxrwxrwx 4 root root 4096 Nov 18 17:05 ..
drwxr-xr-x 2 113 115 4096 Oct 21 14:53 dkim
drwxr-xr-x 2 root root 4096 Oct 21 14:53 override.d
root@mailserver:~/mailserver/docker-data# ls -la dms/config/rspamd/dkim/
total 32
drwxr-xr-x 2 113 115 4096 Oct 21 14:53 .
drwxr-xr-x 4 root root 4096 Oct 21 14:53 ..
-rw-r--r-- 1 113 115 89 Oct 21 14:53 ed25519-dkim-ed25519-christianeirich.de.private.txt
-rw-r--r-- 1 root root 67 Oct 21 14:53 ed25519-dkim-ed25519-christianeirich.de.public.dns.txt
-rw-r--r-- 1 root root 110 Oct 21 14:53 ed25519-dkim-ed25519-christianeirich.de.public.txt
-rw-r----- 1 113 115 3272 Oct 21 14:53 rsa-4096-dkim-rsa-christianeirich.de.private.txt
-rw-r--r-- 1 root root 755 Oct 21 14:53 rsa-4096-dkim-rsa-christianeirich.de.public.dns.txt
-rw-r--r-- 1 root root 803 Oct 21 14:53 rsa-4096-dkim-rsa-christianeirich.de.public.txt
root@mailserver:~/mailserver/docker-data# ls -la dms/config/rspamd/override.d/
total 12
drwxr-xr-x 2 root root 4096 Oct 21 14:53 .
drwxr-xr-x 4 root root 4096 Oct 21 14:53 ..
-rw-r--r-- 1 113 115 488 Oct 21 14:53 dkim_signing.conf
Die Key-Länge für die Signierung mit RSA habe ich manuell hochgesetzt, also nicht verwundern lassen.
Versuch mal in deine Volumes der docker-compose folgendes mit aufzunehmen:
- ./docker-data/dms/config/rspamd/override.d/:/etc/rspamd/override.d/Könnte sein, dass deine Config nicht im korrekten Ordner landet.
Hallo Christian,
ich bekomme es einfach nicht hin. 🙁
Das „- ./docker-data/dms/config/rspamd/override.d/:/etc/rspamd/override.d/“ hat tatsächlich bewirkt, dass beim „docker exec -ti mailserver setup config dkim keytype rsa keysize 2048 selector 202311 ….“ eine entsprechende /docker-data/dms/config/rspamd/override.d/dkim_signing.conf mit Inhalt angelegt wird. Auch kommt beim Erzeugen des Schlüsselmaterials der Hinweis, dass rspamd gestoppt und wieder gestartet wird.
Allerdings scheint die dkim_signing.conf mit ihrem Inhalt vom rspamd keinerlei Berücksichtigung zu finden.
Im Log kommt auch nach wie vor die Fehlermeldung „….proxy; dkim_module_load_key_format: cannot load dkim key /var/lib/rspamd/dkim/srv64.de.dkim.key: cannot stat key file: ‚/var/lib/rspamd/dkim/srv64.de.dkim.key‘ No such file or directory“.
Ich weiß nicht, warum er sowas da sucht. in der dkim_signing.conf steht im domain {}-Block u.a. „path = „/tmp/docker-mailserver/rspamd/dkim/rsa-2048-202311-meinemaildomain.srv64.de.private.txt“;“.
Was mich noch wundert ist, dass im Container unter /etc/rspamd/local.d/ keine dkim_signing.conf mit Default-Werten vorhanden ist, wie z.B. hier beschrieben: https://rspamd.com/doc/modules/dkim_signing.html .
Unter /etc/rspamd/modules.d/ gibt es eine dkim_signing.conf, die u.a. ein .include(try=true,priority=10) „$LOCAL_CONFDIR/override.d/dkim_signing.conf“ enthält. Das sollte doch eigentlich dazu dienen, die Daten unter override.d einzubinden, oder?
Ich weiß echt nicht mehr weiter.
Werden deine E-Mails eigentlich ordentlich signiert?
Viele Grüße
Daniel
Moin Daniel,
es kann sein, dass im Ordner /etc/rspamd/local.d/ keine dkim_signing.conf vorhanden ist, da dies evtl. im Docker-Image angepasst wird.
Genau, die dkim_singing.conf aus dem Ordner override.d sollte im Normalfall eingebunden werden, wie es ja auch bei dir der Fall ist.
Meine E-Mails werden korrekt signiert mit zudem 10/10 Score von mail-tester.com.
Wenn du magst kannst du mir deine Config-Files per Mail zukommen lassen. Dann könnte ich da mal einen Blick drauf werfen.
Viele Grüße,
Christian
Hurra, es funktioniert – ich konnte das Problem lösen. 🙂
Ich habe mir die ganzen Konfigurationsparameter hier nochmal genau angesehen: https://rspamd.com/doc/modules/dkim_signing.html
In meinem Fall lag das Problem darin, dass ich nicht nur Toplevel- und Organisational-Domain (srv64.de) sondern auch noch eine Subdomain (meinemaildomain) verwende.
Beim rspamd ist wohl per default ein „use_esld = true;“ eingestellt.
Das sorgt meinem Verständnis nach dafür, dass bei einer ausgehenden Mail mit Absenderdomain „meinemaildomain.srv64.de“ auf „srv64.de“ gekürzt wird. Für „srv64.de“ gibt’s aber (im domain {} -Block) meiner …/rspamd/override.d/dkim_signing.conf keine Einstellung.
Ein per default gültiges „try_fallback = true;“ hat dann wohl zusätzlich dafür gesorgt, dass rspamd einen default-Key in /var/lib/rspamd/dkim/ gesucht hat. Den gibt’s natürlich im Docker-Container auch nicht. Und das hat dann wohl zusätzlich für oben beschriebene Fehlermeldung „…dkim_module_load_key_format: cannot load dkim key /var/lib/rspamd/dkim/srv64.de.dkim.key: cannot stat key file: ‚/var/lib/rspamd/dkim/srv64.de.dkim.key‘ No such file or directory“ gesorgt.
Meine …/rspamd/override.d/dkim_signing.conf sieht nun so aus:
#######################################################
# documentation: https://rspamd.com/doc/modules/dkim_signing.html
enabled = true;
# Whether to fallback to global config
try_fallback = false;
sign_authenticated = true;
sign_local = true;
# Domain to use for DKIM signing: can be „header“ (MIME From), „envelope“ (SMTP From), „recipient“ (SMTP To), „auth“ (SMTP username) or directly specified domain name
use_domain = „header“;
# Whether to get keys from Redis
use_redis = false; # don’t change unless Redis also provides the DKIM keys
# Whether to normalise domains to eSLD
use_esld = false;
# If `true` get pubkey from DNS record and check if it matches private key
check_pubkey = true;
domain {
meinemaildomain.srv64.de {
path = „/tmp/docker-mailserver/rspamd/dkim/rsa-2048-202311-meinemaildomain.srv64.de.private.txt“;
selector = „202311“;
}
}
#######################################################
Im Header einer versendeten Mail finde ich:
…
Authentication-Results: …….;
dkim=pass (2048-bit key; unprotected) header.d=meinemaildomain.srv64.de header.i=@meinemaildomain.srv64.de header.b=“bATeR8YZ“;
dkim-atps=neutral
…
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinemaildomain.srv64.de;
s=202311; t=1700596199;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding;
bh=C5kxYp5kVUm+34Hg+4j9OIPVED0Og3UYszngpf1BAJ4=;
b=bATeR8YZfASUEjWElf7ExY4Xl90DPESe2SaiBwtzPrKasm9D/3AfQnyNpx97aJBIG+AqJb
uh0vSGpE6J6fc6hTHDmmLJhWwijpSt3zeTsVOAbhiWZs6rgX0K3ZiKNUAyXjJ2Fy1fzLK9
mW+c+BWp3pP1MqYPM7J5AkVGRUa+plcU/d8c+XHfjK0Mz7jgiGMj1z6RlttdjytapDyP41
xY6yadFn06EJpABTsfMZSlV1vzCgJxFJsLCYSNNVLVlH3bIfloy8aHBwmlJopjvgbFOvj4
pgzU3z5i6xddfvLp50cbgRfwDd9kmaRtkLc8tIIGzDOUT22vFcXUdNRUHLW4mQ==
…
Also alles gut. 🙂
Vielen Dank nochmal Christian für das stetige schnelle Feedback!
Viele Grüße
Daniel
Hallo Christian,
ich habe nochmal eine Frage zum Mailserver.
Die SSL-Zertifikate werden im Konstrukt mit dem certbot-Container beim Start des Mailservers erstellt.
Allerdings beendet sich dieser dann wieder, wenn er entweder ein neues Zertifikat erstellt oder festgestellt hat, dass eine Erzeugung bzw. Erneuerung nicht notwendig ist.
Wie wird denn dann im Betrieb die Erneuerung eines auslaufenden Zertifikates bewirkt, ohne den Mailserver (bzw. die Docker-Container) neu zu starten?
Viele Grüße
Daniel
Moin Daniel,
Docker-Mailserver lauscht auf den eingebundenen letsencrypt-Ordner und sorgt dann selbst dafür, dass die Zertifikate während des Betriebs ausgetauscht werden.
Viele Grüße,
Christian
Hi Christian,
ja, dass der letsencrypt-Ordner in den Mailserver eingebunden ist, kann ich nachvollziehen.
Eine automatische Erneuerung der Zertifikate kann ich allerdings nicht nachvollziehen.
Wenn man (hier: https://docker-mailserver.github.io/docker-mailserver/latest/config/security/ssl/#lets-encrypt-recommended im Kasten „Renewing Certificates“) nachliest, liest sich das auch so, als wenn beim (Neu-)Start eine Zertifikats-Kontrolle/-Erneuerung erfolgt (WHEN RUNNING the above certonly –standalone snippet AGAIN, the existing certificate is renewed if it would expire within 30 days.) – nicht aber permanent im laufenden Betrieb.
Weiterhin steht dort geschrieben „This process can also be automated via cron or systemd timers.“.
Das würde also noch etwas Handarbeit (regelmäßiger Start des certbot-Containers z.B. via Cron auf dem Host) bedeuten.
Sehe ich das richtig, oder liege ich falsch?
Viele Grüße
Daniel
Hallo Daniel,
Ja, du hast Recht. Es ist tatsächlich so, dass die automatische Erneuerung der Zertifikate beim (Neu-)Start des Containers erfolgt. Ist mir wohl nicht aufgefallen, da ich hin und wieder ein paar Sachen am Mailserver teste und daher die Container neustarte. Ich habe die Möglichkeit mit dem Cronjob in die Anleitung mit aufgenommen.
Danke dir für den Hinweis!
Viele Grüße,
Christian
Hallo Christian,
ich hoffe du (und auch alle anderen hier) haben Weihnachten und Silvester gut überstanden 🙂
Ich habe soweit die Anleitung durchgearbeitet und einen Docker Mailserver ans laufen bekommen leider funktionieren zwei Sachen aktuell noch nicht. Siehe folgende Auflistung:
1.) Beim versenden einer Mail an meine Uni Mail Adresse erhalte ich den Fehler: „Domain of sender address does not exist“
2.) Beim versenden an meine GMail Adresse erhalte ich dagegen: „This mail has been blocked because the sender is
unauthenticated. 550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.“
Ich habe das ganze dann mal überprüft mit „https://mxtoolbox.com/emailhealth“ und bekomme dort folgende Liste an Fehlern:
„smtp mail.foo.com.foo.com Failed To Connect information More Info“
„smtp mail.foo.com.foo.com Problem getting IP Address for mail.foo.com.fooptifly.com information More Info“
„http foo.com Unable to connect to the remote server (http://foo.com)“
Wieso an der Stelle „mail.foo.com.foo.com“ angezeigt wird kann ich mir beim besten willen nicht erklären…
Anbei noch meine DNS Einstellungen :
$ORIGIN foo.com.
$TTL 86400
; SOA Records
@ IN SOA hydrogen.ns.hetzner.com. dns.hetzner.com. 2024010111 86400 10800 3600000 3600
; NS Records
@ IN NS helium.ns.hetzner.de.
@ IN NS hydrogen.ns.hetzner.com.
@ IN NS oxygen.ns.hetzner.com.
; MX Records
@ IN MX 10 mail.foo.com
; A Records
@ IN A
mail IN A
; TXT Records
@ IN TXT „v=spf1 a mx ~all“
_dmarc IN TXT „v=DMARC1; p=quarantine; rua=mailto:foo@foo.com; ruf=mailto:foo@foo.com; sp=none; ri=86400“
mail._domainkey IN TXT „v=DKIM1; k=rsa; p=…“ „..“
; Others
@ IN CAA 0 issue „letsencrypt“
Vielleicht kannst du mir ja weiterhelfen 🙂
Gruß
Philipp
Moin Philipp,
danke! Deine DNS-Einstellungen sehen für mich korrekt aus. Die IP hast du vermutlich bewusst weggelassen?
Hast du für deinen Hetzner-Server auch die entsprechenden Ports entsperren lassen? 🙂
Hetzner hat nämlich 25 und 465 standardmäßig blockiert, um gegen Spammer vorzugehen.
Mehr dazu findest du hier: https://docs.hetzner.com/de/cloud/servers/faq/#warum-kann-ich-keine-mails-von-meinem-server-verschicken
Das Problem hatte ich bei Hetzner auch schon mal.
Viele Grüße,
Christian
Hi Christian,
erstmal vielen Dank für deine Antwort.
Ja richtig die IP habe ich bewusst weg gelassen. Nach Rücksprache mit dem Hetzner Support ist es so das Port 25/465 bei mir nicht blockiert sind da ich schon seit mehr als einem Monat Kunde bin.
Bis jetzt habe ich leider immer noch keine Lösung für das Problem gefunden 🙁
Hallo,
auch meinerseits an euch noch alles Gute im neuen Jahr!
@Philip:
Irgendwas stimmt da scheinbar generell mit deiner Absenderadresse (bzw. Absenderdomain) nicht.
Was genau ist denn deine Absenderdomain bzw. soll die Absenderdomain sein? Ist das @foo.com?
Google lehnt deine Mail ab, weil für die Absenderdomain der empfangenen Mail im DNS weder SPF- noch DKIM-Record hinterlegt sind.
Wenn ich im DNS mal nach dem SPF Record schaue (falls es um die Domain foo.com geht) bekomme ich:
▪ dig +short -t TXT foo.com
„v=spf1 -all“
Das ist hier natürlich kein nützlicher SPF-Record. Da bekommt der empfangende Mailserver keinerlei Infos über IP-Adressen die berechtigt sind, als @foo.com zu senden.
Hast Du die DKIM-Signierung mit eingerichtet?
Und deine Uni lehnt die Mail ab, weil die Absenderdomain scheinbar nicht existiert – ich denke mal, weil es keinen MX-Record im DNS gibt.
▪ dig +short -t MX foo.com
1000 0.0.0.0.
Hast Du mal im Logfile deines Mailservers geschaut, was der da beim Absenden genau macht?
Wie genau (welche Befehle) hast Du deine E-Mail Adresse(n) eingerichtet?
Was ergibt ein
▪ docker exec -ti mailserver setup email list
bei dir (anstelle „mailserver“ den Namen deines Docker Containers eingeben)?
Grüße
Daniel
Hallo Daniel,
auch dir erstmal vielen Dank für deine Antwort 🙂
Die Adresse „foo.com“ ist hier nur als Platzhalter verwendet. SPF und DKIM habe ich eingerichtet auch habe ich den MX-Record im DNS eingetragen dieser kann auch reverse aufgelöst werden.
Wenn ich eine EMail versende erhalte im Docker Ausschrieb folgende Meldung: “ 18B885FCFF: to=, relay=none, delay=8, delays=0/0/8/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=tu-dortmund.de type=MX: Host not found, try again)“
Das von dir beschriebene Docker Command zeigt mir genau die Mail Adresse an welche ich im Docker Mailserver angelegt habe und mit welcher ich mich auch im Thunderbird anmelden kann.
Hallo Philipp,
ah, das mit der Domain hatte ich mir schon fast gedacht, weil man dieses „foo“ ja oft als Beispiel nutzt. Aber man weiß ja nie. 😉
In deinem Logfile-Auszug sieht es so aus, als wenn der DNS des Mailserver Containers nicht richtig funktioniert.
Du kannst ja mal schauen, ob DNS im Container generell funktioniert.
–> auf die Shell des Containers verbinden:
▪ docker exec -ti mailserver bash
–> dann im Container den DNS prüfen:
root@mail:/# dig +short -t MX tu-dortmund.de
10 esa3.itmc.tu-dortmund.de.
10 esa4.itmc.tu-dortmund.de.
–> Das „+short“ kannst Du auch weglassen. Dann gibt das dig Kommando ein paar mehr Ausgaben.
Mich wundert es allerdings, dass dann bei deinem ersten Post scheinbar zumindest eine Mail-Übergabe an Google versucht wurde.
Der für Google zuständige Mailserver konnte wohl demnach im DNS aufgelöst werden.
Notfalls müsstest Du mal ein paar mehr Logdaten posten. Die (Absender- und Empfänger-E-Mail bzw. IP-Adressen) kannst Du ja wieder anonymisieren.
Ich habe bei mir mal eine Mail versendet und dann im Log auf relevante Anteile gefiltert:
▪ grep 80EF612E673F: mail.log
Jan 11 09:37:27 mail postfix/submission/smtpd[428993]: 80EF612E673F: client=abc123def.dip0.t-ipconnect.de[84.173.123.123], sasl_method=PLAIN, sasl_username=mail@meinedomain.de
Jan 11 09:37:27 mail postfix/sender-cleanup/cleanup[428994]: 80EF612E673F: message-id=
Jan 11 09:37:27 mail postfix/sender-cleanup/cleanup[428994]: 80EF612E673F: replace: header MIME-Version: 1.0 from abc123def.dip0.t-ipconnect.de[84.173.123.123]; from= to= proto=ESMTP helo=: MIME-Version: 1.0
Jan 11 09:37:27 mail postfix/qmgr[1034]: 80EF612E673F: from=, size=366, nrcpt=1 (queue active)
Jan 11 09:37:27 mail postfix/smtp-amavis/smtp[429000]: 80EF612E673F: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=0.41, delays=0.22/0.01/0.01/0.17, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as D392412E6705)
Jan 11 09:37:27 mail postfix/qmgr[1034]: 80EF612E673F: removed
▪ grep D392412E6705 mail.log
Jan 11 09:37:27 mail postfix/smtpd-amavis/smtpd[429003]: D392412E6705: client=localhost[127.0.0.1]
Jan 11 09:37:27 mail postfix/cleanup[428715]: D392412E6705: message-id=
Jan 11 09:37:27 mail postfix/qmgr[1034]: D392412E6705: from=, size=1235, nrcpt=1 (queue active)
Jan 11 09:37:27 mail amavis[285963]: (285963-12) Passed CLEAN {RelayedOpenRelay}, [84.173.123.123]:46478 [84.173.123.123] -> , Queue-ID: 80EF612E673F, Message-ID: , mail_id: ba9afuOg5HnK, Hits: -, size: 1035, queued_as: D392412E6705, 170 ms
Jan 11 09:37:27 mail postfix/smtp-amavis/smtp[429000]: 80EF612E673F: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=0.41, delays=0.22/0.01/0.01/0.17, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as D392412E6705)
Jan 11 09:37:35 mail postfix/smtp[429004]: D392412E6705: to=, relay=mail.zieldomain.de[173.123.12.55]:25, delay=7.3, delays=0.01/0.02/6.5/0.81, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 956088A23ED)
Jan 11 09:37:35 mail postfix/qmgr[1034]: D392412E6705: removed
Via postfix-submission kommt die Mail vom Thunderbird rein und geht an den ersten Postfix.
Sie geht dann vom ersten Postfix, wenn Amavis seine Arbeit getan hat, lokal zum zweiten Postfix (relay=127.0.0.1[127.0.0.1]:10024).
Der zweite Postfix liefert sie an den Zielserver aus (relay=mail.zieldomain.de[173.123.12.55]:25).
Grüße
Daniel
Hi Daniel,
vielen Dank für Antwort 🙂
Versenden an meine Uni Mail Adresse funktioniert immer noch nicht (aber egal). Der Versand an Google funktioniert jetzt aber 😉
Ich weiß nicht wieso aber die Konfiguration bei Hetzner DNS ist merkwürdig… Der MX Record wurde immer auf „mail.foo.mail.foo.com“ aufgelöst !?
Naja nachdem ich das gefixt habe scheint es jetzt zu funktionieren 🙂
Kann man auch mehrere Domains hinterlegen z.B. xyz.de zyx.org um damit Emailadressen abzulegen?
Ja das geht. Dazu einfach ein neues Postfach anlegen oder einen Alias auf ein anderes Postfach.
Die Syntax dazu wird dir angezeigt wenn du folgendes in die Kommandozeile eingibst: docker exec -it CONTAINERNAME setup help
Dann muss der MX-Eintrag der zweiten Domain einfach auf den der „Haupt-Domain“ zeigen.
Christian, Du hast den Containernamen im Kommando vergessen. Es müsste „docker exec -ti containername setup help“ lauten. Bzw. anstelle des Containernamen die Container-ID.
Ja, mein Mailserver ist auch mit Postfächern verschiedener Domains konfiguriert, da ich z.B. die Mailboxen meines Sohnes auch darauf hoste.
Einfach mit dem Setup-Kommando weitere E-Mail Adressen anlegen. Bei neuen Domains entstehen dann im Filesystem auf dem Host unter …/mail-data/… weitere Verzeichnisse – für jede Domain ein anderes. Der dovecot-IMAP-Server ist im Konstrukt so konfiguriert, dass er das so macht.
Bei der DKIM-Signierung musste ich allerdings für weitere Domains noch manuell etwas nach konfigurieren.
Viele Grüße…
Hi Christian,
ich habe eben auf die Schnelle mit deiner Anleitung einen Mailserver zusammengebastelt, um meine händische Lösung (ähnlich, aber eben aufwendig zu konfigurieren) irgendwann einmal komplett abzulösen.
Zwei Dinge sind mir aufgefallen:
1. amavis ist standardmäßig aktiviert und beißt sich mit rspamd, also auch ENABLE_AMAVIS=0 setzen in der mailserver.env
2. rspamd hat ein schönes Webinterface, in dem man schön sehen kann, welche Mails angenommen, abgelehnt oder auf die Greylist gesetzt wurden. Um das zu aktivieren, braucht es zwei Schritte. Zum einen muss der Port 11334 durchgeschleift werden, also bei ports im docker-compose.yml „- 11334:11334″ ergänzen und dann ein Passwort setzen. Dazu habe ich im Verzeichnis ./docker-data/dms/config/rspamd ein Verzeichnis override.d und darin eine Datei worker-controller.inc angelegt. Die Datei enthält eine Zeile
password=““
Vielleicht kennst du ja auch eine elegantere Möglichkeit, jedenfalls funktioniert der Server auf meiner „Spieldomain“ sehr gut, danke für die Anleitung!
Moin.
Ich bekomme den Mailserver nicht sauber gestartet.
Mit aktuellem compose geht die Containererzeugung ja nur noch ohne Bindestrich, soweit klar.
Den healthcheck: habe ich auch auskommentiert, sonst lief der Container in einer health: starting – Schleife und startete nicht.
Mit docker compose up -d wird nun der Container erzeugt und läuft.
Aber schon das erste Hinzufügen einer Mailadresse endet in einer Reboot-Schleife, dabei ist es egal, ob ich das von außerhalb wie oben angegeben oder innerhalb des Containers dialoggeführt mache.
Kann jemand hiermit was anfangen?
Hallo Jürgen,
ich empfehle dir, den bzw. (inkl. certbot) die Container mal mit „docker-compose up“ (ohne das -d) zu starten und die Ausgaben zu beobachten. Möglicherweise ergeben sich darin Hinweise auf Fehler bzw. Ursachen.
Inhalt von docker-compose.yml und mailserver.env selbst wären ggf. auch noch hilfreich.
Gruß
Daniel
Hi,
ich hab meine Mailserver seit 20Jahren auch immer zu Fuß installiert. Beim letzten großen Upgrade dass ich ewig vor mir hergeschoben hatte, bin ich über http://mailcow.email gestolpert und sehr glücklich damit – das ganze ist auch eine komplette mailserver suite die auch auf docker und den üblichen Diensten bestehtn. Das Projekt wird gut gepflegt wird – ich bin happy – Installations und Wartungsaufwand sind minimiert.
Grüsse Tobias
Mir ging es ebenso wie dir und die Kuh habe ich auch ausprobiert, allerdings bin ich damit auf meinem Server nicht warm geworden. Obwohl die Hardwarevorraussetzungen (RAM, CPU) locker erfüllt wurden, hat mailcow meinen Server mitunter an den Anschlag gebracht und alle Bemühungen des ansonsten sehr guten Forums haben nicht geholfen. Dann bin ich auf diese Seite gestoßen und siehe da, ein dockerbasierter Mailserver muss nicht alle Ressourcen des Servers fressen 🙂 …. die hier beschriebene Lösung läuft ruhig im Hintergrund wie erwartet für einen kleinen privaten Mailserver. Mailcow ist eine wunderbare Lösung, aber leider für mich zu ressourcenintensiv umgesetzt.
Nach dem ersten letsencrypt Zyklus muss ich fest stellen, dass hier doch Laufzeitprobleme entstehen.
Zunächst, was ich festgestellt habe:
Den certbot über docker-compose mit restart: any laufen zu lassen ist suboptimal. Zwar wird der Container und damit der Zertbot immer im Minutentakt gestartet, aber das läuft nicht zuverlässig, denn irgendwann hört docker auf den Container im Minutentakt neu zu starten. Zum Glück hat mit Letsencrypr eine Mail geschickt, dass bald mein Zertifikat aus läuft, sonst hätte ich das erst bemerkt, wenn es abgelaufen wäre.
Des weiteren würde es nichts nützen, wenn der Certbot die Zertifikate einfach nur im standalone austauscht. Die Maildienste müssen danach neugestartet werden sonst liefern die lustig die alten Zertifikate weiter aus.
Was habe ich geändert?
Generell scheint der Certbot über Docker nicht die beste Wahl zu sein. Das schreiben auch die Zertbotmacher in ihrer Docku.
Dennoch habe ich mich für die Dockervariante entschieden. Allerdings Wird der Container nicht mehr über docker-compose gesteuert, sondern über ein Bash-Script, welches ich wiederum über cron alle 10 Min. Aufrufe.
Bei einer Zeritfikatslaufzeit von 3 Monaten sollte das völlig reichen.
Mein Certbot Script schreibt auch nach jedem lauf die sha256 Checksummen der Zertifikate in eine Datei (nennen wie sie mal new) und schaut ob diese gleich mit den Checksummen des vorherigen Laufes sind (nennen wir diese Datei mal old).
Wenn ein diff new old ist, dann wird ein docker-compose restart durchgeführt und new nach old kopiert.
Soweit mal meine Anpassung in the nutshell.