(57)【要約】【課題】  本発明は電子メール送受信システムに関し、受信者には１通のみのメールしか配信しないようにすることができる電子メール送受信システムを提供することを目的としている。【解決手段】  ＭＬ情報収集に必要な情報を定義している発信元サーバ構成定義部１１と、ＭＬ情報の収集を行なう発信元サーバＭＬ情報収集部１２と、収集したＭＬ情報の管理を行なう発信元サーバＭＬ情報管理部１３と、発信元サーバとＭＬ管理サーバ間で電子メールの送信を行なう段階で、ＭＬ管理サーバから受信サーバへの送信の有無を決定するために必要な制御情報を加工する発信元サーバ制御情報加工部１４とを具備し、前記発信元サーバで各ＭＬ管理サーバからエンドユーザまでの電子メールの転送を制御し、エンドユーザに届く電子メールを最終的に１つにすると共に、前記ＭＬ管理サーバから受信サーバまでの電子メールの伝送量を削減するように構成する。【選択図】    図１
2005020706.tif 000002
【特許請求の範囲】
【請求項１】
電子メールの送信要求を受ける発信元サーバと、メーリングリスト（以下ＭＬと略す）を管理するＭＬ管理サーバがそれぞれ設置されるネットワーク上で、
発信元サーバにおいては、
ＭＬ情報収集に必要な情報を定義している発信元サーバ構成定義部と、ＭＬ情報の収集を行なう発信元サーバＭＬ情報収集部と、収集したＭＬ情報の管理を行なう発信元サーバＭＬ情報管理部と、発信元サーバとＭＬ管理サーバ間で電子メールの送信を行なう段階で、ＭＬ管理サーバから受信サーバへの送信の有無を決定するために必要な制御情報を加工する発信元サーバ制御情報加工部とを具備し、
前記発信元サーバで各ＭＬ管理サーバからエンドユーザまでの電子メールの転送を制御し、エンドユーザに届く電子メールを最終的に１つにすると共に、前記ＭＬ管理サーバから受信サーバまでの電子メールの伝送量を削減することを特徴とする電子メール送受信システム。
【請求項２】
前記発信元サーバがユーザから電子メール送信要求を受け付けた後、前記発信元サーバＭＬ情報収集部が、前記発信元サーバ構成定義部で定義されている情報を元に、ＭＬ情報の収集をＭＬ管理サーバに依頼した時に、ＭＬ管理サーバのＭＬ管理サーバＭＬ情報収集対応部で発信元サーバの情報を格納しておき、ＭＬ情報が変更された時に格納している発信元サーバ情報を元に、前記ＭＬ管理サーバＭＬ情報収集対応部が自発的に変更対象のＭＬ情報を発信元サーバに送信し、発信元サーバの前記発信元サーバＭＬ情報管理部で管理されているＭＬ情報の変更を行なうことを特徴とする請求項１記載の電子メール送受信システム。
【請求項３】
請求項１または２記載の電子メール送受信システムにおいて、
前記発信元サーバ及びＭＬ管理サーバに、前記エンドユーザが設定した受信拒否情報を収集する受信拒否情報収集手段を設け、
前記発信元サーバに、前記受信拒否情報の条件を基にエンドユーザへの送信の有無を決定するために必要な制御情報を加工するサーバ拒否情報加工手段を設けたことを特徴とする電子メール送受信システム。
【請求項４】
請求項１乃至３のいずれか記載の電子メール送受信システムにおいて、
前記発信元サーバ及び受信サーバに、障害が発生したＭＬ管理サーバと前記障害のＭＬ管理サーバを代理する代理サーバ情報を収集する代理サーバ情報収集手段と、
前記代理サーバ情報を基にエンドユーザへの送信の有無を決定するために必要な制御情報を加工し送信する代理サーバ情報加工手段を設けたことを特徴とする電子メール送受信システム。
【請求項５】
請求項４記載の電子メール送受信システムにおいて、
前記障害のＭＬ管理サーバの配下のエンドユーザに送信できない電子メールを保存し、前記障害のＭＬ管理サーバが復旧したのち前記障害のＭＬ管理サーバの配下のエンドユーザに再送する再送手段を設けたことを特徴とする電子メール送受信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は電子メール送受信システムに関し、更に詳しくはインターネット上でやりとりする電子メールの送受信システムにおいて、情報の共有や宛先指定の簡素化のために使用するメーリングリスト（以下ＭＬと略す）を用いた電子メールの送受信システムに関する。
【背景技術】
【０００２】
近年、ＩＰインフラが普及し、情報伝達手段として電子メールは欠かせないものとなっている。電子メールによる情報伝達は、特に企業活動において活用されており、情報の伝達のみならず、電子メールにより送られてくる情報によって、情報共有が行なわれることも多い。この情報伝達／情報共有の対象者にもれなく電子メールを配信するため、また電子メールを送信する際の宛先指定作業の簡素化のため、ＭＬが使用されている。
【０００３】
ＭＬは、複数の宛先アドレスをグループ化したものであり、該グループに対して割り当てたＭＬアドレスを送信先として電子メールを送信すると、該ＭＬを管理しているサーバがこれを受け、ＭＬ内に登録されている個々のアドレスに対して該電子メールを配信するというものである。ＭＬには他のＭＬを含めることもできる。
【０００４】
ＭＬは、使用目的によって、該当する人物（その目的による連絡をとりたい相手）のメールアドレスを複数含むことによって構成される。メールの発信者は、個々の人物を意識することなく、使用目的に添ったＭＬアドレスを使用すれば、確実に関連する者全てに情報を伝達することができる。
【０００５】
ここで、実際にＭＬを使用している例について説明する。Ａさんは、ある電子機器ｘに搭載するソフトウェアの開発に携わっている。このソフトウェア開発は大規模なもので、多くの開発者が携わっている。Ａさんは、ソフトウェアの一部を複数のメンバと一緒に担当している。このソフトウェア開発には、Ａさんの所属する部署／会社の他に、複数の部署／系列会社等が関わっている。
【０００６】
Ａさんのメールアドレスは、以下のＭＬに収容されている。以下、ＭＬアドレスを［］で括って示す。
【０００７】
・自部署内の連絡用ＭＬ［ＭＬ＃自部署］  ・担当ソフトウェア関連者用のＭＬ［ＭＬ＃自担当ソフト］  更に、関連するソフトウェア開発者同士の情報伝達のため、以下のＭＬが設けられている。
【０００８】
・自担当ソフトウェアを収容する上位ソフトウェア関連のＭＬ［ＭＬ＃上位ソフト］ここで、［ＭＬ＃上位ソフト］は、Ａさんが所属する［ＭＬ＃自担当ソフト］並びに他のソフトウェア群についての同様のＭＬを含んでいる。
【０００９】
・ソフトウェア開発者全員用のＭＬ［ＭＬ＃全ソフト］ここで、［ＭＬ＃全ソフト］は、Ａさんが所属する［ＭＬ＃上位ソフト］ならびに他のソフトウェア群についての同様のＭＬを含んでいる。
【００１０】
今、Ａさんが携わっている電子機器ｘが第１弾の開発を終え、出荷前の検査が行なわれている。検査における問題発生時に、迅速な対応を行なうため、以下のＭＬが設けられている。
【００１１】
・電子機器ｘ第１弾ソフトウェア検査の連絡用ＭＬ［ＭＬ＃第１弾検査ｘ］ここで、［ＭＬ＃第１弾検査ｘ］は、［ＭＬ＃全ソフト］並びに他のＭＬ（例えばハード開発関連者用ＭＬ）を含んでいる。
【００１２】
このソフトウェアは、電子機器ｘの兄弟機種である電子機器ｙ，ｚにも使用され、電子機器ｙの検査も、同時に進行している。この検査のために、以下のＭＬが設けられている。
【００１３】
・電子機器ｙ第１弾ソフトウェア検査の連絡用ＭＬ［ＭＬ＃第１弾検査ｙ］ここで、［ＭＬ＃第１弾検査ｙ］は、［ＭＬ＃全ソフト］並びに他のＭＬ（例えば、ハード開発関連者用ＭＬ）を含んでいる。
【００１４】
・電子機器ｚ第１弾ソフトウェア検査の連絡用ＭＬ［ＭＬ＃第１弾検査ｚ］ここで、［ＭＬ＃第１弾検査ｚ］は、［ＭＬ＃全ソフト］並びに他のＭＬ（例えば、ハード開発関連者ＭＬ）を含んでいる。
【００１５】
電子機器ｘの検査において、ソフトウェアの不具合と疑わしき事象が発生した場合、検査担当者は、ソフトウェア開発者に問題の報告／解析の依頼を、電子メールによって行なう。
【００１６】
この時、検査担当者は、電子メールの宛先として、（１）電子機器ｘの検査で発見されたため、［ＭＬ＃第１弾検査ｘ］を指定する。（２）電子機器ｙ／電子機器ｚも、同じソフトウェアを使用しているため、同じ問題が発生するかもしれないので、迅速にこのことを関連者に知らしめるために、［ＭＬ＃第１弾検査ｙ］ならびに［ＭＬ＃第１弾検査ｚ］も同時に指定する。このようにすることにより、問題発生を知らしめたい人物を一人一人意識することなく、ＭＬアドレスを指定することにより、もれなく情報転送を行なうことができる。
【００１７】
図２３は従来の電子メール送受信システムの原理図である。図において、１は発信元サーバ、２は複数のＭＬ管理サーバ、３はこれらＭＬ管理サーバ２と接続されるインターネット、４は該インターネット３と接続される受信サーバである。５は発信元サーバ１と接続される送信元ユーザ、６は受信サーバ４と接続されるエンドユーザである。今、発信元サーバ１を発信元サーバ（Ｓ）、２つのＭＬ管理サーバ２をそれぞれＭＬ管理サーバ（Ｘ）、ＭＬ管理サーバ（Ｙ）、受信サーバ４を受信サーバ（Ｅ）とする。図中、太い実線は通信回線、細い実線はメール転送の流れを示す。
【００１８】
発信元サーバ（Ｓ）は、送受信部１ａにより構成されるメールサーバである。ＭＬ管理サーバ（Ｘ）、ＭＬ管理サーバ（Ｙ）は送受信部２ａにより構成されており、それぞれＭＬ情報１、ＭＬ情報２を管理する。受信サーバ（Ｅ）は、送受信部４ａにより構成されている。発信元サーバ（Ｓ）、ＭＬ管理サーバ（Ｘ）、ＭＬ管理サーバ（Ｙ）、受信サーバ（Ｅ）はそれぞれ通信回線でネットワーク接続されている。発信元サーバ（Ｓ）配下には、送信元ユーザ５が、受信サーバ（Ｅ）配下にはエンドユーザ６がそれぞれ通信回線により接続されている。
【００１９】
送信元ユーザ５の端末からメールヘッダ「Ｔｏ」の部分にＭＬアドレス１（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ）及びＭＬアドレス２（Ｙ＠ｙｙｙ．ｃｏｍ）を宛先に指定したメール送信要求を、発信元サーバ（Ｓ）が受け付け、送受信部１ａを経由してメール送信が行なわれる。ここで、送信元ユーザのメールアドレスは、（ｕｓｅｒ＠ｘｘｘ．ｃｏｍ）である。その時に、ＭＬ管理サーバ（Ｘ）に対して送信される制御情報が「制御情報１」に、ＭＬ管理サーバ（Ｙ）に対して送信される制御情報が「制御情報２」にそれぞれ示されている。
【００２０】
制御情報１、２をそれぞれ見ると明らかなように、発信元サーバ（Ｓ）から受信サーバ（ＭＬ管理サーバ２）に渡される情報としては、メールヘッダ部に相当する「Ｔｏ」や「Ｆｒｏｍ」や本文、図には示されていないが「Ｃｃ（コピー）」に指定されるアドレスの他に、制御情報の「ＲＣＰＴ  ＴＯ」に指定されるアドレス等がある。
【００２１】
ここで、発信元サーバ（Ｓ）からＭＬ管理サーバ（Ｘ）、（Ｙ）に対してメールの送信を行なう際に、渡す情報として制御情報「ＲＣＰＴ  ＴＯ」の部分には、「Ｔｏ」に記述された宛先アドレスがコピーされる。また、「Ｔｏ」に指定されるアドレス全て「ＲＣＰＴ  ＴＯ」にコピーされるわけではなく、送信するＭＬ管理サーバ２向けのアドレスのみがコピーされる。
【００２２】
図２３では、ＭＬ管理サーバ（Ｘ）宛ての「ＲＣＰＴ  ＴＯ」にはＭＬのアドレスである（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ）が、ＭＬ管理サーバ（Ｙ）宛ての「ＲＣＰＴ  ＴＯ」には、ＭＬのアドレスである（Ｙ＠ｙｙｙ．ｃｏｍ）が付加される。
【００２３】
ＭＬ管理サーバ（Ｘ）、ＭＬ管理サーバ（Ｙ）は、それぞれ発信元サーバ（Ｓ）から送信されたメールをそれぞれの送受信部２ａで受信するが、メールサーバは、メールヘッダ部「Ｔｏ」に記述されている宛先アドレスではなく、制御情報である「ＲＣＰＴ  ＴＯ」に記述されている宛先アドレスを見てメール転送を行なう。
【００２４】
ＭＬ管理サーバ（Ｘ）宛ての「ＲＣＰＴ  ＴＯ」に記述されているＭＬアドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ）、ＭＬ管理サーバ（Ｙ）宛ての「ＲＣＰＴ  ＴＯ」に記述されているＭＬアドレス（Ｙ＠ｙｙｙ．ｃｏｍ）はそれぞれ自サーバで管理するＭＬであるため、ＭＬのメンバリストをそれぞれ展開後、メンバリストに登録されているメールアドレス全てにメールの転送を行なう。
【００２５】
ここで、展開された宛先アドレスの（ｅｅｅ＠ｚｚｚ．ｎｅ．ｊｐ）に注目すると、ＭＬ管理サーバ（Ｘ）のＭＬ情報１、ＭＬ管理サーバ（Ｙ）のＭＬ情報２の両方に登録されているため、アドレスが重複していることが分かる。このため、ＭＬ管理サーバ（Ｘ）、ＭＬ管理サーバ（Ｙ）の両方から受信サーバＥ向けに（ｅｅｅ＠ｚｚｚ．ｎｅ．ｊｐ）宛てのメール転送が行なわれる。その結果、（ｅｅｅ＠ｚｚｚ．ｎｅ．ｊｐ）のアドレスを持つエンドユーザは、同一メールを２通受信してしまうことになる。
【００２６】
従来のこの種のシステムとしては、メールサーバ内のアドレス記憶部に電子メールの発信元アドレスとメール本文を一時記憶しておき、新たなメールが到着した場合、その発信元アドレスとメール本文を調べ、同一の場合には受信した電子メールを破棄する技術が知られている（例えば特許文献１，２参照）。
【００２７】
また、メールサーバにおいて、予めエンドユーザから通知された情報に基づき、当該エンドユーザ宛のメール送信元メールアドレスが、エンドユーザから通知されたメールアドレスと一致すると、当該メールの送信を拒否するものが、特許文献３に記載されている。
【特許文献１】特開２０００−１１２８４３号公報（第６頁、図２）
【特許文献２】特開２０００−９２１１２号公報
【特許文献３】特開２００２−３３０１７５号公報
【発明の開示】
【発明が解決しようとする課題】
【００２８】
メーリングリストは、発信者にとっては、複数の相手に情報を送る場合の宛先アドレス指定作業の簡素化や、宛先指定漏れの防止、個人のアドレスを記憶しておく必要がない、等の利点を持っている。一方、上述のように、複数のメーリングリスト（ＭＬ）を指定して電子メール（以下単にメールと略す）を送信することは通常行なわれることであるが、これを受信者一人一人からみると、自分のメールアドレスが収容された複数のＭＬを経由して、同一内容のメールを複数回受信することになる。これにより、同一内容のメールを読む時間を無駄にしたり、メール保存のために自端末の記憶領域を同一メールで無駄に使用することになってしまう。
【００２９】
また、メールは、受信者が受信するまで、該受信者が所属するメールサーバ（ＰＯＰサーバ）に保存されるのであるが、このメールサーバにおいても、メール保存の記憶領域を同一メールで無駄に使用することになる。また、発信者から受信者への情報伝達は、一通のメールで済むはずであるところを、同一内容のメールが複数回送られるため、ネットワークトラヒックの点でも無駄なトラヒックが生じていることになる。
【００３０】
受信者が同一内容を重複受信することを回避するシステムとして、前述した特許文献１記載の技術がある。この発明では、メールがサーバ内でメールボックスにスプールされる時に、別の記憶部に発信元アドレスとメール本文を保存しておき、次回受信したメールと記憶部に保存した情報から同一内容のメールかどうかを判断し、同一のものであれば、スプールされる前でメールを破棄することにより、同一内容のメールを２度受信することを防ぐというものである。
【００３１】
しかしながら、このシステムでは、末端の受信サーバにおいて、一時的に比較するための情報を保存しておくので、ディスク容量の圧迫とメール比較によるサーバの受信処理負荷の増大に繋がる。また、ネットワーク内のトラヒック量は従来と変わらないため、無駄なトラヒックを抑えることができないという問題がある。
【００３２】
以上、説明したように、特許文献１を含む従来の技術では、複数ＭＬ宛てに同一内容のメール送信を行なった際に、メールサーバのディスク容量圧迫、受信処理負荷の増加、かつネットワーク内の無駄なトラヒックを抑えることができないという問題があった。
【００３３】
エンドユーザが特定のメールの受信を拒否する機能を具備したメールソフトとしてｐｒｏｃｍａｉｌが知られている。これは、エンドユーザがｐｒｏｃｍａｉｌの設定で、メールヘッダのサブジェクトや差出人等をキーワードとして受信拒否を行うことで、エンドユーザが受信サーバのメールボックスからメールを取り出す時に、キーワードでフィルタリングをかけて、キーワードを含むメールを取り出さないことができる。しかし、この方法では受信拒否を設定したメールは必ずエンドユーザのメールボックスを管理する受信サーバまで配信されるため、受信サーバまでのネットワークリソースとサーバが受信することによるディスクリソースの無駄が発生する。
【００３４】
また、特許文献３に記載の方法では、拒否設定を行う情報は送信元ユーザのメールアドレスのみなので、送信元ユーザのメールアドレス以外で受信拒否をしたいメールに関してはメールサーバから転送してしまうため、最終的にエンドユーザはメールを受信してしまう。
【００３５】
更に、情報共有を行うために各所でＭＬサーバが立ち上げられているが、あるＭＬサーバが障害などによりダウンした場合、或いはＭＬサーバ向けの経路が不達になった等の問題が発生した場合、エンドユーザからその問題が発生したＭＬサーバ向けに送信されたメールは障害が解消されるまで発信元サーバからＭＬ管理サーバに対して送信リトライが行われてしまうという問題がある。
【００３６】
また、ＭＬを管理しているＭＬサーバ向けの経路が不達になった場合、たとえＭＬ加入者を収容するＭＬサーバが正常に動作していたとしても、ＭＬ加入者に対してメールは配信されない。このためにＭＬの加入者が、ＭＬを使用せずにＭＬ加入者全員に対して個別にメール送信するということは、ＭＬの加入者がＭＬの加入者全員のメールアドレスを逐次把握しているわけではないため現実的には不可能である。
【００３７】
メール送信先のＭＬサーバに障害が発生し、メールの転送が行えない場合、ＤＮＳのＭＸレコードを利用して他のサーバに転送するという従来技術がある。ＭＸレコードとはホストやドメインに宛てたメールをどのサーバに転送するかを予め指定し、ＭＬサーバに障害が発生した場合、ＭＸレコードを基に指定先のサーバにメール転送を行うものである。これにより、ＭＸレコードに指定しているホストやドメイン宛てにメール転送ができる。しかし、本手法を用いてもＭＬアドレス宛のメールである場合、転送先のサーバではＭＬを展開することができず、メンバ毎にメールアドレスのドメインが異なるので、ＭＸレコードにメンバ全てのドメイン名を指定しない限り、ＭＬのメンバにメールを送信することはできないという問題があった。
【００３８】
本発明はこのような課題に鑑みてなされたものであって、無駄なトラヒックを抑えて受信者には１通のみのメールしか配信しないようにすることができる電子メール送受信システムを提供することを目的としている。
【課題を解決するための手段】
【００３９】
本発明は、メールの発信元サーバが、該メールの宛先であるＭＬを認識し、エンドユーザの受信アドレスを意識して、最適なメール配信を行なうことにより、従来であれば同一メールが複数通、受信者に配信されていたような場合であっても、受信者には１通のみしか配信しないようにするものである。（１）請求項１記載の発明は、以下の通りである。図１は本発明の原理ブロック図である。図中に示す太い実線は通信回線を、細い実線は本発明に必要なデータの流れを、破線はメール転送の流れをそれぞれ示す。各線に付された×印は本発明では用いられていない線（従来用いられていた線）を示す。
【００４０】
図において、１Ａは発信元サーバ、２Ａは該発信元サーバ１Ａと接続されるＭＬ管理サーバである。ここで、発信元サーバ１Ａを発信元サーバ（Ｓ）とする。ＭＬ管理サーバ（Ｘ）,（Ｙ）には、ＭＬ管理サーバ（Ｘ）と、ＭＬ管理サーバ（Ｙ）とがある。２０はそれぞれＭＬ管理サーバ（Ｘ）及びＭＬ管理サーバ（Ｙ）に接続されるユーザ端末である。
【００４１】
ＭＬ管理サーバ（Ｘ）に接続されるユーザ端末のメールアドレスは、例えばａａａ＠ｘｘｘ．ｃｏ．ｊｐ、ｄｄｄ＠ｘｘｘ．ｃｏ．ｊｐであり、ＭＬ管理サーバ（Ｙ）に接続されるユーザ端末のメールアドレスは、例えばｂｂｂ＠ｙｙｙ．ｃｏｍ、ｃｃｃ＠ｙｙｙ．ｃｏｍである。
【００４２】
３はＭＬ管理サーバ（Ｘ）、ＭＬ管理サーバ（Ｙ）及び発信元サーバ（Ｓ）と接続されるインターネットである。４は該インターネット３と接続される受信サーバ（Ｅ）、６は該受信サーバ４と接続されるエンドユーザである。該エンドユーザのメールアドレスは、例えばｅｅｅ＠ｚｚｚ．ｎｅ．ｊｐである。
【００４３】
本発明は、発信元サーバ（Ｓ）に、発信元サーバ構成定義部１１、発信元サーバＭＬ情報収集部１２、発信元サーバＭＬ情報管理部１３及び発信元サーバ制御情報加工部１４を設けた点、及びＭＬ管理サーバ（Ｘ）,（Ｙ）にＭＬ管理サーバＭＬ情報収集対応部２１を設けた点が特徴である。
【００４４】
発信元サーバ（Ｓ）からＭＬ管理サーバ（Ｘ）には、通信回線に図に示すような制御情報１が乗り、発信元サーバ（Ｓ）からＭＬ管理サーバ（Ｙ）には、通信回線に図に示すような制御情報２が乗る。これら制御情報は、発信元メールアドレスと、ＲＣＰＴ  ＴＯの後に記載される各ユーザのメールアドレスと、ＭＬ管理サーバのアドレスが含まれる。
【００４５】
また、ＭＬ管理サーバ（Ｘ）,（Ｙ）には、図に示すようなＭＬ情報が記憶される。このＭＬ情報は、ＭＬ管理サーバ（Ｘ）,（Ｙ）のメールアドレスと、ＭＬ管理サーバ（Ｘ），（Ｙ）に接続されるユーザ端末及び受信サーバ（Ｅ）に接続されるエンドユーザのメールアドレスから構成されている。
【００４６】
また、発信元サーバ（Ｓ）から受信サーバ４には、直接図に示すような制御情報３が乗る。この制御情報は、発信元アドレスと、ＲＣＰＴ  ＴＯの後に記載されるユーザのメールアドレスと、ＭＬ管理サーバ（Ｘ）,（Ｙ）のメールアドレスが含まれる。１ａは発信元サーバ（Ｓ）の送受信部、２ａはＭＬ管理サーバ（Ｘ）,（Ｙ）の送受信部である。
【００４７】
以下に、各構成要素の説明を行なう。（発信元サーバ構成定義部１１）  発信元サーバ構成定義部１１は、送信元ユーザ５がＭＬの宛先アドレスと、各ＭＬ管理サーバ（Ｘ）,（Ｙ）の制御コマンド送信先アドレスと、メンバリストを取得するためのＭＬコマンドを各ＭＬ管理サーバ（Ｘ）,（Ｙ）毎に登録する。（発信元サーバＭＬ情報収集部１２）  発信元サーバＭＬ情報収集部１２は、発信元サーバ（Ｓ）とネットワーク接続されているＭＬ管理サーバ（Ｘ）,（Ｙ）から、発信元サーバ構成定義部１１に登録されている情報を元にＭＬ情報（ＭＬのメンバリスト）を収集する。
【００４８】
また、ＭＬ管理サーバ（Ｘ）,（Ｙ）からのＭＬコマンド（各ＭＬのメンバリスト追加・削除を行なう）を受け付ける機能を持っており、各ＭＬ管理サーバ（Ｘ）,（Ｙ）が管理するＭＬ情報に追加・削除があった場合、ＭＬ管理サーバＭＬ情報収集対応部２１からＭＬコマンドによるＭＬ情報の追加・削除要求を受け付け、発信元サーバＭＬ情報管理部１３に通知する。（発信元サーバＭＬ情報管理部１３）  発信元サーバＭＬ情報管理部１３は、発信元サーバＭＬ情報収集部１２で収集したＭＬ情報の管理を行なう。管理するＭＬ情報としては、各ＭＬに登録されているメールアドレスである。また、発信元サーバＭＬ情報収集部１２からのＭＬ情報の追加・削除通知を受け付けると、各ＭＬに登録されているメールアドレスの追加・削除を行なう。
【００４９】
また、ＭＬ情報を管理するＭＬ管理テーブルには、本発明の適用の有無を識別するフラグを設けており、通常時は“無し”とみなすフラグが設定されているが、ＭＬ管理サーバ（Ｘ）,（Ｙ）からＭＬに登録されているメールアドレスの追加・削除要求があった場合、追加・削除通知を受けたＭＬのアドレスとＭＬ管理テーブルに保持しているＭＬアドレスが一致した時には、“有り”とみなすフラグを設定する。（発信元サーバ制御情報加工部１４）  発信元サーバ制御情報加工部１４は、発信元サーバ（Ｓ）からＭＬ管理サーバ（Ｘ）,（Ｙ）へメール送信を行なう段階で、ＭＬ管理サーバ（Ｘ）,（Ｙ）から受信サーバ（Ｅ）への送信の有無を決定するために必要な制御情報を加工する。発信元サーバＭＬ情報管理部１３に登録されているＭＬ情報を元に、各ＭＬに登録されているメールアドレスに重複がないかどうかチェックする。重複するメールアドレスがあれば、メール制御情報の加工処理を行なう。（ＭＬ管理サーバＭＬ情報収集対応部２１）  ＭＬ管理サーバＭＬ情報収集対応部２１は、発信元サーバＭＬ情報収集部１２からのメンバリスト取得要求時に、発信元サーバ（Ｓ）の制御コマンド送信先アドレスを格納し、ＭＬ情報を返信する時にＭＬ管理サーバ（Ｘ）,（Ｙ）に本発明が適用されている場合に、発明適用有りフラグを一緒に返す。
【００５０】
ＭＬ管理サーバ（Ｘ）,（Ｙ）で管理するＭＬのメンバリストに追加・削除があった場合に、発信元サーバ（Ｓ）の制御コマンド送信先アドレス宛てに、発信元サーバＭＬ情報管理部１３で管理するＭＬのメンバリストの追加・削除を行なうメールを送信する。
【００５１】
このように構成すれば、発信元サーバ（Ｓ）で各ＭＬ管理サーバ（Ｘ）,（Ｙ）からエンドユーザ６までのメールの転送を制御し、エンドユーザ６に届くメールを最終的に１つにすることにより、エンドユーザ６のメール重複受信を防ぎ、かつＭＬ管理サーバ（Ｘ）,（Ｙ）から受信サーバ（Ｅ）までのメールのパケット量を削減することで、ネットワーク内の無駄なトラヒック負荷を抑止することができる。（２）請求項２記載の発明は、前記発信元サーバがユーザから電子メール送信要求を受け付けた後、前記発信元サーバＭＬ情報収集部が、前記発信元サーバ構成定義部で定義されている情報を元に、ＭＬ情報の収集をＭＬ管理サーバに依頼した時に、ＭＬ管理サーバのＭＬ管理サーバＭＬ情報収集対応部で発信元サーバの情報を格納しておき、ＭＬ情報が変更された時に格納している発信元サーバ情報を元に、前記ＭＬ管理サーバＭＬ情報収集対応部が自発的に変更対象のＭＬ情報を発信元サーバに送信し、発信元サーバの前記発信元サーバＭＬ情報管理部で管理されているＭＬ情報の変更を行なうことを特徴とする。
【００５２】
このように構成すれば、発信元サーバの発信元サーバＭＬ情報管理部で管理されているＭＬ情報の変更時に生じる負荷を軽減することができる。
【００５３】
請求項３に記載の発明は、発信元サーバ及びＭＬ管理サーバに、前記エンドユーザが設定した受信拒否情報を収集する受信拒否情報収集手段を設け、
前記発信元サーバに、前記受信拒否情報の条件を基にエンドユーザへの送信の有無を決定するために必要な制御情報を加工するサーバ拒否情報加工手段を設けたことにより、エンドユーザの受信拒否の意思をメールサーバに反映させることができる。
【００５４】
請求項４に記載の発明は、発信元サーバ及び受信サーバに、障害が発生したＭＬ管理サーバと前記障害のＭＬ管理サーバを代理する代理サーバ情報を収集する代理サーバ情報収集手段と、
前記代理サーバ情報を基にエンドユーザへの送信の有無を決定するために必要な制御情報を加工し送信する代理サーバ情報加工手段を設けたことにより、ＭＬを管理するメールサーバの障害時に別のメールサーバで代理することができる。
【００５５】
請求項５に記載の発明は、障害のＭＬ管理サーバの配下のエンドユーザに送信できない電子メールを保存し、前記障害のＭＬ管理サーバが復旧したのち前記障害のＭＬ管理サーバの配下のエンドユーザに再送する再送手段を設けたことにより、障害復旧後、発信元ユーザから電子メールを再送する必要が無くなる。
【発明の効果】
【００５６】
本発明によれば、以下のような効果が得られる。（１）請求項１記載の発明によれば、発信元サーバで各ＭＬ管理サーバからエンドユーザまでのメールの転送を制御し、エンドユーザに届くメールを最終的に１つにすることにより、エンドユーザのメール重複受信を防ぎ、かつＭＬ管理サーバから受信サーバまでのメールのパケット量を削減することで、ネットワーク内の無駄なトラヒック負荷を抑止することができる。（２）請求項２記載の発明によれば、発信元サーバの発信元サーバＭＬ情報管理部で管理されているＭＬ情報の変更時に生じる負荷を軽減することができる。
【００５７】
このように、本発明によれば、無駄なトラヒックを抑えて受信者には１通のみのメールしか配信しないようにすることができる電子メール送受信システムを提供することができる。
【００５８】
また、エンドユーザの受信拒否の意思をメールサーバに反映させることができる。
【００５９】
また、ＭＬを管理するメールサーバの障害時に別のメールサーバで代理することができ、更に、障害復旧後、発信元ユーザから電子メールを再送する必要が無くなる。
【発明を実施するための最良の形態】
【００６０】
以下、図面を参照して本発明の実施の形態例を詳細に説明する。
【００６１】
先ず、前記した請求項１と請求項２の動作について詳細に説明する。（請求項１記載の発明の動作）  メールの送信要求を受け付ける発信元サーバ（Ｓ）と、各ＭＬの管理とエンドユーザ２０を配下に持つＭＬ管理サーバ（Ｘ）,（Ｙ）と、エンドユーザ６を配下に持つ受信サーバ（Ｅ）が通信回線（ここでは例えばインターネット）３でネットワーク接続されている。ＭＬ宛てにメール送信を行なうユーザは、発信元サーバ（Ｓ）の発信元サーバ構成定義部１１に、ＭＬを管理するＭＬ管理サーバ（Ｘ）,（Ｙ）からメンバリストを収集するために必要な情報を登録しておく。
【００６２】
発信元サーバ（Ｓ）がユーザからメールの送信要求を受け付けると、発信元サーバＭＬ情報収集部１２は、メールの宛先に指定されているＭＬアドレスと発信元サーバ構成定義部１１で保持している宛先アドレスを比較する。
【００６３】
次に、発信元サーバＭＬ情報収集部１２では、比較一致した宛先アドレスに対応する発信元サーバＭＬ情報管理部１３のＭＬ管理テーブルの発明適用フラグを参照し、発明適用フラグが無効であれば、制御コマンド送信先アドレス、メンバリスト取得コマンド、自サーバ（発信元サーバ（Ｓ））のアドレスを元に、ＭＬメンバリスト要求用のメール情報を生成し、送受信部１ａを経由してＭＬメンバリスト要求をメール送信する。ＭＬ管理サーバ（Ｘ）,（Ｙ）は、メンバリスト取得要求を受け取ると、自サーバが管理しているＭＬのメンバリスト情報を発信元サーバ（Ｓ）に返信する。
【００６４】
発信元サーバＭＬ情報収集部１２では、各ＭＬ管理サーバ（Ｘ）,（Ｙ）からのＭＬメンバリスト返送メールを送受信部１aを経由して受信し、ＭＬ情報を確認後、発信元サーバＭＬ情報管理部１３にＭＬ情報の登録要求を出す。発信元サーバＭＬ情報管理部１３では、ＭＬ情報登録要求を受けると、ＭＬ情報登録要求パラメータ（宛先アドレス、メンバリスト情報）を元に、ＭＬ管理テーブル（ＭＬ毎に管理される）、メンバリスト管理テーブル（ＭＬに登録されているメールアドレスを管理する）を生成後、発信元サーバＭＬ情報収集部１２へＭＬ情報登録の完了通知を出す。
【００６５】
発信元サーバＭＬ情報管理部１３に該当するＭＬ情報を全て登録後、発信元サーバ制御情報加工部１４に対して該当するＭＬ情報をパラメータとして渡す。発信元サーバ制御情報加工部１４において、発信元サーバＭＬ情報管理部１３から受け取るＭＬ情報を元に、重複しているメールアドレスがないかどうかチェックする。
【００６６】
重複しているメールアドレスがある場合には、発信元サーバ（Ｓ）から各ＭＬ管理サーバ（Ｘ）,（Ｙ）へメールを送信する時に必要な制御情報（加工前はＭＬのアドレスになっている）の加工処理を行なう。
【００６７】
先ず、制御情報であるＭＬのアドレスに登録されている全てのメールアドレス一覧を作成する。次に、ＭＬ間で重複しているメールアドレス一覧を作成する。この２つのメールアドレス一覧を元に、各ＭＬ管理サーバ（Ｘ）,（Ｙ）向けの制御情報の加工を行なう。制御情報に指定されているＭＬのアドレスを、全てのメールアドレス一覧に変更する。
【００６８】
次に、重複しているメールアドレス一覧を元に、重複しているメールアドレスを全てのメールアドレス一覧から削除する。但し、重複しているメールアドレスでＭＬ管理サーバ（Ｘ）,（Ｙ）と同一ドメインのものは１つだけ残しておく。
【００６９】
他のＭＬ管理サーバ（Ｘ）,（Ｙ）に対しても同様の手順で該当するＭＬ管理サーバ向けの制御情報を加工していくが、最後に重複しているメールアドレス内で該当するＭＬ管理サーバ（Ｘ）,（Ｙ）以外で管理されているアドレス向けの制御情報とメールヘッダを作成する。
【００７０】
このようにして各メールサーバ（ＭＬ管理サーバを含む）向けの制御情報を加工後、発信元サーバ（Ｓ）からメール送信を行なう。このようにすることで、従来、制御情報にＭＬのアドレスが指定されていたものが、ＭＬ管理サーバ（Ｘ），（Ｙ）からエンドユーザ６間で最適なメール転送が行なわれるように、制御情報を加工している。
【００７１】
各ＭＬ管理サーバ（Ｘ）,（Ｙ）は、メール受信後、制御情報に指定されているメールアドレスを見るが、ＭＬ管理サーバ（Ｘ）,（Ｙ）で受信したメールの制御情報にはＭＬのアドレスではなく自サーバ配下のエンドユーザ２０のメールアドレスのみが入っているため、ＭＬが展開されることがない。
【００７２】
そのため、同一内容メールがＭＬ管理サーバ（Ｘ）,（Ｙ）から重複して転送されることがなくなる。また、重複メールアドレスに関しては個別にその重複メールアドレスを管理するメールサーバへ送信されるので、最終的に重複メールアドレスを持つエンドユーザには１通しかメールが届かないことになる。（請求項２記載の発明の動作）  メールの送信要求を受け付ける発信元サーバ（Ｓ）と、各ＭＬを管理するＭＬ管理サーバ（Ｘ）,（Ｙ）は、通信回線でネットワーク接続されている。ＭＬ管理サーバ（Ｘ）,（Ｙ）は、発信元サーバ（Ｓ）からＭＬ情報収集の依頼があった際に、発信元サーバ（Ｓ）の制御コマンド送信先アドレスをＭＬ管理サーバＭＬ情報収集対応部２１に格納しておく。この時、ＭＬ管理サーバ（Ｘ）、ＭＬ管理サーバ（Ｙ）に本発明が適用されているならば、本発明適用有りを示すフラグをＭＬ情報１、ＭＬ情報２と一緒に発信元サーバ（Ｓ）の制御コマンド送信先アドレスに返信する。
【００７３】
発信元サーバＭＬ情報収集部１２は、ＭＬ管理サーバ（Ｘ）、ＭＬ管理サーバ（Ｙ）からＭＬのメンバリスト返信メールを送受信部１ａ経由で受信後、発信元サーバＭＬ情報管理部１３のＭＬ管理テーブルの発明適用有無フラグを有りにする。それ以降、ＭＬ管理サーバ（Ｘ）、ＭＬ管理サーバ（Ｙ）向けの送信メールを発信元サーバＭＬ情報収集部１２が受け付けた場合、発信元サーバＭＬ情報収集部１２は、発信元サーバＭＬ情報管理部１３にＭＬ管理テーブルの参照を行うことにより、ＭＬ管理サーバ（Ｘ）、ＭＬ管理サーバ（Ｙ）の本発明適用有無フラグのチェックを行なう。チェックの結果、発明が適用されていることが分かると、ＭＬ管理サーバ（Ｘ）、ＭＬ管理サーバ（Ｙ）に対してＭＬ情報の収集を行なわない。
【００７４】
また、ＭＬ管理サーバ（Ｘ）,（Ｙ）が管理するＭＬのメンバリストに追加が発生した場合に、ＭＬ情報収集対応部２１は保存している発信元サーバの制御コマンド送信先アドレス宛てに、追加対象のメールアドレスを追加コマンドにより、発信元サーバ（Ｓ）の発信元サーバＭＬ情報収集部１２に送信する。
【００７５】
同様に、ＭＬのメンバリストに削除が生じた場合に、削除対象のメールアドレスを削除コマンドにより、発信元サーバ（Ｓ）の発信元サーバＭＬ情報収集部１２に送信する。各ＭＬ管理サーバ（Ｘ）,（Ｙ）からの追加・削除要求を受け付けた発信元サーバ（Ｓ）の発信元サーバＭＬ情報収集部１２は、発信元サーバＭＬ情報管理部１３に該当するＭＬ情報（ＭＬのアドレス、追加・削除対象メールアドレス）をパラメータとして追加・削除要求を通知する。
【００７６】
発信元サーバＭＬ情報管理部１３は、発信元サーバＭＬ情報収集部１２から追加・削除要求を通知されると、パラメータのＭＬ情報を元にＭＬ管理テーブルから追加・削除対象のＭＬを検索し、一致したＭＬの管理テーブル内の発明適用有無フラグ情報を有効に設定する。
【００７７】
追加要求の場合には、一致したＭＬのメンバリスト管理テーブルに追加対象のメールアドレスを追加し、削除要求の場合は一致したＭＬのメンバリスト管理テーブルから削除対象のメールアドレスを検索し、該当するメールアドレスがあれば削除を行なう。
【００７８】
追加・削除が完了すると、発信元サーバＭＬ情報管理部１３は、発信元サーバＭＬ情報収集部１２に変更完了の通知を返す。以降、発信元のユーザが発信元サーバ（Ｓ）に対して発信元サーバ構成定義部１１に登録しているＭＬを指定してメール送信要求を行なった場合、発信元サーバＭＬ情報収集部１２から該当するＭＬのＭＬ情報が登録されているかどうか、発信元サーバＭＬ情報管理部１３にＭＬ管理テーブルの参照が行なわれる。ＭＬ管理テーブルの参照により該当するＭＬの管理テーブル内の発明適用フラグをチェックし、発明有りのフラグであれば、以降そのＭＬに関してはＭＬ情報の収集を行なわないようにする。
【００７９】
このように、発信元サーバ（Ｓ）にネットワークが接続されているＭＬ管理サーバ（Ｘ）,（Ｙ）に本発明（ＭＬ情報変更通知）が適用されることにより、請求項１でメール送信要求毎にメンバリストの取得をする際に発生するネットワークトラヒックの負荷を軽減することができる。（請求項１の実施の形態例）  図２は本発明の第１の実施の形態例を示すブロック図で、請求項１の実施の形態例を示す。図１と同一のものは、同一の符号を付して示す。ここでは、発信元サーバ（Ｓ）をメールサーバ１、ＭＬ管理サーバ（Ｘ）とＭＬ管理サーバ（Ｙ）をそれぞれメールサーバ２、メールサーバ３、受信サーバ（Ｅ）をメールサーバ４としてそれぞれ示している。
【００８０】
メールサーバ１は、発信元サーバ構成定義部１１と、発信元サーバＭＬ情報収集部１２と、発信元サーバＭＬ情報管理部１３と、発信元サーバ制御情報加工部１４と、送受信部１ａにより構成されたメールサーバである。メールサーバ２とメールサーバ３は、送受信部２ａにより構成されたメールサーバである。メールサーバ２はＭＬ情報１を、メールサーバ３はＭＬ情報２を管理しているＭＬ管理サーバでもある。メールサーバ４は、送受信部４ａにより構成されたメールサーバである。
【００８１】
メールサーバ１〜４は、それぞれ通信回線によりネットワーク接続されている。メールサーバ１配下には、端末ａが、メールサーバ２配下には端末ｂ、端末ｃが、メールサーバ３配下には端末ｄ、端末ｅが、メールサーバ４配下には端末ｆがそれぞれ通信回線により接続されている。この内、端末ａは図１の送信元ユーザであり、端末ｂ〜ｅは図１のユーザ端末２０であり、端末ｆは図１のエンドユーザ６である。このように構成されたシステムの動作を以下に説明する。
【００８２】
端末ａから構成定義登録要求を受けた発信元サーバ構成定義部１１は、図３に示すようにメールサーバ２の宛先アドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ）、制御コマンド送信先アドレス（Ｘ−ｃｔｌ＠ｘｘｘ．ｃｏ．ｊｐ）、メンバリスト取得コマンド（ｍｅｍｂｅｒ−ｌｉｓｔ  ｍｅｍｂｅｒｓ）、メールサーバ３の宛先アドレス（Ｙ＠ｙｙｙ．ｃｏｍ）、制御コマンド送信先アドレス（Ｙ−ｃｔｌ＠ｙｙｙ．ｃｏｍ）、メンバリスト取得コマンド（ｍｅｍｂｅｒ−ｌｉｓｔ  ｌｉｓｔ）情報を保持する。
【００８３】
これらの構成定義情報は、ＭＬ情報１及びＭＬ情報２の管理元であるメールサーバ２及びメールサーバ３からＭＬ情報を収集するために必要となる基本情報である。
【００８４】
図４は請求項１のシーケンス例を示す図である。図は、端末ａと、発信元サーバ構成定義部と、発信元サーバＭＬ情報収集部と、発信元サーバＭＬ情報管理部と、発信元サーバ制御情報加工部と、送受信部と、メールサーバ２と、メールサーバ３と、メールサーバ４と、エンドユーザ（図２参照）間の情報のやりとりを示している。
【００８５】
上述の構成定義情報設定後に、ＭＬアドレス１（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ）及びＭＬアドレス２（Ｙ＠ｙｙｙ．ｃｏｍ）を宛先に指定したメール送信要求（１−１）を端末ａよりメールサーバ１の発信元サーバＭＬ情報収集部１２が受信すると、該発信元サーバＭＬ情報収集部１２では、宛先に指定されているＭＬアドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ、Ｙ＠ｙｙｙ．ｃｏｍ）と、発信元サーバ構成定義部１１で保持している宛先アドレスを比較する（１−２）。
【００８６】
次に、発信元サーバＭＬ情報収集部１２では、比較して一致した宛先アドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ、Ｙ＠ｙｙｙ．ｃｏｍ）に対応した発信元サーバＭＬ情報管理部１３のＭＬ管理テーブルの発明適用有無フラグを参照する。そして、参照の結果、発明適用有無フラグが適用無し（“０”）であれば、制御コマンド送信先アドレス、メンバリスト取得コマンド情報及び自サーバ（メールサーバ１）のアドレスを元に、ＭＬメンバリスト要求用のメール情報を生成し、送受信部１ａを経由してＭＬメンバリスト要求をメール送信する（１−３，１−５）。
【００８７】
ＭＬ情報１を管理しているメールサーバ２及びＭＬ情報２を管理しているメールサーバ３では、ＭＬメンバリスト要求用のメールを送受信部２aで受信すると、メンバリスト情報をＭＬメンバリスト返送メールとしてメールサーバ１へ返信する（１−４，１−６）。
【００８８】
図５はＭＬメンバリスト取得方法の説明図である。メール送信元端末５から、ＭＬ管理サーバ（Ｘ）宛てのメールが送信されると、発信元サーバ（Ｓ）はＭＬ管理サーバ（Ｘ）の制御コマンド送信先アドレス（Ｘ−ｃｔｌ＠ｘｘｘ．ｃｏ．ｊｐ）に対してＭＬ管理サーバ（Ｘ）が管理しているＭＬメンバリストを取得するためのメールを出す。
【００８９】
メール本文に「ｍｅｍｂｅｒｓ」という制御コマンドが書かれている。ＭＬ管理サーバ（Ｘ）は、ＭＬメンバリスト取得メールを受信後、メール本文に書かれている制御コマンドに従い、ＭＬ管理サーバＸのＭＬメンバリストをメール本文に記述して、発信元サーバ（Ｓ）の制御コマンド送信先アドレス（Ｘ−ｃｔｌ＠ｘｘｘ．ｃｏ．ｊｐ）に送信する。発信元サーバ（Ｓ）は、メールを受信することで、ＭＬ管理サーバ（Ｘ）のＭＬメンバリストを取得することができる。
【００９０】
再び図４の説明に戻る。発信元サーバＭＬ情報収集部１２では、ＭＬメンバリスト返送メールを送受信部１ａ経由でメールサーバ２より受信すると、ＭＬメンバリスト返送メールの送信元アドレス（Ｘ−ｃｔｌ＠ｘｘｘ．ｃｏ．ｊｐ）と、発信元サーバ構成定義部１１で保持している制御コマンド送信先アドレスを比較し、一致した該当の宛先アドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ）情報と、返送メール内のメンバリスト情報をパラメータとして、発信元サーバＭＬ情報管理部１３へＭＬ情報登録要求を行なう（１−７）。
【００９１】
また、同様にメールサーバ３よりＭＬメンバリスト返送メールを受信した場合も、比較処理を実施し、宛先アドレス（Ｙ＠ｙｙｙ．ｃｏｍ）情報とメンバリスト情報をパラメータとして、ＭＬ情報登録要求を行なう（１−９）。
【００９２】
発信元サーバＭＬ情報管理部１３では、ＭＬ情報登録要求（１−７，１−９）を受けると、ＭＬ情報登録要求パラメータ（宛先アドレス・メンバリスト情報）を元に、ＭＬ管理テーブル及びメンバリスト管理テーブルを作成した後、発信元サーバＭＬ情報収集部１２へＭＬ情報登録完了を通知する（１−８，１−１０）。
【００９３】
ＭＬ管理テーブルの構成は、管理ＭＬ数（ＭＬ  ｎｕｍ），各ＭＬ毎にＭＬアドレス（ＭＬ  ａｄｄｒｅｓｓ）・発明適用有無フラグ（ＭＬ  ｅｎａｂｌｅ  ｆｌａｇ）・メンバリスト管理テーブル先頭ポインタ（ｍｅｍｂｅｒ  ｌｉｓｔ  ｐｏｉｎｔｅｒ）・メンバリスト登録数（ｍｅｍｂｅｒ  ｌｉｓｔ  ｎｕｍ）となっている。
【００９４】
ＭＬ情報登録時には管理ＭＬ数（ＭＬ  ｎｕｍ）がインクリメント（＋１）され、発明適用有無フラグ（ＭＬ  ｅｎａｂｌｅ  ｆｌａｇ）は無し（“０”）として初期登録される。また、メンバリスト管理テーブル（２次テーブル）の構成は、メンバリスト情報（ｍｅｍｂｅｒ  ａｄｄｒｅｓｓ  ｎ）である。メールサーバ２、メールサーバ３用のＭＬ情報登録要求に対するＭＬ管理テーブル・メンバリスト管理テーブルの生成後情報を図６に示す。
【００９５】
図６において、３０はＭＬ管理テーブルを、３１はＭＬ管理テーブル３０と対応付けられるメンバリスト管理テーブルを示している。ＭＬ管理テーブル３０において、ＭＬ  ｎｕｍは管理しているＭＬの数を示す。ここでは「２」個管理していることを示す。ＭＬ  ａｄｄｒｅｓｓはＭＬの電子メールアドレスを表わす。ＭＬ  ｅｎａｂｌｅ  ｆｌａｇは、ＭＬの発明適用の有無を表わす。“０”の場合には無し、“１”の場合には有りである。
【００９６】
ｍｅｍｂｅｒ  ｌｉｓｔ  ｐｏｉｎｔｅｒは、ＭＬアドレスであるＭＬのメンバリストをポイントするものである。ｍｅｍｂｅｒ  ｌｉｓｔ  ｎｕｍはＭＬアドレスであるＭＬのメンバリスト内登録数を示す。ＭＬ管理テーブル３０のｍｅｍｂｅｒ  ｌｉｓｔ  ｐｏｉｎｔｅｒで示されるアドレス（ＸＸＸ）とメンバリスト管理テーブル３１とが対応付けられる。メンバリスト管理テーブルのｍｅｍｂｅｒ  ａｄｄｒｅｓｓは、ＭＬアドレスであるＭＬのメンバのメールアドレスを表わす。
【００９７】
再び、図４の説明に戻る。発信元サーバＭＬ情報収集部１２では、予めＭＬメンバリスト要求（１−３，１−５）の数を予め覚えておき、発信元サーバＭＬ情報管理部１３からのＭＬ情報登録完了（１−８，１−１０）数と一致すると、発信元サーバ制御情報加工部１４へ宛先アドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ、Ｙ＠ｙｙｙ．ｃｏｍ）をパラメータとして、ＭＬ制御情報加工要求（１−１１）を通知する。
【００９８】
発信元サーバ制御情報加工部１４において、ＭＬ制御情報加工要求（１−１１）を受けると、パラメータである宛先アドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ、Ｙ＠ｙｙｙ．ｃｏｍ）に対応するメンバリスト管理テーブル３１のメンバ情報を元に、重複しているメンバ（メールアドレス）がないかどうかチェックを行なう。本実施の形態例の場合、重複しているメールアドレス（ｂｂｂ＠ｙｙｙ．ｃｏｍ、ｄｄｄ＠ｘｘｘ．ｃｏ．ｊｐ、ｅｅｅ＠ｚｚｚ．ｎｅ．ｊｐ）が存在するので、各ＭＬ管理サーバ（メールサーバ２，メールサーバ３）に送信するメール制御情報の加工処理を行なう。
【００９９】
制御情報「ＲＣＰＴ  ＴＯ」に指定されているアドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ、Ｙ＠ｙｙｙ．ｃｏｍ）に対応する、メンバリスト管理テーブル３１のメンバ情報を元に全ての個人アドレスを個人アドレス情報として作成する。本実施の形態例では、ａａａ＠ｘｘｘ．ｃｏ．ｊｐ，ｂｂｂ＠ｙｙｙ．ｃｏｍ，ｄｄｄ＠ｘｘｘ．ｃｏ．ｊｐ，ｅｅｅ＠ｚｚｚ．ｎｅ．ｊｐ，ｃｃｃ＠ｙｙｙ．ｃｏｍ，ｅｅｅ＠ｚｚｚ．ｎｅ．ｊｐとなる。次に、メンバ情報で重複しているアドレス情報を作成する（ｂｂｂ＠ｙｙｙ．ｃｏｍ、ｄｄｄ＠ｘｘｘ．ｃｏ．ｊｐ、ｅｅｅ＠ｚｚｚ．ｎｅ．ｊｐ）。
【０１００】
作成した個人アドレス情報、重複アドレス情報を元にメールサーバ２向けの制御情報の加工を以下に示すように実施する。
【０１０１】
「ＲＣＰＴ  ＴＯ」に指定されているＭＬのアドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ、Ｙ＠ｙｙｙ．ｃｏｍ）を個人アドレス情報に変更する。次に、重複アドレス情報を元に重複しているアドレスを個人アドレス情報から削除する。但し、メールサーバ２と同一ドメイン（ｘｘｘ．ｃｏ．ｊｐ）の重複しているアドレス（ｄｄｄ＠ｘｘｘ．ｃｏ．ｊｐ）は１つだけ残しておく。
【０１０２】
図７は発信元サーバによる各メールサーバ向けの制御情報修正の説明図である。図２と同一のものは、同一の符号を付して示す。図７の制御情報１のような制御情報が加工される。メールサーバ３向けの制御情報の加工も同一の手順で実施する。そして、制御情報２のような制御情報が加工される。最後に重複しているアドレス内で、メールサーバ２，メールサーバ３以外で管理されているアドレス向け（ｅｅｅ＠ｚｚｚ．ｎｅ．ｊｐ）用の制御情報とメールヘッダを作成する。図７の制御情報３のような制御情報とメールヘッダが生成される。
【０１０３】
各ＭＬ管理サーバ（メールサーバ２，メールサーバ３）はメールの配信先アドレスを、ヘッダ部の「ＴＯ」ではなく、制御情報である「ＲＣＰＴ  ＴＯ」にて決定しているため、制御情報の加工対象は「ＲＣＰＴ  ＴＯ」となる。それぞれの制御情報の加工が終わると、送受信部１ａを経由してメール送信を行なう（１−１２，１−１４，１−１６）。
【０１０４】
このように、送信元サーバで受信サーバ向けの制御情報を加工することにより、メールサーバ２には、図７の制御情報１で示される制御情報（ａａａ＠ｘｘｘ．ｃｏ．ｊｐ、ｄｄｄ＠ｘｘｘ．ｃｏ．ｊｐ）が送信され、メールサーバ２配下のエンドユーザ（端末ｂ，ｃ）にメール配信が行なわれる（１−１３）。
【０１０５】
メールサーバ３には、図７の制御情報２で示される制御情報（ｂｂｂ＠ｙｙｙ．ｃｏｍ、ｃｃｃ＠ｙｙｙ．ｃｏｍ）が送信され、メールサーバ３配下のエンドユーザ（端末ｄ，ｅ）に配信が行なわれる（１−１５）。メールサーバ４には、図７の制御情報３で示される制御情報（ｅｅｅ＠ｚｚｚ．ｎｅ．ｊｐ）が送信され、メールサーバ４配下のエンドユーザ（端末ｆ）に配信が行なわれる（１−１７）。
【０１０６】
このように、請求項１記載の発明によれば、各メールサーバ配下全てのエンドユーザが、同一メールを複数受信することを防ぐことができ、また、従来メールの転送が行われていたルート（メールサーバ２←→メールサーバ３間、メールサーバ２←→メールサーバ４間、メールサーバ３←→メールサーバ４間）の転送が無くなるため（図７のルート４０を使用するため）、ネットワーク内の電子メールパケットによる負荷を抑止することができる。（請求項２の実施の形態例）  図８は本発明の第２の実施の形態例を示すブロック図であり、請求項２の実施の形態例を示す。図１、図２と同一のものは、同一の符号を付して示す。メールサーバ１は発信元サーバ構成定義部１１と、発信元サーバＭＬ情報収集部１２と、発信元サーバＭＬ情報管理部１３と、送受信部１ａとにより構成されたメールサーバである。メールサーバ２とメールサーバ３は、ＭＬ管理サーバＭＬ情報収集対応部２１と送受信部２ａとにより構成されたメールサーバである。また、メールサーバ２はＭＬ情報１を、メールサーバ３はＭＬ情報２を管理しているＭＬ管理サーバでもある。メールサーバ１、メールサーバ２、メールサーバ３は、それぞれ通信回線によりネットワーク接続されている。図の太い実線が通信回線、細い実線が本発明に必要なデータの流れを示す。
【０１０７】
図９は請求項２の動作シーケンス例を示す図である。図４と同一のものは、同一の表示で示す。
【０１０８】
発信元サーバＭＬ情報収集部１２からＭＬのメンバリスト要求を出すまでは請求項１の実施の形態例と同じ手順を踏むものとする。構成定義情報設定後に、ＭＬアドレス１（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ）及びＭＬアドレス２（Ｙ＠ｙｙｙ．ｃｏｍ）を宛先に指定したメール送信要求を端末ａよりメールサーバ１の発信元サーバＭＬ情報収集部１２が受信すると、発信元サーバＭＬ情報収集部１２では、宛先に指定されているＭＬアドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ、Ｙ＠ｙｙｙ．ｃｏｍ）と、発信元サーバ構成定義部１１で保持している宛先アドレスを比較する。
【０１０９】
次に、発信元サーバＭＬ情報収集部１２では、比較一致した宛先アドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ、Ｙ＠ｙｙｙ．ｃｏｍ）に対応した、制御コマンド送信先アドレス、メンバリスト取得コマンド情報及び自サーバ（メールサーバ１）のアドレスを元に、ＭＬメンバリスト要求用のメール情報を生成し、送受信部１ａを経由してＭＬメンバリスト要求をメール送信する。
【０１１０】
ＭＬ情報１を管理しているメールサーバ２及びＭＬ情報２を管理しているメールサーバ３では、メンバリスト取得コマンド要求を受けた時に、ＭＬ管理サーバＭＬ情報収集対応部２１にてメールサーバ１の制御コマンド送信先アドレス（Ｓ−ｃｔｌ＠ｘｘｘ．ｃｏｍ）を格納しておく。
【０１１１】
この時、メールサーバ２及びメールサーバ３に本発明が適用されているならば、本発明適用を示すフラグをＭＬ情報１、ＭＬ情報２と一緒にメールサーバ１の制御コマンド送信先アドレス（Ｓ−ｃｔｌ＠ｘｘｘ．ｃｏｍ）に返信する（２−１,２−２）。
【０１１２】
発信元サーバＭＬ情報収集部１２は、メールサーバ２及びメールサーバ３からのＭＬのメンバリスト返信メールを送受信部１ａ経由で受信後、一緒に受け取った発明適用フラグを発信元サーバＭＬ情報管理部１３のＭＬ管理テーブル３０（図６参照）の発明適用有無フラグに適用有り（“１”）を反映させる。
【０１１３】
それ以降、メールサーバ２、メールサーバ３向けの送信メールを発信元サーバＭＬ情報収集部１２が受け付けた場合、発信元サーバＭＬ情報収集部１２は、発信元サーバＭＬ情報管理部１３にＭＬ情報参照（２−３）によりメールサーバ２、メールサーバ３の本発明適用有無フラグのチェックを行ない、適用されていることが分かると、メールサーバ２、メールサーバ３に対してＭＬ情報の収集を行なわない。
【０１１４】
また、メールサーバ２、メールサーバ３のＭＬ管理サーバＭＬ情報収集対応部２１は、自サーバが管理するＭＬのメンバリストに追加・削除の変更があった場合、図１０に示されるように、メールサーバ２においては、メンバリストから（ｄｄｄ＠ｘｘｘ．ｃｏ．ｊｐ）が削除されたので、格納されているメールサーバ１の制御コマンド送信先アドレス（Ｓ−ｃｔｌ＠ｘｘｘ．ｃｏｍ）に対して、メンバリスト削除コマンドと削除対象となるメールアドレス（ｄｄｄ＠ｘｘｘ．ｃｏ．ｊｐ）と、自サーバ（メールサーバ２）のアドレスを元に、ＭＬメンバリスト削除要求用のメール情報を生成し、送受信部２ａを経由してＭＬメンバリスト削除要求をメール送信する（２−４）。
【０１１５】
図１０はＭＬメンバリスト（追加・削除）通知方法の説明図である。メールサーバ２で管理するＭＬメンバリストからメールアドレス（ｄｄｄ＠ｘｘｘ．ｃｏ．ｊｐ）が削除されたため、メールサーバ２は、発信元サーバＳの制御コマンド送信先アドレス（Ｓ−ｃｔｌ＠ｘｘｘ．ｃｏｍ）に対して削除通知を行なうためにメールを出す。
【０１１６】
メール本文には、（ｂｙｅ＜削除対象アドレス＞）という制御コマンドが書かれている。同様に、メールサーバ３で管理するＭＬメンバリストにメールアドレス（ｆｆｆ＠ｙｙｙ．ｃｏｍ）が追加されたため、ＭＬ管理サーバＹは発信元サーバＳの制御コマンド送信先アドレスに対して追加通知を行なうためにメールを出す。
【０１１７】
メール本文には、（ｓｕｂｓｃｒｉｂｅ＜追加対象アドレス＞）という制御コマンドが書かれている。発信元サーバＳは、それぞれ各ＭＬ管理サーバからのＭＬメンバリスト（追加・削除）通知メールを受信する。
【０１１８】
再び図９の説明に戻る。メールサーバ３においては、メンバリストに（ｆｆｆ＠ｙｙｙ．ｃｏｍ）が追加されたので、削除時と同様に宛先（Ｓ−ｃｔｌ＠ｘｘｘ．ｃｏｍ）に対して、メンバリスト追加コマンドと追加対象となるメールアドレス（ｆｆｆ＠ｙｙｙ．ｃｏｍ）と、自サーバ（メールサーバ３）のアドレスを元に、ＭＬメンバリスト追加要求用のメール情報を生成し、送受信部２ａを経由してＭＬメンバリスト追加要求をメール送信する（２−５）。
【０１１９】
発信元サーバＭＬ情報収集部１２では、ＭＬメンバリスト返送メールをメールサーバ２より受信すると、ＭＬメンバリスト返送メールの送信元アドレス（Ｘ−ｃｔｌ＠ｘｘｘ．ｃｏ．ｊｐ）と、発信元サーバ構成定義部１１で保持している制御コマンド送信先アドレスを比較し、一致した該当の宛先アドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ）情報と、返送メール内のメンバリスト情報と、発明適用フラグ（“１”）をパラメータとし、発信元サーバＭＬ情報管理部１３へＭＬ情報登録要求を行なう。
【０１２０】
また、同様にメールサーバ３よりＭＬメンバリスト返送メールを受信した場合も、比較処理を実施し、宛先アドレス（Ｙ＠ｙｙｙ．ｃｏｍ）情報とメンバリスト情報と、発明適用フラグ（“１”）をパラメータとし、ＭＬ情報登録要求を行なう。
【０１２１】
また、ＭＬメンバリスト削除要求を送受信部１ａ経由でメールサーバ２より受信すると、ＭＬメンバリスト削除要求メールの送信元アドレス（Ｘ−ｃｔｌ＠ｘｘｘ．ｃｏ．ｊｐ）と、発信元サーバ構成定義部１１で保持している制御コマンド送信先アドレスを比較し、一致した該当の宛先アドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ）情報と、削除要求メール内の削除対象メールアドレス（ｄｄｄ＠ｘｘｘ．ｃｏ．ｊｐ）をパラメータとし、発信元サーバＭＬ情報管理部１３へＭＬ情報削除要求を行なう（２−６）。
【０１２２】
また、同様にメールサーバ３よりＭＬメンバリスト追加要求を受信した場合も、比較処理を実施し、宛先アドレス（Ｙ＠ｙｙｙ．ｃｏｍ）と追加要求メール内の追加対象メールアドレス（ｆｆｆ＠ｙｙｙ．ｃｏｍ）をパラメータとし、ＭＬ情報追加要求を行なう（２−８）。
【０１２３】
発信元サーバＭＬ情報管理部１３では、ＭＬ情報登録要求を受けると、ＭＬ情報登録要求パラメータ（宛先アドレス、メンバリスト情報、発明適用フラグ）を元に、ＭＬ管理テーブル３０及びメンバリスト管理テーブル３１を生成する。この時、パラメータの発明適用フラグが“１”なので、該当するＭＬアドレスの発明適用有無フラグに有り（“１”）を設定する。
【０１２４】
また、ＭＬ情報削除要求（２−６）を受けると、宛先アドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ）を元にＭＬ管理テーブル３０内のＭＬアドレスを検索し、一致するものがあれば、該当するＭＬアドレスの発明適用有無フラグを有り（“１”）、ＭＬアドレスであるＭＬのメンバリスト登録数（ｍｅｍｂｅｒ  ｌｉｓｔ  ｎｕｍ）がデクリメント（−１）され、メンバリスト管理テーブル３１から削除対象メールアドレス（ｄｄｄ＠ｘｘｘ．ｃｏ．ｊｐ）を元に検索し、該当するものがあれば削除を行なう。
【０１２５】
削除が完了した後、発信元サーバＭＬ情報収集部１２へＭＬ情報削除完了を通知する（２−７）。また、ＭＬ情報追加要求（２−８）を受けると、宛先アドレス（Ｙ＠ｙｙｙ．ｃｏｍ）を元にＭＬ管理テーブル３０内のＭＬアドレスを検索し、一致するものがあれば、該当するＭＬアドレスの発明適用有無フラグを有り（“１”）、ＭＬアドレスであるＭＬのメンバリスト登録数（ｍｅｍｂｅｒ  ｌｉｓｔ  ｎｕｍ）がインクリメント（＋１）された後、メンバリスト管理テーブル３１から、追加対象メールアドレス（ｆｆｆ＠ｙｙｙ．ｃｏｍ）を元に検索し、該当するものがあれば何もせず、該当するものがなければ追加を行なう。追加が終了した後、発信元サーバＭＬ情報収集部１２へＭＬ情報追加完了を通知する（２−９）。
【０１２６】
ＭＬアドレス１（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ）及びＭＬアドレス２（Ｙ＠ｙｙｙ．ｃｏｍ）を宛先に指定したメール送信要求（２−１０）を端末ａからメールサーバ１の発信元サーバＭＬ情報収集部１２が受信すると、発信元サーバ構成定義部１１で保持している宛先アドレスと比較する（２−１１）。比較後、発信元サーバＭＬ情報収集部１２は、比較一致した宛先アドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ、Ｙ＠ｙｙｙ．ｃｏｍ）情報をパラメータとして発信元サーバＭＬ情報管理部１３へＭＬ情報参照を行なう（２−１２）。
【０１２７】
ＭＬ情報参照によりメールサーバ２、メールサーバ３の本発明適用有無フラグのチェックを行ない、適用されていることが分かると、メールサーバ２、メールサーバ３に対してＭＬ情報の収集を行なわない。このように、発信元サーバにネットワーク接続されているメールサーバに本発明が適用されることにより、請求項１でメール送信要求受付時のメンバリスト取得時に生じるネットワークトラヒックの負荷を軽減することができる。
【０１２８】
図１１はＭＬ情報追加・削除時のＭＬ管理テーブルとメンバリスト管理テーブルの構成例を示す図である。発信元サーバ（Ｓ）にＭＬ管理サーバ（Ｘ）,（Ｙ）からＭＬメンバリストの追加・削除通知がくると、発信元サーバＭＬ情報収集部１２が宛先アドレス（Ｘ＠ｘｘｘ．ｃｏ．ｊｐ）を元にＭＬ管理テーブル３０内のＭＬアドレス（ＭＬ  ａｄｄｒｅｓｓ）を検索し、一致するものがあれば、該当するＭＬアドレスの発明適用有無フラグ（ＭＬ  ｅｎａｂｌｅ  ｆｌａｇ）を“１”、ＭＬのメンバリスト数（ｍｅｍｂｅｒ  ｌｉｓｔ  ｎｕｍ）が削除対象メールアドレス分減らされ（−１）、メンバリスト管理テーブル３１から削除対象メールアドレス（ｄｄｄ＠ｘｘｘ．ｃｏ．ｊｐ）を元に検索し、該当するものがあれば、削除を行なう。
【０１２９】
同様に、宛先アドレス（Ｙ＠ｙｙｙ．ｃｏｍ）を元にＭＬ管理テーブル３０内のＭＬアドレス（ＭＬ  ａｄｄｒｅｓｓ）を検索し、一致するものがあれば、該当するＭＬアドレスの発明適用有無フラグを有り（“１”）、ＭＬのメンバリスト登録数（ｍｅｍｂｅｒ  ｌｉｓｔ  ｎｕｍ）が追加対象メールアドレス分追加され（＋１）、メンバリスト管理テーブル３１から追加対象メールアドレス（ｆｆｆ＠ｙｙｙ．ｃｏｍ）を元に検索し、該当するものがあれば何もせず、該当するものがなければ追加を行なう。
【０１３０】
このように、本発明によれば、従来は同一内容のメールが複数通、受信者に配信されていたような場合が、１通のみの配信とすることができ、これによって、以下のような効果が得られる。
（１）受信者は、同一内容メールを重複受信することがなくなり、同一内容のメールを読む時間を無駄にしたり、メール保存のために自端末の記憶領域を同一メールで無駄に使用することがなくなる。
（２）メールの宛先である受信者を収容するメールサーバ（ＰＯＰサーバ）においても、当該受信者宛てに同一内容のメールを複数通受けることがなくなるので、メール保存のための記憶領域を同一メールで無駄に使用することがなくなる。
（３）ネットワーク上に同一内容の無駄なメールが送られることがなくなり、従来よりも無駄なトラヒックがなくなる。
（４）ファイルが添付されている同一内容メールが重複して送信されなくなることにより、従来よりも無駄なトラヒックがなくなる。
【０１３１】
図１２は、本発明の第３の実施の形態例の原理ブロック図を示す。同図中、発信元サーバ１Ａには、送受信部１ａ、発信元サーバ構成定義部１１、発信元サーバＭＬ情報収集部１２、発信元サーバＭＬ情報管理部１３、発信元サーバ制御情報加工部１４の他に、サーバ拒否情報収集部１５，サーバ拒否情報管理部１６，サーバ拒否情報加工部１７を設け、ＭＬ管理サーバ２Ａには、送受信部２ａ、ＭＬ管理サーバＭＬ情報収集対応部２１の他に、サーバ拒否情報収集部１５，サーバ拒否情報管理部１６を設ける。発信元サーバ１Ａには発信元ユーザＳ１が接続され、受信サーバ４にはエンドユーザＥ１，Ｅ２が接続されている。
【０１３２】
サーバ拒否情報収集部１５は、エンドユーザが特定のＭＬのスレッドや話題に関するメールの受信を拒否するために必要な情報として、エンドユーザがメッセージＩＤ情報やトピックス情報（以降、これらを「サーバ拒否情報」と呼ぶ）をメールのヘッダ部に付加し、そのメールをＭＬ管理サーバ２Ａに対して送信を行った時に、ＭＬ管理サーバ２Ａ側の送受信部２ａで受信するが、このサーバ拒否情報を送受信部１ａ，２ａから収集し、サーバ拒否情報管理部１６に通知する。
【０１３３】
サーバ拒否情報管理部１６は、サーバ拒否情報収集部１５からサーバ拒否情報の通知をパラメータと共に受付け、サーバ拒否情報の管理を行う。管理する情報としては、各ＭＬ管理テーブルに登録されているメンバリストのメンバ毎に、エンドユーザがメールの受信拒否指定をどのパラメータで決定する必要があるか識別するテーブル識別フラグ３２と、メッセージＩＤ情報を管理するメッセージＩＤ情報拒否テーブル３３と、トピックス情報を管理するトピックス情報拒否テーブル３４がある。
【０１３４】
また、サーバ拒否情報収集部１５からサーバ拒否情報と共にサーバ拒否情報の通知を受けると、そのサーバ拒否情報を指定するエンドユーザが登録されているＭＬのテーブル識別情報を確認し、サーバ拒否情報に指定されたテーブル識別情報がメッセージＩＤ情報ならばメッセージＩＤ情報拒否テーブルからメッセージＩＤ情報を参照し、トピックス情報ならばトピックス情報拒否テーブルからトピックス情報を参照する。
【０１３５】
サーバ拒否情報加工部１７は、発信元サーバ１ＡからＭＬ管理サーバ２Ａにメールの送信を行う前に、発信元サーバ制御情報加工部１４においてＭＬ管理サーバ２Ａから受信サーバ４への送信の有無を決定するために加工した制御情報を受け取り、さらにサーバ拒否情報管理部１６に登録されているサーバ拒否情報を基に、制御情報中に受信拒否を指定しているエンドユーザがいないかチェックを行う。該当するものがあれば、制御情報からそのエンドユーザのメールアドレスを削除する。
【０１３６】
ここで、エンドユーザＥ１、Ｅ２がＭＬ管理サーバ２Ａから転送されるメールについて受信を拒否したい場合、受信したメールのスレッド（メール１通毎に自動付加されるメッセージＩＤ）やトピックス（メールのサブジェクト（題名）に含まれるものとする）をメールヘッダに付加し、ＭＬ管理サーバ２Ａにメールを送信する。
【０１３７】
ＭＬ管理サーバ２Ａの送受信部２ａがエンドユーザＥ１，Ｅ２から、メールヘッダにサーバ拒否情報が付加されているメールを受信すると、サーバ拒否情報収集部１５は、サーバ拒否情報（エンドユーザＥ１、Ｅ２のメールアドレス、及び受信拒否を識別するための情報である、テーブル識別情報（メッセージＩＤ情報、トピックス情報）を抽出後、ＭＬ管理サーバ２Ａのサーバ拒否情報管理部１６に通知する。
【０１３８】
ＭＬ管理サーバ２Ａのサーバ拒否情報管理部１６はサーバ拒否情報の設定通知を受けつけると、サーバ拒否情報（エンドユーザＥ１、Ｅ２のメールアドレスと、テーブル識別情報）と、ＭＬ管理サーバ２Ａの発信元サーバＭＬ情報管理部１３で管理されているＭＬ情報を基に、まずメンバ―リスト管理テーブル３１に登録されているメンバ毎に、テーブル識別情報がメッセージＩＤ情報なら“１”をトピックス情報なら“２”を、どちらも指定されていたら“３”をテーブル識別フラグ３２に設定し、“１”ならメッセージＩＤ情報拒否テーブル３３を、“２”ならトピックス情報拒否テーブル３４を、“３”なら両テーブルを生成後、ＭＬ管理サーバ２Ａのサーバ拒否情報収集部１５にサーバ拒否情報の設定完了通知を出す。
【０１３９】
設定完了通知を受けたＭＬ管理サーバ２Ａのサーバ拒否情報収集部１５は、ＭＬ管理サーバ２ＡのＭＬ管理サーバＭＬ情報収集対応部２１で取得している発信元サーバ１ＡのＭＬアドレスを基にサーバ拒否情報をメールヘッダに付加した後、メールで送信する。発信元サーバ１Ａの送受信部１ａで受けたサーバ拒否情報メールに付加されているサーバ拒否情報をサーバ拒否情報収集部１５が抽出し、同様に発信元サーバ１Ａのサーバ拒否情報管理部１６にエンドユーザのサーバ拒否情報を設定する。
【０１４０】
次に、発信元ユーザＳ１がＭＬ管理サーバ２Ａ宛にサブジェクトにはある特定の話題を含む文字列が含まれているメールの送信を行うとする。発信元サーバ１Ａの発信元サーバ制御情報加工部１４から受けとった制御情報とＴｏで指定しているＭＬアドレスを基に、発信元サーバ１Ａのサーバ拒否情報加工部１７において、制御情報中に発信元サーバ１Ａのサーバ拒否情報管理部１６のメンバリスト管理テーブルに登録されているメールアドレスと一致するものがある場合、そのメールアドレスに対応するテーブル識別フラグ３２を確認する。この時、テーブル識別フラグ３２に“２”が指定されていた場合、そのメンバに対応するトピックス情報拒否テーブルを参照する。もし、トピックス情報拒否テーブル３４に設定されているトピックスが、メールのサブジェクトの中に含まれていた場合、そのメンバはそのトピックス情報をサブジェクトに含むメールの受信拒否を希望しているとみなし、制御情報からそのメンバへの宛先を削除する。このようにして制御情報を加工後、発信元サーバからメール送信を行う。
【０１４１】
これにより、あるＭＬの受信拒否を希望しているエンドユーザＥ２の設定を発信元サーバ制御情報加工部１４で生成した制御情報に反映させることにより、従来はエンドユーザＥ２に対して送信されていたメール（エンドユーザＥ２が拒否を指定したトピックス情報をメールのサブジェクトに含む）がエンドユーザＥ２を管理する受信サーバ４に送信されなくなる。
【０１４２】
また、発信元ユーザＳ１が、以前ＭＬ管理サーバ２Ａ宛てに出したメールの返信メールをＭＬ管理サーバ２Ａ宛てに再送したとする。発信元サーバ１Ａの発信元サーバ制御情報加工部１４から受けとった制御情報とＴｏで指定しているＭＬアドレスを基に、発信元サーバ１Ａのサーバ拒否情報加工部１７において、制御情報中に発信元サーバ１Ａのサーバ拒否情報管理部１６のメンバリスト管理テーブル３１に登録されているメールアドレスと一致するものがある場合、そのメールアドレスに対応するテーブル識別フラグを確認する。この時、テーブル識別フラグ３２に“１”が指定されていた場合、そのメンバに対応するメッセージＩＤ情報拒否テーブル３３を参照する。もし、メッセージＩＤ情報拒否テーブルに設定されているメッセージＩＤがメールのメッセージＩＤと一致した場合、そのメンバはそのメール（特定のメッセージＩＤに属するスレッド）に対して、受信拒否を希望しているとみなし、制御情報からそのメンバに対する宛先を除外する。
【０１４３】
このようにして制御情報を加工後、発信元サーバからメール送信を行う。これにより、あるＭＬの受信拒否を希望しているエンドユーザＥ１の設定を発信元サーバ制御情報加工部１４で生成した制御情報に反映させることにより、従来はエンドユーザＥ１に対して送信されていたメール（特定のメッセージＩＤに属するスレッド）がエンドユーザＥ１を管理する受信サーバ４に送信されなくなる。
【０１４４】
図１３は、本発明の第３の実施の形態例を説明するためのネットワーク構成図を示す。同図中、メールサーバ５１（Ｙ−ＭＬ＠ｙｙｙ．ｃｏｍ）、メールサーバ５２（Ｘ−ＭＬ＠ｘｘｘ．ｃｏｍ）、メールサーバ５３（Ｚ−ＭＬ＠ｚｚｚ．ｃｏｍ）はそれぞれ通信回線によりネットワーク接続されている。これらのメールサーバ５１，５２，５３それぞれは、発信元サーバ構成定義部１１、発信元サーバＭＬ情報収集部１２、発信元サーバＭＬ情報管理部１３、発信元サーバ制御情報加工部１４，ＭＬ管理サーバＭＬ情報収集対応部２１，サーバ拒否情報収集部１５，サーバ拒否情報管理部１６，サーバ拒否情報加工部１７を備えている。
【０１４５】
また、メールサーバ５１配下には端末５４（ａａａ＠ｙｙｙ．ｃｏｍ）が、メールサーバ５２配下には端末５５（ｂｂｂ＠ｘｘｘ．ｃｏｍ）、端末５６（ｃｃｃ＠ｘｘｘ．ｃｏｍ）がメールサーバ５３配下には端末５７（ｄｄｄ＠ｚｚｚ．ｃｏｍ）、端末５８（ｅｅｅ＠ｚｚｚ．ｃｏｍ）がそれぞれ通信回線により接続されている。
【０１４６】
図１４及び図１７は、本発明の第３の実施の形態例のシーケンスを示す。発信元ユーザである端末５４（ａａａ＠ｙｙｙ．ｃｏｍ）からＭＬアドレス（Ｘ−ＭＬ＠ｘｘｘ．ｃｏｍ）を宛先に指定した図１５（Ａ）に示すメールＡを、メールサーバ５１を経由してメールサーバ５２に送信する。メールサーバ５２が受信したメールは、メールサーバ５２内の発信元サーバ制御情報加工部１４において発信元サーバＭＬ情報管理部１３のＭＬ管理テーブル３０を参照し、制御情報を作成する。ＭＬ（Ｘ−ＭＬ＠ｘｘｘ．ｃｏｍ）宛に送信されたメールはこの制御情報に従い、送受信部２ａにてＭＬに登録しているユーザである端末５４〜５８それぞれに送信する。 
ここで、端末５７のユーザＤ（ｄｄｄ＠ｚｚｚ．ｃｏｍ）にとって、メールＡに関する応答メール（リプライメール）が不要な場合は、ユーザＤはメールＡの応答メールの受信を拒否する旨の図１５（Ｂ）に示すメールＢを、メールサーバ５２に送信する（図１４の３−１）。この際、メールＢにはメールＡのメッセージＩＤ（Ｍｅｓｓａｇｅ−ＩＤ）である“２００３０９０３Ｓ＠ｙｙｙ．ｃｏｍ”を、付加情報αとして付加する。
【０１４７】
メールＢを受け取ったメールサーバ５２では、サーバ拒否情報収集部１５にて、メールＢから付加情報αを取得する（３−２）。付加情報はサーバ拒否情報管理部１６にて登録される（３−３）。
【０１４８】
図１６に示すように、発信元サーバＭＬ情報管理部１３にてＭＬ管理テーブル３０及びメンバリスト管理テーブル３１からＭＬ（Ｘ−ＭＬ＠ｘｘｘ．ｃｏｍ）のメンバであるユーザＤ（ｄｄｄ＠ｚｚｚ．ｃｏｍ）を検索し（３−４，３−５）、付加情報がメッセージＩＤであることからメンバリスト管理テーブル３１に付随するテーブル識別フラグ３２に“１”を設定し、サーバ拒否情報管理部１６内にユーザＤのメッセージＩＤ拒否テーブル３３を作成する。そして、メールＢの付加情報αである“２００３０９０３Ｓ＠ｙｙｙ．ｃｏｍ”を登録する。
【０１４９】
メールサーバ５２のサーバ拒否情報収集部１５は、サーバ拒否情報管理部１６からの登録完了の通知を受け（３−６）、ＭＬ管理サーバＭＬ情報収集対応部２１を参照し（３−７）、ＭＬアドレスを取得する（３−８）。そして、サーバ拒否情報収集部１５は取得したアドレスから取得した拒否情報をメールにて他のサーバ（メールサーバ５１，５３）に送信する（３−９）。
【０１５０】
メールを受信したメールサーバ５１，５３のサーバ拒否情報収集部１５は、拒否情報を取得し（３−１０）、メールサーバ５２と同様に、各々のサーバ拒否情報管理部１６にて拒否情報を登録する（３−１１，３−１２，３−１３，３−１４）。この処理により、全サーバのサーバ拒否情報管理部１６のテーブルを更新する。
【０１５１】
ここで、端末５５のユーザＢ（ｂｂｂ＠ｘｘｘ．ｃｏｍ）がＭＬ（Ｘ−ＭＬ＠ｘｘｘ．ｃｏｍ）に図１５（Ｃ）に示すメールＣを送信すると（図１７の４−１）、メールサーバ５２の送受信部２ａがこれを受け取り、サーバ拒否情報加工部１７にてメールＣのメッセージＩＤとレファランスＩＤ（ＲｅｆｅｒｅｎｃｅＩＤ）を取得する（４−２）。そして、発信元サーバ制御情報加工部１４から制御情報を取得する（４−３，４−４）。この制御情報の個人アドレス情報はａａａ＠ｙｙｙ．ｃｏｍ，ｂｂｂ＠ｘｘｘ．ｃｏｍ，ｃｃｃ＠ｘｘｘ．ｃｏｍ，ｄｄｄ＠ｚｚｚ．ｃｏｍ，ｅｅｅ＠ｚｚｚ．ｃｏｍである。
【０１５２】
サーバ拒否情報管理部１６を参照し、取得した制御情報とメールアドレスが一致するものはないか検索する。既にｄｄｄ＠ｚｚｚ．ｃｏｍは拒否情報として登録されているので、ｄｄｄ＠ｚｚｚ．ｃｏｍが検索される。ｄｄｄ＠ｚｚｚ．ｃｏｍのテーブル識別フラグが“１”に設定されていることからメッセージＩＤ拒否情報テーブルを参照し、メールＣのレファランスＩＤを検索する。“２００３０９０３Ｓ＠ｙｙｙ．ｃｏｍ”がテーブル内に存在するので、ユーザＤがこのメールを拒否している事がわかり、拒否情報として取得する（４−６）。
【０１５３】
なお、この時メールＣのメッセージＩＤをメッセージＩＤ拒否情報テーブルに登録する。メールＣのメッセージＩＤを登録することにより、以降、メールＣへの応答メールも、メッセージＩＤとレファランスＩＤを取得し、メッセージＩＤ拒否情報テーブルを検索することで、ユーザＤを拒否対象にすることができる。取得した拒否情報から、ユーザＤ（ｄｄｄ＠ｚｚｚ．ｃｏｍ）のアドレスを制御情報から削除する。これにより、制御情報の個人アドレス情報はａａａ＠ｙｙｙ．ｃｏｍ，ｂｂｂ＠ｘｘｘ．ｃｏｍ，ｃｃｃ＠ｘｘｘ．ｃｏｍ，ｅｅｅ＠ｚｚｚ．ｃｏｍとなる。
【０１５４】
これに基づいて、サーバ拒否情報加工部１７は送受信部２ａを経て、各メールサーバにメールを送信する（４−７）。各メールサーバは接続されている端末にメールを送信する（４−８）。結果として、このメールＣはエンドユーザＤには送信されないことになる。
【０１５５】
また、あるメールの応答メール受信の拒否ではなく、特定のトピックスに関連するメールを拒否する場合には、次のようなプロセスを行う。
【０１５６】
ここで、端末２９のユーザＥ（ｅｅｅ＠ｚｚｚ．ｃｏｍ）が、メールＡのサブジェクト（Ｓｕｂｊｅｃｔ）である“参考資料について”に関連するメールが不要とする場合、この“参考資料について”に関連するメールの受信を拒否する旨の図１５（Ｄ）に示すメールＤを付加情報β“参考資料について”を付加してメールサーバ５２に送信する（３−１）。
【０１５７】
メールＤを受け取ったメールサーバ５２では、サーバ拒否情報収集部１５にて、付加情報βを取得する（３−２）。付加情報はサーバ拒否情報管理部１６によって登録される（３−３）。
【０１５８】
図１６に示すように、発信元サーバＭＬ情報管理部１３にてＭＬ管理テーブル３０及びメンバリスト管理テーブル３１からＭＬ（Ｘ−ＭＬ＠ｘｘｘ．ｃｏｍ）のメンバであるユーザＥ（ｅｅｅ＠ｚｚｚ．ｃｏｍ）を検索し（３−４，３−５）、付加情報がＴｏｐｉｃｓであることからメンバリスト管理テーブル３１に付随するテーブル識別フラグ３２にテーブル識別フラグ“２”を設定し、サーバ拒否情報管理部１６内にユーザＥのトピックス拒否情報テーブル３４を作成する。そして、メールＢの付加情報βである“参考資料について”を登録する。 
メールサーバ５２のサーバ拒否情報収集部１５は、サーバ拒否情報管理部１６からの登録完了の通知を受け（３−６）、ＭＬ管理サーバＭＬ情報収集対応部２１を参照し（３−７）、ＭＬアドレスを取得する（３−８）。取得したアドレスから、取得した拒否情報をメールにて他のサーバ（メールサーバ５１，５３）に送信する（３−９）。メールを受信したメールサーバ５１，５３のサーバ拒否情報収集部１５は、拒否情報を取得し（３−１０）、メールサーバ５２と同様に、各々のサーバ拒否情報管理部１６にて拒否情報を登録する（３−１１，３−１２，３−１３，３−１４）。この処理により、全サーバのサーバ拒否情報管理部１６のテーブルを更新する。
【０１５９】
ここで、端末５５のユーザＢ（ｂｂｂ＠ｘｘｘ．ｃｏｍ）が端末５５からＭＬ（Ｘ−ＭＬ＠ｘｘｘ．ｃｏｍ）に図１５（Ｃ）に示すメールＣを送信すると（４−１）、メールサーバ５２の送受信部２ａがこれを受け取り、サーバ拒否情報加工部１７にてメールＣのサブジェクトを取得する（４−２）。そして、発信元サーバ制御情報加工部１４から制御情報を取得する（４−３，４−４）。この制御情報の個人アドレス情報はａａａ＠ｙｙｙ．ｃｏｍ，ｂｂｂ＠ｘｘｘ．ｃｏｍ，ｃｃｃ＠ｘｘｘ．ｃｏｍ，ｄｄｄ＠ｚｚｚ．ｃｏｍ，ｅｅｅ＠ｚｚｚ．ｃｏｍである。
【０１６０】
その後、サーバ拒否情報加工部１７はサーバ拒否情報管理部１６を参照し、取得した制御情報とメールアドレスが一致するものはないか検索する。ｅｅｅ＠ｚｚｚ．ｃｏｍが拒否情報として登録されているので、ｅｅｅ＠ｚｚｚ．ｃｏｍが検索される。ｄｄｄ＠ｚｚｚ．ｃｏｍのテーブル識別フラグが“２”に設定されていることから、トピックス拒否情報テーブルを参照し、メールＣのサブジェクトを検索する。“参考資料について”がテーブル内に存在するので、ユーザＥがこのメールを拒否している事がわかる。これを、サーバ拒否情報加工部１７は拒否情報として取得する（４−５，４−６）。取得した拒否情報から、ユーザＥ（ｅｅｅ＠ｚｚｚ．ｃｏｍ）のアドレスを制御情報から削除する。これにより、個人アドレス情報はａａａ＠ｙｙｙ．ｃｏｍ，ｂｂｂ＠ｘｘｘ．ｃｏｍ，ｃｃｃ＠ｘｘｘ．ｃｏｍ，ｄｄｄ＠ｚｚｚ．ｃｏｍとなる。
【０１６１】
これに基づいて、サーバ拒否情報加工部１７は送受信部２ａを経て、各メールサーバにメールを送信する（４−７）。各メールサーバは接続されている端末５５，５６にメールを送信する（４−８）。結果として、このメールＣはエンドユーザＥには送信されないことになる。
【０１６２】
メールサーバ５２がＭＬ（Ｘ−ＭＬ＠ｘｘｘ．ｃｏｍ）宛にメールを受信するたびに、サーバ拒否情報管理部１６の拒否情報テーブルを参照することにより、受信を拒否したユーザへのメールの送信を行わない。メールの拒否情報は１つのサーバのサーバ拒否情報管理部１６にて登録すれば、サーバ拒否情報収集部１５を通して他のサーバにも拒否情報を反映できる。
【０１６３】
拒否情報が他サーバに反映されることにより、たとえば端末５４からＭＬ（Ｘ−ＭＬ＠ｘｘｘ．ｃｏｍ）宛にメールＣのようなメールを送信すれば、メールサーバ５１にてサーバ拒否情報管理部１６を参照して制御情報を加工し、メールを拒否するユーザにはメールを送信しないようにする。
【０１６４】
このように拒否情報をメールサーバごとに保持することにより、メールサーバによるエンドユーザにとって不要なメールのフィルタリングがサーバごとに実現でき、ネットワークトラヒックの軽減が期待できる。
【０１６５】
このようにして、エンドユーザの受信拒否の意思をメールサーバに反映させることで、エンドユーザの意思とは無関係にメールサーバからメールが配信されることがなくなり、これによって以下のような効果が得られる。
（１）エンドユーザの受信拒否設定をサーバ側で行うため、クライアント側でメールソフト等を使用して受信拒否設定を行う必要がない。
（２）ネットワーク上に、エンドユーザに必要のないメールが配信されなくなるので、従来よりも無駄なトラヒックが無くなる。
【０１６６】
図１８は、本発明の第４の実施の形態例の原理ブロック図を示す。同図中、発信元サーバ１Ａには送受信部１ａ、発信元サーバ構成定義部１１、発信元サーバＭＬ情報収集部１２、発信元サーバＭＬ情報管理部１３、発信元サーバ制御情報加工部１４の他に、代理サーバ情報収集部２４，代理サーバ情報管理部２５，代理サーバ情報加工部２６を設け、ＭＬ管理サーバ２Ａには送受信部２ａ、ＭＬ管理サーバＭＬ情報収集対応部２１を設け、受信サーバ４には代理サーバ情報収集部２４，代理サーバ情報管理部２５，代理サーバ情報加工部２６を設ける。発信元サーバ１Ａには発信元ユーザＳ１が接続され、受信サーバ４にはエンドユーザＥ１が接続されている。
【０１６７】
発信元サーバ１Ａの代理サーバ情報収集部２４は、障害前のＭＬ管理サーバ２Ａに対して、代理サーバのＭＬアドレス及びアップ（動作）／ダウン（非動作）情報等の代理サーバ情報を収集し、この情報をパラメータとして発信元サーバ１Ａの代理サーバ情報管理部２５に通知する。また、発信元サーバ１Ａの代理サーバ情報収集部２４は送受信部１ａからＭＬ管理サーバ２Ａの障害を検出した時に、自サーバが代理サーバになれるかの確認を代理サーバ情報管理部２５に対して行う。
【０１６８】
また、代理サーバ情報管理部２５にて決定された自サーバのＭＬアドレスと代理サーバとなるＭＬ管理サーバ２ＡのＭＬアドレス等の情報等の代理サーバ情報を収集後、これらの情報をメールヘッダに付加し、障害が発生していない別サーバに対して送信する機能を持つ。
【０１６９】
また、この代理サーバ情報通知メールを受信した受信サーバ４の代理サーバ情報収集部２４は、受信した代理サーバ情報を基に自分が代理サーバになれるかの確認を行うために、受信サーバ４の代理サーバ情報管理部２５に問い合わせを行う。問い合わせ終了後、応答をメールで発信元サーバ１Ａに返信する。さらに、障害中のＭＬ管理サーバ２Ａのアップ／ダウン状況を監視しアップした場合、代理サーバ情報管理部２５に対してアップ通知を行い、再送する必要のあるエンドユーザがいるかどうかの確認を行う機能を持つ。
【０１７０】
代理サーバ情報管理部２５は、代理サーバ情報収集部２４からの代理サーバ情報問い合わせを受け付ける。問い合わせを受けると、自サーバが管理している代理サーバ管理テーブル３５内に登録されている各代理サーバのプライオリティをチェック後、自サーバが最もプライオリティが高い場合に、代理サーバとなる設定を代理サーバ管理テーブル３５に反映させる。反映後、応答を代理サーバ情報収集部２４に返す。
【０１７１】
また、障害中のＭＬ管理サーバ２ＡのＭＬアドレスとアップ／ダウン情報を管理する。さらに、障害中のＭＬ管理サーバ２ＡのＭＬに登録されているメンバで、送信できなかったメンバに対して、障害復旧後に再送を行うために、再送が必要かどうか判断をするメンバリスト管理テーブル３１の再送フラグ３６を管理し、さらにメール本文も保存する。
【０１７２】
代理サーバ情報加工部２６は、代理サーバ情報管理部に登録されている代理サーバ情報を基に障害が発生したＭＬ管理サーバ２ＡのＭＬに登録されているメンバのメールアドレスをチェックする。該当者がいれば、メール制御情報の加工処理を行う。
【０１７３】
ここで、発信元サーバ１Ａ、ＭＬ管理サーバ２Ａ、受信サーバ４それぞれはお互いのＭＬ情報を保持している。また、このネットワークにおいて、発信元サーバ１Ａと受信サーバ４はＭＬ管理サーバ２Ａが障害発生時に代理サーバの候補となるサーバであり、各サーバの管理者は事前にプライオリティ（代理サーバを決定する時に必要な値）を設定しておく。また、各サーバのプライオリティは発信元サーバ１Ａ及び受信サーバ４の代理サーバ情報収集部２４にて収集済みのものとする。
【０１７４】
まず、ＭＬ管理サーバ２Ａの障害を最初に検出したサーバの代理サーバ情報収集部２４は、自サーバが代理サーバになれるかどうか確認するために、代理サーバ情報管理部２５に対して情報収集通知を出す。情報収集通知を受けた代理サーバ情報管理部２５は、代理サーバ管理テーブル３５に登録されているＭＬの中で、障害になったＭＬに該当するアップ／ダウン情報をダウン状態にする。
【０１７５】
次に、予め収集済みの各代理サーバ候補のプライオリティを確認し、最もプライオリティが高い代理サーバ候補のＭＬアドレスを代理サーバとして設定後、障害中のＭＬ管理サーバのＭＬアドレスと、ダウン情報をパラメータとして代理サーバ情報収集部２４に対して応答を返す。応答を受けた代理サーバ情報収集部２４は、パラメータ（代理サーバ情報）をメールヘッダに付加し、他の代理サーバ候補にメールを送信する。
【０１７６】
メールを受信した代理サーバ候補のサーバは代理サーバ情報収集部２４にてメールヘッダの中身を確認し、その代理サーバ情報を自サーバの代理サーバ情報管理部２５にパラメータとして通知する。通知を受けた代理サーバ情報管理部２５では、代理サーバ管理テーブルに登録してあるＭＬで、障害となったＭＬに該当するアップ／ダウン情報をダウン状態にし、さらに最もプライオリティが高い代理サーバ候補のＭＬアドレスを代理サーバとして設定後、代理サーバ情報収集部２４に応答を返し、代理サーバ情報収集部２４は、設定が完了したことをメールで別の代理サーバ候補に通知する。
【０１７７】
図１８に沿って流れを説明すると、発信元ユーザＳ１がＭＬ管理サーバ２Ａ宛にメールを送信したとする。発信元サーバ１Ａはメールを受信後、ＭＬ管理サーバ２Ａに対してメールを転送する。この時、ＭＬ管理サーバ２Ａに障害が発生していた場合、ＭＬ管理サーバ２Ａに対してメールの送信ができない。メールの送信ができないことを発信元サーバ１Ａの代理サーバ情報収集部２４が検出すると、ダウン情報を発信元サーバ１Ａの代理サーバ情報管理部２５に通知する。
【０１７８】
ダウン情報の設定通知を受け付けた発信元サーバ１Ａの代理サーバ情報管理部２５の代理サーバ管理テーブルにダウン情報を設定後、代理サーバ候補のＭＬの中で最もプライオリティの高いものをチェックする。ここでは、発信元サーバ１Ａが受信サーバ４よりプライオリティが高いものとする。次に発信元サーバ１Ａの代理サーバ管理テーブルに自分が代理サーバとなったことを設定し、応答を発信元サーバ１Ａの代理サーバ情報収集部２４に返す。
【０１７９】
応答を受けた発信元サーバ１Ａの代理サーバ情報収集部２４は自分が代理サーバになったことを受信サーバ４に通知するために、発信元サーバ１Ａのアドレスと障害が発生したＭＬ管理サーバ２ＡのＭＬアドレスとダウン情報をメールヘッダに付加し、受信サーバ４にメールで送信する。受信サーバ４の代理サーバ情報収集部２４は、受信サーバ４の代理サーバ情報管理部２５に、発信元サーバ１Ａから受信したメールのヘッダに付加されている発信元サーバ１Ａのアドレスと障害が発生したＭＬ管理サーバ２ＡのＭＬアドレスとダウン情報をパラメータとして通知する。
【０１８０】
受信サーバ４の代理サーバ情報管理部２５はこの通知を受けて、受信サーバ４の代理サーバ管理テーブルに登録されている代理サーバ候補のＭＬ中から、最もプライオリティの高い発信元サーバ１Ａのアップ/ダウン情報をダウン状態に設定し、さらに発信元サーバ１Ａが代理サーバになったことを設定する。設定後、その応答を受信サーバ４の代理サーバ情報収集部２４に返し、受信サーバ４の代理サーバ情報収集部２４は、自サーバの代理サーバ管理テーブルに設定が完了した事を発信元サーバ１Ａに通知するために、発信元サーバ１Ａの代理サーバ情報収集部２４にメールで返信する。
【０１８１】
次に、発信元サーバ１Ａの発信元サーバ制御情報加工部１４から受けとった制御情報と発信元サーバ１Ａの代理サーバ情報管理部２５の代理サーバ管理テーブルを基に、発信元サーバ１Ａの代理サーバ情報加工部２６はＭＬ管理サーバ２Ａに登録されているＭＬのメンバ中のＭＬ管理サーバが管理するエンドユーザＸ１のメールアドレスを制御情報から除外する。その時、除外したメンバに送信するはずだったメールについては、メンバ毎に発信元サーバ１Ａで保存し、さらにメンバリスト管理テーブル３１中の除外されたメンバに対応する再送フラグ３６に“１”を立てる。
【０１８２】
このようにして代理サーバ情報加工部２６において制御情報を加工後、発信元サーバからメール送信を行う。これにより、従来はＭＬ管理サーバ２Ａにおいて障害が発生していた場合、ＭＬ管理サーバ２Ａで管理されているＭＬのメンバであるエンドユーザＥ１にメールが送信する事ができなかったが、発信元サーバ１Ａが代理サーバとして、メールの転送を行うことにより、エンドユーザＥ１にメールが送信可能となる。
【０１８３】
また、発信元サーバ１Ａの代理サーバ情報収集部２４がＭＬ管理サーバ２Ａの復旧を検出した場合、発信元サーバ１Ａの代理サーバ情報収集部２４は発信元サーバ１Ａの代理サーバ情報管理部２５にアップ情報を通知する。発信元サーバ１Ａの代理サーバ情報管理部２５の通知を受け、代理サーバ管理テーブル中の障害だったＭＬのＭＬアドレスのアップ/ダウン情報をアップ状態にした後、メンバリスト管理テーブル中のメンバの中で再送フラグ３６に“１”が立っているかチェックを行う。再送フラグ３６に“１”が立っていた場合、ＭＬ管理サーバ２Ａに対してメールの再送が必要であるため、該当するメンバ宛てに送信する必要のあるメールを取り出した後、発信元サーバ１Ａの代理サーバ情報収集部２４に対して応答を返す。
【０１８４】
発信元サーバ１Ａの代理サーバ情報収集部２４はこれらのパラメータを基に発信元サーバ１Ａの代理サーバ情報加工部２６に通知を行う。発信元サーバ１Ａの代理サーバ情報加工部２６で制御情報を加工し、ＭＬ管理サーバ２Ａにメールの送信を行う。このことにより、障害中であったＭＬ管理サーバ２Ａが管理するエンドユーザＸ１に対して、障害復旧後メールを送信することができる。
【０１８５】
また、エンドユーザＥ１がＭＬ管理サーバ２Ａ宛てにメールを送信したとする。受信サーバ４の代理サーバ情報加工部２６において受信サーバ４の代理サーバ情報管理部２５の代理サーバ管理テーブルを参照することで、ＭＬ管理サーバ２Ａの代理サーバが発信元サーバ１Ａになっていることが分かる。このことを受けて、受信サーバ４の代理サーバ情報加工部２６で制御情報を加工することで、従来は受信サーバ４からＭＬ管理サーバ２Ａ宛てに送信されていたメールが、発信元サーバ１Ａに対して送信されるようになる。よって、最終的にＭＬ管理サーバ２Ａ向けの送信メールは全て発信元サーバ１Ａに転送されるため、ＭＬ管理サーバ２Ａに送信リトライを行うサーバは代理サーバである発信元サーバ１Ａのみとなる。これにより、従来各サーバ（受信サーバ４を含む）から障害中のＭＬ管理サーバ宛に送信されていた無駄な送信リトライを抑止することができ、ネットワークトラヒックの負荷が軽減される。
【０１８６】
図１９は本発明の第４の実施の形態例を説明するためのネットワーク構成図、図２０はそのネットワーク構成の一部拡大図を示す。同図中、各メールサーバ７１，７２，７３それぞれは、発信元サーバ構成定義部１１、発信元サーバＭＬ情報収集部１２、発信元サーバＭＬ情報管理部１３、発信元サーバ制御情報加工部１４、ＭＬ管理サーバＭＬ情報収集対応部２１、代理サーバ情報収集部２４、代理サーバ情報管理部２５、代理サーバ情報加工部２６及び送受信部により構成されている。
【０１８７】
代理サーバ情報管理部２５は図２０に示す代理サーバ管理テーブル３５を有している。代理サーバ管理テーブル３５には、メールサーバ管理者があらかじめ設定した別のサーバに問題が起きたときに代理サーバとなる優先度（以下プライオリティ）が対象となるサーバ毎に設定・登録され、また、全てのサーバについてのプライオリティ情報を保持している。ここでは、メールサーバ７２に対するプライオリティについて、メールサーバ７１が“３”、メールサーバ７３が“２”と設定されていて、メールサーバ７１が最もプライオリティが高いものとする。
【０１８８】
メールサーバ７２は、ＭＬ情報１を管理しているＭＬ管理サーバでもある。メールサーバ７１（Ｙ−ＭＬ＠ｙｙｙ．ｃｏｍ）、メールサーバ７２（Ｘ−ＭＬ＠ｘｘｘ．ｃｏｍ）、メールサーバ７３（Ｚ−ＭＬ＠ｚｚｚ．ｃｏｍ）はそれぞれ通信回線によりネットワーク接続されている。
【０１８９】
メールサーバ７１配下には端末７４（ａａａ＠ｙｙｙ．ｃｏｍ）が、メールサーバ７２配下には端末７５（ｂｂｂ＠ｘｘｘ．ｃｏｍ）、端末７６（ｃｃｃ＠ｘｘｘ．ｃｏｍ）がメールサーバ７３配下に端末７７（ｄｄｄ＠ｚｚｚ．ｃｏｍ）、端末７８（ｅｅｅ＠ｚｚｚ．ｃｏｍ）がそれぞれ通信回線により接続されている。
【０１９０】
図２１及び図２２は、本発明の第４の実施の形態例のシーケンスを示す。ここで、図１９において、メールサーバ７２に障害が発生した場合を考える。このとき、メールサーバ７１が最初に障害を検知したとする。メールサーバ７１は送受信部によるメールサーバ７２へのメール送信が失敗する（図２１の５−１）。このことから、メールサーバ７２に障害が起こっていることを代理サーバ情報収集部２４に通知する（５−２）。一般的に障害を検知する手段としては、メールサーバ７１からの接続信号に対する応答信号が、あらかじめ設定している時間内に送られてこなければ、メールサーバ７２に障害が起きているものとみなす等がある。
【０１９１】
メールサーバ７２の障害の通知を受けたメールサーバ７１の代理サーバ情報管理部２５は、まず代理サーバ候補の中で最もプライオリティの高いものをチェックする。最もプライオリティが高いサーバはメールサーバ７１であるので、代理サーバ管理テーブル３５にて、ＭＬ（Ｘ−ＭＬ＠ｘｘｘ．ｃｏｍ）がダウン状態であることと、代理サーバとなるメールサーバ７１を登録する（５−３，５−４）。
【０１９２】
その後、メールサーバ７１においては、代理サーバ情報収集部２４にて自サーバがメールサーバ７２の代理サーバになることを他のメールサーバ７３の代理サーバ情報収集部２４に対し、図２０に示すメールＥで通知する（５−５）。このとき通知される情報は、障害が発生しているメールサーバ７２のＭＬアドレスと、メールサーバ７２の代理サーバとなるメールサーバ７１のアドレスである。
【０１９３】
メールＥを受信したメールサーバ７３は、代理サーバ情報収集部２４にて代理メールサーバの情報を収集して、代理サーバ情報管理部２５において代理サーバ管理テーブル３５に、ＭＬ（Ｘ−ＭＬ＠ｘｘｘ．ｃｏｍ）がダウンしていることと、代理サーバとなるメールサーバ７１のアドレス（Ｙ＠ｙｙｙ．ｃｏｍ）を登録する（５−７，５−８）。
【０１９４】
その後、メールサーバ７３はメールサーバ７１がメールサーバ７２の代理サーバとなることを受諾した旨の図２０に示すメールＦをメールサーバ７１に送信する（５−９）。
【０１９５】
メールサーバ７１の代理サーバ情報収集部２４では代理サーバになることを受諾したメールＦを待ち、メールＦを受信したら（５−１０）、メールサーバ７２の代理サーバとして機能することになる。
【０１９６】
以降、各サーバは代理サーバ情報管理部２５の代理サーバ管理テーブル３５を参照して、ＭＬ（Ｘ−ＭＬ＠ｘｘｘ．ｃｏｍ）宛のメールはメールサーバ７１に送信される。
【０１９７】
ユーザＤがＭＬ（Ｘ−ＭＬ＠ｘｘｘ．ｃｏｍ）宛に図１９に示すメールＨを送信すると（図２２の６−２）、メールサーバ７３はこれを送受信部にて受信し、代理サーバ情報加工部２６にて代理サーバ情報管理部２５の代理サーバ管理テーブル３５を参照する（６−３）。Ｘ−ＭＬ＠ｘｘｘ．ｃｏｍを管理するメールサーバ７２は現在障害中で、メールサーバ７１（Ｙ−ＭＬ＠ｙｙｙ．ｃｏｍ）が代理しているという情報を代理サーバ管理テーブル３５から得ると（６−４）、その情報に従い、本来のメールサーバであるメールサーバ７２ではなく、メールサーバ７１にメールＨを送信する（６−５）。
【０１９８】
メールＨを受信したメールサーバ７１では、代理サーバ情報加工部２６にて、発信元サーバ制御情報加工部１４から受けとった（６−６，６−７）制御情報と代理サーバ情報管理部２５の代理サーバ管理テーブル３５を参照して、メールサーバ７１に登録されているＭＬのメンバで、メールサーバ７２の端末７５（ｂｂｂ＠ｘｘｘ．ｃｏｍ）と端末７６（ｃｃｃ＠ｘｘｘ．ｃｏｍ）のメールアドレスを制御情報から除外する。
【０１９９】
その時、除外した端末７５，７６に送信するメールについては、メールサーバ７１で保存し、メンバリスト管理テーブル３１内の該当するメンバ（ｂｂｂ＠ｘｘｘ．ｃｏｍ，ｃｃｃ＠ｘｘｘ．ｃｏｍ）に対応する再送フラグ３６に“１”を立てる（６−８，６−９）。この個人アドレス情報から、送受信部を経てメールＨが送信される（６−１０，６−１１）。
【０２００】
一方、メールサーバ７１の代理サーバ情報収集部２４はメールサーバ７２が復旧するまで、メールサーバ７２へのメール送信を試みる（６−１）。メールサーバ７２への復旧が確認できれば（６−１２）、代理サーバ情報収集部２４は代理サーバ情報管理部２５にメールサーバ７２が復旧したという情報を通知し（６−１３）、代理サーバ情報管理部２５にて、メールサーバ７２のアップ／ダウン情報をアップ状態に書き換え、メンバリスト管理テーブル３１の再送フラグ３６を参照する。ここでは、端末７５，７６への再送フラグ３６に“１”が立っているため、端末７５，７６宛のメールを取り出し、代理サーバ情報収集部２４に通知する（６−１４）。代理サーバ情報収集部２４はこの情報を代理サーバ情報加工部２６に通知し（６−１５）、代理サーバ情報加工部２６にて個人アドレス情報を加工し、メールサーバ７２にメールを送信する（６−１６）。
【０２０１】
このように、あるメールサーバが障害により機能しなくなったとき、別のサーバの代理サーバ情報収集部２４、代理サーバ情報管理部２５にて代理のメールサーバを決めて、その情報を共有することにより、ＭＬを利用したメールの送受信を滞りなく行うことができる。
【０２０２】
また、障害が起きているメールサーバの代理として決定されたメールサーバのみが障害の生じているメールサーバ７２へのメール送信および、メールのスプールを行うことで、ネットワーク全体のトラヒックの軽減、およびリソースの節約が期待できる。
【０２０３】
このようにして、ＭＬを管理するメールサーバで障害が発生した場合に別のメールサーバが代理サーバとして機能することにより、以下のような効果が得られる。
（１）発信元ユーザが、障害中のメールサーバ宛にメールの送信を行った場合、代理サーバが障害中のメールサーバの情報を持つことにより、ＭＬに登録されているエンドユーザにメールの転送を行うことができる。
（２）障害中のメールサーバ配下のエンドユーザに対するメールに関しては、障害復旧後代理サーバが自動的にメールの送信を行うことができるため、発信元ユーザから再送する必要が無くなる。
（３）代理サーバが、各サーバ配下の発信元ユーザから障害中のメールサーバ宛に出されたメールの送信を代理で行うため、メール送信リトライが代理サーバから障害中のメールサーバだけになる。このため、送信リトライによる無駄なトラヒックが抑止される。
【０２０４】
なお、発信元サーバＭＬ情報収集部１２，発信元サーバＭＬ情報管理部１３が請求項または付記に記載のＭＬ情報管理手段に対応し、発信元サーバ制御情報加工部１４が制御情報加工手段に対応し、ＭＬ管理サーバＭＬ情報収集対応部２１がＭＬ情報送信手段に対応し、サーバ拒否情報収集部１５，サーバ拒否情報管理部１６が受信拒否情報収集手段に対応し、サーバ拒否情報加工部１７が個人アドレス削除手段に対応し、代理サーバ情報収集部２４，代理サーバ情報管理部２５が代理サーバ情報収集手段に対応し、代理サーバ情報加工部２６が代理サーバ情報加工手段に対応し、代理サーバ情報管理部２５，代理サーバ情報加工部２６が再送手段に対応する。
（付記１）
電子メールの送信要求を受ける発信元サーバと、メーリングリスト（以下ＭＬと略す）を管理するＭＬ管理サーバがそれぞれ設置されるネットワーク上で、
発信元サーバにおいては、
ＭＬ情報収集に必要な情報を定義している発信元サーバ構成定義部と、ＭＬ情報の収集を行なう発信元サーバＭＬ情報収集部と、収集したＭＬ情報の管理を行なう発信元サーバＭＬ情報管理部と、発信元サーバとＭＬ管理サーバ間で電子メールの送信を行なう段階で、ＭＬ管理サーバから受信サーバへの送信の有無を決定するために必要な制御情報を加工する発信元サーバ制御情報加工部とを具備し、
前記発信元サーバで各ＭＬ管理サーバからエンドユーザまでの電子メールの転送を制御し、エンドユーザに届く電子メールを最終的に１つにすると共に、前記ＭＬ管理サーバから受信サーバまでの電子メールの伝送量を削減することを特徴とする電子メール送受信システム。
（付記２）
前記発信元サーバがユーザから電子メール送信要求を受け付けた後、前記発信元サーバＭＬ情報収集部が、前記発信元サーバ構成定義部で定義されている情報を元に、ＭＬ情報の収集をＭＬ管理サーバに依頼した時に、ＭＬ管理サーバのＭＬ管理サーバＭＬ情報収集対応部で発信元サーバの情報を格納しておき、ＭＬ情報が変更された時に格納している発信元サーバ情報を元に、前記ＭＬ管理サーバＭＬ情報収集対応部が自発的に変更対象のＭＬ情報を発信元サーバに送信し、発信元サーバの前記発信元サーバＭＬ情報管理部で管理されているＭＬ情報の変更を行なうことを特徴とする付記１記載の電子メール送受信システム。
（付記３）
付記１または２記載の電子メール送受信システムにおいて、
前記発信元サーバ及びＭＬ管理サーバに、前記エンドユーザが設定した受信拒否情報を収集する受信拒否情報収集手段を設け、
前記発信元サーバに、前記受信拒否情報の条件を基にエンドユーザへの送信の有無を決定するために必要な制御情報を加工するサーバ拒否情報加工手段を設けたことを特徴とする電子メール送受信システム。
（付記４）
付記１乃至３のいずれか記載の電子メール送受信システムにおいて、
前記発信元サーバ及び受信サーバに、障害が発生したＭＬ管理サーバと前記障害のＭＬ管理サーバを代理する代理サーバ情報を収集する代理サーバ情報収集手段と、
前記代理サーバ情報を基にエンドユーザへの送信の有無を決定するために必要な制御情報を加工し送信する代理サーバ情報加工手段を設けたことを特徴とする電子メール送受信システム。
（付記５）
付記４記載の電子メール送受信システムにおいて、
前記障害のＭＬ管理サーバの配下のエンドユーザに送信できない電子メールを保存し、前記障害のＭＬ管理サーバが復旧したのち前記障害のＭＬ管理サーバの配下のエンドユーザに再送する再送手段を設けたことを特徴とする電子メール送受信システム。
（付記６）
電子メールの送信要求を受け付けるメールサーバである発信元サーバと、ＭＬを管理するメールサーバである一または複数のＭＬ管理サーバと、電子メールを受信するメールサーバである一または複数の受信サーバがネットワークに接続されており、ＭＬを用いて電子メールを配信する電子メール送受信方法において、
前記発信元サーバにて、前記ＭＬ管理サーバのＭＬ情報を収集して各ＭＬを構成するメンバの個人アドレスをメンバリスト情報として管理し、
前記発信元サーバにて、前記ＭＬ管理サーバに送信する電子メールの制御情報をＭＬアドレスから前記メンバリスト情報の個人アドレス情報に変更すると共に、重複する個人アドレスは１つを残して削除し送信することを特徴とする電子メール送受信方法。
（付記７）
付記６記載の電子メール送受信方法において、
前記発信元サーバ及びＭＬ管理サーバは、エンドユーザが設定した受信拒否情報を収集し、
前記発信元サーバは、前記受信拒否情報の条件に該当する個人アドレス情報を前記制御情報から削除することを特徴とする電子メール送受信方法。
（付記８）
付記６または７記載の電子メール送受信方法において、
各メールサーバで、障害が発生したＭＬ管理サーバと前記障害のＭＬ管理サーバを代理する代理サーバ情報を収集し、
前記障害のＭＬ管理サーバに送信する電子メールの制御情報を前記代理サーバ情報に基づいて変更し送信することを特徴とする電子メール送受信方法。
（付記９）
ネットワークに接続されており、電子メールの送信要求を受け付けるメールサーバである発信元サーバにおいて、
ＭＬを管理するメールサーバであるＭＬ管理サーバからＭＬ情報を収集して各ＭＬを構成するメンバの個人アドレスをメンバリスト情報として管理するＭＬ情報管理手段と、
前記ＭＬ管理サーバに送信する電子メールの制御情報をＭＬアドレスから前記メンバリスト情報の個人アドレス情報に変更すると共に、重複する個人アドレスは１つを残して削除し送信する制御情報加工手段を
有することを特徴とする発信元サーバ。
（付記１０）
ネットワークに接続されており、ＭＬを管理するメールサーバであるＭＬ管理サーバにおいて、
電子メールの送信要求を受け付けるメールサーバである発信元サーバからＭＬ情報を収集されたときに前記発信元サーバのアドレスを保持し、変更が生じたＭＬ情報を前記発信元サーバに送信するＭＬ情報送信手段を
有することを特徴とするＭＬ管理サーバ。
（付記１１）
付記９記載の発信元サーバにおいて、
エンドユーザが設定した受信拒否情報を収集する受信拒否情報収集手段と、
前記受信拒否情報の条件に該当する個人アドレスを前記制御情報から削除する個人アドレス削除手段を
有することを特徴とする発信元サーバ。
（付記１２）
付記１１記載の発信元サーバにおいて、
前記受信拒否情報には電子メールのメッセージＩＤが指定されており、
前記個人アドレス削除手段は、前記受信拒否情報を設定したエンドユーザを宛先とする電子メールであってメッセージＩＤまたはレファランスＩＤが前記受信拒否情報のメッセージＩＤに一致する電子メールの制御情報から前記エンドユーザの個人アドレスを削除することを特徴とする発信元サーバ。
（付記１３）
付記１１記載の発信元サーバにおいて、
前記受信拒否情報には電子メールのサブジェクトが指定されており、
前記個人アドレス削除手段は、前記受信拒否情報を設定したエンドユーザを宛先とする電子メールであってサブジェクトが前記受信拒否情報のサブジェクトに一致する電子メールの制御情報から前記エンドユーザの個人アドレスを削除することを特徴とする発信元サーバ。
（付記１４）
付記９または１１乃至１３のいずれかに記載の発信元サーバにおいて、
障害が発生したＭＬ管理サーバと前記障害のＭＬ管理サーバを代理する代理サーバ情報を収集する代理サーバ情報収集手段と、
前記障害のＭＬ管理サーバに送信する電子メールの制御情報を前記代理サーバ情報に基づいて変更し送信する代理サーバ情報加工手段を
有することを特徴とする発信元サーバ。
（付記１５）
付記１４記載の発信元サーバにおいて、
前記障害のＭＬ管理サーバの配下のエンドユーザに送信できない電子メールを保存し、前記障害のＭＬ管理サーバが復旧したのち前記障害のＭＬ管理サーバの配下のエンドユーザに再送する再送手段を
有することを特徴とする発信元サーバ。
【図面の簡単な説明】
【０２０５】
【図１】本発明の原理ブロック図である。
【図２】本発明の第１の実施の形態例を示すブロック図である。
【図３】発信元サーバ構成定義部の構成定義例を示す図である。
【図４】請求項１の動作シーケンス例を示す図である。
【図５】ＭＬメンバリスト取得方法の説明図である。
【図６】ＭＬ管理テーブルとメンバリスト管理テーブルの構成例を示す図である。
【図７】発信元サーバによる各メールサーバ向けの制御情報修正の説明図である。
【図８】本発明の第２の実施の形態例を示すブロック図である。
【図９】請求項２の動作シーケンス例を示す図である。
【図１０】ＭＬメンバリスト（追加・削除）通知方法の説明図である。
【図１１】ＭＬ情報追加・削除時のＭＬ管理テーブルとメンバリスト管理テーブルの構成例を示す図である。
【図１２】本発明の第３の実施の形態例の原理ブロック図である。
【図１３】本発明の第３の実施の形態例を説明するためのネットワーク構成図である。
【図１４】本発明の第３の実施の形態例のシーケンスである。
【図１５】電子メールのヘッダ情報を示す図である。
【図１６】発信元サーバＭＬ情報管理部とサーバ拒否情報収集部の構成を説明するための図である。
【図１７】本発明の第３の実施の形態例のシーケンスである。
【図１８】本発明の第４の実施の形態例の原理ブロック図である。
【図１９】本発明の第４の実施の形態例を説明するためのネットワーク構成図である。
【図２０】図１９のネットワーク構成の一部拡大図である。
【図２１】本発明の第４の実施の形態例のシーケンスである。
【図２２】本発明の第４の実施の形態例のシーケンスである。
【図２３】従来の電子メール送受信システムの原理図である。
【符号の説明】
【０２０６】
１Ａ  発信元サーバ
１ａ  送受信部
２Ａ  ＭＬ管理サーバ
２ａ  送受信部
３    インターネット
４    受信サーバ
５    送信元ユーザ
６    エンドユーザ
１１  発信元サーバ構成定義部
１２  発信元サーバＭＬ情報収集部
１３  発信元サーバＭＬ情報管理部
１４  発信元サーバ制御情報加工部
１５  サーバ拒否情報収集部
１６  サーバ拒否情報管理部
１７  サーバ拒否情報加工部
２０  ユーザ端末
２１  ＭＬ管理サーバＭＬ情報収集対応部
２４  代理サーバ情報収集部
２５  代理サーバ情報管理部
２６  代理サーバ情報加工部
【図１】
2005020706.tif 000003
【図２】
2005020706.tif 000004
【図３】
2005020706.tif 000005
【図４】
2005020706.tif 000006
【図５】
2005020706.tif 000007
【図６】
2005020706.tif 000008
【図７】
2005020706.tif 000009
【図８】
2005020706.tif 000010
【図９】
2005020706.tif 000011
【図１０】
2005020706.tif 000012
【図１１】
2005020706.tif 000013
【図１２】
2005020706.tif 000014
【図１３】
2005020706.tif 000015
【図１４】
2005020706.tif 000016
【図１５】
2005020706.tif 000017
【図１６】
2005020706.tif 000018
【図１７】
2005020706.tif 000019
【図１８】
2005020706.tif 000020
【図１９】
2005020706.tif 000021
【図２０】
2005020706.tif 000022
【図２１】
2005020706.tif 000023
【図２２】
2005020706.tif 000024
【図２３】
2005020706.tif 000025