Thunderbird 60.3.0にバージョンアップしたところ、
過去の受信メールも含めて、特定のメールの件名の途中にひし形に？（U+FFFD）の文字が
入るようになりました。
52.9.1のときは、同じ件名のメールにはU+FFFDの文字は入っていませんでした。
60.3.0でも本文には入っておらず、正常に表示されます。
メールヘッダも、文字コードは正しく指定されているように見えます。
同じような現象が発生した方はいらっしゃらないでしょうか？
--------------------------------------------------------------------
Subject: [plm-icadsx-support:238274] =?ISO-2022-JP?B?W1dFQg==?=
=?ISO-2022-JP?B?GyRCJVUlKSE8JWAlNyU5JUYlYBsoQl0=?=
=?ISO-2022-JP?B?IBskQiVXJW0bKEIbJEIlMCVpJWAbKEI=?=
=?ISO-2022-JP?B?GyRCJTUlXSE8JUglNSE8JVMlOU14GyhC?=
=?ISO-2022-JP?B?GyRCTVEzKztPRVBPP0ZPJDEkWCRORn5OTyQsGyhC?=
=?ISO-2022-JP?B?GyRCJCIkaiReJDckPxsoQg==?=
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
メールの一覧で表示される件名の「プロ」と「グラム」の間にU+FFFDが入ります。

_________________
Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko

当方でも、Thundirbird60.3.0にバージョンアップ後、過去に受信したメールも含めて、宛先名、メール本文に黒菱形の中に白ヌキ「？」の記号が表示されるものがでてきました。
調べてみると、いずれもキャラクタセットがISO-2022-JPで、かつ文字列中に半角カナ文字が使用されているパターンで上記の記号がでています。
emlファイルの内容をバイナリエディタで見ると、半角カナ文字の前後のエスケープシーケンスのところが上記記号に変換されています。
バージョンアップ以前は問題なかったので、バージョンアップ時にISO-2022-JPの処理方法が内部的に変更されたのでしょうか？

_________________
Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko

Subjectが
である .eml のテストデータを作って Thunderbird 60.3.0 に取り込んで見たところ、当方でも下の添付画像のようになりました。

上記エンコード文字列を http://www.encodemaniax.com/ サイトにてデコードしたところ
でしたので、メールソフト Sylpheed 3.7.0 を使って charset=ISO-2022-JP にてテストメール送信してみたところ、
Thunderbird で文字化けは起こらず、エンコードされたソースは下記となっていました。

http://www.encodemaniax.com/ サイトでエンコードした結果も同じです。

送信メールソフトのエンコードにも問題ありますし、そのエンコード結果のデコードで文字化けを生じさせる Thunderbird側にも問題がある、
そういうことのように思えます。
ヘッダに X-Mailer とかの情報が入ってると思います。送信メールソフトがどれなのかわかりますでしょうか？

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

KENT様

返信ありがとうございました。
私のメールには、半角カナは含まれてはいませんでしたので、別の条件が
あるかもしれません。

EarlgreyTea様

返信ありがとうございました。
送信側のメールソフトが何であるか、わかりませんでした。

Thunderbird 52.9.1では、同じタイトルのメールでもU+FFFDは表示されませんので、
Thunderbird 60.3.0になって、なにか表示の処理が変わったという動きに見えます。

_________________
Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko

たぶん ISO-1022-JP の処理に変化があったのでしょう。
すでに申し上げましたように、文字化けが起こるソースのISO-1022-JPエンコードも間違いとまではいいませんが、ちょっと変なのです。
文字化けが起こる箇所の行だけ、手作業でBase64のデコード（途中経過は省きます）してみますね。

　参考：
　 http://www.kipwmi.com/fm/tips/base64.htm
　 http://charset.7jp.net/jis.html

----------------------------------------------------------------------------
=?ISO-2022-JP?B?IBskQiVXJW0bKEIbJEIlMCVpJWAbKEI=?=
↓
20 : 半角空白
1B 24 42 : ESC $ B ［新JIS漢字の開始］
25 57 : プ
25 6D : ロ
1B 28 42 : ESC ( B ［ASCIIの開始］
1B 24 42 : ESC $ B ［新JIS漢字の開始］
25 30 : グ
25 69 : ラ
25 60 : ム
1B 28 42 : ESC ( B ［ASCIIの開始］

----------------------------------------------------------------------------


青文字部分に注目してください。
「プロ」と「グラム」の間でいったん「ESC ( B」でASCIIに戻し、すぐに「ESC $ B」という不要なシーケンスが挿入されています。
そしてその箇所でThunderbird 60は文字化けを起こしています。
素直にエンコードされた Subject であれば文字化けは起きていません。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

tanoさま、EarlgreyTeaさま
先日私が報告した過去に受信済のメールの文字化けも、EarlgreyTeaさんの指摘内容と同じシーケンスのパターンでした。

メール本文中に半角カナ文字で「ｵｰﾀﾞｰ」という記述があるのですが、本文テキストをバイナリで見てみると、

1B 28 42　ASCII開始
1B 28 49　半角カナ開始
35　　　　ｵ（半角カナ）
1B 28 42　ASCII開始
1B 28 49　半角カナ開始
30　　　　-（半角カナ）
1B 28 42　ASCII開始
1B 28 49　半角カナ開始
40　　　　ﾀ（半角カナ）
1B 28 42　ASCII開始
1B 28 49　半角カナ開始
5E　　　　ﾞ（半角カナ）
1B 28 42　ASCII開始
1B 28 49　半角カナ開始
30　　　　-（半角カナ）
1B 28 42　ASCII開始（以降、ASCII文字が記載）

となっていました。
60.3.0になる前はこれで文字化けしていなかったので、60.3.0でやはりISO-2022-JPの処理が変わったものと思われます。

_________________
Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko

ちなみに、これは Thunderbird だけではなく、Firefox も同様です。
さらに Chrome も同じです。

閉じ忘れを防ぐためのなのか「ESC ( B」とセットで開始ESCを挿入してくる手抜きエンコードでも
それなりに読めるようにデコードしてくれるのはIE、Edgeだけみたいです。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

FYI
Thunderbirdが仕様変更すべきかどうかは、GitHubで議論することができます。
Bug 1506049 TextDecoder returns wrong result for ISO-2022-JP text
https://bugzilla.mozilla.org/show_bug.cgi?id=1506049

_________________
Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko

WHATWG の GitHubにエンドユーザーが乗り込んでいって標準仕様の議論をするというのも、ハードルの高い話な気がしています。
標準仕様としてどうあるべきかというよりは、製品としてどうあるべきかの話だと思うからです。
日本のビジネスユーザーにおいて、ISO-2022-JPのメールがいまだ主流であり、しかも「正しいデコーダーでエラーとされるエンコーダー」が多く稼働しているという現実。
そしてそれをMicrosoft製品は問題なく処理できるが、MozillaとGoogle（Appleも？）はエラーにしてしまう。
そうなった場合に、ユーザーはダメなエンコーダーを駆逐しようとはせず、単にMicrosoft製品を選ぶだけです。
そういう観点での議論が必要な気がします。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

とりあえず、 https://github.com/whatwg/encoding/issues/115 にコメントしてみました。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

_________________
Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko

本件、なかなか進まないですよね・・・
社内ユーザーの大半が、メーラーとして古いAL-MAILを使っているため、この文字で
溢れかえっていて、返信時はいちいち気にせねばならないのがストレスなんですよね・・・

進捗することを祈っております。

_________________
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

wr_papa さん、maji とゆ者です。
ちと気になったので、、、、。。。


このスレッドで初めて「 AL-MAIL 」とゆ情報が出てきたので
その真意を教えてください。
わざわざ AL-MAIL を話題に出されたのは

a) AL-MAIL でも Thunderbird同様に本スレッド掲示の現象が出ていて困っている
b) AL-MAIL で発信したメールを Thunderbird受信すると本スレッドと同じメール現象となる
c) 上記以外/具体的には・・・・・

のドチラでしょうか。

.

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

お世話になります。返信有難うございます。

下記のお問い合わせについては、
b) が回答になります。

社内外からメールを受け取る際、社内でAL-MAILから送信されているメールに
限って文字化けしているようです。
社内発信でもthunderbirdを使っているものや、outlook使用者のメールでは
文字化けは発生しておりません。

これで回答になってますか？

_________________
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36