偶然的通行人 さん、素晴らしいフォローありがとうございます。

486831 さん
私のアプローチは「メール本文が途中で切れて送信される」という「事象」をきちんと把握するためのものでした。
今のところその「事象」は
[list]
[*]2台のPCから半角カナを含むメールをThunderbirdで送信した際
[*]送信済みトレイには全文残っているが、相手に届いたメールでは半角カナの部分から後ろが欠損していたことがある
[*]それは頻度は低いが複数回発生した[/list]ということのようです。

ただ、やりとりに時間がかかり過ぎちゃってるので原因の絞り込みもやらなきゃですね。

発生率が低いのをなんとかしたいところですが、問題の「事象」が発生したのと同じ文面のメールを送信したら再現できるのでしょうか？
もし再現性があるのであれば、問題の切り分けを進めることができます。

すなわち、再現性のあるメール文面を
[list]
[*]Thunderbirdをセーフモードにして送信（アドオンの影響）
[*]他のPCから送信（送信側PC環境の影響）
[*]他の相手に送信（受信側PC環境の影響）[/list]することで大雑把な切り分けが可能かと思います。


では、「事象」を把握する作業の方に戻りたいと思います。

[quote="486831"]Meryで表示すると下記のように「:」で切れていました。
（中略）
【新規】316個
　　・559302:[/quote]
半角カナ以降が実際にまるごと欠損しているわけですね。
ご提示のメールソースは受信側のものかと思いますが、送信側の送信済みトレイに残されているメールはどうなっているのでしょうか？

何度もしつこいかもしれませんが、半角カナだったのか全角カナだったのかを確認したいです。
他のメールソフトが作成したメールなら、ISO-2022-JPと言っておいて半角カナを送ってくることもあるかもしれませんが、Thunderbirdが作成したメールで半角カナだと明らかに異常ですので。
それ以外にもなにかの手掛かりが見つかるかもしれません。

よろしくお願いします。

遅ればせですが、横から失礼します。

ざっくりとですがここまでの流れを拝見して、ぼくも EarlgreyTea さんが仰っている
[quote="EarlgreyTea"]ちょっと疑問なのですが、ISO-2022-JPエンコーディングで送信するなら、半角カタカナは全角カタカナに変換されているはずです。
ISO-2022-JPには半角カタカナは含まれていませんので。
送信済みトレーの送信メールコピーや下書きの時点でそうなるはずです。
UTF-8 じゃないと半角カタカナは送れないはず。[/quote]
というご意見に、まったく同感です。
標準的な設定状態の Thunderbird で本文に半角カタカナを書いて送ろうとすると、必ず UTF-8 でエンコーディングされます。
この "本来は考え難い現象" を起こしている原因がどこにあるのか、ということが焦点になってくるわけですよね。

[quote="486831"]私のPCからでは再現できなかたのですが、ある従業員のPCからメール送信を行うと
ごくたまにメール本文が途中で切れた状態で、送信される事象が発生しています。[/quote]
486831 さんと、「ある従業員」の方の PC は異なるが、OS や Thunderbird のバージョンは同じだとすると、Thunderbird の普遍的なバグとかいった話ではなく、問題が起こる PC 環境固有の原因が潜んでいる可能性があると考えるのが自然だろうと思います。
この場合、「ある従業員」の環境において、
（a）変更されている Thunderbird 本体の設定
（b）導入されているアドオン（拡張機能）の種類と設定内容
（c）セキュリティ対策ソフトなど、Thunderbird 以外からの干渉
（d）その他、法人内における個別事情に関する事柄
といったことが、点検対象に挙がってくると思います。

本件の問題が発生する相手（宛先）が固定しているなら、その相手側にも原因の一端があるかもしれませんから、同様に上記の事柄を調べてみるほうがいいと思います。
差出人は「ある従業員」に固定されているが、複数の相手（宛先）でご質問の現象が発生しているのなら、差出人の環境に絞って差し支えないだろうと思います。

過去トピックに、[u]長い件名が途中で途切れる[/u]という問題が投稿されており、これはアドオンの動作仕様が影響していました。
（参考）
・SmartTemplate4の%subject%の文字列が切れる
forums.mozillazine.jp/viewtopic.php?f=16&t=15387

本件の場合は本文で起こっていることなので上記と同じではありませんが、似たような理屈で本文文字列に対して影響を及ぼしているアドオン（拡張機能）があるかもしれません。
ここまでの話の中でアドオンに関する言及がなかったので、トラブルシューティングの定石として「セーフモード」での動作確認はやっておいたほうがいいのではないでしょうか、と提案させていただきます。

ただ、「ごくたまに」発生するという問題は、原因を絞り込むのが厄介です。

「セーフモード」で問題が起こらなかったとしても、たまたま正常に送信できただけかもしれず、正確な切り分けが難しいかもしれません。
あるいは、「ある従業員」が使っているアドオンと、486831 さんが使っているアドオンを比較して、怪しいそうなものを探り出す方法もあるでしょう。
このとき、ひとつのアドオンだけが原因になっている場合と、類似機能も持ったアドオンが競合して不良動作を起こしている場合があることに、ご留意ください。
仮にアドオンに原因があったとしても、本文内に特定の文字配列が存在したときにだけ発現する問題なら、そのあたりを絞り込むのも面倒だろうとは思います。

「社内間のメール」であるなら、しばらく「ある従業員」が送信するメールに Bcc 指定を付け、本人と 486831 さんのアドレスを指定しておくことで、「ごくたまに」起こる問題の追跡ができるかもしれません。（「ある従業員」が社内環境から私的なメールを送信している場合は難しいでしょうけど...。）
Bcc で受信した側には問題は起こらないが、宛先となった同じ社内の人の Thunderbird では本文が切れるということなら、受信側の方に原因がある可能性が高くなると思います。

原因究明よりも現状の改善を優先させたい場合は、ひとまず「ある従業員」の Thunderbird 環境を新規プロファイルに移行してしまうというのも、ひとつの手だろうとは思います。
これで問題が解消されるなら、アドオンや設定内容を含めたプロファイルの異常だったということになるでしょう。
同じ問題が再発するなら、Thunderbird 以外からの干渉を疑ったほうがいいように思います。


とりあえず思いつくことを書かせていただきました。読み込みが足りず的外れな話になっていたらすみません。


（おことわり）
現在、健康上の制約により不定期な書き込みしかできなくなっています。すぐに応答できない場面がかなり多くなりますことを、ご容赦ください。

お手数お掛けして申し訳ありません。
Meryで表示すると下記のように「:」で切れていました。

--------------3D25DC9B8576DCA4DE068C05
Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit


（メール本文）

【新規】316個
　　・559302:
--------------3D25DC9B8576DCA4DE068C05
Content-Type: application/vnd.ms-excel;
name="(中略)"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;

486831 さん

つまり、Excelファイルを添付したメールということですね。
[quote]
Content-Type: multipart/mixed;
boundary="------------3D25DC9B8576DCA4DE068C05"
Content-Language: en-US
（中略）

This is a multi-part message in MIME format.
--------------3D25DC9B8576DCA4DE068C05
Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

（ISO-2022-JPで書かれたメールの本文）

--------------3D25DC9B8576DCA4DE068C05
Content-Type: application/vnd.ms-excel;
Content-Transfer-Encoding: base64
（中略）
（Excelの添付ファイルをbase64でエンコードした文字データ）
--------------3D25DC9B8576DCA4DE068C05--

[/quote]

このメールを保存して .emlファイルにエクスポートし、いろいろな文字エンコードで表示できるテキストエディター（例えば https://www.haijin-boys.com/software/mery/mery-2-6-7 ）で開けば、（ISO-2022-JPで書かれたメールの本文）の部分はきちんと読めるはずです。
メール本文が本当にISO-2022-JPなら、半角カナ文字はISO-2022-JPに含まれませんので全角になっているはずです。
今一度ご確認ください。

>[highlight=#efefef][color=#323d4f][font=Lucida Grande, Trebuchet MS, Helvetica, Arial, sans-serif][size=4]次の部分の「Content-Type:」と「Content-Transfer-Encoding:」はどうなってますか？[/size][/font][/color][/highlight]

下記となっていました。

Content-Type: application/vnd.ms-excel;
Content-Transfer-Encoding: base64




また、一番最初の出てくるContent-Typeの部分は下記でした。

Content-Type: multipart/mixed;
boundary="------------3D25DC9B8576DCA4DE068C05"
Content-Language: en-US

[quote="486831"]メールのヘッダー部が下記のようになっていたのですが確認する箇所が誤っているでしょうか。

This is a multi-part message in MIME format.
--------------3D25DC9B8576DCA4DE068C05
Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit [/quote]
そのメールはマルチパートになっています。
その下に「--------------3D25DC9B8576DCA4DE068C05」で区切られて、
「--------------3D25DC9B8576DCA4DE068C05--」で終わる部分があるはずです。
その部分も確認してください。
添付ファイルだったり、プレーンテキストとHTMLのマルチパートメールかもしれません。

最初の部分は[code]Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit[/code]なので、ISO-2022-JPのテキストそのものです。
次の部分の「Content-Type:」と「Content-Transfer-Encoding:」はどうなってますか？

>先方のメールソフトはなんでしょうか？

今回、発生したのは社内間のメールでしたので
送受信共にThunderbird　52.9.1です。

.emlファイルをテキストエディタで確認してみましたが
申し訳ありあませんが、本文の箇所は英数記号の文字列となっているため
確認の仕方が分かりませんでした。


メールのヘッダー部が下記のようになっていたのですが
確認する箇所が誤っているでしょうか。

This is a multi-part message in MIME format.
--------------3D25DC9B8576DCA4DE068C05
Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

[quote="486831"]>問3 送信メールの本文が途中で切れていることはどのように確認しましたか？
>(a) 送信済みトレイに残っているメールと先方に届いたメールを比較したら内容が欠損していた
>(b) 送信済みトレイと先方に届いたメールの内容が欠損していたが、送信者に聞き取りを行ったら正しい内容で送信していたとの証言だった
>(c) その他

(a)です。[/quote]
先方のメールソフトはなんでしょうか？

そして先方に届いたメールは直接確認できるでしょうか？
可能なら、メールをソース表示、もしくは .emlファイルに保存してテキストエディタで開いて確認してほしいのです。
実は送信したメールデータは切れていないが、受信側の方で途中から表示できていないという可能性も考えられます。

送信側に残ったメールと、受信側のメールをソースで比較すると見えてくることがあるはずです。


[quote="486831"]「:」の後は、下記のように半角カタカタと数量が続きます。

ｽﾘﾑｱﾙﾐﾎﾞﾄﾙ ﾚｯﾄﾞ　53個[/quote]
ちょっと疑問なのですが、ISO-2022-JPエンコーディングで送信するなら、半角カタカナは全角カタカナに変換されているはずです。
ISO-2022-JPには半角カタカナは含まれていませんので。
送信済みトレーの送信メールコピーや下書きの時点でそうなるはずです。
UTF-8 じゃないと半角カタカナは送れないはず。

下記に回答いたします。

>特定の従業員様のPCでのみ、頻度は低いが複数回、その事象が発生するということでしょうか。

把握できているのは、PC２台で頻度は低く複数回発生しています。


>問1 事象が発生するThunderbirdのアカウント種類はPOP/IMAPのどちらでしょうか？IMAPの場合はもし社外のメールサービスをお使いでしたらそれも（差し支えなければ）教えてください。

POPです。

>問2 メールはプレーンテキスト、それともHTMLどちらでしょうか？ また、文字のエンコードはなんでしょうか？

プレーンテキストで、ISO-2022-JPです。

>問3 送信メールの本文が途中で切れていることはどのように確認しましたか？
>(a) 送信済みトレイに残っているメールと先方に届いたメールを比較したら内容が欠損していた
>(b) 送信済みトレイと先方に届いたメールの内容が欠損していたが、送信者に聞き取りを行ったら正しい内容で送信していたとの証言だった
>(c) その他

(a)です。

>問4 途切れたメール内容は実際も例示された感じだったのでしょうか？ それとも、もっと分量がある内容の該当部分のみ抜粋したのでしょうか？

抜粋しております。

全体で約３０行で、
切れてしまった部分は１７行程度で、文字数は420文字です、
>問5 行単位ではなく「:」の直後で切れているのが気になります。「:」やその直後に、間違ってUNICODEの特殊な文字を入れてしまったということはないでしょうか？メールのソースを表示(Ctrl+U)して確認してみてください。[/quote]
「:」の後は、下記のように半角カタカタと数量が続きます。

ｽﾘﾑｱﾙﾐﾎﾞﾄﾙ ﾚｯﾄﾞ　53個

[quote="486831"]私のPCからでは再現できなかたのですが、ある従業員のPCからメール送信を行うと
ごくたまにメール本文が途中で切れた状態で、送信される事象が発生しています。[/quote]
特定の従業員様のPCで[b]のみ[/b]、頻度は低いが[b]複数回[/b]、その事象が発生するということでしょうか。

その事象に関してもう少しお尋ねします。

問1 事象が発生するThunderbirdのアカウント種類はPOP/IMAPのどちらでしょうか？IMAPの場合はもし社外のメールサービスをお使いでしたらそれも（差し支えなければ）教えてください。

問2 メールはプレーンテキスト、それともHTMLどちらでしょうか？ また、文字のエンコードはなんでしょうか？

問3 送信メールの本文が途中で切れていることはどのように確認しましたか？
(a) 送信済みトレイに残っているメールと先方に届いたメールを比較したら内容が欠損していた
(b) 送信済みトレイと先方に届いたメールの内容が欠損していたが、送信者に聞き取りを行ったら正しい内容で送信していたとの証言だった
(c) その他

問4 途切れたメール内容は実際も例示された感じだったのでしょうか？ それとも、もっと分量がある内容の該当部分のみ抜粋したのでしょうか？

問5 行単位ではなく「:」の直後で切れているのが気になります。「:」やその直後に、間違ってUNICODEの特殊な文字を入れてしまったということはないでしょうか？メールのソースを表示(Ctrl+U)して確認してみてください。

OSがWindows7 Pro、メーラーはThunderbird 52.9.1 (32 ビット)の環境です。


私のPCからでは再現できなかたのですが、ある従業員のPCからメール送信を行うと
ごくたまにメール本文が途中で切れた状態で、送信される事象が発生しています。
原因など分かりますでしょうか。

メール本文には「--」は含まれていません。


■本来のメール本文
【定期出荷】100個
　・000001:商品名A　20個
　・000002:商品名B　50個
　・000003:商品名C　30個



■送信されたメール本文
【定期出荷】100個
　・000001: