Spam getting through

[counterpoint]

I'm getting quite a lot of items posted that have reports at stopforumspam. Sometimes long lists going back months, e.g. 117.169.1.158.

Could this be an issue of too tight a timeout? Or something else?

Anything that can be done to fix it?

[sparticus1701]

I have not seen any similar issues; the API calls are synchronous and very quick, so I don't think there is a timeout to worry about.
What I have seen is users who will register via a non-blocked IP, and then post from a blocked IP. To aid in finding those, I hacked the Q2A code to report the creation IP. I block those IPs which have spam coming from them, as well as the creation IP. I have also set moderation on users without enough points which equates to their first posting, which keeps spam from making it to the board. Finally I switched the captcha since ReCaptcha is easily broken these days. With all that in concert I get about 1 or two a week these days.

[counterpoint]

I've written similar code for other environments, but didn't really want to get into coding for this application :) Are you saying that the plugin does not check the IP address for each post? Only the registration IP address? I detest ReCaptcha as a user, so don't wish to inflict them on others - especially as they can, as you say, be broken. I've got moderation set as you describe, but it's tiresome clearing up the mess - I got about 50 spam postings last night.

[sparticus1701]

All the plugin is designed to do is reject users who register from an IP identified as a spammer. Otherwise all it does is give you an indication of whether it came from a spammer. It does not reject posts.

I edited the Q2A code because we were seeing spammers register, but we didn't know from where since they should have been rejected. We found they were registering from IPs not on the spam list, and then doing their activity from a known spam IP.

Because of ReCaptcha's weakness, we switched to AntiBot Captcha for unregistered users and registered users without reputation. Some bots get through, but the majority are coded to ReCaptcha and don't know how to deal with this one. It would be a nice world to live in if we didn't have to use captchas, but for the time being it is the best defense. The consolation is that users who register and make a legitimate post don't have to do it thereafter.

[counterpoint]

Well, I'd have a manageable problem without any captcha if I could simply reject posts that come from known bad IPs. Is it possible, in principle, to do that with a Q2A plugin?

[sparticus1701]

I agree that would be useful; we wrote this plugin to accommodate the need we had at the time, and didn't design it for broader use.

I don't know if the Q2A framework has the appropriate hooks to implement this. You would have to look through their documentation.

Unfortunately this is not a priority for us right now so we won't be looking at implementing this feature in the forseeable future. You are welcome to use the code as a starting point in customizing your own plugin.

[counterpoint]

Seems to be more to it than that. Today, I've got a spam posting. A DB query of "SELECT userid, created, INET_NTOA(createip), handle, INET_NTOA(writeip) FROM qa_users WHERE handle = 'LenHeckel'" yields:
47552 2014-12-02 08:16:15 193.124.18.129 LenHeckel 188.120.238.125
The create IP has a string of entries at stopforumspam going back to May 2014, although the account was created a few hours ago, and the spam posted a few minutes ago.

[sparticus1701]

We have not seen similar issues. You will have to discover why it is having problems for you.

[counterpoint]

Does a test bed exist for plugins? It doesn't seem altogether straightforward creating the environment.

[counterpoint]

OK, resolved. This seems to work:

<?php

define('QA_BASE_DIR', '/var/www/tcouncil/public_html/qatest/');

echo "About to import initial code\n";
require ('/var/www/tcouncil/public_html/qatest/qa-include/qa-base.php');

echo "About to import plugin code\n";
require ('spammer-check-event.php');
echo "Create object\n";
$checker = new spammer_check_event();

echo "Set up parameters\n";
$params['email'] = '[email protected]';
$event = 'u_register';

echo "Run check\n";
$checker->process_event ($event, 47473, null, null, $params);

[AnthonyVO]

I made an update that will allow for logging using the EventLogger in QA. This should make it easier to see what is happening.
https://github.com/AnthonyVO/Q2A-Spammer-Checker