Den eigenen E-Mail-Server betreiben – wie 1984
(maxadamski.com)- Mit dem Betrieb eines eigenen E-Mail-Servers lassen sich Automatisierungsaufgaben sowie Mailinglisten-Verwaltung kostengünstig umsetzen
- In der Praxis gibt es Probleme bei der Zuverlässigkeit der Zustellung, sodass das Senden und Empfangen mit großen Diensten scheitern kann
- Schon mit der Konfiguration von Postfix und OpenDKIM lässt sich ein grundlegendes SMTP- und authentifiziertes Mail-Versandsystem aufbauen
- Mit SSL-Zertifikaten sowie DKIM, SPF und DMARC lassen sich Mail-Vertrauen und Sicherheit bei der Übertragung verbessern
- Wenn zusätzlich ein PTR-(Reverse-DNS-)Record gesetzt wird, steigen die Chancen auf eine bessere Zustellrate bei großen Mail-Diensten
Überblick
Der Betrieb eines eigenen E-Mail-Servers ist nützlich für Automatisierungsaufgaben wie Mailinglisten, Newsletter und E-Mail-Authentifizierungs-APIs.
Die größte praktische Herausforderung ist jedoch die Zuverlässigkeit der Mail-Zustellung: Es besteht das Risiko, dass E-Mails nicht korrekt ankommen oder der Empfang fehlschlägt.
Der Betreiber setzt diesen Ansatz für persönliche Projekte ein, unter der Voraussetzung, dieses Risiko zu akzeptieren.
Ein Vorteil des Eigenbetriebs ist, dass kaum zusätzliche Kosten entstehen: Man muss nur Software auf einer bestehenden Website installieren, und auch Speicher- sowie Energieverbrauch sind sehr gering.
Der Betrieb eines E-Mail-Servers wirkte zunächst sehr schwierig, unterscheidet sich in der Praxis aber im Schwierigkeitsgrad nicht wesentlich von der Einrichtung eines SaaS-basierten E-Mail-Dienstes.
Zur Vereinfachung der Konfiguration wurden Webmail und Multiuser-Umgebung zunächst weggelassen, sodass keine Benutzerkonten, Datenbanken oder Weboberfläche eingerichtet werden müssen.
Diese Konfiguration eignet sich für den Betrieb mit einem einzelnen Konto; bei Bedarf können E-Mails über SSH sowie mit mailx, sendmail, mutt gesendet und empfangen werden.
Später sind je nach Bedarf Erweiterungen und die Ergänzung von Webmail denkbar.
Postfix
Grundsätzlich muss Port 25 geöffnet sein; installiert und konfiguriert man Postfix und OpenDKIM, lässt sich ein grundlegender SMTP-Server aufsetzen.
Damit E-Mails an die meisten Mail-Dienste (z. B. Gmail) zuverlässig zugestellt werden, ist OpenDKIM zur Mail-Authentifizierung erforderlich.
Der Betreiber hat master.cf auf den Standardwerten belassen; im Beispiel für die Hauptkonfiguration (main.cf) werden nur die Kerneinstellungen wie TLS-Verschlüsselung und DKIM-Integration gezeigt.
POP3/IMAP werden nicht eingerichtet; stattdessen bleibt das Setup bewusst einfach, indem bei Bedarf direkt per SSH auf den Server zugegriffen und mit Befehlen wie mailx gearbeitet wird.
TLS (Transportverschlüsselung)
Ein SSL-Zertifikat wird benötigt, um die Datenübertragung mit dem SMTP-Server zu verschlüsseln.
Es ist nicht nötig, für jede Domain ein Zertifikat auszustellen; ausreichend ist ein Zertifikat für den einzelnen Host, auf dem sich der Mail-Server befindet und auf den der MX-Record zeigt.
Wenn der MX-Record beispielsweise mx.example.com ist, genügt es, für genau diese Domain ein kostenloses Zertifikat von Let’s Encrypt zu beziehen und zu verwenden.
TLS verschlüsselt nur den Übertragungsweg zwischen Servern und ist von der eigentlichen Authentifizierung des Absender-Domainnamens getrennt.
Daher kann im From-Header der E-Mail frei ein gewünschter Wert gesetzt werden.
DKIM, SPF, DMARC
DKIM dient dazu nachzuweisen, dass eine E-Mail tatsächlich von der eigenen Domain stammt, und erhöht so die Vertrauenswürdigkeit.
Mit OpenDKIM wird für jede Domain ein Schlüsselpaar erzeugt, und der öffentliche Schlüssel wird als DNS-TXT-Record eingetragen.
Die Schlüssel laufen nicht automatisch ab, ein regelmäßiger Wechsel wird jedoch empfohlen.
Zusätzlich werden SPF- und DMARC-TXT-Records im DNS hinterlegt, um festzulegen, welche Hosts E-Mails senden dürfen und welche DMARC-Richtlinie gilt, etwa Ablehnung bei fehlgeschlagener Authentifizierung.
In den Beispielkonfigurationsdateien (opendkim.conf, KeyTable, SigningTable, TrustedHosts) ist klar nachvollziehbar, wie die einzelnen Einträge gesetzt werden.
Im DNS müssen lediglich die Records für MX, SPF, DKIM und DMARC ergänzt werden.
Reverse DNS (PTR)
Ein PTR-Record (Reverse DNS) erhöht die Vertrauenswürdigkeit des Mail-Servers und verbessert die Wahrscheinlichkeit, dass E-Mails bei großen Diensten wie Gmail nicht blockiert werden.
Dafür muss der ISP kontaktiert werden, um einen PTR-Record für den Mail-Server einrichten zu lassen.
In der tatsächlichen Deployment-Umgebung wurden E-Mails auch ohne PTR-Record von Gmail, GMX und Outlook korrekt empfangen, und bei mail-tester.com wurde eine Bewertung von 10/10 erreicht.
Wegen des fehlenden PTR-Records gab es zwar einen Abzug, dafür wurde jedoch durch „trusted relay“ wieder aufgewertet.
Da die IP auch auf keiner Blacklist stand, war die Vertrauenswürdigkeit der Versand-IP ebenfalls gut.
Gmail-Übertragungstest
Mit dem sendmail-Befehl wurde eine Testmail als HTML-Nachricht an Gmail gesendet.
Die E-Mail kam bei Gmail sofort an, und die TLS-Verschlüsselung wurde bestätigt.
In Gmail zeigte „Show original“, dass SPF-, DKIM- und DMARC-Authentifizierung erfolgreich bestanden wurden.
Mit mailx lässt sich lokal auf dem Server prüfen, welche E-Mails eingegangen sind.
Wenn es Konfigurationsprobleme gibt, sollten DNS, Zertifikate und Zugriffsrechte auf die DKIM-Schlüssel erneut überprüft werden; insbesondere reagieren die Konfigurationsdateien von OpenDKIM empfindlich auf Tippfehler.
Nächste Schritte
Im nächsten Beitrag soll gezeigt werden, wie sich E-Mail-Anwendungen mit Python erstellen lassen.
Fragen oder Anmerkungen können an max@idx.cy geschickt werden.
1 Kommentare
Hacker-News-Kommentare
Ich bin ein wenig stolz darauf, seit über 20 Jahren mein E-Mail-System selbst zu hosten, und habe vor, das auch weiterhin zu tun. Ironischerweise können weder Regierungen noch zuständige Behörden ihre eigenen E-Mail-Systeme betreiben; nur nationale Sicherheitsbehörden hosten noch selbst. Vielleicht hatte ich einfach Glück, aber Probleme beim Versand hatte ich fast nie. Der letzte Fall, an den ich mich erinnere, war, dass Microsoft meine Mails verschluckt hat; das lag an einer TLS-Authentifizierungsinkompatibilität zwischen einem alten exim und Outlook. Mit einer kleinen Konfigurationsanpassung ließ sich das beheben. Die Wartung hält sich sehr in Grenzen, und jedes Mal, wenn ich etwas anfasse, sehe ich es als Gelegenheit, etwas Neues zu lernen. Dieses Jahr habe ich Debian jessie durch Arch Linux ersetzt und Cron-Jobs vollständig auf systemd-Timer umgestellt. Wenn ich wichtige Mails versende, prüfe ich unbedingt die Server-Logs, aber ich halte das ohnehin für eine gute Gewohnheit. Mein Rat wäre: Es ist viel besser, wenn man Self-Hosting als Hobby betrachtet und Freude daran hat. Und zuletzt: Die Person, die sich die Exim-Konfiguration unter Debian ausgedacht hat, hat mir viel Zeit verschwendet. Wenn man Exim unter Debian aufsetzt, ist es am besten, auf die offizielle Upstream-Konfiguration umzusteigen und sie dann an die eigenen Bedürfnisse anzupassen
Heutige soziale Netzwerke betonen gern, wie „dezentralisiert“ oder „offen“ sie seien, aber in Wahrheit haben wir längst Werkzeuge, mit denen wir völlig unabhängig und autark sein können. Unter dem Vorwand besserer UX wird oft übersehen, dass dabei die Kontrolle der Nutzer verloren geht. Wenn wir uns erst einmal an übermäßig vereinfachte Systeme gewöhnt haben, landen wir am Ende in einer Zukunft, in der man nicht einmal mehr eine App installieren kann, wenn jemand in einem fernen Land die „Transaktion“ nicht erlaubt
Ich habe E-Mail zum ersten Mal an der Universität benutzt, noch vor dem WWW, und später hatte ich dann nur noch ein ISP-Konto mit sehr begrenztem Speicher und ausschließlich POP-Unterstützung, weshalb ich anfing, meinen eigenen Mailserver zu betreiben. Damals war ich nicht ständig mit dem Internet verbunden, deshalb habe ich mit Relay und dynamischem DNS Mails empfangen. Heute nehme ich Mails über einen VPS an und speichere sie auf einem Heimserver. Im Laufe der Jahre musste ich zwar einige Male große Mailanbieter wie Outlook bitten, eine IP oder Domain zu entsperren, aber das kam nicht besonders oft vor. Ich möchte nicht in einer Welt leben, in der nur zwei oder drei Unternehmen die globale E-Mail beherrschen, daher sehe ich Self-Hosting als eine kleine Form des Widerstands
Ich wünschte, ich hätte noch wenigstens 1 % der Motivation von vor 20 Jahren. Heute habe ich wegen Vollzeitjob und Familie, also Ehefrau und Kindern, einfach keine Zeit mehr für solche Dinge
Auch ich habe Self-Hosting eine Zeit lang gemieden, aber da sich das Verhältnis von Zeit und Kosten verändert hat, überlege ich, ob es sich wieder lohnt. Mein größtes Thema beim E-Mail-Hosting ist Spam-Management. Wie sieht das heute aus, und falls jemand Tipps hat, würde ich mich freuen
Für mich ist E-Mail ein sehr wichtiger Dienst. Ich habe 15 Jahre lang selbst gehostet und dann aufgehört, weil 1) regelmäßige Backups/Wiederherstellung und Monitoring nicht gut genug liefen, 2) ich ohne Disaster-Recovery-Plan am Ende höhere Kosten hatte als bei anderen Diensten und 3) ich die Sicherheit nicht dauerhaft im Blick behalten konnte. Der Server eines Freundes wurde von Ransomware getroffen und alle Daten waren weg, während ich mit FreeBSD verschont blieb, einfach weil es kein Ziel war. Im Allgemeinen ist die Wartung nicht allzu komplex, aber wenn etwas schiefläuft, kann es wirklich unerquicklich und im schlimmsten Fall fatal werden
Früher habe ich E-Mail selbst gehostet, aber nicht wegen Reputation aufgegeben, sondern weil man 100 % Verfügbarkeit faktisch nicht vermeiden kann und damit das Risiko von Mailverlust oder Blacklisting entsteht. Laut Protokoll ist E-Mail eigentlich robust gegenüber Ausfällen, aber in der Praxis lehnen große E-Mail-Anbieter bei nur einem Problem Mails sofort ab und versuchen es nicht erneut. Früher hat sogar GitHub nach einem einzigen Bounce einen Empfänger als „nicht erreichbar“ markiert und danach gar nichts mehr gesendet. Inzwischen ist das besser, aber moderne E-Mail-Systeme gehen faktisch von „always online“ aus
Mein Mailserver nutzt absichtlich Graylisting und lehnt die erste eingehende Mail eines Absenders zunächst ab. Ich habe unzählige Mails empfangen und noch nie erlebt, dass legitime Mail deshalb dauerhaft nicht zugestellt wurde. Wiederholungsversuche sind im E-Mail-Standard eingebaut, und wer sich Sorgen macht, kann zusätzlich einen Backup-Empfangsserver betreiben und per LMTP zurückleiten. Das gesamte E-Mail-System wurde ursprünglich für eine Zeit entworfen, in der man nicht rund um die Uhr online war
Solche Aussagen sind übertrieben. Bei mir kamen Mails, die zunächst nicht ankamen, nach ein paar Stunden oder einem Tag doch noch an, und im Allgemeinen gibt es keine Möglichkeit zu erfahren, wo genau etwas schiefgelaufen ist. Wenn die Authentifizierung sauber eingerichtet ist, etwa dkim und spf, kann man auch mit Self-Hosting eine Zustellbarkeit von über 99 % erreichen. Man sollte sich von der Komplexität nicht einschüchtern lassen. Als Bonus kann man auch caldav privat nutzen
Ich frage mich, warum man sich bei ein paar Stunden Serverausfall gleich Sorgen um „Mailverlust“ macht. Mein Server läuft seit 219 Tagen durchgehend. Im Vergleich zu dem, was wir sonst so tun, ist der Betrieb eines Mailservers wirklich einfach
Wenn man sich heutige E-Mail-Systeme ansieht, fragt man sich wirklich: „Was habt ihr meinem Sohn angetan?“
Mein Rat an alle, die mit selbst gehosteter E-Mail anfangen wollen: Nutzt zunächst eine selbst gehostete Adresse nur für Account-Anmeldungen. Ihr müsst sie nicht sofort für persönliche Kommunikation verwenden. Mit „Mail-in-a-box“ https://mailinabox.email./ kann man anhand der Installationsanleitung in wenigen Stunden etwas Funktionsfähiges aufsetzen. Nutzt das ein bis zwei Jahre lang, und erst wenn ihr euch wirklich sicher fühlt, solltet ihr persönliche Kommunikation dorthin umziehen
Ich empfehle Stalwart https://github.com/stalwartlabs/stalwart. Es ist ein vollständiger Maildienst in einer einzigen Binärdatei, also ohne Abhängigkeiten, und Installation sowie Updates sind extrem einfach. Ich habe viele andere Projekte ausprobiert, aber Stalwart war am unkompliziertesten und läuft völlig problemlos
Ich betreibe MIAB seit Jahren in der Cloud. Solange die IP-Reputation sauber ist, gibt es beim Versand keine Probleme, aber wenn E-Mails an Outlook nicht ankommen, löse ich das, indem ich Microsoft postmaster direkt anschreibe. Da man dabei Dinge wie DKIM/SPF/DMARC einrichtet und versteht, ist es zum Lernen sehr empfehlenswert. Allerdings ist der Empfang von Registrierungs-E-Mails wirklich schwierig. Das Graylisting von MIAB lehnt unbekannte Erstabsender ab und wartet auf einen erneuten Zustellversuch, aber selbst legitime Websites versuchen oft nicht noch einmal zuzustellen. Authentifizierungs- oder 2FA-Codes kommen dann mit großer Verzögerung an, und es gibt auch keine einfache Möglichkeit, den Spamfilter vorübergehend zu deaktivieren
Auch von ISPs bereitgestellte E-Mail und sogar Google Gmail haben heutzutage gelegentlich Probleme mit Spamfilterung und Ähnlichem. Zum Beispiel werden Shopify-Mails bei Bestellungen über Shopify in Gmail immer wieder als Spam eingestuft. Sogar wenn DMARC, SPF und DKIM alle bestehen, ist nicht klar, warum das passiert. Das eigentliche Senden und Empfangen von E-Mails ist technisch nicht so schwierig, und kein Dienst ist zu 100 % perfekt. Es gibt einfach so viele böswillige Nutzer, also Spammer, dass es fast erstaunlich ist, dass das System überhaupt so gut funktioniert
DMARC, SPF und DKIM sind nur Authentifizierungsmechanismen und stehen nicht in direktem Zusammenhang damit, ob etwas Spam ist. Es gibt korrekt authentifizierten Müll und schlecht oder gar nicht authentifizierte Nachrichten, die dennoch wertvoll sind
Dass Shopify-Mails als Spam klassifiziert werden, liegt daran, dass viele Menschen Shopify als Spam markieren oder dass auf gemeinsam genutzten Mailservern Nutzer mit schlechter Reputation sitzen. Selbst wenn ich sie immer wieder als „kein Spam“ markiere, kommt man aus dem Spamordner nicht heraus, wenn die Gesamtreputation des Absenders zu schlecht ist
Ich hoste E-Mail seit ungefähr 20 Jahren selbst. Zehn bis fünfzehn Jahre lang habe ich alle Mails an Gmail weitergeleitet, aber weil ich die Spamfilter satt hatte, die sogar wichtige Mails verschwinden ließen, habe ich angefangen, meinen eigenen imapd zu betreiben. Wenn Dinge wie SPF sauber konfiguriert sind, fühlt sich Self-Hosting für mich deutlich besser an
Genau solche Filterrichtlinien sind das Problem. Wenn man selbst hostet oder kleine E-Mail-Dienste nutzt, ist die Wahrscheinlichkeit sogar deutlich geringer, dass Mails blockiert werden, vor allem durch strenge Filter wie die von Gmail. Google hält an aggressiven Filterrichtlinien fest, obwohl unter Gmail-Nutzern selbst besonders viele Spamverursacher sind
Der Spamfilter von Gmail reagiert derzeit überempfindlich auf Marketing-Mails. Vor zehn Jahren war eher das Gegenteil das Problem, heute landet dagegen zu viel im Spamordner, was eher lästig ist. Ein großer Teil des heutigen Spams sind vielmehr Cold-E-Mails von kleinen, neuen Absenderadressen. Bei Marketing-Mails funktioniert in Gmail die „Abbestellen“-Funktion gut, bei solchen Cold-Mails hilft das aber nicht
Wer ein solides Setup und einen IMAP-Server möchte, der mit vielen Clients gut zusammenspielt, ist mit der Anleitung https://workaround.org/ispmail-bookworm/ besser bedient. Ich selbst betreibe es bewusst einfach mit Klartextdateien statt mit einer Datenbank. Wenn man der einzige Nutzer ist, funktioniert das gut, und die Anleitung lässt sich auch problemlos auf größere Unternehmensumgebungen skalieren
Kurzer Hinweis in eigener Sache: Wir testen gerade Hyvor Relay https://github.com/hyvor/relay in der Beta als selbst gehostete Alternative. Der Fokus liegt auf Sichtbarkeit, etwa durch DKIM/SPF-Monitoring und DNS-Automatisierung. Mit einem einzigen
docker compose upist es sofort einsatzbereit https://relay.hyvor.com/hosting/deploy-easyIch hoste E-Mail seit 10 bis 15 Jahren selbst auf einer günstigen kimsufi-Box mit opensmtp, dovecot und rspamd. Große Probleme hatte ich nie; einmal wurde mein Server bei telekom.de blockiert, aber nachdem ich das per offizieller Mail erklärt hatte, wurde ich sofort auf die Whitelist gesetzt. Vielleicht liegt es daran, dass ich die IP schon lange habe, aber die Probleme, von denen alle immer sprechen, hatte ich persönlich nicht. Allerdings gehören mir Server und IP auch selbst und laufen auf meinen Namen
Ich habe auf https://krei.se/Doc einen deutschsprachigen Artikel über selbst gehostete E-Mail auf Basis von Debian trixie veröffentlicht. Wenn man es einmal sauber aufsetzt, macht es wirklich Freude. Dank automatischer Updates und Reboots sowie angepasster systemd-Dienste bekomme ich jeden Tag per Mail Statusberichte. Zwei bis drei Jahre, mit trixie sogar bis zu fünf Jahre, muss man praktisch nichts anfassen. E-Mail-Serversoftware ist längst ausgereift. Ich kann Self-Hosting nur empfehlen. Autonomie, Ruhe und direkte Kontrolle sind wirklich wertvoll
Ich betreibe seit über 10 Jahren meine eigene E-Mail-Infrastruktur und habe dazu früher auf HN schon öfter Kommentare hinterlassen, die ich verlinke, etwa 39891262 und 38471262. Weil Digital-Ocean-IP-Adressen als bösartig eingestuft wurden, habe ich den Versand durch Amazon SES ersetzt und nutze Gmail als kostenlosen Spam-Trainingsdienst für meine eigenen Filter (38843288). Wie viele hier schon erwähnt haben, hilft Graylisting enorm. Legitime Mailserver versuchen immer erneut zuzustellen, daher ist es zwar für 2FA unbequem, systemisch aber verlässlich. Selbst ein paar Tage Ausfall sind kein Problem, und wenn man Empfang und Speicherung trennt, sind auch Backups einfach (38512732). Für 2FA-Mails nutze ich zusätzlich https://github.com/stevejenkins/postwhite, aber ehrlich gesagt würde ich E-Mail nicht für 2FA empfehlen; das ist ein eigenes Thema
Kürzlich konnte ich eine wichtige über Amazon SES versandte Mail wegen einer Sperrliste von bl.spamcop.net nicht empfangen. Amazon hat über mehrere IPs erneut versucht zuzustellen und ist dabei auf Graylisting gestoßen, sodass am Ende doch ein Versuch abgewiesen wurde. Zwischen großen Anbietern, also von MX zu MX, mag das weniger problematisch sein, aber auch diese Konstruktion ist keine 100-%-Lösung
Wenn man am Ende so lange darüber redet, scheint das Fazit doch zu sein, dass man besser einfach Gmail oder einen anderen großen E-Mail-Dienst nutzt
Wo ist UUCP, warum ist die Adresse kein Bang-Path, und wo ist sendmail.cf?
Genau. Wenn man wirklich wie 1984, also im Stil klassischer E-Mail-Systeme, selbst hosten wollte, würde man einen Open Relay betreiben, der alles weiterleitet, und sich damit allen möglichen Schwachstellen aussetzen
Wenn wir schon in Erinnerungen schwelgen: Ich erinnere mich daran, wie in einem Uni-Labor mit sechs Unix-Workstations E-Mails von einem Server zum nächsten wanderten und man am Geräusch der Festplatten hören konnte, dass gerade Post unterwegs war
Beim Titel musste ich auch sofort an Bang-Paths und Adressen wie „killer!jolet!“ denken. Wirklich nostalgisch
Sehe ich genauso. Ich bin wegen des Titels „1984“ hereingekommen und war dann enttäuscht, dass es am Ende nur um „postfix-Konfiguration“ ging