Über das Verschleiern von E-Mail Adressen

Viele Leute verschleiern ihre E-Mail-Adresse auf Webseiten in der Hoffnung, dass Bots diese nicht aus der Webseite extrahieren können. Das könnte wie folgt aussehen:

email [AT] example [dot] tld

Diese Vorgehensweise wird zum Beispiel von Mailmans Archiv Pipermail und der MARC E-Mail Schnittstelle, welche von KDE Mailinglisten verwendet wird, angewendet. Manche Leute bitten sogar darum “E-Mail-Adressen nicht unverschleiert im E-Mail Text zu zitieren”.

Ist das Verschleiern von E-Mail-Adressen überhaupt sinnvoll? Gewinnt man dadurch mehr Sicherheit?

Die Antwort ist Nein. Die Verschleierung ist eine CAPTCHA Variante (Completely Automated Public Turing test to tell Computers and Humans Apart). Ein CAPTCHA erfordert, dass ein Computer das Künstliche Intelligenz Problem nicht lösen kann, wenn er Zugriff auf alle Informationen hat, welche benötigt werden um den Test zu erstellen. Gestern hab ich versucht zu beweisen, dass diese Art von CAPTCHAs geknackt ist und hab dazu eine kleine Anwendung geschrieben, welche die E-Mail-Adressen von einem öffentlichen Pipermail Archiv extrahiert. Die Anwendung besteht aus weniger als 300 Zeilen Code und kann automatisch alle E-Mails für einen gegebenen Monat und Jahr herunterladen und die Sender Adresse extrahieren durch das Rausziehen aller a Elemente der online abrufbaren E-Mail. Auf diese Elemente wird ein regulärer Ausdruck angewendet um die E-Mail Adresse zu erhalten. Ich wollte eigentlich nur etwa eine halbe Stunde daran arbeiten, am Ende hab ich dafür Qt 4.6 kompiliert, weil ich das neue QWebElement benötigte ;-) Falls jemand Interesse am Quellcode hat, kann ich ein Repository auf gitorious anlegen.

Das folgende Bild zeigt das Ergebnis eines “Angriffs” auf das plasma-devel Archiv. Aus Datenschutzgründen hab ich den Nutzerteil der E-Mail-Adressen unlesbar gemacht.

Picasaweb

Ich bin der Meinung, dass keine verlässliche Möglichkeit existiert E-Mail-Adressen nur durch Text zu verschleiern. Wenn es einen Algorithmus zum Verschleiern gibt, dann gibt es auch einen regulären Ausdruck um die Verschleierung aufzuheben. Die einzige Möglichkeit eine E-Mail-Adresse zu schützen, ist sie nirgends anzugeben wo ein Bot sie aufsammeln könnte. Dazu könnte man sie durch ein “echtes” CAPTCHA ersetzen, welches die E-Mail-Adresse nach dem Lösen preisgibt. Für Webseiten existiert zum Beispiel die Mailhide API von reCAPTCHA. Für Mailinglisten ist das ganze komplett nutzlos, da die Adresse sowieso unverschleiert in den E-Mail Headern steht. Anstatt Webseiten zu parsen könnten Bots auch einfach die Mailingliste abonnieren.

Also bitte hört auf die E-Mail Adressen zu verschleiern. Es ist nutzlos und man kann nicht mehr auf E-Mail Links klicken. Stattdessen muss der Leser ein nutzloses CAPTCHA lösen.

20 thoughts on “Über das Verschleiern von E-Mail Adressen”

  1. Totale Sicherheit bietet die Pseudo-Verschleierung nicht, richtig.

    Allerdings geht es nicht um totale Sicherheit (die es nicht gibt), sondern darum, das Spamaufkommen so niedrig wie möglich zu halten. Und da macht das Verschleiern Sinn; nicht 100% aller Emailharvester lösen die Verschleierung auf.

  2. Dieser Mist mit den Harvestern ist auch ein Grund warum ich Mailing-Listen völlig verabscheue. Leider setzen viele Softwareprojekte auf diese antiquierte Kommunikationsmethode. Ich ärgere mich tierisch, dass meine eMail-Adresse von der Debian Mailing Liste nach einem Beitrag von mir nun ungeschützt im Netz verteilt wird und ich sie auch nie wieder entfernen kann. Hätte ich das vorher gewusst, hätte ich natürlich eine wertlose Freemail-Adresse benutzt.

    Bei Launchpad.net lässt sich die e-Mail ja ausblenden und mit Mail-Formularen herumhantieren. Ich verlinke jetzt wenn ich irgendwo .po-Dateien veröffentlichen lasse auch nur meine Launchpad-ID. Neben Spamschutz bin ich dann nach einer Adressänderung immer noch erreichbar.

  3. Ich habe die Erfahrung gemacht, dass Verschleierung durchaus in der Praxis einen Effekt auf das Spam-Aufkommen hat. Auf eigenen Webseiten z.B. setze ich einfach Entity-codierte E-Mail-Adressen ein. Dadurch sind die Links immer noch benutzbar, aber bei weitem nicht alle Harvester machen sich die Mühe, die Entities zu decodieren.

    Ich weiß nicht, wie viele Harvester mittlerweile gesteigerte Anstrengungen unternehmen, sowas zu knacken. Dass es möglich wäre, steht natürlich außer Frage. Aber die theoretische Möglichkeit interessiert mich nicht so sehr wie die Anzahl der Spam-Mails, die ich runterladen muss. ;-)

  4. Und wie ist es, eine e-Mail-Adresse verschleiert zu schreiben, ganz ohne A HREF, und diese dann erst über ein JavaScript ins DOM zu schreiben? Nutzt das was?

    So wird z.B. auf generali.ch in der rechten Kontakt-Box dies als HTML ausgegeben:
    info at generali dot ch
    Und ein JavaScript macht daraus dann den klassischen E-Mail Link.

  5. @Michael: jain. Wahrscheinlich nützt es weil die Harvester nicht angepasst sind. Ich würde aber nicht darauf vertrauen, dass die Harvester kein JavaScript ausführen. Auch lädt ein irgendwas at domain dot tld geradezu ein mit regexs danach zu suchen. Auch E-Mail-Adressen müssen über regexs gefunden werden, auf zwei drei mehr kommt es nicht an und die Harvester haben nahezu unendlich Rechenleistung und sind vermutlich lernende Algorithmen, da sie ja feststellen, ob eine Adresse existiert oder nicht. Ich denke man sollte nicht den Fehler machen und sie als dumm anzunehmen. Ein sicheres Verfahren ist wohl nur reCAPTCHA und das kann man mit Manpower knacken.

  6. @Snirp: hehe, da hab ich wohl nicht gut verwischt ;-) Aber ich glaube Aarons Adresse dürfte allgemein bekannt sein

  7. Also da muss ich dir widersprechen. Was Spam angeht ist selbst simples “erschweren” wie z.B. das Greylisting bei Mails bei mir zumindest außerordentlich erfolgreich und das ist ja eigentlich noch trivialer als ein Captcha. Das Verlegen der sshd Ports gehört in die selbe Kategorie. Das alle diese Maßnahmen eigentlich einfach umgangen werden können ist klar, funktioniert trotzdem. Wobei ein at/dot Emailcaptcha vielleicht doch zu leicht ist.

  8. @adun: ich spreche ja nicht von Greylisting, das nutze ich selbst auch. Baut aber auch nur darauf auf, dass die Bots zu dumm sind. Als ich Greylisting aktiviert hatte, bekam ich von einem Tag auf den anderen keinen Spam mehr. Nach einiger Zeit (~6-9 Monate) waren die Bots angepasst und ich bekam wieder Spam.

    Es geht mir in dem hier vorgestellten Fall auch hauptsächlich um Nutzer von Mailinglisten, die meinen ihre Adresse verschleiern zu müssen. Das das sinnlos ist, dürfte wohl bewiesen sein.

  9. Ich bezweifle auch nicht, dass es relativ einfach möglich ist, für jede der Varianten eine Regex zu basteln, mit der man das wieder auflösen kann. Nun gibts aber eben mehr als eine Variante, und entweder wird die Regex dann schon ganz schön kompliziert, oder aber es müssen mehr als eine ausgewertet werden.

    Beides verhältnismäßig teuer, was Rechenleistung angeht. Und unnötig, solange kein nennenswerter Prozentsatz “geschützt” ist, und ich in der selben Zeit 10 ungeschützte Adressen abgrasen kann.

    Ich denke schon, dass es etwas bringt. Und lass nur 2 von 3 Harvestern darauf reinfallen, und schon sind das 2/3 Spam weniger (ja, ich weiß, dass der Zusammenhang mit Sicherheit nicht linear ist)

  10. @Martin: Dein Artikel hat mich sehr erschreckt. Ich habe auf der Website meines Kunden eine Funktion eingebaut, die Email Adressen automatisch verschlüsselt, falls der Anwender eine Email im Content der Seite eingibt. Bsp.:
    http://www.eigenbrodt.de/cont._Eigenbrodt-c1-l1-a65.html

    Ist diese Art der Verschlüsselung dann auch sinnlos ? Bis Dato hat das ganze recht gut funktioniert. Wäre nett, wenn Du mir hierzu einen Tipp geben könntest.

  11. @Martin: Ich würde ja gerne ein CAPTCHA System einsetzen, das ist aber leider in diesem Fall nicht möglich, oder ich sehe die Möglichkeit nicht ( über Ideen würde ich mich freuen ).
    In dem Beispiel gibt der Anwender seine Adresse plus EMail als Klartext im Editor des CMS ein. Für Formulare ist diese CAPTCHA Methode ideal. Besonders wegen der Barierefreiheit dieses Systems ( Audio ).

  12. Ich würde ja gerne ein CAPTCHA System einsetzen, das ist aber leider in diesem Fall nicht möglich, oder ich sehe die Möglichkeit nicht ( über Ideen würde ich mich freuen ).
    In dem Beispiel gibt der Anwender seine Adresse plus EMail als Klartext im Editor des CMS ein. Für Formulare ist diese CAPTCHA Methode ideal. Besonders wegen der Barierefreiheit dieses Systems ( Audio ).

    Sofern das CMS in einer “normalen” Websprache geschrieben ist, kannst du ein MailHide reCAPTCHA verwenden. Das ist auch Barrierefrei.

Comments are closed.