[quote="nino"]結論から言うと、社内で利用しているFirewallの不具合でした。[/quote][quote="nino"]PAN-152003

Fixed an issue where an email client was unable to open an attached file due
to removal of part of the file name encoded in UTF-8 by the firewall CTD
function for SMTP and NAT sessions.[/quote]
この Issue が記載されているページは https://docs.paloaltonetworks.com/pan-os/10-0/pan-os-release-notes/pan-os-10-0-addressed-issues/pan-os-10-0-3-addressed-issues ですね。
いやあ、MTA/MDA じゃなくて Firewall でしたか。
しかし、ネットワークアドレス変換でどうしてメールデータ中の添付ファイル名部分が壊れちゃうんでしょう。
不思議なバグですね。

ようやく解決しました。
色々とご助力いただきましたので、解決に至った内容を報告します。

結論から言うと、社内で利用しているFirewallの不具合でした。
PaloAltoのFirewallで不具合があり、ファームウェアのバージョンを
10.0.3にアップデートすると解消するようです。

前提としてメールサーバが該当Firewallの配下にあり
該当FirewallでNATをかけていると発生する物のようです。

NATをかけない経路では文字化けが発生しなかったり
などパケットのキャプチャを行ってもなかなか切り分けが
付きづらいものでした。

同じようなスレッドも複数上がっているようですし参考に
なればと思います。

PAN-152003

Fixed an issue where an email client was unable to open an attached file due
to removal of part of the file name encoded in UTF-8 by the firewall CTD
function for SMTP and NAT sessions.

もちろんわかっているかとは思いますが、念のため。

私が提示しました Thunderbird で作成したソースはどれも正しいものです。
仮に utf-8 → UTF-8 の変更で受信メールの添付ファイル情報が壊れたとしても、
それはあくまできっかけであって、メールサーバー側またはその他の何かによる問題でしょう。
私は Thunderbird で、Gmail、Outlook.com、Yahoo!メール、Zoho Mail などを利用してきましたが、
今まで送信したメールの添付ファイルが受信先で壊れたことは一度もありません。

EarlgreyTeaさん

回答ありがとうございます。
大文字、小文字の違いですかぁ・・それらが別の場所（MTA等)に影響を与えて
結果おかしくなっているのかも知れませんね。
ありがとうございます。

複数箇所でキャプチャして、被疑箇所を限定します。

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

Thunderbird の側で生成ソースに何か変化があるか調べてみました。
同じ手順でThunderbird 60.9.1 / 68.11.0 / 78.2.1 にて作成したメールの添付ファイル冒頭は以下の通りでした。
60.9.1：[code]Content-Type: application/pdf;
name="=?UTF-8?B?44Oe44Km44K544Kz44Oz44OU44Ol44O844K/44O8KFNUMDA3MDcwNDM3?=
=?UTF-8?B?KS5wZGY=?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0*=utf-8''%E3%83%9E%E3%82%A6%E3%82%B9%E3%82%B3%E3%83%B3%E3%83%94;
filename*1*=%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%BC%28%53%54%30%30%37%30%37;
filename*2*=%30%34%33%37%29%2E%70%64%66

[/code]68.11.0：[code]Content-Type: application/pdf;
name="=?UTF-8?B?44Oe44Km44K544Kz44Oz44OU44Ol44O844K/44O8KFNUMDA3MDcwNDM3?=
=?UTF-8?B?KS5wZGY=?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0*=UTF-8''%E3%83%9E%E3%82%A6%E3%82%B9%E3%82%B3%E3%83%B3%E3%83%94;
filename*1*=%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%BC%28%53%54%30%30%37%30%37;
filename*2*=%30%34%33%37%29%2E%70%64%66

[/code]78.2.1：[code]Content-Type: application/pdf;
name="=?UTF-8?B?44Oe44Km44K544Kz44Oz44OU44Ol44O844K/44O8KFNUMDA3MDcwNDM3?=
=?UTF-8?B?KS5wZGY=?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0*=UTF-8''%E3%83%9E%E3%82%A6%E3%82%B9%E3%82%B3%E3%83%B3%E3%83%94;
filename*1*=%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%BC%28%53%54%30%30%37%30%37;
filename*2*=%30%34%33%37%29%2E%70%64%66

[/code]
60.9.1→68.11.0 の間に filename の値のエンコード指定が「utf-8」→「UTF-8」と小文字から大文字に変わっていました。
しかし、それ以外に変化はありません。

【追記】
上記変化がどの時点に適用された修正によるものかを探索しました。
その結果、nightly 68.0a1 (2019-05-06) での変更で変わっていました。
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=0532fb6e8fa386c644c2ffc1c043f857a4458a1b&tochange=93c409ccf8a2211642d9b3b48a8fb74b2dabb0b5

そして、おそらく下記バグの修正によるものと思われます。
[url=https://bugzilla.mozilla.org/show_bug.cgi?id=1532668]Bug 1532668[/url] Thunderbird breaks UTF-8 character withing encoded words (violates RFC 2047) on RFC 2231 multiline filename generation

これのリリース（ESR）版への適用は 68.0 となっていますね。

[quote="EarlgreyTea"]Thunderbird に 6.10 というバージョンは存在しませんが、6月10日ということでしょうか。[/quote]

すみません、68.10.0の誤りです。

Thunderbird に 6.10 というバージョンは存在しませんが、6月10日ということでしょうか。

EarlgreyTeaさん

回答ありがとうございます。
Postfixの方も合わせて調査してみます。

ただ少し気になる点として該当のメールサーバは2年近く運用していますが
これまでは、添付ファイルの表示がうまくできないという事は発生しませんでした。
filenameのステートメントの扱いが、Thunderbird側で6.10あたりで変更になった
等の情報はリリースノート等からは読み取れませんでした。

なぜ急にこの事象が発生し始めたのか？という点が不可解です。

また説明が漏れていましたが、同様に複数行のfilenameステートメントが
正しく処理できるものもありますし
同じファイル名でも送受信が問題なく行えるケースもあり非常に難解な挙動を
示しています。

[quote="nino"]A1
送信側で発生します。[/quote][quote="nino"]A2
受信時は、ThunderbirdやOutlook等でファイルが見えなくなっているのを
確認しています。送信ソフトウェアがOutlookの場合は発生していないようです。[/quote]
Thunderbird で添付ファイル付きのメールを作成し、御社メールサーバー経由で送信した場合に、受信したメールの添付ファイルが開けなくなる場合がある、ということですね。
そして、Outlookでメールを作成した場合には発生していないのですね。

[quote="nino"]A4
マウスコンピューター(ST007070437).pdf
というファイル名です。[/quote]
同じ名前を付けたPDFファイルを用意し、それを添付したメールを Thunderbird と Outlook（Microsoft 365）で作成して送信（Outlook.com 使用）してみました。
受信したメールソースの添付ファイル冒頭部分は以下の通りでした。
Thunderbird：[code]--------------CA71EBF1837BB6E7078BC4EB
Content-Type: application/pdf;
name="=?UTF-8?B?44Oe44Km44K544Kz44Oz44OU44Ol44O844K/44O8KFNUMDA3MDcwNDM3?=
=?UTF-8?B?KS5wZGY=?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0*=UTF-8''%E3%83%9E%E3%82%A6%E3%82%B9%E3%82%B3%E3%83%B3%E3%83%94;
filename*1*=%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%BC%28%53%54%30%30%37%30%37;
filename*2*=%30%34%33%37%29%2E%70%64%66

JVBERi0xLjMNJeLjz9MNCjM5MSAwIG9iag08PC9MaW5lYXJpemVkIDEvTCAxNDUxMjc3Mi9PIDM5
（以下略）[/code]Outlook：[code]--_002_TYAP286MB0267D0AAB1240159EF116E4C88260TYAP286MB0267JPNP_
Content-Type: application/pdf;
name="=?utf-8?B?44Oe44Km44K544Kz44Oz44OU44Ol44O844K/44O8KFNUMDA3MDcwNDM3KS5w?=
=?utf-8?Q?df?="
Content-Description:
=?utf-8?B?44Oe44Km44K544Kz44Oz44OU44Ol44O844K/44O8KFNUMDA3MDcwNDM3KS5w?=
=?utf-8?Q?df?=
Content-Disposition: attachment;
filename="=?utf-8?B?44Oe44Km44K544Kz44Oz44OU44Ol44O844K/44O8KFNUMDA3MDcwNDM3KS5w?=
=?utf-8?Q?df?="; size=14512772;
creation-date="Wed, 09 Sep 2020 00:36:33 GMT";
modification-date="Wed, 09 Sep 2020 00:44:45 GMT"
Content-Transfer-Encoding: base64

JVBERi0xLjMNJeLjz9MNCjM5MSAwIG9iag08PC9MaW5lYXJpemVkIDEvTCAxNDUxMjc3Mi9PIDM5
（以下略）[/code]
上記を Content-Disposition フィールドに着目してみますと、実は RFC的には Thunderbird が正しく、Outlook が正しくない（準拠していない）ということがわかりました。
これの根拠は [url=https://emaillab.org/emailref/RFC/rfc2231.txt]RFC-2231[/url] および [url=https://emaillab.org/emailref/RFC/rfc2183.txt]RFC-2183[/url] で、以下のページの説明をお読みください。
https://emaillab.org/essay/japanese-filename.html

おそらく、御社のメールサーバーが Thunderbird の複数行連番の filename パラメーターを正しく処理できず、2行目以降の値や改行が欠損してしまったのではないかと思われます。
そういった観点で Postfix 2.10.1 関連の情報を調べてみたら、解決策が見つかるかもしれません。

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

> 説明が不足しているところがあり、状況を把握できないので以下お答えください。

説明不足で申し訳ありません。

問1：
Thunderbird はメール送信側、それとも受信側のどちらでしょうか。

A1
送信側で発生します。

問2：
Thunderbird が受信側（送信側）だとしたらメールを作成・送信（受信）しているソフトは何でしょうか。

A2
受信時は、ThunderbirdやOutlook等でファイルが見えなくなっているのを
確認しています。送信ソフトウェアがOutlookの場合は発生していないようです。

問3：
ソース情報を確認されたメールは、メールソフトに受信されたものでしょうか。

A3
はい

問4：
ご提示の「Content-Disposition」ヘッダーは、ファイル名がファイル内容部分と改行なしにくっついているだけでなく、内容が空の「filename*1*=」「filename*2*=」が奇妙です。
「filename*0*=」部分をデコードすると「マウスコンピ」となり、ファイル名の後半が切れてしまっているようです。
実際のファイル名は何でしょうか。

A4
マウスコンピューター(ST007070437).pdf
というファイル名です。

問5：
マルチパート各部の「Content-Type」「Content-Transfer-Encoding」の情報も教えてください。

A5
Content-Type: application/pdf;
Content-Transfer-Encoding: base64
です。

EarlgreyTea と申します。

nino さん
説明が不足しているところがあり、状況を把握できないので以下お答えください。

問1：
Thunderbird はメール送信側、それとも受信側のどちらでしょうか。

問2：
Thunderbird が受信側（送信側）だとしたらメールを作成・送信（受信）しているソフトは何でしょうか。

問3：
ソース情報を確認されたメールは、メールソフトに受信されたものでしょうか。

問4：
ご提示の「Content-Disposition」ヘッダーは、ファイル名がファイル内容部分と改行なしにくっついているだけでなく、内容が空の「filename*1*=」「filename*2*=」が奇妙です。
「filename*0*=」部分をデコードすると「マウスコンピ」となり、ファイル名の後半が切れてしまっているようです。
実際のファイル名は何でしょうか。

問5：
マルチパート各部の「Content-Type」「Content-Transfer-Encoding」の情報も教えてください。

ひとまず、ここまでよろしくお願いします。

7月の上旬あたりから、会社のメールサーバでThunderbirdでのみ添付ファイルが
送信先で見れないという事象が発生しています。

実際に添付ファイルが見れなかったメールのソース情報を確認すると

Content-Disposition: attachment;
filename*0*=UTF-8''%E3%83%9E%E3%82%A6%E3%82%B9%E3%82%B3%E3%83%B3%E3%83%94;
filename*1*=
filename*2*=
JVBERi0xLjQKJdPr6eEKMSAwIG9iago8PC9DcmVhdG9yIChNb3ppbGxhLzUuMCBcKFdpbmRv

と表示され、filename*2*の後にもう1行改行コードが入っていない為
メールの受信時に異常に長いファイル名と判別され、添付ファイルとして
認識されないのでは無いかと思っています。
メールサーバ側でパケットのキャプチャを行いましたがサーバ到着時には
改行コードが残っていました。

メールサーバや別の機器で改行コードが無くなっていたり、こちらで質問する内容では
無いかもしれませんが、切り分けも十分に行かずに困っています。

お知恵を拝借できればと思い投稿させていただきました。

環境は、
OS:Windows10 Pro64bit(1903)
Thunderbird68.11.0(32ビット）～68.12.0
メールサーバ：redhat enterprise linux 7
Postfix 2.10.1(Yum経由でのインストール)
です。
なお、qmail環境への送信などでは、本事象の発生は見られず
別メーラーでも、同様の事象の発生は無いようです。