少々お尋ねいたします。
以下でも触れますが、一通りこのフォーラムや他のフォーラムで、メッセージを確認してみました。

他者からの受信メールの中に、文字コードが本文と件名とで異なるものがあります。
例えば、何通かの各受信メールについて、本文はShift-JISである のに、これに対して、件名はISO-2022-JPとなっています。
この場合、本文と件名とのいずれか一方の文字コードに合わせて表示を設定すると、他方が文字化けします。

○ Thunderbirdをどのようにか設定することによって、又は、いずれかのアドオンを利用することによって、自動的に本文と件名との文字コードを別々に判定して、適切な表示を行うといったようにすることはできないでしょうか。

確かに、"件名: メール件名の文字化け解消法 投稿時間: 2011年1月07日(金) 22:00"において、上記と同様の問題点についてのご指摘があり、その時点では、「何ともならない」ということだったと思いますが、現在も、何ともならないといった状況は変わらないのでしょうか。

そのような受信メールの送信元で必要を感ずるものに対しては、一応、「本文と件名とで文字コードが違っているようだけど、何とかならないでしょうか。」とはいってみています。
ただ、その相手方は、メールの送受信のシステムを直接担当しているわけではないので、私の指摘に対して会社として対応があるかどうかわからない感じです。

念のために記しますと、Windows 7 64bit版上で、バージョン9.0.1を使っています。

ご回答にお時間を割いていただければ、誠に感謝いたします。

解決方法ではありませんが…


件名と本文が異なる文字コードになっていても、電子メールの仕様上何の問題もありません。むしろ自然です。
本当にThunderbirdで文字化けするのなら、Thunderbirdのバグです。

そうですか、ありがとうございます。

本当に文字化けするので、Thunderbirdのバグですね。
私のPC上で表示されている該当のメールの本文と件名とをコピペしてみても、直接的には再現性がないようなので、今一度、次の通り、似た感じでより詳細を繰り返してみます。

Thunderbird上で、そのメールを表示させた状態で、(1)[表示]から[文字エンコーディング]をShift-JISに設定すると、本文全文が適切に表示されて、件名のすべてが文字化けします。
また、(2)その[文字エンコーディング]をISO-2022-JPとすると、件名が適切に表示されて、本文が文字化けします。

もしMADさんの仰るように、バグであるようならば、その初めての問題点の指摘が今年の1月ですし、なるべく早くフィックスしてほしい感じではあります。

無料なので、強くは言えないところですが。

いいかげんなアドバイスでバグと決めつける前に、そのメールのヘッダをご覧になることをお勧めします。
そして、ご自分で納得した結果でバグと決めつけてください。
現象から想像してみましたが、おそらく送信側でcharset=ISO-2022-JPと指定しておきながら本文部をShift-jisで送信しているのだと予想します。
件のメールのソースを表示してみると以下のようなヘッダが有ると思います。
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
※メールを選んでctrl+uでソースを表示

そのソース表示のウィンドウメニューから「表示」→「文字エンコーディング」→「ユーザ定義」
とすると、デコードしないままの「素」のメールが見られます。
そこには文字化けしない件名部の日本語部分は「=?ISO-2022-JP?」から始まっていて、
文字化けする本文部は「$B」から始まって「(B」で日本語部分が終わっていれば正常ですが、そんな風になっていない状態だと思いますが。（その状態で日本語が読めるならShift-jisでしょう）

もしかしたら、逆にcharset=のところがShift-Jisとなっていて、ヘッダ部が「=?ISO-2022-JP?」から始まっているのかもしれません。

メールの約束事では指定したエンコーディング指定を本文と同じくそのままヘッダ部にも適用するという約束事（MIMEの実装の約束事）が有ります。件名などヘッダ部と本文部とエンコード指定が違うということは「普通のこと」ではなく、有り得ません。
（少なくともThunderbirdは送信時にはこの部分の約束事は守っています）

この説明にお二人とも納得がいかなければRFCとMIMEについて勉強してみてください。インターネット上には情報は転がっています。

あ、ごめんなさい。
現象のｌ原因はわかっているということですね。余計な事書きました。

おそらくThunderbird開発側は間違った実装を行っているメールソフトで送信されたものの面倒を見る気は全くないんじゃないかと思います。
国産ソフトは間違った実装から送信されるメールもリカバーする親切なものも有ります。

対処法をググってみました。
実際に試したわけではないですが、以下のような方法では如何でしょうか？
ThunderbirdでShift_JISのメールの件名が文字化けする

kiyo4_kさん、ありがとうございます。

該当の文字化けメールは、件名の文字コードがiso-2022-jpで、本文の文字コードがShift-JISのようですが、このメールについて、ご助言に従って確認してみたところ、次の感じでした。

Subject: =?ISO-2022-JP?B?GyRCRzxJSiVqJTklSCVHITwlPzx1Tk40ME47JE4kKkNOJGkkOxsoQg==?=
Content-Type: text/plain; charset="iso-2022-jp"

Subject: =?ISO-2022-JP?が件名の文字コードを指定していて、Content-Type: text/plain; charset="iso-2022-jp"のcharset以下が本文の文字コードを指定しているんですよね。
仮に、このcharsetが、"iso-2022-jp"ではなく、"Shift-JIS"となっていれば、文字化けせずに表示されるんだと思います。

送信側で、charsetは"Shift-JIS"とすべきであるにもかかわらず、実際には、誤って、"iso-2022-jp"とされていることが、文字化けの原因なんですよね。

それで、それが文字化けの原因だとすれば、確かに、結論として、この文字化けはThunderbirdのバグとはいえないですね。
とはいえ、もし送信側で誤ってcharset="iso-2022-jp"と指定されていても、受信するThunderbird側で、簡単に、"Shift-JIS"と指定し直すことが可能なようであれば、そのようにプログラムを改良いただいてもよろしいのではないかと思います。

仰る通り、何か支障があったときに、十分にその原因を分析しようとすることなく、安易にThunderbirdのバグと決めつけるのは好ましくないですね。
私としては、いろいろ他にもすることがたくさんある感じで、RFCとMIMEについての学習に時間を割くことまではしていませんが、ご指摘ありがとうございます。

meeyarさん、ご提案ありがとうございます。
ご提案のURLにある方法を試してみました。

ただ、文字コードを件名に合わせて表示させるか、本文に合わせるかといった状況は改善されない感じです。
件名と本文との双方を同時に適切な文字コードで表示させることはできないようです。

とはいえ、私の方は、最近、このThunderbirdを使い始めたところで、「ふむふむ、フォルダ単位で文字コードの指定ができるのか。」と関心の感じでもいました。
大昔は、OutlookとかOutlook Expressとかを使っていましたが、その後Thunderbirdにするまでは、ブラウザ上でメールを操作していました。

Thunderbirdは、ybbのメールサーバーが[spam]認定した迷惑メールを、受信と同時にそのまま、日産協、デ協、yahoo!の迷惑メール受付に転送できるところが気に入っています。
迷惑メールは、「避ける」のではなく、「根絶」の方向で、政府側に対応いただくように、日産協を通じてお願いしている感じです。飽くまで、子を持つ一般市民としてですが。

文字コードについて上述のような問題がなく、迷惑メールの自動転送機能があるメーラを、もしお知りのようであれば、是非、そのようなメーラをお勧めいただければと思います。

間違いだらけのメールリーダ - ああ文字コード - charset の決めうち

私に今さら和さんの記事を読めと仰る？
言葉なしの失礼なやり方で引用しただけで「これを読め」と言われるなら、そのページじゃなくて
http://www.mew.org/~kazu/doc/newsletter/3.html こっちです。
上で示したページの「ヘッダの国際化」という小見出しの中の記事に「文字コードには charset パラメータと同じ値を用います。」と書いています。これが違っているとメールリーダは混乱してしまいます。（和さんの記事はRFCやMIME（それにPGP暗号）などの決め事を初心者に理解しやすく書いてある良い記事だと思います）
今回の状況がこれです。
「MIME-Version: 1.0」というヘッダを吐き出して送信するMUAはこれに従うべきなんです。（とは言うものの、従わないMUAが多すぎるので国産シェアウェアのMUAはサービスとして頑張っています）

ご自分が引用して示したページと合わせてこっちのページも熟読してください。

実際には日本ではISO-2022-JPを使うのが昔からの約束なのですが、まともなメールソフトならsjisでもutf-8でもなんでも良いと思います。（Thunderbirdはutf-8は面白くない結果になりますが）

そちらの問題のメールの送信者のメールソフトはバグっているようですね。今のところmeeyarさんが示してくれた方法と併用してフィルタで読めるフォルダにコピーするという方法で対処するしかないかもしれません。

kiyo4_4さんのおかけで、何が原因で文字化けが生じているかがわかりました。

一応、取引先のご担当には、事実がどうなっているかを表すメールを先ほど送信しました。
もちろん、私としては、とりあえずは、meeyarさんに示していただいた方法とかを使うつもりでいます。

kiyo4_kさんも、MADさんも、どちらが先に攻撃的な書き方をしたとか、主張し合っても不毛なので、寛容な感じにされるのがよろしいのではないかと思います。
何が正しいとか、あまり強く主張されるべきシーンでもないような気もしています。

それで、飽くまで、利用者側の勝手な意見になりますが、Thunderbirdの改良の方向として、どのようなメールでも柔軟に、文字化けを起こすことなく表示するという方が、スマートな感じがするようには思います。

それは、指定した文字コードと実際の文字コードが違う場合の話ですね。
私は初めから件名と本文が異なる文字コードの場合の話をしています。
最初の投稿でそのように読めたので。つまり以下のような場合です。

これは、それぞれ指定した文字コードと実際の文字コードは一致しているので、件名も本文も同時に正常に表示されなければならないと思います。

取引先など仕事関係の相手は言い難いことが有りますから困りますね。

ご心配をおかけして申し訳ありません。
ネット上では顔が見えないからこそ注意しなきゃならないことがたくさんありますよね。私自身がURL提示や引用だけというのは嫌いなので素直に反応してみました。
私の反応を見てなにかを感じてくれたから、次の投稿では言葉で書いてくれています。
勉強している人や知識のある人に対してはそれなりの言葉で、悪意のある人にはそれなりの言葉で、というのが私のスタイルです。
互いが間違っていてもディスカッションになれば間違った知識を修正することが出来ますが、そうでない不毛なことは好まないので私は最初から無視するスタイルですし、一人だけを相手に面倒なことを書くことも有りません。
読む人の勉強になったり興味をもたれる方が良いですね。

MUA（メールユーザエージェントと言い、メールソフトのことですが）を作り育ててきた立場で言うと、実はそう難しくは有りません。しかし「他人の尻拭いをする気は無い」というのがMUAの作者の考えで、その方が実装が楽なんです。私自身は暗号も扱っているので複数のMUAを使い分けている利用者側の人間ですが、全てをThunderbirdに頼らなくても良いという お気楽な立場でもあります。

いいえ、件名と本文が異なる文字コードというのはダメだという話しです。

この例の場合はcharset="shift_jis"としていながらSubject:がISO-2022-JPとしているので実装が間違っていると思います。それを受信側のMUAはcharset="shift_jis"とみなしてデコードしようとして失敗しても無罪だと思います。
そのことの説明が先の和さんの文章では「文字コードには charset パラメータと同じ値を用います。」とだけ書いています。
つまり上の例ではcharsetパラメータは"shift_jis"なのでSubject: =?iso-2022-jp?というのは間違っています。
こういうヘッダと本文部が異なるエンコードを行っているMUAの尻拭いを出来るMUAは少ないと思います。
が、そんな便利なMUAの作者に限ってMIMEの規約をよく知らなかったりしました。規約を無視するからこそ そんな便利なものを作れるとも言えそうです。

今回のオオカミ中年さんの場合はContent-Type: text/plain; charset="iso-2022-jp" と言うことなので送信時のSubject部分は正しいのに本文部を間違ってsjisで送信してしまっているという問題ですが上の例とはちょっと違いますね。

MADさんの例も、オオカミ中年さんの問題も、最近ではMUAというより専用メーラーやWebからの配信メールが多いですが、これらの実装者がMIME規約を知らないというのが理由でしょう。

で、オオカミ中年さんも心配されましたし、meeyarさんから運用での回避方法の情報も得られていました。
ここのフォーラムでThunderbirdでの実装に関係なくRFCやMIMEの話を掘り下げても仕方が無いし、トピックが長くなりすぎるのでこの辺にしておきたいと思います。
他に何かあれば雑談フォーラムのほうで目につきやすい件名を付けて投稿してください。