Review and fix antispam measures targeting unconfirmed users

Put a cap on the waiting period that unconfirmed users must suffer (IMHO, 600 seconds - 10 minutes - should be sufficient).

There actually already is an effective cap, but the UI doesn’t show it. I opened #2993892: Do not report more waiting time than the expire time to help with this, but drupalorg_honeypot’s additional time will need a fix too.

Put a cap on the waiting period that unconfirmed users must suffer (IMHO, 600 seconds - 10 minutes - should be sufficient).

Our custom code that adds extra penalties for spammy characters and phrases was also effectively capped by the honeypot expiration configuration. This is now correctly reported to the user too.

I’ve also reduced the drupalorg_honeypot_factor multiplier to ramp up time limits more slowly. If we see spam coming in more-quickly, we may need to adjust this back up.

Replace the phrase "There was a problem with your form submission" with something that explains what the problem is. My suggestion: "As an unconfirmed user on Drupal.org, you are not allowed to post too frequently".

This message comes from the honeypot module and would be cumbersome to override. We do have our own message in addition to honeypot’s, which I’ve updated to be more accurate 4a27af0. (We do not currently have anything which automatically grants the confirmed role.) I also found that it might not be displayed alongside Honeypot’s messaging, which is now fixed.

Improve the algorithm that unpublishes assumed "spam" to reduce false positives.

That algorithm is actually Akismet, which is now fulfilling the role Mollom had. Unlike Mollom, Akismet does not have an “unsure” classification or other way to adjust the sensitivity. All we can really do is make the trade-off of either treating their “spam” classification as spam, or not. We did have this misconfigured on some forms for some time, and saw plenty of spam. (They also have a “pervasive spam” classification https://blog.akismet.com/2014/04/23/theres-a-ninja-in-your-akismet/ which we always had enabled while the service was active.)

Thanks for following up on these examples @gisle.

Our republish process should be reporting false positives back to Akismet's algorithm the same way that our mark as spam option reports those patterns to their algorithm.

We may want to contact them directly about some examples to see what they can tune - unfortunately we don't get many tuning options with this service.

Unfortunately this is all a balance between how much spam is blocked, how much gets through, and how many false positives result in real users being blocked. There'll always be a few - but we should make sure they know they can always email support for manual review.