はじめまして、新参者ですが、宜しくお願いします。

個別アプリケーションソフトよりメール送信処理があり、
そのアプリより受信したメール（添付ファイル無し）を転送しようと
すると件名のような現象が発生します。
（但し、転送メールに本文が無い場合のみです、一文字でもある場合は
　この現象は起きません）

転送画面で「添付メッセージ部」をダブルクリックすると
”空のファイル”メッセージが表示され、そのまま送信すると送信先には
「添付メッセージ部」が添付された状態で送信されます。

更新される前の　8.X.Xでは起こらない現象でした。

この現象は、個別アプリから送信されたメールだけで発生していますので
9.0.1に対応するには、個別アプリ側の修正が必要なのか？
それとも9.0.1でこの現象を回避する設定方法があるのか？

どなたか御教授願います。

宜しくお願いします。

情報不足、説明不足（言葉足らず）ですみませんでした。
改めて投稿しますので宜しくお願いします。


使用しているThunderbird：
　　　　Thunderbird 9.0.1

使用している拡張機能・テーマ：
　　　　Test Pilot for Thunderbird 1.3.4
　　　　Default 9.0.1

使用しているOS,環境：
　　　　Windows XP Professional Service Pack 3
　　　　メモリ2GB, HDD空き50GB以上

使用しているセキュリティツール（ウィルスチェッカ、ファイアウォールなど）：
　　　　ウィルスバスター Corp.クラインアント 10.0
　　　　Windowsファイアウォール

---- 質問内容 ----
起きている現象：
　　　　個別アプリでメール送受信処理があり、そのアプリより次の条件
　　　　　・本文が一文字も無い
　　　　　・添付ファイル無し
　　　　状態のメール受信後の作業を順番に記述します。
　　　　
　　　　①転送ボタン押下（受信一覧より右クリックで[転送]選択も同）
　　　　②転送メール作成画面　右上の添付ファイル欄に「添付メッセージ部」という
　　　　　名前で空ファイルが作成される。
　　　　　（メール内容は次の状態：

　　　　　　　------ Original Message -------
　　　　　　　Subject: ＮＮＮＮＮＮＮＮＮ
　　　　　　　Date: Mon, 99 XXX 9999 99:99:99 +9999
　　　　　　　From: ＮＮＮＮＮＮＮＮＮＮＮＮ <XXXXX@XXXXXX.jp>
　　　　　　　Reply-To: ＮＮＮＮＮＮＮＮＮＮ <XXXXX@XXXXXX.jp>
　　　　　　　To: ＮＮＮＮＮ <XXXXX@XXXXXX.jp>
　　　　　　　→　これ以降空白（本文無し）
　　　　
　　　　　の内容で表示されています）
　　　　③この状態で転送先を設定し送信。
　　　　④転送先には「添付メッセージ部」名で空テキストァイルが添付されている。

　　　　この現象は、本文が無い場合のみ発生し、一文字でも本文があれば発生しません。

　　　　
現象が起きる前にやったこと：
　　　　2012/01/20に「8.0」より「9.0.1」へバージョンアップ。

　　　　
この現象は個別アプリから受信した上記条件時のみ発生し、
Thunderbird（社内標準メールソフト）から受信した同じ条件では起きません。
また、「8.0」以前で個別アプリから受信した同じ条件でも起きていませんでした。

そこで教えて頂きたい内容は、
　・「9.0.1」にする事によって、個別アプリ側での対応も必要なのでしょうか？
　　（この個別アプリは８年稼動していて、上記現象は今回初めてです）
　・「9.0.1」側で上記現象を回避する為の設定方法等があるのでしょうか？

どなたかご存知の方がいましたら、御教授願います。
　　　　
宜しくお願いします。

　
まず bunsho-kami さんの云われる「個別アプリケーションソフト」から送信されたメッセージが
読んでいる皆さんは手元にないので再現できず、確認のしようがありません。

次に、その「個別アプリケーションソフト」が何であるか、他の受信メッセージと比較してどのよ
うなメッセージなのか、その相違点あるいは全体をメッセージソースを貼り付けるなどして提示し
ていただかないと、さらに不明です。

よって、一般的な内容になりますが単なる転送ではそのような現象は起こらないとしか云いようが
ありません。



・転送メッセージ作成ウィンドウに最初から添付ファイル欄に「添付メッセージ部」というファイルが
　添付された状態になるのですか？
・添付ファイル欄は、通常は転送メッセージ作成ウィンドウでは表れません。
　添付ファイル付きの受信メッセージを転送しようとすると添付ファイル欄が表れます。
　該当の受信メッセージは実は添付ファイルが元からあるのではありませんか？
・添付ファイル欄をダブルクリックするのはなぜでしょうか？
　ダブルクリックしてもシングルクリックしても、添付ファイル欄には何もファイルは添付されません。



その該当の受信メッセージがどんなものか不明なので、起きる挙動も不明です。
よって回避する設定や方法があるのかも不明です。
また Thunderbird 8.0 系では有効に機能していたアドオンなどが 9.0.1 では無効化されているとか
正常に機能していないこともあるかも知れません。

以下のトラブルシューティングを参照して問題を切り分けてみてください。
　＃Thunderbird のセーフモード起動、新規プロファイルの追加適用や再インストールです。
上記の結果でも再現するようならば、Thunderbird 以外に問題がある可能性が高いと思われます。

Mozilla Thunderbird 9.0.1 リリースノート - トラブルシューティング
セーフモード | 操作方法 | Thunderbird ヘルプ
複数のプロファイルを使用する | 操作方法 | Thunderbird ヘルプ
プロファイル | 操作方法 | Thunderbird ヘルプ

[セーフモード起動の補足]
Thunderbird 5.0 以降では、セーフモードの実行方法が変更・追加されています。
（A）起動中の Thunderbird からセーフモードで再起動する場合
　　　メニューの [ヘルプ] -> [アドオンを無効にして再起動] を実行してください。
（B）終了している Thunderbird をセーフモードで起動する場合
　　　[Shift] キーを押したまま、通常の手順でスタートメニューやデスクトップの
　　　アイコンから起動してください。
（C）従来どおりの -safe-mode の起動オプションも有効です。

いずれの場合も、[Thunderbird セーフモード] というダイアログが表示されます。
どの項目もチェックをつけないで [セーフモードを続ける] ボタンを押してください。
　

kikiさん、ご指摘有難うございます。

現象が再現しない皆さんには、情報不足でした。（貴重な時間を・・・、申し訳ありません）

これまでもThunderbirdのバージョンアップは何度かやっていますが、
アップ後に何か設定を変更した事がなかった事と、
アプリ側の変更は当然ありませんでしたから・・・、このフォーラムに投稿すれば、
解決するのでは？　と安易な気持ちでした。

ご指摘のトラブルシューティング等を参照して問題を切り分けてみます。

結果は報告致しますが、もし同じ現象が出るようなら検討して頂けるような情報を
記載するようにします。
有難うございました。

　
それで該当のメッセージを送ってくるアプリケーションとは一体何なんですか？
そのメッセージの中身（メッセージソース全体）はどのようなものですか？


【補足】　

Thunderbird 側の設定を変更していなくても、バージョンアップすれば当然仕様変更もあるのですから
以前とまったく同じということにはなりません。


誤解があるかも知れないので付け加えておきます。
ここは Thunderbird の開発者が要望や不具合の改善を受け付ける場ではありません。
また、それらを開発者に届ける場でもありません。
　
ここはユーザ同士でサポートし、アドバイスや情報を交換し合う場です。
ですから、bunsho-kami のところで起きている内容を、読んでいる皆さんにもわかるように、できる限り具
体的な情報として開示するよう心がけてください。
　

返答が遅くなりました・・・、ご指摘して頂いた

セーフモードでの操作、他トラブルシューティング参照でも解消できていません。


そうです、添付ファイルが無いのに添付ファイル欄に「添付メッセージ部」名でファイルが表示される状態です。
画面右上の添付ファイル欄外上に"添付ファイル1個(C) 4バイト"、欄内に"[TMP拡張子画像]添付メッセージ部 4バイト"と表示されています。
そのファイルを[開く]で参照（秀丸で）すると、中身は空で、保存しようとすると
"nsmail-10.tmp - は空のファイルです。削除しますか？"と表示され、保存が出来無い状態です。

添付ファイルが無い場合は、添付ファイル欄が表示されないのは承知しています。
今回の投稿は、本文無し、添付ファイル無しのメールを受信し、その受信したメールを転送処理すると
『添付ファイルもないのに何故、添付ファイル欄が表示されるのか？』との思いで、投稿しています。
（本文が一文字、又は　添付ファイルが有れば、現象は出ません）

添付ファイル欄をクリックしたのは、添付ファイルもないのにファイルが表示されていたので、
『何だろう？』との思いからです。（添付ファイルがある場合は内容確認の為に普通にやっています）
ExcelやWord等であれば、ダブルクリックで開きますが、今回は拡張子がTMPなので[開く]で確認しました。

「9.0.1」以外で確認したくて、旧バージョンを探したのですが・・・、「3.1.1.7」以外は、最新の「9.0.1」を
ダウンロードするようになっているので、「3.1.1.7」をセットアップして確認してみましたが・・・、現象の
出ているファイルを同じように転送処理をしても、こちらは添付ファイル欄は表示されず正常でした。
（「2.0.0.24」も正常です、この３バージョンは、\Program Filesn内にフォルダを分けてセットアップしています）

現象を把握して頂く為に、画面ハードコピーを貼り付け出来れば一目瞭然なのですが、
アップロード出来るサーバー環境がありません・・・、見てもう為の手段等はないでしょうか？
（よくある質問に「フォーラムにアップロードする機能はない」とはありますが・・・）

kikiさん 稿時間: 2012年1月25日(水) 19:54 について

Windows 2003 Server Standard Edition R2 をメールサーバーとし個別アプリで作成した送受信情報を
「MDaemon PRO v10.0.0」を介して該当アドレスへ送受信する仕組みです。
専用線を使用していて社外へのアクセスは制限されており、このフォーラムへの参加も制限対象となっています。
（閲覧は可能ですが、[検索機能]や[新しいトピック]参加は不可なので、素早い回答が出来無い状況です）

（メッセージソース全体）とは・・・、Thunderbirdの[表示]-[メッセージのソース(O)]で開いた情報の事ですか？
このソースで気付いた事があるのですが、本文や添付ファイル等があると　Subject以降は

|
Subject: XXXXXXXXXXXX
MIME-Version: 1.0
X-Mail-Agent: BASP21 Pro 1,0,301,25 B21Soft
Content-Type: text/plain

等の情報ですが、本文、添付ファイルが無い場合（今回の投稿現象）、

|
Subject: XXXXXXXXXXXX

で終わり、これはこれで、本文も添付ファイルも無いので正常だと思います・・・が、Subject以降に
改行マークが３行あります（本文がある場合は、本文以降に３行の改行）。
Thunderbirdのソースを解析しないと分からないですが、「9.0.1」では、この３行の改行を何かの情報と
受取って添付ファイルが作成されているのかな？っと・・・。（「3.1.1.7」でもソース内容は一緒なので）
個別アプリ側で３行改行をなくすような修正をして検証出来ればよいのですが、開発元が違うので
簡単に出来無い状態です。
（この現象は発生頻度はかなり低いですので、個別アプリ対応も現在検討しています。）

はい、使用するアプリがバージョンアップするれば、個別アプリ側の対応要となる可能性がある事も承知しています。
今回の投稿は「9.0.1」にアップした直後だったので、Thunderbird側で「何かあるのか？」との思いからです。

誤解しているつもりはなかったのですが・・・、今回の投稿でフォーラムの質問⇔回答等にあるような
「[ツール]-[アカウント設定]のどこどこ・」、「[ツール]-[オプション]のどこどこ・」、「XXアドオンを設定すれば・」 etc
の情報が取得出来ればいいなっとの思いでした。

今回の投稿も皆さんへの情報提供としては、「いいかも」と思っていましたが・・・、投稿する際の情報は不足でした。
指摘内容は、心がけるようにします。
それで、上記に記述した内容に戻りますが、現象画面を見てもらうような手段はないでしょうか？
（そぐわない質問と承知していますが・・・、どうしても見てもらいたい、見せたいという思いが強くなっています）

　

了解しました。


了解しました。

メッセージソース全体とは、Thunderbird の [表示] > [メッセージのソース(O)] で開いた内容です。
それをここにコピーして貼り付けるだけですが・・・・。
　＃もちろん不都合な部分はマスク処理（他の文字に置き換える）してください。

細かいことですが、添付ファイル欄をクリックするのと、その中にある添付ファイルをクリックする
のとでは操作が異なります。

画像の貼り付けはリンクを必要としますが、以下の方法で可能です。
MozillaZine.jp :: BBCode ガイド - 投稿文中に画像を表示する
　

上記で記述している「3.1.1.7」は、「3.1.17」の誤りでした。

それぞれ99999～、ｘｘｘｘｘｘｘ～にマスクしています。（欲しい情報をマスクしていたら・・・、すみません）
－－－ここから
From - Mon Jan 23 13:49:24 2012
X-Account-Key: account1
X-UIDL: UID99999-9999999999
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-Path: <xxxxxxxx@xxxxxxxxxxxxxxx.jp>
X-Original-To: xxxxxxxx@xxxxxxxxxxxxxxx.jp
Delivered-To: xxxxxxxx@xxxxxxxxxxxxxxx.jp
Received: from shijer.xxxxxxxxxxxxxxxxxxxxx.jp (shijer.xxxxxxxxxxxxxxxxxxxxx.jp [999.999.9.99])
by yXXXXu.xxxxxxxxxxxxxxxxxxxxx.jp (Postfix) with ESMTP id 9999999999
for <xxxxxxxx@xxxxxxxxxxxxxxx.jp>; Mon, 23 Jan 2012 13:48:57 +0900 (JST)
Received: from shijer.xxxxxxxxxxxxxxxxxxxxx.jp (localhost [999.9.9.9])
by xxxxxxxxx.xxxxx.xxxx.xxxxxxx.jp (Postfix) with ESMTP id 9999999999
for <xxxxxxxx@xxxxxxxxxxxxxxx.jp>; Mon, 23 Jan 2012 13:48:57 +0900 (JST)
Received: from xxxxxx.xxxx.xxxxxxx.xx.jp (xxxxxxx-xxxx.xxxxx.xxxx.xxxxxxx.jp [999.999.9.999])
by shijer.xxxxxxxxxxxxxxxxxxxxx.jp (Postfix) with ESMTP id 9999999999
for <xxxxxxxx@xxxxxxxxxxxxxxx.jp>; Mon, 23 Jan 2012 13:48:57 +0900 (JST)
Received: from xxxxxxx-xxx.xxxxx.xxxx.xxxxxxx.jp ([999.999.9.999])
by xxxxxx.xxxx.xxxxxxx.xx.jp (xxxxxx.xxxx.xxxxxxx.xx.jp)
(MDaemon PRO v10.0.0)
with ESMTP id xx9999999999.msg
for <xxxxxxxx@xxxxxxxxxxxxxxx.jp>; Mon, 23 Jan 2012 13:48:54 +0900
X-Spam-Processed: xxxxxx.xxxx.xxxxxxx.xx.jp, Mon, 23 Jan 2012 13:48:54 +0900
(not processed: spam filter heuristic analysis disabled)
X-MDRemoteIP: 999.999.9.999
X-Return-Path: xxxxxxxx@xxxxxxxxxxxxxxx.jp
X-Envelope-From: xxxxxxxx@xxxxxxxxxxxxxxx.jp
X-MDaemon-Deliver-To: xxxxxxxx@xxxxxxxxxxxxxxx.jp
To: =?ISO-2022-XXXXXXyXXXXXXXTXXXX0XXXXXQXX=?=<xxxxxxxx@xxxxxxxxxxxxxxx.jp>
Message-Id: <99999999999999.9999999999.9999999999.999999999.xxxxxxxx@xxxxxxxxxxxxxxx.jp>
Reply-To:=?ISO-2022-JPXXXXXRCXXXXXXXXXX0XXXXXQXXXXXIxP0XXXXXXXXXGXXXXX==?=
=?ISO-2022-JXXXXXXXXXX9XXXXXTXXXXXXXXXX=?=<xxxxxxxx@xxxxxxxxxxxxxxx.jp>
Date: Mon, 23 Jan 2012 13:48:50 +0900
From: =?ISO-2022-JPXXXXXRCXXXXXXXXXX0XXXXXQXXXXXIxP0XXXXXXXXXGXXXXX==?=
=?ISO-2022-JXXXXXXXXXX9XXXXXTXXXXXXXXXX=?=<xxxxxxxx@xxxxxxxxxxxxxxx.jp>
Subject: XXXXXXXXXX



[EOF]
－－－ここまで

同じ現象の受信メールを転送処理すると、４行目の「X-Mozilla-Status: 0001」は、"1001"になりました。
コピーしましたが、私には？です・・・が、気になるのは、最後Subject以降の３行の改行行です。


実施可能かも含めて検討します。

　
bunsho-kami さんが貼り付けたメッセージソースをコピーして、擬似的に同様のメッセージ
を作成してテストしてみました。

（１）Subject: 行以下に [改行] のみがある場合
　　　添付ファイル欄に「添付メッセージ部 6 バイト」が出現しました。
　　　　＃[改行] が 1 つで 2 バイトとして表記されます。
　　　　＃[改行] が 3 つで 6 バイトとして表記されます。
　　　------------------------------------------　
　　　|Subject: =?ISO-2022-JP?B?XXXXXXXX==?=
　　　|[改行]
　　　|[改行]
　　　|[改行]
　　　------------------------------------------

（２）Subject: 行以下に本文用のヘッダを追記して [改行] がある場合
　　　[改行] があっても添付ファイル欄に「添付メッセージ部 6バイト」は出現しません。
　　　------------------------------------------
　　　|Subject: =?ISO-2022-JP?B?XXXXXXXX==?=
　　　|MIME-Version: 1.0
　　　|X-Mail-Agent: BASP21 Pro 1,0,301,25 B21Soft
　　　|Content-Type: text/plain; charset=ISO-2022-JP
　　　|Content-Transfer-Encoding: 7bit
　　　|[改行]
　　　|[改行]
　　　|[改行]
　　　------------------------------------------
　
以上の結果から、
１．本文用ヘッダがない場合は、[改行] が転送時に誤認識？されて添付ファイル欄に「添付メ
　　ッセージ部 X バイト」としてあらわれる。
２．本文の有無や [改行] に関わらず、本文用のヘッダを付加すれば問題ない。
ということがわかりました。

対処としては、どんなメッセージであろうと送信側のメッセージ生成アプリケーション側でお
行儀よく本文用ヘッダを付加するようにすれば解決（問題回避）できるかと思われます。
尚、Thunderbird は本文のないメッセージでも本文用ヘッダを律儀に付加します。


【補足】
なぜこのようになるのかは、バグ検索もしていませんので不明です。
次期バージョンの開発版 10.0 beta 5 でも同じく開発版の 11.0a2 (20120126) でも同様な
のでおそらく仕様ではないかと推測します。
　

横から失礼します。

ご提示のあったメッセージ・ソースですが、次の 2 点が気になりました。

（1）Content-Type と Content-Transfer-Encoding のヘッダが存在しない。
（2）Subject: XXXXXXXXXX のあと、ボディ部に相当する箇所に改行コードのみの行がある。
　　（「気になるのは、最後Subject以降の３行の改行行です」とのご指摘どおりです。）

一般的にいえば、"本文（ボディ）がない" メッセージは特異なものですし、本文がないといっても一つの改行コードだけが存在したりするケースが多いわけですが、その場合でも Content-Type と Content-Transfer-Encoding のヘッダは存在するのが普通です。

試しに、Thunderbird 9.0.1 で作成した本文なしのメッセージには、Content-Type と Content-Transfer-Encoding のヘッダが存在しますが、このヘッダを手動で削除したメッセージに対して [転送] 処理をおこなうと、ご質問のようにメッセージ作成ウィンドウの添付ファイル欄に「添付メッセージ部」という実体のない添付ファイルが現れます。
Content-Type と Content-Transfer-Encoding のヘッダが付いていると、本文がなくても「添付メッセージ部」は現れません。
同条件のメッセージを、Thunderbird 8.0 で [転送] 処理すると、Content-Type と Content-Transfer-Encoding が存在する場合はもちろん、このヘッダがない場合でも「添付メッセージ部」は現れません（後述）。

RFC 的には、Content-Type と Content-Transfer-Encoding は「必須」ではないらしいですが、ASCII オンリーで済む言語圏ではないなら事実上「つけるべき」ヘッダだと考えられています。
そういう点からいえば、改行コードだけとはいえボディ部にデータが含まれるのに Content-Type と Content-Transfer-Encoding がないメッセージを送ってくる側に第一原因があると思われます。

同時に、これを受信した Thunderbird の動作が、8.0 と 9.0.1 で異なるというのは、Thunderbird 側にも何かしらの内部的な違いがあると考えるのが妥当だと思われます。
（a）Thunderbird 8.0 の不備・不具合を修正した結果、9.0.1 の動作が変わった。＝9.0 の動作が正しい。
（b）Thunderbird 9.0.1 で追加・修正された要素の中にバグが混入されてしまった。＝8.0 の動作が正しい。
―― 大別してこのどちらかだと思われますが、詳細はぼくにもわかりません。

「添付メッセージ部」という名前が付くのは、元のメッセージに含まれるコンテンツに適切なヘッダが付いていないような場合、Thunderbird の判断で便宜的に付けられる名前のようです。
無理やりな例ですが、分割メッセージの 1 パートに対し、元メッセージを本文に含める形式で [転送] 処理をおこなう場合を想定します。
message/partial で規定された分割メッセージには通常の添付ファイルのようなヘッダはありませんが、明らかにデータは存在するため、転送の際そのデータに対して仮に付与される名前といった感じでしょうか。

ご質問の事例では、複数の改行コードに対してこの処理がおこなわれているような印象です。
つまり、適切なヘッダが存在しないため、複数の改行を本文ではなく孤立したデータとして認識しているような節が見受けられます。不可解な挙動だとは感じますが、ご例示のような元々不規則なメッセージに対する [転送] 処理は、本当はどうなるのが正しい動作か、ぼくには判断できません。

で、さしあたっての対策として思いつくのは次のようなことです。

（i）送信側の設定で Content-Type と Content-Transfer-Encoding を付与できるなら、そのように変更する。
（ii）Thunderbird 側の転送方式を [ファイルとして添付] にする。
　　　（[オプション] -> [編集] -> [一般] を参照。）
　　　元のメッセージ全体を eml ファイルとして添付するようになります。
　　　実体のない「添付メッセージ部」とは異なり、これは実体のあるファイルです。
（iii）当該メッセージに手動で Content-Type と Content-Transfer-Encoding を書き加えてから [転送] する。

とりあえず以上です。間違ったことを書いてたらすみません。
ここまで対応なさった kiki さんや、詳しい知識のある他のユーザーさんからも、フォローいただけるとありがたいです。

kikiさん、偶然的通行人さん、テストまでして頂き有難うございます。（最初から、ソースをコピペせぇよって事ですね ）

お二人のアドバイスのベストは、同じで


アプリ側の修正工数等は微々たるものだと思いますが、開発元が違う為に簡単にはいかず、ソースも手元には無い状態です。
後はこちらの問題なので発生頻度（かなり低いはずです）、費用対効果等を検討して対処していきます。

偶然的通行人さんがアドバイスしてくれた対策で

以前、転送方式が統一されていない時に、[ファイルとして添付]にしていると、今回のように
『添付ファイルが無いのに添付ファイル欄が表示されるけど・・・、何？』みたいな事がありましたので、現在は、[メール本文に含める]で統一しています。


１日に1000件～2000件の送受信があるので、手動ではとても対応出来ませんので・・・。

でも、丁寧なアドバイス、ほんとに有難うございます。
私が、最初からメッセージソースをコピペして、ちゃんとした説明していればもっと早く解決できたのしょうが・・・、（貴重な時間を取らさずに済んだと思います・・・）冒頭に記述していますが、『新参者』ですので、そのへんはご勘弁を。
次回からは、kikiさんからの指摘内容を心がけるようにします（今回で分かりましたが、因みに、画像アップロードは、環境が無いのでfacebookにアップロードてやろうかと考えていました）

今回、投稿してよかったと思います 、皆さんへの情報としても「いいかも」だったと思います（？）。

有難うございました。

オフトピで失礼します。

＞　bunsho-kami さん
解決というか問題点の整理ができてよかったですね。

んで、ほんの 4 分差で直前の kiki さんの投稿とほとんど同じ内容の投稿をしてしまいました（汗）。
投稿前に確認すればよかったのですが、無駄にかぶってしまい失礼いたしました（謝）。