TYPO3 Core

It’s not a 100% solution, but fighting against Spam is important on all fronts. It saved resources and money if addresses don’t get crawled in first place.
If there is good library that can replace the code base this would be the best solution IMO.

There are aspects that don't make much sense - like ASCII or HEX encoding to HTML entities.
However, there are measurements that do make sense and can be enhanced (e.g. having something like CloudFlare provides).

In order to get some numbers, I've started https://empirical-experiments.de/ - it'll will take some time until bots process it. In particular the different test are located at https://empirical-experiments.de/blog/email-markup

Research studies I found so far only focussed on detecting(!) spam on a server-level.
Adding some more potential references (in terms of "opinions"):

• https://mailtrap.io/blog/email-obfuscation/
• https://perishablepress.com/best-method-for-email-obfuscation/
• https://superuser.com/questions/235937/does-e-mail-address-obfuscation-actually-work

So, according to the links Oliver provided, javascript encryption (numeric value for spamProtectEmailAddresses) still seems to be pretty effective - and is, by the way, not "broken" by the html sanitizer, since the javascript:linkTo_UncryptMailto-href is left untouched (at least in 9.5.30, will check 10.4 later today).

So the only problem seems to be finding good values for spamProtectEmailAddresses_atSubst and spamProtectEmailAddresses_lastDotSubst. (at)/(dot) are probably not the best values. Some JS call like <script>obscureAt()</script> worked until the latest html sanitizer changes, BUT can be easily turned around to something like:

<a href="javascript:linkTo_UncryptMailto(xyz...);">mail*company#tld</a>

JS:
$('a[href^="javascript:linkTo_UncryptMailto"]').each(function(e) { // Substitute at/dot here });

As long as the substitute characters are non-valid characters or "unique enough" (think of something like ~.~ ;-)), this solution should be compatibly with almost all mail addresses out there - and won't be affected by html sanitizing, since there is not <script> tag in the HTML.

Of course, there may always be one very sophisticated spam harvester that fully parses all JS on a page, but as long as 99% of all "stupid" harvesters are blocked, it will make a difference if the mail addresses are spam-protected in some way.

+ 1 for keeping spamProtectEmailAddresses

Hi Oliver

Did you got some empirical results from your experiments?

Rémy DANIEL wrote in #note-6:

Hi Oliver

Did you got some empirical results from your experiments?

None, I did not receive any spam - even for the exposed addresses.