な、なんと．．．しかも agentがオンになっててパスフレーズが入れられなくて署名無しの暗号しか送れない。（iso-2022-jpになります）

でも、Win版でGnuPG v2.0ってのを初めて見ました。

http://www006.upp.so-net.ne.jp/naoki-s/pgp/enigmail.html の記述によると、



とのことで、どうやら、以前から同様の状況だったようです。(1)



QMAIL3 では試していませんが、少なくとも、手元の Sylpheed 2.7.0-win32 で ISO-2022-JP な文字列を含むメッセージについて PGP/MIME 署名を行うと、 Content-Type は text/plain; charset=ISO-2022-JP で、 Content-Transfer-Encoding は 7bit になります。行末にスペースが含まれる場合は、全て削除された上で、 PGP/MIME 署名が行われます。(2)


(1) サーバのレスポンスによると、当該 URL の Last-Modified は Tue, 30 Sep 2003 19:24:52 GMT らしいですから、少なくとも、2003年9月の時点では、既に同様の状況だったと思われます。

(2) Sylpheed-jp メーリングリストの過去ログや、 Sylpheed の ChangeLog 等を確認せずに書いていますので、盛大に勘違いしている可能性もありますが、記憶によれば、

　以前の Sylpheed では、行末スペースを削除しないまま(本文に手を加えることなく) PGP/MIME 署名が行われていた。
　→一部のメーラで署名検証に失敗することが報告される。
　　→行末スペースを保護するために quoted-printable した後、 PGP/MIME 署名するように変更された。
　　　→被署名パートが quoted-printable されていると、一部のメーラで署名検証に失敗することが報告される。
　　　　→行末スペースを保護することよりも、他のメーラとのやりとりで問題が起きないことを優先して、 quoted-printable するのをやめ、行末スペースを削除することになった。

といった流れだったのではなかったかと。

必要であれば、 Becky! + BkGnuPG で PGP/MIME 署名したメールを送ります。


しかし、今回の件に首をツッコミ始めてから、「PGP 相互検証メーリングリスト」が生きていれば、とか、ニュースグループでやりとりできれば、と何度思ったことか…。
news.mozilla.org がオープンニュースサーバとして提供されていますが、ざっと眺めた感じでは、主に英語圏の開発者向けのようだったので、開発にタッチしていないユーザが、特定の拡張について、日本語でやりとりするのはまずいかなー、と自重しています。
というわけで、誰か enigmail-jp メーリングリスト(仮称)を立ち上げませんか?(^^;

PGP が全くわかっていませんが、今問題となっているのは

• Enigmail を使った場合に、元々 ISO-2022-JP ならば送られるメールでの charset も ISO-2022-JP になってほしい
• Enigmail 0.95.x ではできていたが、0.96 ではできなくなっている

ということで良いでしょうか？

Enigmail のソースを 0.95 と 0.96 とで比較したところ、ISO-2022-JP の場合の処理について

• extensions.enigmail.warnIso2022jp を利用する処理は削除されている。ユーザーに確認するダイアログも削除されている。
• 強制的に UTF-8 にする処理は残っている

となっていて、結果的に ISO-2022-JP ならば有無を言わさず UTF-8 になるようになっています。
また、"ISO-2022-JP" とハードコードされているので、それ以外の charset には全く影響がありません。

どうなるのが正しいのかとか、いったいどういう意図でこんなことになっているのかとかは不明です。

わかりました。この相互検証MLでの行末空白の確認時以外は通常は絶対に空白を入れないので気付かないで忘れていましたが昔のまま変わってなかったということですね。
まぁ、それは運用でカバーですね。（自然にカバーしていたので）

すみません。これも私が最初は"-- "しか入れなかったのでUTF-8になっていたのを見過ごしました。

この最後のは私が作者の山本さんにお願いしてquoted-printableをやめてもらったときですね。　この修正の御礼にいくつかのバグと修正を提示させていただきました。テキスト形式の復号&署名検証以外はバッチリのはずです。


今のところ原因が判ったののでいいかな。ありがとうございます。

いちおう暗号検証用のMLは有るんですが、MUA/PGPに動きが無いので登録者10人未満で投稿は1年以上ゼロです。異なるMUAで多くの参加者があれば有効なんでしょうけど．．．強制参加にしますか？

あさん、気付いてくれてありがとうございます。

登場を期待したのは、
Thunderbird 3.0ではEnigmailのようなアドオンからRFC822ヘッダ（Content-Typeヘッダとか、charsetパラメータとか）の変更が不可能になった、とEnigmailの開発側(Patrick)が言っているらしいのですが、
2.0ではアドオンからRFC822ヘッダの変更が出来ていたのに3.0で不可能になったなんていうことが本当なのでしょうか？　、ということです。
有り得ないと思うんですけど、セキュリティ絡みでそうなったのかな、とも考えられるし。

で、このRFC822ヘッダ（Content-Typeヘッダとか、charsetパラメータとか）をThunderbird3.0に渡せないからUTF-8しか送信出来ないよ、ISO-2022-JPなんて送信出来ないよって言っているらしいんです。
それがです。もし判ればお願いしたいんですが。



え～～～？　削除？　マジですか、それはダメでしょう。
0.95.7の処理が正しくて、必要な処理です。

MLも無視して、Caiさんのバグレポートも解決済みって言っておきながら．．．　(-.-")
ヒドイ兄ちゃんだ

MLに投げました。　Caiさん、できればPatrickのレスが付く前に援護を　(^^;)

「お前～～　解決済みって言ったじゃないか～～～　ソース調べてくれた人が居るんだぜ～」とか
ついでにworkaroundやめてくれ、行末空白は運用でカバーするから、とかも。

これらしいですね。https://www.mozdev.org/bugs/show_bug.cgi?id=21268

いや、ここは何かしらの対応してもらうよう働きかけをした方が良いと思います。

現在、 Thunderbird + Enigmail では、

• 本文中にある行末スペースは、送信前に削除される。しかし、区切り行“-- ”の行末スペースについては、送信前に削除されない。(これらは Thunderbird 本体側の仕様)
• PGP/MIME 署名を行う場合は、強制的に quoted-printable されてしまう(Enigmail 0.96.0)ので、区切り行“-- ”の行末スペースが存在しても問題はない。

状態ですから、 Thunderbird + Enigmail 同士のやりとりであれば、行末スペースに起因する署名検証失敗の問題は起きません。しかし、行末スペースの問題を放置したまま UTF-8 / quoted-printable されなくなったとすると、 Thunderbird + Enigmail ユーザのうち、区切り行“-- ”を記述するユーザとのやりとりで、行末スペースに起因する署名検証失敗の問題が発生するようになります。異なるメーラとのやりとりで発生するならまだしも、 Thunderbird + Enigmail 同士だったりすると、「同じ環境なのに、ちゃんと検証できないなんて、使えねーな。」ということになりかねません。

対応案としては、

■ 送信時に行末スペースを含む場合 (Thunderbird では区切り行“-- ”を含む場合しかないはず)

• Sylpheed のように、本文から全ての行末スペースを強制的に削除(区切り行“-- ”も忘れずに削除)した上で PGP/MIME 署名する。
• 本文を quoted-printable した上で PGP/MIME 署名する。

のいずれかを選択するダイアログを表示する。

■ quoted-printable 等で符号化されていない PGP/MIME 署名メッセージを検証するときに行末スペースを検出した場合

• 行末スペースを削除した上で PGP/MIME 署名を検証する。
• 行末スペースを削除せずに PGP/MIME 署名を検証する。

のいずれかを選択するダイアログを表示する。

あたりではないかと思います…が、多分、「ここまでする必要はない」と判断・スルーされるような気もしています(^^;

ちょっと離れてる間に膨大なコメントが。

状況把握までもう少しお待ちを。
あと、投げるなら 0.96 リリースにぶら下げるんじゃなくて新たにスレッド立ち上げたほうが食いつきがいいような気がします。


むぅ、予想通りといえば予想通りですね。

もう一度 Bug 18361@mozdev 読み直して流れを整理
1. ISO-2022-JP, 7 bit, PGP/MIME --rfc4880 だと署名に失敗する
2. ISO-2022-JP, 7 bit, PGP/MIME --rfc2440 なら問題なかった
3. Bug 18361@mozdev で ISO-2022-JP PGP/MIME のときに UTF-8 quoted-printable に変更するかどうかダイアログを出すようになった (その設定値が extensions.enigmail.warnIso2022jp)

→extensions.enigmail.warnIso2022jp = 2 (ISO-2022-JP 維持) かつ --rfc2440 なら ISO-2022-JP, 7 bit, PGP/MIME で正常に署名できた (これが 0.95 時代)

4. 0.96 で 3. の処理が変更されて PGP/MIME の際に ISO-2022-JP が無条件で UTF-8 に変更されるようになった
5. テキスト形式での暗号化でも、中身は ISO-2022-JP だけど content-type が charset: UTF-8 になってしまった (おそらく 4. のとばっちり)

→テキスト形式の署名以外は全滅 (0.96 時代)

改めて流れを追い直してみると、とりあえず Bug 18361@mozdev をバックアウトしてもらって、自分で --rfc2440 セットすれば、PGP/MIME で quoted-printable になってしまうことを除けば ISO-2022-JP 使えるようになる……かな……？？？
# というか、不要で余計な workaround 仕込ませちゃっただけだったような気がorz

ざっと hg のログ斜め読みした限りでは Bug 18361@mozdev が fix された頃と今では、Thunderbird のその辺のソースに変化はないようなので、単純バックアウトでもいけると思います。
# PGP/MIME で quoted-printable になってしまうのは ISO-8859-1 含めた全エンコード共通のようなので解決できませんが。

行末空白はちょっとフォローできてません。
相互検証の環境がないのがつらいですね……

_________________
[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

Enigmail の挙動はちょっと見てみました。


Enigmail は元メールを書き換えて暗号化メールを作っているので、Enigmail がヘッダの変更をしなければ、元が ISO-2022-JP ならば送信されるメールのヘッダも ISO-2022-JP です。UTF-8 に変更する方が、Enigmail からの指定です。
つまり、Enigmail 0.95.x で
ISO-2022-JP で送る選択をした場合 → Enigmail は charset を触らない。
UTF-8 で送る選択をした場合 → Enigmail が UTF-8 に変更する。

です。
で、Tb3 + Enigmail trunk では ISO-2022-JP では必ずヘッダが UTF-8 になってしまいます。
これはつまり、Enigmail からの charset の変更が(ユーザーに確認すること無く、extensions.enigmail.warnIso2022jp を確認することも無く)必ず生きているということです。


なるほど。
Bug 18631 は typo で Bug 18361 だと思いますが、コメントによると "warns the user if ISO-2022-JP is used" + "convert the message to UTF-8" を導入したわけですね。
謎なのは、0.96 で "warns the user if ISO-2022-JP is used" の方は削除されて、"convert the message to UTF-8" だけが残っている点です。


おかしいなあ。Enigmail trunk を見ても、"convert the message to UTF-8" は残ってるんですけど。
Enigmail が何も変更しない場合、元が ISO-2022-JP ならば送られるメールのヘッダも ISO-2022-JP になるはずです。

で、改造バージョンを作ってみました。
まとめると、
Enigmail 0.95.x: "warns the user if ISO-2022-JP is used" あり、 "convert the message to UTF-8" あり
Enigmail 0.96〜trunk: "warns the user if ISO-2022-JP is used" なし、 "convert the message to UTF-8" あり
trunk-mod-a(差分): "warns the user if ISO-2022-JP is used" あり、 "convert the message to UTF-8" あり
trunk-mod-b(差分): "warns the user if ISO-2022-JP is used" なし、 "convert the message to UTF-8" なし

Tb3 + trunk-mod-a がもし 0.95.x と同じ動作をしてくれるのであれば、Tb 側にはこの件に影響する仕様変更はないと言えます。
また trunk-mod-b が、おそらく workaround をバックアウトした状態です。

うっ、ここが一番辛いところ。
いつも人に言うのは面倒なので運用で逃げています。　しかも英語で対応を働きかけるというのは地獄かも。(^^;)


たぶん、quoted-printableじゃなくなったら正規化により全ての行末ホワイトスペースは取り除かなければならないので署名区切りの空白をThunderbird本体が残しているならEnigmailでもう一回正規化をやらなきゃいけなさそうですね。

後ろの記事でCaiさんが、ここは共通なので変更できなさそうなことを書かれていますが．．．


ドイツ人って日本人が嫌いなんじゃないかという気がしてきました。知り合ったフランス人やトルコ人は日本人が大好きなんですけどね。
お願い聞いてくれるかなぁ

また無視されてます。　通じそうな英語ですよね？

いや、断りもなくただ消されているだけなんて予想外でした。
で、これに返信する前に あさんのEnigmailをインストールして検証用のMLに投げて試しました。


じゃぁ、CaiさんもMLに強制参加ですか？
私のHPにML参加窓口を復活させたので試しに申し込んでみて下さい。

あら、 ウソつきPatrick


そこまでやって戴けましたか。有り難く頂戴いたしました。　取り敢えずtrunk-mod-bをインストールしてThunderbird 3.0 beta3でiso-2022-jpになりました。
ありがとうございます。
なんで、今回のような修正（なんの発展もない削除のみ）が入ってしまったんでしょうね。意地悪したんでしょうかねぇ。

これに署名検証の不具合が残っているわけですね。それをこれからキチッと検証してどうするかを考えて、あさんのバージョンに盛り込む、ってわけですね。　
それを「Enigmail日本語!」（ビックリマーク付きで）という名前でフィックスさせて、Caiさん謹製の日本語パックを組み込んで、今後は日本語ユーザーはこれを使う、と。
取り敢えずは、Enigmail-trunk-mod-あ というコードネームで。

冗談はさておき、　ここまでやっていただいて 本当にありがとうございます。
＃ 自分でもソースを確認したり触ってみたくなったような気がしてきました。

あさんもEnigmail使ってみませんか？　検証用のMLに参加してみて下さい。

ところで、Thunderbird 3.0 beta3に関しての不具合報告するところってbugzillaとか英語以外で有りますか？
検索の後で結果のメールを選んでのフォルダ移動が効かないんですけど。

あ さん、改造版までありがとうございます。
早速試してみました。Thunderbird 3.0b3 間での検証です。

mod-a、UTF-8 へ変換するかどうかのダイアログに No (extensions.enigmail.warnIso2022jp = 2)
テキスト署名: ISO-2022-JP, 7bit
テキスト暗号化: ISO-2022-JP, 8bit
PGP/MIME 署名: ISO-2022-JP, quoted-printable
PGP/MIME 暗号化: ISO-2022-JP, quoted-printable

mod-b
テキスト署名: ISO-2022-JP, 7bit
テキスト暗号化: ISO-2022-JP, 8bit
PGP/MIME 署名: ISO-2022-JP, quoted-printable
PGP/MIME 暗号化: ISO-2022-JP, quoted-printable

結果、テキスト暗号化で 7bit ではなく 8bit と表記されてしまうこと、PGP/MIME では quoted-printable となってしまうことを除けば、0.95.x と同等の動作となることを確認しました。
また、extensions.enigmail.warnIso2022jp = 2 としたmod-a と mod-b の動作が等しいことも確認しました。
さらに、--rfc2440 なし (RFC4880 挙動) でも署名の検証に成功しました。


申し込んでみました。
これから上の検証用のメールを送ってみます。

_________________
[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