• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick

[tut] E-Mail-Adresse vor Harvestern schützen

floeschen

Horneburger Pfannkuchenapfel
Registriert
13.08.06
Beiträge
1.402
Das Problem
Wer im Web auf einer Webseite seine Mail-Adresse einfach so in den Text hineinschreibt und veröffentlicht, verursacht schon fast fahrlässig Spam. Denn das Web wird nicht nur von "guten" Spidern der Suchmaschinen, sondern auch von bösen Harvestern durchsucht. Diese suchen gezielt nach Mail-Adressen. Die so gefundenen Adressen werden dann von den Spammern dazu benutzt, möglichst viele Mails zu versenden.

Die Methode ist grundsätzlich intelligent, denn man kann annehmen, dass im Web veröffentlichte Mail-Adressen fast immer korrekt sind. Ratespiele mit Vor- und Nachnamen ins Blau hinaus sind da weniger erfolgsversprechend.

Das Dilemma
Jede und jeder, der im Web präsent ist, möchte aber gerne per Mail erreichbar sein und veröffentlicht deshalb seine Adresse. Auch hier bei AT gibt es immer wieder Leute, die ihre Adresse fahrlässigerweise veröffentlichen.


Die Lösungen
Es gibt mehr oder weniger praktiable Lösungen für das Problem und drei davon möchte ich gerne vorstellen.

Zuerst kommt eine kurze Beschreibung der Lösung und danach ein Beispiel.

Das @ und den Punkt ersetzen
Email-Adressen charakterisieren sich durch zwei wesentliche Dinge an denen sie sofort erkannt werden können: das @ und der Punkt vor dem Länderdomain. Als einfache Lösung kann man diese beiden ersetzen, damit wird es für Harvester schwierig, die Adresse zu erkennen. Das @ kann durch ät, at o. ä. ersetzt werden. Je nachdem nimmt man auch Klammern zu Hilfe, um es hervorzuheben. Beim Punkt gilt dasselbe: von Punggt bis punkkkkt ist alles denkbar. Wichtig ist einzig, dass der Besucher der Seite die Adresse erkennt, was sich aber mit einem simplen Hinweis ("E-Mail-Adresse:") erreichen lässt.

Vorteile: einfach und schnell realisierbar, wirksamer Schutz;
Nachteile: Adresse evtl. schwer zu erkennen, verunmöglicht in Foren & Co. möglicherweise gewisse Funktionen

Original Adresse: [noparse][email protected][/noparse]
umgewandelt in: spam[ätt]example[pungt]com oder spam{at}example{punkkt}com


Das CSS-Konstrukt
Mit CSS und ein wenig Nachdenken kommt man zu einer weiteren Lösung. Um die Adresse wird ein Nicht-Block-HTML-Tag gelegt (z.B. <span>). Dort wird dann mit der CSS-Anweisung in Style bewirkt, dass die Mail-Adresse von rechts nach links gelesen wird. Dabei muss folgendes in das Style-Attribut eingefügt werden. Alternativ kann auch eine Klasse in CSS verwendet werden. Die Adresse muss umgekehrt eingegeben werden, ganz so, wie im Beispiel unten zu sehen.
Code:
<span style="unicode-bidi: bidi-override; direction: rtl">moc.elpmaxe@maps</span>
Die Adresse wird im Browser dann normal angezeigt, ausser bei einigen wenigen älteren Modellen.

Vorteile: Adresse wird "wie echt" angezeigt, wirksam
Nachteile: nicht in Foren & Co. möglich, ältere Browser bleiben ausgeschlossen

Die Bild-Variante
Wem das alles nicht genug ist, der kann auf eine dritte simple Methode zurückgreifen: Einfach die Mail-Adresse als Grafikdatei in die Webseite einbinden. Das klappt mit allen Browsern und alle können es sehen. Harvester haben keine Chance.

Vorteile: einfach zu machen, für alle verfügbar, trotzdem guter Schutz vor Spam
Nachteile: bei Designwechsel auch an die Adressengrafik denken, Grafik passt vielleicht nicht exakt in den Flusstext (Zeilenabstand wird bei einer Zeile grösser)

Das Fazit
Wie auch immer: Der Schutz vor Harvestern ist zwar teilweise etwas mühsam und lästig, aber zumindest in meinen Augen nötig.

Welche der drei Lösungen angewandt wird, ist jeweils spezifisch für jede Situation.
 

pepi

Cellini
Registriert
03.09.05
Beiträge
8.740
Was ist mit Unicode oder HTML-Entity Encoding Varianten? Diese werden in eigentlich allen halbwegs modernen Browsern korrekt dargestellt und verlangen auch keine besonderen JavaScript oder CSS Fähigkeiten des Browsers. Mischbar sind diese natürlich auch.

Das Problem bei quasi allen diesen Methoden ist leider, daß man solcherart "verwurstete" eMail Adressen oft nicht mehr ordentlich per Copy & Paste ins Mailprogramm übertragen kann.
Gruß Pepi
 

Skeeve

Pomme d'or
Registriert
26.10.05
Beiträge
3.120
Oder man setzt kodierte Einmal-Adressen. Das ist etwas Aufwand, aber so bekommt jeder Besucher eine eigene Adresse und diese kann gegebenenfalls sofort deaktiviert werden. Z.B. kann so eine Adresse aus IP des Besuchers + Zeitstempel bestehen: [email protected]
Häßliche Adresse, ich stimme zu. Aber das ist ja auch erstmal nur eine Idee.
 

Hobbes_

Gast
Oder man setzt kodierte Einmal-Adressen. Das ist etwas Aufwand, aber so bekommt jeder Besucher eine eigene Adresse und diese kann gegebenenfalls sofort deaktiviert werden. Z.B. kann so eine Adresse aus IP des Besuchers + Zeitstempel bestehen: [email protected]
Häßliche Adresse, ich stimme zu. Aber das ist ja auch erstmal nur eine Idee.

Ich denke, ich verstehe langsam die Idee hinter diesem Konzept...

Insbesondere auch wenn es unter Umständen um eine rechtliche Nachverfolgbarkeit geht, ist eine Integration der IP und der Zeit sicher praktisch.

Meine Befürchtung ist jedoch, dass das dem Admin der Seite (sprich mir) mehr Arbeit gibt, da das aussortieren sowieso über einen SPAM-Filter laufen muss und gute SPAM-Filter diese Arbeit bereits schon aufgrund anderer Kriterien recht gut bis sehr gut erledigen...

Optimal wäre in diesem Zusammenhang völlig auf eine eMail-Adresse zu verzichten und nur ein Formular zur Verfügung zu stellen, optimal mit CAPTCHA (siehe Link).
 

Herr Sin

Sternapfel
Registriert
05.01.04
Beiträge
4.990
Das Problem sind auch (unwissende) Kollegen. Ich habe zB. vor geraumer Zeit meine Mail-Adressen bei GMX, Web.de aufgegeben. Habe zwei Adressen mit meiner Domain eingerichtet: Mein "private" Mail mit dem Vornamen steht nirgends online. Die kennen wirklich nur max. 15 Leute. Nun habe ich einen Kollegen, der mir gerne lustige Mails mit Videos, Bilder, ... schickt. Und er hat auch die Angewohnheit die Mail noch an 40 andere Leute zu schicken. Natürlich sind alle Adressen sichtbar. Und was passiert? Ich bekommen nun auf meiner neuen Mail plötzlich 2-5 Spam-Mails pro Tag.

Ich bin schon am überlegen, für jede Person, der ich meine Adresse gebe, eine extra Adresse einzurichten.
 

pepi

Cellini
Registriert
03.09.05
Beiträge
8.740
Ich vergebe selbst für Firmen oder Newsletter Abos jeweils eine eigene Mailadresse. Einerseits um unerlaubte Weitergaben meiner Mailadressen verfolgen zu können, und andererseits um im Notfall einen solchen Alias ganz einfach wieder deaktivieren zu können wenn es notwendig sein sollte.

Allerdings kann das nicht jeder einfach so selbst machen. Ich betreibe und verwalte meine Mailserver selbst, somit ist das für mich kein Problem, das ist aber absolut als Ausnahme zu werten. Wer ein hübsches Webinterface zur Verwaltung seiner Mailkonfiguration beim Provider hat kann das vielleicht auch noch machen.

Ein Problem welches man damit allerdings nicht lösen kann ist eben das notwendige Veröffentlichen/Posten von Mailadressen auf Webseiten. Beispielsweise "muß" man heutzutage als Firma so Adressen wie office@ oder info@ publizieren. Auch wenn es schon ziemlich unnötig ist solche Adressen zu kodieren da diese von jedem Spammer für jede Domain prinzipiell probiert werden unternimmt man trotzdem den Versuch es nicht wirklich jedem Idioten zu einfach zu machen.

@Herr Sin
Ich kann Dich nur zu gut verstehen. Man sollte jedem der Mails mit "ach so lustigen Inhalten" verschickt und dort n>1 Person im To: Feld einträgt verprügeln eindringlich darauf hinweisen, daß sich das nicht gehört. Ebenso wie es sich nicht gehört eMails ohne Betreff zu versenden was ich ab sofort auf meinem Mailserver blockieren werde. :)
Gruß Pepi
 

floeschen

Horneburger Pfannkuchenapfel
Registriert
13.08.06
Beiträge
1.402
Was ist mit Unicode oder HTML-Entity Encoding Varianten? Diese werden in eigentlich allen halbwegs modernen Browsern korrekt dargestellt und verlangen auch keine besonderen JavaScript oder CSS Fähigkeiten des Browsers. Mischbar sind diese natürlich auch.

Das Problem bei quasi allen diesen Methoden ist leider, daß man solcherart "verwurstete" eMail Adressen oft nicht mehr ordentlich per Copy & Paste ins Mailprogramm übertragen kann.
Gruß Pepi
Wenn man das @ mit Entity darstellt, wird dann der Spider immer noch verwirrt? Sollte der nicht dasselbe "sehen" wie ein normaler Browser und damit die Adresse korrekt erkennen? o_O

Persönlich verwende ich nur noch die beschriebene CSS-Variante, weil ich mit einer CSS-Klasse alles abdecken kann. Ausserdem wechseln meine Adressen nicht täglich. :)
 

Hilarious

Gelbe Schleswiger Reinette
Registriert
10.08.05
Beiträge
1.759
Die CSS-Variante hat allerdings immer noch den Nachteil, dass ein Spam-Harvester diese Adresse mühelos mit Hilfe von eines passenden Regexes ausfindig machen kann. Ich denke, hilfreicher ist hier, die Adresse nicht mehr im Klartext auszuschreiben und diese Adresse durch einen speziell präparierten Link mit einem Ziel auf dem Server zu verlinken (zum Beispiel: /briefbote.php?adressat=25). Dort wird diese Action wiederum ausgelesen und ein MailTo-Header nach Prüfung an den Client zurückgeschickt, und zwar mit der aus einer Tabelle von Adressen herausgefischten E-Mail-Adresse (in diesem Fall die Adresse 25). Auf dem Weg durch den Server lassen sich noch verschiedenste Prüfungen vornehmen.

Ebenfalls nicht sonderlich schwierig und sehr effektiv ist es, zusätzlich dieses Verfahren mit der obigen Methode der speziell für den Client hergestellten Adresse (zum Beispiel mit IP-Adresse und Datum codiert) zu verbinden; den Client also eine spezielle Adresse zuzuschicken, die so im schlimmsten Falle nur einmalig verwenbar wäre (der Fantasie sind keine Grenzen gesetzt).

Blöd natürlich, dass dies keine gangbaren Lösungen für kleine Ansprüche sind und immer serverseitige Infrastrukturen erfordert. Aber wenn man vom SPAM erst mal die Nase voll hat...