Spamd bekämpft Spam unter OpenBSD

Schätzungen, wie viel Spam jeden Tag um den Globus wandert, schwanken je nach Statistik zwischen 80 und 95 Prozent des weltweiten E-Mail-Volumens. Kein Wunder, dass eine Schwemme von Antispam-Lösungen um die Gunst der Mail-Admins buhlt. Linux stellt eine Vielzahl von Tools zur Auswahl, wogegen OpenBSD versucht, mit einem Vorschlag eine Art Best-of zu präsentieren.

Welche Verfahren wirken

Die Antispam-Programme lassen sich in Klassen einteilen. Contentfilter (Abbildung 1) akzeptieren zunächst alle zugestellten E-Mails, um sie dann anhand heuristischer oder signaturbasierter Verfahren zu analysieren. Erkennt ein Filter eine E-Mail als legitim, stellt er sie zu. Je nach Konzept und Implementation legt er wahrscheinliche Spam-Mails in einem Quarantäne-Ordner ab oder entfernt sie gleich. Damit offenbart die Methode auch ihren Nachteil: Sie benötigt viele Ressourcen zur Analyse. Selbst wenn Contentfilter wie Dspam viele Werbemails erkennen [1], scheitern sie an deren schierer Masse: Kaum ein Benutzer möchte jeden Tag 300 Quarantäne-Mails nach False-Positives durchsuchen.

Abbildung 1: Antispam-Experten haben eine ganze Reihe von Verfahren vorgeschlagen, um der Flut ungewollter E-Mails Herr zu werden. Die richtige Mischung entscheidet über den Antispam-Erfolg.

Dem stehen klassische Whitelist- und Blacklist-basierte Systeme gegenüber, die die IP-Adressen der Versender prüfen. Oft konfiguriert der Admin dazu Dienstleister in seinen Mailserver, die entweder kostenlos oder kommerziell Listen von Mailservern vorhalten, die negativ aufgefallen sind [2]. Die Anbieter pflegen zwar die Listen, allerdings muss sich der Admin auf ihre Integrität und Korrektheit verlassen und kann diese nicht beeinflussen. Falsch geblockte IPs oder nicht gelistete Versender, die trotzdem Spam versenden, sind immer wieder Gegenstand von Diskussionen.

Signaturen-basierte Maßnahmen zählen ebenfalls zu dieser Gattung, auch wenn sich die Art ihrer White- und Blacklists von IP-Adressen-Listen unterscheidet. Hierbei unterzeichnen legitime Absender ihre Nachrichten und der Empfänger prüft die Unterschrift. Je nachdem, wie es die Unterschriften erzeugt, ist dieses Verfahren unter Umständen treffsicherer. Es setzt jedoch voraus, dass die Signaturen auch verbreitet sind und Mailserver sie nutzen, was gegenwärtig noch nicht großflächig der Fall ist.

Eine weitere Klasse von Antispam-Methoden nutzt weder den Inhalt der Nachrichten noch ihre Herkunft. Stattdessen überprüft sie, ob sich die zustellenden Hosts konform zu den RFCs verhalten. Zu dieser Klasse gehört das klassische Greylisting, das initiale E-Mails von unbekannten Quellen temporär ablehnt und sich auf die erneute Zustellung gemäß RFC 2119 und 2821 verlässt. Einfache Spam-Software wird so überlistet, denn viele lästige Müllschleudern haben keine erneuten Zustellversuche implementiert.

Spamd kombiniert

Alle genannten Verfahren kommen in freier Wildbahn auch kombiniert vor. Spamassassin [3] beispielsweise ist primär ein Contentfilter, verifiziert aber auch gegen externe oder lokale White- und Blacklists. Die meisten haben jedoch eines gemeinsam: Sie versuchen, dem Spam aus dem Wege zu gehen, ihn also abzulehnen oder auszusortieren. Die wenigsten ergreifen aktiv Gegenmaßnahmen, die Spammern das Leben schwer machen sollen. In dieser Hinsicht unterscheidet sich Spamd von der Mehrheit seiner Wettbewerber.

Zu Recht werfen Kritiker ein, dass die Erfolge von Greylisting nicht dauerhaft sein können, da Spammer sich der Situation anpassen und schlicht komplexere Spam-Software entwickeln. Deswegen ist Spamd auch nicht nur als klassischer Greylister konzipiert, sondern denkt das Konzept konsequent zu Ende.

Spamd [4] ist seit mehr als fünf Jahren Bestandteil des Basissystems von OpenBSD. Da hier die Kernelentwickler auch die Userland-Tools bereitstellen, benötigt Spamd keine gesonderte Installation. Das Programm läuft in unterschiedlichen Szenarien. Hervorzuheben ist die Variante, bei der ein Paketfilter eine Vorauswahl auf IP-Ebene trifft, bevor er eingehende Mail an den Spamd und später den MTA weiterleitet. Diese Architektur arbeitet völlig transparent auf einem äußeren Perimeter und lässt sich einem bestehenden Netz vorschalten, ohne die dahinterliegende Mailserver-Struktur anzupassen.

Das SMTP-Flussdiagramm in Abbildung 2 veranschaulicht die prinzipielle Funktionsweise: PF, der OpenBSD-Paketfilter [5], fängt eingehenden SMTP-Traffic ab und leitet ihn an den Spamd-Daemon um. Das Konzept folgt der Maxime: Schuster bleib bei deinem Leisten. Da sich PF bereits gut für diese Aufgabe geeignet, liegt kein Grund vor, die Funktion erneut in einem Daemon abzubilden. Die minimale »pf.conf«-Datei in Listing 1 erledigt den Job.

Abbildung 2: Der Paketfilter PF (gelb) und der Spamd (umbra) arbeiten Hand in Hand. Notorische Störer leitet der Spamd gleich in die Teergrube weiter.

Der Paketfilter ist in der Lage, viele IP-Adressen dynamisch in einer »table« zu verwalten. Zeile 1 konfiguriert die PF-Tabelle »<spamd-white>«. Spamd pflegt sie und speichert dort alle IP-Adressen, die das Greylisting erfolgreich durchlaufen haben und ihm auch anderweitig nicht aufgefallen sind. Das Keyword »persist« hält die Tabelle im Kernel vor, auch wenn sie zu Beginn noch leer ist.

01 table <spamd-white> persist
02 no rdr on egress proto tcp from <spamd-white> to any port smtp
03 rdr pass on egress proto tcp from any to any port smtp -> 127.0.0.1 port spamd
04 block in
05 pass out keep state
06 pass in quick on egress inet proto tcp from any to any port smtp
07 pass in quick on egress inet proto icmp from any to any keep state