Caliban - Opinion and Righteous Anger

It has been brought to my attention that the Atom feed for this site was very poorly formatted. If you read my twaddle using this feed, you'll be pleased to know that the problem has now been fixed.

I've also added an RSS 2.0 feed feed, should anyone prefer or need that.

Some time ago, I turned off the ability of unauthenticated users to comment on entries made to this blog. Registered TypeKey users could still comment, but apparently it was too much trouble for a lot of people to register with this service. After all, who cares about being able to comment on what I say?

Well, in case you do care, I've now switched unauthenticated commenting back on and moved to a CAPTCHA-based scheme for distinguishing between human and automated users. If you want to comment on an entry now, you just have to answer a simple question with a one word answer and your comment will be accepted for publication.

Note, however, that if you are a registered TypeKey user, nothing changes. You can continue to post comments as an authenticated user without having to jump through any hoops.

The migration of our blog data from Berkeley DB to MySQL is now complete and the performance of the site has, as expected, improved somewhat. By how much depends on what you're doing: reading, commenting, searching, etc.

I'm sure I'll find a few minor residual glitches here and there over the next few days, but the major work is now complete.

Even though it was a slow and painful process (and one I said I wouldn't bother to endure), I moved the blog over to the latest Movable Type templates in the course of yesterday.

The hardest part was getting the three column look that I favour to work properly. Even though Movable Type's styles-site.css stylesheet contains styles whose name suggest that everything should just fall into place, that's not the case; or, at least, not for me, as I don't know how to apply them properly.

In fact, whilst Movable Type's site is definitely not short on reasons why you should upgrade to the latest version, it falls down on telling you how to actually do so. All of the instructions are aimed at first-time installers. The only upgrade instructions refer to migrating from the standard version to the Enterprise product.

Apart from twiddling with the stylesheet, the biggest debugging headache was trying to figure out why the archives wouldn't rebuild. Apache kept returning HTTP 500 errors. I debugged this by removing chunks of MT tags from the archive templates until they could successfully be rebuilt.

However, once I'd found what I thought was the culprit, starting afresh with an archive template and removing just that one tag no longer fixed the build problem. It was starting to seem as if the quantity of MT tags, not the type, was the issue.

I suspected some kind of time-out problem, possibly with mod_fcgid, so I turned to Google and eventually came across documentation that mentioned the IPCCommTimeout configuration directive. This controls the time-out when waiting for a response from a fastcgi application. Since the archive build process takes longer than this directive's default setting of 20 seconds, mod_fcgid abandons the task, causing Apache to return an internal server error.

Simple, once you've localised the problem, but it was actually quite a bit of work to turn that up.

The next step will likely be to move the blog's data from Berkeley DB files to MySQL, which should considerably improve its performance.

I upgraded the site to Movable Type 3.34 today and installed mod_fcgid, a FastCGI implementation, which should hopefully provide a few performance improvements.

I wish it was easier to merge the latest versions of the default templates with my older versions, which I've customised quite a lot. Unfortunately, the new templates make use of a radically revised set of stylesheet classes, so it's not possible to cut and paste my customisations into to the new templates. A lot of work would be required to figure out how the new ones work and it's just not worth it for a site like this.

My new blog anti-spam defences seem to be holding up well.

The current configuration starts with MT-Blacklist, which blocks more than 95% of the comment and trackback spam by checking for blacklisted strings in the various fields of the incoming data.

The little bit of spam that makes it through is then funnelled into SpamLookup, which does some advanced extra tests, including a check to see whether a trackback ping originates at the IP address of the blog claiming to be sending it and a dynamic check to see whether a comment is being sent via an open proxy. Clever stuff.

I also have MT-Moderate installed, which allows SpamLookup to also moderate trackback pings.

This combination of plug-ins is working very well. It could be that SpamLookup on its own can do the job and that I could simply disable MT-Blacklist at this point, but I haven't felt inclined to try that out just yet. For now, I'm happy to see how many comments and pings get denied or just moderated.

It's lamentably insane that this problem even exists, but since it does, as with e-mail spam, one simply has to have effective measures against it.

I finally took the plunge and upgraded the server blog software to Movable Type 3.17 today.

It was a fairly substantial upgrade, requiring a lot of template and style sheet editing, as well as the copying of files hither and thither, but I think I've got everything more or less covered now. If you see anything strange on the site in the next couple of days, please report it to me.

My own homebrew methods of dealing with comment spam in Movable Type 2.x had been starting to try my patience, so I'd finally got around to taking a long-postponed look at the MT-Blacklist plug-in during the last couple of days. The upgrade to MT 3.17 allows one to use a much more powerful version of MT-Blacklist than the one available for 2.x, so I have now installed and configured that. It remains to be seen how much more effective this proves than my own hacks, but the interface is certainly very nice and I like the fact that it automatically updates itself with the latest list of spam domains from the Comment Spam Clearing House.

As I wrote in my last entry, I've been forced to take measures against trackback spam.

The patch is proving effective, so I produce it here in the hope it will help some of you, too. Note that this patch uses the same bad_words file that my comment spam patch used. In fact, the code is very similar, too. This should probably be factored into a single function, but I'm feeling lazy.

Anyway, with patch this in place, your MT 2.661 system will auto-ban any IP address that attempts to send you a trackback ping that contains any of the regular expressions in bad_urls. These strings should be listed one per line. They'll be tried until either one matches or the end of the list is reached. If none match, the trackback is allowed through.

Blog comment spammers have been having a hard time of it lately, given the new measures that people have been devising to render their links ineffective.

Of course, rendering spam links ineffective works only acts as a deterrent. It doesn't stop your blog from filling up with rubbish and the genuine comments from being obscured. For that, you need something like MT-Blacklist or my own patch to MovableType 2.661.

After seeing the effectiveness of their efforts dwindle, it seems the spammers have now discovered trackbacks and are using those to propagate their evil links. Last night, I was hit with a major attack for the first time.

After writing a quick Perl script to clean up the mess, I hacked on TBPing.pm to make it use the same bad_words file that my comment spam patch uses. Hopefully, this will put a stop to the trackback spammers before they can really get started. We'll see. If the patch proves effective, I'll post it here.

Slashdot has an article on how comment spammers are killing Movable Type blogs by introducing high load on servers. The report turns out to be talking about a bug in MT 3.x, whereby the server gets put under high load even if the comment is rejected by MT 3.x's anti-spam measures.

What about MT 2.x users, though? Movable Type deliberately left MT 2.x users in the cold in this regard as gentle encouragement to upgrade to MT 3.x. For me and many others, this is more hassle than it's worth, although we definitely don't want to have to continue to fend off the torrential spam that is coming through these days. These fuckers will do anything to get their links crawled in an effort to increase their PageRank.

Below, you'll find a simple patch to MT 2.661, the last of the 2.6 releases. Once this is applied and someone tries to post a comment, MT will read a couple of files, bad_words and bad_urls, and reject the comment if either the author name contains any of the bad words or the comment field contains any of the bad URLs. In fact, it doesn't just reject the comment; it also auto-bans the IP address of the prospective poster.

The bad_words and bad_urls files can actually contain regular expressions, one per line. These files should be installed in the same location as Comment.pm. In the code below, the path is hard-coded as /var/www/cgi-bin/lib/MT/App.

It takes a very short while to build up the bad_words and bad_urls files. If you're hit with spam anything like as often as I am, you'll find this patch starts to save you a lot of arduous work very quickly.

By posting this here, I run the risk that spammers read the code and work around my current measures, but I think the benefit of posting the code outweighs the inconvenience of potentially tipping off the spammers.

One tip: when composing your bad_words file, include &#\d+; as one of your regular expressions, as this will stop spammers from using HTML entities to get around your traps for individual words.

I'm getting really tired of people using the ability to post comments to blog entries for their own nefarious purposes, namely to drop in links to the latest site for cheap Viagra and penis enlargement technology. Presumably, they're hoping that Googlebot will find these links, resulting in an increase of their site's PageRank.

To combat this, I've written a patch to Movable Type 2.661 to detect this kind of spam at the time of entry. If a spam attempt is detected, the comment will be refused and the originating IP will be automatically added to the ban list. So, if you're a genuine user, don't play around with this feature and try to trigger it!