Mailadressen auf Webseiten vor Harvestern schützen
Welche Verfahren automatisiertes Absammeln tatsächlich erschweren, welche nur Barrierefreiheit kosten und warum das Kontaktformular in den meisten Fällen die bessere Antwort ist.
Das Wichtigste
- Die Mailadresse im Impressum ist nach § 5 DDG Pflicht. Sie darf erschwert lesbar sein, aber nicht durch ein Formular ersetzt werden.
- Adressen als Bild sind für Screenreader unbrauchbar und lassen sich per OCR trotzdem auslesen – schlechtester Kompromiss von allen.
- HTML-Entities halten heute keinen ernstzunehmenden Harvester mehr auf. Jeder Parser dekodiert sie.
- Wirksam bleibt, was ohne JavaScript keine Adresse im Quelltext hinterlässt – zulasten der Nutzer ohne JavaScript.
Adressen von Webseiten abzusammeln ist trivial: HTML abrufen, nach einem Muster suchen, fertig. Jede Gegenmassnahme funktioniert deshalb nur so lange, wie sie das Muster verändert – und genau das steht im Konflikt mit Lesbarkeit, Barrierefreiheit und der Impressumspflicht.
Was die Verfahren wirklich leisten
| Verfahren | Schutz | Nutzbar ohne JS | Barrierefrei | Klickbar |
|---|---|---|---|---|
| Adresse im Klartext | keiner | ja | ja | ja |
at und punkt ausgeschrieben | sehr gering | ja | eingeschränkt | nein |
| HTML-Entities | sehr gering | ja | ja | ja |
| CSS mit umgekehrter Schreibrichtung | gering | ja | nein | nein |
| Adresse als Bild | gering (OCR) | ja | nein | nein |
| Zusammenbau per JavaScript | mittel | nein | ja | ja |
| Kontaktformular zusätzlich | – | ja | ja | – |
Die ersten drei Zeilen kosten Komfort und bringen praktisch nichts. Ein Harvester, der HTML parst, dekodiert Entities automatisch – das macht schon der Browser-Parser, den viele Crawler mitbringen.
Der brauchbare Kompromiss
Die Adresse steht als lesbarer Text auf der Seite, der mailto:-Link wird per JavaScript ergänzt. Ohne JavaScript sieht der Nutzer die Adresse, kann sie aber nicht anklicken. Im ausgelieferten HTML steht sie nicht in einer Form, die ein einfaches Muster trifft:
<span class="mail" data-user="kontakt" data-host="example.com">
kontakt (at) example.com
</span>
<script>
document.querySelectorAll('.mail').forEach(function (el) {
var addr = el.dataset.user + '@' + el.dataset.host;
var a = document.createElement('a');
a.href = 'mailto:' + addr;
a.textContent = addr;
el.replaceWith(a);
});
</script>Der Trick ist die Aufteilung auf zwei Attribute. Ein Harvester müsste den Zusammenbau nachvollziehen, statt nur ein Muster zu suchen. Aufwändigere Crawler, die eine JavaScript-Engine mitbringen, kommen trotzdem an die Adresse – aber die sind in der Minderheit und teurer im Betrieb.
Der Nachteil ist real: Wer JavaScript deaktiviert hat, bekommt keinen klickbaren Link. Für ein Impressum ist das vertretbar, solange die Adresse als Text sichtbar bleibt und in einer Form, die man abtippen kann.
Was rechtlich gilt
Die Anbieterkennzeichnung nach § 5 DDG verlangt Angaben, die eine schnelle elektronische Kontaktaufnahme ermöglichen, ausdrücklich einschliesslich der Adresse der elektronischen Post. Daraus folgt:
- Die Adresse muss vorhanden und auffindbar sein.
- Sie darf erschwert maschinenlesbar sein – Verschleierung ist zulässig, solange ein Mensch sie ohne Weiteres erfassen kann.
- Sie darf nicht durch ein Kontaktformular ersetzt werden. Ein Formular ist eine sinnvolle Ergänzung, kein Ersatz.
Eine Adresse ausschliesslich als Bild ist damit heikel: Für Nutzer mit Screenreader ist sie nicht erfassbar.
Der wirksamere Weg: Filtern statt Verstecken
Die Adresse wird früher oder später bekannt. Nicht unbedingt über deine Webseite – ein einziger Kontakt mit kompromittiertem Adressbuch genügt. Verschleierung verschiebt den Zeitpunkt, sie verhindert ihn nicht.
Die dauerhafte Lösung liegt auf dem Mailserver:
- Greylisting als erste, sehr günstige Stufe.
- RBL-Abfragen gegen bekannte Botnetz-IPs vor der Annahme.
- SPF, DKIM und DMARC durchsetzen, damit gefälschte Absender in deinem Namen scheitern.
- Inhaltsfilter wie rspamd für alles, was durchkommt.
Ein Postfach hinter dieser Kette verträgt eine öffentlich stehende Adresse. Eines ohne diese Kette hilft auch die aufwändigste Verschleierung nicht.
Rollenadressen statt persönlicher Adressen
Praktischer Nebeneffekt: Wer im Impressum kontakt@example.com statt einer personenbezogenen Adresse angibt, kann die Adresse bei zu hohem Spamaufkommen austauschen, ohne dass jemand seine persönliche Mailadresse aufgeben muss. Rollenadressen lassen sich zudem auf mehrere Empfänger verteilen und beim Weggang einer Person weiterreichen.
Häufige Fragen
Darf ich die Mailadresse im Impressum durch ein Kontaktformular ersetzen?
Nein. Die Rechtsprechung verlangt eine elektronische Kontaktmöglichkeit, die unmittelbare Kommunikation erlaubt, und eine Mailadresse gehört dazu. Ein Formular darf zusätzlich angeboten werden, ersetzt die Adresse aber nicht.
Hilft es, die Adresse als at und punkt zu schreiben?
Kaum. Die Muster sind seit Jahrzehnten bekannt und werden von jedem Harvester mit ausgewertet. Der einzige verlässliche Effekt ist, dass niemand mehr auf den Link klicken kann.
Ist eine Adresse als Bild eine gute Lösung?
Nein. Screenreader lesen sie nicht vor, kopieren lässt sie sich nicht, und Texterkennung liest sie in Sekunden aus. Sie kostet Barrierefreiheit, ohne nennenswerten Schutz zu bieten.
Was bringt mehr: Verschleierung oder Filterung?
Filterung. Die Adresse wird ohnehin irgendwann bekannt, spätestens wenn ein Kontakt sie in einem kompromittierten Adressbuch stehen hat. Ein gut konfigurierter Mailserver mit Greylisting, RBL und Inhaltsfilter löst das Problem dauerhaft, Verschleierung nur bis zum nächsten Harvester.
Weiterlesen
- PHP-Mailformulare gegen Header-Injection absichern
Eingaben validieren, Header-Zeilen filtern, Rate-Limits setzen und Spam abfangen, ohne echte Anfragen zu blockieren.
- Greylisting: Funktionsweise, Nutzen und Grenzen
Warum ein temporäres Ablehnen den Grossteil des Bot-Spams stoppt, was es an Zustellverzögerung kostet und wie Whitelists den Ärger begrenzen.
- SPF, DKIM und DMARC einrichten
Die drei Einträge in der richtigen Reihenfolge, typische Syntaxfehler und wie du von p=none auf p=reject kommst, ohne Mails zu verlieren.
- Postfix-Grundkonfiguration für kleine Server
main.cf-Einstellungen, die wirklich zählen: Restriktionen, TLS, Limits und ein Setup, das kein offenes Relay wird.