> マルチバイト文字とASCIIなどを別々に扱う

この提案の仕方は良いですね。

言語に関わらず統一的に分解できれば一番いいのですが。
実は現在のtokenizerはUCS2をUTF8に変換し、strtokで分解しています。やめてくれー。
で、マルチバイト文字が出てきたらそれをUCS2に変換してi18n scannerで分解し、さらにUTF8に変換して辞書に載せるという…。やめてくれー。

> SubjectをMIMEデコード後に走査する件は、「ジャンクを作成したタイミングのソースはエンコード前の状態であるからデコードしてから走査するのが自然である」ということを主張するしかないのでしょうか。これも、オプションスイッチで「MIMEデコード後にヘッダ内を走査」とか選択肢をユーザーに認識させて、速度低下に対する認識の保険が必要なように思います。

これは問題にはならなさそうですね。MIMEデコードのオーバーヘッドなんてのはたかが知れてるので。ほとんどの場合、メール一通につき一回通るだけでしょうし。

> ＃ でも現行の方式でヘッダ込みで無理やりジャンクに特定できるのも捨てがたいです。（意図した機能でないとしても）
> これは相手のメールアドレスを「アドレス帳に登録済みはジャンクとしない」という機能と同様にEudoraのベイジアン・フィルタと同じように「登録アドレスはジャンクとして扱う」という機能が有れば便利です。

これはやっぱり、トークンの賞味期限を設定する必要がありますね。
ヘッダも何も、区別せずに全部受け入れて、使われなくなった古いのは捨てる、というアプローチは単純でエレガントだと思います。
training.datの互換性がなくなりますけど。

> また、メッセージフィルタの方と自然に連携できる仕組みも必要だと思います。（今は一発で出来ない）

連携というのは具体的にどういう機能でしょうか。
メッセージフィルタで分類して、同時にジャンク・非ジャンクに学習させるとか？

個人的には、ジャンク・非ジャンクの学習数はなるべく少ないほうがうまく動くような気がしています。数よりも、種類が大事なのかな。いろいろ学習させる。
初期に少数のメールで学習した後、失敗したやつだけ再学習させていく程度のほうが、最終的にはうまくいくような気がします。

> これは、ジャンクフィルタ機能にもextensionが利用出来るような仕組みを作っておいて、後で追加するという方法をとればThundebirdの本体（再ビルドやビルド対象ソースのことなど）を気にせずに開発できるようになるかも知れませんね。（つまりトークンの解析機能を外出ししておけば今まで通りの機能でよいか、漢字仮名混じりのトークンが必要かをユーザーが選択できる、とか）

そうですね。同じことを考えてました。
辞書に単語を登録するインタフェイス、メッセージのトークン化を依頼するインタフェイスを露出させておいて、JavaScript側でトークン分離の処理をするという。
でも、XPCOMインタフェイスの書き方がよく判らないのと、Javascriptでは満足な速度が得られないであろうこと、色々選択肢があっても最終的に必要なのはベストの一つになるはず、と思ったので、これは断念しました。