Achtung: Dieses Blog ist umgezogen auf die Adresse blog.xwolf.de
Bitte ändern Sie Ihre Bookmarks entsprechend.

Donnerstag, 23. Oktober 2003
SPAM-Schutz: EMailadresse als Image?
Kommentar
Das Hauptthema auf der diesjährigen Systems war SPAM, SPAM, SPAM.
(Und nachher krieg ich ebensolches von Ausstellern, weil einige viele Firmen denken, mit der Abgabe oder dem Tausch meiner Visitenkarte wurde bereits eine geschäftliche Verbindung abgeschlossen).

In diversen Vorträgen wurde verschiedene Ratschläge gegeben, wie man SPAM vermeiden könne.
Darunter auch der oft verwendete "Trick", die EMail-Adresse, die ja im Impressum einer Website anzugeben ist, mittels HTML oder Images so zu verschlüsseln, daß die "dummen" SpamBots sie nicht finden oder interpretieren können.

Meines Erachtens ist diese Empfehlung etwas kurzsichtig.
  1. Es gibt bereits SpamBots, die die üblichen HTML-Entities übersetzen. Ich erhalte nachweislich Spam an Mailadressen, die ich dadurch geschützt habe, daß das @-Zeichen als & #064; angegeben ist.
    (Für einen Programmierer mit nur etwa einer Woche Perlerfahrung wäre es ein 4-Zeiler solche Zeilen umzuwandeln.)
  2. Derzeit arbeiten die Entwickler der SPAM-Software daran, die Bayes-/Content-Filter von Anti-Spam-Software auszutricksen. Man sieht dies an der SPAM-Mail, die meist am Ende des Quellcodes der SPAM irgendwelche nicht sinnvollen Wörter drin haben.
    Der programmiertechnische Aufwand, solche Content-Filterer auszutricksen ist weit höher, als ein SpamBot so zu erweitern, daß es auch verschlüsselte Mailadressen erkennt.
  3. Die Erweiterung des Tricks mit JavaScript ist nicht empfehlbar, weil dies Leute mit alten Browsern oder Leuten Sehbeschränkungen, oder aber auch Gerätebrowser, wie Handys oder RSS-Reader vor Probleme stellen könnte.
    Aber selbst wenn: JavaScript wird bereits von einem Browser ausgeführt; Die Tools hierfür sind offen und es liegt in der Natur der Sprache, daß sie bekannt ist. Wieso sollte also ein SpamBot-Programmierer nicht in der Lage sein, JavaScript zu parsen?
  4. Die Methode mit den Bildern: Die E-Mailadresse wird als Bild abgelegt oder Teile der Adresse als Bild.
    • Erste Methode: Die gesamte Adresse ist als Bild abgelegt.
      Nachteile: Ebenso wie bei JavaScript gibt es Probleme mit Leuten, die alternative Browser und Views auf die Seite haben.
      Vorteil: Die Meisten SpamBots schaffen es noch nicht.
      Aber: Wer Content-Filter austricksen kann, der muss selbst Ahnung von Content-Filtering haben. Es ist daher naheliegend, daß die Programmierer entsprechender Software auch Bildanalyse-Funktionen implementieren können und werden.
      Ich verweise hier auf den Kommerz: Für Strassenkarten-Hersteller wurde es zu einem wichtigen kommerziellen Aspekt, daß diese Software entwickelten, mit der sie geklaute und teilweise modifizierte Karten und Lagepläne im Netz aufspüren konnten.
      Bei SPAM geht es aber auch um Geld. Um viel Geld. Wenn also die Verbreitung dieser Form der Adressverschlüsselung zunimmt, werden auch die SPAMer totsicher Geld in die Entwicklung der entsprechenden Software setzen. Oder diese einfach aufkaufen von denselben Leuten, die Geld mit Abmahnungen für Kartennutzer machen.
    • Die Methode: Teiladresse plus Image
      Ich denke, diese Methode dürfte länger erfolgsversprechend sein um SpamBots zu behindern.
      Es ist ungleich komplexer Teilcodes aus verschiedenen teilen einer Seite zu analysieren, als jeweils zugehörige Teile. Erst recht, wenn der Content-Type wechselt.
      Aber auch und gerade diese Methode macht wieder alternativen Browsern Probleme.
Man muß hier mal, auch und gerade als Firma, den wirtschaftlichen Aspekt sehen: 15% aller Surfern haben, bewusst oder unbewusst, Sehfehler. 3% der Surfer haben dabei in D eine rot-grün-Schwäche.
Nur etwa 1% oder weniger (je nach Bekanntheit der Seite) der "Besucher" sind SpamBots.

In anderen Worten: Um 1% der Besucher an illegalen Taten abzuhalten, werden 15% der potentiellen Kunden behindert!

Fazit: Die Verwendung von Bildern zur Verbergung der Mailadresse ist Problembehaftet. Sie nützt vielleicht noch kurzfristig etwas, solange die SpamBot-Programmierer nicht nachgezogen haben. Aber die Probleme damit, daß man potentiell 15% der Besucher der Website behindert treten sofort auf und bleiben.
Ein anderer, eher peinlicher Aspekt: Was nutzt es denn bitte, wenn man die Adresse wunderbar versteckt, diese jedoch beim Registrar nachschlagbar ist, oder sie eine Form hat, die jeder Brute-Force-Algorithmus auch ohne SpamBot ausprobiert?

Meine Meinung:
Wer eine Adresse hat der Form
  • vorname.nachname@domain,
  • vorname@domain,
  • nachname@domain
    oder
  • RFC-Definiert@domain
    (RFC-Definiert sind: postmaster, webmaster, abuse und info?)
braucht garnicht erst zu obigen, problembehafteten Methoden greifen: Es nutzt nichts!

Es gibt genug Namenslisten im Netz um jeden möglichen Vor- und Nachnamen automatisch zu generieren. Dies können SPAM-Software-Programmierer auch nutzen.

Und selbst wenn man all das obige ausschließen kann: Können Sie darauf verzichten, Mail zu verwenden? In anderen Worten: Ihre Adresse irgendwo anzugeben?

Aber wie auch immer.
Um der Diskussion um die Möglichkeit der Verbergung von Adressen eine neue Möglichkeit zu geben, die für Spamer noch etwas problematischer als Bilder + Text sind und ohne dabei potentiell 15% meiner Besucher abzuweisen:

Nutzen Sie CSS-Layers.

Mit CSS-Layer kann man pixelgenau definieren, wo ein Text erscheint. Im Quellcode kann dies dann so aussehen:
<div style="visibility : hidden;">
aetschibaetsch
<div style="visibility : visible; 
position: absolute; top: 10em; left: 12em;">@</div>
example.org
</div>
<div style="position: absolute; top: 10em; left: 13em;">
   xwolf.de
</div>
<div style="position: absolute; top: 10em; left: 1em;">
Hier meine Adresse: 
</div>
<div style="position: absolute; top: 10em; left: 10em;">
  xwolf
</div>
Natürlich kann man die jeweiligen div-Bereiche kreuz und quer übers Dokument verteilen. (Damit der alte NS4 keine Probleme macht bei der Anzeige, kann man mit CSS ein Workaround machen).

Das schöne dabei ist: Der SpamBot wird in den meisten Fällen als Adresse aetschibaetsch@example.org
erkennen, so er denn CSS kann. (Wenn er kein CSS kann, sieht der gar keine Adresse).
Es ist aber unwahrscheinlich, dass er beim Finden einer Adresse dann auch noch nachprüft, was andere Teile des Codes an Positionieren machen.

Noch schöner bei dieser Methode: Sie hält sich an Standards und ist etwas zugänglicher als Bilder für Leute mit Farbschwächen. Leute mit Sehschwächen oder alternative Browser werden daher kaum behindert. Lediglich Blinde werden wahrscheinlich Probleme haben, wenn die Braille-Software nicht fähig ist auf die Positionen von Text einzugehen.


Aber auch dieses Verfahren ist früher oder später angreifbar.
Genauso wie auch JavaScript wird CSS parsbar. Der Aufwand für die Entwicklung eines SpamBot wird zwar höher, aber nicht unmöglich:

Es reicht für den SpamBot nicht mehr einfach nur mit LWP::UserAgent die Seite zu diggen und mit HTML::Parse (und entsprechende JavaScript-Parsmodule, die es auch schon bei CPAN gibt) und CSS-Parser die Seite zu analysieren. Der SpamBot müsste ein Schritt weitergehen und die Seite so optisch simulieren, wie ein echter Browser.

Und dies ist im Bereich der Spammer schon längst umgesetzt.
Es gibt ja diese SPAM, wo um Suchmaschineoptimierung geworben wird und wo dann in der Mail ein "Screenshot" der eigenen Seite enthalten ist.
Die Erstellung dieses Screenshots wäre dann wieder die Lösung für SPAMer um sich aller Probleme durch obige Verbergungsverfahren zu entledigen. Anstelle den Code zu analysieren, wird ein Screenshot genommen und dieser dann analysiert und geparst...

Und dagegen würde dann kein Verfahren mehr helfen.


Das Fazit, welches übrigens auch für die Medienindustrie gilt, heißt also:

Alles was du sehen kannst, kannst du auch lesen, speichern, analysieren und damit auch nutzen.

... link


Spamfutter

Die folgenden E-Mail-Adressen dienen lediglich dazu, SPAM-Bots dazu zu verleiten, ungueltige Adressen in die SPAMer-Datenbanken zu schreiben. Bitte ignorieren.

irbmldr@hqrerdvsbhlmjyaagkb.biz, yhsmyvyy@nyqxoiigmuxd.ca, eol@ctwdagoajpjn.ch, nsxeicefli@dyctmodnnfip.com, urrww@mthghtozowfxfdmxtvpekq.edu, nqmvvm@hvyhxklsqpwtwxjphqiqgnd.de, gmcqrqkr@ugebipdcszvwvqvjdx.tv, mnijwpe@jxpdyzftc.nl, nbmqkqkxkq@gktmdcvckvgl.com, yrnud@rhleigyjiskucmq.de, hdmdygx@onymfmhwdmpbsvs.eu, rlgieba@ccfmhbugcda.nl, fyhq@naybywccqknkljwc.pl, dksv@cvwyutdrfrvxwuekkf.edu, kgtbiuc@rycqyousmzuhwnhkudewal.com, yyhdoft@sqnljjdzubqwoc.ar, pvuoqxsesx@rlcfuqvgqssva.jp, xspx@wtkcxrhbrouwmmc.nl, sjtcbodicq@fmvvehsy.de, mqskunboq@jcrmtojbr.it, rpolrcl@bqgczqfobgez.mil, vkazcyq@zsornnytikxrrxbzixyjrhq.jp, mygibho@dbbpgfwxigwdgvszh.de, xdmlm@yqjoyaxzihjx.st, hnqr@pxcebwbykbpzkwd.org, hticrps@mgeghcknklmfoihdcleb.com, wllclkyv@vewiskfb.de, lqj@rytpdkled.us, lrpnnimvm@gydxcgtpwywqjs.com, yrehe@oaqqhhbjtvklrs.de