Ein nettes Feature des heute Nacht hier auf den aktuellen Stand gebrachten SpamAssassins ist die Unterstützung sogenannter SURBLs (Spam URL Realtime Block Lists). Im Unterschied zu gewöhnlichen RBLs, die nach Auswertung diverser Received:-Header die dort enthaltenen IPs oder Domain-Namen nach bekannten und gelisteten SPAM-Quellen (schlecht gewartete Mailserver, offene Relays und Proxies) auswerten, beschränken sich SURBLs auf den Body einer Nachricht, also den eigentlichen Inhalt selbst. Gesucht werden hier Verweise auf Domains, die bekannterweise durch SPAM beworben und deshalb in einer SURBL Schwarzliste eingetragen sind.

Wie alle RBLs ist auch eine SURBL mit Vorsicht zu genießen, macht man sich doch von der Sorgfalt und Zuverlässigkeit Dritter abhängig - ein Umstand, der im schlimmsten Fall zu unerwünschten False Positives (fälschlicherweise als SPAM markierten Mails) führen kann. Ein gelegentlicher Blick auf die Funktionalität solcher Filter ist also angebracht. Dennoch: Gerade bei deutschsprachigem SPAM, der SpamAssassin hier sonst sehr viel größere Probleme bereitet als englischer oder asiatischer Werbemüll, erscheint der Einsatz von SURBL durchaus effizient. Etliche Werbenachrichten dieser Natur wurden erst durch das Scoring auf gelistete SURBL Einträge zuverlässig als SPAM klassifiziert.

Für spezifisch deutschsprachige Regeln existiert weiterhin das GermanRules-Wiki, ein Sammelbecken passender Regelsätze, welche die Erfolgsquote beim Aussortieren heimischer Verbraucherinformationen erhöhen sollen - es sind allerdings keine Wunder zu erwarten, wie obiger Absatz verdeutlicht.

Prinzipiell wären SURBLs in meinen Augen auch zum Blocken von Comment SPAM in Weblogs geeignet, mit den schon genannten Einschränkungen. Aktuell laufen bei Kristian und auf der s9y-Mailingliste interessante Diskussionen zu dieser Thematik, zu vorderst allerdings über das Für und Wider eines Abgleichs der IP des Posters mit bekannten Blacklisten, welcher in meinen Augen in diesem Zusammenhang wenig Sinn ergibt. Ausgangspunkt war Garvins kurze Zusammenfassung der für das nächste s9y-Release geplanten Anti-SPAM Konzepte.

Ansonsten bleiben mit dem neuen SpamAssassin Release große und kleine Veränderungen bei der Bayes Datenbank, einzelnen Konfigurationsoptionen und verschiedenen Startparametern beachtenswert, ebenso wie die Einführung des nicht NFS-tauglichen, aber sehr viel effizienteren “Flock” Locking-Mechanismus - “Strongly recommended if you’re not using NFS”. Einen Überblick auf die Neuerungen des 3.0er Releases bietet “Note for Users Upgrading to SpamAssassin 3.0.0”.

====== Top 10 Spammails ===============================================
Subject: **SPAM** Score: 232.45: Small Busi.ness, No T.erminals--vagina
Subject: **SPAM** Score: 191.50: Re: kill claustrophobic
Subject: **SPAM** Score: 190.00: Re: bought staid
Subject: **SPAM** Score: 186.10: Re: embeddable mare
Subject: **SPAM** Score: 179.60: Re: switzerland checkerberry
Subject: **SPAM** Score: 178.60: Re: eightfold
Subject: **SPAM** Score: 168.60: assist it, another joined
Subject: **SPAM** Score: 166.60: plodded back and forth
Subject: **SPAM** Score: 166.10: Re: opinionate
Subject: **SPAM** Score: 164.70: avogadro expose
=======================================================================
number of spammails:	100233
minimum/maximum    :	4.0/232.45

Es ist definitiv wieder an der Zeit, meinen SPAM-Ordner zu leeren. Die hier teilweise ungewohnt hoch erscheinenden SpamAssassin-Scores ergeben sich aus angepassten und externen Regelsätzen. Demnächst müssen diese allerdings einer Frischzellenkur unterzogen werden, in letzter Zeit kommen hier einige False Negatives durch, meist deutschsprachig.

Microsoft spielt derweil gekonnt auf dem so unglaublich innovationsfördernden Instrumentarium des Patentrechts und ist offensichtlich munter dabei, herrlich unspezifisch in die Breite gehende Anträge einzureichen, die bei erteiltem Segen der zuständigen Ämter wohl durchaus in der Lage wären, diverse Ideen und Lösungen im Kampf gegen die ungeliebte Werbeflut zu erschlagen. An dieser Front aktuell aus naheliegenden Gründen also Stillstand statt Fortschritt.

In diesem Kontext wirken die Prophezeiungen der Züricher Ökonomin Margit Osterloh beängstigend real und kalkuliert: In einer Ära legitimierter Softwarepatente hätte Open Source keine Überlebenschance - “Dieses System wird sterben”. Setzt man die erschreckend erfolgreichen Beeinflussungsbemühungen diverser Lobbyisten auf eine willfährige Gesetzgebungspolitik und das Geschäfts- und Patentierungsgebaren großer IT Konzerne sinnbildend zusammen, so ergibt sich eine düstere Zukunftsvision, in der die Größe der Patentportfolios und hauseigenen Justizabteilungen grundlegend über Partizipationsmöglichkeiten am Markt entscheiden wird.