FrontendForms - A module for creating and validating forms on the frontend

[Peter Knight]

Sounds great. What happens when an email is identified as spam. Does it get logged, recorded and not forwarded? Or are there options in case of false positives.  

[Juergen]

Hello @Peter Knight

At the moment, it stops the successful form submission like any other validator and an error message will be displayed to the user under the inputfield, that the text looks like SPAM with a hint to prevent 

• using to much links
• to write to much words in uppercase letters
• using typical SPAM words and so on

If a form has too much failed attempts, it will be logged, with timestamp and IP if this security measure was not disabled manually, but not with detailed information. 

So at the moment it only stops the successful form submission. Maybe the error message is written generally. This could be improved to give more information of what went wrong. 

Idea: Could be done only via a session I think but I have to try it.

 

 

[Peter Knight]

Thanks Juergen 

I guess what I was imagining would be the apparent successful submission of a form. The ProcessWire admin might get the spam notification (or not) to catch any false positives. Is there a danger that by telling spammers or bots what content triggers the spam gate, that we are educating them on how to avoid the system you have in place? 
 

Im only coming at this from my own PoV. Looks like a great Module. 

[Juergen]

Hello @Peter Knight

To be clear, FrontendForms doesn't send any form data by default – it just checks whether a form is valid or not. Inside the isValid() method, you can send form data — or do whatever you want (e.g., store the values on a page). So it's not a "Email Form" module by default.

Informing about what went wrong

So in this case, it's a bit more complicated. The validator can only set the form validation to true or false (without sending information to an administrator). Of course, it could happen that a real person uses some characteristics of a SPAM text and the text is therefore declared as SPAM. This risk always exists, but it is very low. For this reason, it is necessary to inform the user about which mechanisms were responsible for the failure of validation. But I agree with you: too much detailed information (e.g., word 1 and word 2 are SPAM words) could give a human spammer too much information.

My Opinion:

In this case you have to make a compromise. You can't stop SPAMMERS completely. If it's a bot, it should post a fixed text in a text box – it will fail and can't react the way it changes the SPAM text it's going to pass. When you have real human SPAMMERS, it becomes much harder to stop them, because they can react much different than a bot.

At the moment, the information in the error message is very general and doesn't contain too much detailed information. 

13 hours ago, Peter Knight said:

Is there a danger that by telling spammers or bots what content triggers the spam gate

Yes the danger is always there, especially with AI - so I guess I leave it general.

You can also change the error message to your own by asking the user to call you by phone if the message fails validation. Another option would be to set the threshold lower (e.g. from 50 to 30) so that more SPAM properties are accepted and the entered text is more likely to pass validation.

I don't know what the "best practice" scenario is in this case. Maybe someone has an idea how best to deal with messages that have been falsely declared as SPAM, even though they are not.