Gedanken zu Mailadressen-Verschleierung

Vorweg: Ich diskutiere mit einem Kollegen grad das Thema “Mailadressen-Verschleierung” als Anti-Spam-Maßnahme. Den technischen Hintergrund dazu gibts auf techblog.tilllate.com.

> Die Frage ist nicht, ob sie [Anm.: die Spammer] theoretisch dazu in der Lage
> wären, sondern ob sie es [Anm.: das Dekodieren verschleierter Mail-Adressen]
> auch wirklich tun. :) Und scheinbar scheint der Trick das Spamaufkommen
> zumindest zu reduzieren.

Es ist richtig, dass es da einen Unterschied gibt. Allerdings sehe ich es nicht als Aufgabe eines Links an, Spam zu verhindern. Denkt man konsequent auf diesem Weg weiter müsste man ja zu dem Schluss kommen, dass es sinnvoll wäre, überhaupt keine E-Mail-Adressen mehr auf Websites zu schreiben, denn das würde Spam ja noch wirkungsvoller verhindern. Man führt so den Zweck des Internets, nämlich die Kommunikation — und die will man doch, ad absurdum.

Auch die in dem Blog-Post genannten Methoden finde ich ehrlich gesagt albern. Das sind alles nur Krücken. Was für Verrenkungen will man sich von Spammern denn noch aufzwingen lassen? Die ewig nervenden CAPTCHAs gehören für mich zur gleichen Kategorie, nur gibt es noch keine Alternative zu denen.

Spam zu verhindern ist die Aufgabe eines dedizierten Spam-Filters auf dem Mailserver. Nur so ist Spam einigermaßen wirkungsvoll beizukommen. So mache ich das seit über 10 Jahren und ich habe kein Problem mit Spam. Die Leute, die mir schreiben wollen, sollen das tun. Wie sie an die Mailadresse kommen ist mir egal, abschreiben, automatisiert auslesen… egal. Wenn mir jemand Spam schreibt, bleibt er im Spam-Filter hängen und fertig ist die Geschichte.

Maillink-Obfuscation macht auch mehr Probleme als dass sie welche löst. Insbesondere das Verschleiern mit Javascript. Was ist z.B., wenn ein Rechtsanwalt in Abmahn-Stimmung aufs Impressum geht, wo eine verschleierte Mailadresse steht und er “aus Prinzip” JavaScript abgeschaltet hat – schon gibts *aus seiner Sicht* einen Abmahngrund.

Computer und das Internet sind dazu da, den Menschen zu bereichern und ihm die Arbeit zu erleichtern. Mail-Adressen zu verschleiern macht dagegen nur unnötig Arbeit und macht nichts besser als ein guter Spam-Filter — daher mein Fazit: Nein zur Mailadressen-Verschleierung! :)

MySQL macht “Peng”…

Heute hatte ich es wieder einmal mit einem abgeschossenen MySQL-Server zu tun, dieses Mal von einem Neukunden. Zur Abwechslung hat dieses Mal der Hoster (!) an der Maschine herumgespielt und sie ohne den Kunden zu informieren während des Betriebs neu gestartet — ohne die Dienste herunterzufahren.

Da fässt man sich nur noch an den Kopf. Das Resultat war natürlich klar — die Datenbank war kaputt.

Was tun… Einen Dump des aktuellen Stands der Datenbank ziehen ging nicht. Schreibzugriffe verhindern per LOCK ging nicht. Per MySQL reparieren ging auch nicht, denn die betroffenen Tabellen waren zum Teil InnoDB-Tabellen, die man lt. MySQL nicht reparieren kann. Ich habe dann den MySQL-Server neu installiert und vorher /var/lib/mysql aufgeräumt. Nun wirds interessant: Ein einige Stunden altes Backup, von dem ich annahm, dass es keine Fehler hatte, konnte ich zwar einspielen. Beim ersten Starten des MySQL-Daemons wurde kein Fehler angezeigt — bei den folgenden Neustarts aber schon: Fehlerhafte Tabellen…. WTF?

Das konnte nicht sein. Ein Problem mit dem Dateisystem konnte es auch nicht sein. Testweise habe ich die MySQL-Dateien auf eine andere Partition geschoben. Das Ergebnis war das gleiche. So langsam gingen mir die Ideen aus, wie ich das Problem schnell beheben konnte. Die nächste Idee: Wenn InnoDB-Tabellen nicht repariert werden können, nehmen wir eben MyISAM-Tabellen. Also den Dump entsprechend manipuliert und wieder eingespielt — voila. Ohne REPAIR wohlgemerkt.

Der Kunde war gerettet und der Abend gleich mit.

Zensur im Internet

Bei Dr. Web ist ein schöner Beitrag zum Thema Zensur im Internet erschienen.

Nicht nur aus politischen Gründen interessiere ich mich für dieses Thema, sondern auch aus technischen Gründen. Meinem Eindruck zufolge kann man es als Admin oder Web-Entwickler mittlerweile nicht mehr sicherstellen, dass ein Produkt, eine Website, eine Web-Applikation von überall auf der Welt genutzt werden kann — egal, wieviel Sorgfalt man dem Produkt angedeihen lässt. Was ist, wenn aufgrund bestimmter Schlüsselbegriffe eine Website oder ein Server im Netz eines Zensors hängenbleibt? Was ist, wenn auf einem Shared-Hosting-Server der “Nachbar” ein schwarzes Schaf ist und man einfach “mitzensiert” wird?

Zensur bleibt natürlich primär ein politisches Problem. Über die technischen Implikationen mache ich mir aber zunehmend Gedanken.

Technik-Demo praktisch umgesetzt

Vor einigen Jahren hatte ich eine Idee für ein Pseudo-CAPTCHA bei Dr. Web vorgestellt.

Kurz gesagt ging es um eine Technik, mit der so etwas ähnliches wie ein CAPTCHA erzeugt wird — aber ohne Grafik. Natürlich erreicht sowas kein besonders hohes Sicherheitsniveau. Es ist mehr eine Alternative zu Anti-Spam-Rechenaufgaben, die man hier und da antrifft, und diese sind ja auch nicht besonders sicher.

Spammer werden aber nicht für jede kleine Sicherheitsmaßnahme ein Gegenmittel entwickeln. Wenn es viele verschiedene Sicherungsmechanismen gibt, lohnt es sich für sie einfach nicht. Die Masse macht es also.

Eine Überraschung habe ich heute erlebt, als ich während einer Pause beim Stern etwas herumgesurft bin. Die setzen doch tatsächlich meine Idee praktisch ein. Finde ich gut :)

stern-pseudo-captchadrweb-demo

Dr. Web: Daumenkino mit jQuery

Fast hätte ich es vergessen: Der Drweb-Artikel “Daumenkino mit jQuery” erklärt, wie mit ein paar Zeilen HTML, CSS und Javascript bzw. jQuery ein kleines “Daumenkino” eingerichtet wird, bei dem die Bilder sanft ineinander übergeblendet werden. Der Artikel ist an Designer gerichtet, die nicht jeden Tag und ständig ihre Programmierfähigkeiten schärfen können :)

Jetzt kostenlos lesen!