現在　Thunderbird/3.1.10　を使用しております。
その他の環境は　WindowsXP Home Edition Version2002 Service Pack 3
（OSは最近Windows 7 HomePremiumでも同じ現象でした。
セキュリティーソフトは　ウイルスバスター2011クラウドです。


現象としては、相手方のメーラーがLotus Notesの場合、そのメールを転送しようとすると
添付ファイル名が全て「�」となってしまいます。

その他のメーラーで同じ事を行っても添付ファイル名は大丈夫です。

相手方にメーラーをかえてとは言えないのでとても困っております。
過去の履歴などを見たんですが、解決方法が分かりません。
初心者の質問かもしれませんが、どなたかお分かりになる方が
いらっしゃいましたらご教授頂けませんでし ょうか？

よろしくお願い致します。

　　
文字化けする事例の多くが文字コードがマッチしていないか、その指定がおかしいケースです。
Lotus Notes は知らないのですが、そのメッセージのヘッダと添付ファイルのヘッダをよく確認して
みてください。（ソース表示で確認できます）

転送する前の状態と転送後の状態で変化してますか？
　

kiki様

ご連絡ありがとうございます。
早速添付ファイルのソースを確認してみました。

【元メールの添付ファイルヘッダ】
Content-type: application/pdf;
name="=?Shift_JIS?B?lKCRZ5engsSO5pDgYTRfMDUzMC5wZGY=?="
Content-Disposition: attachment; filename="=?Shift_JIS?B?lKCRZ5engsSO5pDgYTRfMDUzMC5wZGY=?="
Content-Transfer-Encoding: base64

【転送後メールの添付ファイルのヘッダ】
Content-Type: application/pdf;
name="=?UTF-8?B?77+9?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*=UTF-8''%EF%BF%BD

メールのソースはどこをご連絡していいか、分からなかったため
申し訳ございませんが、連絡できていません。

よろしくお願い致します。

　　　
Thunderbird 3.1.10 / Windows 7 Professional SP1 環境下で再現テストをしたところ、以下のよう
になりました。

【添付ファイルヘッダ】
文字コード：Shift_JIS のメッセージに添付した場合

Content-Type: application/pdf;
name="=?Shift_JIS?B?lKCRZ5engsSO5pDgYTRfMDUzMC5wZGY=?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0*=Shift_JIS''%94%A0%91%67%97%A7%82%C4%8E%E6%90%E0%61%34%5F%30%35;
filename*1*=%33%30%2E%70%64%66


【転送メッセージの添付ファイルのヘッダ】
文字コード：UTF-8 のメッセージで転送（添付形式）をおこなった場合

Content-Type: application/pdf;
name="=?UTF-8?B?566x57WE56uL44Gm5Y+W6KqsYTRfMDUzMC5wZGY=?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0*=UTF-8''%E7%AE%B1%E7%B5%84%E7%AB%8B%E3%81%A6%E5%8F%96%E8%AA%AC;
filename*1*=%61%34%5F%30%35%33%30%2E%70%64%66


上記から filename の部分の違いがわかるかと思います。
簡単に説明しますと添付ファイル名を扱う規格の違いによるものです。

RFC2231 と RFC2047 という規格があるのですが Lotus Notes は古い規格を採用しているようです。
決して間違っているというわけではなく、新しい標準規格に対応していないということです。

Lotus Notes は多くの企業・団体などで利用されているようですので変更してくれとは言い難いです
ね。おそらく説明しても理解を得るのは大変でしょうし、理解を得られても変更対応は困難を伴うも
のと考えられますね。　

結論的には残念ながら回避方法としての決定策はありません。

Thunderbird も以前までは mail.strictly_mime.parm_folding のパラメータを変更することで対処で
きたのですが、現在は仕様が変更されて固定化されたようです。
もしお願いできるようでしたら添付ファイル名を英数字のみにしていただくぐらいしか思いつきません。
　
自動的に変換してくれるアドオンや別途ツールなどがあればそれを利用することで対処できるかも知
れませんが、あいにく存じておりません。

　
[参考]
【解決済み】「mail.strictly_mime.parm_folding」の設定について
Attachments renamed - MozillaZine Knowledge Base
　

ご連絡ありがとうございました。

解決はできませんが、理由が分かりすっきりしました。
手作業でなんんとかします。
この度はありがとうございます。

回答ではないですが…


なぜか「箱組立て取説a4_0530.pdf」が U+FFFF に化けるという問題だと思いますが、どの辺りが RFC 2231 の話なんでしょうか？


間違っていると思いますが。
http://www.emaillab.org/essay/japanese-filename.html

間違えた orz
なぜか「箱組立て取説a4_0530.pdf」が U+FFFD に化けるという問題

横から失礼します。
少々不可解な点があるので、コメントさせていただきます。

kiki さんの検証結果を拝見し、適当に作った「箱組立て取説a4_0530.pdf」というファイルを添付して、デフォルト状態の Thunderbird で自分あてにいくつかのパターンで送受信・転送をおこなってみました。
しかし、Thunderbird で "添付ファイル名が全て「U+FFFD」になる" という現象は再現できませんでした。
（Windows XP SP3 + Thunderbird 3.1.11）

Thunderbird の動作としては、メッセージ本文と添付ファイル名を異なる文字セット（charset）でエンコードすることはなく、[文字エンコーディング] で選択した形式が全体に適用されます。

転送についても、元メッセージの本文部分のエンコード形式を踏襲して全体を同形式で再エンコードして送り出すようです。

以上が Thuderbird についての基本的な動作概要だと思います。

一方、mozi さんの提示されたソースのうち、【転送後メールの添付ファイルのヘッダ】は明らかにおかしいです。
name 、filename とも、「箱組立て取説a4_0530.pdf」というファイル名がまともにエンコードされたものとは思えません。この引用ソースのとおりだとしたら、RFC2231 / RFC2047 以前に文字の欠落など致命的な処理ミスがあるように見えます。

Lotus Notes を試せる環境がないので推測の域を出ませんが、もしも本文のエンコーディングと添付ファイル名のそれが異なる形で送られてきたメッセージだとしたら、これに対し Thunderbird は本文のエンコーディング方式に準じて転送を試みますから、添付ファイル名の再エンコーディングを適切に処理できない…といったようなことがあるのかもしれません。
このあたりは【元メールの添付ファイルヘッダ】の情報だけでは判断がつきませんが......。

ご質問の内容は "添付ファイル名が全て「U+FFFD」になる" ということですが、そもそもこれをどこで確認しておられますか。あるいは、先の投稿で提示された【転送後メールの添付ファイルのヘッダ】は、どこから取得なさったのでしょう。
転送先からでしょうか？　転送元（つまり mozi さん）の Thunderbird の [送信済みトレイ] に残った控えからでしょうか？

との確認もとれているなら、mozi さんがお使いの Thuderbird に問題が起こっている可能性が考えられます。トラブルシューティングの定石であるセーフモードや新規プロファイルでの動作検証は実行なさいましたか？
・セーフモード
・複数のプロファイルを使用する

いずれにしても、Lotus Notes が問題のメッセージ全体をどのように処理して送ってきて、それを Thunderbird がどのように受け取り、転送し、転送先のメールクライアント（メーラー）がどのような受け取り処理をしたか、そのあたりの具体的な中身がつかめないと、本当のところはわからない気がします。

（余談）
そもそも Shift_JIS でエンコードしてくることの是非ですが、これは "絶対に間違っている" とは言い切れません。そのような文字セットを指定したエンコーディングができる余地があるからです。
しかし、ビジネスシーンではあまり耳にしたことがありません。とくに海外との取引や交流がある企業・団体等では、なおさらです。
Shift_JIS は日本語に限った文字セット（charset）ですし、日本語に限ったメールであっても標準的に使われるものではないからです。
ごく一般的な日本語メールなら ISO-2022-JP が標準的に使われますし、多言語対応なら UTF-8 が使われるでしょう。そのほうがより多くの環境で文字化け等のトラブルを避けられるからです。

実際、IBM のサポートページに次のような技術情報があります。
日本語のファイル名を添付した場合、そのファイル名が Shift-JIS でエンコードされる
（関連）
Knowledge Collection：Lotus Notes/Domino での既知の文字化け障害について
つまり、Lotus 製品側の問題として認識されており、解決方法も書かれています。

本質的な解決策ではなくて申し訳ないですが、気がついた点をコメントさせていただきました。
不正確なことを書いてたらすみません。＞ どなたかフォローいただけるとありがたいです。