わかってないなぁ...
それは、メールアドレスの部分でしょ。
私が言っているのは、シグネチャー。
掲示板に書いたのと同じなんですよ。ダウンロード+UNZIPの一手間要るだけで。
ピザ100枚注文しちゃいますよ(^^)

どの「検索」をやりたいのですか？

今回の、pdfがapplication/pdfではなくなってしまっているメールなんて、別に全部探す必要なんてない、と思っているから、お好きな検索方法で、お好きなようにどうぞ。
Thunderbirdにある「検索」の種類程度は、自分でググって調べるなりしてください。

どうしてもやりたいのならば、
(1) ツールバーのカストマイズ、で、「メニューバー」を常に表示。
Altを教えてもらったから、もう、隠していてもメニューバーに行けるでしょうけど、メニューバーが表示されていないことを「ヘルプがない」としか表現なさらなかった方であることですし、一々、Altを押して、あのメニューを出して、なんて書く気は更々無い。
(2) メニューの、Edit(編集)/Find(検索？)/Search Messages(メッセージの検索)、
あるいは、フォルダーのコンテキストメニューのSearch Messages(メッセージの検索)、で検索
(3) カストマイズ、で「Content-Type」を指定し、「Content-Type:ヘッダー」の中のデータの検索ができるようにする。
(4) 条件
Content-type contains multipart/mixed;
AND body contains text/html;
AND body contains name=
AND body contains Content-Transfer-Encoding:
AND body contains base64
AND body doesn't contain application/pdf
あたりで検索。
multipartの場合でも、Body searchは個々のパートを探すようなことはしなくて、text/plainのメールと同じだったはず。
HTMLのタグの中は探さない、という程度はしていたはずですが。
普通にHTMLが添付されたものも、base64だったり他にbase64の添付があると全部ヒットしますから、pdfがapplication/pdfではなくてtext/htmlになっているメールのソースとの違いを見て、条件を追加するなり変えるなりして、絞込み。
要は、pdfなのにapplication/pdfではなくてtext/html、というメールを探索、なんですが、「pdfなのに」の部分で、日本語のファイル名で、エンコードされてしまっているので、".pdf"という文字列がある、という条件を使えないので、他の条件で逃げる、ということ。

申し訳ありません。「わかってない」で…　ソースで陽にシグネチュアの部分が判ることに気を付けなければいけませんね。圧縮前に除去しておくべきでした。ところで、KIKIさんがお忙しそうです。恐れ入りますが前回質問の検索語句指定方法をご教示いただけませんか？

_________________
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0; Touch)

これは添付の形ではダメなのですか？検索結果がでてきません。
また「AND body contains name=」はどういう意味でどう処理したら良いのですか？
この部分は、まだ理解できていません。

_________________
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0; Touch)

「添付の形」とは、何を意味する？
「添付の形」の「メールのソースの検索」とは、何を意味する？


「AND」は、条件式をANDでつなぐ、の意。
「name=」は「name=」という文字列。「body contains "name="」の方が良かったかな？
でもそう書けば書いたで、ダブルクォートを取らなくって、見つからない、が返ってくる...


スクリーンショットを見ると、ほぼ書いた通りに指定しています。
TbのAdvanced Searchは、全部ANDか、全部ORしか指定できなくて、個々の条件にはANDやORを指定できません。

各パートのヘッダーは、ヘッダーとして扱ったかも。
Content-Disposition、Content-Transfer-Encodingなども「カスタムヘッダー」に登録し、
AND Content-Transfer-Encoding contains base64としてみてください。
でも、各パートのヘッダーはヘッダーとして扱った場合、複数の同じ名前のヘッダーがあると先頭しか探さない、という問題に引っかかるような気が...

いずれにせよ、例示されたとおりに全部書いてみて、ダメだった、ではなく、
最初は一つだけ条件を書いてみて確認し、一つづつ条件を増やしてみるとか、
自分なりに、こういった条件ならば、探したいものがヒットしやすい、だろう、とか、
ちゃんとご自分の脳みそを使ってください。
多分、(a) 自分で作成した、pdfで問題が起こったメール、と、(b) pdfで問題が起こらなかったメール、がまだちゃんとあるでしょうから、
(a) はヒットして、 (b) はヒットしなくて、(c) (a) でも(b)でも無いもの、という、(c)ができるだけヒットしないもので、
(a) なのにヒットしない、ということが、無い、あるいは、非常に少ない、
という条件を、自分で探すだけのこと。

メッセージヘッダーは、各パートのものは検索対象ではなくて、
また、本文は、各パートのヘッダーを除いたもの、になるようです。
ということは、各パートのヘッダーとヘッダーの中のデータを頼りに検索するのは無理。
添付ファイルの有無は、「添付がある・ない」であろうが、Content-Typeがmultipart/mixedを含む、であろうが、大差ない。
PDFファイルの、形式を定めている部分の文字列などでひっかけようにも、base64エンコードされた結果の文字列をテキストとして検索するから、引っ掛けようが無い。

メーラーのメールの検索ではなく、OSのテキストファイルの中の文字列の検索で、
Content-Type: application/pdfの行がちゃんとあるメールを特定して、除外し、
"Content-Type: multipart/mixed;"の行があって、その後ろに"Content-Type: text/html;"の行があるものを探して、メールを特定し、それだけを抜き出し、
Content-Typeのnameの値をデコード、あるいはContent-Transfer-Encodingのfilenameの値をデコードして、拡張子が".pdf"になっている行を特定し、
それに関係するメールを抜き出す、
というようなことが、必要になりそうです。

Content-Type: text/html;ではなくて、"Content-Type: とんでもない文字列;"で送ってきてくれていれば、「とんでもない文字列」がある行の検索だけでメールを特定できたんですけどね。

どうもご教示ありがとうございます。残念ながらどうも良く理解できません。本当は間違えた紐付けを送った不逞の輩を特定したいのですが……　　先にも質問しましたように、何のため紐付け（関連付け）を変えて資料を添付するのですか？いやがらせですか？拡張子を変えて送ってもそうなるのですか？これはＴhunderbird以外のものでも起きうるのでしょうね。

_________________
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0; Touch)

メールの作成における添付ファイルでの「関連付け」は、拡張子 ⇒ Mime-Type、
PDFであっても、.zipに変えて送れば、正常な環境ならば、application/zipでbase64で送られ、
受け取り側がそのまま開こうとすると、ZIPファイルじゃないからUNZIPに失敗しますが、
ファイルに保存して拡張子を.pdfに戻せば、なんの問題も無くPDFとして開けます。


普通は、Thunderbird固有の問題。
知らない拡張子「.???」、知らないMime-Type「application/unknown」で送られてきた時に、
「application/unknown」および「.???」 ⇒ 「それを開くアプリケーション」、を登録しておいて、
次回からは、ダブルクリックでそのアプリケーションで開けるようにする、
というのは、多くのメーラーで行っていると思います。
Thunderbirdにおける問題は、
「application/unknown」および「.???」 ⇒ 「それを開くアプリケーション」、の関連付けだけでなく、
「application/unknown ⇒ .???」と「.??? ⇒ application/unknown」の関連付けもできて、
メールの作成時に「.??? ⇒ application/unknown」を使うようになっていることです。
「.PDF-EXTENDED ⇒ x-new-application/My-PDF」といったような、勝手に使っているようなものならいいのですが、
今回のように、「.???」が「.pdf」といった、すでに実際に広く使われているものに、「application/unknown」が「text/html」という、これまたすでに実際に広く使われているもので、しかも他の拡張子用、
となってしまうと、困ったことになります。
これは、Thunderbird固有の問題になります。


だから、どうしてもそれをしたいなら、メールの検索なり、テキストファイルとしてテキストの検索など、お好きな方法で、自分の頭を使ってどうぞ、と言っているんですけど。
あと、felsendorfさんからのPDFファイル付きのメールを受け取ったThunderbirdユーザーの方にとっては、felsendorfさんが、その「不逞の輩」であることをお忘れなく。


本当に、前に書いたことをまともに読んでくれないお方だ...


これに対する答えはなし？

私のお聞きしたいのは、「添付しようとするFILEの拡張子を変えたりして添付する」ことでここでいう「関連付け」は変わってしまうのですかと言うことです。音楽fILEなどでそういうことをする場合がありうる気がします。なぜThunderbirdはこのような複雑さを残しておくのですか？あるいはどこかにその注意書きがあるのですか？今回いくつかの試行錯誤の上で添付にSnipping toolで示している形で検索を行い、7件がヒットしました。次の添付にその結果をまとめていますが、差出人が私（Felzen)になっているものは、貴方の言う「felsendorfさんが、その「不逞の輩」であること」なのですか？
さらに真の不逞の輩をこれらから見つけるにはどうしたらよいですか？受信日時だけの単純な勝負になりますか？


先に一応文字化けの原因と対応（Tdの関連付け表の該当部削除）ができたのでもういいかとおもってしまいました。確かにちょっと納得のいかない所もありますので、次報で述べます。
その前に質問1：　引用で質問や答えを作って言うとき、うっかりメニューバー部の「ｘ」、「➡」等をいじってしまったり、高機能マウスの横のボタンに触ったりすると、今書いてるものが行方不明になってしまいます。
これを避けるには頻繁に「下書きのセーブ」をやるより手が無いのですか？たまに「下書きをロードする」をクリックしても元に戻らない時があります。
質問2：　この下書きの部分（引用）で行替えをしてもそれが、プレビューや送った文に反映されていません。折角判りやすく書いても、その努力が生かされません。何か方法が間違えているのでしょうか？

_________________
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0; Touch)

時間順に書くと、
(1) ソースd：　日付が5/20 21:05、pdfファイルは、Content-Type:application/pdf
(2) 「文字化けした！」と、このトピックを開いたのが、2014年5月20日(火) 23:56
(3) ソースa：　日付が6/04、pdfファイルが、Content-Type:text/html (ソースb、ソースcも、日付は6/04）

「2014年5月20日(火) 23:56」の時点では、PDFの添付で今回の問題が起こっていたのだから、
間違った関連付けを作ってしまったのは、そのメールを作成を開始した時よりも前の話。
しかし、「日付が5/20 21:05ソースd：」ではContent-Type:は正しいのだから、PDFが添付されたメール全部間違った関連付けで送られてきた、というわけではない。
かなり以前のメールだとすると、PDFはAdobe Readerで開いて見るだろうから、もっと以前に問題に遭遇しているはず。
Thunderbirdに間違った関連付けを登録してしまったのは、あるメールの添付をAdobe Readerで開こうとした時、という確率が一番高いのですから、
そのころにご自分が何をしたのかを、良～く思い出しましょう。


そのメールを実際に送っていて、受け取った人がThunderbirdを使っていて、その人も間違った関連付けをThunderbirdに登録してしまった場合には、当然ですが、そうなります。
で、こんどは、その人が「不逞の輩」に変身。


それはありません。
Thunderbirdは、現時点では、添付の時に、
(i) mimeTypes.rdfに登録されている「拡張子 ⇒ Mime-Type」
(ii) OSに登録されている「拡張子 ⇒ Mime-Type」
(iii) Thunderbirdが、ブラウザー・メーラーとして必須であるので、内部的に保持している類のもの(text/plain⇒.txtとか、image/jpeg⇒.jpgなどは、必ずしもOSの登録を見に行かないはず。

で、ファイルを添付する時に、(ii)よりも(i)を優先すると、誰かから来た添付の表示の便宜のためのはずである(i)に間違った関連付けが登録されてしまうと、今回の問題が起こるから、
(i) よりも(ii) を優先するようにコードを書き直すべし、というリクエストが、既に出ている、ということ。


複雑でも何でもないのですよ。
ちょっと長くなりますが、歴史的なことを...

元来、「拡張子 ⇔ Mime-Type」の関係なんて、インターネットやEMailの世界では、存在していなくて、
Macが、ファイルのメタデータでファイルの種類や関連アプリケーションを制御しているのと同様に、全て「Mime-Type」で行う、ことになっている。
でも、Linuxでは、ファイルのメタデータをもてないので、ファイル名の最後のドットとその後ろを「拡張子」と呼んで、ファイルのメタデータとして代用していたし、今もそうなっている。
Winでは、今でこそ、ファイル名の最後のドットとその後ろ、になっていますが、MS DOSの8.3形式では、8の部分が名で3の部分は別途保持された拡張子、ってなことを、DR DOSからパクったんでしょうけど、ファイルシステムでやってしまった。
で、そういったPCのOSの世界では、「拡張子」でどのアプリケーションのファイルかを識別していたし今でもそうなので、「拡張子」からMime-Typeを決める、と言う風にしていたし、今もしている。

でも、先に言ったように、「拡張子 ⇔ Mime-Type」の関係なんて、インターネットやEMailの世界では存在していなくて、
一般的に使われている規則を使っている外部の人との交信ではなくて、
イントラネットでの内部だけでの交信ならば、「拡張子 ⇔ Mime-Type」の関係なんて、任意に定義できるわけで、
そういったことのために、Mozillaでは、ブラウザー・メーラーに登録する「拡張子 ⇔ Mime-Type」の関係は、任意に定義できるようになっていました。
受け取ったメールに、知らない拡張子・知らないMime-Typeがあった時には、必要ならば、その関係を自分で好きなように登録すればいい、ということです。
「好きなように登録」なんだから、非常にシンプル。

それが、Firefoxでの変更(Mozillaを知っている人間にとっては改悪)で、
「今後このアプリケーションで開く」を指定した時に勝手に登録、になり、登録内容の詳細もちゃんとは見せないようにしてしまい、関連付けの「削除」も行きがけの駄賃とついでになくしてしまい、
その後、よせばいいのに、Thunderbirdでもその「改悪」を採用してしまい、
Thunderbirdで、今回のような、頻度は少ないとは言え、とんでもない問題が表面化した後に、
長い時間をかけて、mimeTypes.rdfを消す以外の対処方法がないなんてあまりにお粗末だ、と説得したら、
なんと、「このエントリーが行うアクション」の中に「このエントリーの削除」を入れてきた、というだけ(^^;


何度言っても、トピックとは関係ないことを、たまたまそのトピックに関連した作業で発生しただけなのに、何度も書いてくる...
誰かに電話で聞くときは、用件ごとに電話をかけ直すと、かけられた方もたまったもんじゃないですが、
こういった、テーマや用件ごとにトピックやスレッドが分かれている場所においては、
トピックの主題とは無関係の質問を繰り返すことは、ご法度。

本来別の板（MozillaZine.jp について）で質問すべきことですが、解決しないと先に進めなそうな感じなので、私から回答しておきます。この回答で不十分なら別トピック立ててください。

メニューバーが何を指しているのかはっきりしませんが、マウスの横のボタンというのはブラウザのナビゲーションツールバーの「戻る」「進む」が割り振られてるのだろうと思います。実際にやってみましたが、前のページに戻っても次のページに進むでフォームに入力した内容は残っています。
また掲示板の編集画面の「Remove Text（×）」で文字を消しても、「Undo(左矢印)」で元に戻りますし、「Undo(左矢印)」と「Redo(右矢印)」で相互に取り消しが可能です。編集中に文章が消えてしまったことはありませんが、私なら長文を書くなら下書きのセーブ機能は使わずにメモ帳でも起動しておいてそちらにコピペしておきますね。メモ帳から編集画面にコピペし直すことで書式が落ちる（ただのテキストエディタですから）副産物もあります。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0

EarlgreyTeaさんがここで回答したので、私も。

これ、私も何度か、いや、何度も、経験しています(^^;
内部的に、JavaScriptで行っている部分が何かを待っている時に「Ｘ」ボタンをクリックしたので、JavaScriptによる処理が完了しなくて、入力したデータが保持されない、ということでしょう。
でも、「プレビュー」を押したけれど応答がないので仕方なく「Ｘ」でやり直そうとした時、ですから、困りますよね。

BBCode View ⇔ HTML Viewを何度か切り替えて(最後から二つ目のボタン)、最後にBBCode Viewにしてからだと、とりあえずは入力データの喪失はなさそうですから、JavaScriptの処理が完了していない時点で中止したため、ということだと思います。
応答が返ってこない時でも、「X」ボタンを押す前にCtrl+A/Ctrl+Cでクリップボードにコピー、は効きますから、これで逃げるといいでしょう。
長い時間かけて書くとか長くなる場合は、BBCode View(HTMLのタグと同様にBBCodeを文字列として書く)のソースをテキストエディターに貼り付けて、そちらで編集してからペースト、というような知恵を働かせるといいと思います。

　

申し訳ありませんが、検索機能の使い方や、そのテクニック、工夫といった内容・話題になります
ので、別途新規に、質問投稿トピックを設けてください。

理由は、
・添付ファイルのデータ文字列が、メッセージ本文内に表示されて、文字化けのように
　見えた原因が判明した。
　（不正な MIME TYPE が原因だった）
・その原因に対する対処によって、問題は再現しなくなった。
　（不正な MIME TYPE の削除）
により、当初の問題点は、解決したと思うからです。

確かに、不正な関連付け（MIME TYPE）で、ファイル添付したメッセージがトリガになった可能
性は高いのですが、「該当メッセージの差出人を探し出す」が、当初の問題点ではないと考えるか
らです。

疑問が生じたら、その都度質問を繰り返すことで、話題の主題がどんどん逸れていくのは、よろし
くないと感じます。
話題を、どんどん派生させて、分散を繰り返していることを、いいかげん自覚してください。



送信者が、OS をどうしてるのかまでは、わかりません。
ご自分で、送信者に、お尋ねください。
また、Thunderbird とは、関係ありません。



わかりません。
以下、同上です。



同上です。



WADA さんの説明にあったとおりです。

誤った関連付けを Thunderbird に記憶させて、それでファイルを添付してメッセージを送信すれば、
そのメッセージを受け取った方が、そういうとらえ方をする可能性があります。

今回は、不正な関連付けは、削除されたので、とりあえず回避できるでしょう。
今後も、お勧めに書いたように、その場で添付ファイルを開くのではなく、一旦ローカルに保存する
手段を取れば、回避できるでしょう。

このように、問題点から学んだことや、知って理解できたことを、活かしていけば、失敗を繰り返す
こともないでしょう。

_________________
Mozilla/5.0 (Windows NT 6.1; rv:33.0) Gecko/20100101 Firefox/33.0

EarlgreyTeaさん。ありがとうございます。本来別のトピック立てしなければならないところ、申し訳ありません。
実はWADAさんに再質問を書いているとき、何と4度も同じ間違い（原因はそれぞれ違いますが）をして、4度も該当書類を行方不明に、それも完成まじかでしてしまい、ついカッとなり、短慮に別質問を書いてしまいました。
私も普通はEarlgreyTeaさんがいわれるように、別にメモに記憶させるようにはしています。よくあることですが、あせっているとき間違いを繰り返してしまいます。
もう少し勉強させていただきます。ありがとうございました。

_________________
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0; Touch)

再度整理します。➊PDF文書Aを添付。➡本文で文字化け➡送付文書も文字化け、添付文書は問題なし⇒ソースa……6/04
➋PDF文書Bを添付。➡本文で文字化け➡送付文書も文字化け、添付文書は問題なし⇒ソースb……6/04
➌PPTX文書を添付。➡本文で文字化けせず➡送付文書も文字化けせず、添付文書は問題なし⇒ソースc……6/04
➍PDF文書Aを添付。➡本文で文字化けせず➡送付文書も文字化けせず、添付文書は問題なし⇒ソースd……5/20　　　実際に文字化けが起こったのは5/13　10：44送信分、同日11：05送信分も同じ。共に同じPdf文書を添付。でも➊➋➍の文書A,Bとはちがうものです。
したがって
1.PDF文書でも文字化けするものとしないものがある。
2.同じPDF文書でも文字化けしない場合とする場合がある。
３．今回検索でヒットしたものでは4/20　10：51の私発の文書が怪しくなるが、添付文書はJPEGである。
4.この元文書のJPEGは非常に容量が大きく、メーラーでブロックされていた「曰くつき」のものである。
5.これ以前では、今回のような文字化けはおこっていない。
のようなことが言えますが、「不逞の輩」を特定するには至りませんでした。

明日もう一度考えてみます。

_________________
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0; Touch)