I had the same problem a while back and ended up killing access to the trackback URL via .htaccess.

At first I tried using the Expression Engine blacklist capability, but that was so inefficient that it nearly killed the server, which earned me a nastygram from the hosting company (they were swarming the server with about 30,000 hits per day).

The REFERER spammers are just as bad, but at least for those Expression Engine will automatically generate the right .htaccess rules from the blacklist entries, so all I have to do is add them to the blacklist.

The unfortunate part is that I can't do that for the trackbacks, since the payload is contained in the POST body and isn't in the URL so it can't be examined in .htaccess. It was the process of invoking PHP, checking the blacklist, and then rejecting the request that was killing the server. The .htaccess process is amazingly efficient in comparison.

Each morning when I get my emailed report of REFERER abusers for the previous day I entertain black fantasies about slow and painful ways to kill these bastard spammers.

Hmm... that was weird.

I logged into Typekey for that comment, yet it said I wasn't when I submitted it. So I went back to the main page and then clicked comments again to see if it had something to do with the Preview page. When the page displayed, it showed that I wasn't signed-in. I clicked the link to sign in and was immediately redirected to the comments page (like it knew I was signed in). Weird.

Now that it thinks I'm signed in, I guess the true test will be seeing whether the comment gets posted.

I've been having odd problems with TypeKey accounts since upgrading to MT 3.33. I haven't had time to track them down yet.

Yeah, the referer spam problem — and for that matter the comment spam problem — really bite, too. As does email spam and in fact spam in any forum where you need to have communication between people who don't really know each other at the beginning (even Googlebombing is a manifestation of this). There are two statements which together account for this:

1) Any system not designed at its very base to be secure is inherently insecure, and no amount of band-aids will do more than disguise that.
2) The internet protocols are not designed to be secure.

Until people are willing to start a new internet infrastructure, with secure basic protocols (including such basics as non-deniability), we will have this problem everywhere we try to use the internet for two-way communication or content creation.