通信ネットワーク内の電子メール・スパムおよびウイルスの配布を電子メール・メッセージの発信元の認証によって低減する方法および装置
【課題】通信ネットワーク内の電子メール・スパムおよびウイルスの配布を電子メール・メッセージの発信元の認証によって低減する方法および装置を提供する。
【解決手段】本願発明は、代表的には通信ネットワークにおいて電子メール・メッセージを認証する方法であって、表示されているユーザが電子メール・メッセージを送ったかどうかを判断するための問合せを発信元サーバで受け取る工程と、電子メール・メッセージが発信元サーバから送られたメッセージと一致するどうかを判断するために発信元サーバでログに記録したデータを検査する工程と、電子メール・メッセージを認証するために問合せに応答する工程とを含む。
【解決手段】本願発明は、代表的には通信ネットワークにおいて電子メール・メッセージを認証する方法であって、表示されているユーザが電子メール・メッセージを送ったかどうかを判断するための問合せを発信元サーバで受け取る工程と、電子メール・メッセージが発信元サーバから送られたメッセージと一致するどうかを判断するために発信元サーバでログに記録したデータを検査する工程と、電子メール・メッセージを認証するために問合せに応答する工程とを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般には電気通信の分野に関し、詳細にはインターネット・メッセージのセキュリティに関する。
【背景技術】
【０００２】
インターネットの急激な発展とともに、電子メール・システムの乱用がますます問題となっている。こうした乱用は、発信元になりすまして（ｓｐｏｏｆｉｎｇ）（たとえば、ある発信元を特定の受理可能な発信元のように見せかけるように欺きまたは試みること）電子メール・スパムを作成すること、ウイルスの配布、および電子メールの他の乱用を含んでいる。特に、よく知られた危険な問題は、友人、同僚、および信用ある機関から送られたものと称する電子メールによるコンピュータ・ウイルスの配布である。
【０００３】
今日まで、上記の問題に効率的に取り組む解決策はないものの、既存のインターネット標準では、電子メールの送信者と称するものが電子メールの「Ｆｒｏｍ：」フィールドに示されたドメインに存在するかどうかを検査するオプションが提供されている。しかしながら、このオプションは、まれにしか使用されておらず、これはおそらく、現在の加害者は自分の自由にできる正当なアドレスを現に有しており、したがって、アドレスが有効であるかの検査だけでは不十分であるためである。
【０００４】
既存の電子メール標準（ＲＦＣ ２８２１）およびソフトウェアにより、だれでもＦｒｏｍフィールドにどのような発信元が示される電子メール・メッセージでも送ることができるようになっている。この機能（あるいはむしろ脆弱性）を、広告主は利用して電子メール・スパムを生成する。より邪悪な、いまやますます広がっている利用は、受信者にその友人および同僚に見えるものから送られるメッセージでコンピュータ・ウイルスを配布することである。
【０００５】
既存の電子メール標準によって送信者を確認（ｖｅｒｉｆｙ）できはするが、この機能は、そのアドレスが存在するドメインにおいて正しい（すなわち、存在する）ことを確認するのに過ぎない。この機能は、この特定のメッセージが特定のアドレスから送られていることを確認はしない。多くのメール・サーバでは、まさに役に立たなくなっているためにこの機能は無視されている。たとえば、インターネット上にリストされている大量の有効な電子メール・アドレス、様々な電子メール・リスト上にアーカイブされたやり取り、および（侵入されたコンピュータのアドレス帳にある情報などの）他の情報源により、スパム・メール発信者（ｓｐａｍｍｅｒ）または犯罪の実行者は使うのに十分な数のアドレスを得ている。さらに、検索エンジンが、潜在的な標的となる通信相手のリストを入手する助けになっており、この攻撃はより集中したものとなっている。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】「ＲＦＣ ２８２１」、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２８２１．ｔｘｔ？ｎｕｍｂｅｒ＝２８２１＞
【非特許文献２】「ＲＦＣ ８２２」、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ０８２２．ｔｘｔ？ｎｕｍｂｅｒ＝８２２＞
【発明の開示】
【発明が解決しようとする課題】
【０００７】
この問題に対処する１つの手法は、あらゆるメッセージの証明およびデジタル署名であるが、これは高価であり複雑であるという理由で実装されてきていない。より重要なのは、どこにでも展開されるまでこれが相互運用可能でないことであるが、費用と複雑さのために、その広範な展開は非常に難しいものとなっている。
【課題を解決するための手段】
【０００８】
セキュリティ、スパム防止、ＡＡＡ、Ｒａｄｉｕｓ、およびインターネット・メッセージング・プロトコルの分野に関する方法を対象とする本発明の原理により、従来技術にまさる利点がもたらされる。提案する発明により、発信元になりすまして電子メール・スパムを作成すること、ウイルス配布、および他の電子メールの乱用の問題が解決される。特に、これにより、友人、同僚、および信頼できる機関から送られたものと称する電子メールによってコンピュータ・ウイルスを配布する問題が解決される。
【０００９】
提案する発明により、ある電子メール・メッセージが、電子メール・ゲートウェイ、電子メール・リレー・サーバ、または宛先電子メール・サーバで受け取られたときに、「Ｆｒｏｍ：」フィールドに指定された場所で発信され、またそこに指定される人（またはプログラム）が送ったことを無理なく保証する包括的な１組の機構および装置が定められる。
【００１０】
本発明により、末端である電子メール・メッセージの受信者までのリレー・チェインにあるどの電子メール・サーバ（すなわち、ゲートウェイ、リレー、または宛先サーバ）も、そのメッセージがＦｒｏｍ：フィールドに示される人（またはプログラム）が送ったかどうかが適切に確かめられることが保証される。
【００１１】
本発明は、ａ）発信元と称するサーバに問合せを直接送って、またはｂ）（Ｌｕｃｅｎｔ Ｎａｖｉｓ Ｒａｄｉｕｓサーバなどの）ＡＡＡサーバを用いてこの機能を実行することによって動作する。この問合せに対する応答が否定的である場合は、そのメッセージは廃棄され、必要な場合には、適切なセキュリティ・ログ・エントリが生成される。
【００１２】
この機構は、それぞれが実装の簡単な、様々な方法で（送信者と称する者だけでなく）メッセージを認証する点で新しいものとなっている。また、この機構では、複雑なキー配布、暗号法などを利用する可能性のある（電子署名などの）証明書および他の複雑なセキュリティ機構の使用のための、これまでに提案された（しかし実装が難しいとわかった）機構を回避している。この目的で、この機構では、ＰＫＩの高価な実装および外部のトラスト・センタの証明書の組み込みを回避している。
【００１３】
本発明の教示は以下の詳細な説明を添付の図面と併せ考慮することによって容易に理解することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の方法の実施に使用する諸要素を簡略化した構成図の形で示す図である。
【図２】本発明によるサーバ装置の例示的な構成図である。
【発明を実施するための形態】
【００１５】
本発明の例示的な一実施形態を、これから図面を参照しながら説明するが、そのうちのいくつかは、以下の説明を進めるあいだ、同時に参照することがある。
【００１６】
提案する発明は単純であり、これにより、どのようなタイプの（デジタル署名を含む）暗号法、証明書、または公開鍵配布機構をも使用する費用および複雑さが省かれる。
【００１７】
本発明により、末端である電子メール・メッセージの受信者までのリレー・チェインにあるどの電子メール・サーバ（すなわち、ゲートウェイ、リレー、または宛先サーバ）も、そのメッセージがＦｒｏｍ：フィールドに示される人（またはプログラム）が送ったかどうかが適切に確かめられることが保証される。
【００１８】
本発明は、ａ）発信元と称するサーバに問合せを直接送って、またはｂ）（Ｌｕｃｅｎｔ Ｎａｖｉｓ Ｒａｄｉｕｓサーバなどの）ＡＡＡサーバを用いてこの機能を実行することによって動作する。この問合せに対する応答が否定的である場合は、そのメッセージは廃棄され、必要な場合には、適切なセキュリティ・ログ・エントリが生成される。
【００１９】
この機構は、それぞれが実装の簡単な、様々な方法で（送信者と称する者だけでなく）メッセージを認証する点で新しいものとなっている。また、この機構では、複雑なキー配布、暗号法などを利用する可能性のある（電子署名などの）証明書および他の複雑なセキュリティ機構の使用のための、これまでに提案された（しかし実装が難しいとわかった）機構を回避している。この目的で、この機構では、ＰＫＩの高価な実装および外部のトラスト・センタの証明書の組み込みを回避している。
【００２０】
図１に、本発明の説明に使用する典型的な電子メールのパスを示すネットワーク１０の例示的な部分を示している。ここで、クライアント１２はサーバ１４を介してメッセージを送り、これはドメイン・ゲートウェイ１６および他のプロキシ・サーバ１８を通過し、このそれぞれが、発信元サーバ１４に始まって、ＲＦＣ ２８２１に記述されるＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を使用している。メッセージが宛先サーバ２０に着くと、メッセージは適当な受信者（図示せず）に送られる。発信元サーバ１４、宛先サーバ２０、プロキシ・サーバ１８およびゲートウェイ１６は、すべてＲＦＣ ２８２１に定義するメール転送エージェントの役割を果たすことに注意されたい。
【００２１】
図１を参照すると、本発明のある例示的な実施形態が次のようにして動作している。すなわち、
１．発信元サーバ１４は、発信側クライアント１２から電子メールの転送の要求を受け取るときはいつでも、次のステップを実行する。すなわち、
ａ．電子メール・ヘッダの中のＦｒｏｍ：フィールドがサーバ上のメールボックスを指しているかどうか検査する。そうである場合、その電子メールを転送する。そうでない場合、その電子メールを、たとえば、ＲＦＣ ２８２１に示される最終的な否定的完結応答（ａ ｐｅｒｍａｎｅｎｔ， ｎｅｇａｔｉｖｅ ｃｏｍｐｌｅｔｉｏｎ ｒｅｐｌｙ）によって拒絶する。
ｂ．この発明では、また、転送の成功した電子メール（またはおそらく、その一部、またはローカルに選択されたハッシング・アルゴリズムによって決まるそのハッシュまでも）のログをとる。ログ中のそのエントリは、ある期間のあいだ維持されることになる（通常、たとえば、１０分間を超えない）。
【００２２】
２．本発明の例示的な一実施形態では、チェインにある他のどのサーバも下に述べる諸ステップを実行してよい。これらを、宛先サーバ２０は実行しなければならない。これらのステップは当業者が理解するような数多くの代替方法で実行することができる。すなわち、
ａ．（オプション１）：（矢印のラベル（１）で示す）メッセージ転送が始まり、（ＳＭＴＰのＦｒｏｍ：フィールドで渡される）そのメッセージの発信元と称するものが知られているときには、サーバ２０が、（２）のラベルの付いた問合せを送ることによって、発信元サーバ１４との（ＴＣＰセッションなどの）短いセッション、またはこれに対するトランザクションを開始する。この問合せにより、１組のパラメータ（そのようなパラメータは、Ｆｒｏｍ：フィールド、時刻、長さ、件名の行、選択された内容、または、以上のすべてを含む、メッセージに固有のパラメータの他のどのような組を含んでもよいがこれに限定されなくてもよい）のうちの１つまたは複数が識別する発信元からのメッセージ（ｏｒｉｇｉｎａｔｉｎｇ ｍｅｓｓａｇｅ）が実際にそこに示すユーザによって送られたかどうかが問い合わせられる。以下では可能な問合せフォーマットを説明する（ここで構文はＳＭＴＰをモデルとしている）。１つの問合せは、コマンドと、それに続く複数の引数からなる。すなわち、ＣＯＮＦＩＲＭ＜Ｍｅｓｓａｇｅ−ＩＤ＞＜ｍｅｓｓａｇｅ−ｓｐｅｃｉｆｉｃ−ｐａｒａｍｅｔｅｒｓ＞である。ここで、ＣＯＮＦＩＲＭはコマンド名であり、＜Ｍｅｓｓａｇｅ−ＩＤ＞引数はそのメッセージの（ＲＦＣ ８２２で指定される）一意の識別子を含み、＜ｍｅｓｓａｇｅ−ｓｐｅｃｉｆｉｃ−ｐａｒａｍｅｔｅｒｓ＞（メッセージ固有のパラメータ）引数は、メッセージ識別に使用することもできる、上に述べたパラメータのリストを含む。この問合せを受け取ると、発信元サーバは一意のＭｅｓｓａｇｅ−ＩＤを用いてそのログを検査して、問合せのＭｅｓｓａｇｅ−ＩＤで受信したメッセージが送られたかどうかを確認する。そうでない場合、対応するリプライが受信側サーバに送られる。この例示的な実施形態では、そのＭｅｓｓａｇｅ−ＩＤで識別されるメッセージのログがとられていた場合には、発信元サーバは、ログのとられたメッセージ中の情報と、問合せの＜メッセージ固有のパラメータ＞引数で受け取った情報とを比較することによって、そのメッセージの真正性（ａｕｔｈｅｎｔｉｃｉｔｙ）に関する決定を下す能力があるはずである。この決定が、問合せに応答して送られることになる。
問合せの例をＣＯＮＦＩＲＭ＜４０６Ｃ９５２６．２０６０３０７＠ａｇｅｒｅ．ｃｏｍ＞＜Ｆｒｏｍ：ａｂｃ＠ａｇｅｒｅ．ｃｏｍ＞とする。この問合せを受け取ると、発信元サーバは、４０６Ｃ９５２６．２０６０３０７＠ａｇｅｒｅ．ｃｏｍで参照されるメッセージを取り出し、「ａｂｃ」がそのメッセージの送信者に関連付けられたエリアスのうちにあるかどうかを検査することができるはずである。送信者の識別子は、このメッセージが発信されたときに実行されたＳＭＴＰコマンドＭＡＩＬ ＦＲＯＭ：＜ｒｅｖｅｒｓｅ−ｐａｔｈ＞［ＲＦＣ２８２１］に対する引数として与えられていたのだから、発信元サーバは情報をもっていたはずである。
提案した問合せは、ＲＦＣ ８２２に記述されている一意のＭｅｓｓａｇｅ−ＩＤを有する圧倒的多数のメッセージに対して働くはずである。この標準ではＭｅｓｓａｇｅ−ＩＤフィールドを任意選択（ｏｐｔｉｏｎａｌ）として指定しているが、ほとんどのＳＭＴＰサーバではこのフィールドがその電子メール・メッセージに含められている。このフィールドが存在しない場合は、受信側サーバはローカル・ポリシに従って行動をとることができる（たとえば、メッセージを打ち切る（ａｂｏｒｔ）、受信者に警告を送る、など）。
ｂ．問合せを受け取ると、発信元サーバ１４はログ２２を検査し、発信されたメッセージが表示されているユーザによって送られたかどうかに関する情報を有するメッセージ（３）で応答する。
ｃ．発信元サーバが肯定的に応答した場合、受信側（宛先）サーバ２０は、その電子メール・メッセージの処理および転送を続行する。そうでなかった場合、そのプロセスをただちに打ち切ることができる。打ち切りの結果は、メッセージは保存または転送されないということである。打ち切りは、さらに数多くの異なるやり方で行うことができる。たとえば、打ち切りを行う１つのやり方は、タイムアウトを課し、そうでなければ「受信者が存在しません」などのメッセージを作成し送信することである。さらにどのような攻撃も思いとどまらせるようにそのようなやり方で通信を停止する他のそのようなやり方も本明細書では考慮する。関係のあるどのようなサーバもまた、そのセキュリティ・ポリシで決定されている適切なセキュリティ・ログ・エントリを作成し、または適切な執行機関（ｅｎｆｏｒｃｅｍｅｎｔ ａｇｅｎｃｙ）への通知など他のどのようなセキュリティ関連アクションも取ることができることが理解されよう。
ｄ．（オプション２）：別の代替実施形態では、宛先サーバ２０は、適切なＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ，Ａｕｔｈｏｒｉｚａｔｉｏｎ，ａｎｄ Ａｃｃｏｕｎｔｉｎｇ、認証、認可、アカウンティング）サーバ２４にそのメッセージを認証しその受け取り（メッセージ２’）を認可してくれるように頼む。次いで、ＡＡＡサーバ２４は、それ自体が発信元サーバ１４とのやり取りを実行し（メッセージ２’’および３’）、適切な決定を下し、この決定をもって問い合わせてきたサーバに応答する（メッセージ３’’）。
ｅ．発信元サーバ１４（およびＡＡＡサーバ）が肯定的に応答した場合、宛先サーバ２０はその電子メール・メッセージの処理および転送を続行する。そうでなかった場合、宛先サーバはそのプロセスをただちに打ち切る。関係のあるどのようなサーバもまた、そのセキュリティ・ポリシで決定されている適切なセキュリティ・ログ・エントリを作成し、他のどのようなセキュリティ関連アクションも取ることができる。ＡＡＡサーバが発信元サーバに一度問合せを行った後では、発信元サーバが宛先サーバに直接応答することもでき、または代替方法として、ＡＡＡが通信の応答フェーズだけに関係することもできることも、また理解されよう。
【００２３】
図２に、本発明によるサーバ装置１１０の例示的な構成図を示している。一般に、この装置は、プロセッサ１２０とともに動作する、少なくとも２つの機能ブロックを含む。最初のブロック１３０は、すでに説明したように、受け取った送信を保存するログである。次のブロック１４０は、本発明の方法（ｍｅｔｈｏｄｏｌｏｇｉｅｓ）を実行するために、たとえばソフトウェアの形の、命令を格納するための記憶装置である。ログはまたこの装置のためのメモリ全体の一部であってもよいことが理解されよう。サーバ装置は、また、入力および出力のポート１５０、１６０を含む。さらに、本発明の機能をサーバに関して説明しているが、本発明はプロキシ装置またはサーバに関連付けられた他の同様の装置にあってもよいことが理解されよう。
【００２４】
説明の明瞭さのために、本発明のこの例示的な実施形態を個々の機能ブロックおよび／またはボックスを含むものとして説明してきた。こうしたブロックおよび／またはボックスが表す機能は、ソフトウェアを実行可能なハードウェアを含んでもよいがこれに限定されなくてもよい、共用または専用のハードウェアの使用によって享受することができる。「プロセッサ」という用語の使用はソフトウェアを実行可能なハードウェアをもっぱら指すものと解釈すべきではない。さらに、この例示的な実施形態は、ＤＳＰ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ、デジタル信号プロセッサ）ハードウェア、以下で論じる動作を実行するソフトウェアを格納するためのＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ、読み出し専用メモリ）、およびＤＳＰの結果を格納するためのＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ランダム・アクセス・メモリ）を含むことができる。ＶＬＳＩ（ｖｅｒｙ ｌａｒｇｅ ｓｃａｌｅ ｉｎｔｅｇｒａｔｉｏｎ、超大規模集積回路）ハードウェア実装形態、ならびに、汎用ＤＳＰ回路と組み合わせたカスタムＶＬＳＩ回路もまた設けることができる。
【００２５】
この発明を、好ましい一実施形態の状況で詳細に示し説明してきたが、変形形態および修正形態が、本明細書に添付の特許請求の範囲の範囲のみが限定すべきこの発明の広範な原理および趣旨から逸脱することなく可能であることは、当業者に明らかであろう。
【００２６】
上の説明はこの発明の諸原理を示すものに過ぎない。したがって、明示的に本明細書で説明しまたは示していないが、この発明の諸原理を実施し、その趣旨および範囲に含まれる様々な配置（ａｒｒａｎｇｅｍｅｎｔ）を考案することが当業者には可能であることが理解されよう。さらに、ここに述べたすべての例および条件的な用語法（ｌａｎｇｕａｇｅ）はもっぱら、読者がこの発明の諸原理および当該技術を進めるために発明者が寄与する諸概念を理解するのを助けるのに有益な目的のみを明確に意図しており、そのような特に述べた例および条件への限定のないものとして理解すべきである。しかも、この発明の原理、態様、および実施形態を述べる本明細書中のすべての申し立て、ならびにこの発明の特定の例は、この発明の構造的と機能的の均等物をともに包含するものとする。さらに、そのような均等物は、現在知られる均等物と将来開発される均等物、すなわち、構造に関わらず同じ機能を果たすどのような開発された要素も含むものとする。
【００２７】
本明細書の特許請求の範囲では、特定の機能を果たす手段として表現したどのような要素も、たとえば、ａ）その機能を果たす回路要素の組み合わせ、またはｂ）その機能を果たすようにそのソフトウェアを実行する適切な回路と組み合わせた、どのような形式の、したがって、ファームウェア、マイクロコードまたはその他も含めたソフトウェアを含む、その機能を果たすどのようなやり方も包含するものとする。そのような特許請求の範囲が定義する発明は、ここに述べた様々な手段の提供する機能が、特許請求の範囲が要求するように組み合わせ一緒にされているという事実の中にある。したがって本出願人は、その機能を提供できるどのような手段も本明細書に示すものと均等であると見なす。この発明の諸原理の他の多くの修正および適用は当業者に明らかであろうし、また本明細書の教示の企図するところである。したがって、この発明の範囲を限定するものは特許請求の範囲のみである。
【技術分野】
【０００１】
本発明は、一般には電気通信の分野に関し、詳細にはインターネット・メッセージのセキュリティに関する。
【背景技術】
【０００２】
インターネットの急激な発展とともに、電子メール・システムの乱用がますます問題となっている。こうした乱用は、発信元になりすまして（ｓｐｏｏｆｉｎｇ）（たとえば、ある発信元を特定の受理可能な発信元のように見せかけるように欺きまたは試みること）電子メール・スパムを作成すること、ウイルスの配布、および電子メールの他の乱用を含んでいる。特に、よく知られた危険な問題は、友人、同僚、および信用ある機関から送られたものと称する電子メールによるコンピュータ・ウイルスの配布である。
【０００３】
今日まで、上記の問題に効率的に取り組む解決策はないものの、既存のインターネット標準では、電子メールの送信者と称するものが電子メールの「Ｆｒｏｍ：」フィールドに示されたドメインに存在するかどうかを検査するオプションが提供されている。しかしながら、このオプションは、まれにしか使用されておらず、これはおそらく、現在の加害者は自分の自由にできる正当なアドレスを現に有しており、したがって、アドレスが有効であるかの検査だけでは不十分であるためである。
【０００４】
既存の電子メール標準（ＲＦＣ ２８２１）およびソフトウェアにより、だれでもＦｒｏｍフィールドにどのような発信元が示される電子メール・メッセージでも送ることができるようになっている。この機能（あるいはむしろ脆弱性）を、広告主は利用して電子メール・スパムを生成する。より邪悪な、いまやますます広がっている利用は、受信者にその友人および同僚に見えるものから送られるメッセージでコンピュータ・ウイルスを配布することである。
【０００５】
既存の電子メール標準によって送信者を確認（ｖｅｒｉｆｙ）できはするが、この機能は、そのアドレスが存在するドメインにおいて正しい（すなわち、存在する）ことを確認するのに過ぎない。この機能は、この特定のメッセージが特定のアドレスから送られていることを確認はしない。多くのメール・サーバでは、まさに役に立たなくなっているためにこの機能は無視されている。たとえば、インターネット上にリストされている大量の有効な電子メール・アドレス、様々な電子メール・リスト上にアーカイブされたやり取り、および（侵入されたコンピュータのアドレス帳にある情報などの）他の情報源により、スパム・メール発信者（ｓｐａｍｍｅｒ）または犯罪の実行者は使うのに十分な数のアドレスを得ている。さらに、検索エンジンが、潜在的な標的となる通信相手のリストを入手する助けになっており、この攻撃はより集中したものとなっている。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】「ＲＦＣ ２８２１」、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２８２１．ｔｘｔ？ｎｕｍｂｅｒ＝２８２１＞
【非特許文献２】「ＲＦＣ ８２２」、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ０８２２．ｔｘｔ？ｎｕｍｂｅｒ＝８２２＞
【発明の開示】
【発明が解決しようとする課題】
【０００７】
この問題に対処する１つの手法は、あらゆるメッセージの証明およびデジタル署名であるが、これは高価であり複雑であるという理由で実装されてきていない。より重要なのは、どこにでも展開されるまでこれが相互運用可能でないことであるが、費用と複雑さのために、その広範な展開は非常に難しいものとなっている。
【課題を解決するための手段】
【０００８】
セキュリティ、スパム防止、ＡＡＡ、Ｒａｄｉｕｓ、およびインターネット・メッセージング・プロトコルの分野に関する方法を対象とする本発明の原理により、従来技術にまさる利点がもたらされる。提案する発明により、発信元になりすまして電子メール・スパムを作成すること、ウイルス配布、および他の電子メールの乱用の問題が解決される。特に、これにより、友人、同僚、および信頼できる機関から送られたものと称する電子メールによってコンピュータ・ウイルスを配布する問題が解決される。
【０００９】
提案する発明により、ある電子メール・メッセージが、電子メール・ゲートウェイ、電子メール・リレー・サーバ、または宛先電子メール・サーバで受け取られたときに、「Ｆｒｏｍ：」フィールドに指定された場所で発信され、またそこに指定される人（またはプログラム）が送ったことを無理なく保証する包括的な１組の機構および装置が定められる。
【００１０】
本発明により、末端である電子メール・メッセージの受信者までのリレー・チェインにあるどの電子メール・サーバ（すなわち、ゲートウェイ、リレー、または宛先サーバ）も、そのメッセージがＦｒｏｍ：フィールドに示される人（またはプログラム）が送ったかどうかが適切に確かめられることが保証される。
【００１１】
本発明は、ａ）発信元と称するサーバに問合せを直接送って、またはｂ）（Ｌｕｃｅｎｔ Ｎａｖｉｓ Ｒａｄｉｕｓサーバなどの）ＡＡＡサーバを用いてこの機能を実行することによって動作する。この問合せに対する応答が否定的である場合は、そのメッセージは廃棄され、必要な場合には、適切なセキュリティ・ログ・エントリが生成される。
【００１２】
この機構は、それぞれが実装の簡単な、様々な方法で（送信者と称する者だけでなく）メッセージを認証する点で新しいものとなっている。また、この機構では、複雑なキー配布、暗号法などを利用する可能性のある（電子署名などの）証明書および他の複雑なセキュリティ機構の使用のための、これまでに提案された（しかし実装が難しいとわかった）機構を回避している。この目的で、この機構では、ＰＫＩの高価な実装および外部のトラスト・センタの証明書の組み込みを回避している。
【００１３】
本発明の教示は以下の詳細な説明を添付の図面と併せ考慮することによって容易に理解することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の方法の実施に使用する諸要素を簡略化した構成図の形で示す図である。
【図２】本発明によるサーバ装置の例示的な構成図である。
【発明を実施するための形態】
【００１５】
本発明の例示的な一実施形態を、これから図面を参照しながら説明するが、そのうちのいくつかは、以下の説明を進めるあいだ、同時に参照することがある。
【００１６】
提案する発明は単純であり、これにより、どのようなタイプの（デジタル署名を含む）暗号法、証明書、または公開鍵配布機構をも使用する費用および複雑さが省かれる。
【００１７】
本発明により、末端である電子メール・メッセージの受信者までのリレー・チェインにあるどの電子メール・サーバ（すなわち、ゲートウェイ、リレー、または宛先サーバ）も、そのメッセージがＦｒｏｍ：フィールドに示される人（またはプログラム）が送ったかどうかが適切に確かめられることが保証される。
【００１８】
本発明は、ａ）発信元と称するサーバに問合せを直接送って、またはｂ）（Ｌｕｃｅｎｔ Ｎａｖｉｓ Ｒａｄｉｕｓサーバなどの）ＡＡＡサーバを用いてこの機能を実行することによって動作する。この問合せに対する応答が否定的である場合は、そのメッセージは廃棄され、必要な場合には、適切なセキュリティ・ログ・エントリが生成される。
【００１９】
この機構は、それぞれが実装の簡単な、様々な方法で（送信者と称する者だけでなく）メッセージを認証する点で新しいものとなっている。また、この機構では、複雑なキー配布、暗号法などを利用する可能性のある（電子署名などの）証明書および他の複雑なセキュリティ機構の使用のための、これまでに提案された（しかし実装が難しいとわかった）機構を回避している。この目的で、この機構では、ＰＫＩの高価な実装および外部のトラスト・センタの証明書の組み込みを回避している。
【００２０】
図１に、本発明の説明に使用する典型的な電子メールのパスを示すネットワーク１０の例示的な部分を示している。ここで、クライアント１２はサーバ１４を介してメッセージを送り、これはドメイン・ゲートウェイ１６および他のプロキシ・サーバ１８を通過し、このそれぞれが、発信元サーバ１４に始まって、ＲＦＣ ２８２１に記述されるＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を使用している。メッセージが宛先サーバ２０に着くと、メッセージは適当な受信者（図示せず）に送られる。発信元サーバ１４、宛先サーバ２０、プロキシ・サーバ１８およびゲートウェイ１６は、すべてＲＦＣ ２８２１に定義するメール転送エージェントの役割を果たすことに注意されたい。
【００２１】
図１を参照すると、本発明のある例示的な実施形態が次のようにして動作している。すなわち、
１．発信元サーバ１４は、発信側クライアント１２から電子メールの転送の要求を受け取るときはいつでも、次のステップを実行する。すなわち、
ａ．電子メール・ヘッダの中のＦｒｏｍ：フィールドがサーバ上のメールボックスを指しているかどうか検査する。そうである場合、その電子メールを転送する。そうでない場合、その電子メールを、たとえば、ＲＦＣ ２８２１に示される最終的な否定的完結応答（ａ ｐｅｒｍａｎｅｎｔ， ｎｅｇａｔｉｖｅ ｃｏｍｐｌｅｔｉｏｎ ｒｅｐｌｙ）によって拒絶する。
ｂ．この発明では、また、転送の成功した電子メール（またはおそらく、その一部、またはローカルに選択されたハッシング・アルゴリズムによって決まるそのハッシュまでも）のログをとる。ログ中のそのエントリは、ある期間のあいだ維持されることになる（通常、たとえば、１０分間を超えない）。
【００２２】
２．本発明の例示的な一実施形態では、チェインにある他のどのサーバも下に述べる諸ステップを実行してよい。これらを、宛先サーバ２０は実行しなければならない。これらのステップは当業者が理解するような数多くの代替方法で実行することができる。すなわち、
ａ．（オプション１）：（矢印のラベル（１）で示す）メッセージ転送が始まり、（ＳＭＴＰのＦｒｏｍ：フィールドで渡される）そのメッセージの発信元と称するものが知られているときには、サーバ２０が、（２）のラベルの付いた問合せを送ることによって、発信元サーバ１４との（ＴＣＰセッションなどの）短いセッション、またはこれに対するトランザクションを開始する。この問合せにより、１組のパラメータ（そのようなパラメータは、Ｆｒｏｍ：フィールド、時刻、長さ、件名の行、選択された内容、または、以上のすべてを含む、メッセージに固有のパラメータの他のどのような組を含んでもよいがこれに限定されなくてもよい）のうちの１つまたは複数が識別する発信元からのメッセージ（ｏｒｉｇｉｎａｔｉｎｇ ｍｅｓｓａｇｅ）が実際にそこに示すユーザによって送られたかどうかが問い合わせられる。以下では可能な問合せフォーマットを説明する（ここで構文はＳＭＴＰをモデルとしている）。１つの問合せは、コマンドと、それに続く複数の引数からなる。すなわち、ＣＯＮＦＩＲＭ＜Ｍｅｓｓａｇｅ−ＩＤ＞＜ｍｅｓｓａｇｅ−ｓｐｅｃｉｆｉｃ−ｐａｒａｍｅｔｅｒｓ＞である。ここで、ＣＯＮＦＩＲＭはコマンド名であり、＜Ｍｅｓｓａｇｅ−ＩＤ＞引数はそのメッセージの（ＲＦＣ ８２２で指定される）一意の識別子を含み、＜ｍｅｓｓａｇｅ−ｓｐｅｃｉｆｉｃ−ｐａｒａｍｅｔｅｒｓ＞（メッセージ固有のパラメータ）引数は、メッセージ識別に使用することもできる、上に述べたパラメータのリストを含む。この問合せを受け取ると、発信元サーバは一意のＭｅｓｓａｇｅ−ＩＤを用いてそのログを検査して、問合せのＭｅｓｓａｇｅ−ＩＤで受信したメッセージが送られたかどうかを確認する。そうでない場合、対応するリプライが受信側サーバに送られる。この例示的な実施形態では、そのＭｅｓｓａｇｅ−ＩＤで識別されるメッセージのログがとられていた場合には、発信元サーバは、ログのとられたメッセージ中の情報と、問合せの＜メッセージ固有のパラメータ＞引数で受け取った情報とを比較することによって、そのメッセージの真正性（ａｕｔｈｅｎｔｉｃｉｔｙ）に関する決定を下す能力があるはずである。この決定が、問合せに応答して送られることになる。
問合せの例をＣＯＮＦＩＲＭ＜４０６Ｃ９５２６．２０６０３０７＠ａｇｅｒｅ．ｃｏｍ＞＜Ｆｒｏｍ：ａｂｃ＠ａｇｅｒｅ．ｃｏｍ＞とする。この問合せを受け取ると、発信元サーバは、４０６Ｃ９５２６．２０６０３０７＠ａｇｅｒｅ．ｃｏｍで参照されるメッセージを取り出し、「ａｂｃ」がそのメッセージの送信者に関連付けられたエリアスのうちにあるかどうかを検査することができるはずである。送信者の識別子は、このメッセージが発信されたときに実行されたＳＭＴＰコマンドＭＡＩＬ ＦＲＯＭ：＜ｒｅｖｅｒｓｅ−ｐａｔｈ＞［ＲＦＣ２８２１］に対する引数として与えられていたのだから、発信元サーバは情報をもっていたはずである。
提案した問合せは、ＲＦＣ ８２２に記述されている一意のＭｅｓｓａｇｅ−ＩＤを有する圧倒的多数のメッセージに対して働くはずである。この標準ではＭｅｓｓａｇｅ−ＩＤフィールドを任意選択（ｏｐｔｉｏｎａｌ）として指定しているが、ほとんどのＳＭＴＰサーバではこのフィールドがその電子メール・メッセージに含められている。このフィールドが存在しない場合は、受信側サーバはローカル・ポリシに従って行動をとることができる（たとえば、メッセージを打ち切る（ａｂｏｒｔ）、受信者に警告を送る、など）。
ｂ．問合せを受け取ると、発信元サーバ１４はログ２２を検査し、発信されたメッセージが表示されているユーザによって送られたかどうかに関する情報を有するメッセージ（３）で応答する。
ｃ．発信元サーバが肯定的に応答した場合、受信側（宛先）サーバ２０は、その電子メール・メッセージの処理および転送を続行する。そうでなかった場合、そのプロセスをただちに打ち切ることができる。打ち切りの結果は、メッセージは保存または転送されないということである。打ち切りは、さらに数多くの異なるやり方で行うことができる。たとえば、打ち切りを行う１つのやり方は、タイムアウトを課し、そうでなければ「受信者が存在しません」などのメッセージを作成し送信することである。さらにどのような攻撃も思いとどまらせるようにそのようなやり方で通信を停止する他のそのようなやり方も本明細書では考慮する。関係のあるどのようなサーバもまた、そのセキュリティ・ポリシで決定されている適切なセキュリティ・ログ・エントリを作成し、または適切な執行機関（ｅｎｆｏｒｃｅｍｅｎｔ ａｇｅｎｃｙ）への通知など他のどのようなセキュリティ関連アクションも取ることができることが理解されよう。
ｄ．（オプション２）：別の代替実施形態では、宛先サーバ２０は、適切なＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ，Ａｕｔｈｏｒｉｚａｔｉｏｎ，ａｎｄ Ａｃｃｏｕｎｔｉｎｇ、認証、認可、アカウンティング）サーバ２４にそのメッセージを認証しその受け取り（メッセージ２’）を認可してくれるように頼む。次いで、ＡＡＡサーバ２４は、それ自体が発信元サーバ１４とのやり取りを実行し（メッセージ２’’および３’）、適切な決定を下し、この決定をもって問い合わせてきたサーバに応答する（メッセージ３’’）。
ｅ．発信元サーバ１４（およびＡＡＡサーバ）が肯定的に応答した場合、宛先サーバ２０はその電子メール・メッセージの処理および転送を続行する。そうでなかった場合、宛先サーバはそのプロセスをただちに打ち切る。関係のあるどのようなサーバもまた、そのセキュリティ・ポリシで決定されている適切なセキュリティ・ログ・エントリを作成し、他のどのようなセキュリティ関連アクションも取ることができる。ＡＡＡサーバが発信元サーバに一度問合せを行った後では、発信元サーバが宛先サーバに直接応答することもでき、または代替方法として、ＡＡＡが通信の応答フェーズだけに関係することもできることも、また理解されよう。
【００２３】
図２に、本発明によるサーバ装置１１０の例示的な構成図を示している。一般に、この装置は、プロセッサ１２０とともに動作する、少なくとも２つの機能ブロックを含む。最初のブロック１３０は、すでに説明したように、受け取った送信を保存するログである。次のブロック１４０は、本発明の方法（ｍｅｔｈｏｄｏｌｏｇｉｅｓ）を実行するために、たとえばソフトウェアの形の、命令を格納するための記憶装置である。ログはまたこの装置のためのメモリ全体の一部であってもよいことが理解されよう。サーバ装置は、また、入力および出力のポート１５０、１６０を含む。さらに、本発明の機能をサーバに関して説明しているが、本発明はプロキシ装置またはサーバに関連付けられた他の同様の装置にあってもよいことが理解されよう。
【００２４】
説明の明瞭さのために、本発明のこの例示的な実施形態を個々の機能ブロックおよび／またはボックスを含むものとして説明してきた。こうしたブロックおよび／またはボックスが表す機能は、ソフトウェアを実行可能なハードウェアを含んでもよいがこれに限定されなくてもよい、共用または専用のハードウェアの使用によって享受することができる。「プロセッサ」という用語の使用はソフトウェアを実行可能なハードウェアをもっぱら指すものと解釈すべきではない。さらに、この例示的な実施形態は、ＤＳＰ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ、デジタル信号プロセッサ）ハードウェア、以下で論じる動作を実行するソフトウェアを格納するためのＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ、読み出し専用メモリ）、およびＤＳＰの結果を格納するためのＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ランダム・アクセス・メモリ）を含むことができる。ＶＬＳＩ（ｖｅｒｙ ｌａｒｇｅ ｓｃａｌｅ ｉｎｔｅｇｒａｔｉｏｎ、超大規模集積回路）ハードウェア実装形態、ならびに、汎用ＤＳＰ回路と組み合わせたカスタムＶＬＳＩ回路もまた設けることができる。
【００２５】
この発明を、好ましい一実施形態の状況で詳細に示し説明してきたが、変形形態および修正形態が、本明細書に添付の特許請求の範囲の範囲のみが限定すべきこの発明の広範な原理および趣旨から逸脱することなく可能であることは、当業者に明らかであろう。
【００２６】
上の説明はこの発明の諸原理を示すものに過ぎない。したがって、明示的に本明細書で説明しまたは示していないが、この発明の諸原理を実施し、その趣旨および範囲に含まれる様々な配置（ａｒｒａｎｇｅｍｅｎｔ）を考案することが当業者には可能であることが理解されよう。さらに、ここに述べたすべての例および条件的な用語法（ｌａｎｇｕａｇｅ）はもっぱら、読者がこの発明の諸原理および当該技術を進めるために発明者が寄与する諸概念を理解するのを助けるのに有益な目的のみを明確に意図しており、そのような特に述べた例および条件への限定のないものとして理解すべきである。しかも、この発明の原理、態様、および実施形態を述べる本明細書中のすべての申し立て、ならびにこの発明の特定の例は、この発明の構造的と機能的の均等物をともに包含するものとする。さらに、そのような均等物は、現在知られる均等物と将来開発される均等物、すなわち、構造に関わらず同じ機能を果たすどのような開発された要素も含むものとする。
【００２７】
本明細書の特許請求の範囲では、特定の機能を果たす手段として表現したどのような要素も、たとえば、ａ）その機能を果たす回路要素の組み合わせ、またはｂ）その機能を果たすようにそのソフトウェアを実行する適切な回路と組み合わせた、どのような形式の、したがって、ファームウェア、マイクロコードまたはその他も含めたソフトウェアを含む、その機能を果たすどのようなやり方も包含するものとする。そのような特許請求の範囲が定義する発明は、ここに述べた様々な手段の提供する機能が、特許請求の範囲が要求するように組み合わせ一緒にされているという事実の中にある。したがって本出願人は、その機能を提供できるどのような手段も本明細書に示すものと均等であると見なす。この発明の諸原理の他の多くの修正および適用は当業者に明らかであろうし、また本明細書の教示の企図するところである。したがって、この発明の範囲を限定するものは特許請求の範囲のみである。
【特許請求の範囲】
【請求項１】
通信ネットワークにおいて電子メール・メッセージを認証する方法であって、
表示されているユーザが前記電子メール・メッセージを送ったかどうかを判断するための問合せを発信元サーバで受け取る工程と、
前記電子メール・メッセージが前記発信元サーバから送られたメッセージと一致するどうかを判断するために前記発信元サーバでログに記録したデータを検査する工程と、
前記電子メール・メッセージを認証するために前記問合せに応答する工程とを含む方法。
【請求項１】
通信ネットワークにおいて電子メール・メッセージを認証する方法であって、
表示されているユーザが前記電子メール・メッセージを送ったかどうかを判断するための問合せを発信元サーバで受け取る工程と、
前記電子メール・メッセージが前記発信元サーバから送られたメッセージと一致するどうかを判断するために前記発信元サーバでログに記録したデータを検査する工程と、
前記電子メール・メッセージを認証するために前記問合せに応答する工程とを含む方法。
【図１】
【図２】
【図２】
【公開番号】特開２０１２−３４３９６（Ｐ２０１２−３４３９６Ａ）
【公開日】平成２４年２月１６日（２０１２．２．１６）
【国際特許分類】
【出願番号】特願２０１１−２０８５２９（Ｐ２０１１−２０８５２９）
【出願日】平成２３年９月２６日（２０１１．９．２６）
【分割の表示】特願２００５−６４７０１（Ｐ２００５−６４７０１）の分割
【原出願日】平成１７年３月９日（２００５．３．９）
【出願人】（５９６０９２６９８）アルカテル−ルーセント ユーエスエー インコーポレーテッド (965)
【Ｆターム（参考）】
【公開日】平成２４年２月１６日（２０１２．２．１６）
【国際特許分類】
【出願日】平成２３年９月２６日（２０１１．９．２６）
【分割の表示】特願２００５−６４７０１（Ｐ２００５−６４７０１）の分割
【原出願日】平成１７年３月９日（２００５．３．９）
【出願人】（５９６０９２６９８）アルカテル−ルーセント ユーエスエー インコーポレーテッド (965)
【Ｆターム（参考）】
[ Back to top ]