S. Müller 4. August 2008

Wirklich wirksamer Schutz für E-Mail-Adressen

Kein Beitragsbild

Spam ist eine Plage. Spam ist nicht mehr wegzudenken. Spam wird nicht aufhören. Mittlerweile hat sich der Großteil der Internetnutzer an die unerwünschte Werbung im Postfach der E-Mail-Anwendung gewöhnt und so gehört das Aussortieren der durchgesickerten Spamnachrichten zum Tagesgeschäft.

Spätestens jetzt scheinen alle Mittel für die Bekämpfung oder zumindest Reduzierung der Spamflut wirkungslos zu sein. Kaum wird eine E-Mail-Adresse online gestellt (Foren, Kommentare oder Kontaktseiten sind Paradebeispiele dafür), nimmt Google die entsprechende Webseite fleißig in den Index auf – lecker Fressen für Spamer und ihre automatisierten, hungrigen Spyder. Zwei Tage später trudeln erste Rolex-Angebote ein.

Gegenmittel vorrätig?
Kann man sich denn gar nicht schützen? Oder doch? E-Mail-Adressen als grafische Elemente? Dienste wie eMailLink? Die Benutzerfreundlichkeit bleibt dabei öfters auf der Strecke…

Silvan Mühlemann von Techblog meint geringstenfalls eine zuverlässig funktionierende Lösung gefunden zu haben. Zumindest was den Schutz der sensiblen E-Mail-Daten auf eigenen Webseiten angeht, welche verstärkt auf Autoren-, Kontakt- und Impressumseiten vertreten sind. Für sein Experiment hat Silvan Mühlemann genau 9 unterschiedliche E-Mail-Adressen mit entsprechenden Postfächern angelegt. Diese wurden wiederum durch 8 grundverschiedene Methoden geschützt (zum späteren Vergleich: Eine Adresse als reiner Text, also gänzlich unbehütet) und auf einer stark frequentierten Seite im Internet veröffentlicht. Ab diesem Zeitpunkt musste sich jede angewendete Technik als Wächter beweisen: Wie wirkungsvoll ist die verschriebene Mixtur gegen Spam-Roboter?

Aufklärung nach jahrelanger Eignungsprüfung
1,5 Jahre später erreicht die Belastungsprobe ihr geplantes Ende. Die Testresultate sind ausgewertet und zeigen eindeutig, die ungeschützte Variante in Plain-Form hat am meisten Spam zugeschickt bekommen. Drei der herangezogenen Ansätze haben die anvertraute Adresse so effizient getarnt, dass Einlesemechanismen der Spamer diese Köder übersprungen haben – die dazugehörigen Postfächer blieben von Werbung jeglicher Art verschont.

Screenshot
Spamaufkommen in MB

Zwei der acht Lösungen sind besonders leistungsfähig und trivial zu implementieren, da pures CSS:

Veränderung der Schreibrichtung


moc.etalllit@7raboofnavlis

silvanfoobar8@nulltilllate.com

Angewendete Schutzverfahren sind public und können auf den Seiten des Initiators angeschaut werden.

Dr. Webs exklusiver Newsletter
Hinweise zum Datenschutz, also dem Einsatz von Double-Opt-In, der Protokollierung der Anmeldung, der Erfolgsmessung, dem Einsatz von MailChimp als Versanddienstleister und deinen Widerrufsrechten findest du in unseren Datenschutzhinweisen.

83 Kommentare

  1. Ich verhindere Spam in meinen privaten Postfächern indem ich überall wo es möglich ist eine meiner Trashmail Adressen angebe.

    Die trashmail Adressen erstelle ich immer auf http://www.privy-mail.de

    Das geht wirklich super. Durch diese Spam Adressen bekomme ich in meinem privaten Postfach seit Monaten nur sehr sehr wenig bis gar keinen Spam mehr.

  2. Naja, Spam Mails sind auch nur Müll. Man sollte sich lieber eine richtige Domain anlegen die nicht von Provider voll gemüllt werden.

  3. Guter Beitrag, werde das auch gleich mal testen/einsetzten :)

  4. Normalerweise finden sich Mail-Adressen gesammelt in einer bestimmten Seite – zum Beipiel unter Kontakt oder Impressum.

    Was ist vom Vorschlag zu halten, dass in einer solchen Seite zum Beispiel ein Input-Feld platziert wird, in welchem beispielsweise das Ergebnis einer Rechnung vom user einzufügen ist (z.B. 5 + 2 =)? Der user gibt das Ergebnis ein und drückt submit. Serverseitig wird auf richtiges Ergebnis geprüft und falls korrekt, wird die genau selbe Seite nochmals an den user gesendet, diesmal jedoch mit Email-Adressen (zuvor nur Mail-Adressen-Platzhalter). Der user kann dann mailtos ganz herkömmlich benutzen…

    Auf der Seite wird als Notiz bemerkt, dass man die Lösung der Rechnung korrekt absenden muss, um die Mail-Adressen angezeigt zu bekommen und dass dies so ist, um Spam zu vermeiden.

    • Hm, gute Idee, ich weiß bloß nicht, ob das gesetzeskonform ist. Ich verstehe das Telemediengesetz so, dass ein Benutzer im Impressum die E-Mail-Adresse sofort, ohne weitere Schritte, lesen können muss.

      Aber dein Tipp hat mich auf eine andere Idee gebracht: Im Impressum könnte man eine völlig unverschleierte, aber ab und zu wechselnde Adresse veröffentlichen (vorab mehrere beim Web-/Mail-Hoster anlegen und per PHP auf der Webseite zum Beispiel monatlich wechseln lassen). Wenn man eine Nachricht von einem seriösen Absender erhält, bittet man in der Antwort-E-Mail, statt dieser temporären Adresse die „richtige“ (dauerhafte) Mail-Adresse zu speichern (Textbaustein/Signatur). Das dürfte abmahnsicher sein, schätze ich mal.

  5. Das bei Beitrag 54 soll ‚Noscript-Bereich‘ heißen … die eckigen Klammern wurden offenbar rausgefilter ;-)

  6. So, ich habe nun meine Email-Adressen mit JavaScript geschützt UND gleich im Anschluss einen -Bereich definiert, der ja bei deaktiviertem JS angezeigt wird. Statt dem üblichen Hinweistext („Sie haben JS deaktiviert …“) hab ich aber darin den obigen CSS-Schutz verwendet. Ergo: Benutzer mit deaktiviertem JS sehen dadurch auch die Email-Adresse und können sie zumindest kopieren (mailto geht ja nicht). Das ist fein! Einziger Nachteil: Durch die Verwendung von zwei verschiedenen Schutztechniken (JS & CSS) ergeben sich in Zukunft zwei Angriffsstellen … aber derzeit ist das so das Bessere das mir untergekommen ist.

    lg
    Ernst

  7. Also die beiden CSS Lösungen erscheinen zuerst genial, aber sind sie völlig nutzlos, wie hier weiter unten schon jemand geschrieben hat:

    Das CSS kümmert sich nur um die dargestellte Email-Adresse, aber was ist mit dem MAILTO-Tag im Hintergrund? Hier ist man offensichtlich wieder auf JavaScript angewiesen. Und beim Umdrehen der Cursor-Richtung gibt es tatsächlich ein Problem beim Kopieren der Email.

  8. Super Beitrag….werde die CSS-Lösung gleich testen.

  9. kann ich das null eigentlich zwischen displaynone“> und </span löschen?

    p span.displaynone { display:none; }

    silvanfoobar8@nulltilllate.com

    danke
    dynamite

  10. Wer über eine dynamische Anwendung oder ein CMS wie TYPO3 Web-Seiten erzeugt, kann einen Link „E-Mail an Max Mustermann“ einfügen, der auf eine Seite mit E-Mail-Formular verweist. Als Übergabeparameter im Link kann ein hash-Wert benutzt werden, der den internen Kontaktdatensatz eindeutig bestimmt und ein spam-sicheres E-Mail-Formular erzeugt.
    So hat der Empfänger neben dem Schutz vor automatisiertem Spam zusätzlich die Möglichkeit, auch gegenüber realen Spammern unentdeckt zu bleiben.

  11. also wenn ich die Technik mit „display:none;“ anwende kann ichs in jedem browser ohne probleme kopieren.

    Welcher Browser soll da angeblich probleme machen?

    @Jojo
    Im firefox 3 habe ich kein Problem, so wie von dir behauptet wurde…

  12. Ne gute Lösung dafür ist auch ne kleine Seite anzulegen dort Fakemail Adressen (in Klartext) reinzuschreiben.

  13. Wie oben angekündigt, habe ich Verfahren 2 „Unsichtbare Elemente“ bei meiner Lösung eingebaut. Eine kleine Verbesserung hätte ich anzumerken: Ich verwende statt span das Element del. Das hat den Vorteil, dass dieses Element standardmäßig von den meisten Browsern durchgestrichen dargestellt wird. Falls man also die passende CSS-Deklaration mit display:none vergessen hat oder der User CSS ausgeschaltet hat, ist dies immer noch eine kleine sematische Hilfe für den User. Schlechter als Konstrukte wie name[at]domain[dot]de ist es jedenfalls nicht.

  14. Ich habe eine etwas andere Lösung gefunden, die so ein bisserl von allem vereint. Ich programmiere derzeit eine Art Social Network und da stehen natürlich auch Kontaktdaten wie MSN und Jabberadressen drin. Diese werden per PHP in base64 kodiert und in JS zurückkodiert, allerdings mit ein paar Tricks.

    Original: user@domain.com
    Ergebnis: user [ät] domain [punkt] com
    mit Link auf: /faq#eMail anzeigen
    und onclick event: return z.de(‚dXNlckBkb21haW4uY29t‘)

    Ist Javascript aktiviert, erscheint die eMail unkodiert in einem Prompt, so dass sie kopiert werden kann. Drückt der User da ok, wird er auf den mailto Link weiter geleitet.

    Ist JS deaktiviert, kann er die Domain abtippen und wird beim anklicken auf die FAQ Seite geleitet, wo steht, warum das so gemacht ist. :-)

  15. @ D.T.: Wie schauts denn da mit den Informationspflichten aus (§5 TMG)? Ich glaub nicht gut.

  16. Endlich wieder mal ein guter Beitrag.

  17. Hallo zusammen,

    was haltet ihr von dem Ansatz:

    Statt der Email Adresse wird nur ein Formular bestehend aus Input Textfeld und Submit Button angezeigt und natürlich noch Text, wofür das ganze gut ist.
    In das Textfeld gibt der Benutzer seine Emailadresse ein und erhält daraufhin die gewünschte Emailadresse per Email.

  18. was bringt ´ne emailadresse, die zwar (noch!) spam abhaelt aber auch nicht angeklickt werden kann? so ’schuetzt‘ man sich generell vor mails – nicht nur spam… ;-)

    da ist mir (auch bzw. VOR ALLEM aus usability-gesichtspunkten) doch immer noch eine gute alte javascript-loesung lieber.

  19. herzlichen Dank für die Auflistung der vielen Möglichkeiten. Auch ich teile die Bedenken mancher anderen, dass damit diese techniken wohl auch schon bald von den Spammern erkannt werden und somit das Spiel von vorne wieder losgeht.

    Nichtsdestotrotz gefallen mir die CSS-Spielereien, denn damit ist die Usability noch schön gegeben.

  20. Interessante Lösungen, zweifellos. Werde das eine oder andere auch mal probieren.

    Ich mache allerdings häufig die Erfahrung, dass der schönste Spamschutz einer Mail-Adresse wenig bringt, wenn dieselbe Adresse dann auf anderen Seiten – ungeschützt – angegeben muss (z. B. in Pressemitteilung auf PR-Portalen) oder ungefragt auf anderen Seiten publiziert wird.

    • Ja, das hat mich auch schon geärgert. Einem Anbieter dieser seuchenartig um sich greifenden automatisierten Web-Auskünfte habe ich eine recht deutliche E-Mail geschrieben mit der Aufforderung, meine sämtlichen Daten umgehend zu entfernen. Diesem Wunsch wurde zum Glück auch entsprochen.

  21. hallo,
    wir benutzen auf unserem mailserver greylisting und erhalte nun statt 24000 spam´s im monat nur noch 250-270. wenn man nun noch spamassign benutzen würde dann ist nahezu nichts mehr dabei.

    lg

    frank

  22. In meinem Kommentar wurde im zweiten Absatz „noscript-Bereich“ zu „-Bereich“ gekürzt, weil ich es als Tag geschrieben habe. Sorry für die verminderte Lesbarkeit.

  23. @Rene Schmidt: Ein weiterer Grund, warum der Aufwand für intelligente Suchfunktionen von den Spammern unterlassen wird, könnte einfach sein, dass die Spammer wissen, dass diejenigen, die einen ziemlichen Aufwand zur Verschlüsselung ihrer emails betreiben, sowieso nicht auf den Spam hereinfallen werden. Es lohnt sich also nicht, diese email-Adressen zu sammeln.

    Zur Diskussion: Ich biete email-Adressen im Normalfall in einer JavaScript-Version und einer im -Bereich an, erstere verlinkt, zweitere nur als kopierbarer Text. Die JS-Version ist ja kein Problem. Man kann sich eine beliebig komplizierte Verschlüsselung ausdenken und auch alles verlinkbar (mit mailto:adresse@domain.tld) machen.

    Das Problem ist die Noscript-Version, aus rechtlichen Gründen eingebaut, aus Spamschutz-Gründen aber nicht verlinkt, weil es eben für das href-Attribut keine vernünftige Verschlüsselung gibt. Da werde ich wohl die zweite vorgestellte Lösung mit dem display:none noch zusätzlich zu meinen bisherigen Verschlüsselungsversuchen einbauen.

    Das Problem an der Lösung ist, dass das noscript-Element leider ein Blocklevel-Element ist, man email-Adressen aber oft gerne Inline haben möchte, was den Code ggf. invalide macht. Dafür gibts zwar auch wiederum eine Lösung, denn die beiden Elemente INS und DEL haben (als einzige in HTML) die wunderbare Eigenschaft dass sie sowohl innerhalb von Blocklevel- und Inline-Elementen stehen dürfen als auch Blocklevel- und Inline-Elemente enthalten dürfen. Im Extremfall dürfen sie also in Inline-Elementen stehen und Blocklevel-Elemente enthalten.

    Damit ist der Code zwar valide, dafür habe ich meine Bedenken, was Barrierefreiheit angeht und von Semantik kann man dann eh nicht mehr reden. Aber man kann in diesem Fall einfach nicht alles haben. Das musste ich mir erkaufen für die Usability (verlinkt immerhin in der JavaScript-Version) und dem eigentlichen Grund für die ganze Aktion (Verschlüsselung).

  24. Kann man dem eMail-Spider eigentlich auch Köder auslegen? So im Sinne von: richtige Adresse mit JS zusammensetzen und mehrere falsche Adressen mit mailto im Quelltext hinterlegen.

    Oder arbeiten die Programme nicht mehrstufig und scannen eh alles, was vor die Flinte kommt?

  25. Der Service unter http://mailhide.recaptcha.net/ ist auch ganz nett. Kommt zwar auch nicht ohne JavaScript aus, aber naja.

  26. Die 2. Lösung finde ich eigentlich ganz gut, da Harvester diesen Code wegen der vielfältigen Möglichkeiten nur sehr schwer bis gar nicht auslesen können. Allerdings geht der mailTo: nicht mehr.
    Die 1. Methode ist so lange gut, wie ein Programmierer sie nicht kennt.

    Kann mich noch gut erinnern, als das Codieren der eMail-Adressen
    in der Form &#116&#101&#115&#116 als der Weisheit letzter Schluss verkauft wurde. Inzwischen können die Bots solche Codierungen auch lesen.

    Inzwischen mix ich die ascii-Werte der Buchstaben in einem Array und füge noch je 2 Blindwerte zu jedem Buchstaben hinzu. Das sollte die nächsten paar Jahre halten. Schau mal bei http://www.fincy.com/spameater

    Ausschliesslich auf Spamfilter zu setzen, halte ich nur für halbschlau. Ich lass mir ja auch nicht in Suppe pinkeln um die … dann wieder rauszufiltern.
    Das bedeutet allerdings nicht, dass Spamfilter keine gute Sache sind. Man sollte Spam von sovielen Seiten wie möglich einschränken.
    Auf die Idee mit der Weiterleitung von plexinote (18) werde ich auch auf meiner oben erwähnten Site hinweisen. Das spart einen Haufen Arbeit gegebenenfalls Kontakte und den ganzen Kram anzupassen.

    Grüsse

    Tümmel

  27. Hi,

    also ich schreibe meine email bei sowas immer so:
    meinname (ät) diedomain [Punkt] de klar läßt sich das auch scannen und rausfiltern, aber alleine schon da es auf deutsch ist denke ich das die meisten spammer aus timbuktu oder von sonst wo nicht wirlich danach suchen werden.

  28. Hmm… Also eine serverseitig umgesetzte Filterlösung halte ich auch für effektiv und am zugänglichsten für den Webseitenbesucher.
    Bots können doch munter weiter sammeln, zumindest an dafür ausgewiesenen Sammelstellen.
    (Ist so keine gangbare Lösung – schon klar, schon klar…)

  29. moc.etalllit@7raboofnavlis

    na dann sind die spamer aber hempels; wenn sie sowas nicht scannen ;)

    alles ab leerzeichen vor dem @ bis zum ersten leerzeichen nach dem @ und dann umdrehen. da kommen die auch noch drauf; muss sich halt alles erst verbreiten und schon scannen die diese dinger auch.

    aber die idee ist echt gut!!!

    gruß

  30. Dann nämlich, wenn jemand ohne grafischen Browser, z.B. mit einem Screenreader auf die Seite kommt und die E-Mailadresse nicht korrekt erkennen kann.

    Deswegen ist der Inhalt in meinem display:none so etwas wie; {Dies ist Spamschutz, bitte nicht beachten.}
    Sodass es klar erkennbar ist.

  31. Also ich finde der einfachste SpamSchutz ist noch immer der: Ein guter Spamfilter, wie SpamAssassin, der ggf. auch noch Greylisting macht.

    Warum soll ich einen Teil meiner User Probleme machen, mir den Kopf lang um Tricks zerbrechen (wobei gleichzeitig andere Geld verdienen werden um Workarounds für diese Tricks zu bauen!), wenn gute Filter reichen?

    Ich nutz meine E-Mail-Adressen ganz offen seit 1994. Und trotzdem hab ich kein Spamproblem.

  32. Sorry Beitrag 27, mein codebeispiel ist beim posten manipuliert worden;-) Es geht um das noscript Tag, in diesem wird der Link zum Formular angeboten oder bei aktivierten JS eben der echte mailto Link.

  33. Also, ich würde keine irgendwo publizierten Lösung benutzen. Früher oder später werden diese Mechanismen von den bösen Scripts mit einbezogen…

    Trotzdem hier noch meine Variante:
    – Zusammesetzen des Links aus Variablen (Javascript) und diese dann in das Link-DIV (InnerHTML=myMailVar) schreiben.
    Im selben DIV folgendes:
    Zum Kontaktformular

    So wird ohne JS ein Link zum Kontaktformular angeboten.

  34. Noch ein Nachtrag:

    Die CSS-Methoden wie z.B. das Verstecken mittels ‚display: none‘ funktionieren bei E-Mail-Harvestern (automatisierte Skripte) gar nicht, da diese die grafisch aufbereitete, mit CSS formatierte Seite gar nicht sehen, sondern lediglich den vom Webserver generierten und ausgelieferten HTML-Text.

  35. Alle Verschleierungsmethoden, die auf CSS-Basis für Bildschirmdarstellung (media=all, media=screen) arbeiten, könnten auf Impressumseiten im unangenehmsten Fall zu rechtlichem Ärger führen: Dann nämlich, wenn jemand ohne grafischen Browser, z.B. mit einem Screenreader auf die Seite kommt und die E-Mailadresse nicht korrekt erkennen kann.

    Aus solchen — möglichen — rechtlichen Erwägungen verbietet sich auch die Verschleierung der Adresse per Javascript oder gar rein grafisch ausgeführte E-Mailadressen.

    Mir jedenfalls wäre bei allen drei Arten das Risiko zu groß, versehentlich auf die Fußmatte irgendeines fixen Abmahners zu treten …

  36. Und schon darf ich mir wieder eine andere Methode suchen. Die display:none-Methode hat so gut funktioniert und jetzt kennt sie jeder.

    Manchmal frage ich mich echt, ob solche Studien nicht von Spammern aufgestellt werden um die Ergebnisse danach groß verteilen zu können.

    Gruß
    Wishu

  37. Und schon darf ich mir wieder eine andere Methode suchen. Die display:none-Methode hat so gut funktioniert und jetzt kennt sie jeder.
    Manchmal frage ich mich echt, ob solche Studien nicht von Spammern aufgestellt werden um die Ergebnisse danach groß verteilen zu können.

  38. @16: Internet Explorer, Versionen 5-6 (wer sonst?)
    Jedenfalls in den „MultipleIE“-Versionen.

  39. @Runa: Zustimmung. So richtig schwierig sind die genannten Sachen nicht zu umgehen. Wenn man es wirklich drauf ankommen lassen will, kann man innerhalb weniger Minuten/Stunden entsprechende Programme schreiben.

    Dass es trotzdem nicht gemacht wird, wundert mich auch etwas. Eine mögliche Erklärung ist wohl, dass derzeit auch mit den noch billigeren Methoden kein Mangel an Mailadressen herrscht, die man bespammen kann. Das kann sich aber durchaus mal ändern und wenn dann mal ein Mangel herrscht wird auch mehr Aufwand fürs „Ernten“ der Adressen betrieben werden. Da bin ich mir zu 100% sicher.

  40. Ups, sorry! Kleine Unachtsamkeit, große Wirkung…
    Also die Methode kommt von der Uni Hamburg und verwendet Javascript. Nicht dass ich den Rest so betonen wollte, aber der Link funktioniert… ;-)

  41. Ich habe die letzte Methode (kombiniert mit Unicode) auch schon ausprobiert und sie funktioniert tadellos. Wenn die Mailadresse dann mit einem „hier klicken“-Verweis ergänzt wird, öffnet sich beim Besucher das entsprechende Programm und auch dort ist die Mailadresse richtig eingetragen. So besteht also kaum Notwendigkeit, die Mailadresse zu kopieren (oder man tut das dann eben im Maileditor). Oder?
    Ich möchte ebenfalls weiterführende Lektüre empfehlen, nämlich die Methode der
    :
    Javascript hat zwar – wie schon erwähnt, mehr Nachteile
    als CSS, aber wer von Spam überflutet wird, kann auch mal zu dieser Methode greifen.
    Alles in allem eine never ending story, aber es ist interessant, die Methoden mal in Einsatz-Vergleich zu sehen. Ich hätte ja gedacht, dass sich Spam-Bots auch die Laufrichtungsänderung auch schon eingestellt haben, aber scheinbar ist dem nicht so.

  42. Ich denke auch, dass es nur eine Frage der Zeit ist, bis die hier vorgestellten Möglichkeiten auch nicht mehr sicher sind. Kann mich noch gut erinnern, als das Codieren der eMail-Adressen
    in der Form &#116&#101&#115&#116 als der Weisheit letzter Schluss verkauft wurde. Inzwischen können die Bots solche Codierungen auch lesen.

    Wenn man die eMail-Adresse in Ihrer vollen Benutzbarkeit darstellen will, sprich verlinkt und kopierbar, sollte man sich vielleicht eher darüber Gedanken machen, welche Adressen man veröffentlicht und welche nicht.

    Ich habe mir z.B. angewöhnt, eine „wichtige“ eMail-Adresse nie direkt auf eine Webseite zu setzen, sondern eine alternative einzurichten (z.B. anfrage_x27@domain.de) und diese dann auf die wichtige eMail-Adresse umzuleiten. Das schützt zwar nicht vor Spam, aber wenn dann eine alternative Adresse nur noch zugemüllt wird, kann man sie einfach austauschen und hat vorerst wieder etwas Ruhe. Nicht der Königsweg, aber einer von vielen.

    Vielleicht kann man ja verschiedene Lösungen kombinieren. Man sollte nur nicht die Usability einschränken – denn eMail-Adresse abtippen will ich meinen Besuchern wirklich nicht zumuten.

  43. Leute, die ich, wenn ich Spammer wäre und programmieren könnte, im Handumdrehen mit drei Zeilen Code fertigmachen würde:

    – Leute, auf deren Seite das @-Zeichen plain oder chiffriert vorkommt;
    – Leute, die @ durch at ersetzen;
    – Leute, die mich durch Leerzeichen herausfordern;
    – Leute, die mich mit maschinenlesbarem CSS und Java-Code hinters Licht führen wollen.

    Da fragt man sich, warum so wenig Menschen sich für den leichten und verdienstvollen Beruf des Spammers entscheiden :)

  44. @Klaus
    In welchen genau nicht? In sehr alten vielleicht, sonst alles top: http://de.selfhtml.org/css/eigenschaften/positionierung.htm#direction

  45. @Mike: Die „E-Mail-Adresse-als-Grafik-einfügen“-Technik halte ich für keineswegs besser als die genannten (unzureichenden) CSS-Verschleierungstechniken. Die Gegenargumente fangen mit der Barrierefreiheit an und hören beim „Abtippen“ der Mailadresse auf. Dazwischen gibts beliebig viel.

    Ich schreibe meine Adresse ganz normal auf meine Website. Da kommt eine Menge Spam, 99% davon wird von mehreren Spamfiltern (auf dem Server und auf dem Client) gefiltert, der Rest ist zwar störend, aber nicht weltbewegend. Und die Nutzer brauchen sich nicht die Finger zu verrenken.

  46. @Rene Schmidt

    Schon klar. Beispielsweise stellt die JavaScript-Lösung die Spam-Roboter beim Kopieren vor Probleme, den „normalen“ Besucher der Seite aber nicht. Das war gemeint. Trotzdem wäre mir die reine CSS-Lösung lieber.

  47. Die Lösungen sind alle schön und gut, aber eine nicht kopierbare Lösung, und die nicht Verwendbarkeit in mailto:-Links stellen alle Lösungen wieder schlecht hin.
    Wer tippt denn heutzutage noch Email-Addressen ab?

  48. Ich persönlich finde den Artikel bei A List Apart zum Thema „Spamschutz selbst gebaut“ sehr gut und empfehle ihn hier mal als „Weiterführende Literatur“: http://www.alistapart.com/articles/gracefulemailobfuscation/

  49. Für mich haben die oben genannten Versionen keinerlei Vorteile, im Gegenteil, die verwirren den User nur. Eine direkte Verlinkung ist auch mit der CSS Technik nicht gegeben und da die Email Adresse nach dem Kopieren wieder rückwärts steht ist es nur unnötig verwirrend.

    Da bleibe ich lieber bei der einfachten „E-Mail-Adresse-als-Grafik-einfügen“-Technik ;)

  50. Die Methode über Trennung mittels unsichtbarer Elemente ist mit Vorsicht zu genießen.

    Ich hab sie auf http://nerdyberdy.com/author/ ausprobiert. Sie ist zwar sehr wirksam gegen Spam allerdings wird die über display:none ausgezeichnete Zeichenkette bei Copy’nPaste mitkopiert (FF3). Das könnte bei Unaufmerksamkeit dazu führen, dass die EMail nicht ankommt ;)

  51. @SITS & Co: Es ist ja gerade Sinn der Sache, dass die Adressen nicht einfach zu kopieren sind :) Wenn die Adressen einfach zu kopieren wären, gäbe es wieder keinen Schutz vor Spam.

  52. Besonders die reinen CSS-Lösungen finde ich clever. Dass das Umkehren der Schreibrichtung Nachteile beim Kopieren hat, ist aber weniger schön.

  53. … und nach dieser Veröffentlichung dürften wohl gerade diese beiden „einfachen“ CSS-Lösungen nun auch nicht mehr sonderlich sicher sein. :-/

  54. Die Veränderung der Schreibrichtung funktioniert in einigen Browsern nicht oder nicht korrekt!

  55. Letztere Methode kommt bei mir seit rund einem Jahr zum Einsatz und funktioniert blendend. Ich habe das noch verfeinert, indem ich den unsichtbaren String an verschiedene Stellen der Domain rücke und dynamisch eine Zeichenfolge generiere. Zudem kann man Leerzeichen einbauen. Mit diesen x Faktoren lässt sich eine Adresse für einen Bot so umbauen, dass sie nciht mehr dem gesuchten Muster entspricht und nicht mehr gefunden wird.

  56. Kurzer Nachtrag: In der verlinkten Quelle schreiben einige Kommentatoren, dass beide CSS-Methoden zu kaputtem Copy&Paste führen. Scheint also browserabhängig zu sein.

  57. Wow, es einfach und doch so genial. Manchmal sind die einfachste Dinge auch die Besten – man muss nur drauf kommen. Sehr gut! Ich verwende jetzt auch diese Methode :-)

    Danke für diesen extrem wertvollen Tipp!

  58. Ich binde meine E-Mail-Adresse für gewöhnlich als Bild ein. Die Technik habe ich zwar nicht so schön getestet, aber ich vermute, dass sie auch sehr effektiv ist.

    Die CSS-Lösungen finde ich auch schick. Vor allem die zweite, denn bei dieser kann man die Adresse sogar kopieren. Wenn ich die erste kopiere bekomme ich sie leider in der ursprünglichen also umgekehrten Schreibrichtung.

    • Das Einbinden als Bild ist allerdings für das Impressum keine Lösung, da die Emailadresse dort zugänglich sein soll.

      Ich für meinen Teil habe mich für eine Kombination aus beiden oben angegebenen Lösungen entschieden. Also Falsch rum und „Spam“ für den Spambot. Doppelt hält besser ;-)

  59. Toller Beitrag und vorallem die zwei „einfachen“ CSS Lösungen finde ich genial. lg hOO

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kennst du schon unseren Newsletter?

Hinweise zum Datenschutz, also dem Einsatz von Double-Opt-In, der Protokollierung der Anmeldung, der Erfolgsmessung, dem Einsatz von MailChimp als Versanddienstleister und deinen Widerrufsrechten findest du in unseren Datenschutzhinweisen.