Namazu-devel-ja(旧)

[Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx>]

寺西です。

Yukio USUDA wrote:
> 
> 「Quoted-Printable encodingは、大部分US-ASCII文字セットの印字可能な文
> 字に相当するオクテット（8ビット）からなっているデーターを表現するよ
> う考えられています。」rfc2045の和訳より
> http://www.asahi-net.or.jp/~bd9y-ktu/dtd_f/rfc_f/rfc2045j.html
> というものなのでマルチバイト文字部分以外はそのまま読める状態です。
> 基本的にテキストであること（多くはhtmlでしょう）から積極的に捨てる
> こともないだろうと考えました。

趣旨は理解しました。
私はてっきり添付ファイルを展開するスイッチの意味で --decode-base64 
があるものと思っていたので、誤解しました。

設定にもよるのだろうけど、Netscape だと Quoted-Printable encoding
されたものは添付ファイルとみなされるようで、私の場合、積極的に捨てて
ます。そして、Quoted-Printable encoding されたメールは、私が受け取る
もののほぼ全てが SPAM です。

# 他の人(ごく一般的な人)とは、状況が異なっているのかもしれません。
 
> base64はなにが入っているかわからないので必要と判断した方のみ利用するのが
> よかろうと考えました。

これは、ウィルス関係のためでしょうか、それともとてもファイルサイズ
の関係でしょうか? (両方?)

> あまり深く考えてはいませんので、動作のわかりやすさをとるほうがよければ修正
> します。

とても個人的な要望のような気がしてきましたので、修正が必要とまでは
思えなくなってきました。
(あくまでも、個人的には Quoted-Printable encoding + base64 のデコード
をしないオプションと、base64 のデコードはしないオプションがあると
うれしいですけど。)
 
> 実はwin32-oleフィルターにマクロウィルスつきのms-wordファイルが渡ったときに
> マクロが動き出すのではと不安だったのでbase64はデフォルトで展開しないことに
> したほうがよいかとも考えました。
> oleフィルターがどのような仕組みで動いているのか知らないので詳しい方のご意見
> をいただきたいです。

私も詳しくはないです。マクロ自体は実行するメソッドがあるので、
マクロを処理する能力はそなわっていますよね。
ということは、ファイルを Open した際に自動実行マクロを動かす
ようになっていても不思議じゃないような気はします。
(ウィルス対策で、自動実行しないようにしてある気もするが。)

このウィルス問題は、mailnews.pl の問題ではなくて、win32/ole*.pl の
問題ですね。ウィルスに感染した Office ファイルを処理した場合でも
同じ問題が生じますから。
# まだ、ウィルスに感染すると決まったわけではないので、問題というの
# は、適切ではありません。

一方で、Office ファイルが感染している可能性よりも、メールにウィルス
に感染した Office ファイルが大量に含まれている可能性が何倍にも高い
ので、このことを心配されているのだと思います。

win32-ole がどうなっているかわかりませんが、ウィルスメールを
処理したら、感染してしまうのは、確かに問題です。(まだ、感染するとは
決まったわけではない)
そういう意味ではスイッチがあった方が良いでしょう。そして、注意書き
がいりますね。(事前にウィルスを除去した上で、使用することというような
ものが。)

また、win32-ole でマクロを自動実行しないとした場合でも、
テンポラリファイルにウィルスに感染したファイルが生成されるのは
とても嫌ですね。アンチウィルスソフトによっては、ファイルが生成された
時点で検知するようなものもあったかと思いますので、気持ち悪いです。
この意味でも、事前にウィルスを除去してもらった上で、実行することが
必要ですね。

そう考えると、Quoted-Printable encoding された HTML ファイルに
JavaScript ウィルスが仕込まれていたりすると、感染はしませんが、
処理する度に、アンチウィルスソフトに警告されるかもしれません。

# う〜む。難しい。
# ウィルス除去プログラムまで組み込めないしなぁ。
 
> > 2. 添付ファイルのファイル名の扱いについて、現状はそのまま使って
> >    (nkf でデコードされた結果)いますが、実はここは結構やっかいな
> >    ところです。
...
> 昨年このメーリングリストで話題が出て
> 最終的に添付ファイルの名前をインデックスに入れるのは保留にしたよう
> ですので気にはなっていました。

デコードするしないにかかわらず、ファイル名をせっかく切り出したのなら、
それを検索対象に入れておくのは良いと思います。
 
> 拡張子だけ無事であればよいと考えておりました。
> （渡した先のフィルターで本文に追加していれば入ってしまいますが）
> このあたりは改善の余地ありです。

たぶん、タイトルにも使われるのではないかと思います。
# 実はまだ multipart の処理をきちんと検証できていません。
# ごめんなさい。

> 複数行にデコードされるようなURIを持った添付ファイルが
> ちゃんと処理できるのかなどはサンプルを作って
> 検証をする必要がありそうですね。

はい。とってもバラバラなところなので、検証するのが大変ですが、
こっちでも、サンプルをいろいろ作ってみようと思います。
-- 
=====================================================================
寺西 忠勝(TADAMASA TERANISHI)  yw3t-trns@xxxxxxxxxxxxxxx
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E