After an overnight spam attack in which hundreds of spams got posted to the blog, including many that would have been blocked if the regular expression filter actually worked, I have set the comment options in Movable Type to moderated. I was going to switch off commenting entirely, until I realised that moderation would work for the small number of real comments I get here.
There may be delays in getting your comment posted. I haven't switched on email notification for new comments because I'm not that masochistic. The ratio of real comments to spam is very low, and the last thing I want is to have hundreds of spam comments in my incoming email as well as my Movable Type backend.
This message only affects comments on the weblog, not on the webcomic, which has a superior commenting and comment filtering system written by one guy in his spare time.
I could go on forever on how bad Movable Type's spam prevention is. Where to begin? How about with cleanup? I could cook dinner in the time it takes to rebuild a hundred entries - and then let it get cold checking whether the entries have actually rebuilt. At least one batch of twenty rebuilds timed out during today's cleanup, which means that the spam posts on those may or may not have gone from the archived entries.
Why twenty? Why not do a hundred at a time? Partly because of the timeout problem, but today I'd actually have been willing to do the cleanup in batches of seventy-five or a hundred, just to get it over with. All the spams that got posted were gibberish (which I can't filter because there's no regular pattern in it) with links in BBCode (which I can filter using a regex, but as I said, the regex filter doesn't work). But another problem with MT's commenting system is some very poorly-written AJAX(-ish) programming in the backend, which causes common interface elements to behave differently from how they should. You can see that in the category selecter - unlike with regular dropdowns, you can't actually scroll to the category you need unless you keep the mouse button pushed down all the time. If you don't keep the mouse button pushed down, the dropdown will reset itself to its initial position. The same happens within the AJAX(-ish) widget that governs the display options in the commenting backend, so when, brainwashed as I am by more than a decade of using standard dropdown boxes, I thought I'd selected to display 75 rows of comments in my backend, I'd actually chosen to display twenty. So I ended up cleaning them out twenty at a time. Another example of terrible backend scripting is the checkboxes with each individual entry's backend that you can use to close the entry for comments or trackbacks. You have to click them very decisively and firmly, looking straight at them and mumbling incantations along the lines of "obey, motherfucker". And. Don't. Blink. Otherwise, they will revert to the state they were in before you clicked them. I've observed this in both Opera and Safari, by the way. It's unbelievable that something like this was allowed to pass the quality control. If you don't give the act of clicking a check box your full and undivided attention, you'll move your mouse to "Save Changes" and click that thinking you've closed the entry whereas in fact you've left it wide open. It's Movable Type's Christmas gift to spammers.
What else? Oh yeah. The Spamlookup Plugin's word and regular expression filter works only about half of the time. I don't know what causes it to fail, but fail it does. Also lose and suck.
But all this bitching about the superficial design and implementation flaws only serves to conceal Movable Type's fundamental design and implementation flaws. These aren't unique to Movable Type - I could easily write a similarly long and ranty screed about how bad, say, PHPBB is in this regard.
Movable Type and many other content management/commenting/forum posting/yadda yadda yadda systems have this fundamental design problem: There is no single interface for dealing with spam, and far too many of the tools are included as plugins. Bundled plugins, as far as SpamLookup is concerned, but still plugins.
Systems that publish user-contributed material to the web should be written from the ground up to detect and prevent spam The SpamLookup code, as well as additional code like Akismet and Bad Behaviour that users now have to hunt down and install, should be there as part of the core functionality with every installed version of the system, so that the user running the install doesn't have to think about it and spam can be dealt with as quickly and quietly as possible. Spam prevention is as important as the content creation itself, for the simple reason that spam will eventually be posted in such numbers that it will bury and defeat the content creation (see A quick reminder of why there are no comments on this blog from 2005) and, in forums, bury and defeat all other aspects of the forum (see any PHPBB forum that hasn't got a team of rabid, fascist moderators purging the member lists, blocking posts by non-members, blocking fake account creation, blocking whole IP ranges from posting messages or creating accounts, blocking, blocking, blocking).
Over time, the utility of a content creation system that lets spam in drops to zero. For that reason, it's worth it to compromise other aspects of the system, such as ease of use, to prevent spam from getting a foothold. In Movable Type (and PHPBB, and, and, and), we get poor usability anyway, especially in dealing with spam. To close old posts, we need to go to one place, or rather, several places: the posts themselves (there are, of course, plugins for that, but see the previous paragraph). To clean up spam, we need to go to another - the comments backend. To filter our messages, we need to go to yet another - the SpamLookup plugin, and if we have three different kinds of changes to make, we need to open three different boxes to make them. Then there's the general settings in which we decide how to handle comments globally, and we need to go somewhere else again.
Simplifying this isn't a trivial task, in fact now that I think of it, it's rather daunting. However, adding "Delete and close" and/or "Delete and Blacklist" buttons or checkboxes in the comments backend would shave off quite a bit of time from the daily despamming chores. And those would be easier to add if blacklists weren't governed by plugins to start with.
See also: Six Apart Picked Apart.