JP2005518173A5 - - Google Patents

Description

Ｅメール管理サービス

ここで開示される実施形態は、一般にＥメール管理システムに関し、より詳細には、トラフィックの監視及び管理に基づいて電子メッセージを監視し、フィルタリングするための、トラフィックの監視及び管理を用いるＥメール管理システム（ＥＭＳ）に関する。

Ｅメール管理は、通常は、ユーザ／加入者を有するＩＳＰにより、又はＥメールユーザを雇用する会社によってなされる。Ｅメール管理の一部には、スパム又はウィルス制御のためのフィルタリングが含まれるが、こうしたＥメール管理がＩＳＰで又は会社のサーバ位置で行われるときには、貴重な通信帯域幅及び計算リソースが、ルーティングすること、解析すること、その他のスプリアス（spurious）Ｅメールトラフィックを取り扱うことに消費されてしまう。現在のＥメール管理システムはさらに、リアルタイムの監視、フィードバック、及びＥメールトラフィック又はＳＭＴＰ接続状況に関するルールのアップデートの欠如により特徴付けられる。Ｅメールトラフィック状況の管理及び監視は、通常は、人間の介入によってなされる。
スパム又はウィルスを遮断するためのその他の現在のシステムには、おとりのＥメールアドレスをインターネット内におき、このおとりのＥメールアドレスがスパム収集体として働くシステムがある。次いで、人間のエディタが受信メッセージを調べ、それらを分類整理し、こうしたジャンクメール・メッセージとそれらのチェックサムのデータベースを作る。次いで、作成したデータベースをサービスの加入者に配布し、顧客宅で受信されたメッセージの各々がウィルス／スパムデータベースと対照してチェックされる。この場合もまた、インターネットの新しいウィルス及びスパムメッセージの検出及び監視はリアルタイムではなく、顧客宅のメールサーバは依然として全てのスプリアスＥメールを受信するので、全ての受信Ｅメールを解析してデータベースに適合するものがあるかどうか確かめなければならない。

（関連出願のクロスリファレンス）
本出願は、２００２年２月１９日付けの「Ｅ−Ｍａｉｌ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｉｃｅｓ」と題する本発明の譲受人に譲渡された米国特許仮出願第６０／３５７，８９３号に基づく優先権を主張するものであり、該特許出願を引用によりここに組み入れる。

（発明の概要）
上述の従来技術の欠点に対処するために、本発明は、１つの態様において、送信メールサーバから受信メールサーバへの電子メッセージの伝送を管理するコンピュータ処理と共に用いられるトラフィックモニタを提供し、送信メールサーバから送信されたメッセージは、送信メールサーバに関連する発信元データと、受信メールサーバに関連する宛先データとを含む。一実施形態においては、トラフィックモニタは、複数の受信電子メッセージの発信元データ及び宛先データを格納するためのデータ・マトリックスと、該マトリックスに結合されたインターフェースとを含む。この実施形態においては、インターフェースは、発信元データ及び宛先データに対して、コンピュータ処理により与えられ且つ複数の電子メッセージに基づいたメタデータを補充することを容易にし、かつこの複数の電子メッセージの処理に用いるために発信元データ及び宛先データ並びにメタデータに容易にアクセスするように構成される。
別の態様においては、本発明は、送信メールサーバから受信メールサーバへの電子メッセージの伝送を管理するコンピュータ処理と共に用いられる方法を提供し、送信メールサーバから送信されたメッセージは、送信メールサーバに関連する発信元データと、受信メールサーバに関連する宛先データとを含む。一実施形態においては、この方法は、接続プロセスを完了することなく複数の受信電子メッセージの発信元データ及び宛先データをリアルタイムで収集し、保存して、該発信元データ及び宛先データに対して、コンピュータ処理により与えられ且つ複数の電子メッセージに基づいたメタデータを補充することを含む。さらに、この方法は、コンピュータ処理において、発信元データ及び宛先データ並びにメタデータに基づき複数の電子メッセージを解析し、処理することを含む。

さらに別の態様においては、本発明は、送信メールサーバから受信メールサーバへの電子メッセージの伝送を管理するのに用いられる電子メッセージ管理システム（ＥＭＳ）を提供し、送信メールサーバから送信されたメッセージは、送信メールサーバに関連する発信元データと、受信メールサーバに関連する宛先データとを含む。一実施形態においては、ＥＭＳは、複数の受信電子メッセージの発信元データ及び宛先データを保存するためのデータ・マトリックスを有するトラフィックモニタと、データ・マトリックスへのアクセスを容易にするためのインターフェースとを含む。また、ＥＭＳは、複数の電子メッセージから外挿されたメタデータを発信元データ及び宛先データに対して補充するように構成され且つインターフェースに結合された、メッセージ取扱いプロセスを含む。この実施形態においては、ＥＭＳはさらに、発信元データ及び宛先データ並びにメタデータにアクセスして、それらに基づく処理命令を生成するように構成され且つインターフェースに結合された、インタープリタ・プロセスを含む。こうした実施形態においては、メッセージ取扱いプロセスはさらに、処理命令に基づいて複数の電子メッセージを処理するように構成される。
別の態様においては、本発明は、送信メールサーバから受信メールサーバへの電子メッセージの伝送を管理する方法を提供し、送信メールサーバから送信されたメッセージは、送信メールサーバに関連する発信元データと、受信メールサーバに関連する宛先データとを含む。一実施形態においては、この方法は、複数の受信電子メッセージの発信元データ及び宛先データをデータ・マトリックスに保存し、複数の電子メッセージからメタデータを外挿することを含む。さらに、この方法は、発信元データ及び宛先データに対してメタデータを補充することと、インターフェースを介して発信元データ及び宛先データに並びにメタデータにアクセスすることを含む。この方法はまた、発信元データ及び宛先データ並びにメタデータに基づく処理命令を生成し、該処理命令に基づき複数の電子メッセージを処理することを含む。

さらに別の実施形態においては、本発明は、送信メールサーバから受信メールサーバへの電子メッセージの伝送を管理するのに用いられるＥＭＳを提供する。一実施形態においては、ＥＭＳは、複数の受信電子メッセージから送信メールサーバに関連する発信元データと受信メールサーバに関連する宛先データとを抽出するように構成された接続管理モジュールを含む。さらに、ＥＭＳは、発信元データ及び宛先データを保存するためのデータ・マトリックスと、該データ・マトリックスと接続管理モジュールとの間に結合されたインターフェースとを含む。こうした実施形態においては、インターフェースは、複数の受信電子メッセージから外挿されたメタデータを発信元データ及び宛先データに対して補充することを容易にし、かつ発信元データ及び宛先データ並びにメタデータへのアクセスを容易にするように構成される。こうした実施形態においては、接続管理モジュールはさらに、発信元データ及び宛先データ並びにメタデータに基づいて、送信メールサーバからの複数の受信電子メッセージのいずれかを受諾するように構成される。
さらに別の実施形態においては、本発明は、送信メールサーバから受信メールサーバへの電子メッセージの伝送を管理する方法を提供する。一実施形態においては、この方法は、複数の受信電子メッセージから送信メールサーバに関連する発信元データと受信メールサーバに関連する宛先データとを抽出することを含む。この方法はまた、複数の電子メッセージから外挿されたメタデータを発信元データ及び宛先データに対して補充し、発信元データ及び宛先データ並びにメタデータに基づいて、送信メールサーバから複数の電子メッセージのいずれかを受諾することを含む。

さらに別の実施形態においては、本発明は、送信メールサーバから受信メールサーバへの電子メッセージの伝送を管理するのに用いるＥＭＳを提供する。一実施形態においては、ＥＭＳは、送信メールサーバに関連する発信元データと受信メールサーバに関連する宛先データとを保存するためのデータ・マトリックスを含む。ＥＭＳはまた、複数の電子メッセージから外挿されたメタデータを発信元データ及び宛先データに対して補充することを容易にし、かつ発信元データ及び宛先データ並びにメタデータに容易にアクセスするように構成され且つデータ・マトリックスに結合された、インターフェースを含む。この実施形態においては、ＥＭＳはさらに、発信元データ及び宛先データ並びにメタデータに基づいて、複数の受信電子メッセージのいずれかを受信メールサーバに配信するように構成され、且つインターフェースに結合された配信管理モジュールを含む。

さらに別の実施形態においては、本発明は、送信メールサーバから受信メールサーバへの電子メッセージの伝送を管理するのに用いる方法を提供する。一実施形態においては、この方法は、複数の受信電子メッセージからの送信メールサーバに関連する発信元データと受信メールサーバに関連する宛先データとを保存することを含む。この方法はまた、複数の電子メッセージから外挿されたメタデータを発信元及び宛先データに対して補充することを含む。こうした実施形態においては、この方法はさらに、発信元データ及び宛先データ並びにメタデータに基づいて、複数の電子メッセージのいずれかを受信メールサーバに配信することを含む。
上記は、本発明の好ましい選択的な特徴を概説するものであり、当業者であれば、以下の本発明の詳細を良く理解することができるであろう。以下に、本発明の特許請求の主題となる本発明の付加的な特徴を説明する。当業者であれば、本発明と同じ目的を実行するために他の構造を設計し又は修正するための基礎として、開示された概念及び特定の実施形態を直ちに使用できることを認識するであろう。また、当業者であれば、こうした均等構成が、本発明の精神及び範囲から逸脱するものではないことを理解するであろう。

本発明のより完全な理解のために、添付の図面と組み合わされた以下の詳細な説明について言及する。種々の特徴が正確なスケールで描かれているわけではないことを強調しておく。実際には、種々の特徴の寸法は、説明を簡単にするために任意に増減されている場合がある。さらに、説明を簡単にするために幾つかのコンポーネントが図示されていない場合があることを強調しておく。添付の図面と組み合わされた以下の詳細な説明について言及する。
最初に図１を参照すると、図示されているのは、インターネット１０１又は他のコンピュータ・ネットワークにわたるＥメールメッセージの配信のための従来技術のシステム１００である。送信メールサーバ１０２ａ、１０２ｂ（関連する発信元インターネット・プロトコル（ＩＰ）アドレスを有する）及び受信メールサーバ１０２ｃ、１０２ｄ（関連する宛先ＩＰアドレスを有する）、又は他のメッセージ・ゲートウェイは、電子メール（すなわち「Ｅメール」）のような電子メッセージを、送信顧客マシン１０４ａ−１０４ｄと受信顧客マシン１０４ｅ−１０４ｈとの間で、又は移動電話、ページャ（携帯無線呼出し器）、及び／又はハンドヘルドコンピュータのような他の装置との間で配信できるようにする。通常のシステムによれば、Ｅメールの伝送方向は逆であってもよく、その場合、送信マシン及びサーバは、受信マシン及びサーバとなり、逆もまた同様である。

Ｅメールメッセージは、典型的には、顧客マシン１０４上で動作するアプリケーションによって作成される。メッセージの作成が完了すると、ユーザは、完成したメッセージをメールサーバ１０２にアップロードする。一実施形態においては、メールサーバ１０２は、インターネットサービスプロバイダ（ＩＳＰ）か、又はユーザが働く私法人が所有する。ダイヤルアップ、デジタル加入者線システム（ＤＳＬ）、インターネットケーブルを介して、又は他の適切な手段により、ユーザ顧客マシン１０４がメールサーバ１０２に接続される。Ｅメールフォーマットの１つの標準は、ＲＦＣ２８２２によって過去のものとなったＲＦＣ８２２により説明され、これらはそれぞれ、インターネット技術特別調査委員会（「ＩＥＴＦ」）により公布された、標準及び提案された標準である。Ｅメールメッセージを送信メールサーバ１０２から受信メールサーバ１０２に伝送するためのプロトコルは、ＲＦＣ２８２１によって過去のものとなったＲＦＣ８２１により説明され、これらもそれぞれＩＥＴＦの標準及び提案された標準である。これらの標準は、ＷＷＷ．ｉｅｔｆ．ｏｒｇで見ることができる。ＲＦＣ８２１及びＲＦＣ８２２標準、ならびにＲＦＣ２８２１及びＲＦＣ２８２２提案標準の主題を、引用により本開示に組み入れる。提案された標準が、２００１年４月発行のバージョンから更新される場合には、引用によりここに組み入れられるのは、これらの提案された標準の２００１年４月バージョンの主題である。ＲＦＣ８２１及びＲＦＣ２８２１文書は、シンプル・メール・トランスポート・プロトコル（「ＳＭＴＰ」）を説明するものであり、典型的には、そのプロトコルによって、Ｅメールメッセージがインターネット上で運ばれる。

ＳＭＴＰサーバ及びＳＭＴＰ顧客（ＳＭＴＰ顧客は、ネットワークコンピュータであって、顧客マシン１０４とは混同されない）は、メール配達サービスを与え、それによりメール転送エージェント（「ＭＴＡ」）として働く。メール・ユーザ・エージェント（「ＭＵＡ」又は「ＵＡ」）は、普通は、メールの発信元及び宛先と考えられる。発信元においては、ＭＵＡは、発信元メールサーバ１０２ａ、１０２ｂであって、ユーザから送信されたメールを収集し、それをネットワーク１０１内のＭＴＡに渡すことができる。最後の（「配信」）ＭＴＡは、メールをＭＵＡに渡すものと考えられ、ユーザのメールボックスの中のユーザのメールを保持する宛先メールサーバ１０２ｃ、１０２ｄとなるであろう。
ＳＭＴＰメール配達プロトコルは、メッセージを送信者からＥメール受信者にルーティングするのにドメイン名を用いる。特定のドメイン名に対応するＴＣＰ／ＩＰアドレスの分散型データベースが、インターネット１０１を横断するドメイン名サーバ（「ＤＮＳ」）１０８に維持される。したがって、Ｅメールを宛先にルーティングするために、発信元メールサーバ１０２ａ、１０２ｂが、通常は送信ユーザによって指定されるアドレスを受け取り、特定のアドレス指定されたドメイン名に割り当てられることになるＩＰアドレスを、ＤＮＳサーバ１０８に問い合わせる。本明細書で用いられる「アドレス」は、メールが送信されることになるユーザ、メールを送信するユーザ又は発信元、或いはメールが置かれることになる場所を識別する文字列である。「メールボックス」という用語は、保管所のことをいう。これら２つの用語は、典型的には、メールがおかれる場所（メールボックス）と、その場所の参照（アドレス）との区別が重要でない場合には、交換可能に用いられる。アドレスは、普通は、ユーザ及びドメイン指定からなるが、アドレスは、使用とアドレス形式に応じて異なる形態をとってもよい。標準的なメールボックス命名規則は、「ローカル部分＠ドメイン」と定義され、最新の使用は、単純な「ユーザ名」より非常に幅広い組の適用を可能にする。アドレスのローカル部分は、典型的には、アドレスのドメイン部分において指定されるホストによってのみ解釈され割り当てられる意味規則（セマンティクス）である。対照的に、標準的なインターネット・プロトコル（ＩＰ）アドレスは、典型的には、発信元又は宛先サーバを識別する特定の数の列である。
発信元メールサーバ１０２ａ、１０２ｂが、Ｅメールが配信されることになるドメインを処理のために字句的に識別すると、ＤＮＳサーバ１０８を通じてＤＮＳ検索が行われ、ドメイン名が解析される。次いで、Ｅメール１１０が、発信元メールサーバ１０２ａ、１０２ｂからインターネット１０１経由で識別されたドメインに送られる。

次に図２を参照すると、図示されているのは、インターネット１０１と受信メールサーバ２０２との間にアクティブな電子メッセージ（例えばＥメール）管理システム（ＥＭＳ）２０３が与えられる実施形態のブロック図２００である。本発明のＥＭＳ２０３は、該ＥＭＳが、管理プロセスの種々の段階で人間の介入を必要とすることなく、電子メッセージの試行された伝送を常に管理するので、「アクティブ」であり、自動化されている。その意味で、ここで開示された原理に係るＥＭＳ２０３は、自動化されており、メッセージの配信をリアルタイムで管理するように構成される。ＥＭＳシステムは、送信者と受信者との間のＳＭＴＰ接続の各々が処理されるときに処理ステップを実行することにより、状態を解釈し、パターンを解析し、受信サーバ２０２へのデータの配信を管理することができる。従来のＥメールサーバは、典型的には、メッセージデータを受け取り、解析を行う前に該メッセージをディスクに書き込むことになる。ＥＭＳ２０３は、ＳＭＴＰトランザクションの各段階で管理ステップを実行して、セキュリティと管理を与えながら宛先サーバ２０２に対する影響を最小にすることができる。メールサーバ２０２に宛てられ、それにより受信顧客端末２０４に宛てられるメールが、ＥＭＳ２０３を通してルーティングされるためには、目標とされたメールサーバ２０２のドメイン名に関連するＤＮＳ１０８における数値ＩＰアドレスが、ＥＭＳ２０３の数値アドレスを反映するように更新される。例えば、メールサーバ２０２のドメイン名が「ａｎｙｗｈｅｒｅ．ｃｏｍ」であり、メールサーバ２０２とＥＭＳ２０３の数値ＩＰアドレスが、それぞれ「１２３４．５６７８．９８７６．５４３２」及び「９８７６．５４３２．１２３４．５７６８」であると仮定する。そのとき、分散型ＤＮＳデータベース１０８における「ａｎｙｗｈｅｒｅ．ｃｏｍ」についてのレコードは、「１２３４．５６７８．９８７６．５４３２」ではなく、ＥＭＳの数値アドレス「９８７６．５４３２．１２３４．５７６８」を反映するように更新されることになる。
この図は、ＥＭＳ２０３を、メールサーバ２０２に物理的に隣接するものとして示しているが、こうした配置は、図示する目的のためのものである。ＥＭＳ２０３は、インターネット１０１上のどこかに配置することができる。ＥＭＳ２０３は、位置「Ａ」（ファイアウォールの外側）か、又は位置「Ｂ」（ファイアウォールの内側）における随意的なファイアウォール２１０位置によって示されるように、メールサーバ２０２のファイアウォール２１０に関連する外部か又は内部のいずれかに配置することもできる。或いは、ＥＭＳ２０３は、メールサーバ２０２と同じ物理的マシン上で動作することもできる。

次に図３を参照すると、図示されているのは、ＥＭＳ２０３のブロック図３００を含む、より詳細な図である。実際のＥＭＳシステム２０３と同じ特定のサーバマシン上に、管理コンソールウェブページ３１６（管理モジュール３１８を含む）を置いて、ＥＭＳ２０３がどのように受信電子メッセージを処理するか設定するのを助ける管理アクセスツールを与えることができる。ＥＭＳ２０３とメールサーバ１０２ａ、１０２ｃとの間の接続は、インターネットか又はＳＭＴＰ接続を通じて行うことができる。既に述べたように、ＥＭＳ２０３は、メールサーバ１０２ａ、１０２ｃの１つがある又はない特定のファイアウォールの内部に又は外部に存在させることができる。
通常、図３に示されたシステムは、「送信」メールサーバ１０２ａからのメールを取り扱う。「送信側」としての１つのメールサーバと、「受信側」としての他のメールサーバの指定は、任意のものである。事実上、両方のメールサーバ１０２ａ、１０２ｃは、一般に、メールサーバ１０２ａ及び１０２ｃの送信及び受信顧客１０４ａ、１０４ｅの間で電子メッセージの送信側と受信側との両方として働くことになる。図示された実施形態においては、メールサーバ１０２ａ、１０２ｃのドメイン名の少なくとも１つは、ＤＮＳ分散型データベース及びそのサーバ１０８においてＥＭＳ２０３に関連付けられることになる。管理コンソール３１６を採用する実施形態においては、コンソール３１６は、ユーザに送信された疑わしいウィルス及びスパムＥメール、ディレクトリ獲得攻撃、又は望ましくないコンテンツ又は配信試行に関する情報のような、特定のユーザ又はユーザのグループに宛てて受信する電子メッセージの形式に関する、ＥＭＳ２０３からの情報を受信する。ユーザ又は組織のためにＥＭＳ２０３によって適用されるフィルタリングのパラメータを設定するのに用いられるのが、管理コンソール３１６である。管理コンソール３１６は、特定のドメインから送信された法外な数のＥメール又は他の不審なトラフィックパターンのような、システムのトラフィックパターンに関するＥＭＳ２０３からの情報を受信する。管理コンソール３１６は、ウェブサーバ上か又は随意的にＥＭＳ２０３と同じ中間プラットフォーム上で動作する「管理」ソフトウェアモジュール３１８を有するウェブベースのアプリケーションであってもよい。

図３において、ＥＭＳ２０３は、相互接続された多くのソフトウェアモジュールを有するメッセージ取扱いコンピュータ処理３２０を含むものとして示されている。メッセージ取扱い処理３２０におけるこれらの種々のソフトウェアモジュールのレイアウトは、こうしたソフトウェアモジュールを動作させるマシンの物理構造を特定的に示すものではない。処理３２０に含まれるモジュールの１つは、接続管理モジュール又は簡単には接続マネジャ３２２である。接続マネジャ３２２は、ＵＡ／メールサーバ１０２ａ（又はメール転送エージェント）からの受信ＳＭＴＰ接続をセットアップし、監視する役割を果たす。接続マネジャ３２２は、ＥＭＳ２０３への入口点であり、受信ＳＭＴＰ接続試行及びＥメールメッセージを監視する。処理３２０はさらにトラフィックモニタ３４０に接続され、該トラフィックモニタが、受信ＳＭＴＰ接続データ、メッセージメタデータ、及びメッセージ配信情報を収集する。

特定の形式のソフトウェア・デーモンとすることができるインタープリタ・プロセス３５０がさらに与えられる。インタープリタ・プロセス３５０は、トラフィックモニタ３４０におけるデータと相互に作用して、動作可能なメッセージのトラフィック内のメッセージパターンを認識する。より具体的には、それら全てが処理３２０の一部を構成する、接続マネジャ３２２、Ｅメールハンドラ３２６、アプリケーション３３２、及び配信管理モジュール（又は簡単には配信マネジャ３２４）が、受信メッセージの処理中に、発信元及び宛先データ並びにメタデータをトラフィックモニタ３４０に書き込む。発信元及び宛先データは、送信メールサーバ１０２ａに関連する発信元データと、受信メールサーバ１０４ｅに関連する宛先データとからなる。メタデータは、処理３２０によって、コンテンツの形式又はサイズにより定められる特定のメッセージのような望ましくないメッセージを検出するプログラム・スレッドであるアプリケーション３３２を用いて電子メッセージから外挿される。表１は、ＥＭＳ２０３により生成されたメタデータのより詳細な例を示すが、このリストは、他を除外することを意図されているものではない。

（表１）

電子メッセージのパターン、又はさらにはメッセージを送信するユーザの挙動を判断するために、インタープリタ・プロセス３５０が、トラフィックモニタ３４０に書き込まれた発信元及び宛先データ並びにメタデータの両方を解析する。例えば、多数のメッセージが同じ外部ＵＡメールサーバ１０２ａから受信する場合、これは、スパム攻撃、又は他のサービスの拒絶、或いは望ましくない配信アクティビティを示すであろう。インタープリタ・プロセス３５０は、トラフィックモニタ３４０に格納された発信元及び宛先データ並びにメタデータのパターンを通じてこうした傾向に気付き、メールハンドラ３２６における厄介なＥメールを遮断するアクションを開始することができる。好都合な実施形態においては、インタープリタ・プロセス３５０は、こうしたタスクのために作成された特定のソフトウェア・デーモンであるが、本発明は、どんな特定の実施形態にも限定されるものではない。インタープリタ・プロセス３５０が発信元及び宛先データ並びにメタデータに基づいて検出することができる他のパターン又は状態の例には、この限りではないが以下の事象、すなわち、
・サーバ上の有効なアドレスのリストをコンパイルするべく、統計学上顕著な割合の配信試行が正当でないユーザに向けられるディレクトリ獲得攻撃の検出、
・同じ又は同様のメッセージが同じユーザ又はユーザグループに繰り返し配信されるＥメール爆弾の検出、
・発信元ＩＰアドレスから送信される顕著な割合のデータがスパムであるか又はそうでなければ望ましくないＥメールであるスパム攻撃、
・発信元ＩＰアドレスから送信される顕著な割合のデータがウィルス感染したものであるウィルス攻撃、
・送信ＩＰアドレスが繰り返し接続され、その接続がオープンに保たれるか、又は意味のあるデータが配信されない、サービス接続要求の妨害、
・接続試行が失敗し、メッセージが宛先変更されるか又はスプールされる、不応答の顧客サーバ、
・顧客サーバの容量が閾値にあり、さらなるメッセージを受信できない、容量が閾値にある顧客サーバ、
・アイドル状態にある顧客サーバが未使用容量を有し、より多くのメッセージを受信することができる、アイドル（不動）状態にある顧客サーバ、
・受信側サーバの割当てローテーションにおける次のＥメールサーバが次のメッセージを受信する、次のサーバ、
・顧客サーバが要求を処理することができないことを示唆する据え置きエラーを戻す、ビジー（動作）状態の顧客サーバ、
がある。

この実施形態においては、データベース３６０はまた、インタープリタ・プロセス３５０のアクション及び／又はフィルタリングされたＥメールに関する情報をログに記録し、トラフィックモニタ３４０において認識されるパターンに基づきメッセージ処理アクションを適用するための構成パラメータを保存するために与えられる。管理コンソール３１６がデータベース３６０にアクセスし、次いでインタープリタ・プロセス３５０にアクセスして、とられるアクションを再検討することができ、システムをある種の状況においてとられるアクションに関して構成することができる。
概念上、処理３２０の他方の側には、ＥＭＳ２０３がメッセージを送信する受信ＵＡメールサーバ１０２ｃの状態をリアルタイムで知る能力を有する配信マネジャ３２４がある。接続マネジャ３２２と配信マネジャ３２４との間には、ＥＭＳ２０３内の全てのプロセスを管理するメールハンドラ３２６がある。メールハンドラ３２６は、概念上、多目的インターネットメール拡張子（ＭＩＭＥ）デコーダ３２８と、アプリケーション・インターフェース３３０に接続される。アプリケーション・インターフェース３３０は、メールハンドラ３２６とアプリケーション３３２との間のインターフェースを与え、トラフィックモニタ３４０にメタデータの基礎となる情報を書き込むのを助ける。

データベース３６０に格納されたルールにより確立される構成に従い、インタープリタ・プロセス３５０が、上述のようにトラフィックモニタ３４０に保存されたデータのパターンを解釈し、接続管理テーブル（conmanテーブル）３７０のレコードをアップデートする。接続管理テーブル３７０は、典型的には措置命令の形態のこのメッセージ処理情報を保存し、受信メッセージ及び特定の発信元ＩＰアドレスについての接続及び配信がどのように処理されるかを規制する。接続管理テーブル３７０のレコードにおける措置フラグの形で現れる処理命令の例は、この限りではないが以下の事象、すなわち、
・メッセージ受諾、
・メッセージ拒否、
・メッセージ検疫、
・メッセージスプール、
・メッセージ据え置き、
・メッセージ抑制、
・メッセージ宛先変更、
・ブラックホール
を含む。

一例においては、１つの特定のアドレスがスパミングであったり、又は別の手法で望ましくないメッセージを１つの特定の顧客に送信するものであると知っている場合には、ＳＭＴＰ接続を拒否するか又は抑制し、それにより組織を防護するために、接続管理レコード（接続管理レコード）を接続管理テーブル３７０に書き込む。したがって、発信元及び宛先データ並びにメタデータに基づいてパターン及び挙動を確認することができ、接続管理レコードをロールアップし、全ての顧客ベースに適用することができる。その後の同様のメッセージ配信要求に対して害を与える状態が確認されると、その送信ＩＰアドレスからの要求を取り扱うことについての特定の命令が存在するかどうかを判断するために、接続マネジャ３２２が接続管理テーブル３７０に問い合わせる。措置フラグが存在する場合には、接続マネジャ３２２が接続管理テーブル３７０における措置命令を用いて、メッセージを適切に処理するか、又は第１位置にある送信メールサーバ１０２ａによる接続を防止する。宛先ユーザにメッセージを伝送するのを防止する条件に応じて、接続マネジャ３２２による接続が受諾される場合であっても、配信マネジャ３２４は、インタープリタ・プロセス３５０により配信管理テーブル３８０を介してメッセージを適切に処理するように命令されてもよい。配信管理テーブル３８０は、インタープリタ・プロセス３５０か又は各ＥＭＳプロセス２０３が、トラフィックモニタ３４０に保存されたデータに基づくメッセージ処理命令を該テーブル３８０に書き込むという点では、接続管理テーブル３７０と同様のものである。接続管理テーブル３７０ではなく配信管理テーブル３８０において見られる措置命令には、この限りではないが以下の事象、すなわち、
・メッセージ配信
・メッセージ据え置き
・メッセージ拒否
・メッセージ宛先変更
がある。メッセージハンドラ３２６の幾つかのコンポーネント、並びにそれらの機能のより詳細な説明を、図４を参照しながら以下に示す。

次に図４を参照すると、図示されるのは、メッセージ取扱いコンピュータ処理３２０の、より詳細なソフトウェア・モジュールのブロック図４００である。この実施形態におけるメールハンドラ３２６は、高速の国境のない（stateless）メールハンドラとなるように設計されたメッセージ処理サーバ（ＭＰＳ）４２６を含む。ＭＰＳ４２６は、受信Ｅメールメッセージ１１０を取り上げ、該メッセージが通過する際に、すなわちメッセージ１１０の配信に遅延を与えることなく、該メッセージ１１０から情報を「すくい取る」又は抽出することができる。ＭＰＳ４２６はまた、配信マネジャ３２４を介して、おのずから又はインタープリタ・プロセス３５０（図３参照）からの命令に従って、メッセージを条件付きで配信することができる。例えば、インタープリタ・プロセス３５０が、トラフィックモニタ３４０のデータから、共通の発信元ＩＰアドレスからの接続試行又は接続試行群がディレクトリ獲得攻撃であると判断した場合には、該インタープリタ・プロセス３５０は、接続管理テーブル３７０をアップデートして、接続マネジャ３２２に接続を拒否するように命令する。或いは、インタープリタ・プロセス３５０は、配信管理テーブル３８０をアップデートして、配信マネジャ３２４に他の手法でメッセージを処理するように命令する。スパム検出アプリケーション３３２のようなアプリケーションが、スパムであると思しきメッセージの値を戻す場合には、ＭＰＳ４２６は、インタープリタ・プロセス３５０と協働して、メッセージの配信を検疫ウェブサイトにルーティングするように構成することができる。電子メッセージをパスすること、方向転換すること、据え置くこと等の決定は、一部には、受信メッセージの体系から生成されたメタデータに基づいて、及びメッセージを処理するために選択された管理コンソール３１６及びアプリケーション３３２を通じてＥＭＳ２０３が構成される方法に基づいて下される。

図４には付加的なサブモジュールも示されている。この実施形態においては、ＥＭＳ２０３に受信する電子メッセージからデータを収集し、その情報をトラフィックモニタ３４０に与えるといった図３の実施形態について説明された機能を実行する、メタデータ・コレクタ・サブモジュール４３０及びイベント・センダ・サブモジュール４３２が与えられる。これらのサブモジュールはＭＰＳ４２６に関連して示されるが、それらは、別個のソフトウェアモジュールとすることもできるし、又はメタデータ・コレクタ４３０と関連付けることもできる。アプリケーション３３２は、接続管理テーブル３７０に特に書き込みしないが、それらは、アプリケーション・インターフェース３３０を介して、ａ）メッセージを処理する、ｂ）処理結果に基づいて措置フラグをアップデートする、ｃ）メタデータをトラフィックモニタ３４０に配信するように構成することができる。
図３−図４に示された実施形態の別の特徴は、宛先ＵＡのＥメールサーバ１０２ｃにおけるローディングに従ってＥメールの配信を調整する機能である。配信マネジャ３２４は、例えば、前のＥメールメッセージの受け取りを確認する際のサーバ１０２ｃによる遅延によって、宛先ＵＡのＥメールサーバ１０２ｃのローディング問題を検出することができる。したがって、出力バッファリレー４４０及びスプールリレー４４２が、宛先ＵＡのＥメールサーバ１０２ｃの検出されたローディング問題に基づいて、出力メッセージをスプールするように働く。

次に図５を参照すると、図示されるのは、２つ又はそれ以上のメッセージ取扱いコンピュータ処理３２０ａ、３２０ｂの各々が、独立して動作するが、単一のトラフィックモニタ３４０及び接続管理テーブル３７０に接続されている実施形態を示すブロック図５００である。各処理３２０ａ−ｎはまた、受信サーバと現在オープンな接続に関するデータを共有する。この共有された配信管理テーブル３８０は、全てのメッセージが受信サーバを通過するいずれの時点においても現在のステータスを含む。処理３２０ａ、３２０ｂは、Ｅメールトラフィックのストリーミングにおいて発生するイベントについてのメタデータをトラフィックモニタ３４０に送るイベント・センダ４３２ａ、４３２ｂを含む。トラフィックモニタ３４０は、処理３２０ａ、３２０ｂのイベント・センダ４３２ａ、４３２ｂへの通信インターフェースであるイベント・リスナ５０２を有する。したがって、この実施形態におけるトラフィックモニタ３４０及びインタープリタ・プロセス３５０は、図示のように多数の受信電子メッセージストリームの多数の処理３２０ａ、３２０ｂを監視し、制御する。

トラフィックモニタ３４０内の幾つかのデータの編成の例として、データテーブル５０４の形態の例示的なデータ・マトリックスが示されている。このデータテーブル５０４においては、多数の発信元から多数の宛先へのＥメールの生起は、特定の発信元からのメッセージが行に沿ってマッピングされ、特定の宛先へのメッセージが列に沿ってマッピングされるテーブルとして配列されている。スパムの可能性があるものは、多くの割合の宛先が特定の発信元からのメッセージを受信し、それによりテーブル５０４における行がほぼフル状態であるように見える事例として、テーブル５０４に示される。次いで、インタープリタ・プロセス３５０は、データベース３６０を参照して、該インタープリタ・プロセス３５０が管理コンソール３１６を介してそのルールの構成の下で動作するように命令される、該データベース３６０におけるルールを調べる。
したがって、ユーザは、データベース３６０を通じてインタープリタ・プロセス３５０を構成する。例示的なルールは、スパム攻撃（例えば、単一のＩＰアドレスからの１００又はその他の数のメッセージ）と、そのＩＰアドレスへの許可される接続数を制限すること、又はそのＩＰアドレスからの全ての受信Ｅメールを削除することといった、スパム攻撃に対してとられるアクションの定義を含むこととなる。メッセージ取扱いルールの作成を促す他の状況の例は、前述のようなウィルス攻撃、ディレクトリ獲得攻撃、Ｅメール爆弾等であろう。ルールがデータベース３６０に格納されると、そのデータベース３６０に関連する全ての接続マネジャ３２２ａ、３２２ｂ及び配信マネジャ３２４ａ、３２４ｂが、宛先ＩＰアドレスに基づいて、データベース３６０及び接続管理テーブル３７０における構成情報を各メッセージのトランザクションにおいて使用して、最新のルールセットの下で動作することを確実なものにする。既に述べたように、接続マネジャ３２２ａ、３２２ｂは、このプロセスの間にトラフィックモニタ３４０にイベント情報を与える。

トラフィックモニタ３４０を監視するインタープリタ・プロセス３５０は、トラフィックモニタ３４０において検出された、指定のルールに違反するパターンに基づいて、接続管理テーブル３７０をアップデートすることができる。コンピュータ処理３２０ａ、３２０ｂのモジュールは、各メッセージ・トランザクションにおいて、データベース３６０、接続管理テーブル３７０、及びトラフィックモニタ３４０に接続されて、ルール又は配信管理テーブル３８０により示される最新の構成及びアクセス制限を受信し、現在の状態に基づいて、宛先サーバへの配信についての命令を受ける。したがって、システムは、最新の接続及び配信情報によりそれ自身で絶えず更新され、それえにより、人間の検閲又は介入なしに、電子メッセージトラフィックの負荷の変化にリアルタイムで適応される。インタープリタ・プロセス３５０は、全てのＭＰＳ４２６ａ、４２６ｂにおける全ての接続マネジャ３２２ａ、３２２ｂによって問い合わせされる接続管理テーブル３７０をアップデートし、それによりルールにおいて公布された必要とされるアクティビティを、全てが同時に知ることとなる。

さらに、多数の配信マネジャ３２４ａ、３２４ｂ及び／又は接続マネジャ３２２ａ、３２２ｂが互いに通信するシステムを構成することが可能である。例えば、配信マネジャ３２４ａ、３２４ｂの１つが、宛先メールサーバが遅いことに気付いた場合には、配信マネジャ３２４ａ、３２４ｂは、全ての他の配信マネジャ３２４ａ、３２４ｂに、特定の宛先サーバへのメッセージの配信を据え置くか又は遅らせるように通知する。
全てのトランザクションデータはログ５０６に格納される。ログ５０６は、全てのメッセージ・トランザクション及びパラメータのレコードを保持することになる。例示的な実施形態においては、どんなサーバがどんな特定の宛先アドレスに送信したかについての詳細なレポート５０８が、恐らくは日々生成される。こうした実施形態においては、このデータは、グラフィカル・ウェブベース・フォーマットで与えられるか、又はユーザにより生データとしてダウンロードされてもよい。レポート５０８を生成することができる情報には、この限りではないが、発信元ＩＰアドレス、メッセージコンテンツ形式、メッセージ容量、受信者情報等がある。
システムの状態の管理者に通知するための警告５１０を構成することもできる。例えば、ＥＭＳ２０３がディレクトリ獲得攻撃を検出した場合には、インタープリタ・プロセス３５０が、接続管理テーブル３７０をアップデートし、指定された受信者に警告を発する。別の例においては、メールサーバがダウンした場合には、インタープリタ・プロセス３５０が接続管理テーブル３７０における措置フラグをスプールに更新し、指定された受信者に警告を発する。したがって、警告５１０は、インタープリタ・プロセス３５０が識別する全ての状態に基づいて発することができる。

一実施形態においては、図６によれば、ユーザデータベース階層６００が確立され、該階層６００内のユーザの位置に従って、接続を管理する及びメッセージデータを走査するために識別及び措置並びに他のイベントのパラメータを調整することができる。システム内の全てのユーザは、階層の最上位６０２より下に位置し、それによりシステムに所属する全てのユーザに対する一定のルールが確立されることになる。
最上位６０２より下において、ユーザは、最上位６０２に位置する管理者の顧客６０４ａ−６０４ｃである従属的組織に所属してもよい。例えば、Ａｃｍｅ社にいるユーザが、ｕｓｅｒ１＠ａｃｍｅ．ｃｏｍというＥメールアドレスをもち、ａｃｍｅ．ｃｏｍというアドレスが、分散型ＤＮＳデータベースサーバ１０８におけるＡｃｍｅと関連付けられた最上位６０２のドメインサーバアドレスであるとする。Ｅメールは、最上位６０２のルールに従って動作することになる。さらに、ｕｓｅｒ１が階層における「顧客＃１」６０４ａとしての特定の要件を示すことになるので、ａｃｍｅ．ｃｏｍの特定のルールがそれらのユーザに適用されることになる。しかしながら、ｕｓｅｒ１の特定の要件は、「顧客＃２」６０４ｂ又は「顧客＃３」６０４ｃと関連付けられたユーザ群には適用されない。
さらに、時には、組織が従属的組織６０６ａ、６０６ｂを有し、その結果、ｃｏｒｐ．ａｃｍｅ．ｃｏｍ及びｕｓａ．ａｃｍｅ．ｃｏｍといった異なるドメイン名が与えられることがある。ここで説明される実施形態は、必ずしも各ユーザ別に個別化された完全なルールセットを実施する必要なしに、そうした個別化も可能ではあるが、カスタムルールが階層の下位に逐次に同様に適用されることを可能にする。

次に図７を参照すると、図示されているのは、図６の階層に関連するイベントに対して動作するために接続マネジャによって使用され得るデータベース構造７００である。このデータベース構造７００によれば、接続管理テーブル３７０で用いられる接続管理レコード７１０は、内部識別子（「ＩＩＤ」）７１０ａによって編成され、該レコード７１０は、受信者が階層６００内のどこに存在するか、並びにどの構成パラメータが設定されるかについてのレコードである。同じく図示されるのは、メッセージのＩＰアドレスを発生させる開始ＩＰアドレス７１０ｂ及び終了アドレス７１０ｃのための、接続管理レコード７１０に含めることができる付加的なフィールドである。他の例示的なフィールドは、接続管理レコード７１０の有効期限７１０ｄ、及び特定の接続要求に応答して接続マネジャ３２２によってとられるアクションである接続管理テーブル３７０の措置フラグ７１０ｅである。

この実施形態においては、組織的階層６００内のユーザについて定められたルールに従って接続管理レコード７１０を作成するのが、インタープリタ・プロセス３５０である。或いは、接続管理レコード７１０は、管理コンソール３１６を通じて手動で作成されてもよい。こうしたレコード７１０は、データベース３６０か、又は接続マネジャ３２２によってアクセス可能な別のデータベースに格納することができる。単一ＩＩＤが多数のレコード７１０を有してもよい。こうしたレコード７１０は、遮断され、抑制され又は他の手法で制御された送信メールサーバが、それらのメッセージ送信行為がクリーンアップされる場合には、制約なしに、正当な送信者としてのステータスを保持できるようにする有効期限値７１０ｄを含む。有効期限値７１０ｄに到達すると、接続マネジャ３２２及びＭＰＳ４２６が、その送信者からの個々のメッセージを処理することになる。それらがウィルスを送信し続ける場合には、接続管理テーブル３７０に新たなレコード７１０が設置されることになる。このプロセスは、送信者の状態が変化して、彼らが正当なＥメールメッセージを送信し始めるまで、繰り返されることになる。
同じく図７に示されているのは、接続管理テーブル３７０内の可能性のある措置フラグ７１０ｅの詳細なレコード７２０ａ−ｉである。図示された例は、メッセージ受諾７２０ａ、メッセージ拒否７２０ｂ、メッセージ検疫７２０ｃ、メッセージスプール７２０ｄ、メッセージ据え置き７２０ｅ、メッセージ抑制７２０ｆ、メッセージ宛先変更７２０ｇ、接続拒否７２０ｈ、及びブラックホール７２０ｉである。もちろん、本発明は、こうした特定の措置フラグ７１０ｅに限定されるものではない。

次に図８を参照すると、図示されているのは、動作フローチャートを通じたＭＰＳの動作の一実施形態である。図に示されるように、全てのプロセスに沿って、プロセスにより得られたデータが、かなり詳しく上記で説明したように、ＥＭＳにおけるＭＰＳの種々のコンポーネントを用いてトラフィックモニタに書き込まれる。そのデータは、次いで、接続管理モジュールにより用いられる接続管理テーブル、並びに配信管理モジュールにより用いられる配信管理テーブルにおける情報をアップデートするために、インタープリタ・プロセスによって用いられる。プロセスは開始ステップで始まり、次いでステップ８００に移行し、受信側メールサーバに接続された宛先ユーザにＥメールのような電子メッセージを送信するために、送信者が送信側メールサーバを介して接続を開く。ステップ８０２において、ここで説明された原理に従って構築されたＥＭＳが、送信者による接続試行に割り込み、ＳＭＴＰ情報（例えば送信者のＩＰアドレス）のような送信者からの情報を受信する。

ステップ８０４において、ＥＭＳが、メッセージの意図された受信者に関するＳＭＴＰ情報（例えば受信者のＥメールアドレス）のような同様の情報を受信する。ＥＭＳによって両方のデータセットが受信されると、プロセスがステップ８０６に移行し、そこでこのデータが接続管理（conman）テーブルにおけるレコードと比較される。前述のように、テーブルにおけるレコードは、インタープリタ・プロセスによって、トラフィックモニタのデータ・マトリックスに保持された情報に基づいてアップデートすることができる。送信者からの伝送に対して何らかの遮断がなされる場合には、ステップ８０６において否定応答が与えられ、伝送試行が拒否される。或いは、ＥＭＳが特定の送信者からの全てのメッセージを受諾しないと定めた場合には、プロセスは、ＥＭＳにより送信者のＳＭＴＰ情報が受信されるステップ８０２から、送信者のＩＰアドレスが接続管理テーブルにおける可能性のある措置フラグと比較されるステップ８０６に移行する。この場合には、ステップ８０４で受信者のＳＭＴＰ情報を受信する必要なしに、送信者による伝送試行が拒否されることになる。

ステップ８０６において、接続管理テーブルにおいて送信者に対する遮断が見つからない場合には、肯定応答が与えられ、プロセスがステップ８０８に移行する。ステップ８０８において、意図された受信者の情報が、ユーザデータベース又はディレクトリにおけるユーザリスト、並びに宛先サーバディレクトリにおけるユーザリストと対照して正当であるか確認される。試行された伝送が正当な受信者情報を含まない場合には、ステップ８０８において否定応答が与えられ、伝送が拒否される。また、正当な受信者がユーザデータベースに見つかる場合であっても、受信者情報が宛先サーバデータベースにおけるユーザリストと対照して正当であると確認されないならば、伝送は拒否される。ユーザデータベースと宛先サーバデータベースとの両方からの正当性確認が得られた場合に、肯定応答が与えられ、プロセスがステップ８１０に移行する。

ステップ８１０において、意図されたメッセージを宛先サーバに配信できるかどうかを判断するために、配信管理テーブルに問い合わせする。例えば、配信管理テーブルは、宛先サーバが伝送を受信できるかどうか、又は負荷限界に達しているかどうかを判断するために問い合わせされてもよい。宛先サーバがメッセージを読み取って受信しない場合には、ステップ８１０において肯定応答が与えられ、後で宛先サーバがメッセージを受信できるようになったときに配信するために伝送試行が据え置かれる。宛先サーバがメッセージを受信できる場合には、ステップ８１０において否定応答が与えられ、プロセスがステップ８１２に移行する。図に示されるように、送信者及び受信者に関するデータが、このプロセスの全体を通してトラフィックモニタに書き込まれる。

ステップ８１２において、試行された伝送におけるヘッダ又は他のルーティング情報を含むデータ、並びに配信される意図された電子メッセージを形成するデータの全てが、ＥＭＳによって受信される。次いで、プロセスがステップ８１４に移行し、そこで、メッセージをどのように処理するかを決めるために、例えばユーザ又は組織についての構成設定により示されるルールによって定められる構成プロファイルが読み取られる。ステップ８１６において、アプリケーションを用いてメッセージデータの解析を実行し、望ましくない、禁止された又は危害を与えるメッセージを識別する。この処理結果に関連するメタデータは、トラフィックモニタに書き込まれ、接続及び配信ガイドラインを制定するのに用いられるパターン又は条件を求めるためにインタープリタ・プロセスによって用いられる。このアプリケーションを用いることによって作成されるメタデータの例は、上の表１に記載されている。

アプリケーションが解析を完了すると、プロセスがステップ８１８に移行し、そこで、アプリケーションの処理結果が、構成データベースのコンテンツと対照して比較される。アプリケーションの処理結果が、そのメッセージについて現在利用可能なフラグではなく別の措置フラグを推奨する場合には、新しい措置フラグが挿入される。ステップ８２０において、ステップ８１８からの結果が、接続管理テーブルに記載の、メッセージに割り当てられた措置フラグのいずれかと比較される。ステップ８２０において、試行された伝送を示す措置フラグがこの時点では受諾されない場合には、プロセスが接続管理テーブルにおける既存の措置フラグに対応する適切なステップに移行する。より具体的には、メッセージがスプールされる場合には、プロセスはステップ８２２に移行する。メッセージが検疫される場合には、プロセスはステップ８２４に移行する。メッセージが「ブラックホール」に送信される場合には、プロセスはステップ８２６に移行する。メッセージが据え置かれる場合には、プロセスはステップ８２８に移行する。メッセージが宛先変更される場合には、プロセスはステップ８３０に移行する。

しかしながら、ステップ８２０において、接続管理テーブルにおけるレコードが、伝送が受諾されると定める場合には、プロセスがステップ８３２に移行する。ステップ８３２において、メッセージが意図された宛先サーバに伝送される。ステップ８３４において、メッセージが宛先サーバにより受信される。ステップ８３６において、宛先サーバがメッセージ受取確認（「ＡＣＫ」）をＥＭＳに返送し、ＥＭＳにおいて配信マネジャからのメッセージ受取確認をする。最後に、ステップ８３８において、ＥＭＳがメッセージの元の送信者に伝送のＡＣＫを返送して、メッセージが宛先ユーザに伝送されたことを送信者に通知する。そこでプロセスが終了する。
当業者であれば、提案されたプロセスの実施は、図８に示された特定のステップに限定されるものではないことを理解するであろう。したがって、より多くの又はより少ない数のステップを用いることができる。さらに、図８に示されたものより多くの又は少ない詳細を有するステップも、有利に用いることができる。

次に図９を参照すると、図示されるのは、受信電子メッセージを管理するのに用いるために接続マネジャ３２２により採用される手順の一実施形態を説明する流れ図９００である。より詳細には、図９００は、送信ＩＰアドレスと、ＥＭＳ２０３により管理された組織的階層における特定の受信者の構成パラメータに基づいて、制御命令を割り当てることを説明するものである。ＭＰＳ４２６がトラフィックストリームにおける新しい受信者を識別する新しい「ＲＣＰＴ」コマンドを検出するたびに、ＭＰＳ４２６により接続マネジャ３２２の動作が開始される。接続マネジャ３２２の最初の動作条件が、図９００のステップ９０２に示されている。ステップ９０４において、接続マネジャ３２２が新しい受信者に対応するＩＩＤをもつレコードについて接続管理テーブル３７０に問い合わせする。判断ブロック９０６において、接続管理テーブル３７０が特定のＩＩＤについてのエントリを含んでいることが判断された場合には、制御は、第２の制御ループに送られ、そこで各ＩＩＤレコードが読み出され（ステップ９０８）、それが依然としてアクティブであるか又は有効期限切れであるかどうかを確かめるために試験され（ステップ９１０）、それに対して動作する（ステップ９１２）。単一のＩＩＤは、複数のレコードをもってもよく、そのため、上記のステップ９０８−９１２におけるアクションは、判断ブロック９１４で反映されるようにＩＩＤについての付加的なレコードが存在する限り、図９００に示されるように繰り返される。

図９に示すように、特定の受信者は階層内の一定のレベルに適合することができ、この方法においては、これらの階層レベルの各々に従って特定の接続アクションを調整することができる。したがって、ステップ９１６において、特定のＩＩＤが、次の上位の階層レベルにおけるメンバーシップについて試験される。接続マネジャ３２２がこの階層レベルに特定のＩＩＤに関連付けられた接続管理テーブルにおけるレコードが存在すると知った場合には、判断ステップ９１８のプロセスの流れにより、より上位のレベルにおいてＩＩＤと関連付けられたアクションの全てについて、ステップ９０８−９１４のループのアクションが繰り返される。既に述べたように、この階層レベルにおける所与のＩＩＤに関連する全てのアクションが実行され、制御が判断ステップ９２０に戻るとすぐに、階層の最上位レベルに到達したかどうかを確認するために、そのＩＩＤが該階層レベルに対して試験される。最高の階層レベルに到達した場合には、接続マネジャ３２２は制御をＭＰＳ４２６に戻す。

接続は、一対のエンドポイント、すなわち送信者及び受信者として特徴付けることができる。接続は、送信者／受信者の対に基づいて管理することができ、又は受信者の識別子のみに基づいて管理されてもよい。ＩＰアドレス範囲は、不確定位置に応じて、送信者及び／又は受信者を特定するのに用いることができ、範囲又は不確定性はまた、特定のＩＰアドレスが階層内のどこに所属するかを特定するのに用いることができる。一定のＩＰアドレス範囲により定められる組におけるＩＰアドレスのメンバーシップを、そのアドレスの階層組織メンバーシップを定義するのに用いることもできる。
接続管理レコードは、階層内の組織ごとの基準に基づいて挿入することができ、それらは、上位レベルの組織から下方の下位レベルの組織まで継承することができる。図９のプロセスの流れに関して説明したように、レコードは、特定の組織から底辺の組織までボトムアップ形式で処理することができる。単一の組織に複数のレコードが存在するとき、それらは、最も近い日に期限が切れるものを最初に試験するというように、有効期限順に処理しても良い。或いは、それらは、プロセスがどのように定義されるかに応じて、異なる順序で処理されてもよい。

前述のように、要求された接続に基づいてとることができる多くの形式のアクション又は処置が存在するが、一般的なものの１つは、以下の事象、すなわち、
・エラー：エラーメッセージが指定され、送信者に返送されること（例えば「Ｅｒｒｏｒ５０１−ｕｎｋｎｏｗｎ ｕｓｅｒ」
・検疫：規定の理由（例えば、わいせつ、ポルノ又はウィルス感染）の下でメッセージが検疫されること。
・ブラックホール：メッセージが配信されるように見える（すなわち、配信確認が送信者に送られる）が、実際にはどこへも行かないこと。さらなる修正が行われない限り、別のアプリケーションがメッセージを検疫させることもある。
・受諾：メッセージが受諾され、宛先サーバに転送されること。さらなる修正が行われない限り、別のアプリケーションがメッセージを遮断することもある。
・スプール：ＩＩＤに対応するＥメールサーバが応答せず、それによりメッセージがスプーラに書き込まれること。
前述のように、接続マネジャ３２２は、電子メッセージ・トランザクションにおける要求された接続の受諾及び実行を取り扱う。前述の措置は、接続マネジャ３２２が管理コンソール３１６を通じた手動構成によって実施することができ、又はそれらは、インタープリタ・プロセス３５０か又は別のソフトウェアモジュールによって自動的に実施されてもよい。図８のプロセスと同様に、図９に示されたプロセスの実施は、ここで説明された特定のステップに限定されるものではない。したがって、より多くの又はより少ない数のステップを採用することができる。さらに、図９に示されたものより多くの又はより少ない詳細を有するステップを有利に用いることもできる。

次に図１０を参照すると、図示されているのは、図３−図４に伴う本文においても概略的に説明されたインタープリタ・プロセス３５０の作動流れ図１０００である。インタープリタ・プロセス３５０のプロセスフローの実行はステップ１００２で始まり、それはプロセスのスリープ状態である。一定時間後に、例えば１５秒後に、プログラムフローの実行がステップ１００４に移行する。ステップ１００４において、ＥＭＳ２０３が応答できる全ての組織についてのＥＭＳ２０３の構成がアップデートされる。このプロセスは、「同期」と呼ぶこともできる。ステップ１００６において、インタープリタ・プロセス３５０が、ステップ１００４で識別された各組織について生起するトラフィック・イベントを解析し始める。このアクションの一部として、ＥＭＳ２０３は、トラフィックモニタ３４０に格納されたデータに反映された際に生起するトラフィック・イベントを評価する。

プロセスフローがステップ１０１０に続き、そこでＥＭＳ２０３が、考慮中の組織についての特定のＥＭＳ２０３イベントルールのイベント状態を評価する。判断ステップ１０１２において、インタープリタ・プロセス３５０のソフトウェアが、特定のルールがアクティブなものであるかどうかを問い合わせる。ルールがアクティブではない場合には、プロセスフローは判断ステップ１０４に進み、そこでソフトウェアモジュールが、特定の組織について処理されるべきＥＭＳ２０３イベントルールがさらに存在するかどうかを問い合わせる。特定の組織についてのＥＭＳ２０３イベントルールがそれ以上存在しない場合には、プロセスフローが判断ステップ１０１６に進み、そこでソフトウェアモジュールが、ＥＭＳ２０３イベントが処理されるべき付加的なＥＭＳ２０３組織が存在するかどうかを問い合わせる。処理されるべき付加的なＥＭＳ２０３組織が存在しない場合には、ステップ１００２においてソフトウェアモジュールが動作をこのプロセスフローの始まりであったスリープモードに戻す。しかしながら、処理されるべきＥＭＳ２０３イベントルールを有する付加的なＥＭＳ２０３組織が存在する場合には、動作がステップ１００６に戻り、そこでソフトウェアモジュールが、再びこの他の組織についてのＥＭＳ２０３イベントルールに対してＥＭＳ２０３トラフィックを評価するプロセスを開始することになる。

再びステップ１０１０において、各ＥＭＳ２０３イベントルールに対してイベント状態が評価される。このケースでは、判断ステップ１０１２においてルールがアクティブである場合には、ソフトウェアフローがステップ１０２０に進むことになる。ステップ１０２０において、インタープリタ・プロセス３５０が、各トラフィック・セルを評価し、トラフィック・セルは発信元と宛先との間の単一接続であり、データテーブル５０４における単一セルによりトラフィックモニタ３４０において表わされる。判断ステップ１０２２において、ステップ１０２０における特定のトラフィック・セルの肯定的評価結果が正（「１より大きい結果」）である場合には、インタープリタ・プロセス３５０のアルゴリズムが判断ステップ１０２４に続く。判断ステップ１０２４において、既にトリガされているかどうかを確認するために、ルール・ステートが評価される。トリガされていない場合には、ステップ１０２６において、イベント実行が開始される。ルール・ステートが既にトリガされている場合には、イベントの実行がステップ１０２８に続くことになる。いずれの場合においても、動作がステップ１０３０に続き、その時点で、特定のイベント・ステータスに関連付けられたアクションを「ファイアリング」するためにプロセスが開始される。

判断ステップ１０３２において、インタープリタ・プロセス３５０が、そのイベントに関連付けられた特定のアクションが、プロセス実行においてそれに関連付けられたステートを既にもつかどうかを問い合わせる。もっていなければ、インタープリタ・プロセス３５０が、判断ステップ１０３４において特定のアクションを遅延すべきかどうかを問い合わせる。アクションが遅延されるべきではない場合には、ステップ１０３６において、特定のアクションが「ファイア」され、そのアクションの開始を示すステートが設定される。次に、判断ステップ１０３８において、インタープリタ・プロセス３５０が、ファイアされるべき付加的なアクションが存在するかどうかを問い合わせる。存在する場合には、実行がステップ１０３０に戻り、このループにおいて、特定のイベントに関連する全てのアクションが処理されるまで、ステップ１０３０からステップ１０３９までが続く。ステップ１０３８において「ファイア」されるべきアクションがそれ以上存在しない場合には、実行が判断ステップ１０４０に進み、そのときインタープリタ・プロセス３５０ソフトウェアが、評価されるべきトラフィックがそれ以上存在するかどうかを試験する。評価されるべき付加的なトラフィック・セルが存在しない場合には、プロセスがステップ１０２０に戻る。評価されるべきトラフィック・セルがそれ以上存在しない場合には、プロセスが判断ステップ１０１４に戻り、そこで、処理されるべき付加的なＥＭＳ２０３ルールが存在するかどうか判断される。この判断に基づき、プロセスは、既に説明したステップ１０１０か又はステップ１０１６に続くことができる。

ステップ１０２０においてトラフィック・セルを再び評価し、判断ステップ１０２２において正の結果が存在しない場合には、プロセスがステップ１０５０に進み、そこでインタープリタ・プロセス３５０が、特定のルール・ステートが既にＯＮであったかどうかを問い合わせる。ＯＮでなかった場合には、このルール・ステートに関してとられる特定のアクションが存在せず、トラフィック・セルの処理を判断ステップ１０４０に続けることができる。しかしながら、ルール・ステートが前はＯＮであったが今はＯＦＦである場合には、それは、判断ステップ１０５０における正の結果によって示される状態であり、プロセスはステップ１０５２に進んで、その特定のルール・ステートの終了プロシージャを評価する。判断ステップ１０５４において正の結果が生じる場合には、ステップ１０５６において特定のルール・ステートのイベントエンドが処理される。しかしながら、判断ステップ１０５４における負の結果により示されるように、実行されるべきエンドプロセスが存在しない場合には、インタープリタ・プロセス３５０のアルゴリズムが、判断ステップ１０４０及びその後の分岐を通して付加的なトラフィック・セルを処理し続ける。

次に図１１を参照すると、図示されているのは、トラフィックモニタ３４０におけるトラフィックのリアルタイムでの監視のためのＥＭＳ２０３の実施形態において用いることができるデータ構造である。図５に示されていたように、或る実施形態においては、複数のメッセージ取扱いコンピュータ処理３２０ａ、３２０ｂが用いられ、それにより単一のトラフィックモニタ３４０及びインタープリタ・プロセス３５０への複数の接続が、平行して処理される。図１１は、単一リングバッファ１１０２に接続される複数のこうしたコンピュータ処理３２０ａ、３２０ｂのＭＰＳ４２６ａ−４２６ｄを示し、それは、最終的に、この実施形態においては単一トラフィックモニタにデータを与える。ＭＰＳ４２６ａ−４２６ｄは、それらのデータを、小さな非同期式データブロックの形態でリングバッファ１１０２に送信する。データは、各インスタンスにおける時間及びセッションＩＤによりタグ付けされる。例えば、各データブロックは、ヘッダ「ＳＩＤ８，００：０２」によりタグ付けされ、それは、セッションＩＤがセッションナンバー８であり、データの受信時間が００：０２であることを示す。この例で示されるセッションＩＤ及び時間は単なる例であり、百又は千となるセッションＩＤを用いることができる。さらに、１０００分の１秒又はそれ以下の厳密な時間表示を用いることもできる。

リングバッファ１１０２は、接続マネジャ３２２、配信マネジャ３２４、ＭＰＳ４２６ａ−４２６ｄにより生成された全てのデータを保持し、この例においては、データをＳＩＤ順にソートし、それは後の中間フォーマットに挿入する際の検索オーバーヘッドを減少させ、データをリングバッファ１１０２の中にソーティングするときの効率を与えることもできる。リングバッファ１１０２から、トラフィック監視データが中間データ構造１１１０に格納される。この中間データ構造１１１０においては、データがセッションＩＤに関連付けられたグループ１１２０に入れられ、グループ１１２０は、各接続（Ｃ１、Ｃ２．．．ＣＮ）、及び各接続により送信された各メッセージ（Ｍ１、Ｍ２、Ｍ３．．．）についてのレコードを有する。このデータは、リングバッファ１１０２からの新しいデータにより継続的にアップデートされ、データが現在のトラフィックモニタ・データ・マトリックス１１３０に格納されたデータより古いときに継続的にリフレッシュされる。

データ・マトリックス１１３０の構造は、トラフィックモニタ・データマトリックス１１３０の単なる例示的なフォーマットであり、インタープリタ・プロセス３５０によるアクセスのために維持される。中間データ構造１１１０の使用により、よりコンパクトなトラフィックモニタ・データマトリックス１１３０が可能とされ、空のセルをもたないように構造化することができる。データ・マトリックス１１３０は、異なるＩＩＤ（宛先）が異なる行に分布し、異なる発信元ＩＰ（ＳＩＰ又は発信元）が各行内の異なる列として分布するように配置される。ＳＩＰについての独立した列エントリを有するように各行を個々に構造化することにより、図１１に示すように、空のセルなしに、このデータテーブル又はマトリックス１１３０を構築することができる。次いで、各セル内に、異なる統計値を与えることができ、インタープリタ・プロセス３５０は、これらのセルに格納された情報に基づいて、一定のアクティビティを認識することができる。

インタープリタ・プロセス３５０と他のリソースとの両方が、トラフィックモニタ・データ・マトリックス１１３０へのアクセスを有することが望ましい。データ・マトリックス１１３０のコンテンツへのアクセスを可能にするために、少なくとも２つの異なる機構、すなわちダイレクト及びプールを与えることができる。ダイレクトアクセスを通して、インタープリタ・プロセス３５０は、データ・マトリックス１１３０の所与のセルをロックして、そのセルのデータをリアルタイムで読み出すことができる。プールされたアクセスを通じて、プロセスは、ネットワークを介するデータ・マトリックス１１３０のデータへのアクセスを要求するための複数のリソースを与える。データ・マトリックス１１３０又はデータ・マトリックス１１３０に関連するプロセスは、要求を仲裁することができ、データ・マトリックス１１３０における要求されたデータを一定の周期でロックし、そのデータにアクセスし、要求するリソースに送信することができる。データは、生データ、合計データとして要求することができ、又は顧客のメールホストによって要求されても良い。

したがって、ここで説明されたシステムは、全ての受信要求及び要求された宛先、全ての関連するメッセージパラメータ（スパム、ウィルス、受信者、接続時間、データサイズ、宛先サーバのリターンコード等）をデータ・マトリックスにリアルタイムでマッピングするとともに、あらゆる数の受信者Ｅメールアドレス又は多数の顧客にわたるメールサーバについての接続／宛先マトリックスをリアルタイムで監視し、トラフィックモニタ・データ・マトリックス１１３０のステートのリアルタイムでの監視に基づき、アクションを直ちに自動的に開始する機能を有する。説明された実施形態が所有する他のシステムの機能には、必ずしも単一のサーバだけではない受信者メールシステムへの接続を要求するために生じた全てのＳＭＴＰ接続をリアルタイムで認識する機能を含む。説明されたＥＭＳはまた、１顧客／受信者からのマトリックスデータを用いて、別の顧客／受信者についてのアクションを修正することができる。例えば、ＥＭＳが１つの顧客グループに向けられたそのアクションに基づいて「スパム発信者」を認識する場合には、ＥＭＳはまた、その発信元からのスパムが他の宛先に到達するのを防止することができる。
したがって、ここで説明されるＥＭＳは、多くの受信接続を取り扱い、フィルタリングし、監視し、反応することができる。しかしながら、ＥＭＳはまた、そのサーバにおけるローディング又は他の状態に基づいて、メッセージの配信を宛先メールサーバに合わせるように動作可能である。多数の宛先サーバ間で負荷のバランスをとり、宛先サーバに発信されるメッセージを制御された形でスプールし、異なる条件に基づいて宛先サーバにメッセージを条件付で配信することができる。

次に図１２を参照すると、図示されているのは、後述するように３つのＭＰＳを含むスプール・マネジャである。スプール配信マネジャは、ＥＭＳのメッセージ取扱いコンピュータ処理で動くＭＰＳプラグインにより呼び出され、接続マネジャと調和して作動して、メッセージがスプールされるべきかどうかを判断する。図１２を参照すると、スプール配信マネジャは、以下のように機能する。
１）組織メールサーバが到達不能であることを検出した場合には、スプール（ＳＰＯＯＬ）を開始するために、ＳＰＯＯＬ接続管理レコードを、ＵＩを通じて手動で又はインタープリタ・プロセスにより自動的に、組織について挿入しなければならない。
２）接続マネジャが、接続管理テーブルにＳＰＯＯＬ接続管理レコードが存在する組織に送信される各メッセージに、ＳＰＯＯＬタグを割り当てる。
３）スプール配信マネジャが、各受信メッセージを「スプール」タグについて試験する。
４）メッセージにスプールタグが存在する場合には、スプール配信マネジャは、メッセージが配信されるのを遮断し、その代わりにスプーラを用いてスプールサーバへのメッセージを遅延する。

スプーラは、スプールサーバ上で動作する修正されたＭＰＳアプリケーションであり、スプール配信マネジャからのメッセージを受諾し、それらをスプール・リポジトリに格納する。図１２を参照すると、スプーラは、以下のように機能する。
１）スプーラは、スプール配信マネジャからのＳＭＴＰ接続要求を待つ。
２）メッセージ生データを含む受信ＳＭＴＰコマンドの各々が、組織の（すなわち受信者の）スプール・リポジトリに格納される。
３）スプールサイズが、幾つかの所定のスプールサイズ・チェックポイントの１つ（例えば容量の７５％）に到達した場合には、警告通知が生成される。
４）メッセージを格納した後に、スプールサイズが組織についての最大割当てスプールサイズを超えた場合には、警告通知が生成され、スプール接続管理レコードが除去されて、その後のメッセージをスプールするのが防止される。
５）メッセージにスプールタグが存在する場合には、スプール配信マネジャは、メッセージが配信されるのを遮断し、その代わりにＳＭＴＰ接続を用いてスプールサーバへのメッセージを遅延する。

デスプーラもまた、スプールサーバ上で動作する修正されたＭＰＳアプリケーションであり、スプール配信マネジャからのメッセージを受諾し、それらをスプール・リポジトリに保存する。この目的のために、デスプーラは、以下のように機能する。
１）デスプーラは、スプール配信マネジャからのＳＭＴＰ接続要求を待つ。
２）メッセージ生データを含む受信ＳＭＴＰコマンドの各々が、トラフィックモニタに格納される。
３）スプール配信マネジャは、適正な接続を維持するために、組織への接続を制限する。
４）メッセージが組織によって拒否された場合には、デスプーラがメッセージを元の送信者に返送する。
５）メッセージが上手く配信された場合には、スプール・リポジトリにおいて「配信済み」タグが付される。
ステップ２−５は、スプール・リポジトリにおける全てのメッセージが配信されるまで繰り返される。

次に図１３を参照すると、図示されているのは、本発明に係るＥＭＳと共に用いられる管理コンソールのアクセスページの一例のスクリーンショット１３００である。図示のように、アクセスページは、ユーザ及び／又はシステム管理者が、彼らの電子メッセージネットワークにおいて生起する統計及び警告を監視するのに利用可能である。さらに、アクセスページは、電子メッセージの伝送を管理するためにＥＭＳによって用いられるルールを構成するために、ユーザ及び／又はシステム管理者によって用いられても良い。ここで示される特定のアクセスページは、「Ｃｏｎｎｅｃｔｉｏｎ Ｍｇｒ」「Ｄｅｌｉｖｅｒｙ Ｍｇｒ」、「Ｓｐｏｏｌ Ｍｇｒ」、「Ａｌｅｒｔｓ」及び「Ｒｅｐｏｒｔｓ」を含む多数のアクセスタブを含む。ＥＭＳのこれらの個々のコンポーネントにアクセスすることに加えて、図１３におけるアクセスページは、個々のコンポーネントのステータスを与えるとともに、システムへの電子メッセージの流れの概観を与える。

次に簡単に図１４を参照すると、図示されているのは、本発明に係るＥＭＳに用いられる接続マネジャを監視し、構成するためのページの一例のスクリーンショット１４００である。図示のように、このアクセスページは、ＥＭＳにおける接続マネジャのステータスを表示するとともに、発生した特定の伝送違反の統計を与える。説明された特定の害を与えるアクティビティは、ディレクトリ獲得攻撃、ウィルスの大発生、Ｅメール爆弾、及びスパム攻撃のみであるが、アクセスページは、限定なしに、他の形式の害を与える挙動の統計を説明するように構成されてもよい。
図１５は、本発明のＥＭＳに用いられる接続マネジャの別のアクセスページの例のスクリーンショット１５００である。図示のように、このアクセスページは、受信電子メッセージの特定の害を与えるアクションの定義を与え、必要性が生じたときにユーザがＥＭＳを構成するのを支援する。さらに、このアクセスページはまた、ユーザが彼らの受信電子メッセージを管理するための幅広い範囲の選択を可能にする種々の検出及び予防選択を含む。

図１６を参照すると、図示されているのは、本発明に係るＥＭＳに用いられる配信マネジャを監視し、構成するためのページの一例のスクリーンショット１６００である。このアクセスページは、ＥＭＳにおける配信マネジャのステータスを表示するとともに、受信メッセージの害を与えるアクティビティに応答してＥＭＳによりとられた特定の配信（又は非配信）アクションの統計を与える。さらに、このアクセスページは、ユーザが個別の宛先サーバのステータスを監視して、例えば、こうした宛先サーバの空き容量を判断できるようにする。
最後に、図１７を参照すると、図示されているのは、ＥＭＳにおいて用いられる配信マネジャのためのページの別の例のスクリーンショットである。図示のように、このアクセスページは、ユーザが、図１６に示された個々の宛先サーバの特定の詳細を構成できるようにする。このアクセスページを通じて変更できる構成パラメータは接続容量を含み、また、本発明により与えられる保護を享受する新たな宛先サーバをＥＭＳに加えることができる。
ここで開示された原理に従って構成されたＥＭＳの種々の実施形態、並びにＥＭＳの特定のコンポーネントが上記で説明されたが、それらは単なる例として与えられたものであって、限定するためのものではないことを理解されたい。したがって、本発明の広さ及び範囲は、上述の例示的実施形態のいずれによっても限定されるべきではないが、特許請求の範囲の請求項及びそれらの均等物に従ってのみ定められるべきである。

インターネット上のＥメール配信を概説する概略的ブロック図である。 インターネットＥメール配信パスにおけるアクティブＥメール管理システムの可能性のある配置を説明するブロック図である。 電子メッセージＥメール管理システムのＥメール配信ネットワークにおけるアーキテクチュア及び配置をより詳細に示すブロック図である。 メッセージ処理コンピュータ処理の、より的が絞られたブロック図であり、ＥＭＳの幾つかの要素に焦点が当てられており、ＥＭＳのこの部分を通るＥメールメッセージの可能性のあるルーティングが示されている。 多数のメッセージ処理コンピュータ処理が、単一トラフィックモニタとそれに関連するインタープリタ・プロセスに接続されている、ＥＭＳの全体図である。 宛先ＩＰアドレスに適用されることになり、ここで開示された原理に従って構成されたＥＭＳによって管理することができる、Ｅメール管理機能の階層分けの一実施形態を説明するブロック図である。 所定の階層に関連するイベントに対して動作するために接続マネジャによって使用され得る接続管理テーブルを形成するデータベース構造である。 ＥＭＳのコンポーネントにデータを書き込み、ＥＭＳのコンポーネントから命令を受け取ることを含む電子メッセージの伝送を管理する方法を示すフローチャートである。 送信ＩＰアドレスと、ＥＭＳにより管理された組織的階層における特定の受信者についての構成パラメータとに基づいて制御命令を割り当てるためのプロセスの流れを示すフローチャートである。 ＥＭＳ内のインタープリタ・プロセスリソースについてのプロセスの流れを示すフローチャートである。 リアルタイムでのトラフィックの監視を説明する実施形態において用いることができるデータ構造の図である。 説明された実施形態のスプール配信リソースのプロセスの流れを説明するフローチャートである。 本発明に係るＥＭＳと共に用いるための管理コンソールのアクセスページ例のスクリーンショットである。 本発明に係るＥＭＳに用いられる接続マネジャを監視し構成するためのページ例のスクリーンショットである。 ＥＭＳに用いられる接続マネジャの別のページ例のスクリーンショットである。 本発明に係るＥＭＳに用いられる配信マネジャを監視し、構成するためのページ例のスクリーンショットである。 ＥＭＳに用いられる配信マネジャの別のページ例のスクリーンショットである。

Claims (74)

1. 送信メールサーバに関連する発信元データと、受信メールサーバに関連する宛先データとを含む電子メッセージを前記送信メールサーバから前記受信メールサーバへ伝送することを管理するコンピュータ処理と共に用いられるトラフィックモニタであって、
   複数の受信電子メッセージに関する前記発信元データ及び前記宛先データを格納するためのデータ・マトリックスと、
   前記コンピュータ処理により与えられ且つ前記複数の受信電子メッセージに基づいたメタデータを、前記発信元データ及び前記宛先データに対して容易に補充にするとともに、前記複数の受信電子メッセージの処理に用いるために前記発信元データ及び前記宛先データ並びに前記メタデータに容易にアクセスするように構成され且つ前記マトリックスに結合された、インターフェースと、
   を含むことを特徴とするトラフィックモニタ。
2. 前記インターフェースは、前記複数の受信電子メッセージを処理する処理命令を生成するのに用いるために、前記発信元データ及び前記宛先データ並びに前記メタデータに容易にアクセスするように構成されたことを特徴とする請求項１に記載のトラフィックモニタ。
3. 前記処理命令が、前記複数の受信電子メッセージの措置命令であることを特徴とする請求項２に記載のトラフィックモニタ。
4. 前記措置命令は、
   メッセージ受諾、
   メッセージ拒否、
   メッセージ検疫、
   メッセージスプール、
   メッセージ据え置き、
   メッセージ抑制、
   メッセージ宛先変更、
   接続拒否、
   ブラックホール、
   からなる群から選択されることを特徴とする請求項３に記載のトラフィックモニタ。
5. 前記インターフェースは、前記複数の受信電子メッセージから外挿されたメタデータを、望ましくない電子メッセージ及び望ましくない電子メッセージ配信試行を検出するためのプログラム・スレッドを用いて前記発信元データ及び前記宛先データに対して容易に補充するように構成されたことを特徴とする請求項１に記載のトラフィックモニタ。
6. 前記複数の受信電子メッセージから外挿されたメタデータが、
   発信元ＩＰアドレスからの接続試行のカウントと、
   発信元ＩＰアドレスからの現在オープンな接続のカウントと、
   発信元ＩＰアドレスからの接続継続時間と、
   発信元ＩＰアドレスからのメッセージのカウントと、
   メッセージサイズと、
   メッセージの受信者のカウントと、
   発信元ＩＰアドレスからのスパムメッセージのカウントと、
   発信元ＩＰアドレスからのウィルス感染メッセージのカウントと、
   発信元ＩＰアドレスからの望ましくないバイナリ添付を有するメッセージのカウントと、
   発信元ＩＰアドレスからの望ましくないコンテンツを有するメッセージのカウントと、
   発信元ＩＰアドレスからの、措置オプションが遮断され、ブラックホール化され、スプールされ又は検疫されたメッセージのカウントと、
   宛先ＩＰアドレスへの現在オープンな接続のカウントと、
   宛先ＩＰアドレスへの接続の継続時間と、
   宛先ＩＰアドレスへの失敗接続のカウントと、
   宛先ＩＰアドレスからの一時的据え置きエラーのカウントと、
   宛先ＩＰアドレスからの不明ユーザエラーのカウントと、
   からなる群から選択されることを特徴とする請求項１に記載のトラフィックモニタ。
7. 送信メールサーバから受信メールサーバへの電子メッセージの伝送を管理するコンピュータ処理と共に用いられる方法であって、前記送信メールサーバから送信されたメッセージは、前記送信メールサーバに関連する発信元データと、前記受信メールサーバに関連する宛先データとを含み、
   複数の受信電子メッセージに関する前記発信元データ及び前記宛先データを格納し、
   前記コンピュータ処理により与えられ且つ前記複数の受信電子メッセージに基づいたメタデータで前記発信元データ及び前記宛先データを補充し、
   前記コンピュータ処理において、前記発信元データ及び前記宛先データ並びに前記メタデータに基づき前記複数の受信電子メッセージを処理する、
   ことを含む方法。
8. 前記処理は、前記複数の受信電子メッセージを処理するのに用いる前記発信元データ及び前記宛先データ並びに前記メタデータに基づいて処理命令を生成することを含む、請求項７に記載の方法。
9. 前記処理命令を生成することが、前記複数の受信電子メッセージの措置命令を生成することを含む、請求項８に記載の方法。
10. 前記措置命令を生成することは、
    メッセージ受諾、
    メッセージ拒否、
    メッセージ検疫、
    メッセージスプール、
    メッセージ据え置き、
    メッセージ抑制、
    メッセージ宛先変更、
    接続拒否、
    ブラックホール、
    からなる群から選択される措置命令を生成することを含む、請求項９に記載の方法。
11. 前記補充することは、前記複数の受信電子メッセージから外挿されたメタデータを、望ましくない電子メッセージ及び望ましくない電子メッセージ配信試行を検出するためのプログラム・スレッドを用いて前記発信元データ及び前記宛先データに対して補充することを含む、請求項７に記載の方法。
12. 前記補充することがさらに、
    発信元ＩＰアドレスからの接続試行のカウントと、
    発信元ＩＰアドレスからの現在オープンな接続のカウントと、
    発信元ＩＰアドレスからの接続継続時間と、
    発信元ＩＰアドレスからのメッセージのカウントと、
    メッセージサイズと、
    メッセージの受信者のカウントと、
    発信元ＩＰアドレスからのスパムメッセージのカウントと、
    発信元ＩＰアドレスからのウィルス感染メッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないバイナリ添付を有するメッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないコンテンツを有するメッセージのカウントと、
    発信元ＩＰアドレスからの、措置オプションが遮断され、ブラックホール化され、スプールされ又は検疫されたメッセージのカウントと、
    宛先ＩＰアドレスへの現在オープンな接続のカウントと、
    宛先ＩＰアドレスへの接続の継続時間と、
    宛先ＩＰアドレスへの失敗接続のカウントと、
    宛先ＩＰアドレスからの一時的据え置きエラーのカウントと、
    宛先ＩＰアドレスからの不明ユーザエラーのカウントと、
    からなる群から選択され、前記複数の受信電子メッセージから外挿されたメタデータを、前記発信元データ及び前記宛先データに対して補充することを含む、請求項７に記載の方法。
13. 送信メールサーバに関連する発信元データと、受信メールサーバに関連する宛先データとを含む電子メッセージを、前記送信メールサーバから前記受信メールサーバへ伝送することを管理することに用いる電子メッセージ管理システムであって、
    複数の受信電子メッセージに関する前記発信元データ及び前記宛先データを格納するデータ・マトリックス、及び前記データ・マトリックスへのアクセスを容易にするインターフェースを有するトラフィックモニタと、
    前記複数の受信電子メッセージから外挿されたメタデータを、前記発信元データ及び前記宛先データに対して補充するように構成され、且つ前記インターフェースに結合された、メッセージ取扱いプロセスと、
    前記発信元データ及び前記宛先データ並びに前記メタデータにアクセスし且つそれらに基づく処理命令を生成するように構成され、前記インターフェースに結合された、インタープリタ・プロセスと、
    を含み、前記メッセージ取扱いプロセスがさらに、前記処理命令に基づき前記複数の受信電子メッセージを処理するように構成されたことを特徴とするシステム。
14. 前記処理命令が、前記複数の受信電子メッセージの措置命令であることを特徴とする請求項１３に記載の電子メッセージ管理システム。
15. 前記インタープリタ・プロセスは、
    メッセージ受諾、
    メッセージ拒否、
    メッセージ検疫、
    メッセージスプール、
    メッセージ据え置き、
    メッセージ抑制、
    メッセージ宛先変更、
    接続拒否、
    ブラックホール、
    からなる群から選択される措置命令を生成するように構成されたことを特徴とする請求項１４に記載の電子メッセージ管理システム。
16. 前記メッセージ取扱いプロセスは、前記発信元データ及び前記宛先データを抽出し、且つ前記処理命令に基づいて前記送信メールサーバから複数の受信電子メッセージを受諾するように構成された接続管理モジュールを含むことを特徴とする請求項１３に記載の電子メッセージ管理システム。
17. 前記処理命令を保持するように構成され且つ前記インタープリタ・プロセスと前記接続管理モジュールとの間に結合された、接続管理テーブルをさらに含むことを特徴とする請求項１６に記載の電子メッセージ管理システム。
18. 前記メッセージ取扱いプロセスは、前記処理命令に基づいて前記複数の受信電子メッセージを前記受信メールサーバに配信するように構成された配信モジュールを含むことを特徴とする請求項１３に記載の電子メッセージ管理システム。
19. 前記インタープリタ・プロセスは、データベースに格納されたルールに従って、前記発信元データ及び前記宛先データ並びに前記メタデータに基づく処理命令を生成するように構成されたことを特徴とする請求項１８に記載の電子メッセージ管理システム。
20. 前記ルールを制定するように構成され、前記データベースに結合された管理アクセスコンソールをさらに含むことを特徴とする請求項１９に記載の電子メッセージ管理システム。
21. 前記メッセージ取扱いプロセスは、望ましくない電子メッセージ及び望ましくない電子メッセージ配信試行を検出するためのプログラム・スレッドを用いて、外挿されたメタデータを前記発信元データ及び前記宛先データに対して補充するように構成されたことを特徴とする請求項１３に記載の電子メッセージ管理システム。
22. 前記複数の受信電子メッセージから外挿されたメタデータは、
    発信元ＩＰアドレスからの接続試行のカウントと、
    発信元ＩＰアドレスからの現在開かれた接続のカウントと、
    発信元ＩＰアドレスからの接続継続時間と、
    発信元ＩＰアドレスからのメッセージのカウントと、
    メッセージサイズと、
    メッセージの受信者のカウントと、
    発信元ＩＰアドレスからのスパムメッセージのカウントと、
    発信元ＩＰアドレスからのウィルス感染メッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないバイナリ添付を有するメッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないコンテンツを有するメッセージのカウントと、
    発信元ＩＰアドレスからの、措置オプションが遮断され、ブラックホール化され、スプールされ又は検疫されたメッセージのカウントと、
    宛先ＩＰアドレスへの現在開かれた接続のカウントと、
    宛先ＩＰアドレスへの接続の継続時間と、
    宛先ＩＰアドレスへの失敗接続のカウントと、
    宛先ＩＰアドレスからの一時的据え置きエラーのカウントと、
    宛先ＩＰアドレスからの不明ユーザエラーのカウントと、
    からなる群から選択されることを特徴とする請求項１３に記載の電子メッセージ管理システム。
23. 前記宛先データが、前記受信メールサーバの元の配信アドレスを含み、前記メッセージ取扱いプロセスがさらに、前記電子メッセージ管理システムの配信アドレスを前記元の配信アドレスと関連付けることによって、前記複数の受信電子メッセージをインターセプトするように構成されたことを特徴とする請求項１３に記載の電子メッセージ管理システム。
24. 送信メールサーバから受信メールサーバへの電子メッセージの伝送を管理するための方法であって、前記送信メールサーバから送信されたメッセージは、前記送信メールサーバに関連する発信元データと、該受信メールサーバに関連する宛先データとを含み、
    複数の受信電子メッセージの前記発信元データ及び前記宛先データをデータ・マトリックスに格納し、
    前記複数の受信電子メッセージからメタデータを外挿し、
    前記発信元データ及び前記宛先データを前記メタデータで補充し、
    インターフェースを介して前記発信元データ及び前記宛先データ並びに前記メタデータにアクセスし、
    前記発信元データ及び前記宛先データ並びに前記メタデータに基づいて処理命令を生成し、
    前記処理命令に基づいて前記複数の受信電子メッセージを処理する、
    ことを含む方法。
25. 前記処理命令を生成することが、前記複数の受信電子メッセージの措置命令を生成することを含む、請求項２４に記載の方法。
26. 前記措置命令を生成することは、
    メッセージ受諾、
    メッセージ拒否、
    メッセージ検疫、
    メッセージスプール、
    メッセージ据え置き、
    メッセージ抑制、
    メッセージ宛先変更、
    接続拒否、
    ブラックホール、
    からなる群から選択される措置命令を生成することを含む、請求項２５に記載の方法。
27. 前記処理が、前記発信元データ及び前記宛先データ並びに前記メタデータに基づいて、前記送信メールサーバから複数の受信電子メッセージを受諾することを含む、請求項２４に記載の方法。
28. 前記処理命令を生成することが、接続管理テーブルにおいて処理命令を生成することを含み、前記処理が、前記接続管理テーブルにおける前記メッセージ処理命令に基づいて前記複数の受信電子メッセージを処理することを含む、請求項２７に記載の方法。
29. 前記処理が、前記発信元データ及び前記宛先データ並びに前記メタデータに基づいて、前記複数の受信電子メッセージを前記受信メールサーバに配信することを含む、請求項２４に記載の方法。
30. 前記生成することが、データベースに格納されたルールに従って前記発信元データ及び前記宛先データ並びに前記メタデータに基づく処理命令を生成することを含む、請求項２４に記載の方法。
31. 前記生成することがさらに、前記データベースに結合された管理アクセスコンソールを用いて制定されたルールに従って処理命令を生成することを含む、請求項３０に記載の方法。
32. 前記外挿することが、望ましくない電子メッセージ及び望ましくない電子メッセージ配信試行を検出するためのプログラム・スレッドを用いて前記複数の受信電子メッセージから前記メタデータを外挿することを含む、請求項２４に記載の方法。
33. 前記外挿することは、
    発信元ＩＰアドレスからの接続試行のカウントと、
    発信元ＩＰアドレスからの現在オープンな接続のカウントと、
    発信元ＩＰアドレスからの接続継続時間と、
    発信元ＩＰアドレスからのメッセージのカウントと、
    メッセージサイズと、
    メッセージの受信者のカウントと、
    発信元ＩＰアドレスからのスパムメッセージのカウントと、
    発信元ＩＰアドレスからのウィルス感染メッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないバイナリ添付を有するメッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないコンテンツを有するメッセージのカウントと、
    発信元ＩＰアドレスからの、措置オプションが遮断され、ブラックホール化され、スプールされ又は検疫されたメッセージのカウントと、
    宛先ＩＰアドレスへの現在オープンな接続のカウントと、
    宛先ＩＰアドレスへの接続の継続時間と、
    宛先ＩＰアドレスへの失敗接続のカウントと、
    宛先ＩＰアドレスからの一時的据え置きエラーのカウントと、
    宛先ＩＰアドレスからの不明ユーザエラーのカウントと、
    からなる群から選択されるメタデータを外挿することを含む、請求項２４に記載の方法。
34. 前記宛先データが、前記受信メールサーバの元の配信アドレスを含み、前記方法がさらに、新しい配信アドレスを前記元の配信アドレスと関連付けることによって、前記複数の受信電子メッセージをインターセプトすることを含む、請求項２４に記載の方法。
35. 送信メールサーバから受信メールサーバへの電子メッセージの伝送を管理するのに用いられる電子メッセージ管理システムであって、
    複数の受信電子メッセージから送信メールサーバに関連する発信元データと、受信メールサーバに関連する宛先データとを抽出するように構成された接続管理モジュールと、
    前記発信元データ及び前記宛先データを格納するためのデータ・マトリックスと、
    前記複数の受信電子メッセージから外挿されたメタデータを前記発信元データ及び前記宛先データに対して補充するのを容易にするとともに、前記発信元データ及び前記宛先データ並びに前記メタデータに容易にアクセスするように構成され且つ前記データ・マトリックスと前記接続管理モジュールとの間に結合された、インターフェースと、
    を含み、前記接続管理モジュールがさらに、前記発信元データ及び前記宛先データ並びに前記メタデータに基づいて、前記送信メールサーバから前記複数の受信電子メッセージのいずれかを受諾するように構成されたことを特徴とするシステム。
36. 前記発信元データ及び前記宛先データ並びに前記メタデータに基づく処理命令を有する接続管理テーブルをさらに含み、前記接続管理モジュールが、前記処理命令に基づいて前記複数の受信電子メッセージのいずれかを受諾するように構成されたことを特徴とする請求項３５に記載の電子メッセージ管理システム。
37. 前記処理命令は、
    メッセージ受諾、
    メッセージ拒否、
    メッセージ検疫、
    メッセージスプール、
    メッセージ据え置き、
    メッセージ抑制、
    メッセージ宛先変更、
    接続拒否、
    ブラックホール、
    からなる群から選択される措置命令であることを特徴とする請求項３６に記載の電子メッセージ管理システム。
38. 前記処理命令が、データベースに格納されたルールに従って生成されたことを特徴とする請求項３６に記載の電子メッセージ管理システム。
39. 前記ルールを制定するように構成され、前記データベースに結合された管理アクセスコンソールをさらに含むことを特徴とする請求項３８に記載の電子メッセージ管理システム。
40. 前記メタデータが、望ましくない電子メッセージ及び望ましくない電子メッセージ配信試行を検出するためのプログラム・スレッドを用いて前記複数の受信メッセージから外挿されることを特徴とする請求項３５に記載の電子メッセージ管理システム。
41. 前記複数の受信電子メッセージから外挿されたメタデータは、
    発信元ＩＰアドレスからの接続試行のカウントと、
    発信元ＩＰアドレスからの現在オープンな接続のカウントと、
    発信元ＩＰアドレスからの接続継続時間と、
    発信元ＩＰアドレスからのメッセージのカウントと、
    メッセージサイズと、
    メッセージの受信者のカウントと、
    発信元ＩＰアドレスからのスパムメッセージのカウントと、
    発信元ＩＰアドレスからのウィルス感染メッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないバイナリ添付を有するメッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないコンテンツを有するメッセージのカウントと、
    発信元ＩＰアドレスからの、措置オプションが遮断され、ブラックホール化され、スプールされ又は検疫されたメッセージのカウントと、
    宛先ＩＰアドレスへの現在オープンな接続のカウントと、
    宛先ＩＰアドレスへの接続の継続時間と、
    宛先ＩＰアドレスへの失敗接続のカウントと、
    宛先ＩＰアドレスからの一時的据え置きエラーのカウントと、
    宛先ＩＰアドレスからの不明ユーザエラーのカウントと、
    からなる群から選択されることを特徴とする請求項３５に記載の電子メッセージ管理システム。
42. 前記宛先データが、前記受信メールサーバの元の配信アドレスを含み、前記接続管理モジュールがさらに、前記電子メッセージ管理システムの配信アドレスを前記元の配信アドレスと関連付けることによって、前記複数の受信電子メッセージをインターセプトするように構成されたことを特徴とする請求項３５に記載の電子メッセージ管理システム。
43. 送信メールサーバから受信メールサーバへの電子メッセージの伝送を管理する方法であって、
    複数の受信電子メッセージから送信メールサーバに関連する発信元データと、受信メールサーバに関連する宛先データとを抽出し、
    前記複数の受信電子メッセージから外挿されたメタデータを前記発信元データ及び前記宛先データに対して補充し、
    前記発信元データ及び前記宛先データ並びに前記メタデータに基づいて、前記送信メールサーバから前記複数の受信電子メッセージのいずれかを受諾する、
    ことを含む方法。
44. 前記受諾することが、前記発信元及び宛先データ並びにメタデータに基づく処理命令に基づいて、前記複数の受信電子メッセージのいずれかを受諾することを含む、請求項４３に記載の方法。
45. 前記処理命令は、
    メッセージ受諾、
    メッセージ拒否、
    メッセージ検疫、
    メッセージスプール、
    メッセージ据え置き、
    メッセージ抑制、
    メッセージ宛先変更、
    接続拒否、
    ブラックホール、
    からなる群から選択される措置命令であることを特徴とする請求項４４に記載の方法。
46. 前記受諾することがさらに、データベースに格納されたルールに従って生成された処理命令に基づいて、前記複数の受信電子メッセージのいずれかを受諾することを含む、請求項４４に記載の方法。
47. 前記受諾することがさらに、データベースに結合された管理アクセスコンソールを用いて制定されデータベースに格納されたルールに従って生成された処理命令に基づいて、前記複数の受信電子メッセージのいずれかを受諾することを含む、請求項４６に記載の方法。
48. 前記補充することは、前記複数の受信電子メッセージから外挿されたメタデータを、望ましくない電子メッセージ及び望ましくない電子メッセージ配信試行を検出するためのプログラム・スレッドを用いて前記発信元データ及び宛先データに対して補充することを含む、請求項４３に記載の方法。
49. 前記補充することは、
    発信元ＩＰアドレスからの接続試行のカウントと、
    発信元ＩＰアドレスからの現在オープンな接続のカウントと、
    発信元ＩＰアドレスからの接続継続時間と、
    発信元ＩＰアドレスからのメッセージのカウントと、
    メッセージサイズと、
    メッセージの受信者のカウントと、
    発信元ＩＰアドレスからのスパムメッセージのカウントと、
    発信元ＩＰアドレスからのウィルス感染メッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないバイナリ添付を有するメッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないコンテンツを有するメッセージのカウントと、
    発信元ＩＰアドレスからの、措置オプションが遮断され、ブラックホール化され、スプールされ又は検疫されたメッセージのカウントと、
    宛先ＩＰアドレスへの現在オープンな接続のカウントと、
    宛先ＩＰアドレスへの接続の継続時間と、
    宛先ＩＰアドレスへの失敗接続のカウントと、
    宛先ＩＰアドレスからの一時的据え置きエラーのカウントと、
    宛先ＩＰアドレスからの不明ユーザエラーのカウントと、
    からなる群から選択される前記複数の受信電子メッセージから外挿されたメタデータを、前記発信元データ及び宛先データに対して補充することを含む、請求項４３に記載の方法。
50. 前記宛先データが、前記受信メールサーバの元の配信アドレスを含み、前記方法がさらに、新しい配信アドレスを前記元の配信アドレスと関連付けることによって、前記複数の受信電子メッセージをインターセプトするように構成されたことを特徴とする請求項４３に記載の方法。
51. 送信メールサーバから受信メールサーバへの電子メッセージの伝送を管理するための電子メッセージ管理システムであって、
    複数の受信電子メッセージの送信メールサーバに関連する発信元データと、受信メールサーバに関連する宛先データとを格納するためのデータ・マトリックスと、
    前記複数の受信電子メッセージから外挿されたメタデータを、前記発信元及び宛先データに対して容易に補充するとともに、前記発信元データ及び前記宛先データ並びに前記メタデータに容易にアクセスするように構成され且つ前記マトリックスに結合された、インターフェースと、
    前記発信元データ及び前記宛先データ並びに前記メタデータに基づいて、前記複数の受信電子メッセージのいずれかを前記受信メールサーバに配信するように構成され且つ前記インターフェースに結合された、配信管理モジュールと、
    を含むシステム。
52. 前記配信管理モジュールが、前記発信元データ及び前記宛先データ並びに前記メタデータに基づく処理命令に基づいて、前記複数の受信電子メッセージのいずれかを前記受信メールサーバに配信するように構成されたことを特徴とする請求項５１に記載の電子メッセージ管理システム。
53. 前記配信管理モジュールが、前記複数の受信メールサーバのロード容量に基づいて、前記複数の受信電子メッセージのいずれかを前記複数の受信メールサーバに配信するように構成されることを特徴とする請求項５２に記載の電子メッセージ管理システム。
54. 前記処理命令が、前記複数の受信電子メッセージの措置命令であることを特徴とする請求項５２に記載の電子メッセージ管理システム。
55. 前記措置命令は、
    メッセージ配信、
    メッセージ据え置き、
    メッセージ拒否、
    メッセージ宛先変更、
    からなる群から選択されることを特徴とする請求項５４に記載の電子メッセージ管理システム。
56. 前記発信元データ及び前記宛先データ並びに前記メタデータに基づく処理命令が、データベースに格納されたルールに従って生成されたことを特徴とする請求項５１に記載の電子メッセージ管理システム。
57. 前記ルールを制定するように構成され、前記データベースに結合された管理アクセスコンソールをさらに含むことを特徴とする請求項５５に記載の電子メッセージ管理システム。
58. 前記メタデータが、望ましくない電子メッセージ及び望ましくない電子メッセージ配信試行を検出するためのプログラム・スレッドを用いて、前記複数の受信電子メッセージから外挿されることを特徴とする請求項５１に記載の電子メッセージ管理システム。
59. 前記外挿されたメタデータは、
    発信元ＩＰアドレスからの接続試行のカウントと、
    発信元ＩＰアドレスからの現在オープンな接続のカウントと、
    発信元ＩＰアドレスからの接続継続時間と、
    発信元ＩＰアドレスからのメッセージのカウントと、
    メッセージサイズと、
    メッセージの受信者のカウントと、
    発信元ＩＰアドレスからのスパムメッセージのカウントと、
    発信元ＩＰアドレスからのウィルス感染メッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないバイナリ添付を有するメッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないコンテンツを有するメッセージのカウントと、
    発信元ＩＰアドレスからの、措置オプションが遮断され、ブラックホール化され、スプールされ又は検疫されたメッセージのカウントと、
    宛先ＩＰアドレスへの現在オープンな接続のカウントと、
    宛先ＩＰアドレスへの接続の継続時間と、
    宛先ＩＰアドレスへの失敗接続のカウントと、
    宛先ＩＰアドレスからの一時的据え置きエラーのカウントと、
    宛先ＩＰアドレスからの不明ユーザエラーのカウントと、
    からなる群から選択されることを特徴とする請求項５１に記載の電子メッセージ管理システム。
60. 送信メールサーバから受信メールサーバへの電子メッセージの伝送を管理する方法であって、
    複数の受信電子メッセージから送信メールサーバに関連する発信元データと、受信メールサーバに関連する宛先データとを格納し、
    前記複数の受信電子メッセージから外挿されたメタデータを、前記発信元データ及び前記宛先データに対して補充し、
    前記発信元データ及び前記宛先データ並びに前記メタデータに基づき前記複数の受信電子メッセージのいずれかを前記受信メールサーバに配信する、
    ことを含む方法。
61. 前記配信することが、前記発信元データ及び前記宛先データ並びに前記メタデータに基づく処理命令に基づいて、前記複数の受信電子メッセージのいずれかを前記受信メールサーバに配信することを含む、請求項６０に記載の方法。
62. 前記配信することが、前記複数の受信メールサーバのロード容量に基づいて、前記複数の受信電子メッセージのいずれかを複数の受信メールサーバに配信することを含む、請求項６１に記載の方法。
63. 前記処理命令は、
    メッセージ配信、
    メッセージ据え置き、
    メッセージ拒否、
    メッセージ宛先変更、
    からなる群から選択される措置命令であることを特徴とする請求項６１に記載の方法。
64. 前記配信することがさらに、データベースに格納されたルールに従って生成された処理命令に基づいて、前記複数の受信電子メッセージのいずれかを配信することを含む、請求項６１に記載の方法。
65. 前記配信することがさらに、データベースに結合された管理アクセスコンソールを用いて制定されデータベースに格納されたルールに従って生成された処理命令に基づいて、前記複数の受信電子メッセージのいずれかを配信することを含む、請求項６０に記載の方法。
66. 前記補充することが、前記複数の受信電子メッセージから外挿されたメタデータを、望ましくない電子メッセージ及び望ましくない電子メッセージ配信試行を検出するためのプログラム・スレッドを用いて、前記発信元データ及び前記宛先データに対して補充することを含む、請求項６０に記載の方法。
67. 前記補充することは、
    発信元ＩＰアドレスからの接続試行のカウントと、
    発信元ＩＰアドレスからの現在オープンな接続のカウントと、
    発信元ＩＰアドレスからの接続継続時間と、
    発信元ＩＰアドレスからのメッセージのカウントと、
    メッセージサイズと、
    メッセージの受信者のカウントと、
    発信元ＩＰアドレスからのスパムメッセージのカウントと、
    発信元ＩＰアドレスからのウィルス感染メッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないバイナリ添付を有するメッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないコンテンツを有するメッセージのカウントと、
    発信元ＩＰアドレスからの、措置オプションが遮断され、ブラックホール化され、スプールされ又は検疫されたメッセージのカウントと、
    宛先ＩＰアドレスへの現在オープンな接続のカウントと、
    宛先ＩＰアドレスへの接続の継続時間と、
    宛先ＩＰアドレスへの失敗接続のカウントと、
    宛先ＩＰアドレスからの一時的据え置きエラーのカウントと、
    宛先ＩＰアドレスからの不明ユーザエラーのカウントと、
    からなる群から選択され、前記複数の受信電子メッセージから外挿されたメタデータを、前記発信元データ及び前記宛先データに対して補充することを含む、請求項６０に記載の方法。
68. 複数の受信電子メッセージを伝送するための、少なくとも送信メールサーバと受信メールサーバとを含んだ電子メッセージングネットワークと関連付けられたデータ構造であって、
    前記複数の受信電子メッセージから抽出され、少なくとも前記送信メールサーバに関連するデータを有する発信元データを含むように構成された発信元データフィールドと、
    前記複数の受信電子メッセージから抽出され、少なくとも前記受信メールサーバに関連するデータを有する宛先データを含むように構成された宛先データフィールドと、
    前記複数の受信電子メッセージを処理するためのメッセージ処理データを含むように構成された処理フィールドと、を含み、
    前記メッセージ処理データは、前記発信元データ及び前記宛先データに基づき、かつ前記複数の受信電子メッセージから外挿されたメタデータに基づくものであることを特徴とするデータ構造。
69. 前記メッセージ処理データが、前記複数の受信電子メッセージを処理するためのメッセージ措置命令を含むことを特徴とする請求項６８に記載のデータ構造。
70. 前記処理命令は、
    メッセージ受諾、
    メッセージ拒否、
    メッセージ検疫、
    メッセージスプール、
    メッセージ据え置き、
    メッセージ抑制、
    メッセージ宛先変更、
    接続拒否、
    ブラックホール、
    からなる群から選択されることを特徴とする請求項６９に記載のデータ構造。
71. 前記メタデータが、望ましくない電子メッセージ及び望ましくない電子メッセージ配信試行を検出するためのプログラム・スレッドを用いて、前記複数の受信電子メッセージから外挿されることを特徴とする請求項６８に記載のデータ構造。
72. 前記複数の受信電子メッセージから外挿されたメタデータは、
    発信元ＩＰアドレスからの接続試行のカウントと、
    発信元ＩＰアドレスからの現在オープンな接続のカウントと、
    発信元ＩＰアドレスからの接続継続時間と、
    発信元ＩＰアドレスからのメッセージのカウントと、
    メッセージサイズと、
    メッセージの受信者のカウントと、
    発信元ＩＰアドレスからのスパムメッセージのカウントと、
    発信元ＩＰアドレスからのウィルス感染メッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないバイナリ添付を有するメッセージのカウントと、
    発信元ＩＰアドレスからの望ましくないコンテンツを有するメッセージのカウントと、
    発信元ＩＰアドレスからの、措置オプションが遮断され、ブラックホール化され、スプールされ又は検疫されたメッセージのカウントと、
    宛先ＩＰアドレスへの現在オープンな接続のカウントと、
    宛先ＩＰアドレスへの接続の継続時間と、
    宛先ＩＰアドレスへの失敗接続のカウントと、
    宛先ＩＰアドレスからの一時的据え置きエラーのカウントと、
    宛先ＩＰアドレスからの不明ユーザエラーのカウントと、
    からなる群から選択されることを特徴とする請求項６８に記載のデータ構造。
73. 前記発信元データ及び前記宛先データ並びに前記メタデータに基づく前記メッセージ処理データが、データベースに格納されたルールに従って生成されることを特徴とする請求項６８に記載のデータ構造。
74. 前記ルールが、前記データベースに結合された管理アクセスコンソールを用いて制定されることを特徴とする請求項７３に記載のデータ構造。