Den Erfolg der E-Mail haben sich wohl selbst ihre Erfinder nicht in ihren kühnsten Träumen ausgemalt: Bis heute ist sie praktisch das unangefochtene Standardkommunikationsmedium im Netz. Das bringt ihr viel Aufmerksamkeit ein – oft auch von Ganoven und Betrügern. Unternehmen mit eigenem E-Mail-Server können davon ein Lied singen. Wer das Hosting des eigenen E-Mail-Systems aus Sicherheits- oder Compliance-Gründen nicht auslagern will oder kann, braucht zwangsläufig starke Nerven.

Wer sich mit den Themen Anti-Spam und Anti-Malware eine Weile nicht mehr beschäftigt hat, dürfte die zahlreichen Neuerungen der vergangenen Jahre kaum mitbekommen haben. Denn so, wie das Thema Betrug per E-Mail quasi ein Dauerbrenner ist, ist es auch der Schutz davor. Dieser Artikel listet die aktuell gängigen Methoden, Mittel und Wege auf, um die elektronischen Nachrichten gegen eingehendes Ungemach abzusichern. So viel ist schließlich klar: Eine E-Mail, die der Server gar nicht erst annimmt oder kommentarlos verwirft, kann in der Inbox des Anwenders und auf dessen Systemen keinen Schaden anrichten. Und genau das ist das Ziel der meisten Admins.

Pragmatisch betrachtet besteht der Zustellvorgang einer E-Mail aus Phasen, auf die der Admin des empfangenden Mailservers Einfluss nehmen kann: Dem eigentlichen Akzeptieren der E-Mail sowie der Zustellung ebendieser in die Inbox eines Benutzers. Es empfiehlt sich, diesen Prozess in diesen zwei Abschnitten zu betrachten, denn so haben Sie Handlungsspielraum. Nehmen Sie E-Mails gar nicht erst an, ist es auch nicht erforderlich, diese eingehend zu untersuchen und abzuschätzen, ob es sich um Spam, einen Betrugsversuch oder gar einen aktiven Angriff handelt. Je effektiver ein E-Mail-Setup unter Verwendung aktueller Technologien also gegen dubiose Versender geschützt ist, desto weniger gibt es im Nachgang zu untersuchen.

Das entbindet den Administrator jedoch nicht von der Notwendigkeit, einen Zoo verschiedener Techniken im Hintergrund aufzufahren, um auch das Filtern von E-Mails effizient und effektiv zu gestalten. Es spart hier und dort aber Rechenleistung und Zeit beim Verarbeiten von eingehenden E-Mails. Entsprechend klar ist der Schlachtplan: Zurückweisen, was auch nur den leisesten Verdacht erweckt, und den Rest gründlich und profund durchsuchen und analysieren.

Denn der Versuch, verdächtige E-Mails schon während der Zustellung zurückzuweisen, findet mittlerweile vorrangig auf der Ebene von DNS statt und bedingt die Existenz verschiedener DNS-Einträge für die jeweiligen Domänen. Die drei zentralen Begriffe sind dabei SPF, DKIM und DMARC. Allen drei Ansätzen ist gemein, dass sie versuchen, die Authentizität eines Absenders über DNS-Einträge zu validieren beziehungsweise dies einem gegenüberliegenden E-Mail-Server zu ermöglichen. Auch wenn die drei Technologien im öffentlichen Diskurs regelmäßig im selben Atemzug auftauchen, handelt es sich doch um drei unterschiedliche Ansätze, die in der Kombination jedoch deutlich mehr Schlagkraft entfalten.

SPF etwa bezeichnet das "Sender Policy Framework" (Bild 1), ein relativ simpler Ansatz, um für eine Domäne festzulegen, welche Mailserver im Netz für sie offiziell E-Mails verschicken dürfen. Das ist in sämtlichen Standards der ersten Generationen nicht definiert und jeder, der einen Mailserver betreibt, kann diesen zunächst so konfigurieren, dass er beliebige Domänen als Absenderadresse von Clients akzeptiert und nach außen hin auch benutzt.

Gerade in den Anfangsjahren des Internets war es üblich, dass solche E-Mails von Systemen hinter "Dial-Up"-Verbindungen kamen, also gekaperten Rechnern hinter heimischen Anschlüssen mit Modem. Längst sind deshalb die allermeisten Netzwerk-segmente, die im Einwahlbereich zum Einsatz kommen, in sämtlichen Spam-Filterlisten des Internets eingetragen. Dieser statische Ansatz hat sich in der Breite allerdings nicht als zielführend herausgestellt, weil er zu viele False Positives aufgrund fälschlich eingetragener IP-Adressen produziert. In den Blacklist-Datenbanken finden sich nämlich regelmäßig auch IP-Adressen, die mit Einwahlzugängen gar nichts zu tun haben.

SPF schlägt deshalb den beschriebenen andersartigen Weg ein. Der empfangende Server muss dann nur noch die Liste der im DNS-Eintrag hinterlegten Hosts abgleichen und prüfen, ob die gerade eingehende Nachricht ursprünglich von einem dieser Server stammt. Gibt es eine Übereinstimmung, gilt der SPF-Test als bestanden. Schlägt der Abgleich hingegen fehl, weist der Server die E-Mail zurück. SPF sollte heute zum Standardprozedere gehören. Zweckdienlich ist es dann allerdings, für die Domänen unter eigener Kontrolle die SPF-Einträge ebenfalls korrekt zu hinterlegen. Hier empfiehlt es sich, mit den für DNS zuständigen Kollegen zu konferieren.

DKIM und DMARC sind deutlich komplexere Technologien als SPF, blasen letztlich aber in dasselbe Horn. Auch hier geht es um DNS-Einträge, allerdings stellen die beiden Ansätze diesen digitale Verschlüsselungen zur Seite. Beim "DomainKeys Identified E-Mail"-Verfahren, also DKIM, hinterlegt der Mailserver-Administrator beispielsweise den öffentlichen Teil eines Schlüssels im DNS für eine Domäne. Komplementär dazu signiert der versendende Mailserver mithilfe eines privaten Keys die Header ausgehender E-Mails. Anhand des öffentlichen Schlüssels lässt sich die digitale Signatur der Header auf der Gegenseite verifizieren. Passen Signatur und öffentlicher Schlüssel zusammen, gilt die E-Mail als authentisch. Auch das Überprüfen von DKIM für eingehende E-Mails sowie die richtige Konfiguration von DNS für DKIM bei ausgehenden E-Mails sollten zum Standardrepertoire eines modernen Mailservers zählen.

Die dritte Technologie schließlich, das Domain-based Message Authentification Reporting and Conformance-Konzept (DMARC), ergänzt SPF und DKIM. In einem DMARC-Eintrag im DNS-Server einer Domäne lässt sich nämlich für empfangende E-Mail-Server festlegen, was diese mit E-Mails für die eigene Domäne tun sollen, die den SPF- und DKIM-Test bestehen oder eben nicht. Es handelt sich also um eine Art Sicherheitsnetz zur genaueren SPF- und DKIM-Konfiguration. Obendrein enthält DMARC auch eine erweiterte Verifikation der Absenderzeile, also der "From"-Angabe. Schalten Sie SPF und DKIM auf dem eigenen Server scharf, sollten Sie auch DMARC-Kompatibilität herstellen. Denn die Technologie hat noch eine weitere Funktion, die erlaubt, per DMARC-Eintrag für eine Domäne auch ein Reporting anzulegen, das Ergebnisse von DMARC-Abfragen an Sie schickt. Lehnt ein empfangender Server also eine eingehende E-Mail ab, benachrichtigt er Sie bei entsprechender Anweisung im DMARC-Eintrag. So erfahren Sie, dass es möglicherweise ein Konfigurationsproblem gibt und können entsprechend eingreifen. SPF, DKIM und DMARC bilden zusammen insofern ein Dreigestirn im Kampf gegen Spam, eine Barriere, die schon vor der Verarbeitung der eigentlichen E-Mail greift und diese anhand externer Faktoren (der validierten Domäne) gegebenenfalls zurückweist.

Andere Mechanismen mit ähnlichen Zielen haben sich indes nicht dauerhaft durchgesetzt. Blacklists etwa, die zwischenzeitlich ein wirklich rege genutzter Dienst waren, haben stark an Zulauf verloren. Einige der größeren Anbieter der Vergangenheit gibt es heute schon gar nicht mehr. Dasselbe gilt für Greylisting: Dabei hat ein empfangender E-Mailserver eine Nachricht beim ersten Zustellversuch temporär zurückgewiesen, weil Spammer früher in der Regel keinen weiteren Zustellversuch mehr unternommen haben. Doch diese haben längst dazugelernt und reagieren auf Greylisting heute mit einem zweiten, verzögerten Zustellversuch. Gleichzeitig landen bei reinem Greylisting automatisch alle eingehenden E-Mails zunächst in der digitalen Zurückweisung und kommen letztlich stark zeitverzögert an. Weil die Wartezeit vielen zu lang war, spielt auch Greylisting heute nur noch eine untergeordnete Rolle.

SPF, DKIM, DMARC und vergleichbare Technologien zur Verifikation des Absenders und der Stationen, die eine E-Mail auf ihrem Weg genommen hat, sind effektiv und dämmen das Aufkommen von Spam erheblich ein. Sie greifen aber nur dort, wo Address Spoofing stattfindet. Stammt eine verräterische E-Mail von einem genuinen Account, sind die Dienste machtlos. Und das kommt häufiger vor, als manchem Administrator klar ist: Klickt etwa ein Bekannter auf einen mit Schadsoftware verseuchten Anhang einer E-Mail, durchforstet die dadurch installierte Software nicht selten zuerst das gesamte Adressbuch und verschickt sich selbst an alle dort hinterlegten Adressen. Die Nachricht geht reibungslos durch die genannten Verifikationsmaßnahmen und findet ihr Ziel, wo sich das Schauspiel im schlimmsten Falle wiederholt. Die inhaltliche Überprüfung von E-Mails, die ein Server bereits angenommen hat, ist deshalb die zweite Säule im Kampf gegen Bösewichte. Und hier hat sich in den vergangenen Jahren einiges getan.

Wer selbst noch E-Mailserver etwa mit SpamAssassin aufgesetzt hat, muss beispielsweise umdenken. Denn das Gespann aus SpamAssassin, ClamAV und Amavisd gegen Viren existiert zwar noch. Längst gilt es aber nicht mehr als zeitgemäß. Der neue Stern am Anti-Malware-Himmel heißt stattdessen Rspamd [1]. Und anders als SpamAssassin übernimmt Rspamd eine aktive Rolle nicht nur beim E-Mail-Empfang, sondern auch beim Versand. Denn DMARC arbeitet mit der Signaturfunktion von Rspamd zusammen.

Die Hauptaufgabe von Rspamd besteht aber natürlich darin, eingehenden Spam zu erkennen und aus dem Strom der E-Mails zuverlässig auszusortieren. In vielerlei Hinsicht unterscheidet die Software sich dabei nicht so sehr von älteren Werkzeugen wie SpamAssassin. Ähnlich wie dieses arbeitet auch Rspamd mit einem Punktesystem, um E-Mails anhand verschiedener Eigenschaften als Spam zu klassifizieren. Das funktioniert recht simpel: Zunächst überprüft Rspamd jede eingehende E-Mail anhand eines festgelegten Regelwerks. Treffen bestimmte Aspekte wie etwa eigenartige Zeichen in den Headern der E-Mail zu, weist der Spamfilter der E-Mail dafür einen Punktwert zu und addiert diesen am Ende der Überprüfung auf. Liegt der Gesamtpunktwert über einer vom Administrator festgelegten Schwelle, markiert Rspamd die E-Mail über einen Eintrag in deren Headern als Spam. Die Entscheidung darüber, wo die E-Mail letztlich landet, trifft allerdings nicht das Tool. Stattdessen obliegt es dem Administrator, den eigenen Zustelldienst für E-Mails – oft IMAP in Form von Dovecot – so zu konfigurieren, dass dieser Messages mit der "bösen" Zeile im Header gleich ins Spam-Postfach verschiebt. Bei erkannter Malware ist es noch besser, die Nachricht gleich in Quarantäne zu stecken.

Ähnlich wie seine historischen Vorgänger setzt auch Rspamd auf Heuristik, um eine Bayes-Datenbank zu trainieren und Spam so zunehmend besser zu identifizieren. Dabei ist der Dienst allerdings auf die Hilfe des Nutzers angewiesen. Geht der Software eine Spam-E-Mail durch die Lappen, tut der Benutzer gut daran, diese händisch ins Spam-Postfach zu verschieben. Das erkennt Rspamd und packt die fragliche Nachricht gleich in den Fundus seines Lernmaterials. Eine Einbahnstraße ist dieser Prozess indes nicht: Wird eine E-Mail fälschlicherweise als Spam erkannt, kann der Benutzer diese ebenso gut händisch vom Spamordner in den regulären E-Mail-Ordner verschieben. Auch das erkennt die Software und zieht in Zukunft daraus ihre Schlüsse.

Die Antivirus-Funktionalität implementiert Rspamd übrigens nicht selbst und bedient sich mit dem fast schon altehrwürdigen ClamAV eines ausgezeichnet funktionierenden Virenscanners mit aktueller Definitionsdatenbank unter freier Lizenz. Clam-AV ist vielseitig, performant und zuverlässig, auch weil es auf einen langen Erfahrungsschatz und viel Praxis zurückblickt. Mittels seines Antivirus-Moduls kann Rspamd ClamAV extern aufrufen und mit dem Testen von E-Mails, die es zur Überprüfung erhält, beauftragen.

Die folgenden Absätze enthalten eine erste Übersicht darüber, wie Sie Rspamd im Gespann mit ClamAV und Postfix in Betrieb setzen. Allein die tatsächlich notwendigen Einträge in der Postfix-Konfiguration würden den verfügbaren Platz andernfalls sprengen – vollständige Installations- und Konfigurationsanweisungen liefern diverse Anleitungen im Netz, so auch [2]. Das folgende Beispiel geht jedenfalls vom heute typischen Fall aus, der Dovecot für IMAP, Postfix für SMTP und Rspamd im Gespann mit ClamAV kombiniert, um zuverlässige und sichere Zustellung von E-Mails zu ermöglichen. Um das Beispiel nachvollziehbarer zu machen, gehen wir zudem davon aus, dass die Installation eines neuen E-Mail-Servers ansteht. Möchten Sie das folgende Know-how auf einen bestehenden Server anwenden und diesen an die neuen Standards anpassen, lassen sich die nötigen Änderungen aus der Anleitung herleiten.

Anfangs spielt Rspamd beim E-Mail-Setup aber ohnehin keine bedeutende Rolle. Zunächst konfigurieren Sie die DNS-Einträge Ihrer Domänen, installieren Dovecot und Postfix und richten diese grundlegend ein. Mailserver nutzen bis heute eine eigene Skriptsprache namens Sieve [3] für die Integration von Filtern. Sieve unterstützt den Administrator also durch eine generische Schnittstelle für Filter dabei, E-Mails auszusieben. Dafür genügt de facto sogar eine simple Anweisung in der "dovecot.conf"-Datei: "sieve_before = /var/vmail/sieve/global/spam-global.sieve" bringt die in der Datei referenzierten Regeln schon zur Anwendung, bevor eine E-Mail für die Zustellung in das Postfach des Nutzers vorgesehen ist. Ein funktionales Beispiel für ein "spam-global.sieve"-Skript sieht so aus.

Damit auch das automatische Training für Spam und fälschlich erkannte Nachrichten funktioniert, sind (hier für Ubuntu 22.04) zwei weitere Sieve-Skripte im globalen Sieve-Ordner nötig, zunächst "learn-ham.sieve":

Und daneben legen Sie "learn-spam.sieve" für False Positives an:

Gut zu erkennen ist dabei, dass das Sieve-Regelwerk für fälschlich erkannte E-Mails deutlich umfassender ist als jenes für das automatische Einschleusen von Spam-E-Mails in den Bayes-Fundus von Rspamd.

Im Anschluss steht Postfix samt seiner Konfiguration auf dem Programm. Auch hier gilt, dass sich mit der Konfigurationsdatei "main.cf" zahllose Parameter definieren und nutzen lassen – Details liefert die zugehörige Dokumentation [4]. Die zentrale Konfiguration für die Integration von Rspamd in Postfix erledigen Sie jedoch über wenige Zeilen:

Rspamd ist ab Werk so eingerichtet, dass es auf dem TCP/IP-Port 11332 lauscht. Postfix schickt mit der beschriebenen Konfiguration jede eingehende E-Mail zunächst durch einen E-Mail-Filter ("Milter"), bevor es sie lokal zustellt.

Schließlich steht die Installation von Rspamd an. Achtung: Vielen Distributionen liegt Rspamd zwar bei, allerdings in stark veralteten Versionen. Die Rspamd-Entwickler bieten selbst aktualisierte Pakete an, die Sie jedoch über ein separates Repository zunächst installieren müssen. Die Dokumentation [5] enthält hierzu genauere Hinweise. Haben Sie eine aktuelle Rspamd-Version auf dem System, sind zunächst diverse Einstellungen fällig. Mittels rspamdadm pw generieren Sie zunächst ein Passwort, das Sie anschließend in "/etc/ rspamd/local.d/worker-controller.inc" bei "password =" eintragen. Wichtig dabei ist, dass die Zeile in der Konfigurationsdatei in Anführungszeichen stehen muss und hinter dem letzten Anführungszeichen ein ";" benötigt.

Darüber hinaus toben Sie sich nach Belieben im Hinblick auf weitere Parameter aus. In "/etc/rspamd/local.d/logging.inc" lässt sich das Verhalten des Loggings umfassend festlegen und in "/etc/rspamd/local.d/milter_headers.conf" sollten Sie die Header definieren, die Rspamd in E-Mails hinterlässt. Weil der Bayes-Filter heute stilecht in Redis liegt, sorgt "backend = "redis";" in "/etc/rspamd/local.d/classifier-bayes.conf" genau dafür. Die Datei "/etc/rspamd/local.d/redis.conf" sollte die nötige Konfiguration dafür enthalten, im Regelfall die Zeile "servers = "127.0.0.1";". Die wesentlichen Teile der Anti-Spam-Konfiguration sind damit hinterlegt. Idealerweise konfigurieren Sie zusätzlich das Webinterface.

Nun fehlt Ihnen noch die Antivirus-Funktionalität. Dafür installieren Sie zunächst ClamAV und widmen sich hinterher der Datei "/etc/rspamd/local.d/antivirus.conf". Hier ist das Antivirus-Modul einerseits zu aktivieren, andererseits muss Rspamd wissen, wo es ClamAV erreicht, um E-Mails dorthin weiterzuleiten. Anbei ein minimales, aber funktionales Beispiel:

Nach einem Neustart von Rspamd ist die neue Konfiguration aktiv und ClamAV kommt für das Prüfen von Nachrichten zum Einsatz (Bild 2).

Der Betrieb von E-Mail-Servern ist in den vergangenen Jahren kaum einfacher geworden, doch dank einer etablierten Toolchain von Standardwerkzeugen durchaus zu meistern. Das umfasst den umfassenden Schutz vor Spam, Mal- und Ransomware durch Maßnahmen auf verschiedenen Ebenen. Doch sind das keine Selbstläufer: Viel mehr gilt es, DMARC-Reports regelmäßig nachzuhalten, die Antiviren-Definitionen zu aktualisieren und Augen und Ohren im Hinblick auf neue Tricks und Kniffe offenzuhalten. Denn fest steht leider auch: Spammer, Ganoven und IT-Verantwortliche befinden sich in einem ständigen Wettlauf. Schutzmaßnahmen der einen Seite werden von der Gegenseite so lange untersucht und unterwandert, bis sie irgendwann weitgehend nutzlos sind. Googles E-Mail-Chef verkündete einst, er betrachte den "Kampf gegen Spam vorerst als gewonnen". Die Vorsicht, die in dieser Aussage eindeutig mitschwingt, sollte eine eindeutige Warnung sein.