Users of Bad Behavior on Microsoft Internet Information Server 7.0 may find that Bad Behavior’s error pages are not always displayed to spammers and malicious crawlers.
This behavior occurs because of a misfeature in IIS 7.0 where it serves custom error pages by default, overriding the error page generated by your web application. This is, of course, utterly broken behavior, and just one of many reasons you shouldn’t use IIS on Windows to serve your web site.
But some people still want to do it, so here is a workaround to allow Bad Behavior (not to mention every other web app you have) to display its error pages properly.
You will need to know your way around IIS already; I cannot give you any support for this.
You will need to modify your IIS configuration to set the web server httpErrors element to “passthrough”. An MSDN blog post from the IIS team explains how to set this property for an individual web site or for your entire server.
Not only does this provide a fix for Bad Behavior, it also fixes WordPress 404 pages, as well as numerous problems where a web application expects to generate its own error page. Of course, it’s utterly ridiculous that this requires a workaround and is not the default behavior, as it is with every other web server. But that’s one more reason not to use IIS.
There’s a whole lot of buzz about the newest WordPress spam-fighting plugin on the block, and so I decided to go take a look and see if WP-SpamFree lives up to its hype.
“The WP-SpamFree plugin virtually eliminates automated comment spam from bots, including trackback and pingback spam,” its author, Scott Allen, claims. “It takes a different approach than most and stops spam at the door.”
Indeed, everyone who’s tried it reports that their spam has dropped off to virtually zero and that they haven’t heard from anybody who had problems leaving comments. Sounds like the Holy Grail of spam prevention, right?
Not so fast.
WP-SpamFree, it turns out, uses JavaScript and cookies to verify that someone is using an actual web browser to access your site and leave a comment. These approaches are not that different from what other plugins have done in the past. What distinguishes WP-SpamFree in this respect is that it requires both JavaScript and cookies in order for someone to post a comment. This will certainly keep out virtually every spambot out there.
Unfortunately, it will also block most mobile web browsers and some disabled users. In both cases the browsers being used aren’t capable of JavaScript, cookies, or both. If your blog targets mobile web users or people with disabilities, WP-SpamFree might not be for you.
Then there is WP-SpamFree’s method of blocking trackback and pingback spam. These are always automated, so using JavaScript and cookies is impossible. WP-SpamFree, it turns out, uses several extensive internal lists of IP addresses, URL fragments, and keywords to block this type of spam.
This works fairly well; however, the way it’s implemented in the current version of WP-SpamFree (1.9.6.2) is quite strange. It appears the author didn’t want to use arrays and loops to iterate through his lists and instead unrolled all his loops, resulting in a huge plugin clocking in at over 3,700 lines. There’s no obvious good reason for this; it would seem in PHP that the plugin would be much slower than it would otherwise. The gain of not having the loops doesn’t seem nearly as much as the overhead of compiling thousands of extra lines of bytecode. In addition there are several other examples of duplicate code which could have been split into functions.
These technical implementation issues make me wonder at how much experience the programmer has. If they were intentionally done by an experienced programmer, I would have expected them to be mentioned in the README or release notes or a blog entry, but especially in the code comments.
Despite those issues, the plugin works pretty well for what it does. I hope that the author addresses those implementation issues for his next major version, though, to make the plugin even better.
And there are things that WP-SpamFree does not do. It does not block email harvesters, for instance. It also does not block spambots when they scrape your site looking for your comment forms, nor block denial of service attacks. Indeed, under a heavy spam attack, its size and CPU usage could cause limited web hosting resources to be exhausted.
That’s all just a long way of saying that WP-SpamFree has its pros and cons, and if you choose to use WP-SpamFree, you still should keep Bad Behavior around as part of your overall spam prevention strategy.
Bad Behavior 2.0.10 has been released. It is a maintenance/bug fix release.
Who should upgrade?
This is an optional upgrade for those of you already running version 2.0.9. If you are running an older version, please update as soon as possible.
This is a critical upgrade for those of you who are using PHP 5.2.0 or later versions.
What’s new?
Bad Behavior 2.0.10 fixed a bug which caused a failure to block any spam on sites using PHP 5.2.0 or later.
Download
Bad Behavior 2.0.10 may be obtained from the download page.
I’ve gotten a couple of isolated reports from people using PHP 5.2.0 that Bad Behavior is failing to block anything on this version of PHP.
I don’t have access to any machines running this version of PHP (it’s far too new) so I haven’t yet been able to investigate the problem.
Until I can figure out what’s going on, I recommend downgrading to PHP 5.1.6, the latest version known to work. You can also use PHP 4, if your Web host gives you this option.
(Or, if you already happen to know what the problem is, please let me know.)