Project

General

Profile

Actions

Story #94904

open

Is spamProtectEmailAddresses still worth keeping around?

Added by Benni Mack over 2 years ago. Updated 9 months ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Frontend
Target version:
-
Start date:
2021-08-16
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
11
PHP Version:
Tags:
Sprint Focus:

Description

This question is around for quite some time, and I think it's worth discussing whether this option makes sense or not, or if we should deprecate it.

The main issue with having it around is still some quirks in our code base. Mainly the issue is regarding Content-Security-Policy (spamProtectEmailAddresses does not work with proper CSPs), and having inline JS which is output in Frontend (e.g. a separate JS file for the 50 lines of code).

I think it's best to have good and qualified feedback with statistics and numbers before we should move on regarding this feature.


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #89910: spamProtectEmailAddresses doesn't work as expected with value "ascii" Closed2019-12-10

Actions
Actions #1

Updated by Jan Kiesewetter over 2 years ago

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.

Actions #2

Updated by Oliver Hader over 2 years ago

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

Actions #3

Updated by Oliver Hader over 2 years ago

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

Actions #4

Updated by Sven Teuber over 2 years ago

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

Actions #5

Updated by Oliver Hader about 2 years ago

  • Related to Bug #89910: spamProtectEmailAddresses doesn't work as expected with value "ascii" added
Actions #6

Updated by Rémy DANIEL 9 months ago

Hi Oliver

Did you got some empirical results from your experiments?

Actions #7

Updated by Oliver Hader 9 months ago

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.

Actions

Also available in: Atom PDF