To the moderators of this forum: Feel welcome to drop this post, if you feel it necessary. While the response is discussing something I am developing it is not intended as Spam (a concept I hate).
To Umbra: If you are asking about the Spam blocking, it as such do not really care where they come from. VPN, server farms, home networks..., No matter.
The plugin checks blog comment spam (and in a future plugin forum site posts) against my API service/algorithm, and it does not really care. The algorithm I am developing do not really distinguish. In various proportions, it uses information from the spam itself, the links submitted, the IP origination, the proxies used, the combined knowledge from my DNSBLs gathered from various traps and honeypot type setups I have, the posters (whether robotic postings or people in India paid to post manually), site owner opinions, and other information. One factor is learning from the blog administrators. If some new Spam is not recognized it will stay in the WordPress moderation queue showing its history as undetermined, and if the admin then Spam manually, the algorithm learns from that for any future Spams (on that site or others). Similar for potential false positives. When an admin Unspams, it learns from that. If a Spam stays in the moderation queue as not recognized (with no admin intervention), it will be re-checked later automatically, as it might suddenly be recognized/categorized then and flipped either way.
The intent is multiple.
a) let spammers dig their own holes (read: graves). The more Spam they try to post (across sites), the worse off they get and the more money and effort they have to spend on buying new domains, finding new proxies, ... Assuming of course that the same spam-blocker is used across the sites. The Slime essentially sticks to everything they involve in its submission, rather than sticking to your site. (At least that is my plan. :))
The worse they behave, the higher their Slime score gets. I watch a lot of them in Beta runs right now, and they keep buying new domains with slightly different names (advertising the same products or phishing sites), changing proxies, changing format, ... Even changing the bots they use. But rarely do the Slimers manage to make themselves unrecognizable when all factors are taken into account together. Plus, the effectiveness of these evasion actions is limited, as the new factors quickly get tainted as well.
b) Stop annoying site users with CAPTCHA type fronts, lengthy manual moderation queuing, ... Good posters automatically build good karma (across sites) and can move more freely, bad posters build bad karma (across sites) and get stomped.
c) Limit site admins from wasting time with manual Spam intervention. When running correctly, washing away Slime should be automatic. In my current tests, I have only had one piece of Spam be undetermined across sites and stay in the moderation queue. And it was subsequently auto-spammed on the automatic recheck.
Since I also track other types of offenders, hacking, info trackers, mark scanners, ... around 50 types in total, the same plugin also has a security type front. Blocking certain URL patterns (SQL Injections, PHP injections, ...), and the blog owner can select which levels/types of DNSBL types to block out IPs by as well. Default, known hacker types are blocked out (known SSH, PHP, mysql, ppmyadmin, ..), but the admin can also select to block out known mark scanners, info trackers, known bad content scrapers, ..., ... The site admin can choose to report these catches back to the API (the default setting), so essentially the site can help build future blocks across the net. I have some other stuff in the plans as well.
Essentially to save some server/network bandwidth from the thousands out there that think they should be tracking and lifting our sites (one of my pet peeves). The more we block them, the more we dilute the values of the databases they sell.
When caught, they will see only either a code 403: Permission denied, or a 418: I am a Teapot (as in they violated the coffee pot protocol, which I am in love with right now :) )).
I see it as Crud and Slime. Crud: Security/scanner issues, Slime: The unwanted Spam that clings and sticks to us all.)
The same service will also tracks certain known email-spam, so if they use email spam as promotions as well, it will taint and block up their blog spam in a combined effort.
I am finishing up the generics and the Wordpress specific code right now. Later I'll start a phpBB plugin, I think.
BTW.. I have it running in test across some sites right now, but they are all similarly configured, since I control them. Before I let the Wordpress plugin out in the wild (as in upload to the Wordpress.org plugin site), I would like to have some other test sites install it. So if anyone is interested in the final Beta test or maybe just in more information, please drop me a note.
