datenklause.de » Spam

Spamassassin und T-Online-Server ohne DNS-Eintrag

sirko — Mon, 28 Jun 2010 10:19:10 +0000

T-Online hat offensichtlich für mehrere Server (z.B. fwd01.aul.t-online.de oder fwd01.t-online.de) keine DNS-Einträge gesetzt, trotzdem werden von T-online diese “Server-Namen” ohne Angabe von IPs in die Header der ausgehenden Mails geschrieben. Damit erkennt Spamassassin diese Server natürlich nicht als trusted_networks und ALL_TRUSTED feuert nicht. So liefern verschiedene Tests dann falsche Ergebnisse, RBLs werden abgefragt (was bei trusted_networks ja sonst gar nicht passiert), und einige Mails werden falsch als Spam eingestuft.
Als Workaround haben wir required_hits erhöht und den score von REVC_IN_PBL und RECV_IN_SORBS_DUL auf 0 gesetzt. Ja, und jetzt rutscht natürlich ab und an etwas Spam in die Mail. Die andere Alternative wäre gewesen, die T-Online-Server auch als internal_networks zu klassifizieren, aber von dort kommt leider auch eine Menge Spam, weil viele Kunden dort Weiterleitungen zu uns eingerichtet haben. Deswegen geht das nicht.
Eine sehr unbefriedigende Situation.

Spass mit der CBL

sirko — Fri, 05 Feb 2010 14:41:21 +0000

Die Betreiber der CBL antworten auf Anfragen, warum man gelistet wurde. Lobenswert. Wir haben jetzt herausgefunden, warum ein Server nahezu täglich auf dieser RBL landete. Die Maillogs des Servers enthielten keine Anomalien, also konnten wir davon ausgehen, dass der Versand direkt via SMTP von einem PHP-Script geschah. Jetzt wissen wir, wer dafür verantwortlich war:

Ein Kunde programmiert offenbar gern und kam auf die grandiose Idee, zum Schutz seines Gästebuchs vor Spammern nicht nur Captchas einzusetzen, sondern auch die E-Mail-Adresse der Gästebuch-Schreiberlinge zu verifizieren, indem er quasi life prüfte, ob eine E-Mail an die angegebene Adresse vom zuständigen MX auch angenommen wird. Nur zu dumm, dass diese Prüfung VOR erfolgreicher Prüfung der Captchas stattfand…

Spamtrap-Orders

sirko — Thu, 28 Jan 2010 14:36:41 +0000

Ich habe einen bösen Verdacht. Ein bestimmter Server landet beinahe täglich auf einer RBL. Die Mail-Logs habe ich nun täglich untersucht, es gibt kein erhöhtes Mail-Aufkommen, die Absender- und Ziel-Adressen weisen keine Anomalien auf, die auf Spam hinweisen. Besagte RBL arbeitet mit Spam-Traps. Auf dem Server liegen fast nur Online-Shops verschiedenster Art. Trotzdem landet die Kiste fast täglich auf einer RBL. Das kann kein Zufall sein.

Wenn man wissen will, warum etwas geschieht, endet man immer bei dieser uralten Frage: Que bono. Wer profitiert?

Nun ist es für einen Online-Shop ziemlich dumm, wenn ein beträchtlicher Teil der ausgehenden Mails nicht ankommt. Es wäre eine effektive Form von Sabotage, täglich beim Shop eines Konkurrenten eine Fake-Bestellung mit einer Spam-Trap-Adresse auszuführen. Der Aufwand ist minimal und die Wirkung enorm. Egal, ob es die Verifikation der E-Mail-Adresse oder die Bestellbestätigung ist, die IP des Servers vom Shop landet durch eine einzige Mail in einer RBL.

Ich kann das natürlich nicht beweisen. Noch nicht. Aber da fällt mir sicher etwas ein.

Spammende Kunden

sirko — Wed, 27 Jan 2010 13:00:46 +0000

Es wird zunehmend schwerer, die Kunden zu identifizieren, über deren Webseiten (genauer über darin enthaltene Sicherheitslücken) Spam verschickt wird. Mittlerweile sind die Spammer, also die Leute, die diese Sicherheitslücken zum Spam-Versand mißbrauchen, so clever, dass sie nicht mehr als 10 Mails am Tag pro geknackter Website versenden. Darum fliegen solche Benutzerkonten natürlich lange unter dem Radar. Und wir wundern uns, dass Server auf einer RBL landen, ohne dass nennenswertes Mail-Aufkommen von diesem Server zu beobachten ist.
Das ist ganz schön doof. Für uns Hoster.
Ich musste eben Serverlogs von mehreren Tagen mergen und nach Anomalien bei den Absender-Adressen suchen. Was für ein undankbarer Job.

Suchbegriff-Spam

sirko — Tue, 30 Dec 2008 13:44:53 +0000

Offenbar ist Referer-Spam nicht mehr angesagt. In den Web-Statistiken einer bei uns gehosteten Seite tauchen aber viele pornographische Begriffe auf, die zwar nichts mit der Webseite gemein haben können, aber eine Gemeinsamkeit aufweisen: Sie sind relativ lang und haben alle Tippfehler. Gibt man diese Vertipper-Suchbegriffe bei Google ein, bekommt man nur sehr wenige Treffer. Clever. Ohne die Vertipper würden die Seiten der Spammer nie unter den ersten Suchergebnissen auftauchen, weil andere Seiten einen viel höheren PageRank haben. Aber so ist das natürlich ein Kinderspiel.
Sollte sich diese Praxis ausweiten, dürfte unser Support recht viel Arbeit bekommen. Ein normaler Webmaster kann sich natürlich nicht erklären, warum er mit solchen Suchbegriffen in Verbindung gebracht wird.

Spam: Der McColo-Knick

sirko — Tue, 18 Nov 2008 12:34:21 +0000

So sieht bei uns der Spam-Anteil am Mail-Aufkommen aus. Man beachte den Knick, der sich wahrscheinlich auf das Abklemmen der McColo Corp. vom Rest des Internet zurückführen läßt.

Nachtrag: Mehr dazu auch bei adminlife.net und beim Rackblogger.

Weniger Zombies?

sirko — Mon, 31 Mar 2008 10:30:02 +0000

Ein Kollege von einer anderen Firma schickte mir gerade eine Statistik von seinem Greylisting. Demnach hat sich seit diesem Wochenende die Anzahl seiner Greylisting-Triplets dramatisch verkleinert. Wenn ich mir nun unsere eigenen Statistiken ansehe, ist der Stand so niedrig wie seit der zweiten Novemberhälfte 2007 nicht mehr (Erfaßt sind nur die gleichzeitigen Verbindungen zu Port 25 vom Greylisting-Server). Da erkennt man schon deutlich, dass auch unsere Kurve steil nach unten zeigt.

Nachtrag: Spam-Versand durch reguläre Accounts

sirko — Thu, 06 Mar 2008 14:57:52 +0000

Hier schrieb ich, daß wir kaum Gegenmaßnahmen zur Hand haben, wenn die Spam über geknackte reguläre POP-Konten geschickt wird. Diese Aussage muß ich teilweise revidieren. Distributed Checksum Clearinghouse (DCC) erweist sich derzeit als ungeahnt effektiv. Noch, denn das bedeutet, daß die Spammer noch nicht angefangen haben, diese Mails zu personalisieren. Nur schade, daß DCC wegen der Lizenz nicht standardmäßig im Spamassassin aktiviert ist.

Spam-Versand durch reguläre Accounts

sirko — Tue, 19 Feb 2008 11:40:42 +0000

Heise schreibt, daß Spammer erste Testläufe für den Versand von Spam mit geknackten Kunden-Konten machen. Angekündigt habe ich dies schon 2005 auf dem 21C3, nun heißt es Gegenmaßnahmen zu treffen. Tarpitting ist ja sowieso schon Pflicht. Im Gegensatz zu altmodischer Spam besitzen diese Spam-Mails weitgehend korrekte Header, d.h. man könnte alle NDNs in ein Script pipen und den Return-Path herausholen. Sollte die Anzahl NDNs je Return-Path einen Schwellwert überschreiten, könnte man den Account aus dem Return-Path für den Versand sperren. Das reicht aber noch nicht. Immer weniger Mailserver senden überhaupt noch NDNs, einige blockieren zumindest per 5XX-Fehlermeldung beim SMTP-Dialog, wenn der Empfänger nicht existiert. Also müßte man auch die Logfiles in Echtzeit parsen (man bedenke dabei aber, der SMTP-Auth-Login ist ohne Reverse Split Horizon nicht zwingend die Absender-Adresse). Die Spammer werden vielleicht wieder versuchen, die Mails zu personalisieren damit die Bayes-Filter nicht trainiert werden, das würde aber viele Verbindungsaufbauten von wenigen IPs an den Ports 25 bzw. 587 bedeuten, was leicht zu begrenzen wäre.
Auch wollen sie bestimmt wieder von vielen Quell-IPs aus versenden, damit DCC oder Razor/Pyzor nicht anschlagen. Das setzt aber eine entsprechende Anzahl geknackter Konten auf verschiedenen Servern voraus. Und wenn sie (wie derzeit bei den meisten Fällen von Spam-Versand über Schwachstellen in Web-Applikationen) nur ein einziges Mal 1000 oder 3000 Mails je geknacktem Konto versenden, haben wir kaum Gegenmaßnahmen zur Hand. Ich glaube, diese Runde geht erstmal an die Spammer.

Massenversand von E-Mails

sirko — Wed, 23 Jan 2008 13:13:25 +0000

Soeben haben wir beschlossen, unsere AGB um einige Punkte zum Massenversand von E-Mails zu erweitern. Bis dato sieht die Liste so aus:

Jeder Empfänger muß sich selbst aktiv in die Empfänger-Liste eingetragen haben (Opt-In). Diese Bedingung gilt auch als erfüllt, wenn er in einem Webformular eine Checkbox “Ich will den Newsletter XYZ erhalten” selbst angewählt hat.

Die Absender-Adresse der Massen-Email muß eine gültige E-Mail-Adresse sein, die vom Absender ausgewertet wird. Sollte diese Auswertung maschinell geschehen, müssen alle nicht automatisch auswertbaren E-Mails an diese Adresse manuell ausgewertet werden.

Jede Massen-E-Mail muß den Header “Precedence: bulk” beinhalten.

Jede Massen-E-Mail muß eine Option zum Austragen aus der Liste in Form einer URL oder eines Links der Form mailto:adresse@domain.tl?Subject=empfaenger@domain2.tld austragen beinhalten.

Jeder einzelnen Bitte um Austragung aus der Empfänger-Liste, gleich in welcher Form sie gestellt wird, ist unverzüglich nachzukommen.

Die in Rückläufern (Bounce-E-Mails) mit permanenten Fehlermeldungen angegebenen Empfänger-Adressen müssen unverzüglich aus der Empfänger-Liste entfernt werden.

Weitere Vorschläge?