JP2015534668A - ダイレクト電子メール - Google Patents

Abstract

通信ネットワークにおける電子メール処理の向上を可能にする技術が開示される。たとえば、電子メールシステムにおいて電子メールメッセージを処理する方法は以下のステップを含む。電子メールシステムにおいてメッセージ送信者のクライアントとメッセージ受信者のサーバの間に安全な接続が確立される。メッセージ送信者の識別子を確認するために認証交換が使用される。メッセージ送信者は、メッセージ送信者のクライアントの識別子の確認が成功すると、電子メールメッセージをメッセージ受信者のサーバに預ける。

Description

本出願は一般に通信ネットワークに関し、より詳細には、そのような通信ネットワークにおける電子メール処理の改善を可能にする技術に関する。

ワールドワイドウェブで使用される既存の電子メール（Ｅメール）システムは、「簡易メール転送プロトコル（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）」（ＳＭＴＰ）と題された、インターネット技術タスクフォース（ＩＥＴＦ）ＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔ）５３２１および「インターネットメッセージフォーマット（Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｅ Ｆｏｒｍａｔ）」と題されたＲＦＣ５３２２に記載されており、それらの開示は、引用によりその全体が本明細書に組み込まれている。

典型的には、Ｅメールは、Ｅメールクライアントアプリケーションを介して送信者によって生成され、受信者へのＥメールの送信を処理するためのＳＭＴＰサーバに提供される。ＳＭＴＰサーバは他のＳＭＴＰサーバと通信してＥメールを送達することができる。具体的には、Ｅメールクライアントアプリケーションは、ＳＭＴＰサーバに送信者のアドレスと受信者のアドレスを通知し、メッセージの本文を提供する。Ｅメールが外部のドメインに送達される場合、発信側のＳＭＴＰサーバがドメインネームサーバ（ＤＮＳ）と通信し、ＤＮＳは、外部の（宛先）ドメインに対応するＳＭＴＰサーバについての１つまたは複数のインターネットプロトコル（ＩＰ）アドレスを返す。発信側のＳＭＴＰサーバは、宛先ＳＭＴＰサーバのうちの１つと通信し、Ｅメールをその宛先ＳＭＴＰサーバに提供する。ＳＭＴＰサーバ同士は、サーバ間プロトコルを介して通信する。

種々のサーバ間プロトコルが必要であることに加えて、既存のＥメールシステムの別の大きな欠点は、迷惑メール（または「スパム」）の存在であり、これには、フィッシング（すなわち、信頼のおけるエンティティを装って電子通信で情報を取得しようとすること）やウイルス拡散など、その悪意のある形態が含まれる。

ＩＥＴＦ ＲＦＣ５３２１ ＩＥＴＦ ＲＦＣ５３２２ ＩＥＴＦ ＲＦＣ２６１６ ＩＥＴＦ ＲＦＣ６５４４ ＩＥＦＴ ＲＦＣ５２４６、バージョン１．２ 「Ｔｈｅ ＯＡｕｔｈ ２．０ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ ｄｒａｆｔ−ｉｅｆｔ−ｏａｕｔｈ−ｖ２−３０」、ＩＥＴＦ Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２０１２年７月１５日

本発明の実施形態は、通信ネットワークにおける電子メール処理の向上を可能にする技術を提供する。

たとえば、一実施形態において、電子メールシステムにおいて電子メールメッセージを処理する方法は、以下のステップを含む。電子メールシステムにおいてメッセージ送信者のクライアントとメッセージ受信者のサーバの間に安全な接続が確立される。メッセージ送信者のクライアントの識別子を確認するために認証交換が使用される。メッセージ送信者のクライアントの識別子の確認が成功すると、メッセージ送信者のクライアントが、電子メールメッセージをメッセージ受信者のサーバに預ける。

別の実施形態において、電子メールシステムにおいて電子メールメッセージを処理する方法は、以下のステップを含む。電子メールシステムにおいてメッセージ送信者のクライアントとメッセージ受信者のサーバの間に安全な接続が確立される。メッセージ送信者のクライアントの識別子を確認するために認証交換が使用される。メッセージ送信者のクライアントの識別子の確認が成功すると、メッセージ受信者のサーバが、メッセージ送信者のクライアントによって送信された電子メールメッセージを受信する。

さらに別の実施形態において、電子メールシステムにおいて電子メールメッセージを処理する装置は、メモリに結合されており、所与の方法についての上述のステップを実施するようにクライアントまたはサーバを実行するように構成されたプロセッサを備える。

さらなる実施形態において、製造物品は、プロセッサによって実行されたときに、所与の方法についての上述のステップを実施する１つまたは複数のソフトウェアプログラムを記憶するプロセッサ可読記憶媒体を備える。

有利には、例示的な本発明の実施形態は、送信者認証を実現することによって迷惑Ｅメールを減らすか、またはなくし、既存のＥメールメッセージシステムにおいてＥメールメッセージを送達するために必要なサーバ間プロトコルを減らすか、またはなくす。

本発明のこれらの特長および利点ならびに他の特長および利点は、添付の図面および以下の詳細な説明から、より明らかになろう。

本発明の一実施形態による、ダイレクト電子メールシステムを示す図である。 本発明の一実施形態による、ダイレクト電子メールシステムにおいてクライアントとサーバの間に安全な接続を確立することを示す図である。 本発明の一実施形態による、ダイレクト電子メールクライアントによって実施される方法を示す図である。 本発明の一実施形態による、ダイレクト電子メールシステムにおける認証オペレーションについてのメッセージの流れを示す図である。 本発明の別の実施形態による、ダイレクト電子メールシステムにおける認証オペレーションについてのメッセージの流れを示す図である。 本発明のさらに別の実施形態による、ダイレクト電子メールシステムにおける認証オペレーションについてのメッセージの流れを示す図である。 本発明の一実施形態による、ダイレクト電子メールシステムを実施するのに適した通信ネットワークのコンピューティングアーキテクチャを示す図である。

以下、例示的な通信プロトコルに関して本発明の実施形態が説明される。ただし、本発明の実施形態はいずれかの特定の通信プロトコルには限定されないことが理解されるはずである。むしろ、本発明の実施形態は、電子メール処理の向上を提供するのに望ましいと思われる任意の適切な通信環境に適用可能である。

本明細書で使用される語句「通信ネットワーク」は一般に、限定はしないが、テキストベースのデータ、グラフィックベースのデータ、音声ベースのデータおよび映像ベースのデータを含む１つまたは複数のタイプの媒体を送ることが可能な通信ネットワークまたはシステムと定義される。そのような通信ネットワーク全体にわたって実装されている電子メールシステムの場合、通常、電子メールシステムを介して送信されるメッセージ（Ｅメール）はテキストベースのメッセージである。ただし、これらのテキストベースのメッセージは、他のタイプの媒体（たとえば、ビデオ、画像、オーディオ、グラフィック、さらにはテキスト）が入った添付物を含むことがある。

本明細書で使用される語句「安全な接続」は一般に、関連するエンティティの認証に基づいて、暗号手段によって秘匿性または完全性（あるいは両方）が保護される通信接続と定義される。また、通常、安全な接続を介して送達されるメッセージは再生され得ない。

また、本明細書で使用される「サーバ」は一般に、通信ネットワーク、クライアントおよび／または別のサーバからの要求を受けて１つまたは複数の機能を実行する、１つもしくは複数のコンピューティング装置および／または１つもしくは複数のソフトウェアプログラムと定義される。したがって、たとえば、「Ｅメールサーバ」は１つまたは複数のＥメール送達機能を実行する。本発明の例示的な実施形態で使用されるサーバはウェブサーバであることが想定されている（すなわち、ハイパーテキスト転送プロトコル（ＨＴＴＰ）標準をサポートしていることが想定されている）。

本明細書で使用される「クライアント」は一般に、通信ネットワーク、サーバ、および／または別のクライアントに１つまたは複数の機能を要求する、１つもしくは複数のコンピューティング装置および／または１つもしくは複数のソフトウェアプログラムと定義される。クライアントに関連づけられるデバイスの例としては、限定はしないが、携帯電話、スマートフォン、タブレット、卓上電話、携帯情報端末、ラップトップコンピュータ、パーソナルコンピュータなどがあり得る。また、コンピューティング装置またはソフトウェアプログラムが、ある目的ではサーバに、別の目的ではクライアントになり得、キー定義要素が、ＨＴＴＰプロトコルについてのそれぞれの関数である。

したがって、ある例においては、「Ｅメールクライアント」は、１つまたは複数のＥメール送達機能を「Ｅメールサーバ」に要求する。Ｅメールクライアントはまた、とりわけ、Ｅメールを読み、Ｅメールを作成する機能をユーザに提供することができる。

既存のＥメールシステムについての上記の検討に戻ると、既存のＥメールシステムにおいて認証が困難な主な理由は、システムが、サーバ間プロトコル交換およびさまざまなアクセスプロトコルとともに複数のメールサーバを使用することである。既存のＥメールシステムにまつわる大きな問題は、それが隔世遺伝的であること、すなわち、１９７０年代に設計され、ウェブ以前のインフラを反映しているということである。当時、ネットワーキングは信頼できないものであったため、クライアントとリモートサーバの間の直接的なリアルタイム同期通信は検討されなかった。今日では、グローバル接続およびサーバのロードバランシングによって、状況は大きく変わった。それに限定はされないが、例示的な本発明の実施形態は、ウェブ配備における最先端技術を活用する。

そのため、グローバルサーバの発見およびクライアント−サーバ間の接続が進むにつれて、既存のＥメールシステムが著しく簡素化され得ることがここで理解される。したがって、本発明の１つまたは複数の実施形態において、本発明者らは既存のＥメールインフラを変更しており、その中ではメッセージの受信者と送信者が別々のサーバをもち、そのためＥメールの受信者に対して単一のサーバが使用される。すなわち、受信者は、Ｅメールの送達のために自身に関連づけられた複数のサーバをもたない。送信者は、Ｅメールを送達するためには単一の受信者サーバに接続するだけでよく、これによって任意のサーバ間プロトコルの必要性がなくなる。

認証機能を持たないのがこのサーバ間プロトコルなので、グローバル接続および「オンデマンド」のコンピューティング力の存在下で不必要に複雑になるだけでなく、本発明の実施形態はその問題を完全に取り除く。より具体的には、本発明の実施形態によって、送信者は、Ｅメールを直接的に（ダイレクトＥメール）受信者のサーバに預けられるようになり、サーバは、受信者の必要に応じて送信者を認証できるようになる。

したがって、ダイレクトＥメール（本明細書では「ｄメール」と称する）は、既存のＥメールシステムのインフラを極めて簡素化し、また、認証されていないポスティングを防ぐ。ある例において、用語「ダイレクト」は、インターネットプロトコル（ＩＰ）のアプリケーション層に関してのエンドポイントであるＥメールクライアントおよびＥメールサーバを指す。知られているように、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）プロトコルスイートにおいて、アプリケーション層は、ＩＰネットワークにおけるプロセス間通信のカテゴリに入るプロトコルおよび方法を含む。コンピュータネットワーキングの開放型システム間相互接続モデル（ＯＳＩモデル）はまた、名前アプリケーション層によって識別されるあるグループのプロトコルおよび方法を特定する。したがって、Ｅメール送信者のクライアントとメッセージ受信者のサーバの間の通信（ここで、たとえばメッセージ受信者は別のＥメールクライアントまたは宛先Ｅメールクライアントであると推定される）は、Ｅメール送信者のクライアントとメール受信者のサーバがアプリケーション層において１対１で通信するという意味でダイレクトである。これはＥメールメッセージがＥメールクライアントとＥメールサーバを実装する装置間にある中間デバイス／サーバ（たとえば、プロキシ、ファイアウォール、ルータ、およびスイッチ）を通過できないことを意味するのではなく、中間デバイス／サーバの存在がｄメール送達とは無関係であることを意味することと理解されたい。

１つまたは複数の実施形態では、ダイレクトメールのコンセプトは、ＨＴＴＰ（たとえば、ＩＥＴＦ ＲＦＣ２６１６に記載されており、その開示は、引用によりその全体が本明細書に組み込まれている）、ＷｅｂＳｏｃｋｅｔプロトコル（たとえば、ＩＥＴＦ ＲＦＣ６５４４に記載されており、その開示は、引用によりその全体が本明細書に組み込まれている）、およびＨＴＭＬ５（ワールドワイドウェブコンソーシアム（Ｗ３Ｃ）によって開発されたハイパーテキストマークアップ言語バージョン５）を含むブラウザ技術に基づいている。ＨＴＭＬ５は通常、クライアント側のプログラミング物に適用されることを理解されたい。

一実施形態において、ｄメールクライアントはもともと実装されていても、またはブラウザプログラムを介してアクセスされるウェブアプリケーションとして実装されていてもよい。有利には、ｄメールシステムは、ウェブ以前のＥメール中継インフラを、受信者のメールサーバとのインスタント通信に置き換える。しかし、新たな方法／プロトコルは、特に受信側の既存のＳＭＴＰメールサーバ機能と容易に共存できる。

図１は、本発明の一実施形態による、ダイレクト電子メール（ｄメール）システムを示す図である。より具体的には、この図は、ｄメールクライアントとｄメールサーバの間のインターフェースがＨＴＴＰに基づいている一実施形態を示す。

図示されているように、ｄメールシステム１００は、識別子提供部１０２、ｄメールクライアント１０４、ＤＮＳサーバ１０６およびｄメールサーバ１１０を備える。ｄメールサーバ１１０は、ウェブアクセスモジュール１１２、メールストレージ１１４およびディレクトリ１１６を備える。

識別子提供部１０２は、各エンティティについての識別子情報を作成、維持、および管理するプロバイダエンティティであり、エンティティ認証を通信ネットワーク内の他のサービスプロバイダに提供する。

既に言及したように、ｄメールクライアント１０４は、エンティティについての電子メッセージを管理する１つもしくは複数のコンピューティング装置および／または１つもしくは複数のソフトウェアプログラムであり得る。ｄメールクライアントに関連づけられるデバイスの例としては、限定はしないが、携帯電話、スマートフォン、タブレット、卓上電話、携帯情報端末、ラップトップコンピュータ、パーソナルコンピュータなどがあり得る。したがって、クライアントは、これらのデバイスおよび／またはそのようなデバイスに関連づけられた１つもしくは複数のソフトウェアプログラムのうちの１つまたは複数と考えられ得る。

ＤＮＳサーバ１０６は、要求を受けて、意図したメッセージ受信者に関連づけられたｄメールサーバのＩＰアドレスをｄメールクライアント１０４に提供するドメインネームサーバである。

ウェブアクセスモジュール１１２は、ＨＴＴＰプロトコルのサーバ側を実装しているＥメールサーバにおけるモジュールである。

ディレクトリ１１６は、Ｅメールサーバ１１０のファイルシステムに関連づけられたディレクトリである。

メールストレージ１１４は、Ｅメールクライアントによって預けられたｄメールメッセージが記憶されるメモリである。

図２は、本発明の一実施形態による、ダイレクト電子メールシステムにおいてクライアントとサーバの間に安全な接続を確立することを示す図である。すなわち、メッセージを預けるかまたは取り出すために、ｄメールクライアントは図２に示されるようにｄメールサーバとの安全な接続を確立する。

図示されているように、ｄメールクライアント２０２は、ｄメールサーバ２０４−１、２０４−２および２０４−３と通信している。有利には、アプリケーション層において、ｄメールクライアントは、上記のようにｄメールサーバと直接通信している。したがって、Ｅメールメッセージを預けるためにＥメール送信者が通信する必要があるアプリケーションレベルのサーバ、すなわち、Ｅメール受信者のサーバは１つだけなので、従来のＳＭＴＰ Ｅメールシステムに関連づけられたいかなるサーバ間プロトコルも必要ない。

各ｄメールサーバは、１つまたは複数の所与のｄメールクライアントのためのｄメールサーバである。たとえば、ｄメールサーバ２０４−１はｄメールクライアント２０６−１のｄメールサーバであり、ｄメールサーバ２０４−２はｄメールクライアント２０６−２のｄメールサーバであり、ｄメールサーバ２０４−３はｄメールクライアント２０６−３のｄメールサーバである。この例示的シナリオでは、ｄメールクライアント２０２はｄメール「送信者」またはｄメール発信元であり、したがって、１つまたは複数のＥメールメッセージをｄメールサーバ２０４−１、２０４−２および２０４−３のうちの１つまたは複数に預け、一方、ｄメールクライアント２０６−１、２０６−２および２０６−３のうちの１つまたは複数はｄメール「受信者」またはｄメール宛先であり、したがって、１つまたは複数の預けられたＥメールメッセージを、ｄメールサーバ２０４−１、２０４−２および２０４−３のうちの１つまたは複数から取り出す。当然ながら、ｄメールクライアント２０２は他のＥメールの受信者であってもよく、一方、ｄメールクライアント２０６−１、２０６−２および２０６−３のうちのいずれか１つまたは複数は、他のＥメールの送信者であってもよい。

安全な接続２０８が、ｄメールクライアント２０２と、ｄメールサーバ２０４−１、２０４−２および２０４−３との間にそれぞれ確立され、安全な接続２１０が、ｄメールクライアント２０６−１、２０６−２および２０６−３と、ｄメールサーバ２０４−１、２０４−２および２０４−３との間にそれぞれ確立される。そのような安全な接続の例が以下でさらに説明される。

図３は、ｄメールクライアントがｄメールサーバに（たとえば、図２のｄメールクライアント２０２がｄメールサーバ２０４−１、２０４−２または２０４−３に）Ｅメールメッセージを預けるための方法３００を示す。

ステップ３０２において、ｄメールクライアントは、ＤＮＳサーバ（たとえば、図１のＤＮＳサーバ１０６）によって、受信者のＵＲＩ（ユニフォーム リソース アイデンティファイア、ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ）（たとえば、ｄｍａｉｌ：／／ｉｇｏｒ．ｆａｙｎｂｅｒｇ＠ａｌｃａｔｅｌ−ｌｕｃｅｎｔ．ｃｏｍ）に基づいて対象ｄメールサーバのＩＰアドレスを見つける。したがって、再び図２を参照すると、ｄメールクライアント２０６−３に関連づけられたＥメール受信者のＵＲＩがｄｍａｉｌ：／／ｉｇｏｒ．ｆａｙｎｂｅｒｇ＠ａｌｃａｔｅｌ−ｌｕｃｅｎｔ．ｃｏｍである場合、送信側ｄメールクライアント２０２は、ＤＮＳサーバから、ｄメール受信者のｄメールサーバ、この場合はｄメールサーバ２０４−３のＩＰアドレスを取得する。

ステップ３０４において、ｄメールクライアントは、受信者のｄメールサーバとの安全なセッション（たとえば、図２の安全な接続２０８）を直接セットアップする。送信者認証が取得され、Ｅメールプロバイダのポリシーまたは受信者の選好あるいはその両方に従って、あるタイプの添付物が禁止されてもよい。

接続失敗の場合、ｄメールクライアントは、構成可能なパラメータに従い、接続が確立するまでそれ自体のストレージを使用して再試行を実施する責任があり、これは既存のＥメールの標準的な手順とちょうど同じである。接続がない場合、クライアント自体のストレージは、当然ながらオフラインで動作するために使用されることがあり、現在はＥメールソフトウェアで行われる。

ステップ３０６において、ｄメールクライアントは、任意の許可された添付物とともに送信者のメッセージを預ける。

ステップ３０８において、ｄメールクライアントは送達受領証を取得する。ある例において、受領証は、その受領証の日付および時間が入ったメッセージの署名済みハッシュであり得る。

Ｅメールセキュリティの強化が例示的な本発明の実施形態に従って実現されるのはステップ３０４であることに留意されたい。一例として、図４は、安全なセッションの確立の例を含むｄメールクライアントとｄメールサーバの対話をさらに記載している。

図４は、本発明の一実施形態による、ダイレクト電子メールシステムにおける認証オペレーションについてのメッセージの流れを示す図である。より具体的には、図４は、ｄメールクライアント４０２とｄメールサーバ４０４の間のプロトコル４００を示す。ｄメールサーバ４０４は、特定のメッセージ受信者（図示せず）のｄメールサーバである。

図示されているように、ステップ４０６において、Ｅメールの書き手がメッセージを作成する間、ｄメールクライアントは定期的にＥメールメッセージを保存する。

プロトコル４００は、ｄメールクライアント４０２とｄメールサーバ４０４が、ステップ４０８においてトランスポート層セキュリティ（ＴＬＳ）接続をセットアップするところから始まる。知られているように、ＴＬＳは、インターネット上でセキュリティを実現する暗号のプロトコルであり、「Ｔｈｅ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＴＬＳ） Ｐｒｏｔｏｃｏｌ」と題されたＩＥＦＴ ＲＦＣ５２４６、バージョン１．２に定義されており、その開示は、引用によりその全体が本明細書に組み込まれている。ＴＬＳ接続はｄメールクライアントとｄメールサーバの間の通信を保護する。ＴＬＳ接続はまた、ｄメールクライアントと後述される識別子提供部との間の通信も保護することができる。識別子提供部がｄメールクライアントと同じイントラネット内にある場合、ＴＬＳ接続は通常は配備されない。

ステップ４１０において、ｄメールセッションセットアップ要求がｄメールクライアント４０２からｄメールサーバ４０４に送信される。ｄメールサーバ４０４は、ステップ４１２において、ｄメールクライアント４０２が認証されない場合、返送認証要求をｄメールクライアントに送信する。ステップ４１４において、ｄメールクライアント４０２は、その識別子を証明する相手である識別子提供部４１５と対話する。その結果、ｄメールクライアント４０２は、アサートする物／人であることを証明するためにｄメールサーバ４０４に提示できるトークンまたはアサーション（識別子情報）を受け取る。

ｄメールクライアント４０２は、ステップ４１６において、ＨＴＴＰポスト要求によって識別子情報をｄメールサーバ４０４に送る。ステップ４１８において、ｄメールサーバ４０４は識別子情報を確認する。そうするために、ｄメールサーバは別途識別子提供部４１５と通信することができるが、適切な署名のトークンがある場合、これはスキップされ得る。この場合、識別子提供部４１５はサーバの署名を確認するだけでよい。

ｄメールクライアント４０２が確認された場合、ｄメールサーバ４０４は、ステップ４２０において、確認応答メッセージ（ＨＴＴＰ 返送 ２００ ＯＫのメッセージ）をｄメールクライアント４０２に送る。

認証されると、ｄメールクライアント４０２は、ステップ４２２のＨＴＴＰポスト要求によって、Ｅメールメッセージをｄメールサーバ４０４に預ける。ステップ４２４に示されるように、ｄメールサーバ４０４は、（ステップ４２２において）メッセージの送信者が認証された識別子（すなわちステップ４１８において確認されたエンティティ）に一致する場合、Ｅメールメッセージの処理に進む。そうである場合、ｄメールサーバ４０４はＵＲＩを格納し、それをポストされたメッセージに割り当てる。

ｄメールサーバ４０４は、ステップ４２６において、ＨＴＴＰリダイレクトコマンドをｄメールクライアント４０２に送る。それに応答して、ステップ４２８において、ｄメールクライアント４０２は、ＨＴＴＰ取得要求をｄメールサーバ４０４に発行して、リダイレクトされたＵＲＩ（すなわち、ステップ４２４においてｄメールサーバ４０４によってＥメールメッセージに割り当てられたＵＲＩ）を取得する。このポスト−リダイレクト−取得（Ｐｏｓｔ−Ｒｅｄｉｒｅｃｔ−Ｇｅｔ）の手順は、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）の枠組み、すなわち、ワールドワイドウェブなどの分散通信ネットワークで使用されるウェブサービス設計モデルに共通している。サーバは通常、状態をもたないのでＰＲＧが使用され、クライアントがリソースを見ることを可能にするのが３つの方法の組合せ（ＰＲＧ）である。たとえば、ウェブ上で注文を受けるためのフォームに記入するとき、それをクリックして送ると、見ることはできなくなるはずである。返送できるリソースの作成をもたらすのがＰＲＧである。したがって、同じＰＲＧ手順によって、クライアントは、現在もｄメールサーバに格納されている預けたＥメールメッセージにアクセスできるようになる。

ステップ４３０において、ｄメールサーバ４０４は、ｄメールクライアント４０２によって預けられたＥメールメッセージがメッセージ受信者（図示せず）に送られたことがｄメールサーバ４０４によって署名された確認応答メッセージをｄメールクライアント４０２に送る。

ステップ４３２において、ｄメールクライアント４０２は、ｄメールセッションおよびＴＬＳ接続を終了するための要求をｄメールサーバ４０４に送る。ステップ４３４において、確認応答メッセージ（ＨＴＴＰ 返送 ２００ ＯＫ）が、ｄメールサーバ４０４によってｄメールクライアント４０２に送られる。メッセージ受信者（別のｄメールクライアント）は、預けられたＥメールメッセージをｄメールサーバ４０４に要求して、そのメッセージを受信することに留意されたい。メッセージ受信者のｄメールクライアントは、新たに預けられたＥメールを確認するように促されてもよい。

例示的な実施形態において、ｄメールクライアント４０２、ｄメールサーバ４０４、識別子提供部４１５の間の対話は、アイデンティファイフェデレーション（ｉｄｅｎｔｉｆｙ ｆｅｄｅｒａｔｉｏｎ）またはＯＡｕｔｈ２．０プロトコルなどによるものであり得ることを理解されたい。知られているように、「アイデンティティフェデレーション」は、異種のシステム同士が対話できるように複数の識別子を関連づけるためのプロトコルであり、一方、ＯＡｕｔｈ２．０は認証のためのオープンな標準規格であり、「Ｔｈｅ ＯＡｕｔｈ ２．０ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ ｄｒａｆｔ−ｉｅｆｔ−ｏａｕｔｈ−ｖ２−３０」と題された２０１２年７月１５日付けのＩＥＴＦ Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔに定義され、その開示は、引用によりその全体が本明細書に組み込まれている。

図５は、本発明の別の実施形態による、ダイレクト電子メールシステムにおける認証オペレーションについてのメッセージの流れを示す図である。より具体的には、図５は、アイデンティティフェデレーションによる対話を示す。

図示されているように、プロトコル５００は、ｄメールクライアント５０２と、ｄメールサーバ５０４と、識別子提供部５０６との間で実行される。図５のステップ５０８から５２２は図４のステップ４１２から４１８に対応することに留意されたい。

ステップ５０８において、ｄメールサーバ５０４が認証要求をｄメールクライアント５０２に送る。それに応答して、ステップ５１０において、ｄメールクライアント５０２のブラウザプログラムが識別子提供部５０６にリダイレクトされる。次いで、ステップ５１２において、認証要求がｄメールクライアント５０２から識別子提供部５０６に送られる。

ステップ５１４において、ｄメールクライアント５０２と識別子提供部５０６の間に認証交換が存在する。交換は方法に固有のものであり、方法は、アイデンティティフェデレーション環境、たとえば、Ｂａｓｉｃ ＨＴＴＰ Ｄｉｇｅｓｔ、公開鍵基盤、Ｋｅｒｂｅｒｏｓ、ＯｐｅｎＩＤ、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ、またはＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で使用されるいずれかの既存の認証方法であり得る。

認証交換の結果、ステップ５１６において、識別子提供部５０６は、ｄメールクライアント５０２に認証情報（たとえば、アサーション）を提供する。ｄメールクライアント５０２のブラウザは、ステップ５１８において、ｄメールサーバ５０６に戻るようにリダイレクトされる。次いで、ステップ５２０において、認証情報はｄメールクライアント５０２によってｄメールサーバ５０４に提供される。次いで、ステップ５２２において、ｄメールサーバ５０６は、署名をチェックするかまたは識別子提供部５０６との直接通信によって、アサーションを確認する。

図６は、本発明のさらに別の実施形態による、ダイレクト電子メールシステムにおける認証オペレーションについてのメッセージの流れを示す図である。より具体的には、図６は、ＯＡｕｔｈ２．０による対話を示す。

図示されているように、プロトコル６００は、ｄメールクライアント６０２と、ｄメールサーバ６０４と、識別提供部６０６との間で実行される。図６のステップ６０８から６２８は図４のステップ４１２から４１８に対応することに留意されたい。

ステップ６０８において、ｄメールサーバ６０４は認証要求をｄメールクライアント６０２に送る。それに応答して、ステップ６１０において、ｄメールクライアント６０２のブラウザプログラムが識別子提供部６０６にリダイレクトされる。次いで、ステップ６１２において、認証要求がｄメールクライアント６０２から識別子提供部６０６に送られる。

ステップ６１４において、ｄメールクライアント６０２と識別子提供部６０６の間に認証交換が存在する。交換は方法に固有のものであり、方法は、オープンな標準認証環境、たとえば、ＨＴＴＰ ｂａｓｉｃ、Ｋｅｒｂｅｒｏｓにおいて、またはＸ．５０９の証明書チェーンによって補足されるプライベート鍵署名によって使用されるいずれかの既存の認証方法であり得る。

認証交換の結果、ステップ６１６において、識別子提供部６０６は、ｄメールクライアント６０２に認証応答（たとえば、認証コード）を提供する。ｄメールクライアント６０２のブラウザは、ステップ６１８において、ｄメールサーバ６０６に戻るようにリダイレクトされる。次いで、ステップ６２０において、認証応答はｄメールクライアント６０２によってｄメールサーバ６０４に提供される。次いで、ステップ６２２において、ｄメールサーバ６０６は認証コードを確認する。ステップ６２４において、識別子提供部６０６は、認証トークンをｄメールサーバ６０４に要求する。ステップ６２６において、ｄメールサーバ６０４は、ユーザ情報要求（たとえば、アクセストークン）を識別子提供部６０６に提供する。それに応答して、識別子提供部６０６は、ｄメールサーバ６０４に送信者（ｄメールクライアント６０２）情報を提供し、それによってｄメールサーバ６０４はｄメールクライアント６０２の識別子を確認できるようになる。

ｄメールサーバに預けられたＥメールメッセージを取り出すために、取り出すユーザ（図５および図６には示していない別のｄメールクライアント）もまた認証される必要があることをさらに理解されたい。１つまたは複数の例示的な実施形態において、メッセージ受信者のＥメールクライアントについての認証の流れは、図５および図６にそれぞれ示されたメッセージの流れに類似しており、そのため、本明細書における詳細な説明から当業者には簡単に認識されよう。

最後に、図７は、本発明の１つまたは複数の実施形態による、認証手順を含むダイレクト電子メールの実施に適した通信ネットワーク７００のコンピューティングアーキテクチャを示す。

図示されているように、コンピューティング装置７１０（たとえば、ｄメールクライアントに対応）、コンピューティング装置７２０（たとえば、ｄメールサーバに対応）、およびコンピューティング装置７３０（たとえば、識別子提供部に対応）は、通信ネットワーク媒体７４０を介して動作可能に結合されている。ネットワーク媒体は、コンピューティング装置が通信するために動作可能な任意のネットワーク媒体であり得る。一例として、ネットワーク媒体は、ワールドワイドウェブの一部の任意の媒体であり得る。ただし、本発明の実施形態は特定のタイプのネットワーク媒体には限定されない。

当業者にはすぐに明らになるように、サーバ、クライアント、および他のコンピューティング装置は、コンピュータプログラムコードの制御下で動作するプログラム制御型コンピュータとして実装され得る。コンピュータプログラムコードは、一時的でない（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ）コンピュータ（すなわちプロセッサまたは機械）可読記憶媒体（たとえば、メモリ）に記憶され、コードはコンピュータのプロセッサによって実行されることになろう。本発明の種々の例示的な実施形態の本開示を考慮すると、当業者は、本明細書に記載のプロトコルを実施するために、適切なコンピュータプログラムコードを容易に作り出すことができよう。

それでもなお、図７に、ネットワーク媒体を介して通信するデバイスごとの例示的なアーキテクチャを一般的に示す。図示されているように、ｄメールクライアントデバイス７１０は、Ｉ／Ｏデバイス７１２、プロセッサ７１４、およびメモリ７１６を備える。ｄメールサーバデバイス７２０は、Ｉ／Ｏデバイス７２２、プロセッサ７２４、およびメモリ７２６を備える。識別子提供装置７３０は、Ｉ／Ｏデバイス７３２、プロセッサ７３４、およびメモリ７３６を備える。

本明細書で使用される用語「プロセッサ」は、中央処理装置（ＣＰＵ）または他の処理回路を含む１つまたは複数の処理装置を含むことが意図されており、これには、限定はしないが１つまたは複数の信号プロセッサ、１つまたは複数の集積回路などが挙げられることが理解されるはずである。また、本明細書で使用される用語「メモリ」は、ＲＡＭ、ＲＯＭ、固定メモリデバイス（たとえば、ハードディスクドライブ）、または取り外し可能なメモリデバイス（たとえば、ディスケットまたはＣＤＲＯＭ）などの、プロセッサまたはＣＰＵに関連づけられたメモリを含むことが意図されている。さらに、本明細書で使用される用語「Ｉ／Ｏデバイス」は、データを処理ユニットに入力するための１つまたは複数の入力デバイス（たとえば、キーボード、マウス）、さらには処理ユニットに関連する結果を提供するための１つまたは複数の出力デバイス（たとえば、コンピュータディスプレイ）を含むことが意図されている。

したがって、本明細書に記載された本発明の方法を実施するためのソフトウェアの命令またはコードが、関連づけられたメモリデバイス、たとえば、ＲＯＭ、固定型または取り外し可能なメモリのうちの１つまたは複数に記憶されていてもよく、使用の準備ができたとき、ＲＡＭにロードされ、ＣＰＵによって実行される。すなわち、図７に示された各コンピューティング装置（７１０、７２０、および７３０）は、図３および図６に示された方法およびプロトコルのそれぞれのステップを実行するために個別にプログラム化されていてもよい。

有利には、本発明の実施形態は、現在の（旧式の）Ｅメールシステムを単純化しながら、送信者認証およびコンテンツ制御によってスパムを除去するための単純な機構を設けている。より具体的には、各実施形態はＥメール送信者の認証を実現する。その結果、送信者偽装によるスパムは完全に除去され得る。さらに、実施形態は、メッセージ送信者のクライアントがＥメールメッセージをメッセージ受信者のＥメールサーバに直接的に預けられるようにすることによって、Ｅメール送達インフラ全体を単純化し、システム全体にわたって複製されるメッセージの数を著しく減らす（したがって、Ｅメールシステムにおけるメールプロキシでメッセージが複製されることが回避される）。各実施形態はウェブサービスにも適用可能である。すなわち、Ｅメールクライアントによって実行されるステップ／動作は、クライアントのブラウザで実行される１つもしくは複数の独立型のアプリケーションまたはＪａｖａＳｃｒｉｐｔ（登録商標）アプレットのいずれかによって実行されることがあり、あるいはＨＴＭＬ５で記述されたページによって実行されることもあり得る。

本発明の例示の実施形態は添付の図面に関連づけて本明細書に記載されているが、本発明はそれらの厳密な実施形態には限定されず、さまざまな他の変更および修正が本発明の範囲または趣旨から逸脱することなく当業者によって行われ得ることが理解されるはずである。

Claims (10)

1. 電子メールシステムにおいて電子メールメッセージを処理する方法であって、
   電子メールシステムにおいてメッセージ送信者のクライアントとメッセージ受信者のサーバの間に安全な接続を確立するステップと、
   メッセージ送信者のクライアントの識別子を確認するために認証交換に関与するステップと、
   メッセージ送信者のクライアントの識別子の確認が成功すると、メッセージ送信者のクライアントが、電子メールメッセージをメッセージ受信者のサーバに預けるステップと
   を含む、方法。
2. メッセージ送信者のクライアントにおいて、電子メールメッセージがメッセージ受信者のサーバに送達されたことの確認応答を受け取るステップをさらに含む、請求項１に記載の方法。
3. メッセージ送信者のクライアントが、電子メールメッセージが送達されるアドレスを取得するステップをさらに含む、請求項１に記載の方法。
4. 認証交換が識別子提供部を関与させる、請求項１に記載の方法。
5. 認証交換がアイデンティティフェデレーションプロトコルに従って行われる、請求項１に記載の方法。
6. 認証交換が、オープンな標準認証プロトコルに従って行われる、請求項１に記載の方法。
7. メッセージ送信者のクライアントとメッセージ受信者のサーバとの間の通信の少なくとも一部が、ＨｙｐｅｒＴｅｘｔトランスポートプロトコルを使用する、請求項１に記載の方法。
8. 電子メールシステムにおいて電子メールメッセージを処理する装置であって、
   メモリと、
   メモリに結合されており、メッセージ送信者のクライアントが実行されたときに、メッセージ送信者のクライアントとメッセージ受信者のサーバの間に安全な接続を確立し、クライアントの識別子を確認するために認証交換に関与し、クライアントの識別子の確認が成功すると、電子メールメッセージをメッセージ受信者のサーバに預けるようにメッセージ送信者のクライアントを実行するように構成されたプロセッサと
   を備える、装置。
9. 電子メールシステムにおいて電子メールメッセージを処理する方法であって、
   電子メールシステムにおいてメッセージ送信者のクライアントとメッセージ受信者のサーバの間に安全な接続を確立するステップと、
   メッセージ送信者のクライアントの識別子を確認するために認証交換に関与するステップと、
   メッセージ送信者のクライアントの識別子の確認が成功すると、メッセージ受信者のサーバが、メッセージ送信者のクライアントによって送信された電子メールメッセージを受信するステップと
   を含む、方法。
10. 電子メールシステムにおいて電子メールメッセージを処理する装置であって、
    メモリと、
    メモリに結合されており、メッセージ受信者のサーバが実行されたときに、メッセージ送信者のクライアントとメッセージ受信者のサーバの間に安全な接続を確立し、クライアントの識別子を確認するために認証交換に関与し、メッセージ送信者のクライアントの識別子の確認が成功すると、メッセージ送信者のクライアントによって送信された電子メールメッセージを受信するようにメッセージ受信者のサーバを実行するように構成されたプロセッサと
    を備える、装置。

Images