© zmeika / 123RF.com

Die E-Mail ist im Internet nach wie vor das mit Abstand beliebteste Kommunikationsmedium. Wer seine Mails nicht an Konzerne abtreten möchte, muss einen eigenen Mailserver betreiben. Ihn sinnvoll abzusichern, macht einige Mühe.

Den Erfolg der E-Mail hätten sich wohl selbst ihre Erfinder in ihren kühnsten Träumen nicht auszumalen getraut: Seit über 40 Jahren schicken sich Menschen rund um den Globus digitale Nachrichten. An etlichen Stellen merkt man der E-Mail an, dass sie für ihren heutigen Ruhm nicht konzipiert war. Anfangs gab es im Internet nur wenige Teilnehmer, der größte Teil davon waren Wissenschaftler. Es verstand sich von selbst, dass man sich bei der Kommunikation nicht als jemand anderes ausgab oder gar versuchte, andere zu schädigen. Mit dem Erfolg der E-Mail kam aber auch das Interesse von Gaunern und Banditen. Plötzlich florierten unliebsame Werbenachrichten, handfeste Betrugsversuche, gefälschte Absenderadressen und viele weitere Unarten.

Seither sehen sich Vereinigungen wie die IETF, die die gültigen Standards für das Internet definiert, in einer Art Spirale gefangen: Immer wieder müssen sie die Standards für E-Mails erweitern und mit Pflastern versehen, um mit neuer Technologie Designfehler des Protokolls auszubügeln. Es einfach abzuschaffen und durch etwas komplett Neues zu ersetzen, ist keine Option: Eine derartige weltweite Umstellung wäre kaum zu organisieren. So leben die Netzteilnehmer mit der E-Mail und ihren Nachteilen, in unterschiedlichen Leidensstufen.

So manche kleinere Firma lagert das Problem an Dienstleister wie Microsoft oder Google aus, die mittlerweile ein gerüttelt Maß an Erfahrung im Umgang mit E-Mails haben. Andere Unternehmen möchten die Kontrolle über ihre Daten nicht aus der Hand geben. Sie haben wohl oder übel keine andere Möglichkeit, als ihre Mailserver selbst zu betreiben. So mancher Admin stellt erst mitten im Vorgang fest, dass das keinesfalls aus der Hüfte klappt, sondern penible Planung und perfekte technische Umsetzung voraussetzt. Das gilt umso mehr, wenn das Thema Sicherheit der E-Mails eine Rolle spielen soll: Dabei gibt es etliche Faktoren zu beachten.

Das beginnt bereits beim Mailserver selbst: Es gilt, den Dienst so zu sichern, dass Angreifer ihn nicht mit wenigen Handgriffen übernehmen und missbrauchen können. Wer nicht im Handumdrehen auf irgendwelchen Grey- oder Blacklists landen will, braucht heute eine funktionierende Validierung für die eigene Domäne. Der Transport von E-Mails zwischen Client und Server sowie zwischen Mailservern, die Mails untereinander weiterleiten, muss ebenfalls sicher gestaltet werden. Daneben spielt das Thema Spam eine Rolle, schließlich verteilen Cyberkriminelle ihre Schadsoftware bevorzugt per E-Mail. Man muss sich also um funktionierende Spam- und Malware-Filter kümmern.

Steht man als Administrator vor der Aufgabe, ein neues Mailserver-Setup zu bauen, fühlt man sich deshalb nicht selten plan-, wenn nicht sogar mutlos. Das muss nicht sein: Mit jeder gängigen Linux-Distribution lässt sich heute ein stabiler und zuverlässiger Mailserver betreiben – vorausgesetzt, man weiß, was man tut. Dieser Artikel listet die grundsätzlichen Überlegungen auf, die beim Absichern von Mailservern eine Rolle spielen oder das Drumherum betreffen.

Voraussetzungen

Wer bereits mit dem Betrieb von Mailservern zu tun hatte, weiß: Für kaum eine Aufgabe gibt es so viele Wege, die nach Rom führen. Zwar findet man heute Sendmail in freier Wildbahn kaum noch – sehr zum Glück, wie mancher leidgeplagte Admin wohl anfügen würde. Auch ohne den Oldtimer ist der Markt der Mailserver allerdings unübersichtlich, und zwar auch dann, wenn man den Fokus auf Linux legt und die zahllosen Microsoft-Exchange-Setups außen vor lässt. Das macht nötig, ein paar Voraussetzungen zu definieren, insbesondere im Hinblick auf die zu nutzende Software.

Weitverbreitet ist mittlerweile Postfix, das sowohl in Sachen Features als auch in Sachen Sicherheit auf der Höhe der Zeit liegt. Betreiben lässt der Dienst sich auf jeder aktuellen Enterprise-Distribution; für unser Beispiel gehen wir im Folgenden von Ubuntu 22.04 aus. Sämtliche Tipps können Sie allerdings auch auf andere Distributionen übertragen. Als Werkzeug zum Filtern von Mails kommt ClamAV im Gespann mit SpamAssassin zum Einsatz. Wo Maßnahmen im Hinblick auf Nameserver nötig sind, verzichten wir hier auf konkrete Kommandos oder Anweisungen und raten Ihnen stattdessen dazu, sich mit den üblicherweise ohnehin separat dafür verantwortlichen DNS-Administratoren kurzzuschließen.

Aller Anfang

Gegeben sei also ein frisch installiertes Ubuntu 22.04, auf dem künftig ein Mailserver beheimatet sein soll. Bevor Sie sich des eigentlichen Mailservers annehmen, steht zunächst das Härten des Systems selbst auf dem Programm. Hier gelten die üblichen Regeln: Den Zugriff auf das System sollten Sie auf so wenige Menschen beschränken wie möglich. Gibt es im Unternehmen bereits eine zentrale Benutzerverwaltung, empfiehlt es sich unbedingt, den Mailserver daran anzuschließen: So können Sie Accounts zentral aktivieren und deaktivieren.

Ein Mailserver lässt sich üblicherweise nicht ohne viel Bastelei in der Firewall ohne direkten Zugang zum Internet zu betreiben. Wenn er aber schon von außen erreichbar sein muss, sollten Sie zumindest den Zugriff von außen auf alle nicht relevanten Ports einschränken. Konfigurieren Sie insbesondere die Firewall oder den Host selbst so, dass er keinen Zugriff auf den Port 22 – also SSH – erlaubt. Die Ports 25 und 587 sollten jedoch offen sein. Falls Sie vorhaben, auf dem System auch IMAP zu betreiben, setzt das den Zugriff auf die Ports 143 und 993 voraus. Darüber hinaus gelten für die Sicherheitsmaßnahmen auf Mailservern dieselben Grundregeln wie für alle anderen Server. Nutzen Sie beispielsweise Ubuntu, sollten Sie Apparmor lieber richtig konfigurieren, statt es pauschal abzuschalten. Ähnliches gilt für SELinux auf RHEL.

Danach stehen die Sicherheitseinstellungen des Mailservers selbst auf der Agenda. Es verbietet sich quasi von selbst, den Mailserver – wie das klassische Mail-Protokoll es durchaus vorsieht – ohne Benutzerverwaltung zu betreiben. Stattdessen sollten Sie den Versand von E-Mails unbedingt an eine erfolgreiche Authentifizierung durch den Client knüpfen. Das Problem ist in der Linux-Welt längst gelöst, aber längst nicht überall im Einsatz. Konkret geht es um den Simple Authentication and Security Layer alias SASL. SASL ist ein Brückenkonstrukt und fungiert als Mittler zwischen dem Mailserver einerseits und einer Vielzahl möglicher Authentifizierungs-Backends auf der anderen Seite.

In der Regel verwalten Unternehmen heute auch ihre Kundendaten in irgendeiner Form von Verzeichnisdienst, meist Active Directory oder LDAP. Für LDAP existiert ein SASL-Plugin, das den Mailserver an das Benutzerverzeichnis anschließt. Über dessen LDAP-Kompatibilitätsschnittstelle lässt sich das LDAP-Backend von SASL auch an Active Directory koppeln. Der Mühe Lohn: E-Mails darf nur versenden, wer einen aktiven und gültigen Account im Benutzerverzeichnis hat. Das Prozedere gibt es übrigens auch in anderer Form: Haben Sie Ihr System über PAM an LDAP angebunden, können Sie SASL auch einfach an PAM anschließen und erben so indirekt die LDAP-Benutzer.

Dienste einhegen

Die Sache mit SASL und LDAP macht die Konfiguration von Postfix allerdings etwas komplizierter. Die meisten Linux-Distributionen, so auch Ubuntu, sperren Postfix mittlerweile in eine eigene Chroot-Umgebung. Dabei handelt es sich um eine sehr oberflächliche Form der Virtualisierung: Ein mittels Chroot eingesperrter Prozess betrachtet den Ordner im Dateisystem, der als Grundlage für Chroot dient, als Wurzelordner des eigenen Dateisystems.

Vom Prinzip her funktioniert das ähnlich wie ein Container, auch wenn ein Chroot anders als echte Container keine eigenen Namespaces für Prozess-IDs oder die Netzwerkschnittstellen zur Verfügung stellt. Zusätzliche Sicherheit bietet das Chroot für Postfix trotzdem: Ein erfolgreicher Angriff auf den Mailserver verhindert bei aktivem Chroot, dass der Angreifer sofort Zugriff auf das Dateisystem des Hosts erhält. Das kann er des Chroots wegen schlicht nicht sehen.

Kommt Chroot zum Einsatz, müssen allerdings alle Dateien, auf die Postfix zugreifen soll, auch innerhalb der Chroot-Umgebung liegen. In der Standardkonfiguration betrifft das beispielsweise den Socket, den der zu SASL gehörende Daemon für die Kommunikation mit seinen Clients nutzt. Fertige Lösungen für das Problem gibt es erfreulicherweise zuhauf. So lässt sich etwa SASL so konfigurieren, dass es seinen Socket innerhalb des Chroot-Verzeichnisses von Postfix ablegt. Das ist auch die empfohlene Konfiguration.

Apropos Konfiguration: Sie erleichtern sich das Leben erheblich, wenn Sie für die Konfiguration des Mailservers auf Automation setzen. Ansible lässt sich auch für einzelne Systeme schnell in Betrieb nehmen, vorgefertigte Ansible-Rollen für Postfix auf Ubuntu gibt es im Netz reichlich. Setzen Sie auf Ansible oder einen anderen Automatisierer, bekommen Sie quasi zum Nulltarif alle Vorteile der Automation und reduzieren die Anfälligkeit für Flüchtigkeitsfehler. Sie sorgen damit sogar für den Notfall vor, denn selbst wenn ein System einem Angriff zum Opfer fallen und als kompromittiert gelten sollte, lässt sich aus einer fertigen Automation heraus ein Ersatz schnell aufsetzen.

Ähnliche Überlegungen gelten übrigens, wenn dieselbe Maschine zugleich auch als IMAP-Server dienen soll. Dovecot empfiehlt sich hier als Quasi-Standard und bietet vergleichbare Sicherheitsoptionen wie den Betrieb in einem Chroot. Möchten Sie die Clients gleich noch mit auf demselben System abhandeln, etwa mittels eines Webmail-Clients, greifen Sie zu Werkzeugen wie Roundcube (Abbildung 1). Achten Sie idealerweise aber auch hier darauf, die grundlegenden Details in Sachen sicherer Systemadministration zu berücksichtigen.

Abbildung 1: Wer einen Mailserver-in-a-Box bauen möchte, findet in Form von Roundcube eine gute und sichere Methode, einen webbasierten Client anzubinden. Quelle: Roundcube

Sofern Sie den Umgang mit Containern nicht scheuen, haben Sie noch eine weitere Möglichkeit, Dovecot sowie Postfix zu härten: Indem Sie die Dienste in Containern laufen lassen, unter Ubuntu üblicherweise in Form von Docker-Containern (Abbildung 2). Benötigte Verzeichnisse wie das Datenverzeichnis für Dovecot, über das der Dienst auf Mails zugreift, integrieren Sie per Bind-Mount in das Konstrukt. Dovecot und Postfix laufen dann komplett vom System separiert, was auch Merkmale wie Hochverfügbarkeit leichter macht. Im Zweifelsfall genügt es, den jeweiligen Container von einem Host auf einen anderen zu schieben und dabei die IP-Adresse mitzunehmen. Der zugegebenermaßen etwas ungeliebte Cluster-Manager Pacemaker bietet das relativ unkompliziert an.

Abbildung 2: Wer seine Mail-Dienste im Container betreibt (wie hier mit Rspamd und Postfix), zieht eine zusätzliche Sicherheitsebene ins System ein, die Einbrechern den Durchgriff erschwert.

Der Königsweg liegt darin, Containerisierung und Automation zu kombinieren. Automatisch ausgerollte Container, die Ansible oder eine Alternative gleich auch mit der passenden Konfiguration versehen, kommen nahe an das Ideal der unzerstörbaren Infrastruktur heran und lassen Sie dadurch ruhiger schlafen.

Im Netz finden sich komplementär zu diesem Artikel zahllose Anleitungen, die Ihnen einen guten Überblick über die sinnvollsten Konfigurationsdirektiven für Postfix verschaffen. Dazu gehört etwa, dass Postfix Clients ablehnt, die den Versand von E-Mails nicht mit EHLO beginnen: Das sind entweder unsauber programmierte Clients oder Spammer. Für den Alltag nützliche Kleinigkeiten wie diese gibt es zuhauf, aber selbst so mancher passionierter Mail-Admin kennt nicht alle.

Das Medium absichern

Wer als Administrator Postfix und Dovecot automatisiert in Container-Form ausrollt und mit der richtigen Konfiguration versorgt, hat zwar schon etwas geleistet, doch ist es noch zu früh, die Füße hochzulegen. Bei Mailservern steht nicht nur die Sicherheit des Diensts im Fokus, sondern auch die des Versands und Empfangs von Nachrichten. Die eingangs beschriebenen Unsitten im Hinblick auf die E-Mail haben dafür gesorgt, dass Sie eben nicht nur den Mailserver brauchen, sondern auch eine passende DNS-Konfiguration, eine Spam-Abwehr und eine sichere Verbindung zu den Clients und anderen Mailservern.

Ähnlich wie für Webserver gilt heute auch für Mailserver, dass sie besser nicht im Klartext mit irgendeiner Gegenseite kommunizieren. Jeder, der Zugriff auf die Netzwerkverbindung zwischen den Servern hat, könnte dann übermittelte Nachrichten im Klartext lesen. Sinnvoller ist es, den Mailserver mit SSL zu betreiben oder ihm zumindest einen SSL-Terminator voranzustellen. Wie man das am besten erledigt, hängt vom jeweiligen Setup ab.

Betreiben Sie Ihren Mailserver ohnehin in Form von Containern, können Sie für diese Aufgabe sogar einen Mesh-Dienst wie Istio benutzen. Der terminiert SSL-Verbindungen und kümmert sich komplett autark um das Thema, sodass Postfix selbst erst gar keine SSL-Konfiguration benötigt. Läuft Postfix stattdessen als Dienst direkt auf dem System, lässt er sich mit wenigen Arbeitsschritten SSL-fähig machen. Dann sollten Sie allerdings darauf achten, den Empfang und den Versand von E.Mails über die unverschlüsselten Kanäle zu deaktivieren.

Ähnliches gilt für ein drittes denkbares Szenario, indem ein dem Mailserver vorangestellter Load Balancer sich um das Thema SSL kümmert. Aber Achtung: Möchten Sie DANE nutzen, muss der Mailserver zwingend STARTTLS unterstützen. Dann kommen Sie nicht umhin, ihn selbst mit einem SSL-Zertifikat auszurüsten. Der Verbindungsaufbau geschieht bei STARTTLS immer unverschlüsselt, erst die Kommunikation nach dem STARTTLS-Befehl erfolgt verschlüsselt.

Empfangen und versenden

Beim Versand gilt es, gegenüberliegende Mailserver von der Authentizität einer versendeten E-Mail zu überzeugen. Wie eingangs beschrieben, sah die E-Mail in ihrer ursprünglichen Form überhaupt keine Maßnahmen vor, die den Versender einer Mail dazu gezwungen hätten, eine bestimmte Absenderadresse zu verwenden. Das öffnet Missbrauch Tür und Tor und sorgte letztlich für das Entstehen mehrerer halboffizieller Techniken, von denen einige mittlerweile als offizielle Internet-Standards gelten.

Mit zu den einfachsten Methoden gehört dabei SPF (Abbildung 3), das in keinem ernst zu nehmenden E-Mail-Setup fehlen darf. Vereinfacht ausgedrückt, hinterlegt SPF in einem TXT-DNS-Eintrag für eine Domäne, welche Server E-Mails mit dieser Domäne als Absender verschicken dürfen. Ihren eigenen DNS-Server sollten Sie also so einrichten, dass im SPF-Eintrag für die eigene Domäne auch wirklich nur der eigene Mailserver steht. Umgekehrt sollte der eigene Postfix die SPF-Einträge von gegenüberliegenden Servern prüfen und E-Mails ablehnen, wenn sie von einer anderen Adresse kommen als der im SPF-Eintrag.

Abbildung 3: Branchenprimus Google macht es vor: Mittels SPF-Einträgen lässt sich der Missbrauch von Absenderdomänen gut unterbinden.

In dasselbe Horn stößt DKIM (DomainKeys Identified Mail): Dabei hinterlegen Sie in einem weiteren TXT-Eintrag der Domäne den öffentlichen Teil eines kryptografischen Schlüssels. Beim Versand von E-Mails errechnet der Server dann den Hash-Wert des Inhalts der E-Mail und fügt die digitale Signatur vor dem Versand in die Header-Felder der Mail ein. Der empfangende Mailserver kann dann den Inhalt der Mail auf Grundlage des öffentlichen Schlüssels des versendenden Mailservers sowie der digitalen Signatur überprüfen. Passen Signatur und Schlüssel zusammen, nimmt DKIM an, dass der versendende Server authentisch ist, und akzeptiert die Mail. Ansonsten weist er sie zurück. Wie SPF hat DKIM sich zu einem gängigen Werkzeug im alltäglichen Mail-Verkehr entwickelt, das Missbrauch vorbeugt und entsprechend in keiner Mailserver-Konfiguration fehlen sollte.

DMARC, DANE und mehr

Die dritte Technologie im Bunde ist etwas umstrittener: Domain-based Message Authentication, Reporting and Conformance oder kurz DMARC. Auch dazu hinterlegen Sie einen TXT-Eintrag im DNS-Server Ihrer Domäne. Der fällt allerdings deutlich komplexer aus als bei SPF und DKIM, die DMARC sogar inkorporiert. Zusätzlich zu den Abgleichsmodi für DKIM und SPF enthält ein DMARC-Eintrag für eine Domäne konkrete, standardisierte Anweisungen im Hinblick auf etwa das Weiterleiten von Mails. Werden sie verletzt, weist ein DMARC-aktivierter Mailserver die Mail komplett zurück.

Das führt im Alltag gelegentlich zu Problemen, weil durch DMARC auch der Versand eigentlich legitimer Mails fehlschlagen kann. Mailing-Listen etwa fußen auf dem Prinzip, Mails vom Sender an viele Empfänger weiterzuleiten. Wer schon einmal eine E-Mail von einer Mailing-Liste bekommen hat, in der statt des ursprünglichen Autors als Absender die Mailing-Liste selbst mit Benutzer via … in der From-Zeile steht, kennt nun den Grund: Solche Konstrukte sind nötig, damit DMARC funktioniert. Ob der insgesamt katastrophalen Flut von Spam hat auch DMARC sich mittlerweile allerdings weitgehend etabliert, und neue Mailserver sollten darauf möglichst nicht verzichten.

Etwas fernab der anderen drei Lösungen steht schließlich DANE, die DNS-based Authentication of Named Entities. DANE hat mit der Authentifizierung von Absendern nichts zu tun, sondern erzwingt aus Absendersicht die Verwendung einer SSL-verschlüsselten Verbindung. Dazu macht es sich DNSSEC zunutze, jenen Standard, der die Authentizität von DNS-Einträgen durch digitale Signaturen absichern soll und dabei ein ähnliches Problem zu lösen versucht wie DKIM. Auch DNS ist ein uraltes, in seiner ursprünglichen Form gegen Missbrauch kaum geschütztes Protokoll.

DNSSEC bessert das nach: Es sorgt via DANE dafür, dass ein entfernter Mailserver nur dann für die Zustellung einer Mail an eine bestimmte Domäne infrage kommt, wenn sein signierter DNS-Eintrag den Aufbau einer SSL-verschlüsselten Verbindung mittels STARTTLS explizit ermöglicht. Tut er das nicht, bricht der ausgehende Mailserver den Versand sofort ab. Das verhindert Angriffe nach dem Man-in-the-Middle-Prinzip und kann sogar ein Baustein sein, um das eigene Setup etwas konformer mit der DSGVO zu machen. Daher sollte es bei neuen Mailservern Standard sein. Dafür muss man notgedrungen die Kröte schlucken, dass Mails mangels DANE auf der Empfängerseite möglicherweise nicht zugestellt werden können.

Schließlich gibt es noch TLS-RPT, das in ein ähnliches Horn stößt wie DANE. Es gilt mittlerweile selbst als anerkannter Standard und geht mit modernerer Technik zu Werke. Stark vereinfacht dargestellt, prüft ein ausgehender Mailserver bei der Verwendung von TLS-RPT, ob der MTA auf der Gegenseite das STARTTLS-Kommando unterstützt. Falls ja, verschlüsselt er die E-Mail via TLS und schickt sie an die Gegenseite, wo sie ausgepackt und zugestellt wird. TLS-RPT erzwingt damit eine Verschlüsselung der zu übermittelnden Inhalte. Es weist insbesondere die im Netz häufig zu findenden Clients ab, die durch einen Trick während des Bestehens einer Verbindung versuchen, die Kommunikation von der verschlüsselten Variante auf eine Klartextverbindung herabzustufen. Das Muster kommt insbesondere bei Betrugsversuchen bis heute regelmäßig zur Anwendung.

Darüber hinaus spielt bei TLS-RPT das Reporting (RPT steht für Report) eine wichtige Rolle: Der Administrator eines Servers erhält bei aktivem TLS-RPT regelmäßige Berichte über Vorkommnisse (Abbildung 4), bei denen etwa ein Client wie beschrieben einen Betrugsversuch unternommen hat. Das hilft dabei, Fehlfunktionen und verpasste E-Mails frühzeitig zu erkennen und nötigenfalls durch eine Änderung der Konfiguration darauf zu reagieren.

Abbildung 4: TLS-RPT generiert Berichte über fehlgeschlagene E-Mail-Zustellungen und sorgt so dafür, dass Sie umgehend von potenziellen Konfigurationsproblemen erfahren.

Empfänger schützen

Das Absichern und Verifizieren von Empfänger- und Absenderadressen ändert nichts daran, dass jeden Tag Milliarden böswilliger E-Mails den Weg in die Posteingänge der potenziellen Opfer finden. Zu den Pflichten eines Mailserver-Administrators gehört es letztlich auch, etwas gegen diesen Umstand zu unternehmen. Praktischerweise gibt es auch dafür erprobte Lösungen, die sich seit vielen Jahren bewiesen haben.

Von SpamAssassin dürften wohl die meisten Administratoren schon einmal etwas gehört haben. Üblicherweise tritt das Tool im Gespann mit ClamAV auf, einem Virenscanner auf Basis freier Software. Zum Zustellglück fehlt dann nur noch eine weitere Komponente: Amavisd fungiert als Brücke zwischen Postfix, SpamAssassin und eventuell erwünschten weiteren Komponenten, die eine Rolle im Zustellprozess einer Mail spielen sollen.

Das Ganze funktioniert im Grunde recht simpel. Postfix nimmt eine eingehende Mail entgegen und gibt sie an Amavisd weiter. Das ruft SpamAssassin, ClamAV und weitere Komponenten auf und lässt sie den gesamten Inhalt der E.Mail überprüfen. Findet einer der aufgerufenen Dienste Malware oder erkennt SpamAssassin unerwünschte Inhalte, markiert er die Mail im Header entsprechend, bevor Amavisd die Nachricht mitsamt aller neuen Header an Postfix zurückgibt. Die finale Entscheidung darüber, was mit der Mail geschieht, obliegt also Postfix und dessen Konfiguration.

Praktisch: SpamAssassin vergibt anhand verschiedener Faktoren bei E-Mails Punkte, die den Spamverdacht erhärten oder reduzieren. Die Grenzen, anhand derer ein lokales Setup eine E-Mail als definitiven Spam einstuft, als spamverdächtig betrachtet oder als vermutlich in Ordnung einschätzt, bestimmen Sie selbst. Wichtig ist allerdings, dass Sie ein Setup dieses Zuschnitts selbst trainieren und idealerweise auch durch die Anwender trainieren lassen. Hinter Lösungen wie SpamAssassin steckt ein Bayes-Filter, der ohne entsprechende Einübung nicht ordentlich funktionieren kann. Es schadet aus Nutzersicht in einer solchen Umgebung also nicht, fälschlicherweise nicht als Spam erkannte Mails in das entsprechende Postfach zu verschieben und den Filter so zu konfigurieren, dass er die Inhalte des Spam-Ordners für das eigene regelmäßige Training nutzt (Abbildung 5).

Abbildung 5: Moderne Anti-Spam-Werkzeuge wie Rspamd arbeiten erst dann effizient und gut, wenn man sie ordentlich trainiert. Nur dann gelangen sie auf Basis realistischer Annahmen zu ihren Bewertungen.

Deutlich moderner präsentiert sich eine alternative Lösung auf Grundlage von Rspamd, einem kompakten Ersatz für Amavisd, SpamAssassin, ClamAV und andere Komponenten. In Postfix bauen Sie Rspamd als Mail-Filter ein. Es ist streng modular aufgebaut: Über Module lassen sich entsprechend Funktionen nachrüsten, beispielsweise eine Antivirus-Option und ein Filter für potenzielle Spam-Nachrichten. Prinzipiell funktioniert Rspamd dabei ähnlich wie SpamAssassin. Anders als Amavisd beherrscht es auch einen LDA-Modus (Local Delivery Agent). Hier dockt es nicht an den Mailserver Postfix an, sondern an den Zustelldienst – im Regelfall also an Dovecot als IMAP-Server. Der Nachteil dieser Lösung: E-Mails, die erst im Mail Delivery Agent geprüft werden, gelten bereits als angenommen und lassen sich nicht mehr komplett zurückweisen. Wo das kein Problem darstellt, bietet Rspamd eine moderne und leistungsfähige Alternative zu SpamAssassin.

Möchten Sie wie beschrieben Ihren Mailserver im Container betreiben, müssen Sie darauf achten, dass er die Zusatzdienste ebenfalls in Container-Form betreibt und einen Kommunikationspfad herstellt. Auch dafür bieten die gängigen Automatisierer fertige Lösungen.

Fazit

Wollen Sie einen Mailserver so betreiben, dass er gut und sicher funktioniert, erwartet Sie ein gerüttelt Maß an Arbeit. Der Flickenteppich aus Erweiterungen des ursprünglichen E-Mail-Standards trägt erheblich zur Verwirrung und zum komplizierten Betrieb bei. Alles Mosern hilft aber nichts: Wer einen Mailserver betreiben muss, dem bleibt nichts anderes übrig, als durch etliche brennende Reifen zu springen. Dank vieler fertiger Automationslösungen und modernen Technologien wie Containern [1] kommen Admins heute trotzdem deutlich schneller an den Start als je zuvor. (jcb)