2006年3月22日

[SpamAssassin-JP 113] Re:SpamAssassin-3.1.1日本語対応パッチ(案、その1)

** SpamAssassin メーリングリスト **
** 注意:このメールへの返信は SpamAssassin-jp へ行きます **
滝澤です。

何故かいつの間にか長文になってしまいました。

On Mon, Mar 20, 2006 at 09:28:19PM +0900,
Motoharu Kubo wrote:


> 早速ダウンロードしました。3月中は思うように進まないかもしれませんが、読
> んでみて、試してみたいと思います。

今日一日中、さらにハックしていたので、すでに結構中身が変わっていたりします。
今週末にまたアップします。

> 以前、松田さんと議論したことがあるのですが、JISとShift-JISのスパムで内容
> のニュアンスが異なる場合、従来の使いにくいルール記述方法も役立つのではな
> いか、という意見があるかもしれません。
>
> 従来のbodyなどのテストはそのまま残して、わかち書きしたテキストの処理のた
> めにnbody (またはlbody)などのテストを新しく作る、という方法も検討する必
> 要があるかもしれないですね。でも、この改造はかなり大がかりになって、オー
> バーヘッドも増えるかもしれません。

これに関しては後述します。

> > - 分かち書きはプラグインで有効になるようにする。

> ただ、日本語の場合はTokenizerMeCab/Kakasiでいいですが、これも組み込んだ
> 上で中国語だったら(将来だれかが作るかもしれない)中国語独自の処理プラグイ
> ンも組み込めて、言語によりそれらが使い分けられる、という構造にしておくべ
> きだと思います。まだ詳しく見ていないので、すでに考慮ずみだったら言わずも
> がなのコメントかもしれません。

手元のコードでは言語毎のプラグインを追加できるように修正しました。
言語の特定を行う必要があるので、そのメソッドを作成している最中です。
CJKだけの対応なら出来ているのですが、さらに一般性を持たせたいので
結構面倒。
TextCatプラグインが精度良く使えれば楽なのに。

> > - normalize時に漢字で終わり次の行が漢字で始まる行はunfoldingする。
> > これによりrule判定時の単語の分断を防げる。
>
> これって、MeCabやkakasiが自動的にそのようにハンドリングしてくれませんで
> したっけ?

分かち書きとは別の意図があるため、分けています。

> > - ベイズのトークナイズを行うときに分かち書きを行う。
>
> ここが、いろいろと異論があるところかもしれません。
>
> うまい実例が見当たらないのですが、bodyテストの方でもわかち書きしておかな
> いと、単語の境界の解釈によって、解釈がずれてしまうことが出るんじゃないか
> と思うのですが。

全文検索におけるngramと分かち書きのインデックスの特徴の違いと同じような
ケースになるのですが、どちらも利点・欠点がありますので、慎重に考える必要
があります。

分かち書きの欠点は以前に書いたとおり、マッチさせたい言葉が分断されてし
まうことがある点です。分かち書きも完璧ではない(辞書に依存する)ために、
新しい流行語・造語・略語などには対応できないという点があります。
分かち書きを考慮したルールを書くのはどのように分かち書きされるかを一度
試さないと行けないために少し手間になります。

まあ、ルールの取り扱いやすさとfalse positive, false negativeのバランス
をどうするかということなのですが。

また、大きなパッチになると一般的に本家にマージされにくくなるので、機能
毎に分離した小さなパッチの集まりにしたいと思うのですが。
そういう意味でも、UTF-8 normalization と分かち書きは別にしたいという
意図があったりします。

> > 気になる点
> >
> > - SAは初期化(コンフィグのロードなど)を行う前にメッセージのヘッダの解析を
> > 行うため、そのままではヘッダのnormalizeが有効に働かない。
> > そのため、SpamAssassin->parse()内でinit()を呼び出すようにしたが、これが
> > 問題(副作用)がないか調べる。
> > そもそも何でparse()では初期化していないのか疑問である。
>
> これは、たしかspamassassin-dev MLでも少し話題になっていました。読み返し
> て、何か参考になりそうだったらお知らせします。

何か情報がありましたらお願いします。

> > - ベイズのトークナイズ前に全角空白文字を空白文字に置換した方がよいか?
>
> これはたしかに考慮点ですね。どっちがいいのでしょう?

全角空白文字がベイズ的に意味を持たせるかどうかということなので、持たせても
意味がないということで、空白文字に置換するということで良いでしょうか?


On Tue, Mar 21, 2006 at 07:41:53PM +0900,
MATSUDA Yoh-ichi / 松田陽一 wrote:

> > 以前、松田さんと議論したことがあるのですが、JISとShift-JISのスパムで内容
> > のニュアンスが異なる場合、従来の使いにくいルール記述方法も役立つのではな
> > いか、という意見があるかもしれません。
> >
> > 従来のbodyなどのテストはそのまま残して、わかち書きしたテキストの処理のた
> > めにnbody (またはlbody)などのテストを新しく作る、という方法も検討する必
> > 要があるかもしれないですね。でも、この改造はかなり大がかりになって、オー
> > バーヘッドも増えるかもしれません。

> 下手糞な英語で恥ずかしいことこの上ないのですが、一読して頂ければ
> 幸いです。

読みました。
私の考えでは基本的にはmetaルールでcharsetの評価と組み合わせれば良いのでは
ないかと思っています。
しかし、過去の資産というか血と汗と涙とスパマーに吐いた唾の結晶?のルールを
書き換えるのは大変なことです。
松田さんのルールに限っていえば、今更UTF-8に書き換えなんて出来ない規模に
なっていますし。

> patch を本家にマージしてもらうには、互換性を第一に考慮しなければ
> ならないと思います。
> body ルール対象のプレーンテキストメッセージに対して、 kakasi 或
> は mecab のわかち書き処理と UTF-8 変換を行いますと、従来のルール
> との互換性が損なわれます。
> これは日本語圏だけの問題ではなく、他国語圏を巻き込むこととなりま
> す。
>
> したがいまして、 body ルールはそのままに、新たに body メッセージ
> に対してわかち書き処理と UTF-8 変換を施した "normalized body" と
> いう意のルールを新設し、これに対して UTF-8 による NG ワード記入
> を行う、というアプローチが理想だと思います。

了解です。
bodyとは別のルールを新設する方向で検討します。
新しいルールの追加はちょっと大がかりになりそうなので、もうちょっと時間を
ください。
ちなみにルールの名前は何がよいでしょうか?
思いついたものを並べてみます。わかりやすさと短さからはutf8bodyかなぁと。
- nbody
- normalbody
- normalized_body
- normalization_body
- ubody
- utf8body
設置スイッチ normalize_encoding も何か良い名前がありましたら提案を
お願いします。


また、Encode::Detectについて、インストールスクリプトとか、Encodeとの互換
性問題(単にMozillaから持ってきたものだから)とか、考える必要があるものが
いくつかあります。検出性能は非常にすばらしいのですが。

--
TAKIZAWA Takashi(滝澤 隆史)
http://www.emaillab.org/

--
SpamAssassin メーリングリスト
http://mm.apache.jp/mailman/listinfo/spamassassin-jp

投稿者 xml-rpc : 2006年3月22日 00:49
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/41018
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。