Submissions wrongly marked as spam - still having issues

[terryupton]

Describe the bug or issue you're experiencing I am still seeing many issues with genuine form submissions (with Stripe payments) getting marked as spam. This has increased over the past few weeks. I noticed this was also reported here https://github.com/solspace/craft-freeform/issues/674 but I am also on the latest version of 3.13.29

The client is getting increasing concerned as it causes additional work and issues. User not getting email confirmations for bookings, but more notably that often the Stripe payment doesn't go through, so they have to manual contact and speak to the users. However, this is not always the case and sometimes the payment does go through.

All submissions are marked as 'Honeypot check failed` on the spam reason.

I have just disabled the Javascript Enhancement and changed the Spam Protection Behaviour to 'Show As Errors' to see if this helps reduce the issues.

Client is on Craft 3 and will ultimately move to Craft 4 but likely October time, so ideally a solution for Craft 3 version would be much appreciated. As I have mentioned before, the payment facility is enough of a spam prevention tool IMO, so perhaps forms that have Stripe integrations could also bypass the spam settings, like that of a 'logged in user' Bypass All Spam Checks for Logged in Users setting on the spam settings.

Please let me know if you need any more information or any information in regards to Stripe.

Craft & Plugin Info (please complete the following information):

• Craft Version: Craft Pro 3.8.11
• Freeform Version: 3.13.29
• Freeform Edition: Pro

[terryupton]

Further to this in regards to the Stripe and Spam. When a submission is marked as Spam, the payment is not completed.

Instead it sits in Stripe as follows:

{
  "id": "pi_3NBEhzKbtiNy912D1B2QsCzZ",
  "object": "payment_intent",
  "last_payment_error": null,
  "livemode": true,
  "next_action": {
    "type": "use_stripe_sdk",
    "use_stripe_sdk": {
      "directory_server_encryption": {
        "algorithm": "RSA",
        "certificate": "-----BEGIN CERTIFICATE-----\nMIIFADCCAuigAwIBAgIIDzMLWm4xrKMwDQYJKoZIhvcNAQELBQAwejELMAkGA1UE\nBhMCVVMxEzARBgNVBAoTCk1hc3RlckNhcmQxKDAmBgNVBAsTH01hc3RlckNhcmQg\nSWRlbnRpdHkgQ2hlY2sgR2VuIDMxLDAqBgNVBAMTI1BSRCBNYXN0ZXJDYXJkIDNE\nUzIgQWNxdWlyZXIgU3ViIENBMB4XDTIxMDYxNjIwNDgyNloXDTI0MDYxNTIwNDgy\nNlowgaYxJjAkBgNVBAMMHTNkczIuZGlyZWN0b3J5Lm1hc3RlcmNhcmQuY29tMScw\nJQYDVQQLDB5zZGstZGV2aWNlaW5mby1lbmNyeXB0LWRlY3J5cHQxHTAbBgNVBAoM\nFE1hc3RlckNhcmQgV29ybGRXaWRlMRQwEgYDVQQHDAtTYWludCBMb3VpczERMA8G\nA1UECAwITWlzc291cmkxCzAJBgNVBAYTAlVTMIIBIjANBgkqhkiG9w0BAQEFAAOC\nAQ8AMIIBCgKCAQEAxhfEFuMQfwKcHwSm1rbHmT82eKSCmgpf+8QZwuIBCofl62Y5\nXDli5eOQeo5+iToJKKgEroMLrIjvvXDSp5MHu0mDmTChD4hiy9s4cAkJokBObgU9\nHorCOsjSwqNuFovO3jXMp4lgeCTFsF5iAJTZBPN0Nyg2mVZ4kjyAc/4V5oaKEmCg\nA+Kbi0UNum9n2wN/UYpNiZktk+lr0XrCoOs7KKxGQ2upI7Lr3pO0unIput0IcGQC\ncehQM4UYvd31x5u8harrun7c6H3jmpPoqEy3DqojvxR05B7zlkqUdbYGu579pCMR\nijXMyyRfrWEip44pEzJLz1kNCUcvPV8G3ltP3QIDAQABo10wWzAOBgNVHQ8BAf8E\nBAMCACgwCQYDVR0TBAIwADAdBgNVHQ4EFgQUPF7TGQqa5LaSVmu/3nSDvigAI4gw\nHwYDVR0jBBgwFoAUmpKiVMeAjf7OVuMDFP9e7ki4RbswDQYJKoZIhvcNAQELBQAD\nggIBAHoHWo3G9XEHGBc/L4JuW6ZZXvZmAThQb71WBxsvOMZOw/SDLO50ksG1y/Xt\nzCbpkM9PktiNx6+HDusJMhaop6jCkkKTJlG7TYxbN8sHpTI/G21nAgMBP5anePll\nO8Wcw/uMW9FzycyDMCryTVfriwxvLSeVcbB4N5x/wUBe54c+fVOBXw0Dczdw5/JE\nIcZs98O2rX+YQCaYMhxwJoil99ogIKEqFcHuSrqlpiXeaD8xC3gRewUyfr1roHNG\nr3KQWH3Kjdkk4TrXeAxdh0JfGJecHzm6oxekQOmm4jcxJoh84fRjCPsdq83r12Er\nLK2CuyXN0eTgz+VooM2lqU6YZorBAtLfVzckiCFFHek8kc2Jx7bTdreOO0vHQiwj\nNKdkVwge4hVDoVyp3rulBVFPTXduP0yGF/OYaUt84wz5I7Cjphw2d/MlZetXO0Bx\n7kXq+WRbgwrTi+aiL6TxOdONyrATODOP39rKLSpot4Jil4M4JeT9oy5g0JuTddwe\nFXmemcG1M0L2C6qGx79Hx8gpdEKRM4t6/vNia98kBFBFBHRwCr37hsiAmMeRRG2n\n7GtQFECJxVXkVbNXPjnPQkrY1fPFlTr9+CIKse2mtzG8nexhQUyIEvvuIDlNefmF\n+UrJ/C3zO2IlF0Um8Rk8L85gJNDMexmDx7Sx5aDj8zFC6hgI\n-----END CERTIFICATE-----\n",
        "directory_server_id": "A000000004",
        "key_id": "3c5ed3190a9ae4b692566bbfde7483be28002388",
        "root_certificate_authorities": [
          "-----BEGIN CERTIFICATE-----\nMIIFxzCCA6+gAwIBAgIQFsjyIuqhw80wNMjXU47lfjANBgkqhkiG9w0BAQsFADB8\nMQswCQYDVQQGEwJVUzETMBEGA1UEChMKTWFzdGVyQ2FyZDEoMCYGA1UECxMfTWFz\ndGVyQ2FyZCBJZGVudGl0eSBDaGVjayBHZW4gMzEuMCwGA1UEAxMlUFJEIE1hc3Rl\nckNhcmQgSWRlbnRpdHkgQ2hlY2sgUm9vdCBDQTAeFw0xNjA3MTQwNzI0MDBaFw0z\nMDA3MTUwODEwMDBaMHwxCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpNYXN0ZXJDYXJk\nMSgwJgYDVQQLEx9NYXN0ZXJDYXJkIElkZW50aXR5IENoZWNrIEdlbiAzMS4wLAYD\nVQQDEyVQUkQgTWFzdGVyQ2FyZCBJZGVudGl0eSBDaGVjayBSb290IENBMIICIjAN\nBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxZF3nCEiT8XFFaq+3BPT0cMDlWE7\n6IBsdx27w3hLxwVLog42UTasIgzmysTKpBc17HEZyNAqk9GrCHo0Oyk4JZuXHoW8\n0goZaR2sMnn49ytt7aGsE1PsfVup8gqAorfm3IFab2/CniJJNXaWPgn94+U/nsoa\nqTQ6j+6JBoIwnFklhbXHfKrqlkUZJCYaWbZRiQ7nkANYYM2Td3N87FmRanmDXj5B\nG6lc9o1clTC7UvRQmNIL9OdDDZ8qlqY2Fi0eztBnuo2DUS5tGdVy8SgqPM3E12ft\nk4EdlKyrWmBqFcYwGx4AcSJ88O3rQmRBMxtk0r5vhgr6hDCGq7FHK/hQFP9LhUO9\n1qxWEtMn76Sa7DPCLas+tfNRVwG12FBuEZFhdS/qKMdIYUE5Q6uwGTEvTzg2kmgJ\nT3sNa6dbhlYnYn9iIjTh0dPGgiXap1Bhi8B9aaPFcHEHSqW8nZUINcrwf5AUi+7D\n+q/AG5ItiBtQTCaaFm74gv51yutzwgKnH9Q+x3mtuK/uwlLCslj9DeXgOzMWFxFg\nuuwLGX39ktDnetxNw3PLabjHkDlGDIfx0MCQakM74sTcuW8ICiHvNA7fxXCnbtjs\ny7at/yXYwAd+IDS51MA/g3OYVN4M+0pG843Re6Z53oODp0Ymugx0FNO1NxT3HO1h\nd7dXyjAV/tN/GGcCAwEAAaNFMEMwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI\nMAYBAf8CAQEwHQYDVR0OBBYEFNSlUaqS2hGLFMT/EXrhHeEx+UqxMA0GCSqGSIb3\nDQEBCwUAA4ICAQBLqIYorrtVz56F6WOoLX9CcRjSFim7gO873a3p7+62I6joXMsM\nr0nd9nRPcEwduEloZXwFgErVUQWaUZWNpue0mGvU7BUAgV9Tu0J0yA+9srizVoMv\nx+o4zTJ3Vu5p5aTf1aYoH1xYVo5ooFgl/hI/EXD2lo/xOUfPKXBY7twfiqOziQmT\nGBuqPRq8h3dQRlXYxX/rzGf80SecIT6wo9KavDkjOmJWGzzHsn6Ryo6MEClMaPn0\nte87ukNN740AdPhTvNeZdWlwyqWAJpsv24caEckjSpgpoIZOjc7PAcEVQOWFSxUe\nsMk4Jz5bVZa/ABjzcp+rsq1QLSJ5quqHwWFTewChwpw5gpw+E5SpKY6FIHPlTdl+\nqHThvN8lsKNAQg0qTdEbIFZCUQC0Cl3Ti3q/cXv8tguLJNWvdGzB600Y32QHclMp\neyabT4/QeOesqpx6Da70J2KvLT1j6Ch2BsKSzeVLahrjnoPrdgiIYYBOgeA3T8SE\n1pgagt56R7nIkRQbtesoRKi+NfC7pPb/G1VUsj/cREAHH1i1UKa0aCsIiANfEdQN\n5Ok6wtFJJhp3apAvnVkrZDfOG5we9bYzvGoI7SUnleURBJ+N3ihjARfL4hDeeRHh\nYyLkM3kEyEkrJBL5r0GDjicxM+aFcR2fCBAkv3grT5kz4kLcvsmHX+9DBw==\n-----END CERTIFICATE-----\n"
        ]
      },
      "directory_server_name": "mastercard",
      "merchant": "acct_1GuMccKbtiNy912D",
      "one_click_authn": null,
      "server_transaction_id": "833293cf-08cb-4337-b4e3-dbaf45fda19e",
      "three_d_secure_2_source": "payatt_3NBEhzKbtiNy912D1hjasNPC",
      "three_ds_method_url": "https://www.securesuite.co.uk/hbos/threeDSMethod/3ds2/",
      "three_ds_optimizations": "kf",
      "type": "stripe_3ds2_fingerprint"
    }
  },
  "status": "requires_action",
  "amount": 7000,
  "amount_capturable": 0,
  "amount_details": {
    "tip": {
    }
  },
  "amount_received": 0,
  "application": null,
  "application_fee_amount": null,
  "automatic_payment_methods": null,
  "canceled_at": null,
  "cancellation_reason": null,
  "capture_method": "automatic",
  "charges": {
    "object": "list",
    "data": [
    ],
    "has_more": false,
    "total_count": 0,
    "url": "/v1/charges?payment_intent=pi_3NBEhzKbtiNy912D1B2QsCzZ"
  },
  "client_secret": "pi_3NBEhzKbtiNy912D1B2QsCzZ_secret_pkST7FbdMh8SgcF5FF8eGE2Iq",
  "confirmation_method": "manual",
  "created": 1684923259,
  "currency": "gbp",
  "customer": "cus_Nx8zCdHJ0nWhyc",
  "description": null,
  "invoice": null,
  "latest_charge": null,
  "metadata": {
  },
  "on_behalf_of": null,
  "payment_method": "pm_1NBEhuKbtiNy912DCb2mXcKa",
  "payment_method_options": {
    "card": {
      "installments": null,
      "mandate_options": null,
      "network": null,
      "request_three_d_secure": "automatic"
    }
  },
  "payment_method_types": [
    "card"
  ],
  "processing": null,
  "receipt_email": "rahulg16@gmail.com",
  "review": null,
  "setup_future_usage": null,
  "shipping": null,
  "source": null,
  "statement_descriptor": null,
  "statement_descriptor_suffix": null,
  "transfer_data": null,
  "transfer_group": null
}

On the Freeform Dashboard, I see the following errors:

Then on the submission:

[chadcrowell]

I am having issues as well with real submissions being marked as spam for the last few weeks. In fact, every submission is getting marked as spam on a site with about a dozen forms that have been in use since 2021. I updated Freeform from version 3.13.28 to 3.13.29 on 5/16, which happens to be the date that the issue began. I do have honeypot on, with the JS enhancement, and do use Blitz, but use an exploded dynamic folder as instructed in the docs, this has been working fine since 2021. My Form Session Context is set to Encrypted Payload.

[kjmartens]

Hi @terryupton and @chadcrowell,

I'm very sorry for the trouble you're experiencing with Freeform 3.13.29. I'm wondering if you have additionally included the payload when rendering the cached form (see examples in docs link below): https://docs.solspace.com/craft/freeform/v3/templating/caching/

{% set form = craft.freeform.form(craft.app.request.get('form')) %}
{{ {
    hash: form.hash,
    honeypot: craft.freeform.honeypot(form),
    payload: form.payload,
    csrf: {
        name: craft.app.config.general.csrfTokenName,
        value: craft.app.request.csrfToken,
    }
}|json_encode|raw }}

And in the JS:

// Update the Payload if encrypted payloads are enabled
form.querySelector('input[name=freeform_payload]').value = response.payload;

[terryupton]

Hey @kjmartens i am not doing any caching at all.

[chadcrowell]

Yes, I had included the updated code in that snippet with the payload var. I downgraded to 3.13.28 and forms are flowing again.

[terryupton]

A further update from myself. Since setting the Javascript Enhancement to false, the client has seen a massive amount of real spam been accepted and passed through to them. Naturally, this means no bookings have gone into spam, but this has a complete reversed and adversed effect and thus I can't leave the Javascript Enhancement off if this is the case.

For now, I have kept the the Javascript Enhancement to off (false). I have just added Google Captcha V3 to help assist with the spam issues. I don't want to downgraded to 3.13.28 yet, but this would be my next step. However, even prior to this version we did see some genuine bookings ending up in spam, but it certainly didn't seem as common.

It would be great if we could get this fixed ASAP. It would also be great to get that new feature setting to disable spam on certain forms enabled as I think this would hlpe with my booking forms.

Hoping you can find a solution @kjmartens

Thank you.

[kjmartens]

Thanks for the feedback, @chadcrowell and @terryupton.

We know that 3.13.29 resolved issues for several others that were reporting issues with false spam. I'm not sure why it's made the issue worse for others. We will investigate this issue further and see what might be happening. Thanks for your patience.

In the meantime, can you both provide a screenshot of the Diagnostics page and let me know anything else important about your setups? I'm also curious if you might be able to install the demo templates and see if your forms work without issue there. This info will help us track down the issue quicker. 🙂

[terryupton]

Hey @kjmartens - sorry, what do you mean by the Diagnostics page? Happy to send over a screenshot or details, but not sure what you are asking for.

I afraid I wouldn't be able to use the demo templates on the site, for several reasons. Happy to speak in more detail though if it helps at all. Discord or any other way.

[kjmartens]

@terryupton I am referring to this page: 🙂 https://docs.solspace.com/craft/freeform/v4/reliability/diagnostics/

If you can't install the demo templates, would you be able to create a new template with the following:

<html>
<head></head>
<body>
    {{ craft.freeform.form("myFormHandle", {
        formattingTemplate: 'flexbox.html'
    }).render() }}
</body>
</html>

[terryupton]

@kjmartens please find screenshot below.

In regards to the code to provided, I cannot see how this will help in our situation? Could you elaborate on your thinking behind this? Thanks :-)

[kjmartens]

@terryupton The Diagnostics feature was added to the control panel in Freeform 3.12+: https://docs.solspace.com/craft/freeform/v3/reliability/diagnostics/

You can access it by going to: Freeform -> Settings -> Diagnostics (at bottom)

As for the demo templates (or at least that basic new template test), it usually helps us narrow down whether the issue might be simply related to a formatting template/parent template issue, caching issue, server rewrite issue, etc. If the issue continues to happen there, it's likely not one of those issues. 🙂

[kjmartens]

Thanks for that @terryupton. What is your Submission Throttling setting set to?

[terryupton]

@terryupton The Diagnostics feature was added to the control panel in Freeform 3.12+: https://docs.solspace.com/craft/freeform/v3/reliability/diagnostics/

You can access it by going to: Freeform -> Settings -> Diagnostics (at bottom)

As for the demo templates (or at least that basic new template test), it usually helps us narrow down whether the issue might be simply related to a formatting template/parent template issue, caching issue, server rewrite issue, etc. If the issue continues to happen there, it's likely not one of those issues. 🙂

Sorry I found it. The link was/is hidden in production environment. I had to access it via a direct url. This might be worth a fix too ;-)

In regards to the form/template, as we won't be driving traffic through it and it doesn't replicate the fact I have stripe payment forms etc and the fact not ALL submissions were marked as spam but only some and randomly, but it had increased much more recently. I don't see the value in adding. Sorry. Or were you hoping to use the form to test with? It seemed much more likely down to the JS honeypot or potential expiration of this. That was my gut instinct as to why it was failing.

Thanks.

[terryupton]

Thanks for that @terryupton. What is your Submission Throttling setting set to?

Initially when I raised the issue, it wasn't set. Since the increase in genuine spam getting through since my changes on Wednesday. Today I added a captcha v3 and set throttling to 2 per minute.
The captcha v3 is only used on the simple enquiry forms and this was only added today to help with the influx of real spam. It has solved it for now.

[kjmartens]

@terryupton Thank you. 🙂

The throttling feature is intended for extreme conditions, such as preventing your site from going down if attacked by a spammer. It should NOT be used as a 'fine-tuning' spam measure, as it applies to ALL users. For example, if you set it to '1 per minute', once one user submits any form, any other user will not be able to submit a form within that timeframe. A more realistic value for smaller websites is something like 50 per minute. Use extreme caution for larger and more active sites.

Attempting to use it as a 'fine-tuning' spam prevention measure is more likely to result in falsely flagged spam submissions.

As for handling the spam itself, we do strongly recommend the use of a captcha service like reCAPTCHA or hCaptcha, as the Honeypot and JS Honeypot features are fairly limited and much easier to get around.

We will still investigate why this recent change has specifically affected some customers, though. 🙂

[terryupton]

Thanks @kjmartens I wasn't using the throttling feature to 'fine-tune' the spam settings. It was to try and prevent the onslaught of genuine spam coming into the customer and submissions section for the enquiry form. This only happened after disabling the JS Enhancement setting. It did solve the issue of the bookings and registrations getting marked as spam, but it did then allow loads of spam through.

As you can see from these screenshots.

Adding the captcha V3 has resolved it. Should I therefor remove the throttling?

Thanks.

[kjmartens]

2 forms a minute seemed reasonable for a normal human, they shouldn't be putting through more than 2 submissions per minute!!? In particular for booking course and registering etc.

Yes, 2 per minute per user is reasonable, but this feature applies across all users. For example, if you set it to 1 per minute, once one user submits any form, any other user will not be able to submit a form within that timeframe. In the case of you setting it to 2 per minute as well as receiving heavy spam, it's entirely possible a spammer could "use up" those 2 allowed in the minute so a regular user wouldn't be able to (and have theirs flagged as spam). I am updating the CP to include a warning that explains this more clearly, as I can see how it can be a bit confusing. 🙂

[terryupton]

2 forms a minute seemed reasonable for a normal human, they shouldn't be putting through more than 2 submissions per minute!!? In particular for booking course and registering etc.

Yes, 2 per minute per user is reasonable, but this feature applies across all users. For example, if you set it to 1 per minute, once one user submits any form, any other user will not be able to submit a form within that timeframe. In the case of you setting it to 2 per minute as well as receiving heavy spam, it's entirely possible a spammer could "use up" those 2 allowed in the minute so a regular user wouldn't be able to (and have theirs flagged as spam). I am updating the CP to include a warning that explains this more clearly, as I can see how it can be a bit confusing. 🙂

Thanks Kelsey. That makes sense. It was my fault for not reading your message or the setting message properly and I was assuming it was a per user basis. I have set this to 50 for now and see how this goes, but with the capture now working, I might be able to remove this setting once again.

Thanks for your support and response so far. :-)

[kjmartens]

Happy to help, @terryupton.

I'm glad your site is seeing relief from spam now. Just to be clear (since I believe there are a couple of other issues fragmented around here), can you let me know the status of other issues you're experiencing?

I know you mentioned the issue with falsely (?) flagged Stripe submissions in the spam folder, as well as Stripe not showing them completed. I tested this on my end and I can't seem to replicate the issue. Maybe there's more to it, though. 🙂

[terryupton]

@kjmartens I think it all stems from the same issue of them being marked as spam incorrectly.

If the submission gets marked as spam (for whatever reason, but always showed as failing the honeypot test), then the payment is not processed by stripe (and those Stripe errors show on the dashboard).

Upon moving this out of spam, we get that internal server error issue: https://github.com/solspace/craft-freeform/issues/666 And I believe the above error repeats.

What I believed was happening was that when it was marked as spam by Freeform, it wasn't completing the Stripe payment or hook.

To a degree, the changes I have now made to ensure these are not marked as spam, have also solved this issue. However, the outcome of those changes could be reverted if we re-enable the JS Enhancement for Hoenypot.

What I was partially alluding to as a possible solution/option, was if there was a payment form involved in form, it could always bypass the spam stuff, like it does if you are logged in as a user. I feel the values and fact payment is required is potentially prevention enough from genuine spam and this would then ensure these booking/registration submissions never get marked and thus break the flow (payment and emails).

I hope this offers some clarity.

Thanks.

[kjmartens]

Thanks @terryupton. It's been noted.

[alexr8]

I've got this issue, all submissions are ending up in spam, even after updating to the latest version for Freeform (4.1.0). I've not amended any settings as far as i can remember, all pretty standard with js enhancement + honeypot enabled. in my local dev i'm not caching anything.

[alexr8]

a bit more digging - actually appears to only be one of my forms, which just has a single email input field and a submit button (and a connection to campaign monitor) - could this be why it gets marked as spam? if i turn off honeypot/enhanced js it submits just fine.

[kjmartens]

Sorry for the delay @alexr8.

Are you able to provide any additional information about your setup? Perhaps a screenshot of the Diagnostics page and what your template code looks like, etc. 🙂

[chadcrowell]

@kjmartens for the record, on this site, I have upgraded from 3.13.28 to .29, .30, .31, and .32 when those releases have been released, and with each version, this spam issue comes back. I just this morning, again reverted to 3.13.28 to get emails flowing again on my client's site. I think I am locked to 3.13.28 to keep this issue from happening in the future.