質問

終了

Thunderbird2.0.0.**およびNS7.1メールのメール受信時のトラブルについてです。
（参考P3-M1.2GのWIN2K上のノートパソコン・PC）
特定のサイトからのメールに限られていることもあり、そのサイトの方々と解析にあたっているのですが、全くわからずに非常に困っています。
何らかのご経験のある方、メール送受信プロトコルに詳しい方など、★原因の推測ができる方よろしくお願いいたします。

★過去のNS7.1★
経緯を説明しますと、2005年ぐらいからNS7.1で受信しているとある「情報メール」がありました。
（複数の端末からアクセスするなどの関係上、サーバにメールを残すの設定で、まずはこれが一つのキーではないかという気はしています）
ところが、昨年か今年の初めぐらいから、その情報メールの受信時、稀にですがメールを（本文まで）受信した後に、以降のサーバ接続のたびに延々繰り返して同じメールのみを受信し続け、次メール受信へ全く移行しなくなるという現象が起こる様になりました。
ヘッダを見ると、最初のみ正常受信しているのですが、以降の同一メールの物は、当然というかStatus: ROです。
ただし、NS7.1を終了して再起動をかけると、一旦は解消して次のメール以降を受信出来る様になります。

★Thunderbird2.0.0.**★
NS7.1メールの慣れで使い続けて来ましたが、上記の様な問題が発生する様になったために、Thunderbird2.0.0.16に切り替えました。（現在Thunderbird2.0.0.17）
ところが、何と上記で問題を起こしているサイトのあるメールが来ると、今度はその時点でそのメールを受信することも無くそれ以降の受信がストップしてしまい、Thunderbirdを再起動しても復活せずに、にっちもさっちもいかない状態になるのです。
（なお、両方のメーラで最初に受信することは不可能なため個別の整合性はわかりません）
苦肉の策で「ヘッダのみ取得する」として件名などのヘッダ情報を取得した後に読み込み直しを実行しなければなりませので、振り分けなどしているしている場合にはかなりの手間がかかります。
ただし、ここでさらに問題なことは、そのきっかけとなったであろう問題のメールの本文はいくら繰り返してもThunderbirdでは取得出来ないことです。
（「メールをサーバに残す」設定に鳴っていますから、後からNS7.1で取得すると、メールサーバには残っているために取得出来るのです）

ただ単に受信が止まってしまっただけのNS7.1に対して、Thunderbirdは修復に再起動どころか、かなりの手間がかかってしまうことが問題を大きくしていますが、何とついに昨日は関連してメール受信ファイルの不整合まで起こして、大量に過去のメールが消えるという致命的な症状につながりました。。。。。。

はっきり申しましてショックです。
念のためソースのテキストファイルも探したのですが、勝手に最適化された感じで見事に容量が激減していて中身も消えているのです。。。

（以下起こるメールのみということでは無く、起こる可能性のあるメール群とその他での差ということで）
そのサイトの他のユーザでは起こっていないとのことですが、私の方ではそのサイトの情報メールでしか起こらないために、念のためにヘッダの差を解析したところ、
その他と差があるのは、
X-Priority: 3
X-MSMail-Priority: Normal
があります。
（これはあまり関係無さそうですが、念のため）

あとは、Return-Path: が毎回変わっていることで、もしかしたらNS7.1やThunderbirdの迷惑メール防止機能のモニタリングに絡んで、このReturn-Path:との対応のデータベースというか学習の量が多くなったとか一度に大量に入って来た場合などに、オーバフローやタイムアウトを起こす可能性があるのではないかと疑っています。
（最初はこの学習量が少なかったために起こらなかったが、一つのFrom:に対応するReturn-Path:の学習データが過多になったために起こるようになったとか）
「迷惑メール機能を切る」ということも対策ではありますが、それはそれで困りますので可能性としてどうかということです。

余談ですが、専門家だというサポートサイトに聞いてみると「同一のFrom:でReturn-Path:が変わらない方が迷惑メールとして判断され、Return-Path:を変えた方が迷惑メールと判断されないのでそうしている」とおっしゃるのですが、「Return-Path:が同じで迷惑メールと判断されるとわかっているなら、迷惑メール側がReturn-Path:を変えるであろう？ことより、むしろReturn-Path:を個人特定で一定にしてパスワード的に判別させた方がよほどか迷惑メール対策であって、サポートサイトの言う対策は「出す側の迷惑メール対策回避策」に過ぎず、「Return-Path:をランダムに変えることが迷惑メール対策になるとは思えない」のですがいかがなものでしょうか？

原因推定の参考になりそうなコメントをよろしくお願いいたします。

質問者：questioner
質問日時：2008-10-11 10:07:10
0

回答してくれたみんなへのお礼

みなさま、ご回答ありがとうございました。

最近、メールサーバを弄らなくなって久しく、サーバのmailspoolに手を付けることの背中を押してくださった知識人さんをベスト回答とさせていただきたいと思います。

かなりわかって来たことはありますが、お礼返信の期限内ではまだ推論の段階で、確定的な最終結論は出そうにありませんのでご了承願います。

当初「ヘッダ」と思われていたのですが、それはあまり関係が無く、種々の状況からすると、むしろmailspoolのEOFが一時的におかしな状態になるために発生するのではないかという方向になっています。
ただし、この発生の状況をプレイバックするとか再現させるには困難がありますのであくまでも推測です。

かなりの量のログ情報とmailspoolファイルがありますので、これからいろいろと解析を進めたいと思います。

なお、現象の詳細がわかって来るのと並行して関連の情報をネット検索するのですが、この手の問題（何らかのPOPのタイムアウト）のカラクリを解析されている物がほとんど無く、かなりが通信の不安定とか切断で片付けられている様です。
（中には気にすることは無いとまでありますが、実はこの手のエラーは、何らかの投げられたメールその物に問題がありそうで、突っ込んで解析して行けば、大元のメール配信ソフトだけで無く、メールサーバ、メーラなどの機能改善につながるのではないかと言う気がしています）

今回の件は、起こるのが1つの特定のサイトであってその他のサイトでは全く起こらないことより、メールソフトの仕様の問題はあるにしても、単に「通信の不安定」だけでは説明が付かない物です。
まず、本来は他のサイトからの物でも起こる物が、たまたま特定のサイトにのみに当たってしまったというのは、あまりにも偶然過ぎます。
（いくら特定サイトのメールが比較的多いとは言え、全体で何千通も受けて問題の約50件が特定サイトに限られるため）
ましてや、そのサイトのメールが無ければほぼ全く問題が発生しない（であろう）ということで、そのサイトのメールが存在することによって「通信の不安定」になるというのもかなりおかしな話です。
メーラの要因としてメーラを変更すれば解消する可能性は大きいものの、メーラの仕様としてどこでどうなってこうなるのかは、詰める必要があると思っています。

その他副作用的に発生していることで、Thunderbirdで不具合のトリガーになったメールに限り、ヘッダのみ取得するでリスティングさせた上で「本文をダウンロード」した時、サーバに残っているにもかかわらずタイムアウトエラーで全く本文を取得出来ないこともありますので、今しばらくじっくり検討したいと思います。

ベスト回答

mailspoolに問題があるような気がしますね

受信サーバが何のプログラムかによっても変わってきますが
通常のmailbox形式なら、問題のメールをローカルに保存して
サーバ上のメールを削除して見て下さい

telnetでログイン出来るなら、mailspoolを直接確認するという方法もありますが
原因を特定するのは難しいかと思います

出来ればmailspool自体を削除するのが確実なんですが

回答者：知識人 (質問から13時間後)
0

この回答の満足度

とても参考になり、非常に満足しました。回答ありがとうございました。

ご回答ありがとうございます。

私もメールサーバのmailspoolに問題がある様な気がします。
ただ、稀な相性の問題であって、たまたま特定のサイトからのメールのヘッダによって、メーラとの組み合わせで異常を起こしているというカラクリなのかなと思っています。

mailspoolの直接削除は行っていないものの、時々全取り込みでサーバ内を削除しておりますので、実質削除になっているものとは思います。
その後にも繰り返しますので、削除することによる効果は無いものと思っています。

メーラの仕様が主要因であることは間違い無いのですが、奇しくも2つのメーラで起こった類似の問題の起こるメカニズムを特定したいのですが・・・

現状を申しますと、当方のメアドのサーバが形式上ダイアルアップ契約で、現在の契約プロバイダと違うために、実質アカウントのみ契約して外から入る形になっており、ダイアルアップしないとtelnetでログイン出来ないために、別の意味でも苦慮中です。

見かけ上の受信後のヘッダでは差が見られないこと、あくまでも受信後の平文テキストはメーラがアレンジして作成した物であることからすると、mailspoolのファイルその物のヘッダ部分をバイナリレベルで確認しないと特定出来ないと思っており、次回発生した時はその特定・確認を行う方向で打診中です。

他のサイトからのメールでは全く起こらないことからすると、「起こるメールには、たまたま何らかの異常なコードが埋め込まれているのではないか」と思っているのですが、焦らず確実に追求したいと思います。

並び替え：

回答

参考になるか判りませんが、メールサーバを管理してた立場から言えばサーバに
メールを残して欲しくはありません。容量が逼迫すると圧縮最適化を頻繁に実行するしかなく、配信停止などの障害も頻発するようになってしまいます。
統計までは取ってないですが、特定のヘッダーのメールで停止することが多いようです。

回答者：某企業IT管理者 (質問から7日後)
0

この回答の満足度

参考になり、満足しました。回答ありがとうございました。

ご回答ありがとうございます。

私は基本的には、昨今の慣習で常識化したかの様なメールにメガ単位ものバカでかいファイルを添付して送受信する様なことは非常識と考える方で、極力FTPやHTTPなどのアップロード・ダウンロードで対応する口で、メールをサーバに残す点の懸念点は充分に理解しています。

ですから、定期的あるいは選択的に削除はしていて、基本的にはmailspool全体がメガオーダになることは無く、Yahoo!フリーメールの1.5GBなどほど遠い容量で、数メガ程度でおっしゃる様な「配信停止などの障害も頻発する」問題を起こす様なメールサーバでは極めて脆弱と言わざるを得ない様な気もします。

ですから、「メールをサーバに残す」は、メーラおよびメールサーバ（というかボランティア規格的なTCP/IPと言うべきか）の脆弱性の万が一のバックアップの目的で使用すると言った方が正しいです。

なお、今回の解析では、何と無くメールサーバ側にも脆弱性を持ち合わせている様な感じです。
（確証をつかむには、送信側調査とかでもう少々時間がかかりそうですが）

そもそも、サポート窓口に、sendmail、サーバのログやmailspoolの話をしても、システムの方が出るのでは無く、それほどわかっていらっしゃらない方が対応して、「メールソフトを変えてみてどうですか」程度をおっしゃるのみ。
mailspoolが残存して明確に不具合が再現している状況に対して、こちらの操作に対するログの確認やコメントは一切無しという状況で、むしろサポートその物が脆弱であると思いました。
ありがたいと言うべきか・・・、ログもmailspoolもこちらに丸投げとなりました。

特にログファイルは、サポートの話の最初に出してくださっていれば、かなりやり取りの時間が短くて済んだにもかかわらず、これが出て来たのは話が平行線をたどってかなり期間が経過し、サポートがサジを投げかかってからでした。
（不具合の発生している前後というか以降のログを見ると一目瞭然の問題アリアリ。問題メールを特定して調査依頼していたにもかかわらず、どうしてこれを見ながら話を進めなかったのかが疑問なくらいです。）

なお、種々の状況からすると、問題の原因はヘッダでは無くmailspoolのEOFではないかという方向です。
（比較的つじつまが合うため）

とにかく、「問題が起こると、ろくろく解析せずに現象論や結果論から全くのだろう話で対処療法で逃げている」ことが、潜んでいる真の問題の解決を阻む最大の要因の様な気がしています。

回答

何が原因なのかを求めておられるので直接的な回答にはなりませんが、個人的に感じた事を書かせて頂きます。

まずはThunderbirdやNetscape以外のメーラーで発生するかどうかを確認されてはいかがですか？
他のメーラーでも発生するのであれば、その「情報メール」が問題でしょうし、
他のメーラーで発生しないのであれば、ThunderbirdやNetscapeが原因です。
ThunderbirdやNetscapeが原因であれば、ソフトの不具合が考えられます。
不具合が改修されるのを待つか、問題なく受信できるメーラーへの乗り換えを検討されてはどうですか？

それから対策としてですが、私なら問題の「情報メール」だけを受信した後にサーバから消します。
もしも複数の端末でその「情報メール」を見たいのであれば、再度自分に転送します。
メールのヘッダに原因があるのなら、これで問題は起こらなくなると予想できます。

最後に、POPメールをサーバに残して複数の端末で見ようとしている事に疑問を感じます、
こういった使い方をするのであれば、IMAPメールの方が適していると思うのですがどうでしょうか？
アドレスが変わる事を危惧されているのでしたら、受信したPOPメールをIMAPに転送すれば、
複数端末で同じメールを読む事ができます。

問題の解決だけにこだわらず、ご自分の環境を変えて問題を回避する事を
考えても良いのではないかと思いました。

回答者：Sooda! ちゃん (質問から29分後)
0

この回答の満足度

参考になり、満足しました。回答ありがとうございました。

ご回答ありがとうございます。

一番は、原因を特定出来そうなのに特定せずにだろう話で訳のわからないまま対処療法を恒久化したくないということがあります。

他のサイトからのメールでも同様な現象が起こる様であれば、それも考えました。
ところが、起こるサイトが完全に限定されていることより、原因追求に向かっているのです。
「そこだけがヘッダあたりの違いがあって起こる」ことはほぼ確かです。
そこを受信しなければ、起こらないのですから。
バグとか現仕様でも構いませんので、その原因を特定したいということです。

誤解があるといけませんので追記しておきますと、特定のサイトから来るメールが全て問題を起こす訳では無く、「時々上記の様な問題を起こすことがあるメールが含まれている」ということですから、問題が起こるメールを選択的に削除したり転送したりすることは不可能です。
もちろん、別途全面的なGmailなどの転送を介した手段も検討中ではありますが、同時に影響の無い分のメール登録までに転送がかかるために躊躇しているのです。

そもそも、メーラ自体の信頼性も問題で、本件にしてもまさに、このままThunderbirdでサーバから消してしまっては、未だ経験したことの無い「来ているのに内容さえ読むことが出来ない」ことさえ起こっていますので、なおさら単一受信でサーバから消すことをためらうことになっていますね。
もちろん、アクセスが遅くなるために定期的には消しています。
この点ではサポートの無いNS7.1の方がまだ良かった。
しかし、Thunderbirdの優れた機能も使いたいので困っているのです。

以前はEUDORAを用いていましたが、とにかくマルチアカウントに加えて詳細な振り分けを実施していますので、少なくともマルチアカウントがゴチャゴチャに受信されるのではなく、きちんとマルチアカウントに対応し、振り分けや迷惑メール機能もNS7.1あるいはThunderbird同等あるいはそれ以上のソフトで無いと恒久的な変更は出来ないということもあります。

Sooda!からのお知らせ

一覧を見る

質問

回答してくれたみんなへのお礼

ベスト回答

回答

回答

関連する質問・相談

Sooda!からのお知らせ