E-Mail-Self-Hosting auf die harte Tour: angefangen bei einem selbst routbaren IPv4-Block

• Die seit 1997 betriebene Recoil-Mail-Infrastruktur wurde zu einem selbst gehosteten Stack modernisiert, der mit einem dedizierten IPv4-/24-Block, Postfix, Dovecot, rspamd, Roundcube usw. Ein- und Ausgang sowie Zugriff direkt selbst verarbeitet
• Der eigene Mailbetrieb bietet Datenhoheit und Lernwert, aber auf dem nur schwach vertrauensbasierten SMTP müssen IP-Reputation, DNS-Einträge und Spam-Abwehr selbst verwaltet werden
• Der eingehende Pfad ist so aufgebaut, dass Bot-Traffic und bösartige Mails schrittweise reduziert werden: über postscreen, DNSBL, Greylisting, ClamAV, Bayes-Filterung, LMTP und Sieve
• Die Zuverlässigkeit beim Versand hängt von SPF, DKIM, DMARC und SRS ab; bei Fehlkonfiguration können Mails bei Prüfungen auf Empfängerseite wie Gmail oder Outlook als Spam behandelt oder still verworfen werden
• E-Mail-Self-Hosting ist auch 2026 noch möglich, erfordert aber Defense in Depth zur Absicherung von IPv4-Beschaffung, diversen DNS-Einträgen, Sicherheitsupdates und Angriffen auf Basis von KI-gestützter Schwachstellenausnutzung

---

Warum eigene E-Mail betreiben

• Der Betrieb eigener Server ist eine lehrreiche Erfahrung für Systeme und Netzwerke und ein Weg, die Funktionsweise des Internets und die Beteiligung an Open Source zu verstehen
• In einer Situation, in der sich das Web auf wenige Anbieter konzentriert, ist Self-Hosting ein Weg, den souveränen Zugriff auf die eigenen Daten zu bewahren
• Eine Analyse von 2023 kam zu dem Schluss, dass sich die Akteure, die E-Mail-Traffic lesen können, im Wesentlichen auf Google und Microsoft reduzieren
• E-Mail ist mit dem Zurücksetzen von Passwörtern vieler Online-Konten verknüpft, sodass Kontoübernahmen oder Phishing auch den Zugriff auf andere Dienste gefährden können
• Der eigene Mailbetrieb erfordert langfristige Pflege sowie stabiles Internet-Hosting und den Aufbau von Reputation, mehr als ein Heimnetz in der Regel leisten kann

Struktur des E-Mail-Empfangs

• Eine Internet-Domain legt über MX-DNS-Einträge fest, welcher SMTP-Server Mails annimmt; bei recoil.org verarbeitet pork.recoil.org die E-Mail
• SMTP stammt aus einem stärker vertrauensbasierten Design der 1980er Jahre und kann die Identität des Absenders grundsätzlich nicht beweisen; der Absender eingehender Mails lässt sich leicht fälschen
• Die Reaktion des IETF hat sich zu einem Stapel mehrerer Identitätsprüfungen entwickelt; werden diese falsch konfiguriert, sinkt die Zustellzuverlässigkeit
• DNS-basierte Sperrlisten sammeln Informationen über Botnets, kompromittierte Hosts und Spammer; Mailserver können RBLs abfragen, um verdächtige IPs auszusortieren
• E-Mail-Reputation baut sich nicht auf der Domain, sondern auf der IP-Adresse auf, weshalb wiederverwendete Cloud-Adressen oder Nachbar-IPs im selben Block die Reputation beeinflussen können

• Beschaffung und Routing eines dedizierten IPv4-Blocks

  • Recoil hat sich einen dedizierten IPv4-Adressblock 185.33.27.0/24 gesichert, um eine eigene Mail-Reputation unabhängig aufzubauen
  • RIPE NCC hat im November 2019 den nicht zugewiesenen IPv4-Adressraum ausgeschöpft; seitdem erfolgen direkte Zuweisungen über eine Warteliste für kleine /24-Blöcke
  • Der /24-Block wurde nach etwa 6 Monaten Wartezeit zugewiesen; wer ihn in Europa direkt beantragen will, muss den RIPE-NCC-Mitgliedsbeitrag zahlen und ein LIR-Konto eröffnen
  • Für den zugewiesenen IPv4-Block wird per RPKI ROA die Routing-Berechtigung festgelegt; der Recoil-Block ist an Mythic Beasts AS44684 angebunden
  • Auch Reverse DNS lässt sich direkt steuern; 185.33.27.128 ist auf pork.recoil.org abgebildet und dient als Reputationssignal für E-Mail

Abwehr von Bots und Spam

• Ein sauberer IPv4-Block allein reicht nicht aus; die meisten TCP-Verbindungen auf Port 25 dienen der Spam-Zustellung, der Suche nach Open Relays, dem Erraten von Zugangsdaten oder dem Sammeln von Trainingsdaten für KI
• Postfix postscreen führt vor Port 25 parallele DNSBL-Abfragen, Pre-Greet-Verzögerung sowie Prüfungen auf Pipelining und Nicht-SMTP-Befehle durch
• postscreen leitet nur unauffällige Clients an das eigentliche smtpd weiter; fehlerhafte Clients werden mit einem temporären Fehler getrennt, damit Fehlklassifikationen erneut versuchen können
• Listen von Spamhaus, Spamcop und Barracuda werden gewichtet kombiniert; konfiguriert ist eine Ablehnung bei einem Treffer in Spamhaus allein oder bei gleichzeitigen Treffern in zwei schwächeren Listen
• Der sendende MX-Pool von Apple iCloud versucht Wiederholungen nicht von derselben IP aus und passt daher nicht zum postscreen-Whitelist-Modell; deshalb wird der gesamte Bereich 17.0.0.0/8 vorab erlaubt

• Greylisting und Inhaltsprüfung

  • Greylisting gibt bei unbekannten Absendern zunächst einen temporären Fehler zurück; versucht ein legitimer MTA es einige Minuten später erneut, wird die Nachricht zugelassen
  • Einmalige Botnets ziehen nach einem Fehlschlag oft weiter zum nächsten Ziel und unterscheiden sich dadurch von legitimen Absendern mit Retry-Queue
  • Nach postscreen und Greylisting werden bereits mehr als 99 % des ursprünglichen Bot-Traffics bei geringen CPU-Kosten blockiert
  • rspamd prüft alle Nachrichten über das Milter-Protokoll und lehnt verdächtige Mails ab oder verzögert sie, solange der sendende Server noch verbunden ist, statt sie erst anzunehmen und später zurückzusenden
  • ClamAV prüft bekannte virenverseuchte Anhänge und lehnt infizierte Nachrichten sofort ab; der Bayes-Klassifikator von rspamd bewertet Nachrichten anhand eines in Redis gespeicherten Spam-/Ham-Korpus

Lokale Zustellung, Speicherung, Filterung

• Eingehende Nachrichten werden nach postscreen, Greylisting, rspamd, ClamAV und Bayes-Klassifikation an Dovecot übergeben
• Statt dass Postfix direkt in Benutzer-Home-Verzeichnisse schreibt, übergibt es per LMTP an Dovecot, das Indizierung, Quotas, Volltextsuche und Sieve-Filterung übernimmt
• virtual_alias_maps wandelt Adressen wie [e-mail] in lokal zustellbare Adressen um
• Als Speicherformat dient seit 1998 Maildir, wobei jede E-Mail als einzelne Datei unter ~/Maildir gespeichert wird
• Maildir nutzt die drei Unterverzeichnisse tmp/, new/, cur/ und atomare POSIX-rename-Operationen, um neue Nachrichten ohne globales Mailbox-Locking zuzustellen

• Suchindex und Sieve

  • Moderne Mailserver wie Stalwart wurden ebenfalls geprüft, aber nicht übernommen, weil sie Maildir nicht unterstützen und stattdessen benutzerdefinierte Datenbankspeicher wie RocksDB verlangen
  • Dovecot trennt Maildir-Speicherung und Suchleistung über den separaten Volltextindex Flatcurve
  • Flatcurve ist ein Xapian-Wrapper und legt pro Mailbox einen Xapian-Index unter ~/Maildir/fts-flatcurve an, der beim Eintreffen neuer Mails automatisch aktualisiert wird
  • Sieve ist eine deklarative Sprache speziell für Mail-Filterung; das Dovecot-Plugin Pigeonhole Sieve führt benutzerseitige Filter beim Zustellzeitpunkt aus
  • Systemweite Sieve-Skripte verschieben von rspamd markierte Mails nach Junk, während benutzerspezifische Skripte Ordnerzuordnung, Abwesenheitsregeln, Prioritäten, Header-Bearbeitung usw. behandeln

Zuverlässiger E-Mail-Versand

• Für stabilen Mailversand ist die Authentifizierung nach außen ebenso wichtig wie die Abwehr eingehender Mails; scheitert eine Prüfung bei großen Empfängern, landet die Nachricht im Spam-Ordner oder wird still verworfen
• SPF ist ein DNS-TXT-Eintrag an der Domain-Spitze und deklariert, welche IP-Adressen behaupten dürfen, von @recoil.org zu senden
• Das SPF von Recoil lautet v=spf1 a mx -all; als gültiger Absender gilt damit nur pork.recoil.org, auf das der MX von recoil.org zeigt
• Auf Hosts mit mehreren IPs bindet Postfix über smtp_bind_address und smtp_bind_address6 an eine bestimmte Absenderadresse, damit der Kernel nicht willkürlich eine Adresse auswählt
• DKIM versieht den Nachrichtenkörper und ausgewählte Header in normalisierter Form mit einer kryptografischen Signatur; der öffentliche Prüfschlüssel liegt in DNS unter <selector>._domainkey.<domain>

• DMARC und SRS

  • DMARC prüft, ob die über SPF und DKIM authentifizierte Domain zur für Nutzer sichtbaren From:-Kopfzeile passt, und teilt Empfängern mit, wie sie bei Fehlern verfahren sollen
  • Die DMARC-Richtlinie von Recoil ist p=quarantine; über eine rua=-Adresse werden aggregierte Berichte empfangen, um Zustellprobleme zu debuggen
  • Große Empfänger senden ungefähr einmal täglich zusammenfassende XML-Berichte über Nachrichten, die behaupteten, von recoil.org zu stammen; dazu gehören Google, Microsoft, Yahoo, Fastmail und andere
  • Bei weitergeleiteten Mails kann die ursprüngliche Absenderdomain so erscheinen, als würde sie von einer Recoil-IP senden, wodurch SPF fehlschlagen kann
  • SRS schreibt die Envelope-Absenderadresse in eine Form wie SRS0=…=example.com=[e-mail] um, damit SPF-Prüfungen am Ziel gegen die Recoil-Domain ausgewertet werden

Benutzerzugang und Webmail

• Nutzer greifen entweder mit normalen IMAP-Clients auf den Dovecot-Server zu oder öffnen selbst gehostetes Webmail im Browser, um ihre E-Mails zu lesen
• Dovecot übernimmt auf pork den Mailbox-Zugriff und verschlüsselt seine Listener mit TLS, damit weder Klartext-Mails noch Passwörter über öffentliche Netze laufen
• Für Zertifikate wird LetsEncrypt verwendet; mehrere Host-Aliase wie imap.recoil.org und smtp.recoil.org werden per SNI bereitgestellt
• Dovecot fungiert auch als SASL-Backend für Postfix, sodass Nutzer für IMAP-Zugriff und SMTP-Versand dasselbe Passwort verwenden können
• Roundcube läuft als Docker-Compose-Dienst hinter einem TLS-Reverse-Proxy von Caddy und verbindet sich wie ein normaler Client per TLS/IMAP mit pork

• Roundcube-Plugins

  • Das Roundcube-Plugin managesieve nutzt das ManageSieve-Protokoll, damit Sieve-Filter im Browser bearbeitet werden können
  • Das Plugin markasjunk macht die Webmail-Schaltfläche „Junk“ zu einem Verschieben in den Junk-Ordner, wodurch das Training der Ham-/Spam-Klassifikation unauffällig für den Benutzer mitläuft
  • Die ManageSieve-Oberfläche von Roundcube legt das rohe Sieve-DSL nicht offen

Verbleibende Arbeit und die Bedeutung von Self-Hosting

• Die aktuelle Konfiguration war in den letzten Wochen im Alltagsbetrieb recht robust, doch es bleibt weitere Arbeit zu tun
• recoil.org kombiniert DNS-Einträge wie MX, A/AAAA, PTR, SPF TXT, DKIM TXT und DMARC TXT, um Mail-Empfang, -Versand und -Validierung aufzubauen
• MTA-STS teilt anderen Mailservern mit, nur über TLS mit gültigen Zertifikaten zu kommunizieren, und mindert so STARTTLS-Downgrade-Angriffe
• DANE/TLSA verwendet statt HTTPS in DNS verankerte TLS-Zertifikat-Hashes, erfordert aber eine mit DNSSEC signierte DNS-Zone und ist daher noch nicht ausgerollt
• SRS ist teilweise ausgerollt, wird aber noch nicht in allen Weiterleitungspfaden validiert; Fehlschläge im Zusammenhang mit INRIA gelten als besorgniserregend, weil sie DMARC-Fehler und Auswirkungen auf die Domain-Reputation verursachen könnten

• JMAP, Sicherheit und zukünftiges Self-Hosting

  • JMAP ist ein Mailzugriffsprotokoll auf Basis von HTTPS und JSON und passt besser zu modernen Netzwerk-Clients als IMAP
  • Dovecot unterstützt JMAP nicht nativ, und die evaluierten eigenständigen JMAP-Server verlangen statt Maildir eigene Mailbox-Speicher
  • Ein erwogener Plan ist, eine OCaml-JMAP-Implementierung als Übersetzungs-Proxy vor Dovecot zu setzen, JMAP-Anfragen auf IMAP-Aufrufe abzubilden und dann JSON-Antworten zurückzugeben
  • Um 2026 einen Mailserver zu betreiben, müssen mindestens sechs DNS-Einträge korrekt gesetzt sein, und die Beschaffung eines IPv4-Blocks über RIPE dauert fast ein Jahr
  • Die Zeitspanne zwischen CVE-Veröffentlichung und realem Exploit-Einsatz gegen SMTP-/IMAP-Listener dürfte inzwischen eher in Stunden als in Wochen gemessen werden; nötig ist deshalb Defense in Depth mit Maßnahmen wie fest zugewiesenen Adressen, Isolation des Webmail-Containers, Greylisting und DNSBL

[GN⁺]

Lobste.rs-Kommentare

• Ich beobachte immer wieder Gatekeeper, die kategorisch behaupten, etwas sei unmöglich, das andere seit Jahrzehnten tun.
  Tatsächlich sage ich immer wieder, dass es reicht, Reverse DNS, SPF, DMARC und MTA-STS einzurichten, und dass es weder viel kostet noch besonders schwierig ist.
  Beispiel-Mailserver: https://poofydoof.zia.io/

  • Ich betreibe seit etwa 2008 selbst selbstgehostetes E-Mail-Hosting, und es irritiert mich immer noch, wie viele Leute behaupten, das sei unmöglich.
    Derzeit nutze ich Debian + Postfix, Dovecot und rspamd, und in meinem Job gibt es mit Google Workspace häufiger Probleme als mit meiner eigenen Konfiguration.
  • Ich denke, der entscheidende Teil ist „etwas, das andere seit Jahrzehnten tun“.
    Zu sagen, dass Reverse DNS, SPF, DMARC und MTA-STS ausreichen, stimmt zu 100 % für Domains und IP-Adressen mit bereits gutem Ruf.
    Wenn man einem Mailserver, dem große Anbieter bereits vertrauen, eine neue Domain hinzufügt, baut sich Reputation schnell auf, und auch wenn man eine bestehende Domain auf eine neue Mailserver-IP umzieht und dabei DKIM einrichtet, ist das in Ordnung.
    Wenn man aber mit einer neuen Domain und einer neuen Mailserver-IP ganz von vorne anfängt, ist die Lage wohl deutlich anders, und ich habe gehört, dass E-Mails wahrscheinlich automatisch als Spam behandelt werden, bis die Machine-Learning-Systeme der großen Anbieter zufrieden sind.
    Es scheint oft gut zu funktionieren, wenn Nutzer dieser Systeme E-Mails an meine Domain schicken und Antworten aus dem Spam-Ordner herausholen.
  • Nach etwa drei Jahren Betrieb eines Mailservers würde ich sagen, dass der schwierige Teil nicht die Einrichtung von DNS, SPF, DMARC und MTA-STS ist, sondern bei transaktionalen E-Mails nicht auf Blocklisten zu landen und bei manchen E-Mail-Anbietern nicht auf eine Allowlist zu kommen.
    Statt Zeit darauf zu verwenden, diesen Dingen ständig hinterherzulaufen, halte ich es für besser, etwa 5 Dollar im Monat zu zahlen und das jemand anderem zu überlassen.
  • Der Beispiel-Mailserver ist cool, und das hier ist auch gut:
    https://dmesgd.nycbug.org/dmesgd?do=view&id=8929
    Ich würde gern mehr Details zu diesem Aufbau erfahren.
    Der Mango Pi MQ-Pro scheint schwer zu bekommen zu sein, und ich frage mich, ob es andere extrem günstige Geräte mit brauchbarer NetBSD-/Linux-Unterstützung gibt.

• Ein weiterer Grund, einen Mailserver selbst zu betreiben, ist, dass man feststellen kann, dass jemand bereits Spam über die eigene Domain verschickt.
  Als eine meiner Domains wegen des Verkaufs von Google Domains zu Squarespace umgezogen wurde, hat Squarespace automatisch MX-/SPF-/DKIM-DNS-Einträge für Mailgun hinzugefügt, obwohl ich gar kein Mailgun-Konto hatte.
  Jemand hat sich dieses Konto bei Mailgun geschnappt und mir Spam geschickt, der so aussah, als käme er von meiner Domain.
  Danke, Google.

• Besonders der Teil mit der IPv4-Zuteilung ist interessant.
  Für Europa steht dort, man solle, wenn man es selbst machen will, den Jahresbeitrag an RIPE NCC zahlen und ein Konto als Local Internet Registry (LIR) eröffnen; laut https://www.ripe.net/membership/payment/ sind das 1800 Euro pro Jahr.
  Das tut ziemlich weh, aber wenn es billiger wäre, könnten Spammer es wohl noch leichter missbrauchen.

  • Es ist nicht billig, aber es sind etwa 12 Pfund pro Adresse und Jahr, also gar nicht so schlecht, wenn man es mit Freunden und Familie in der Region für deren Dienste teilt.
    Der Spaß, einen BGP-Server in OCaml zu schreiben, ist unbezahlbar :-)

• Ich frage mich, ob man IPv6 für das Senden und Empfangen von E-Mails realistisch nutzen kann.

  • Gute Frage.
    Ich habe mich beim Schreiben des Artikels damit beschäftigt, aber da auf meinem Mailserver IPv6 seit einigen Jahren deaktiviert ist, habe ich beschlossen, das zu verschieben, bis ich mehr Erfahrung gesammelt habe.
    Laut https://dn.org/ipv6-and-domain-reputation-in-anti-spam-filters verwenden E-Mail-Anbieter wie Gmail, Microsoft und Yahoo jeweils eigene Spam-Filter, die Domain-Reputation und IP-Reputation unterschiedlich gewichten, und auch die IPv6-Unterstützung reift weiter.
    Gmail verlangt für E-Mails über IPv6 gültige PTR-Records, SPF und DKIM und empfiehlt die Nutzung von DMARC nachdrücklich.
    Ohne diese Faktoren landen über IPv6 gesendete E-Mails oft im Spam-Ordner oder werden verzögert.
    Das Filtersystem von Microsoft berücksichtigt IPv6 in den Programmen SNDS und JMRP, kann IPv6-Mail aber einschränken oder verzögern, wenn die Absender-Reputation unbekannt ist.
    Letztlich ist IPv6 ein weiterer möglicher Fehlerpunkt, und beim Einstieg ist es vermutlich keine gute Idee, eine gemischte IPv4/IPv6-Übertragungsdomain zu konfigurieren.
    Ich habe noch keinen reinen SMTP-Endpunkt nur für IPv6 gefunden.