あ、そういうことですか。内容を説明して修正してもらうんじゃなくて、パッチを送ってしまうんですね。
enigmailMsgComposeOverlay.js をさらにオーバーレイとかは無理なんじゃないでしょうか、部分的に置き換える仕組みにはなっていないような．．．　ただの勘ですが。

quoted-printableが無理なMUAの参加が無いのでしょうがないです。
ちなみに 2006年9月当時でダメなことを確認したのは、
・Eudora 6, 7　（文字化け）
・Outlook Express （本文を表示しない）
・Thunderbirdのソース表示機能　（文字化け）
ですが、Thunderbird本体は直っているし、Eudoraは消えて無くなっているし、Outlook Express ぐらいでしょうかね。
PGP/MIMEの被署名パートが表示不可能だったはずですが、現状はどうなるのかさっぱりわかりません。

やはり、相手が有るので相手と共に成長しなければ「Thunderbirdが進みすぎで相手に出来ない」ってことになったらマズいでしょうし。
相手のMUAが正常に検証出来なければ Thunderbird+Enigmailのユーザが減るかも知れませんし。
本丸もあと少しでしょうし、がんばりましょう。

まずは、 UTF-8 への強制変換の阻止でしょうか。
無事受け入れられれば、ほとぼりが冷めた頃に、できれば別の誰かが、

• ISO-2022-JP は 7bit なので、わざわざ quoted-printable する必要がない。
• それでもなお、 ISO-2022-JP / quoted-printable をデフォルトにするというなら、 quoted-printable しないオプションを(隠しオプション扱いでも構わないので)同時に設けて欲しい。

などと要望する、と………こ、姑息ですかねぇ(笑)

ここは最初からダメっぽそうなこと書いてありましたよね。
これをやっているところを見つけてパッチ作って送って、承認されれば実現ですかね。

今日、秀丸メールも再確認しましたが quoted-printableでした。
ただし、秀丸メールからのテキスト形式の署名がヘンで Thunderbirdでの検証でエラーになりました。Bad Sig.じゃなくてエラーです。
＃ 秀丸メールでの参加者を募集

そういえば、日本語への翻訳時にPGP/MIMEが利用出来るMUAを紹介する文章があったんですよ。
次回の日本語パックには今回の検証で問題無く相互で暗号／署名を確認出来たMUAを挙げるようにしましょう。
＃ う～ん、まだまだ少ないな


みんなで ソース見ながら勉強会しますか？

GnuPG/PGP暗号メールの実験・検証用のメーリングリストで Thunderbird+Enigmail、Becky!+BkGnuPG、QMAIL3、Sylpheedなどと RFC2440, RFC4880, RFC3156 の各RFC対応での相互接続性の再確認を行っています。

その検証過程で、MUAを介さずにGnuPG(ver.1.4.9)単体で RFC2440, RFC4880 オプション付きでの行末空白文字の扱いに関する動作の違いについて不断さんが検証してくれました。
不断さんの検証結果を表にしたものを参考のために対応策とともに掲示しておきます。(表はエディタなどにコピーして等幅フォントで見て下さい)


【１】：Bug 18361 の現象が発生する理由の調査
　　( https://www.mozdev.org/bugs/show_bug.cgi?id=18361 )
a. 行末空白文字を含むテキストに対し、MUA(Enigmail等)を利用せずに
　　--detach-sign --armor --textmodeオプションに --rfc2440または
　　--rfc4880オプションを追加したコマンドでのGnuPG単体実行にて
　　分離署名を実行する。(署名時)
b. 元の被署名テキストに必要な変更を加える。(被署名テキストの修正)
c. 上記の被署名テキストと元の署名ファイルと共に署名を検証する。(検証時)

このオプション指定と一連の操作、および検証結果が以下の表です。
(GnuPG ver1.4.9/1.4.8では 未指定の場合は--rfc4880指定と同じ)
+-----------+----------------------+-----------+------+
|　署名時　 | 被署名テキストの修正 |　検証時　 | 結果 |
+-----------+----------------------+-----------+------+
| --rfc2440 | 修正なし　　　　　　 | --rfc2440 | Good |
| --rfc2440 | 行末空白文字を削除　 | --rfc2440 | Good |
| --rfc2440 | 行末空白文字を追加　 | --rfc2440 | Good |
| --rfc2440 | 修正なし　　　　　　 | --rfc4880 | Bad　|#1
| --rfc2440 | 行末空白文字を削除　 | --rfc4880 | Good |
| --rfc2440 | 行末空白文字を追加　 | --rfc4880 | Bad　|
+-----------+----------------------+-----------+------+
| --rfc4880 | 修正なし　　　　　　 | --rfc2440 | Bad　|#2
| --rfc4880 | 行末空白文字を削除　 | --rfc2440 | Bad　|
| --rfc4880 | 行末空白文字を追加　 | --rfc2440 | Bad　|
| --rfc4880 | 修正なし　　　　　　 | --rfc4880 | Good |
| --rfc4880 | 行末空白文字を削除　 | --rfc4880 | Bad　|
| --rfc4880 | 行末空白文字を追加　 | --rfc4880 | Bad　|
+-----------+----------------------+-----------+------+
以上、オプション指定の違いだけでも検証結果が変わる場合があり、#1, #2の
ケースでは被署名テキストが同じ内容でも署名検証に失敗します。
(Bug 18361は #2 のケースで発生)


【２】：相互接続性維持のためのEnigmailの変更点
a. Bug 18361 のバックアウト
　　Enigmailの動作とは無関係な現象に対する修正を元に戻してもらう。
　　(ISO-2022-JPからUTF-8への変換を中止する。確認ダイアログも出さない)
b. Armor Header KeysのCharsetヘッダとコンテント・ヘッダのContent-Typeの
　　charsetの両方をエンコード指定と同じにする。
　　(これで文字コード指定が正常に設定される)
これにより、
・Armor Header KeysのCharsetを理解しないMUAでも文字化けはしません。
ただし、現時点ではThunderbird+Enigmailが生成する本文パートがquoted-printableに(つまり ISO-2022-JPでquoted-printableに)なってしまいます。


【３】：RFC4880とRFC3156に対応していないMUAとの相互接続
a. 他MUAからThunderbird+Enigmail宛てにPGP/MIME署名メッセージを送る場合は以下の二つの条件を満たしておかないと、被署名パートに行末空白文字が含まれる場合にThunderbird+Enigmailでの検証に失敗します。
　　　* テキストモード (--textmode オプション相当)
　　　* RFC2440 準拠　 (--rfc2440　オプション相当)
b. ISO-2022-JPのquoted-printableをデコード出来ないMUAでは文字化けします。(これは予想)

一応、現象に従ってEnigmail 0.96のソースを見てみましたがよくわかりません。
合っているかどうかも判らないのですが、以下のような感じです。

PGP/MIME署名で 7bitにならないのは、
\enigmail\src\nsEnigMsgCompose.cpp
の 958: PRBool encapsulate = PR_FALSE;
の以降、
974: if (encapsulate) {
のifまでの間の条件で true になってしまうからではないかという気がします。

それとも、
946: rv = mMimeListener->GetContentEncoding(contentEncoding);
のときに既に"quoted-printable"が返ってくるとか。

この辺りを解決すれば quoted-printable にならずに 7bit になるような気がします。



PGP/MIME暗号時の Armor Header KeysのCharsetが無いのは
\enigmail\ui\content\enigmailMsgComposeOverlay.js
の 1626: cipherText = cipherText.replace(/(-----BEGIN PGP
MESSAGE----- *)(\r?\n)/, "$1$2Charset: "+charset+"$2");
を通過しない条件になっているからではないかという気がします。
ブロックヘッダ＋改行 を ブロックヘッダ＋改行＋Charset....に置き換えているところだと思います。

実行時には、
Shift_JISの時は以下のようにCharsetが付きますが、
> > -----BEGIN PGP MESSAGE-----
> > Charset: Shift_JIS
> > Version: GnuPG v1.4.9 (MingW32)
このとき、
1604:
DEBUG_LOG("enigmailMsgComposeOverlay.js: enigEncryptMsg:
charset="+charset+"\n");
のデバッグログを吐き出します。
> > 2009-08-22 22:38:34.355 enigmailMsgComposeOverlay.js: enigEncryptMsg: charset=Shift_JIS

しかし、iso-2022-jpの時にはデバッグログは吐き出しません。
これは 1567:の
if (origText.length > 0) {
の条件かどうかの違いでしょうか。
EnigEditorGetContentsAs()関数の結果がおかしいか引数がおかしいのか。



感じ的には この辺りなのかなと思うんですが、上のそれぞれの条件判定を通過するまでにEnigmailのソースには無い関数を呼び出していたりして わけがわかりません。
どうもThunderbird本体のソースも必要なんだろうなということぐらいしか わからないんですけど。
＃EnigmailのHPにはビルドにはThunderbirdのソースも要るような感じのことが書いてあるような気がします。（ビルド出来ないので落としてはいませんが）

ソースを修正してパッチを送り付けるか、英語で説明して修正を依頼するか、
どっちも ものすごく難しいので止まってしまっています。
まだ、こんな感じなので ソースが読める方に是非とも援護をお願いしたいと思います。

ご協力いただける方のレスをお待ちしています。

結局、わからないままなので、

a. Bug 18361 のバックアウト
　　Enigmailの動作とは無関係な現象に対する修正を元に戻してもらう。
　　(ISO-2022-JPからUTF-8への変換を中止する。確認ダイアログも出さない)
b. Armor Header KeysのCharsetヘッダとコンテント・ヘッダのContent-Typeの
　　charsetの両方をエンコード指定と同じにする。

これだけを修正依頼することになりました。
a.は同時にパッチも送りますがb.は文章による依頼だけです。quoted-printableになるのは依頼はしますがどうなるか判りません。 少なくともThunderbird+Enigmail同士なら問題がないのと先に挙げたMUAとは問題がないので検証に参加していなかったMUAとの不具合が発生した場合は「相手のMUAがGnuPGへの対応が不十分」ということで諦めてもらうしかありません。 Thunderbird+Enigmailの利用を勧めて下さい。

ただ、私が調べたところ
メーリングリストのアーカイブの閲覧などでquoted-printableが問題を引き起こしているケースが有ります。（アーカイバがquoted-printableに対応していないとか）
メーリングリストの投稿にはPGP/MIMEでの署名は避けた方が良いかも知れません。
Outlook、Outlook Express が相手の時もテキスト形式での署名をお勧めします。


以上で今回のEnigmail 0.96の不具合に関する話題は終了します。

次回日本語化の文言です。

enigmail.properties

今さら疑問に思うんですが、「 Mac OS X のポピュラーなメーラ 」ってなんでしょう。　PGPが利用可能なMUAって一つも無いような．．．なんか、ウソっぽいような。
Thunderbirdだけのような気がするんですが どうなんでしょう。

# Mac OS X ユーザーではないので、何がポピュラーかはわかりませんが…。

とりあえず、標準の(?) MUA である Mail.app については、デフォルトでは GnuPG に対応していません。しかし、別途プラグイン GPGMail [1] をインストールすることで、 GnuPG が使えるようになる[2]ようです。 GPGMail のサイトをざっと見た感じでは、 RFC 3156 に対応しているようですから、 PGP/MIME 対応と考えて良いだろうと思います。(求む!! 現役ユーザーさん!!^^;)

Thunderbird が Mac OS X にインストールされているかどうかはわからないのですが、仮にインストールされているとしても、どちらも別途、アドオンないしはプラグインをインストールしなければならないという意味で、 GnuPG 対応化の手間は大差ないだろうと思います。

なお、 Mac OS X は UNIX Like OS ですから、標準でインストールされている MUA 以外にも、他の UNIX Like OS で利用されるような MUA (例えば Sylpheed のような MUA)を、比較的容易にインストール・利用することができるのではないかと思います。

[1] http://www.sente.ch/software/GPGMail/En ... GMail.html
[2] http://www.goodpic.com/mt/archives2/200 ... pppgp.html

思い出しました。 GPGMailに手を加えてPGP/MIME可能にしたのと日本語化した人は私も不断さんも知っている人です　(^^;)

当時の私は気付かなかったんですが．．．
GPGMailはSylpheedを参考にしたと言うことでしたが、暗号化＋署名のPGP/MIMEを復号＆検証出来たのはEudora＋プラグインを使用していた私だけだったようです。他の人は復号は出来るけども署名の検証に失敗していました。
理由は当時のSylpheedと同じく、「署名してから暗号化」しているからです。この形式の署名を検証出来るMUAは少ないです。
Sylpheedのほうは数年前に私が他のWindowsのMUAとの互換性をとるために暗号化と署名を同時にやってもらうようにお願いして修正してもらいました。
もしかしたらGPGMailは当時のままかもしれません。 当時のままならWindowsでは この形式の署名を検証出来るのはThunderbird+EnigmailとSylpheedとQMAIL3だけかな。

でも、そういう問題が発覚していないというのは 「誰か他の人」を相手にして使っているユーザが居ないってことの裏返しでしょうかねぇ。

ThunderbirdがOSにバンドルってことは無いと思いますけど、EnigmailもGPGMailも比較的簡単そうですね。

でも検証していないので上の文言のMacのところは変更せずに置いておこうかな。

調べておいたのに書くのを忘れていました。

GPGMailが吐き出すヘッダです。

テキスト形式：
PGP/MIME時のパートヘッダ：
PGP/MIME時のパート内のPGPブロック内：PGPブロック内が二重になっています。 つまり、暗号化した結果に さらに署名しているので二重になっています。（format=flowedも付いていますが）

この形式はEnigmailはぜんぜん大丈夫です。
しかし現在でもこのような暗号化＋署名の形式なら、署名の検証が出来るMUAは少ないです。

その他の検証としては、micalg=pgp-sha1 がsha1以外でも大丈夫かどうか、
quoted-printableが大丈夫かどうか、
でしょうか。 GPGMailユーザの確認をお願いしたいですね。

＃ こんなところ、読んでいるわけがないと思いますが Googleさんに期待

http://homepage.mac.com/mio_rhapsody/gnupg/GPGMail.html より
（「解読」は復号に、「認証」は署名の検証に、「multipart書式」はPGP/MIMEに、「古いPGP書式」はテキスト形式に置き換えて読んで下さい）
私はEudora 5.0.2-Jr1で「検証出来る」とリポートしたはずなのに．．．
Becky! Ver.2は検証に失敗していたんじゃなかったっけかなぁ。（検証に成功したのは裏技にて）
DatulaとEdMaxの結果を見る限り 昔のSylpheedと同じ感じですね。

＃ Enigmailとは互換性があるので問題なしということにしますか　(^^;)
＃ Windowsユーザを相手にするMacユーザはThunderbird+Enigmailを使いましょう ってことで．．．
＃ 私がMacユーザに戻ったときはGPGMailの修正を依頼することにします

Enigmail の ML に投げたら「ISO-2022-JP 以外の charset にも影響するからダメ」と言われたので、ad-hoc バージョン。
mod-b は常に有効、ISO-2022-JP のときだけ c が効果を発揮します。

enigmail-trunk-tb-win32-trunk-20090915-0557-localized.xpi
enigmailMsgComposeOverlay_1.187_rev.js.patch

_________________
[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 をなんとかしたい。

# 書いた後に新しい nightly が出てたのに気づいて修正

本家に提出済みパッチ適用 (ISO-2022-JP のまま PGP/MIME を扱えるように)、および日本語リソースに細かい修正を加えたバージョンです。
Thunderbird 2.0 系列および SeaMonkey 1.x 系列では ISO-2022-JP でまともに動作しません。
Thunderbird 3.0 Beta 4 で動作確認済みです。

http://www.chaoticshore.org/moz/Enigmai ... -ja-JP.xpi
http://www.chaoticshore.org/moz/Enigmai ... JP.xpi.sig

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

# さらに修正

http://www.chaoticshore.org/moz/Enigmai ... JP-rev.xpi
http://www.chaoticshore.org/moz/Enigmai ... ev.xpi.sig

一箇所修正抜けです。

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