当社は、幹部社員が、非マイクロソフト派で、Netscape → Thunderbird を標準にしているのですが、あまりの出来の悪さに、自分は有料メール Shuriken 2010 に避難しました。直して欲しいというより、ソフトとしての配布を停止して下さい。

新規開発が中止になったと聞いた時、「当たり前だろうが！！」 と思いました。Firefoxは誠実で良いソフトだと思いますが、Thunderbirdは、0点どころか、マイナス50点ぐらいをあげたいです。
パッチだけ開発とか、曖昧な事を言わず、潔く、歴史に幕を下ろすのが正しいと思います。

問題点(1) 未だに日本語に完全に対応できない。日本で配る資格無し。
　prefs.js が文字化けし、パスワードを一切覚えなくなるなど、根幹部分が不安定すぎます。ごみ箱が、Trash と ごみ箱 に生き別れになる等、Thunderbird以外では殆どお目にかかれません。IMAPの対応も不十分で、英語とローカライズを読替える部分は、情けないほど不安定です。

　サーバーに作ったフォルダを削除できないとか、IMAPに対応していると、言えるのでしょうか？ 英語で作ったフォルダは制御できるが、日本語のファイルは一旦作ったら、管理者に頼まないと削除できないというのは、明らかに文字コードの問題でしょう。CentOS 5.4のUTF-8で、KDDIの法人向けサーバーですから、サーバー側のせいとは到底思えない。他のソフトは、ちゃんと制御できますしね。

問題点(2) 定期的にパスワードを変更するように出来ていない。
　【アカウント設定に、パスワード入力欄が無い仕様は理解不能です】。

　変更になった事が分かっているのに、あらかじめ入力できないのは、管理体制をバカにしています。

　お客様に、送信するその時にしか、パスワード入力欄が出てこないのでは、業務に支障が出るに決まっています。おまけに、行きと帰りで別々にパスワードを保存しているため、1セットしかない、IDパスワードを、最低2度入れる必要があります。

　更に、証明書エラーが出ると、パスワードの保存も行われない事が多いです。たった1回変更になったパスワードを、3回、4回と入れては保存して、また聞いてくるのでは？ と固唾を呑んで、送受信を見なければならないソフトは、もう動作しているとは言えない気がします。

　設定したはずのパスワードを、何度も何度も聞いてくる、おバカ振りに、呆れました。他のソフトでこんな事が起きるものは、1つも無いです。

問題点(3) パスワードの保存方法が、根本的に問題。
　借り物のLinuxホスティングサーバーなどは、ID・パスワードは1セットしかない事が殆どです。ところが、ポートごと、サーバー名ごと、送信、受信と、パスワード保存がバラバラ。
　例えば、社内設定を暗号化に変更して、ポートが587から、465に変わったりすると、パスワードが別に保存され、不整合が発生します。そんな構成になっているとは、ユーザーは普通思いません。営業マンが客先で困ってしまうケースが多発。迂闊にパスワード変更が出来ない、本末転倒の事態が起きています。

　そもそも、パスワード変更は、定期的に行うもの。一旦パスワードを消去しないと、次に入力が出来ないのは、仕様に反しています。変更＝Change は、消去＝Delete じゃありませんよ！

　それと、送信時の認証に、「受信と同じものを使う」 と設定してあったはずのものを、勝手に、送信と受信に分けてしまうのは、仕様違反です。

問題点(4) アカウント配下に、全てが取り付く構成が、既に時代遅れ。
　アカウント操作を誤ると、全損、という怖い仕様。

　サーバーが古くなったので、ドメインはそのままに、移転する、というのは法人ではよくある話です。その際、一時的に、両方のサーバーを見に行く必要が出てきます。DNSは、書き換えにある程度時間がかかるからです。しかし、一時的に2受信トレイ制には、一切できません。必ずアカウント追加の概念になってしまいます。

　受信トレイ数＝アカウント数になっているからです。送信済みトレイや、他のトレイも同様。

　ところが、サーバー移転の場合、ドメインは不変ですので、メールアドレスは変わりません。同じメールアドレスで、アカウントを2つ作るとどうなると思いますか？

　account@domain.com という名のアカウントが、2セットできます。誤って、メインの方を削除したら、どうなります？　「全部のデーターが消失します！！！！！」。何ですか？ この仕様は？

問題点(5) 昨今の、仮想サーバーを想定していない仕様。
　子会社の方で、NTTComの仮想サーバーを借りているのですが、domain.com のテンポラリドメインが、xxx.securesites.net となっています。これも移転の際に起きたのですが、強制暗号化の 465番ポートが、移転先では、初期状態で対応していませんでした。DNSや、迷惑メールフィルタ等の、工事期間が1週間前後あり、その間、SSLでなく、STARTTLSを使い 587番に変更してくれと、連絡がありました。ところが。

　変更を告知した当日、社内中で、証明書エラーを連発、内線がパンクしました。ポートごとに、別々に記憶している仕様のようで、domain.com:465 を承認したのとは別に、domain.com:587 をまた別に承認しないとダメです。

　とにかく、継続使用中に、サーバー仕様の設定変更が起きた場合、呆れるほど、付いて来られないんですね。同じサーバー証明書ですよ？ ポートが変わったら、信頼性が変化するんですか？

　よくここまで不出来なソフトを作れましたね？　新しい機能を盛り込むとか、提携先のメール登録を宣伝するとかよりも、それ以前に、基本的な部分を、真剣に開発するのが先でしょ？

　シェアを獲得し、商売につなげる方法は沢山あったと思いますよ？

　長い歴史がある電子メールですが、使い勝手の悪い部分が、結構あります。

欲しい機能(1) 着信監視。
　Outlookのような有料のメールでも、ソフト自体が起動していない時に、メール着信を知らせる機能を持つソフトは少ないです。でもこれが無いとリアルタイムの対応が必要なビジネスでは全く役に立ちません。メインは無料でも、こういった便利機能を有料で売れば商売になる可能性はあります。

欲しい機能(2) バックアップ。
　Outlookには絶対に出来ないのが、これです。ご存知のように、Outlookは、設定から、メールから、アドレスから、仕訳から、全部1つのファイルにしてしまいます。送受信量が桁外れに多い、営業マンは、日々のバックアップなんて、絶対に無理です。4GBのPSTファイルが、ゴロゴロしているOutlookは、ハードディスクが壊れた瞬間、昇天する事が多いです。直近のバックアップはダメだった、ケースが一番多いのがOutlookです。
　細かくファイルを分割し、変更が掛かったものだけ、所定の場所に書き出すツールを作るのは、Thunderbirdの方が可能性があります。

欲しい機能(3) 設定概念だけを、インポート＆エクスポート。
　100人単位で同じ設定を作って送り込んだり、全員の設定を一気に変えたりできれば、安全対策としては理想。暗号化非対応のアカウントを、調べて、1つ1つ変えて歩くなど、非効率も甚だしい。
　基本設定を共通化して、仕様を引き継いでいく概念なしに、完成度の高いソフトが作れるのか？ と思いますね。prefs.js の文字コードの問題が、設定破損に繋がるThunderbirdの今の状況では、望むべくもないですが。

当サイトは Mozilla Foundation, Mozilla Corporation, Mozilla Japan と直接のつながりを持たない、Mozilla ソフトウェア利用者のオンラインコミュニティにすぎませんので、「配布を停止しろ」と仰られましても私どもには不可能です。

配布停止をご希望であれば Mozilla Foundation へ。
http://www.mozilla.org/

仕様変更をご希望であれば、御自分でパッチを書いて bugzilla に提出すれば将来のバージョンで取り込まれるかもしれません。
http://bugzilla.mozilla.org/

法人サポートをご希望であれば Mozilla Japan の法人向けサポートへ。
http://www.mozilla.jp/business/

ざっと眺めてみましたが…

問題点
1. pref.js は UTF-8 です。Trash とゴミ箱の生き別れも見たことありませんし、IMAP でもフォルダ管理は日本語で作ったものも含めて問題なく行えます。

2. 見落としておられるようですが、ツール→オプション→セキュリティ→パスワードからパスワードの管理は可能です。POP, IMAP, SMTP で別々にアカウント/パスワードの組を管理しているのは Netscape 時代からの仕様ですので今さら変わることはないでしょう。

3. submission port (587) と SSL (465) で改めてパスワードを聞かれた覚えはありません。

4. アカウントを削除しただけではメールの実体は削除されません。プロファイルフォルダ内に残っています。

5. オレオレ証明書使ってるからです。

欲しい機能
1. ソフトが起動していない状態での着信監視であれば、誰がどう見ても Thunderbird の管轄外でしょう。メールソフトと無関係にIMAP や POP の新着監視を行うソフトならいくつかあります。

2. プロファイルフォルダを丸ごとコピーしておけばバックアップになります。

3. 設定ファイルを前もって用意しておくことで一括設定は可能です。詳細は法人サポートへ。

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

前提として、

・ThunderbirdはMozillaが勝手に作って勝手に配布している物であるという事。（お客様の要望に応えるために作られている、というわけでは必ずしもないという事。）
・法人サポートという物はあっても、それはMozillaが公式に行っている訳ではなく、Mozillaの製品に詳しい他の一般企業がサービスを提供しているものであるという事。
・このフォーラムは、Mozillaのスタッフではない有志のユーザによって運営されており、ユーザ同士の情報交換によって相互に助け合いながらそれぞれの問題を解決していくことを目的として作られた物である事。（Mozillaという組織の「目安箱」ではない、という事。回答している側の人間も基本的には、エレジー。さんと同じ立場のエンドユーザであるという事。）

を、まずはご理解下さい。




自分は個人的にIMAPアカウントでThunderbirdを6年以上は常用していますが、日本語絡みの不具合には今の所遭遇していません。
今も試しに日本語のメールフォルダを作成→削除といった操作を試してみましたが、特に問題は起こりませんでした。
複数の条件が重なっている時にだけ問題が起こるレアケースに該当されているのではないかと思います。

レアケースである場合、「このような条件下で問題が起こる」という情報が開発コミュニティに伝わらない限りは、その問題が解決される可能性は残念ながら低いです。
情報を上流に伝えるためには、技術的に詳しい方が直接開発コミュニティに参加してバグを立てるか、有償の法人サポートの範囲でバグを立ててもらうかする必要があります。
また、暫定的にでも問題を解決するためには、やはり自力で解決するか、有償の法人サポートで解決してもらうかしないといけません。




パスワード欄をあらかじめ設けておくべきという要望が出なかったか、出ても何らかの理由で却下されたか、あるいは作業の優先順位によって後回しにされているかの、いずれかだと思われます。
もし要望が出ていなかったのであれば、要望が開発コミュニティに伝われば反映される可能性はゼロではありませんし、また却下されていた場合であっても、開発コミュニティを説得できるだけの十分な材料があれば、過去の決定を覆すことは可能だと思います。
作業者の手が足らずに後回しにされているだけなのであれば、自分でが開発者としてパッチを提供したり、あるいは、法人サポートの中で有償でのパッチ作成を依頼したりといった手もあります。
ただ、今すぐにそのような仕様に変更されなければ困る、という場合には、法人サポートでThunderbirdに改造を施すよう依頼する他ないと思われます。




Thunderbirdの中まで詳しく調べたわけではないのですが、通信が正常終了したことをもってパスワードを保存するという処理の流れになっているために、証明書エラーで通信が正常終了しなかった→パスワードが保存されない という状況に陥っているのではないかと思います。
Thunderbirdが認証のエラーと証明書のエラーとを分けて認識していない事が原因なのであれば、この点はThunderbirdに改善の余地があると自分も思います。
ただ、そうだとしても、この「問題」がすぐに解消される可能性は残念ながら低いです。
早急にこの点が改善されなければ困るという場合には、これも、法人サポートを行っている企業に改造を依頼するしかないと思います。









これらも同様です。

前述した通り、MozillaはMozillaの思惑に則って開発を進めているため、外部からThunderbirdのあり方をコントロールすることは難しいです。
今あるThunderbirdを所与の物として捉えた上で、それがどれだけ自分のニーズに近いのか、ニーズとかけ離れている部分があるのであればそれは解決できるのかどうか（公開されているアドオンを使う、有償サポートの範囲内で改造やアドオンの開発を依頼する、など）を検討して、その結果のトータルコストがExchange ServerとOutlookを一体とした統合メール製品などを導入する場合のコストと比べて本当に安く済むかどうかをきちんと判断してから、採用するかどうかを決定し、運用していく必要があります。

Thunderbirdは、導入にあたってそのような「リスク」がある製品だという事を、どうかお忘れにならないで下さい。