sakuraya様
meeyar様
いろいろ有り難うございます。

名古屋弁には驚きましたが、わかりやすい例えをありがとうございました。
エンコードについては一応はわかってますが、
MIMEはちょっと怪しいので躓いていました。

結局、Thunderbirdをやめ、WindowsLiveメールに乗り換えようと思いましたが、
やはりThunderbirdに慣れているのでバージョンを3.1に落として利用することにしました。

現在は全く問題はありません。過去のメールも元に戻りました。
自動アップデートはやめ今後はこのバージョンだけで行くつもりです。

ご教授いろいろ有り難うございました。

「Content-Transfer-Encoding: 7bitである」
やはり難しいですよね。これを調べてから質問してね！と言われると、
やはり敷居がたかいのだと思います。

とりあえずですが、感謝です。

ええと、たとえ話による概略は既にsakurayaさんから行われていますので、実際のメール周りについて書いてみます。理解が怪しげな部分もあるので、識者の皆さまからの突っ込み、訂正歓迎します。

たとえ話の中で、
[quote="Sakuraya"]今まではメールの本文が名古屋弁で書かれているとThunderbirdが判断した場合、それに合わせて件名も名古屋弁であると解釈されるようになっていました。[/quote]
とあるのが、「iso-2022-jpエスケープシーケンス」を指しています。
これが何であるかの詳しい説明は行いません(説明できるほどの予備知識が…)が、
http://d.hatena.ne.jp/blanketsky/20080515/1210841524
とか
http://www.d2.dion.ne.jp/~imady/charset/jis.html
など。

で、今回のアップデートではこれをサポートしなくなりましたというお話です。
beckymoniさんの提示されている情報(適宜改行を入れました)は、
[code]Subject: [ｘｘ] $B%-%e!<%V7r9/?)IJ=q(B
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="ISO-2022-JP"[/code]
ということなので、MIMEが使われていないiso-2022-jpエスケープシーケンスの件名だろうと推測されます。

[quote="Sakuraya"]しかし、新しく決められた別のルールではメールの本文がどの方言で書かれているかとは関係なく、件名の冒頭で指定されていなければその件名は東京弁であると判断されることになりました。[/quote]
ここで、「件名の冒頭で指定」する方法がMIMEと呼ばれる方法です。
これも詳しい説明は行いませんが、Wikipediaの
https://ja.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions
など。

Thunderbird側の対処については、開発側に認識してもらわないことには始まらないので、今まで述べられてきたとおりです。
ただ、
[quote="beckymoni"]自分が立てたサーバからのメールが文字化けしているようですが、
下手にアプリをいじっていたら本文まで文字化けしてしまい
どうにもならなくなってしまいました。[/quote]
ということであればやりようはあります。
「自分が立てたサーバー」がメールサーバーとしての機能を有していて、メールの作成、配送を担っているのならば、ご自身のサーバーから出されるメールをMIMEで扱うようにすれば問題が出なくなるのではないでしょうか。
具体的にどのように実装するかはここのフォーラムの範疇ではないので調べてください。

【補足】
RFC5335との関係について
原文丸ごと読むことはしていないのですが、以下
http://wiki.suikawiki.org/n/RFC%205335
を読みますと、
[quote]RFC 5335 4.6 は、メッセージが message/global メッセージである条件として、[list]
[*]UTF-8 頭値を含んでいること、または
[*]本体部分の頭欄が UTF-8 値を含むこと[/list]を挙げています。 [/quote]
[quote]この媒体型に対しては任意の内容転送符号化が認められていますが、 可能な場合は 8bit や binary とすることが推奨 (小文字の recommend) されています。 更に、7ビット専用の輸送路を通す場合を除き、 8bit や binary を使わなければ[b]ならない[/b] (RFC 2119 の [b]MUST[/b]) とされています。[/quote]
とあり、内容転送符号化=Content-Transfer-Encoding(7bitとか8bitとかを規定する）と考えると、
MIMEを使っていない(冒頭で文字コードの指定がない)
Content-Transfer-Encoding: 7bitである
↓
8bit(UTF-8)で統一しちゃえ！　
なのかもですね。
「日本語メール環境はiso-2022-jpがメインだから7bit専用の輸送路だろ！」と強弁できなくもないかな、とも思うのですが。

こんばんは。
少しでも理解の助けになれるならと思い返信してみます。
以下はおおざっぱで乱暴な例えを使った説明になりますし、理解が怪しいので細かい部分で間違っているかもしれませんが参考までに。

メールの件名の冒頭でどこの方言が使われているかを指定することができます。しかしこれは特に指定しなくてもルール上問題ありません。
今まではメールの本文が名古屋弁で書かれているとThunderbirdが判断した場合、それに合わせて件名も名古屋弁であると解釈されるようになっていました。
しかし、新しく決められた別のルールではメールの本文がどの方言で書かれているかとは関係なく、件名の冒頭で指定されていなければその件名は東京弁であると判断されることになりました。
本当は名古屋弁で書かれているのに東京弁であるとThunderbirdが判断するのでおかしなことになっています。
ちなみにこの例における方言のことを文字コードと言います。

文字コード関連はThunderbirdやMozilla製品に限らず、いろいろな歴史的経緯やデファクトスタンダードがあったりそれが変わったりしてゴタゴタしがちなので、今回の変更もそういうものの一つとも言えます。
現状ではThunderbirdをダウングレードするしか解決策はありませんが、Thunderbirdの開発側でこの問題に対して「これは誤動作なんじゃ？」とか「いや、新しく決められたルールだし」とか議論されています。
ですから、あなたが不便を感じるようなら「名古屋弁で書かれているこういう件名が東京弁だと判断されると困る！」と証拠付きで議論に加わることであなたが望む結果になるよう努力することができます。
ただし議論は英語で行われていますし、この問題で困る大部分のひとは中国日本韓国だと思うので英語圏の開発者は困らない(=優先度が低い)し、名古屋弁だの東京弁だのはあくまでも例えなのでそのまま翻訳しても理解してもらえません。

最後に少しだけ苦言を書いておきます。が、個人的な主張なので読み飛ばして構いません。
結論から言えばフリーソフトウェアのエンドユーザは「何も知らないお客様」ではダメです。
Thunderbirdを始めとしたフリーソフトウェアはAt Your Own Riskで使うもので、有償サポート契約でも結んでいなければ問題の解決は基本的に自助努力で行われるべきです。
ここのような相互サポートを行う場を有志が立ち上げる場合もありますが、「相互」サポートであることと「Mozilla製品の」サポートであることを理解してほしいなと強く思います。
自分が使っているソフトウェアがどういう理屈で動いているのか、自動車で言うならエンジンだとか車輪だとかガソリンだとかエンジンオイルだとかそういう基礎的な用語や、燃料と空気をいい感じで混ぜて爆発させるなんていうエンジンを動かす簡単な理屈に相当する部分くらいは知っておくべきです。

分からなければ尋ねる前に調べましょう。
調べても分からなければ「どこが分からないのか」を細かく分類してから尋ねましょう。
全部わからないは全く調べていませんと同義です。

[b]meeyar様
ご丁寧にいろいろ有り難うございます。

高度なレベルでとても理解ができません。
理解ができたら読めば解決するのだろうと思いますがわからないので聞いております。

自分が立てたサーバからのメールが文字化けしているようですが、
下手にアプリをいじっていたら本文まで文字化けしてしまい
どうにもならなくなってしまいました。

[/b]Subject: [ｘｘ] $B%-%e!<%V7r9/?)IJ=q(B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-2022-JP"ヘッダー部はこれぐらいしか説明ができません。

すみません自分の環境をうまく説明できないので
これ以上はたぶん聞けないと思います。

しかし、通常にメールを使ってる人がトラブってそこまで高度なスキルをもってないと
敷居が高くて聞けないのも変だと思うのですが。

Thunderbirdを使っていて同じ悩みを抱えてる人も多いかと思います。
どうかわかりやすい言葉でお伝えいただけると助かります。

スレッド全体に目を通されていますか。
先に、「相当するなら」と書きましたが、
[quote]1. MIME形式でないPlain text
2. MIME形式でヘッダに
　Content-Type: text/plain; charset="iso-2022-jp"
　Content-Transfer-Encoding: 7bit
　MIME-Version: 1.0
　の指定がある。

1/2.のいずれかで、かつ本文・Subject:がISO-2022-JPエスケープシーケンス
(BASE64ではなく直接ESC$B,ESC(Bの埋め込みによるプレーンテキスト)で
7bit JISエンコーディングされている。[/quote]
これらの条件にあてはまるということでよいでしょうか？

関連情報は上記スレッドのほか、今日付け(7/23)の記事で、
[url=http://forums.mozillazine.jp/viewtopic.php?f=3&t=15545]MozillaZine.jp フォーラム ; トピック - 件名（Subject）の文字化けについて [Thunderbird 38.0 系][/url]
に対処法が書かれているので、こちらも確認してみてください。

一方で、Thunderbird側の対応についてですが、一応それらしき報告はBugzillaに出ているようです。
ただし、いずれもメールのヘッダ情報が提示されていないため、確実に同一現象と断定はできません。
[url=https://bugzilla.mozilla.org/show_bug.cgi?id=1176722]Bug 1176722 ; charset problem in subject field[/url]
[url=https://bugzilla.mozilla.org/show_bug.cgi?id=1176662]Bug 1176662 ; Mojibake in subject line[/url]

「どうしても修正を」と希望されるなら、上記のようなBugzillaの報告にヘッダの生情報（ctrl+Uで表示されるメッセージソースに相当する情報)を提示し、MIMEエンコーディングではないメールであってもデコードできるように要望する必要があると思います。

ただ、今回の変更がRFC5335に従うものであるならば（きちんとRFCの文章を確認してわけではありませんが[url=http://forums.mozillazine.jp/viewtopic.php?t=15539&p=55515#p55519]そういう指摘がある[/url]ので)、「RFC違反であっても対応してほしい理由」も開発者側にわかるように提示、説得する必要があるでしょう。

[quote="meeyar"]該当するメールが
[url=http://forums.mozillazine.jp/viewtopic.php?t=15539&p=55515#p55515]MozillaZine.jp フォーラム; トピック - Thunderbird 38.* で日本語プレーンテキストの件名が表示されない[/url]
に相当するなら、上記リンク先を参照してください。[/quote]

拝見しましたが解決されていないようです。
結果的には31.1まで落としたほうがいいということでしょうか？
数日前までは問題なく使えていたので、なにが変わったのかわかりません。

該当するメールが
[url=http://forums.mozillazine.jp/viewtopic.php?t=15539&p=55515#p55515]MozillaZine.jp フォーラム; トピック - Thunderbird 38.* で日本語プレーンテキストの件名が表示されない[/url]
に相当するなら、上記リンク先を参照してください。

Windows7（64）でThunderbird38.1を利用させて頂いています。
昨晩、自動アップデートしたと思いますが、急に一覧の件名が一部文字化けをしてしました。

Subject: [xxxx] $B$*?6$j9~$_$N$4

メール単体の件名は文字化けされてなく、一覧が一部文字化けしています。
原因不明でしたので、アプリをダウングレードをしてみましたが、
改善されません。

どうすれば改善ができるのでしょうか？
それともソフト自体を削除し、再インストールするか悩んでおります。
どうぞよろしくお願いします。