もし自分がTrackBack/1.02だったら
ステータスコードで不快感を表現したいを読みました．
ここで，「もしも，自分がSPAM Trackbackを行うユーザエージェントを作る立場だったら」という想定をしてみました．
SPAM Trackbackを行うユーザエージェント(以下，botと記述)の目標は，「よりたくさんのWebサイトに，Trackbackを送り付ける」ということになります．このため，なるべくたくさんのWebサイトにHTTPセッションを張り，なるべくたくさんのTrackback pingを投げつける，というのが基本的な動作になります．
このとき，どんな形であれ相手側からレスポンスが返ってくることは，botにとってはとても好都合です．なぜなら，否定的応答が返ってきた場合には，さっさと次のWebサイトに行く，という判断ができるため，単位時間あたりのTrackback ping送信の試行回数を上げることができるからです．
逆にやっかいなのは「Trackback pingを投げたものの，返事がかえってこない」ようなサイトです．このようなサイトにTrackback pingを投げてしまったbotは，TCPセッションのタイムアウトまでの間，動作をとめてじっと待っていなければなりません．その間，次のWebサイトに行くこともできません．
もちろん，bot自身はマルチスレッドまたはマルチプロセスにて動作していることでしょうから，並行して他のWebサイトにも送信を試みるでしょうが，ひとつのホストで処理することのできるTCPセッション数には上限があります．仮に，このような「返事が返ってこない」設定をされたサイトが100や200にも上れば，botにとっては大変都合の悪い環境になるでしょう．
まとめると，botにとってみれば以下のような感じになります．
ということで，Trackback pingを受け取るようなサイトのrootを持っている人で，「"TrackBack/1.02"をなんとかギャフンと言わせてやりたい!」という人は，SPAM Trackbackに対して返事を返すかわりに，ipfw(Linuxだったらipchainsとか?)などのホストベースファイアウォール機構にて動的にdenyルールを追加してしまい，そのTCPセッションについてはACKもFINもRSTももう送らない，という感じにしてしまえばよいんではないかと思います．
問題は，このようにして遮断したTCPセッションは，自サーバ側でも(相手に送ったつもりで，でもipfwで遮断される)HTTPレスポンスのACKパケットを受け取ることができないので，自分もTCPセッションタイムアウトを待つしかない，というあたりかなぁ．これについては要再考．
……あ，今思いついたけど，bot→自分方向はRSTも何も返さず(ipfw的にはdenyアクション)，自サーバ→bot方向にはRSTを返送する(ipfw的にはresetアクション)ようにすればいいのかも．httpdがbotに対してHTTPレスポンスを返そうとしたら，ipfwからRSTを食らってTCPセッション開放，という寸法です．
