実は、今回の件に気付いたとき、真っ先に pgp-users メーリングリスト http://pgp.iijlab.net/ml/ に投げようとしたのですが、とうの昔に運用が停止されていました。 pgp-users であれば、山本さんをはじめとする PGP やメールシステムに精通している方々からの的確なアドバイスや援護射撃を得ることができるのではないか、と勝手に期待してのことだったのですが…そうは問屋が卸してくれませんでした orz



まさにこれを主張し続けるしかないのではないかと(^^;
こういう事例でこういうメーラを使っている相手とのやりとりで問題が起きている
という具体例を挙げて攻めるしか、翻意は期待できないように感じています。

これしかないみたいですね。Armor Header Keys の Charsetなんか無視してるMUAは多いけど、この形式だと復号＆表示できないMUAは無さそうかな。

そうですね、残念でした。ML 廃止っていうSubjectでの最終が2005年4月です。その年の10月に相互検証MLのサーバが吹っ飛んで無くなってしまいました。
話題が違っていたので私にはiijより相互検証MLのほうが勉強になりましたけど。

RFC4880をサポートしているMUAがほとんど無いということと、開発が終わっていて修正も期待出来ないということも。 それと、quoted-printableは改行の処理がまずいMUAが有るので使いたくないということも。
是非、下位互換性を維持して欲しいってことで。
うまく英語にしてお願い出来ると良いんですが。


私の方は、相手とのやり取りもあるので6月に問題が発覚した時点で仕事用はQMAIL3に戻しています。
このマシンは昨夜からThunderbird 3.0beta3にCaiさん謹製のEnigmail日本語版を入れています。さっきまで自分達が日本語化した表示がどんな風に表示されるのか確かめていたところです。
もう少ししたら、他のMUAとの互換性を調べることにします。

＃ そういえば、Enigmailのウィザードの表示が大変なことになってます　> Caiさん

ということで、少しだけ確認してみました。
送信は全てThunderbird/3.0b3 + Enigmail 0.97a (20090719-0558) です。

1.Sylpheed 2.7.0
　　・テキスト形式を復号／検証する機能が無いため問題無し（問題外？）
　　・iso-2022-jp指定でPGP/MIME UTF-8 quoted-printableは問題なし、署名検証はOK。
　　・UTF-8指定でPGP/MIME UTF-8 quoted-printableは問題なし、署名検証はOK。

2.QMAIL3
　　・iso-2022-jp指定でテキスト形式暗号は文字化け。署名検証はOK。エンコーディングを変更すれば読める。
　　・iso-2022-jp指定でPGP/MIME UTF-8 quoted-printableは問題なし、署名検証はOK。
　　・UTF-8指定でPGP/MIME UTF-8 quoted-printableは問題なし、署名検証はOK。

普通に予想通りで面白くなかったです。UTF-8が利用可能なMUAならPGP/MIMEで問題無いというのを確認しただけになってしまいました。

ふと思い立って実験したところ、送信時の文字エンコーディングとして Shift_JIS や EUC-JP を指定する場合には、 ISO-2022-JP を指定する場合と異なり、勝手に UTF-8 に変換されることはない(1)ようです。

■PGP/MIME を使わずに処理を行った場合

【署名のみ】
　Content-Type: text/plain; charset=Shift_JIS または EUC-JP
　Content-Transfer-Encoding: 8bit
　PGP ブロックに Charset 指定なし

【署名 + 暗号化 および 暗号化のみ】
　Content-Type: text/plain; charset=Shift_JIS または EUC-JP
　Content-Transfer-Encoding: 8bit
　PGP ブロックに Charset 指定あり (Charset: Shift_JIS または EUC-JP)
　ASCII armor の復号内容には Content-Type ヘッダや Content-Transfer-Encoding ヘッダが存在しない。
　ASCII armor の復号内容の文字列は quoted-printable されていない。文字コードは Shift_JIS または EUC-JP 。

■ PGP/MIME を使って処理を行った場合

【署名のみ】
　Content-Type: text/plain; charset=Shift_JIS
　Content-Transfer-Encoding: quoted-printable
　PGP ブロックに Charset 指定なし

【署名 + 暗号化 および 暗号化のみ】
　PGP ブロックに Charset 指定なし
　encrypted.asc の復号内容には、 Content-Type ヘッダや Content-Transfer-Encoding ヘッダが含まれる。
　　Content-Type: text/plain; charset=Shift_JIS または EUC-JP
　　Content-Transfer-Encoding: quoted-printable
　encrypted.asc の復号内容の文字列は quoted-printable されている。

といった感じになり(2)、 ISO-2022-JP を指定したときのように、 PGP/MIME を使わずに暗号化を含む処理を行うと、メールヘッダの charset と ASCII armor の復号内容の文字コードが異なってしまう、といった状況にはならないようです。

(1) 特殊な扱いをされているのは、日本語というより ISO-2022-JP のようなので、この挙動は当然といえば当然なのかもしれませんが。
(2) もちろん、これらのケースでも、相手方が Shift_JIS や EUC-JP に対応しているか、 quoted-printable の扱いに問題がないか、といった心配はあります。

http://forums.mozillazine.jp/viewtopic.php?p=18952#18952 このiso-2022-jpのworkaroundのせいですね。

これ、設定ウィザードの2ページ目のという文が宙に浮いているというか、ど真ん中に鎮座します。翻訳なんか関係なくEnigmailのバグでしょうね。
スクロールするほどアカウントが有るというのがバグの引き金かも。

あと、署名に失敗したときの文言に「エラー - 署名の検証に失敗しました。; 詳細はペンのアイコンをクリックしてください 」と表示しますが、3.0ではペンのアイコンじゃないんですね。
CaiさんがアイコンがどうのこうのってMLに投げたのは これですか？

ML は完全にスルーされてるようなので、そろそろ第二波をかけないと……

Thunderbird 内部で ISO-2022-JP だけ特別な処理をしていてソレを回避するためのものだったのですが、中途半端な workaround を放置したまま曖昧にしていたツケが回ってきてしまいましたか。
ただ、Shift_JIS や EUC-JP なら quoted-printable ではあるけれどエンコードが維持されていることが確認できたのは収穫だと思います。
少なくとも、Thunderbird の仕様変更でも Enigmail の仕様変更でもなく、Enigmail の regression だということははっきりしましたし。



やはりこれが一番まともな解決法になりそうですね。
ちょっと文面考えてみます。


アカウント 6 個でスクロールバーが出てますが、こちらだとちゃんと最下部にいます。
再現条件が明確になれば投げ込んでみましょう。


う、そう言えばペンじゃなくなってた……
僕が投げたのは、メインウインドウのツールバーの「復号/検証」のやつです。
あの微妙に傾いた封筒アイコンは、1.5 時代のデフォルトデザインに合わせたやつなんですよね。

_________________
[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.1+)
-- いつまでたっても nightly

完全に無視されてますね。

でも、このThunderbird内部処理にバグが有るから署名の検証が出来ないのでは？　根本解決にはThunderbirdの修正も必要なのかも知れません。
あんまりよく読めないのですが、"-- "というのが登場しているところを見ると行末空白処理のバグのような気がしますが、行末処理とか正規化の問題なら暗号化なんか関係なく、MIME処理のための作業のはずです。

取り敢えずはこれで行きましょう。

うちは9個で宙に浮いています。

なるほど、そうだったんですか。でも翻訳に関係有るのはエラーメッセージの文言だけですよね。次回は「ヘッダペインのEnigmailのアイコンを」とかボカして書いておけばアイコンが変わっても気にせずに済むかも。

Thunderbird3.0beta3もなかなか快適に使えていますが、
検索結果から「メッセージフォルダを開く」ボタンを押してもフォルダを開いてくれない。

追加です。

3.秀丸メール
　　・iso-2022-jp指定でテキスト形式暗号は文字化けなし。署名検証はOK。
　　・iso-2022-jp指定でPGP/MIME UTF-8 quoted-printableは問題なし、署名検証はOK。
　　・UTF-8指定でPGP/MIME UTF-8 quoted-printableは問題なし、署名検証はOK。

秀丸メールはヘッダのエンコード指定とコンテンツが不一致でも自動的に表示出来るような機能が備わっているそうです。

どなたか、Edmax利用されている相手で確認可能な人って居ませんかね。
まだまだ多くのMUAが有りますが、MozillaZine.jp フォーラムってことで見に来る人は居ないような感じですね。

すっかり忘れていましたが、“-- ”といえば、“-- ”の行のみ含むメールを Becky! + BkGnuPG で作成(US-ASCII, 7bit)し、

• PGP/MIME を使って署名したものを Thunderbird + Enigmail で検証すると失敗
• PGP/MIME を使わずに署名したものを Thunderbird + Enigmail で検証すると成功

します(^^;

Thunderbird に行末スペースの処理絡みのバグがあるかどうかはまではわかりません(1)が、 Thunderbird + Enigmail で検証に失敗したメールを Sylpheed で検証すると成功することから、少なくとも、 Thunderbird + Enigmail の組み合わせにおいて、行末スペースの処理まわりに何かしらの問題(2)があるのだろう、とは思っています。

(1) 試した限りでは、 Thunderbird では、“-- ”の行以外で、行末にスペースを含むメールを作成することができませんでした。シングルパート、マルチパート、いずれの場合も、行末にスペースを入力しても、送信前に全て削除されるようです。“-- ”の行が特別扱い(?)されているのは、これが慣習的に署名(ここでいう署名は PGP 署名のことではない)の区切りとして使われているからではないかと推測しています。
(2) あるいは、日本語圏で主に使われている PGP 対応メーラとは異なった“仕様”。

それはThunderbirdの正規化のミス、に1票
署名区切りの"-- "の最後のブランクに固執して正規化を間違ってるんじゃないかなぁ。MIME化のお約束は”行末の空白文字(tabとか、ホワイトスペース)は削除！”　ですよね？　違ったっけ？

＃ 私、PGP署名を付けるときは自分の署名を一切付けないので"-- "には無縁でした。

やっぱり削除が必要です。RFC2045に有りました。

＃ 相互検証MLで2000年に話題になってたのをしっかり覚えてた

あ、すみません。逆ですか。
Thunderbirdが検証するときに空白を足しているのかな？
署名区切りの"--"の時だけ わざわざ空白を足して捏造しているということですか？　Thunderbirdが自分で改ざんしたものを検証して失敗するってことですか。　やめて欲しいなぁ。

でも、この問題は受信時の復号＆検証ですよね？　iso-2022-jpを無理にUTF-8にして送信するのとなんの関係があるのやら？

＃ 頭が痛くなってきた

おそらく、“-- ”の行だけに限らず、行末スペースを含む PGP/MIME メッセージについて、 Thunderbird + Enigmail が署名を検証する際、行末スペースを削除した状態で検証してしまうのではないかな、と思います………って、どういった処理の流れで不正な署名扱いになっているのかを追いかけずに、単なる想像で書いていますが(^^;


多分、関係ないです(笑)

ただ何となく、署名の検証処理に行末スペースに起因する問題を抱えているなら、署名の作成処理にその問題の影響が及んでいてもおかしくないな、と感じていまして、

行末のスペース絡みで署名検証に失敗するケースがあるらしい。
　→(作者さんが Thunderbird + Enigmail で作成したメッセージに関するものだと勘違いしてしまい、)そういうことなら、行末のスペースを保護してやれば解決だよね?
　　→ Base64 だとやり過ぎなので quoted-printable にするかー
　　　→ ISO-2022-JP / quoted-printable でも良いけれど、 ISO-2022-JP は 7bit なので、 quoted-printable するのは好ましくないかなー
　　　　→それなら、 ISO-2022-JP の大部分をカバーする 8bit の UTF-8 にしてから quoted-printable すれば良くね?

といった感じで UTF-8 / quoted-printable 化の強制が決まっちゃったのかなー、とか経緯を想像してみたりしています。

マジですか？　もしかして復号時も正規化とかしてたり？　(-_-;)
そういうおバカなミスはしていないと思うけど、現象からは想像出来るってのが怖い．．．
残念ながら、手持ちの暗号メールには一切署名が付いていなくて、行末空白も無くて．．．有ったとしてもテスト途中のダメダメなのばっかりです（相互検証MLの）

今は残念ながら、私はiso-2022-jpを普通(?)にMIME処理するMUAを持っていなくて、なぜか昨夜試していたらSylpheedもQMAIL3もQPなんですよね。ビックリしました。（QPやめてもらったのはテキスト形式だけだったのか？、と　頭が痛くなりました）
そういうわけで行末空白の確認は出来なかったんです。（--=20になってて）
QPじゃないiso-2022-jpのPGP/MIMEを受信してEnigmailをテストするしかないと思うんですが、なんか探してみます。

送信は無関係ですよね。署名の検証に失敗したというのとは関係ない修正になってるんですよね。

QPじゃないときに何が原因で署名の検証に失敗するのかを確かめるために一旦元に戻して欲しいなぁ。　こっちでテストするには古いThunderbirdとEnigmailと、それを入れるマシンが必要です　(^^;)

しかし、みんなThunderbird同士を相手にしか使っていないのかね。
＃ あぁ、Claws Mailを入れようかな