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

Zu diesem Zweck dienen RSS-Feeds, die sozusagen ein “Abonnieren” der Webseite erlauben. Diese RSS-Feeds werden von Programmen, sogenannten RSS-Readern (auch Aggregatoren oder Feed-Reader genannt) in regelmäßigen Abständen geladen und der Benutzer erfährt so, ob neue Beiträge vorliegen und kann diese dann entsprechend komfortabel lesen.

Das sieht dann in etwa so aus:

Der RSS-Reader akregator

Als ich damals unter Windows gearbeitet habe, fand ich den FeedReader sehr schön. Inzwischen arbeite ich eigentlich nur noch unter Linux (KDE) und verwende dort den akregator.

Der Browser Firefox bietet von Haus aus rudimentäre RSS-Möglichkeiten: Befindet man sich auf einer Seite, die einen RSS-Feed anbietet, so erscheint in der unteren rechten Ecke das dargestellte universelle Symbol für RSS-Feeds. Mit einem Klick darauf öffnet sich ein Auswahlfenster, aus dem man am besten den “RSS 2.0″-Feed auswählt. Speichert man die angegebene Seite auf diesem Weg als Bookmark, so kann man dort jeweils die Überschriften der letzten Beiträge sehen. Auch der kommende Internet Explorer 7.0 wird (laut Heise-Meldung) eine RSS-Unterstützung mitbringen und diese systemweit zur Verfügung stellen (laut golem.de).

Für “Viel-Blog-Leser” ist das alles ein alter Hut. Wer diese Funktionalität aber nicht nutzt und trotzdem auf dem Laufenden bleiben möchte, was sich im Wikipedistik-Bereich tut und was es für Neuigkeiten über die Wikipedia zu berichten gibt, der hat nun auch die Möglichkeit, neue Beiträge per Mail zu abonnieren.

Auf der Seite Feeds / Benachrichtigungen findet sich eine Übersicht über die verschiedenen Abo-Möglichkeiten – und der Einfachheit halber gibts die Möglichkeit der E-Mail-Anmeldung auch direkt hier im Beitrag: