Six ApartがDISQUS風のサービスを始めたようですね。
TypePad Connect Beta を開始 | MovableType.jp
TypePad - TypePad Connect Beta - Home
埋め込み用のJavaScriptだけ見たら、DISQUSのOEMだと言われても信じちゃうくらいですよね（笑）
今のところ、TypePad/TypeKeyのアカウント（とユーザ資産）を流用できる点を除いては、先発のサービスに対するアドバンテージはほとんど見当たりません。残念ながら現時点では、私を含めDISQUSのユーザの食指を動かすに至らないのではないかと思います。
是非とも後発のメリットをいかしたサービスにしていってもらいたいです。特にDISQUS | API並みのAPIはどうしても欲しいところですよね。
Disqus Exporter for MTを使ってMTのコメントをDIQUSにインポートすると、「Unverified」コメント(DISQUSのアカウントを持っていないユーザのコメント)として登録されてしまいます。
これは妥当な仕様です。コメンターのメールアドレスなどを自動的にDISQUSアカウントに関連付けてしまうと、API経由で人のコメントを捏造できてしまいます。API経由でコメントをポストするたびに、アカウントを持っているユーザ自身にそのコメントの承認要求を送って承認させるという方法もあり得ますが、何年の前からの自分のコメントを承認するのはバカバカしい作業ですし、結局その承認システムへのスパミングが可能になってしまうので意味がありません。
しかし、後からDisqus Exporterで変換したコメントをDISQUSアカウントに統合する方法が「ないこともない」です。
まず、DISQUSで新たに「Unverified」コメントをポストします。DISQUSからログアウトして名前とメールアドレスを入力してポストすればUnverifiedコメントになります。このとき、メールアドレスに以前MTコメントをポストするときに使ったのと同じアドレスを使います。
ポストしたコメントのユーザアイコンにフォーカスを合わせると、以下のようにポップアップ表示されます。
ちなみにコメンター画像が表示されているのは、メールアドレスがGravatarに登録してあるためです。登録していない場合にはデフォルト画像が表示されます。
このポップアップ内の「unclaimed profile」というボタンをクリックしてみましょう。下のようにユーザ画面が表示され、先ほどコメントをポストする際に入力したメールアドレスを使って投稿されたすべてのDISQUSコメントが一覧できるはずです。
上の画面で「Claim Profile」というボタンをクリックしてみましょう。ログイン画面が表示されます。DISQUSのユーザ名とパスワードを入力して、ログインします。
下のようにVerifyするためにメールアドレスの入力フォームが表示されます。入力して「Done」をクリック。
しばらくすると、Verify用のURLが記載されたメールが届きます。Verifyしてみましょう。投稿したコメントと、そのコメント投稿時のメールアドレスを使用した過去のコメントすべてが、DISQUSアカウントに統合されるはずです。
WWW-Disqusを使って、MTのコメントをDISQUSにブッこむツール「Disqus Exporter for MT」を作りました。このブログの過去コメントもすでに全部DISQUSに移行してあります。
DisqusExporter-0.1-dev.zip
ogawa - Revision 607: /trunk/DisqusExporter
インストール方法などを説明する前に注意点を述べておきます。
あと、これはTipsですが、DISQUSにブッこまれたコメントは、MT側では「保留中のコメント」に変更されます。Disqus Exporter for MTをインストールする前に「保留中のコメント」を不要なら消去しておくと、都合がよいケースがあります。例えば、「このツールでDISQUSにブッこむ→やっぱりなかったことにしたい」という場合、あとで「保留中のコメント」をまとめて「公開」するだけで済みます。
まず、パッケージの中のtools, extlibの中身をMTの対応するディレクトリにコピーしてください。
パッケージにはMakamaka Hannyaharamitu / JSON-1.15 - search.cpan.orgが同梱されています。コピーする際にMTのextlibに含まれている古いJSONモジュールを、同梱されているJSONモジュールで置き換えることを忘れないでください。
コピーが済んだら、toolsディレクトリがWebなどで外部からアクセスできないことを確認してください。絶対に確認してください。
確認が済んだら、次にtools/disqus-exporter.plを編集して、以下の定数を適切に設定してください。
以上でインストールはおしまいです。
コマンドラインからtools/disqus-exporter.plを実行するだけです。MTのコメントが順次DISQUSにイクスポートされ、イクスポートに成功したコメントはMT側では「保留中のコメント」に変更されます。保留中のコメントに設定するのは、再実行した際に同じコメントを複数回イクスポートするのを防ぐためです。
実行が完了すると以下のような統計情報が表示されます。
$ cd <MT_DIR>; tools/disqus-exporter.pl ----------------------------------- Statistics ----------------------------------- Processed entries: 100 Skipped entries: 30 Exported comments: 200 Failed comments: 5 ----------------------------------- Permalinks without Disqus threads ----------------------------------- http://www.example.com/blog/archives/000745.html http://www.example.com/blog/archives/000753.html http://www.example.com/blog/archives/000756.html http://www.example.com/blog/archives/000759.html (snipped)
上の例では、100件のエントリーが処理され、30件のエントリーの処理がスキップされています。また、200件のコメントのイクスポートに成功して、5件は失敗しています。
なぜエントリーの処理がスキップされたかというと、そのエントリーアーカイブに対するDISQUSのスレッドがまだ作成されていない(そのエントリーアーカイブがブラウザなどで閲覧されてコメントフォームが表示されるまで作成されない)ためです。「Permalinks without Disqus threads」以下に表示されているのは、そのようなエントリーアーカイブのURLです。片っ端からブラウザで閲覧するかしばらく放置してからtools/disqus-exporter.plを再度実行すればスキップされずに処理されるでしょう。
またなぜイクスポートに失敗したコメントがあるかというと、APIの処理能力のせいでたまに失敗することがあるというだけです。気にせずに再度実行してみてください。ダメな場合、コメント欄で教えてください。
WWW-DisqusというPerlモジュールを書いてみました。StraightforwardにDISQUS APIを叩くためのインタフェースを提供しています。
ogawa - Revision 637: /trunk/WWW-Disqus
こんな感じで使えます。詳しくはDISQUS | APIを参照。
#!/usr/bin/perl use strict; use warnings; use WWW::Disqus; my $forum_name = 'your forum short name'; my $user_api_key = 'your user api key'; my $api = WWW::Disqus->new; $api->user_api_key($user_api_key); my $forum_id = $api->get_forum_id($forum_name); my $forum_api_key = $api->get_forum_api_key($forum_id); $api->forum_api_key($forum_api_key); # The above 3 lines can be rewritten by using a helper method: # $api->set_forum_api_key_by_forum_name($forum_name); use Data::Dumper; print Dumper( $api->get_thread_list() );
で、いくつか試した結果、DISQUS APIには以下のような疑問点があることが分かりました。
洗練の余地が残されていますね。
あと、Wordpressのプラグイン(DISQUS Comment System)には、API version 2が使われていて、これに関するドキュメントがどこにもありません。
MTにDISQUSを配備するにはプラグインを使う方法もあるのですが、私の場合はMTのコメント許可、トラックバック許可を双方ともOFFにした上で、エントリーアーカイブのテンプレートに以下のように書いています。
<div class="comments">
<h2 id="comments" class="comments-header">Comments and Trackbacks</h2>
<div id="disqus_thread"></div>
<script type="text/javascript">
var disqus_url = '<$MTEntryPermalink$>';
var disqus_title = '<$MTEntryTitle encode_js="1"$>';
var disqus_message = '<$MTEntryExcerpt encode_js="1"$>';
</script>
<script type="text/javascript" src="http://disqus.com/forums/short_name/embed.js"></script>
<noscript><a href="http://short_name.disqus.com/?url=<$MTEntryPermalink$>" rel="nofollow">View the discussion thread.</a></noscript>
</div>
short_nameのところには、DISQUSにブログを登録するときに設定したshort nameを指定します。
Movable Type組み込みのコメントシステムを使うのを止めて、DISQUSという外部コメントシステムにアウトソースすることにしました。
サイトオーナーにとっては、スパムコメントや再構築のオーバーヘッドの心配をする必要もなく、スレッド機能やユーザ・コメントのレーティング機能を備えたコメントシステムが利用できるというメリットがあります。あ、おまけでトラックバック機能も付いています。
DISQUSのアカウントがなくてもコメントはできますが、一旦DISQUS | Login or Sign Upでサインアップしてアカウントを作っておけば、アバター機能やコミュニティ機能が使えたり、自分が書いたコメントを一覧できたりするのでお勧めです。
IntenseDebateやSezWhoでも良かったのですが、IntenseDebateは(多分)一時的にInvite Codeがないと登録できないようになっていて今は利用できません。DISQUSがサービスを終了しちゃったらとか、はてながはて子を始めたらとか、つまらない心配はしていません。相互に変換するためのツールもそのうちできるでしょうから。自分のところにユーザを連れてくるには相手からユーザを奪うツールが必要になりますからね。いざとなったら自分で書けばいいんです。
日本でいまいち流行っていないのは、多くのブログシステムで組み込みのコメントシステムと外部コメントシステムを同期する仕組みが提供されていないためかもしれません。外部コメントシステムがDISQUS APIのようなAPIを備えるようになったのもつい最近のことなので仕方のないことですけどね。Movable TypeのコメントデータをDISQUSに統合するようなツールくらいはそのうち作ってもいいかなと思っています。
CAPTCHA™テストを使った簡単なアンチコメントスパムプラグイン(Ogawa::Buzz: Captcha Plugin公開)をアップデートしました。
Captcha_Plugin - ogawa - CAPTCHA(TM)テストによる簡単なアンチコメントスパムを実現するプラグイン。 - Google Code
最初に公開した時点ではプロトタイプ的なものでしかありませんでしたが、今回はなるべく柔軟に使用できるように以下の拡張をしました。
4. のsecret keyの設定機能に関して補足しておきます。
Kazuho@Cybozu Labs: Captcha Plugin/ja についてでも指摘されている通り、このプラグインで使用されているAuthen-Captchaはbrute force attackに弱い性質がありました。
CAPTCHAテストの生成時と検証時に共有鍵を使用する方式に改めればこの問題は大幅に緩和でき、実際下記のようなパッチも提案されています(FreeBSD portsでp5-Authen-Captchaをインストールするとパッチが当たったものがインストールされます)。
#7664: improve Authen::Captcha security
Captcha Pluginのsecret keyの設定機能は、このパッチが当たっているAuthen-Captchaがインストールされている場合のみ有効になります。この機能を使用するためには、おそらくほとんどのユーザは、手でこのパッチを当てる必要がありますのでご注意ください。
Authen-Captchaはもう保守されていないっぽい。Authen-PluggableCaptchaというのもあるけど。本当はGoogleあたりがCaptcha部分だけ外部サービスとして提供してくれれば良いのにね。
2006-10-08追記: CAPTCHA表示用のテンプレートをプラグインの設定画面から変更できるようにした0.12を公開してあります。
2006-10-17追記: CAPTCHAを使用しない設定にしたブログで、正常にコメントポストできない問題を修正した(0.13)。
CAPTCHA™テストを使った簡単なアンチコメントスパムプラグインを作ったので公開しておきます。
Captcha_Plugin - ogawa - CAPTCHA(TM)テストによる簡単なアンチコメントスパムを実現するプラグイン。 - Google Code
このプラグインは、以下のように、コメント時に大抵の人間には容易に解答できるがプログラムでは簡単に解けないようなテストを課すことで(この場合はSecure Codeを入力させることで)、spambotを排除するという仕組みを実現します。
Movable Typeで同様の機能を実現する方法としては、SCode - Movalog Plugins - TracやCAPTCHA によるコメントスパム対策 - Open MagicVox.netが知られています。
Captcha Pluginがこれらと異なるのは、セッションごとに(つまりはコメントフォームが表示されるごとに)Javascriptを使って新しいCAPTCHAテストを生成するということと、各CAPTCHAテストに有効期限が設定されていることです。ですから、単純なbot攻撃に加えて、「人間が解いて、botが攻撃する」タイプのbot攻撃にも有効ではないかと思われます。
また、セッションごとに新しいテストを生成するということは、テストの生成が十分に軽量に行える保証が必要です。このため、テスト生成を行うCGIスクリプトcaptcha_js.cgiは簡単なものに留めて、あえてMTアプリケーションにしていません。MTアプリとして作ると、プラグインの設定画面での設定内容を処理に利用できるとか、中間ストレージにMTのフレームワークを利用できるとか可用性の点で大いにメリットがある反面、ブートストラップやDBアクセスのオーバーヘッドが無視できないものとなります。
ちなみにSCode Pluginは、テスト画像を作るCGIプログラムをMTアプリとして実現しており、その上毎セッションまったく同じ画像を返すにも関わらず、GDモジュールを使って毎回画像を生成していてキャッシュすらしません。それもなんだかなあ…。
Ogawa::Buzz: AutoIPBan Plugin公開
とか作っておきながらなんですが、どうもねえ…。
昨日の時点で約7000件のトラックバックスパムがやってきて、うち約6000件はリジェクト、250件はスロットリングされ、残りの700件強がやはりJunk Folderに溜まっていくご様子…。結果として9割方リジェクトできているのだからいいじゃないかとはちょっと思えませんね。なんかくじけそうです。
対SPAM最終兵器“Junk slowdown”!! : 亜細亜ノ蛾 - Weblog
やっぱりこっちの方が素直で有効っぽいです。スクリプトの途中でスリープさせるのはあまり意味がないかと思いますが。そのままだと芸がないので私はCで超簡単なマルチスレッドプログラムを書いて済ませてみました。
さて、ここからが本題。
教えてエロいえらいひと
コメント・トラックバックCGIのリネームとMT.cfg・.htaccessの変更を、同時に行ってくれるスクリプトがあれば、週一くらいで実行すると万全なのですが。
ってことなのですが、基本的に「スクリプトで」mt-config.cgiを更新するのはあまりお勧めしません。代わりと言ってはなんですが、定期的にmt-config.cgiのCommentScriptとTrackbackScriptを変更し、再構築するだけで済むようにするには以下のようにするとよいです。
まず、mt-comments.cgi, mt-tb.cgiは予想しにくいでたらめな名前に変更しておきます。ここでは、仮にmt-comment-detarame.cgi, mt-tb-detarame.cgiとします。
次にmt-config.cgiのCommentScript, TrackbackScriptにスクリプト名を設定します。ここで設定する名前は、mt-comment-detarame.cgiなどにリライトされるので、ファイルとして実際に存在している必要はありません。また、mt-comment-detarame.cgiなどとは異なった名前の方がよいでしょう。例えば、mt-comments-nospam.cgi, mt-tb-nospam.cgiとか日付を使った名前とか。
最後に、以下のようなテンプレートを作り、出力するファイル名にはフルパスでMTがインストールされているディレクトリの.htaccessを指定します(例: /home/hoge/.../mt/.htaccess)。また、インデックス・テンプレートと同時に再構築されるようにしておくとよいでしょう(このテンプレートは絶対にダイナミックパブリッシングにしてはいけません)。
RewriteEngine on
RewriteRule ^<$MTCommentScript$>(.*)$ mt-comments-detarame.cgi$1 [L]
RewriteRule ^<$MTTrackbackScript$>(.*)$ mt-tb-detarame.cgi$1 [L]
RewriteRule ^(mt-comments|...)\.cgi$ /hoge/sand-trap.php [L]すでに.htaccessに何かを指定しているのであればその内容も含めます。また、Movable TypeからMTディレクトリに書き込めるようにパーミッションを設定しておく必要があります。それが済んだらこのテンプレートを再構築して正しく.htaccessが生成できることを確認してください。
確認できたらすべてのアーカイブ、インデックスを再構築して終わりです。以降は、定期的にmt-config.cgiのCommentScriptとTrackbackScriptを変更し、再構築するだけで済みます。
…というのは全部実際には試さずに書いています。
「コメントスパム対策」と言うとき、それは複合的な意味を持ちます。コメントスパムがブログ内に表示されるのを避けたいのか、管理画面の「コメント一覧」に表示されるのすら避けたいのか、あるいはコメント投稿によって発生する再構築の負荷を低減したいのか？
このエントリーでは私がやっているコメントスパム対策について述べます。
番組の途中ですが緊急速報です。mt-comments.cgiに極めて重大な欠陥が見つかったようです。スパムメールの踏み台にされるという、とんでもない欠陥です。対策が発表されたら全員がすぐに適用する必要があります。
MT-Blacklist -> Hijacked comments.cgi
というわけで対策出ました。必ずパッチ適用をしましょう。
Movable Type Publishing Platform: Movable Type 3.15 released
Movable Type 日本語版サイト: 【重要】 Movable Typeの脆弱性と対策について
STEP 1: 「TypeKey + 承認付き」にする
単に「コメントスパムがブログ内に表示されるのを避けたい」のであれば、TypeKeyを用いた投稿だけを許すか、それに加えて「承認(事前確認)付き」でのコメント投稿を許すようにすればよいだけです。承認付きであるだけで、スパマーのスパミングに対するインセンティブは非常に小さなものになります。
STEP 2: 特定の文字列を含むコメントをdenyする
ときどき見かけるのは、ASCIIのみのコメントをdenyするパッチやプラグインです。私自身も以前同じ目的のプラグインを作りました(単純にアプリケーションレベル・コールバックの機能を試したかっただけですが)。
Ogawa::Buzz: Application-level Callbacks in MT3.1
しかし、個人的にはASCIIのみのコメントをdenyしたくはありません。そもそも英語のブログを書いているのならdenyすべきではありませんし、この日本語ブログに英語やポルトガル語のコメントが付くこともあります。投稿者の端末の都合も考慮したいところです。最近は非ASCII文字を混ぜてくるSpambotもあるらしいので実効性にやや疑問を感じます。
私がやっているのは、コメントスパムに現れる特定の文字列に着目して、それを含むコメントをdenyするという方法です。上記のエントリーのものを若干変更して以下のようなプラグインを使っています(下記はプラグインのコア部分だけ)。
use strict;
MT->add_callback('CommentFilter', 10, 'Reject Spam Comments', sub {
my ($eh, $app, $comment) = @_;
return ($comment->text !~ /PATTERN/i);
});
1;
「PATTERN」の部分を明示していませんが、この部分には例えばコメントスパムに含まれがちな特定のタグを書いておくと非常に効果があります。以下のエントリに具体例を含むプラグインを公開しています。
Ogawa::Buzz: Quasi-Spam Filter Plugin
STEP 3: 再構築の負荷を低減する
「TypeKey + 承認付き」にしている場合、MT 3.121までのバージョンでは承認付きコメントが投稿されたときにも再構築が発生します。したがって、STEP 2の方法でdenyできない限り、DoSとしてのコメントスパムは依然有効です。また、スパムでなかったとしても承認時点で再構築されるのが望ましいでしょう。MT 3.14では再構築が発生しませんが、「コメントが登録されたら(メールで)通知する」ように設定していても、承認付きコメントに対して通知されなくなります。
まとめると承認付きコメント投稿時の動作は、バージョンによって以下のように異なります。
| バージョン | 再構築の有無 | 通知の有無 |
|---|---|---|
| 3.121まで | あり | あり |
| 3.14 | なし | なし |
| 望ましい動作? | なし | あり |
3.14の動作でもよいのかもしれませんが、私自身は再構築「なし」、通知「あり」というのが好みなので、以下のようなパッチを当てています。このパッチはMT 3.121用です。
--- lib/MT/App/Comments.pm.bak 2004-11-24 18:43:21.000000000 +0900
+++ lib/MT/App/Comments.pm 2005-01-22 17:12:13.000000000 +0900
@@ -346,29 +346,25 @@
$blog->touch;
$blog->save;
- # Rebuild the entry synchronously so that if the user gets
- # redirected to the indiv. page it will be up-to-date.
- $app->rebuild_entry( Entry => $entry )
- or return $app->error($app->translate(
- "Rebuild failed: [_1]", $app->errstr));
- # Index rebuilds and notifications are done in the background.
- MT::Util::start_background_task(sub {
- $app->rebuild_indexes( Blog => $blog )
+ if ($comment->visible) {
+ # Rebuild the entry synchronously so that if the user gets
+ # redirected to the indiv. page it will be up-to-date.
+ $app->rebuild_entry( Entry => $entry )
or return $app->error($app->translate(
"Rebuild failed: [_1]", $app->errstr));
- my $send_notfn_email = 0;
- if (!$commenter) {
- $send_notfn_email = !$comment->visible();
- } else {
- $send_notfn_email = !$commenter_has_comment
- && !$comment->visible();
- }
- if ($blog->email_new_comments || $send_notfn_email)
- {
+ # Index rebuilds and notifications are done in the background.
+ MT::Util::start_background_task(sub {
+ $app->rebuild_indexes( Blog => $blog )
+ or return $app->error($app->translate(
+ "Rebuild failed: [_1]", $app->errstr));
+ });
+ }
+ if ($blog->email_new_comments) {
+ MT::Util::start_background_task(sub {
$app->_send_comment_notification($comment, $comment_link,
$entry, $blog);
- }
- });
+ });
+ }
}
}
MT::Util::start_background_task(
MTCommentFieldsはstaticオプションによって生成されるコメントフォームにstaticという名前のhiddenフィールドを生成します。
<input type="hidden" name="static" value="0" />
<input type="hidden" name="static" value="1" />
このstaticフィールドは、フォームのサブミット後、およびTypeKeyサイン・イン/サイン・アウト後、に誘導するページを「mt-comments.cgiが生成するコメント・リスト」にするか、「個別エントリーアーカイブ」にするかを選択する機能を持ちます。
問題になるのは、staticオプションとしてあらかじめ定められた静的な値(0/1)しか設定できないということです。ここで自然な拡張を試みます。
このパッチは、MTCommentFieldsのstaticオプションの振る舞いを以下のように変更します。
<input type="hidden" name="static" value="0" />
<input type="hidden" name="static" value="1" />
<input type="hidden" name="static" value="MTCommentPreviewIsStaticの値" />
つまり、MTCommentFieldsにstaticオプションを与えない場合、直前のフォームで入力されたstaticの値に従ったinputフィールドを生成します。これにより、コメントポストのエントリポイントとなるテンプレート(「mt-comments.cgiが生成するコメント・リスト」または「個別エントリーアーカイブ」)においてstaticかdynamicかを指定すれば、その後遷移するすべてのフォームにおいてその指定が有効になります。
このパッチは以下のエントリにあるようなコメンティングシステムを支援することができます。
小粋空間: ポップアップ画面を用いたコメント投稿（その3：公開テンプレート修正方法）
またそれだけではなく、誤ったstatic値をテンプレートに記述してしまうことで生じる混乱を避けることができます。例えば、個別エントリーアーカイブではstatic=1としてあるのに、コメントプレビューやコメントエラーのどちらか、あるいは両方にstatic=0と記述すると、コメント後に誘導されるページが状況によって異なるという混乱が生じます。が、こうしたテンプレート記述時の人為的なミスを幾分自動的に避けられます。
Movable Type 3.1(日本語版じゃなくて英語版)は現在beta testフェーズにあります。このバージョンで追加された機能はこの辺り(Movable Type 日本語版サイト: Movable Type 3.1の主な新機能について)で確認できますが、私にとってはアプリケーション・レベルのコールバック機能の追加が一番重要な変更で、それ以外は枝葉末節でしかありません。
ではこの機能がどのようなことに使えるかというと、例えば今流行っている「日本語を含まないコメントはSpamとしてRejectする」などの改造は、以下のようなごく簡単なプラグインとして実現できてしまいます(自分でこのプラグインを使うつもりはありませんけれど…)。このプラグインを拡張してルールを追加・変更するのも簡単でしょう。
また、Ogawa::Buzz: Trackbackの脆弱性で話題になっていたような改造も以下のようなごく簡単なプラグインとして実現できてしまいます。この種の脆弱性は時々刻々と発見され、対処する必要がある性質のものですから、プラグインの形でincrementalに対策できるメリットは大きいと思われます。
サンプルプラグインを作ってみて分かったのは、結構強力な機能だということです。もちろん、CommentFilterやTBPingThrottleFilterなどと言った有用なコールバック用のフックがアプリケーション側でちゃんと定義されていることが肝なのですが。
念のため断っておきますと、Movable Type 3.01以前のバージョンでは動作しません。まだ公開されていない3.1以上のバージョンが必須です。ベータテストに参加していない方は、3.1公開まで素直に待ちましょう。
ここで書いている内容はすでにobsoleteです。MTCommentFieldsはpreview="1"オプションを付けることでCommentPreviewBodyを展開してくれるように修正されています。ご注意ください。 2004.07.15記
Movable Type 日本語版サイト: Movable Type 3.0 Developer Edition 日本語ベータ版をお届けします
alfabeat: MovableType 3.0D日本語版がリリース
とかっていう具合に日本語版リリース作業が進んでおり、私も自分のページでBug fixを公開したり、ベータテストのページ(Beta Weblog)でパッチを流したりしているわけです。
が、当初から何かの冗談ではないかと思っているのが、Comment Preview Templateなどに使われているMTCommentFieldsタグです。Comment Preview時のFormを展開してくれるタグなのですが、前のページで入力したCommentBodyをTextareaに展開してくれません。コメンター情報(Author、Email、URL)も展開してくれません。ソースのどこを読んでもそんなこと書いてないわけで当然と言えば当然なのですが...。
lib/MT/Template/Context.pmの中にあるMTCommentFieldsタグをガリガリ書き換えてもいいのですが、以下のようにComment Preview Templateなどの<MTCommentFields>の直後にJavaScriptを追加することで対処するのがよいでしょう。
<MTCommentFields>
<script language="javascript" type="text/javascript">
<!--
if (document.comments_form.author)
document.comments_form.author.value =
'<$MTCommentPreviewAuthor encode_js="1"$>';
if (document.comments_form.email)
document.comments_form.email.value =
'<$MTCommentPreviewEmail encode_js="1"$>';
if (document.comments_form.url)
document.comments_form.url.value =
'<$MTCommentPreviewURL encode_js="1"$>';
if (document.comments_form.text)
document.comments_form.text.value =
'<$MTCommentPreviewBody convert_breaks="0" encode_js="1"$>';
-->
</script>
上記は、Ogawa::Buzz: Movable Type 3.0DEのバグフィックスで説明しているdefault-templates.zipで修正できます。