まだ、「文字化け」云々と、ある種「ナンセンスだ」と言っておいたものとか、同じPDFファイルだの別のPDFファイルだとか、無関係のＰＰＴやJPEGがでてくる...

問題の本質は、
(1-a) Content-Type: application/pdfでないといけないのに、 Content-Type: text/htmlで、拡張子＝.pdfのファイルが添付されたメールが送られてきた。
(1-b) あるいは、Webサイトに Content-Type: text/htmlでPDFファイルがあって、それを添付してメールを作成したので、拡張子＝.pdfのファイルなのにContent-Type: text/htmlで添付されたメールを作成した。
(2) (1)のメールに添付された.pdfファイルを見た時に、その間違った関連付け(.pdf ⇒ text/html)を、Thunderbirdに覚えこませてしまった。
(3) そのために、PDFファイルを添付すると、PDFなのに、Content-Type: text/plainで送られるようになってしまった。
(4) Thunderbirdの、間違った関連付け(.pdf ⇒ text/html)を消したら、元通り、PDFは、Content-Type: application/pdfで送られるようになった。
であり、
PDFは、本来インライン表示できないのに、text/htmlになっているので、表示/添付をインライン表示、にしていると、PDFファイルの中身をHTMLとして表示しようとするから、滅茶苦茶な表示になって当然。
それを「文字化け」というのは、ナンセンス。
「滅茶苦茶な表示になる」ことは、問題が起こっていることの、かなり確度の高い傍証であることは確かですが、
常に、メールのソースで確認し、「PDFファイルの添付なのに、Content-Type: application/pdfではなくContent-Type: text/htmlになっているメール」、ということを検証していかないとダメです。

[追記]
問題の本質を考えようともせず、「文字化け」といった曖昧なことを根拠にするから、以下のようなことを書き出すのです。
> (A) 実際に文字化けが起こったのは5/13　10：44送信分、同日11：05送信分も同じ
> (B) PDF文書Aを添付。➡本文で文字化けせず➡送付文書も文字化けせず、添付文書は問題なし⇒ソースd……5/20
問題の原因から考えると、問題が起こり始めたのは、5/13 10：44以前であり、間違った関連付けを消すまでは、拡張子=.pdfのファイルを添付すれば、必ず、Content-Type: text/htmlで送られてしかるべきです。

「文字化けの有無」は、U+FFFD(�)が表示されていたか・いないか、ではありませんか？
PDFファイルの中身は、asciやShift_JIS版もあれば、バイナリーデータ版もあります。
そして、PDFファイルの中身をHTMLとして表示すれば、何が表示されてもおかしくはありません。
以前、ちゃんと『ナンセンスだ」と書きましたよね。
以前書いたことは、ちゃんと読んでください。
[追記おわり]

仰ることは判りますが、私のような「Thunderbirdの単なる利用者」にとって、『滅茶苦茶な表示になって当然。それを「文字化け」というのは、ナンセンス』と言うことを言われても困ります。私の感覚では「無茶苦茶な表示≧（または≒）文字化けでありこのような表現を使ってしまいます。それはともかく、今度真の「不逞の輩」らしきものが見つかりました。「検索条件（１）添付を持つ。AND検索条件（2）本文に.Pdfをふくむ」でけんさくすると何故か次の2件しかヒットしません。　➀2014/04/10 16:23 書類C（インラインで「文字化け」）　添付書類は正常に開く　…添付sunipping1に添付書類スペックを示す。　②2014/03/20　0：21　書類D（正常）　添付書類も正常…添付sunipping2に添付書類スペックを示す。　この中で➀が怪しいと思ったのは、1.インラインで文字化けしている、2.添付書類スペックで、「プログラムで開く　Internet Explore(規定）となっていること、3.私のパソコンの状況から言って、時期的にもっとも怪しいこと、4.この書類Cを複数の場所に配っていますがすべてインライン文字化けをおこしていること、等です。
ただ、判らないのはa.この書類を複数配布しているが、特に苦情が」きていないこと、b.このメールの保存は受信トレイにあると検索ではいってますが、受信トレイをいくらしらべても見つからないこと、c.この書類は学会から複数の人に依頼文書として送られているものなので、被害者が私だけというのは信じられないことなどです。

もっとも②でも上記b.はおこっていますのでTbの検索の特殊仕様なのかもしれません。
➀のメールのソースは、セキュリティ処理後の物を圧縮して添付します。
もう少し調べてみますが、取敢えず御報告いたします。

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

なるほど、本文に「～.pdfを添付したから読んどいて」みたいなものがあるメール、という手もあったか...
例え一部でも見つかれば、それを足がかりに捜索の範囲を広げたり絞り込めたりします。

あとは、felsendorfさんが間違った関連付けでPDFを添付したメールを見つけると、間違った関連付けをThunderbirdに覚えこませてしまった時期を推測できます。
少なくとも、その中の一番古いメールよりも前、になります。


これは、(a) そのPDFの添付がCntent-Type: text/html になっていることと、(b) 既定のブラウザーがIEになっていること、を示しますが、わざわざそんなスクリーンショットを貼り付けなくても、(a) と(b) を説明するだけで済む話です。

このメールは、誰が送ったものですか？felsendorfさんは、受信者ですか？送信者ですか？


でも、検索して、見つかったメールを開いて、添付を保存しようとしたら、「プログラムで開く　Internet Explore(規定）」、なんですよね？
検索後、どうやってそのメールを開いた？どうやってメールのソースを保存できた？


本当に、前に書いたことをちゃんと読んでくれない...

たとえそのメールにContent-Type:text/htmlで添付されていたとしても、
まだ間違った関連付けをThunderbirdに覚えさせる前に、自分でpdfファイルとしてファイルに保存して、それを送ったのなら、Content-Type:text:htmlで送られるはずはない。
たとえ、felsendorfさんが、間違った関連付けをThunderbirdに覚えさせてから送ったとしても、拡張子は正しい.pdfであり、
多くのメーラーは、Content-Type:優先ではなくて、base64のデータを～.pdfというファイルに展開し、その.pdfを見てAdobe Readerに渡す、というようなことをしているし、
ましてや、受信者がファイルに保存した場合には、データとしてはbase64エンコードされた正しいPDFファイルのデータが送られているわけで、Content-Type:text:htmlであることは、一切の問題をひき起こさない。
そして、たとえ、felsendorfさんと同様にThunderbirdを使っていたとしても、間違った関連付けをThunderbirdに覚えさせてしまうことを、felsendorfさんからのそのメールを受け取った全Thunerbirdユーザーがするはずもない。
また、felsendorfさんからのそのメールを受け取った全Thunerbirdユーザーが、関連付けをThunderbirdに覚えさせることをしたとしても、必ずしも、felsendorfさんからの間違った関連付けのメールで行うとは限らないし、他にもPDFが添付されたメールも受け取っているであろうし、正しい関連付けのメールで関連付けをThunderbirdに覚えさせる確率のほうが高い。

そして、何度言っても、「文字化けする」「文字化けしない」、で、Content-Type:がどうなっているかの説明は一切無し...

正しいapplication/pdfのPDFの添付ならば、表示・添付をインラインで表示、がオンだろうがオフだろうが、インラインで表示されることはありえなくて、アタッチメントペインにファイル名が表示されるだけです。
これくらいはおわかりですよね？
ですから、表示・添付をインラインで表示、をオンにしたときに、PDFにもかかわらずインラインで表示されてしまうこと自体が異常なのです。
何度も何度もContent-Typeのことを説明しているにも関わらず、
その異常な「PDFのインライン表示」において、Ｕ+FFFDが表示されると「文字化け」で、読める文字が表示されるから「文字化けしていない」、ということを、このトピックの始めのうちだけならともかく、今になっても繰り返し書いてくるのは、どういった理由からなんですか？
何度も何度もContent-Typeのことを説明しているにも関わらず、Content-Typeの確認・説明は一切せずに、その異常な「PDFのインライン表示」において、「文字化け」があるから怪しくて、読める文字が表示されていて「文字化けしていない」から怪しくない、というようなことを、今になっても繰り返し書いてくるのは、どういった理由からなんですか？

一度、ファイルに保存したいくつかのPDFファイルの中身を、テキストエディターで見てみるといいかも。

早速にご返事ありがとうございます。.「PDFが添付文書である」メールを検索する方法はあるのでしょうか？➊がインラインで「文字化け」していることと、プログラムで開くがadb 関係になっていないことを強調するため、スクリーンショットを貼り付けました。　　なお、前にも述べていますが、所属学会が会員に送ったもので、私は受信者です。

検索の書式を添付に示していますが、検索結果をクリックすることでそのメールに跳びます。そのソースを取って、圧縮したものを添付に付けています。
何故か受信トレイからは消えてしまいます。Tb検索の仕様なのですかね。　大変判りの悪い生徒で申し訳ありません。しかし前報で「Content-Type:がどうなっているかの説明」をするために、該当メールのソースを付けておいた筈です。念のため再度添付いたします。
またExel, pdf, word, wordの4つの添付書類があり、Content-Typeの部分をソースから抜き出すと以下のようになります。Content-Type: multipart/mixed;
Content-Type: text/plain; charset=ISO-2022-JP
Content-Type: application/vnd.openxmlformats-officedocument.
Content-Type: text/html;……Content-Transfer-Encoding: base64
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.
これらのことから


の『誰かが』が特定できたかなと思ったわけです。早計ですか？
　大変出来の悪い生徒で申し訳ありません。しかし通常の「Thunderbird利用者」はこの程度の物なのだという認識はしてください。貴方が要求することを全利用者に求めるとすれば、利用者は格段に減ってしまいますよ。
恥かきついでに、「テキストエディター」とは何で、それをどうり用意するのですか？

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

> の『誰かが』が特定できたかなと思ったわけです。早計ですか？

新しいバージョンは、読んでくれない？

felsendorfさんが最初に(1-b)と(2)をやって、SICEさんにtext/htmlのPDFを送ったのが原因、という可能性は、まだ排除されていませんよ。

ファイル/新規/検索フォルダ、あるいは、検索結果で、検索フォルダに保存、を行うと、検索対象に複数のフォルダーを指定できる「検索フォルダ」を作成できます。
(通常の検索は、対象が、あるフォルダとそのサブフォルダーだけ)
From, Contains, SICE、とか、Subject, Contains, SICE、で検索してみてください。
問題のメールはヒットしますか？

From, Contains, SICE、AND 添付がある、だと、過去の添付つきメールがわかりますから、問題のメールの前後で、PDFの添付がapplication/pdfからtext/htmlに変わった時点を特定できるかもしれません。
また、From, Contains, SICE, OR, To or CC, Contains, SICE、で検索すると、過去のやりとりのメールがわかります。

今回の問題が起こり始めるよりも前に、PDFファイルを開こうとした時に、IEが表示されたのでAdobe Readerを選択した、というような記憶はありますか？
たとえその時に既にPDFがtext/htmlだったとしても、felsendorfさんがThunderbirdに間違った関連付けを覚えさせるということをしなければ、その時点では今回の問題は起こり始めません。

学会関係で、多くの人に文書をメールで配布、だと、ある個人のパソコンに全文書を保管して管理、ということはなくて、ファイルサーバーに保管してあるケースが多いと思います。
誰かがあるPDFファイルをtext/htmlでアップロードしてしまい、それをメールに添付、じゃないかな？
そうだとすると、全部が全部text/htmlで送られてきたわけではなくて、一部のPDFファイルだけがtext/htmlで送られてきているはず。

ところで、ピザや寿司を勝手に注文される危険性の排除は、お済みですか？
1ページ目でアクセスできるファイルはもう不要ですから、早めに削除しておきましょう。

> 「テキストエディター」とは何で、それをどう用意するのですか？

これまた、前に書いたことを読んでくれない...

意訳は、「ワードじゃぁない、普通に文字を書けて普通にテキストファイルにしてくれるソフト」。
たった一行のテキストなのに、ワードで書いて、巨大なワードのファイルをメールに添付、ということを、よくなさった方かな？
自分で「テキストエディター」でググる、くらいはしましょう。
http://ja.wikipedia.org/wiki/テキストエディタ

Winの標準は、notepad.exe(メモ帳)。LinuxだとEmacsあるいはvi。Mac OS Xだとわかりやすくて、テキストエディット、というらしい。Simple Textはもう過去のものらしい...
私は、矩形領域のコピー・ペーストが楽にできて、文字コードや改行コードを変えられるSakura Editorを愛用しています。
掲示板などでの「引用」の作成には、Thunderbirdのコンポーザーを、「Paste as Quotation」専用のテキストエディターとして利用。

> Content-Type: multipart/mixed;
> Content-Type: text/plain; charset=ISO-2022-JP
> Content-Type: application/vnd.openxmlformats-officedocument.
> Content-Type: text/html;……Content-Transfer-Encoding: base64
> Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.
> Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.

felsendorfさんの場合、伺ったお話から推測して、ワード、エクセル、PDF、が、添付ファイルの主流、と考えて良さそうですね。
となると、base64で送られてくるものの、かなりがPDFファイルのはず。
だとすると、OSの「ファイルの検索」などで、Thunderbirdの...\Mail\<サーバー名>のディレクトリーとその下のものについて、「Content-Transfer-Encoding: base64」が含まれる行を見つけ出すといいかもしれません。

ImportExportToolsというアドオンで、全メールを個々の.emlファイルにわけておいて、データに「Content-Transfer-Encoding: base64」が含まれるファイルを探す、という方が、メールの探索にはいいかな？
HTMLメールを多用していなくて、メールの本文はtext/plainが主流のようにも見えますから、
.emlファイルに分けておいて、「Content-Transfer-Encoding: base64」と「Content-Typpe: text/html」の両方を含むもの、という手もありそう。
「Content-Typpe: application/pdf」を含むもの、にすれば、正しいmime-typeのPDFの添付があるメール全て、が確実に探せます。
後は、ImportExportToolsで、ヒットした.emlファイルをインポートしてThunderbirdのメールフォルダに統合すれば、Thunderbirdでのメールの検索ができますし、時系列に並べて、Content-Typeが変わった時点も特定しやすくなります。

もし、学会のデータのContent-Typeの問題だとすると、間違ったContent-Type:でアップロード、が起こっていて、今回の問題だけでなく、予期せぬ問題を起こす可能性もあります。
Firefoxでの、アップロードしたファイルのContent-Type:が狂った、という問題報告のほとんどが、今回の問題と同様のメカニズムで起こった問題です。
多少、手間と時間をかけてでも調べて、報告してあげたほうがいいでしょうね。

でも、今回の「間違った関連付け」、というのが、いやらしいことに、添付のパートのヘッダーなのでThunderbirdの検索では検索できなくて、
PDFなのにContent-Type: text/html、なので、他の正しいtext/htmlのものとの区別のつけようがなく、
その上、「PDFなのに」を検索しようにも、「.pdf」という文字列がメールデータの中にはなくて検索できない、という難問があります(日本語のファイル名なので、base64エンコードによって隠されてしまっている)。
こうなると、手動での検索では手がかかってしょうがなくて、スクリプトを書いて探し出す、などの手を考える必要がでてきます。
"From -" の行番号、Content-Type: multipartの行番号、base64の行番号、text/htmlの行番号、application/pdfの行番号、ファイル名をデコードした最後が.pdfの行番号、などを、行番号の順に並べれば、おおよその判定ができて、
X-felsendorf-Keys: といったヘッダーに判定のためのデータを書いて付け加えておけば、この後に、Thunderbirdでの「メールの検索」が、簡単にできるようになります。

今回の問題そのものに関しては、Thunderbirdに登録してしまった間違った関連付けの削除、で、すでに解決しています。
問題がどこでどのように生み出されたかの追跡は、別に急を要するわけではありません。
別途、上記の「困難な検索」を主題にしたトピックを開いて、そちらで検討した方いいと思います。

ソースｘを見て気になったこと。
> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

事務局の田中さんという方も、Thunderbirdを使っているようですね。

このメールの日付。
> From - Thu Apr 10 17:24:07 2014
> 最後(先頭) のReceived: from ... Thu, 10 Apr 2014 16:23:16 +0900 (JST)
> Date: Thu, 10 Apr 2014 16:23:13 +0900
4/10 16:23に発信され、4/10 16:23にサーバーに届き、felsendorfさんのPCでは、4/10 17:24にダウンロード。

felsendorfさんが先にPDFをtext/plainで送り、田中さんも間違った関連付けをThunderbirdに覚えこませてしまったので、このメールで、PDFがtext/plainで送られてきた、ということはないですか？

1. FolderX,FolderYというフォルダーを作り、
   FolderYに、felsendorfさんが送信したメールで、少しでも関係しそうなメールを全部コピーし、
   日付順にソートし、一番新しいものを除いてFolderXにコピーし(全選択だと、ソート順に無関係にコピーだったはず)、一番新しいものをFolderXにコピー。
2. FolderXをテキストエディターで開き、Content-Type: application/pdf の行を検索し、
   上に戻って"From - 日付"の行を探し、その下のSubject:やDate:などを記録、を繰り返せば、
   felsendorfさんが送信したメールで、application/pdfでPDFファイルが送られた日付が全部わかります。
3. 今回の問題が起こる前に、最後にapplication/pdfでPDFファイルが送られた日付と、
   今回の問題が起こった後、間違った関連付けを削除して、最初にapplication/pdfでPDFファイルが添付されたメールが作成された日付の間が、
   felsendorfさんがPDFをtext/htmlで送った可能性がある期間になります。

felsendorfさんと田中さんの、どちらが先にtext/htmlのPDFをメールに添付して送ったのでしょう？

なお、アップロードされたzipの中のメールデータは、本文部分が、元々のiso-2022-jpのバイナリーからShift_JISのバイナリーに書き換えられています。
多分、メールアドレスなどの書き換えの時に、iso-2022-jpだとエスケープシーケンスで判別できるので正しく読み込めて、編集に使ったソフトウェアで保存した時に、意図した・意図していない、に関わらず、Shift_JISで保存した、ということでしょうけど、ご注意を。

Thunderbirdだから、filenameをRFC 2231 エンコードしてますね。( Bug 193439 )
> filename*0*=ISO-2022-JP''%53%49%43%45%1B%24%42%42%33%21%39%25%57%25%6D%25;
> filename*1*=%3B%25%39%3D%4E%23%32%23%30%23%31%23%34%4A%67%3D%38%4D%57%39;
> filename*2*=%60%1B%28%42%30%34%31%30%2E%70%64%66
大体がiso-2022jpのメールでしょうから、filenameもiso-2022-jpでしょうし、皆さん拡張子は小文字でしょう。
となると、.emlファイルにわけて、「%2E%70%64%66」という文字列を含むファイル、で、最後の「.pdf」部分が分割されていない限りは「.pdfがファイル名にあるもの」を引っ掛けられるでしょう。
たとえ全部ではなくても、ある程度の数が引っかかれば、判断材料になります。

どうも色々ありがとうございました。学会と連絡をとったところ、Thunderbirdに詳しい人がおられ、大体解決がつきました。私の推測が当たっており、学会発のメールが主犯だったようです。
他にも問合せがあったようです。「Thundebirdのバグでは無い」と言われましたが、「善意の利用者」がこのような騒ぎに巻き込まれるのは何かおかしいなと思います。折角ですからWADAさんからその後ご教示受けたことも後で勉強してみようと思います。一つ教えてください。
寿司なら少々の量は大丈夫ですが、大量のピザは勘弁してください。
削除の方法をお教えください。

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

やっぱり、前に書いたことをちゃんと読んでくれていない。

他のトピックでしたが、以前、掲示板トップ のリンクから入ったページにヘルプのリンクがある、と書きましたよね。
BBCodeなどの件でもそうですが、各種の操作方法などについては、余程手抜きのひどいところを除き、フォーラムなどでは、ほぼ必ずガイドやヘルプの文書を用意しています。
ヘルプ文書には、ちゃんと以下の項目があります。
> ファイルの添付
> 　この掲示板にアップロードできるファイルの種類は？
> 　自分がアップロードしたファイルを確認するには？
そして、このリンクの文書には、以下のように書いてあります。
> » 自分がアップロードしたファイルを確認するには？
> 登録ユーザーであればアップロードした添付ファイルのリストをユーザーCP 内の “添付ファイルの管理” で確認できます。
たとえ、誰かに最初に聞くほうが早いから自分で調べるなんてな無駄なことはしない、という文化で育った方であっても、操作説明書とか取扱説明書とか、マニュアルの類には必ず書いてあることを、自分では一切調べようともせず、何度も何度も他人に聞いて他人に調べさせる、ということは、できるだけ避けてください。
紙のマニュアルしかない時代は、大量のマニュアルの中から目的のマニュアルを見つけ出すだけでも大変でしたが、
HTMLが極く普通に使えるようになって、目次や索引でページを調べてからページを繰る必要もなくなり、
インターネットのおかげで、ブラウザーさえあれば世界中の文書を簡単に読めるようになり、
グーグルのおかげで、文書の探索なども驚くほど楽になっています。

最初にこの問題に遭遇したのがBug 471027でした。
今見ると、2008年のクリスマス、でしたね。
felsendorfさんも経験なさった問題は、Bug 476133に分離してあります。
Bug 471027 に書いてあることとあまり変わらないので、後に、Bug 471027 のDUPでクローズされちゃったんですけどね(^^;
この時から変わっているのは、ツール・オプション・添付で、エントリーの削除を「アクション」の中でできるようになって、mimeTypes.rdfを手動で消す必要がなくなった、ということだけです。
このバグのDependency Treeにあるバグ、それらのバグのコメントにあるバグへのリンク、それらのDependency Tree、...、は、この問題との格闘、というよりも、デベロッパーとの格闘の歴史(^^)

インターネットの世界の基礎のRFCは、一種のマナーであって、正しく書いてある時のことしか規定していなくて、今回のような、異常なデータが発生した場合には、何をするかの規定がないので、変更を要求してもなかなか通りません。
規定されていない異常なデータは、最初に作り出した人がそもそも悪いのであって、その異常なデータの登録をThunderbirdに要求した人も悪いのです。
「フェィルセーフ」的なことを念頭においてデザイン・開発をしてくれればいいのですが、そうは問屋が...

私の探し方が悪いのか、また「添付　削除」で検索しても行き当たりませんでした。また、想像の元に添付文書を削除しようとしたのですが、うっかり「編集」をクリックしてなかったため、動作してくれませんでした。上記のように、上手く行き当たりません。

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

WADAさまのご苦労が十分に判ります。時間のある時、ゆっくり読ませていただきます。ただ「今後も今回私が経験したことは起りうる。起こった場合の対応はある」ということですね。長いお付き合いありがとうございました。そろそろ幕をひこうとおもいますがよろしいでしょうか？

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

「不逞の輩」さんを特定できて、問題を指摘してあげることができて、よかったですね。

それにしても、「本文に.pdf」で、犯人のメールともうひとつだけを簡単に見つけることができるとは、思いもよりませんでした(^^;
添付ファイル名はメーラーが一覧で表示してくれるんだから、と、本文にわざわざファイル名を書く、なんてことはしなくなってから、随分経ちます。
お見事。

あのバグで、冗談で書いた「解決策」は、
取締役会長さんが、(a) Thunderbirdでの添付のデリート禁止令と、(b) Thunderbirdでの添付のダブルクリック禁止令を出し、
それでダメなら、取締役会長さんが、(c) Thunderbird使用禁止命令を出す、
でした。
巨大エクセルファイルを添付して送るのが普通の会社のようで、みんな(a)をやって自分のPCのHDDがパンクしないようにしていたみたいで、
mimeTypes.rdfを消して自分のところで問題が起こらないようにしても、
いずれ誰かが(a)と(b)をやって、困ったチャンなメールの添付を他の人に送り、受け取った人のところで(b)をやると又問題が起こり始めて、多くの人にばら撒く、
の連鎖の絶ちようがなかったから、(c)以外の解決策がない(^^;

そして、felsendorfさんも「不逞の輩」にならずに済んだようで、よかったですね。
これにて、一件落着(^^)