[Mew-dist 13124] Re: 1.95b37

[Shun-ichi GOTO]

>>>>> at Mon, 29 May 2000 11:44:21 +0900
>>>>> kazu == Kazu Yamamoto (山本和彦) <kazu at example.com> said,

kazu> (i)  無条件にクオートを外す
kazu> (ii) 複数の encoded-word には対応していない

kazu> です。ので、以下のような、とてもいい加減なパラメータの復号には失敗する
kazu> はずです。

kazu> 	FOO="=? ? ?=
kazu>          =? ? ?="

これ、多分かなり多いですよ。

というか、CT: name= やCDP: filename= を B-Enc するMUAは大部分がこうなっ
てるように思います。ある意味、互いに見習いあってスタンダードになってしまっ
た感があります。

この手のエンコードをするMUA作成者の気持ちを好意的に解釈すると、
(1) attribute=value の value をB-enc する
(2) B-Enc すると76文字を越えてしまう。分割が必要だ。
(3) value はquoted-string が許されている。
(4) RFC822では quoted-string はlinear-white-space が許されている。
(5) という事で、Subject: などと同様に折り返しを行なえば良い。

なんてロジックでこうなってるのではないかと思います。
## あくまでも後藤の勝手な想像です。


メジャーなWin32 MUA でCT: name= や CDP: filename= で B-Enc している例を
以下にあげます。

## Mew/SEMI 以外のMUAでファイル名に漢字を使っているメールをちょいと
## 探すだけで、例はあっさり見つかります。


[1] Lotus Notes (4.5) の場合

Content-Type: application/octet-stream;
 name="Standardization Working Report Ver3
 =?ISO-2022-JP?B?GyRCRTo6bxsoQg==?=
 .doc"
Content-Disposition: attachment;
 filename="Standardization Working Report Ver3
 =?ISO-2022-JP?B?GyRCRTo6bxsoQg==?=
 .doc"
Content-Transfer-Encoding: base64


[2] Becky 1.25.06 の場合

Content-Type: application/octet-stream;
 name="=?ISO-2022-JP?B?GyRCPEI+WjxCODNKczlwPXEbKEIg?=
 ver6f.lzh"
Content-Disposition: attachment;
 filename="=?ISO-2022-JP?B?GyRCPEI+WjxCODNKczlwPXEbKEIg?=
 ver6f.lzh"
Content-Transfer-Encoding: base64


[3] Microsoft Outlook Express 4.72.3612.1700 の場合

Content-Type: application/msword;
	name="=?iso-2022-jp?B?GyRCN1dCLDRvJE5BajhfMT9NUUAtJE44IT5aGyhCLmRvYw==?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="=?iso-2022-jp?B?GyRCN1dCLDRvJE5BajhfMT9NUUAtJE44IT5aGyhCLmRvYw==?="


というわけで、上記のような悪しくもDefact-Standard(?)なパターンを
認めないと、tolerant にする意味も半減してしまいそうです。

--- Regards,
 Shun-ichi Goto  <gotoh at example.com>
   R&D Group, TAIYO Corp., Tokyo, JAPAN