© giannip, Fotolia.com

OpenBSD verfügt mit Spamd über eine mächtige Waffe im Kampf gegen Müllmails. Statt nur passiv zu filtern lockt es Spammer gezielt an und stiehlt ihnen wertvolle Ressourcen. Das Duo setzt mehrere bekannte Techniken in neuer Kombination ein, um Netzwerke vor Spam zu schützen.

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

Paketfilter sorgt für Ruhe

Verbindungsversuche von IP-Adressen, die in der Tabelle »spamd-white« gespeichert sind und somit ihre Legitimität bereits bewiesen haben, leitet der PF performant ohne Umweg über Spamd direkt durch (Zeile 2). Im Normalfall ist das Ziel dann ein MX, der die Mail zur Auslieferung entgegennimmt. Das Keyword »egress« ersetzt die Angabe eines statischen Interface und zeigt stattdessen auf jenes mit der Defaultroute.

Zeile 3 biegt alle Zustellversuche nicht bekannter IPs auf den Spamd-Daemon um, der sich als Pseudo-MTA zu erkennen gibt (Listing 2). Die restlichen Regeln definieren eine klassische, minimale Firewall: Alles darf raus, nichts darf rein, außer SMTP und ICMP. Den Paketfilter lädt der Administrator mit Regeln und aktiviert ihn:

sudo pfctl -f /etc/pf.conf
sudo pfctl -e

Anschließend aktiviert er den Spamd und die zugehörige Protokollierung:

sudo /usr/libexec/spamd
sudo /usr/libexec/spamlogd

Spamd lauscht auf Port 8025 und verhält sich fast wie ein richtiger MTA. Standardmäßig arbeitet er bereits im Greylisting-Modus, was die Angabe weiterer Optionen überflüssig macht. Spamd ließe sich auch im reinen Blacklist-Modus betreiben, die Manpage »spamd(8)« gibt Aufschluss über alle optionalen Parameter. Dem aufmerksamen Admin entgeht nicht, dass die Prozesstabelle mehrere Spamd-Daemons listet (Abbildung 3). Keiner läuft als Root, was dem OpenBSD-Anspruch “Secure by default” [6] folgt: Nur die notwendigsten Codeteile laufen priviligiert (Privilege Separation). Wer in »/etc/rc.conf.local« die Einträge

pf=
spamd_flags=
spamlogd_flags=

schreibt, sorgt dafür, dass alle Dienste auch nach einem Reboot wieder neu starten. Anders als Linux bildet BSD seine Rechtestruktur nicht durch Runlevel ab.

Abbildung 3: Mehrere Spamd-Prozesse teilen sich die Arbeit. Dem BSD-Prinzip des &bdquo;Least Privilege&ldquo; folgend, benötigen sie dafür keine Root-Rechte.

Immer mit der Ruhe

Jede auf Spamd umgeleitete und damit anfangs unbekannte Verbindung durchläuft zunächst eine Stotterphase (Stuttering). Während des SMTP-Dialogs antwortet Spamd 10 Sekunden lang mit einer Geschwindigkeit von 1 Byte pro Sekunde und stiehlt dem Versender wertvolle Ressourcen. Die Folge: Die Verzögerung kostet die Spammer Zeit, sodass etwa ein Sechstel aller Anfrager bereits in dieser Phase entnervt aufgibt. Spammer werden nämlich nicht für den Zustellversuch, sondern pro erfolgreicher Zustellung bezahlt. Je länger diese dauert, desto geringer fällt der Verdienst aus.

Legitime SMTP-Server lassen sich durch die Verzögerung nicht beirren, da sie ihnen im Vergleich zu Spammern keinen finanziellen Verlust verursacht. Abgebrochene Verbindungen behandelt Spamd nicht gesondert in einer Blacklist, denn sollte sich die IP erneut verbinden, muss sie sich sowieso erneut durchstottern.

Datenempfang

Nach 10 Sekunden Stottern, das Hartgesottene auf bis zu 90 Sekunden erweitern können, läuft der SMTP-Dialog in normaler Geschwindigkeit weiter. Direkt nach der Client-Aufforderung »data«, die den zu übermittelnden Inhalt der E-Mail einleiten soll, bricht Spamd die Verbindung mit dem Fehlercode »451« jedoch ab: Temporary Failure (Listing 2).

01 $ telnet smtp.yourdomain.org 25
02 Connected to smtp.yourdomain.org.
03 Escape character is '^]'.
04 220 smtp.yourdomain.org ESMTP spamd IP-based SPAM blocker; Thu Oct  9 16:52:31 2008
05 EHLO mydomain.org
06 250 Hello, spam sender. Pleased to be wasting your time.
07 MAIL FROM: <ichbins@mydomain.org>
08 250 You are about to try to deliver spam. Your time will be spent, for nothing.
09 RCPT TO: <andich@yourdomain.org>
10 250 This is hurting you more than it is hurting me.
11 data
12 451 Temporary failure, please try again later.
13 Connection closed by foreign host.

Hier setzt der klassische Greylister ein, der sich das Tupel aus Absender- und Empfängeradresse sowie Sender-IP in der Spamd-Datenbank merkt und auf den zweiten Zustellversuch wartet. Erfolgt dieser, biegt PF den Übermittlungsversuch erneut auf Spamd um, da die Sender-IP ja noch nicht gewhitelistet und damit nicht in der PF-Tabelle »<spamd-white>« eingetragen ist. Erst nachdem Spamd das identische Tupel mit dem Status »GREY« in der Datenbank findet, setzt es den Eintrag auf »WHITE« und aktualisiert die PF-Tabelle. Jede E-Mail von dieser Sender-IP marschiert nun direkt zum MX durch.

Auch an das Whitelisting für ausgehende Verbindungen haben die Entwickler gedacht: Der »spamdlogd«-Daemon beobachtet ausgehenden E-Mail-Verkehr und trägt Ziel-IPs in die Spamd-Datenbank ein. Falls die Empfängerseite denselben Server für ein- und ausgehenden E-Mail-Verkehr benutzt, sind Spamd und PF vorbereitet und stellen beispielsweise Antwort-E-Mails direkt zu. Aus Sicht einer per SMTP übermittelten Nachricht haben Empfänger- und Sender-IP zwar protokolltechnisch nichts gemein, aber die Praxis zeigt, dass einige sendende MTAs auf derselben IP auch Nachrichten annehmen.

Greyscanning

Einmal korrekt zustande gekommene Mailverbindungen landen also in der Whitelist. Zukünftige Nachrichten müssen sich somit nicht mehr der aufwändigen Untersuchung unterziehen. Da sich das Internet jedoch dynamisch verändert, gibt Spamd diesen Einträgen eine Lebensdauer von 36 Tagen, lang genug für monatlich versandte Newsletter. Eine neue Nachricht setzt diesen Timeout wieder zurück. Damit stellt Spamd sicher, dass nur inaktive IP-Adressen aus der Whitelist verschwinden.

Nachdem Spamd einen Zustellversuch nach dem Greylisting-Paradigma temporär abgelehnt hat, erwartet er den zweiten Zustellversuch frühestens in 25 Minuten und spätestens in 4 Stunden. Das sollten Mail-Admins ihren Nutzern möglichst mitteilen. Das bedeutet nämlich, dass etwa eine Bestätigungsmail von einer Anmeldung im Web frühstens nach dieser Zeit eintrifft, wenn der Dienst noch nicht in der Whitelist steht. Auch dieser Wert ist jedoch einstellbar.

Die so gewonnene wertvolle Zeit bis zur zweiten Verbindung nutzt der Spamd, um Informationen über das gespeicherte Tupel von IP-Adressen sowie Namen von Empfängern und Absendern einzuholen. OpenBSD erlaubt es, eigene Skripte einzubinden. Es gibt aber außerdem erprobte Werkzeuge wie etwa das Greyscanner-Skript von Bob Beck, dem Spamd-Entwickler. Das nicht standardmäßig in OpenBSD enthaltene Tool installiert der Systemverantwortliche in »/stand/greyscanner« [7]. Es benötigt einige Perl-Module, die er mit »pkg_add« von einem OpenBSD-Package-Mirror [8] nachinstalliert:

export PKG_PATH=ftp://mirror.switch.ch/pub/OpenBSD/$(uname -r)/packages/$(uname -m)
sudo pkg_add p5-Net-DNS p5-Email-Valid

Ein aktiver Greyscanner arbeitet sich durch alle Spamd-DB-Einträge und analysiert eine Reihe von formalen Kriterien der erhaltenen Tupel. So prüft er, ob die Domain des Versenders einen A- oder MX-Record eingetragen hat und ob alle Adressen korrekt formatiert sind. Optional fragt er ab, ob der Empfänger lokal überhaupt bekannt ist. Schließlich berechnet er eine Statistik, wie viele Nachrichten eine bestimmte IP an unterschiedliche Domains addressiert. Wer zu viele ähnliche Nachrichten an viele Domains verschickt, macht sich verdächtig.

Um dieses Verhältnis zu bestimmen, muss er während der Wartezeit von Spamd mindestens zweimal die Datenbank durchsuchen. Standardmäßig passt das Scan-Intervall von 10 Minuten zum Spamd-Default von 25 Minuten. Wer diesen Wert verringert, muss deshalb ebenfalls das Scan-Intervall des Greyscanners reduzieren. Er startet ihn dann mit »/stand/greyscanner«.

Findet der Greyscanner nun einen nicht-konformen Eintrag in der Datenbank, die Spamd führt, ändert er die zugehörige Sender-IP vom Status »GREY« zu »TRAP«. Ab sofort fängt er alle Zustellversuche dieser IP ab (Trapping). Getrappte IP-Adressen werden nicht nur für 10 Sekunden verzögert, sondern bleiben mindestens 24 Stunden lang im Tarpit (der Teergrube) hängen – bis sie irgendwann entnervt abbrechen. So gehen dem Spammer Zeit und Ressourcen verloren. Da sich der Absender damit nicht RFC-konform verhält, schätzt Spamd die Wahrscheinlichkeit hoch ein, dass dieser ein Spammer ist.

In so einem Fall kehrt Spamd die Beweispflicht um: Erst wenn sich die IP nach frühestens 24 Stunden RFC-konform verhält, wird Greyscanner sie nicht mehr trappen – und E-Mail von dieser IP erreicht ihr Ziel. Natürlich ist es genauso möglich, dass eine Fehlkonfiguration eines eigentlich legitimen Senders im Tarpit landet. Hier hilft es, den Postmaster freundlich auf den Fehler hinzuweisen. Erfahrungsgemäß nehmen die angeschriebenen Admins solche Hinweise dankbar auf und setzen sie schnell um. Die Wahrscheinlichkeit ist nämlich groß, dass auch andere Mailserver die verschickten E-Mails nicht wie gewünscht zustellen.

Greytrapping

Zusätzlich zu Greylisting und Greyscanning bietet Spamd mit Greytrapping eine nützliche Möglichkeit, Spammer in die Falle zu locken. Dazu definiert der Admin eine Anzahl von E-Mail-Adressen, Domains oder Subdomains, die er in Wirklichkeit gar nicht benutzt. In Foren oder Blogs publiziert, hofft dieses Verfahren darauf, dass automatische Erntemaschinen für Mailadressen sie aufsammeln. Auf diese Weise leidet die Qualität der Listen aus Sicht der Spammer, da Spamd solche Adressen in der Tabelle »<spamd-tarpit>« sammelt und umgehend ins Tarpit schickt. Eine solche Adresse aktiviert der Admin beispielsweise mit »spamdb -T -a \’spamtrap@mydomain.org\’«.

Die zweite Variante des Greytrappings implementiert eine Anforderung, die eigentlich jeder MTA umsetzen sollte: Die Positivliste in »/etc/mail/spamd.alloweddomains« enthält Domains, Domainteile und E-Mail-Adressen, für die sich der Mailserver zuständig fühlt. Andere weist das Gateway gleich wieder ab. Das ist besonders dann nützlich, wenn ein Skript die Datei mit Benutzerdaten füllt:

@blowfish.org
obtuse.com
stephan.rickauer@mydomain.org

Diese Konfiguration erlaubt nur Zustellversuche an »blowfish.org« sowie alle Domains, die auf »obtuse.com« enden, etwa an »startek@snouts.obtuse.com«. Die letzte Zeile akzeptiert zusätzlich Nachrichten an »stephan.rickauer@mydomain.org«. Alle anderen Versuche weist die Software kompromisslos ab und schickt sie ins Tarpit.

Greyscanner kann dem Admin die Verwaltung der Datei auch abnehmen, denn das Skript verarbeitet optional Adressen und Domains via Regular Expressions und greift per Plugin-Schnittstelle auf LDAP- oder Active-Directory-Server zu. Aber Vorsicht: Auch Tippfehler von legitimen Versendern bestraft Greytrapping gnadenlos. Immerhin erhalten diese frühzeitig eine Bounce-Mail und dürfen ihre Nachricht dann korrekt adressieren.

Greytrapping ist ein mächtiges Features von Spamd, da es erlaubt, eine maßgeschneiderte Blacklist für die eigene Umgebung zu erzeugen. Damit wird das Hauptproblem der Ungenauigkeit von Blacklists völlig eliminiert.

Schwarz-Weiß-Malerei

Spamd integriert auch klassische Blacklists. Dazu dient die Datei »/etc/mail/spamd.conf«. Der Admin findet bereits vier Listen vorkonfiguriert. Die Blacklist »uatraps« generiert beispielsweise der externe Spamd-MX einer kanadischen Universität mit einem ähnlichen Setup. Will der Admin etwa nur diese auswählen, ändert er die Zeile »:uatraps:nixspam:china:korea:« in »:uatraps:« und startet Spamd mit einem »sudo pkill -HUP spamd« neu.

Ruft der Systemverwalter »/usr/libexec/spamd-setup« auf, aktiviert er den bereits eingetragenen, aber auskommentierten Cronjob von Root. Er aktualisiert damit stündlich alle konfigurierten Listen.

Wer ganz sicher gehen will, gibt erlaubte Adressen an. Das Schlüsselwort »white« überschreibt die Blacklists mit eigenen IP-Listen. Den Greylisting-Prozess müssen erlaubte Adressen dann zwar weiterhin durchlaufen, doch verhindert dies, dass sie fälschlicherweise im Tarpit landen. Ein Beispieleintrag dazu findet sich in der spamd-Konfigurationsdatei sowie in der Manpage »spamd.conf(5)«.

Unter der Lupe

Was wäre ein sauber arbeitender Daemon ohne Logging und Debugging-Funktionalität. Unter OpenBSD stehen in Bezug auf Spamd zwei Userland-Tools sowie eine Logdatei zur Analyse des Spamd-Systems bereit. »pfctl« dient als Schnittstelle zu PF und klärt über den Inhalt der Tabellen auf. Die Manpage »pfctl(8)« erklärt die mächtige Syntax im Detail. »spamdb« zeigt den Inhalt der Spamd-Datenbank oder führt mit zusätzlichen Parametern Änderungen daran durch. Die wichtigsten Kommandos listet Tabelle 1 auf.

Die Ausgabe von »spamdb« lässt sich leicht parsen. Tabelle 2 zeigt einige Beispieleinträge. Die Spalten »first«, »pass« und »expire« zählen die Sekunden seit Epoch. Die drei Zeitstempel geben an, wann die Software den Sender erstmals registrierte, wann die IP zum Status »WHITE« wechselte und wann der »WHITE«-Status auslaufen wird. Bei einem »GREY«-Eintrag sind deshalb die letzten beiden Daten identisch.

Der »block«-Zähler zeigt an, wie häufig Spamd den Host mit dem Antwortcode »451« abgespeist hat. Wie viele Male die IP zum Backend-MTA durchgelassen wurde, protokolliert »spamlogd« im »pass«-Zähler, hier natürlich ebenfalls noch Null. Das Format für »WHITE«- und »TRAP«-Einträge ist ähnlich, unterscheidet sich aber in der Anzahl Felder. Datensätze mit dem Status »BLACK« sind nicht explizit aufgeführt, denn Tupel mit diesem Wert stehen nicht in der Datenbank.

Logfiles

Die vom Spamd-Daemon protokollierten Meldungen finden sich in »/var/log/daemon«. Der Greyscanner kann so konfiguriert werden, dass er in dieselbe Datei schreibt (Listing 3). Zeile 1 zeigt den Verbindungsaufbau einer unbekannten IP. In Klammern steht die Zahl der derzeitigen Spamd-Verbindungen und die der sich im Tarpit befindlichen IPs.

01 Oct  9 14:06:47 mygate spamd: 81.143.30.46: connected (46/35)
02 Oct  9 14:06:49 mygate spamd: 91.122.70.203: disconnected after 12 seconds.
03 Oct  9 14:06:49 mygate spamd: 83.22.246.134: disconnected after 81 seconds. lists: spamd-greytrap
04 Oct  9 14:06:50 mygate spamd: 195.117.152.136: connected (45/34), lists: uatraps
05 Oct  9 14:06:53 mygate greyscanner: Scan started
06 Oct  9 14:07:17 mygate greyscanner: scanned 9866 whitelisted, 4506 trapped, 1475 unique greys
07 Oct  9 14:14:17 mygate greyscanner: Trapped 124.121.75.161: Host sending from 14 domains (> 3)
08 Oct  9 14:14:17 mygate greyscanner: Trapped 67.234.218.185: Invalid source address Matthias (rfc822)
09 Oct  9 14:14:21 mygate greyscanner: Scan completed

Zeile 2 protokolliert das Ende einer 12 Sekunden andauernden Verbindung. Also landet sie als »GREY« in der Spamd-Datenbank, da sie die 10 Sekunden des anfänglichen Stotterns brav geduldet hat. Zeile 3 zeigt einen weniger wohlgesonnen Genossen. Spamd hatte diese IP als »TRAP« erkannt und rang dem Spammer 81 Sekunden Zeit und damit Geld ab. Spitzenreiter kommen auf viele Stunden. Zeile 4 zeigt eine IP, die die Blacklist »uatraps« erkannt hat. Sie wandert ebenfalls in den Tarpit und wird beim Disconnect erneut im Log erscheinen.

Die restlichen Einträge stammen vom Greyscanner im Debug-Modus. Zunächst verschafft er dem Admin eine Übersicht der gescannten Einträge, bevor er sich den verdächtigen Kandidaten widmet. Die Zeilen 7 und 8 trappen die entsprechenden IPs und nennen einen Grund. So behält der Admin die Übersicht über die Spamd-Abläufe und kann notfalls manuell eingreifen – sofern der Umfang der empfangenen Mails das noch zulässt.

Doppelt hält besser

Spamd lässt sich auch ausfallsicher betreiben. Dabei synchronisieren zwei oder mehrere Daemons ihre Spamd-Datenbank. Gleichzeitig bekämpft dieses HA-Setup nebenbei einen weiteren Trick von Spammern, den so genannten Low-Priority-MX-Abuse. Hierbei stellen Spammer ihren Datenmüll dem niedriger priorisierten Mail-Exchanger zu, in der Hoffnung, dass dieser über weniger ausgefeilte Filtermethoden verfügt. Läuft der Spamd im synchronisierten Betrieb, erkennt er dies und trappt IP-Adressen, die direkt an einen untergeordneten Server zustellen wollen, ohne zuvor den primären Server befragt zu haben.

Bei der Fülle an Einzelverfahren kommt es letztlich darauf an, wie effizient sie Spam abblocken. Eine Untersuchung bei einem Dienstleister für Mailserver zeigt (Abbildung 4), dass 16 Prozent der Verbindungsanfragen das Tarpit erkennen und sofort abbrechen. Mehr als ein Drittel aller ungewollten Verbindungen verhindern die konfigurierte Blacklist »uatraps« und das Domain-Trapping. Weitere rund 40 Prozenz bringt das Greylisting zur Strecke. Die restlichen fünf Prozent erledigt eine Contentanalyse mit Dspam. Zu beachten ist, dass die kostengünstigen Verfahren möglichst früh greifen sollten, um Ressourcen beim Filtern zu sparen. Insofern sind die Trefferquoten zwangsläufig auch von der konfigurierten Reihenfolge abhängig. Daher sind die Werte untereinander nicht vergleichbar.

Abbildung 4: Die Effizienz von Antispam-Maßnahmen hängt stark davon ab, in welcher Reihenfolge sie angewandt werden. 16 Prozent der Dosenfleisch-Verschicker geben schon in der Stotterphase auf, jeweils knapp 40 Prozent kapitulieren bei Greylisting und Greytrapping.

Spamd unter OpenBSD punktet durch die Integration seiner Komponenten. Die Einzelteile und Techniken gibt es alle auch für andere Betriebssysteme und Distributionen, aber die geringere Auswahl macht es dem Admin auch leichter, einen guten Spamschutz einzurichten. Das Subsystem stellt dabei alles bereit, was das Füllhorn der Spambekämpfung zu bieten hat: Black- und Whitelists, klassisches Greylisting und ein paar nützliche Variationen drumherum. Das Tüpfelchen auf dem i ist der Spamd-Ansatz, den Versendern ungewollter E-Mail-Nachrichten das Leben so richtig schwer zu machen. Vielleicht lässt sich die Zeit nutzen, in der die Spammer in den Teergruben zappeln, um schon einmal die nächste Runde des Wettrüstens zu planen – denn die kommt bestimmt. (mg/dko)