メールサーバ網、サーバ装置、メールシステム及びそれらに用いる障害箇所調査方法
【課題】 故障・遅延箇所の特定・切り分けに要する時間を短縮することが可能なメールサーバ網を提供する。
【解決手段】 複数のメールサーバ（第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７）と、複数のメールサーバから一定時間間隔で送出される定期メールを受信する受信サーバ（受信サーバ群４）と、受信サーバで受信した定期メールの解析を行う解析サーバ１とを含むメールサーバ網は、解析サーバ１に、受信サーバで受信した定期メールの受信時間及びメール経路の情報を記録する記録手段と、記録手段に記録された情報の統計処理を行う統計手段とを設けている。解析サーバ１は、統計処理の結果を基にメールサーバにおけるメール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報を作成する。
【解決手段】 複数のメールサーバ（第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７）と、複数のメールサーバから一定時間間隔で送出される定期メールを受信する受信サーバ（受信サーバ群４）と、受信サーバで受信した定期メールの解析を行う解析サーバ１とを含むメールサーバ網は、解析サーバ１に、受信サーバで受信した定期メールの受信時間及びメール経路の情報を記録する記録手段と、記録手段に記録された情報の統計処理を行う統計手段とを設けている。解析サーバ１は、統計処理の結果を基にメールサーバにおけるメール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報を作成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はメールサーバ網、サーバ装置、メールシステム及びそれらに用いる障害箇所調査方法に関し、特にメールサーバにハートビート機能を持ち、ハートビートメールの自動解析を行う解析サーバを含むメールサーバ網における故障箇所や遅延箇所等の障害箇所の切り分け方法に関する。
【背景技術】
【０００２】
本発明に関連するメールシステムでは、メール未着やメール遅延が発生した際、自局及び相手局の管理者が故障箇所や遅延箇所の切り分けを行うが、各メールサーバ、各ネットワーク制御サーバ、ネットワーク網の調査や切り分けを行う必要があり、原因究明や復旧に時間を要している。
【０００３】
また、上記のメールシステムでは、相手局の設定ミス、相手局のメールサーバ不調が原因である場合、自局単独でのテストを行っても事象が再現する可能性が低く、機器の間欠故障によるトラブル時にあっても再現性があまり無いことから、切り分けに時間を要し、長時間不調状態が続く場合が多い。
【０００４】
メールサーバ網としては、メールサーバにハートビート機能を備えることで、メールサーバにおける故障等を監視するシステムがある。ここで、ハートビート機能は、一定期間毎に定期メールを送信することで自装置が動作していることを通知する機能であり、解析サーバはハートビート機能によって送られてくる定期メールの有無に基づいて各メールサーバが動作可能かどうかの確認を行っている。
【０００５】
本発明に関連するメールシステムとしては、エラー情報を故障解析センタに送信するシステムにおいて、エラーが発生しても、あるいはエラーが発生していなくともエラー情報を定期メールで故障解析センタに送信する装置が提案されている（例えば、特許文献１参照）。
【０００６】
また、本発明に関連する他のメールシステムとしては、各メールサーバ間の通信量の総数を比較して、通信量の偏っているメールサーバがある場合に、負荷を軽減するユーザポストの配置を立案表示する装置が提案されている（例えば、特許文献２参照）。
【０００７】
さらに、本発明に関連する別のメールシステムとしては、問い合わせ条件として設定された期限までに指定相手先から電子メールが届かないことを検出した場合、予め登録しておいた関係者に対して問い合わせの電子メールを自動送信する装置が提案されている（例えば、特許文献３参照）。
【０００８】
【特許文献１】特開２００１−１６６８２０号公報
【特許文献２】特開平０８−２３７２９６号公報
【特許文献３】特開２００５−３４６１２１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
上述した本発明に関連するメールシステムでは、メール未着やメール遅延発生時にどのメールサーバで遅延が発生しているのか、ネットワーク網の異常によって発生しているのかを利用者が知ることは困難である。
【００１０】
メール未着やメール遅延発生時には、利用者サイドとしてはひたすら待つか、メールの再送信操作によって再送処理を行うしかないが、利用者がメールの再送信を行うことはトラフィックをさらに倍増させることになり、リトライ方法としては適した方法ではない。
【００１１】
また、上記のハートビート機能を備えた装置としては、製品として市販されているが、これらは専用のハードウェアやソフトウェアで構成されており、専用プラットフォームが必須である。
【００１２】
さらに、上記の特許文献１に記載の技術では、エラー情報を定期メール（ハートビートメール）を用いて送信しているが、メールサーバ自体が不調となった場合に、その定期メールの未着や遅延が発生しても、それらメール未着やメール遅延発生時の対策は何ら考慮されていないという問題が内在する。
【００１３】
したがって、上述した本発明に関連するメールシステムでは、メールサーバのトラブル、メールネットワークの制御装置［ハブ（ＨＵＢ）、Ｌｘ（レイヤｘ）スイッチ、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）］の不調等の場合、管理者が切り分けに時間を要することとなる。上記の特許文献１〜３でも、メール未着やメール遅延発生時の対策は何ら考慮されていないため、上記と同様の課題がある。
【００１４】
Ｗｅｂサーバでは、３秒ルールやｘ秒ルールというのがあり、サービスレベルの要件（ＳＬＡ：Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）として制定される場合もあるが、メールサービスでのサービスレベルの基準はあいまいなケースが多く、現在どのくらいのレスポンスなのか、利用者は把握することができない、管理者にあっても容易に把握することはできない。
【００１５】
そこで、本発明の目的は上記の問題点を解消し、故障箇所や遅延箇所の特定及び切り分けに要する時間を短縮することができるメールサーバ網、サーバ装置、メールシステム及びそれらに用いる障害箇所調査方法を提供することにある。
【課題を解決するための手段】
【００１６】
本発明によるメールサーバ網は、複数のメールサーバと、前記複数のメールサーバから一定時間間隔で、もしくは予め設定された所定条件が検出された時に送出される定期メールを受信する受信サーバと、前記受信サーバで受信した前記定期メールの解析を行う解析サーバとを含むメールサーバ網であって、
前記受信サーバで受信した前記定期メールの受信時間及びメール経路の情報を記録する記録手段と、前記記録手段に記録された情報の統計処理を行う統計手段とを備え、
前記解析サーバは、前記統計処理の結果を基に前記メールサーバにおけるメール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報を作成している。
【００１７】
本発明によるサーバ装置は、上記のメールサーバ網に記載の手段を含むことを特徴とする。
【００１８】
本発明によるメールシステムは、上記のサーバ装置を含み、
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合にメールクライアントにて送信するメールが一つ前に送信したメールと同じ宛先か否かを判定し、
前記メールクライアントにて送信するメールが同じ宛先へ送信する場合に再送信警告もしくは再送信禁止メッセージを提示している。
【００１９】
本発明による第１の障害箇所調査方法は、複数のメールサーバと、前記複数のメールサーバから一定時間間隔で、もしくは予め設定された所定条件が検出された時に送出される定期メールを受信する受信サーバと、前記受信サーバで受信した前記定期メールの解析を行う解析サーバとを含むメールサーバ網に用いる障害箇所調査方法であって、
前記解析サーバが、前記受信サーバで受信した前記定期メールの受信時間及びメール経路の情報を記録手段に記録する第１の処理と、前記記録手段に記録された情報の統計処理を行う第２の処理とを実行し、
前記解析サーバが、前記統計処理の結果を基に前記メールサーバにおけるメール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報を作成している。
【００２０】
本発明による第２の障害箇所調査方法は、複数のメールサーバと、前記複数のメールサーバから一定時間間隔で送出される定期メールを受信する受信サーバと、前記受信サーバで受信した前記定期メールの解析を行う解析サーバとを含むメールサーバ網に用いる障害箇所調査方法であって、
前記受信サーバと前記解析サーバとの間に配設した統計サーバが、前記受信サーバで受信した前記定期メールの受信時間及びメール経路の情報を記録手段に記録する第１の処理と、前記記録手段に記録された情報の統計処理を行う第２の処理とを実行し、
前記解析サーバが、前記統計処理の結果を基に前記メールサーバにおけるメール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報を作成している。
【発明の効果】
【００２１】
本発明は、上記のような構成及び動作とすることで、故障箇所や遅延箇所の特定及び切り分けに要する時間を短縮することができるという効果が得られる。
【発明を実施するための最良の形態】
【００２２】
次に、本発明の実施の形態について図面を参照して説明する。図１は本発明の第１の実施の形態によるメールサーバ網の構成例を示すブロック図である。図１において、本発明の第１の実施の形態によるメールサーバ網は、解析サーバ１と、タイムサーバ３と、受信サーバ群４と、第１メールサーバ群５と、第２メールサーバ群６と、第３メールサーバ群７と、ネットワーク・メールサーバ網１００とを含んで構成されている。
【００２３】
第１メールサーバ群５は各々ハートビート機能を持つメールサーバ５０〜５９からなり、第２メールサーバ群６は各々ハートビート機能を持つメールサーバ６０〜６９からなり、第３メールサーバ群７は各々ハートビート機能を持つメールサーバ７０〜７９からなっている。これら第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７は、それぞれネットワーク・メールサーバ網１００に接続されている。
【００２４】
ここで、上記のハートビート機能から送信されるハートビートメール１０１とは、メールサーバから一定時間間隔で受信サーバ群４に送出されるメール、メールサーバにて予め設定された所定条件（例えば、メールサーバでの送受信メール数が予め設定された一定数を超えた等）が検出された時に受信サーバ群４に送出されるメール、これらのメールに対して受信サーバ群４からメールサーバに送出されるメール等である。
【００２５】
受信サーバ群４は各々ネットワーク・メールサーバ網１００に接続される第１受信サーバ４１、第２受信サーバ４２、第３受信サーバ４３から構成され、１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバ５０〜５９，６０〜６９，７０〜７９から定期メール（ハートビートメール１０１）を受信する。
【００２６】
解析サーバ１は、プログラム制御によって動作し、受信サーバ群４の第１受信サーバ４１、第２受信サーバ４２、第３受信サーバ４３各々から受取った定期メールの情報を蓄積して統計処理を施すとともに、その定期メールの情報及び統計処理の結果を解析する自動解析機能を有する。タイムサーバ３は、解析サーバ１、受信サーバ群４、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７にそれぞれ時間情報を提供する。
【００２７】
本実施の形態では、上記のような構成とすることで、ハートビート機能及び自動解析機能を有するネットワーク・メールサーバ網１００において、メール未着やメール遅延発生時におけるメールサーバ故障箇所・ネットワーク網異常箇所について、切り分け作業を迅速かつ容易にすることを特徴とする。
【００２８】
また、本実施の形態では、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７から定期メールを定期的に受信サーバ群４に送ることによって、解析サーバ１においてメール遅延・メール未着問題を解決するのに必要な情報（メール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報）を作成し、メールサーバ管理者及びメール利用者に提供している。
【００２９】
図２は図１の解析サーバ１の構成例を示すブロック図である。図２において、解析サーバ１は、ＣＰＵ（中央処理装置）１１と、ＣＰＵ１１が実行するプログラム等を記録するＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２と、ＣＰＵ１１がプログラム制御によって上記の統計処理及び解析処理を行う際の作業領域とするＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３と、メール利用者向け画面生成部１４と、通信部１５と、通信状況・メール経路情報１６１を記録する記録部１６と、タイムサーバ３からの時間情報を基に計時を行う計時部１７と、メールサーバ管理者用画面生成部１８とを備えている。
【００３０】
図３は本発明の第１の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。これら図１〜図３を参照して本発明の第１の実施の形態の動作について詳細に説明する。この動作例は、時間超過で定期メールを送信するモデルを対象として記述している。また、図１にあっては、メールサーバ台数を３０台として記述してあるが、メールサーバ台数が増加した場合にあっても本発明の趣旨が損なわれないことは明白である。
【００３１】
タイムサーバ３は、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバ、受信サーバ群４の受信サーバ、解析サーバ１の間で授受される通信記録内の時間情報について整合性を保つため、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバ、受信サーバ群４の受信サーバ、解析サーバ１にそれぞれ正確な時間情報を随時提供する（図３のａ１）。
【００３２】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバは、受信サーバ群４の受信サーバに一定時間間隔で定期メールを送出する（図３のａ２）。尚、図３では一つのメールサーバのみを図示しているが、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７のメールサーバ５０〜５９，６０〜６９，７０〜７９各々もこのメールサーバと同様の動作を行う。
【００３３】
この定期メール通信については、ＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ） Ｂｅｆｏｒｅ ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）／ＳＭＴＰ Ａｕｔｈ（Ａｕｔｈｅｎｒｉｃａｔｉｏｎ）等のセキュリティ認証を行うことによって、不正パケットによるかく乱を避けることができ、より正確なハートビート通信を行うことが可能となる。
【００３４】
定期メールを受信した受信サーバ群４の受信サーバは解析サーバ１に受信時間とメール経路情報（メールリレー情報）とを通知する（図３のａ３）。
【００３５】
解析サーバ１は各メールサーバの通信状況及びメール経路情報を記録し（図３のａ４）、その記録した通信状況及びメール経路情報に対してメールサーバ管理者用画面生成部１８にて統計処理を行ってメールサーバ管理者用画面を生成した後、ネットワーク・メールサーバ網１００にメールサーバ管理者用画面のメール通信情報を提供する（図３のａ５）。尚、統計処理としては、後述するメール通信情報の項目を生成できればよい。
【００３６】
提供するメール通信情報としては、次の項目が考えられる。つまり、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７の各メールサーバと受信サーバ群４の受信サーバとの間でのメール通信情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信に要した時間が長い一定数メールのメールリレー情報
（５）ｘ日間の定期メール通信に要した時間が短い一定数メールのメールリレー情報
（６）ｘ日間の定期メール通信受信失敗率
（７）最終の定期メール受信日時
という７点が考えられる。
【００３７】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７と受信サーバ群４との間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【００３８】
また、メール経路情報については、経路上に存在するサーバ名が全て記録されており、そのまま平文で公開すると、全てのメールサーバ名が漏洩することとなり、セキュリティ上（不正パケットによるかく乱等）の問題が発生する可能性がある。この対策として、サーバ管理者用の画面を表示する際にあっては、ユーザＩＤ及びパスワードによる認証及びＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）対応ブラウザで表示させる等のセキュリティ対応を行うことが望ましい。
【００３９】
解析サーバ１は、上記の各メールサーバの通信状況及びメール経路情報に対してメール利用者向け画面生成部１４にて解析処理を行ってメール利用者向けの運用状況画面を生成した後、ネットワーク・メールサーバ網１００にメール利用者向けの運用状況画面のメール通信情報を提供する（図３のａ６）。尚、解析処理としては、下記のメール通信情報を生成できればよい。
【００４０】
提供するメール通信情報としては、次の項目が考えられる。メールサーバと受信サーバとの間の情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信受信失敗率
（５）最終の定期メール受信日時
という５点が考えられる。
【００４１】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７と受信サーバ群４との間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【００４２】
また、上記の数値情報に適切な上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合にガイダンス表示を行うことによって、利用者による無用な再送操作を防ぐことも可能である（例：「３０分ほどお待ち下さい」等）。
【００４３】
このように、本実施の形態では、各メールサーバ群の管理者がどのメールサーバでメールリレー動作が遅延しているかどうかの情報を取得することが可能となり、故障箇所及び遅延箇所の特定や切り分けに要する時間を短縮することができる。
【００４４】
また、本実施の形態では、利用者に対して解析した遅延情報を提供し、どう対処すれば良いかを具体的にガイダンス表示による情報提供を行うことによって、利用者の無駄な再送操作を防ぐことができ、無用なトラフィック上昇を防ぐ効果も期待できる。
【００４５】
図４は本発明の第２の実施の形態によるメールサーバ網の構成例を示すブロック図である。図４において、本発明の第２の実施の形態によるメールサーバ網は、解析サーバ１ａと、統計サーバ２と、タイムサーバ３と、受信サーバ群４と、第１メールサーバ群５と、第２メールサーバ群６と、第３メールサーバ群７と、ネットワーク・メールサーバ網１００とを含んで構成されている。
【００４６】
第１メールサーバ群５は各々ハートビート機能を持つメールサーバ５０〜５９からなり、第２メールサーバ群６は各々ハートビート機能を持つメールサーバ６０〜６９からなり、第３メールサーバ群７は各々ハートビート機能を持つメールサーバ７０〜７９からなっている。これら第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７は、それぞれネットワーク・メールサーバ網１００に接続されている。上記のハートビート機能からは、上述したハートビートメール１０１が送出される。
【００４７】
受信サーバ群４は各々ネットワーク・メールサーバ網１００に接続される第１受信サーバ４１、第２受信サーバ４２、第３受信サーバ４３から構成され、１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバ５０〜５９，６０〜６９，７０〜７９から定期メール（ハートビートメール１０１）を受信する。
【００４８】
統計サーバ２は、プログラム制御によって動作し、受信サーバ群４の第１受信サーバ４１、第２受信サーバ４２、第３受信サーバ４３各々から受取った定期メールの情報を蓄積して統計処理を施すとともに、解析サーバ１ａは、プログラム制御によって動作し、その定期メールの情報及び統計処理の結果を解析する自動解析機能を有する。タイムサーバ３は、解析サーバ１ａ、統計サーバ２、受信サーバ群４、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７にそれぞれ時間情報及びメール経路情報を提供する。
【００４９】
図５は図４の解析サーバ１ａの構成例を示すブロック図である。図５において、解析サーバ１ａは、ＣＰＵ１１と、ＣＰＵ１１が実行するプログラム等を記録するＲＯＭ１２と、ＣＰＵ１１がプログラム制御によって上記の解析処理を行う際の作業領域とするＲＡＭ１３と、メール利用者向け画面生成部１４と、通信部１５と、通信状況・メール経路情報１６１を保持する保持部１６ａと、タイムサーバ３からの時間情報を基に計時を行う計時部１７とを備えている。
【００５０】
図６は図４の統計サーバ２の構成例を示すブロック図である。図６において、統計サーバ２は、ＣＰＵ２１と、ＣＰＵ２１が実行するプログラム等を記録するＲＯＭ２２と、ＣＰＵ２１がプログラム制御によって上記の統計処理を行う際の作業領域とするＲＡＭ２３と、メールサーバ管理者用画面生成部２４と、通信部２５と、通信状況・メール経路情報２６１を記録する記録部２６と、タイムサーバ３からの時間情報を基に計時を行う計時部２７とを備えている。
【００５１】
図７は本発明の第２の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。これら図４〜図７を参照して本発明の第２の実施の形態の動作について詳細に説明する。この動作例は、時間超過で定期メールを送信するモデルを対象として記述している。また、図１にあっては、メールサーバ台数を３０台として記述してあるが、メールサーバ台数が増加した場合にあっても本発明の趣旨が損なわれないことは明白である。
【００５２】
タイムサーバ３は、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバ、受信サーバ群４の受信サーバ、統計サーバ２、解析サーバ１ａの間で授受される通信記録内の時間情報について整合性を保つため、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバ、受信サーバ群４の受信サーバ、統計サーバ２、解析サーバ１ａにそれぞれ正確な時間情報を随時提供する（図７のｂ１）。
【００５３】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバは、受信サーバ群４の受信サーバに一定時間間隔で定期メールを送出する（図７のｂ２）。尚、図７では一つのメールサーバのみを図示しているが、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７のメールサーバ５０〜５９，６０〜６９，７０〜７９各々もこのメールサーバと同様の動作を行う。
【００５４】
この定期メール通信については、ＰＯＰ Ｂｅｆｏｒｅ ＳＭＴＰ／ＳＭＴＰ Ａｕｔｈ等のセキュリティ認証を行うことによって、不正パケットによるかく乱を避けることができ、より正確なハートビート通信を行うことが可能となる。
【００５５】
定期メールを受信した受信サーバ群４の受信サーバは統計サーバ２に受信時間とメール経路情報（メールリレー情報）とを通知する（図７のｂ３）。
【００５６】
統計サーバ２は各メールサーバの通信状況及びメール経路情報を記録し（図７のｂ４）、その記録した通信状況及びメール経路情報に対してメールサーバ管理者用画面生成部２４にて統計処理を行ってメールサーバ管理者用画面を生成した後、解析サーバ１ａとネットワーク・メールサーバ網１００とにメールサーバ管理者用画面のメール通信情報を提供する（図７のｂ５）。尚、統計処理としては、下記のメール通信情報の項目を生成できればよい。
【００５７】
この時に提供するメール通信情報としては、次の項目が考えられる。つまり、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７の各メールサーバと受信サーバ群４の受信サーバとの間でのメール通信情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信に要した時間が長い一定数メールのメールリレー情報
（５）ｘ日間の定期メール通信に要した時間が短い一定数メールのメールリレー情報
（６）ｘ日間の定期メール通信受信失敗率
（７）最終の定期メール受信日時
という７点が考えられる。
【００５８】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７と受信サーバ群４との間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【００５９】
また、メール経路情報については、経路上に存在するサーバ名が全て記録されており、そのまま平文で公開すると、全てのメールサーバ名が漏洩することとなり、セキュリティ上（不正パケットによるかく乱等）の問題が発生する可能性がある。この対策として、サーバ管理者用の画面を表示する際にあっては、ユーザＩＤ及びパスワードによる認証及びＳＳＬ対応ブラウザで表示させる等のセキュリティ対応を行うことが望ましい。
【００６０】
解析サーバ１ａは、上記の各メールサーバの通信状況及びメール経路情報に対してメール利用者向け画面生成部１４にて解析処理を行ってメール利用者向けの運用状況画面を生成した後、ネットワーク・メールサーバ網１００にメール利用者向けの運用状況画面のメール通信情報を提供する（図７のｂ６）。尚、解析処理としては、下記のメール通信情報を生成できればよい。
【００６１】
この時に提供するメール通信情報としては、次の項目が考えられる。メールサーバと受信サーバとの間の情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信受信失敗率
（５）最終の定期メール受信日時
という５点が考えられる。
【００６２】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７と受信サーバ群４との間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【００６３】
また、上記の数値情報に適切な上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合にガイダンス表示を行うことによって、利用者による無用な再送操作を防ぐことも可能である（例：「３０分ほどお待ち下さい」等）。
【００６４】
他定時トラフィックの影響を受けない（他定時トラフィックに影響を与えない）ようにするには、割り切れない数・素数のタイミングでハートビート通信を行うことが望ましい。
【００６５】
メールサーバ台数が１０を超える場合には、メールサーバのシリアル番号を１０で除した余りの数を、図８に示す表にあてはめることで対応可能である。例えば、１時間間隔の場合、推奨ハートビート通信タイミングは、図８に示すように、メールサーバ番号の下１ケタが「〜〜０」であれば通報時間（毎時）が「１３分」となる。
【００６６】
同様に、下１ケタが「〜〜１」であれば通報時間が「１７分」、下１ケタが「〜〜２」であれば通報時間が「１９分」、下１ケタが「〜〜３」であれば通報時間が「２３分」、下１ケタが「〜〜４」であれば通報時間が「２９分」、下１ケタが「〜〜５」であれば通報時間が「３７分」となる。
【００６７】
さらに、下１ケタが「〜〜６」であれば通報時間が「４３分」、下１ケタが「〜〜７」であれば通報時間が「４７分」、下１ケタが「〜〜８」であれば通報時間が「５３分」、下１ケタが「〜〜９」であれば通報時間が「５９分」となる。
【００６８】
このように、本実施の形態では、各メールサーバ群の管理者がどのメールサーバでメールリレー動作が遅延しているのか情報を取得することが可能となり、故障箇所及び遅延箇所の特定や切り分けに要する時間を短縮することができる。
【００６９】
また、本実施の形態では、利用者に解析した遅延情報を提供し、どう対処すれば良いかを具体的にガイダンス表示による情報提供を行うことによって、利用者の無駄な再送操作を防ぐことができ、無用なトラフィック上昇を防ぐ効果も期待できる。
【００７０】
本発明に関連するメールシステムでは、定期メールを用いる場合、専用のハードウェア＋専用ソフトウェア等の専用プラットフォームが必要であるが、本実施の形態のように、ハートビート機能及び自動解析機能を有するメールサーバ網であれば、汎用ハードウェア＋汎用ソフトとしてシステム構築が可能であり、ハードウェアやプラットフォームＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、及びメールソフトに依存しないシステム構築が可能である。ハートビート機能及び自動解析機能を有するメールサーバ網は、メールプロトコルさえ一致すれば、どのメールシステムにも組み込むことが可能である。
【００７１】
また、定期メールを用いる場合、ノードダウン検知手段が定期メール、ノードダウン情報通知手段もメールであり、メールサーバ自体の不調若しくはウィルスメールによるＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）のメール送受信ポート輻輳状態になると、通知できない、通知が遅延するという問題が内在されている。
【００７２】
しかしながら、本実施の形態のように、ハートビート機能及び自動解析機能を有するメールサーバ網であれば、メールレスポンス異常検出手段を定期メール、メールレスポンスの情報通知手段が解析サーバ（自動解析装置）からＷｅｂ画面として提供されるので、ＴＣＰポートが異なる。このように、異常検出手段と情報通知手段とのＴＣＰポートが異なるため、メールサーバ自体の不調やウィルスメールによるＴＣＰのメール送受信ポート輻輳が発生しても、上記のように通知できないという問題は発生しない。
【００７３】
次に、本発明の第３の実施の形態について説明する。本発明の第３の実施の形態によるメールサーバ網は、図４に示す本発明の第２の実施の形態と同様の構成となっている。以下、この図４を参照して本発明の第３の実施の形態によるメールサーバ網について説明する。
【００７４】
図９は本発明の第３の実施の形態によるメールサーバの構成例を示すブロック図である。図９において、メールサーバ５０は、ＣＰＵ５０１と、ＣＰＵ５０１が実行するプログラム等を記録するＲＯＭ５０２と、ＣＰＵ５０１がプログラム制御によってメール送受信処理及び転送処理を行う際の作業領域とするＲＡＭ５０３と、図示せぬメールクライアントまたは他のメールサーバからのメールを記録するメール記録部５０４と、通信部５０５と、メール送受信部５０６と、メール累積件数計数部５０７と、タイムサーバ３からの時間情報を基に計時を行う計時部５０８とを備えている。尚、他のメールサーバ５１〜５９，６０〜６９，７０〜７９も、このメールサーバ５０と同様の構成となっている。
【００７５】
本実施の形態では、メール累積件数計数部５０７が計数する送受信数が予め設定された一定数を超過した時に定期メールを送信するモデルを対象として説明する。この送受信数の超過によってハートビート動作するモデルとしては、メールサーバのホスト名を通常時において公表する必要が無いサーバ（災害対応用メールサーバ、特定イベント及び特定キャンペーン期間にのみ使用するメールサーバ等）が混在しているメール環境を想定している。
【００７６】
図４にあっては、メールサーバ台数を３０台として記述しているが、メールサーバ台数が増加した場合にあっても本発明の趣旨が損なわれないことは明白である。
【００７７】
図１０は本発明の第３の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。これら図４と図９と図１０とを参照して本発明の第３の実施の形態によるメールサーバ網の動作について説明する。
【００７８】
タイムサーバ３は通信記録内の時間情報について整合性を保つため、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７の各メールサーバ、受信サーバ群４、統計サーバ２、解析サーバ１ａに正確な時間情報を随時提供する（図１０のｃ１）。
【００７９】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７の各メールサーバは、メール累積件数計数部５０７が計数するメール送受信の累積件数が一定数を超過したことを検出した場合（図１０のｃ２）、メール累積件数計数部５０７のメール累積件数をクリアした後（図１０のｃ３）、受信サーバ群４に定期メール（ハートビートメール１０１）を送出する（図１０のｃ４）。
【００８０】
この定期メール通信については、セキュリティ認証（ＰＯＰ Ｂｅｆｏｒｅ ＳＭＴＰ／ＳＭＴＰ Ａｕｔｈ等）を行うことによって、不正パケットによるかく乱を避けることができ、より正確なハートビート通信を行うことが可能となる。
【００８１】
定期メールを受信した受信サーバ群４は統計サーバ２に受信時間とメール経路情報（メールリレー情報）とを通知する（図１０のｃ５）。
【００８２】
統計サーバ２は各メールサーバの通信状況及びメール経路情報を記録し（図１０のｃ６）、記録した通信状況及びメール経路情報の統計処理を行ってメールサーバ管理者用画面を生成した後、解析サーバ１ａとネットワーク・メールサーバ網１００とにメールサーバ管理者用画面のメール通信情報を提供する（図３のステップｃ７）。尚、統計処理としては、下記のメール通信情報の項目を生成できればよい。
【００８３】
この時に提供するメール通信情報としては、次の項目が考えられる。各メールサーバと受信サーバ群４との間でのメール通信情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信に要した時間が長い一定数メールのメールリレー情報
（５）ｘ日間の定期メール通信に要した時間が短い一定数メールのメールリレー情報
（６）ｘ日間の定期メール通信受信失敗率
（７）最終の定期メール受信日時
という７点が考えられる。
【００８４】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７と受信サーバ群４との間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【００８５】
また、メール経路情報については、経路上に存在するサーバ名が全て記録されており、そのまま平文で公開すると全メールサーバ名が漏洩することとなり、セキュリティ上（不正パケットによるかく乱等）の問題が発生する可能性がある。この対策として、サーバ管理者用の画面を表示する際にあっては、ユーザＩＤ及びパスワードによる認証及びＳＳＬ対応ブラウザで表示させる等のセキュリティ対応を行うことが望ましい。
【００８６】
統計サーバ２から各メールサーバのメール通信情報を受け取った解析サーバ１ａは、それらメール通信情報に対して解析処理を行ってメール利用者向けの運用状況画面を生成し、ネットワーク・メールサーバ網１００に提供する（図１０のｃ８）。尚、解析処理としては、下記のメール通信情報の項目を生成できればよい。
【００８７】
この時に提供するメール通信情報としては、次の項目が考えられる。メールサーバと受信サーバとの間の情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信受信失敗率
（５）最終の定期メール受信日時
という５点が考えられる。
【００８８】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７と受信サーバ群４との間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【００８９】
また、本実施の形態では、上記の数値情報に適切な上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合にガイダンス表示を行うことによって、利用者による無用な再送操作を防ぐことも可能である（例えば、「３０分ほどお待ち下さい」等）。
【００９０】
このように、本実施の形態では、メール送受信動作の多いメールサーバだけの統計・解析動作を行うことによって、受信サーバ群４、統計サーバ２、解析サーバ１ａの負荷を減らすことができる。
【００９１】
また、本実施の形態では、メールサーバのホスト名を通常時において公表する必要が無いサーバが存在しているメール環境にあって、公表したくないメールサーバを統計動作対象とせず、サーバ名公開動作をしないことによって、災害対応用メールサーバ、特定イベント及び特定キャンペーン期間にのみ使用するメールサーバ・予備メールサーバ等に対する不正アタックを防ぐことができる。
【００９２】
図１１は本発明の第４の実施の形態によるメールサーバ網の構成例を示すブロック図である。図１１において、本発明の第４の実施の形態によるメールサーバ網は、第１メールサーバ群５ａ、第２メールサーバ群６ａ、第３メールサーバ群７ａのメールサーバ５０ａ〜５９ａ，６０ａ〜６９ａ，７０ａ〜７９ａと受信サーバ群４ａの受信サーバ４１ａ〜４３ａとの間の通信を双方向とした以外は図４に示す本発明の第２の実施の形態と同様の構成となっており、同一構成要素には同一符号を付してある。
【００９３】
図１１を参照すると、本発明の第４の実施の形態では、時間超過で定期メール（ハートビートメール１０１）を送信し、定期メール未着の場合に受信サーバから逆に定期メール（ハートビートメール１０２）を送信するモデルを対象として説明している。図１１にあっては、メールサーバ台数を３０台として説明しているが、メールサーバ台数が増加した場合にあっても本発明の趣旨が損なわれないことは明白である。
【００９４】
図１２は本発明の第４の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。これら図１１及び図１２を参照して本発明の第４の実施の形態によるメールサーバ網の動作について説明する。
【００９５】
タイムサーバ３は通信記録内の時間情報について整合性を保つため、第１メールサーバ群５ａ、第２メールサーバ群６ａ、第３メールサーバ群７ａの各メールサーバ、受信サーバ群４ａの受信サーバ、統計サーバ２、解析サーバ１ａに正確な時間情報を随時提供する（図１２のｄ１）。
【００９６】
第１メールサーバ群５ａ、第２メールサーバ群６ａ、第３メールサーバ群７ａの各メールサーバは、受信サーバ群４ａの受信サーバに一定時間間隔で定期メールを送出する（図１２のｄ２）。
【００９７】
この定期メール通信については、セキュリティ認証（ＰＯＰ Ｂｅｆｏｒｅ ＳＭＴＰ／ＳＭＴＰ Ａｕｔｈ等）を行うことによって、不正パケットによるかく乱を避けることができ、より正確なハートビート通信を行うことが可能となる。
【００９８】
受信サーバ群４ａの受信サーバは定時から３０分（一定時間間隔＝６０分の場合）を経過しても定期メールを受信していない場合、逆に受信サーバ群４ａの受信サーバから第１メールサーバ群５ａ、第２メールサーバ群６ａ、第３メールサーバ群７ａの各メールサーバに定期メールを送信する（図１２のｄ３，ｄ４）。
【００９９】
受信サーバ群４ａの受信サーバは第１メールサーバ群５ａ、第２メールサーバ群６ａ、第３メールサーバ群７ａの各メールサーバに定期メールを送信した後に、ネットワーク・メールサーバ網１００からエラー返信メールを受信すると（図１２のｄ５）、エラーメールのメール経路（メールリレー）情報を記録する（図１２のｄ６）。
【０１００】
定期メールを受信した受信サーバ群４ａの受信サーバは統計サーバ２に受信時間とメール経路情報（メールリレー情報）とを通知する（図１２のｄ７）。
【０１０１】
統計サーバ２は各メールサーバの通信状況及びメール経路情報を記録し（図１２のｄ８）、その記録した通信状況及びメール経路情報に対して統計処理を行ってメールサーバ管理者用画面を生成した後、解析サーバ１ａとネットワーク・メールサーバ網１００とにメールサーバ管理者用画面のメール通信情報を提供する（図１２のｄ９）。尚、統計処理としては、下記のメール通信情報を生成できればよい。
【０１０２】
この時に提供するメール通信情報としては、次の項目が考えられる。各メールサーバと受信サーバ群４ａの受信サーバとの間でのメール通信情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信に要した時間が長い一定数メールのメールリレー情報
（５）ｘ日間の定期メール通信に要した時間が短い一定数メールのメールリレー情報
（６）ｘ日間の定期メール通信受信失敗率
（７）ｘ日間における受信サーバからメールサーバへハートビートメール逆送信時に、ネットワーク・メールサーバ網から返ってきたエラーメールのメール経路（メールリレー）情報
（８）最終の定期メール受信日時
という８点が考えられる。
【０１０３】
第１メールサーバ群５ａ、第２メールサーバ群６ａ、第３メールサーバ群７ａと受信サーバ群４ａとの間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【０１０４】
また、メール経路情報については、経路上に存在するサーバ名が全て記録されており、そのまま平文で公開すると全メールサーバ名が漏洩することとなり、セキュリティ上（不正パケットによるかく乱等）の問題が発生する可能性がある。この対策として、サーバ管理者用の画面を表示する際にあっては、ユーザＩＤ及びパスワードによる認証及びＳＳＬ対応ブラウザで表示させる等のセキュリティ対応を行うことが望ましい。
【０１０５】
統計サーバ２から各メールサーバのメール通信情報を受け取った解析サーバ１ａは、それらのメール通信情報に対して解析処理を行ってメール利用者向けの運用状況画面を生成し、ネットワーク・メールサーバ網１００に提供する（図１２のｄ１０）。尚、解析処理としては、下記のメール通信情報を生成できればよい。
【０１０６】
この時に提供するメール通信情報としては、次の項目が考えられる。メールサーバと受信サーバとの間の情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信受信失敗率
（５）最終の定期メール受信日時
という５点が考えられる。
【０１０７】
第１メールサーバ群５ａ、第２メールサーバ群６ａ、第３メールサーバ群７ａと受信サーバ群４ａとの間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【０１０８】
また、本実施の形態では、上記の数値情報に適切な上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合にガイダンス表示を行うことによって、利用者による無用な再送操作を防ぐことも可能である（例えば、「３０分ほどお待ち下さい」等）。
【０１０９】
他定時トラフィックの影響を受けない（他定時トラフィックに影響を与えない）ようにするには、割り切れない数・素数のタイミングでハートビート通信及びハートビートの逆送信動作を行うことが望ましい。
【０１１０】
メールサーバ台数が１０を超える場合には、メールサーバのシリアル番号を１０で除した余りの数を、図１３に示す表にあてはめることで対応可能である。例えば、１時間間隔の場合、図１３に示すように、メールサーバ番号の下１ケタが「〜〜０」であれば通報時間（毎時）が「１１分」、逆送信のタイミングが「４１分」となる。
【０１１１】
同様に、下１ケタが「〜〜１」であれば通報時間が「１３分」、逆送信のタイミングが「４３分」、下１ケタが「〜〜２」であれば通報時間が「１７分」、逆送信のタイミングが「４７分」、下１ケタが「〜〜３」であれば通報時間が「２３分」、逆送信のタイミングが「５３分」、下１ケタが「〜〜４」であれば通報時間が「２９分」、逆送信のタイミングが「５９分」となる。
【０１１２】
さらに、下１ケタが「〜〜５」であれば通報時間が「４１分」、逆送信のタイミングが「１１分」、下１ケタが「〜〜６」であれば通報時間が「４３分」、逆送信のタイミングが「１３分」、下１ケタが「〜〜７」であれば通報時間が「４７分」、逆送信のタイミングが「１７分」、下１ケタが「〜〜８」であれば通報時間が「５３分」、逆送信のタイミングが「２３分」、下１ケタが「〜〜９」であれば通報時間が「５９分」、逆送信のタイミングが「２９分」となる。
【０１１３】
このように、本実施の形態では、受信サーバからメールサーバへ逆にメール送信を行うことによって、エラーメールのメール経路（メールリレー）情報を記録することができ、メール送受信についての情報が増加し、故障箇所切り分けの分解能を上げることができる。
【０１１４】
図１４は本発明の第５の実施の形態によるメールサーバ網の構成例を示すブロック図である。図１４において、本発明の第５の実施の形態によるメールサーバ網は、第１メールサーバ群５ｂ、第２メールサーバ群６ｂ、第３メールサーバ群７ｂ各々に負荷分散装置８１〜８３を設けた以外は図１１に示す本発明の第４の実施の形態と同様の構成となっており、同一構成要素には同一符号を付してある。
【０１１５】
本発明の第５の実施の形態では、時間超過で定期メール（ハートビートメール１０１）を送信し、定期メール未着の場合に受信サーバから逆に定期メール（ハートビートメール１０２）を送信し、メールサーバ群の負荷分散装置で処理負荷を自動分散するモデルを対象として説明している。図１４にあっては、メールサーバ台数を３０台として説明しているが、メールサーバ台数が増加した場合にあっても本発明の趣旨が損なわれないことは明白である。
【０１１６】
図１５は本発明の第５の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。これら図１４及び図１５を参照して本発明の第５の実施の形態によるメールサーバ網の動作について説明する。
【０１１７】
タイムサーバ３は通信記録内の時間情報について整合性を保つため、第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３、第１メールサーバ群５ｂ、第２メールサーバ群６ｂ、第３メールサーバ群７ｂの各メールサーバ、受信サーバ群４ａの受信サーバ４１ａ〜４３ａ、統計サーバ２、解析サーバ１に正確な時間情報を随時提供する（図１５のステップｅ１）。
【０１１８】
第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３配下の各メールサーバは、受信サーバ群４ａの受信サーバに一定時間間隔で定期メール（ハートビートメール１０１）を送出する（図１５のｅ２）。
【０１１９】
この定期メール通信については、セキュリティ認証（ＰＯＰ Ｂｅｆｏｒｅ ＳＭＴＰ／ＳＭＴＰ Ａｕｔｈ等）を行うことによって、不正パケットによるかく乱を避けることができ、より正確なハートビート通信を行うことが可能となる。
【０１２０】
受信サーバ群４ａの受信サーバは定時から３０分（一定時間間隔＝６０分の場合）を経過しても定期メールを受信していない場合、逆に受信サーバ群４ａの受信サーバから第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３配下の各メールサーバに定期メール（ハートビートメール１０２）を送信する（図１５のｅ３，ｅ４）。
【０１２１】
受信サーバ群４ａの受信サーバは第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３配下の各メールサーバに定期メールを送信した後に、ネットワーク・メールサーバ網１００からエラー返信メールを受信すると（図１５のｅ５）、エラーメールのメール経路（メールリレー）情報を記録する（図１５のｅ６）。
【０１２２】
定期メールを受信した受信サーバ群４ａの受信サーバは統計サーバ２に受信時間とメール経路情報（メールリレー情報）とを通知する（図１５のｅ７）。
【０１２３】
統計サーバ２は各メールサーバの通信状況及びメール経路情報を記録し（図１５のｅ８）、その記録した通信状況及びメール経路情報に対して統計処理を行ってメールサーバ管理者用画面を生成した後、解析サーバ１ａと第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３とネットワーク・メールサーバ網１００とにメールサーバ管理者用画面のメール通信情報を提供する（図１５のｅ９）。尚、統計処理としては、下記のメール通信情報を生成できればよい。
【０１２４】
この時に提供するメール通信情報としては、次の項目が考えられる。各メールサーバと受信サーバとの間でのメール通信情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信に要した時間が長い一定数メールのメールリレー情報
（５）ｘ日間の定期メール通信に要した時間が短い一定数メールのメールリレー情報
（６）ｘ日間の定期メール通信受信失敗率
（７）ｘ日間における受信サーバからメールサーバへハートビートメール逆送信時に、ネットワーク・メールサーバ網から返ってきたエラーメールのメール経路（メールリレー）情報
（８）最終の定期メール受信日時
という８点が考えられる。
【０１２５】
第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３と受信サーバ群４ａとの間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【０１２６】
統計サーバ２から上記のメール通信情報（統計情報）を受信した第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３は、各数値情報に適切な上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合に各メールサーバに対して自動負荷分散動作を行う（図１５のｅ１０）。
【０１２７】
また、メール経路情報については、経路上に存在するサーバ名が全て記録されており、そのまま平文で公開すると全メールサーバ名が漏洩することとなり、セキュリティ上（不正パケットによるかく乱等）の問題が発生する可能性がある。この対策として、サーバ管理者用の画面を表示する際にあっては、ユーザＩＤ及びパスワードによる認証、ＳＳＬ対応ブラウザで表示させる等のセキュリティ対応を行うことが望ましい。
【０１２８】
統計サーバ２から各メールサーバのメール通信情報を受け取った解析サーバ１ａは、それらのメール通信情報に対して解析処理を行ってメール利用者向けの運用状況画面を生成し、ネットワーク・メールサーバ網１００に提供する（図１５のｅ１１）。尚、解析処理としては、下記のメール通信情報を生成できればよい。
【０１２９】
この時に提供するメール通信情報としては、次の項目が考えられる。メールサーバと受信サーバとの間の情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信受信失敗率
（５）最終の定期メール受信日時
という５点が考えられる。
【０１３０】
第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３と受信サーバ群４ａの受信サーバ４１ａ〜４３ａとの間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【０１３１】
また、本実施の形態では、上記数値情報に適切な上限しきい値・下限しきい値を設け、それぞれの値を超えた場合にガイダンス表示を行うことによって、利用者による無用な再送操作を防ぐことも可能である（例えば、「３０分ほどお待ち下さい」等）。
【０１３２】
他定時トラフィックの影響を受けない（他定時トラフィックに影響を与えない）ようにするには、割り切れない数・素数のタイミングでハートビート通信及びハートビートの逆送信動作を行うことが望ましい。
【０１３３】
メールサーバ台数が１０を超える場合には、メールサーバのシリアル番号を１０で除した余りの数を、図１３に示す表にあてはめることで対応可能である。例えば、１時間間隔の場合、図１３に示すように、メールサーバ番号の下１ケタが「〜〜０」であれば通報時間（毎時）が「１１分」、逆送信のタイミングが「４１分」となる。
【０１３４】
同様に、下１ケタが「〜〜１」であれば通報時間が「１３分」、逆送信のタイミングが「４３分」、下１ケタが「〜〜２」であれば通報時間が「１７分」、逆送信のタイミングが「４７分」、下１ケタが「〜〜３」であれば通報時間が「２３分」、逆送信のタイミングが「５３分」、下１ケタが「〜〜４」であれば通報時間が「２９分」、逆送信のタイミングが「５９分」となる。
【０１３５】
さらに、下１ケタが「〜〜５」であれば通報時間が「４１分」、逆送信のタイミングが「１１分」、下１ケタが「〜〜６」であれば通報時間が「４３分」、逆送信のタイミングが「１３分」、下１ケタが「〜〜７」であれば通報時間が「４７分」、逆送信のタイミングが「１７分」、下１ケタが「〜〜８」であれば通報時間が「５３分」、逆送信のタイミングが「２３分」、下１ケタが「〜〜９」であれば通報時間が「５９分」、逆送信のタイミングが「２９分」となる。
【０１３６】
このように、本実施の形態では、統計サーバのメール送受信遅延情報をメールサーバ管理者が参照することで、負荷分散装置が適切な分散処理を行っているかをメール送受信情報ベースで確認することができる。
【０１３７】
また、本発明に関連する負荷分散装置にあっては、個々のメールサーバのＣＰＵ負荷率・ハードディスク空き容量のみを判定し、負荷分散を行う装置が多いため、個々のメールサーバのＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）ポート不調やハードディスク不調・スイッチングハブ不調等によるメール送受信不調についてはコントロールしきれない場合が多くある。
【０１３８】
本発明では、上記の対策として定期メールによる自動負荷判定を行っており、上記のトラブルが発生した場合にあっても、正確な負荷コントロール動作を行うことが期待できる。
【０１３９】
さらに、本発明では、メールサーバの負荷がしきい値をオーバしていることを検知している間、メールクライアント（図示せず）にて直前に送信した同じ宛先へのメール再送信を抑止し、直前に送信した添付ファイル容量と同じ添付ファイル容量のメール再送信を抑止する機能を付加することによって、不要なトラフィック上昇を防ぐことができる。この抑止動作については、メールサーバで行ってもよい。また、大量に宛先指定がある等によって判定が難しい場合には、同じサブジェクト（Ｓｕｂｊｅｃｔ）での判定も考えられる。
【０１４０】
さらにまた、本発明では、しきい値を超える宛先の数及び一定容量を超える添付ファイル、もしくは宛先数と添付ファイル容量とを乗じた値が一定量を超える場合に、メールサーバの過負荷が検出された時に、メールクライアントにて警告／送信禁止メッセージを表示させることも可能である。尚、メールサーバの過負荷を最短時間で解消するには、メールクライアントにて、メールサーバの過負荷が検出されている間、一切の送受信を禁止するように、送受信警告もしくは送受信禁止メッセージを指示することが有効である。
【０１４１】
本発明では、受信サーバ群４，４ａ内の受信サーバ４１〜４３，４１ａ〜４３ａをそれぞれ任意のインタネットサービスプロバイダに配置し、各メールサーバ群５〜７，５ａ〜７ａ，５ｂ〜７ｂのメールサーバからハートビートメール１０１を受信サーバ４１，４１ａ、受信サーバ４２，４２ａ、受信サーバ４３，４３ａの順に送信することで、どのインタネットサービスプロバイダの不調でメール遅延が発生しているかの切り分けを容易にすることが可能である。
【０１４２】
また、本発明では、解析サーバ１，１ａ及び統計サーバ２のＷｅｂ掲載情報として、インタネットサービスプロバイダのメールサーバの管理者や各企業のメールサーバの管理者からの書込みを許可し、「〜時〜分からメール遅延発生」、「〜時 〜交換予定」、「〜時〜分頃復旧予定」、「〜時〜分（〜交換により）復旧致しました」等のトラブル経過情報と、それぞれのメールサーバ管理者への連絡先と、インタネットサービスプロバイダのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）とを掲載することによって、トラブル発生時の連絡をよりスムーズにし、メールサービス品質の向上を期待することができる。
【０１４３】
通常のメールサーバ機能にあっては、外部ネットワーク側で送受信されるメールアドレスが不定であり、不要な通信を避けるために特定のコンピュータ以外からのメール通信をフィルタする場合がある。メールクライアントとの通信に用いられる内部ネットワーク側についても、メールアカウントが複数あることから、メールサーバの設定については、複雑となることが多い。本発明によれば、負荷状況判定対象となるサーバから、外部ネットワーク側に送受信されるメールアドレスが固定であり、内部ネットワーク側のメールアドレスが単一であることから、メールサーバの設定が非常に簡単となる。
【０１４４】
また、内部ネットワーク側のメールアカウントが同じサーバ内にある必要は必ずしもなく、図１と図４と図１１と図１４とにそれぞれ示すメールサーバを、メールサーバと同じネットワーク上にあるＡＰ（アプリケーション）サーバやＤＢ（データベース）サーバ、及びＤＮＳ（ドメインネームシステム）等の汎用サーバ（図示せず）とした場合にあっても、それぞれの汎用サーバにメールアドレスを割り当てることで、レスポンス低下／スループット低下を検出することが可能となる。
【産業上の利用可能性】
【０１４５】
本発明は、インタネットサービスプロバイダ及び企業内メールサーバ等に適用することが可能であり、それらインタネットサービスプロバイダ及び企業内メールサーバ等におけるメールサービス品質の向上が期待できる。
【図面の簡単な説明】
【０１４６】
【図１】本発明の第１の実施の形態によるメールサーバ網の構成例を示すブロック図である。
【図２】図１の解析サーバの構成例を示すブロック図である。
【図３】本発明の第１の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。
【図４】本発明の第２の実施の形態によるメールサーバ網の構成例を示すブロック図である。
【図５】図４の解析サーバの構成例を示すブロック図である。
【図６】図４の統計サーバの構成例を示すブロック図である。
【図７】本発明の第２の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。
【図８】本発明の第２の実施の形態における推奨定期メール通信タイミングを示す図である。
【図９】本発明の第３の実施の形態によるメールサーバの構成例を示すブロック図である。
【図１０】本発明の第３の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。
【図１１】本発明の第４の実施の形態によるメールサーバ網の構成例を示すブロック図である。
【図１２】本発明の第４の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。
【図１３】本発明の第４の実施の形態における推奨定期メール通信タイミング及び逆送信タイミングを示す図である。
【図１４】本発明の第５の実施の形態によるメールサーバ網の構成例を示すブロック図である。
【図１５】本発明の第５の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。
【符号の説明】
【０１４７】
１，１ａ 解析サーバ
２ 統計サーバ
３ タイムサーバ
４，４ａ 受信サーバ群
５，５ａ，５ｂ 第１メールサーバ群
６，６ａ，６ｂ 第２メールサーバ群
７，７ａ，７ｂ 第３メールサーバ群
１１，２１，５０１ ＣＰＵ
１２，２２，５０２ ＲＯＭ
１３，２３，５０３ ＲＡＭ
１４ メール利用者向け画面生成部
１５，２５，５０５ 通信部
１６，２６ 記録部
１６ａ 保持部
１７，２７，５０８ 計時部
１８，２４ メールサーバ管理者用画面生成部
４１，４１ａ 第１受信サーバ
４２，４２ａ 第２受信サーバ
４３，４３ａ 第３受信サーバ
５０〜５９，５０ａ〜５９ａ，
５０ｂ〜５９ｂ，
６０〜６９，６０ａ〜６９ａ，
６０ｂ〜６９ｂ，
７０〜７９，７０ａ〜７９ａ，
７０ｂ〜７９ｂ メールサーバ
８１〜８３ 負荷分散装置
１００ ネットワーク・メールサーバ網
１０１，１０２ ハートビートメール
１６１，２６１ 通信状況・メール経路情報
５０４ メール記録部
５０６ メール送受信部
５０７ メール累積件数計数部
【技術分野】
【０００１】
本発明はメールサーバ網、サーバ装置、メールシステム及びそれらに用いる障害箇所調査方法に関し、特にメールサーバにハートビート機能を持ち、ハートビートメールの自動解析を行う解析サーバを含むメールサーバ網における故障箇所や遅延箇所等の障害箇所の切り分け方法に関する。
【背景技術】
【０００２】
本発明に関連するメールシステムでは、メール未着やメール遅延が発生した際、自局及び相手局の管理者が故障箇所や遅延箇所の切り分けを行うが、各メールサーバ、各ネットワーク制御サーバ、ネットワーク網の調査や切り分けを行う必要があり、原因究明や復旧に時間を要している。
【０００３】
また、上記のメールシステムでは、相手局の設定ミス、相手局のメールサーバ不調が原因である場合、自局単独でのテストを行っても事象が再現する可能性が低く、機器の間欠故障によるトラブル時にあっても再現性があまり無いことから、切り分けに時間を要し、長時間不調状態が続く場合が多い。
【０００４】
メールサーバ網としては、メールサーバにハートビート機能を備えることで、メールサーバにおける故障等を監視するシステムがある。ここで、ハートビート機能は、一定期間毎に定期メールを送信することで自装置が動作していることを通知する機能であり、解析サーバはハートビート機能によって送られてくる定期メールの有無に基づいて各メールサーバが動作可能かどうかの確認を行っている。
【０００５】
本発明に関連するメールシステムとしては、エラー情報を故障解析センタに送信するシステムにおいて、エラーが発生しても、あるいはエラーが発生していなくともエラー情報を定期メールで故障解析センタに送信する装置が提案されている（例えば、特許文献１参照）。
【０００６】
また、本発明に関連する他のメールシステムとしては、各メールサーバ間の通信量の総数を比較して、通信量の偏っているメールサーバがある場合に、負荷を軽減するユーザポストの配置を立案表示する装置が提案されている（例えば、特許文献２参照）。
【０００７】
さらに、本発明に関連する別のメールシステムとしては、問い合わせ条件として設定された期限までに指定相手先から電子メールが届かないことを検出した場合、予め登録しておいた関係者に対して問い合わせの電子メールを自動送信する装置が提案されている（例えば、特許文献３参照）。
【０００８】
【特許文献１】特開２００１−１６６８２０号公報
【特許文献２】特開平０８−２３７２９６号公報
【特許文献３】特開２００５−３４６１２１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
上述した本発明に関連するメールシステムでは、メール未着やメール遅延発生時にどのメールサーバで遅延が発生しているのか、ネットワーク網の異常によって発生しているのかを利用者が知ることは困難である。
【００１０】
メール未着やメール遅延発生時には、利用者サイドとしてはひたすら待つか、メールの再送信操作によって再送処理を行うしかないが、利用者がメールの再送信を行うことはトラフィックをさらに倍増させることになり、リトライ方法としては適した方法ではない。
【００１１】
また、上記のハートビート機能を備えた装置としては、製品として市販されているが、これらは専用のハードウェアやソフトウェアで構成されており、専用プラットフォームが必須である。
【００１２】
さらに、上記の特許文献１に記載の技術では、エラー情報を定期メール（ハートビートメール）を用いて送信しているが、メールサーバ自体が不調となった場合に、その定期メールの未着や遅延が発生しても、それらメール未着やメール遅延発生時の対策は何ら考慮されていないという問題が内在する。
【００１３】
したがって、上述した本発明に関連するメールシステムでは、メールサーバのトラブル、メールネットワークの制御装置［ハブ（ＨＵＢ）、Ｌｘ（レイヤｘ）スイッチ、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）］の不調等の場合、管理者が切り分けに時間を要することとなる。上記の特許文献１〜３でも、メール未着やメール遅延発生時の対策は何ら考慮されていないため、上記と同様の課題がある。
【００１４】
Ｗｅｂサーバでは、３秒ルールやｘ秒ルールというのがあり、サービスレベルの要件（ＳＬＡ：Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）として制定される場合もあるが、メールサービスでのサービスレベルの基準はあいまいなケースが多く、現在どのくらいのレスポンスなのか、利用者は把握することができない、管理者にあっても容易に把握することはできない。
【００１５】
そこで、本発明の目的は上記の問題点を解消し、故障箇所や遅延箇所の特定及び切り分けに要する時間を短縮することができるメールサーバ網、サーバ装置、メールシステム及びそれらに用いる障害箇所調査方法を提供することにある。
【課題を解決するための手段】
【００１６】
本発明によるメールサーバ網は、複数のメールサーバと、前記複数のメールサーバから一定時間間隔で、もしくは予め設定された所定条件が検出された時に送出される定期メールを受信する受信サーバと、前記受信サーバで受信した前記定期メールの解析を行う解析サーバとを含むメールサーバ網であって、
前記受信サーバで受信した前記定期メールの受信時間及びメール経路の情報を記録する記録手段と、前記記録手段に記録された情報の統計処理を行う統計手段とを備え、
前記解析サーバは、前記統計処理の結果を基に前記メールサーバにおけるメール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報を作成している。
【００１７】
本発明によるサーバ装置は、上記のメールサーバ網に記載の手段を含むことを特徴とする。
【００１８】
本発明によるメールシステムは、上記のサーバ装置を含み、
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合にメールクライアントにて送信するメールが一つ前に送信したメールと同じ宛先か否かを判定し、
前記メールクライアントにて送信するメールが同じ宛先へ送信する場合に再送信警告もしくは再送信禁止メッセージを提示している。
【００１９】
本発明による第１の障害箇所調査方法は、複数のメールサーバと、前記複数のメールサーバから一定時間間隔で、もしくは予め設定された所定条件が検出された時に送出される定期メールを受信する受信サーバと、前記受信サーバで受信した前記定期メールの解析を行う解析サーバとを含むメールサーバ網に用いる障害箇所調査方法であって、
前記解析サーバが、前記受信サーバで受信した前記定期メールの受信時間及びメール経路の情報を記録手段に記録する第１の処理と、前記記録手段に記録された情報の統計処理を行う第２の処理とを実行し、
前記解析サーバが、前記統計処理の結果を基に前記メールサーバにおけるメール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報を作成している。
【００２０】
本発明による第２の障害箇所調査方法は、複数のメールサーバと、前記複数のメールサーバから一定時間間隔で送出される定期メールを受信する受信サーバと、前記受信サーバで受信した前記定期メールの解析を行う解析サーバとを含むメールサーバ網に用いる障害箇所調査方法であって、
前記受信サーバと前記解析サーバとの間に配設した統計サーバが、前記受信サーバで受信した前記定期メールの受信時間及びメール経路の情報を記録手段に記録する第１の処理と、前記記録手段に記録された情報の統計処理を行う第２の処理とを実行し、
前記解析サーバが、前記統計処理の結果を基に前記メールサーバにおけるメール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報を作成している。
【発明の効果】
【００２１】
本発明は、上記のような構成及び動作とすることで、故障箇所や遅延箇所の特定及び切り分けに要する時間を短縮することができるという効果が得られる。
【発明を実施するための最良の形態】
【００２２】
次に、本発明の実施の形態について図面を参照して説明する。図１は本発明の第１の実施の形態によるメールサーバ網の構成例を示すブロック図である。図１において、本発明の第１の実施の形態によるメールサーバ網は、解析サーバ１と、タイムサーバ３と、受信サーバ群４と、第１メールサーバ群５と、第２メールサーバ群６と、第３メールサーバ群７と、ネットワーク・メールサーバ網１００とを含んで構成されている。
【００２３】
第１メールサーバ群５は各々ハートビート機能を持つメールサーバ５０〜５９からなり、第２メールサーバ群６は各々ハートビート機能を持つメールサーバ６０〜６９からなり、第３メールサーバ群７は各々ハートビート機能を持つメールサーバ７０〜７９からなっている。これら第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７は、それぞれネットワーク・メールサーバ網１００に接続されている。
【００２４】
ここで、上記のハートビート機能から送信されるハートビートメール１０１とは、メールサーバから一定時間間隔で受信サーバ群４に送出されるメール、メールサーバにて予め設定された所定条件（例えば、メールサーバでの送受信メール数が予め設定された一定数を超えた等）が検出された時に受信サーバ群４に送出されるメール、これらのメールに対して受信サーバ群４からメールサーバに送出されるメール等である。
【００２５】
受信サーバ群４は各々ネットワーク・メールサーバ網１００に接続される第１受信サーバ４１、第２受信サーバ４２、第３受信サーバ４３から構成され、１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバ５０〜５９，６０〜６９，７０〜７９から定期メール（ハートビートメール１０１）を受信する。
【００２６】
解析サーバ１は、プログラム制御によって動作し、受信サーバ群４の第１受信サーバ４１、第２受信サーバ４２、第３受信サーバ４３各々から受取った定期メールの情報を蓄積して統計処理を施すとともに、その定期メールの情報及び統計処理の結果を解析する自動解析機能を有する。タイムサーバ３は、解析サーバ１、受信サーバ群４、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７にそれぞれ時間情報を提供する。
【００２７】
本実施の形態では、上記のような構成とすることで、ハートビート機能及び自動解析機能を有するネットワーク・メールサーバ網１００において、メール未着やメール遅延発生時におけるメールサーバ故障箇所・ネットワーク網異常箇所について、切り分け作業を迅速かつ容易にすることを特徴とする。
【００２８】
また、本実施の形態では、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７から定期メールを定期的に受信サーバ群４に送ることによって、解析サーバ１においてメール遅延・メール未着問題を解決するのに必要な情報（メール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報）を作成し、メールサーバ管理者及びメール利用者に提供している。
【００２９】
図２は図１の解析サーバ１の構成例を示すブロック図である。図２において、解析サーバ１は、ＣＰＵ（中央処理装置）１１と、ＣＰＵ１１が実行するプログラム等を記録するＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２と、ＣＰＵ１１がプログラム制御によって上記の統計処理及び解析処理を行う際の作業領域とするＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３と、メール利用者向け画面生成部１４と、通信部１５と、通信状況・メール経路情報１６１を記録する記録部１６と、タイムサーバ３からの時間情報を基に計時を行う計時部１７と、メールサーバ管理者用画面生成部１８とを備えている。
【００３０】
図３は本発明の第１の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。これら図１〜図３を参照して本発明の第１の実施の形態の動作について詳細に説明する。この動作例は、時間超過で定期メールを送信するモデルを対象として記述している。また、図１にあっては、メールサーバ台数を３０台として記述してあるが、メールサーバ台数が増加した場合にあっても本発明の趣旨が損なわれないことは明白である。
【００３１】
タイムサーバ３は、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバ、受信サーバ群４の受信サーバ、解析サーバ１の間で授受される通信記録内の時間情報について整合性を保つため、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバ、受信サーバ群４の受信サーバ、解析サーバ１にそれぞれ正確な時間情報を随時提供する（図３のａ１）。
【００３２】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバは、受信サーバ群４の受信サーバに一定時間間隔で定期メールを送出する（図３のａ２）。尚、図３では一つのメールサーバのみを図示しているが、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７のメールサーバ５０〜５９，６０〜６９，７０〜７９各々もこのメールサーバと同様の動作を行う。
【００３３】
この定期メール通信については、ＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ） Ｂｅｆｏｒｅ ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）／ＳＭＴＰ Ａｕｔｈ（Ａｕｔｈｅｎｒｉｃａｔｉｏｎ）等のセキュリティ認証を行うことによって、不正パケットによるかく乱を避けることができ、より正確なハートビート通信を行うことが可能となる。
【００３４】
定期メールを受信した受信サーバ群４の受信サーバは解析サーバ１に受信時間とメール経路情報（メールリレー情報）とを通知する（図３のａ３）。
【００３５】
解析サーバ１は各メールサーバの通信状況及びメール経路情報を記録し（図３のａ４）、その記録した通信状況及びメール経路情報に対してメールサーバ管理者用画面生成部１８にて統計処理を行ってメールサーバ管理者用画面を生成した後、ネットワーク・メールサーバ網１００にメールサーバ管理者用画面のメール通信情報を提供する（図３のａ５）。尚、統計処理としては、後述するメール通信情報の項目を生成できればよい。
【００３６】
提供するメール通信情報としては、次の項目が考えられる。つまり、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７の各メールサーバと受信サーバ群４の受信サーバとの間でのメール通信情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信に要した時間が長い一定数メールのメールリレー情報
（５）ｘ日間の定期メール通信に要した時間が短い一定数メールのメールリレー情報
（６）ｘ日間の定期メール通信受信失敗率
（７）最終の定期メール受信日時
という７点が考えられる。
【００３７】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７と受信サーバ群４との間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【００３８】
また、メール経路情報については、経路上に存在するサーバ名が全て記録されており、そのまま平文で公開すると、全てのメールサーバ名が漏洩することとなり、セキュリティ上（不正パケットによるかく乱等）の問題が発生する可能性がある。この対策として、サーバ管理者用の画面を表示する際にあっては、ユーザＩＤ及びパスワードによる認証及びＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）対応ブラウザで表示させる等のセキュリティ対応を行うことが望ましい。
【００３９】
解析サーバ１は、上記の各メールサーバの通信状況及びメール経路情報に対してメール利用者向け画面生成部１４にて解析処理を行ってメール利用者向けの運用状況画面を生成した後、ネットワーク・メールサーバ網１００にメール利用者向けの運用状況画面のメール通信情報を提供する（図３のａ６）。尚、解析処理としては、下記のメール通信情報を生成できればよい。
【００４０】
提供するメール通信情報としては、次の項目が考えられる。メールサーバと受信サーバとの間の情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信受信失敗率
（５）最終の定期メール受信日時
という５点が考えられる。
【００４１】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７と受信サーバ群４との間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【００４２】
また、上記の数値情報に適切な上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合にガイダンス表示を行うことによって、利用者による無用な再送操作を防ぐことも可能である（例：「３０分ほどお待ち下さい」等）。
【００４３】
このように、本実施の形態では、各メールサーバ群の管理者がどのメールサーバでメールリレー動作が遅延しているかどうかの情報を取得することが可能となり、故障箇所及び遅延箇所の特定や切り分けに要する時間を短縮することができる。
【００４４】
また、本実施の形態では、利用者に対して解析した遅延情報を提供し、どう対処すれば良いかを具体的にガイダンス表示による情報提供を行うことによって、利用者の無駄な再送操作を防ぐことができ、無用なトラフィック上昇を防ぐ効果も期待できる。
【００４５】
図４は本発明の第２の実施の形態によるメールサーバ網の構成例を示すブロック図である。図４において、本発明の第２の実施の形態によるメールサーバ網は、解析サーバ１ａと、統計サーバ２と、タイムサーバ３と、受信サーバ群４と、第１メールサーバ群５と、第２メールサーバ群６と、第３メールサーバ群７と、ネットワーク・メールサーバ網１００とを含んで構成されている。
【００４６】
第１メールサーバ群５は各々ハートビート機能を持つメールサーバ５０〜５９からなり、第２メールサーバ群６は各々ハートビート機能を持つメールサーバ６０〜６９からなり、第３メールサーバ群７は各々ハートビート機能を持つメールサーバ７０〜７９からなっている。これら第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７は、それぞれネットワーク・メールサーバ網１００に接続されている。上記のハートビート機能からは、上述したハートビートメール１０１が送出される。
【００４７】
受信サーバ群４は各々ネットワーク・メールサーバ網１００に接続される第１受信サーバ４１、第２受信サーバ４２、第３受信サーバ４３から構成され、１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバ５０〜５９，６０〜６９，７０〜７９から定期メール（ハートビートメール１０１）を受信する。
【００４８】
統計サーバ２は、プログラム制御によって動作し、受信サーバ群４の第１受信サーバ４１、第２受信サーバ４２、第３受信サーバ４３各々から受取った定期メールの情報を蓄積して統計処理を施すとともに、解析サーバ１ａは、プログラム制御によって動作し、その定期メールの情報及び統計処理の結果を解析する自動解析機能を有する。タイムサーバ３は、解析サーバ１ａ、統計サーバ２、受信サーバ群４、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７にそれぞれ時間情報及びメール経路情報を提供する。
【００４９】
図５は図４の解析サーバ１ａの構成例を示すブロック図である。図５において、解析サーバ１ａは、ＣＰＵ１１と、ＣＰＵ１１が実行するプログラム等を記録するＲＯＭ１２と、ＣＰＵ１１がプログラム制御によって上記の解析処理を行う際の作業領域とするＲＡＭ１３と、メール利用者向け画面生成部１４と、通信部１５と、通信状況・メール経路情報１６１を保持する保持部１６ａと、タイムサーバ３からの時間情報を基に計時を行う計時部１７とを備えている。
【００５０】
図６は図４の統計サーバ２の構成例を示すブロック図である。図６において、統計サーバ２は、ＣＰＵ２１と、ＣＰＵ２１が実行するプログラム等を記録するＲＯＭ２２と、ＣＰＵ２１がプログラム制御によって上記の統計処理を行う際の作業領域とするＲＡＭ２３と、メールサーバ管理者用画面生成部２４と、通信部２５と、通信状況・メール経路情報２６１を記録する記録部２６と、タイムサーバ３からの時間情報を基に計時を行う計時部２７とを備えている。
【００５１】
図７は本発明の第２の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。これら図４〜図７を参照して本発明の第２の実施の形態の動作について詳細に説明する。この動作例は、時間超過で定期メールを送信するモデルを対象として記述している。また、図１にあっては、メールサーバ台数を３０台として記述してあるが、メールサーバ台数が増加した場合にあっても本発明の趣旨が損なわれないことは明白である。
【００５２】
タイムサーバ３は、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバ、受信サーバ群４の受信サーバ、統計サーバ２、解析サーバ１ａの間で授受される通信記録内の時間情報について整合性を保つため、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバ、受信サーバ群４の受信サーバ、統計サーバ２、解析サーバ１ａにそれぞれ正確な時間情報を随時提供する（図７のｂ１）。
【００５３】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７各々のメールサーバは、受信サーバ群４の受信サーバに一定時間間隔で定期メールを送出する（図７のｂ２）。尚、図７では一つのメールサーバのみを図示しているが、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７のメールサーバ５０〜５９，６０〜６９，７０〜７９各々もこのメールサーバと同様の動作を行う。
【００５４】
この定期メール通信については、ＰＯＰ Ｂｅｆｏｒｅ ＳＭＴＰ／ＳＭＴＰ Ａｕｔｈ等のセキュリティ認証を行うことによって、不正パケットによるかく乱を避けることができ、より正確なハートビート通信を行うことが可能となる。
【００５５】
定期メールを受信した受信サーバ群４の受信サーバは統計サーバ２に受信時間とメール経路情報（メールリレー情報）とを通知する（図７のｂ３）。
【００５６】
統計サーバ２は各メールサーバの通信状況及びメール経路情報を記録し（図７のｂ４）、その記録した通信状況及びメール経路情報に対してメールサーバ管理者用画面生成部２４にて統計処理を行ってメールサーバ管理者用画面を生成した後、解析サーバ１ａとネットワーク・メールサーバ網１００とにメールサーバ管理者用画面のメール通信情報を提供する（図７のｂ５）。尚、統計処理としては、下記のメール通信情報の項目を生成できればよい。
【００５７】
この時に提供するメール通信情報としては、次の項目が考えられる。つまり、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７の各メールサーバと受信サーバ群４の受信サーバとの間でのメール通信情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信に要した時間が長い一定数メールのメールリレー情報
（５）ｘ日間の定期メール通信に要した時間が短い一定数メールのメールリレー情報
（６）ｘ日間の定期メール通信受信失敗率
（７）最終の定期メール受信日時
という７点が考えられる。
【００５８】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７と受信サーバ群４との間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【００５９】
また、メール経路情報については、経路上に存在するサーバ名が全て記録されており、そのまま平文で公開すると、全てのメールサーバ名が漏洩することとなり、セキュリティ上（不正パケットによるかく乱等）の問題が発生する可能性がある。この対策として、サーバ管理者用の画面を表示する際にあっては、ユーザＩＤ及びパスワードによる認証及びＳＳＬ対応ブラウザで表示させる等のセキュリティ対応を行うことが望ましい。
【００６０】
解析サーバ１ａは、上記の各メールサーバの通信状況及びメール経路情報に対してメール利用者向け画面生成部１４にて解析処理を行ってメール利用者向けの運用状況画面を生成した後、ネットワーク・メールサーバ網１００にメール利用者向けの運用状況画面のメール通信情報を提供する（図７のｂ６）。尚、解析処理としては、下記のメール通信情報を生成できればよい。
【００６１】
この時に提供するメール通信情報としては、次の項目が考えられる。メールサーバと受信サーバとの間の情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信受信失敗率
（５）最終の定期メール受信日時
という５点が考えられる。
【００６２】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７と受信サーバ群４との間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【００６３】
また、上記の数値情報に適切な上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合にガイダンス表示を行うことによって、利用者による無用な再送操作を防ぐことも可能である（例：「３０分ほどお待ち下さい」等）。
【００６４】
他定時トラフィックの影響を受けない（他定時トラフィックに影響を与えない）ようにするには、割り切れない数・素数のタイミングでハートビート通信を行うことが望ましい。
【００６５】
メールサーバ台数が１０を超える場合には、メールサーバのシリアル番号を１０で除した余りの数を、図８に示す表にあてはめることで対応可能である。例えば、１時間間隔の場合、推奨ハートビート通信タイミングは、図８に示すように、メールサーバ番号の下１ケタが「〜〜０」であれば通報時間（毎時）が「１３分」となる。
【００６６】
同様に、下１ケタが「〜〜１」であれば通報時間が「１７分」、下１ケタが「〜〜２」であれば通報時間が「１９分」、下１ケタが「〜〜３」であれば通報時間が「２３分」、下１ケタが「〜〜４」であれば通報時間が「２９分」、下１ケタが「〜〜５」であれば通報時間が「３７分」となる。
【００６７】
さらに、下１ケタが「〜〜６」であれば通報時間が「４３分」、下１ケタが「〜〜７」であれば通報時間が「４７分」、下１ケタが「〜〜８」であれば通報時間が「５３分」、下１ケタが「〜〜９」であれば通報時間が「５９分」となる。
【００６８】
このように、本実施の形態では、各メールサーバ群の管理者がどのメールサーバでメールリレー動作が遅延しているのか情報を取得することが可能となり、故障箇所及び遅延箇所の特定や切り分けに要する時間を短縮することができる。
【００６９】
また、本実施の形態では、利用者に解析した遅延情報を提供し、どう対処すれば良いかを具体的にガイダンス表示による情報提供を行うことによって、利用者の無駄な再送操作を防ぐことができ、無用なトラフィック上昇を防ぐ効果も期待できる。
【００７０】
本発明に関連するメールシステムでは、定期メールを用いる場合、専用のハードウェア＋専用ソフトウェア等の専用プラットフォームが必要であるが、本実施の形態のように、ハートビート機能及び自動解析機能を有するメールサーバ網であれば、汎用ハードウェア＋汎用ソフトとしてシステム構築が可能であり、ハードウェアやプラットフォームＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、及びメールソフトに依存しないシステム構築が可能である。ハートビート機能及び自動解析機能を有するメールサーバ網は、メールプロトコルさえ一致すれば、どのメールシステムにも組み込むことが可能である。
【００７１】
また、定期メールを用いる場合、ノードダウン検知手段が定期メール、ノードダウン情報通知手段もメールであり、メールサーバ自体の不調若しくはウィルスメールによるＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）のメール送受信ポート輻輳状態になると、通知できない、通知が遅延するという問題が内在されている。
【００７２】
しかしながら、本実施の形態のように、ハートビート機能及び自動解析機能を有するメールサーバ網であれば、メールレスポンス異常検出手段を定期メール、メールレスポンスの情報通知手段が解析サーバ（自動解析装置）からＷｅｂ画面として提供されるので、ＴＣＰポートが異なる。このように、異常検出手段と情報通知手段とのＴＣＰポートが異なるため、メールサーバ自体の不調やウィルスメールによるＴＣＰのメール送受信ポート輻輳が発生しても、上記のように通知できないという問題は発生しない。
【００７３】
次に、本発明の第３の実施の形態について説明する。本発明の第３の実施の形態によるメールサーバ網は、図４に示す本発明の第２の実施の形態と同様の構成となっている。以下、この図４を参照して本発明の第３の実施の形態によるメールサーバ網について説明する。
【００７４】
図９は本発明の第３の実施の形態によるメールサーバの構成例を示すブロック図である。図９において、メールサーバ５０は、ＣＰＵ５０１と、ＣＰＵ５０１が実行するプログラム等を記録するＲＯＭ５０２と、ＣＰＵ５０１がプログラム制御によってメール送受信処理及び転送処理を行う際の作業領域とするＲＡＭ５０３と、図示せぬメールクライアントまたは他のメールサーバからのメールを記録するメール記録部５０４と、通信部５０５と、メール送受信部５０６と、メール累積件数計数部５０７と、タイムサーバ３からの時間情報を基に計時を行う計時部５０８とを備えている。尚、他のメールサーバ５１〜５９，６０〜６９，７０〜７９も、このメールサーバ５０と同様の構成となっている。
【００７５】
本実施の形態では、メール累積件数計数部５０７が計数する送受信数が予め設定された一定数を超過した時に定期メールを送信するモデルを対象として説明する。この送受信数の超過によってハートビート動作するモデルとしては、メールサーバのホスト名を通常時において公表する必要が無いサーバ（災害対応用メールサーバ、特定イベント及び特定キャンペーン期間にのみ使用するメールサーバ等）が混在しているメール環境を想定している。
【００７６】
図４にあっては、メールサーバ台数を３０台として記述しているが、メールサーバ台数が増加した場合にあっても本発明の趣旨が損なわれないことは明白である。
【００７７】
図１０は本発明の第３の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。これら図４と図９と図１０とを参照して本発明の第３の実施の形態によるメールサーバ網の動作について説明する。
【００７８】
タイムサーバ３は通信記録内の時間情報について整合性を保つため、第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７の各メールサーバ、受信サーバ群４、統計サーバ２、解析サーバ１ａに正確な時間情報を随時提供する（図１０のｃ１）。
【００７９】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７の各メールサーバは、メール累積件数計数部５０７が計数するメール送受信の累積件数が一定数を超過したことを検出した場合（図１０のｃ２）、メール累積件数計数部５０７のメール累積件数をクリアした後（図１０のｃ３）、受信サーバ群４に定期メール（ハートビートメール１０１）を送出する（図１０のｃ４）。
【００８０】
この定期メール通信については、セキュリティ認証（ＰＯＰ Ｂｅｆｏｒｅ ＳＭＴＰ／ＳＭＴＰ Ａｕｔｈ等）を行うことによって、不正パケットによるかく乱を避けることができ、より正確なハートビート通信を行うことが可能となる。
【００８１】
定期メールを受信した受信サーバ群４は統計サーバ２に受信時間とメール経路情報（メールリレー情報）とを通知する（図１０のｃ５）。
【００８２】
統計サーバ２は各メールサーバの通信状況及びメール経路情報を記録し（図１０のｃ６）、記録した通信状況及びメール経路情報の統計処理を行ってメールサーバ管理者用画面を生成した後、解析サーバ１ａとネットワーク・メールサーバ網１００とにメールサーバ管理者用画面のメール通信情報を提供する（図３のステップｃ７）。尚、統計処理としては、下記のメール通信情報の項目を生成できればよい。
【００８３】
この時に提供するメール通信情報としては、次の項目が考えられる。各メールサーバと受信サーバ群４との間でのメール通信情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信に要した時間が長い一定数メールのメールリレー情報
（５）ｘ日間の定期メール通信に要した時間が短い一定数メールのメールリレー情報
（６）ｘ日間の定期メール通信受信失敗率
（７）最終の定期メール受信日時
という７点が考えられる。
【００８４】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７と受信サーバ群４との間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【００８５】
また、メール経路情報については、経路上に存在するサーバ名が全て記録されており、そのまま平文で公開すると全メールサーバ名が漏洩することとなり、セキュリティ上（不正パケットによるかく乱等）の問題が発生する可能性がある。この対策として、サーバ管理者用の画面を表示する際にあっては、ユーザＩＤ及びパスワードによる認証及びＳＳＬ対応ブラウザで表示させる等のセキュリティ対応を行うことが望ましい。
【００８６】
統計サーバ２から各メールサーバのメール通信情報を受け取った解析サーバ１ａは、それらメール通信情報に対して解析処理を行ってメール利用者向けの運用状況画面を生成し、ネットワーク・メールサーバ網１００に提供する（図１０のｃ８）。尚、解析処理としては、下記のメール通信情報の項目を生成できればよい。
【００８７】
この時に提供するメール通信情報としては、次の項目が考えられる。メールサーバと受信サーバとの間の情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信受信失敗率
（５）最終の定期メール受信日時
という５点が考えられる。
【００８８】
第１メールサーバ群５、第２メールサーバ群６、第３メールサーバ群７と受信サーバ群４との間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【００８９】
また、本実施の形態では、上記の数値情報に適切な上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合にガイダンス表示を行うことによって、利用者による無用な再送操作を防ぐことも可能である（例えば、「３０分ほどお待ち下さい」等）。
【００９０】
このように、本実施の形態では、メール送受信動作の多いメールサーバだけの統計・解析動作を行うことによって、受信サーバ群４、統計サーバ２、解析サーバ１ａの負荷を減らすことができる。
【００９１】
また、本実施の形態では、メールサーバのホスト名を通常時において公表する必要が無いサーバが存在しているメール環境にあって、公表したくないメールサーバを統計動作対象とせず、サーバ名公開動作をしないことによって、災害対応用メールサーバ、特定イベント及び特定キャンペーン期間にのみ使用するメールサーバ・予備メールサーバ等に対する不正アタックを防ぐことができる。
【００９２】
図１１は本発明の第４の実施の形態によるメールサーバ網の構成例を示すブロック図である。図１１において、本発明の第４の実施の形態によるメールサーバ網は、第１メールサーバ群５ａ、第２メールサーバ群６ａ、第３メールサーバ群７ａのメールサーバ５０ａ〜５９ａ，６０ａ〜６９ａ，７０ａ〜７９ａと受信サーバ群４ａの受信サーバ４１ａ〜４３ａとの間の通信を双方向とした以外は図４に示す本発明の第２の実施の形態と同様の構成となっており、同一構成要素には同一符号を付してある。
【００９３】
図１１を参照すると、本発明の第４の実施の形態では、時間超過で定期メール（ハートビートメール１０１）を送信し、定期メール未着の場合に受信サーバから逆に定期メール（ハートビートメール１０２）を送信するモデルを対象として説明している。図１１にあっては、メールサーバ台数を３０台として説明しているが、メールサーバ台数が増加した場合にあっても本発明の趣旨が損なわれないことは明白である。
【００９４】
図１２は本発明の第４の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。これら図１１及び図１２を参照して本発明の第４の実施の形態によるメールサーバ網の動作について説明する。
【００９５】
タイムサーバ３は通信記録内の時間情報について整合性を保つため、第１メールサーバ群５ａ、第２メールサーバ群６ａ、第３メールサーバ群７ａの各メールサーバ、受信サーバ群４ａの受信サーバ、統計サーバ２、解析サーバ１ａに正確な時間情報を随時提供する（図１２のｄ１）。
【００９６】
第１メールサーバ群５ａ、第２メールサーバ群６ａ、第３メールサーバ群７ａの各メールサーバは、受信サーバ群４ａの受信サーバに一定時間間隔で定期メールを送出する（図１２のｄ２）。
【００９７】
この定期メール通信については、セキュリティ認証（ＰＯＰ Ｂｅｆｏｒｅ ＳＭＴＰ／ＳＭＴＰ Ａｕｔｈ等）を行うことによって、不正パケットによるかく乱を避けることができ、より正確なハートビート通信を行うことが可能となる。
【００９８】
受信サーバ群４ａの受信サーバは定時から３０分（一定時間間隔＝６０分の場合）を経過しても定期メールを受信していない場合、逆に受信サーバ群４ａの受信サーバから第１メールサーバ群５ａ、第２メールサーバ群６ａ、第３メールサーバ群７ａの各メールサーバに定期メールを送信する（図１２のｄ３，ｄ４）。
【００９９】
受信サーバ群４ａの受信サーバは第１メールサーバ群５ａ、第２メールサーバ群６ａ、第３メールサーバ群７ａの各メールサーバに定期メールを送信した後に、ネットワーク・メールサーバ網１００からエラー返信メールを受信すると（図１２のｄ５）、エラーメールのメール経路（メールリレー）情報を記録する（図１２のｄ６）。
【０１００】
定期メールを受信した受信サーバ群４ａの受信サーバは統計サーバ２に受信時間とメール経路情報（メールリレー情報）とを通知する（図１２のｄ７）。
【０１０１】
統計サーバ２は各メールサーバの通信状況及びメール経路情報を記録し（図１２のｄ８）、その記録した通信状況及びメール経路情報に対して統計処理を行ってメールサーバ管理者用画面を生成した後、解析サーバ１ａとネットワーク・メールサーバ網１００とにメールサーバ管理者用画面のメール通信情報を提供する（図１２のｄ９）。尚、統計処理としては、下記のメール通信情報を生成できればよい。
【０１０２】
この時に提供するメール通信情報としては、次の項目が考えられる。各メールサーバと受信サーバ群４ａの受信サーバとの間でのメール通信情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信に要した時間が長い一定数メールのメールリレー情報
（５）ｘ日間の定期メール通信に要した時間が短い一定数メールのメールリレー情報
（６）ｘ日間の定期メール通信受信失敗率
（７）ｘ日間における受信サーバからメールサーバへハートビートメール逆送信時に、ネットワーク・メールサーバ網から返ってきたエラーメールのメール経路（メールリレー）情報
（８）最終の定期メール受信日時
という８点が考えられる。
【０１０３】
第１メールサーバ群５ａ、第２メールサーバ群６ａ、第３メールサーバ群７ａと受信サーバ群４ａとの間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【０１０４】
また、メール経路情報については、経路上に存在するサーバ名が全て記録されており、そのまま平文で公開すると全メールサーバ名が漏洩することとなり、セキュリティ上（不正パケットによるかく乱等）の問題が発生する可能性がある。この対策として、サーバ管理者用の画面を表示する際にあっては、ユーザＩＤ及びパスワードによる認証及びＳＳＬ対応ブラウザで表示させる等のセキュリティ対応を行うことが望ましい。
【０１０５】
統計サーバ２から各メールサーバのメール通信情報を受け取った解析サーバ１ａは、それらのメール通信情報に対して解析処理を行ってメール利用者向けの運用状況画面を生成し、ネットワーク・メールサーバ網１００に提供する（図１２のｄ１０）。尚、解析処理としては、下記のメール通信情報を生成できればよい。
【０１０６】
この時に提供するメール通信情報としては、次の項目が考えられる。メールサーバと受信サーバとの間の情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信受信失敗率
（５）最終の定期メール受信日時
という５点が考えられる。
【０１０７】
第１メールサーバ群５ａ、第２メールサーバ群６ａ、第３メールサーバ群７ａと受信サーバ群４ａとの間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【０１０８】
また、本実施の形態では、上記の数値情報に適切な上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合にガイダンス表示を行うことによって、利用者による無用な再送操作を防ぐことも可能である（例えば、「３０分ほどお待ち下さい」等）。
【０１０９】
他定時トラフィックの影響を受けない（他定時トラフィックに影響を与えない）ようにするには、割り切れない数・素数のタイミングでハートビート通信及びハートビートの逆送信動作を行うことが望ましい。
【０１１０】
メールサーバ台数が１０を超える場合には、メールサーバのシリアル番号を１０で除した余りの数を、図１３に示す表にあてはめることで対応可能である。例えば、１時間間隔の場合、図１３に示すように、メールサーバ番号の下１ケタが「〜〜０」であれば通報時間（毎時）が「１１分」、逆送信のタイミングが「４１分」となる。
【０１１１】
同様に、下１ケタが「〜〜１」であれば通報時間が「１３分」、逆送信のタイミングが「４３分」、下１ケタが「〜〜２」であれば通報時間が「１７分」、逆送信のタイミングが「４７分」、下１ケタが「〜〜３」であれば通報時間が「２３分」、逆送信のタイミングが「５３分」、下１ケタが「〜〜４」であれば通報時間が「２９分」、逆送信のタイミングが「５９分」となる。
【０１１２】
さらに、下１ケタが「〜〜５」であれば通報時間が「４１分」、逆送信のタイミングが「１１分」、下１ケタが「〜〜６」であれば通報時間が「４３分」、逆送信のタイミングが「１３分」、下１ケタが「〜〜７」であれば通報時間が「４７分」、逆送信のタイミングが「１７分」、下１ケタが「〜〜８」であれば通報時間が「５３分」、逆送信のタイミングが「２３分」、下１ケタが「〜〜９」であれば通報時間が「５９分」、逆送信のタイミングが「２９分」となる。
【０１１３】
このように、本実施の形態では、受信サーバからメールサーバへ逆にメール送信を行うことによって、エラーメールのメール経路（メールリレー）情報を記録することができ、メール送受信についての情報が増加し、故障箇所切り分けの分解能を上げることができる。
【０１１４】
図１４は本発明の第５の実施の形態によるメールサーバ網の構成例を示すブロック図である。図１４において、本発明の第５の実施の形態によるメールサーバ網は、第１メールサーバ群５ｂ、第２メールサーバ群６ｂ、第３メールサーバ群７ｂ各々に負荷分散装置８１〜８３を設けた以外は図１１に示す本発明の第４の実施の形態と同様の構成となっており、同一構成要素には同一符号を付してある。
【０１１５】
本発明の第５の実施の形態では、時間超過で定期メール（ハートビートメール１０１）を送信し、定期メール未着の場合に受信サーバから逆に定期メール（ハートビートメール１０２）を送信し、メールサーバ群の負荷分散装置で処理負荷を自動分散するモデルを対象として説明している。図１４にあっては、メールサーバ台数を３０台として説明しているが、メールサーバ台数が増加した場合にあっても本発明の趣旨が損なわれないことは明白である。
【０１１６】
図１５は本発明の第５の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。これら図１４及び図１５を参照して本発明の第５の実施の形態によるメールサーバ網の動作について説明する。
【０１１７】
タイムサーバ３は通信記録内の時間情報について整合性を保つため、第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３、第１メールサーバ群５ｂ、第２メールサーバ群６ｂ、第３メールサーバ群７ｂの各メールサーバ、受信サーバ群４ａの受信サーバ４１ａ〜４３ａ、統計サーバ２、解析サーバ１に正確な時間情報を随時提供する（図１５のステップｅ１）。
【０１１８】
第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３配下の各メールサーバは、受信サーバ群４ａの受信サーバに一定時間間隔で定期メール（ハートビートメール１０１）を送出する（図１５のｅ２）。
【０１１９】
この定期メール通信については、セキュリティ認証（ＰＯＰ Ｂｅｆｏｒｅ ＳＭＴＰ／ＳＭＴＰ Ａｕｔｈ等）を行うことによって、不正パケットによるかく乱を避けることができ、より正確なハートビート通信を行うことが可能となる。
【０１２０】
受信サーバ群４ａの受信サーバは定時から３０分（一定時間間隔＝６０分の場合）を経過しても定期メールを受信していない場合、逆に受信サーバ群４ａの受信サーバから第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３配下の各メールサーバに定期メール（ハートビートメール１０２）を送信する（図１５のｅ３，ｅ４）。
【０１２１】
受信サーバ群４ａの受信サーバは第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３配下の各メールサーバに定期メールを送信した後に、ネットワーク・メールサーバ網１００からエラー返信メールを受信すると（図１５のｅ５）、エラーメールのメール経路（メールリレー）情報を記録する（図１５のｅ６）。
【０１２２】
定期メールを受信した受信サーバ群４ａの受信サーバは統計サーバ２に受信時間とメール経路情報（メールリレー情報）とを通知する（図１５のｅ７）。
【０１２３】
統計サーバ２は各メールサーバの通信状況及びメール経路情報を記録し（図１５のｅ８）、その記録した通信状況及びメール経路情報に対して統計処理を行ってメールサーバ管理者用画面を生成した後、解析サーバ１ａと第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３とネットワーク・メールサーバ網１００とにメールサーバ管理者用画面のメール通信情報を提供する（図１５のｅ９）。尚、統計処理としては、下記のメール通信情報を生成できればよい。
【０１２４】
この時に提供するメール通信情報としては、次の項目が考えられる。各メールサーバと受信サーバとの間でのメール通信情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信に要した時間が長い一定数メールのメールリレー情報
（５）ｘ日間の定期メール通信に要した時間が短い一定数メールのメールリレー情報
（６）ｘ日間の定期メール通信受信失敗率
（７）ｘ日間における受信サーバからメールサーバへハートビートメール逆送信時に、ネットワーク・メールサーバ網から返ってきたエラーメールのメール経路（メールリレー）情報
（８）最終の定期メール受信日時
という８点が考えられる。
【０１２５】
第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３と受信サーバ群４ａとの間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【０１２６】
統計サーバ２から上記のメール通信情報（統計情報）を受信した第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３は、各数値情報に適切な上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合に各メールサーバに対して自動負荷分散動作を行う（図１５のｅ１０）。
【０１２７】
また、メール経路情報については、経路上に存在するサーバ名が全て記録されており、そのまま平文で公開すると全メールサーバ名が漏洩することとなり、セキュリティ上（不正パケットによるかく乱等）の問題が発生する可能性がある。この対策として、サーバ管理者用の画面を表示する際にあっては、ユーザＩＤ及びパスワードによる認証、ＳＳＬ対応ブラウザで表示させる等のセキュリティ対応を行うことが望ましい。
【０１２８】
統計サーバ２から各メールサーバのメール通信情報を受け取った解析サーバ１ａは、それらのメール通信情報に対して解析処理を行ってメール利用者向けの運用状況画面を生成し、ネットワーク・メールサーバ網１００に提供する（図１５のｅ１１）。尚、解析処理としては、下記のメール通信情報を生成できればよい。
【０１２９】
この時に提供するメール通信情報としては、次の項目が考えられる。メールサーバと受信サーバとの間の情報としては、
（１）ｘ日間（ｘは１以上の整数）において定期メール通信に要した最長の時間
（２）ｘ日間において定期メール通信に要した平均の時間
（３）ｘ日間において定期メール通信に要した最短の時間
（４）ｘ日間の定期メール通信受信失敗率
（５）最終の定期メール受信日時
という５点が考えられる。
【０１３０】
第１メールサーバ群５ｂの負荷分散装置８１、第２メールサーバ群６ｂの負荷分散装置８２、第３メールサーバ群７ｂの負荷分散装置８３と受信サーバ群４ａの受信サーバ４１ａ〜４３ａとの間におけるメール統計情報を提供する場合の情報項目としても、上記のデータは有用である。
【０１３１】
また、本実施の形態では、上記数値情報に適切な上限しきい値・下限しきい値を設け、それぞれの値を超えた場合にガイダンス表示を行うことによって、利用者による無用な再送操作を防ぐことも可能である（例えば、「３０分ほどお待ち下さい」等）。
【０１３２】
他定時トラフィックの影響を受けない（他定時トラフィックに影響を与えない）ようにするには、割り切れない数・素数のタイミングでハートビート通信及びハートビートの逆送信動作を行うことが望ましい。
【０１３３】
メールサーバ台数が１０を超える場合には、メールサーバのシリアル番号を１０で除した余りの数を、図１３に示す表にあてはめることで対応可能である。例えば、１時間間隔の場合、図１３に示すように、メールサーバ番号の下１ケタが「〜〜０」であれば通報時間（毎時）が「１１分」、逆送信のタイミングが「４１分」となる。
【０１３４】
同様に、下１ケタが「〜〜１」であれば通報時間が「１３分」、逆送信のタイミングが「４３分」、下１ケタが「〜〜２」であれば通報時間が「１７分」、逆送信のタイミングが「４７分」、下１ケタが「〜〜３」であれば通報時間が「２３分」、逆送信のタイミングが「５３分」、下１ケタが「〜〜４」であれば通報時間が「２９分」、逆送信のタイミングが「５９分」となる。
【０１３５】
さらに、下１ケタが「〜〜５」であれば通報時間が「４１分」、逆送信のタイミングが「１１分」、下１ケタが「〜〜６」であれば通報時間が「４３分」、逆送信のタイミングが「１３分」、下１ケタが「〜〜７」であれば通報時間が「４７分」、逆送信のタイミングが「１７分」、下１ケタが「〜〜８」であれば通報時間が「５３分」、逆送信のタイミングが「２３分」、下１ケタが「〜〜９」であれば通報時間が「５９分」、逆送信のタイミングが「２９分」となる。
【０１３６】
このように、本実施の形態では、統計サーバのメール送受信遅延情報をメールサーバ管理者が参照することで、負荷分散装置が適切な分散処理を行っているかをメール送受信情報ベースで確認することができる。
【０１３７】
また、本発明に関連する負荷分散装置にあっては、個々のメールサーバのＣＰＵ負荷率・ハードディスク空き容量のみを判定し、負荷分散を行う装置が多いため、個々のメールサーバのＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）ポート不調やハードディスク不調・スイッチングハブ不調等によるメール送受信不調についてはコントロールしきれない場合が多くある。
【０１３８】
本発明では、上記の対策として定期メールによる自動負荷判定を行っており、上記のトラブルが発生した場合にあっても、正確な負荷コントロール動作を行うことが期待できる。
【０１３９】
さらに、本発明では、メールサーバの負荷がしきい値をオーバしていることを検知している間、メールクライアント（図示せず）にて直前に送信した同じ宛先へのメール再送信を抑止し、直前に送信した添付ファイル容量と同じ添付ファイル容量のメール再送信を抑止する機能を付加することによって、不要なトラフィック上昇を防ぐことができる。この抑止動作については、メールサーバで行ってもよい。また、大量に宛先指定がある等によって判定が難しい場合には、同じサブジェクト（Ｓｕｂｊｅｃｔ）での判定も考えられる。
【０１４０】
さらにまた、本発明では、しきい値を超える宛先の数及び一定容量を超える添付ファイル、もしくは宛先数と添付ファイル容量とを乗じた値が一定量を超える場合に、メールサーバの過負荷が検出された時に、メールクライアントにて警告／送信禁止メッセージを表示させることも可能である。尚、メールサーバの過負荷を最短時間で解消するには、メールクライアントにて、メールサーバの過負荷が検出されている間、一切の送受信を禁止するように、送受信警告もしくは送受信禁止メッセージを指示することが有効である。
【０１４１】
本発明では、受信サーバ群４，４ａ内の受信サーバ４１〜４３，４１ａ〜４３ａをそれぞれ任意のインタネットサービスプロバイダに配置し、各メールサーバ群５〜７，５ａ〜７ａ，５ｂ〜７ｂのメールサーバからハートビートメール１０１を受信サーバ４１，４１ａ、受信サーバ４２，４２ａ、受信サーバ４３，４３ａの順に送信することで、どのインタネットサービスプロバイダの不調でメール遅延が発生しているかの切り分けを容易にすることが可能である。
【０１４２】
また、本発明では、解析サーバ１，１ａ及び統計サーバ２のＷｅｂ掲載情報として、インタネットサービスプロバイダのメールサーバの管理者や各企業のメールサーバの管理者からの書込みを許可し、「〜時〜分からメール遅延発生」、「〜時 〜交換予定」、「〜時〜分頃復旧予定」、「〜時〜分（〜交換により）復旧致しました」等のトラブル経過情報と、それぞれのメールサーバ管理者への連絡先と、インタネットサービスプロバイダのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）とを掲載することによって、トラブル発生時の連絡をよりスムーズにし、メールサービス品質の向上を期待することができる。
【０１４３】
通常のメールサーバ機能にあっては、外部ネットワーク側で送受信されるメールアドレスが不定であり、不要な通信を避けるために特定のコンピュータ以外からのメール通信をフィルタする場合がある。メールクライアントとの通信に用いられる内部ネットワーク側についても、メールアカウントが複数あることから、メールサーバの設定については、複雑となることが多い。本発明によれば、負荷状況判定対象となるサーバから、外部ネットワーク側に送受信されるメールアドレスが固定であり、内部ネットワーク側のメールアドレスが単一であることから、メールサーバの設定が非常に簡単となる。
【０１４４】
また、内部ネットワーク側のメールアカウントが同じサーバ内にある必要は必ずしもなく、図１と図４と図１１と図１４とにそれぞれ示すメールサーバを、メールサーバと同じネットワーク上にあるＡＰ（アプリケーション）サーバやＤＢ（データベース）サーバ、及びＤＮＳ（ドメインネームシステム）等の汎用サーバ（図示せず）とした場合にあっても、それぞれの汎用サーバにメールアドレスを割り当てることで、レスポンス低下／スループット低下を検出することが可能となる。
【産業上の利用可能性】
【０１４５】
本発明は、インタネットサービスプロバイダ及び企業内メールサーバ等に適用することが可能であり、それらインタネットサービスプロバイダ及び企業内メールサーバ等におけるメールサービス品質の向上が期待できる。
【図面の簡単な説明】
【０１４６】
【図１】本発明の第１の実施の形態によるメールサーバ網の構成例を示すブロック図である。
【図２】図１の解析サーバの構成例を示すブロック図である。
【図３】本発明の第１の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。
【図４】本発明の第２の実施の形態によるメールサーバ網の構成例を示すブロック図である。
【図５】図４の解析サーバの構成例を示すブロック図である。
【図６】図４の統計サーバの構成例を示すブロック図である。
【図７】本発明の第２の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。
【図８】本発明の第２の実施の形態における推奨定期メール通信タイミングを示す図である。
【図９】本発明の第３の実施の形態によるメールサーバの構成例を示すブロック図である。
【図１０】本発明の第３の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。
【図１１】本発明の第４の実施の形態によるメールサーバ網の構成例を示すブロック図である。
【図１２】本発明の第４の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。
【図１３】本発明の第４の実施の形態における推奨定期メール通信タイミング及び逆送信タイミングを示す図である。
【図１４】本発明の第５の実施の形態によるメールサーバ網の構成例を示すブロック図である。
【図１５】本発明の第５の実施の形態によるメールサーバ網の動作を示すシーケンスチャートである。
【符号の説明】
【０１４７】
１，１ａ 解析サーバ
２ 統計サーバ
３ タイムサーバ
４，４ａ 受信サーバ群
５，５ａ，５ｂ 第１メールサーバ群
６，６ａ，６ｂ 第２メールサーバ群
７，７ａ，７ｂ 第３メールサーバ群
１１，２１，５０１ ＣＰＵ
１２，２２，５０２ ＲＯＭ
１３，２３，５０３ ＲＡＭ
１４ メール利用者向け画面生成部
１５，２５，５０５ 通信部
１６，２６ 記録部
１６ａ 保持部
１７，２７，５０８ 計時部
１８，２４ メールサーバ管理者用画面生成部
４１，４１ａ 第１受信サーバ
４２，４２ａ 第２受信サーバ
４３，４３ａ 第３受信サーバ
５０〜５９，５０ａ〜５９ａ，
５０ｂ〜５９ｂ，
６０〜６９，６０ａ〜６９ａ，
６０ｂ〜６９ｂ，
７０〜７９，７０ａ〜７９ａ，
７０ｂ〜７９ｂ メールサーバ
８１〜８３ 負荷分散装置
１００ ネットワーク・メールサーバ網
１０１，１０２ ハートビートメール
１６１，２６１ 通信状況・メール経路情報
５０４ メール記録部
５０６ メール送受信部
５０７ メール累積件数計数部
【特許請求の範囲】
【請求項１】
複数のメールサーバと、前記複数のメールサーバから一定時間間隔で、もしくは予め設定された所定条件が検出された時に送出される定期メールを受信する受信サーバと、前記受信サーバで受信した前記定期メールの解析を行う解析サーバとを含むメールサーバ網であって、
前記受信サーバで受信した前記定期メールの受信時間及びメール経路の情報を記録する記録手段と、前記記録手段に記録された情報の統計処理を行う統計手段とを有し、
前記解析サーバは、前記統計処理の結果を基に前記メールサーバにおけるメール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報を作成することを特徴とするメールサーバ網。
【請求項２】
前記記録手段と前記統計手段とを前記解析サーバに配設したことを特徴とする請求項１記載のメールサーバ網。
【請求項３】
前記解析サーバは、前記統計処理の結果からメールサーバ管理者用画面を生成してネットワークを介して配信し、前記解析の結果からメール利用者向けの運用状況画面を生成してネットワークを介して配信することを特徴とする請求項２記載のメールサーバ網。
【請求項４】
前記記録手段と前記統計手段とを含む統計サーバを前記受信サーバと前記解析サーバとの間に配設したことを特徴とする請求項１記載のメールサーバ網。
【請求項５】
前記解析サーバは、前記解析の結果からメール利用者向けの運用状況画面を生成してネットワークを介して配信し、
前記統計サーバは、前記統計処理の結果からメールサーバ管理者用画面を生成してネットワークを介して配信することを特徴とする請求項４記載のメールサーバ網。
【請求項６】
前記メールサーバは、送受信メールの累積件数が予め設定された一定数を超過したタイミングで前記定期メールを送出することを特徴とする請求項１から請求項５のいずれか記載のメールサーバ網。
【請求項７】
前記統計手段は、前記統計処理において、ｘ日間（ｘは１以上の整数）において前記定期メールの通信に要した最長の時間、前記ｘ日間において前記定期メールの通信に要した平均の時間、前記ｘ日間において前記定期メールの通信に要した最短の時間、前記ｘ日間の前記定期メールの通信に要した時間が長い一定数メールの経路情報、前記ｘ日間の前記定期メールの通信に要した時間が短い一定数メールの経路情報、前記ｘ日間の前記定期メールの通信受信失敗率のうちの少なくとも一つを算出することを特徴とする請求項１から請求項６のいずれか記載のメールサーバ網。
【請求項８】
前記受信サーバは、前記定期メールが未着の時に前記メールサーバに対して定期メールを送信し、
前記統計手段は、ｘ日間（ｘは１以上の整数）における前記受信サーバから前記メールサーバへ前記定期メールの逆送信時に返ってきたエラーメールの経路情報を前記統計処理の結果として送出することを特徴とする請求項１から請求項７のいずれか記載のメールサーバ網。
【請求項９】
前記解析サーバは、ｘ日間（ｘは１以上の整数）において前記定期メールの通信に要した最長の時間、前記ｘ日間において前記定期メールの通信に要した平均の時間、前記ｘ日間において前記定期メールの通信に要した最短の時間、前記ｘ日間の前記定期メールの通信の受信失敗率、最終の定期メール受信日時のうちの一つをメール利用者向けの運用状況画面として配信することを特徴とする請求項１から請求項８のいずれか記載のメールサーバ網。
【請求項１０】
前記解析サーバは、前記定期メール情報の時間情報に上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合にその旨のガイダンス表示を行ってネットワークに配信することを特徴とする請求項１から請求項９のいずれか記載のメールサーバ網。
【請求項１１】
前記定期メールの通信記録の時間情報について整合性を保つための時間情報を少なくとも前記メールサーバと前記受信サーバと前記解析サーバとに提供するタイムサーバを含むことを特徴とする請求項１から請求項１０のいずれか記載のメールサーバ網。
【請求項１２】
前記定期メールの通信時にセキュリティ認証を行うことを特徴とする請求項１から請求項１１のいずれか記載のメールサーバ網。
【請求項１３】
前記定期メールの経路情報の配信時にユーザＩＤ（ＩＤｅｎｔｉｆｉｅｒ）及びパスワードによってセキュリティ認証を行うことを特徴とする請求項１２記載のメールサーバ網。
【請求項１４】
前記定期メールの経路情報の配信時に少なくともＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）にて前記経路情報を暗号化することを特徴とする請求項１２または請求項１３記載のメールサーバ網。
【請求項１５】
前記統計手段にて算出される前記定期メールの通信に要した時間情報に上限しきい値及び下限しきい値を設け、
それぞれの値を超えた場合に前記複数のメールサーバに対して自動負荷分散を行う負荷分散装置を含むことを特徴とする請求項１から請求項１４のいずれか記載のメールサーバ網。
【請求項１６】
任意のメールアドレスが割り当てられかつ前記受信サーバに対して一定時間間隔で、もしくは予め設定された所定条件が検出された時に定期メールを送出する汎用サーバを配設し、
前記統計手段にて算出される前記定期メールの通信に要した時間情報に上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合に、前記汎用サーバのレスポンス低下もしくはスループット低下のガイダンス表示を行ってネットワークに配信することを特徴とする請求項１から請求項１５のいずれか記載のメールサーバ網。
【請求項１７】
請求項１から請求項１６のいずれかに記載の手段を含むことを特徴とするサーバ装置。
【請求項１８】
複数のメールサーバと、前記複数のメールサーバから一定時間間隔で、もしくは予め設定された所定条件が検出された時に送出される定期メールを受信する受信サーバと、前記受信サーバで受信した前記定期メールの解析を行う解析サーバとを含むメールサーバ網に用いる障害箇所調査方法であって、
前記解析サーバが、前記受信サーバで受信した前記定期メールの受信時間及びメール経路の情報を記録手段に記録する第１の処理と、前記記録手段に記録された情報の統計処理を行う第２の処理とを実行し、
前記解析サーバが、前記統計処理の結果を基に前記メールサーバにおけるメール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報を作成することを特徴とする障害箇所調査方法。
【請求項１９】
前記解析サーバが、前記統計処理の結果からメールサーバ管理者用画面を生成してネットワークを介して配信し、前記解析の結果からメール利用者向けの運用状況画面を生成してネットワークを介して配信することを特徴とする請求項１８記載の障害箇所調査方法。
【請求項２０】
複数のメールサーバと、前記複数のメールサーバから一定時間間隔で送出される定期メールを受信する受信サーバと、前記受信サーバで受信した前記定期メールの解析を行う解析サーバとを含むメールサーバ網に用いる障害箇所調査方法であって、
前記受信サーバと前記解析サーバとの間に配設した統計サーバが、前記受信サーバで受信した前記定期メールの受信時間及びメール経路の情報を記録手段に記録する第１の処理と、前記記録手段に記録された情報の統計処理を行う第２の処理とを実行し、
前記解析サーバが、前記統計処理の結果を基に前記メールサーバにおけるメール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報を作成することを特徴とする障害箇所調査方法。
【請求項２１】
前記解析サーバは、前記解析の結果からメール利用者向けの運用状況画面を生成してネットワークを介して配信し、
前記統計サーバは、前記統計処理の結果からメールサーバ管理者用画面を生成してネットワークを介して配信することを特徴とする請求項２０記載の障害箇所調査方法。
【請求項２２】
前記メールサーバが、送受信メールの累積件数が予め設定された一定数を超過したタイミングで前記定期メールを送出することを特徴とする請求項１８から請求項２１のいずれか記載の障害箇所調査方法。
【請求項２３】
前記統計処理において、ｘ日間（ｘは１以上の整数）において前記定期メールの通信に要した最長の時間、前記ｘ日間において前記定期メールの通信に要した平均の時間、前記ｘ日間において前記定期メールの通信に要した最短の時間、前記ｘ日間の前記定期メールの通信に要した時間が長い一定数メールの経路情報、前記ｘ日間の前記定期メールの通信に要した時間が短い一定数メールの経路情報、前記ｘ日間の前記定期メールの通信受信失敗率のうちの少なくとも一つを算出することを特徴とする請求項１８から請求項２２のいずれか記載の障害箇所調査方法。
【請求項２４】
前記受信サーバが、前記定期メールが未着の時に前記メールサーバに対して定期メールを送信し、
ｘ日間（ｘは１以上の整数）における前記受信サーバから前記メールサーバへ前記定期メールの逆送信時に返ってきたエラーメールの経路情報を前記統計処理の結果として送出することを特徴とする請求項１８から請求項２３のいずれか記載の障害箇所調査方法。
【請求項２５】
前記解析サーバが、ｘ日間（ｘは１以上の整数）において前記定期メールの通信に要した最長の時間、前記ｘ日間において前記定期メールの通信に要した平均の時間、前記ｘ日間において前記定期メールの通信に要した最短の時間、前記ｘ日間の前記定期メールの通信の受信失敗率、最終の定期メール受信日時のうちの一つをメール利用者向けの運用状況画面として配信することを特徴とする請求項１８から請求項２４のいずれか記載の障害箇所調査方法。
【請求項２６】
前記解析サーバが、前記定期メール情報の時間情報に上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合にガイダンス表示を行ってネットワークに配信することを特徴とする請求項１８から請求項２５のいずれか記載の障害箇所調査方法。
【請求項２７】
前記定期メールの通信記録の時間情報について整合性を保つための時間情報をタイムサーバから少なくとも前記メールサーバと前記受信サーバと前記解析サーバとに提供することを特徴とする請求項１８から請求項２６のいずれか記載の障害箇所調査方法。
【請求項２８】
前記定期メールの通信時にセキュリティ認証を行うことを特徴とする請求項１８から請求項２７のいずれか記載の障害箇所調査方法。
【請求項２９】
前記定期メールの経路情報の配信時にユーザＩＤ（ＩＤｅｎｔｉｆｉｅｒ）及びパスワードによってセキュリティ認証を行うことを特徴とする請求項２８記載の障害箇所調査方法。
【請求項３０】
前記定期メールの経路情報の配信時に少なくともＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）にて前記経路情報を暗号化することを特徴とする請求項２８または請求項２９記載の障害箇所調査方法。
【請求項３１】
前記統計処理にて算出される前記定期メールの通信に要した時間情報に上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合に負荷分散装置にて前記複数のメールサーバに対して自動負荷分散を行うことを特徴とする請求項１８から請求項３０のいずれか記載の障害箇所調査方法。
【請求項３２】
前記受信サーバを任意のインタネットサービスプロバイダに設け、
前記複数のメールサーバ各々から前記受信サーバに順番に前記定期メールを送信することで、メール動作不調の原因となっているメールサーバが配設された前記インタネットサービスプロバイダを特定することを特徴とする請求項１８から請求項３１のいずれか記載の障害箇所調査方法。
【請求項３３】
請求項１から請求項１６のいずれかに記載の手段を含むサーバ装置を含み、
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合にメールクライアントにて送信するメールが一つ前に送信したメールと同じ宛先か否かを判定し、
前記メールクライアントにて送信するメールが同じ宛先へ送信する場合に再送信警告もしくは再送信禁止メッセージを提示することを特徴とするメールシステム。
【請求項３４】
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合に前記メールクライアントにてメール宛先数が一定数を超過しているか否かを判定し、
前記メール宛先数が前記一定数を超過している場合に送信警告もしくは送信禁止メッセージを提示することを特徴とする請求項３３記載のメールシステム。
【請求項３５】
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合に前記メールクライアントにて送信する添付ファイルが一つ前に送信した添付ファイル容量と同じ添付ファイル容量か否かを判定し、
前記メールクライアントにて送信する添付ファイルが同じ添付ファイル容量であった場合に再送信警告もしくは再送信禁止メッセージを提示することを特徴とする請求項３３または請求項３４記載のメールシステム。
【請求項３６】
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合に前記メールクライアントにて添付ファイル容量が一定容量を超過しているか否かを判定し、
前記添付ファイル容量が前記一定容量を超過している場合に送信警告もしくは送信禁止メッセージを提示することを特徴とする請求項３３から請求項３５のいずれか記載のメールシステム。
【請求項３７】
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合に前記メールクライアントにて宛先数と添付ファイル容量とを乗じた値が一定量を超過しているか否かを判定し、
前記宛先数と前記添付ファイル容量とを乗じた値が前記一定量を超過していた場合に再送信警告もしくは再送信禁止メッセージを提示することを特徴とする請求項３３から請求項３６のいずれか記載のメールシステム。
【請求項３８】
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合に前記メールクライアントにて送信するメールが一つ前に送信したメールと同じサブジェクト（Ｓｕｂｊｅｃｔ）か否かを判定し、
前記メールクライアントにて送信するメールと一つ前に送信したメールとが同じサブジェクトであった場合に再送信警告もしくは再送信禁止メッセージを提示することを特徴とする請求項３３から請求項３７のいずれか記載のメールシステム。
【請求項３９】
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合に前記メールクライアントにて送受信警告もしくは送受信禁止メッセージを提示することを特徴とする請求項３３から請求項３８のいずれか記載のメールシステム。
【請求項１】
複数のメールサーバと、前記複数のメールサーバから一定時間間隔で、もしくは予め設定された所定条件が検出された時に送出される定期メールを受信する受信サーバと、前記受信サーバで受信した前記定期メールの解析を行う解析サーバとを含むメールサーバ網であって、
前記受信サーバで受信した前記定期メールの受信時間及びメール経路の情報を記録する記録手段と、前記記録手段に記録された情報の統計処理を行う統計手段とを有し、
前記解析サーバは、前記統計処理の結果を基に前記メールサーバにおけるメール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報を作成することを特徴とするメールサーバ網。
【請求項２】
前記記録手段と前記統計手段とを前記解析サーバに配設したことを特徴とする請求項１記載のメールサーバ網。
【請求項３】
前記解析サーバは、前記統計処理の結果からメールサーバ管理者用画面を生成してネットワークを介して配信し、前記解析の結果からメール利用者向けの運用状況画面を生成してネットワークを介して配信することを特徴とする請求項２記載のメールサーバ網。
【請求項４】
前記記録手段と前記統計手段とを含む統計サーバを前記受信サーバと前記解析サーバとの間に配設したことを特徴とする請求項１記載のメールサーバ網。
【請求項５】
前記解析サーバは、前記解析の結果からメール利用者向けの運用状況画面を生成してネットワークを介して配信し、
前記統計サーバは、前記統計処理の結果からメールサーバ管理者用画面を生成してネットワークを介して配信することを特徴とする請求項４記載のメールサーバ網。
【請求項６】
前記メールサーバは、送受信メールの累積件数が予め設定された一定数を超過したタイミングで前記定期メールを送出することを特徴とする請求項１から請求項５のいずれか記載のメールサーバ網。
【請求項７】
前記統計手段は、前記統計処理において、ｘ日間（ｘは１以上の整数）において前記定期メールの通信に要した最長の時間、前記ｘ日間において前記定期メールの通信に要した平均の時間、前記ｘ日間において前記定期メールの通信に要した最短の時間、前記ｘ日間の前記定期メールの通信に要した時間が長い一定数メールの経路情報、前記ｘ日間の前記定期メールの通信に要した時間が短い一定数メールの経路情報、前記ｘ日間の前記定期メールの通信受信失敗率のうちの少なくとも一つを算出することを特徴とする請求項１から請求項６のいずれか記載のメールサーバ網。
【請求項８】
前記受信サーバは、前記定期メールが未着の時に前記メールサーバに対して定期メールを送信し、
前記統計手段は、ｘ日間（ｘは１以上の整数）における前記受信サーバから前記メールサーバへ前記定期メールの逆送信時に返ってきたエラーメールの経路情報を前記統計処理の結果として送出することを特徴とする請求項１から請求項７のいずれか記載のメールサーバ網。
【請求項９】
前記解析サーバは、ｘ日間（ｘは１以上の整数）において前記定期メールの通信に要した最長の時間、前記ｘ日間において前記定期メールの通信に要した平均の時間、前記ｘ日間において前記定期メールの通信に要した最短の時間、前記ｘ日間の前記定期メールの通信の受信失敗率、最終の定期メール受信日時のうちの一つをメール利用者向けの運用状況画面として配信することを特徴とする請求項１から請求項８のいずれか記載のメールサーバ網。
【請求項１０】
前記解析サーバは、前記定期メール情報の時間情報に上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合にその旨のガイダンス表示を行ってネットワークに配信することを特徴とする請求項１から請求項９のいずれか記載のメールサーバ網。
【請求項１１】
前記定期メールの通信記録の時間情報について整合性を保つための時間情報を少なくとも前記メールサーバと前記受信サーバと前記解析サーバとに提供するタイムサーバを含むことを特徴とする請求項１から請求項１０のいずれか記載のメールサーバ網。
【請求項１２】
前記定期メールの通信時にセキュリティ認証を行うことを特徴とする請求項１から請求項１１のいずれか記載のメールサーバ網。
【請求項１３】
前記定期メールの経路情報の配信時にユーザＩＤ（ＩＤｅｎｔｉｆｉｅｒ）及びパスワードによってセキュリティ認証を行うことを特徴とする請求項１２記載のメールサーバ網。
【請求項１４】
前記定期メールの経路情報の配信時に少なくともＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）にて前記経路情報を暗号化することを特徴とする請求項１２または請求項１３記載のメールサーバ網。
【請求項１５】
前記統計手段にて算出される前記定期メールの通信に要した時間情報に上限しきい値及び下限しきい値を設け、
それぞれの値を超えた場合に前記複数のメールサーバに対して自動負荷分散を行う負荷分散装置を含むことを特徴とする請求項１から請求項１４のいずれか記載のメールサーバ網。
【請求項１６】
任意のメールアドレスが割り当てられかつ前記受信サーバに対して一定時間間隔で、もしくは予め設定された所定条件が検出された時に定期メールを送出する汎用サーバを配設し、
前記統計手段にて算出される前記定期メールの通信に要した時間情報に上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合に、前記汎用サーバのレスポンス低下もしくはスループット低下のガイダンス表示を行ってネットワークに配信することを特徴とする請求項１から請求項１５のいずれか記載のメールサーバ網。
【請求項１７】
請求項１から請求項１６のいずれかに記載の手段を含むことを特徴とするサーバ装置。
【請求項１８】
複数のメールサーバと、前記複数のメールサーバから一定時間間隔で、もしくは予め設定された所定条件が検出された時に送出される定期メールを受信する受信サーバと、前記受信サーバで受信した前記定期メールの解析を行う解析サーバとを含むメールサーバ網に用いる障害箇所調査方法であって、
前記解析サーバが、前記受信サーバで受信した前記定期メールの受信時間及びメール経路の情報を記録手段に記録する第１の処理と、前記記録手段に記録された情報の統計処理を行う第２の処理とを実行し、
前記解析サーバが、前記統計処理の結果を基に前記メールサーバにおけるメール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報を作成することを特徴とする障害箇所調査方法。
【請求項１９】
前記解析サーバが、前記統計処理の結果からメールサーバ管理者用画面を生成してネットワークを介して配信し、前記解析の結果からメール利用者向けの運用状況画面を生成してネットワークを介して配信することを特徴とする請求項１８記載の障害箇所調査方法。
【請求項２０】
複数のメールサーバと、前記複数のメールサーバから一定時間間隔で送出される定期メールを受信する受信サーバと、前記受信サーバで受信した前記定期メールの解析を行う解析サーバとを含むメールサーバ網に用いる障害箇所調査方法であって、
前記受信サーバと前記解析サーバとの間に配設した統計サーバが、前記受信サーバで受信した前記定期メールの受信時間及びメール経路の情報を記録手段に記録する第１の処理と、前記記録手段に記録された情報の統計処理を行う第２の処理とを実行し、
前記解析サーバが、前記統計処理の結果を基に前記メールサーバにおけるメール遅延及びメール未着における故障箇所及び遅延箇所の調査用の情報を作成することを特徴とする障害箇所調査方法。
【請求項２１】
前記解析サーバは、前記解析の結果からメール利用者向けの運用状況画面を生成してネットワークを介して配信し、
前記統計サーバは、前記統計処理の結果からメールサーバ管理者用画面を生成してネットワークを介して配信することを特徴とする請求項２０記載の障害箇所調査方法。
【請求項２２】
前記メールサーバが、送受信メールの累積件数が予め設定された一定数を超過したタイミングで前記定期メールを送出することを特徴とする請求項１８から請求項２１のいずれか記載の障害箇所調査方法。
【請求項２３】
前記統計処理において、ｘ日間（ｘは１以上の整数）において前記定期メールの通信に要した最長の時間、前記ｘ日間において前記定期メールの通信に要した平均の時間、前記ｘ日間において前記定期メールの通信に要した最短の時間、前記ｘ日間の前記定期メールの通信に要した時間が長い一定数メールの経路情報、前記ｘ日間の前記定期メールの通信に要した時間が短い一定数メールの経路情報、前記ｘ日間の前記定期メールの通信受信失敗率のうちの少なくとも一つを算出することを特徴とする請求項１８から請求項２２のいずれか記載の障害箇所調査方法。
【請求項２４】
前記受信サーバが、前記定期メールが未着の時に前記メールサーバに対して定期メールを送信し、
ｘ日間（ｘは１以上の整数）における前記受信サーバから前記メールサーバへ前記定期メールの逆送信時に返ってきたエラーメールの経路情報を前記統計処理の結果として送出することを特徴とする請求項１８から請求項２３のいずれか記載の障害箇所調査方法。
【請求項２５】
前記解析サーバが、ｘ日間（ｘは１以上の整数）において前記定期メールの通信に要した最長の時間、前記ｘ日間において前記定期メールの通信に要した平均の時間、前記ｘ日間において前記定期メールの通信に要した最短の時間、前記ｘ日間の前記定期メールの通信の受信失敗率、最終の定期メール受信日時のうちの一つをメール利用者向けの運用状況画面として配信することを特徴とする請求項１８から請求項２４のいずれか記載の障害箇所調査方法。
【請求項２６】
前記解析サーバが、前記定期メール情報の時間情報に上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合にガイダンス表示を行ってネットワークに配信することを特徴とする請求項１８から請求項２５のいずれか記載の障害箇所調査方法。
【請求項２７】
前記定期メールの通信記録の時間情報について整合性を保つための時間情報をタイムサーバから少なくとも前記メールサーバと前記受信サーバと前記解析サーバとに提供することを特徴とする請求項１８から請求項２６のいずれか記載の障害箇所調査方法。
【請求項２８】
前記定期メールの通信時にセキュリティ認証を行うことを特徴とする請求項１８から請求項２７のいずれか記載の障害箇所調査方法。
【請求項２９】
前記定期メールの経路情報の配信時にユーザＩＤ（ＩＤｅｎｔｉｆｉｅｒ）及びパスワードによってセキュリティ認証を行うことを特徴とする請求項２８記載の障害箇所調査方法。
【請求項３０】
前記定期メールの経路情報の配信時に少なくともＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）にて前記経路情報を暗号化することを特徴とする請求項２８または請求項２９記載の障害箇所調査方法。
【請求項３１】
前記統計処理にて算出される前記定期メールの通信に要した時間情報に上限しきい値及び下限しきい値を設け、それぞれの値を超えた場合に負荷分散装置にて前記複数のメールサーバに対して自動負荷分散を行うことを特徴とする請求項１８から請求項３０のいずれか記載の障害箇所調査方法。
【請求項３２】
前記受信サーバを任意のインタネットサービスプロバイダに設け、
前記複数のメールサーバ各々から前記受信サーバに順番に前記定期メールを送信することで、メール動作不調の原因となっているメールサーバが配設された前記インタネットサービスプロバイダを特定することを特徴とする請求項１８から請求項３１のいずれか記載の障害箇所調査方法。
【請求項３３】
請求項１から請求項１６のいずれかに記載の手段を含むサーバ装置を含み、
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合にメールクライアントにて送信するメールが一つ前に送信したメールと同じ宛先か否かを判定し、
前記メールクライアントにて送信するメールが同じ宛先へ送信する場合に再送信警告もしくは再送信禁止メッセージを提示することを特徴とするメールシステム。
【請求項３４】
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合に前記メールクライアントにてメール宛先数が一定数を超過しているか否かを判定し、
前記メール宛先数が前記一定数を超過している場合に送信警告もしくは送信禁止メッセージを提示することを特徴とする請求項３３記載のメールシステム。
【請求項３５】
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合に前記メールクライアントにて送信する添付ファイルが一つ前に送信した添付ファイル容量と同じ添付ファイル容量か否かを判定し、
前記メールクライアントにて送信する添付ファイルが同じ添付ファイル容量であった場合に再送信警告もしくは再送信禁止メッセージを提示することを特徴とする請求項３３または請求項３４記載のメールシステム。
【請求項３６】
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合に前記メールクライアントにて添付ファイル容量が一定容量を超過しているか否かを判定し、
前記添付ファイル容量が前記一定容量を超過している場合に送信警告もしくは送信禁止メッセージを提示することを特徴とする請求項３３から請求項３５のいずれか記載のメールシステム。
【請求項３７】
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合に前記メールクライアントにて宛先数と添付ファイル容量とを乗じた値が一定量を超過しているか否かを判定し、
前記宛先数と前記添付ファイル容量とを乗じた値が前記一定量を超過していた場合に再送信警告もしくは再送信禁止メッセージを提示することを特徴とする請求項３３から請求項３６のいずれか記載のメールシステム。
【請求項３８】
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、
前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合に前記メールクライアントにて送信するメールが一つ前に送信したメールと同じサブジェクト（Ｓｕｂｊｅｃｔ）か否かを判定し、
前記メールクライアントにて送信するメールと一つ前に送信したメールとが同じサブジェクトであった場合に再送信警告もしくは再送信禁止メッセージを提示することを特徴とする請求項３３から請求項３７のいずれか記載のメールシステム。
【請求項３９】
前記統計手段にて算出される前記定期メールの通信に要した時間情報に対して上限しきい値及び下限しきい値を設け、前記定期メールの通信に要した時間情報が前記上限しきい値を超えかつ前記下限しきい値を下回らない場合に前記メールクライアントにて送受信警告もしくは送受信禁止メッセージを提示することを特徴とする請求項３３から請求項３８のいずれか記載のメールシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２００９−８９２８３（Ｐ２００９−８９２８３Ａ）
【公開日】平成２１年４月２３日（２００９．４．２３）
【国際特許分類】
【出願番号】特願２００７−２５９３１３（Ｐ２００７−２５９３１３）
【出願日】平成１９年１０月３日（２００７．１０．３）
【出願人】（０００２３２１４０）ＮＥＣフィールディング株式会社 (373)
【Ｆターム（参考）】
【公開日】平成２１年４月２３日（２００９．４．２３）
【国際特許分類】
【出願日】平成１９年１０月３日（２００７．１０．３）
【出願人】（０００２３２１４０）ＮＥＣフィールディング株式会社 (373)
【Ｆターム（参考）】
[ Back to top ]