Um direkt an das Thema lokaler DNS-Server mit Unbound anzuknüpfen, möchte ich heute etwas zum Thema E-Mails sagen. Wir alle nutzen sie täglich, ganz gleich zu welchem Zweck. Wir alle werden dort täglich mit Spam zugeschüttet – auch das ist ein gegenwärtiges Phänomen.
Und die meisten von uns nutzen der Einfachheit halber US-Dienste zur Bereitstellung ihrer privaten Postfächer – aber auch gewerbliche finden sich hier. Letztlich ist es auch eine Kostenfrage, sind diese Dienste doch kostenlos. So liegt der Marktanteil hier aktuell wie folgt:
- Gmail (Google): 37,5 % Anteil!
- Hotmail (Microsoft): 7,6 % Anteil
In Deutschland schaut das dann so aus:
- Web.de: 1&1
- GMX.com: United Internet AG (auch 1&1 gehört dazu) – 16 %
- Mail.com: Auch United
- T-Online: Hauptsächlich für Kunden der Telekom
Tracking für personalisierte Werbung ist diesen allen gemein. Bei den US-Diensten kommt die Bildung ganzer Nutzerprofile noch hinzu. Also um das noch einmal in aller Deutlichkeit zu erklären: Der Inhalt deiner E-Mails wird in lesbarer Form auf US-Servern gespeichert.
Sollten diese mit einer Signatur verschlüsselt sein, ist für den Moment evtl. etwas mehr Sicherheit gegeben. Aber auch hier wird diese Sicherheit nicht mehr lange andauern: Kommerzielle Quantencomputer werden heutige Signaturen ohne Probleme brechen können. Da die Mails von heute bereits gespeichert sind – und damit in der Zukunft gebrochen werden können.
Die Alternativen: Kostenpflichtig oder Selbst?
Der eine hat mehr, der andere weniger guten Spam-Schutz.
Kostenpflichtige Dienste wie Proton Mail, mailbox.org, Posteo oder Tuta Mail bieten zwar besseren Datenschutz. Da sie kostenpflichtig sind, entfällt hier die Analyse der E-Mail-Inhalte durch KI und andere Systeme, keine personalisierte Werbung, keine Verknüpfung von Daten.
Die grundsätzliche Verschlüsselung dieser Dienste ist übrigens ein Mythos – nur wenn Sender und Empfänger diese Verschlüsselung auch verstehen, kann sie genutzt werden. Sonst nicht. Also von z. B. Proton Mail zu Hotmail wäre auch weiterhin keine Verschlüsselung aktiv.
Hosting, wenn du selbst eine Domain betreibst bei einem deutschen Anbieter wie zum Beispiel mail@hans-mustermann.de, ist alles unter deiner Kontrolle. Keine großartigen Konfigurationen nötig, meistens. Webmailer inklusive in der Regel. Betrifft auch viele kleine Firmen, die Webseiten bei einem Hoster liegen haben: Dort liegen in der Regel auch die E-Mails dann gehostet. Da spricht so weit auch nichts dagegen, außer dass die Daten (Mails) eben nicht bei dir im Netzwerk vor Ort liegen.
Wir werfen einen Blick auf Mailcow
Eine recht pfiffige Software, die von deutschen Anbietern in Hosting-Paketen gebucht werden kann. Je nach Anbieter und Paket unterscheiden sich die Leistungen wie z. B. Support, Speicherplatz und Frequenz der dringend zu empfehlenden Backups.
Oder selbst gehostet mit Docker!
Hier benötigst du vorab ein paar Zutaten: Mailcow selbst ist zwar mächtig, bringt aber dennoch keine komplizierte Konfiguration mit sich. Es ist übersichtlich gestaltet und passt sowohl auf einen Raspberry als auch in eine Proxmox VM: Da Mailcow Docker-basiert ist, ist die Plattform egal. Wo Docker läuft, läuft auch Mailcow.
Nun gibt es aber diverse Fallstricke, die einem den Spaß verderben könnten – diese möchte ich hier unbedingt aufzeigen, auch wenn dieser Beitrag keinen Anspruch auf Vollständigkeit erheben kann. Die reine Installation von Mailcow entnehmt ihr bitte dem Internet – schon alleine deshalb, weil sich dies ändern könnte – und der Beitrag hier dann falsch wäre.
Auf einem Raspberry ist eine Hardware wie bei dem NAS-Raspi-Artikel empfohlen, da die Datenbank von Mailcow viele Schreibzugriffe mit sich bringt – was eine SD-Karte nicht besonders lange durchhält.
DNS-Einstellungen: Der schwierigste Part dabei
- Eigene IP: Auch dynamisch, muss vorhanden sein. DS Lite / Stacking-Anschlüsse funktionieren nicht direkt – nur über ein VPS oder einen Tunnel, was das Setup jedoch sehr komplex werden lässt.
- DynDNS: Dienst nutzen, wenn nötig – einige Provider bieten dies direkt mit an. Auch im Router (Fritz!Box etc.) aktivieren.
Eintrag am einfachsten in deiner lokalen /etc/crontab mit:
wget -q -O /dev/null "https://dyndns-adresse.de/xxxx"(ohne „“, um die Aktualisierung zu automatisieren – den Umgang mit der Crontab findest du im Netz!)
CNAME Record
Wenn vorhanden, muss dieser entfernt werden. Dieser kollidiert mit dem MX Record (bisherigen Inhalt evtl. irgendwo notieren und sicher verwahren, falls doch mal der Server wieder umgestellt werden muss).
MX Record
- Deine registrierte Domain (z. B.
meine-domain.de) - Priorität – je geringer, desto höher die Prio (z. B.
10) - Wohin die Mails dieser Domain von 1) umgeleitet werden sollen (z. B.
mails.dyndns-adresse.de)
A Record
Die Adresse (1) des MX Records muss noch auf deine aktuelle dynamische IP (2) umgeleitet werden (z. B. mails.dyndns-adresse.de). Die täglichen Änderungen fließen dann über den hier gezeigten wget-Aufruf in der Crontab automatisch ein.
Damit zeigt die ganze Geschichte nun auf deinen Router, wie z. B. eine Fritz!Box. Wenn du mit MX- und A-Records so weit klar gekommen bist, dann weißt du vermutlich sowieso, wie man nun ein- oder zwei Löcher in die Firewall der Fritz!Box bohrt.
Die Ports im Überblick
Kurz nur die Ports dazu bzw. die Portfreigaben:
- Web-Interface: Port 80 bzw. 443 (für den Zugriff auf die Mailcow-Oberfläche).
- IMAP (Empfang): TCP 993 (verschlüsselt).
- SMTP (Versand): TCP 465 (SSL/TLS) oder 587 (STARTTLS).
Wichtig zu Port 25: Der Standard-Port für SMTP (25) ist für den Empfang von E-Mails (via MX-Record) zwingend erforderlich und muss in der Firewall geöffnet sein. Viele ISPs blockieren Port 25 jedoch für ausgehende Mails. In diesem Fall ist ein SMTP-Relay-Host nötig, um Mails zu versenden.
Wichtig: Bedenke: Jede Portweiterleitung auf deinem ISP-Router ist ein Sicherheitsrisiko und darf auf keinen Fall „einfach mal so“ eingerichtet werden. Halte dir immer vor Augen: Wer es hinter diese Abschottung geschafft hat, ist in deinem LAN. Du alleine bist hier der Hausherr und dafür verantwortlich, dass es sicher aufgebaut ist! Weitere Router, Firewalls, DMZ evtl. oder ein Bastion Host, Reverse Proxy(s) sind unumgänglich, je nach Setup.
Welche kritischen Systeme liegen mit in diesem LAN? Kannst du diese mit einem VLAN heraustrennen und besser isolieren? Wie fängst du Brute-Force-Attacken ab? Halte deine Dienste im LAN aktuell, informiere dich über Sicherheitslücken und Patches zum Beispiel per Newsletter.
Du hast mehr als eine Docker-Instanz, die unter 80/443 erreichbar sein muss, auf einer einzigen externen IP-Adresse? In diesem Fall werden komplexere interne Routings bei dir notwendig – da HTTP und auch HTTPS so erst einmal keine Ports kennen, außer ihre eigenen. Ein Mapping von einer IP-Adresse mit Port zu einer Domain ist nicht möglich. In so einem Fall ist ein interner DNS-Dienst wie eine Pi-hole-Instanz mit nachgelagertem Reverse-Proxy notwendig. Mailcow verfügt bereits über einen integrierten Nginx-Reverse-Proxy, der diese Aufgaben übernehmen kann.
Mit Fail2Ban lassen sich Brute-Force-Attacken abwehren; auch dieses Teil ist in Mailcow bereits integriert. Aber vermutlich noch nicht richtig konfiguriert – also prüfen und nachschärfen ist angesagt.
Fazit: Die Rückeroberung deiner Kommunikation
Mailcow ist keine Magie, aber es ist der Schlüssel. Es erfordert Fokus, es erfordert ein gewisses technisches Verständnis. Aber am Ende hast du etwas, das dir gehört. Nicht Google. Nicht Microsoft. Nicht United Internet. Dir.
Und das ist es, was Datensouveränität ausmacht.
