"通信ネットワークにおいて電子メールメッセージを認証する方法であって、表示されているユーザが前記電子メールメッセージを送ったかどうかを判断するための問合せを発信元サーバで受け取る工程と、前記電子メールメッセージが前記発信元サーバから送られたメッセージと一致するどうかを判断するために前記発信元サーバでログに記録したデータを検査する工程と、前記電子メールメッセージを認証するために前記問合せに応答する工程とを含む方法。この問題に対処する1つの手法は、あらゆるメッセージの証明およびデジタル署名であるが、これは高価であり複雑であるという理由で実装されてきていない。より重要なのは、どこにでも展開されるまでこれが相互運用可能でないことであるが、費用と複雑さのために、その広範な展開は非常に難しいものとなっている。セキュリティ、スパム防止、AAA、Radius、およびインターネットメッセージングプロトコルの分野に関する方法を対象とする本発明の原理により、従来技術にまさる利点がもたらされる。提案する発明により、発信元になりすまして電子メールスパムを作成すること、ウイルス配布、および他の電子メールの乱用の問題が解決される。特に、これにより、友人、同僚、および信頼できる機関から送られたものと称する電子メールによってコンピュータウイルスを配布する問題が解決される。提案する発明により、ある電子メールメッセージが、電子メールゲートウェイ、電子メールリレーサーバ、または宛先電子メールサーバで受け取られたときに、From:フィールドに指定された場所で発信され、またそこに指定される人またはプログラムが送ったことを無理なく保証する包括的な1組の機構および装置が定められる。本発明により、末端である電子メールメッセージの受信者までのリレーチェインにあるどの電子メールサーバすなわち、ゲートウェイ、リレー、または宛先サーバも、そのメッセージがFrom:フィールドに示される人またはプログラムが送ったかどうかが適切に確かめられることが保証される。本発明は、a発信元と称するサーバに問合せを直接送って、またはbLucentNavisRadiusサーバなどのAAAサーバを用いてこの機能を実行することによって動作する。この問合せに対する応答が否定的である場合は、そのメッセージは廃棄され、必要な場合には、適切なセキュリティログエントリが生成される。この機構は、それぞれが実装の簡単な、様々な方法で送信者と称する者だけでなくメッセージを認証する点で新しいものとなっている。また、この機構では、複雑なキー配布、暗号法などを利用する可能性のある電子署名などの証明書および他の複雑なセキュリティ機構の使用のための、これまでに提案されたしかし実装が難しいとわかった機構を回避している。この目的で、この機構では、PKIの高価な実装および外部のトラストセンタの証明書の組み込みを回避している。本発明の教示は以下の詳細な説明を添付の図面と併せ考慮することによって容易に理解することができる。本発明の例示的な一実施形態を、これから図面を参照しながら説明するが、そのうちのいくつかは、以下の説明を進めるあいだ、同時に参照することがある。提案する発明は単純であり、これにより、どのようなタイプのデジタル署名を含む暗号法、証明書、または公開鍵配布機構をも使用する費用および複雑さが省かれる。本発明により、末端である電子メールメッセージの受信者までのリレーチェインにあるどの電子メールサーバすなわち、ゲートウェイ、リレー、または宛先サーバも、そのメッセージがFrom:フィールドに示される人またはプログラムが送ったかどうかが適切に確かめられることが保証される。本発明は、a発信元と称するサーバに問合せを直接送って、またはbLucentNavisRadiusサーバなどのAAAサーバを用いてこの機能を実行することによって動作する。この問合せに対する応答が否定的である場合は、そのメッセージは廃棄され、必要な場合には、適切なセキュリティログエントリが生成される。この機構は、それぞれが実装の簡単な、様々な方法で送信者と称する者だけでなくメッセージを認証する点で新しいものとなっている。また、この機構では、複雑なキー配布、暗号法などを利用する可能性のある電子署名などの証明書および他の複雑なセキュリティ機構の使用のための、これまでに提案されたしかし実装が難しいとわかった機構を回避している。この目的で、この機構では、PKIの高価な実装および外部のトラストセンタの証明書の組み込みを回避している。図1に、本発明の説明に使用する典型的な電子メールのパスを示すネットワーク10の例示的な部分を示している。ここで、クライアント12はサーバ14を介してメッセージを送り、これはドメインゲートウェイ16および他のプロキシサーバ18を通過し、このそれぞれが、発信元サーバ14に始まって、RFC2821に記述されるSMTPSimpleMailTransferProtocolを使用している。メッセージが宛先サーバ20に着くと、メッセージは適当な受信者図示せずに送られる。発信元サーバ14、宛先サーバ20、プロキシサーバ18およびゲートウェイ16は、すべてRFC2821に定義するメール転送エージェントの役割を果たすことに注意されたい。図1を参照すると、本発明のある例示的な実施形態が次のようにして動作している。すなわち、1.発信元サーバ14は、発信側クライアント12から電子メールの転送の要求を受け取るときはいつでも、次のステップを実行する。すなわち、a.電子メールヘッダの中のFrom:フィールドがサーバ上のメールボックスを指しているかどうか検査する。そうである場合、その電子メールを転送する。そうでない場合、その電子メールを、たとえば、RFC2821に示される最終的な否定的完結応答apermanent,negativecompletionreplyによって拒絶する。b.この発明では、また、転送の成功した電子メールまたはおそらく、その一部、またはローカルに選択されたハッシングアルゴリズムによって決まるそのハッシュまでものログをとる。ログ中のそのエントリは、ある期間のあいだ維持されることになる通常、たとえば、10分間を超えない。2.本発明の例示的な一実施形態では、チェインにある他のどのサーバも下に述べる諸ステップを実行してよい。これらを、宛先サーバ20は実行しなければならない。これらのステップは当業者が理解するような数多くの代替方法で実行することができる。すなわち、a.オプション1:矢印のラベル1で示すメッセージ転送が始まり、SMTPのFrom:フィールドで渡されるそのメッセージの発信元と称するものが知られているときには、サーバ20が、2のラベルの付いた問合せを送ることによって、発信元サーバ14とのTCPセッションなどの短いセッション、またはこれに対するトランザクションを開始する。この問合せにより、1組のパラメータそのようなパラメータは、From:フィールド、時刻、長さ、件名の行、選択された内容、または、以上のすべてを含む、メッセージに固有のパラメータの他のどのような組を含んでもよいがこれに限定されなくてもよいのうちの1つまたは複数が識別する発信元からのメッセージoriginatingmessageが実際にそこに示すユーザによって送られたかどうかが問い合わせられる。以下では可能な問合せフォーマットを説明するここで構文はSMTPをモデルとしている。1つの問合せは、コマンドと、それに続く複数の引数からなる。すなわち、CONFIRM<Message-ID><message-specific-parameters>である。ここで、CONFIRMはコマンド名であり、<Message-ID>引数はそのメッセージのRFC822で指定される一意の識別子を含み、<message-specific-parameters>メッセージ固有のパラメータ引数は、メッセージ識別に使用することもできる、上に述べたパラメータのリストを含む。この問合せを受け取ると、発信元サーバは一意のMessage-IDを用いてそのログを検査して、問合せのMessage-IDで受信したメッセージが送られたかどうかを確認する。そうでない場合、対応するリプライが受信側サーバに送られる。この例示的な実施形態では、そのMessage-IDで識別されるメッセージのログがとられていた場合には、発信元サーバは、ログのとられたメッセージ中の情報と、問合せの<メッセージ固有のパラメータ>引数で受け取った情報とを比較することによって、そのメッセージの真正性authenticityに関する決定を下す能力があるはずである。この決定が、問合せに応答して送られることになる。問合せの例をCONFIRM<406C9526.2060307agere.com><From:abcagere.com>とする。この問合せを受け取ると、発信元サーバは、406C9526.2060307agere.comで参照されるメッセージを取り出し、abcがそのメッセージの送信者に関連付けられたエリアスのうちにあるかどうかを検査することができるはずである。送信者の識別子は、このメッセージが発信されたときに実行されたSMTPコマンドMAILFROM:<reverse-path>[RFC2821]に対する引数として与えられていたのだから、発信元サーバは情報をもっていたはずである。提案した問合せは、RFC822に記述されている一意のMessage-IDを有する圧倒的多数のメッセージに対して働くはずである。この標準ではMessage-IDフィールドを任意選択optionalとして指定しているが、ほとんどのSMTPサーバではこのフィールドがその電子メールメッセージに含められている。このフィールドが存在しない場合は、受信側サーバはローカルポリシに従って行動をとることができるたとえば、メッセージを打ち切るabort、受信者に警告を送る、など。b.問合せを受け取ると、発信元サーバ14はログ22を検査し、発信されたメッセージが表示されているユーザによって送られたかどうかに関する情報を有するメッセージ3で応答する。c.発信元サーバが肯定的に応答した場合、受信側宛先サーバ20は、その電子メールメッセージの処理および転送を続行する。そうでなかった場合、そのプロセスをただちに打ち切ることができる。打ち切りの結果は、メッセージは保存または転送されないということである。打ち切りは、さらに数多くの異なるやり方で行うことができる。たとえば、打ち切りを行う1つのやり方は、タイムアウトを課し、そうでなければ受信者が存在しませんなどのメッセージを作成し送信することである。さらにどのような攻撃も思いとどまらせるようにそのようなやり方で通信を停止する他のそのようなやり方も本明細書では考慮する。関係のあるどのようなサーバもまた、そのセキュリティポリシで決定されている適切なセキュリティログエントリを作成し、または適切な執行機関enforcementagencyへの通知など他のどのようなセキュリティ関連アクションも取ることができることが理解されよう。d.オプション2:別の代替実施形態では、宛先サーバ20は、適切なAAAAuthentication,Authorization,andAccounting、認証、認可、アカウンティングサーバ24にそのメッセージを認証しその受け取りメッセージ2’を認可してくれるように頼む。次いで、AAAサーバ24は、それ自体が発信元サーバ14とのやり取りを実行しメッセージ2’’および3’、適切な決定を下し、この決定をもって問い合わせてきたサーバに応答するメッセージ3’’。e.発信元サーバ14およびAAAサーバが肯定的に応答した場合、宛先サーバ20はその電子メールメッセージの処理および転送を続行する。そうでなかった場合、宛先サーバはそのプロセスをただちに打ち切る。関係のあるどのようなサーバもまた、そのセキュリティポリシで決定されている適切なセキュリティログエントリを作成し、他のどのようなセキュリティ関連アクションも取ることができる。AAAサーバが発信元サーバに一度問合せを行った後では、発信元サーバが宛先サーバに直接応答することもでき、または代替方法として、AAAが通信の応答フェーズだけに関係することもできることも、また理解されよう。図2に、本発明によるサーバ装置110の例示的な構成図を示している。一般に、この装置は、プロセッサ120とともに動作する、少なくとも2つの機能ブロックを含む。最初のブロック130は、すでに説明したように、受け取った送信を保存するログである。次のブロック140は、本発明の方法methodologiesを実行するために、たとえばソフトウェアの形の、命令を格納するための記憶装置である。ログはまたこの装置のためのメモリ全体の一部であってもよいことが理解されよう。サーバ装置は、また、入力および出力のポート150、160を含む。さらに、本発明の機能をサーバに関して説明しているが、本発明はプロキシ装置またはサーバに関連付けられた他の同様の装置にあってもよいことが理解されよう。説明の明瞭さのために、本発明のこの例示的な実施形態を個々の機能ブロックおよび/またはボックスを含むものとして説明してきた。こうしたブロックおよび/またはボックスが表す機能は、ソフトウェアを実行可能なハードウェアを含んでもよいがこれに限定されなくてもよい、共用または専用のハードウェアの使用によって享受することができる。プロセッサという用語の使用はソフトウェアを実行可能なハードウェアをもっぱら指すものと解釈すべきではない。さらに、この例示的な実施形態は、DSPdigitalsignalprocessor、デジタル信号プロセッサハードウェア、以下で論じる動作を実行するソフトウェアを格納するためのROMread-onlymemory、読み出し専用メモリ、およびDSPの結果を格納するためのRAMrandomaccessmemory、ランダムアクセスメモリを含むことができる。VLSIverylargescaleintegration、超大規模集積回路ハードウェア実装形態、ならびに、汎用DSP回路と組み合わせたカスタムVLSI回路もまた設けることができる。この発明を、好ましい一実施形態の状況で詳細に示し説明してきたが、変形形態および修正形態が、本明細書に添付の特許請求の範囲の範囲のみが限定すべきこの発明の広範な原理および趣旨から逸脱することなく可能であることは、当業者に明らかであろう。上の説明はこの発明の諸原理を示すものに過ぎない。したがって、明示的に本明細書で説明しまたは示していないが、この発明の諸原理を実施し、その趣旨および範囲に含まれる様々な配置arrangementを考案することが当業者には可能であることが理解されよう。さらに、ここに述べたすべての例および条件的な用語法languageはもっぱら、読者がこの発明の諸原理および当該技術を進めるために発明者が寄与する諸概念を理解するのを助けるのに有益な目的のみを明確に意図しており、そのような特に述べた例および条件への限定のないものとして理解すべきである。しかも、この発明の原理、態様、および実施形態を述べる本明細書中のすべての申し立て、ならびにこの発明の特定の例は、この発明の構造的と機能的の均等物をともに包含するものとする。さらに、そのような均等物は、現在知られる均等物と将来開発される均等物、すなわち、構造に関わらず同じ機能を果たすどのような開発された要素も含むものとする。本明細書の特許請求の範囲では、特定の機能を果たす手段として表現したどのような要素も、たとえば、aその機能を果たす回路要素の組み合わせ、またはbその機能を果たすようにそのソフトウェアを実行する適切な回路と組み合わせた、どのような形式の、したがって、ファームウェア、マイクロコードまたはその他も含めたソフトウェアを含む、その機能を果たすどのようなやり方も包含するものとする。そのような特許請求の範囲が定義する発明は、ここに述べた様々な手段の提供する機能が、特許請求の範囲が要求するように組み合わせ一緒にされているという事実の中にある。したがって本出願人は、その機能を提供できるどのような手段も本明細書に示すものと均等であると見なす。この発明の諸原理の他の多くの修正および適用は当業者に明らかであろうし、また本明細書の教示の企図するところである。したがって、この発明の範囲を限定するものは特許請求の範囲のみである。"