wwt3_encryption für TYPO3

Warum E-Mail-Verschleierung nach wie vor Pflicht für jede öffentliche Website ist

Jede Firmen-Website, jede Hochschul-Seite und jeder Behörden-Auftritt veröffentlicht E-Mail-Adressen: Ansprechpartner im Impressum, Kontaktpersonen in Teams, Presse-Kontakte in Newsrooms, Rechtsabteilung in Datenschutzhinweisen. Ohne Schutz sammeln Harvester-Bots diese Adressen innerhalb weniger Tage nach der Veröffentlichung und verkaufen sie an Spam-Versender. wwt3_encryption ist eine klassische TYPO3-Extension für dieses Problem und verschlüsselt E-Mail-Adressen serverseitig, sodass Bots beim HTML-Parsing nur unbrauchbaren Code sehen, während echte Nutzer auf die korrekte Adresse klicken können. Die Extension richtet sich an Betreiber, die aus rechtlichen Gründen Kontaktdaten prominent zeigen müssen, aber nicht bereit sind, die resultierende Spam-Flut in Kauf zu nehmen.

Typische Einsatzszenarien

Eine Anwaltskanzlei mit 60 Partnern und Associates veröffentlicht alle Anwalts-Profile inklusive direkter E-Mail-Adressen, weil die Berufsordnung eine erreichbare Kontaktangabe fordert. Ohne Verschleierung erhalten alle 60 Adressen binnen Wochen Phishing-Mails, Werbung und zum Teil gezielte Angriffe. wwt3_encryption rendert die Adressen so, dass der Quelltext keinen lesbaren @-String enthält, während der Browser beim Nutzer die korrekte mailto-Link-Adresse anzeigt.

Ein zweites Szenario ist eine Hochschule, die Fachbereichs-Seiten mit Lehrstuhl-Kontakten pflegt. Jeder Lehrstuhl hat eine Webseite mit Telefon- und E-Mail-Angaben, die über das TYPO3-Content-Management redaktionell gepflegt werden. Redakteure tragen die Adressen als normalen Text in RichText-Elementen oder Kontaktfelder ein, ohne sich um Verschleierung kümmern zu müssen. wwt3_encryption greift automatisch in den Rendering-Prozess ein und schützt alle mailto-Links ohne redaktionelle Mehrarbeit.

Der dritte Fall sind öffentliche Verwaltungen mit Impressum, Kontaktformularen und Fachabteilungs-Listen. Hier ist die Anforderung oft noch strenger, weil ein Barrierefreiheits-Anspruch besteht: Die geschützte Adresse muss von Screenreadern korrekt vorgelesen werden, und ein Klick muss den Mail-Client öffnen, genau wie bei einer unverschleierten Adresse. Eine Kombination aus JavaScript-Dekodierung und semantisch sauberen href-Attributen ist der einzige Weg, beides zu erfüllen.

Technische Architektur: Content-Post-Processing im TYPO3-Rendering

wwt3_encryption klinkt sich in den Rendering-Prozess von TYPO3 ein, typischerweise über einen Content-Post-Processor-Hook oder ein TypoScript-Userfunc. Nach dem Zusammenbau des HTML-Outputs durch den Page-Renderer durchläuft die Extension das fertige Markup, findet alle mailto-Links und alle einfachen E-Mail-Adressen im Fließtext per Regex und ersetzt sie durch verschleierte Varianten. Die Verschleierung kann über verschiedene Methoden laufen: ROT13-Kodierung des Link-Ziels mit JavaScript-Dekodierung, Base64-Kodierung, Zeichenweise-Fragmentierung mit CSS-Pseudo-Elementen oder eine Kombination.

Der Vorteil der Post-Processing-Variante ist, dass sie ohne Änderungen an Content-Elementen oder Templates funktioniert. Redakteure arbeiten weiter mit normalen mailto-Links im RichText, und die Extension übernimmt die Absicherung automatisch. Konfiguriert wird die Extension über TypoScript-Konstanten, die zwischen den verschiedenen Verschleierungsmethoden wählen und Ausnahmen für bestimmte Seiten- oder Content-Bereiche definieren lassen.

Häufige Probleme und Lösungen

Das erste Problem ist Barrierefreiheit. Reine JavaScript-Lösungen scheitern bei Nutzern mit deaktiviertem JavaScript, und einige Screenreader haben Probleme mit CSS-basierter Zeichenfragmentierung. Ein pragmatischer Ansatz kombiniert eine leicht brechbare Client-Verschleierung mit einem zusätzlichen semantischen aria-label auf dem Link, sodass Screenreader die Adresse korrekt vorlesen, während Harvester an der syntaktischen Unterschiedlichkeit scheitern. Absolute Sicherheit ist mit öffentlich zugänglichen Adressen nicht erreichbar, aber schon moderate Hürden reduzieren die Spam-Last messbar.

Das zweite Problem sind Caching-Schichten. Wenn die Post-Processing-Verschleierung vor dem Page-Cache ausgeführt wird, liefert der Cache die verschleierten Daten aus und alles funktioniert. Liegt sie dagegen nach dem Cache, wird jedes gecachte Seite bei jeder Anfrage erneut durch den Post-Processor geschickt, was die Performance deutlich drückt. Die richtige Reihenfolge im TypoScript-Rendering-Chain ist daher kritisch und sollte bei jeder größeren Änderung am Caching-Verhalten überprüft werden.

Das dritte Thema betrifft dynamische Inhalte. E-Mail-Adressen, die erst per AJAX nachgeladen werden oder aus externen APIs stammen, laufen nicht durch den TYPO3-Renderer und damit auch nicht durch wwt3_encryption. Solche Stellen müssen separat geschützt werden, entweder indem die API selbst verschleierte Varianten liefert oder indem ein clientseitiges JavaScript den nachgeladenen Content nachbearbeitet.

Migration und Versions-Kompatibilität

wwt3_encryption hat wie viele ältere TYPO3-Extensions eine uneinheitliche Versions-Geschichte: Für v9 und v10 gab es gepflegte Releases, für v11 und v12 existieren Community-Forks, deren Aktivität unterschiedlich ist. Wer auf TYPO3 v13 migriert, sollte vor dem Upgrade prüfen, ob der eigene Fork noch funktioniert oder ob ein Wechsel auf eine alternative Verschleierungsmethode notwendig wird.

Der TYPO3-Core bringt selbst eine einfache E-Mail-Verschleierung mit, die über config.spamProtectEmailAddresses im TypoScript aktiviert wird und im Kern-Renderer ROT13 anwendet. Für einfache Setups reicht diese Core-Variante und macht eine eigene Extension überflüssig. Wer stärkere oder flexiblere Verschleierung braucht, etwa mit mehreren parallelen Methoden oder Ausnahmen pro Content-Element, greift zu einer Extension wie wwt3_encryption. Gosign bewertet im Einzelfall, ob die Core-Funktion ausreicht oder eine dedizierte Extension sinnvoll ist, und unterstützt bei Bedarf auch den Umbau auf eine eigene, schlanke Post-Processing-Implementierung, die sich direkt an das jeweilige Projekt anpasst.

Die Effektivität jeder E-Mail-Verschleierung nimmt im Laufe der Zeit ab, weil Harvester-Techniken sich weiterentwickeln. ROT13 gilt heute als nahezu wirkungslos gegen spezialisierte Bots, während zeichenweise Fragmentierung mit CSS oder Unicode-Tricks noch moderate Hürden aufbaut. Die wirklich belastbare Verteidigung ist daher eine Kombination: Verschleierung im HTML-Output, ergänzt um einen guten Spam-Filter auf der Empfänger-Seite und idealerweise eine Kontakt-Option per Formular statt einer direkt veröffentlichten Adresse. Wer die rechtlichen Anforderungen erfüllen muss, wird um die Veröffentlichung nicht herumkommen, sollte aber das Kontakt-Formular als primären Weg anbieten und die Adresse nur sekundär zeigen.

Für Betreiber von TYPO3 v13 empfiehlt sich zusätzlich, die Content-Rendering-Pipeline regelmäßig gegen Breaking Changes im Core zu prüfen. Einige Hook-Punkte, die in früheren Versionen für Post-Processing verfügbar waren, wurden in v13 deprecated oder durch PSR-14-Events ersetzt. Extensions, die sich noch auf alte Hooks verlassen, laufen nach dem Upgrade zwar technisch, bearbeiten aber keine Inhalte mehr. Eine kurze Prüfung der Log-Einträge nach einem Upgrade zeigt solche stillen Ausfälle frühzeitig und verhindert, dass über Wochen unbemerkt unverschleierte Adressen ausgeliefert werden.