JP2005259141A - 通信ネットワーク内の電子メール・スパムおよびウイルスの配布を電子メール・メッセージの発信元の認証によって低減する方法および装置 - Google Patents

Abstract

【課題】 通信ネットワーク内の電子メール・スパムおよびウイルスの配布を電子メール・メッセージの発信元の認証によって低減する方法および装置を提供する。
【解決手段】 本願発明は、代表的には通信ネットワークにおいて電子メール・メッセージを認証する方法であって、表示されているユーザが電子メール・メッセージを送ったかどうかを判断するための問合せを発信元サーバで受け取る工程と、電子メール・メッセージが発信元サーバから送られたメッセージと一致するどうかを判断するために発信元サーバでログに記録したデータを検査する工程と、電子メール・メッセージを認証するために問合せに応答する工程とを含む。
【選択図】 図１

Description

本発明は、一般には電気通信の分野に関し、詳細にはインターネット・メッセージのセキュリティに関する。

インターネットの急激な発展とともに、電子メール・システムの乱用がますます問題となっている。こうした乱用は、発信元になりすまして（ｓｐｏｏｆｉｎｇ）（たとえば、ある発信元を特定の受理可能な発信元のように見せかけるように欺きまたは試みること）電子メール・スパムを作成すること、ウイルスの配布、および電子メールの他の乱用を含んでいる。特に、よく知られた危険な問題は、友人、同僚、および信用ある機関から送られたものと称する電子メールによるコンピュータ・ウイルスの配布である。

今日まで、上記の問題に効率的に取り組む解決策はないものの、既存のインターネット標準では、電子メールの送信者と称するものが電子メールの「Ｆｒｏｍ：」フィールドに示されたドメインに存在するかどうかを検査するオプションが提供されている。しかしながら、このオプションは、まれにしか使用されておらず、これはおそらく、現在の加害者は自分の自由にできる正当なアドレスを現に有しており、したがって、アドレスが有効であるかの検査だけでは不十分であるためである。

既存の電子メール標準（ＲＦＣ ２８２１）およびソフトウェアにより、だれでもＦｒｏｍフィールドにどのような発信元が示される電子メール・メッセージでも送ることができるようになっている。この機能（あるいはむしろ脆弱性）を、広告主は利用して電子メール・スパムを生成する。より邪悪な、いまやますます広がっている利用は、受信者にその友人および同僚に見えるものから送られるメッセージでコンピュータ・ウイルスを配布することである。

既存の電子メール標準によって送信者を確認（ｖｅｒｉｆｙ）できはするが、この機能は、そのアドレスが存在するドメインにおいて正しい（すなわち、存在する）ことを確認するのに過ぎない。この機能は、この特定のメッセージが特定のアドレスから送られていることを確認はしない。多くのメール・サーバでは、まさに役に立たなくなっているためにこの機能は無視されている。たとえば、インターネット上にリストされている大量の有効な電子メール・アドレス、様々な電子メール・リスト上にアーカイブされたやり取り、および（侵入されたコンピュータのアドレス帳にある情報などの）他の情報源により、スパム・メール発信者（ｓｐａｍｍｅｒ）または犯罪の実行者は使うのに十分な数のアドレスを得ている。さらに、検索エンジンが、潜在的な標的となる通信相手のリストを入手する助けになっており、この攻撃はより集中したものとなっている。

「ＲＦＣ ２８２１」、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２８２１．ｔｘｔ？ｎｕｍｂｅｒ＝２８２１＞ 「ＲＦＣ ８２２」、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ０８２２．ｔｘｔ？ｎｕｍｂｅｒ＝８２２＞

この問題に対処する１つの手法は、あらゆるメッセージの証明およびデジタル署名であるが、これは高価であり複雑であるという理由で実装されてきていない。より重要なのは、どこにでも展開されるまでこれが相互運用可能でないことであるが、費用と複雑さのために、その広範な展開は非常に難しいものとなっている。

セキュリティ、スパム防止、ＡＡＡ、Ｒａｄｉｕｓ、およびインターネット・メッセージング・プロトコルの分野に関する方法を対象とする本発明の原理により、従来技術にまさる利点がもたらされる。提案する発明により、発信元になりすまして電子メール・スパムを作成すること、ウイルス配布、および他の電子メールの乱用の問題が解決される。特に、これにより、友人、同僚、および信頼できる機関から送られたものと称する電子メールによってコンピュータ・ウイルスを配布する問題が解決される。

提案する発明により、ある電子メール・メッセージが、電子メール・ゲートウェイ、電子メール・リレー・サーバ、または宛先電子メール・サーバで受け取られたときに、「Ｆｒｏｍ：」フィールドに指定された場所で発信され、またそこに指定される人（またはプログラム）が送ったことを無理なく保証する包括的な１組の機構および装置が定められる。

本発明により、末端である電子メール・メッセージの受信者までのリレー・チェインにあるどの電子メール・サーバ（すなわち、ゲートウェイ、リレー、または宛先サーバ）も、そのメッセージがＦｒｏｍ：フィールドに示される人（またはプログラム）が送ったかどうかが適切に確かめられることが保証される。

本発明は、ａ）発信元と称するサーバに問合せを直接送って、またはｂ）（Ｌｕｃｅｎｔ Ｎａｖｉｓ Ｒａｄｉｕｓサーバなどの）ＡＡＡサーバを用いてこの機能を実行することによって動作する。この問合せに対する応答が否定的である場合は、そのメッセージは廃棄され、必要な場合には、適切なセキュリティ・ログ・エントリが生成される。

この機構は、それぞれが実装の簡単な、様々な方法で（送信者と称する者だけでなく）メッセージを認証する点で新しいものとなっている。また、この機構では、複雑なキー配布、暗号法などを利用する可能性のある（電子署名などの）証明書および他の複雑なセキュリティ機構の使用のための、これまでに提案された（しかし実装が難しいとわかった）機構を回避している。この目的で、この機構では、ＰＫＩの高価な実装および外部のトラスト・センタの証明書の組み込みを回避している。

本発明の教示は以下の詳細な説明を添付の図面と併せ考慮することによって容易に理解することができる。

本発明の例示的な一実施形態を、これから図面を参照しながら説明するが、そのうちのいくつかは、以下の説明を進めるあいだ、同時に参照することがある。

提案する発明は単純であり、これにより、どのようなタイプの（デジタル署名を含む）暗号法、証明書、または公開鍵配布機構をも使用する費用および複雑さが省かれる。

本発明により、末端である電子メール・メッセージの受信者までのリレー・チェインにあるどの電子メール・サーバ（すなわち、ゲートウェイ、リレー、または宛先サーバ）も、そのメッセージがＦｒｏｍ：フィールドに示される人（またはプログラム）が送ったかどうかが適切に確かめられることが保証される。

本発明は、ａ）発信元と称するサーバに問合せを直接送って、またはｂ）（Ｌｕｃｅｎｔ Ｎａｖｉｓ Ｒａｄｉｕｓサーバなどの）ＡＡＡサーバを用いてこの機能を実行することによって動作する。この問合せに対する応答が否定的である場合は、そのメッセージは廃棄され、必要な場合には、適切なセキュリティ・ログ・エントリが生成される。

この機構は、それぞれが実装の簡単な、様々な方法で（送信者と称する者だけでなく）メッセージを認証する点で新しいものとなっている。また、この機構では、複雑なキー配布、暗号法などを利用する可能性のある（電子署名などの）証明書および他の複雑なセキュリティ機構の使用のための、これまでに提案された（しかし実装が難しいとわかった）機構を回避している。この目的で、この機構では、ＰＫＩの高価な実装および外部のトラスト・センタの証明書の組み込みを回避している。

図１に、本発明の説明に使用する典型的な電子メールのパスを示すネットワーク１０の例示的な部分を示している。ここで、クライアント１２はサーバ１４を介してメッセージを送り、これはドメイン・ゲートウェイ１６および他のプロキシ・サーバ１８を通過し、このそれぞれが、発信元サーバ１４に始まって、ＲＦＣ ２８２１に記述されるＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を使用している。メッセージが宛先サーバ２０に着くと、メッセージは適当な受信者（図示せず）に送られる。発信元サーバ１４、宛先サーバ２０、プロキシ・サーバ１８およびゲートウェイ１６は、すべてＲＦＣ ２８２１に定義するメール転送エージェントの役割を果たすことに注意されたい。

図１を参照すると、本発明のある例示的な実施形態が次のようにして動作している。すなわち、
１．発信元サーバ１４は、発信側クライアント１２から電子メールの転送の要求を受け取るときはいつでも、次のステップを実行する。すなわち、
ａ．電子メール・ヘッダの中のＦｒｏｍ：フィールドがサーバ上のメールボックスを指しているかどうか検査する。そうである場合、その電子メールを転送する。そうでない場合、その電子メールを、たとえば、ＲＦＣ ２８２１に示される最終的な否定的完結応答（ａ ｐｅｒｍａｎｅｎｔ， ｎｅｇａｔｉｖｅ ｃｏｍｐｌｅｔｉｏｎ ｒｅｐｌｙ）によって拒絶する。
ｂ．この発明では、また、転送の成功した電子メール（またはおそらく、その一部、またはローカルに選択されたハッシング・アルゴリズムによって決まるそのハッシュまでも）のログをとる。ログ中のそのエントリは、ある期間のあいだ維持されることになる（通常、たとえば、１０分間を超えない）。

２．本発明の例示的な一実施形態では、チェインにある他のどのサーバも下に述べる諸ステップを実行してよい。これらを、宛先サーバ２０は実行しなければならない。これらのステップは当業者が理解するような数多くの代替方法で実行することができる。すなわち、
ａ．（オプション１）：（矢印のラベル（１）で示す）メッセージ転送が始まり、（ＳＭＴＰのＦｒｏｍ：フィールドで渡される）そのメッセージの発信元と称するものが知られているときには、サーバ２０が、（２）のラベルの付いた問合せを送ることによって、発信元サーバ１４との（ＴＣＰセッションなどの）短いセッション、またはこれに対するトランザクションを開始する。この問合せにより、１組のパラメータ（そのようなパラメータは、Ｆｒｏｍ：フィールド、時刻、長さ、件名の行、選択された内容、または、以上のすべてを含む、メッセージに固有のパラメータの他のどのような組を含んでもよいがこれに限定されなくてもよい）のうちの１つまたは複数が識別する発信元からのメッセージ（ｏｒｉｇｉｎａｔｉｎｇ ｍｅｓｓａｇｅ）が実際にそこに示すユーザによって送られたかどうかが問い合わせられる。以下では可能な問合せフォーマットを説明する（ここで構文はＳＭＴＰをモデルとしている）。１つの問合せは、コマンドと、それに続く複数の引数からなる。すなわち、ＣＯＮＦＩＲＭ＜Ｍｅｓｓａｇｅ−ＩＤ＞＜ｍｅｓｓａｇｅ−ｓｐｅｃｉｆｉｃ−ｐａｒａｍｅｔｅｒｓ＞である。ここで、ＣＯＮＦＩＲＭはコマンド名であり、＜Ｍｅｓｓａｇｅ−ＩＤ＞引数はそのメッセージの（ＲＦＣ ８２２で指定される）一意の識別子を含み、＜ｍｅｓｓａｇｅ−ｓｐｅｃｉｆｉｃ−ｐａｒａｍｅｔｅｒｓ＞（メッセージ固有のパラメータ）引数は、メッセージ識別に使用することもできる、上に述べたパラメータのリストを含む。この問合せを受け取ると、発信元サーバは一意のＭｅｓｓａｇｅ−ＩＤを用いてそのログを検査して、問合せのＭｅｓｓａｇｅ−ＩＤで受信したメッセージが送られたかどうかを確認する。そうでない場合、対応するリプライが受信側サーバに送られる。この例示的な実施形態では、そのＭｅｓｓａｇｅ−ＩＤで識別されるメッセージのログがとられていた場合には、発信元サーバは、ログのとられたメッセージ中の情報と、問合せの＜メッセージ固有のパラメータ＞引数で受け取った情報とを比較することによって、そのメッセージの真正性（ａｕｔｈｅｎｔｉｃｉｔｙ）に関する決定を下す能力があるはずである。この決定が、問合せに応答して送られることになる。
問合せの例をＣＯＮＦＩＲＭ＜４０６Ｃ９５２６．２０６０３０７＠ａｇｅｒｅ．ｃｏｍ＞＜Ｆｒｏｍ：ａｂｃ＠ａｇｅｒｅ．ｃｏｍ＞とする。この問合せを受け取ると、発信元サーバは、４０６Ｃ９５２６．２０６０３０７＠ａｇｅｒｅ．ｃｏｍで参照されるメッセージを取り出し、「ａｂｃ」がそのメッセージの送信者に関連付けられたエリアスのうちにあるかどうかを検査することができるはずである。送信者の識別子は、このメッセージが発信されたときに実行されたＳＭＴＰコマンドＭＡＩＬ ＦＲＯＭ：＜ｒｅｖｅｒｓｅ−ｐａｔｈ＞［ＲＦＣ２８２１］に対する引数として与えられていたのだから、発信元サーバは情報をもっていたはずである。
提案した問合せは、ＲＦＣ ８２２に記述されている一意のＭｅｓｓａｇｅ−ＩＤを有する圧倒的多数のメッセージに対して働くはずである。この標準ではＭｅｓｓａｇｅ−ＩＤフィールドを任意選択（ｏｐｔｉｏｎａｌ）として指定しているが、ほとんどのＳＭＴＰサーバではこのフィールドがその電子メール・メッセージに含められている。このフィールドが存在しない場合は、受信側サーバはローカル・ポリシに従って行動をとることができる（たとえば、メッセージを打ち切る（ａｂｏｒｔ）、受信者に警告を送る、など）。
ｂ．問合せを受け取ると、発信元サーバ１４はログ２２を検査し、発信されたメッセージが表示されているユーザによって送られたかどうかに関する情報を有するメッセージ（３）で応答する。
ｃ．発信元サーバが肯定的に応答した場合、受信側（宛先）サーバ２０は、その電子メール・メッセージの処理および転送を続行する。そうでなかった場合、そのプロセスをただちに打ち切ることができる。打ち切りの結果は、メッセージは保存または転送されないということである。打ち切りは、さらに数多くの異なるやり方で行うことができる。たとえば、打ち切りを行う１つのやり方は、タイムアウトを課し、そうでなければ「受信者が存在しません」などのメッセージを作成し送信することである。さらにどのような攻撃も思いとどまらせるようにそのようなやり方で通信を停止する他のそのようなやり方も本明細書では考慮する。関係のあるどのようなサーバもまた、そのセキュリティ・ポリシで決定されている適切なセキュリティ・ログ・エントリを作成し、または適切な執行機関（ｅｎｆｏｒｃｅｍｅｎｔ ａｇｅｎｃｙ）への通知など他のどのようなセキュリティ関連アクションも取ることができることが理解されよう。
ｄ．（オプション２）：別の代替実施形態では、宛先サーバ２０は、適切なＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ，Ａｕｔｈｏｒｉｚａｔｉｏｎ，ａｎｄ Ａｃｃｏｕｎｔｉｎｇ、認証、認可、アカウンティング）サーバ２４にそのメッセージを認証しその受け取り（メッセージ２’）を認可してくれるように頼む。次いで、ＡＡＡサーバ２４は、それ自体が発信元サーバ１４とのやり取りを実行し（メッセージ２’’および３’）、適切な決定を下し、この決定をもって問い合わせてきたサーバに応答する（メッセージ３’’）。
ｅ．発信元サーバ１４（およびＡＡＡサーバ）が肯定的に応答した場合、宛先サーバ２０はその電子メール・メッセージの処理および転送を続行する。そうでなかった場合、宛先サーバはそのプロセスをただちに打ち切る。関係のあるどのようなサーバもまた、そのセキュリティ・ポリシで決定されている適切なセキュリティ・ログ・エントリを作成し、他のどのようなセキュリティ関連アクションも取ることができる。ＡＡＡサーバが発信元サーバに一度問合せを行った後では、発信元サーバが宛先サーバに直接応答することもでき、または代替方法として、ＡＡＡが通信の応答フェーズだけに関係することもできることも、また理解されよう。

図２に、本発明によるサーバ装置１１０の例示的な構成図を示している。一般に、この装置は、プロセッサ１２０とともに動作する、少なくとも２つの機能ブロックを含む。最初のブロック１３０は、すでに説明したように、受け取った送信を保存するログである。次のブロック１４０は、本発明の方法（ｍｅｔｈｏｄｏｌｏｇｉｅｓ）を実行するために、たとえばソフトウェアの形の、命令を格納するための記憶装置である。ログはまたこの装置のためのメモリ全体の一部であってもよいことが理解されよう。サーバ装置は、また、入力および出力のポート１５０、１６０を含む。さらに、本発明の機能をサーバに関して説明しているが、本発明はプロキシ装置またはサーバに関連付けられた他の同様の装置にあってもよいことが理解されよう。

説明の明瞭さのために、本発明のこの例示的な実施形態を個々の機能ブロックおよび／またはボックスを含むものとして説明してきた。こうしたブロックおよび／またはボックスが表す機能は、ソフトウェアを実行可能なハードウェアを含んでもよいがこれに限定されなくてもよい、共用または専用のハードウェアの使用によって享受することができる。「プロセッサ」という用語の使用はソフトウェアを実行可能なハードウェアをもっぱら指すものと解釈すべきではない。さらに、この例示的な実施形態は、ＤＳＰ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ、デジタル信号プロセッサ）ハードウェア、以下で論じる動作を実行するソフトウェアを格納するためのＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ、読み出し専用メモリ）、およびＤＳＰの結果を格納するためのＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ランダム・アクセス・メモリ）を含むことができる。ＶＬＳＩ（ｖｅｒｙ ｌａｒｇｅ ｓｃａｌｅ ｉｎｔｅｇｒａｔｉｏｎ、超大規模集積回路）ハードウェア実装形態、ならびに、汎用ＤＳＰ回路と組み合わせたカスタムＶＬＳＩ回路もまた設けることができる。

この発明を、好ましい一実施形態の状況で詳細に示し説明してきたが、変形形態および修正形態が、本明細書に添付の特許請求の範囲の範囲のみが限定すべきこの発明の広範な原理および趣旨から逸脱することなく可能であることは、当業者に明らかであろう。

上の説明はこの発明の諸原理を示すものに過ぎない。したがって、明示的に本明細書で説明しまたは示していないが、この発明の諸原理を実施し、その趣旨および範囲に含まれる様々な配置（ａｒｒａｎｇｅｍｅｎｔ）を考案することが当業者には可能であることが理解されよう。さらに、ここに述べたすべての例および条件的な用語法（ｌａｎｇｕａｇｅ）はもっぱら、読者がこの発明の諸原理および当該技術を進めるために発明者が寄与する諸概念を理解するのを助けるのに有益な目的のみを明確に意図しており、そのような特に述べた例および条件への限定のないものとして理解すべきである。しかも、この発明の原理、態様、および実施形態を述べる本明細書中のすべての申し立て、ならびにこの発明の特定の例は、この発明の構造的と機能的の均等物をともに包含するものとする。さらに、そのような均等物は、現在知られる均等物と将来開発される均等物、すなわち、構造に関わらず同じ機能を果たすどのような開発された要素も含むものとする。

本明細書の特許請求の範囲では、特定の機能を果たす手段として表現したどのような要素も、たとえば、ａ）その機能を果たす回路要素の組み合わせ、またはｂ）その機能を果たすようにそのソフトウェアを実行する適切な回路と組み合わせた、どのような形式の、したがって、ファームウェア、マイクロコードまたはその他も含めたソフトウェアを含む、その機能を果たすどのようなやり方も包含するものとする。そのような特許請求の範囲が定義する発明は、ここに述べた様々な手段の提供する機能が、特許請求の範囲が要求するように組み合わせ一緒にされているという事実の中にある。したがって本出願人は、その機能を提供できるどのような手段も本明細書に示すものと均等であると見なす。この発明の諸原理の他の多くの修正および適用は当業者に明らかであろうし、また本明細書の教示の企図するところである。したがって、この発明の範囲を限定するものは特許請求の範囲のみである。

本発明の方法の実施に使用する諸要素を簡略化した構成図の形で示す図である。 本発明によるサーバ装置の例示的な構成図である。

Claims (10)

1. 通信ネットワークにおいて電子メール・メッセージを認証する方法であって、
   表示されているユーザが前記電子メール・メッセージを送ったかどうかを判断するための問合せを発信元サーバで受け取る工程と、
   前記電子メール・メッセージが前記発信元サーバから送られたメッセージと一致するどうかを判断するために前記発信元サーバでログに記録したデータを検査する工程と、
   前記電子メール・メッセージを認証するために前記問合せに応答する工程とを含む方法。
2. 発信元サーバが電子メールを転送する要求を受け取ったときに、電子メール・メッセージ・ヘッダ内の「Ｆｒｏｍ」フィールドが前記発信元サーバの処理するメールボックスと一致するかどうかを検査する工程と、
   前記電子メール・メッセージの前記発信元サーバとの一致が成功する場合、前記電子メール・メッセージを識別するデータをログに記録する工程とをさらに含むことを特徴とする請求項１に記載の方法。
3. 前記問合せを宛先サーバから受け取ることを特徴とする請求項１に記載の方法。
4. 前記問合せを認証サーバから受け取ることを特徴とする請求項１に記載の方法。
5. 発信元からのメッセージの識別を、Ｆｒｏｍ：フィールド、時刻、長さ、件名の行、選択された内容、およびメッセージ固有のパラメータからなる群から選択された１組のパラメータのうちの１つまたは複数によって行うことを特徴とする請求項１に記載の方法。
6. 通信ネットワークにおいて宛先サーバで電子メール・メッセージを認証する方法であって、発信元サーバが、電子メールを転送する要求を受け取ったときに、電子メール・メッセージ・ヘッダ内の「Ｆｒｏｍ」フィールドが前記発信元サーバの処理するメールボックスと一致するかどうかを検査し、前記電子メール・メッセージの前記発信元サーバとの一致が成功する場合、前記電子メール・メッセージを識別するデータをログに記録し、前記方法が、
   表示されているユーザが前記電子メール・メッセージを送ったかどうかを判断するための問合せを送る工程と、
   前記メッセージが認証されたかどうかを判断するために前記問合せに対する応答を受け取る工程であって、前記応答が前記電子メール・メッセージが前記ログに記録したデータおよび前記発信元サーバに一致するかどうかに関する情報を含む工程とを含む方法。
7. 通信ネットワークにおいて電子メール・メッセージを認証する方法であって、
   発信元サーバが電子メールを転送する要求を受け取ったときに、電子メール・メッセージ・ヘッダ内の「Ｆｒｏｍ」フィールドが前記発信元サーバの処理するメールボックスと一致するかどうかを検査する工程と、
   前記電子メール・メッセージの前記発信元サーバとの一致が成功する場合、前記電子メール・メッセージを識別するデータをログに記録する工程と、
   表示されているユーザが前記電子メール・メッセージを送ったかどうかを判断するための問合せを宛先サーバから送る工程と、
   前記電子メール・メッセージが前記発信元サーバから送られたメッセージと一致するどうかを判断するために前記発信元サーバでログに記録したデータを検査する工程と、
   前記電子メール・メッセージを認証するために前記問合せに応答する工程と
   前記応答を前記宛先サーバで受け取る工程とを含む方法。
8. 通信ネットワークにおいて電子メール・メッセージを認証する装置であって、
   表示されているユーザが前記電子メール・メッセージを送ったかどうかを判断するための問合せを発信元サーバで受け取る手段と、
   前記電子メール・メッセージが前記発信元サーバから送られたメッセージと一致するどうかを判断するために前記発信元サーバでログに記録したデータを検査する手段と、
   前記電子メール・メッセージを認証するために前記問合せに応答する手段とを含む装置。
9. 発信元サーバが電子メールを転送する要求を受け取ったときに、電子メール・メッセージ・ヘッダ内の「Ｆｒｏｍ」フィールドが前記発信元サーバの処理するメールボックスと一致するかどうかを検査する手段と、
   前記電子メール・メッセージの前記発信元サーバとの一致が成功する場合、前記電子メール・メッセージを識別するデータをログに記録する手段とをさらに含む、請求項８に記載の装置。
10. 通信ネットワークにおいて宛先サーバで電子メール・メッセージを認証する装置であって、発信元サーバが、電子メールを転送する要求を受け取ったときに、電子メール・メッセージ・ヘッダ内の「Ｆｒｏｍ」フィールドが前記発信元サーバの処理するメールボックスと一致するかどうかを検査し、前記電子メール・メッセージの前記発信元サーバとの一致が成功する場合、前記電子メール・メッセージを識別するデータをログに記録し、前記装置が、
    表示されているユーザが前記電子メール・メッセージを送ったかどうかを判断するための問合せを送る手段と、
    前記メッセージが認証されたかどうかを判断するために前記問合せに対する応答を受け取る手段であって、前記応答が前記電子メール・メッセージが前記ログに記録したデータおよび前記発信元サーバに一致するかどうかに関する情報を含む手段とを含む装置。
    

Images