Status: RESOLVED
Resolution: INVALID
ってことで、「バグじゃないよ、終わり」だそうです。


大丈夫だと思います。
実例あるし。


UI はまだしもバックエンドの修正なんてぜんぜん把握できてないですorz
特にエンコード/デコード周りなんて……
想像するしかないのがつらいところ。


Mozilla 全般として、非 ascii 圏の文字コード事情に無頓着な人ばっかりですからねぇ。
こっちからプッシュしないと理解してくれないし。
ああ、援護射撃してくれる人が大勢欲しい。


さすがにそれは通らないと思います (^^;
通すにしても、ほんとに一時しのぎとして正攻法なパッチをだせるようにしないと……


extensions.enigmail.warnIso2022jp でググるとけっこう参照してる人は多そうなんですよね。
そんな人が今回の問題に気づいて応援してくれるといいんですが。

_________________
[Desktop] Windows 10 Pro 22H2 (64bit) / Intel Core i7-2600 / Nvidia GeForce GTX 1650 GDDR6 / 32 GB Memory
[Laptop] Windows 10 Pro 22H2 (64bit) / Intel Core i5-520M vPro / Intel HD Graphics / 8 GB Memory
[Android] Android 13.0 (arm64) / Xperia 5 III (XQ-BQ42)
常用環境: Firefox ベータ版、リリース版 (Win64 x86-64, Android), Thunderbird ベータ版、リリース版 (Win64 x86-64)
テスト環境: Firefox (ESR, Nightly, Win64 x86-64, Android)
Cai/1.0 (Homo sapiens; N; Homo sapiens chemist; male; rv:0.0.4.2+)
-- いつまでたっても nightly

Thunderbird 2.0.0.22 (Windows) では、送信時の既定の文字エンコーディングを ISO-2022-JP に設定しているとき、 Subject, body ともに US-ASCII だけで記述すると、 charset は UTF-8 ではなく ISO-2022-JP になります。(1)

さて、そのことを踏まえて、 PGP/MIME を使わずに暗号化を含む処理を行う場合を考えます。

この場合、 body は ASCII armor 形式、つまり US-ASCII だけになります。 body が US-ASCII だけですから、 Subject も US-ASCII だけで記述してやれば、前述の挙動から言えば、 charset は ISO-2022-JP になるはずです…が、期待に反して charset は UTF-8 になってしまいます。また、このとき作成したメールの body にある ASCII armor 形式のテキストをコピーし、新規に作成したメールの body としてペースト、 Subject を US-ASCII だけで記述した上で送信すると、 charset は期待通りの ISO-2022-JP になります。

これらのことから、 Enigmail が charset を UTF-8 に 生成? 改変? してしまっているのだろうと推測しています。(2)

(1) 本来はこの挙動はおかしい(MIME には最小の文字コードを指定しなければならない規則がある http://www.mew.org/Newsletters/4.html らしいので、この場合の charset は US-ASCII になるのが正しい)のですが、それはさておき(^^;
(2) UTF-8 の文字列に対して暗号化を含む処理を行っているのであれば、この改変でも整合性があると言えるかもしれませんが、 ISO-2022-JP の文字列に対して暗号化を含む処理を行っている現状では、この改変は整合性がないと感じます。仮に「UTF-8 でいいんじゃない?」ということで、そのように実装されているのであれば、クリアテキスト署名のときだけ ISO-2022-JP で処理されるのはバグだと思いますし、暗号化を含む処理が ISO-2022-JP の文字列に対して行われる(その上で charset が UTF-8 になる)というのも、バグだと思います。

あぁ～　なるほど。　まず、Thunderbirdで強制エンコード指定で試すというのは思いつきましたが成功してもThunderbirdのおかげになるのでやめたんです。その上でコピ＆ペを試されたとは　m(_ _;)m
これはテキスト形式については当面の回避方法になるのかな。
強制エンコード指定を設定しておいて、いきなり送信せずに暗号化した状態で保存して、新規メールにコピ＆ペ、ですね。
私のやり方がド下手なのか、失敗してUTF-8になります　(-_-;)
あとで練習します。

そうか、Enigmailがエンコード指定を渡していないのではなくて、無理やりUTF-8を渡しているということですね。
結局はextensions.enigmail.warnIso2022jpの処理が抜けただけということなのかなぁ。
テキスト形式署名のみの場合はEnigmailは本文を触らないからThunderbirdがiso-2022-jpを付けているのだろうと思います。（厳密に言えばPGPブロックを付けているんですけど）

(1)のMIMEパート内の文字コード指定については山本さんが書かれた http://www.mew.org/Newsletters/3.html を参考にしてもらうと初心者の方でも理解してもらえるかも知れません。
これ、不断さんの提示されたページの前のページですけど。

なるほど、そこが原因でしたか。
少なくとも 2.0 系列に関しては regression で押せそうな感じですね。
3.0 系列は……どうしよう……

_________________
[Desktop] Windows 10 Pro 22H2 (64bit) / Intel Core i7-2600 / Nvidia GeForce GTX 1650 GDDR6 / 32 GB Memory
[Laptop] Windows 10 Pro 22H2 (64bit) / Intel Core i5-520M vPro / Intel HD Graphics / 8 GB Memory
[Android] Android 13.0 (arm64) / Xperia 5 III (XQ-BQ42)
常用環境: Firefox ベータ版、リリース版 (Win64 x86-64, Android), Thunderbird ベータ版、リリース版 (Win64 x86-64)
テスト環境: Firefox (ESR, Nightly, Win64 x86-64, Android)
Cai/1.0 (Homo sapiens; N; Homo sapiens chemist; male; rv:0.0.4.2+)
-- いつまでたっても nightly

門前払いってやつですか。

まだ無視されてますよ。無視され続けたら次はRFC違反だ！　っていうのを送るつもりです。
それとも、バグに気付いて長考中なんですかね。　門前払いを食わせた直後のバグ発覚なので落ち込んでいるとか。

私もThunderbirdやEnigmailの内部処理はわからないですよ。ただ、MIME処理はPGP/MIMEだろうが添付ファイルだろうが、S/MIMEであろうがMIMEパートを纏めて後始末をするのはMUAのはずなのでMUAに備わっていると思っています。
いつか、パスワードの処理の話題の時に あさんがソースコードの在処を提示してくれたときにソースメンバ名だけ見たことがあって、MIME処理を表す名前のソースコードが有ったのは覚えています。

それはEnigmailだけじゃなくてThunderbird本体も同じと言うことですね。あぁ、Firefoxとかも。
英語は書くのが苦手です（読むのも苦手ですけど）　翻訳は英語の読解力じゃなく、ボキャブラリでもなく、想像力で賄っているだけです。
絶対に喧嘩は出来ません。長距離からハンドガンで援護射撃するしか．．．

多いですね、だいたいそこには私のWeblogがリンクされているってパターンが多そうです。
ただし、実戦で利用している人は少なそうです。私も今回翻訳中のモノを使用して相手から注意を受けて気付いたんですが、自分で自分宛に、しかも同じThunderbirdで受信していたら普通に復号して文字化けもしないので気付きません。
それだけ実戦で使っている人が少ないんだと思います。


ところで、MLの方ですが、
無視されたら不断さんが書かれている内容を送り付けようと思っています。難しすぎて英語に出来ないんですけど　(-_-;)

3.0は、
まずは、あ さんに登場していただいて、
本当にThunderbirdにエンコード指定を通知する仕組みが無くなってしまったのかどうかを確かめることですね。　(^^;)

本当なのか、それとも同じバグが原因でThunderbird 3.0が受け取ってくれないと思い込んでいるだけなのか、ですね。

手元の環境では、

1. メインウィンドウの [ツール(T)] - [オプション(O)...] - [表示] - [書式] - [フォント(F)...] で開く [フォントと文字エンコーディング] ダイアログの [送信メッセージ(U):] と [受信メッセージ(I):] を「日本語 (ISO-2022-JP)」に設定する。すべての受信メッセージに既定の文字エンコーディングを適用する(P)] と [返信メッセージに既定の文字エンコーディングを適用する(H)] はいずれもオフ。
2. メインウィンドウの [ファイル(F)] - [新規作成(N)] - [メッセージ(M)] で新規メール作成ウィンドウが開くので、メールを作成する。このとき、本文は US-ASCII 以外を含んでも構わないが、 Subject は US-ASCII 以外を含まないように記述する。
3. 本文の編集が終わったら、メール作成ウィンドウの [OpenPGP(N)] - [このメッセージに署名(S)] および [OpenPGP(N)] - [このメッセージを暗号化(E)] にチェックを入れる。
4. メール作成ウィンドウの [ファイル(F)] - [後で送信(L)] すると、秘密鍵に対応するパスフレーズを聞かれるので、入力する。
5. メインウィンドウの「ローカルフォルダ」の「未送信」フォルダにメールが保存されているので、当該メールを選択し、メインウィンドウの [表示(V)] - [メッセージのソース(O)] を実行すると、ソース表示ウィンドウが開く。
6. 表示されているソースの「-----BEGIN PGP MESSAGE-----」から「-----END PGP MESSAGE-----」までをコピーする。
7. メインウィンドウの [ファイル(F)] - [新規作成(N)] - [メッセージ(M)] で新規メール作成ウィンドウが開くので、メールを作成する。
8. 本文に先ほどコピーした「-----BEGIN PGP MESSAGE-----」から「-----END PGP MESSAGE-----」までをペーストする。このときの Subject は US-ASCII 以外を含んでも構わない。
9. メール作成ウィンドウの [ファイル(F)] - [後で送信(L)] する。
10. メインウィンドウの「ローカルフォルダ」の「未送信」フォルダにメールが保存されているので、当該メールを選択し、メインウィンドウの [表示(V)] - [メッセージのソース(O)] を実行すると、ソース表示ウィンドウが開く。
11. Subject は ISO-2022-JP でエンコードされている。 Content-Type は text/plain; charset=ISO-2022-JP になっている。 Content-Transfer-Encoding は 7bit になっている。

といった感じです。

PGP/MIME を使う場合だけを見れば、全てのケースで、 Subject, body とも、問答無用で UTF-8 に変換された上で PGP 処理されることから、わたしもそういう推測をしたと思います。

しかし、 PGP/MIME を使わない場合を見ると、 body については、実は全てのケースで ISO-2022-JP に対して PGP 処理が行われています。

• 署名のみのときは ISO-2022-JP に対して PGP 処理を行い、 charset=ISO-2022-JP としている。 Subject は ISO-2022-JP でエンコードする。
• 署名 + 暗号化のときは ISO-2022-JP に対して PGP 処理を行い、 charset=UTF-8 としている。 Subject は UFT-8 でエンコードする。
• 暗号化のみのときは ISO-2022-JP に対して PGP 処理を行い、 charset=UTF-8 としている。 Subject は UTF-8 でエンコードする。

仮に extensions.enigmail.warnIso2022jp の処理が抜けている / 意図的に抜いた のだとすると、 Subject, body ともに UTF-8 に変換された上で PGP 処理されるだろうと思いますので、　一部のエンコードで発生する問題に、その都度、対応するのが面倒臭い。 → 全て UTF-8 で処理するようにしよう。 → extensions.enigmail.warnIso2022jp の処理を抜こう。 → PGP/MIME を使用する場合については抜いた…が、 PGP/MIME を使用する場合については抜き忘れている / きちんと抜ききれていない 。　といった感じなんじゃないかなーと、勝手に想像しています(^^;

はじめまして。rigarashと申します。

Thunderbird+Enigmailは、署名の検証時に公開鍵の自動ダウンロードがあるので気に入って使っています。日本語化もされていて、現状他のMUAに移れないです。

さて、Thunderbird(nightly)+Enigmail(nightly)での運用があまりうまくいかず、Thunderbird 2.x系列に戻ってきて利用しています。なぜうまくいかないかを自分なりに検索しているうちにここにたどり着きました。

さて、OpenPGPのメールフォーマット(not MIME)に関しては、最新のRFCはRFC4880ですよね？

そうすると、Thunderbird 2.x + Enigmail 0.96でISO-2022-JPのメールに署名して送信するときのメールはRFCに照らすとまずいような気がするのですが、どうでしょうか？
RFC4880 6.2節(Page 54)によると、

とあり、Armor Header KeysにCharset指定がないと、署名/暗号対象の文章のEncodingはUTF-8とみなすべきである、と僕には読めます。すると、現行、Thunderbird 2.x(日本語版)の初期設定では「メールをISO-2022-JPで送信する」となっており、メールヘッダにContent-Type: text/plain; charset=ISO-2022-JPが指定され、実際メール全体がISO-2022-JPで送信されるのですが、Enigmailの初期設定ではArmor Header KeysにCharsetの指定はありません。(メール全体の)Content-Typeヘッダでのcharsetの指定はともかく、(Armor Header Keysの)Charset指定はしてないと完全RFC4880準拠なMUAでは文字化けすることになり、まずい気がします。

さらに、悲しいことに、上記引用の最終行に、「実装は(Armor Header KeysのCharset指定を)無視して(PGP ARMOR BLOCK内の)すべての文章をUTF-8とみなしてもよい、とあります。すると、Thunderbird/Enigmailの実装者からみると、RFCに準拠することを考える限り、すべてのテキストをUTF-8に変換するほうが、規格により準拠した安全な実装、ということになってしまうと思われます。

すると、今後のEnigmailの実装の方向性としては、もし暗号化メッセージならメール全体(あるいはMIMEの各パート)のContent-TypeヘッダのcharsetはUS-ASCIIになったとしてもRFC違反ではないので、Armor Header KeysにCharsetを指定できるようにする(デフォルトはUTF-8)しかないような気がしますが、どうでしょうか。

さらに、RFC4880準拠だけをかんがえるのであれば、署名の際にコンテンツをUTF-8に変換するのは全く合法なので、ISO-2022-JPで使えない、というバグがINVALIDになっていても仕方がないような気がします。

全部 UTF-8 化が流れなんですかね、やっぱり。
http ならまだしもメールでこれをやられると過去の遺産との挟み撃ちで身動きが取れなくなりますorz
ただ、これだと ISO-2022-JP 以外にも被害を受けてるエンコードがあってもいいはずなんですが他には聞かないですね……


--rfc2440 スイッチを使う限りこの問題は避けて通れていたのですが、extensions.enigmail.warnIso2022jp の処理が抜けたせいで逃げられなくなってしまったようですね。
実装としては「Thunderbird がメール作成に用いているエンコードを Armor Header Keys の Charset として自動的にセットする」と言った感じでしょうか。

_________________
[Desktop] Windows 10 Pro 22H2 (64bit) / Intel Core i7-2600 / Nvidia GeForce GTX 1650 GDDR6 / 32 GB Memory
[Laptop] Windows 10 Pro 22H2 (64bit) / Intel Core i5-520M vPro / Intel HD Graphics / 8 GB Memory
[Android] Android 13.0 (arm64) / Xperia 5 III (XQ-BQ42)
常用環境: Firefox ベータ版、リリース版 (Win64 x86-64, Android), Thunderbird ベータ版、リリース版 (Win64 x86-64)
テスト環境: Firefox (ESR, Nightly, Win64 x86-64, Android)
Cai/1.0 (Homo sapiens; N; Homo sapiens chemist; male; rv:0.0.4.2+)
-- いつまでたっても nightly

この Armor Header Keys についてですが、わたしの認識と実験結果に誤りがなければ、暗号化を含む処理を行った場合には Charset ヘッダ「Charset: ISO-2022-JP」が付加されます(1)。しかし、署名のみを行った場合には Charset ヘッダが付加されません(2)(3)(4)。



問題がないわけではありませんが(5)、これがベターだと思います。もちろん、その前に extensions.enigmail.warnIso2022jp の処理が(中途半端に?)抜けていると思しき問題を修正して貰う必要があるわけですが、その問題は「ISO-2022-JP などへの個別対応を行わずに UTF-8 に強制変換して処理するようにした(からバグじゃない)」として、スルーされそうな気もします(6)。


(1) 当該 ASCII armor ブロックを復号すると、 ISO-2022-JP な文字列が得られます。
(2) その代わりなのかどうかはわかりませんが、メール全体の Content-Type が plain/text; charset=ISO-2022-JP になります。
(3) PGP/MIME を使った場合は、全てのケースで「Charset: ISO-2022-JP」は付加されません。
(4) Ref. http://kiyo.chips.jp/blog/archives/2009 ... ment-10800
(5)メール全体の Content-Type を Armor Header Keys の Charset に一致させると、 ASCII armor のみ(US-ASCII のみ)の body に対して、 US-ASCII 以外の Content-Type を指定してしまう場合があり得るわけで、規約に準拠という意味では、この方法はあまり好ましくありません。かといって、一致させなければ、文字化けを起こすメーラが相当数出てくるだろうということが容易に想像できるわけでして…。
(6) ISO-2022-JP で処理される場合と UTF-8 で処理される場合とが混在している状況を指摘して、「その挙動は統一感がないので、ひとまず、従来の挙動に戻してくれまいか?」と攻めるのもアリかもしれません。いや、そうすると逆にますます UTF-8 への強制変換が進んでしまうかもしれません…。なかなか悩ましいところです(^^;;;

ちょっと混乱してきました。自分の理解のために整理してみます。送信時にEnigmailとしては、RFC準拠(で他のMUAとの相互運用がうまくいく)にすることが必要だ、と私は理解しています。

情報をありがとうございます。とすると、いったん過去とのつながりを忘れたと仮定して、RFC4880に準拠して送信するときの挙動は以下のようになります。

1. RFC4880形式で署名のみのメール
   コンテンツのEncodingがUTF-8であれISO-2022-JPであれArmor Header KeysのCharsetヘッダはつかない。この挙動は、コンテンツがUTF-8であればRFC準拠だが、ISO-2022-JPならRFC違反のため、Enigmailへのバグ報告が必要。なお、Armor Header KeysへのCharsetヘッダの実装はMAY(任意)なので、ISO-2022-JP対応コードがdropされる可能性はあるが、日本人で実装をつくって送ることができれば取り込んでもらえると信じています。
   また、さすがに署名のみの文章にArmor Header KeysのCharset:が指定してあって問題となる他のクライアントがあるとは考えていません。
   さて、この際のメールヘッダのContent-Typeの中のcharset指定は、Armor Header KeysのCharsetヘッダの指定と同じになるべきです。なぜならメール全体のcharsetは本文のcharsetにはずだからです。
2. RFC4880形式で暗号化したメール
   コンテンツのEncodingがISO-2022-JPならArmor Header KeysのCharsetヘッダがつく。これは、CharsetヘッダがなければUTF-8とみなされる、という規格に準拠したものである。ここにEnigmailのバグはありません。
   次にメールヘッダのContent-Type中のcharset指定をどうするか、という問題ですが、fudan10uさんが引用されたhttp://www.mew.org/Newsletters/4.htmlをみるとUS-ASCIIになるはずです(RFC2822上charsetのデフォルトなので省略されていてもよい)。しかしながら、ISO-2022-JPもUTF-8もUS-ASCIIの上位互換なので、Armor Header KeysのCharsetヘッダ指定にかかわらず、ISO-2022-JPとUTF-8のどちらかが指定されていてもRFC違反とは言い切れないように思います(これは本来のコンテンツがISO-2022-JPで書かれていて、暗号化されたメールのContent-Type中のcharsetがUTF-8とされるケースとその逆の双方とも)。
3. PGP/MIMEで署名のみ行ったメール
   署名対象となるPartのContent-Type中のcharset指定があるので問題なし。
4. PGP/MIMEで暗号化したメール
   pgp-encryptedなPartの内容はRFC4880のものと形式は等しいので、Armor Header KeysのCharsetヘッダに指定すればよい。
   pgp-encryptedなPartのContent-Type中のcharset指定に関しては、上記「RFC4880で暗号化したメール」の際と同じ。

すると、少なくとも上記4通りを満たす作法で送信されてきたメールを正しく処理するためには、Armor Header KeysのCharsetヘッダの情報のみで復号することが必要のように思われます。

わかりました、出来ました。
出来なかった理由は、最初の暗号化の後「保存する」で保存していました。「後で送信」なんですね。それのPGPブロックをコピ＆ペして送信したメールはiso-2022-jpのテキスト形式暗号でした。
「保存する」で保存したときは PGP/MIMEでUTF-8なんです。


ところで、
ぜんぜん関係ないですが　私はFireGPGというアドオンを入れて（正確に言うと外すのを忘れていた）いるんですが、不断さんの説明の中の「----- BEGIN PGP MESSAGE-----」に過剰反応してしまって、復号しようとして失敗しているんです。こういうのは初めてなのでビックリしました。
編集：これが邪魔でRFC4880が読めなくなったので削除しました

rigarashさん、はじめまして。
もしかしたら初めてじゃないかも。
＃ 不断さんも ですが、どこぞのMLで既に実名で知り合いだということも．．．
＃ iijとかkuniとか相互検証とか．．．PGP人口少ないし

そういうことが出来るMUAって無いですよね？　何でも出来るMewなら出来るのかなぁ。

RFC4880については勉強不足というか、興味が無かったのでよく知りませんが。難しい話になっていますね。

まぁ、いつのまにかEnigmailのPGPブロック内にcharsetが復活していたので、なにをヘンなコメントを入れているんだろうと思っていたんですが、RFC4880のPGPブロック内のcharsetの指定だったんですね。（昔から有ったとか？）

今の状態でiso-2022-jpエンコード指定で暗号化した場合はRFC2047の、
The 'charset' portion of an 'encoded-word' specifies the character set associated with the unencoded text.
”符号化以前のテキストの文字セットを記述する”というお約束が守られていないんですよね。PGPブロック内にcharsetが有ればヘッダのcharsetは違っていても構わないってことはないはずです。PGP/MIMEはコンテント・ヘッダに必ずcharsetが有れば問題はないと思いますが。

確かに現状でもエンコード指定をUTF-8にしておけば署名も暗号化も問題はないんですけど。「相手」が有ることなので、それで良いというわけに行かないのが実情です。


Enigmailの処理が一貫性を欠いているというバグは修正して欲しいですけど、RFC4880なPGP/MIME署名のメールは、今までのようにPGPを持たない人には本文が普通に読めて、署名がゴミ添付になるだけ、ということになってくれるかが心配です。
実際に既に相手が居るわけで、相手はRFC4880には対応していないMUAなので、こちらとしては当面の間（いや、ずっと）今まで通りのRFC2440準拠で行きたいんですが。（相手にMUAを変えろとは言えない立場でもあるし）

どっちにしても、元に戻るのは難しいような気もするのでThunderbird3.0 beta3に変えてしまおうかなぁ。

＃ あぁ、EnigmailのMLは無視されたまま

はい。そういう事情もあって、「あまり好ましくありません」との表記に留めました(^^;



既存のメーラとのやりとりを考えるなら、メールヘッダの Content-Type の charset を Armor Header Keys の Charset と一致させることも必要になるのではないかと思います。その上で、検証・復号する時に、 Content-Type の charset と Armor Header Keys の Charset が異なっている場合は、 Armor Header Keys の Charset を採用して、文字化けしないようによきにはからってもらう、というのが嬉しいのではないかと。(1)

(1) Thunderbird + Enigmail で検証・復号する場合に限って言えば、 Content-Type の charset が UTF-8 で、 Armor Header Keys の Charset が ISO-2022-JP と異なっていても、復号結果が文字化けすることはないようです。画面表示フォントとして、 UTF-8 のときに使うようにしているものが採用されているようです。おそらく、 ISO-2022-JP から UTF-8 に変換した上で表示しているのだろうと思いますが、 UTF-8 の範囲に含まれない ISO-2022-JP な文字が含まれている場合にどうなるかはわかりません。