🚀 go-pugleaf

なかたにです。

河野さん>
> In article <395F4A46.48E6FFCA@pop02.odn.ne.jp> , 
>         Koichi Nakatani <kvn@pop02.odn.ne.jp> writes 
> >ISO-2022-JP+base64 を読めない MUA がいまだにはびこっている組織
> >というのは、(もし主に日本語を使っている組織であれば) MIME への
> >対応を怠っている組織、ということになります。
> 
> MIME が読める読めないが問題になっているわけではないですよね?

いえ、まさに MIME が読めるか読めないかが (言い換えれば、
受信側の環境が RFC 2049 の条件を満たしているか否かが)
問題になっている訳です。

> base64 encode されたMIME系のメールは、
> 
>     MIME decode すると、電子メールとしての形式に違反してしまう可能性がある
> 
> ために、どの時点でもMIME encodeされた形式を維持しなければな
> らないからです。これらは、メールの処理を根本から変えてしまい
> ます。なので、MIME encode された形式は、内容に関わる処理系で
> は、基本的に無視することになります。MIME decode するかどうか
> は、基本的にユーザの選択を待つ必要があります。まぁ、それは設
> 計ミスなんでしょうけど、おかげで、メールの検索とかがまったく
> できなくなってしまいます。

この部分には反例があります。 IMAP4rev1 のリファレンス実装として
UW imapd (ftp://ftp.cac.washington.edu/mail/) というものがあります。
よく知られている通り、 POP3 のサーバとクライアントの役割分担に比べて、
IMAP4rev1 というプロトコルはサーバ側の役割が大きくできるように設計
されていて、サーバ側でメールの全文検索を行なう機能なども備えています。
  このとき、たとえば IMAP クライアントから「『毛沢東』という文字列を
検索してくれ」というリクエストが来たとします。 IMAP サーバは、中に
格納されているメールが ISO-2022-JP であれ、 Big5 であれ、 UTF-8 であれ
EUC-JP であれ、その文字列を含むメールを検索できるようになっています。
さらに、 transfer encoding syntax が 7bit であれ base64 であれ問題には
なりません。
  重要なことは、 UW imapd という特定の実装だけでそれが可能になって
いるのではなくて、 IMAP4rev1 というプロトコルの設計自体がそれを可能と
するような実装を要求しているという点です。

# 面白いことに、 IMAP4rev1 の主たる設計者であり UW imapd の実装者でも
# ある Mark Crispin さんは RFC 1468 の共著者のひとりでもあります。

従って、(引用が前後しますが)

> 問題は、そういう構成では、Internet のメールのルールとしては
> 違反しているってことです。

という部分は河野さんの誤解です。メールの中の文字列検索というのは、
Crispin さんが実装したようなレベルでなければ語れなくなっています。

# 同様にして、 encoded-word を含む subject の文字列検索なども
# オニのように複雑ですが、 IMAP 流の解き方はあります。