JP4829223B2 - 電子メッセージソース評判情報システム - Google Patents

Description

［関連出願の相互参照］
本出願は、その内容の全体を参照することにより本書に含まれる、２００４年５月２５日に出願された、米国仮出願番号６０／５７４，２９０の利益を主張する。また本出願は、その内容のすべてを参照することにより本書に含まれる、２００５年２月２日に出願された、米国仮出願番号６０／５９３，６５１の利益を主張する。

本文に開示された実施例は一般的に、ネットワーク活動を監視する、監視された活動を反映する情報の集積を作成する、および、監視された活動を反映した情報に基づくネットワーク活動を管理するためのシステムに関連する。

Ｐｅｔｒｉその他による（「能動ＥＭＳ特許出願」）、米国特許出願公開番号２００３／０１５８９０５は、その全体を本文に参照することにより、本書に含まれる。能動EMS特許出願は、受信接続試み、送信配信試み、およびメッセージ内容解析において電子メッセージから、データが収集され、データマトリクスに書き込まれる、リアルタイムフィードバックループを含む、能動電子メッセージ管理システムを記述する。

２００５年５月現在、本開示の譲受人Ｐｏｓｔｉｎｉ，Ｉｎｃ．は、週ごとに３０億以上のメッセージを処理する。この処理から収集された情報は、インターネット上の電子メールトラフィックの活動に関する、貴重な洞察を与える。攻撃的な電子メール送信者、または「スパム送信者」は、現存する多くの電子メールメッセージフィルタリング製品、およびサービスを克服するためブルートフォース法を使用し始めた、コンテンツベースの電子メールメッセージフィルタリングによって阻止されてきた。多くの場合において、これらのブルートフォース法は、− ＩＳＰ、大学、および企業ネットワークで管理されているルーターを含む − インターネットのサーバおよびネットワークの全体的な負荷であるほど、エンドユーザーのメッセージボックスにとってそれほどの脅威にはならない。たとえば、ある場合では、スパム送信者は、これらのフィルターは、インターネット上のメッセージトラフィックパターンに適応することから、コンテンツベース電子メールフィルターのフィルタリングパラメータを影響させる目的で、数百万ものメッセージを無作為に送信する。これらのメッセージは、したがって商業広告さえも含まない。これらは一般的に、反復的な性質ではないがランダムであり、無作為にスパマーのデータベースにある無作為の既知の電子メールアドレスに送信する。メッセージには既知のパターンがないことから、ソースアドレスによる電子メールメッセージの攻撃的送信者の検出に基づき、メッセージをブロックするよう設定されていない、コンテントベースの電子メールフィルターは、一般的にこれらのメッセージをユーザーに通すことを許す。さらに、このような電子メールフィルタリングの多くが、企業またはＩＳＰロケーション、およびメールサーバユーザーのメールサーバほどもずっと以前、またはユーザーの個人電子メールクライアントでさえも行われることから、このタイプの電子メールフィルタリングは、ＩＳＰまたは企業ネットワークが処理しなければならない、ネットワークトラフィックのレベル低減に影響しない。

電子メッセージソース評判システムを用いる、フィルタリングシステム、および方法が開示されている。ソース評判システムは、リアルタイム脅威識別ネットワーク（ＲＴＩＮ）データベースの形で、ソースＩＰアドレスの評判を提供することができ、また、ソース評判システムの顧客により、ネットワークトラフィックのフィルタリングに使用することができる、インターネットプロトコル（ＩＰ）アドレス情報の集積を維持する。ソース評判システムは、ソース評判情報にアクセスするための複数の手段を提供する。そのような手段の例は、ドメインネームサーバー（ＤＳＮ）型クエリ、ルーターテーブルデータのある、サービスルーター、またはほかの手段を含むことがある。

この全体的概念の様々な側面には、ソースＩＰアドレス評判情報の集積の投入のためのシステム、および方法、ソース評判情報にアクセスするための認証プロセス（例、暗号キー等により）、ソース評判情報集積において維持される情報の種類、およびソース評判情報のアクセス、または提供方法を含む。

ソース評判情報は、様々なデータソースから抽出することができる。データソースの例の一つは、リアルタイムインターネット・トラフィック情報を生成する、トラフィック監視システムである。トラフィック監視システムには、電子メールトラフィックに基づき、リアルタイム情報を収集するよう設定された、トラフィックモニターを含むことがある。トラフィックモニターは、トラフィックモニターにより収集された情報を反映するデータを含む、トラフィックログを維持することができる。そしてソース評判システムによって、様々なドメインまたは、ＩＰアドレスを起源とする電子メール活動の評価を作成するため、トラフィックログの解析を行うことができる。ドメインの評価は、そのドメインからの閾値の電子メールトラフィックが検証されるまで遅らせることができる。

データソースの他の例は、偽陽性スパム識別の低減方法を提供する、ツーストライクシステムである。ツーストライクシステムが、あるＩＰアドレスからの電子メールがスパムだと疑う場合、疑われるスパム電子メールが、そのＩＰアドレスから最後に受信されてから経過した時間を確認する。所定以上の時間が経過した場合に、ツーストライクシステムは、疑われるメールがスパムである可能性が小さいと判断する。あるいは、所定時間を下回る時間しか経過していない場合は、システムは疑われる電子メールがスパムである可能性が大きいと判断し、送信ＩＰアドレスを可能性あるスパム源として識別する。ツーストライクシステムは、たとえば、可能性あるスパム源と判断されるＩＰアドレスを一覧するなど、このプロセスから生じる情報のデータベースを維持することができる。この情報は次に、データソースとして評判システムに提供することができる。

さらに、データソースの他の例は、例えば「サドンデス」システムなどの、非存在と知られる電子メールアドレスへ宛てられた、受信電子メールに基づきスパムを検出するシステムでもよい。サドンデスシステムは、非存在電子メールアドレスに宛てられた電子メールメッセージの事例に基づきスパムのソースを識別する方法を提供することができる。非存在電子メールに送信された大量の電子メールは、ディレクトリ獲得攻撃（ＤＨＡ）を示す場合がある、よってソースＩＰアドレスは、ＤＨＡのソース、および可能性のあるスパム源として識別することができる。サドンデスシステムは、非存在電子メールアドレスに宛てられた電子メールを、様々な方法で検出することができる。ある場合では、サドンデスシステムは受信電子メールの配信アドレスと、実際のメールボックスアドレスに使用される可能性のない文字組み合わせを含む、メールボックスパターンのリストと、比較することができる。また、本当のユーザーに属さない「種」電子メールアドレスは、インターネット、「ユーズネット」、またはほかの場所で回覧することができる。そしてサドンデスシステムは、これらの「種」アドレスの一つに送られた電子メールを検出し、スパムの可能性あるソースとして、ソースＩＰアドレスをタグ付けする。サドンデスシステムは、非存在、または「種」アドレスに宛てられた電子メールアドレスの事例に関連する情報を保存するデータベースを含むことができる。データベースはまた、例えば、サドンデスシステムによって、スパムおよび／または、ＤＨＡのソースの可能性があるとして判断されたＩＰアドレスなどの、ＩＰアドレス情報を保存することができる。そしてこの情報は、データソースとして、ソース評判システムに提供することができる。

さらに、データソースの例は、ＩＰアドレス情報データベース（または複数のデータベース）を含むことがある。情報は受信スパム、およびそのスパムを送信したＩＰアドレスに関する情報を提供する顧客によって、提供されることがある。また情報は、ＩＰアドレスに関して、システム管理者によって提供されることがある。ＩＰアドレス情報データベースは、スパム、または他の悪意ある活動のソースだと知られているＩＰアドレスのリストなどの、ブロックリストを含むことがある。ＩＰアドレス情報データベースは、例えば、ＩＰアドレスが信頼度合いに従い得点されたＩＰアドレスなど、「グレイリスト」とされたＩＰアドレスを、ある程度信頼できるものとして含むことができる。ＩＰアドレス情報データベースはまた、スパム、または他の悪意ある活動のソースとして可能性のないと知られる、信用されたＩＰアドレスのリストを含むことがある。

信用されたＩＰアドレスは、スパムを送信する可能性がないと思われる、ドメインの識別を伴うプロセスを通して識別することができる。これには、予想される行動に基づき、ＩＰアドレスに信用レベルを割り当てることを含むことができ、信用レベルは、スパムを送信するか、またはしないかどうかという可能性のさまざまな度合いを補う。信用レベルは、とりわけ、ビジネス、産業、またはそのほかの経験則に基づくことがある。ＩＰアドレスは、ある産業と関連付けて識別することができる、例えば、ＩＰアドレスのブロックは、金融、または法律機関、或いは、あらゆる数の一般的に信用できる団体を網羅する、「一般的信用」カテゴリーにさえ、属すると識別されることがある。ある実施例では、カテゴリーは一定の信用レベルに結びつけることができ、よってカテゴリーに割り当てられたＩＰアドレスまたドメインは、自動的に関連する信用レベルが割り当てられる。

歴史的に特定のＩＰアドレスが、スパム、または他の悪意ある、あるいは望ましくないインターネット活動のソースと知られる場合、この情報は、ＩＰアドレス情報データベースに維持することができる。歴史的に、あるＩＰアドレスが認められる電子メール、またはインターネット・トラフィックのソースと知られる場合、この情報もまた、ＩＰアドレス情報データベースに保存することができる。ある実施例では、ＩＰアドレスは歴史的な情報に基づき、フラグ付け、または評価することができる。フラグ、または評価は、認められる、または望ましくない過去の活動の指標となることができる。ある実施例では、例えば、低減された信頼レベルを示す、ＩＰアドレスまたはアドレスのブロックに由来する、悪意ある活動の増大の検出に基づき、ＩＰアドレスの評価を下げる能力のある、増大活動検出システムを導入することができる。ＩＰアドレスはまた、例えば、スパムまたは他の悪意ある活動の検出が、ある一定の期間に著しく低減した場合、より信頼できるとみなされるようになる、改善された評価を得ることができる。この情報は、インターネット・トラフィックモニターからの、リアルタイムトラフィック情報に基づき、所定の間隔で更新することができる。

ソース評判システムは、データソース、または複数のデータソースから受け取った情報に基づきＩＰアドレスを評価できる、ＲＴＩＮエンジンを含む。信頼性の度合い、またはドメイン或いはＩＰアドレスが信用できるか否かの判断に到達するため、いくつものリスク数的指標を使用することができる。リスク数的指標の例は、スパム、ウィルス、電子メール爆弾、およびディレクトリ獲得攻撃に関連する、数的指標を含むことができる。これらの数的指標のそれぞれに対する測定は、例えば、１から１００の範囲のスケールなど、対象ソースＩＰアドレスが、これらの関与している度合いを示す、所定のスケールを使用して行うことができる。そしてＩＰアドレスは、これらの測定に基づき、例えば、スパム測定で５０から１００の範囲のスコアは、対象IPアドレスが著しいスパムのソースとして考慮されることを意味するなどのように、フラグ付けすることができる。そうでなければ、スパム測定が５０を下回る場合、ＩＰアドレスは一定の度合いで信用することができ、この信頼性のレベルは測定値に依存する。例えば、スパム測定が１−１０範囲のＩＰアドレスは、範囲４０−５０のスパム測定のＩＰアドレスよりも信用できると考えられる。

ある実施例では、産業、または団体がＩＰアドレスを所持すると仮定して、そのＩＰアドレスがスパムまたは悪意ある活動のソースになる可能性の大小を示す、産業要因指標となるＩＰアドレスの調査を要素に入れるため、ＩＰアドレスのオーナーを、（例、ＤＮＳまたは「ｗｈｏｉｓ」調査操作を行うことにより）識別することができる。所定の信用度を達成するドメイン、またはＩＰアドレスは、肯定的に識別することができる。ある実施例では、信用できると識別されたドメイン、またはＩＰアドレスは、信用されるＩＰアドレスのデータベースに追加することができる。

ＲＴＩＮデータベースに維持されている情報の種類には、ＩＰアドレス、またはＩＰアドレスのブロックに、対象のアドレスがスパム、ウィルス、ＤＨＡ、またはその他の悪意ある活動のソースである可能性を示す、データなどを含むことがある。例えば、ＲＴＩＮデータベースには、各ＩＰアドレスに対する、スパム、ウィルス、またはＤＨＡなど、ひとつ以上のカテゴリーのスコアを含むことがあり、そのスコアは、対象アドレスが、それぞれのカテゴリーに関連する活動に関与する可能性がどのくらいかという目安を提供する。ソース評判データベースへのクエリは、特定種類の情報の要求から、例えば、特定のＩＰアドレス またはアドレスのブロックに関連する、すべての入手可能な情報の要求など、より一般的な要求まで、さまざまである。

ソース評判データベースの投入、保存、およびアクセスの提供のための具体的な設計は、さまざまである。好ましい設計の例がここに開示されているが、本開示の精神と範囲から離れることなく、他の設計を使用することができる。

図１は、ソースＩＰアドレスの評判に基づき、ネットワークトラフィックのフィルタリングを提供する、フィルタリングシステム１００の一例を示す、ブロック図である。図示された実施例に従い、システム１００は、ひとつ以上のデータソース１０２ａ、１０２ｂ（集合的に「１０２」）、ソース評判システム１０４、および一つ以上の顧客システム１０６ａ、１０６ｂ（集合的に「１０６」）を含む。ソース評判システム１０４は、リアルタイム脅威識別（ＲＴＩＮ）エンジン１０８および、任意の顧客設定データベース１１０を含む。

ＲＴＩＮエンジン１０８は、いくつものデータソース１０２から、ＩＰアドレス情報を検索すること、ＲＴＩＮデータベース１１４のＩＰアドレス、またはＩＰアドレスブロックのソース評判プロファイルを作成、維持するため、検索した情報を処理すること、また、顧客システム１０６へのソース評判プロファイル情報の配布の管理することに関与する。顧客システム１０６ａおよび１０６ｂは、顧客ルーター１０７ａおよび１０７ｂ（集合的に「１０７」）をそれぞれ含むことに注意すること。ある実施例では、ＲＴＩＮエンジン１０８は、プロファイル情報の配布の管理を、直接顧客ルーター１０７に行うことができる。ある実施例では、ＲＴＩＮエンジン１０８は、データベース１１０に保存された顧客情報に従い、ＩＰアドレスプロファイル情報の配布管理をすることができる。例えば、情報配布方法と、顧客システム１０６ａに提供される情報の種類は、顧客システム１０６ｂのものとは異なることがある。ＲＴＩＮエンジン１０８は、顧客１０６ａと１０６ｂの適切な扱いを、その特有な選択および／または設定に従い、確実にするため、データベース１１０に保存されたデータを参照することがある。

ＲＴＩＮエンジン１０８は、一つ以上のデータソース１０２から受け取った情報に基づき、ＩＰアドレスを評価することができる。信頼性の度合い、またはソース／ドメインが信用できるか否かの判断に到達するため、いくつものリスク数値指標を使用することができる。リスク数値指標の例には、スパム、ウィルス、電子メール爆弾、およびディレクトリ獲得攻撃に関する数値指標を含むことがある。これら数値指標それぞれの測定は、例えば、１から１００範囲の尺度などの、対象ソースＩＰアドレスがこれらの行動に関与した度合いを示す、所定の尺度において行うことができる。それからＩＰアドレスは、例えば、５０から１００の範囲のスコアのスパム測定は、対象ＩＰアドレスが著しいスパム源であると考えられると意味することがあり得るなど、これらの測定に従い、フラグ付けすることができる。さもなければ、スパム測定が５０を下回る場合、ＩＰアドレスは一定の度合いに信用することができ、信用の度合いは測定値に依存する。例えば、スパム測定が１−１０の範囲のＩＰは、スパム測定が範囲４０−５０にあるＩＰアドレスより、より信用できると考えられる。

ある実施例では、産業、または団体がＩＰアドレスを所持すると仮定して、そのＩＰアドレスがスパムまたは悪意ある活動のソースになる可能性の大小を示す、産業要因指標となるＩＰアドレスの調査を要素に入れるため、ＩＰアドレスのオーナーを、（例、ＤＮＳまたは「ｗｈｏｉｓ」調査操作を行うことにより）識別することができる。所定の信用度を達成するドメイン、またはＩＰアドレスは、肯定的に識別することができる。ある実施例では、信用できると識別されたドメイン、またはＩＰアドレスは、信用されるＩＰアドレスのデータベースに追加することができる。

ＲＴＩＮデータベース１１４を生成するため、ソース評判システム１０４の管理者は、例えば、メッセージの数と、特定のＩＰアドレスから送信されたスパムメッセージの数の割合など、さまざまなデータソース１０２において入手可能な情報のさまざまな領域の組み合わせをクエリし、評価することができる。その他の測定には、次のものがあるが、これに限定されない。
・ 配信されたメッセージの数
・ スパムと見られるメッセージの数
・ 受信者の数
・ 接続の試みの数
・ 接続成功の数
・ 接続失敗の数
・ ４００クラスエラーの数
・ ５００クラスエラーの数
・ バイトでの平均メッセージサイズ
・ 平均接続時間
・ ウィルスの数

ＲＴＩＮエンジン１０８は、どのソースＩＰアドレスが、スパム攻撃規定、ディレクトリ獲得攻撃規定、ウィルス規定、または、サービス妨害攻撃規定に違反するかクエリを行う、データソース１０２のいくつか、すべての一斉検索を行うことができる、または、ＲＴＩＮエンジン１０８は、ソースＩＰアドレスをデータソース１０２内のデータ解析に従い、評価、または識別を行うことができる。

ＲＴＩＮデータベース１１４は、特定のソースＩＰアドレスにその記録の消去を許可するが、必ずしも、悪い記録を作成するのと同じ割合で適正証明を受け取るわけではない。例えば、ソースＩＰアドレスのＤＨＡスコアを減少するために、１０の「クリーン」パスが必要になるかもしれない。これらの評価は、経験的観測、または設計目標に従い調整することができ、−例えば、以前の攻撃の重大性／レベルまたはそのＩＰアドレスに関して、その他の知られている情報など、異なる状況の下では異なることさえもある。

手続きとして、ＲＴＩＮエンジン１０８は、顧客１０６の要求に基づき、名前、または値の対のカンマ区切り一覧ＩＰアドレス固有値を供給することができる。これらは、加算値の追加、および以前のシステムとの下位の互換性に大きな柔軟性を与える。

前述されたとおり、産業固有ＩＰアドレス範囲の知識を通してなど、否定的なものの代わりに、肯定的な評判を作成することが可能である。したがって、一定のソースＩＰアドレスは、−例えば、ＩＢＭ，３Ｍ、またはＧＭなどに保有されたサーバなど−スパムやＤＨＡなどではなく、有効な電子メールを送信すると強く推測することができる。そして、この評価は、顧客１０６からの、ソース評判問い合わせとともに返すことができる、肯定的な評判スコアを構成することがある。また、医療、法律、会計などそれらの産業の一つに属すＩＰアドレスは、それらの産業の一つに属する顧客によって、ブロックされる可能性がより少なくなるよう、より粒度の細かい産業固有情報を提供することが可能である。

発信者番号通知型、またはブラックリストなどの、以前に詳細されているアプローチに関連のある、ソース評判システム１０４の区別は、ＲＴＩＮデータベース１１４が、ネットワークパフォーマンスの性能に基づき、システム１０４によって行われた測定に客観的に基づくことである。これらは、人々にスパマーの記録をとること、または報告することを要求しない。簡潔に言うと、ソース評判システム１０４は、あなたが誰であると言うか、またはあなたが誰と登録しているかということを気にしない。もしあなたが悪いことをしていれば、悪いことをしていると識別され、ＲＴＩＮデータベース１１４の支持により、顧客システム１０６にフィルターされるあなたの送信メールの性能に影響する。発信者番号通知は既知のサーバから、人々がスパムを送信することを止めない、特定の電子メールのＳＭＴＰ情報が識別されたサーバに関連するもの以外の、サーバから送信された電子メールをブロックするだけであり、発信者番号通知はスパムへの完全な解決策にはならない。さらに、発信者番号通知アプローチは、ディレクトリ獲得攻撃から保護しない、なぜなら、発信者番号通知評価は、メッセージのペイロードにアクセスすることを要求するからである。経験則ベースのアプローチは、しかしながら、多くの場合において、活発にスパマーによって使用されている、または、一定の産業やビジネスの種類など、正当な送信者によって活発に使用されていると判断された、電子メールのソースＩＰアドレスの関係によって、スパマーからのメールを単純に邪魔することができる。そのようなフィルタリングへの産業経験側アプローチに関する、広範囲な議論は、本開示と同一出願人による、また本文にその全体を参照することにより組み込まれる、米国特許出願番号１０／８３２，４０７、発明の名称「ビジネス経験則を使用した電子メールフィルタリングのシステムと方法」を参照されたい。

ＲＴＩＮデータベースに維持される情報の種類は、したがって、ＩＰアドレスまたはＩＰアドレスのブロックに対し、対象アドレスが、スパム、ウィルス、ＤＨＡ、またはその他の悪意ある活動のソースと思われる可能性を示すデータなどの情報を含むことがある。例えば、ある実施例では、ＲＴＩＮデータベースは、ＩＰアドレスのそれぞれに対し、スパム、ウィルス、またはＤＨＡなどの、一つ以上のカテゴリーの評価を含むことがあり、スコアは、対象ＩＰアドレスがどのぐらいそれぞれのカテゴリーに関連する活動に関与する可能性があるかを示す目安となる。

図２は、ＲＴＩＮエンジン１０８の一番目の実施例を示すブロック図である。最初の実施例によると、ＲＴＩＮエンジン１０８は、一つ以上のＲＴＩＮサーバを備える。図示されている例では、ＲＴＩＮエンジン１０８は、一次および二次ＲＴＩＮサーバ１１２ａ、および１１２ｂ（集合的に「１１２」）を含む。サーバ１１２のそれぞれは、同じ情報を処理し、保存する能力がある。これにより、顧客１０６に提供されるサービスは、保守やその他の理由によりサーバ１１２の一つがダウンしていても、断続することがない。したがって、複数のＲＴＩＮサーバ１１２の使用は、より頑強なシステム１０４を可能にする。代替の実施例には、いくつものＲＴＩＮサーバ１１２を含むことがある。

ＲTＩＮサーバ１１２のそれぞれは、ＲＴＩＮデータベース１１４ａ、１１４ｂ（集合的に「１１４」）を含み、ソースＩＰアドレス評判情報が維持されている。ＲＴＩＮサーバ１１２は、定期的にデータソース１０２にＩＰアドレスを情報のクエリを実行し、そのＩＰアドレス情報を、ＩＰアドレスのソース評判プロファイルを生成するため処理し、そして、それに応じてＲＴＩＮデータベース１１４を更新する。図２に示されているように、一つ以上のＲＴＩＮサーバ１１２を含む実施例においては、各サーバ１１２ａおよび１１２ｂは、それぞれ同じ情報を収容する、ＲＴＩＮデータベース１１４ａ、１１４ｂを含むことがある。

ＲＴＩＮサーバ１１２はまた、顧客１０６へのソースＩＰアドレス評判情報の配布を管理する。サーバ１１２は、ある実施例では、アクセスが必要に応じて制限および管理されることができるが、顧客１０６からアクセスすることがある。例えば、ＲＴＩＮサーバ１１２は、ソース評判システム１００に加入する顧客１０６によってのみ、ＲＴＩＮデータベース１１４に、信頼できる、認証されたアクセスを許すよう設定することができる。顧客１０６は、サーバ１１２にクエリ実行することができ、ＲＴＩＮデータベース１１４の保存された情報に基づく応答を受け取る。

ＲＴＩＮデータベース１１４に保存されたデータは、顧客によってアクセス、または様々な方法によって顧客へ提供することができる。ＲＴＩＮデータにアクセスできる方法の一つは、ＲＴＩＮコントローラ（ＲＴＩＮサーバ１１２に関連付けられている（図３参照））により、顧客１０６が認証されたＤＮＳ型問い合わせを送信することによる、ＤＮＳ型検索アルゴリズムを通じて行うものである。これらのＤＮＳ型検索は、特定の送信サーバＩＰアドレスに対し（ＳＭＴＰ接続を要求している電子メールサーバに送信するため）、送信サーバが悪い、あるいは良い評判があるかどうかを確認するため、顧客１０６により送信することができる。

ＲＴＩＮコントローラは、顧客設定データベース１１０に保存された、顧客データを参照することができる。したがって、例えば、顧客１０６ａは、システム１０４に送信サーバＩＰアドレスのＤＮＳ型問い合わせを送信することがある。この問い合わせは、ＲＴＩＮサーバ１１２の一つによって扱われる。ＲＴＩＮサーバ１１２は、顧客設定データベース１１０の設定情報に従い、ＲＴＩＮデータベース１１４から情報を供給することができる。顧客の問い合わせへの応答には、ＲＴＩＮ顧客１０６へ、特定の送信サーバＩＰアドレスが、スパム、またはディレクトリ獲得攻撃、またはサービス拒否攻撃に、関連付けられている可能性があることを示す評価、または肯定的な面では、送信サーバが正当な電子メールに関連付けられると示す、肯定的な評価が、特定の送信サーバに関連付けることができるかを、提供することを含むことがある。これらの検索は、加入者電子メールシステムが、電子メール接続要求を受信する際に、リアルタイムで行うことができる。

図３は、ＲＴＩＮエンジン１０８の二つ目の実施例を示すブロック図である。最初の実施例では、ＲＴＩＮサーバ１１２で実施された機能が、二番目の実施例において、ＲＴＩＮコントローラ１１６ａ、１１６ｂ（集合的に「１１６」）と、ＲＴＩＮサーバ１１８ａ、１１８ｂ（集合的に１１８）に分割される点において、最初の実施例と異なる。したがって、二番目の実施例に従い、ＲＴＩＮエンジン１０８は、一つ以上のＲＴＩＮコントローラ１１６、および一つ以上のＲＴＩＮサーバ１１８を備える。各コントローラ１１６と、サーバ１１８は、それぞれのＲＴＩＮデータベース１１４ａ、１１４ｂ、１１４ｃ、１１４ｄ（集合的に「１１１４」）を維持する。最初の実施例と同様、複数のコントローラ１１６と、サーバ１１８の組み合わせを使用することは、より頑強なシステム１０４を可能にする。

ＲＴＩＮコントローラ１１６と、ＲＴＩＮサーバ１１８の間での業務分割は異なることがある。例えば、ＲＴＩＮコントローラ１１６は、ＩＰアドレス情報を収集するため、データソース１０２に定期的にクエリ実行し、ソースＩＰ評判データを作成するため、ＩＰアドレス情報を処理し、また、コントローラ１１６と、サーバ１１８両方のＲＴＩＮデータベース１１４を更新することに関与している。ＲＴＩＮサーバ１１８は、顧客１０６からのクエリを扱うことも含む、顧客１０６へＲＴＩＮデータベース１１４に保存されている、ソースＩＰアドレス評判情報の配布の管理に関与することがある。

図１に戻って、ソース評判システム１０４は、いくつものデータソース１０２にアクセスすることができる。ブロック図は、２つのデータソース１０２ａ、１０２ｂを示すと同時に、本開示の範囲から逸脱することなく、いくつものデータソース１０２が使用できることに注意する。

データソース１０２の仕様も、異なることがある。ある実施例では、例えば、電子メールトラフィックを監視するシステムが、データソース１０２として使用されることがある。図４は電子メールトラフィック監視システム１２０の、一実施例を示すブロック図である。トラフィック監視システム１２０は、リアルタイム電子メールトラフィック統計を生成する。トラフィック監視システム１２０は、能動ＥＭＳ特許（上記に参照）において述べられている、能動電子メッセージ管理システムの構成部品、およびプロセスを含むことがある。トラフィック監視システム１２０は、メッセージ処理プロセス１２２を含む。メッセージ処理プロセス１２２は、サーバ１２４などの送信電子メールサーバから、サーバ１２６などの、受信メールサーバへの着信ＳＭＴＰ接続の試みの設定、監視に関与する。

プロセス１２２は、トラフィックモニター１２８に接続されている。トラフィックモニター１２８は、リアルタイム受信ＳＭＴＰ接続データ、メッセージメタデータ、および、プロセス１２２からのソースおよび配信先データを含む、メッセージ配信情報を収集する。ソースおよび配信先データは、送信メールサーバ１２４に関連付けられたソースデータ、および受信メールサーバ１２６に関連付けられた配信先データを含むことがある。各ソースＩＰアドレス、および配信先データ／情報の組み合わせに対し、トラフィックモニター１２８により維持されるデータポイントの具体的な例は：
・ 過去一分間に、ソースによりトラフィック監視システム１２０になされた接続の数
・ 現在オープンなソースからの接続の数
・ 過去一分間にソースに代わり、トラフィック監視システム１２０により、顧客になされた接続の数
・ 現在オープンな、ソースに代わり、トラフィック監視システム１２０により、顧客になされた接続の数
・ ソースに代わり、トラフィック監視システム１２０により、顧客になされた接続の試みで失敗の数
・ ソースからトラフィック監視システム１２０への接続時間の、平均と標準偏差
・ ソースに代わり、トラフィック監視システム１２０により、顧客になされた接続時間の、平均と標準偏差
・ ソースから顧客へのすべてのメッセージの大きさの平均と標準偏差
・ ソースから顧客へのメッセージの受信者数の平均と標準偏差
・ ソースから顧客へ送信されたメッセージの数（合計）
・ トラフィック監視システム１２０がスパムと識別した、ソースから顧客に送信されたメッセージの数
・ トラフィック監視システム１２０がウィルスを含むと識別した、ソースから顧客に送信されたメッセージの数
・ 接続管理記録により、トラフィック監視システム１２０が、送り返したソースから顧客に送信されたメッセージの数
・ 接続管理記録により、ブラックホーリングした、ソースから顧客に送信されたメッセージの数
・ 接続管理記録により、検疫した、ソースから顧客に送信されたメッセージの数
・ トラフィック監視システム１２０が集積した、ソースから顧客に送信されたメッセージの数
・ ソースと顧客が関与する接続に見られた４００クラスエラーの数
・ ソースと顧客が関与する接続に見られた５００クラスエラーの数
したがって、トラフィック監視システム１２０は、システム１２０を通して行われる送信サーバに対し、ソースＩＰアドレスに従いリアルタイム解析保存することができる。

図４は、単一トラフィックモニター１２８として、トラフィックモニターを示しているが、実用的な実装においては、トラフィックモニターは、より少ない、またはより多くても良い。例えば、加入者の地理、または第一言語に従って、トラフィックモニターを分割することが望ましいかもしれない。

ある実施例では、トラフィック監視システム１２０は、例えば６０秒間など、比較的短期のすべての送信サーバ、またはメール配達エージェント（MTAs）の情報の維持に関与することがある。 これらの送信ＩＰアドレスのすべては、トラフィックモニター１２８内の記憶グリッドに保存され、トラフィックモニター１２８は、いくつのメッセージを送信したか、いくつの「５００エラー」、または他の種類のエラーが発生したか、および内容スキャンに基づき、いくつのスパムメッセージが送信されたかなどの、それらのソースＩＰアドレスに関する複数片の情報を維持する。ある実施例では、トラフィック監視システム１２０はいつでも、過去６０秒の間に何が起こったかのみを知るように設定することができる、一つの接続が６０秒以上オープンでも、トラフィック監視システム１２０は、接続が生きている限り、そのデータを蓄積することができる。

データソース１０２のほかの例は、電子メールを監視し、ある期間の電子メールの量に基づき、スパムのソースのＩＰアドレスを検出するシステムでもよい。図５は、そのようなシステムの一実施例を示す、ブロック図である。図５に示されているシステムはツーストライクシステム１３０である。ツーストライクシステム１３０は、擬陽性スパム識別を低減する方法を提供する。スパムと間違って識別された電子メールを送信するＩＰアドレスは、通常スパムと識別される電子メールを大量に送信しない。したがって、ツーストライクシステム１３０が、あるＩＰアドレスからの電子メールがスパムだと疑う場合、そのＩＰアドレスから、疑われるスパム電子メールを受信してからの経過時間を確認する。そして所定の時間以上経過している場合、ツーストライクシステム１３０は、疑われた電子メールがスパムである可能性が小さいと考える。一方、経過時間が一定時間を下回る場合は、システム１３０は、疑われた電子メールはスパムである可能性は高く、送信ＩＰアドレスを可能性あるスパムのソースとして識別する。

ツーストライクシステム１３０は、図４に参照し述べられているプロセス１２２などの、メッセージ処理プロセス１２２を含む。メッセージ処理プロセス１２２はまた、送信メッセージに関連付けられたソースおよび配信先データを判断することと同時に、サーバ１３４など、送信電子メールサーバから、サーバ１３６などの受信メールサーバへの受信ＳＭＴＰ接続の試みの設定、および監視に関与する。プロセス１２２は、ツーストライクエンジン１３２に接続されている。ツーストライクエンジン１３２は、メッセージ処理プロセス１２２と、プロセス１２２が取得するデータと連携するよう設定されている。エンジン１３２は、さらに受信電子メールがスパムに見られるかどうかを検出するように設定されてもよい。いくつかの代替の実施例においては、この判断はプロセス１２２によって行うことができ、検出はエンジン１３２に提供される。いくつかのそのような実施例では、ツーストライクエンジン１３２は、スパムだと疑われる識別を電子メールと共に受け取ることができる。他の代替の実施例では、システム１３０は、スパムと疑われる電子メールのみを受け取るよう設定することができ、その場合、その趣旨での表示が必要ない。このスパム検出は、例えば電子メールの内容に基づくなどの、あらゆる既知のスパム検出方法に基づくことができる。

エンジン１３２は、ツーストライクデータベース１３８に接続されている。エンジン１３２は、スパムと疑われる電子メールの事例に関する情報を保存するため、データベース１３８を使用することができる。データベース１３８はまた、例えば、エンジン１３２によって、スパムのソースの可能性が検出されたＩＰアドレスなど、ＩＰアドレス情報を保存する。この情報は、RTINエンジン１０８に利用される。

図６は、ツーストライクシステム１３０によって実施される、ツーストライクプロセスを示すフローチャートである。ブロック１４０では、対象ＩＰアドレスからの受信電子メールは、例えばメッセージ処理プロセス１２２などによって、スパムである可能性が高いと識別される。ブロック１４２では、ツーストライクエンジン１３２は、データベース１３８に対象ＩＰアドレスに対するクエリ実行する。疑われる電子メールが以前に対象ＩＰアドレスから受信されている場合は、次にデータベース１３８は、最後に疑われる電子メールが受信された時間を含める。ツーストライクエンジン１３２は、最後の疑われる電子メールの時間を検索する。対象ＩＰアドレスのデータが存在しない場合、プロセスはブロック１４８にスキップできることに注意すること。ブロック１４４では、エンジン１３２は、現在の疑われる電子メールと、以前の疑われる電子メールの間で、どのぐらいの時間が経過したか、また時間は所定の閾値を下回るかを判断する、この時間はどのぐらいでもよく、ヒストリー情報に従い設定することができる。閾値の一例として、２時間にすることができる。時間の閾値が経過していない場合（ブロック１４４の「はい」）、電子メールはスパムと考えられ、処理はブロック１４６に続く。ブロック１４６では、電子メールは検疫される、またそうでなければスパムと扱われる。また、既知のスパムのソースとして、スパム電子メールのソースＩＰアドレスを識別するため、データベース１３８は更新される。次に、ブロック１４８において、データベース１３８は更新され、将来のこのプロセスの繰り返しのために、現在の疑われる電子メールは前回の疑われる電子メールの時間を置き換える。ブロック１４４において、閾値の時間が経過した場合（ブロック１４４の「いいえ」）、プロセスはブロック１４６をスキップし、ブロック１４８に進むことに注意する。

また、データソース１０２の他の例は、既知の非存在電子メールアドレスに宛てられた受信電子メールに基づきスパムを検出するシステムでも良い。図７は、そのようなシステムの一実施例を示す、ブロック図である。図７に示されているシステムは、サドンデスシステム１５０である。システム１５０は、非存在電子メールアドレスに宛てられた電子メールメッセージの事例に基づき、スパムのソースを識別する方法の一つを提供する。非存在電子メールアドレスへ送信された大量の電子メールは、ＤＨＡの兆候であることがあり、ソースＩＰアドレスは、ＤＨＡのソースおよびスパムの可能性あるソースとして識別することができる。ある場合では、実在のユーザーに属さない、「種」電子メールアドレスがインターネット、「ユーズネット」、または他の場所上に流通されることがある。そしてシステム１５０は、これらの「種」アドレスの一つに送信された電子メールを検出し、ソースＩＰアドレスをスパムのソースの可能性があるとして、タグ付けすることができる。

サドンデスシステム１５０はまた、図４および５に参照して述べられているプロセス１２２などの、メッセージ処理プロセス１２２を含む。メッセージ処理プロセス１２２はまた、送信メッセージに関連付けられたソースおよび配信先データを判断することと同時に、サーバ１５４など、送信電子メールサーバから、サーバ１５６などの受信メールサーバへの受信ＳＭＴＰ接続の試みの設定、および監視に関与する。プロセス１２２は、サドンデスエンジン１５２に接続されている。サドンデスエンジン１５２は、メッセージ処理プロセス１２２と、プロセス１２２が取得するデータと連携するよう設定されている。エンジン１５２はさらに、受信電子メールの受取人は、非存在アドレス、または「種」アドレスと思われるかどうかを検出するように設定されても良い。いくつかの代替の実施例においては、この判断はプロセス１２２によって行われ、その判断はエンジン１５２に提供されてもよい。そのようなある実施例では、サドンデスエンジン１５２は、電子メールと共に、非存在または「種」アドレスに送信されたという、何らかの兆候を受け取ることができる。その他のそのような代替の実施例において、システム１５０は非存在、または「種」アドレスに宛てられた電子メールのみを受け取るように設定されても良い、この場合、その趣旨での表示が必要とされない。

エンジン１５２は、サドンデスデータベース１５８に接続されている。エンジン１５２は、非存在、または「種」アドレスに宛てられた電子メールの事例に関連する情報を保存するため、データベース１５８を使用することができる。データベース１５８はまた、例えば、エンジン１５２によって、スパムおよび／またはＤＨＡのソースの可能性があると判断されたＩＰアドレスなどの、ＩＰアドレス情報を保存する。この情報は、ＲＴＩＮエンジン１０８に利用される。

図８は、サドンデスシステム１５０によって実施されたサドンデスプロセスを示す、フローチャートである。ブロック１６０では、例えばメッセージ処理プロセス１２２などにより、対象ＩＰアドレスからの受信電子メールが、非存在電子メールアドレスに送信されたと識別されている。ある場合では、これは、受信メールサーバ１５６が、電子メールメッセージの受取人を認識しないことを意味する、対象電子メールが受信メールサーバ１５６にクラス５００エラーを発生させたと意味することがある。電子メールはまた、「種」アドレス、またはサドンデスアドレスパターン（「ＳＤパターン」）に一致するアドレスをもつとして、フラグ付けされることがある。ＳＤパターンは、メールボックス （例えば、ｐｔｅｘｑｌ＠）が、実際のメールボックスである可能性が低いものである。サドンデスエンジン１５２は、そのようなＳＤパターンの一覧を維持することができる。ブロック１６２では、サドンデスエンジン１５２は、配信アドレスがＳＤパターンの一つと一致するかどうかを判断する。一致する場合は、プロセスはブロック１６４に続く。そうでなければ、ブロック１６４は、スキップされる。ブロック１６４では、サドンデスエンジン１５２は、存在する正当な電子メールアドレスにＳＤパターンが使用されているかどうかを判断する。例えば、電子メールが「ｐｔｅｘｑｌ＠ｘｙｚ．ｃｏｍ」に宛てられたとする、メールボックス「ｐｔｅｘｑｌ」はＳＤパターン「ｐｔｅｘｑｌ」に一致する。しかしながら、電子メールアカウントが存在し、かつＳＤパターンと一致する可能性がある。よって、ブロック１６４において、サドンデスエンジン１５２は、「ｐｔｅｘｑｌ＠ｘｙｚ．ｃｏｍ」が実際に存在するかどうかを判断するため、サーバに「ｘｙｚ．ｃｏｍ」に対するクエリを実行することができる。存在する場合は、サドンデスプロセスを終了し、電子メールを通常通り配信することができる。そうでなければ、プロセスはブロック１６６に進む。ブロック１６２において、アドレスがＳＤパターンに一致しない場合、プロセスはまたブロック１６６に進むことができることに注意する。

ブロック１６６において、配信アドレスが十分不明瞭であるかどうか、判断がなされる。例えば、電子メールが「ｐｔｅｘｑｌ＠ｘｙｚ．ｃｏｍ」に宛てられていて、正当な電子メールアカウントは、「ｐｒｅｘｑｌ＠ｘｙｚ．ｃｏｍ」で存在する場合、二つのアドレスは非常に似ていることから、送信者が配信アドレスを間違えて入力している可能性が十分ある。したがって、ブロック１６６は、例えば、１つまたは２つ以上の違いなど、配信アドレスと、存在するアドレスのいずれかとの違いの数が、所定の数の違い（例えば文字）を上回るかをどうか判断するため、配信アドレスと存在するアドレスの比較を含むことがある。上回っていなければ、（ブロック１６６の「いいえ」）、サドンデスエンジン１５２は、電子メールを、間違って宛てられた正当な電子メールであるとして扱う。そうでなければ（ブロック１６６の「はい」）、電子メールはスパムとして扱われ、サドンデスエンジン１５２は、ソースＩＰアドレスをスパムの可能性あるソースとして識別するため、サドンデスデータベース１５８を更新する。

再び図１を参照して、さらにデータソース１０２の一例は、ＩＰアドレス情報データベース（または複数データベース）でも良い。情報は、受信したスパム、およびスパムを送信したＩＰアドレスに関する情報を提供する、顧客１０６により提供されることがある。この情報は、システム監視者によってＩＰアドレスに関して、提供されても良い。ＩＰアドレス情報データベースは、既知のスパム、またはその他の悪意ある活動のソースであるＩＰアドレスの一覧などの、ブロックリストを含んでもよい。ＩＰアドレス情報データベースは、例えば、ＩＰアドレスが、その信頼度合いによって判断されるなど、ある程度信用できるとして、グレイリストＩＰアドレスを含んでも良い。ＩＰアドレス情報データベースはまた、スパム、またはその他の悪意ある活動のソースである可能性が低いと知られている、信頼できるＩＰアドレスの一覧を含んでも良い。

信頼できるＩＰアドレスは、スパムを送信する可能性が低いと見られる、ドメインの識別を伴うプロセスを通して識別することができる。これには、予測される行動に基づき、ＩＰアドレスの信頼レベルを割り当てることを含むことがあり、信用レベルは、スパムが送信されるか、されないかという可能性の様々な度合いを測る。信頼レベルは、とりわけ、ビジネス、産業または、他の経験則に基づくことがある。ＩＰアドレスは、例えば、ＩＰアドレスのブロックが、金融または法律団体、またはいくつもの一般的に信頼のできる団体を網羅する「一般的信頼」カテゴリーでさえに属するとして識別されるなど、一定の産業に関連付けられると識別することができる。ある実施例では、カテゴリーは、一定の信頼レベルと結びつけることができるので、カテゴリーを割り当てられたＩＰアドレスやドメインは、関連付けられた信頼レベルを自動的に割り当てられる。

歴史的に、特定のＩＰアドレスがスパム、または他の悪意ある、あるいは望ましくないインターネット活動のソースであると知られている場合、この情報は、ＩＰアドレス情報データベースに維持することができる。歴史的に、ＩＰアドレスが認められる電子メール、または他のインターネット・トラフィックのソースと知られている場合、この情報もまたＩＰアドレス情報データベースに保存することができる。ある実施例では、ＩＰアドレスは、歴史的情報に基づき、フラグ付けまたは評価することができる。フラグ付け、または評価は、認められる、または望ましくない過去の活動の指標であってもよい。ある実施例では、例えば、低減された信頼レベルを示す、ＩＰアドレスまたはアドレスのブロックに由来する、悪意ある活動の増大の検出に基づき、ＩＰアドレスの評価を下げる能力のある、増大活動検出システムを、導入することができる。ＩＰアドレスはまた、例えば、スパムまたは他の悪意ある活動の検出が、ある一定の期間に著しく低減した場合、より信頼できると考慮されるようになる、改善された評価を得ることができる。この情報は、インターネット・トラフィックモニターからの、リアルタイムトラフィック情報に基づき、一定の間隔で更新することができる。

次に図９は、ＲＴＩＮデータベース１１４を投入するための、プロセスの一実施例を示す、フローチャートである。この実施例において、トラック監視システム１２０がデータソース１０２の一つとして使用可能である。

ブロック１７０から始まり、トラフィックモニター１２８は、リアルタイムトラフィック統計を受信する。次に、ブロック１７２に示されているように、トラフィックモニター１２８は、リアルタイム受信ＳＭＴＰ接続データ、メッセージメタデータ、およびソースおよび配信データを含む、メッセージ情報を収集する。ソースおよび配信先データには、送信メールサーバ１２４に関連付けられたソースデータ、および受信メールサーバ１２６に関連付けられた配信先データを含むことがある。したがって、トラフィックモニター１２８は、送信サーバがシステム１２０を通して送られるために、ソースＩＰアドレスに従い、リアルタイム統計を保存する。具体的な実装では、トラフィックモニター１２８は、例えば６０秒などの、比較的短い時間の、送信サーバまたはＭＴＡに関するすべての情報を維持することに関与する。これらの送信ＩＰアドレスのすべては、トラフィックモニター１２８内の記憶グリッドに保存され、トラフィックモニター１２８は、いくつのメッセージを送信したか、いくつの「５００エラー」、または他の種類のエラーを発生したか、および内容スキャンに基づき、いくつのスパムメッセージが送信されたかなどの、それらのソースＩＰアドレスに関する複数片の情報を維持する。いくつかの実施例において、トラフィックモニター１２８はいつでも、過去６０秒の間に何が起こったかのみを知るように設定することができる、一つの接続が６０秒以上オープンでも、トラフィックモニター１２８は、接続が生きている限り、そのデータを蓄積することができる。

次に、図９のブロック１７４に示されているように、ＲＴＩＮエンジン１０８はデータソース１０２にクエリを実行する。本実施例では、これにはトラフィック監視システム１２０にクエリ実行し、トラフィックモニター１２８に保存されているデータを、スウィープすることを含む。トラフィックモニター１２８のスウィープは、例えば、１５分ごとに起こるなど、６０秒より頻繁になど、定期的でも良い。理想的には、スウィープの間の時間は、トラフィックモニター１２８にデータが維持された時間を下回るべきである。

ＲＴＩＮエンジン１０８は、上述されたもののような、追加のデータソース１０２にクエリ実行することができる。例えば、ある実施例では、ＲＴＩＮエンジン１０８は、ツーストライクデータベース１３８、サドンデスデータベース１５８、および／または上述のデータベースにクエリ実行してもよい。

様々なデータソース１０２からデータが収集されると、ＲＴＩＮエンジン１０８は、図９のブロック１７６に示されているように、クエリの結果を処理することができる。トラフィック監視システム１２０からデータが収集された場合、ＲＴＩＮエンジン１０８は、トラフィックモニター１２８のデータを収集し、また解釈プロセスを使用し、作用することのできるメッセージのトラフィックの中で、メッセージのパターンを認識するため、このデータを解析することができる。解釈プロセスは、上述されている能動ＥＭＳ特許に述べられているような解釈プロセスでもよい。解釈プロセスは、ソースと配信先データの両方、そしてトラフィックモニターに書き込まれたメタデータを解析することによって、電子メールメッセージ、またはメッセージを送信するユーザーの行動さえにも、関連付けられているパターンを判断する。ある場合において、解釈プロセスは、追加のデータソース１０２から受信したデータを考慮に入れることができる。

模範的なアプローチとして、ＲＴＩＮデータベース１１４は、特定ＩＰアドレスに関する多くのほかの種類の情報や攻撃を識別するために、柔軟に定義することができるが、解釈プロセスは、４つの主な種類のアタック−ＤＨＡ、スパム攻撃、ウィルスの発生、およびメール爆弾／サービス拒否攻撃−を識別することができる。具体的な例として、ソースＩＰアドレスが、これら４つの攻撃のうち一つ以上に関与していると検出される場合、ソースＩＰアドレスと、識別された攻撃の特定のタイプに関連付けられたカウンターは、一つ増える。具体的な例として、ＲＴＩＮエンジン１０８が深夜にトラフィック監視システム１２０を通し、スイープを行い、ＩＰアドレス「ＸＹＺ」がＤＨＡに関与していると判断する場合、ＲＴＩＮデータベース１１４の「ＸＹＺ」ソースＩＰアドレス入力に関連付けられたカテゴリーに一つのカウントを加算することができる。これがこのソースＩＰアドレスに対する新しい入力である場合は、関連付けられる評価はＤＨＡ＝１である。スウィープ中の次の一分間に、「ＸＹＺ」ソースがまだ攻撃していると識別される場合、そのスコアは一つ増え、ＤＨＡ＝２に更新され関連付けられたスコアを生み出す。このプロセスは、例えば９９などの最大値まで継続することができる。９９回のスウィープを通して、ソースＩＰアドレス「ＸＹＺ」が、トラフィックモニター解析に基づき、誰かを攻撃している場合、カウンターは、最大と定義することができる９９まで増加する。

図９のブロック１７８に示されている通り、解釈処理より生じたデータは、ＲＴＩＮデータベース１１４を更新するために使用される。追加データソースから受信されたデータの性質により、解釈プロセスの必要性なく、いくつかのデータソース１０２から受け取ったデータで直接ＲＴＩＮデータベースを更新することがふさわしいことがある。例えば、データソース１０２の一つが、ＩＰアドレスがブロックされるべきだという情報を提供する場合である。

ＲＴＩＮコントローラ１１６がＲＴＩＮデータベース更新をＲＴＩＮサーバ１１８に押し出す、任意のブロック１７９が示されている。この任意のブロックは、図３に示されている２つ目の実施例などの実施例に使用される。任意のブロック１７９は、図２の最初の実施例などの他の実施例には必要にならない。ブロック１７９が実用的な場合備えられ、ＲＴＩＮサーバ１１８のＲＴＩＮデータベース１１４が、ＲＴＩＮコントローラ１１６のＲＴＩＮデータベース１１４と同期することができる。

トラフィックモニター１２８は短期間のみデータを維持する一方、ＲＴＩＮデータベース１１４は、より長い時間ＩＰアドレスに関する蓄積され、更新された情報を維持できることに注意することである。

ＲＴＩＮデータベースのソース評判情報を、顧客１０６が利用するさまざまな方法がある。一つの方法は、顧客システムが、ＴＣＰ接続を要求するＩＰアドレスに関する、ＤＮＳ型問い合わせをすることである。どのようにしてそのようなＤＮＳ型クエリが、顧客１０６により、システム１０４に実施できるかは、次に図１０のフローチャートを参照して述べられている。

ブロック１８０で始まり、顧客１０６はソースＩＰアドレスからＴＣＰ接続要求を受け取る。例えば、ソースＩＰアドレスは、電子メールメッセージを配信するために、顧客１０６とＳＭＴＰ接続を確立しようとしているかもしれない。顧客システム１０６は、接続要求に肯定応答する前に、ソース評判システム１０４にクエリを実行する。ある実施例では、ブロック１８２に示されているように、顧客システム１０６には、有効なキーで認証されたクエリを生成するためのＲＴＩＮクライアントを含む。

商業用加入向けに備えられたソース評判システム１０４は、加入の支払いをした人からのみ、ＲＴＩＮデータベース１１４にアクセスされることが望ましい。したがって、システム１０４は、ＲＴＩＮデータベース１１４に認証されたアクセスを提供することができ、それにより、ＲＴＩＮ顧客１０６から送信されたＤＮＳ型検索コマンドにセキュリティーキー（模範的アプローチの一つで）を組み込むことができる。ＲＴＩＮ検索コマンドの形式は、検索されたＩＰアドレスの先頭に追加された、ハッシュ化されたセキュリティーキーでも良い。よって、例えば、ハッシュ化されたセキュリティーキーは「４５４９２１４７」で、検索される特定のＩＰアドレスが１２７０００．０００．００１であるかもしれない。すると、完全なコマンドの形式は、「ＲＴＩＮ．４５４９２１４７．１２７．０００．０００．００１ＲＴＩＮ．ｐｏｓｔｉｎｉｃｏｒｐ．ｃｏｍ」になることがある。したがって、顧客１０６の一般的アプローチは、検索したいＩＰまたは「マシン」アドレスを取り、ハッシュ化されたＭＤ５セキュリティーキーをそのＩＰアドレスの先頭に追加し、ＲＴＩＮエンジン１０８にＤＮＳ型問い合わせを行うことである。ＲＴＩＮアクセスセキュリティキーは、定期的に失効させることができ、システムのセキュリティを増強する。模範的なアプローチとして、各キーは６０日間有効で、新しいものが３０日ごとに提供されるかもしれない、これにより、次のキーは３０日間オーバーラップする。キーは、コンピューター読み取り可能媒体を通しての配布、またはセキュアオンラインアクセスおよび認証を通してなどを含む、数々のアプローチを通して提供されることがある。特定の加入者が、加入者によって定期的に更新することができる、２年分のキーを持つなど、前もって複数組のキーを提供することができる。

次に、ブロック１８６で、顧客システム１０６がソース評判システム１０４へのアクセスを得られると、顧客システム１０６は、ＲＴＩＮエンジン１０８に、ソースＩＰアドレスに関する情報のクエリを実行する。そして、ブロック１８８で、ＲＴＩＮエンジン１０８は、認証されたクエリが実行された場合は、要求を認証し、ブロック１９０で、ＲＴＩＮエンジン１０８は、ＲＴＩＮデータベース１１４にソースＩＰアドレスに関する情報のクエリを実行する。ブロック１９２では、ＲＴＩＮデータベース１１４は、クエリ結果がある場合、ＲＴＩＮエンジンに結果を返す。そして、ブロック１９４では、ＲＴＩＮエンジン１０８は、顧客１０６にクエリ結果を提供する。

ある実施例では、ブロック１９４には、顧客設定データベース１１０に保存された顧客の嗜好に応じて、クエリ結果を処理することを含んでも良い。例えば、データベース１１０に保存されている顧客設定ファイルには、信頼できる、または既知の不良IPアドレスの一覧を含むことがある。このリストは、ＲＴＩＮデータベース１１４から受け取った情報を修正するため使用することができる。例えば、ＲＴＩＮデータベース１１４は、ソースＩＰアドレスが可能性あるスパムのソースで、ブロックされるべきであるという情報を含むが、顧客設定が、ソースIPアドレスを含むＩＰアドレスのブロックが、ブロックされてはならないという情報を含む場合、顧客の嗜好が優先し、ＲＴＩＮエンジン１０８は、ソースＩＰアドレスがブロックされてはならないものだと報告することができる。

最後に、ブロック１９６では、顧客１０６がクエリ結果を受け取る。この時点で、顧客システム１０６は、クエリ結果と顧客１０６ローカルポリシーに基づき、ソースＩＰアドレスからの接続要求に返答することができる。

上述のアクセスアプローチが、ＤＮＳ型アプローチとして示されているが、問い合わせは、標準ＤＮＳ問い合わせではない。ＤＮＳ問い合わせは、例えば、一般的にＤＮＳサーバのドメインネームの送信を伴うもので、次にＩＰアドレスを返す。ＲＴＩＮデータベースをアクセスするために使われる問い合わせは、逆に言えば、ＩＰアドレスそのもので、返されるのは、送信電子メールサーバとして、特定のＩＰアドレスの特性に関するＲＴＩＮデータベースによって知られている情報である。

ＲＴＩＮデータベース１１４のソース評判情報を、顧客１０６が利用するほかの方法は、システム１０４が顧客のルーターへ情報を直接提供するプロセスを伴う。ＲＴＩＮデータがどのように顧客ルーターに提供されるかを示すプロセスは、図１１−１３に関連してここで述べられる。このプロセスは、電子メールパケット／ルーターレベルにおいて適用するために、以前に識別された技術の上に築かれている。インターネット、および企業イントラネット全体のメッセージルーターは、数百万ものルーターを通し、パケット経路指定パスを集合的に開発し、最下位ＩＰアドレスからインターネットに送信されたメッセージは、意図された送信先を見つけることができ、トラフィック処理速度と、特定のルーターを通した伝播時間に適応し、また、「ダウン」している、またはそのときに利用不可能のルーターに適応する。このインターネットでのパケット経路指定スキームの適応性は、企業、教育および消費者ユーザーにとって、電子メッセージ配信の信頼ある手段として、インターネットにその多大な人気を与える要因の一つである。

インターネットルーターにおけるメッセージ経路指定パスを共有するための、標準プロトコルは、「Ｒｅｑｕｅｓｔ ｆｏｒ ｃｏｍｍｅｎｔ」（ＲＦＣ）により開発され、それによりインターネットコミュニティーは、その標準を規定する。数年にわたり開発されたプロトコルには、インターネットの初期に広く利用された、エクステリアゲートウェイプロトコル（ＥＧＰ）と優先インターネット搬送プロトコルとして、ＥＧＰを次第に置き換えているボーダゲートウェイプロトコル（ＢＧＰ）が含まれる。最新のＢＧＰは、ボーダゲートウェイプロトコル４（ＢＧＰ−４）で、ＲＦＣ１７７１に記載されている。

ＢＧＰを理解するためには、インターネットを自立システムの集まりとして考えると役立つ。例えば、インターネットの一部は、図１１に示される自立システム２００−２０４のグループとして、図示することがきる。各自立システム２００−２０４は、ボーダールーター２０６−２１０を利用して、一部のほかの自立システム２００−２０４と直接通信することができる。さらに、各自立システム２００−２０４は、直接接続されていないほかの自立システム２００−２０４と通信することができる。例えば、自立システム（ＡＳ−Ａ）２００は、輸送サービスとして自立システム（ＡＳ−Ｃ）２０２を使用して、自立システム（ＡＳ−Ｅ）と通信することができる。また、自立システム（ＡＳ−Ａ）２００は、輸送サービスとして自立システム（ＡＳ−Ｂ）２０１と（ＡＳ−Ｄ）２０３を使用して、自立システム（ＡＳ−Ｅ）２０４と通信することもできる。よって、自立システム（ＡＳ−Ａ）２００と（ＡＳ−Ｅ）２０４との通信を可能にするため、ルーターＲＡ２０６が選択できる複数のパスがある。図１１は、非常に簡略化された図をのみを提供することに注意すること、例えば、通信は、輸送サービスを提供する自立システムの内部ルーターを通じてリレーされる。

ルーターＲＡ２０６が、ルーターＲＥ２１０との通信を要求するには、最初にルーターＲＥ２１０へのパス、または複数パスを知らなくてはならない。ルーターＲＡ２０６は、ＢＧＰを使用して、ルーターＲＢ２０７および、ＲＣ２０８からの可能性あるパスを知ることができる。ＢＧＰは、ネットワーク到着可能性情報を交換するために、ルーター２０６−２１０など、ルーターによって使用されるプロトコルである。よって、図１１に示されている例では、ルーターＲＣ２０８は、ＡＳ−Ｅ２０４への理療可能なパスをＲＡ２０６に伝えるため、ＢＧＰを使用する、同様に、ルーターＲＢ２０６は、ＡＳ−Ｅ２０４への利用可能なパスを、ＡＳ−Ｄ２０３のルーターＲＤ２０９を経由して（ルーターＲＤ２０９が、ＡＳ−Ｅ２０４へのパスをルーターＲＢ２０７に伝えたと仮定して）、ＲＡ２０６に伝えるため、ＢＧＰを使用することができる。この経路決定情報の交換は、例えば、ルーターＲＡ２０６が、ルーターＲＢ２０７に最初に接続されるときなど、通常直接ネットワーク接続確立のはじめに起こる。ルーターＲＡ２０６は、ルーターＲＢ２０７から受け取った経路決定情報を、ＢＧＰ経路指定テーブルを作成するために使用する。ＢＧＰ経路指定テーブルは時間と共に、進路決定更新がルーターＲＢ２０７（ルーターＲＣ２０８など、他のルーターからと同様）から受け取られるにつれ、更新することができる。

図１に戻り、ＲＴＩＮエンジン１０８は、顧客システムの１０６ａおよび１０６ｂのルーター１０７ａおよび１０７ｂそれぞれと通信するよう設定することができる。各顧客システム１０６は、個別ルーター１０７と示されているが、顧客１０６ごとにいくつものルーター１０７を含むことができる。

図１２は、顧客ルーター１０７の一例を示すブロック図である。ルーター１０７は、進路決定テーブル２１２とピアリングテーブル２１４を含む。ＲＴＩＮエンジン１０８は、ＢＧＰプロトコルを使用して通信するように設定することができる。したがって、ピアリングテーブル２１４がピアとしてＲＴＩＮエンジン１０８を含むように適切に設定されると、ＲＴＩＮエンジン１０８は、ルーター１０７に、経路決定テーブル２１２を更新し、ＲＴＩＮデータベース１１４に保存された情報に従い、進路決定テーブル２１２に保存される進路決定データを提供するよう指示する。

したがって、ＲＴＩＮエンジン１０８のほかの機能は、顧客ルーター１０７に、特定のＩＰアドレスから、各顧客システム１０６に、コンタクトを取ることを効果的ブロックする接続データを提供できることである。ＲＴＩＮエンジン１０８は、データソース１０２にクエリ実行し、インターネット・トラフィックの集合的な図を形成する。ある実施例では、ＲＴＩＮエンジン１０８は、インターネット・トラフィックデータから収集された情報と、設定データベース１１０に保存された顧客優先と比較して、その比較に基づき、各顧客のシステム１０６でブロックされる、違反ＩＰアドレスの一覧を作成する。他の実施例においては、所定の閾値、または決定点を、ブロックされたＩＰアドレスリストを作成するために使用することができる。そしてＲＴＩＮエンジン１０８は、数々の個別（またはグループの）違反ＩＰアドレスの具体的知識があるルーターの「ふり」をする。ＲＴＩＮエンジン１０８は、ルーター１０７に更新コマンドを発行し、ＢＧＰを違反ＩＰアドレスのブラックホール経路決定情報を使用し、ルーター１０７へリレーする。そしてルーター１０７は、各経路決定テーブル２１２をＲＴＩＮエンジン１０８から受け取った新しいブラックホール経路決定情報に従い、更新する。

ＲＴＩＮエンジン１０８によって発行されたブラックホール経路決定情報は、経路決定テーブル２１２に、ブラックホール経路と共に以前保存された、違反ＩＰアドレスの既存の経路決定情報を置き換える。ブラックホール経路は、違反ＩＰアドレスに関連付けられたシステム以外の位置への経路である。ある実施例では、ブラックホール経路は、顧客１０６によって提供された大体の位置への経路で、設定データベース１１０に保存することができる。

ブラックホール経路によって、適正な経路を置き換えることの影響を、図１３を参照して説明する。図１３において、経路２２０は、ソースシステム２２２から配信先顧客システム１０６への適正な経路である。経路２２０は、いくつもの輸送サービスシステム２２６を通した、経路決定を含むことができる。

ソースシステム２２２と、配信先顧客システム１０６の間にＴＣＰ接続を確立するためには、二つのシステム２２２と１０６との間で、メッセージまたはパケットの交換が起きなくてはならない。ソースシステム２２２は、配信先システム１０６のＩＰアドレスに最初のパケットを送ることによって、配信先システム１０６とＴＣＰ接続確立の試みを開始することができる。最初のパケットが送信されると、ソースシステム２２２は、配信先システム１０６からの確認を待つ。初期パケットは、ルート２２０に沿って送信され、配信先システム２２４によって受信される。この初期パケットを受領すると、配信先システム２２４は、確認パケットを準備し、送信する。配信先システム１０６のルーターが、ソースシステム２２２に戻る適正な経路を知っていると仮定する、これはルート２２０と同じ、またはそうでないかもしれないが、確認は、ソースシステム２２２によって返信および受信され、ソースと配信先システム２２２と１０６の更なる通信を行うことができる。

一方、ＲＴＩＮエンジン１０８がソースシステム２２２を、違反システムと識別したとする。ある実施例では、これはソースシステム２２２が配信先システム１０６によって設定された基準を満たす一定の行動パターンを示したことを意味することができる。例えば、ＩＰアドレスまたは、ＩＰアドレスのブロックなどにより、ＲＴＩＮエンジン１０８がソースシステム２２２を識別した後、ＲＴＩＮエンジン１０８は、配信先システム１０６のルーターまたは複数ルーター１０７に、経路決定テーブル２１２を更新するように指示し、よって、システム２２２への適正経路がブラックホール経路２２８と置き換わる。そして、ソースシステム２２２が続けて、配信先１０６へＴＣＰ接続確立の試みを行うとき、接続の試みは失敗する。ソースシステム２２２は、配信先システム１０６のIPアドレスに宛てられた初期パケットを送信し、この初期パケットは、ソースシステム１５２から、適正ルート１５０を通じて、配信先システム１０６へ送付される。返答として、配信先システム１０６は、確認メッセージを準備し、発行する。しかしながら、配信先システムのルーター１０７が認識している、唯一のソースシステム２２２のＩＰアドレスへの経路がブラックホール経路であることから、ソースシステム２２２に確認メッセージは配信されない。かわりに、確認メッセージは、ブラックホールアドレス２３０に向けられる。一定の時間が経過した後、ソースシステム２２２によってなされたＴＣＰ接続の試みは、「タイムアウト」になり、ソースシステム２２２は、配信先システム１０６が、利用不能、さもなければ、到達不可能と判断する。ソースシステム２２２からの更なる通信は、これによって防がれる。

上述のように、ソース評判システムと組み合わせて、ブラックホーリング技術を使用することは、ソース評判システムは、対象に電子メール脅威の性格で迅速な識別を提供し、ルーターレベルにおいて、違反システムとの通信をブロックすることによって、その脅威が発生することを防ぐ。違反ＩＰアドレスは、従来のリアルタイムブラックリスト（ＲＢＬ）を形成し、しばし不正利用の対象になる、部分的で、非効果的な手動報告プロセスではなく、リアルタイムで観察、一覧される。ソース評判システムはまた、客観的で、その点で、メッセージ実行を完了すると、違反者を自動的に取り除く。今日多くのＲＢＬは、疑われる出来事のかなり後にＩＰアドレスをリストに残す。ソース評判システムを使用する解決策は、単純なはい／いいえプロセスよりも、むしろ確率的スコアに基づき脅威を評価し、パートナーが、階層化解析技術を使用し、電子メールを受け入れるかどうかの決定を可能にする。結果として、ソース評判システムはより少ない擬陽性をもたらし、それは、適正なＩＰアドレスを悪意があるとして、誤ってみなすときである。

ソース評判システムは、本書に述べられている概念に従い、内部アドレスを予測することにより、また、返信「メールボックスが見つかりません」メッセージが受信されていないというインスタンスをそこに登録することにより、スパマーが企業全体の電子メールディレクトリ「獲得」を試みる、ディレクトリ獲得攻撃に対する防御を可能にする。ソース評判システムは、標的システム全体を利用不可能、または「見つからない」ようにすることによって、そのような攻撃を無効にする。ＲＢＬは通常スパム配信に関与するＩＰアドレスを一覧する、またはスパム配信のリレーまたは通路としての役目をするのみである一方、ソース評判システムは、ディレクトリ獲得攻撃、および電子メールベースサービス拒否攻撃を実施しているものの知識を提供する。ソース評判システムは、ソースＩＰアドレスによって、ディレクトリ獲得攻撃とスパム攻撃を追跡し、関連付け、結果は憂慮すべきものである。ＤＨＡは、典型的電子メールサーバの受信ＳＭＴＰトラフィックと能力の４０％までを占め、通常スパム活動の有力な指標である。

本文に開示された原理に従うさまざまな実施例が上述される一方で、これらは、例の目的でのみ示されていて、制限でないことが理解されること。したがって、本発明の幅と範囲は、上述の模範的な実施例のいずれによっても制限されてはならず、しかし、本開示に由来するいずれの請求項及びその同等物にしたがってのみ、定義されること。さらに、上記の利点及び機能は、記載の実施例に規定されているが、そのような発行された請求項の適用を上記の利点のいずれの又は、全てを達成する工程及び構造に制限されない。

さらに、本文のセクション見出しは、３７ＣＦＲ１．７７の提案、又は別の方法で組織的な形式を規定するものと一貫性を保つよう規定されている。これらの見出しは、本開示に由来する、いかなる請求項に記されている発明を制限又は特徴付けてはならない。特に、また例の目的で、見出しは「技術分野」と言及しているが、いわゆる技術分野を説明するため、この見出しに基づき選択された言語によって制限されてはならない。さらに、「背景」での技術の説明は、技術が本開示におけるいかなる発明に対する従来技術であることの了解とみなされてはならない。また、「課題を解決するための手段」は、由来する請求項に記載された発明の特徴付けであると考慮されてはならない。さらに、本開示における単数の「発明」の言及は、本開示に単一の新規性しかないという論争に使用されてはならない。複数の発明が、本開示に由来する複数請求項の制限に従い記載することが出来、そのような請求項は、それに応じ、それによって保護される発明およびその同等物を定義する。全ての場合おいて、そのような請求項の範囲は、本開示の点から、それ自身の利益を考慮され、本文に記載された見出しによって、制約されてはならない。

ソース評判システムの一例を示す、ブロック図である。 ＲＴＩＮエンジンの最初の実施例を示すブロック図である。 ＲＴＩＮエンジンの２番目の実施例を示すブロック図である。 トラフィック監視システムの一実施例を示すブロック図である。 ツーストライクシステムの一実施例を示すブロック図である。 図５に示されている、ツーストライクシステムによって行われる、プロセスの一実施例を示すフローチャートである。 サドンデスシステムの一実施例を示すブロック図である。 図７に示されているサドンデスシステムによって行われる、プロセスの一実施例を示すフローチャートである。 図１に示されているソース評判システムによって行われるプロセスの一実施例を示す、フローチャートである。 図１に示されているソース評判システムにアクセスするプロセスの実施例を示す、フローチャートである。 インターネットの自治システムのグループを示すブロック図である。 顧客ルーターの一例を示すブロック図である。 図１に示されているソース評判システムと呼応する、ブラックホーリング技術を使用するトラフィックの流れの一例を示す、ブロック図である。

Claims (29)

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. 前記評判プロファイルを、外部システムに提供することは、フィルタリング方法を使用するために加入している顧客システムに、前記評判プロファイルを提供することからなることを特徴とする、請求項１７に記載のフィルタリング方法。