Rspamd statt SpamAssassin: Moderne Spamfilter sinnvoll vergleichen

Spamfilterziele und unvermeidbare Fehlentscheidungen

Ein E-Mail-Spamfilter bewertet Nachrichten im Mailfluss anhand technischer und inhaltlicher Merkmale. Dazu zählen je nach Produkt etwa Absender- und Authentifizierungsdaten, Header, URLs, Nachrichtentext, HTML-Struktur, statistische Klassifikationen und externe Abfragen. Das Ziel ist nicht, den Wahrheitsgehalt einer E-Mail festzustellen, sondern das Zustellrisiko nachvollziehbar einzuordnen. Rspamd bündelt dafür ebenfalls zahlreiche Prüfmodule und kann die Ergebnisse zu einer Entscheidungsvorlage zusammenführen.

Mehrere Schritte müssen dabei getrennt bleiben: Der MTA nimmt eine SMTP-Nachricht zunächst an oder weist sie während der Übertragung zurück. Der Filter ermittelt anschließend oder während der Einbindung einen Score. Eine Markierung ergänzt beispielsweise Header oder verschiebt die Nachricht durch nachgelagerte Regeln in einen Junk-Ordner. Eine Ablehnung beendet dagegen die Annahme; sie ist daher die folgenreichste Maßnahme und nicht bloß eine stärkere Kennzeichnung.

A False Positive liegt vor, wenn eine legitime Nachricht fälschlich als Spam eingestuft wird. Das kann etwa eine echte Rechnung eines Lieferanten treffen, deren PDF-Anhang, Zahlungsaufforderung oder ungewohnte Versanddomain mehrere Prüfungen auslöst. Wird sie nur markiert, kann der Empfänger sie noch finden; wird sie abgelehnt, erreicht sie das Postfach überhaupt nicht. Für geschäftliche Kommunikation ist dieser Unterschied entscheidend.

Umgekehrt ist ein False Negative eine Spamnachricht, die den Filter passiert. Typisch wäre eine Kampagne mit leicht veränderten Texten, wechselnden Links und technisch korrekt wirkenden Headern. Solche Nachrichten erhöhen das Risiko von Phishing, Schadsoftware oder unerwünschter Werbung, bedeuten aber nicht automatisch, dass jede strenge Ablehnung gerechtfertigt wäre. Ein email spamfilter optimiert stets zwischen beiden Fehlerarten, nicht auf eine fehlerfreie Quote.

Schwellenwerte sind deshalb eine betriebliche Risikoentscheidung. Ein niedriger Wert für Ablehnungen reduziert möglicherweise durchgelassenen Spam, erhöht aber das Risiko verlorener legitimer Post. Ein höherer Wert verlagert mehr Verantwortung auf Markierung, Quarantäne und Nutzerprüfung. Sinnvoll ist eine abgestufte Strategie: erst Kennzeichnung und Beobachtung, dann Greylisting oder strengere Maßnahmen nur dort, wo Logs, Rückmeldungen und der eigene Mailverkehr die Entscheidung tragen.

SpamAssassin: Regeln, Scores und Betriebsmodell

SpamAssassin ist ein erweiterbarer, regel- und punktbasierter Filter. Er untersucht unter anderem Header, Textkörper, HTML und URLs; ergänzend stehen statistische Verfahren, Netzwerkabfragen und Plugins für Funktionen wie Bayes, SPF, DKIM oder DMARC bereit. Einzelne Treffer tragen Punkte zum Ergebnis bei. Aus der Summe entsteht ein Score, der mit einem konfigurierten Grenzwert verglichen werden kann.

Eigene Anpassungen erfolgen klassisch in .cf-Dateien. Damit lassen sich etwa Header-, Body- und URI-Regeln mit eigenen Scores definieren. Dieses Modell ist besonders transparent, wenn ein Team nachvollziehen muss, weshalb eine bestimmte Regel ausgelöst hat. Gleichzeitig wächst mit vielen Ausnahmen, lokalen Regelpaketen und unterschiedlichen Bewertungen der Pflegeaufwand: Jede Regel braucht einen fachlichen Anlass, eine dokumentierte Wirkung und regelmäßige Kontrolle.

Im dauerhaften Serverbetrieb nimmt üblicherweise der Dienst spamd Prüfaufträge entgegen, während der schlanke Client spamc Nachrichten an ihn übergibt. Diese Trennung vermeidet den Aufwand eines vollständigen Programmstarts pro Nachricht und ist für wiederkehrende Prüfungen vorgesehen. Der Dienst kann außerdem SQL- oder LDAP-Konfigurationen sowie nutzerbezogene Einstellungen einbeziehen.

Das ist für Hosting-Umgebungen relevant: Eine Domain kann abweichende Whitelists benötigen, während einzelne Postfächer eigene Präferenzen oder Lernstände haben. Solche gewachsenen Strukturen sind kein technischer Makel, aber sie erschweren einen Austausch. Vor einer Umstellung sollte daher klar sein, welche Regeln tatsächlich geschäftskritisch sind, welche nur historisch übernommen wurden und welche Aufgaben bereits der MTA oder ein anderer Dienst erfüllt.

Eine gepflegte SpamAssassin-Installation muss nicht allein wegen ihres Alters ersetzt werden. Wenn Regeln verständlich sind, die Integration stabil arbeitet und der administrative Aufwand zum Mailaufkommen passt, kann gezielte Pflege sinnvoller sein als eine Migration. Umgekehrt ist ein hoher Anteil schwer wartbarer Sonderregeln kein Argument für blindes Kopieren: Er ist ein Anlass, den Regelbestand kritisch zu bereinigen, unabhängig vom später gewählten Filter.

Rspamd: Worker, Symbole und Aktionen

Rspamd arbeitet mit einem Master-Worker-Modell. Der Master verwaltet Prozesse und Konfiguration, während normale Worker Nachrichten prüfen. Ein Proxy-Worker kann unter anderem Milter-Anfragen entgegennehmen und an Scanner verteilen. Der Controller stellt Verwaltungsfunktionen und eine Weboberfläche bereit, gehört aber nicht ungeschützt ins öffentliche Netz. Diese Rollen trennen Mailverkehr, Verarbeitung und Administration deutlicher voneinander.

Wichtig für die Architektur ist die nicht blockierende Ein- und Ausgabe. DNS-, Redis- oder HTTP-Abfragen können asynchron erfolgen. Wartet eine Prüfung auf eine externe Antwort, muss dies nicht zwangsläufig andere Scans desselben Workers anhalten. Daraus folgt keine allgemeine Leistungsgarantie: Reale Ergebnisse hängen weiterhin von Regelwerk, Hardware, DNS-Latenzen, Redis, MTA-Anbindung und dem tatsächlichen Nachrichtenmix ab.

Prüfungen erzeugen in Rspamd Símbolos mit Bewertungen und Zusatzinformationen. Der Filter verdichtet sie zu einem Gesamtscore und kann eine Aktion vorschlagen, etwa add header, greylist o reject. Die Aktion ist keine zwangsläufige Zustellentscheidung: Erst die Konfiguration und die konkrete Einbindung in Postfix, Exim oder Sendmail bestimmen, ob und wie der MTA sie durchsetzt.

Gerade deshalb dürfen vorhandene SpamAssassin-Grenzwerte nicht als Zahlenwert übernommen werden. Ein Score bildet jeweils das Zusammenspiel der aktivierten Regeln, ihrer Gewichtung und der verfügbaren Datenquellen ab. Selbst gleich benannte Prüfungen können in beiden Systemen anders gewichtet, anders aggregiert oder zu unterschiedlichen Zeitpunkten ausgeführt werden. Ein direkter Vergleich von required_score mit einer Rspamd-Schwelle wäre fachlich irreführend.

Für den Betrieb ist die Trennung von Bewertung und Durchsetzung ein Vorteil: Du kannst zunächst Symbolausgaben und vorgeschlagene Aktionen beobachten, ohne sofort abzulehnen. Erst anhand eigener legitimer Nachrichten, erkannter Kampagnen und Rückmeldungen lässt sich festlegen, welche Aktionsschwellen vertretbar sind. So wird aus einer technischen Voreinstellung eine überprüfbare Zustellrichtlinie statt einer vermeintlich objektiven Spamgrenze.

Vergleich für den täglichen Mailbetrieb

Die Unterschiede zwischen SpamAssassin und Rspamd liegen weniger in einer einzelnen Erkennungsregel als im Betriebsmodell. Beide bewerten E-Mails anhand vieler Signale, doch die Wege zu Konfiguration, Integration und verteiltem Betrieb unterscheiden sich. Die folgende Gegenüberstellung ordnet diese Punkte als Planungsgrundlage ein; sie ersetzt keine Auswertung des eigenen Mailverkehrs.

Für einen kleinen Einzelserver ist eine gepflegte SpamAssassin-Installation daher kein technischer Notfall. Wenn eigene Regeln nachvollziehbar sind, der Dienst stabil arbeitet und Fehlklassifikationen bearbeitet werden, kann die Beibehaltung den geringeren Änderungsaufwand bedeuten. Ein Neuaufbau mit Rspamd bleibt dennoch plausibel, wenn dessen Milter-Anbindung und zentral zusammengefasste Module besser zur geplanten Umgebung passen.

In Hosting-Umgebungen mit mehreren Scannern wird die Escala wichtiger als die bloße Zahl installierter Regeln. Rspamds Proxy-Worker kann Milter-Anfragen an andere Worker weitergeben; asynchrone externe Abfragen sollen dabei nicht den gesamten Worker blockieren. Daraus folgt jedoch kein allgemeines Leistungsversprechen: DNS-Latenzen, Regeln, Hardware und Nachrichtenmix bestimmen den tatsächlichen Durchsatz.

MTA-Anbindung, Redis und zustandsbasierte Module

Die technische Einbindung bestimmt, an welcher Stelle ein email spamfilter seine Bewertung an den Mail Transfer Agent zurückliefert. Rspamd kann mit Postfix und Sendmail über Milter verbunden werden. Exim verwendet dafür seine Integration über spamd_address. Der Filter liefert ein Ergebnis, doch der MTA und die gewählte Konfiguration entscheiden weiterhin, ob eine Nachricht markiert, verzögert oder abgewiesen wird.

Nicht jede Prüfung benötigt einen gemeinsamen Zustand. SPF, DKIM und DMARC werten Authentifizierungsinformationen aus; DNS-basierte Listen und reguläre Ausdrücke prüfen weitere Merkmale einer einzelnen Nachricht. Auch wenn solche Prüfungen externe DNS-Antworten benötigen können, führen sie nicht automatisch eine Lernhistorie. Ihre Aussagekraft hängt unter anderem von korrektem DNS-Betrieb und einer angemessenen Gewichtung im gesamten Regelwerk ab.

Anders arbeiten zustandsbasierte Module. Bayes-Klassifizierung speichert gelernte Merkmale, Greylisting muss frühere Zustellversuche wiedererkennen, und Rate Limits benötigen Zähler über mehrere Verbindungen hinweg. Rspamd sieht Redis in der dokumentierten Architektur für Bayes, neuronale Klassifizierung, Greylisting und weitere Zustände vor. Damit können mehrere Instanzen auf gemeinsame Informationen zugreifen.

Redis ist damit weder ein austauschbares Detail noch eine Voraussetzung für jede einzelne Rspamd-Prüfung. Ohne erreichbaren Speicher können statische Module weiter nutzbar sein, während Lern- und Reputationsfunktionen eingeschränkt sind oder ausfallen. Betreiber müssen deshalb Verfügbarkeit, Netzwerkanbindung, Zugriffsschutz, Sicherung und das Verhalten bei einem Redis-Ausfall vor der Produktivnahme festlegen.

Praktisch ist eine Trennung der Verantwortlichkeiten sinnvoll: Der MTA nimmt SMTP-Verbindungen an und setzt die Filterentscheidung um, Rspamd bewertet Nachrichten, Redis hält erforderliche Zustände vor. Diese Aufteilung erleichtert die Fehlersuche, erhöht aber die Zahl der zu überwachenden Dienste. Eine langsame oder nicht erreichbare Abhängigkeit sollte nicht durch unüberlegte Ablehnungen kompensiert werden.

Regeln und Lerndaten kontrolliert überführen

Eine Migration beginnt mit einer Bestandsaufnahme, nicht mit dem Kopieren aller Dateien. Besonders eigene Regeln verdienen Prüfung: Sie können geschäftliche Anforderungen abbilden, aber auch veraltete Ausnahmen enthalten. Rspamd stellt ein SpamAssassin-Modul bereit, das nur einen Teil von Regeln verarbeitet. Die technische Ähnlichkeit einer Regel ist daher keine Zusage, dass sie dieselbe Wirkung erzielt.

Das Modul kann unter anderem bestimmte body-, rawbody-, header-, meta- y uri-Regeln verarbeiten. Netzwerk- und HTML-spezifische Plugins sind dagegen nicht vollständig abgedeckt. Umfangreiche fremde Regelsätze ungeprüft zu laden, kann die Konfiguration komplizieren und die Verarbeitung belasten. Besser ist es, nur belegbar benötigte eigene Regeln zu übernehmen und native Module vorzuziehen.

Besondere Sorgfalt verlangt das Bayes-Training. SpamAssassin-Bayes-Datenbanken lassen sich laut Rspamd-Dokumentation nicht importieren. Für Rspamd werden deshalb neue, geprüfte Korpora aus erwünschten Nachrichten und Spam benötigt. Falsch zugeordnete Rechnungen, Newsletter oder Kampagnen verschieben die Klassifizierung in die falsche Richtung und können spätere Fehlentscheidungen verstärken.

Auch AWL sollte nicht als Dateiübernahme behandelt werden. Eine frühere Absenderhistorie und eine aktuelle Reputationsbewertung verfolgen zwar verwandte Ziele, können aber andere Datenquellen und Gewichtungen nutzen. Dokumentiere deshalb zunächst, welchen Effekt eine vorhandene Ausnahme oder Vertrauensregel haben soll. Erst danach lässt sich entscheiden, ob eine native Rspamd-Funktion oder eine gezielte eigene Regel angemessen ist.

Rspamd im Parallelbetrieb sicher einführen

Eine produktive Umstellung beginnt nicht mit dem Ersetzen des bisherigen Filters, sondern mit einer Bestandsaufnahme. Dokumentiere MTA-Anbindung, SpamAssassin-Regeln, nutzerbezogene Ausnahmen, DNS-Abhängigkeiten, akzeptierte Absender und die aktuelle Behandlung auffälliger Nachrichten. Lege außerdem fest, welche Kennzahlen später zählen: etwa fälschlich markierte Geschäftsmails, durchgelassene Kampagnen und der manuelle Bearbeitungsaufwand.

Installiere Rspamd zunächst getrennt vom entscheidenden Mailpfad und binde ihn so ein, dass seine Bewertung aufgezeichnet wird, aber keine Zustellung verändert. Der dokumentierte Shadow Mode erlaubt genau diese Beobachtung: Rspamd prüft Nachrichten, ohne seine vorgeschlagenen Aktionen durchzusetzen. Damit bleibt SpamAssassin während der Vergleichsphase der alleinige aktive Entscheider.

Werte nicht nur den Gesamtscore aus, sondern vor allem die ausgelösten Símbolos und die daraus abgeleitete Aktion. Ein hoher Wert kann aus Authentifizierungsfehlern, URL-Merkmalen, Reputationsdaten oder lokalen Regeln entstehen; diese Ursachen verlangen unterschiedliche Korrekturen. Prüfe daher pro auffälliger Nachricht Header, Empfängergruppe und die vom Filter vorgeschlagene Aktion, bevor du Scores oder Module veränderst.

Ein sinnvoller Vergleich enthält gezielt erwünschte und unerwünschte Grenzfälle. Eine legitime Rechnung eines bekannten Lieferanten kann etwa eine PDF-Datei und einen externen Tracking-Link enthalten. Eine variantenreiche Spamkampagne verändert dagegen Betreff, Textbausteine und Absender laufend, behält aber typische URLs oder strukturelle Eigenschaften. Beide Nachrichtenarten zeigen, ob einzelne Symbole nachvollziehbar beitragen oder eine Regel zu grob greift.

Yugo Valores umbral erst an, wenn ausreichend prüfbare Beispiele vorliegen. Die Score-Skala von Rspamd ist nicht mit einem bisherigen SpamAssassin-Wert gleichzusetzen; eine direkte Übernahme kann daher unpassende Aktionen auslösen. Entscheide getrennt, ab wann nur Header ergänzt, wann vorübergehend gegreylistet und unter welchen Bedingungen abgelehnt werden soll. Die MTA-Integration bestimmt dabei, ob und wie eine Aktion tatsächlich durchgesetzt wird.

Nach einer geplanten Beobachtungsphase erfolgt die Umschaltung kontrolliert: Rspamd wird zum aktiven Filter, während SpamAssassin installiert und konfigurierbar bleibt, aber nicht mehr im Mailfluss entscheidet. Dieser Rückfallzeitraum sollte Zuständigkeiten, eine dokumentierte Rückschaltmethode und Kriterien für einen Abbruch enthalten. Ergänzend hilft eine sauber begrenzte Firewall-Konfiguration; Grundlagen für schrittweise Regelmigrationen erläutert der Beitrag Netfilter vs. nftables.

Betrieb, Logging und systematische Fehlersuche

Bei einer unerwarteten Ablehnung beginnt die Diagnose mit der konkreten Nachricht und ihrer Verarbeitungskette, nicht mit einer pauschalen Lockerung der Filtergrenze. Prüfe MTA-Protokoll, Rspamd-Resultat, ausgelöste Symbole, Score und vorgeschlagene Aktion. Erst diese Zuordnung zeigt, ob etwa eine lokale Regel, eine DNS-basierte Prüfung oder die MTA-Durchsetzung die Ablehnung verursacht hat.

Durchgelassener Spam verlangt die umgekehrte Analyse. Stelle fest, ob die Nachricht Rspamd überhaupt erreicht hat, welche Symbole fehlen und ob eine konfigurierte Aktion wegen des Scores nicht erreicht wurde. Fehlen erwartete DNS-Ergebnisse, untersuche Resolver, Erreichbarkeit und Antwortzeiten, bevor du neue Inhaltsregeln schreibst. Nicht jede Kampagne lässt sich durch einen einzelnen Grenzwert sinnvoll erfassen.

Ein Redis-Ausfall ist gesondert zu behandeln, weil er zustandsbasierte Funktionen beeinträchtigen kann. Kontrolliere die Verbindung des Filters zum Speicher, die Protokolle des Redis-Dienstes und anschließend, welche Module auf diesen Zustand angewiesen sind. Statische Prüfungen können weiterhin Ergebnisse liefern, doch Bayes-Training, Greylisting oder andere zustandsabhängige Auswertungen benötigen eine funktionierende Datenhaltung.

Löst eine erwartete Regel nicht aus, prüfe zuerst ihren tatsächlichen Ladeort, die Syntax und die Nachrichtendarstellung, gegen die sie arbeiten soll. Header-, Rohtext-, HTML- und URL-Prüfungen betrachten unterschiedliche Daten. Bei SpamAssassin können Regeldateien vor dem Einsatz mit einer Syntaxprüfung kontrolliert werden; der folgende Befehl prüft die Konfiguration und verändert keine produktive Mailzustellung.

spamassassin --lint

Behalte für wiederkehrende Störungen Zeitstempel, Queue-Verhalten, DNS-Anfragen und Antwortfehler in einer gemeinsamen Sicht. So lässt sich unterscheiden, ob eine verzögerte Zustellung vom MTA, von einer externen Abfrage oder vom Filterprozess ausgeht. Für weitergehende Linux-Telemetrie und die Beobachtung laufender Systeme bietet der ergänzende Beitrag bpftool für moderne Kernelanalyse technische Grundlagen.

Ändere nach einem einzelnen Vorfall weder globale Scores noch umfangreiche Regelsätze reflexhaft. Sichere stattdessen die betreffende Nachricht datenschutzgerecht, vergleiche sie mit ähnlichen Fällen und dokumentiere die Ursache samt Änderung. Diese Análisis de errores schafft nachvollziehbare Korrekturen und verringert das Risiko, dass eine Ausnahmeregel später große Mengen legitimer oder unerwünschter E-Mails falsch behandelt.

Entscheidung nach Serverprofil treffen

SpamAssassin gezielt weiterzubetreiben ist plausibel, wenn der bestehende Mailserver mit seinen eigenen Regeln, per-user-Einstellungen und Betriebsabläufen zuverlässig verwaltet wird. Das System ist regel- und punktbasiert erweiterbar und unterstützt Plugins sowie verschiedene Konfigurations- und Speicherwege. Ein Wechsel allein wegen des Alters einer Installation schafft keinen fachlichen Nutzen, wenn kein konkretes Betriebsproblem besteht.

Rspamd ist für einen Neuaufbau naheliegend, wenn Milter-Anbindung, moderne Authentifizierungsprüfungen, zentrale Steuerung und zustandsbasierte Module von Beginn an zusammen geplant werden. Seine Architektur umfasst Worker-Rollen für die Verarbeitung, Proxy-Anbindungen und Verwaltung; zugleich müssen DNS und gegebenenfalls Redis als betriebliche Abhängigkeiten zuverlässig betrieben werden. Das ist eine Architekturentscheidung, keine allgemeine Leistungszusage.

Für gewachsene Hosting-Umgebungen mit vielen Sonderfällen ist der Funcionamiento en paralelo meist die belastbarste Option. Er macht sichtbar, welche eigenen SpamAssassin-Regeln weiter benötigt werden, ob Rspamd-Symbole die erwarteten Ursachen abbilden und welche Empfängergruppen besonders empfindlich auf Fehlklassifikationen reagieren. Erst auf dieser Grundlage lässt sich über eine vollständige Umstellung oder den bewussten Verbleib beim Bestand entscheiden.

Die Auswahl hängt daher weniger von der Zahl der Postfächer allein ab als von Wartungskapazität und Abhängigkeiten. Wer Redis, DNS-Resolver, Protokollauswertung und Updates dauerhaft verantworten kann, kann Rspamd einschließlich lernender und zustandsbasierter Funktionen konsistent betreiben. Fehlen diese Ressourcen, kann ein schlanker, gut dokumentierter Bestand mit klaren Regeln das geringere Betriebsrisiko darstellen.

Unabhängig vom Produkt gilt: Stelle den Rspamd-Controller nicht ungeschützt im Netz bereit. Die Dokumentation empfiehlt lokale Bindung oder Firewall-Schutz; bei entferntem Zugriff sind Zugangsschutz und ein Passwort-Hash erforderlich. Übernimm außerdem weder fremde Regeln noch historische Scores ungeprüft. Einzelne Messungen oder auffällige Kampagnen sind keine Grundlage für eine globale Filterpolitik.

Die richtige Entscheidung ist damit eine Risikoabwägung: Schutz vor unerwünschten Nachrichten steht gegen die Folgen verlorener legitimer E-Mails. Definiere für jede Aktion, wer sie verantwortet, wie sie überprüft wird und wie eine Rückkehr zum vorherigen Zustand gelingt. So bleibt der E-Mail-Spamfilter ein kontrollierbarer Teil des Mailbetriebs statt einer schwer nachvollziehbaren automatischen Instanz.