Der Spamfilter lief ohne Fehler, und Phishing erreichte trotzdem die Posteingänge

Dienste liefen, die Konfiguration war gültig, im Systemstatus stand kein Fehler. Trotzdem landete Phishing im Posteingang, während Newsletter von Partnern im Spam lagen. Unsere Ingenieure haben gemessen, welche Erkennungsmechanismen tatsächlich ansprangen, die Ursachen behoben und drei Monate später eine Regression gefunden und behoben, die sich nur stundenweise zeigte.

Erstgespräch vereinbaren Die Leistung E-Mail-Zustellbarkeit

Eine Beispiel-Phishingmail: von −2,7 auf 9,1 Punkte
Der Bayes-Filter bewertet 100 % der Nachrichten
Datenbank im Hintergrund neu aufgebaut, ohne Unterbrechung

Ein deutschsprachiges Unternehmen mit rund einem Dutzend Domains und einigen Dutzend Postfächern, etwa 600 externe Nachrichten am Tag

Ausgangslage

Die Nutzer meldeten zwei Probleme zugleich: Spam und Phishing kamen am Filter vorbei, und ein Teil der legitimen Post von Partnern wurde als Spam markiert. Frühere Versuche hatten eigene Regeln ergänzt und Punktzahlen erhöht, was beide Probleme verschärfte.

Die Umgebung: Debian 12, Postfix mit postscreen, Dovecot mit LMTP und Sieve, SpamAssassin 4.0 und amavis mit ClamAV.

Lösung

Daten statt Intuition. Die Kopfzeile, die der Filter jeder Nachricht hinzufügt, nennt die Regeln, die angesprochen haben. Über echte Post und mehrere Wochen Logs ausgewertet, zeigt sie, welche Erkennungsmechanismen arbeiten und welche schweigen. Keine Einstellung wurde ohne Beleg in diesen Daten geändert.

Die erste Reparatur beseitigte die Ursachen: DNS-Blacklists, die nie antworteten, eine vergiftete und fast leere Bayes-Datenbank, Autolernen, das dem Filter beibrachte, Phishing sei in Ordnung, Positivlisten für ganze Freemail-Domains und überzogene eigene Regeln. Als der Spam nach drei Monaten zurückkam, fand eine stundenweise Auswertung der Logs vergessene Cron-Aufträge und eine geschrumpfte Datenbank, und die Datenbank wurde im Hintergrund neu aufgebaut, ohne den Mailverkehr zu unterbrechen.

Ergebnisse

Spam vor der Reparatur: Als sauber bewertet, Median 1,1 Punkte bei einer Schwelle von 3,1
Vom Bayes-Filter bewertet: 100 % der Nachrichten nach der Reparatur, stundenweise geprüft
Neu aufgebaute Bayes-Datenbank: 5,3 Millionen Tokens, aus 47.828 Spam- und 110.302 legitimen Nachrichten
Beispiel-Phishingmail: Von −2,7 Punkten im Posteingang auf 9,1 Punkte im Spamordner
Fehlalarme bei Newslettern von Partnern: Keine nach der Reparatur
Nächtliches Training: Etwa 2 Minuten statt mehrerer Stunden

So sind wir vorgegangen

Zuerst messen

Die Filterkopfzeilen echter Post, dann mehrere Wochen Logs: Welche Regeln sprechen an, welche schweigen?
Ursachen statt Symptome

Ein eigener rekursiver Resolver für die DNS-Blacklists, eine neu aufgebaute Bayes-Datenbank, sicheres Lernen, Positivlisten nur mit gültigem DKIM oder SPF, kalibrierte Standardpunktzahlen.
An echter Post prüfen

Newsletter von Partnern, die als Spam markiert worden waren, fielen auf etwa −3 Punkte, und keine legitime Nachricht überschritt die Schwelle.
Drei Monate später: die Regression

Die Konfiguration war unverändert und der Resolver arbeitete. Erst stundenweise Statistiken zeigten, dass der Filter ganze Nächte ohne Bayes lief.
Reparatur in Schritten

Zwei vergessene Cron-Aufträge entfernt und Berechtigungen repariert; Autolernen aus und Datenbanklimits gesetzt; vollständiger Neuaufbau aus etwa 158.000 Nachrichten in einer separaten Datenbank, etwa fünf Stunden im Hintergrund, dann ein atomarer Tausch.
Neues nächtliches Training

Es läuft als Dienstbenutzer, nur über die letzten drei Tage, in etwa zwei Minuten statt Stunden.

Herausforderungen, die wir gelöst haben

Die DNS-Blacklists liefen, sie sagten nur nie etwas

Der Server nutzte einen öffentlichen Resolver. Betreiber von Listen wie Spamhaus blockieren Anfragen von öffentlichen Resolvern wegen ihres Volumens. Der Filter meldet in diesem Fall keinen Fehler: Er fügt eine Regel mit der Endung BLOCKED und null Punkten hinzu und arbeitet weiter. Die stärksten Reputationssignale waren tot, und das System sah gesund aus. SpamAssassin 4.0 liefert die Spamhaus-ZEN-Regeln außerdem nicht mehr standardmäßig mit; sie wurden so ergänzt, dass nur echte Listungscodes zählen, nie Fehler- oder Limitcodes.

Der Filter hatte gelernt, dass Phishing in Ordnung ist

Moderner Spam ist oft perfekt authentifiziert: gültiges DKIM, SPF und DMARC, versandt von großen Mailplattformen. Dafür bekommt er Minuspunkte, fällt unter die Autolernschwelle als legitime Post, und der Bayes-Filter lernt, dass solche Inhalte in Ordnung sind. Vor der ersten Reparatur enthielt die Datenbank 174 Spamnachrichten gegenüber 139.600 angeblich legitimen. Das Autolernen ist jetzt dauerhaft aus, und nur die Ordner Gesendet dienen als Muster für legitime Post. Der Posteingang eignet sich nicht, denn er enthält genau den Spam, der durchgekommen ist.

Ein Standardlimit warf fast das ganze Training still weg

Das Standardlimit der Bayes-Datenbank liegt bei 150.000 Tokens; darüber entfernt der Filter die ältesten Einträge, und die Synchronisation nach einem großen Training genügt, um das auszulösen. Eine Datenbank aus etwa 147.000 Nachrichten hatte direkt nach dem Training 134.000 Tokens; dieselbe Menge Post ergibt mit abgeschaltetem automatischem Verfall 5,3 Millionen. Mehr als 95 Prozent des ersten Trainings waren weggeworfen, bevor der Filter sie nutzen konnte.

Ein vergessener Cron-Auftrag schaltete den Filter jede Stunde ab

Zwei alte Einträge in der Crontab von root trainierten den Filter jede Stunde aus den Spamordnern. Weil der Datenbankpfad global gesetzt war, schrieben sie in dieselbe Datenbank wie der Dienst, und von root angelegte Dateien wurden für den Dienstbenutzer unlesbar. Tagesstatistiken sahen gut aus. Erst die Aufschlüsselung nach Stunden zeigte Nächte, in denen der Filter sieben Stunden ohne Bayes lief, und einen Tag, an dem das die Hälfte aller Nachrichten betraf.

Ein Fehlalarm, der einen Umbau der ganzen Architektur hätte kosten können

Zwischendurch hatten etwa 95 Prozent der Nachrichten in den Postfächern gar keine Filterkopfzeile, was nach massenhaftem Umgehen aussah. Die Postfix-Logs erklärten es: Das waren die internen Systembenachrichtigungen, etwa 12.000 am Tag, die einen eigenen vertrauenswürdigen Weg nehmen. Die gesamte externe Post, etwa 600 Nachrichten am Tag, lief durch den Filter. Eine echte, kleinere Lücke kam dabei ans Licht: Das Clientprogramm lässt Nachrichten über 500 KB ungeprüft durch, und etwa die Hälfte der externen Nachrichten ohne Kopfzeile lag über dieser Grenze, darunter Spam mit einem Anhang von 1,9 MB.

Die Dienstkonfiguration überschrieb die globale

Die globale Konfiguration nannte amavis mit ClamAV als Inhaltsfilter. Die Dienste, die Post aus dem Internet annehmen, hatten einen eigenen Parameter, der auf SpamAssassin zeigte und Vorrang hat; eingehende Post lief also nie durch amavis, während die Dokumentation etwas anderes annahm. Das betrifft die Annahmen zum Virenscan ebenso wie den Spam.

Der Mailserver fragt die DNS-Blacklist auf zwei gleichmäßigen Bahnen: Über den öffentlichen Resolver, als Wolke gezeichnet, endet die Anfrage vor der Liste an einem Kreuz; über den eigenen Resolver, einen orangen Kasten, kommt sie an

Vorher und nachher

Kennzahl	Vorher	Nachher
DNS-Blacklists	Bei 100 Prozent der Nachrichten blockiert	Antworten korrekt; keine Blockade in vier Wochen Logs
Bewertung durch Bayes	Keine Nachricht bewertet; später Lücken von mehreren Stunden	100 Prozent der Nachrichten, stundenweise geprüft
Bayes-Datenbank	174 Spam- und 139.600 legitime Nachrichten, vergiftet	47.828 Spam- und 110.302 legitime Nachrichten, 5,3 Millionen Tokens
Fehlalarme bei Newslettern	Newsletter von Partnern als Spam markiert	Keine nach der Reparatur
Beispiel-Phishingmail	−2,7 Punkte, Posteingang	9,1 Punkte, Spamordner
Nächtliches Training	Viele Stunden, blockierte die Datenbank	Etwa 2 Minuten, keine Blockade

Was wir daraus mitnehmen

Keine Fehler heißt nicht wirksam. Messen, welche Regeln tatsächlich ansprechen, nicht nur, ob der Dienst läuft.
Eine Datenbank, ein Eigentümer. Jeder Prozess, der den Filter trainiert, läuft als Dienstbenutzer.
Legitime Post nur aus vertrauenswürdiger Quelle: die Ordner Gesendet, nie der Posteingang.
Stundenweise überwachen. Tagesstatistiken verbergen Lücken von mehreren Stunden.
Alte Cron-Aufträge prüfen bei jeder Änderung der Filterarchitektur.

Ein günstiges und genaues Maß für Übersehenes braucht keine Umfrage: Der Filter markiert den Betreff jeder Nachricht, die er erkennt, also wurde eine Nachricht im Spamordner ohne diese Markierung von einem Nutzer dorthin verschoben. Über die Reparatur hinaus haben wir empfohlen, einige Punkte zu schließen: ein Limit von 3 MB für das Clientprogramm, tägliche Regelaktualisierungen, drei enge Regeln für die häufigsten Phishingmuster und Training in Echtzeit, sobald ein Nutzer eine Nachricht in den Spamordner oder aus ihm heraus verschiebt.

24 Stundenbalken von 0 bis 24; ein oranger Rahmen markiert sieben Nachtstunden ohne Balken, in denen der Filter ohne Bayes lief

Weitere Projekte

Eine Foto-Upload-App für Hochzeitsgäste

Hochzeitsgäste scannen einen QR-Code, öffnen eine geheime Adresse und laden Fotos und Videos direkt vom Telefon hoch: keine App, kein Konto, keine Anmeldung. Dateien bis 5 GB landen auf der Festplatte des Kunden, und das Paar sieht zu, wie sich die Galerie während der Feier füllt. Ein Abend, keine zweite Chance, und Telefone von vor sechs Jahren.
E-Mail-Zustellbarkeit für vier Firmendomains

Ein Mailserver für vier Firmendomains signierte nichts, veröffentlichte keine DMARC-Richtlinie und wurde von Microsoft abgewiesen. Unsere Ingenieure haben ihn geprüft, die Änderung an einer Domain erprobt und in Gruppen ausgerollt. Das Ergebnis: Alle drei Prüfungen bestehen bei Gmail, die Microsoft-Sperre ist aufgehoben, und die Nutzer haben nichts bemerkt.