Excuse me???

I did not ask you to fix anything.

I am telling you that your software blocks perfectly good users. This makes you upset? Facts hurt your feelings?

You should accept the fact that all rule-based filters that are created by an untrusted community are inaccurate.

Or, I guess the only posts that are acceptable are "We Love You So Much Posts"?

You cannot accept a bit of facts without flying off the handle?

Wrong.

Blocking professional, legitimate users is called a FALSE POSITIVE.

The software is not perfect and stop trying to make it out to be.

Anyone can place an entry in the dB and that does not make it perfect. Also, anyone can spoof your IP and spam 1000 people then your IP will be in the spammer database as well.

The fact is that the StopForumSpam DB blocks many perfectly legit professionals. We have seen this a number of times.

For God's sake, Pedigree. PLEASE block imported_silkroad or send him to coventry and lets move on. I installed VSFS a week ago. It has correctly blocked hundreds of bot registration attempts and so far I've not seen a single false positive. IMHO, the only thing this guy has proved is he's a flamer and spammer of a different sort.

For some reason, he has an axe to grind. Let's ignore him and move on. While I'll grant your code may not be perfect, it's WAY the hell ahead of whatever is in second place and you're doing what you can to fix it. It's obvious you're not going to perfect it by arguing with imported_silkroad. That's for dang sure.

After all, as he's said several time he's spoken directly to the Lord GOD Almighty who we all now know works at Sun! Arguing with him makes as much sense as arguing with Pat Robertson over whether or not the Haiti quake was Divine Retribution... :p

To HELL with Robertson and imported_silkroad too. Let's spit in their eye and go dig some innocent victims out of the rubble instead. The God I worship would approve of that! :)

My 2 cents worth: Ignore the comments from the peanut gallery!

Oh, I see... Of COURSE you can't block him. This is the vb.org site and they don't let you do that. Duuuhh! It's early here and I'm still working on my first cup of coffee. Sorry. As an alternative, I've decided to ignore future posts from this guy and move on.

It WILL help a LOT. Trust me. It will! :D

pedigree...

I absolutely LOVE this mod! I've had it installed for quite some time now...and it does exactly what it's supposed to do. Thank you very much!

As for those other negative posts...I would have done exactly what you have done...ignore them. It's just someone looking to get a rise out of you. No need to feed the trolls...know what I mean?

By the way...funny how your mod is to blame for blocking legitimate "professionals". I was under the impression it's not your database...but StopForumSpam's database. Shouldn't this guy be complaining to them? Duh!

There's one no matter where ya go...if not, they come looking for ya!

Great work, pedigree...keep on keepin' on!

Hurray! Good for you, Pedigree. Me too.

Locking out one potential legitimate forum user (a false positive) from a company like Sun Microsystems (or any good company) is not worth the benefit of the few spam posts that occasionally make it past a captcha or random question anti-spam measure.

Our forums (obviously it seems) value members and users more than those here demonizing our concerns, which we voiced here as an FYI only. Weaknesses in user generated rule-based lists are well established. Here is a statement from the user who was locked out by this software and the DB:

Pedigree and others can demonize me (and others) for telling the truth, if it makes them feel good. However, as for us, we value our users much more than folks here, anti-spam at any cost zealots, seem to.

As I said, we have disabled IP checking in this mod and may disable the entire mod if we see more false positive complaints from our user base. We don't need a mod that locks out legitimate users via a polluted database generated.

My apologies if the developer's feelings are so fragile that he cannot deal with the fact that this mod and the DB is guilty of false positives and locking out valid forum members.

The truth is obvious and there is no reason for emotional argument and debates on this topic.

I will never understand why technical people become so in love with a technology that they will demonize anyone who does not stand up and shout "how much they love it".

This mod is useful, but it is far from a perfect system.

Oh yes it is! Seriously if sun are going to use spammy ips then it shouldn't surprise them when they get blocked from sites online. I doubt the ip is only in one database either.

Why are you even looking at this mod if you only occasionally get spammers anyway?

INSTALLED on mousepad.mouseplanet.com along with the "Submit" plugin.

Thanks!

Oh I wish I had read your forum before going to Disneyland in LA.

It seems that you completely missed (or ignored) post #875 in this thread, where someone else took the time to research the IP in question. Post #875's author not only provided proof of spamming by that IP going back to January 18, 2010, but they also gave you the Google link so that you could see it for yourself.

Therefore, the listing for that IP in the Stop Forum Spam database is a legitimate entry. Your concerns should be taken to Stop Forum Spam, not hashed with the author of this add-on.

Also, the add-on has the capability to allow or deny registration based on whether the registering person/bot is listed in the database:

If "check database for username" is selected:
Username found in database: allow or deny registration?

If "check database for email address" is selected:
Email address found in database: allow or deny registraton?

If "check database for IP address" is selected:
IP address found in database: allow or deny registration?

Pedigree specifically wrote these options so that you could configure this add-on to settings that matter to you. If you don't want to check IP, then don't check it. Same with username or email address. It's not Pedigree's fault that you selected options that were later found to be restricting registrations to your forum.

(And personally, if someone told me they were using their employer's "internal server" to access the Internet, I'd smell a fish. Isn't the whole point of an internal server to keep it isolated from the external Internet? How did a server that is isolated from the external Internet manage to reach your forum? :confused:

All this person had to do was register from their home IP, this would get them around the Sun IP ban, and then they could use your forum from work. Unless they're a spammer who's using the Sun IP as a relay -- in which case, the database worked as intended, wouldn't you agree?)

While I don't use this mod (I coded my own), I do use the stopforumspam website and have been extremely pleased with its results.

I'm actually able to catch 99.9% of the bots before I even check the SFS website. I'm not going to post exactly how because then a spammer might decide to fix their code. However I *do* double-check with the SFS website.

If a certain threshold of matches exist, the user gets auto-banned. If only one or two things match, then they go to the coppa/moderation group. In which case I look over the account manually and see what hit and make a determination from there...

I don't know why someone is whining about a SUN IP address... Is it not beyond possibility that a user's computer there has been compromised? When I worked for Verizon, there were people there that should have never been allowed to touch a computer. They would get them infected with all sorts of crap on a weekly basis (and the IT people would be cussing and swearing as they would walk down the halls)...

I often get hack attemps and port scanning from Amazon IPs... Is Amazon doing it? No... But people paying for their cloud computing services is...

*sigh*

Ra (aka Silkroad, aka the Sun god) got an irate email from one potential member. So what? If your time is SO bloody valuable that you can't deal with a blocked user, why are you out here arguing whether or not this mod, and the associated database, works properly? Can't you get it through your head that an IP being used to attack our board is a BAD THING? If it wasn't for the fact that this mod did work, I wouldn't have the spare time to be out here making comments.

If I was getting spammed from an IP address, I wouldn't care if it was Sun, the White House, or Bill Gates himself, that IP would get blacklisted. I've been running this mod for about two years now and have never had a single legitimate user blocked. More than 95% of the attempts to register on my board are spammers. I have a real job and don't have time to deal with that mess. This mod has made it possible for me to do both.

Is this mod perfect? No...I know of NO software that is perfect. I would dare say that most of us do not run boards for a living. The way you talk, it's important enough for you that you're concerned, and I'd guess that you're being paid to deal with it.

It doesn't work for you? You claim to be some kind of expert...what it the solution, then? You MUST have a viable solution! If you're not part of the solution, as they say, you're part of the problem.

Silkroad, you're mentioning "professional" and "Sun Microsystems" in every post... I'd hate to point it out but it may work the exact opposite on us mere mortals after a couple of times. Putting so much emphasis on it makes it sound like you're actually the janitor ;)

Anyway, standard practice for "professionals" (just as with mailserver blacklisting): contact the server owner, let them know their machine has been blacklisted and may have been compromised. *They* can -and have to if they want it to operate normally- deal directly with stopforumspam.com about their machine being blacklisted. And in your case it seems that thing really has been compromised, if it were mine I'd really appreciate someone telling me.
Complaining about either the forum that runs the mod, or the mod that queries the database, doesn't do anyone any good :)

Love, love, love, this mod. Installed a few weeks ago and it does a great job. Much thanks to the developer.

Is the http://www.stopforumspam.com/ website down for anyone else? I can't connect via web browser, ping, reverse lookup, nothing! :(

It's coming up normally for me.

Me it's giving me : [REMOTEERR] Unverfied and rejected by policy

and rejecting ALL my "normal" registrations... is their server down?

Great mod. Just installed it this morning and it's working already!

It wasnt down but GoDaddy (who, in my opinion are the internets biggest joke) decided to drop all the DNS for our domain and restarted returning NXDOMAIN for all queries (thats Non-existent Domain)

Its not the first time they decided to randomly screw with us and we are going to move the domain reg off NoDaddy to some company that isnt sh*t (in my opinion)

You might want to change the policy to log and accept on connection errors.

Errors still occurring even after the DNS update.
Users attempted to register receive this:
"Registration denied. We check new registrations against a database of known forum spammers. At this time, we are unable to contact this database to verify your registration. We are sorry for the inconvenience but please do try again later."

Maybe your servers dns server is caching a nxdomain result. try this

<?php
var_dump(@gethostbyname ('www.stopforumspam.com'));
?>

Upload that to your server and post back what results it gives

Sorry for the question, where do we put that? vbstopforumspam.php?

create a new file called anything, like testsfs.php, and upload it and then load it in your browser. It reports back the status of your servers DNS resolution.

OK, thanks!

I'll report back with results.

Results:

string(21) "www.stopforumspam.com"

Still getting: [REMOTEERR] Unverfied but allowed by policy

that's odd, it should have returned something like:

That shows that DNS isnt resolving. Try this one, which might or might not work as some hosts dont allow exec()

<?php


exec('TERM=xterm nslookup www.stopforumspam.com', $dig, $error );
echo nl2br(implode("\n",$dig));
if ($error){
exec('TERM=xterm nslookup www.stopforumspam.com 2>&1', $error );
echo "Error: ";
exit($error[0]);
}


exec('TERM=xterm dig www.stopforumspam.com', $dig, $error );
echo nl2br(implode("\n",$dig));
if ($error){
exec('TERM=xterm dig www.stopforumspam.com 2>&1', $error );
echo "Error: ";
exit($error[0]);
}
?>

Get this:

ok, your webserver is hosted at iWeb. The server is failing to resolve the IP to the domain. There really isnt anything that you can do to hurry it up other than to ring them and give them a "oh, DNS isnt working"

Sorry :(

Most DNS can take up to 24 hours to propagate, depending on the DNS servers configurations.

I sure will ring them up!

Thanks!

great mod pedigree, certainly stopped all the ahole bots from signing up and trolling my board. I was getting like 10 a day! A++ :)

Here are the results:

Im hoping that some of these dns failures are fixing themselves now.

Not one bot registration got past my junk yard dogs, vBSFS and STRB in the past 10 days. Legit users got in without issues. But between them vBSFS and Stop The Registration Bots stopped every single bot.

Way to kick butt, pedigree. {loud applause, cheering, foot stomping, howling and wolf whistles} I say, HELL YES!!!

Thank You!!! :D :up: :up: :up: :up: :up: :up: :up: :up: :up: :up: :D

This wasn't working on my site for the last couple of days and as a result nobody could register. I turned it off three hours ago and since have had 20 spam registrations.

Luckily the DNS now seems to be working again and so I've turned it back on again.

This little outage has made me doubly appreciate just how vital this mod is to ANYBODY running vbulletin. If you have to install just one mod, make it this one!
:D

@burlesque: While I don't suspect SFS will be moving DNS again soon, to future proof yourself, be sure to set the "on network connection issue" in the SFS Mod settings to allow registration instead of rejecting.

That's actually a good idea.

@skippybosco: Yes, I agree with djbaxter this IS a good idea. That's why I already had my installation configured that way.

I also increased my local cache retention time from 30 minutes to 480 minutes (8 hours) and I increased my local log retention time from 30 to 60 days. increasing the cache time dramatically reduces the number of lookup requests I send to the central server and greatly reduces the likelihood I'm going to find that server too busy to handle my requests. At the moment, my server processes and rejects about 120 bot registrations a day (that's 5 per hour). By increasing my cache time from 30 minutes to 8 hours, I'm retaining just 40 records in my recent registration attempts cache rather than 3; but I've reduced my load on the central server to roughly 1/13th of what it would have been otherwise.

In short, from what I can tell by increasing my cache time to 16 times as long, I've reduced the load my site places on the central server over 92% and I've also improved the performance of SFS on my site because its getting a local cache hit in many more cases rather than waiting for 3 database queries to occur on an overloaded remote server. Frankly, I recommend those changes to EVERY site that's using SFS. I suspect we'd totally eliminate the central server performance issues if we did this.


@pedigree:

I'm confused about something here. It occurred to me this evening that I never actually saw anything that said this addon checks its own local database of rejected registrations using the registering user's email address, IP address and username BEFORE it goes off to the central server to check the database there. Yes, I realize it looks in the local cache covering the last xx (user configurable) minutes of registration attempts before it goes to check the host, but since the "standard" user-configurable cache time is set at 30 minutes whereas the local rejected user registrations table involves weeks or months of rejected registration history (I'm keeping 60 days of history) it seems to me the load on the central SFS server could be HUGELY reduced by increasing the cache time to 4 or 8 hours and then checking BOTH the cache from the last (user configurable) minutes and the local rejection log database for the last (user configurable) days rather than going off to check the central database practically everytime a bot tries to register on any site.

For example, my site receives about 120 bot registration attempts per day. That's 5 per hour or 2.5 bot registration attempts every 30 minutes. Compared to the 1,200 rejected bot registrations captured in our local SFS rejection log in the past 10 days, that suggests the 30 minute local cache is so small it's almost useless.

As I examine my own local SFS rejection log which already contains 1200 bounced registration attempts after just 10 days, I can see many of these bots come back time after time every day and try registering with the same IP address, username and email address over and over again. Furthermore, many of the bot registration attempts occur day after day several times per day and then the bot goes away and comes back again after 24 hours or so. With those behavior patterns in mind, it looks to me as if the load on your central server could be cut WAY down to maybe 5% or 10% of the current load if the hack was just modified to first check the local cache, then query the local rejection log for the last 5 or 10 or 15 or 30 (user configurable) days BEFORE going off to ask the remote server if this registrant has been reported as a spammer by any other site. If you combined this mod with a signficant increase in the cache time it looks to me like you'd eliminate most of the query requests the central server now sees -- especially on sites that have been around a while.

It's just a suggestion, pedigree, but I suspect if you'd just increase the cache time and make this one simple change to your look-up logic your problems with database and name server performance at the central server will completely disappear. As it stands now, with at least 1000 sites using your product and accessing your database and an average of lets say 120 bot registration attempts per day per site (that's my own site's average), that says at least 5,000 bot registration attempts per hour (that's up to 15,000 central database queries per hour) are being handled by your product worldwide. However, since recording the fact that they're using your software is NOT mandatory here for ANY webmaster, I'll bet that 1000 site estimate is low and the actual number is 2 or 3 times that. Even if we assume half those 5,000 bot registration attempts are never reaching your central database because the local cache is blocking them (with a 30 minute cache time I'll bet the percentage being blocked locally is much lower than 50%), that still means your local database receives up to 7,500 query requests per hour to look up the IP address, email address or username of a bot who in all probability has visited the requesting site one or more times in the past few hours, days or weeks.

If my "SWAG" is right and there are actually 2,000 or 3,000 sites using your software rather than the 1,000 sites shown as having clicked "install" here at vbulletin.org, then your central server could be receiving 15,000 - 22,500 query requests per hour. That starts to sound like a helluva LOT of database work and would certainly explain why the central server is overloaded. To make matters worse, if my guess about the local cache hit rate is correct, then you're getting a much smaller percentage of local cache hits than the 50% I assumed above. In that case, your central server's database workload could be as high as 30,000 to 67,500 query requests per hour rather than 7,500, 15,000 or 22,500.

But the good news is, if my hunch about the cache time being too short is correct, you could reduce that query load by 93% just by increasing the cache time from 30 minutes to 8 hours. That would cut a central server query load of 50,000 requests per hour to about 4,000 per hour. And if the 7,500 queries per hour request is a more accurate estimate, by increasing the cache time, you'd decrease the central server workload from 7,500 to about 600 queries per hour.

If you increase the cache time, check the local cache first and then query the local log file second BEFORE going to the central server, you are effectively spreading that 7,500 query per hour workload out across thousands of servers. In doing that I bet you'd eliminate 95% of the load on your central server and everyone who uses your product would see much better performance.

In my mind, that's definitely worth thinking about.

So tell me, what have I missed here, pedigree? Where has my reasoning gone wrong?

I hope this helps.