Logo

Es gibt einige Gründe dafür, einen eigenen E-Mail Server zu betreiben - aber auch Gründe dagegen.

Was spricht für einen eigenen Mail Server?

  • Man hat Kontrolle darüber, wo die Mails liegen → Vom Datenschutz Aspekt ist das die optimale Lösung.
  • Man hat volle Kontrolle über die Konfiguration → z.B. keine schwache Verschlüsselung, keine unbemerkte Datenausleitung.
  • Man hat das Patchmanagement (insbesondere Security Patches selbst in der Hand)

Was spricht gegen einen eigenen Mail Server?

Leider sehr viele Punkte, schon die Punkte, die dafür sprechen zeigen schon, dass für den Betrieb eines Mailservers ein erhebliches, technisches Know-How gebraucht wird.

  • Bevor man auch nur daran denkt, den Port 25 aufzumachen, muss man die Dokumentation von Postfix (mehrfach) gelesen und wirklich verstanden haben. Ansonsten wird das Vorhaben garantiert in einer Katastrophe enden.
  • Die Mails, die Postfix empfängt, will man auch irgendwann mal lesen. Die Aussagen zur Postfix Konfiguration gelten uneingeschränkt auch für Dovecot. Macht man hier etwas falsch, dann kann im Zweifel die ganze Welt die privaten E-Mails lesen.
  • Postfix und Dovecot brauchen noch einige Tools, damit man einen vernüftigen E-Mail Betrieb machen kann, dazu gehören u.A. DNS, eine Datenbank für Verzeichnisdienste (LDAP oder z.B. eine SQL Datenbank), Spamfilter, Signatur Lösung für DKIM etc.
  • Alles muss sauber konfiguriert und am besten täglich gepatcht werden.
  • Wird der Mailserver für die eigene Firma betrieben, dann nie - nie - nie ohne einen Wartungsvertrag. Shit happens...

Du hast bis hierher durchgehalten? Sehr gut!

Dann schlafe wenigstens eine oder mehrere Nächste darüber, ob Du wirklich einen Mailserver selbst betreiben möchtest.

Der eigene Mailserver

Wer schon einmal Projektmanagement gemacht hat, kann dieses Wissen hier nun gut anwenden, denn die Installation und Konfiguration eines Mailserver ist ein ausgewachsenes Projekt.

Domain

Ohne Domain kein Mail, zunächst steht die Auswahl eines geeigneten Domain Registrars an. Dieser muss DNSSEC unterstützen. Wenn der Registrar das nicht kann, dann ist der raus aus der Auswahl. Die DNS Server müssen das natürlich auch können. Im Idealfall bietet der Registrar die DNS Server mit DNSSEC Unterstützung gleich mit an. Falls nicht, dann ist Cloudflare eine gute Wahl dafür. Die kann man auch als reine DNS Server nutzen, das CDN von denen muss man nicht nutzen. Der DNS Server muss auch die nicht ganz so geläufigen Resource Record Typen, wie z.B. TLSA unterstützen.

Nicht vergessen auch eine Testdomain zu holen, wenn man da mal Mist macht, dann ist nicht die ganze Produktions-Infratruktur weg.

IP-Adresse

Es werden zumindest eine IPv4 und eine IPv6 Adresse benötigt, damit der E-Mail Server Mail empfangen und versenden kann. Die IP-Adresse muss statisch sein, mit einer dynamischen IP-Adresse klappt das nicht, i.d.R. werden Mails von dynamischen IP-Adressen von kaum einem Mailserver angenommen.

Wichtig ist auch die "Reputation" einer IP-Adresse. Ist eine IP-Adresse in der letzten Vergangenheit schon häufiger durch Spam aufgefallen, dann wird kaum ein Mailserver von dieser IP-Adresse Mails annehmen.

Leider gibt es auch Postmaster bei größeren Unternehmen, die auch E-Mails von IP-Adresse mit guter Reputation (keine Spamaktivitäten in den letzten Jahren) blocken, weil die Postmaster offensichtlich nicht wissen, wie man einen Spamfilter richtig nutzt und konfiguriert. Für solche Problemfälle lohnt es sich, ein spezifisches Routing über den Provider einzurichten.

Die IP-Adresse sollte ausschließlich für den Mailserver genutzt werden.

Ein Reverse DNS für diese IP-Adressen muss genau zu dem Hostnamen führen, der für den Mailserver vorgesehen ist. Der DNS Eintrag für den Hostnamen muss wiederum genau den IP-Adressen des Mailservers entsprechen.

Mailserver

Grundsätzlich kommen zwei Varianten für den Betrieb eines Mailservers in Betracht.

Mietserver

Die einfachste Lösung mit einer statischen IP-Adresse besteht darin, einen Server bei einem der bekannten Hoster zu mieten, z.B. Hetzner, Strato, Host-Europe, OVH etc. Es sollte da nicht am falschen Ende gespart werden, von daher sollten Billigsthoster nicht in die engere Wahl gezogen werden. Bei der Option Mietserver kann auch die Variante "Managed Server" in Betracht gezogen werden, dann kümmert sich der Provider um Patches und das die Maschine läuft. Das kostet dann aber auch richtig Geld...

Eigener Server am Internetanschluss

Wer einen Business-Anschluss mit fester IP-Adresse und Know-How für den Betrieb hat, kann den Server auch in den eigenen Räumlichkeiten betreiben. Dazu sollte man aber zumindest eine USV für den Server und die Internet Infrastruktur haben. Dazu sollten auch Ersatzteile oder noch besser ein Ersatzserver vorgehalten werden, falls es z.B. an einem Sonntag zu einem Hardwareausfall kommen sollte. Weiterhin kann dieser Ersatzserver auch als Testsystem diesen, auf dem z.B. Updates des Betriebssystem oder der Container getestet werden. Zum Test von Backups kann dieser Server auch verwendet werden.

Beides

Optimal sind ein (virtueller) Mietserver und ein Server am Internetanschluss. Ein Failover kann dann innerhalb von Minuten über DNS erfolgen.

Systemarchitektur

Damit Updates und auch Migrationen nicht jedes Mal zu Stressreaktionen führZertifikat für TLSen, sollte der Mailserver als Container laufen. Für kleine Installationen ist Docker hier die erste Wahl. Egal wie der Server aufgebaut ist und wo er betrieben wird: Ein minimales Linux System mit Docker reicht aus.

Zwischen dem Server und dem Internet muss sich eine dedizierte Firewall befinden. Zu empfehlen sind OPNsense oder pfSense. Beides sind Open Source Produkte, die sich professionell nutzen lassen. Reicht denn nicht eine AVM Fritzbox (oder ein anderer Router der Consumer Klasse)? Nein! → Bei diesen Consumerprodukten fehlen grundlegende Konfigurations- und Testmöglichkeiten, so dass damit keinerlei Möglichkeit besteht, die Richtigkeit der Firewall Regeln zu überprüfen.

Zwischenstand

Wir haben nun:

  • DNS Server ist für Domain mit DNSSEC konfiguriert.
  • Domain ist mit DNSSEC Keysigning Public Key oder DS beim Registrar registriert.
  • Eine IPv4 und IPv6 Adresse, die exclusiv für den Mailserver verwendet wird.
  • Eine Firewall, mit der der Internetzugang des Mailservers kontrolliert werden kann.
  • Einen Docker Server, auf dem der Mailserver laufen soll.

Was jetzt noch gebraucht wird, ist einer dockerfähiger Mailserver. Für kleine Installationen ist dafür Mailcow die erste Wahl. Für den Unternehmenseinsatz gibt es für wenig Geld auch Wartungsverträge, das ist steuerlich auch absetzbar.

Docker Host

Zunächst muss der Docker Host so konfiguriert werden, so das Mailcow damit betrieben werden kann. In erster Linie wird Docker Dual-Stack fähig gemacht, damit auch mit IPv6 alles funktioniert. Das Docker Storage Filesystem sollte zfs oder btrfs sein. Dazu wird die Datei /etc/docker/daemon.json wie folgt angepasst:

{
  "storage-driver": "btrfs",
  "ipv6": true,
  "fixed-cidr-v6": "fc00:123:456:789::1/64",
  "iptables": true,
  "ip6tables":true,
  "experimental":true,
  "debug": false
}

Das Präfix muss natürlich dem vom Provider zugeteilten Netz angepasst werden.

Firewall

Es muss eine Firewall Regel konfiguriert werden, die zumindest die Ports 25, 80, 110, 143, 443, 993, 995 und 4190 (alles tcp) auf den Docker Server weiterleitet. Weiterhin muss die Firewall für IPv4 alle Zugriffe von Mailcow auf die für Mailcow vorgesehene externe IPv4 Adresse übersetzen (Outbound NAT).

Mailcow

Die Installationsanleitung erklärt sehr gut, wie man zu einem lauffähigen Mailserver kommt.

STOP!

Auf keinen Fall darf zu diesem Zeitpunkt Mailcow aus dem Internet erreichbar sein, weil Mailcow zunächst ein unsicheres Startdardpasswort für den Admin-Zugang hat. Das Passwort muss geändert werden, bevor irgendein Zugriff aus dem Internet erlaubt wird. Erst nachdem das Admin Passwort - oder noch besser: Eine 2Faktor Authentifizierung - gesetzt sind, darf überhaupt ein Zugang aus dem Internet erlaubt werden.

Zwischenstand

Wir haben nun:

  • Der Mailserver sollte jetzt auf den Ports 25, 80, 110, 143, 443, 993, 995 und 4190 (alles tcp) auf IPv4 und IPv6 erreichbar sein.
  • Es gibt aber noch einen Zertifikatsfehler, weil Mailcow an dieser Stelle noch ein selbstsigniertes Zertifikat nutzt.
  • Mailcow weist alle Mails ab, weil noch keine Domain und kein user mit E-Mail Adresse konfiguriert ist.

Zertifikat für TLS

Mailcow hat zwar einen Service, der Let's Encrypt Zertifikate verwaltet, allerdings funktioniert das nur in speziellen Umgebungen. In mailcow.conf sollte man daher SKIP_LETS_ENCRYPT=y setzen und das Zertifikatsmanagement woanders machen. Auch hier ist eine Docker Lösung wieder die erste Wahl.

Das Dockerfile dazu

Mit diesem Container erfolgt die Validerung der Domain über DNS (hier Cloudflare).

from debian:bullseye-slim

run DEBIAN_FRONTEND=noninteractive apt-get update
run DEBIAN_FRONTEND=noninteractive apt-get install -q -y apt-utils
run DEBIAN_FRONTEND=noninteractive apt-get install -q -y \
  locales

RUN sed -i -e 's/# de_DE.UTF-8 UTF-8/de_DE.UTF-8 UTF-8/' /etc/locale.gen && \
  locale-gen
ENV LANG de_DE.UTF-8
ENV LANGUAGE de_DE:de
ENV LC_ALL de_DE.UTF-8

run DEBIAN_FRONTEND=noninteractive apt update && apt -q -y full-upgrade

run mkdir -p /usr/share/man/man1 \
  && DEBIAN_FRONTEND=noninteractive apt-get install -q -y \
  certbot \
  python3-certbot-dns-cloudflare

Damit das funktioniert, muss noch die Datei etc/cloudflare.ini erstellt werden:

# Cloudflare API credentials used by Certbot
dns_cloudflare_email = <cloudflare username>
dns_cloudflare_api_key = <cloudflare API Key>

Jetzt kann man ein Let's Encrypt Zertifikat erstellen ohne dass der Mailserver vorab erreichbar sein muss (aus Sicherheitsgründen auch nicht zu empfehlen).

docker run --rm -it -v ./letsencrypt/etc:/etc/letsencrypt certbot /usr/bin/certbot \
  -d 'autoconfig.example.com' \
  -d 'autodiscover.example.com' \
  -d 'mail.example.com' \
  --server https://acme-v02.api.letsencrypt.org/directory \
  --preferred-challenges dns certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  --rsa-key-size 4096 --key-type rsa \
  --cert-name mailcow-rsa

Im Erfolgsfall sind dann die Zertifikate und Keys unter etc/live/mailcow-rsa/ zu finden. Mit dieser Lösung kann man auch Wildcard Zertifikate unter Mailcow erstellen und verwenden. Dabei ist aber zu beachten, dass *.example.com nicht für example.com selbst gilt.

Die Datei privkey.pem muss dann nach ${mailcow_home}/data/assets/ssl/key.pem und die Datei fullchain.pem nach ${mailcow_home}/data/assets/ssl/cert.pem kopiert werden.

Nach einem Neustart von Mailcow sollten nun offizielle Zertifikate zu sehen sein.

Der erste User

Damit Mailcow etwas macht, wird zumindest ein E-Mail gebraucht. Die Mail Domain wird dazu unter Konfiguration → E-Mail Setup → Domains angelegt. Jetzt können für diese Domain auch Benutzer angelegt werden. Im Tab Mailboxen können die Benutzer erstellt werden.

Test

Für einen ersten Test ist z.B. ein Gmail oder outlook.de Account hilfreich. Ein erster Test besteht darin, dem gerade angelegten User eine Mail zu schicken. Kommt die Mail an, dann hat man alles richtig gemacht. Falls nicht, dann sollte das Logfile Auskunft darüber geben, was schief gegangen ist. Wurde von Außen überhaupt Kontakt aufgenommen? Falls nicht, dann kommen folgende Fehlerquellen in Betracht:

  • Firewall Regel ist falsch, es wird kein Traffic zum Mailcow durchgelassen.
  • MX Eintrag im DNS fehlt oder Hosteintrag ist falsch.

Hat eine Kontaktaufnahme stattgefunden, aber die Mail wurde abgewiesen, dann ist ein Schreibfehler in der Domain oder dem Usernamen eine häufige Ursache. Der Postfix Logeintrag beschreibt i.A. ganz gut, was der Fehler war.

Im nächsten Schritt wird eine Mail vom Mailcow an die Test E-Mail Adresse geschickt, z.B. <myusername>@outlook.de. Wenn die Mail aus zunächst einem nicht ersichtlichen Grund abgewiesen wird, dann geht mit der Arbeit los, dazu sind folgende Adressen hilfreich:

Diese Tests müssen auch mit der IPv6 Adresse durchgeführt werden, um sicher zu gehen.