I’ve followed the directions detailed above and it has helped stop spam to a point.
I now see someone has figured out how to utilise the send mail function to bypass the honey pot trap!
Looks like the form is being submitted directly e.g.;
dmxConnect/api/Categories/RequestInfo.php
Is there a way to stop this or hide the send function pages so they can only be run from the actual request page?
CK
Of course! You need to put the recaptcha as a first step in your server action to prevent this!
as you can from above people don’t like recaptcha, is there not a way to prevent robots directly accessing these function files?
Well at least apply serverside validation to your POST vars 
for example, apply required validation to the inputs that are required.
I already have several required form fields, this Russian robot is simply filling out all the required fields which it finds in the dmxConnect/api file.
Add a form field that contains the time taken to fill in the form. On the server, determine if that time is too short to enable a human to fill in the form. If so, reject the submission.
Also, @patrick’s solution is an important one.
Thanks @ben, thats a clever idea but I think everyone has missed the point, its not the page that has the form which is the problem its the dmxConnect/api connection/send file which is being used directly.
I did have once a function file which checked that the information coming from the form was local and not some spammer but the dmxConnect/api connection/send file does not seem to have this.
What do you see in your browser when you run your: dmxConnect/api/Categories/RequestInfo.php directly from the “open in browser” button in Server Connect?
// 20220802085154
// https://domain.com/dmxConnect/api/Categories/RequestInfo.php
{
“form”: {
“name”: “This field is required.”,
“company”: “This field is required.”,
“email”: “This field is required.”,
“country”: “This field is required.”
}
}
We had 1300 junk emails in today, all Russian spam!
On mail send function I have various dynamic data that gets send in the email, things like ref. no. and url link to machine, in the spam all these are missing which tells me the spammer never used the actual request page but the api function instead.
So have you implemented this? Do you have such a condition in the server action, checking if the session created on page load is the same as the one in the input on the page (and if it even exists)?
It’s not spam, it’s a special email delivery operation.
Call it what you like but its not very pleasant!
No, but you can check if it’s not empty and then compare it to the session
{{$_POST.nospam != '' && $_POST.nospam == $_SESSION.nospam}}
Not sure i understand what you mean and what do you show with this screenshot.
I asked you to just change the condition in your server action, not to add any validations to the form:
Off Topic: “ie” after “c”. In other words, the word is spelt receive.
