Machine room archaeology
The Computer Science department has been using its primary machine room for at least 25 years, and it's a proper machine room, complete with a raised floor. (People with the right sort of experience are now wincing.)
The problem is best illustrated by an anecdote: we just recently took out some hybrid 208V plus 120V power circuits that we believe were put in to power old Vaxes (which would make them obsolete for going on 20 years). We didn't have them removed out of any sense of neatness; we pulled them only because we needed the breaker panel space they were taking up for more plain 120V circuits.
(They were taking up three breaker spaces each, because apparently each hot wire uses up a space; 208V uses two hot wires, and the hot wire for the plain 120V was the third. My new job is an education in many things, electrical power issues included.)
The problem with raised floors is that over time all sorts of things accumulate down there below the floor tiles, because they aren't in people's way to be tripped over and thus yanked out. In fact, once you pass a critical snarl point pulling things out takes more work than leaving them there and just running new wiring over top.
By now, lifting up our floor tiles is an archaeological expedition into the dusty depths of our machine room's past. The CAT-5 tangles are the most recent stratum, then comes the carefully tied down runs of now obsolete serial cable that once connected to various consoles (we think), and down at the bottom you can still see the faded orange of a loop of thick Ethernet, complete with vampire taps and thicknet cables stretching off to somewhere. We're not sure what stratum the occasional dusty power cable belongs to, or whether they're still connected to anything.
(We are still better off than my old job, which once managed to accrete a slowly growing puddle of water until it seeped through a cinderblock wall and started soaking the carpet in my cubicle. Although to be fair, this can happen to anyone at more or less any time. That's the other problem with raised floors: you can't see what's going on underneath them, you just have to trust that nothing interesting is.)
What I currently do to stop comment spam on WanderingThoughts
WanderingThoughts has been pretty free of successful comment spam attempts for a while, so I think it's about time to write up all of the various things I'm currently doing to stop comment spammers.
(I'm not worried about comment spammers reading this and working past my precautions, because I'm confidant that comment spammers don't bother reading the blogs they spam.)
First off, I get a big leg up by being neither popular nor using common software. This basically reduces the comment spammers down to people automatically filling in any form that moves and people spamming completely by hand. Since I can never stop the latter sort of spammer, I only worry about the former sort.
My current precautions:
- I refuse comments entirely from web browsers that don't send a
User-Agent:header or send a User-Agent header that includes the string '
User-Agent:'. Technically I consider them robots, which are blocked from retrieving a variety of URLs, including the 'Add Comment' pages.
- the initial Add Comment page doesn't have a 'Post Comment' option
in the comment form; you have to preview your comment before it shows
up. I think that this is the right behavior to encourage in general,
especially since I use nonstandard comment formatting.
(I got this idea from Sam Ruby, although my implementation is simpler than his.)
- to prevent spammers from fetching my comment form from one IP address
and submitting from another, the comment form stamps itself with the
IP address that you previewed from (more or less) and you can only
post the comment from an IP address in the same /24.
(I could have required 'from the same IP address', but I decided that that was too dangerous in the face of proxies and the like.)
- to deal with spam software that fills in every text field it can find,
there's an invisible honeypot field that is supposed to always be
blank; if there's any value in the field, the comment won't post.
For people with
lynxand other browsers that don't deal with CSS, there's text next to the field that tells you to leave it blank.
(I got this idea from Ned Batchelder.)
- I refuse comment posts from IP addresses that are in the
SBL or the XBL. At the moment I don't bother checking
the SBL and the XBL for comment previews, mostly because I
want to delay as few things as possible with DNS lookups.
- comments with control characters are refused; this is part anti-spam precaution and part something required in general. (DWiki doesn't allow control characters in actual pages either.)
Technically I also have a content blacklist, but it is quite out of date and thus pointless. I keep it around mostly to have the hooks in the rest of the code.
DWiki is deliberately written so that it has no general way to write files or otherwise record data locally. This means that I can't take various sorts of precautions that require storing local state, like rate-limiting IP addresses or blocking IP addresses that exhibit characteristic bad behaviors.
(Technically I could write code that assumes that caching is turned on and hijack it for various evil purposes, but I'm not going to go there. Plus, there are concurrency issues that the simple caching layer currently gets to ignore.)