Kampf dem SPAM ( XL )

Kampf dem SPAM ( XL )

Das ist mein 40. Beitrag, in dem es um SPAM geht (direkt oder indirekt) geht. Trauriges Jubiläum, denn das ist sicherlich das unproduktivste Thema für jeden Serverbetreiber. Dafür aber um so Zeitaufwändiger.

Ich werd mal Revue passieren lassen, was in den Jahren so gelaufen ist, in diesem Zusammenhang.

Nachdem es uns um die Jahrtausendwende nicht mehr gereicht hat, die täglichen SPAM-Mails zu löschen, hatten wir (damals Fair-Networx & ISSB) einen Client-proxy entwickelt, der einkommende POP3 Mails auf Spamtexte untersucht. Es war ein reiner Inhaltsfilter mit selbstlernendem Wörterbuch. Das Produkt war der ISSB-SpamTrash, lief nur auf Windows, und hat super sortiert, wenn man ihn monatelang trainiert hat. Allerdings musste man sich immer noch alle Spammails zu Kontrollzwecken ansehen, automatisches Löschen konnte ungewünschte Nebeneffekte haben. Bei verschlüsselter oder codierter Mail hat das nicht funktioniert.

2007 haben wir dann schrittweise auf Blockierung der Mails statt filtern gesetzt, damals mit dem ASSP (Anti-Spam SMTP Proxy). Tolle Sache, sehr transparent, man kann eine Menge von dem Ding lernen. Der lief letztendlich auf einem eigenen Server vor unserem Windows-basierten Mailserver. Spams wurden somit nicht mehr dem Empfänger überlassen, sondern die Annahme verweigert, zusammen mit einer Fehlermeldung, die die Ursache beschreibt. Damit kann der Absender (so es denn ein Mensch war und die Ablehnung falsch) entsprechende Maßnahmen einleiten, um zukünftige Zustellversuche erfolgreicher werden zu lassen. Maschinen oder SpamBots haben diese Fehler ohnehin nie gesehen.

Das man vom ASSP eine Menge lernen kann, haben sich wohl die Entwickler von Postfix (Mail-Server für Linux) auch gedacht, und dem System eine Menge der Funktionen aus ASSP auch spendiert. Als wir 2009 dann das Mailsystem auf Linux umgestellt hatten, entfiel ASSP. Eine Erkennung auf irreguläres Verhalten der Absendersysteme und einige wenige Regeln (PTR/helo/hostname) sowie eine manuell geführte Böse-Buben-Liste und einen Regelsatz für ungültige Absender haben lange Zeit gereicht, so viel unerwünschte Mail abzuschmettern, das jeglicher Mehraufwand nur so einen geringen Nutzwert gehabt hätte, das es sich nie gelohnt hat, selbigen zu betreiben.

Da wir zumeist unsere Policies kommunizieren und auch reichlich Nachahmer haben, wurde unsere Block-Logik vielfach auch von Kollegen übernommen. Die Folge: Spammer mussten sich was neues einfallen lassen, als ungeschützte Rechner an privaten Internetanschlüssen zu kapern, um ihren Dreck loszuwerden.

Seit mitten letzten Jahres nehmen nun Mails von gekaperten Servern zu.

Systeme, die eigentlich in professionelle Hände gehören, sich in einer Leistungsstarken Umgebung befinden und von Hause aus unverdächtig Mails versenden können. Es werden Mails in ganz unglaublichen Größenordnungen zugestellt und das von regulären und korrekt konfigurierten Mailservern.

Da bleibt dann nur ein Mittel, von dem wir uns mit dem ASSP zusammen verabschiedet hatten: RBL.

Da wir aber diverse Erfahrungen mit diesen Listen haben was falsche positive betrifft, wollten wir uns nicht auf eine einzelne verlassen. Denn auf eine Blacklist kommt man schon mal, wenn ein Kunde bei einer Rundsendung übertreibt.

Und auch hier scheinen die Postfix-Leute unserer Meinung zu sein, denn es gibt inzwischen eine Postfix-Erweiterung: Postscreen. Diese ist nun auf unseren eigenen Mailsystemen (mail.crnet.de/mx.anycast.io) aktiv, unsere Konfiguration prüft 11 RBLs und verweigert die Annahme, wenn ein kontaktierender Server auf 2 oder mehr Listen zu finden ist.

Auf 2 verschiedene RBLs kommt man nicht zufällig – somit gibt es im Falle einer Ablehnung keine falschen positiven. Falls man auf 2en ist, hat man eh ganz andere Sorgen.

Und das läuft nun:

Die Auswahl der 11 Listen lief in den letzten Wochen, wir haben einige sehr kurzlebige, auf die Spammer durch Automatismen schnell kommen, aber auch schnell wieder verschwinden und einige manuell geführte, mit längeren Laufzeiten.
Wir hatten die Tests in 2 Stufen anrollen lassen: erst einmal grundsätzlich auf einem mäßig frequentierten Einzelserver, dann auf einer Adresse im anycast-Cluster (da ist die Konfiguration etwas aufwändiger) – und nun haben wir es für das Gesamtsystem aktiviert.

Mal sehen, wie lange es gut genug ist.

 

Über den Autor

Christian Rehkopf administrator