wwt3_encryption for TYPO3

Why email obfuscation is still mandatory for every public website

Every corporate website, every university page and every public authority publishes email addresses: contacts in the legal notice, team members on staff pages, press contacts in newsrooms, legal departments in privacy policies. Without protection, harvester bots collect these addresses within a few days of publication and sell them to spam senders. wwt3_encryption is a classic TYPO3 extension for this problem and encrypts email addresses server-side, so that bots parsing the HTML only see unusable code, while real users can click through to the correct address. The extension is aimed at operators who have to show contact data prominently for legal reasons but are not willing to accept the resulting spam flood.

Typical use cases

A law firm with 60 partners and associates publishes all lawyer profiles including direct email addresses, because professional rules of conduct require a reachable contact option. Without obfuscation, all 60 addresses receive phishing mail, advertising and sometimes targeted attacks within weeks. wwt3_encryption renders the addresses so that the source code contains no readable @ string, while the browser shows the correct mailto link address to the user.

A second scenario is a university that maintains department pages with chair contacts. Every chair has a page with phone and email data, edited editorially via the TYPO3 content management. Editors enter the addresses as normal text in rich text elements or contact fields without having to worry about obfuscation. wwt3_encryption automatically hooks into the rendering process and protects all mailto links without any extra editorial work.

The third case is public authorities with legal notices, contact forms and department lists. The requirement here is often even stricter, because an accessibility obligation applies: the protected address has to be read out correctly by screen readers, and a click has to open the mail client, exactly as with an unobfuscated address. A combination of JavaScript decoding and semantically clean href attributes is the only way to satisfy both.

Technical architecture: content post-processing in TYPO3 rendering

wwt3_encryption hooks into the TYPO3 rendering process, typically via a content post-processor hook or a TypoScript userfunc. After the page renderer has assembled the HTML output, the extension walks through the finished markup, finds all mailto links and all simple email addresses in running text via regex and replaces them with obfuscated variants. The obfuscation can run through several methods: ROT13 encoding of the link target with JavaScript decoding, base64 encoding, character-wise fragmentation with CSS pseudo elements or a combination.

The advantage of the post-processing variant is that it works without changes to content elements or templates. Editors keep working with normal mailto links in rich text, and the extension handles the protection automatically. The extension is configured via TypoScript constants that select between the different obfuscation methods and define exceptions for certain page or content areas.

Common problems and solutions

The first problem is accessibility. Pure JavaScript solutions fail for users with JavaScript disabled, and some screen readers struggle with CSS-based character fragmentation. A pragmatic approach combines lightly breakable client-side obfuscation with an additional semantic aria-label on the link, so that screen readers read the address correctly while harvesters fail on the syntactic inconsistency. Absolute security is not achievable with publicly accessible addresses, but even moderate hurdles measurably reduce the spam load.

The second problem is caching layers. If the post-processing obfuscation runs before the page cache, the cache delivers the obfuscated data and everything works. If it runs after the cache, every cached page is sent through the post-processor on every request, which noticeably drags down performance. The correct order in the TypoScript rendering chain is therefore critical and should be reviewed with every larger change to caching behaviour.

The third topic concerns dynamic content. Email addresses that are loaded via AJAX or come from external APIs do not pass through the TYPO3 renderer and therefore not through wwt3_encryption. Such places have to be protected separately, either by having the API deliver obfuscated variants or by a client-side JavaScript that post-processes the loaded content.

Migration and version compatibility

wwt3_encryption, like many older TYPO3 extensions, has an uneven version history: there were maintained releases for v9 and v10, community forks exist for v11 and v12, and their activity varies. Anyone migrating to TYPO3 v13 should check before the upgrade whether their fork still works or whether a switch to an alternative obfuscation method is needed.

The TYPO3 core itself ships a simple email obfuscation enabled via config.spamProtectEmailAddresses in TypoScript, which applies ROT13 in the core renderer. For simple setups this core variant is enough and makes a separate extension unnecessary. Anyone who needs stronger or more flexible obfuscation, for example with several parallel methods or exceptions per content element, reaches for an extension such as wwt3_encryption. Gosign evaluates case by case whether the core function is sufficient or a dedicated extension makes sense, and supports the rebuild to a lean, project-specific post-processing implementation if needed.

The effectiveness of any email obfuscation decreases over time because harvester techniques evolve. ROT13 is today considered nearly ineffective against specialised bots, while character-wise fragmentation with CSS or Unicode tricks still raises moderate barriers. The genuinely robust defence is therefore a combination: obfuscation in the HTML output, a good spam filter on the recipient side and, ideally, a contact form as the primary option rather than a directly published address. Operators who have to meet legal requirements cannot avoid publishing the address but should offer the contact form as the primary path and show the address only as a secondary option.

For operators of TYPO3 v13, it is also worth reviewing the content rendering pipeline regularly for breaking changes in the core. Several hook points that were available in earlier versions for post-processing were deprecated in v13 or replaced by PSR-14 events. Extensions that still rely on old hooks keep running technically after the upgrade but no longer modify any content. A short review of the log entries after an upgrade reveals such silent failures early and prevents unobfuscated addresses from being served unnoticed for weeks.