Das Spam-Problem hat in den letzten Monaten bei mir etwas überhand genommen. Der Großteil der Mails, die an eine meiner Domains gesendet werden, landen auf einem gemeinsamen Server und wurden bisher ausschließlich SpamAssassin vorgeworfen.

Der Assassine leistet hervorragende Arbeit. Um Spam (= unerwünschte Mail) von Ham (= erwünschte Mail) zu unterscheiden, führt er eine Reihe von Tests durch:

• Prüfung der Mails auf statistische Spam-Merkmale (z.B. “Absender aus Korea”, “Mail nur in GROSSBUCHSTABEN”, …)
• Abfrage von RBLs und DNSBLs
• Abfrage von Prüfsummen-basierten Filter-Diensten
• Bayes-Filterung

Das Problem: Die Durchführung dieser Tests ist ressourcen-intensiv. Neben einer Menge Hauptspeicher belegt die Spam-Filterung zusätzlich CPU-Arbeitszeit und die Abfragen an netzbasierte Dienste summieren sich auch.

Schaut man sich einmal das Aufkommen von meiner Mail der letzten Monate an…

Mailaufkommen (Größter Teil meiner Mailadressen) 2007/2008

…so sieht man, dass die Situation wohl eher nicht besser wird.

Neben dem Problem der Ressourcen-Auslastung (das z.B. dazu führt, dass die Webseiten auf dem Server – unter anderem Wikipedistik – langsamer ausgeliefert werden) kommt noch dazu, dass die Anzahl der false negatives steigt. Unter “false negative” versteht man Mails, die Spam sind, aber nicht als solcher erkannt werden. Diese Nachrichten verstopfen die Inbox und verursachen Aufwand, da sie von Hand gelöscht werden müssen.

SpamAssassin ist gut – aber kein Spamfilter hat eine Erkennungsrate von 100 Prozent. Daraus folgt: Je mehr Mails durch den Filter gehen, desto mehr Problemfälle treten auf. Dank sinnvoller Einstellung gibt es bei mir jedoch so gut wie keine false positives, also Mails, die erwünschte Mails darstellen, aber als Spam erkannt wurden. Der Preis für eine geringere Wahrscheinlichkeit an “false positives” ist jedoch eine höhere Wahrscheinlichkeit für “false negatives”.

Die einfachste Lösung um die Anzahl an Fehleinordnungen wieder zu senken ist einleuchtend: Die Anzahl der von SpamAssassin zu bearbeitenden Mails muss gesenkt werden. Dies führt dann zusätzlich zu einem weniger ausgelasteten, performanteren System.

Greylisting
Aus diesem Grund habe ich am Karfreitag um 7:00 Uhr auf meinem Mailserver Greylisting aktiviert.

Whitelisting bedeutet, dass Mail nach bestimmten Kriterien immer angenommen wird, während beim Blacklisting die Mail immer abgelehnt wird. Greylisting nutzt hingegen eine Besonderheit des SMTP-Protokolls: Kann eine Mail nicht zugestellt werden, so versucht es der entsprechende Server nach einer gewissen Zeitspanne erneut.

Während diese Funktionalität in jedem vernünftigem Mailsystem umgesetzt ist, so gilt dies nicht für eine Vielzahl von Spam-Software, die wesentlich einfacher gestrickt ist und in der Regel nur einen Zustellversuch macht.

Kontaktiert ein einlieferndes System meinen Mailserver, so gibt es folgende Daten an:

• IP-Adresse des absendenden Mailservers
• E-Mail-Adresse des E-Mail-Senders
• E-Mail-Adresse des E-Mail-Empfängers

Wurde noch nie Mail empfangen, auf die dieses Trippel zutrifft, so wird die Maileinlieferung mit einem temporären Fehler quittiert. Ein herkömmliches Mailsystem versucht dann nach einer kurzen Zeitspanne eine erneute Einlieferung, die dann akzeptiert wird. Bei der Vielzahl von einmaligen Zustellversuchen von Spam führt dies dazu, dass die betreffende Mail gar nicht erst in meinem System landet und demnach auch nicht von SpamAssassin untersucht werden muss.

Systeme, die in der Greylist gelandet sind und danach eine erfolgreiche Zustellung durchführen, werden automatisch in die Whiltelist aufgenommen. So tritt der Nachteil der nicht unmittelbar ankommenden Mail nur beim ersten Kontakt mit einem bisher unbekannten Trippel auf. Trotzdem muss natürlich dieser Nachteil mit einem möglichen Vorteil abgewogen werden.

Wie meine Abwägung ausfällt?
Das muss ich glaube ich nicht extra in Worten beschreiben.

Die folgenden Graphen sprechen für sich:

Angenommene (und verarbeitete) Mails – Massiver Rückgang seit Freitag, 7:00 Uhr

(Durch Greylisting) abgelehnte Mails – Aktivierung ab Freitag, 7:00 Uhr

Seit diesem Zeitpunkt sind immerhin 95 Beiträge und 192 Kommentare in diesem Blog erstellt worden. Etwas erschreckend ist es allerdings, wenn man sich anschaut, wieviele Kommentare nicht veröffentlicht wurden: Gestern habe ich den 50.000sten Kommentar-Spam gelöscht.

Ebenso wie Spam den E-Mail-Dienst belastet, belastet er auch Blogs. Spammer wollen entweder ihre Nachricht per Kommentar loswerden, oder einen Link auf ihr Angebot unterbringen. Da das Spamproblem schon bei einem relativ kleinem Nischenblog wie meinem solche Ausmaße annimmt, kann man sich in etwa vorstellen, welche Dimensionen das bei bekannten Blogs erreicht.

Robert Basic sammelt auch schonmal 10.000 Spam-Einträge innerhalb von nicht ganz zwei Wochen. Ohne eine zusätzliche Filtersoftware (ich benutze dazu Akismet) scheint es für Blogs nicht mehr möglich, eine Kommentarfunktion anzubieten.

Eine Reihe von Journalisten hingegen versucht sich im Wettkampf untereinander mit einer enorm hohen Fehlerdichte pro Kurztext zu profilieren. Den Klassiker in dieser Disziplin stellte die unvergessene Zeitschrift TOMORROW auf, die uns 1999 mit dem Abschnitt

WWW. World Wide Web. Dieser Teil der Adresse beschreibt die Organisation, die vereinfacht den Zugang ins Netz ermöglicht. Hier könnte zB auch eine Nummer stehen wie 123.456.789″

einen Höhepunkt bescherte. Oder wie Gisbert Damaschke (nach Wau Holland zitiert) damals treffend feststellte:

Es ist ein Kunststueck eigener Art, so viele Fehler in einen so kurzen Text zu packen. Mein Liebling ist die IP-Adresse mit drei statt 4 Tripeln, von denen 2 auch noch oberhalb von 255 liegen.”

In der heutigen Zeit sind diese Kleinode weitestgehend unerreicht, aber immer wieder gibt es Versuche in die Richtung, die Fehlerdichte möglichst hoch zu treiben. Bereits in der Vergangenheit ist Spiegel-Online positiv in diesem Feld aufgefallen. Heute gab es nach längerer Zeit wieder einen Höhepunkt zu vermelden.

Felix Knoke schreibt im Netzwelt-Ticker:

Wiki-Community verhindert Wurm-Attacke

In einen Wikipedia-Artikel eingefügte Links und eine ganze Spam-Lawine sollte gestern die Malware W32.Blaster verbreiten – aber die Wiki-Community schritt schnell genug ein. Nur Minuten nach der Attacke wurde der Angriff abgewehrt.

• Von einer Wurm-Attacke spricht man in der Regel, wenn ein Wurm sich selber verbreitet.
• Die Wiki-Community (gemeint ist wohl die Wikipedia-Community) hat an dem eigentlichen Spamrun nichts verhindert.
• Dass die Dateien Malware enthielten ist wahrscheinlich – allerdings wurde bei Heise Security keiner von 20 Virenscanner fündig. W32.Blaster war somit also garantiert nicht enthalten.
• Die “Minuten” bis zur Versionslöschung waren leider Stunden. Die entsprechende “manipulierte” Version des Artikels wurde zwar schnell nach Einstellung revertet – das wiederum hatte keinen Einfluss auf den “Angriff”, da in der Spam-Mail der Permalink auf die alte Version genutzt wurde.

Die Mail brüllte laut, wie Spam-Mails eben brüllen: “Wikipedia schlägt Alarm. Neue Variante des W32.Blasters im Umlauf. Wurm-Fix zum Download”. Ein Link zur Wikipedia sollte Vertrauen schaffen: Wer sich gegen die neue Blaster-Variante schützen wolle, müsse nur auf den Blaster-Artikel in der Wikipedia surfen, dort gäbe es die nötigen Updates.

• Von “brüllen” schreibt man im Mailkontext dann, wenn Großbuchstaben verwendet werden – aber ich will nicht zu kleinlich sein.
• Der letzte Satz ist irreführend (war aber auch in der Original-Mail unklar gehalten). In der entsprechenden Artikelversion fand sich ein externer Link auf die angeblichen Updates.

Und tatsächlich: Wer dem Link zur Wikipedia folgte, konnte dort Links zu den Patches finden – samt Hinweis von Microsoft, dass man zu so einem außergewöhnlichen Mittel greifen müsse, da die Microsoft-Downloadserver ausgefallen seien. Natürlich versteckte sich hinter den Downloads nichts anderes als der W32-Blaster, vor dem sich hereingelegte Surfer eigentlich schützen wollten.

• Siehe oben. Wenn in den Dateien eine Malware enthalten war (wahrscheinlich), so definitiv nicht W32.Blaster.

Doch unter den Empfängern der Blaster-Spammail muss auch ein Wikipedia-Autor gewesen sein. Der bemerkte schnell, dass eine einfache Änderung des Artikels nicht viel bringen wird. Der Wurm-Autor hatte auf eine History-Version des Artikel verlinkt, diese Versionen lassen sich nicht ändern. Nur wenige Minuten, nachdem die Spam-Lawine losging, sperrte die Wikipedia deshalb den kompletten Artikel.

• Die logische Schlussfolgerung, warum unter den Empfängern des Spams ein Wikipedia-Autor gewesen sein muss, bleibt mir verborgen. Fakt ist, dass wir unter anderem durch Hinweise von Dritten, aber auch durch eine große Anzahl an Bounces auf den Spamrun aufmerksam wurden.
• Die Aussage, dass der Artikel nach wenigen Minuten gesperrt wurde ist falsch und unsinnig: Eine Sperre bringt hier natürlich nichts. Der wichtige Punkt ist die Löschung der entsprechenden Artikelversion. Dies geschah leider nicht nach Minuten, sondern erst nach Stunden. Nachdem dann die verunstaltete Seite erneut eingestellt wurde, wurde diese wieder gelöscht und der Artikel gesperrt.

Alles in allem ist das für einen relativ kurzen Text eine ansehnliche Fehlerdichte. Aber ich werde die Augen nach weiteren Anwärtern offen halten. Bis dahin ersteinmal herzlichen Glückwunsch, Spiegel-Online!