DNSBL - Blacklists

- 1 -


Ich habe mal ein wenig Zeit investiert und mich im Netz umgesehen, warum meine Posts (Blog-Kommentare und E-Mails) sowohl bei den ScienceBlogs als auch bei Google-Mail im Spamfilter landen. Der Grund liegt mit hoher Wahrscheinlichkeit bei meinem Internet-Provider, HanseNet (Alice).

ScienceBlogs benutzen MovableType als CMS (Content Management System), was wiederum (zumindest per Default) SpamLookup benutzt, um Spam zu zu filtern. Dort hat man (als User, wie es z.B. die ScienceBlogs sind) u.a. die Option, die eingehenden Kommentare mit Blacklists abzugleichen (und abzuweisen), Datenbanken also, in denen Versender von Spam verzeichnet sind. Die beiden wichtigsten Anbieter solcher Datenbanken heißen SURBL und URIBL. Bei denen taucht jedoch weder meine Domain (michael-michaelis.de) auf, noch die (dynamische, mir von HanseNet zugeordnete) IP-Adresse, unter der ich meine Posts (Blog-Kommentare bzw. E-Mails) verschicke.

Nach weiterer Sucherei bin ich dann auf die Seiten von BacklistAlert gestoßen. Dort erscheint HanseNet dann in weit mehr als nur einer Blacklist (vergl. die Suchergebnisse meiner momentanen IP). Bei einem Blick auf eine der dort verlinkten Seiten - UceProtect - war dann klar, was los ist: HanseNet ist dort auf Level 3 gelistet. Das ist dort die höchste Stufe, auf der ein Provider nur dann landet, wenn von ihm gehostete IP's richtig Spam in die Welt schicken:

Was bedeutet auf UCEPROTECT-Level 3 gelistet?

UCEPROTECT-Network betreibt eine dreistufige Blackliste um unseren Usern die Wahl zu lassen, wie hart sie filtern möchten. Während Level 1 nur einzelne IP's listet, die innerhalb der letzten 7 Tage wegen Mißbrauchs aufgefallen sind, kann Level 2 als Eskalationsliste bereits komplette Netzbereiche listen, aus denen innerhalb der letzten 7 Tage zu viel Mißbrauch ausgegangen ist.

Level 3 schließlich ist die höchstmögliche Eskalation[...]: Alle IP's des betroffenen Providers werden im Level 3 gelistet, wenn innerhalb der letzten 7 Tage übermäßig viel Abuse von den IP's und Netzen dieses Providers ausgegangen ist, mithin also zu viele spammende IP's im Level 1 gelistet wurden.

[...]

Es gibt derzeit weltweit etwa 105000 Provider, aber nur einige Hundert schaffen es in UCEPROTECT-Level 3 gelistet zu werden.

Gemäß der unabhängigen Statistik des international anerkannten Anti-Spam Gurus Mr. Al Iverson aus Chicago USA sind die wenigen Provider, die es schaffen in unserem Level 3 zu enden, für etwa 35 - 40% des globalen Spams verantwortlich, während der Anteil an realen Mails aus deren Netzen deutlich unter 1% liegt.

Wenn das so ist - und ich habe keinen Grund, daran zu zweifeln - lande ich also mit gutem Grund in den Spamfiltern. UceProtect versichert, daß es einem Provider durchaus möglich ist, dem Problem zu begegnen, das von seinen Servern Spam ausgeht („AOL hat etwas über 6 Millionen IP's und die Mehrheit ihrer Kunden dürften Homeuser sein düften. Trotz dieser Größe sieht man so gut wie keinen Spam aus dem AOL Adressraum.”), und schlägt konkrete Maßnahmen vor, die dieser ergreifen sollte.

Ich habe HanseNet gerade einen Brief (auch via E-Mail)[1] geschrieben, mit der Aufforderung, den Mißstand umgehend abzustellen, und damit gedroht, andernfalls den Provider zu wechseln - und bin gespannt, wie die Reaktion aussieht.

Das beschreibt aber nur einen Teil des Problems.

Heute morgen habe ich einen Kommentar von meinem Arbeitsplatz bei Steinberg gepostet - also mit der IP-Adresse eines ganz anderen Providers (das war der Ausgangspunkt meiner Recherche). Auch das schlug fehl (sprich: landete im Spamfilter). Erst als ich meine E-Mail-Adresse geändert und den Link auf meine Homepage entfernt hatte, ging der Kommentar letztlich durch.

Ein unaufgelöstes Rätsel bleibt also übrig: wieso wird ein Kommentar als Spam eingeordnet, obwohl er von einer IP-Adresse gepostet wird, die auf den Blacklists nicht auftaucht, und einen Verweis (Link, E-Mail-Adresse) auf eine Domain enthält, die ebenso wenig unter Spam-Verdacht steht?

Ich kann mir nur noch vorstellen, daß hier ein Anti-Spam-Plugin am Werke ist, das zu jeder von den Blacklists als „positiv” ausgewiesenen IPs sicherheitshalber die dazugehörige Domain abspeichert, auf die die E-Mail-Adresse verweist - Gründe, dies zu tun, gäbe es mehr als genug. Mit anderen Worten: selbst wenn ich den Provider wechsle, bliebe mir ein ungehinderter Zugang zum - z.B. - Kommentarbereich der ScienceBlogs verwehrt. Mehr noch: alle Kommentare, die einen Link auf meine Seiten enthalten, würden dort ebenfalls zunächst im Spamfilter landen, und müßten darauf warten, von einem Moderator freigeschaltet zu werden.

Solange HanseNet da keine Abhilfe schafft, werde ich jedenfalls sehr genau überlegen, ob eine Mail oder ein Blog-Kommentar es wert sind, daß mein „digitales Zuhause” auf einer Blacklist landet, wodurch ich möglicherweise auf unabsehbare Zeit von Diskursen ausgeschlossen wäre, die ich wichtig finde.




[1] Mein Schreiben an HanseNet:

Sehr geehrte Damen und Herren,

nachdem ich sowohl bei dem Versuch, in Blogs zu kommentieren (namentlich den ScienceBlogs), als auch beim Versenden von E-Mails an Accounts bei Goggle-Mail, im Spamfilter des jeweiligen Adressaten gelandet bin, habe ich nach der Ursache geforscht. Dabei musste ich feststellen, dass der komplette IP-Bereich von Hansenet auf mehreren Blacklists auftaucht. Wenn man beispielsweise bei UceProtect (http://www.uceprotect.net) nach einer IP-Adresse von Hansenet sucht (z.B. meine momentan zugewiesene IP, 85.176.2.88 ), bekommt man den Hinweis, daß Hansenet aktuell auf dem UceProtect-Level-3 gelistet wird.

Ich zitiere die Website:

“Während Level 1 nur einzelne IP's listet, die innerhalb der letzten 7 Tage wegen Mißbrauchs aufgefallen sind, kann Level 2 als Eskalationsliste bereits komplette Netzbereiche listen, aus denen innerhalb der letzten 7 Tage zu viel Mißbrauch ausgegngen ist.

Level 3 schließlich ist die höchstmögliche Eskalation, und listet ausnahmslos das betreffende Autonomus System (AS), was sofern der Provider lediglich über eine ASN (Autonomus System Number) verfügt, grundsätzlich heißt:

Alle IP's des betroffenen Providers werden im Level 3 gelistet, wenn innerhalb der letzten 7 Tage übermäßig viel Abuse von den IP's und Netzen dieses Providers ausgegangen ist, mithin also zu viele spammende IP's im Level 1 gelistet wurden.”

UceProtect verweist auf denn Umstand, daß ein Provider wie AOL trotz ca.6 Millionen IP's nur minimal Probleme mit Usern hat, die Spam versenden, und schlägt auch Maßnahmen vor, wie man diese Probleme in den Griff bekommt.

Ich möchte Sie hiermit auffordern, umgehend Maßnahmen zu ergreifen, um diesem Missstand Abhilfe zu schaffen. Andernfalls sehe ich mich gezwungen, den Provider zu wechseln.

Ich weise Sie darauf hin, daß ich den Vorgang in meinem Blog (http://www.michael-michaelis.de) dokumentieren werde – laut Zugriffsstatistik sind dort überproportional viele Besucher mit einem Hansenet-Account, die das sicherlich interessieren dürfte.

Ich bitte um eine Stellungnahme.

Mit freundlichen Grüßen,



- 2 -


Es ist leicht möglich, daß die eigene IP-Adresse auf Blacklists auftaucht, ohne daß man davon zunächst etwas mitbekommt. Das ist mir, als Hansenet(Alice)-Kunde, soeben passiert.

Man sollte sich klar machen, daß man ein echtes Problem hat, sobald man in solchen Blacklists auftaucht. Mail, die man abschickt, wird nicht gelesen - und zwar ohne daß man dies sofort bemerkt, weil sie beim Adressaten zwar ankommt, dort aber auf Nimmerwiedersehen im Spam-Ordner landet. Auch Kommentare bei Blogs werden als Spam aussortiert, wobei man womöglich auch noch den Namen einer eigenen Domain dem Spamverdacht aussetzt.

Selbst dann, wenn man nie Spam verschickt hat und auch nie gekapert und zum Teil eines Spam-verschleudernden Bot-Netzes wurde, kann man auf Blacklists landen. Das passiert z.B. dann, wenn von den Servern des eigenen Internet-Providers derart viel Spam ausgeht, daß Anti-Spam-Dienste dessen komplette IP-Range in ihre Blacklist aufnehmen. In diesem Fall wird man gewissermaßen in Sippenhaft genommen: man wird dafür bestraft, den Account bei jemandem zu bezahlen, der Spam-Mail vielleicht nicht gerade fördert, aber zumindest schlampig mit dem Problem umgeht.

Wohlbemerkt: ich sehe hier keine Schuld bei den Blacklists oder den Anti-Spam-Tools, die sie nutzen. Es ist Sache der Provider, gewisse Standards einzuhalten und ihren Teil zur Bekämpfung eines Problems beizutragen, das weit mehr ist als ein ärgerlicher Schönheitsfehler.

Die einzige Möglichkeit, sich zu wehren besteht darin, sich massiv beim Provider zu beschweren, und, falls der nicht prompt reagiert, den Account bei ihm umgehend zu kündigen.

Wenn man überprüfen will, ob die eigene IP in Blacklists auftaucht, kann man z.B. hier mal klicken. Spezialisiert auf Mail-Blacklists ist BlacklistAlert. Wenn man mehr über die Hintergründe erfahren will, lohnt ein Besuch beim UceProtect-Netzwerk.

Nachtrag: Entwickler könnte es interessieren, wie man Blacklists händisch abfragen kann.

Nachtrag 2: Tobias Klausmann hat mir mal erklärt, wie man sich - aus der Sicht von ISPs - mit der Benutzung von Blacklists selber ins Bein schießen kann.



- 3 -


Ich hatte heute einen Anruf vom Hansenet-Support, der mir den Eingang meiner Beschwerde bestätigte, und dem ich nochmals den Grund meines Schreibens erklären sollte. Ich habe mir viel Mühe gegeben, dem Supporter meine Situation klar zu machen (ich habe meine Zweifel, ob der meinen Brief wirklich gelesen hat), bekam ihn aber nicht wirklich runter von der Idee, daß man erstmal meinen Hansenet-Zugang scannen müsse - irgendwie ging er davon aus, daß mit meiner Hardware etwas nicht stimmt (was ja definitiv nicht das Problem ist). Wenige Minuten später hatte ich eine SMS auf dem Handy, in dem mir die Ticket-(Auftrags-)Nummer mitgeteilt wurde, unter der meine „Störungsmeldung” bearbeitet wird. Ich bin ziemlich sicher, daß man dort keine Ahnung hat, worum es eigentlich geht.

Man hat mir eine Überprüfung und einen Rückruf in ein, spätestens zwei Tagen versprochen - darauf werde ich erst einmal warten. Vertrösten lasse ich mich kein zweites Mal, und wenn deutlich wird, daß man das Problem nicht versteht (bzw. verstehen will), werde ich noch in diesem Monat den Provider wechseln.

Das Problem hat sich längst noch nicht herumgesprochen, und die allermeisten Kunden von Providern, die als Spamschleuder fungieren, wissen nichts davon. Ich vermute, daß die meisten User ebenso unangenehm-überrascht wären wie ich selber, wenn sie erfahren, daß sie für ihren Internetzugang einen Dienst bezahlen, der für die Verbreitung von Spam maßgeblich mitverantwortlich ist.

Selbst ein Provider, der nur ungewollt Spam über seine Server verstreut, weil er die Zusammenhänge nicht versteht, ist damit längst nicht aus der Pflicht. Man bezahlt schließlich gutes Geld, damit der eigene Internet-Zugang von Profis verwaltet werden, die ihr Handwerk verstehen.

Ich habe mal bei UceProtect angeklopft und um Hilfe gebeten, eine Idee umzusetzen, mit der man Blogleser davor warnen kann, wenn sie Kunde einer Spamschleuder sind. Dort kam dann auch innerhalb kürzester Zeit eine Antwort mit einem Tipp, wie man mit wenigen Zeilen PHP-Code die UceProtect-Blacklists auf eine bestimmte IP abfragt.

Es wird sicherlich nicht bei diesem Eintrag bleiben - das Thema kommt noch auf das oberste Level meines Blogs. Ich weiß noch nicht, in welcher Form - ich stelle mit irgend ein Element auf meinen Seiten vor, das nur dann eingeblendet wird, wenn man mit einer Spammer-IP hier vorbeischaut, und mit dem man weitere Informationen bekommt.

Nochmals, nur für den Fall, daß ich das nicht klar genug gesagt habe: es geht mir nicht darum, Blog-Leser als Spammer zu diffamieren, oder irgendwelche Tricks zu entwickeln, Kommentar-Spam in den Griff zu bekommen. Es geht darum, bei der Lösung einer Problems mitzuhelfen, unter dem jeder Internet-User zu leiden hat, und das heißt: Spam.

Ich werde mal sehen, ob ich Kontakt zu den WordPress-Machern aufnehmen kann, um ein Plug-In für alle Blogger auf den Weg zu bringen, die eventuell bei dieser Aktion mitmachen wollen.

2 Kommentare

- 4 -


Heute morgen rief ein Supporter von Hansenet an und teilte mir mit, daß das Problem mit UceProtect bekannt sei, man da aber nichts machen könne, weil ich ja mit einer dynamischen IP im Netz unterwegs sei.

Klasse. Ich hätte gerne ein wenig herumgeschrieen.

Nochmal zum Mitschreiben: Hansenet ist einer von etwas über hundert ISPs (Internet Service Providern), von denen etwa ein Drittel des weltweiten Spam-Aufkommens ausgeht - etwa 10.000 andere ISPs machen es besser, und haben ein marginales Spam-Problem. Dort hat man Maßnahmen ergriffen, die so nahe liegen, daß es völlig unverständlich ist, wenn einige wenige sich weigern, sie ebenfalls zu implementieren.

Alles, was von einem Server abgeschickt wird, kann dessen Administrator protokollieren und in kontrollierte Bahnen lenken. Wenn er feststellt, daß von einer bestimmten IP-Adresse binnen weniger Sekunden hunderte E-Mails verschickt werden, kann er messerscharf schließen, daß das unmöglich von einem menschlichen User kommen kann. Er ist dann aufgefordert, ein Skript zu schreiben, das in solchen Fällen eingreift und die betreffende IP-Adresse blockt. - Das ist nur ein simples Beispiel, man kann auch mehr tun (wobei ich, als Nicht-Admin, nicht alle Punkte verstehe).

Der Clou an der Sache ist, daß es hier ausgerechnet den kleinen Usern an den Kragen geht. Firmen und andere „Profis” verschaffen sich für sie reservierte fixe IP-Adressen (wofür sie auch ordentlich bezahlen müssen). Damit ist sichergestellt, daß sie nie in schlechte Nachbarschaft von Spammern geraten. Endkunden, die bei jeder Einwahl ins Netzwerk eine neue („dynamische”) IP-Adresse innerhalb eines gewissen Adressraums zugewiesen bekommen, sind hingegen nicht dagegen gefeit, daß gleich nebenan ein Spammer Millionen Mails mit Viagra-Werbung unters Volk bringt - womöglich unter derselben IP-Adresse, die ihnen am Tag zuvor zugewiesen wurde.

Wir „kleinen” Internet-Bewohner werden also in Sippenhaft genommen - und etwas anderes bleibt den Betreibern von Mail-Servern oder auch Blogs gar nicht mehr übrig, wenn sie nicht mit Spam zugeschüttet werden wollen. Die Versuche, den Content solcher Mails und Blog-Kommentare darauf zu untersuchen, ob sie möglicherweise Spam enthalten, sind allesamt gescheitert. Jetzt wird - zurecht! - die Brechstange herausgeholt. Dummerweise sind wir es, die die Suppe auszulöffeln haben.

Der Sys-Op bei Steinberg, mit dem ich noch gestern das Thema diskutiert hatte, wußte gerade einmal von der Existenz dieser Listen, war aber doch verwundert, daß sie momentan offenbar wirklich in Gebrauch kommen - und zog die Augenbrauen hoch, als ihm klar wurde, daß man dazu übergegangen ist, ganze Subnetz-Bereiche als „verseucht” zu markieren. In der breiten Öffentlichkeit ist die Thematik noch überhaupt nicht angekommen, und ich fürchte, es wird schwierig, jenseits der Fachwelt klar zu machen, worin überhaupt das Problem besteht.

Maßnahmen:

  • Meinen Vertrag bei Hansenet werde ich umgehend kündigen - mir ist allerdings noch nicht klar, wohin ich wechseln soll. T-Online, Grogstar, und Kabel-Deutschland sind ebenfalls nicht ganz sauber, Arcor scheint OK, verlangt aber eine Mindestlaufzeit des Vertrages von 24 Monaten - d.h., es wird schwierig, Druck auszuüben, wenn dort doch noch irgendwann geschlampt werden sollte.
  • Ich werde mich an die Rechtsabteilung der Verbrauerberatung wenden - die sind eigentlich immer sehr erpicht darauf, Abmahnungen an Firmen zu verschicken, die sich unlauter verhalten. In diesem Fall dürfte allerdings die Rechtsgrundlage äußerst umstritten sein.
  • Ich versuche mal, einen Text schreiben, in dem das Thema so aufbearbeitet ist, daß es auch für einen Laien verständlich wird. Es reicht natürlich nicht aus, das alles im Rahmen dieses winzigen Blogs zu belassen. Irgendwie muß das auch in den breiten Medien ankommen - mal schauen, wer sich da ansprechen läßt.
  • Im meinem Blog gibt es seit heute eine Warnung, wenn man mit seiner IP-Adresse in Blacklists geführt wird - vorläufig checke ich nur gegen vier Listen, ev. werde ich das noch erweitern. Die Form ist nur vorläufig - ich vermute, daß es nerven dürfte, wenn man die Warnung ständig zu sehen bekommt.

Nachtrag: Arcor ist leider alles andere als sauber - die sind gerade kurz vor dem Aufstieg ins Level3 von UceProtect.

2 Kommentare

- 5 -


Bei BlacklistAlert findet sich eine recht lange Liste von Blacklists, die allesamt als Subdomain des jeweiligen Blacklist-Providers realisiert sind. Man kann nach einem simplen Schema ein Lookup für eine bestimmte IP realisieren, das für alle Blacklist-Provider gleich lautet:

Man stellt die abzufragende IP in umgekehrter Reihenfolge vor den Namen der Subdomain, und macht ein DNS-Lookup. Bei der IP "85.182.76.104" wäre das z.B der Aufruf:

$ipv = gethostbyname ("104.76.182.85.subdomain.domain.net");

Konkretes Beispiel (PHP-Code):

$ip = explode(".", $_SERVER[REMOTE_ADDR]); $addr = "$ip[3].$ip[2].$ip[1].$ip[0].dnsbl-1.uceprotect.net"; $ipv = gethostbyname ($addr); if ($ipv == "127.0.0.2") /* Die IP ist auf der Blacklist */

Der Rückgabewert für eine gelistete IP - "127.0.0.2" - ist bei allen Blacklist-Providern derselbe (wenn die IP nicht gelistet ist, wird der übergebene Domain-Name unverändert zurückgegeben).

Es würde sich für einen Blog anbieten, die IP eines Users zumindest mit einigen Blacklists abzugleichen, und ihn zu warnen, falls er dort gelistet wird. Das sollte man spätestens dann tun, wenn er im Begriff ist, einen Kommentar zu posten.

Falls es hilft: man kann das Codefragment herunterladen, mit der ich die Warnung über dem Kommentarfeld meiner Seiten ausgebe, wenn mein Blacklist-Test positiv ausfällt.



- 6 -


Ich hatte Tobias Klausmann gebeten, einmal aufzuschreiben, wie sich das Problem mit Blacklists aus der Sicht eines System-Administrators darstellt. Das hat er dankenswerter Weise auch getan - in seinem Text finden sich zahlreiche Hinweise, die mir durchaus neu sind.

Von Tobias Klausmann

RBL (Realtime Blackhole Lists) gibt es schon eine ganze Weile, so wie es den ursprünglichen Beweggrund dafür auch schon länger gibt: Spam. Allerdings sind auch sie kein Allheilmittel (sonst gäbe es ja keinen Spam mehr). Ferner sind sie trefflich dazu geeignet, sich in den Fuss zu schiessen - und es unter Umständen noch nicht einmal zu merken.

Aber bevor ich erkläre, warum das so ist, beschreibe ich erst mal, wie die Dinger überhaupt funktionieren, denn dort liegen einige der Gründe begraben, warum man mit ihnen vorsichtig sein muss.

Das grundsätzlicher Szenario ist, dass irgend eine Software automatisiert entscheiden soll, ob ein bei ihr abgelieferter Happen Text Spam (oder im weitesten Sinne unerwünscht) ist oder nicht. Ob diese Software ein Mailserver oder eine Blogsoftware wie Wordpress ist, ist ziemlich egal. Die meiste Software ist in der Lage, einige primitive Checks selber zu machen, aber das ist rudimentär und macht die User und Admins nicht auf Dauer glücklich. Also kam die Idee auf, eine zentrale Stelle zu fragen, ob es sich nun um Spam handelt oder nicht. Dabei kann man nun noch zwischen zwei Sorten Daten unterscheiden: zum einen die, die der Absender nicht (leicht) fälschen kann (zum Beispiel die IP, mit der er die Daten anliefert) und jenen, die er sich aussuchen kann (also der Content). RBLs befassen sich praktisch immer mit den ersteren und hier de facto nur mit der IP. Es gibt auch Systeme (wie Razor), die nach dem Content gefragt werden können, aber die sollen hier nicht Gegenstand sein. Wir stellen also fest: eine RBL sagt mir im Allgemeinen nicht, ob das, was ich da habe, Spam ist. Vielmehr kann ich sie fragen, ob ein bestimmter Einlieferer (nicht der Mail-Absender, der ist trivial zu fälschen) "als Spammer bekannt" ist.

Der Mechanismus, mit dem die RBL abgefragt wird ist, im Allgemeinen DNS. Dieses Protokoll hat den Vorteil, dass es so gut wie immer durch Firewalls kommt und an den Endpunkten nur wenig Overhead bereitet. Normalerweise haben IPs im Internet eine sogenannte Rückwärtsauflösung, in DNS-Sprech einen PTR (Pointer to Record). Der ist vor allem für Menschen gedacht, die halt wissen wollen, was zum Beispiel 193.99.144.80 denn nun genau ist. Dafür delegiert zum Beispiel die europäische IP-Vergabestelle (RIPE) ein Netz an denjenigen der IPs braucht. Ferner sorgt das RIPE dafür, dass mein DNS-Server herausfinden kann, wen er nach Informationen zu 193.99.144.80 fragen soll. Aber ich kann natürlich auch irgendwen anderen nach 193.99.144.80 fragen, zum Beispiel einen Cache bei meinem Provider (das ist genaugenommen der Normalfall). Ebenso kann ich auf diesem Wege den Betreiber einer RBL fragen, ob 193.99.144.80 denn in der Vergangenheit unangenehm als Spammer aufgefallen ist. Dazu frage ich den RBL-Server nach dem PTR zu 193.99.144.80. Der kann mir dann sagen "Kenn ich nicht" (in DNS-Sprech NXDOMAIN), wenn das nicht der Fall ist oder mir eine Antwort geben wie spammer.example.com, wobei 'example.com' eine Domain ist, die dem RBL-Betreiber gehört. Einige RBLs geben dann verschiedene Antworten, je nachdem, was die IP böses getan hat (Spam verschicken, auf Abuse-Anfragen nicht reagieren und noch ein ganzer Stapel andere Dinge).

Was nun meine Software mit dieser Information anfängt, ist natürlich wieder meine eigene Sache. So kann man Mail während der Einlieferung direkt ablehnen, sie als Spam markieren, einen Spam-Score erhöhen oder einige andere Dinge. Die häufigste Massnahme ist die erste: man lehnt Content von der IP rundweg ab. Wenn man ein netter Admin ist, schreibt man in die Ablehnung auch hinein, warum man das tut.

Eine Frage die bleibt, ist: woher weiss denn ein RBL-Betreiber, wer ein Spammer ist und wer nicht? Das übliche Verfahren ist, dass User einfach Spammer melden können (i.A. über ein Webformular). Der RBL-Betreiber nimmt diese Meldung und überprüft, ob das stimmt (zum Beispiel, ob es eine antwortende Abuse-Abteilung gibt). Diese Überprüfung kann durchaus mit menschlichem Input passieren, was natürlich die üblichen Vor- und Nachteile hat. Ebenso kann jemand, der auf einer solchen Liste gelandet ist, den RBL-Betreiber anschreiben und erklären, dass das Problem gelöst ist. Der Betreiber wird dann im allgemeinen die IP überprüfen und entsprechend reagieren. Manche RBLs setzen den Status zunächst auf "Proband" und überprüfen einen Monat lang zu zufälligen Zeitpunkten, ob das Problem wirklich repariert ist. In extremen Fällen werden IPs auch "für immer" gesperrt, zum Beispiel bei ISPs, die damit werben, dass sie Spammern eine Heimat bieten (ja, die gibt es).

Bei dieser ganzen Betrachtung fällt auf, dass ich als jemand, der eine RBL benutzt, die Grundlage (bzw. das Finden derselben) einer Entscheidung delegiere. Ich vertraue darauf, dass der RBL-Betreiber das richtige (oder das was ich für richtig hielte) tut. Das hat neben dem üblichen Problem, dass auch Menschen Fehler machen, noch weitere Punkte, die man beachten muss. Zum einen muss ich mir Klaren darüber sein, was genau der RBL-Betreiber für Ansichten hat: was genau ist Spam? was ist Abuse? Es gibt ausserdem einige RBLs, die in Internet-Standards geforderte Aspekte von IPs und Domains abfragen. Ein gutes Beispiel ist, dass es bei jeder Domain, zu der es einen Mailserver gibt, der Account postmaster@ vorhanden sein und gelesen werden muss (bis hierhin ist das noch vielen Admins klar) - ausserdem muss auch Postmaster@ auf die selbe Art existieren. Es gibt eine ganze Reihe solcher Anforderungen, die zum Teil eher akademisch sind (die Funktionalität wird heute schlicht nicht mehr benutzt) oder deren Auslegung mehr als schwammig ist (mache argumentieren zum obigen Beispiel, dass auch pOstMAsteR@ und ähnliches existieren muss). Indem ich die Suche nach und Entscheidung über diese "Nickeligkeiten" abgebe, begebe ich mich (und meine User) in die Hand des RBL-Betreibers. Die Entscheidung, die darauf basiert, bleibt natürlich bei mir. Dennoch kann sich die Politik des RBL-Betreibers bezüglich eines Aspektes auch ändern, ohne dass er mir das mitteilt.

Ein weiteres Problem ist Gruppenstrafe. Da ISPs im Allgemeinen Pools von IPs für die Einwahl benutzen, ist es mit dem Anprangern einer IP nicht getan: bis die Übertretung gemeldet und überprüft ist, sitzt auf der IP längst ein anderer Nutzer und der Spammer lacht sich eins. Also werden von RBLs manchmal auch ganze Netze gesperrt. Das kann je nach ISP also ganz schnell ein paar tausend oder noch mehr User erwischen. Zeitweise waren alle Reseller-IPs der Telekom (gut 4 Millionen IPs) auf manchen RBLs gesperrt, weil sich die Telekom-Reseller nicht um Abuse gekümmert haben. Den Mist an der Backe haben natürlich die Endkunden. Der RBL-Betreiber hofft, dass der entstehende Druck seitens der Kunden den ISP (oder den Reseller oder wen auch immer) dazu zwingt, den Spammer rauszuwerfen. Leider gibt es auch ISPs, denen das alles egal ist, da seine Lieblingskunden (der doofe Einwahl-Michel) ja eh keine Dienste betreibt und Webmail benutzt, weswegen er gar nicht merkt, dass er auf einer RBL gelandet ist. Die Kunden des ISPs, die aber gerne Mails direkt versenden wollen, schauen in die Röhre, denn sie werden geflissentlich ignoriert. Hierbei darf man aber nicht vergessen, dass manche RBL-Betreiber ganz extreme Eiferer sind, die sofort einen ISP listen, wenn er etwas tut, was sie für eine Verletzung irgend einer angeblichen Regel ist. Und schon sind wir wieder beim Problem der delegierten Einschätzung eines Sachverhalts: klar will ich keine Mail von Systemen, wo ich niemals einen Admin oder Abuse erreichen kann - aber ist beschwerden@ nun ein Abuse-Kontakt oder nicht? Es gibt beispielsweise auch RBLs, die nur eine Aussage treffen, ob es sich bei einer IP um eine Einwahl-IP handelt. Viele Provider von grossen Mailsystemen (also mit User-Zahlen deutlich jenseits von einer Million) nehmen Mails von Einwahl-IPs nicht an, da auf diesem Weg zu viel gespammt wird. Was zunächst als Harsch erscheint, ist eigentlich pragmatisch: Einwahl-Nutzer können praktisch immer den Mailserver ihres ISPs zum Mailversand nutzen, oft authentisiert (via SMTP AUTH). Das führt dazu, dass der ganze Abuse-Fall beim Einwahlprovider bleibt und der grosse Email-Provider nichts damit am Hut hat. Vor allem, weil man einen echten MX im allgemeinen nicht auf einer dynamischen IP betreiben will. Mailclients wiederum brauchen oft ohnehin einen ausgehenden Mailserver. Schliesslich gibt es noch ein ganz besonders fieses Problem mit RBLs: sie werden manchmal auch dichtgemacht (zum Beispiel, weil dem Betreiber ganz konkret und en Detail Gewalt angedroht wird). Dann hat der Betreiber das Problem, dass er entweder zu allem "ist kein Spam" sagen kann, zu allem "das ist Spam" oder er reagiert gar nicht mehr (was etwa dem ersten Teil entspricht). Da einfaches Abschalten den Nutzern der RBL nichts mitteilt (es gibt auf einmal keinen Spam mehr), stellen RBL-Betreiber in solchen Fällen ihr System für einige Zeit (Monate) auf "alles ist Spam" und hoffen, dass die Admins der nutzenden Systeme es so schneller merken. Nur dumm, wenn der Admin gar nicht existiert und so eine Firma eine Woche lang keinerlei Mails mehr empfangen kann.

Letztendlich gibt es bei all den RBLs und verwandten Systemen zwei Punkte, auf die man achten sollte. Zum ersten sollte man jede neu konfigurierte RBL sehr genau im Auge behalten. Das heisst, dass man sie zunächst nur als Markierungshilfe benutzen sollte - Mails gehen dann in einen Ordner und man sieht, was die RBL als "böse" qualifiziert und wie oft sie daneben liegt (in beide Richtungen: eine RBL, die böses niemals erkennt ist fast genauso wertlos wie eine, die alles als böse markiert). Zum zweiten sollte man nur die ganz krassen Fälle (zum Beispiel Absenderdomains, die gar nicht existieren) direkt und ohne menschliche Interaktion verwerfen. Alles andere kann man prima mit Scoring-Regeln versehen und je nach erhaltenem Score dann in Eimern sammeln, die man mehr oder minder oft kontrolliert. Das hat auch den Vorteil, dass man RBLs kombinieren kann: keine der RBLs kann einer Domain den "Todesstoss versetzen", aber wenn vier von fünfen die Gegenstelle als Spammer gelistet haben, könnte etwas dran sein.



Kommentieren [Drucken]