とあるところからやってくるメールのサブジェクトがデコードされずにそのまま表示されます。ヘッダを見ると、内容は、

SUBJECT: =?iso-2022-jp?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI==?=

となっています。mutt や squirrelmail で見ると問題なく表示されますし、nkf でデコードしても問題なく表示されます。なので、エンコード自体は問題ないと思いますが、なぜデコードされないのでしょう？
なお、OS には依存しないようで、Win, Mac, Linux どの OS 上の TB でもデコードされず、そのまま表示されます。
ちなみに、デコードされた文字列を、TB や nkf でエンコードすると、

=?iso-2022-jp?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI=?=

最後の方のはてなマークの前のイコールが、2つではなく1つになりますが、元のメールのイコールが２つになるというのが、問題なのでしょうか？

こんにちは。


本文は読めますか？

私のところにやって来るそのたぐいのメールはほとんどがスパムです。
ヘッダを見ればわかると思います。
Subject: は ?ISO-2022-JP? で書かれているが、
Content-Type: は charset="SHIFT_JIS" となっている場合です。

Thunderbird は器用なふるまいはしないで約束に沿って文字エンコードを
表示します。

参照：
Mozilla Japan ナレッジベース - メッセージの件名が文字化けしたり「?」になってしまう

こんにちは



問題なく読めます。また、一応スパムではありません。
TB が、うまくデコードできないのか、わざとしてないのか。。。

どちらにしても、次期バージョンでは、うまくデコードしてほしいと思っています。

わざとしていないのです。そういう仕様です。


多分、将来のバージョンでも対応しないと思います。

どういう仕様なのか、詳細を教えていただけると助かります。
もちろん、ポインタだけでも結構です。

詳細をと言われると、またポインタだけでもと言われると具体的に自信を持って
示す根拠がありません。
申し訳ありません。

あくまでも経験値からのコメントになってしまいます。
ヘッダにある Content-Type: に指定された文字エンコードに従っている仕様
としか説明ができません。
他のメールクライアントも一般的には同様の仕様だと思われます。
RFC にそれを概説した物があると推測するのですが探したところ発見できませ
んでした。
RFC indices related to the Internet Mail

mozillaZine 本家のナレッジベースでも検索してみましたが、下記のものぐらい
しか見つけられませんでした。
Mail content types - MozillaZine Knowledge Base

もしどなたか「それはここに書いてあるよ」という資料がありましたらフォローいた
だくと助かります。

RFCは2047です。でも2047だけを読んでもわからないかも。

http://www.mew.org/Newsletters/2.html の
「Subject: フィールド」と
http://www.mew.org/Newsletters/3.html を読んでみてはどうでしょうか。

今回のは、
Mime-Version: 1.0 というヘッダが存在するのでMIMEメールと見なし、
Content-Type:ヘッダによりsjisエンコードと見なし、
ThunderbirdはSubject:ヘッダをsjisとしてデコードしようとして失敗。

Content-Type:ヘッダとSubject:ヘッダのエンコード指定に矛盾があるからデコードできない、と。

すみません。今回のメールには、ちゃんとヘッダに、

Content-type: text/plain; charset="iso-2022-jp"

と記載されているのに、デコードされていないのです。

そして、他のMUAでは、きちんとデコードされていることから、TBのバグかもしれないと思っていますが、もしかしたら他のMUAは、許容範囲が広いだけで、TBは厳格に処理している(仕様)だけなのか解からず、質問しています。
なので、どちらにしても次期バージョンでの対応を願っているのですが。。。

あぁ、なるほど。"SHIFT_JIS"というのはPremierさんが書いていたのを読み違えていたようです。

気になるのは SUBJECT:ですが、大文字でしたか？
このSUBJECT:が原因なのかな。
可能なら、エディタでSUBJECT:をSubject:に修正してみてはどうでしょう。

ちなみにThunderbirdは「Content-Type: Multipart/Encrypted;」を理解できません。「Content-Type: multipart/encrypted;」でないとダメというバグがありました。（現バージョンでは確認できていませんが）

はい、大文字でした。しかし、これを変更しても同じでした。

エディタで修正というヒントをもらったので、最後から３文字目のイコール ('=') を削除すると、問題なくデコードされました。始めに書いた通り、最後の方のイコールが2つ続くのが余計なようでした。やはりエンコードミスなのでしょうか？つまり、TBの解釈が厳格すぎ？

のような終端のケースでも Thunderbird はデコードします。
=? で始まり、 ?= で終わるのが決まりのようですが、ビット数が合わない場合は
== として調整する仕様のようです。

以下のケースがそうです。
＊文字数が多い場合ですが。

Subject: 欄等のエンコードするヘッダ項目には仕様があるのですが、送り手側と
受け手側のメールクライアントの仕様により一致していないと文字化けとなります。
参照：
エンコード・コレクション (メール、テキスト関連)

終端の処理のケースが2種類あるのは私には技術的知識が無いので不明ですが、
一方だけしかデコードできない Thunderbird は処理が厳格というか標準準拠なの
かなと思います。
そのデコードできないメールのヘッダ、送り手のメールクライアント、OS 等の情報を
具体的に提示してください。
それによってはバグかも知れませんし、そうではないかも知れません。
もしバグの場合はここで書いても開発者は見ていませんのでその存在をBugzilla@Mozilla
等にレポートしないと解決されません。

＊TB と略するのなら Tb がお勧めです。

デコードされなかったので、質問しました。


では、エンコードの仕様的には正しそうですね。



文字化けは発生していません。デコードせずに、そのまま表示されます。



そうかもしれませんが、多くのクライアントでデコードできているという事実もあります。



ヘッダで関連すると思われるのは、下記の通り。

SUBJECT: =?ISO-2022-JP?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI==?=
Content-type: text/plain; charset="iso-2022-jp"

送り手のメールクライアントおよびOSは不明(User-Agent もありません)ですが、おそらくプログラムによる自動生成だと思われます。



バグか仕様かの判断ができずにいます。
英語でレポートできるのかという問題もありますが。。。



了解しました。

試しに、Gmailから自分のメインアドレスに問題となっている件名の以下
=?ISO-2022-JP?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI==?=
をそのままGmailの件名欄に貼付けて自分のメインアドレスに送って Thunderbird で受信してみました。
本文には「テスト」と書いてあります。

Thunderbird のUI上の件名は
=?ISO-2022-JP?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI==?=
と表示されてます。
本文は「テスト」と表示されます。
メッセージのソースを見ると
Subject: =?iso-2022-jp?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI==?=
となってます。


=?iso-2022-jp?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI==?= を解読すると
「留守モードからの通知」ですよね。

これって自動生成の返信メールかなんかですよね?
自動生成の際に上記テストしたような事をやっているのではないでしょうか?
ちなみに Mail.app や yahoo のフリーメールなんかではデコードしてくれてました。

以上、報告まで。

うーん、正確には私にはわかりません。
RFC 2045 を読むとどちらも正しいとも読み取れます。
＊ 6.8 Base64 Content-Transfer-Encoding の部分です。
RFC2045 日本語訳
RFC2045 Base64 で使用する文字の種類


失礼しました。
文字化けという表現はデコードされずにそのまま表示されるという意味で使いました。


そのとおりですね。
一方で多くのクライアントでデコードできているからそれが標準あるいは正しい仕様だ
とも言い切れないかも知れませんね。
ちなみに Becky!Ver2 で「留守モードからの通知」をタイトルにしてダミーメールを作
成したところ、Subject: の終端は ==?= ではなく、 ?= となりました。
Becky!Ver2 も終端はどちらのタイプもデコードしてくれましたので親切なのかな？


そうですね。どなたかよくご存知の方から「これはバグです」とか「仕様です」とか「どち
らも正しいです」とか明確に教えていただくとスッキリしますね。
バグ検索をしていないので不明ですが、日本語なら Bugzilla-jp がありますのでそち
らで要望として ==?= の場合もデコードする仕様にしてほしいとレポートする方法もあ
りかと思います。
既に同様のレポートがあったとしたらごめんなさい。
参照：はじめてのバグジラ ver2.16.1a2-ja編 ＊最新版ではないのですが参考まで。

Thunderbirdの開発側のポリシーと頑なな態度 そのものがバグと言いたいものが多いです。
送信はRFCをきっちり守り、受信は寛容＆柔軟に対応して欲しいです。