(57)【要約】  インターネットを通じたインターフェースをもつメッセージ交換システムにおいて、送信者サーバーを通じてインターネットへのインターフェースをもつ送信者から受信者サーバーを通じてインターネットへのインターフェースをもつ少なくとも一受信者に配送すべく宛てられた、少なくとも受信者情報およびメッセージボディを含むメッセージを処理するための方法が開示される。当該方法は、前記送信者サーバーから前記受信者サーバーへのインターネットを通じた一時的な試験接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者への当該メッセージの配送可能性の指標を提供する。
2007535011.tif 000002
【特許請求の範囲】
【請求項１】
インターネットを通じたインターフェースをもつメッセージ交換システムにおいて、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ送信者から少なくとも一受信者に配送すべく宛てられた、少なくとも受信者情報およびメッセージボディを含むメッセージを処理するための方法であって：
前記送信者サーバーから前記受信者サーバーへのインターネットを通じた接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者への当該メッセージの配送可能性の指標を提供する、
ことを有することを特徴とする方法。
【請求項２】
前記接続確立が一時的な試験接続であり、前記メッセージを送るための前記受信者情報に頼る前に行われることを特徴とする、請求項１記載の方法。
【請求項３】
前記接続確立が前記メッセージを送るための前記受信者情報に頼る前に行われ、
前記指標に基づいて、（ｉ）前記メッセージを前記受信者への前記接続を通じて前記受信者サーバーに向けるか、（ｉｉ）前記メッセージの配送を中止するかのうちの一つを実行する、
ことを有することを特徴とする、請求項１記載の方法。
【請求項４】
前記受信者情報の試験が、該受信者情報に従って前記受信者への前記メッセージの配送可能性を確認することであり、確認は前記送信者サーバーと前記受信者サーバーとの間のインターネットを通じた前記接続の前記確立と、
前記接続を用いて、前記ＳＭＴＰのＶＲＦＹコマンドを使うことなく、前記受信者サーバーとともに前記受信者情報を、前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもつかどうかに関して検証することによって前記指標を提供するようにし、該指標が前記受信者が確かに前記受信者サーバーを通じてインターネットへのインターフェースをもっているという肯定的な確証および前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもっていないことを示す否定のうちの一つである、
ことを含むことを特徴とする、請求項１記載の方法。
【請求項５】
前記指標に基づいて、（ｉ）前記送信者サーバーから前記受信者サーバーにインターネットを通じた配送接続を確立してそれから前記メッセージを前記受信者への配送のために前記受信者サーバーに向けるか、（ｉｉ）前記受信者への前記メッセージの配送を中止するかのうちの一つを実行する、
ことをさらに有することを特徴とする、請求項１または２記載の方法。
【請求項６】
前記メッセージの配送可能性に関するレコードを生成することをさらに有することを特徴とする、請求項１ないし３のうちいずれか一項記載の方法。
【請求項７】
前記指標に基づいて、（ｉ）前記肯定的確証に反応してそのようにして生成された前記メッセージを前記受信者への配送のために前記接続を通じて前記受信者サーバーに向けるか、（ｉｉ）前記否定に反応して前記メッセージの配送を中止するかのうちの一つを実行すること、
をさらに有することを特徴とする請求項４記載の方法。
【請求項８】
前記メッセージがさらに送信者情報を含んでおり、当該方法が：
前記受信者サーバーに前記メッセージを向ける前に、あるいは前記配送接続を確立する前に、前記送信者サーバーにおける複数のＩＰアドレスを選択し、
所定の規則セットに従って前記複数のＩＰアドレスのある一つを指定し、
前記メッセージの前記送信者情報の一部として前記複数のＩＰアドレスの前記ある一つを含める、
ことをさらに有することを特徴とする、請求項１ないし４のうちいずれか一項記載の方法。
【請求項９】
前記指標に関するレコードを生成することをさらに有することを特徴とする、請求項４記載の方法。
【請求項１０】
前記メッセージ交換システムがデータを処理するための電子メモリおよびファイルを保存するためのハードディスクドライブを含んでおり、当該方法が：
前記メッセージを前記ハードディスクドライブの前記ファイルの一つとして保存することなく前記電子メモリ内のデータとして前記メッセージを扱う、
ことをさらに有することを特徴とする、請求項１ないし４のうちいずれか一項記載の方法。
【請求項１１】
前記接続が一時的な試験接続であり、前記検証が該一時的な試験接続を通じたものであることを特徴とする、請求項４記載の方法。
【請求項１２】
前記指標に基づいて、（ｉ）前記肯定的確証に反応して少なくとも前記受信者情報およびメッセージボディを組み合わせることによって前記メッセージを生成し、次いで前記送信者サーバーと前記受信者サーバーとの間のインターネットを通じた配送接続を確立し、続いてそのようにして生成された前記メッセージを前記受信者への配送のために前記配送接続を通じて前記受信者サーバーに向けるか、（ｉｉ）前記否定に反応して前記メッセージの配送を中止するかのうちの一つを実行する、
ことをさらに有することを特徴とする、請求項１１記載の方法。
【請求項１３】
前記受信者情報を試験することまたは前記一時的な試験接続を使うことが、前記受信者情報が有効であることを認証するために受信者サーバーに問い合わせをすることを含むことを特徴とする、請求項１、２または１１記載の方法。
【請求項１４】
前記受信者情報を試験することまたは前記一時的な試験接続を使うことが、前記受信者サーバーがはいってくるメッセージを受信するために利用可能であることを確かめることを含むことを特徴とする、請求項１、２または１１記載の方法。
【請求項１５】
インターネットを通じたインターフェースをもつメッセージ交換システムにおいて、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ送信者から少なくとも一受信者に配送すべく宛てられたメッセージを処理するための方法であって：
送信者サーバーにおいて前記送信者から当該メッセージを定義するのに使う複数の離散的なデータパケットを受信し、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでおり、
当該メッセージを送るための前記受信者情報に頼る前に前記送信者サーバーから前記受信者サーバーへのインターネットを通じた接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者への配送可能性の指標を提供し、
前記指標に基づいて、（ｉ）少なくとも前記受信者情報およびメッセージボディを組み合わせることによって当該メッセージを生成し、次いで前記受信者への配送のために前記接続を通じて前記受信者サーバーに向けるか、（ｉｉ）当該メッセージの配送を中止するかのうちの一つを実行する、
ことを有することを特徴とする方法。
【請求項１６】
前記受信者情報の前記試験がインターネットを通じた一時的な試験接続を確立することによって行われ、前記メッセージを向けることが前記送信者サーバーから前記受信者サーバーへのインターネットを通じた配送接続を確立することである、ことを特徴とする、請求項１５記載の方法。
【請求項１７】
前記メッセージがさらに送信者情報を含んでおり、前記メッセージの生成が：
前記送信者サーバーにおける複数のＩＰアドレスを選択し、
所定の規則セットに従って前記複数のＩＰアドレスのある一つを指定し、
前記メッセージの前記送信者情報の一部として前記複数のＩＰアドレスの前記ある一つを含める、
ことを含むことを特徴とする、請求項１６記載の方法。
【請求項１８】
前記送信者から前記複数の離散的なデータパケットを受信することが人間のユーザーによって生成された前記複数の離散的なデータパケットを処理することを含む、ことを特徴とする、請求項１５または１６記載の方法。
【請求項１９】
前記送信者から前記複数の離散的なデータパケットを受信することがソフトウェアアプリケーションによって生成された前記複数の離散的なデータパケットを処理することを含む、ことを特徴とする、請求項１５または１６記載の方法。
【請求項２０】
前記ソフトウェアアプリケーションにデータベースとのインターフェースをもたせ、
前記データベース中にトリガーイベントを定義することで、該トリガーイベントが前記データベース中で発生したときに前記ソフトウェアアプリケーションが自動的に前記複数の離散的なデータパケットを生成するようにする、
ことをさらに有することを特徴とする、請求項１９記載の方法。
【請求項２１】
インターネットを通じたインターフェースをもつメッセージ交換システムにおいて、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ送信者から少なくとも一受信者に配送すべく宛てられたメッセージを処理するための方法であって：
送信者サーバーにおいて前記送信者から当該メッセージを定義するのに使う複数の離散的なデータパケットを受信し、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでおり、
前記送信者サーバーと前記受信者サーバーとの間のインターネットを通じた接続を確立することによって前記受信者情報に従って前記受信者への前記メッセージの配送可能性を確認し、
前記送信者サーバーから、前記接続を通じて、ＳＭＴＰのＶＲＦＹコマンドを使うことなく、前記受信者サーバーとともに前記受信者情報を、前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもつかどうかに関して検証することによって指標を提供するようにし、該指標が前記受信者が確かに前記受信者サーバーを通じてインターネットへのインターフェースをもっているという肯定的な確証および前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもっていないことを示す否定のうちの一つであり、
前記指標に基づいて、（ｉ）前記肯定的確証に反応して少なくとも前記受信者情報およびメッセージボディを組み合わせることによって当該メッセージを生成し、次いで前記受信者への配送のために前記接続を通じて前記受信者サーバーに当該メッセージを向けるか、（ｉｉ）前記否定に反応して当該メッセージの配送を中止するかのうちの一つを実行する、
ことを有することを特徴とする方法。
【請求項２２】
インターネットを通じたインターフェースをもつメッセージ交換システムにおいて、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ送信者から少なくとも一受信者に配送すべく宛てられたメッセージを処理するための方法であって：
送信者サーバーにおいて前記送信者から当該メッセージを定義するのに使う複数の離散的なデータパケットを受信し、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでおり、
前記送信者サーバーと前記受信者サーバーとの間のインターネットを通じた一時的な試験接続を確立することによって前記受信者情報に従って前記受信者に前記メッセージが配送可能性であることを確認し、
前記送信者サーバーから、前記一時的な試験接続を通じて、ＳＭＴＰのＶＲＦＹコマンドを使うことなく、前記受信者サーバーとともに前記受信者情報を、前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもつかどうかに関して検証することによって前記指標を提供するようにし、該指標が前記受信者が確かに前記受信者サーバーを通じてインターネットへのインターフェースをもっているという肯定的な確証および前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもっていないことを示す否定のうちの一つであり、
前記指標に基づいて、（ｉ）前記肯定的確証に反応して少なくとも前記受信者情報およびメッセージボディを組み合わせることによって当該メッセージを生成し、次いで前記送信者サーバーと前記受信者サーバーとの間のインターネットを通じた配送接続を確立し、続いて前記受信者への配送のために前記接続を通じて前記受信者サーバーに当該メッセージを向けるか、（ｉｉ）前記否定に反応して当該メッセージの配送を中止するかのうちの一つを実行する、
ことを有することを特徴とする方法。
【請求項２３】
送信者から少なくとも一受信者に配送すべく宛てられたメッセージを処理するためのインターネットへのインターフェースをもつ、未修正のメッセージサーバーを置き換えるよう構成された修正メッセージサーバーであって、送信者は、受信者サーバーと通信することのできる前記未修正メッセージサーバーを通じてインターネットへのインターフェースをもち、前記未修正メッセージサーバーは、当該メッセージをメッセージファイルとして保存するために構成されたハードディスクドライブを含み、前記未修正メッセージサーバーは該メッセージファイルを前記受信者サーバーに転送するよう構成されており、
当該修正メッセージサーバーが当該メッセージを定義するのに使う複数の離散的なデータパケットを前記送信者から受信するための手段を有し、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでおり、当該修正された受信設備は前記複数の離散的なデータパケットを保存するための電子メモリを含んでおり、
当該修正メッセージサーバーが前記複数の離散的なデータパケットを処理し、当該メッセージを少なくとも前記受信者情報およびメッセージボディを組み合わせることによって生成するための手段をも有する、
ことを特徴とする修正メッセージサーバー。
【請求項２４】
前記修正メッセージサーバーから前記受信者サーバーへのインターネットを通じた接続を確立し、前記接続を用いて、ＳＭＴＰのＶＲＦＹコマンドを使うことなく、前記受信者サーバーとともに前記受信者情報を、前記メッセージを送るための前記受信者情報に頼る前に、前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもつかどうかに関して検証することによって指標を提供するようにし、該指標が前記受信者が確かに前記受信者サーバーを通じてインターネットへのインターフェースをもっているという肯定的な確証および前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもっていないことを示す否定のうちの一つであるような手段、
をさらに有することを特徴とする、請求項２３記載の修正メッセージサーバー。
【請求項２５】
前記処理手段が、前記指標に基づいて、（ｉ）前記肯定的確証に反応してそのようにして生成された前記メッセージを前記受信者への配送のために前記接続を通じて前記受信者サーバーに向けるか、（ｉｉ）前記否定に反応して前記メッセージの配送を中止するかのうちの一つを実行するよう構成されていることを特徴とする請求項２４記載の修正メッセージサーバー。
【請求項２６】
前記処理手段が、前記試験手段が前記肯定的確証を与えたのちにのみ前記メッセージを生成するよう構成されていることを特徴とする、請求項２４記載の修正メッセージサーバー。
【請求項２７】
インターネットを通じたインターフェースをもつメッセージ交換システムにおいて、送信者からの一群のメッセージを処理するための方法であって、送信者は、複数の受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもち、前記一群のメッセージのそれぞれは受信者に配送すべく宛てられており、当該方法は：
送信者サーバーにおいて前記送信者から前記一群のメッセージを定義するのに使う複数の離散的なデータパケットを受信し、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つは前記一群のメッセージのうちの対応するメッセージのメッセージボディを含んでおり、
前記一群のメッセージのそれぞれについての少なくとも前記受信者情報およびメッセージボディを組み合わせることによって前記一群のメッセージを生成し、
該一群のメッセージのそれぞれの前記受信者情報および前記メッセージボディのうちの少なくとも一方に基づく所定の規則セットに従った順序に前記一群のメッセージを配列する、ことを有することを特徴とする方法。
【請求項２８】
前記一群のメッセージのそれぞれについて：
前記一群のメッセージのうちの対応するメッセージを送るための前記受信者情報に頼る前に、前記送信者サーバーから前記複数の受信者サーバーのうちの対応するサーバーへのインターネットを通じた接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのＶＲＦＹコマンドを使うことなく前記複数の受信者のうちの対応する受信者への配送可能性の指標を与えるようにし、
前記指標に基づいて、（ｉ）前記一群のメッセージのうちの当該メッセージを、前記複数の受信者サーバーのうちの前記対応するサーバーを通じた配送のために前記接続を通じて前記複数の受信者のうちの一に向けるか、（ｉｉ）前記一群のメッセージのうちの当該メッセージの配送を中止するかのうちの一つを実行する、
ことをさらに有することを特徴とする、請求項２７記載の方法。
【請求項２９】
前記一群のメッセージのそれぞれについて：
前記一群のメッセージのうちの対応するメッセージを送るための前記受信者情報に頼る前に、前記送信者サーバーから前記複数の受信者サーバーのうちの対応するサーバーへのインターネットを通じた一時的な試験接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのＶＲＦＹコマンドを使うことなく前記複数の受信者のうちの対応する受信者への配送可能性の指標を与えるようにし、
前記指標に基づいて、（ｉ）前記送信者サーバーから前記複数の受信者サーバーのうちの対応するサーバーへのインターネットを通じた配送接続を確立し、前記一群のメッセージのうちの当該メッセージを、前記複数の受信者サーバーのうちの前記対応するサーバーを通じた配送のために前記配送接続を通じて前記複数の受信者のうちの一に向けるか、（ｉｉ）前記一群のメッセージのうちの当該メッセージの配送を中止するかのうちの一つを実行する、
ことをさらに有することを特徴とする、請求項２７記載の方法。
【請求項３０】
前記複数の離散的なデータパケットのうちの別の一つが前記一群のメッセージのうちの対応するメッセージについての送信者情報を含んでおり、前記一群のメッセージを生成することがさらに：
前記送信者サーバーにおける複数のＩＰアドレスを選択し、
所定の規則セットに従って前記複数のＩＰアドレスのある一つを指定し、
前記一群のメッセージのうちのそれぞれの前記送信者情報の一部として前記複数のＩＰアドレスの前記ある一つを含める、
ことをさらに含むことを特徴とする、請求項２７記載の方法。
【請求項３１】
インターネットを通じたインターフェースをもつメッセージ交換システムにおいて、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ送信者から少なくとも一受信者に配送すべく宛てられたメッセージを処理するための方法であって：
送信者サーバーにおいて前記送信者から当該メッセージを定義するのに使う複数の離散的なデータパケットを受信し、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでおり、
（ｉ）前記複数の離散的なデータパケットを第一の所定の規則セットに従って修正すること、（ｉｉ）前記複数の離散的なデータパケットに第二の所定の規則セットに従って追加データパケットを加えること、（ｉｉｉ）前記複数の離散的なデータパケットを第三の所定の規則セットに従って順序付けること、のうちの少なくとも一つを実行するためであって、結果として複数の結果データパケットを与えるための複数の外部アプリケーションのうちの一つへのアプリケーションプログラムインターフェースを通じて前記複数の離散的なデータパケットを差し向け、
前記アプリケーションプログラムインターフェースを通じて複数の外部アプリケーションの前記一つから前記複数の結果データパケットを受信し、
前記複数の結果データパケットのうちの少なくとも一部分を組み合わせることによって前記メッセージを生成し、
前記送信者サーバーから前記受信者サーバーへインターネットを通じた接続を確立し、
前記接続を通じて前記メッセージを前記受信者サーバーに前記受信者への配送のために向ける、
ことを有することを特徴とする方法。
【請求項３２】
送信者からの少なくとも一受信者に配送すべく宛てられたメッセージを処理するための、インターネットを通じたインターフェースをもつメッセージ交換システムであって、送信者は、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもち、前記メッセージは少なくとも受信者情報およびメッセージボディを含み、当該メッセージ交換システムが：
当該メッセージを送るための前記受信者情報に頼る前に前記送信者サーバーから前記受信者サーバーへのインターネットを通じた一時的な試験接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者への当該メッセージの配送可能性の指標を提供するための試験設備を含む、
ことを特徴とするメッセージ交換システム。
【請求項３３】
前記接続確立が一時的な試験接続であることを特徴とする、請求項３２記載のシステム。
【請求項３４】
前記指標に基づいて、（ｉ）前記送信者サーバーから前記受信者サーバーにインターネットを通じた配送接続を確立してそれから前記メッセージを前記受信者への配送のために前記受信者サーバーに向けるか、（ｉｉ）前記受信者への前記メッセージの配送を中止するかのうちの一つを実行するための選択的配送設備、
をさらに有することを特徴とする、請求項３２または３３記載のメッセージ交換システム。
【請求項３５】
データを処理するための電子メモリおよびファイルを保存するためのハードディスクドライブをさらに有しており、前記メッセージを前記ハードディスクドライブの前記ファイルの一つとして保存することなく前記電子メモリ内のデータとして前記メッセージを処理するよう構成されていることを特徴とする、請求項３２または３３記載のメッセージ交換システム。
【請求項３６】
（ｉ）前記メッセージを前記受信者への配送のために前記接続を通じて前記受信者サーバーに向けるか、（ｉｉ）前記メッセージの配送を中止するかのうちの一つを実行するための選択的配送設備、
をさらに有することを特徴とする、請求項３２記載のメッセージ交換システム。
【請求項３７】
送信者からの少なくとも一受信者に配送すべく宛てられたメッセージを処理するためのインターネットを通じたインターフェースをもつメッセージ交換システムであって、送信者は、送信者サーバーを通じてインターネットへのインターフェースをもち、受信者は受信者サーバーを通じてインターネットへのインターフェースをもち、前記メッセージは少なくとも送信者情報、受信者情報およびメッセージボディを含み、当該メッセージ交換システムが：
前記送信者サーバーと前記受信者サーバーとの間のインターネットを通じた接続を確立し、
前記送信者サーバーから、前記接続を使って、ＳＭＴＰのＶＲＦＹコマンドを使うことなく、前記受信者サーバーとともに前記受信者情報を、前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもつかどうかに関して検証することによって指標を提供するようにし、該指標が前記受信者が確かに前記受信者サーバーを通じてインターネットへのインターフェースをもっているという肯定的な確証および前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもっていないことを示す否定のうちの一つであるようにすることによって、
前記受信者情報に従って前記受信者への前記メッセージの配送可能性を確認するための試験設備、
を有することを特徴とする当該メッセージ交換システム。
【請求項３８】
前記指標に基づいて、（ｉ）前記肯定的確証に反応してそのようにして生成された前記メッセージを前記受信者への配送のために前記接続を通じて前記受信者サーバーに向けるか、（ｉｉ）前記否定に反応して前記メッセージの配送を中止するかのうちの一つを実行するための選択的配送設備をさらに有することを特徴とする請求項３７記載のメッセージ交換システム。
【請求項３９】
送信者からの少なくとも一受信者に配送すべく宛てられたメッセージを処理するための方法、インターネットを通じたインターフェースをもつメッセージ交換システムであって、送信者は、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもち、前記メッセージは少なくとも受信者情報およびメッセージボディを含み、当該メッセージ交換システムが：
前記送信者サーバーと前記受信者サーバーとの間のインターネットを通じた一時的な試験接続を確立し、
前記送信者サーバーから、前記一時的な試験接続を通じて、ＳＭＴＰのＶＲＦＹコマンドを使うことなく、前記受信者サーバーとともに前記受信者情報を、前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもつかどうかに関して検証することによって指標を提供するようにし、該指標が前記受信者が確かに前記受信者サーバーを通じてインターネットへのインターフェースをもっているという肯定的な確証および前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもっていないことを示す否定のうちの一つであるようにすることによって、
前記受信者情報に従って前記受信者への前記メッセージの配送可能性を確認するための試験設備、
を有することを特徴とする当該メッセージ交換システム。
【請求項４０】
前記指標に基づいて、（ｉ）前記肯定的確証に反応して少なくとも前記受信者情報およびメッセージボディを組み合わせることによって前記メッセージを生成し、次いで前記送信者サーバーと前記受信者サーバーとの間のインターネットを通じた配送接続を確立し、続いてそのようにして生成された前記メッセージを前記受信者への配送のために前記配送接続を通じて前記受信者サーバーに向けるか、（ｉｉ）前記否定に反応して前記メッセージの配送を中止するかのうちの一つを実行する、ことをさらに有することを特徴とする、請求項３９記載のメッセージ交換システム。
【請求項４１】
送信者からの少なくとも一受信者に配送すべく宛てられたメッセージを処理するためのインターネットを通じたインターフェースをもつメッセージ交換システムであって、送信者は、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもっており、当該メッセージ交換システムが：
前記送信者サーバーにおいて、前記送信者から当該メッセージを定義するのに使う複数の離散的なデータパケットを受信するための受信装置を有し、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでおり、
当該メッセージ交換システムがまた、当該メッセージを送るための前記受信者情報に頼る前に前記送信者サーバーから前記受信者サーバーへのインターネットを通じた一時的な試験接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者への配送可能性の指標を提供するための試験設備と、
前記指標に基づいて、（ｉ）少なくとも前記受信者情報およびメッセージボディを組み合わせることによって前記メッセージを生成し、それから前記送信者サーバーから前記受信者サーバーにインターネットを通じた配送接続を確立し、続いて前記メッセージを前記受信者への配送のために前記配送接続を通じて前記受信者サーバーに向けるか、（ｉｉ）前記受信者への前記メッセージの配送を中止するかのうちの一つを実行するための選択的配送設備、
とを有することを特徴とするメッセージ交換システム。
【請求項４２】
送信者からの少なくとも一受信者に配送すべく宛てられたメッセージを処理するためのインターネットを通じたインターフェースをもつメッセージ交換システムであって、送信者は、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもっており、当該メッセージ交換システムが：
前記送信者サーバーにおいて、前記送信者から当該メッセージを定義するのに使う複数の離散的なデータパケットを受信するための受信装置を有し、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでおり、
当該メッセージ交換システムがまた、当該メッセージを送るための前記受信者情報に頼る前に前記送信者サーバーから前記受信者サーバーへのインターネットを通じた接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者への配送可能性の指標を提供するための試験設備と、
前記指標に基づいて、（ｉ）少なくとも前記受信者情報およびメッセージボディを組み合わせることによって前記メッセージを生成し、それから前記メッセージを前記受信者への配送のために前記接続を通じて前記受信者サーバーに向けるか、（ｉｉ）前記受信者への前記メッセージの配送を中止するかのうちの一つを実行するための選択的配送設備、
とを有することを特徴とするメッセージ交換システム。
【請求項４３】
送信者からの少なくとも一受信者に配送すべく宛てられたメッセージを処理するためのインターネットを通じたインターフェースをもつメッセージ交換システムであって、送信者は、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもっており、当該メッセージ交換システムが：
前記送信者サーバーにおいて、前記送信者から当該メッセージを定義するのに使う複数の離散的なデータパケットを受信するための受信装置であって、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでいるような受信装置と、
前記送信者サーバーと前記受信者サーバーとの間のインターネットを通じた接続を確立し、
前記送信者サーバーから、前記接続を通じて、ＳＭＴＰのＶＲＦＹコマンドを使うことなく、前記受信者サーバーとともに前記受信者情報を、前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもつかどうかに関して検証することによって指標を提供するようにし、該指標が前記受信者が確かに前記受信者サーバーを通じてインターネットへのインターフェースをもっているという肯定的な確証および前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもっていないことを示す否定のうちの一つであるようにすることによって、
前記受信者情報に従って前記受信者への当該メッセージの配送可能性を確認するための試験設備と、
前記指標に基づいて、（ｉ）前記肯定的確証に反応して少なくとも前記受信者情報およびメッセージボディを組み合わせることによって当該メッセージを生成し、次いで前記受信者への配送のために前記接続を通じて前記受信者サーバーにそのようにして生成された前記メッセージを向けるか、（ｉｉ）前記否定に反応して当該メッセージの配送を中止するかのうちの一つを実行するための選択的配送設備、
とを有することを特徴とするメッセージ交換システム。
【請求項４４】
送信者からの少なくとも一受信者に配送すべく宛てられたメッセージを処理するためのインターネットを通じたインターフェースをもつメッセージ交換システムであって、送信者は、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもっており、当該メッセージ交換システムが：
前記送信者サーバーにおいて、前記送信者から当該メッセージを定義するのに使う複数の離散的なデータパケットを受信するための受信装置であって、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでいるような受信装置と、
前記送信者サーバーと前記受信者サーバーとの間のインターネットを通じた一時的な試験接続を確立し、
前記送信者サーバーから、前記一時的な試験接続を通じて、ＳＭＴＰのＶＲＦＹコマンドを使うことなく、前記受信者サーバーとともに前記受信者情報を、前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもつかどうかに関して検証することによって指標を提供するようにし、該指標が前記受信者が確かに前記受信者サーバーを通じてインターネットへのインターフェースをもっているという肯定的な確証および前記受信者が前記受信者サーバーを通じてインターネットへのインターフェースをもっていないことを示す否定のうちの一つであるようにすることによって、
前記受信者情報に従って前記メッセージが前記受信者に配送可能であるかどうかを確認するための試験設備と、
前記指標に基づいて、（ｉ）前記肯定的確証に反応して少なくとも前記受信者情報およびメッセージボディを組み合わせることによって当該メッセージを生成し、次いで前記送信者サーバーと前記受信者サーバーとの間にインターネットを通じた配送接続を確立し、続いて前記受信者への配送のために前記配送接続を通じて前記受信者サーバーにそのようにして生成された前記メッセージを向けるか、（ｉｉ）前記否定に反応して当該メッセージの配送を中止するかのうちの一つを実行するための選択的配送設備、
とを有することを特徴とするメッセージ交換システム。
【請求項４５】
インターネットを通じたインターフェースをもつメッセージ交換システムにおいて、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ送信者から少なくとも一受信者に配送すべく宛てられたメッセージを処理するための方法であって、前記メッセージ交換システムがデータを処理するための電子メモリを含んでおり、
前記メッセージを前記電子メモリ中のデータとして扱うことを含むことを特徴とする方法。
【請求項４６】
前記メッセージ交換システムがファイルを保存するためのハードディスクドライブをさらに含んでおり、前記メッセージの前記扱いが、前記メッセージを前記ハードディスクドライブの前記ファイルの一つとして保存することなく前記メッセージを扱うことを含むことを特徴とする、請求項４５記載の方法。
【請求項４７】
前記送信者サーバーにおいて、当該メッセージを複数の離散的なデータパケットに分離し、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでおり、
（ｉ）前記複数の離散的なデータパケットを第一の所定の規則セットに従って修正すること、（ｉｉ）前記複数の離散的なデータパケットに第二の所定の規則セットに従って追加データパケットを加えること、（ｉｉｉ）前記複数の離散的なデータパケットを第三の所定の規則セットに従って順序付けること、のうちの少なくとも一つを実行するためであって、結果として複数の結果データパケットを与えるための複数の外部アプリケーションのうちの一つへのアプリケーションプログラムインターフェースを通じて前記複数の離散的なデータパケットを差し向ける、
ことをさらに有することを特徴とする、請求項４５記載の方法。
【請求項４８】
前記アプリケーションプログラムインターフェースを通じて複数の外部アプリケーションの前記一つから前記複数の結果データパケットを受信し、
前記複数の結果データパケットのうちの少なくとも一部分を組み合わせることによって前記メッセージを生成し、
前記送信者サーバーから前記受信者サーバーへインターネットを通じた接続を確立し、
前記接続を通じて前記メッセージを前記受信者サーバーに前記受信者への配送のために向ける、
ことをさらに有することを特徴とする請求項４７記載の方法。
【請求項４９】
インターネットを通じたインターフェースをもつメッセージ交換システムにおいて、複数の受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ送信者からある受信者に配送すべく宛てられたメッセージを処理するための方法であって、
前記送信者サーバーにおいて、当該メッセージを複数の離散的なデータパケットに分離し、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含むようにし、
前記メッセージを送るための前記受信者情報に頼る前に、前記送信者サーバーから受信者サーバーへのインターネットを通じた接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者への配送可能性の指標を提供するようにし、
前記指標に基づいて、（ｉ）前記メッセージを前記受信者への前記受信者サーバーを通じた配送のために前記接続を通じて向けるか、（ｉｉ）前記メッセージの配送を中止するかのうちの一つを実行する、
ことを有することを特徴とする方法。
【請求項５０】
インターネットを通じたインターフェースをもつメッセージ交換システムにおいて、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ送信者からある受信者に配送すべく宛てられたメッセージを処理するための方法であって、
前記送信者サーバーにおいて、当該メッセージを複数の離散的なデータパケットに分離し、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含むようにし、
前記メッセージを送るための前記受信者情報に頼る前に、前記送信者サーバーから受信者サーバーへのインターネットを通じた一時的な試験接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者への配送可能性の指標を提供するようにし、
前記指標に基づいて、（ｉ）前記送信者サーバーから前記受信者サーバーへのインターネットを通じた配送接続を確立し、前記メッセージを前記受信者への前記受信者サーバーを通じた配送のために前記接続を通じて向けるか、（ｉｉ）前記メッセージの配送を中止するかのうちの一つを実行する、
ことを有することを特徴とする方法。
【請求項５１】
インターネットを通じたインターフェースをもつメッセージ交換システムにおいて、送信者からの一群のメッセージを処理するための方法であって、送信者は、複数の受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもち、前記一群のメッセージのそれぞれは受信者に配送すべく宛てられており、当該方法は：
前記送信者サーバーにおいて、当該一群のメッセージにおける各メッセージを複数の離散的なデータパケットに分離し、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含むようにし、
前記一群のメッセージのうちの各メッセージについて前記受信者情報および前記メッセージボディの少なくとも一つに基づいて所定の規則セットに従って前記一群のメッセージをある順序に配置する、
ことを含むことを特徴とする方法。
【請求項５２】
（ｉ）前記複数の離散的なデータパケットを第一の所定の規則セットに従って修正すること、（ｉｉ）前記複数の離散的なデータパケットに第二の所定の規則セットに従って追加データパケットを加えること、（ｉｉｉ）前記複数の離散的なデータパケットを第三の所定の規則セットに従って順序付けること、のうちの少なくとも一つを実行するためであって、結果として複数の結果データパケットを与えるための複数の外部アプリケーションのうちの一つへのアプリケーションプログラムインターフェースを通じて前記複数の離散的なデータパケットを差し向ける、
ことをさらに含むことを特徴とする、請求項５１記載の方法。
【請求項５３】
インターネットを通じたインターフェースをもつメッセージ交換システムにおいて、送信者からの少なくとも一受信者に宛てられたメッセージを処理するための方法であって、送信者は受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもち、前記メッセージ交換システムはデータを処理するための電子メモリおよびファイルを保存するためのハードディスクドライブを含んでおり、当該方法が：
（ｉ）前記メッセージを前記ハードディスクドライブの前記ファイルの一つとして保存することなく前記電子メモリ内のデータとして前記メッセージを扱うこと、および（ｉｉ）前記メッセージを前記ハードディスクドライブの前記ファイルの一つとして保存することのうちの少なくとも一つを選択する、
ことを含むことを特徴とする方法。
【請求項５４】
請求項５３記載の方法であって、当該メッセージが少なくとも受信者情報およびメッセージボディを含んでおり、当該方法が：
当該メッセージを送るための前記受信者情報に頼る前に前記送信者サーバーから前記受信者サーバーへのインターネットを通じた一時的な試験接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者への当該メッセージの配送可能性の指標を提供する、
ことをさらに含むことを特徴とする方法。
【請求項５５】
前記指標に基づいて、（ｉ）前記送信者サーバーから前記受信者サーバーにインターネットを通じた配送接続を確立してそれから前記メッセージを前記受信者への配送のために前記受信者サーバーに向けるか、（ｉｉ）前記受信者への前記メッセージの配送を中止するかのうちの一つを実行する、
ことをさらに有することを特徴とする、請求項５４記載の方法。
【請求項５６】
請求項５３記載の方法であって、当該メッセージが少なくとも受信者情報およびメッセージボディを含んでおり、当該方法が：
当該メッセージを送るための前記受信者情報に頼る前に前記送信者サーバーから前記受信者サーバーへのインターネットを通じた接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者への配送可能性の指標を提供し、
前記指標に基づいて、（ｉ）前記メッセージを前記受信者への配送のために前記接続を通じて前記受信者サーバーに向けるか、（ｉｉ）前記メッセージの配送を中止するかのうちの一つを実行する、
ことをさらに含むことを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、2003年7月7日に出願された米国特許仮出願第60/485,167号の利益を主張するものであり、該出願の内容はここに参照によって組み込まれる。
【０００２】
本文書は一般には電子的なメッセージ交換システムに関するものであり、より詳細には送信者から受信者へのインターネットを通じた電子メッセージを処理するための電子メッセージ配送システムに関する。より特定的には、本文書は一つの実施形態として、高機能電子メッセージ配送エンジンを開示する。
【背景技術】
【０００３】
電子メッセージ配送の課題
電子メッセージ交換は急速に現代社会の日常生活の欠かせない一部となった。今日、電子メール（ｅメール）はインターネットの最も広く使われている用途であり、最も急速に成長している通信媒体である。一対一のユーザー連絡の劇的な拡大に加え、多くの会社が、電子メールを介した自動顧客サービスと並んで定期的な電子メッセージ通信を配信することが会社と顧客との関係を強化できることを認識するに至っている。しかし、大量の電子メールの送受信はいくつかの技術的な難題を呈する。たとえば次のようなものである：（１）大量送信のための膨張するインフラの管理およびサポート、（２）インターネットに対して開かれているアプリケーション上でのセキュリティの維持、（３）ネットワークに出入りする電子メールにウイルスフィルタ、コンテンツフィルタその他のフィルタを適用する必要性、（４）メッセージキューの管理および優先順位付け、（５）生の顧客データを使って顧客へのメッセージを発生させ、目標を絞り、定義すること、（６）「不達」で返ってくる電子メールの管理、（７）顧客の嗜好に一貫性をもって自動的に対応する機能、（８）迅速かつ効率的な配送の実行。
【０００４】
スケーラブルな電子メッセージ交換プログラムについてこうした難題に対処することは既存の技術を用いては不可能とは言わないまでも困難であり、ハードウェアおよび人的資本において相当規模の投資を必要としていた。現在、あらゆる種類の会社や組織が、電子メール専門家やサービスプロバイダーも含め、インターネットを通じて電子メールを送信し、ルーティングするために、何十年前の技術を展開し続けている。すなわち、今日のネットワークのトラフィック量の爆発的増大およびシステム複雑化を予期していなかったメール転送エージェント（MTA）を介しているのである。
従来技術のＭＴＡとオープンソースメールルーティングサーバー
電子メールは電子的な通信文をあるユーザーから別のユーザーにコンピュータネットワーク上で配送するために開発された。ここで、ユーザーは電子メールメッセージ交換システムのメンバーであり、電子メールメッセージ交換システムのドメイン内の電子メールアドレスを有する人間でも、機械でも、アプリケーションでもよい。電子メールのための主要な技術は簡単なメール転送プロトコル（SMTP:  Simple  Mail  Transfer  Protocol）として知られるＴＣＰ／ＩＰ通信プロトコルであり、これは1981年に発明され、一つのコンピュータのユーザーから受信コンピュータのユーザーにインターネットを通じて互換性のあるルーティング配送サーバーを介して電子メッセージのルーティングおよび配送をサポートするよう設計されている。ＳＭＴＰは、共通のヘッダおよびルーティング情報をもつメッセージフォーマットを標準化し、電子メールを扱うアプリケーション間での通信トランザクションのためのコマンド・シンタックスおよびプロセスを確立することによって、電子メール配送を容易にした。
【０００５】
一般に、電子メールアプリケーションは、電子メールを転送し、管理するプロセスにおいて特定の役割を果たす三つの分類のうちの少なくとも一つにあてはまる。第一のアプリケーション分類はメール転送エージェント（MTA:  Mail  Transfer  Agent）であり、これはホストとネットワークとの間でＳＭＴＰを使ってインターネットを介して電子メールを転送する。電子メールはその意図された目的地への途上でいくつかのＭＴＡを経由することもある。第二のアプリケーション分類はメール配送エージェント（MDA:  Mail  Delivery  Agent）であり、これは送り出す電子メールをローカルなホストまたはネットワークから配送のためにＭＴＡに送信したり、ＭＴＡによって呼び出されてはいってくる電子メールを宛先の受信者のメールボックスに区分けしたりする。実際上は、多くのＭＴＡはＭＤＡが組み込まれており、一部のＭＤＡはある種のＭＴＡの構成要素を含んでいる。第三のアプリケーション分類はメールユーザーエージェント（MUA:  Mail  User  Agent）であり、これは本質的には電子メールクライアントアプリケーションであって、最低限でもユーザーがＭＤＡからの電子メールを読んだり書いたりできるようにする。1
現状技術においては、複数のＭＴＡによって、電子メールがローカルホストおよびネットワークからゲートウェーを通じてインターネットに、そして途中の他のＭＴＡメールサーバーへ、さらに受信者へとルーティングされる。ＭＴＡ技術は1980年代なかばにカリフォルニア大学バークレー校のエリック・オールマンによって開発された。当初のＭＴＡ技術の基本的なアーキテクチャおよび構成要素は今なお使われている。2
現状技術のＭＴＡ
現状技術においては、ＭＴＡ電子メール送信の標準的なプロセスは次の通りである。
１．ＭＴＡにおいて、ＭＤＡその他の電子メール生成アプリケーションからはいってくるＳＭＴＰフォーマットのメッセージを受け取る。
２．はいってきたメッセージを一時記憶のためのハードディスク上のファイルに書き込む。
３．目的地情報を得るためにメッセージのＳＭＴＰヘッダを読む。
４．目的地のメール交換（MX:  mail  exchange）レコードをドメイン名サービス（DNS:  Domain  Name  Service）を検索してみつける。
５．目的地ネットワークにあるＭＴＡと接続（すなわちソケット）を確立する。
６．このソケットを通じて、一連の送信ＭＴＡからの情報送信および受信ＭＴＡからの応答からなるＳＭＴＰ通信を実行する。応答は、ＩＤを検証して配送可能性を確認し、あるいは一時的もしくは恒久的な配達不能状態を通知する。
７．メッセージを送信する。
８．受信者ＭＴＡからの配達不能エラー（「不達」）を含んだ何らかの短期応答メッセージを待つ。配達不能エラーの場合、メッセージを再送信する。そうでなければハードディスクからメッセージを削除し、プロセスを終了する。
接続から送信までのシーケンスは現状技術においては実質均一であり標準的である。メッセージの送信は完全な配送プロセスの第一部であり、メッセージが送信されたのち、ＭＴＡはメッセージのコピーをある期間保存し続け、その間に短期エラーメッセージ（すなわち不達メール）――受信ＭＴＡから送信ＭＴＡに送られる配達不能を伝えるＳＭＴＰ電子メール――を受け取れるようになっている。そのような不達通知が受信されたら、送信ＭＴＡは保存してあるメッセージのコピーを使ってプロセス全体を繰り返し、メッセージを再び送る（すなわち再試行）。典型的にはＭＴＡは、配送プロセスを打ち切って配送不能メッセージを送信者に転送する前に何回か続けて不達になったメッセージの送信を再試行する。このプロセスは、発信地から最終目的地までの途上のＭＴＡ間で電子メールが転送される際にも繰り返されることがある。
【０００６】
ここで図面を参照する。同様の要素は同様の参照符号を使って示されている。最初に目を向けるのは図１Ａおよび図１Ｂである。これは、送信者から受信者に電子メールを届けるための従来技術の、それぞれ構成およびＳＭＴＰプロセスを示している。図１Ａは、従来技術の、ＭＴＡを通じてＳＭＴＰ電子メールを送受信するためのマルチユーザー電子メールメッセージ交換システムを図示しており、全体として参照符号１０で示されている。システム１０は、送信者ＭＤＡ１４に接続されている複数の送信者（ボックス１２Ａ〜１２Ｆで表されている）を含んでいる。送信者１２Ａ〜１２Ｆは複数の電子メール１６を生成し、該電子メールを送信者ＭＤＡ１４に届ける。該複数の電子メール１６のそれぞれは一般に、発信元の送信者についての情報（送信者のユーザー名や送信者のサーバードメイン名など）および宛先の受信者についての情報（受信者のユーザー名や受信者のサーバードメイン名など）を含むヘッダ、ならびに、メッセージ本文などを含むメッセージボディを含んでいる。送信者ＭＤＡ１４は電子メール１６を送信者ＭＴＡ２０に送信する。送信者ＭＤＡ１４および送信者ＭＴＡ２０の具体的な構成要素のたとえばプロセッサやハードディスクは簡単のため図１Ａでは示されていないことを注意しておく。送信者ＭＴＡ２０はインターネット（参照要素３０で表されている）を通じて受信者ＭＴＡ４０とのＳＭＴＰ通信を開始し、電子メール１６を受信者ＭＴＡ４０に中継してもらう。受信者ＭＴＡ４０は電子メール１６を受信者ＭＤＡ４４に転送し、次いでこの受信者ＭＤＡ４４が電子メールを、それぞれの宛先の受信者を複数の受信者（４６Ａ〜４６Ｆで表されている）のうちの一から選んで届ける。図１Ａで示されているようなプロセスは反転することができ、受信者４６Ａ〜４６Ｆが複数の電子メールメッセージを生成し、それがＭＤＡおよびＭＴＡを通じて送信者１２Ａ〜１２Ｆに送られてもよい。
【０００７】
今度は図１Ａとともに図１Ｂを参照すると、電子メールを送るための送信者ＭＴＡ２０におけるＳＭＴＰプロセスが図示されている。図１Ｂに示されているようなプロセス６０では、ステップ６２で、まず送信者ＭＴＡ２０が電子メッセージ（すなわち、複数の電子メール１６のうちの一つ）を送信者ＭＤＡ１４から受け取る。するとステップ６４で、ＭＴＡ２０がその電子メッセージを自分のハードディスクに書き込む。次いで、ステップ６６で、ＭＴＡ２０は受信者のドメイン名を検索し、ステップ６８で受信者ＭＴＡ４０に接続する。判断ボックス７０が送信者ＭＴＡ２０と受信者ＭＴＡ４０との接続が確立できたかどうかを判定し、判断ボックス７０の結果がＹＥＳ（接続が確立された）であれば、送信者ＭＴＡ２０はステップ７２で自分のハードディスク上のＳＭＴＰメッセージのコピーを受信者ＭＴＡ４０に転送する。判断ボックス７０の結果がＮＯ（接続は確立されていない）であれば、送信者ＭＴＡはステップ７４で後刻配送を再試行するスケジュールを立ててもよい（すなわち、ステップ６６にループで戻る）。ステップ７２に続いて、判断ボックス７６はＳＭＴＰメッセージの受信者ＭＴＡ４０への配送が成功したかどうかを判定する。判断ボックス７６の結果がＹＥＳ（配送成功）であれば、ステップ７８で配送されたＳＭＴＰメッセージは送信者ＭＴＡ２０のハードディスクから削除される。判断ボックス７６の結果がＮＯ（配送不成功）であれば、送信者ＭＴＡはステップ７４にループで戻ることによって後刻メッセージを再送信するスケジュールを再び立ててもよい。
【０００８】
図１Ａおよび図１Ｂの参照を続けると、この従来技術の電子メッセージ配送システム構成においては、送信者ＭＴＡ２０および受信者ＭＴＡ４０はいずれも本質的には盲目的な中継者として機能している。すなわち、送信者ＭＴＡ２０は事前形成された電子メール１６を受け入れ、受信者ユーザーネームや受信者サーバードメイン名の正確さや受信者ＭＴＡ４０がはいってくる電子メールを受け取れる状態にあるかどうかといった考慮はいっさいなしに、受け入れた電子メール１６をインターネットを通じて送り出す。結果として、システム１０は必然的に複数の不達メール５０を生じ、これは送信者ＭＴＡ２０、送信者ＭＤＡ１４を通って送信者１２Ａ〜１２Ｆへと返送される。不達メールや返送の処理は送信者ＭＴＡおよびＭＤＡの利用可能な処理能力を消費し、プロセス中に複数の電子メールを送受信する間に追加的な通信帯域を利用する。本出願人らは、従来技術の電子メール配送システムでは上述した不達メールおよび返送の処理が望ましくない量の処理時間および通信帯域を使うことを指摘するものである。
【０００９】
ここで図１Ａと併せて図２を参照すると、電子メッセージの標準的なメッセージ（図１Ａに示した複数の電子メール１６のうちの一つのような）のフォーマットが示されている。図２に示されているように、複数の電子メール１６のそれぞれはメッセージヘッダ９０およびメッセージボディ９２を含んでいる。図２に示した例では、メッセージヘッダ９０は、メッセージ生成の日時（date）、メッセージＩＤ（message  ID）、発信元の送信者（すなわち「From」）、宛先の受信者（すなわち「To」）その他の情報を含んでいる。メッセージボディ９２はたとえば、メッセージ本文やメッセージの見え方を指定する付随するＨＴＭＬコードを含んでいる。一般に、複数の電子メール１６のそれぞれはメッセージヘッダおよびメッセージボディを含む単一のファイルとして送信者ＭＴＡ２０に届けられるので、たとえばカスタム内容、セキュリティ鍵または添付ファイルを追加するような追加的な処理を送信者ＭＴＡ２０において実行することは不可能である。
【００１０】
まとめると、現状技術における電子メールＭＴＡのキーとなるプロセスは次の通りである。
１．ＳＭＴＰ供給：事前形成されたＳＭＴＰメッセージをもっぱら受信し、処理する。
２．保存と転送：一時記憶のためにハードディスク上のファイルに各メッセージを書き込み、該ファイルを配送のために受信者ＭＴＡに転送し、その後配送プロセス完了後にそれを削除する機構によって、配送プロセス完了前にシステム障害があった場合に復元、そして再配送を保証するようにしている。
３．組み合わされた有効確認および送信：メッセージ送信を頂点とする、受信者ＭＴＡとのＳＭＴＰ通信内での一連の通信トランザクションの固定されたシーケンス。
４．中継：受け取る各メッセージを送信し、不達になったメッセージを再送信し続ける配送プロセス。
５．閉鎖的アーキテクチャ：上述の諸要素を組み合わせて中断できないプロセスのシーケンスとするアーキテクチャ。
ＭＴＡ技術における近年の進展
上述したＭＴＡのプロセスおよび特性は、1981年に最初の現代的なＭＴＡアプリケーションであるsendmailが公表されて以来、基本的には変わっていない。今日まで、ＭＴＡ電子メール配送の技術における進展は、上述した基本的なプロセスおよび特性は何も変えることなく、これらのプロセスが実行されるスピードと効率を改善することによってその制約条件内で配送効率を最適化しようと努めてきた。
【００１１】
そのような目的に向け、当該技術における近年の進展は、ＭＴＡ電子メール配送のための既存のキーとなるプロセスのあるもの――すなわち、受信者ＭＴＡへのソケット接続生成およびハードディスクまたはファイル入出力（すなわち、ファイルＩ／Ｏ）との間でのメッセージファイルの保存および取得――をサポートするハードウェアＯＳの機能における進歩と結びついて発展してきた。
【００１２】
ソケット接続の生成はＳＭＴＰメール配送の基礎である。当該技術の最初期の具現であるsendmailにおいては、受信者ＭＴＡへのソケット接続を確立するための方法は、新しいソケットのそれぞれについて当該アプリケーションの新たなインスタンスを生成することに頼っていた（すなわち、プロセスベースのソケット接続）。このアプローチは本来的にプロセッサ集約的であり、配送スピードは当該アプリケーションがハードウェア上で自らのインスタンス生成ができる速度に限定された。
スレッドベースのＳＭＴＰ接続
電子メールの量が増大し、情報発信、マーケティングその他の目的のために膨大な受信者リストに対してメッセージを送信する慣行が現れたことで、電子メールＭＴＡのスピードおよび処理効率を改善することへの関心が強まった。同時に、ＯＳの進歩によって、プログラム内部において同時並行する複数のコマンドチェーン（すなわちスレッド）をサポートする機能がもたらされた。これにより、インスタンス生成に必要とされるよりも著しく少ない処理オーバーヘッドで複数の同時データトランザクションをサポートする同時並行プロセスが可能になる。よって、電子メールＭＴＡは複数のソケット接続を同時に生成することができ、ＳＭＴＰ接続の並列処理によってずっと少ない処理オーバーヘッドでずっと高速な配送を行うことが可能になるのである（スレッドベースのソケット接続）。
【００１３】
オープンソースのＭＴＡアプリケーションqmailは、この方法の最初の、そして最も幅広く使われた例である。さまざまなＯＳのためのスレッド化モデルのその後の改良によって、スレッド化のためのより効率的なメモリ割り当てがもたらされ、それによりソケット接続のために効率的に使うことのできるスレッド数の劇的な増加が可能となった。
【００１４】
このスレッド数の増加は、大規模マルチスレッドでの電子メッセージ送信のために構成されたＯＳ上で最も効率的に走るよう最適化されたqmail型のＭＴＡアプリケーションの登場につながった。この進歩の最も成功した例は、商用製品で1999年に公表されたPowerMTA（商標）および2001年に公表されたLyris  MailEngineである。
非同期ファイルＩ／Ｏ
マルチスレッドＳＭＴＰ通信によるスピードおよび効率の改善によって、ＭＴＡ電子メール配送における新たな速度制限要因となるプロセスが浮き彫りになった。ハードディスクにメッセージファイルを書き込んだりハードディスクからメッセージファイルを取得したりする、すなわちファイルＩ／Ｏプロセスである。ファイルＩ／Ｏプロセスはさまざまなコンピュータアプリケーションにわたって共通なもので、アプリケーションまたは一連のプロセスの速度がディスクとの間のファイルの逐次的な読み書きスピード以下に低下する、すなわちボトルネックが生じる傾向は広く知られている。このプロセスにおける最初の有意な進歩はデータ保存を複数のドライブディスクに分散して並列して管理することを導入して（ＲＡＩＤ）劇的にスピードを改善した。このプロセスにおける第二のより最近の進歩は、オープンソースＯＳのＯｐｅｎＢＳＤおよびリナックスＲｅｄＨａｔにおいて実施されたもので、ＯＳが複数のファイルをドライブとの間できざみに分けて同時に、すなわち非同期的に読み書きすることを可能にする（すなわち、非同期Ｉ／Ｏ）。この進歩によりディスクとの間のずっと高速なファイルの読み書きが可能になり、ＭＴＡアプリケーションにおけるファイルＩ／Ｏプロセスの効率の著しい改善がもたらされ、それにより処理速度および効率が改善された。
【００１５】
このように、qmailベースのＭＴＡアプリケーションを大規模マルチスレッド化および非同期ファイルＩ／ＯをサポートするＯＳ上で最適化することによって電子メールＭＴＡアプリケーションから現在のところ最高のパフォーマンスを達成することが可能となった。実際、最適なＯＳの構成およびＭＴＡアプリケーションのチューニングを保証するため、そのようなアプリケーションの好ましい実施形態はＲＡＩＤを用いて事前構成されたハードウェア機器である。2001〜2002年にそのような機器が二つ登場した：IronPort  A60（商標）およびMirapoint  Message  Serverである。以上に述べた従来技術のＭＴＡアプリケーションの実効性能について、公表されている仕様に基づく比較を表１にまとめておく。
【００１６】
【表１】
2007535011.tif 000003
ＭＴＡについての最も一般的な性能尺度は、標準的なデュアルペンティアム（登録商標）３またはペンティアム（登録商標）４プロセッササーバーまたはその同等物から標準的なテキストメッセージ（5,000から10,000バイトの範囲）を送信する実効速度である。SendmailはＭＴＡとして最も性能が貧弱だが、これはそのスピードがソケット接続のためのインスタンス生成および標準的なファイルＩ／Ｏ処理によって妨げられているからである。qmailの標準的な実装はスレッドベースのソケット接続の使用により３倍ほど性能が上がる。qmailベースのマルチスレッドＭＴＡはqmailの標準的な実装に対して劇的な１０倍の性能改善をもたらすが、非同期Ｉ／Ｏも使用するqmailベースのマルチスレッドＭＴＡは使用しない大規模マルチスレッドのqmailベースのＭＴＡに対してさらに５０％以上もの性能向上をもたらす。
ＭＴＡのためのアプリケーションプログラムインターフェース
sendmailその他のＭＴＡは内容解析のための機能および規則セットを使うよう進化したが、ＳＭＴＰメッセージへの修正その他の複雑な処理（たとえばスパムおよび添付ファイルのフィルタ処理、カスタムログ記録、断り書き挿入、ウイルススキャンなど）を実行する上でのユーザーが利用可能なオプションは次のものに限られてきた：（１）一般にローカルアドレスへのメッセージのローカルな配送のためにのみ使える外部プログラムの呼び出し、（２）定期的にトリガーされるプログラムを用いた待ち行列形成モードでのＭＴＡの使用、（３）転送スキームの使用（すなわち、いくつかのＭＴＡインスタンスを用いたシリアルアーキテクチャ）、または（４）いくつかの拡張を追加するためにsendmailのソースコードの改変（この場合はsendmailの再コンパイルが必要になる）3。これら４つのオプションはいずれも運用上、使いやすくも効率的でもない。他のアプリケーションへの共通インターフェースを欠いているので、このアーキテクチャは「閉鎖的アーキテクチャ」とも称される。
【００１７】
電子メール用の処理フィルタを書いたり統合したりするのを容易にするため、sendmailチームは、ＭＴＡのＳＭＴＰプロセス中のさまざまな段階において外部電子メール処理シーケンスの導入を可能にするいくつかのアプリケーションプログラムインターフェース（ＡＰＩ）を開発した。4これらのＡＰＩはまとめてＭＩＬＴＥＲ（Mail  Filtering  API）と呼ばれた。ＭＩＬＴＥＲはsendmailのバージョン8.10.xで最初に実装され、バージョン8.12.x以来sendmailでは公式にサポートされている。
【００１８】
ＭＩＬＴＥＲ  ＡＰＩの範囲は後処理に限定されており、ＡＰＩイベントはプロトコル中で各ＳＭＴＰイベント（たとえば、接続、HELO、MAIL  FROM、RCPT  TO、DATA、QUIT）が発生したあとでしかトリガーされない。すなわち、受信サーバーが送信サーバーの作用に反応する場合は、サーバーにはいってくる間にメッセージが作用を受けることはできる。しかし、イベントが発生する前にメッセージに作用する仕組みはなく、その結果、送信サーバーのほうが作用を開始する場合にはサーバーから出て行くメッセージに対して作用する機構はないのである。
【００１９】
以下で見られるように、本発明は、現状技術の電子メッセージ配送システムに存在する前述の問題を解決する一方、パフォーマンス向上をもたらす能力のおかげで、上記で議論したような従来技術に対して著しい改善を提供する。
【非特許文献１】１．ビル・ボール、ホイト・ダフ著『レッドハット（登録商標）リナックス９』、サムス、2003年5月8日、第11章２．デーヴィッド・ピッツ、ビル・ボール著『レッドハット（登録商標）リナックス６（アンリーシュト）』、サムス、1999年7月30日、第7章  ＳＭＴＰとプロトコル３．ステファン・ランツ著「Ｍｉｌｔｅｒ」http://milter.free.fr/intro/  スライド１および２、フランス、2004年4月14日４．Sendmail社著「Ｍｉｌｔｅｒ  ＡＰＩ」http://www.milter.org/milter_api/api.html、2003年
【発明の開示】
【課題を解決するための手段】
【００２０】
以下でより詳細に記載されるように、ここではインターネットを通じたインターフェースをもつメッセージ交換システムにおいて使うための方法が開示される。受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ送信者から少なくとも一受信者に配送すべく宛てられた、少なくとも受信者情報およびメッセージボディを含むメッセージを処理するためのこの方法は、当該メッセージを送るための前記受信者情報に頼る前に前記送信者サーバーから前記受信者サーバーへのインターネットを通じた一時的な試験接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰ検証（verify）（VRFY）コマンドを使うことなく前記受信者への当該メッセージの配送可能性の指標を提供する。
【００２１】
本発明の別の側面では、インターネットを通じたインターフェースをもつメッセージ交換システムにおいて使うための方法が開示される。受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ送信者から少なくとも一受信者に配送すべく宛てられた、少なくとも受信者情報およびメッセージボディを含むメッセージを処理するためのこの方法は、前記受信者情報に基づいて受信者への当該メッセージの配送可能性を確認することを含む。該確認は、インターネットを通じて送信者サーバーと受信者サーバーとの間で接続を確立し、送信者サーバーから前記接続を使って受信者サーバーと前記受信者情報とを検証し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者が受信者サーバーを通じてインターネットへのインターフェースをもつかどうかについての指標を提供することを含む。その指標は、受信者が実際に受信者サーバーを通じてインターネットへのインターフェースをもつという肯定的確認か、受信者が受信者サーバーを通じてインターネットへのインターフェースをもっていないことを示す否定かの一つである。
【００２２】
本発明のさらに別の側面では、インターネットを通じたインターフェースをもつメッセージ交換システムにおいて使うための方法が開示される。受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ送信者から少なくとも一受信者に配送すべく宛てられたメッセージを処理するこの方法は、送信者サーバーにおいて送信者から当該メッセージを定義するのに使う複数の離散的なデータパケットを受信することを含む。前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでいる。当該方法はさらに、当該メッセージを送るための前記受信者情報に頼る前に前記送信者サーバーから前記受信者サーバーへのインターネットを通じた一時的な試験接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者への配送可能性の指標を提供する。当該方法はまた、前記指標に基づいて、（ｉ）少なくとも前記受信者情報およびメッセージボディを組み合わせることによって当該メッセージを生成し、次いで送信者サーバーから受信者サーバーへのインターネットを通じた配送接続を確立し、続いて当該メッセージを該配送接続を通じて受信者への配送のために受信者サーバーに届けるか、（ｉｉ）当該メッセージの配送を中止するかのうちの一つを実行することを含む。
【００２３】
本発明のさらに別の側面では、インターネットを通じたインターフェースをもつメッセージ交換システムにおいて送信者から少なくとも一受信者に配送すべく宛てられたメッセージを処理するための方法が開示される。送信者は受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ。この方法は、送信者サーバーにおいて送信者から当該メッセージを定義するのに使う複数の離散的なデータパケットを受信することを含む。前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでいる。当該方法はまた、前記受信者情報に基づいて受信者への当該メッセージの配送可能性を確認することを含む。該確認は、インターネットを通じて送信者サーバーと受信者サーバーとの間で接続を確立し、送信者サーバーから前記接続を通じて受信者サーバーと前記受信者情報を検証し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者が受信者サーバーを通じてインターネットへのインターフェースをもつかどうかについての指標を提供することによる。その指標は、受信者が実際に受信者サーバーを通じてインターネットへのインターフェースをもつという肯定的確認か、受信者が受信者サーバーを通じてインターネットへのインターフェースをもっていないことを示す否定かの一つである。当該方法はさらに、前記指標に基づいて、（ｉ）前記肯定的確認に反応して、少なくとも前記受信者情報およびメッセージボディを組み合わせることによって当該メッセージを生成し、次いでそのようにして生成されたメッセージを接続を通じて受信者への配送のために受信者サーバーに届けるか、（ｉｉ）前記否定に反応して、当該メッセージの配送を中止するかのうちの一つを実行することを含む。
【００２４】
本発明のさらにいまひとつ別の側面では、送信者から少なくとも一受信者に配送すべく宛てられたメッセージを処理するためのインターネットへのインターフェースをもつ、未修正のメッセージサーバーを置き換えるよう構成された修正メッセージサーバーが開示される。送信者は、受信者サーバーと通信することのできる未修正メッセージサーバーを通じてインターネットへのインターフェースをもつ。前記未修正メッセージサーバーは、当該メッセージをメッセージファイルとして保存するために構成されたハードディスクドライブを含み、前記未修正メッセージサーバーは該メッセージファイルを受信者サーバーに転送するよう構成される。前記修正メッセージサーバーは、送信者から当該メッセージを定義するのに使う複数の離散的なデータパケットを受信するための設備を含む。前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでいる。前記修正受信設備は前記複数の離散的なデータパケットを保存するための電子メモリを含む。前記修正メッセージサーバーはさらに、前記複数の離散的なデータパケットを処理し、当該メッセージを少なくとも前記受信者情報およびメッセージボディを組み合わせることによって生成するための設備を含む。
【００２５】
本発明のさらに別の側面では、インターネットを通じたインターフェースをもつメッセージ交換システム中の送信者からの一群のメッセージを処理するための方法が開示される。送信者は、複数の受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ。前記一群のメッセージのそれぞれは受信者に配送すべく宛てられている。当該方法は、送信者サーバーにおいて送信者から前記一群のメッセージを定義するのに使う複数の離散的なデータパケットを受信することを含む。前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つは前記一群のメッセージのうちの対応するメッセージのメッセージボディを含んでいる。当該方法はさらに、前記一群のメッセージのそれぞれについての少なくとも前記受信者情報およびメッセージボディを組み合わせることによって前記一群のメッセージを生成することを含む。当該方法はまた、該一群のメッセージのそれぞれの受信者情報およびメッセージボディのうちの少なくとも一方に基づく所定の規則セットに従った順序に前記一群のメッセージを配列することを含む。
【００２６】
本発明の別の側面では、インターネットを通じたインターフェースをもつメッセージ交換システム中の送信者からの、少なくとも一受信者に配送すべく宛てられたメッセージを処理するための方法が開示される。送信者は、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ。当該方法は、送信者サーバーにおいて送信者から当該メッセージを定義するのに使う複数の離散的なデータパケットを受信することを含む。前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでいる。当該方法はまた、前記前記複数の離散的なデータパケットをアプリケーションプログラムインターフェースを通じて複数の外部アプリケーションの一つに届けることを含んでおり、該外部アプリケーションは、（ｉ）前記複数の離散的なデータパケットを第一の所定の規則セットに基づいて修正すること、（ｉｉ）前記複数の離散的なデータパケットに第二の所定の規則セットに基づいて追加的なデータパケットを加えること、（ｉｉｉ）前記複数の離散的なデータパケットを第三の所定の規則セットに基づいて順序付けること、のうちの少なくとも一つを実行するためのものであり、したがって複数の出力データパケットを与えるものである。当該方法はさらに、複数の外部アプリケーションの前記一つから前記アプリケーションプログラムインターフェースを通じて前記複数の出力データパケットを受信すること、および、前記複数の出力データパケットの少なくとも一部分を組み合わせることによって当該メッセージを生成することを含む。当該方法はさらに、送信者サーバーから受信者サーバーへのインターネットを通じた接続を確立し、当該メッセージを前記接続を通じて受信者に配送するために受信者サーバーに届けることを含む。
【００２７】
本発明のさらなる側面では、送信者からの少なくとも一受信者に配送すべく宛てられたメッセージを処理するための、インターネットを通じたインターフェースをもつメッセージ交換システムが開示される。送信者は、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ。前記メッセージは少なくとも受信者情報およびメッセージボディを含む。当該メッセージ交換システムは、当該メッセージを送るための前記受信者情報に頼る前に前記送信者サーバーから前記受信者サーバーへのインターネットを通じた一時的な試験接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者への当該メッセージの配送可能性の指標を提供するための試験設備を含む。
【００２８】
本発明のさらに別の側面では、送信者からの少なくとも一受信者に配送すべく宛てられたメッセージを処理するための、インターネットを通じたインターフェースをもつメッセージ交換システムが開示される。送信者は、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ。前記メッセージは少なくとも受信者情報およびメッセージボディを含む。当該メッセージ交換システムは、当該メッセージを送るための前記受信者情報に頼る前に前記送信者サーバーから前記受信者サーバーへのインターネットを通じた接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者への配送可能性の指標を提供するための試験設備を含む。当該メッセージ交換システムはまた、前記指標に基づいて、（ｉ）受信者に配送するために接続を通じて受信者サーバーに当該メッセージを届けるか、（ｉｉ）当該メッセージの配送を中止するかのうちの一つを実行するための選択的配送設備をも含む。
【００２９】
本発明のさらなる側面では、インターネットを通じたインターフェースをもつメッセージ交換システムにおける、送信者からの少なくとも一受信者に配送すべく宛てられたメッセージを処理するための方法が開示される。送信者は、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ。前記メッセージ交換システムはデータを処理するための電子メモリを含む。当該方法は、該電子メモリ中で当該メッセージをデータとして扱うことを含む。追加的な側面として、前記メッセージ交換システムはさらにファイルを保存するためのハードディスクドライブを含み、前記メッセージは前記メッセージ交換システムにおいて当該メッセージを前記ハードディスクドライブ中のファイルの一つとして保存することなく扱われる。
【００３０】
本発明のさらにいまひとつ別の側面では、インターネットを通じたインターフェースをもつメッセージ交換システムにおける、送信者からのメッセージを処理するための方法が開示される。送信者は、複数の受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ。前記メッセージはある受信者に配送すべく宛てられている。当該方法は、送信者サーバーにおいて、当該メッセージを複数の離散的なデータパケットに分離し、ここで前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでいる。当該方法はまた、当該メッセージを送るための前記受信者情報に頼る前に前記送信者サーバーからある受信者サーバーへのインターネットを通じた接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者への配送可能性の指標を提供することを含む。当該方法はさらに、前記指標に基づいて、（ｉ）受信者に受信者サーバーを通じて配送するために接続を通じて当該メッセージを届けるか、（ｉｉ）当該メッセージの配送を中止するかのうちの一つを実行することを含む。代替的に、当該メッセージは配送接続を通じて届けられる一方、前記試験は一時的な試験接続を通じて実行される。
【００３１】
本発明のさらにいまひとつの側面では、インターネットを通じたインターフェースをもつメッセージ交換システムにおける、送信者からの一群のメッセージを処理するための方法が開示される。送信者は、複数の受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ。前記一群のメッセージのうちの各メッセージは受信者に配送すべく宛てられている。当該方法は、送信者サーバーにおいて、当該一群のメッセージを複数の離散的なデータパケットに分離し、ここで前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つは前記一群のメッセージのうちの対応するメッセージについてのメッセージボディを含んでいる。当該方法はまた、該一群のメッセージのうちの各メッセージについて受信者情報およびメッセージボディのうちの少なくとも一方に基づく所定の規則セットに従った順序に前記一群のメッセージを配列することを含む。
【００３２】
本発明の別の側面においては、インターネットを通じたインターフェースをもつメッセージ交換システムにおける、送信者からの、少なくとも一受信者に配送すべく宛てられたメッセージを処理するための方法が開示される。送信者は、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ。前記メッセージ交換システムは、データを処理するための電子メモリおよびファイルを保存するためのハードディスクドライブを含んでいる。当該方法は、（ｉ）当該メッセージを前記ハードディスクドライブ中のファイルの一つとして保存することなく、当該メッセージを前記電子メモリ中のデータとして扱うか、（ｉｉ）当該メッセージを前記ハードディスクドライブ中のファイルの一つとして保存するかのうちの少なくとも一つを選択することを含む。
【００３３】
本発明は、以下の詳細な記述を図面と併せて参照することによって理解されうる。説明の明確化のため、図面におけるある種の要素は縮尺どおりに描かれていないことがある。
【発明を実施するための最良の形態】
【００３４】
以下の記述は、通常の当業者が本発明を作成し、使用することを可能にするために示されているもので、特許出願およびその要件のコンテキストにおいて与えられている。当業者には記載されている実施形態へのさまざまな修正がすぐに明らかとなることであろう。ここに記載される一般的な原理は他の実施形態にも適用されうるものである。よって、本発明は示されている実施形態に限定されることは意図されておらず、ここに記載される原理および特徴と一貫する最も広範なる範囲を与えられるべきものである。
現状技術における問題点
当該技術における進歩は、ＯＳの進歩とともに配送スピードおよびハードウェア効率の向上をもたらした。しかし、電子メールＭＴＡのキーとなる特徴のいくつかにおいて、パフォーマンス、柔軟性、セキュリティおよび機能追加の進展を制限する問題がある。
【００３５】
電子メールは当初、電子的なメッセージをコンピュータネットワーク上のある者（通例は人間）から別の者に伝送するために開発された。電子メールＭＴＡは、送信者のアカウントのホストとなっているローカルなメール配送エージェントに出入りする電子メールメッセージを当該ホストまたはネットワーク外の他のＭＴＡとの間で受け取ったり配送したりするために作成された。電子メールおよびインターネットの使用が拡大したため、ユーザーや組織は、人間の送信者が生成した通信以外に電子メールの用途を見出すようになり、大量情報発信のために電子メールを使うことに始まって、直接マーケティング、自動トランザクション、サポートおよび顧客サービスのための用途へと進化してきている。これらの新しい用途は、大量通信活動について劇的にコストを削減し、効率を改善する途方もない可能性をもたらし、よって対応する技術ソリューションへの関心を高めた。
【００３６】
電子メールのための最も有望な用途は、受信者を特定し、メッセージ内容を作成し、電子メール配送を生起させるために顧客、会員または加入者についての情報のデータベースを使う機能にまつわるものであった。より根本的には、ウェブページ上での接触や取引の普及度の上昇は、電子メール受領証およびオンラインのやりとりのその他の確認に対する需要を押し上げた。
【００３７】
こうして、データベースおよびローカルなウェブアプリケーションが電子メールを送信できるようにすることが重要となった。しかし、この場合のメッセージは個々のユーザーによって作成されるのではなくシステムによって生成されることになるため、標準的なＭＤＡは必要とされるプロセスをサポートせず、電子メールはこうしたシステムからＭＴＡに直接送る必要が出てくる。しかし、ウェブおよびデータベースアプリケーションがデータ出力を生成しても、ＭＴＡは事前形成されたＳＭＴＰメッセージしか受け付けない。その結果、システム開発者たちは、データパケットをローカルなＭＴＡに送信するための電子メッセージに変換してくれる、ローカルシステムならびに特製電子メールマーケティングおよび情報発信システムのためのＳＭＴＰ「フィーダー」（たとえばJava（登録商標）mail）を作成した。しかし、ＳＭＴＰフィーダーはその性質上、いかなるＭＴＡの配送スピードも、フィーダーによって供給できる速度に制限してしまう（現在の技術では実効ベースで１時間あたり電子メール約200,000通）。
【００３８】
さらに、電子メールの使用が洗練されてくるにつれ、二つ以上のソースシステムからの情報を使って電子メールを生成することがますます望ましくなる。たとえば、電子商取引のアプリケーションが最近完了した取引についての特定の情報を含むテキストメッセージのためのデータを生成したりする。そのメッセージに含まれる情報に基づいて、別個のシステムから目標を絞った広告またはサービスのコンテンツを引き出すことが望ましいこともありうる。現状技術においては、複数のソースシステムからの情報をそのように組み合わせるには、ＳＭＴＰ電子メールメッセージを生成するためにＳＭＴＰフィーダーにコンテンツデータの完全なセットを提出するのに先立って第一のシステムと第二のシステムとの間でトランザクションを処理することを必要とする。第一および第二のシステムの間のこの処理はこれらのシステムの間のかなりの統合を含意しており、大規模な電子メール運用のために実行された先例は出願人らの知る限りただ一社、アマゾン・コムしかない。
【００３９】
さらに、電子メールＭＴＡが、各メッセージ、中央処理される業務ロジックまたはその他の機構内での仕様に基づいて、他の電子メッセージプロトコルフォーマットをサポートし、ＳＭＴＰ電子メールに変換するために他のプロトコルのメッセージを受け付けたり、あるいは他のプロトコルに変換するためにＳＭＴＰ電子メールメッセージを受け付けたりできるようにすることが望ましいこともある。
「保存して転送」処理の問題点
ＳＭＴＰフィードの慣行に関連しているのが、現在行われている「保存して転送」処理の慣行である。この方式では、ＭＴＡはＳＭＴＰ電子メールメッセージをアプリケーションに受け入れ、それぞれをハードディスク上のファイルに書き込み、それを配送プロセスを通じて送り、それから保存されているメッセージをハードディスクドライブから削除する。この慣行は電子メール配送についていくつかの問題を引き起こす。
【００４０】
先に議論したように、ハードディスクドライブへのファイルの書き込みというファイルＩ／ＯはＭＴＡのパフォーマンスにおける長年の問題である。非同期ファイルＩ／Ｏにおける近年の技術革新はパフォーマンスを改善したものの、ハードディスクドライブとの間で機械的にファイルの読み書きを行う活動は本来的に処理集約的であり、ボトルネックを生じやすい。
【００４１】
「保存して転送」処理のさらなる問題は、システム内でのメッセージ処理の逐次的な、先入れ先出し（ＦＩＦＯ）の性格である。これは電子メールのそれぞれが処理中の当該メールと一緒に、あるいは近接して送られる他のメールとは一切切り離されて処理されるという事実に起因する。これは大量ＭＴＡ電子メール配送のパフォーマンスにおいて最も重要な問題の一つを生ずる。電子メールはアクティブな接続を通じた伝送のために、相前後して一列の待ち行列にされる。大量用途では、メッセージはさらにドメインによってグループ化される。これは、複数のＳＭＴＰ通信が同時に同じドメインに向けられて受信者ドメインのＭＴＡにおける速度低下や接続障害の可能性を増加させるという好ましくない状況を呈する。そのような諸接続が試みられて速度低下か接続障害を起こせばそれらの接続は停止状態になる。同じドメインへの個別のメッセージによって生じる同一ドメインへの度重なる接続試行は当該アプリケーションを順に通過し、さらなる接続を停止状態にし、当該アプリケーション全般にわたって配送の速度低下または停止を引き起こす。当初は非常に多数のスレッドが利用可能であってもである。
【００４２】
「保存して転送」処理に関連するＦＩＦＯ処理は電子メール送信にさらなる制限をもたらす。接続が停止状態になったときに配送試行を上手にさばくために複数の受信者アドレスを見直すことができないのと同じように、あるＭＴＡを通る電子メールトラフィックに優先順位を割り当てることが望ましいような場合にも、前記システムは一つの待ち行列または待ち行列の集合にわたってトラフィックの優先順位付けをするためにメッセージおよびメッセージ群を見直すこともできない。
【００４３】
「保存して転送」処理の最後の問題は、メッセージに何らかの追加または修正を導入するためのいかなる機構も欠いていることである。ＳＭＴＰフィードの問題と密接に関連して、固定されたメッセージがＭＴＡに入力されて最終受信者への配送のための厳格に定義された一連の処理を受けるという事実は、ＭＴＡの機能をメッセージの中継に厳密に限定してしまう。セキュリティ証明書、カスタマイズされたコンテンツなどといった電子メール処理の進展とともに、今では送信者アプリケーション（ＭＤＡまたはその他のシステム）からインターネットへの転送中にメッセージに修正を加えることがきわめて望ましいような用途が数多くある。ＳＭＴＰフィードに関するメッセージを生成するために二つ以上のシステムを使う問題と同様、ＭＴＡを通過するメッセージの内容を修正できないということは、電子メールへの内容修正を生成するアプリケーションは送信前に処理するために送信アプリケーションに統合されていなければならないという現状技術につながっている。
有効確認および送信および中継を組み合わせることに関する問題
周知のように、ＭＴＡ電子メール送信の現状技術において、ひとたびＭＴＡが受信者サーバーを同定して接続を開くと、一連の情報のやり取りが発生し、それにより送信ＭＴＡが受信者サーバーの利用可能性を有効確認し、受信者サーバーがメッセージの配送可能性を有効確認する。現状技術においては、ＭＴＡは有効確認の結果に関わりなくメッセージを受信者ＭＴＡに送信する。メッセージが最終的に配送不能と判明した場合には、受信者サーバーがＳＭＴＰエラーメッセージを送信ＭＴＡに返送し、次いで該送信ＭＴＡはメッセージを再送信する。このプロセスは一般に何試行か続けられ、所定の回数に達すると送信ＭＴＡは送信失敗の報告を発信元の送信者またはシステムに返す。これは、元来の配送不能電子メールのため、ならびに不達メールおよびそれに続くその後の再送信のため、相当な処理のオーバーヘッドを生じ、通信帯域も使う。
【００４４】
メッセージを送るのに先立って受信者電子メールアドレスの配送可能性を有効確認し、配送可能でない場合には送らないことによってこのプロセスを改良することは、電子メール配送の長年の問題である。この問題は、大きなリストの電子メールアドレスの配送可能性を有効確認し、恒久的に配送不能なアドレスは将来の電子メール送信の試行からは消去するという目的のためにも追求されてきた。現在のところ、さまざまな試みは、この目的のためにsendmailに組み込まれている検証プロセスであるＶＲＦＹコマンドを使うことに焦点を当ててきた。このコマンドは、電子メールを送信するための標準的なＳＭＴＰ通信プロセスからは独立して動作するよう設計されたものである。しかし、この単体の検証プロセスは、ネットワークの外部の操作者が自動化された試行錯誤を通じてネットワーク内の有効な電子メールアドレスを同定するために使うこともできるもので、従って重大なセキュリティ上の危険を呈する。
【００４５】
ここで図１Ａとともに図３を参照すると、図１Ａの従来技術のメッセージ交換システムにおいてＶＲＦＹコマンドを使ってうまくいく場合のプロセスが示されている。ステップ１０２において、ＶＲＦＹプロセス１００は送信者ＭＴＡ２０が受信者ＭＴＡ４０に接続することによって開始される。ステップ１０４では受信者ＭＴＡ４０が接続を認識する。するとステップ１０６で送信者ＭＴＡ２０は受信者ＭＴＡ４０に“HELO”を送信する。ステップ１０８で、受信者ＭＴＡ４０は
“Welcome”で応答することによってこの挨拶の受領確認をする。送信者ＭＴＡ２０は宛先の受信者の電子メールアドレスの有効性を検証するためにＶＲＦＹコマンドでこれに続く。ＶＲＦＹコマンドで送られた宛先の受信者の電子メールアドレスが受信者ＭＴＡ４０において正しいものであれば、受信者ＭＴＡはステップ１１２で“Okay”の応答をする。そうでなければ、受信者ＭＴＡ４０は送信者ＭＴＡ２０にＶＲＦＹコマンドで送られた電子メールアドレスのユーザーは送信者ＭＴＡ４０を通じてのインターネットとのインターフェースはもたないと通知する。
【００４６】
ＶＲＦＹコマンドの機能は普通に使われるアプリケーションsendmailに組み込まれているのでこのコマンドは便利である。しかし、ＶＲＦＹプロセスのサポートは受信者sendmailＭＴＡ上の任意的な設定であり、標準的な電子メール配送処理に決定的ではないため、この機能はセキュリティへの配慮から無効にされることが一般的である。すなわち、ステップ１１２で“Okay”または否定的な結果で応答するのではなく、受信者ＭＴＡ４０は送信者ＭＴＡからのＶＲＦＹコマンドに対してＶＲＦＹコマンドが無効になっているとの通知を返す――よって、宛先の受信者の電子メールアドレスの正確さについて確認も否定もしない――のである。したがって、本出願人らは、ＶＲＦＹコマンドだけでは電子メール有効確認の問題への解決策にはならないことを指摘するものである。
ＭＴＡのためのアプリケーションプログラムインターフェースの問題点
先に述べたように、電子メールの使用および用途の拡大により、電子メールメッセージに作用し、これを修正し、検査し、その他の仕方で相互作用するプロセスに対する必要性と要望が生じた。今日、そのようなプロセスはウイルス保護アプリケーション、スパムフィルタ、コンテンツフィルタ、暗号化、ネットワーク署名、ポリシーフィルタ、ＨＴＭＬテンプレートアプリケーションその他を含む。さらに、内容を修正するアプリケーションは先に述べたように発信元の送信者システムとの統合を通じて適用できる（困難ではあるが）一方、スキャンするプロセスは定義により電子メッセージがネットワークにはいってきたり、ネットワーク内を転送されたりするときに適用される。従来技術の電子メッセージ配送プロセスに存在する問題の一つは、現在のＭＴＡプロセスを一シーケンスをなした高々単一の外部プロセスとしか組み合わせられないＭＴＡアーキテクチャが多いことである。さらに、システムまたはネットワークにおいてメッセージに対して複数の外部プロセスを行う必要がある場合には、そのような外部プロセスは別個のＭＴＡのシーケンスを通じて逐次適用する必要がある。
【００４７】
現状技術においては、そのようなプロセスは、各メッセージを、メッセージを受け付けるための受信ＭＴＡと次の処理アプリケーションもしくはインターネットを通じて配送するための主要ＭＴＡに転送するための別個の送信ＭＴＡとによってサポートされている別個のアプリケーションを通じて送ることによって、逐次適用される。結果として、システム全体の配送効率は、複数のＭＴＡおよび処理アプリケーションを通じた逐次的な処理の一連の階層の配送効率によって制限される。この逐次的なアーキテクチャはまたハードウェア集約的かつサポート集約的である。
提案される解決策
上述したように、現在利用可能なＭＴＡのＳＭＴＰフィードにおける本来的な制約のため、従来技術のＭＴＡがたとえば配送スピードの増大や複数のソースシステムからのデータベース情報の組み合わせといった機能を提供する能力は禁止または限定される。これらの問題への解決策として、本出願人らは、アプリケーションプログラムインターフェースを通じてデータ要素、生データファイルまたは他の電子メッセージフォーマットを受け付け、関係のあるデータ項目を使って当該ＭＴＡアプリケーション内でＳＭＴＰ電子メールを構築することのできるＭＴＡを提起する。前記電子メッセージはたとえば、ＳＭＴＰメッセージすなわち電子メールであってもよいし、あるいは送信者から宛先の受信者に配送することが意図されたその他のフォーマットの電子データのパッケージであってもよい。
【００４８】
従来技術のＭＴＡには「保存して転送」の通信モードを使うことによる追加的な問題があった。本出願人らは、この問題に対する一つの解決策は、プロセッサチップによって直接アクセス可能なランダムアクセスメモリ（ＲＡＭ、すなわち電子的メモリ）内にメッセージを保存し、それによりファイルＩ／Ｏに付随する機械的動作をなくすことによって効率の劇的な向上を実現することであることを提起する。ファイルＩ／Ｏ法は電子メール開発の初期に、システム障害の場合にプロセス内に保存されているメッセージの回復可能性を保証するよう設計され、現在のＭＴＡの基本アーキテクチャに組み込まれた。今日、配送処理スピードを増して保存時間がほとんど０にまで短縮されるような進歩によって、またシステム障害が起こったときにファイルをハードディスクドライブに書き込む機構を容易に設計できる可能性によって、プロセス中にメッセージを失う危険性は大幅に低下している。
【００４９】
従来技術のＭＴＡの「保存して転送」処理に起因するもう一つの問題は、メッセージ処理の逐次的な先入れ先出し（ＦＩＦＯ）の性格である。これはしばしば処理のボトルネックを生じ、いかなる形のトラフィック優先順位付けも待ち行列管理も妨げる。この問題への解決策として、本出願人らは、ＭＴＡが一群のメッセージまたは受信者リストにわたってドメイン構成を見直し、配送すべきメッセージの処理を個々のドメインへの接続試行がリスト全体に分散するような順番にすることができるようにすることを提起するものである。この方法により、受信者ＭＴＡによる速度低下および障害の可能性、ならびに、問題のある同じドメインに配送を試みることでスレッド接続がいっぱいになることによって生じるボトルネックの可能性が最小化される。さらに、本発明は、メッセージトラフィックに優先順位をつけ、うまく管理するための柔軟でカスタマイズ可能なプロセスを提供する。
【００５０】
本発明はまた、標準的なＳＭＴＰ通信プロセスを設計しなおして、該標準的なＳＭＴＰ対話の間に配送不能応答を受けたメッセージのために代替プロセスを可能にすることによって配送可能性の有効確認問題に解決策を提供する。このプロセスでは、そうしたメッセージは受信者ＭＴＡには送られず、さらなるＳＭＴＰ配送通信の試行を通じて再試行され、最終的には配送可能と有効確認されて送信されるか、発信元の送信者またはシステムに配送不能と報告されて打ち切られるかする。
【００５１】
閉鎖的アーキテクチャの問題もまた本発明によって緩和される。本発明の提供するＭＴＡアプリケーションは、スキャンおよび修正のような付随的な電子メールプロセスの当該ＭＴＡアプリケーション自身との緊密な統合を、そのようなプロセスのために設計された互換アプリケーションに対して標準的ＳＭＴＰプロセスの諸段階のいずれにおいても開かれたインターフェースを利用可能にすることによって可能にする。そのようなＭＴＡアプリケーションは、電子メールまたは電子メール相当データファイルを配送のために受け付け、それらを直接的なデータインターフェースを通じて、受信者ＭＴＡに配送するのに先立つこれらの追加プロセスを通して届けることができる。これらのことを含む本発明のさまざまな特徴について以下でより詳細に説明する。
【００５２】
ここで図１Ａとともに図４Ａ〜図４Ｃを見ると、図１Ａの従来技術のメッセージ交換システムにおけるＳＭＴＰ送信プロセス２００のさらなる詳細が示されている。図４Ａは、図１Ａの送信者ＭＴＡ２０と受信者ＭＴＡ４０との間の通信プロセスを示している。ステップ２０２で送信者ＭＴＡ２０が受信者ＭＴＡ４０に接続することによってプロセス２００が開始される。ステップ２０４では受信者ＭＴＡ４０が送信者ＭＴＡを認識することによって応答する。するとステップ２０６で送信者ＭＴＡ２０は受信者ＭＴＡ４０に“HELO”を送信する。ステップ２０８で、受信者ＭＴＡ４０は送信者ＭＴＡ２０に“Welcome”を送ることによって応答する。ステップ２１０では、送信者ＭＴＡ２０は受信者ＭＴＡ４０に未処理の電子メールメッセージについて通知する。受信者ＭＴＡ４０がはいってくるメッセージを受け付けている場合には、ステップ２１２で受信者ＭＴＡ４０は“Okay”で応答し、それにより受信者ＭＴＡの利用可能性を確認する。するとステップ２１４で送信者ＭＴＡ２０は受信者ＭＴＡ４０に宛先の受信者の電子メールアドレスを示す。そのようにして示された電子メールアドレスが受信者ＭＴＡにおいて有効な電子メールアドレスダル場合には、受信者ＭＴＡ４０はステップ２１６で“Okay”の応答をし、それにより宛先の受信者の電子メールアドレスの有効性を確認する。するとステップ２１８で、送信者ＭＴＡ２０は受信者ＭＴＡ４０にデータを送ろうとしていることを示す。このうまくいく場合のＳＭＴＰ送信プロセス２００においては、受信者ＭＴＡ４０はステップ２２０で“Begin”〔開始〕で応答し、そこでステップ２２２で送信者ＭＴＡ２０は電子メールメッセージの送信を開始する。該電子メールを受け取ったとき、受信者ＭＴＡ４０はステップ２２４でもう一度“Okay”で応答する。するとステップ２２６で送信者ＭＴＡ２０は電子メール送信プロセスが完了したことを“Quit”〔終了〕によって示す。これに対して受信者ＭＴＡ４０はステップ２２８で“Okay”で応答する。最後に、ステップ２３０で送信者ＭＴＡ２０は受信者ＭＴＡ４０から切断し、同様にステップ２３２で受信者ＭＴＡ４０も送信者ＭＴＡ２０から切断する。こうしてうまくいった場合のＳＭＴＰ送信プロセスが完了する。
【００５３】
図４Ａの参照を続けると、電子メールの配送可能性（すなわち、受信者ＭＴＡ利用可能性および宛先の受信者情報の有効性）の確認は、本発明のプロセスにおいては、通常のＳＭＴＰ通信の過程で実現されており、たとえば従来技術におけるＶＲＦＹコマンドには頼っていないことを強調しておく。この方法により、本発明は従来技術の問題点を回避しながら、従来技術のＭＴＡを使った場合に可能であったよりも著しく不達メールの少ない、はるかに高いパフォーマンスを提供している。
【００５４】
図４Ｂおよび図４Ｃは、図４Ａで示された確認プロセスの二つの可能な結果を示している。図４Ｂはうまくいった場合の確認プロセス２５０を示すものだが、本質的には図４Ａのうまくいった場合のＳＭＴＰ送信プロセス２００の最初の数ステップと同一である。基本的には、送信者ＭＴＡ２０と受信者ＭＴＡ４０との間の通常のＳＭＴＰ通信の過程で、受信者ＭＴＡがはいってくるメッセージを受け付けられるかどうかの利用可能性がステップ２１０およびステップ２１２で確認され、宛先の受信者の電子メールアドレスの有効性がステップ２１４およびステップ２１６において確認される。これに対して図４Ｃはうまくいかなかった場合の確認プロセス２５０′を示している。ここでは受信者ＭＴＡはステップ２１４における宛先受信者情報問い合わせに反応して、ステップ２５２で送信者ＭＴＡに「User  Unknown」〔該当ユーザーなし〕メッセージを返す。すなわち、宛先の受信者の電子メールアドレスの有効性が否定されたのである。この否定に反応して、送信者ＭＴＡはたとえば、メッセージ配送プロセスを放棄して待ち行列で待機中の次の電子メッセージの処理に進むことができる。
【００５５】
ここで図５Ａ〜図５Ｄに目を向ける。これらは本発明の電子メッセージ配送システムのさらなる改良を示している。まず図５Ａを参照すると、電子メッセージ配送システム３００は送信者ＭＴＡ３２０を含んでいる。送信者ＭＴＡ３２０は、複数の送信者３２６によって発信された複数のデータパケット３２２Ａ（点線のボックス３２４Ａで囲まれている）を受け付けるよう構成されている。複数のデータパケット３２２Ａはたとえば、図２に示したような電子メールを構成するさまざまな構成要素を含んでいてもよい。送信者３２６はたとえば送信者ＭＴＡ３２０を通じてインターネットへのインターフェースをもつ人間のユーザーであってもよい。送信者ＭＴＡ３２０は、従来技術における送信者ＭＴＡと同様に、複数の送信者３２６からの複数の完全な電子メッセージ３２８を受け付けるよう追加的に構成されていてもよい。送信者ＭＴＡ３２０はまた、データベース３３２とのインターフェースをもつコンピュータシステム３３０によって生成された複数のデータパケット３２２Ｂ（点線のボックス３２４Ｂで囲まれている）を受け付けるようにも構成されている。たとえば、コンピュータシステム３３０はデータベース３３２に含まれる要素を図２に示した電子メールのさまざまな構成要素に変換することができる。
【００５６】
引き続き図５Ａを参照すると、送信者ＭＴＡ３２０はランダムアクセスメモリ（ＲＡＭ）３３６を含んでおり、送信者ＭＴＡ３２０が複数のデータパケット３２２Ａおよび３２２Ｂを受信するにつれ、そのように受信されたデータパケットはハードディスクドライブ上の別個のファイルとしてではなくＲＡＭ内に保存される。結果として、ＭＴＡ３２０は、たとえば固定内容挿入３４０、ドメインベースのフロー制御３４２、動的なＩＰ割り当て３４４そしてさらには配送可能性確認３４６といった改良プロセスを実行し、次いで前記複数のデータパケット３２２Ａおよび３２２Ｂからインターネット３０を通じて届けられるべき複数の最終的な電子メッセージ３５０を生成することができる。
【００５７】
送信者ＭＴＡ３２０における改良プロセスは、送信者ＭＴＡ３２０が、ハードディスク上にファイルとして保存されている完全な電子メッセージだけに依存するのではなく、データパケットをＲＡＭに受け入れるよう構成されているという事実によって容易にされている。前記のさまざまなデータパケットから最終的な電子メッセージが生成されるので、電子メッセージ配送システム３００は、前述した従来技術の「保存して転送」システムに対して「構築して転送」システムと称される。この「構築して転送」システムは、「保存して転送」システムに対して著しい利点をもたらす。「構築して転送」システムに含まれる改良プロセスは「保存して転送」システムでのような一連のファイルの読み込みおよび再書き込みを必要とせず、すべてＲＡＭ内で扱うことができるからである。また、改良プロセス内に配送可能性確認が含められている場合には、送信者ＭＴＡ３２０は、最終的な電子メッセージ３５０の配送可能性が確認されなかった場合には最終的な電子メッセージ３５０を生成しないよう構成することができ、これにより処理時間および通信帯域の節約を生むことができる。
【００５８】
図５Ｂおよび図５Ｃは、ドメイン名分散なしの従来技術のシステムおよびドメイン名分散を含む本発明の電子メッセージ配送システムにおける複数の電子メッセージの配送の過程を通じたドメイン名の典型的な分布を示すグラフである。まず図５Ｂを考えると、たとえば大量電子メール送信の環境においての電子メッセージの典型的なバッチ処理において、一握りの大きなインターネットサービスプロバイダードメイン名に大量の電子メールが送られる傾向がある。たとえば、電子メールの大半がＡＯＬ（商標）、ＭＳＮ（商標）、ホットメール（商標）、ヤフー（商標）といった大手プロバイダを通じてインターフェースをもつ受信者に宛てられているなどである。図５Ｂはｘ軸３６２が時間、ｙ軸３６４がメッセージ数を表すグラフ３６０を示しているが、縦の棒３６６Ａ、３６６Ｂなどのそれぞれがある特定のドメインに所与の時刻において向けられている電子メールメッセージの数を表している。大半の受信者アドレスが少数のドメイン名に集中するため、配送試行におけるドメイン名分布は時間的に全く不均一になる傾向がある。図５Ｂに示した例では、グラフ３６０は、送信者ＭＴＡ（または電子メールメッセージ生成データベース）がある特定のドメイン名に向けられた電子メールを一緒にまとめる傾向がある場合を表している。たとえば、送信者ＭＴＡは、最初に大量の電子メールをＡＯＬ（商標）に届け（縦の棒３６６Ａで示されているように）、次にＭＳＮ（商標）に（縦の棒３６６Ｂで示されているように）、そして時間がたつとともにより小規模のＩＳＰのドメインにと進めていくなどである。結果として、送信者ＭＴＡは最初の送信期間の間に大量の電子メールを送り出さなければならず、時間が進むにつれその数は少なくなる。このため送信者ＭＴＡの処理能力の利用画が時間的に不均一になり、配送スピードおよびパフォーマンスが悪影響を受ける。さらに、一部のプロバイダには、短い時間範囲内に単一の送信者ＭＴＡから大量の電子メールを受信することを禁止するフィルタリング機能がある。
【００５９】
これに対し、図５Ｃはやはりｘ軸３７２が時間、ｙ軸３７４がメッセージ数を表すが、本発明に基づくドメインベースのフロー制御を用いたメッセージ配送のグラフ３７０を示している。グラフ３７０では、各ドメインへの電子メッセージの配送は時間を通じて分散され、それぞれの横の棒３７６Ａ、３７６Ｂなどがある特定のドメインに所与の時刻に向けられている電子メールメッセージの数を表している。図５Ｃから見て取れるように、ある特定のドメインに向けられているメッセージの数は時間的に均一に分散しており、本発明の送信者ＭＴＡの配送スピードおよびパフォーマンスは従来技術に対して大幅に改善される。また、ドメインの均一分散のおかげで大量のメッセージ配送のために特定のドメインでメッセージ配送がブロックされる問題が軽減される。ドメイン名の分散は、図５Ａの送信者ＭＴＡ３２０の、電子メールメッセージの構成ブロックを含むデータパケットを受け付ける機能によって可能となっている。すなわち、従来技術のＭＴＡと異なり、送信者ＭＴＡ３２０は、最終的な電子メッセージが生成される前に電子メールメッセージの構成要素を操作することができ、それによりドメインベースのメッセージ分散およびフロー制御のようなタスクを実行できるのである。完全な電子メッセージファイルではなくデータパケットを扱うという本発明のＭＴＡの機能のため、そのような追加的な処理ステップをメッセージ配送プロセスそのものの中に組み込むことが大いに簡単になっている。本出願人らは、この特徴は大量および／または一括メッセージ交換の環境においてとりわけ有益であることを提起するものである。
【００６０】
図５Ｄは図５Ａの動的なＩＰ割り当て３４４の詳細を示している。図５Ａに示したように、動的なＩＰ割り当て３４４はＩＰアドレス要求ステップ３８０で始まり、ＩＰアドレス選択ステップ３８２がそれに続く。図５Ａに示した実施形態では、ＩＰアドレス選択ステップ３８２はＩＰアドレス＃１〜＃８の巡回を含んでおり（円３８４Ａ〜３８４Ｈで示されている）、連続した外行きメッセージが同じ発信元ＩＰアドレスをもたないようになっている。本出願人らは、この特徴は大量メッセージ配送においてとりわけ有益であることを提起するものである。
【００６１】
図６Ａは、本発明に基づくドメインベースのフロー制御、受信者サーバー利用可能性確認およびデータベースフィードバックループを含む電子メッセージ配送プロセスの諸ステップを示すフローチャートである。具体的には、図６Ａに示したプロセス４００Ａは単一のＳＭＴＰ通信を通じて生起する確認ステップおよび配送ステップを含んでいる。プロセス４００Ａはデータベース４０２から開始され、そこから特定の電子メールまたは複数の電子メールに関する情報（すなわちデータパケット）が抽出される。プロセス４００Ａではデータパケットはデータベース４０２からドメインベースのフロー制御ステップ（ボックス４０４で示されている）に向けられ、そこで図５Ａ〜図５Ｃを参照しつつ上述したドメインベースのフロー制御が行われる。このドメインベースのフロー制御ステップに続いて、ステップ４０６で、データパケットの特定の集合、すなわちレコードが配送試行のために選択される。次いでステップ４０８でＳＭＴＰ接続が開始される。ひとたびＳＭＴＰ接続が確立されたら、判断４１０が実行されて、受信者サーバーが存在するかどうかが判定される（すなわち、確認）。判断４１０の結果がＮＯ（受信者サーバーが存在しない）であれば、プロセス４００Ａはステップ４１２のＳＭＴＰ接続の終了に進み、ステップ４１４で配送失敗をデータベース４０２に記録する。判断４１０の結果がＹＥＳ（受信者サーバーが存在）であれば、プロセス４００Ａはステップ４２０に進んで当該電子メールを受信者サーバーに配送し、ステップ４２４でＳＭＴＰ接続を終了し、それからステップ４２６でデータベース４０２に配送成功を記録する。この方法により、ドメインベースのフロー制御、受信者サーバー利用可能性確認およびデータベースフィードバックがすべて単一のＳＭＴＰ接続を通じて単一のプロセス内で達成される。
【００６２】
ここで図６Ａとともに図６Ｂを参照すると、図６Ｂはやはり本発明に基づく、ドメインベースのフロー制御、受信者サーバー利用可能性確認およびデータベースフィードバックループを含む代替的な電子メッセージ配送プロセスの諸ステップを示すフローチャートである。図６Ｂに示したプロセス４００Ｂは確認ＳＭＴＰハンドシェークを通じた確認ステップおよび別個の配送ＳＭＴＰ通信を通じて生起する配送ステップを含んでいる。図６Ａに示したプロセス４００Ａと同様、プロセス４００Ｂはデータベース４０２から開始され、データベース４０２からのデータパケットはドメインベースのフロー制御ステップ４０４および配送試行のための選択４０６のステップを通じて操作される。次いで、配送可能性確認の目的のためのＳＭＴＰ接続がステップ４０８′で開始される。プロセス４００Ａの場合と同様、ステップ４０８′に判断４１０が続き、受信者サーバーが存在するかどうかが確認される。以前と同様、判断４１０の結果がＮＯ（受信者サーバーが存在しない）であれば、ステップ４１２でＳＭＴＰ接続が打ち切られ、ステップ４１４で配送失敗がデータベース４０２に記録される。しかし、プロセス４００Ａの場合と異なり、判断４１０の結果がＹＥＳ（受信者サーバーが確かに存在）であれば、プロセス４００Ｂは新たなステップ４３０に進んで第二の配送ＳＭＴＰ接続を開始する。メッセージ配送ステップ４２０は、ステップ４０８′で確立された確認ＳＭＴＰと同じＳＭＴＰ接続ではなく、この配送ＳＭＴＰ接続を通じて実行される。確認ステップと配送ステップのために別個のＳＭＴＰ接続を確立するこのプロセスは、サーバー接続を開始するのに先立って配送可能性を決定することが望ましいような事例において有益である。
【００６３】
ここで図６Ａとともに図７Ａを参照すると、図７Ａは本発明に基づく、ドメインベースのフロー制御、配送可能性確認（受信者サーバー利用可能性および受信者情報有効性の確認を含む）およびデータベースフィードバックループを含む電子メッセージ配送プロセスの諸ステップを示すフローチャートである。図６Ａのプロセス４００Ａの場合と同様、図７Ａに示したプロセス５００Ａは、単一のＳＭＴＰ通信を通じて生起する確認ステップおよび配送ステップを含んでいる。プロセス４００Ａに含まれているステップのすべてに加えて、プロセス５００Ａはさらに判断４１０に続く判断５０２を含んでいて、宛先の受信者（すなわちユーザー）が受信者サーバー上に存在するかどうかの判定が行われる。換言すれば、判断５０２は、データベース４０２によって提供された受信者情報が有効であるかどうかを判定するのである。判断５０２の結果がＮＯ（そのユーザーが受信者サーバー上に存在しない）であれば、プロセス５００Ａは先ほどと同じでＳＭＴＰ通信を打ち切って配送失敗をデータベース４０２に書き込むステップへと進む（図に示したステップ４１２および４１４）。この方法により、プロセス５００Ａは図６Ａのプロセス４００Ａで提供されているような受信者サーバー確認ステップに加えて追加的な受信者情報有効性の確認ステップを提供する。
【００６４】
同様に、図７Ｂは図６Ｂに示されたようなプロセス４００Ｂの変形を示している。図７Ｂはやはり本発明に基づく、ドメインベースのフロー制御、配送可能性確認（受信者サーバー利用可能性および受信者情報有効性の確認を含む）およびデータベースフィードバックループを含む代替的な電子メッセージ配送プロセスの諸ステップを示すフローチャートである。図７Ｂに示したプロセス５００Ｂは確認ＳＭＴＰハンドシェークを通じた確認ステップおよび別個の配送ＳＭＴＰ通信を通じて生起する配送ステップを含んでいる。図６Ｂのプロセス４００Ｂと比較して、プロセス５００Ｂは受信者情報をチェックするための別個のステップ５１０を備えている。ステップ５１０は確認ＳＭＴＰ通信を開始するステップ４０８′を含み、それに受信者サーバーが存在するかどうかの判断４１０および宛先の受信者が受信者サーバー上に存在するかどうかの判断５０２が続く。次いで、判断４１０および５０２への答えがいずれもＹＥＳであれば、ステップ４３０で、確認ＳＭＴＰ通信とは別個の配送ＳＭＴＰが開始されてメッセージの実際の配送が実行される。
【００６５】
図８Ａは、本発明に基づく、ドメインベースのフロー制御、配送可能性確認（受信者サーバー利用可能性および受信者情報有効性の確認を含む）、後段メッセージ生成およびデータベースフィードバックループを含むいま一つの電子メッセージ配送プロセスの諸ステップを示すフローチャートである。図８Ａに示したプロセス６００Ａは単一のＳＭＴＰ通信を通じて生起する確認ステップおよび配送ステップを含んでいる。プロセス６００Ａは本質的には図７Ａに示したプロセス５００Ａの変形であるが、さらに後段メッセージ生成ステップ６０２を含んでいる。すなわち、配送可能性確認ステップ４１０および５０２は、事前生成された電子メールメッセージから抽出された受信者情報ではなく、データベース４０２から与えられるデータパケットのみに基づいて実行される。次いで、後段メッセージ生成ステップ６０２によって、判断４１０および５０２で配送可能性が確認された受信者のみについての実際の電子メールメッセージ生成が行われる。これにより事前生成された電子メールの保存のための必要メモリが少なくなる。
【００６６】
図８Ｂは、やはり本発明に基づく、ドメインベースのフロー制御、配送可能性確認（受信者サーバー利用可能性および受信者情報有効性の確認を含む）、後段メッセージ生成およびデータベースフィードバックループを含む代替的な電子メッセージ配送プロセスの諸ステップを示すフローチャートである。図８Ｂに示したプロセス６００Ｂは確認ＳＭＴＰハンドシェークを通じた確認ステップおよび別個の配送ＳＭＴＰ通信を通じて生起する配送ステップを含む。図８Ａが図７Ａのプロセス５００Ａに後段メッセージ生成ステップを追加したのと同様、図８Ｂは本質的には図７Ｂのプロセス５００Ｂに後段メッセージ生成６０２を追加するものである。
【００６７】
図９のＡおよびＢは従来技術の「保存して転送」法の電子メッセージ配送を本発明の「構築して転送」モデルと比較するフローチャートである。図９のＡは前述した従来技術の「保存して転送」モデルを示している。ここではメッセージ配送エンジンは完全な電子メッセージを受け付け、そのメッセージをディスクに書き込み、ドメイン名（電子メッセージのヘッダ部に含まれている）の位置をつきとめ、そして当該メッセージをインターネットを通じて宛先の受信者に向けて届ける。具体的には、図９Ａに示したプロセス７００Ａは入力電子メッセージを受け付けるステップ７０２で始まる「保存して転送」モデルを示している。そのようにして受信された電子メッセージはステップ７０４でディスク上にファイルとして保存される。次いで、ステップ７０６で、電子メッセージ内で指定されている受信者サーバーのドメインが、たとえばＤＮＳ検索を通じて「検索」される。次いでステップ７０８で電子メッセージはインターネット３０に向けて送信される。前述したように、プロセス７００Ａは不都合である。なぜなら…［空白を埋めてほしい］。
【００６８】
これに対し、図９のＢは本発明の「構築して転送」モデルを示している。ここではメッセージ配送エンジンは電子メッセージ（完全なメッセージとしてでも離散的なデータパケットとしてでもよい）を受け付け、そのメッセージの配送可能性を確認し、次いで配送可能性確認の結果によってインターネットを通じて宛先の受信者に配送するためのメッセージを構築する。図９のＢに示したプロセス７００Ｂはやはり入力電子メッセージを受け取るステップ７０２で始まる。しかし、入力電子メッセージはディスク上のファイルとしてではなく、メッセージについての情報のビットを含むデータパケットとして保存される。プロセス７００Ｂはさらに、先に述べたようにこれらのデータパケットに基づいて配送可能性の確認のためのステップ７２０を含む。さらに、プロセス７００Ｂにおいては、実際の電子メールメッセージはメッセージの配送可能性が確認された後のステップ７２２まで構築されない。プロセス７００Ｂは次いで結果として得られるインターネット３０を通じて配送することに進む。
【００６９】
図１０Ａおよび図１０Ｂは、従来技術と、メッセージフィルタのような追加的なプロセスがメッセージサーバー機能に追加された本発明とを比較するフローチャートである。図１０Ａに示すように、従来技術の配送エンジンはメッセージサーバー８０２においてユーザー（図示せず）から完全なＳＭＴＰメッセージを受け付け、次いでそのメッセージをＳＭＴＰ通信によりたとえばウイルス対策アプリケーション８０４に、次いで別のＳＭＴＰ通信によりスパムフィルタ８０６に、次いでさらに別のＳＭＴＰ通信によりコンテンツフィルタ８０８に、次いでさらにいまひとつのＳＭＴＰ通信を通じて送信のためにメールサーバー８１０へと送り、該メールサーバー８１０がさらにいまひとつ別のＳＭＴＰ通信によって宛先の受信者へと送る。この複数のＳＭＴＰハンドシェークプロセスは面倒なばかりか時間や通信帯域を費消する。これに対し、図１０Ｂの配送エンジンはメッセージサーバー８５２において電子メッセージをデータソースからデータパケットとして、たとえばＳＭＴＰによって、あるいはアプリケーションプログラムインターフェース（ＡＰＩ）によって受け付け、次いでその電子メッセージを、ウイルス対策アプリケーション８５４、スパムフィルタ８５６、コンテンツフィルタ８５８および着信ルータ８６０のようなさまざまなプロセスを通るようＡＰＩによって送り出し、追加プロセスどうしの間のＳＭＴＰ通信は必要ない。次いでメッセージはたとえばＳＭＴＰ通信によって送信者メールサーバー８６２から宛先の受信者へと送り出される。
【００７０】
以下で電子メッセージ配送における本発明の手法についてさらに議論する。
一般的な手法
ＳＭＴＰメッセージ配送のためのこの設計しなおされたアーキテクチャを使ったメッセージ送信の一般的な手法は、サーバーに配送のためにメッセージを供給し、受信サーバーとのＳＭＴＰ通信を開始し、配送のためにメッセージを構築し、最終的にそのメッセージコンテンツを受信サーバーに転送する。このそれぞれについて以下で順に扱う。
【００７１】
サーバーはまず送信者および受信者情報を供給される。このプロセスは完全な「適切に形成された」ＳＭＴＰメッセージまたはプロセス中に組み合わされてメッセージを生成するデータパケットの集合を受領することを含む。好ましい実装においては、入力はデータパケット／ポイントの集合で、あとでメッセージ構築ができるようなものである。このデータは、受信者電子メールアドレス、件名欄、送信者アドレスなどといったメッセージヘッダのための情報を含む。また、メッセージボディのための情報も含む。これはテキスト、ＨＴＭＬコード、画像、別個のデータソースからの保存された個人情報、オーディオ／ビデオファイル、添付ファイルまたはその他の種類のいくつもの電子データのいかなるものをも含みうる。
【００７２】
ひとたびシステムが有効なＳＭＴＰ接続のために必要とされるデータポイントを有したら、受信サーバーとの接続を開始する。受信サーバーへの通信ソケットを開き、通常のＳＭＴＰ通信を開始することによって、システムはメッセージの「配送可能性」を決定することができる。配送可能性が肯定的に確認された場合、システムは、配送のために、提供されたデータポイントに基づいて、関係するプロトコル（たとえばＳＭＴＰ）のためにフォーマットされた完全なメッセージを構築する。配送可能性が否定された場合には、システムはメッセージに配送不能のフラグを立てて受信サーバーとの接続を閉じる。
【００７３】
メッセージ配送は配送可能性試験が成功し、メッセージが構築されたあとでのみ生起する。ひとたびこれらのイベントが生起したら、通信ソケットを通じてメッセージが受信者サーバーに転送され、システムは接続を閉じる。
上記の各ステップについての詳細な説明
このプロセスが電子メッセージに適用される過程を詳細にたどろうとするならば、下記に概括される過程のように進行することになる。
【００７４】
ａ）所望のメッセージを生成するのに必要なすべての情報を含むデータパケットの集合がシステムによって受け付けられる。
【００７５】
ｂ）送信サーバーが前記データパケットを調べて受信サーバーのドメイン名をさがす。
【００７６】
ｃ）送信サーバーがインターネットドメイン名サービス（ＤＮＳ）インターフェースでこのドメイン名を使ってメール交換（MX）レコードを検索する。このプロセスはこのメッセージの受信サーバーの実際のＩＰアドレスを返す。
【００７７】
ｄ）送信サーバーは受信サーバーのＩＰアドレスへのＴＣＰ／ＩＰソケット接続を確立する。
【００７８】
ｅ）接続したら、受信サーバーは自らの宣言を送信する。
【００７９】
ｆ）送信サーバーは自分の名前を引数として“HELO”コマンドを発する。
【００８０】
ｇ）すると受信サーバーが、送信サーバーが有効であり、受信サーバーのシステムに電子メールを送信できることを検証する。受け付けられる場合は、受信サーバーは“250  Welcome”コマンドで応答する。接続が拒否される場合は、受信サーバーは“500  connection  refused”コマンドで応答する。
【００８１】
ｈ）この時点で送信サーバーが“MAIL  FROM:  senderprefix@senderdomain.com”コマンドを用いて電子メールの送り主を宣言する。
【００８２】
ｉ）今一度、受信サーバーは、送信者のアドレスが受信サーバーに電子メールを配送することが許されていることを検証する。電子メールが受け付けられる場合には、受信サーバーは“250  Okay”コマンドを用いて応答する。メッセージが受け付けられない場合には、受信サーバーは“500  Not  allowed”コマンドを用いて応答する。
【００８３】
ｊ）この時点で送信サーバーは“RCPT  TO:  recipientprefix@recipientdomain”コマンドを送って受信サーバーに誰が当該メッセージを受信すべきかを伝える。
【００８４】
ｋ）受信サーバーは受信者アドレスが当該ドメイン内で有効なアドレスであり、メッセージを受信できる状態にあることをチェックして受信者アドレスを検証する。受信者アドレスが有効かつ利用可能であれば、受信サーバーは“250  Okay”コマンドを用いて応答する。受信者アドレスが有効でなければ、受信サーバーは“500  User  Unknown”またはその他のユーザー利用不能コマンドを用いて応答する。
【００８５】
ｌ）本発明のプロセスが現状技術から離れるのはこの時点である。ひとたびＳＭＴＰ対話における検証トランザクションが生起したら、送信サーバーは、配送可能性の肯定的検証の場合には、メッセージを構築して送信プロセスを継続する。また、配送不能エラーの場合には、エラーを記録ログに書き込み、プロセスを中止して接続を閉じる。
【００８６】
ｍ）この新しいプロセスにおいては、ひとたびメッセージが構築されれば、送信サーバーは“DATA”コマンドを送信する。
【００８７】
ｎ）受信サーバーがメッセージを受け付ける準備ができていれば、“250  Okay”のフォーマットでコマンドを送る。
【００８８】
ｏ）ひとたび送信サーバーが前述のokayを得たら、メッセージ内容全体を受信サーバーに送る。そのメッセージは“<cr><lf>.<cr><lf>”という文字シーケンスで終わり、この文字列が受信サーバーにメッセージ完了を伝える。
【００８９】
ｐ）受信サーバーがメッセージを受け付けたら、今一度“250  Okay”コマンドを送信する。
【００９０】
ｑ）ひとたび最終的なokayが受信されれば、送信サーバーは“QUIT”コマンドを発し、それを受け取ると受信サーバーはソケットを切断し、両者とも通信を閉じる。
任意的な追加機能
「構築して転送」（データパケットベース）
「構築して転送」メッセージ交換は三つの主要ステップからなる。第一の最も重要なものは、一群のメッセージを送信するためにＳＭＴＰ通信が確立されている間、受信者情報、配送情報およびメッセージ内容情報を含むデータパケットを受け付けて、それをハードディスクドライブに書き込むのではなくランダムアクセスメモリ（ＲＡＭ）に保存する機能である。第二のキーとなる特徴は、配送その他の個人別情報を含んでいる一意的な受信者データパケットを大量に処理する間、主たる電子メール内容（ボディおよびある種のヘッダ）の単一のコピーを保持することである。「構築して転送」プロセスにおける第三のステップは、ＳＭＴＰ接続が確立されて配送可能性が判定されたのち、受信サーバーへの送信前（または送信中）に、前記電子メール内容を各受信者の一意的な配送その他の個人別情報とマージすることである。
メモリ内で扱われるメッセージ（ディスクでなくＲＡＭに書き込み）
このシステムのキーとなる特徴の一つはメッセージを電子メモリ中で扱うことである。これはファイルＩ／Ｏではなくアドレッシング可能なＲＡＭリソースを用いて行われる。システムの典型的なハードディスクドライブではなくこのリソースを使うことによって、従来技術に一般的であったファイルＩ／Ｏに付随するボトルネックおよび単一障害点を減らすことができる。
動的なＩＰアドレス割り当て
動的なＩＰアドレス割り当ては配送負荷をずっと広いアドレス空間に拡散させるために用いられる。これはより高速な配送の余地を生み、大量に配送されるメッセージが未承諾広告メールと見なされる可能性を減らす。
逐次法（各受信者についてのハンドシェーク／送信）と並列法（確認接続一回、別の配送接続）
この配送可能性確認ステップは逐次的なやり方で、すなわち同じソケット接続を利用して一ステップずつ行うこともできれば、実際の配送に並列して行うこともできる。いずれの方法にもメリットがあり、結果は同じになる。
送信者は人間でもアプリケーション／機械でも可
このシステムのための主要な受け付け法（acceptance  method）はデータであって適切に形成されたＳＭＴＰメッセージではないため、発信元は人間でもコンピュータシステムでもよい。データ駆動実装の使用はＳＭＴＰメッセージの使用を排除するものではなく、互換範囲を広げるものである。
データ駆動サポート
メッセージ転送を別々のデータパケットに分解することによって、システムは既存のアプリケーションおよび将来のアプリケーションとのインターフェースをもつばかりでなくメッセージ配送プロセスの間のメッセージ拡張処理の可能性を拡大することができる。
【００９１】
ａ）さまざまなソフトウェアとのＡＰＩ接続の特徴：ＡＰＩ「チェーン」を確立することによって、各メッセージが「修飾」アプリケーションに渡されることができる。そのようなアプリケーションはウイルス保護、スパムフィルタリング、コンテンツ管理などの機能を果たしうる。
【００９２】
ｂ）トリガーされた電子メール：提案されるシステムにおいてメッセージはデータパケットから構成されるので、このシステムはデータベーストリガーによって駆動される電子メールの修飾および配送に役立つ。データベーストリガーは、データベース中で特定の基準が満たされたときに発生する。データベースは電子メールの配送のようなイベントを「トリガー」することができる。メッセージプロセスをデータパケットに対して開き、メッセージを配送プロセスの後期に構築することによって、トリガーによるメッセージ交換が実際的になる。
【００９３】
ｃ）発信メッセージおよびイベントの監視：データ駆動メッセージ交換がもたらしうる追加的な機能に加え、このデータ手法はシステム管理者がシステム内でのあらゆるメッセージ交換活動を監視し、制御することを可能にする。メッセージ数の単なる計数から高度なＡＰＩチェーン管理までである。
ドメインベースのフロー制御
ドメインベースのフロー制御は、配送が予定されている電子メールドメインのグループ全体を見渡して分布を「平常化」し、単一のドメインが他のドメインの配送をブロックすることがないようにすることによって達成される。当業界で周知のように、電子メールアドレスのいかなるリストも、大手ＩＳＰのアドレスが大半を占め、残りがより小規模のサービスプロバイダーのアドレスで埋められている。典型的なリスト送信シナリオでは、電子メールはドメイン名に基づいてグループごとに配送される。大手ＩＳＰの一つまたは複数がメールを受け付けるのが困難になったり、速度低下を起こしたりした場合、リストの残りの部分は先行するメールが送られるのを待つことになる（古典的なＦＩＦＯ挙動）。この挙動が大量のメールを迅速に配送するシステムの機能を制限することは明らかである。ドメインベースのフロー制御は、各ドメインを等しいサイズの部分に分割し、厳密などメイン順ではなくこれらのグループに基づいて配送することによって達成される。
着信メッセージの受信
システムのデータ駆動性と並んで、標準的なＳＭＴＰプロトコルを使ってメッセージがシステムにはいってくるのをも許可する。これは拡張機能を可能とし、それについてさらに説明する。
ハンドシェーク／配送結果に基づくデータベースへのデータフィードバック
このシステムの強力な機能の一つは、実際に電子メールを送信することなくメール配送における不達や失敗を記録する機能である。これはメッセージ生成および配送の前に受信サーバーからの応答を記録することによって達成される。
データ駆動サポート
当該システムのもう一つの側面は、一つまたは複数のデータソースを各メッセージのための入力として扱う機能である。この機能は標準的なメールサーバーを従来技術の「メール中継」の考えから解放し、その代わりにメール配送システムの内部にメッセージ生成工場を生成する。
マクロ置換フィールド、修飾電子メール、個人化、内容修正
上述した進歩は、各メッセージが、別個のデータソースから引き出され、カスタム業務ロジックまたは標準的なマクロ置換を通じて当該メッセージに組み込まれる個人化されたデータを含むことを可能にする。これはメッセージ生成プロセスにおいて無限の柔軟性を提供し、従来技術とは著しい対照をなすものである。
アーキテクチャの柔軟性
提案されるシステムのキーとなる機能の一つは、メールシステムアーキテクチャを拡大し、拡張する機能である。システム内を移動するメッセージへの「インライン」ＡＰＩを許可することによって、従来技術において一般的な逐次的な手法を使うことなく、メッセージを修飾したり、修正したり、操作したりすることができる。このプロセスは次のように作用する：
ｉ  メッセージがシステムに受け入れられる。
【００９４】
ｉｉ  最初のメッセージ関連処理が発生する。
【００９５】
ｉｉｉ  メッセージが、ＡＰＩチェーンの順序付けられた処理を可能にする「待ち行列マネージャ」に渡される。
【００９６】
ｉｖ  次いでメッセージがシステム内に登録されている各ＡＰＩプロセスに渡される。
【００９７】
ｖ  ひとたびメッセージがＡＰＩチェーンを通過し終えると、配送経路を継続する。
【００９８】
ｖｉ  次いでメッセージが最終的な受信者に配送される。
他のメッセージ配送プロトコル
これまでに議論した電子メールメッセージ交換プロトコルに加えて、このシステムはそれ以外の現在または将来のインターネットプロトコルについても前述した機能のすべてを可能にするために用いることができる。これは、ＳＭＳ（Simple  Messaging  Service）やその他の現在利用可能な、あるいは将来開発されうるプロトコルを含む。
着信／発信ＭＴＡとして使うための適応
拡張されたプロトコルに加えて、このシステムはネットワークの内側に面するよう向けて当該技術における同じ進歩を用いて着信メッセージを処理できるようにすることもできる。着信処理またはメッセージ中継の機能として、システムは、配送可能性が完全に決定されている場合、あるいはメッセージが明示的に後刻再送信するよう指示されている場合に、メッセージに対して再試行を試みるよう構成されることができる。このシステムはまた、純粋にメッセージ交換の中継者として機能して従来技術のパフォーマンスおよび機能を向上させるよう拡張されることもできる。
追加的な諸修正
ＡＰＩイベント管理および伝送
従来技術のＡＰＩプロセスの一つの例は、前述したＭＩＬＴＥＲプロセスである。図１１Ａを参照すると、従来技術のメールサーバー内における従来技術のＭＩＬＴＥＲ  ＡＰＩのイベント管理および伝送プロセス９００が示されている。以下の記述では、アプリケーションはこのＡＰＩとのインターフェースをもつよう書かれた何らかのコンピュータコードとして定義され、リスナーはシステムに埋め込まれたＡＰＩインターフェースとして定義される。プロセス９００がメールサーバー９０２内でトリガーされるのは、ステップ９０６においてメールサーバー内でＡＰＩイベントが実行されたときである。ステップ９０６でのＡＰＩイベントの実行に続いて、メールサーバーは次いでステップ９０８においてそのＡＰＩイベントについてのリスナーをさがしてスキャンする。ステップ９０８に判断９１０が続き、ＡＰＩリスナーがみつかったかどうかが判定される。判断９１０への答えがＹＥＳ（一つまたは複数のＡＰＩリスナーがそのイベントについて見出された）であれば、ステップ９１２でメッセージはランダムに選択された第一のリスナーに渡される。ステップ９１４で、第一のリスナーはそのメッセージオブジェクトを変更したり、削除したり、あるいは未修正で通過させたりなどしてはたらきかけることができる。ステップ９１６で、この第一のリスナーがメールサーバーに応答を送る。この応答はたとえば、メールサーバーが起点の送信者サーバーに送り返すための結果コードを含んでいてもよい。追加的なＡＰＩリスナーがみつかっていた場合には、メッセージオブジェクトは次いでステップ９１８で第二のリスナーに渡される。そしてこの第二のリスナーについてステップ９１２からステップ９１６が繰り返される。このプロセスは前記ＡＰＩリスナーのすべてが当該メッセージにはたらきかけ終わるまで繰り返される。次いでステップ９２０でメールサーバーは、所定のメッセージ交換プロトコルに従って起点の送信者サーバーに応答を送り、ステップ９２２でプロセスは次のメッセージイベントに進む。
【００９９】
前述のＭＩＬＴＥＲアーキテクチャはＭＴＡが外部アプリケーションとさまざまな種類の処理のためにインターフェースをもつことを可能にする一方で、ＭＴＡのパフォーマンス、アーキテクチャおよび機能の制限がＭＩＬＴＥＲアーキテクチャの適用可能性の性質を制限していた。具体的には、ＭＩＬＴＥＲインターフェースは一般に単一の電子メール処理アプリケーション（たとえばウイルスフィルタ）とＭＴＡとのインターフェースとなってＭＴＡをそのアプリケーションのためのメール中継機構として強化するために使用される。ネットワークまたはシステムのためにそのようなアプリケーションが二つ以上必要とされる場合には（たとえばウイルスフィルタとスパムフィルタなど）、複数のＭＴＡが列をなして展開され、図１０Ａに示すように一方が他方にメッセージを供給する。
【０１００】
この問題ある逐次的な処理方式が広まっているのは主として現状技術におけるＭＴＡの制約のためである。そうした制約には、遅い処理スピード、ハードウェアリソースの非効率的利用、非効率的なデータトラフィック管理、利用可能プロセスが複数ある状況で処理を待っているメッセージのための効率的待ち行列処理法の欠如、複数のプロセスを通過するメッセージの順序付けのための手段の欠如、が含まれる。こうした制約が組み合わさった結果、複数のＡＰＩプロセスがＭＴＡの単一のインスタンス内で実装されたときの、利用可能システムリソースの過剰な使用、トラフィックのボトルネック、潜在的なシステム障害といった許容できない危険性を作り出す。したがって、現状技術においては、そのような諸プロセスはほとんど常に、各メッセージを、メッセージを受け付けるための受信ＭＴＡと次の処理アプリケーションもしくはインターネットを通じて配送するための主要ＭＴＡに転送するための別個の送信ＭＴＡとによってサポートされている別個のアプリケーションを通じて送ることによって逐次的に適用される（たとえば、図１０Ａの配送エンジン８００によって例示されるように）。結果として、システム全体の配送効率は、複数のＭＴＡおよび処理アプリケーションを通じた逐次的な処理の一連の階層の配送効率によって制限される。この逐次的なアーキテクチャはまたハードウェア集約的かつサポート集約的である。
【０１０１】
図１０Ｂとの関連で記述した本発明のＡＰＩフィードプロセスへの代替として、複数のアプリケーションがいかなるメッセージイベントについても登録することができ、同時に実行順をも指定するように修正することもできる。それと同時に、本発明のＡＰＩプロセスは、データ伝送のためのソケットチャネル・セレクタ法、プロセス間のメッセージの流れを最適化するためのイベント待ち行列形成機構、および大きなサイズのメッセージのための処理効率を改善するためのメッセージ圧縮を含むがこれらに限られないパフォーマンス改善の諸方法を強化しうる。本発明のＡＰＩプロセスの詳細について以下に詳細に説明する。
【０１０２】
ＳＭＴＰプロトコルを使った電子メッセージの配送プロセスが複数のメッセージイベントを含んでいることは知られている。たとえば、接続、HELO、MAIL  FROM、RCPT  TO、DATA、QUITである。本発明のＡＰＩプロセスにおいては、ＡＰＩアプリケーションは配送プロセス中のいつでもこれらのメッセージイベントに登録することができる。換言すれば、登録はPost_Connect、Post_HELO、Post_MAIL、Post_RCPT、Post_DATA、Post_QUIT、Msg_Injector、Pre_Connect、Pre_HELO、Pre_MAIL、Pre_RCPT、Pre_DATA、Pre_QUITのインスタンスにおいて生起できる。
【０１０３】
イベント後（Post-）およびイベント前（Pre-）登録の例が図１１Ｂおよび図１１Ｃに示されている。まず図１１Ｂを参照すると、本発明に基づくpost_HELOイベント登録９３２を含むイベント後ＡＰＩプロセスの例９３０が示されている。イベント後ＡＰＩプロセス９３０は送信サーバー９３４と受信サーバー９３６との間の通信を含む。一連のＳＭＴＰイベント（括線９３８で示されている）が送信サーバー９３４と受信サーバー９３６との間で発生し、それには送信サーバーから受信サーバーに送られるHELO要求も含まれる。Post_HELOイベント登録９３２の規定では、post_HELOイベントのために登録されたＡＰＩアプリケーションは、サーバーが送信サーバーからのHELOコマンドを受け付けたのちにメッセージオブジェクトを受信する。これに対し、図１１Ｃはpre_HELOイベント登録９４２を含むイベント前ＡＰＩプロセスの例９４０が示されている。イベント前ＡＰＩプロセス９４０では、pre_HELOイベントのために登録されたＡＰＩアプリケーションは、送信サーバー９３４が受信サーバー９３６にHELOコマンドを発する前にメッセージオブジェクトを受信することになる。
【０１０４】
メッセージ交換イベント前にトリガーされうるイベント（たとえばpre_HELO）を追加することにより、サーバーから出て行く途上のメッセージに対してフィルタアプリケーションを適用できるようになる。これは従来技術のＭＩＬＴＥＲプロセスに対して著しい前進と考えられる。本発明のＡＰＩプロセスでは、アプリケーションはメールサーバーに、ローカルまたはリモートのＴＣＰソケット接続を通じて登録しうる。このアプリケーション登録は送信者が補足したいイベントおよびその特定の送信者のリスナー待ち行列における順番を指定する。本発明のこのＡＰＩイベント登録の概念が図１１Ｄに図解されている。ここに示されているのは本発明に基づくＡＰＩのブロック概略図９５０である。ＡＰＩ概略図９５０は中央メールサーバー９５２を含んでおり、これが上に挙げた複数のメールイベントのうちの少なくとも一部のための複数の登録（参照符号９５４Ａ〜９５４Ｇをもつボックスで示されている）を扱う。すなわち、メールサーバー９５２は複数のアプリケーションからの複数の登録を扱い、複数のアプリケーションが同じイベントのために登録してもよい。任意的に、メールサーバー９５２はＡＰＩイベント順序付け機能（ボックス９５６で示される）を含んでいてもよい。これは、メールサーバー９５２が複数のアプリケーションからの登録を扱う際に、各アプリケーションが、該特定のＡＰＩアプリケーションがリスナー待ち行列における順番を指定できるようにするものである。リスナーとＡＰＩアプリケーションの両者は、処理を待っているメッセージを一時的に保持しておくための高性能メッセージオブジェクト待ち行列を備えていてもよい。待ち行列機構は、サーバーの主たる活動を阻害することなく、ＡＰＩアプリケーションおよびリスナーのより高速なフィードを可能にする。ＡＰＩイベント順序付け機能９５６を含めることによって、たとえば、ある種のＡＰＩアプリケーションが他のＡＰＩアプリケーションより優先されるようにできる。
【０１０５】
ここで図１１Ａおよび図１１Ｄとともに図１１Ｅを参照すると、メールサーバー９５２が複数の登録を扱うプロセスが記述されている。図１１Ｅに示されている本発明のＡＰＩイベント管理・伝送プロセス９６０は図１１Ａに示したＭＩＬＴＥＲ  ＡＰＩプロセスのステップのいくつかを共有しているが、ＭＩＬＴＥＲプロセス９００に加えていくつかのステップを含んでいる。プロセス９６０がメールサーバー９５２内でトリガーされるのは、ステップ９０６においてメールサーバー内でＡＰＩイベントが実行されたときである。ステップ９０６でのＡＰＩイベントの実行に続いて、メールサーバーは次いでステップ９６２においてＡＰＩイベント待ち行列にメッセージを追加する。するとメールサーバーがステップ９０８においてそのＡＰＩイベントについてのイベントリスナーをさがしてスキャンする。ステップ９０８に判断９１０が続き、ＡＰＩリスナーがみつかったかどうかが判定される。判断９１０への答えがＹＥＳ（一つまたは複数のＡＰＩリスナーがそのイベントについて見出された）であれば、ステップ９６４で当該メッセージのサイズが決定される。判断９６４で当該メッセージがある所定の閾値より大きいと判定された場合には、当該メッセージはステップ９１２に進む前にステップ９６６で圧縮される。判断９６４で当該メッセージが十分小さいと判定された場合には、当該メッセージはすぐに当該メッセージを最初のリスナーイベント待ち行列に渡すステップ９１２に向けられる。この伝送は、たとえば、ソケットチャネル・セレクタ法を使って実行されうる。この最初のリスナーイベント待ち行列はステップ９６８でメッセージを受け付け、その後、ステップ９１４で、リスナーはそのメッセージを変更したり、削除したり、あるいは未修正で通過させたりなどしてそのメッセージにはたらきかけることができる。ステップ９１６で、このリスナーがそのメッセージをイベント待ち行列に返し、メールサーバーに応答を送る。この応答はたとえば、メールサーバーが起点の送信者サーバーに送り返すための結果コードを含んでいてもよい。次いでステップ９７０でメッセージはイベント待ち行列から除去される。追加的なＡＰＩリスナーがみつかっていた場合には、メッセージは次いでステップ９１８で第二のリスナーに渡される。そしてこの第二のリスナーについてステップ９１２、９６８、９１６、９７０が繰り返される。これらのステップは前記ＡＰＩリスナーのすべてが当該メッセージにはたらきかけ終わるまで繰り返される。次いでステップ９７２でメールサーバーは所定のメッセージ交換プロトコル（たとえばＳＭＴＰ）に従って応答を起点の送信者サーバーに送る。次いでステップ９７４で当該メッセージがＡＰＩイベント待ち行列から除去され、ステップ９２２でプロセスは次のメッセージイベントに進む。変形として、図１１Ｅのプロセス９６０は上述した配送可能性確認プロセスと一緒に実行されてもよい。
設定可能なＲＡＭまたはハードディスクでのメッセージ交換処理
前述の実施形態への可能な修正の例として、本発明の電子メッセージ配送システムは、メッセージを、上述したようなＲＡＭ処理内のデータパケットとして扱う処理と従来技術で用いられているようなハードディスクドライブ（ＨＤＤ）上に保存されたファイルとして扱う処理との間の選択を与えるよう構成されることもできる。すなわち、受信者サーバーにおける受信者に配送すべく宛てられているメッセージが送信者から受信されると、送信メールサーバーはこのメッセージの一部または全部を保存のためにＨＤＤに書き込むよう構成してもよい。メッセージの一部または全部をＨＤＤに保存するというこのオプションは上述したような本発明のＲＡＭベースの処理を、たとえばＲＡＭ処理中に電力供給が切れた場合にバックアップ記憶システムを提供することによって補完する。そのような修正されたシステムが図１２Ａに図示されている。ここで示されているのは、設定可能なＲＡＭ／ＨＤＤメッセージ処理方式を使ってメールサーバー内で生起するメッセージ処理プロセスのフローチャートである。このメッセージ処理プロセスは、全体として参照符号１０７０で示されており、ステップ１０７２でシステムが送信者サーバーからメッセージを受け付けることによって始まる。所与のメッセージの一部または全部がＨＤＤに保存されるべきかどうかについての設定は設定記憶１０７４に保存されている。設定記憶１０７４で指定されている設定はステップ１０７６でチェックされる。判断１０７８によって所与のメッセージが部分的または全体的にＨＤＤに保存されるべきかどうかが判定される。判断１０７８への答えがＹＥＳ（メッセージの一部または全部がＨＤＤに保存されるべきである）であれば、ステップ１０８０でメッセージの少なくとも一部がＨＤＤ上の一時記憶に書き込まれる。次いでステップ１０８２でメールサーバーがこの保存されたメッセージをＨＤＤから読んで、次いでステップ１０８４で配送シーケンスへと進む。これは上述の通りで、たとえば先述の図９Ｂにおいて示したような配送可能性確認および後段メッセージ生成を含む。判断１０７８への答えがＮＯ（メッセージはＨＤＤに保存されるべきではない）であれば、メールサーバーは直接ステップ１０８４の配送シーケンスへと進む。追加的に、配送ステップ１０８４に続いて、メールサーバーは判断１０８６を行い、メッセージがＨＤＤに保存されているかどうかを再び判定する。判断１０８６への答えがＹＥＳ（メッセージの一部または全部がＨＤＤに保存されている）であれば、ステップ１０８８で保存されたメッセージが任意的にＨＤＤから除去されうる。判断１０８６への答えがＮＯ（メッセージはＨＤＤには保存されていない）であれば、メッセージ処理は単にステップ１０９０で終了される。設定可能なＲＡＭ／ＨＤＤメッセージ処理は、配送スピードとシステム障害の場合のメッセージ回復の確度との間の好ましいバランスを管理者が設定できるようにするので有益である。
【０１０６】
さらにもう一つの代替として、設定可能なＲＡＭ／ＨＤＤメッセージ処理は、所与のメッセージがＨＤＤに保存されるべきかどうかを所定のシステム閾値に基づいて決定するよう修正することもできる。メールサーバー内でのそのような閾値ベースの処理は、図１２Ａで図示したプロセスと同様であるが、閾値ベースの処理はメールサーバーの現在状態を既知のシステムパフォーマンス閾値（たとえばメモリ使用率）と付き合わせてチェックしてある特定のメッセージがＨＤＤに保存されるべきかどうかを決定する。閾値ベースのプロセス１０９５の詳細が図１２Ｂに図示されている。閾値ベースのプロセス１０９５は、図１２Ａに示したメッセージ処理プロセス１０７０と実質同様であるが、追加的にシステム閾値を現在状態と比較するステップ１０９６を含んでいる。この比較ステップ１０９６において、メールサーバーはシステムの現在状態を、メモリ使用率、ハードディスク使用率、スループット容量といった既知のシステムパフォーマンス閾値と付き合わせて比較する。次いで判断１０９８が行われてこの所定の閾値に達しているかどうかが判定される。判断１０９８がＹＥＳ（前記の特定の閾値を超えている）であれば、メッセージはステップ１０８０でＨＤＤに書き込まれる。判断１０９８がＮＯ（前記の特定の閾値に達していない）であれば、メッセージはステップ１０８４で配送シーケンスに送られる。このような閾値ベースのシステムは、システム使用率閾値を、すなわち、システムリソースが厳しい使用レベルに近づいたときにシステム障害の場合にメッセージ回復を保証するよう「保存して転送」処理を開始するタイミングを指定する「危険レベル」を、管理者が設定できるので有益である。
チャネル・セレクタ・ソケット管理
メールサーバー技術におけるもう一つの検討事項は、サーバー間の電子メール伝送のためのソケット通信の使用である。簡単に背景を説明すると、ソケットというのはプロセス間の物理的なリモートまたはローカルな接続のための機構である。ソケットは、標準的な入出力（Ｉ／Ｏ）関数がネットワーク通信機能を通じてＯＳ（たとえばＵＮＩＸ（登録商標））のサービスを流すインターフェースとなるものである。ソケット関数は通信の終点を生成し、そのソケットにアクセスするのに用いるファイル記述子を返す。ソケットにはポート番号とローカルホストのネットワークアドレスからなるソケットアドレスが関連づけられている。
【０１０７】
古典的なソケット通信モデルは、図１３Ａに図示した単一ソケットモデルである。図１３Ａに示した単一ソケットモデル１１００では、送信サーバー（起点）１１０２と受信サーバー（終点）１１０４との間の通信は専用の単一ソケットチャネル１１０６を介して起こる。
【０１０８】
ここで図１３Ａと併せて図１３Ｂを参照すると、古典的な単一ソケット生成および通信プロセスが記述されている。図１３Ｂは起点１１０２と終点１１０４との間にソケット接続１１０６を確立することによるサーバー間ソケット通信を使った電子メール送信のための標準的な処理シーケンス１１１０を示すフローチャートである。典型的には、シーケンスは、送信サーバーが、該サーバーがまだソケット接続を有していないネットワーク上またはインターネット上のある位置にある受信者サーバーへのメッセージ送信のプロセスを開始したときにいつでも開始される。従来技術のソケット接続プロセスは図１３Ｂとの関連で次のようにまとめることができる。
【０１０９】
ａ  ステップ１１１２で、送信サーバー（起点）でソケットを生成。
【０１１０】
ｂ  ステップ１１１４で、送信サーバーから受信サーバー（終点）へソケットを接続。
【０１１１】
ｃ  ステップ１１１６で、受信者サーバーがソケット接続を受け入れることを選ぶ。ひとたび接続が確立され、受け入れられたら、起点と終点との間で情報――標準的な電子メッセージプロトコル対話データおよびメッセージ内容の両方を含む――を転送するためにソケット通信チャネルが利用可能になる。
【０１１２】
ｄ  ステップ１１１８で、送信サーバーが受信サーバーにデータを送り、また受信サーバーからデータを受け取る。
【０１１３】
ｅ  ステップ１１２０で、受信サーバーがデータを送受信する。
【０１１４】
ｆ  ステップ１１２０に続いて判断１１２２が行われ、送信サーバーと受信サーバーとの間でさらにデータ転送が必要かどうかが判定される。判断１１２２への答えがＹＥＳ（さらなるデータが送信サーバーと受信サーバーとの間で交換される必要がある）であれば、プロセスは再びステップ１１１８および１１２０を繰り返す。判断１１２２への答えがＮＯ（データの流れが完了）であれば、送信サーバーはステップ１１２４で接続を終了させる。
両者とも（すなわち起点および終点とも）ソケットを通じて接続されている間はアクティブなままである。いずれの側も接続を中断したり閉じたりしてもよい。この接続は終点サーバーに（待ち行列から）複数の電子メールを送信するために使うことができる。送信が完了するか、どちらか一方のサーバーによって中断されるか閉じられるかしたとき、接続は切断されてソケットは消滅する。ソケット生成から情報転送、そして接続を閉じてソケットが消滅するまでのシーケンスは、サーバー間での電子メール送信の現在技術において標準的で一様である。一般に、開かれたソケットは、終点位置へのメッセージ／データの連続的な流れがある間のみ存在する（すなわち、前記位置への新しいメッセージは現在のメッセージの送信の完了に先立ってソケットに提示される）。
【０１１５】
従来技術の古典的な単一ソケット通信プロセスにはさまざまな固有の問題がある。図１３Ａおよび図１３Ｂに示した従来技術においては、電子メール送信は複数のデータトランザクションに関わる対話プロトコルを通じて行われる。この対話プロトコルは、プロトコル信号交換（すなわち、ハンドシェーク）とメッセージそのものを送信するための複数のデータトランザクションとの両方を含む。現状技術においては、個別にバインドされたソケットをもつ専用スレッドが対応する送信サーバーと受信サーバーとの間のある特定のメッセージのためのデータトランザクションすべてが完了するのを待たねばならない。同時進行する各スレッド／ソケット対はある特定の位置をもつ対話の専用であり、個々のメッセージ／対話が開始され、終了されるのに合わせて生成され、終了される。複数の終点に
複数の同時電子メール送信を行うためには、送信サーバーはその複数の終点に対応する複数のソケットを生成する必要がある。最も効率的な現在の慣行は、一つのスレッドが一つのソケットを管理するマルチスレッドのアプリケーション設計である。この場合、許される潜在的な同時ソケットの数は、基礎にあるＯＳ環境によって確立される制約条件に従って送信サーバーが扱うことのできる可能な同時スレッドの数によって支配される。しかし、現在利用可能なメールサーバーによって生成されうる同時スレッドの数は、メールサーバーを置いているコンピュータの基礎にあるＯＳによって制限される。したがって、複数の終点への同時電子メール送信の速度（すなわち、所与の電子メールサーバーについての一般的な電子メール送信速度）はサーバーのＯＳによってサポートされうる同時スレッドおよびソケットの数によって制限される。よって、この種のアーキテクチャではリソースの沈滞と競合が一般的である。
【０１１６】
図１３Ｃおよび図１３Ｄに図示したようなサーバー間のデータ通信における最近の進歩は、送信者サーバー（起点）から他の受信者サーバー（終点）にメッセージを送信するためにサーバー間の複数のソケットチャネルの間でデータの流れをうまく管理するためのコンピュータサーバーがセレクタを使用する（よってシングルスレッドである）ことを含む。セレクタは本質的には先に述べた複数スレッドのソケット管理機能を置き換えるものである。この従来技術のプロセスは、全二重のプロセス間接続を提供するためのインターネットのトランスポート層のプロトコルである転送制御プロトコル（ＴＣＰ）を使って行われる。
【０１１７】
まず図１３Ｃを参照すると、従来技術のデータ送信のための複数ソケットチャネル・セレクタ方式が記述されている。従来技術の通信プロセスは三つの主要構成要素を含んでいる：（１）ソケットチャネル（または単にチャネル）、セレクタ、そして受信サーバー（すなわち終点）である。図１３Ｃに示したように、複数ソケットチャネル・セレクタ方式１１３０は複数のソケットチャネル（参照符号１１３２Ａ〜Ｃで示されるチャネルＡ〜Ｃによって表されている）を含んでいる。各ソケットチャネルはデータのための接続ルートとして生成される。ソケットチャネル１１３２Ａ〜Ｃのそれぞれはセレクタ１１３６に対しての登録１１３４を経る。本質的には、セレクタはメールサーバーに出入りするあらゆる通信のための「門番」の役割をするもので、はいってくる通信、出て行く通信の両方を見張っている。セレクタは多数の同時通信チャネルを受け持っていてもよい。
【０１１８】
ここで図１３Ｃとともに図１３Ｄを参照すると、従来技術のＴＣＰ複数ソケットチャネル・セレクタ方式が記述されている。従来技術のＴＣＰプロセス１１４０においては、ステップ１１４２でソケットチャネルがデータのための接続ルートとして生成される。複数の通信要求に反応して複数のソケットチャネルが生成される。ステップ１１４２で生成された各ソケットチャネルは、ステップ１１４４で、終点位置（たとえばＩＰアドレス）および受信したいイベントの種類（たとえばソケット書き込み、読み取りなど）を指定してセレクタ１１３６に対して登録をる。するとセレクタはステップ１１４６で終点との要求された接続を開始し、ステップ１１４８で対応するチャネルによって登録された活動をポーリングする。判断１１５０では、セレクタはソケット接続の一つを通るデータがあるかどうかを判定する。判断１１５０への答えがＮＯ（はいってくるデータも出て行くデータも存在しない）であれば、セレクタはステップ１１４８でデータ通信活動のポーリングをする。判断１１５０への答えがＹＥＳ（ソケット接続の一つを通ってデータが伝送されている）であれば、セレクタは判断１１５２に進んでデータ伝送の方向を判定する。判断１１５２がデータ伝送の方向が送信者サーバーから受信者サーバーへの発信方向と判定すれば、セレクタはステップ１１５４でデータ終点に届ける。判断１１５２がデータ伝送の方向が着信方向と判定すれば、セレクタはステップ１１５６でそのデータに対してはたらきかける。セレクタによって行われる作用はプロトコル（今の場合ＴＣＰ）によって決定される。この従来技術のプロセス１１４０においては、受け取ったデータが所与のタスクを完了するのに十分かどうかをチャネルが判定しなければならない。データが不十分であれば、チャネルはセレクタからの追加的なデータを待ち、セレクタはステップ１１４８に戻ってさらなる活動のポーリングをする。ひとたびセレクタから完全なプロトコルメッセージが受信されたら、チャネルはプロトコルに基づいて受信された全データに作用する。チャネルが応答を発する場合、該メッセージはセレクタに返送され、ステップ１１４８および１１５４を通じて終点に配送される。チャネルからの応答が必要でなければ、セレクタはステップ１１５９で接続を閉じる。通信ソケットはいずれの端で中断したり閉じたりしてもよい。
【０１１９】
図１３Ｃおよび図１３Ｄに示した従来技術の複数ソケットチャネル・セレクタＴＣＰプロセスはいくつかの問題を呈する。従来技術のプロセス１１４０では、処理論理がセレクタ内で行われる一方、チャネルは単にセレクタへの要求を管理しているにすぎない。図１３Ｄのこの従来技術のプロセスは、現在ウェブサーバーにおいてハイパーテキスト転送プロトコル（ＨＴＴＰ）通信を管理するために使われている。これは一ステップの要求／応答パラダイムを使用するものである。すなわち、全プロセスは起点からの一つの要求および終点からの一つの応答に基づいている。本出願人らは、図１３Ｄに示した複数ソケットチャネル・セレクタＴＣＰプロセスは図１３Ａおよび図１３Ｂの古典的な単一ソケット−単一通信チャネルプロセスに対してデータ通信におけるいくらかの改善を与えるものの、プロセス１１４０は電子メール配送に使われるようなマルチステッププロトコルのためにはまだ非効率的で好適でないと考えられることを見出した。
【０１２０】
従来技術の前述した問題を回避し、ソケット通信プロセスを電子メール配送での使用のために適応させるため、本出願人らは、従来技術のソケット通信方法への代替を提供するいくつかのデータ通信方法を考案した。特に、本出願人らは、図１３Ｅおよび図１３Ｆに示されるように、チャネル・セレクタＴＣＰ法に基づきながらも複数ソケットチャネル・セレクタ方式に対して追加的な利点を提供する、改良された電子メッセージ交換サーバーを開発した。特に、本発明の複数ソケットチャネル・セレクタＴＣＰプロセスは、未完了コマンドをバッファ中に保存できるようにするためにソケットチャネルに状態管理およびバッファ測定を提供し、それにより多様なサイズのデータを用いたマルチステップ通信を可能にする。この、可変バッファ測定およびセレクタからソケットチャネルへの未完了読み書きを扱う機能の追加は結果としてデータ処理をセレクタからチャネルに移す。本出願人らは、この追加は従来技術のチャネル・セレクタ法からは重要な変化であることを提起し、さらに、本出願人らは処理論理をセレクタからソケットチャネルに移すことによって期待される結果を超えてメールサーバーのデータ処理能力の改良を与えることを見出した。それについて以下にさらに詳細に説明する。
【０１２１】
まず図１３Ｅを参照すると、本発明の複数ソケット／スレッドモデル１１６０は従来技術の場合（たとえば図１３Ｃに示したような）と同様に複数のソケットチャネルを含んでいるが、セレクタ１１６２は今では複数の終点（参照符号１１６４Ａ〜Ｃによって示される終点Ａ〜Ｃで表されている）の間で通信を制御するはたらきをする。本質的には、セレクタ１１６２はデータの門番としてはたらき、実際のデータ処理はチャネルで起こる。モデル１１６０に対応するプロセスは以下で図１３Ｆを参照しつつ説明する。
【０１２２】
図１３Ｅとともに図１３Ｆを参照すると、本発明のソケットチャネル・セレクタ方式を使ったＴＣＰプロセス１１７０が図示されている。ＴＣＰプロセス１１７０は、図１３Ｄの従来技術ソケット通信プロセス１１４０と同じステップ１１４２〜１１５４を含んでいる。しかし、本発明のプロセスは、データの流れの方向（着信方向か発信方向か）の判定後は従来技術のプロセスから離れる。この点で、ひとたび着信方向データが終点から受信されたとなれば、セレクタはステップ１１７２で適当なサイズのバッファを割り当て、データを処理のためソケットチャネルに届ける。次いでチャネルで判断１１７４が行われて受信データがプロトコルコマンドを完了するのに十分かどうかが判定される。判断１１７４への答えがＮＯ（手元のタスクを完了させるのに十分な情報はない）であれば、プロセスはステップ１１４８に戻ってさらなるデータのポーリングをする。判断１１７４への答えがＹＥＳ（完全なプロトコルメッセージが受信された）であれば、ステップ１１７６でソケットチャネルが、使われているプロトコルに従ってデータを処理する。判断１１７８では、ソケットチャネルにおいて、ソケットチャネルからの応答が終点に送られるべきかどうかの判定がなされる。判断１１７８への答えがＹＥＳであれば、処理ステップ１１７６の結果が終点への配送のためにステップ１１４８に届けられる。判断１１７８への答えがＮＯであれば、チャネル応答は必要でなく、チャネルはステップ１１８０でセレクタに接続を閉じるよう指示し、セレクタはステップ１１５９で接続を閉じる。接続は終点によって中断されてもよい。
【０１２３】
上述したチャネル・セレクタＴＣＰ法はＳＭＴＰおよびその他の電子メッセージ交換プロトコルを介して電子メールを送受信するために使うことができる。セレクタが所与のソケットチャネルについて終点からの応答を待っている間、セレクタは他のソケット接続を開始したり、管理したり、通信に使ったり、あるいは閉じたりすることが自由にできる。この方法は、データ送信の効率を劇的に上げることによって、ＳＭＴＰデータトラフィックのためのスループット容量を、よって電子メール配送サーバーのパフォーマンスを大幅に増すことになるので有益である。
【０１２４】
本出願人らによって開発された技術革新以前の従来技術の電子メール配送技術は、３２通毎秒のピークスループットである。本出願人らによる上述した技術革新を取り入れつつ本発明のソケットチャネル・セレクタＴＣＰプロセスは使わない場合、メッセージ配送システムは１５０通毎秒のピークスループットを達成した。本発明の前述したソケットチャネル・セレクタＴＣＰによるＳＭＴＰ電子メール配送についてのパフォーマンス向上は、実際の実装前の予想ではすでに達成されていた１５０通毎秒のピークスループット（10，000バイトのメッセージについて）に対して約５０ないし７５％の改善であった。ところが、実装してみると、本発明のソケットチャネル・セレクタＴＣＰプロセスを本出願人らによって開発された先に記載した改良と組み合わせることによって、８００通毎秒のメッセージスループットを出している（10,000メッセージについて）。本出願人らによって達成されたパフォーマンス上昇はソケットチャネル・セレクタＴＣＰプロセスを使わない場合に対して５３０％、既知の従来技術に対しては２５００％という驚異的な結果である。本出願人らはこの向上は著しいもので予想されなかったものであることを提起する。
【０１２５】
図１３Ｅおよび図１３Ｆを参照しつつ記載されたチャネル・セレクタ法はユーザーデータグラムプロトコル（UDP:  User  Datagram  Protocol）のようなステートレスなプロトコルにも適用しうる。この場合のデータ伝送プロセスは上述したＴＣＰ方式と同様であるがステートレスなプロトコルを使う。これは配送を保証することもなければ接続を要求することもない。これらの概念は以下で図１３Ｇを参照しつつさらに詳細に説明される。
【０１２６】
図１３ＧはＵＤＰを使ったデータ通信プロセスを示しており、全体として参照符号１１９０で示されている。通信チャネルソケットが生成され、チャネルソケットがセレクタに登録されたのち、チャネルソケットはデータグラムパケット（たとえばＵＤＰパケット）を生成してステップ１１９２でセレクタに送る。次いでステップ１１９４でそのデータグラムパケットはセレクタによって終点に渡され、次いでステップ１１４８でセレクタはデータ伝送活動のポーリングをする。ひとたび終点から応答が受信されたら、ステップ１１７２でセレクタは適切なバッファを割り当て、起点チャネルに対して応答を渡す。図１３Ｇに示したようなＵＤＰ通信は図１３ＦのＴＣＰ通信よりも単純である。というのも、図１３Ｇの通信プロセスはステートレスなプロトコルに基づいており、送信者と受信サーバーとの間の完全な通信は単一の要求と単一の応答からなるからである。
【０１２７】
ＵＤＰを使ったチャネル・セレクタ・ソケット管理プロセスは、たとえば、ＤＮＳレゾルバにおいて使用されてＤＮＳ検索プロセスのスピードを大幅に上げることができる。本発明のＤＮＳレゾルバは、標準的なＤＮＳプロトコルを使ってドメイン名検索データを送り、要求するのにソケットチャネル・セレクタ・プロセスを利用する。電子メールの送受信を容易にするよう、そのようなＤＮＳプロトコルレゾルバは起点のメールサーバー自信の内部に含めてもよい。ＴＣＰまたはＵＤＰを使ったチャネル・セレクタ・ソケット管理プロセスは、たとえば上述した配送可能性確認プロセスと組み合わせてもよい。
【０１２８】
本発明のＤＮＳレゾルバを実際に実装する前には、ソケットチャネル・セレクタ・プロセスを使ったＤＮＳ解決（すなわち検索）についての予期された向上は、平均ピーク性能の速度が毎秒５０検索である現状技術の方法（ＢＩＮＤ）に対して約１００％であった。予想外にも、本出願人らは本発明のソケットチャネル・セレクタ・プロセスに基づくＤＮＳプロトコルレゾルバが毎秒3400検索という驚くべき速度を出し、既存の従来技術に対して６８００％のパフォーマンス向上となることを見出した。
【０１２９】
ソケットチャネル・セレクタ・プロセスは、サーバーからＡＰＩアプリケーションへのメッセージ伝送遅延がきわめて低い、より高いパフォーマンスのＡＰＩアプリケーションを実現するために、たとえば、前述の本発明のＡＰＩプロセスと組み合わせてもよい。
【０１３０】
おおまかに言えば、本文書は、少なくともインターネットとのインターフェースをもつメッセージ交換システムにおける、送信者サーバーを通じてインターネットへのインターフェースをもつ送信者から受信者サーバーを通じてインターネットへのインターフェースをもつ少なくとも一受信者に配送すべく宛てられた、少なくとも受信者情報およびメッセージボディを含むメッセージを処理するための方法を開示した。この方法は、当該メッセージを送るための前記受信者情報に頼る前に前記送信者サーバーから前記受信者サーバーへのインターネットを通じた一時的な試験接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく前記受信者への当該メッセージの配送可能性の指標を提供することを含む。
【０１３１】
前述した諸実施形態のそれぞれはそれぞれに特定の配向を有するさまざまな構成要素をもつものとして示されてきたが、本発明は、該さまざまな構成要素が多様な位置および相互の配向で位置された多様な特定の構成をとることができ、それでも本発明の精神と範囲内であることは理解しておくべきである。さらに、前記様々な構成要素の代替または追加として好適な等価物を使ってもよい。そのような代替または追加構成要素の機能および使用は当業者にはなじみのあるものと考えられるものである。したがってそのような場合も本発明の範囲内にはいるものと見なされる。たとえば、前述した実施形態のそれぞれは主として電子メールのメッセージ交換の場合を使って議論されてきたが、本発明の電子メッセージ配送システムは、たとえば携帯電話その他の携帯機器との間でやりとりするメッセージといったような他の種類の電子メッセージにも対応するよう容易に構成できるものである。
【０１３２】
したがって、ここで挙げた諸例は解説するものと考えるべきであって、限定するものと考えてはならない。本発明はここに与えられている細部によって限定されるものではなく、付属の特許請求の範囲内で修正されうるものである。
【図面の簡単な説明】
【０１３３】
【図１Ａ】現在利用可能な従来技術に基づく、インターネットを通じて電子メッセージを送るための電子メールメッセージ交換システムの主要な構成要素を示す概略図である。
【図１Ｂ】図１Ａに示されているシステムを使った、インターネットを通じて電子メッセージを送るプロセスを示すフローチャートである。
【図２】電子メールの主要な構成部分を図解するために示した電子メールの概略図である。
【図３】従来技術において実施されているようなＶＲＦＹプロセスの概略図である。
【図４Ａ】本発明に基づくＳＭＴＰ通信プロセスの概略図である。
【図４Ｂ】本発明に基づく、ＳＭＴＰベースの受信者情報確認プロセスの、肯定的な結果の場合のさらなる詳細を示す概略図である。
【図４Ｃ】本発明に基づく、ＳＭＴＰベースの受信者情報確認プロセスの、否定的な結果の場合のさらなる詳細を示す概略図である。
【図５Ａ】本発明に基づく、複数のデータパケットを受信し、その後前記複数のデータパケットの少なくとも一部分を含んでいる電子メッセージを送信するためのメールサーバーシステムを示す概略図である。
【図５Ｂ】本発明のドメインベースのフロー制御を用いた場合の受信者ドメインの理論的な分布を示す例示的なグラフである。
【図５Ｃ】本発明のドメインベースのフロー制御を用いない場合の受信者ドメインの理論的な分布を示す例示的なグラフである。
【図５Ｄ】本発明のメールサーバーシステムにおいて使うのに好適な動的なＩＰ選択プロセスを示す概略図である。
【図６Ａ】本発明に基づく受信者サーバー情報検証プロセスの可能な実施形態を示すフローチャートである。
【図６Ｂ】本発明に基づく受信者サーバー情報検証プロセスの可能な実施形態を示すフローチャートである。
【図７Ａ】本発明に基づく受信者サーバー情報および受信者情報検証プロセスの可能な実施形態を示すフローチャートである。
【図７Ｂ】本発明に基づく受信者サーバー情報および受信者情報検証プロセスの可能な実施形態を示すフローチャートである。
【図８Ａ】本発明に基づく受信者サーバー情報および受信者情報検証プロセスの、後段メッセージ生成を含む可能な実施形態を示すフローチャートである。
【図８Ｂ】本発明に基づく受信者サーバー情報および受信者情報検証プロセスの、後段メッセージ生成を含む可能な実施形態を示すフローチャートである。
【図９Ａ】インターネットを通じた電子メッセージ送信の、従来技術の「保存して転送」プロセスを本発明の「構築して転送」プロセスと比較するフローチャートである。
【図９Ｂ】インターネットを通じた電子メッセージ送信の、従来技術の「保存して転送」プロセスと比較する、本発明の「構築して転送」プロセスのフローチャートである。
【図１０Ａ】電子メッセージを扱う際に補足プロセスを追加するための、従来技術の方法を本発明の方法と比較するフロー図である。
【図１０Ｂ】電子メッセージを扱う際に補足プロセスを追加するための、従来技術の方法と比較する本発明の方法のフロー図である。
【図１１Ａ】従来技術のＭＩＬＴＥＲ  ＡＰＩイベント管理・伝送プロセスを示すフローチャートである。
【図１１Ｂ】本発明のイベント後ＡＰＩプロセスを示す概略図である。
【図１１Ｃ】本発明のイベント前ＡＰＩプロセスを示す概略図である。
【図１１Ｄ】本発明に基づくメールサーバーにおけるＡＰＩイベントの登録を示す概略図である。
【図１１Ｅ】本発明に基づくＡＰＩイベント管理・伝送プロセスを示すフローチャートである。
【図１２Ａ】本発明に基づく設定可能なＲＡＭ／ＨＤＤメッセージプロセスの可能な実施形態を示すフローチャートである。
【図１２Ｂ】本発明に基づく設定可能なＲＡＭ／ＨＤＤメッセージプロセスの可能な実施形態を示すフローチャートである。
【図１３Ａ】従来技術のソケット通信のシングルスレッドモデルを示す概略図である。
【図１３Ｂ】図１３Ａの従来技術のシングルスレッドモデルのソケット通信プロセスを示す概略図である。
【図１３Ｃ】従来技術のサーバー間のデータ伝送のためのマルチスレッドモデル・ソケットチャネル・セレクタ実施形態を示す概略図である。
【図１３Ｄ】図１３Ｂに対応するＴＣＰを使った従来技術のセレクタプロセスを示すフローチャートである。
【図１３Ｅ】本発明に基づくマルチスレッド・ソケットチャネル・セレクタ通信モデルを示す概略図である。
【図１３Ｆ】本発明に基づくＴＣＰを使ったソケットチャネル・セレクタ・プロセスを示すフローチャートである。
【図１３Ｇ】ＵＤＰを使った場合の本発明のセレクタ処理を示すフローチャートである。
【図１Ａ】
2007535011.tif 000004
【図１Ｂ】
2007535011.tif 000005
【図２】
2007535011.tif 000006
【図３】
2007535011.tif 000007
【図４Ａ】
2007535011.tif 000008
【図４Ｂ】
2007535011.tif 000009
【図４Ｃ】
2007535011.tif 000010
【図５Ａ】
2007535011.tif 000011
【図５Ｂ】
2007535011.tif 000012
【図５Ｃ】
2007535011.tif 000013
【図５Ｄ】
2007535011.tif 000014
【図６Ａ】
2007535011.tif 000015
【図６Ｂ】
2007535011.tif 000016
【図７Ａ】
2007535011.tif 000017
【図７Ｂ】
2007535011.tif 000018
【図８Ａ】
2007535011.tif 000019
【図８Ｂ】
2007535011.tif 000020
【図９Ａ】
2007535011.tif 000021
【図９Ｂ】
2007535011.tif 000022
【図１０Ａ】
2007535011.tif 000023
【図１０Ｂ】
2007535011.tif 000024
【図１１Ａ】
2007535011.tif 000025
【図１１Ｂ】
2007535011.tif 000026
【図１１Ｃ】
2007535011.tif 000027
【図１１Ｄ】
2007535011.tif 000028
【図１１Ｅ】
2007535011.tif 000029
【図１２Ａ】
2007535011.tif 000030
【図１２Ｂ】
2007535011.tif 000031
【図１３Ａ】
2007535011.tif 000032
【図１３Ｂ】
2007535011.tif 000033
【図１３Ｃ】
2007535011.tif 000034
【図１３Ｄ】
2007535011.tif 000035
【図１３Ｅ】
2007535011.tif 000036
【図１３Ｆ】
2007535011.tif 000037
【図１３Ｇ】
2007535011.tif 000038
【手続補正書】
【提出日】平成18年6月29日(2006.6.29)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
送信者から少なくとも一受信者に配送すべく宛てられたメッセージを処理するためのインターネットへのインターフェースをもつメッセージサーバーであって、送信者は受信者サーバーと通信することのできる当該メッセージサーバーを通じてインターネットへのインターフェースをもち、当該メッセージサーバーは、前記メッセージをメッセージファイルとして保存するために構成されたハードディスクドライブを含み、当該メッセージサーバーは該メッセージファイルを前記受信者サーバーに転送するよう構成されており、当該修正メッセージサーバーが：
前記メッセージを定義するのに使う複数の離散的なデータパケットを前記送信者から受信するための受信手段であって、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでおり、該受信設備が前記複数の離散的なデータパケットを保存するための電子メモリを含んでいるような受信設備と、
前記複数の離散的なデータパケットを処理し、前記メッセージを少なくとも前記受信者情報およびメッセージボディを組み合わせることによって生成するための、前記電子メモリを使った処理設備、
とを有することを特徴とするメッセージサーバー。
【請求項２】
前記メッセージを送るための前記受信者情報に頼る前に、
前記メッセージサーバーから前記受信者サーバーへのインターネットを通じた一時的な試験接続を確立することによって、ＳＭＴＰのＶＲＦＹコマンドを使うことなく前記メッセージの配送可能性の指標を提供するよう、前記受信者情報を試験するための試験設備、
をさらに有することを特徴とする、請求項１記載のメッセージサーバー。
【請求項３】
前記メッセージがさらに送信者情報を含んでおり、前記処理設備がさらに：
前記受信者サーバーに前記メッセージを向ける前に、前記メッセージサーバーにおける複数のＩＰアドレスを同定し、
所定の規則セットに従って前記複数のＩＰアドレスのある一つを指定し、
前記メッセージの前記送信者情報の一部として前記複数のＩＰアドレスの前記ある一つを含める、
よう構成されていることを特徴とする、請求項２記載のメッセージサーバー。
【請求項４】
前記試験設備が前記指標に関するレコードを生成することを特徴とする、請求項２記載のメッセージサーバー。
【請求項５】
前記受信設備がソフトウェアアプリケーションによって生成される前記複数の離散的なデータパケットを受信するよう構成されていることを特徴とする、請求項１記載のメッセージサーバー。
【請求項６】
前記ソフトウェアアプリケーションにデータベースとのインターフェースをもたせるためのインターフェース設備と、
前記データベース中のトリガーイベントに反応する監視設備であって、該トリガーイベントが発生したときに、前記ソフトウェアアプリケーションをして前記データベース中に保存されている情報を使って自動的に前記複数の離散的なデータパケットを生成せしめるための監視設備、
とをさらに有することを特徴とする、請求項５記載のメッセージサーバー。
【請求項７】
前記メッセージサーバーがさらに、複数の受信者サーバーと通信するよう構成されており、
前記メッセージサーバーがさらに、送信者によって与えられる、当該メッセージサーバーによって送信されるべき一群のメッセージを定義する情報を扱うよう構成されており、
前記処理設備が
前記一群のメッセージを定義するために前記複数の離散的なデータパケットを使い、
前記一群のメッセージのそれぞれについての少なくとも前記受信者情報およびメッセージボディを組み合わせ、
前記一群のメッセージのそれぞれの前記受信者情報および前記メッセージボディのうちの少なくとも一つに基づき所定の規則セットに従って前記一群のメッセージを順序付ける、
よう構成されていることを特徴とする、請求項１記載のメッセージサーバー。
【請求項８】
前記処理設備が、（ｉ）前記複数の離散的なデータパケットを第一の所定の規則セットに従って修正すること、（ｉｉ）前記複数の離散的なデータパケットに第二の所定の規則セットに従って追加データパケットを加えること、（ｉｉｉ）前記複数の離散的なデータパケットを第三の所定の規則セットに従って順序付けること、のうちの少なくとも一つを実行することによって複数の結果データパケットを与えるための複数の外部アプリケーションのうちの一つへのアプリケーションプログラムインターフェースを通じて前記複数の離散的なデータパケットを差し向けるよう構成されており、
前記処理設備がさらに、前記アプリケーションプログラムインターフェースを通じて複数の外部アプリケーションの前記一つから前記複数の結果データパケットを受信し、前記複数の結果データパケットのうちの少なくとも一部分を組み合わせることによって前記メッセージを生成するよう前記複数の離散データパケットを処理するよう構成されている、ことを特徴とする、請求項１記載のメッセージサーバー。
【請求項９】
インターネットを通じたインターフェースをもつメッセージ交換システムにおいて、受信者サーバーと通信することのできる送信者サーバーを通じてインターネットへのインターフェースをもつ送信者から少なくとも一受信者に配送すべく宛てられたメッセージを処理するための方法であって：
送信者サーバーにおいて前記送信者から当該メッセージを定義するのに使う複数の離散的なデータパケットを受信し、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つはメッセージボディを含んでおり、
（ｉ）前記複数の離散的なデータパケットを第一の所定の規則セットに従って修正すること、（ｉｉ）前記複数の離散的なデータパケットに第二の所定の規則セットに従って追加データパケットを加えること、（ｉｉｉ）前記複数の離散的なデータパケットを第三の所定の規則セットに従って順序付けること、のうちの少なくとも一つを実行するためであって、結果として複数の結果データパケットを与えるための複数の外部アプリケーションのうちの一つへのアプリケーションプログラムインターフェースを通じて前記複数の離散的なデータパケットを差し向け、
前記アプリケーションプログラムインターフェースを通じて複数の外部アプリケーションの前記一つから前記複数の結果データパケットを受信し、
前記複数の結果データパケットのうちの少なくとも一部分を組み合わせることによって前記メッセージを生成し、
前記送信者サーバーから前記受信者サーバーへインターネットを通じた接続を確立し、
前記接続を通じて前記メッセージを前記受信者サーバーに前記受信者への配送のために差し向ける、
ことを有することを特徴とする方法。
【請求項１０】
請求項９記載の方法であって、
前記送信者サーバーにおいて前記複数の離散的なデータパケットを保存することをさらに有しており、
前記メッセージの生成が前記送信者サーバーにおいて保存されている前記複数の離散的なデータパケットを処理することを含むことを特徴とする方法。
【請求項１１】
当該メッセージを送るための前記受信者情報に頼る前に前記送信者サーバーから前記受信者サーバーへのインターネットを通じた一時的な試験接続を確立することによって前記受信者情報を試験し、それによりＳＭＴＰのVRFYコマンドを使うことなく当該メッセージの配送可能性の指標を提供する、
ことをさらに有することを特徴とする、請求項９記載の方法。
【請求項１２】
前記メッセージがさらに送信者情報を含んでおり、当該方法が：
前記受信者サーバーに前記接続を通じて前記メッセージを差し向ける前に、前記送信者サーバーにおける複数のＩＰアドレスを選択し、
所定の規則セットに従って前記複数のＩＰアドレスのある一つを指定し、
前記メッセージの前記送信者情報の一部として前記複数のＩＰアドレスの前記ある一つを含める、
ことをさらに有することを特徴とする、請求項９記載の方法。
【請求項１３】
前記指標に関するレコードを生成することを特徴とする、
請求項１２記載の方法。
【請求項１４】
前記複数の離散的なデータパケットを前記送信者から受信することが、ソフトウェアアプリケーションによって生成される前記複数の離散的なデータパケットを処理することを含むことを特徴とする、請求項１２または１３記載の方法。
【請求項１５】
前記ソフトウェアアプリケーションにデータベースとのインターフェースをもたせ、
前記データベース中にトリガーイベントを定義することで、該トリガーイベントが前記データベース中で発生したときに前記ソフトウェアアプリケーションが自動的に前記複数の離散的なデータパケットを生成するようにする、
ことをさらに有することを特徴とする、請求項１４記載の方法。
【請求項１６】
請求項９記載の方法であって、前記複数の離散的なデータパケットが一群のメッセージを定義するのに使うためのデータパケットの組を含んでおり、前記複数の離散的なデータパケットの少なくとも一つは受信者情報を含み、前記複数の離散的なデータパケットの少なくとももう一つは前記一群のメッセージの対応するメッセージについてのメッセージボディを含んでおり、前記生成が、少なくとも前記一群のメッセージのそれぞれについての前記受信者情報およびメッセージボディを組み合わせることによって前記一群のメッセージを生成するものであり、当該方法がさらに：
前記一群のメッセージのうちのそれぞれにの前記受信者情報および前記メッセージボディのうちの少なくとも一つに基づいて所定の規則セットを使って前記一群のメッセージを配列する、
ことを含むことを特徴とする方法。
【手続補正書】
【提出日】平成18年6月30日(2006.6.30)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】００１９
【補正方法】変更
【補正の内容】
【００１９】
以下で見られるように、本発明は、現状技術の電子メッセージ配送システムに存在する前述の問題を解決する一方、パフォーマンス向上をもたらす能力のおかげで、上記で議論したような従来技術に対して著しい改善を提供する。
【非特許文献１】ステファン・ランツ著、Ｍｉｌｔｅｒ、http://milter.free.fr/intro/  スライド１および２、フランス、2004年4月14日
【非特許文献２】Sendmail社著、Ｍｉｌｔｅｒ  ＡＰＩ、http://www.milter.org/milter_api/api.html、2003年
【非特許文献３】ビル・ボール、その他著、レッドハット（登録商標）リナックス９、サムス、2003年5月8日、第1９章
【非特許文献４】デーヴィッド・ピッツ、その他著、レッドハット（登録商標）リナックス６（アンリーシュト）、サムス、1999年7月30日、第7章