„Es dauert nicht lange, bis man die erste Spam-Mail bekommt, sobald man seine E-Mail-Adresse ungeschützt im Internet veröffentlicht hat.“ Das schrieb die ursprüngliche Fassung dieses Beitrags im Jahr 2006 – und es stimmt bis heute. Was sich geändert hat, ist die Antwort darauf.
Die Lösung von damals
Der Beitrag empfahl, die Adresse gar nicht erst in den Quelltext zu schreiben, sondern sie von JavaScript aus Einzelteilen zusammensetzen zu lassen. Die Datei hieß spamschutz.js und sah so aus:
function email(name, domain, tld) {
var mail = name + "@" + domain + "." + tld;
var link = "<a href='mailto:" + name + "@" + domain + "." + tld + "'>"
+ mail + "</a>";
document.write(link);
}
Eingebunden wurde sie im Kopfbereich, aufgerufen an der gewünschten Stelle im Text:
<script type="text/javascript">email('mail','deinedomain','de');</script>
Der Gedanke: Ein Bot, der den Quelltext nach dem Muster etwas@etwas.etwas durchsucht, findet nichts, weil die vollständige Adresse dort nirgends steht. Der Besucher dagegen sieht einen ganz normalen Link.
Den Nachteil benannte der Beitrag selbst: Wer JavaScript ausgeschaltet hatte, sah die Adresse gar nicht. Als Alternative nannte er die Adresse als kleine Grafik – „das kann zur Zeit auch noch kein Spam-Bot auslesen“ – mit dem Nachteil, dass man sie abschreiben muss.
Warum das heute nicht mehr trägt
Beide Verfahren sind überholt, und zwar aus je eigenen Gründen.
Die JavaScript-Variante setzt darauf, dass der Bot kein JavaScript ausführt. Das war 2006 eine sichere Annahme. Heute nutzen Crawler dieselben Browser-Engines wie normale Nutzer – sie führen die Funktion aus, warten auf das Ergebnis und lesen die fertige Adresse aus dem gerenderten Dokument. Der Schutz ist damit wirkungslos. Hinzu kommt, dass document.write heute als problematisch gilt und bei asynchron geladenen Skripten das Dokument überschreiben kann.
Die Grafik-Variante hält länger, ist aber aus einem anderen Grund keine Option mehr: Sie ist nicht barrierefrei. Ein Screenreader liest eine Bilddatei nicht vor, die Adresse lässt sich nicht kopieren, nicht anklicken, nicht vergrößern. Und Texterkennung ist inzwischen zuverlässig genug, dass der Schutz ohnehin begrenzt wäre.
Wie man es heute löst
Der ehrliche Ausgangspunkt
Es gibt keine Methode, die eine öffentlich sichtbare Adresse zuverlässig vor Sammlern verbirgt und sie gleichzeitig für alle Nutzer bedienbar hält. Jede Verschleierung, die den Menschen nicht behindert, hindert auch den Bot nicht dauerhaft.
Deshalb hat sich die Frage verschoben: Nicht mehr „wie verstecke ich die Adresse“, sondern „wie gehe ich damit um, dass sie gefunden wird“.
Kontaktformular statt Adresse
Der Standardweg für Unternehmensseiten. Die Adresse steht nirgends im Quelltext, der Besucher braucht kein Mailprogramm, und die Anfrage kommt strukturiert an. Wichtig sind dabei zwei Dinge, die oft falsch gemacht werden:
- Ein Honeypot statt eines Captchas. Ein Feld, das per CSS verborgen ist und von Menschen nie ausgefüllt wird – ist es befüllt, war es ein Bot. Das kostet den Nutzer nichts, während ein Captcha alle belästigt und für manche eine echte Hürde ist.
<label class="hp">Bitte leer lassen
<input type="text" name="website" tabindex="-1" autocomplete="off">
</label>
<style>
.hp { position: absolute; left: -9999px; }
</style>
Serverseitig wird nur geprüft, ob das Feld leer ist:
if (!empty($_POST['website'])) {
// Bot -- stillschweigend verwerfen, keine Fehlermeldung
exit;
}
- Ein Zeitfenster. Wer ein Formular in unter zwei Sekunden absendet, hat es nicht gelesen. Ein Zeitstempel im Formular, serverseitig geprüft, filtert einen großen Teil des automatisierten Verkehrs.
Wenn die Adresse sichtbar sein soll
Bei einem Impressum ist eine erreichbare Adresse rechtlich vorgeschrieben – sie muss also stehen. Dann gilt: normal auszeichnen, nicht verschleiern.
<a href="mailto:info@beispiel.de">info@beispiel.de</a>
Der Schutz wandert an eine andere Stelle: zum Server. Ein moderner Spamfilter auf Postfachebene fängt heute den weit überwiegenden Teil ab – deutlich zuverlässiger, als eine Verschleierung im Quelltext es je könnte. Sinnvoll ist zusätzlich, für öffentlich genannte Adressen eine eigene zu verwenden, damit sich der Sammelverkehr von der internen Post trennen lässt.
Was von der alten Idee übrig bleibt
Eine leichte Verschleierung kostet nichts und hält die einfachsten Sammler ab – sie sollte nur nicht als Schutz missverstanden werden. Die barrierefreie Variante nutzt CSS, um die Anzeige umzudrehen, während im Quelltext eine unbrauchbare Zeichenfolge steht:
<span class="mail-rueckwaerts">ed.leipsieb@ofni</span>
<style>
.mail-rueckwaerts { unicode-bidi: bidi-override; direction: rtl; }
</style>
Das ist derselbe Gedanke wie 2006 – nur ohne JavaScript und ohne Grafik. Anklickbar ist es allerdings nicht, und Screenreader geben es unterschiedlich wieder. Für ein Impressum ist es deshalb ungeeignet; für eine beiläufig genannte Adresse ist es vertretbar.
Gegenüberstellung
- JavaScript-Zusammensetzung – 2006 wirksam, heute wirkungslos, weil Crawler JavaScript ausführen.
- Adresse als Grafik – teilweise noch wirksam, aber nicht barrierefrei und nicht bedienbar.
- Kontaktformular mit Honeypot – der Regelfall für Unternehmensseiten. Adresse taucht nicht auf, kein Captcha nötig.
- Normaler mailto-Link plus Serverfilter – der Weg fürs Impressum. Ehrlich, bedienbar, und der Schutz sitzt dort, wo er wirkt.
Fazit
Der Beitrag von 2006 beschrieb eine gute Lösung für ein Problem, das es weiterhin gibt – nur ist die technische Grundlage weggefallen, auf der sie beruhte. Was bleibt, ist die richtige Beobachtung, dass eine ungeschützt veröffentlichte Adresse zuverlässig gefunden wird. Die Konsequenz daraus ist heute eine andere: Der Schutz liegt nicht mehr im Verstecken, sondern im Filtern.
Bei Kontaktformularen, Spamschutz und rechtssicherer Umsetzung helfen wir als Agentur für Programmierung gerne weiter.
Kommentare