[mew-dist 28270] Re: mew and Thunderbird

[Kazu Yamamoto ( 山本和彦 )]

山本です。

> Mew は case を気にしないが、Enigmail 側は case を区別したはずで、
> Mew が送る CT: を Enigmail は解釈できず、Enigmail から Mew へは問題な
> かった記憶があります。Mew から送る CT: をこっそり書き換えると Enigmail
> でも読めたはずです。

念のため、RFC 1847 について、説明しておきます。

Mew では、以下のようなメールを生成します。

Content-Type: Multipart/Signed; protocol="application/pgp-signature";
 micalg=pgp-sha1; boundary="--xxxx--"
Content-Transfer-Encoding: 7bit

	Content-Type: Text/Plain; charset=iso-2022-jp
	Content-Transfer-Encoding: 7bit

	Content-Type: application/pgp-signature
	Content-Transfer-Encoding: 7bit

RFC 2045 において、Content-Type: の値は、大文字小文字を区別しないと定義
されています。(application/pgp-signature と Application/Pgp-Signature
は同じ意味。)

RFC 2045 において、パラメータの値は、大文字小文字を区別すると定義されて
います。(application/pgp-signature は正しく、
Application/Pgp-Signature は間違い。)

Security Multipart の RFC 1847 では、protocol パラメータの値が第二パー
トの Content-Type: の値を指すと定義されいます。大文字小文字を区別するも
のが、大文字小文字を区別しないものを指すのです！

誰が見てもおかしいでしょう？ 作者に問題を指摘したところ、バグだと認めま
したが、直そうとはしませんでした。(僕は、このいい加減な対応に怒っていま
す。:p)

Mew は CT: の値に先頭が大文字の文字列を使いますが、Security Multipart
だけは全部小文字の値を使っています。Security Multipart の(よく考えられ
ていない)例題がそうなっており、そうしないと相互接続がうまく行かないこと
が頻発すると予想されたからです。

P.S.

RFC 2047 は、決定するのが難しいのが誰も使わない micalg を指定しなければ
ならず、さらにその micalg は署名で守られていないなど、品質に問題があり
ます。

作者たちが Multipart/Signed を強く押し、CT: text/pgp-signature の策定を
拒んだので、PGP のクリア署名が使われなくなりました。しかし、PGP/MIME は
普及したとは言いがたいです。彼らは、その責任を取ろうとはしていませ
ん。。。

--かず