Hi, war schon länger nicht mehr hier im Forum unterwegs.
War grade am überlegen wie man Email Adressen effektiv aber user-zugänglich vor mail-harvestern schützen kann.
Folgende Überlegung:
Alle Email Adressen werden ersetzt mit einem Link, in etwa: mail.php?name=x&domain=y
Die mail.php sähe dann konsequenterweise in etwa so aus:
Auf Userseite scheint diese Methode zu funktionieren, zumindest mein Test mit Firefox lief erfolgreich: Email-Client öffnet sich und der Rest der Seite wird ausgegeben.
Daher stellt sich mir jetzt die Frage, funktioniert das generell, oder würde man auch hier einigen Usern den Zugang verwehren?
Aber vor allem: was macht der mail harvester wenn er dem Link folgt? wird er sozusagen von der Weiterleitung auf mailto überrumpelt, weil er einen Quelltext auslesen will, den er nicht bekommt, oder schafft er es trotzdem die Adresse in seine Datenbank einzutragen?
bin gespannt auf Antworten
PS: Wie verhält sich eigentlich ein mailto Link bei Usern die keinen Email Clienten nutzen?
Die Weiterleitung im header ist ja Bestandteil von HTTP, das wird
jedes Programm interpretieren können, jeder browser und auch
jeder Roboter, der im Netz unterwegs ist.
Wenn mit mailto im Programm kein email-Programm verknüpft
ist, funktioniert das natürlich nicht, genausowenig wie in einem
normalen Verweis. Der Inhalt des headers ist natürlich immer
verfügbar und auswertbar.
Da Roboter auch GET-Anfragen folgen, insbesondere wenn sie
nicht direkt mit einem Formular erzeugt werden, stellt das also
vermutlich kein großes Hindernis dar. Ein Formular an sich wohl
schon, besonders wenn es mit POST funktioniert und anhand
der Attribute ‘name’ im Formular nicht unmittelbar erkennbar
ist, wozu das Formular dienen soll.
Ok Danke.
Dann werd ichs wohl mal mit dieser Methode versuchen.
Javascript bietet zwar wahrscheinlich auch keine unbegrenzten Schutz vor Bots aber es ist sicherlich besser als nichts und anwenderfreundlich.
Bild wohl in der Tat noch mit Abstand das sicherste, aber auch am nervigsten, wenn man extra abtippen muss
Formular ist insofern umständlich dass es ne Lösung für ein Gästebuch sein soll, in dem man die Email-Adresse freiwillig angeben kann. Und dann oft die Adresse an sich interessanter, als die Kontaktmöglichkeit über ein Formular.
Von daher denke ich dass Javascript der derzeit beste Kompromiss zwischen Sicherheit und usability ist.
Das Unzugänglichmachen von Kontaktadressen mit java-script
ist nun wieder eine ziemlich üble Lösung, ähnlich übel wie der
Einsatz von Pixelgraphik. Wenn man das nicht zugänglich haben
will, sollte man das einfach ganz weglassen, dann gibt es auch
keine Probleme.
Bei den gesetzlich vorgeschriebenen Kontaktmöglichkeiten kann
man das nicht ganz weglassen, da kann man aber auch ein
Formular verwenden.
Man könnte auch noch mal testen, ob es (immer noch)
funktioniert, die komplette email-Adresse einschließlich
’mailto’ mittels (X)HTML-unicode-Maskierung eines jeden
Zeichens anzubieten. Für darstellende/interpretierende
browser ist das kein Problem und kein Zugänglichkeitshindernis.
Für Roboter, die einfach nur nach unmaskierten Schlüsseln wie
’mailto:’ und ‘@’ suchen, ist das aber schon ein Hindernis, weil
die die Einzelzeichenmaskierung nicht prüfen.
[quote=“hoffmann”]Für Roboter, die einfach nur nach unmaskierten Schlüsseln wie
’mailto:’ und ‘@’ suchen, ist das aber schon ein Hindernis, weil
die die Einzelzeichenmaskierung nicht prüfen.[/quote]
Entities oder Unicode-Zeichenreferenzen dekodieren zu koennen, gehoert zum grundlegenden Funktionsumfang jedes HTML-Parsers.
Fertige HTML-Parser gibt’s wohl in jeder Sprache, mit der man auch einen Bot schreiben kann - das stellt also keine Huerde dar, wenn man nur etwas mehr Aufwand betreibt, als reine Zeichenkettensuche.
Warum sollte es das auch?
Google sucht sich ein paar wichtige Tags raus, erhält daraus Titel und Beschreibung, und lässt alles andere wegfallen.
Google ist es wirklich Scheiß-egal ob der Text nun in einer Liste, im Header, kursiv, fett oder wie auch immer ist…
Wenn du das aber schon als parsen verstehst, dann muss ich dir Recht geben
Nunja, während das parsen von XML-Formaten ein recht
überschaubares Problem ist, ist das beim guten alten HTML
meist ein größeres Kunststück, insbesondere wenn man bedenkt,
daß die meisten Seiten grob fehlerhaft sind.
Die Erfolge und Resultate bei den wenigen, die es versuchen,
sind ja auch recht unterschiedlich und die Frustration ist relativ
hoch, sieht man ja auch an so einer Frustreaktion wie ‘HTML5’,
die stammt ja in wesentlichen Teilen von browser-Anbietern und
von Google-Mitarbeitern.
Insofern - da es bei dem spam-bots ja doch meist darum geht, mit
niedrigem Aufwand eine große Wirkung zu erzielen, ist es nicht
so unwahrscheinlich, daß die den Quelltext nur nach bestimmten
’Schlüsselreizen’ durchsuchen, selbst wenn ihnen da ein paar
Schlaumeier durch die Lappen gehen, die Masse zählt ;o)
Ich meine, bei meinem email-Konto, welches ich als Kontakt
angebe, geht die spam-Rate langsam zurück, seit ich die
konsequent maskiere, kann man natürlich nicht wirklich sagen,
ob es daran liegt oder das eine andere Ursache hat.
Für die Google-Bots wird es ja auch reichen, nach einigen
Schlüsselelementen zu suchen und deren Inhalt dann etwas
besser zu gewichten. Wenn da dem bot was fehlerhaft vorkommt,
kann er die Aktion ja einfach abbrechen und nur nach dem Inhalt
gucken, fällt ja doch niemandem auf, weil das Ergebnis ja nie
zu einer Präsentation des Dokumentes selbst führt. Insofern
können die da schon mal viel dünnere Bretter bohren als ein
Anbieter eines browsers, der ja wirklich jeden HTML-Müll
irgendwie darstellen können soll. Gibt ja wohl auch das
begründete Gerücht, daß man mit korrekten und strukturierten
Seiten bei den bots eher weiterkommt als mit irgendwelchem
Gerümpel ;o)
Man muss ja nicht das komplette HTML in eine DOM-Struktur parsen (was den Aufwand zugegebenermaszen bei fehlerhaftem HTML drastisch erhoehen wuerde) - Entities und nummerische Zeichenreferenzen aufloesen kann man “auch so”, dazu reichen ein paar regulaere Ausdruecke und ggf. eine Ersetzungstabelle. Und schon kann man da wieder “normale” Stringfunktion drueberjagen, die nach mailto:… u.ae. suchen.
