JP2014511075A - 国際化ｅメールシステムと非国際化ｅメールシステムとのメッセージ伝送 - Google Patents

Abstract

送信者から被選択受信者へｅメールメッセージを送信する方法が提供され、被選択受信者は情報交換用米国標準コード（ＡＳＣＩＩ）に準拠するｅメールメッセージだけを受信できる。ただし、送信者または他の受信者のうち１名以上は非ＡＳＣＩＩ ｅメールアドレスを有する。非ＡＳＣＩＩ ｅメールアドレスの各々につき、次の通りにマップ済みＡＳＣＩＩ ｅメールアドレスが作成される。既定マッピングアルゴリズムを使用し非ＡＳＣＩＩ ｅメールアドレスのマッピングとしてユーザ名が生成される。既定ゲートウェイサーバまで解決されるよう各々構成された１つ以上の既定ドメイン名からドメイン名が選択される。マップ済みＡＳＣＩＩ ｅメールアドレスを作成するため、ユーザ名はドメイン名に連結される。その後、非ＡＳＣＩＩ ｅメールアドレスはマップ済みＡＳＣＩＩ ｅメールアドレスに差し替えられ、被選択受信者へｅメールメッセージが送出される。上記の方法を実施するよう構成されたゲートウェイサーバとコンピュータ可読媒体も提供される。
【選択図】図２

Description

本発明は、一般的には電子メール（ｅメール）サーバに関し、具体的には非ＡＳＣＩＩ ｅメールアドレスを処理するよう構成された電子メールサーバに関する。

コンピュータネットワークの拡大にともない、私的な通信手段や業務用の通信手段として電子メール（ｅメール）が人気を博している。主にインターネットの普及により、ｅメールは何十億もの人々にとって標準的な通信手段となっている。

送信者はメールユーザエージェント（ＭＵＡ）を使ってｅメールメッセージを作成する。ＭＵＡの例は、Ｍｉｃｒｏｓｏｆｔ ＯｕｔｌｏｏｋやＭｏｚｉｌｌａ Ｔｈｕｎｄｅｒｂｉｒｄ等のクライアント側アプリケーションと、ＨｏｔｍａｉｌやＧｍａｉｌ等のウェブベースアプリケーションを含む。周知のように、送信者は１つ以上のｅメールアドレスとメッセージ件名とメッセージ本文を入力することによってｅメールメッセージを作成し、場合によってはメッセージにファイルを添付する。ｅメールアドレスは２つの部分からなる。第１の部分はｅメールアドレスのドメインと呼ばれ、ホスト名またはドメイン名を指す。ドメインは「＠」符号の右側に通常位置する。第２の部分はユーザ名またはアカウント名と呼ばれ、ドメインでｅメールアカウントを識別するため使用される。ユーザ名は「＠」符号の左側に通常位置する。

ＭＵＡは送信ｅメールサーバを通じて１名以上の受信者へｅメールメッセージを送信する。送信ｅメールサーバはメールサブミッションエージェント（ＭＳＡ）とメールトランスポートエージェント（ＭＴＡ）とを含む。ＭＴＡはｅメールアドレスのドメイン名を解決して対応するインターネットプロトコル（ＩＰ）アドレスを取得するため、ドメイン名システム（ＤＮＳ）と連絡をとる。ＭＴＡサーバは取得したＩＰアドレスを使って受信者の受信ｅメールサーバへメッセージを送信する。ｅメールメッセージは受信ｅメールサーバへ直接送信されることもあれば、複数のメールトランスポートエージェント（ＭＴＡ）で中継されることもある。

受信ｅメールサーバはｅメールメッセージを引き出すため、ＭＴＡと、ローカルデリバリエージェントと、ローカルファイルストレージと、ポストオフィスプロトコル（ＰＯＰ）および／またはインターネットメッセージアクセスプロトコル（ＩＭＡＰ）サーバとを通常含む。受信者はＭＵＡを使って受信ｅメールサーバからｅメールメッセージを引き出す。

典型的な情報交換用米国標準コード（ＡＳＣＩＩ）環境では全てのネットワークコンポーネントがＡＳＣＩＩ ｅメールアドレスを処理できる。ただし、ｅメールアドレスは近い将来に国際化（非ＡＳＣＩＩ）文字を含む可能性がある。例えば、国際化ドメイン名（ＩＤＮ）は非ＡＳＣＩＩ文字を含む可能性のあるインターネットドメイン名と定義される。国際化ｅメールアドレスもｅメールアドレスの一部として国際化ユーザ名を含むと予想されている。したがって、国際化ユーザ名も非ＡＳＣＩＩ文字を含む可能性がある。

この制限を克服するため、ｅメールシステムコンポーネントで国際化ｅメールアドレスを「格下げ（downgrade）」する方法が提案されている。具体的には、国際化ｅメールアドレスのユーザによって代替ＡＳＣＩＩ ｅメールアドレスが設定される。ＡＳＣＩＩ限定システムコンポーネントに遭遇する場合は、ＡＳＣＩＩ限定システムコンポーネントにｅメールを送達する前に、国際化ｅメールアドレスを代替ＡＳＣＩＩ ｅメールアドレスに差し替えることによって国際化ｅメールアドレスが格下げされる。

このソリューションなら、国際化ｅメールアドレスを有するｅメールメッセージを既存のネットワークコンポーネントを使って送達できる。

先行技術の制限をなくし、ＡＳＣＩＩ ｅメールアドレスのみに適合する１つ以上のコンポーネントを含むネットワークで国際化ｅメールアドレスを有するｅメールメッセージの送達を助長することが望まれる。

本発明の一態様によると、送信者から被選択受信者へｅメールメッセージを送信するコンピュータ実装方法が提供され、被選択受信者は情報交換用米国標準コード（ＡＳＣＩＩ）に準拠するｅメールメッセージだけを受信でき、送信者または他の受信者のうち１名以上は非ＡＳＣＩＩ ｅメールアドレスを有し、前記方法は、既定マッピングアルゴリズムを使用し非ＡＳＣＩＩ ｅメールアドレスのマッピングとしてユーザ名を生成することと、既定ゲートウェイサーバまで解決されるよう各々構成された１つ以上の既定ドメイン名からドメイン名を選択することと、マップ済みＡＳＣＩＩ ｅメールアドレスを作成するためユーザ名とドメイン名を連結することと、によって、非ＡＳＣＩＩ ｅメールアドレスの各々につきマップ済みＡＳＣＩＩ ｅメールアドレスを作成することと、非ＡＳＣＩＩ ｅメールアドレスを対応するマップ済みＡＳＣＩＩ ｅメールアドレスに差し替えることと、必要に応じ、既定プロトコルを使用しｅメールメッセージの残りの部分を格下げすることと、被選択受信者へｅメールメッセージを送信することと、の各ステップを備える。

本発明の別の態様によると、上記の方法を実施するよう構成されたゲートウェイサーバが提供される。さらに、上記の方法を遂行する命令を蓄積したコンピュータ可読媒体が提供される。

これより下記図面を参照しながら本発明の一実施形態を一例として説明する。

図１は、標準ネットワーク基盤（先行技術）のブロック図である。 図２は、本発明の一実施形態のネットワーク基盤のブロック図である。 図３は、１つ以上のメール送達要素が非ＡＳＣＩＩを処理できない場合の非ＡＳＣＩＩ ｅメールアドレスからのｅメールメッセージ送信を示す流れ図である。

簡便化のため、説明の中の同様の数字は図面の中の同様の構造を示す。図１を参照すると、標準ネットワーク基盤を示すブロック図が数字１００により図示されている。ネットワーク１００は送信者１０２と通信ネットワーク１０４と受信者１０６とを含む。説明を簡潔にするため、送信者１０２は送信ｅメールサーバ１０８を含み、受信者１０６は受信ｅメールサーバ１１０を含む。当技術で周知のように、通信ネットワーク１０４は送信ｅメールサーバ１０８と受信ｅメールサーバ１１０との通信を促進するにあたって必要となる複数のネットワークコンポーネントを含む。

送信者１０２は、例えばパーソナルコンピュータ、ノートブックコンピュータ、スマートフォン、タブレット、個人用デジタル補助装置等、ｅメールメッセージを送信できる計算装置である。送信者１０２はそのユーザにメールユーザエージェント（ＭＵＡ）へのアクセスを提供する。送信ｅメールサーバ１０８はメールサブミッションエージェント（ＭＳＡ）１１４とＭＴＡ １１６とを含む。

当技術で周知のように、送信ｅメールサーバ１０８は送信者１０２に局在してローカルネットワーク（図示せず）により送信者１０２に接続され、あるいは遠隔地でホストされて通信ネットワーク１０４により送信者１０２に接続される。

送信者１０２と同様、受信者１０６は、例えばパーソナルコンピュータ、ノートブックコンピュータ、スマートフォン、タブレット、個人用デジタル補助装置（ＰＤＡ）等、ｅメールメッセージを受信できる計算機である。受信者１０６はそのユーザにＭＵＡへのアクセスを提供する。受信ｅメールサーバ１１０は、ＭＴＡ １１８と、ローカルデリバリエージェント１２０と、ローカルファイルストレージ１２２とメッセージ検索サーバ１２４とを、含む。

当技術で周知のように、受信ｅメールサーバ１１０は受信者１０６に局在してローカルネットワーク（図示せず）により受信者１０６に接続され、あるいは遠隔地でホストされて通信ネットワーク１０４により受信者１０６に接続される。

ＭＴＡ １１８は、送信ｅメールサーバ１０８からｅメールメッセージを直接的に、または複数の中間ＭＴＡ １１８を介して間接的に、受信するよう構成される。ローカルデリバリエージェント１２０は、ユーザ名に対応するローカルストレージ１２２のディレクトリに受信ｅメールメッセージを維持するよう構成される。メッセージ検索サーバ１２４は、１つ以上のＰＯＰサーバ、ＩＭＡＰサーバ、またはローカルホストサーバを備え、ｅメールメッセージをＭＵＡによる表示のためローカルストレージ１０８から受信者１０６へ送達するよう構成される。

本実施形態によると、国際化ｅメールアドレスを処理できる国際化ｅメールサーバと国際化ｅメールアドレスを処理できない従来型ｅメールサーバとの間の仲介として１つ以上のゲートウェイサーバが構成される。図２を参照すると、本実施形態によるｅメールネットワークが数字２００により図示されている。ｅメールネットワーク２００は、従来型ｅメールサーバ２０２と、２つの国際化ｅメールサーバ２０４と、２つのゲートウェイサーバ２０６と、通信ネットワーク１０４とを、含む。

サーバ数は説明を簡潔にするため記載されているに過ぎず、１つ以上の従来型ｅメールサーバ２０２、１つ以上の国際化ｅメールサーバ２０４、１つ以上のゲートウェイサーバ２０６からｅメールネットワーク２００を構成できることは、当業者によって理解されよう。

国際化ｅメールサーバ２０４と従来型ｅメールサーバ２０２は、ＭＵＡ、ＭＳＡ １１４、および／またはＭＴＡ １１８を含んでよい。また、国際化ｅメールサーバ２０４と従来型ｅメールサーバ２０２は、図１を参照して説明した送信ｅメールサーバ１０８や受信ｅメールサーバ１１０と同様に通信するよう構成される。

ただし、本実施形態ではｅメールメッセージがゲートウェイサーバ２０６を経由する。つまりゲートウェイサーバ２０６は、国際化ｅメールサーバ２０４のいずれか１つから受信するｅメールメッセージを従来型ｅメールサーバ２０２で受信できる標準形式に格下げするよう構成される。さらにゲートウェイサーバ２０６は、従来型ｅメールサーバ２０２から受信する返信メッセージを国際化ｅメールサーバ２０４で受信できる国際化形式に「格上げ（upgrade）」するよう構成される。ゲートウェイサーバ２０６は、対応する国際化ｅメールサーバと直接的に、または通信ネットワーク１０４を介して間接的に、通信するよう、構成されてよい。

本実施形態でゲートウェイサーバ２０６は中間ＭＴＡ １１８として機能する。ゲートウェイサーバ２０６は、１つ以上の関連ゲートウェイドメインとＤＮＳレジストリ内で構成されたＭＸレコードを有する。これによりゲートウェイサーバ２０６のＩＰアドレスが提供され、他のＭＴＡ １１８はゲートウェイサーバ２０６に接続できる。それぞれの国際化ｅメールサーバ２０４は、対応するゲートウェイサーバ２０６へｅメールメッセージを転送するよう構成される。

第１の例において、それぞれのゲートウェイサーバ２０６は組織に関連付けされ、国際化ｅメールサーバ２０４のいずれか１つに関連付けされる。この場合、国際化ｅメールサーバ２０４はそれぞれ別々のゲートウェイサーバ２０６へｅメールメッセージを転送するよう構成される。

第２の例において、ゲートウェイサーバ２０６は共有サーバとして運用され、複数の国際化ｅメールサーバ２０４に関連付けされる。この場合、複数の国際化ｅメールサーバ２０４は同じゲートウェイサーバ４０６へｅメールメッセージを転送するよう構成される。この例はサードパーティがその顧客にゲートウェイサービスを提供する能力を与える。

第１の例と第２の例の混成を実施できることは当業者によって理解されよう。

尚、従来型ｅメールサーバ２０２は格下げの必要がある非ＡＳＣＩＩアドレスでｅメールメッセージを送出できないため、ゲートウェイサーバ２０６のいずれか１つを使用するよう構成される必要はない。ただし、従来型ｅメールサーバ２０２がゲートウェイサーバ２０６からｅメールメッセージを受信する場合は、国際化ｅメールアドレスは予めＡＳＣＩＩ ｅメールアドレスに格下げされている。後ほど詳述するように、格下げされたＡＳＣＩＩ ｅメールアドレスはゲートウェイサーバ２０６に関連付けされたドメインと一意な識別子からなるユーザ名を含む。このため、従来型ｅメールサーバ２０２は標準ＤＮＳルックアップを使用しゲートウェイサーバ２０６を介して国際化ｅメールサーバ２０４へ返信を送ることができる。ゲートウェイサーバ２０６は、一意な識別子を対応する国際化ｅメールアドレスにマップすることにより、国際化ｅメールサーバ２０４へ返信を転送できる。

後方適合性を促進するため、ゲートウェイサーバ２０６は国際化ｅメールサーバ２０４と従来型ｅメールサーバ２０２でやり取りされる全てのｅメールメッセージを処理できる。ゲートウェイサーバ２０６は送信者によって指定された全ての受信者へｅメールを送り届ける。ゲートウェイサーバ２０６はまた、送信者へ返信を送り返す。簡易メール転送プロトコル（ＳＭＴＰ）高信頼性メール転送法では、全ての受信者が全てのｅメールメッセージとその後に続く全ての返信に対し返信できなければならない。

国際化ｅメールサーバ２０４と従来型ｅメールサーバ２０２との根本的不適合性は、ＡＳＣＩＩ限定ｅメールアドレスと国際化ｅメールアドレスの送信者および／または受信者がｅメールメッセージに混在する場合に発生する。

このため、国際化ｅメールサーバ２０４と従来型ｅメールサーバ２０２との通信を促進するルーティングソフトウェアがゲートウェイサーバ２０６に設けられる。図３を参照すると、ゲートウェイサーバ２０６に実装されたルーティングソフトウェアの動作を示す流れ図が数字３００により図示されている。ステップ３０２で、ゲートウェイサーバ２０６は１名以上の受信者へ送信されるｅメールメッセージを受信し、第１の受信者を選択する。ステップ３０４で、ゲートウェイサーバ２０６は被選択受信者のドメインがゲートウェイサーバ２０６に関連付けされているか否かを判断する。

ドメインがゲートウェイサーバ２０６に関連付けされている場合、ルーティングソフトウェアはステップ３０５へ進む。ゲートウェイサーバ２０６に関連付けされたドメインを有するｅメールアドレスは、元のｅメールアドレスをマップした結果である。ステップ３０５ではｅメールアドレスを逆マップすることによって受信者の元のｅメールアドレスが取り戻され、ルーティングソフトウェアはステップ３０６へ進む。説明を簡潔にするため、マッピングと逆マッピングはルーティングソフトウェアの動作説明の後に詳述する。

ドメインがゲートウェイサーバ２０６に関連付けされていない場合、ルーティングソフトウェアはステップ３０６へ進む。ステップ３０６で、ルーティングソフトウェアは受信者が国際化ｅメールアドレスか否かを判断する。受信者が国際化ｅメールアドレスならルーティングソフトウェアはステップ３０８へ進む。ステップ３０８では、ｅメールメッセージがゲートウェイサーバ２０６に関連付けされたドメインを有するｅメールアドレスを有する他の受信者を含むか否かを判断する。

ゲートウェイサーバ２０６に関連付けされたドメインを有する他のｅメールアドレスがなければ、ステップ３１２で国際化規格を使用しｅメールメッセージが受信者へ送信される。ゲートウェイサーバ２０６に関連付けされたドメインを有する他のｅメールアドレスがあるなら、ステップ３１０で元のｅメールアドレスを取り戻すためｅメールアドレスが逆マップされる。元のｅメールアドレスが取り戻されたら、ステップ３１２でｅメールメッセージが受信者へ送信される。

ステップ３０６へ戻り、受信者が国際化ｅメールアドレスでなければルーティングソフトウェアはステップ３１４へ進む。この時点で、受信者は国際化ｅメールアドレスではないため、ＡＳＣＩＩ ｅメールアドレスであることは分かっている。ステップ３１４では、送信者がＡＳＣＩＩ ｅメールアドレスを有するか否かを判断し、さらにｅメールメッセージが国際化前規格に適合するか否かを判断する。ｅメールメッセージが国際化前規格に適合するか否かを判断する方法は複数ある。例えばｅメールメッセージがゲートウェイサーバ２０６へ送出された場合、ＳＭＰＴ ＭＡＩＬ ＦＲＯＭコマンドはこれが国際化メッセージであることを指示する。もうひとつの例として、ｅメールメッセージをスキャンし、ｅメールメッセージにコピーされた他の受信者等、国際化前ｅメール規格では許可されない非ＡＳＣＩＩ文字がｅメールメッセージに含まれているか否かを判断できる。

両方の条件が満たされるならルーティングソフトウェアはステップ３４２へ進み、国際化前規格を使用しメッセージが送信される。一方の条件か両方の条件が満たされなければ、ルーティングソフトウェアは３１６へ進む。

ステップ３１６では、受信者が国際化ｅメールメッセージを受信できるか否かを判断する。受信者が国際化ｅメールメッセージを受信できるか否かを判断するにあたってｅメールアドレスそのものでは不十分かもしれない。例えば、ＡＳＣＩＩ ｅメールアドレスを持つ人々は、従来型ｅメールサーバ２０２から国際化ｅメールサーバ２０４へ移行する場合でもＡＳＣＩＩ ｅメールアドレスを変更しないかもしれない。また、国際化ｅメールサーバ２０４を使用する人々でも、引き続き新しいＡＳＣＩＩ ｅメールアドレスを作る見込みはある。

受信者が国際化ｅメールメッセージを受信できるか否かを判断するには数通りの方法がある。例えば、受信者の宛先は、被選択受信者のドメインに関するＭＸレコードの標準ＤＮＳルックアップから判断できる。ゲートウェイサーバ２０６は対応するＭＴＡサーバに対しＳＭＴＰ接続を行い、ＳＭＴＰ ＥＨＬＯコマンドを発行する。ＥＡＩ規格案「国際化ＥメールアドレスのためのＳＭＴＰ拡張仕様」、ｄｒａｆｔ−ｉｅｔｆ−ｅａｉ−ｒｆｃ５３３６ｂｉｓ、ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｗｇ／ｅａｉ／によると、対応するＭＴＡサーバからの返信が能力リストの中で国際化アドレスをサポートすることを指示する既定フラグを含むなら、被選択受信者に関連付けされたＭＴＡ １１８は国際化サーバである。別の例では、宛先ドメインまたは個別ｅメールアドレスの構成情報でパラメータが設定され、受信者が国際化ｅメールメッセージを受信できるか否かの判断に役立てることができる。本発明の範囲から逸脱せず別の方法を開発することもできる。

被選択受信者が国際化ｅメールメッセージを受信できると判断される場合、ルーティングソフトウェアはステップ３０８へ進む。受信者が国際化ｅメールメッセージを受信できないと判断される場合、ルーティングソフトウェアはステップ３１８へ進む。

ステップ３１８で、ルーティングソフトウェアはｅメールヘッダにある全ての国際化ｅメールアドレスを格下げする。これは送信者を含み、また「差出人」、「宛先」、「Ｃｃ」、および他の標準ｅメールヘッダ内の受信者を含む。それぞれの国際化ｅメールアドレスにつきＡＳＣＩＩ ｅメールアドレスが次の通りに決定される。

一般的なｅメールアドレス提示形式ではオプションの表示名を提示し、その後に山括弧で括られたｅメールアドレスを続ける。対応するマップ済みＡＳＣＩＩ ｅメールアドレスはいくつかのステップで取得する。第１のステップ３１８ａでは、既定マッピングアルゴリズムを使用し国際化ｅメールアドレスからＡＳＣＩＩユーザ名が生成される。第２のステップ３１８ｂでは、複数の既定ドメインからＡＳＣＩＩドメインが選択される。生成されたＡＳＣＩＩユーザ名と選択されたＡＳＣＩＩドメイン名は連結され、マップ済みＡＳＣＩＩ ｅメールアドレスが形成される。オプションのステップである第３のステップ３１８ｃでは表示名が決定される。

全ての国際化ｅメールアドレスが格下げされたら、ステップ３２０でルーティングソフトウェアは必要に応じｅメールメッセージの他の部分を格下げする。他の部分の例は件名行やＭＩＭＥ本文部分ヘッダフィールドを含む。ｅメールメッセージの他の部分は数通りの方法で格下げできる。本実施形態ではｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｗｇ／ｅａｉ／ｄｒａｆｔ−ｉｅｔｆ−ｅａｉ−ｐｏｐｉｍａｐ−ｄｏｗｎｇｒａｄｅ／で確認できる策定中の規格「国際化Ｅメールメッセージの送達後メッセージ格下げ」ｄｒａｆｔ−ｉｅｔｆ−ｅａｉ−ｐｏｐｉｍａｐ−ｄｏｗｎｇｒａｄｅ−００．ｔｘｔに従ってｅメールメッセージの他の部分が格下げされる。

ステップ３４２ではｅメールメッセージが被選択受信者へ送信される。ステップ３４４で、ルーティングソフトウェアはｅメールメッセージを送るべき別の受信者がいるか否かを判断する。別の受信者がいなければ、ゲートウェイサーバ２０６の観点からはｅメールメッセージ送信は完了し、ステップ３４６でｅメールメッセージ送信は終了する。別の受信者がいるなら、ステップ３４８で次の受信者が被選択受信者となり、ルーティングソフトウェアはステップ３０４へ進む。

ゲートウェイサーバ２０６で実行するルーティングソフトウェアが、国際化ｅメールサーバ２０４を使用する送信者から、少なくとも１名の受信者が従来型ｅメールサーバ２０２を使用する複数の受信者へ、送信者と受信者の双方にとって透過的な方法で、ｅメールメッセージを送信することは理解されよう。国際化ｅメールサーバ２０４を使用する受信者の場合、ルーティングソフトウェアはｅメールメッセージを修正せず送信する。従来型ｅメールサーバ２０２を使用する受信者の場合、ルーティングソフトウェアはｅメールメッセージを格下げし、送信する。ルーティングソフトウェアはまた、受信者からの返信メッセージを処理する。

これよりマッピングの詳細を説明する。一例として国際化ｅメールアドレス

を検討する。ステップ３１８ａでは、ＡＳＣＩＩユーザ名を生成するため、既定のマッピングアルゴリズムを使用し国際化ｅメールアドレスがＡＳＣＩＩにマップされる。当業者によって理解されるように、マッピングアルゴリズムは数ある公知の、または独自の、マッピングアルゴリズムのいずれか１つであってよい。本実施形態のマッピングアルゴリズムは次のような特質を持つ。マッピングアルゴリズムは、任意のＵＴＦ８入力文字列を、有効なＡＳＣＩＩ ｅメールユーザ名を表すＡＳＣＩＩ文字列に、符号化できる。この符号化ＡＳＣＩＩ文字列は異なるＵＴＦ８文字列から得ることはできない。逆マッピングまたは復号化アルゴリズムが存在し、これが符号化ＡＳＣＩＩ文字列に適用されると、元のＵＴＦ８入力文字列が得られる。さらに、マッピングアルゴリズムで大文字／小文字の区別がなされないと望ましい。この場合は、何らかのプロセスやヒトによる入力により返信メッセージの符号化ＡＳＣＩＩ文字列の文字の大文字／小文字が変わる場合でも、元のＵＴＦ８文字列を得ることができる。

かかるアルゴリズムの一例は、ＵＴＦ８文字列の各バイトを１６進値の２文字列として表現する。例えば、ｅメールアドレス

はｃｅ９５２ｅｃｅ９４ｃｅｂ４ｃｅｂ１ｃｅｂ９ｃｅｂｄｃｅｂｆｃｆ８２４０ｃｅｂ１ｃｆ８６ｃｅｂ９ｃｅｂｂｃｅｂ９ｃｅｂ１ｃｆ８２２ｅ６９６ｅ６６６ｆ０ｄ０ａの１６進符号化を有する。

かかるアルゴリズムのもうひとつの例はＢａｓｅ６４符号化である。この符号化法はよりコンパクトな符号化を達成し、「多目的インターネットメール拡張仕様（ＭＩＭＥ）第１部：インターネットメッセージ本文の形式」、ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ２０４５等のｅメール規格で既に使用されているため、ある種の実装においては１６進符号化より好ましい。国際化ｅメールアドレス

のＢａｓｅ６４符号化はｚｐＵｕｚｐＴＯｔＭ６ｘｚｒｎＯｖｃ６／ｚ４ＪＡｚｒＨＰｈｓ６５ｚｒｖＯｕｃ６ｘｚ４ＩｕａＷ５ｍｂｗ＝＝である。

かかるアルゴリズムのさらに別の例はＢａｓｅ３２符号化である。Ｂａｓｅ３２では大文字／小文字の区別がなされないためＢａｓｅ６４より好ましい場合がある。符号化で大文字の代わりに小文字を使用した場合の国際化ｅメールアドレス

のＢａｓｅ３２符号化はｚ２ｋｓ５ｔｕｕｚ２２ｍ５ｍｏｏｘｈｈｌ３ｔｖ７ｚ６ｂｅｂｔｖｒｚ６ｄｍ５ｏｏｏｘｐｈｌｔｔｖｒｚ６ｂｃ４２１ｏｍｚｘｑである。

マッピングアルゴリズムに対する将来の変更に対応するため、符号化ＡＳＣＩＩ文字列の最初のバイトとしてアルゴリズム識別子が加えられる。アルゴリズム識別子は、符号化ＡＳＣＩＩ文字列を符号化するため複数のマッピングアルゴリズムが使用された場合に、どのマッピングアルゴリズムが使用されたのかを指示するため使用される。アルゴリズム識別子は、他の符号化アルゴリズムを規定するため使用されるアルゴリズム識別子とは異なる有効なｅメール文字である。アルゴリズム識別子は任意に選択でき、特定の符号化アルゴリズムに事前に割り当て、複数のゲートウェイサーバ２０６にわたって一貫性を持たせることができる。

本実施形態ではバイト「＊」がＢａｓｅ３２符号化を表すアルゴリズム識別子として選ばれるため、ユーザ名は＊ｚ２ｋｓ５ｔｕｕｚ２２ｍ５ｍｏｏｘｈｈｌ３ｔｖ７ｚ６ｂｅｂｔｖｒｚ６ｄｍ５ｏｏｏｘｐｈｌｔｔｖｒｚ６ｂｃ４２１ｏｍｚｘｑとなる。

ステップ３１８ｂでは、マップ済みＡＳＣＩＩ ｅメールアドレスにドメインを提供するため、ゲートウェイサーバは既定ゲートウェイドメインリストからドメインを選択する。既定リスト上の複数のゲートウェイドメインはＤＮＳレジストリにてゲートウェイサーバ２０６にそれぞれ関連付けされている。

既に述べたように、ゲートウェイサーバ２０６は単一の国際化ｅメールサーバ２０４に応対することもあれば、複数の国際化ｅメールサーバ２０４に応対する場合もある。それぞれの国際化ｅメールサーバ２０４は１つ以上のｅメールドメインを使用する。ゲートウェイサーバ２０６がただ１つのｅメールドメインを使用する単一の国際化ｅメールサーバ２０４に応対する場合は、ただ１つのゲートウェイドメインが使用される。例えばゲートウェイドメインｇａｔｅｗａｙ．ａｆｉｌｉａｓ．ｉｎｆｏがドメインとして使用されるなら、ｅメールアドレスは下記の通りになる。

＊ｚ２ｋｓ５ｔｕｕｚ２２ｍ５ｍｏｏｘｈｈｌ３ｔｖ７ｚ６ｂｅｂｔｖｒｚ６ｄｍ５ｏｏｏｘｐｈｌｔｔｖｒｚ６ｂｃ４２ｌｏｍｚｘｑ＠ｇａｔｅｗａｙ．ａｆｉｌｉａｓ．ｉｎｆｏ
ただし、ゲートウェイサーバ２０６が複数のｅメールドメインを使用する単一の国際化ｅメールサーバ２０４に応対する場合、またはゲートウェイサーバ２０６が１つ以上のｅメールドメインを使用する複数の国際化ｅメールサーバ２０４に応対する場合は、ゲートウェイドメインのリストからゲートウェイドメインが選択される。リスト内の各ゲートウェイドメインは対応するｅメールドメインのいずれか１つに関連付けされ、対応する国際化ｅメールサーバ２０４に関連付けされる。上記の例でゲートウェイサーバ２０６はドメインｇａｔｅｗａｙ．ａｆｉｌｉａｓ．ｉｎｆｏ、ｇｗ．ａｔｈｅｎｓ．ｃｏｍ、およびｇｗ．ａｆｉｌｉａｓ．ｉｎｆｏを登録している。これらのドメインには対応するｅメールドメイン

、およびデフォルトがそれぞれ関連付けされている。この情報は表１に示すゲートウェイサーバ４０６のドメイン構成表に保管される。

表１

国際化ｅメールアドレスがゲートウェイサーバ２０６によって応対されるｅメールドメインを含む場合、マップされたＡＳＣＩＩ ｅメールアドレスのドメインは関連付けされたゲートウェイドメインである。例えばｅメールドメインが

なら、マップされたＡＳＣＩＩ ｅメールアドレスのドメインはゲートウェイドメインｇａｔｅｗａｙ．ａｆｉｌｉａｓ．ｉｎｆｏである。同様に、ｅメールドメインが

なら、マップされたＡＳＣＩＩ ｅメールアドレスのドメインはゲートウェイドメインｇｗ．ａｔｈｅｎｓ．ｃｏｍである。ｅメールドメインがゲートウェイサーバ２０６によって応対されない場合、マップされたＡＳＣＩＩ ｅメールアドレスのドメインはデフォルトドメインｇｗ．ａｆｉｌｉａｓ．ｉｎｆｏである。

ステップ３１８ｃでは表示名が決定される。本実施形態では、元の表示名と説明コメントと国際化ｅメールアドレスを連結することによってｅメールアドレスの表示名が生成される。説明コメントは、ドメイン構成表の中でｅメールドメインとゲートウェイドメインに関連付けされている既定コメントである。

ＡＳＣＩＩ ｅメールメッセージのヘッダで非ＡＳＣＩＩ文字は許可されないため、ゲートウェイサーバ２０６はＲＦＣ ２０４７、「ＭＩＭＥ（多目的インターネットメール拡張仕様）第３部：非ＡＳＣＩＩテキストのためのメッセージヘッダ拡張仕様」、ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ２０４７に従い、ｅメールメッセージを送信するときに元の表示名をＭＩＭＥ符号化する。

受信者は格下げされたｅメールアドレスを認識できない可能性があるため、表示名は国際化ｅメールアドレスの識別情報を受信者に提供する。先の例で最終的な格下げされたＡＳＣＩＩ ｅメールアドレスは次の通りになる。

＜＊ｚ２ｋｓ５ｔｕｕｚ２２ｍ５ｍｏｏｘｈｈｌ３ｔｖ７ｚ６ｂｅｂｔｖｒｚ６ｄｍ５ｏｏｏｘｐｈｌｔｔｖｒｚ６ｂｃ４２ｌｏｍｚｘｑ＠ｇａｔｅｗａｙ．ａｆｉｌｉａｓ．ｉｎｆｏ＞
本実施形態は各ｅメールドメインにつきゲートウェイドメインを提供する方法を説明する。ただし、国際化ｅメールアドレス全体は格下げされたｅメールアドレスのユーザ名で符号化されるため、全てのｅメールドメインに対し１つのゲートウェイドメインを提供すれば十分である。ただし、説明コメントに関して例示されるように、各ｅメールドメインにつきゲートウェイドメインを提供することで柔軟性とカスタマイゼーションが得られる。さらに、ゲートウェイドメインは受信者によって見られるため、ｅメールの出所を表すため使用できる。例えば、ある企業は中国の子会社から格下げされたｅメールアドレスにゲートウェイドメインｃｈｉｎａ．ａｆｉｌｉａｓ．ｃｏｍを使用し、ヨーロッパの子会社から格下げされたｅメールアドレスにｅｕｒｏｐｅ．ａｆｉｌｉａｓ．ｃｏｍを使用する。

既に述べたように、多くのユーザは自身のｅメールサーバが国際化ｅメールサーバ２０４にアップグレードされた後にも引き続きＡＳＣＩＩ ｅメールアドレスを使用するかもしれない。ルーティングソフトウェアはメッセージを格下げするときにＡＳＣＩＩ ｅメールアドレスをマップする必要はないが、これを行わない場合、ｅメールメッセージに対する返信は元の国際化ｅメールアドレスではなくマップされたゲートウェイサーバｅメールアドレスにより国際化ｅメールサーバ２０４に到着する。これは望ましくないかもしれない。

代替実施形態において、ルーティングソフトウェアは、ゲートウェイサーバ２０６に関連付けされたドメインを有さない全てのＡＳＣＩＩ ｅメールアドレスを、ゲートウェイサーバ２０６に関連付けされたドメインを有するマップ済みＡＳＣＩＩ ｅメールアドレスにさらに格下げする。さらなる代替実施形態において、ルーティングソフトウェアは、国際化ｅメールサーバに関連付けされた全てのＡＳＣＩＩ ｅメールアドレスを、ゲートウェイサーバ２０６に関連付けされたドメインを有するマップ済みＡＳＣＩＩ ｅメールアドレスに格下げする。

サンプルｅメールアドレスＥｒｎｉｅ Ｄａｉｎｏｗ ＜ｅｄａｉｎｏｗ＠ａｆｉｌｉａｓ．ｉｎｆｏ＞を用いてＡＳＣＩＩマッピングアルゴリズムを説明する。ＡＳＣＩＩマッピングアルゴリズムのアルゴリズム識別子は「＃」記号である。ステップ３１８ａではマップ済みＡＳＣＩＩユーザ名が生成される。ｅメールアドレス内の最後の「＠」記号はドメイン名の手前の「＠」記号となり、アルゴリズム識別子「＃」に差し替えられる。さらにｅメールアドレスの先頭にもアルゴリズム識別子「＃」が加えられるため、ｅメールユーザ名は＃ｅｄａｉｎｏｗ＃ａｆｉｌｉａｓ．ｉｎｆｏとなる。

ステップ３１８ｂでは、マップ済みＡＳＣＩＩ ｅメールアドレスにドメインを提供するため、ゲートウェイサーバ２０６は既定ゲートウェイドメインリストからドメインを選択する。この例でドメインａｆｉｌｉａｓ．ｉｎｆｏはドメインｇｗａｙ．ａｆｉｌｉａｓ．ｉｎｆｏにマップされる。「＠」記号とゲートウェイドメイン名がユーザ名に加えられ、ｅメールアドレスは＃ｅｄａｉｎｏｗ＃ａｆｉｌｉａｓ．ｉｎｆｏ＠ｇｗａｙ．ａｆｉｌｉａｓ．ｉｎｆｏとなる。

ステップ３１８ｃでは表示名が決定される。既に述べたように、ｅメールアドレスの表示名は、元の表示名と説明コメントと国際化ｅメールアドレスを連結することによって生成される。この例の説明コメントは「ｍａｐｐｅｄ ｆｒｏｍ」である。最終的な格下げＡＳＣＩＩ ｅメールアドレスは次の通りになる。

”Ｅｒｎｉｅ Ｄａｉｎｏｗ ｍａｐｐｅｄ ｆｒｏｍ ｅｄａｉｎｏｗ＠ａｆｉｌｉａｓ．ｉｎｆｏ”＜＃ｅｄａｉｎｏｗ＃ａｆｉｌｉａｓ．ｉｎｆｏ＠ｇｗａｙ．ａｆｉｌｉａｓ．ｉｎｆｏ＞
マップ済みＡＳＣＩＩ ｅメールアドレスは全ての返信をゲートウェイサーバ２０６経由で戻るよう誘導し、そこでＡＳＣＩＩと非ＡＳＣＩＩを含むｅメールメッセージの全マップ済みｅメールアドレスは元のアドレスに復元できる。

これより逆マッピングの詳細を説明する。元の国際化ｅメールアドレスを復元するため、ゲートウェイサーバ２０６はｅメールアドレスからユーザ名を抽出する。例えばｅメールアドレスが先の例の国際化ｅメールアドレス

なら、抽出されるユーザ名は下記の通りである。

＊ｚ２ｋｓ５ｔｕｕｚ２２ｍ５ｍｏｏｘｈｈｌ３ｔｖ７ｚ６ｂｅｂｔｖｒｚ６ｄｍ５ｏｏｏｘｐｈｌｔｔｖｒｚ６ｂｃ４２ｌｏｍｚｘｑ
アルゴリズム識別子はユーザ名から除去され、使用された元のマッピングアルゴリズムを判断するため分析される。この例で「＊」はマッピングアルゴリズムとしてＢａｓｅ３２符号化が使用されたことを意味する。したがって、標準Ｂａｓｅ３２復号化を適用することによって逆マッピングが達成され、国際化ｅメールアドレス

が復元される。

表示名は先に加えられた国際化ドメインとコメントを除去することによって修正され、完全な国際化ｅメールアドレスが次の通りに復元される。

元のＡＳＣＩＩ ｅメールアドレスを復元するため、ゲートウェイサーバ２０６はｅメールアドレスからユーザ名を抽出する。例えばｅメールアドレスが先の例のＡＳＣＩＩ ｅメールアドレスｅｄａｉｎｏｗ＠ａｆｉｌｉａｓ．ｉｎｆｏなら、抽出されるユーザ名は下記の通りである。

＃ｅｄａｉｎｏｗ＃ａｆｉｌｉａｓ．ｉｎｆｏ
アルゴリズム識別子はユーザ名から除去され、使用された元のマッピングアルゴリズムを判断するため分析される。この例で「＃」記号はマッピングアルゴリズムとしてＡＳＣＩＩ符号化が使用されたことを意味する。したがって、最後の「＃」記号を「＠」記号に差し替えることによって逆マッピングが達成され、元のＡＳＣＩＩ ｅメールアドレスがｅｄａｉｎｏｗ＠ａｆｉｌｉａｓ．ｉｎｆｏとして復元される。

表示名は先に加えられたＡＳＣＩＩ ｅメールアドレスとコメントを除去することによって修正され、元のｅメールアドレスが”Ｅｒｎｉｅ Ｄａｉｎｏｗ”＜ｅｄａｉｎｏｗ＠ａｆｉｌｉａｓ．ｉｎｆｏ＞として復元される。

説明を簡潔にするため、これより３つの事例を説明してルーティングソフトウェアの実装を例証する。最初の事例では、国際化ｅメールアドレス（ｕｓｅｒ１＠Ｉ１）を有する第１のユーザが国際化ｅメールアドレス（ｕｓｅｒ２＠Ｉ２）を有する第２のユーザとＡＳＣＩＩ限定ｅメールアドレス（ｕｓｅｒ３＠Ａ１）を有する第３のユーザへｅメールメッセージを送信する。第１および第２のユーザは国際化ｅメールサーバ２０４をそれぞれ含み、第３のユーザは従来型ｅメールサーバ２０２を含む。ｅメールメッセージのヘッダは次の通りに表示される。

差出人：ｕｓｅｒ１＠Ｉ１
宛先：ｕｓｅｒ２＠Ｉ２
Ｃｃ：ｕｓｅｒ３＠Ａ１
第１のユーザは関連付けされた第１のゲートウェイサーバ２０６へｅメールメッセージを送信する。ルーティングソフトウェアはｅメールメッセージを受信し、第２のユーザを被選択受信者として選ぶ。第２のユーザは国際化ｅメールアドレスを有するため、ｅメールメッセージは第２のユーザへ転送される。第２のユーザによって受信されたｅメールメッセージのヘッダは次の通りに表示される。

差出人：ｕｓｅｒ１＠Ｉ１
宛先：ｕｓｅｒ２＠Ｉ２
Ｃｃ：ｕｓｅｒ３＠Ａ１
別のユーザがいることが判明し、第３のユーザが被選択受信者として選ばれる。また、第３のユーザがＡＳＣＩＩ限定ｅメールアドレスを有し、第３のユーザのｅメールサーバが従来型ｅメールサーバ２０２であることが判明する。このため、第１のユーザと第２のユーザの国際化ｅメールアドレスは格下げされる。具体的に、第１のユーザの国際化ｅメールアドレスは第１のマップ済みＡＳＣＩＩ ｅメールアドレス＜ｍａｐｐｅｄ（ｕｓｅｒ１＠Ｉ１）＞に格下げされ、第２のユーザの国際化ｅメールアドレスは第２のマップ済みＡＳＣＩＩ ｅメールアドレス＜ｍａｐｐｅｄ（ｕｓｅｒ２）Ｉ２＞に格下げされる。第１および第２のマップ済みＡＳＣＩＩ ｅメールアドレスはｇｗ１．ｄｏｍａｉｎによって表されるゲートウェイドメインにあり、従来のＤＮＳ解決により第１のゲートウェイサーバ２０６まで解決できる。完全なマップ済みｅメールアドレスは＜ｍａｐｐｅｄ（ｕｓｅｒ１＠Ｉ１）＠ｇｗ１．ｄｏｍａｉｎ＞と＜ｍａｐｐｅｄ（ｕｓｅｒ２＠Ｉ２）＠ｇｗ１．ｄｏｍａｉｎ＞である。ｅメールメッセージは第３のユーザへ送出される。第３のユーザによって受信されたｅメールメッセージのヘッダは次の通りに表示される。

差出人：ｍａｐｐｅｄ（ｕｓｅｒ１＠Ｉ１）＠ｇｗ１．ｄｏｍａｉｎ
宛先：ｍａｐｐｅｄ（ｕｓｅｒ２＠Ｉ２）＠ｇｗ１．ｄｏｍａｉｎ
Ｃｃ：ｕｓｅｒ３＠Ａ１
このｅメールメッセージに別の受信者は存在しないため作業は完了であり、ｅメールメッセージは送信済みである。

第２の事例では第２のユーザが全員に返信を実行する。その結果、ｅメールメッセージのヘッダは次の通りに表示される。

差出人：ｕｓｅｒ２＠Ｉ２
宛先：ｕｓｅｒ１＠Ｉ１
Ｃｃ：ｕｓｅｒ３＠Ａ１
第２のユーザは関連付けされた第２のゲートウェイサーバ２０６へｅメールメッセージを送信する。第２のゲートウェイサーバ２０６は第１のゲートウェイサーバ２０６と同じであってよく、同じでなくてもよい。ルーティングソフトウェアはｅメールメッセージを受信し、第１のユーザを被選択受信者として選ぶ。第１のユーザは国際化ｅメールアドレスを有するため、ｅメールメッセージは第１のユーザへ転送される。第１のユーザによって受信されたｅメールメッセージのヘッダは次の通りに表示される。

差出人：ｕｓｅｒ２＠Ｉ２
宛先：ｕｓｅｒ１＠Ｉ１
Ｃｃ：ｕｓｅｒ３＠Ａ１
別のユーザがいることが判明し、第３のユーザが被選択受信者として選ばれる。また、第３のユーザがＡＳＣＩＩ限定ｅメールアドレスを有し、第３のユーザのｅメールサーバが従来型ｅメールサーバ２０２であることが判明する。第１のユーザと第２のユーザの国際化ｅメールアドレスは格下げされる。第２のゲートウェイに登録されたドメインはｇｗ２．ｄｏｍａｉｎと表される。具体的に、第１のユーザの国際化ｅメールアドレスは第３のマップ済みＡＳＣＩＩ ｅメールアドレス＜ｍａｐｐｅｄ２（ｕｓｅｒ１＠Ｉ１）＠ｇｗ２．ｄｏｍａｉｎ＞に格下げされ、第２のユーザの国際化ｅメールアドレスは第４のマップ済みＡＳＣＩＩ ｅメールアドレス＜ｍａｐｐｅｄ２（ｕｓｅｒ２＠Ｉ２）＠ｇｗ２．ｄｏｍａｉｎ＞に格下げされる。第３および第４のマップ済みＡＳＣＩＩ ｅメールアドレスは従来のＤＮＳ解決により第２のゲートウェイサーバ２０６まで解決できる。ｅメールメッセージは第３のユーザへ送出される。第３のユーザによって受信されたｅメールメッセージのヘッダは次の通りに表示される。

差出人：ｍａｐｐｅｄ２（ｕｓｅｒ１＠Ｉ１）＠ｇｗ２．ｄｏｍａｉｎ
宛先：ｍａｐｐｅｄ２（ｕｓｅｒ２＠Ｉ２）＠ｇｗ２．ｄｏｍａｉｎ
Ｃｃ：ｕｓｅｒ３＠Ａ１
別の受信者いないと判断され、作業は完了し、ｅメールメッセージは送信済みである。

第３の事例では、第３のユーザが第１の事例で受信したｅメールメッセージに応じて第１のユーザと第２のユーザへ返信する。ｅメールメッセージのヘッダは次の通りに表示される。

差出人：ｕｓｅｒ３＠Ａ１
宛先：ｍａｐｐｅｄ（ｕｓｅｒ１＠Ｉ１）＠ｇｗ１．ｄｏｍａｉｎ
Ｃｃ：ｍａｐｐｅｄ（ｕｓｅｒ２＠Ｉ２）＠ｇｗ１．ｄｏｍａｉｎ
第３のユーザはゲートウェイサーバ２０６に関連付けされていない。既に述べたように、第３は従来型ｅメールサーバ２０２を含むため、ＡＳＣＩＩ ｅメールアドレスだけにｅメールメッセージを送信する。従来型ｅメールサーバ４０２は標準ｅメール伝送プロトコルを使って第１および第２のマップ済みＡＳＣＩＩ ｅメールアドレスへｅメールメッセージを送達する。

第１のマップ済みｅメールアドレスのドメインはＤＮＳレジストリにて第１のゲートウェイサーバ２０６に関連付けされているため、第１のマップ済みｅメールアドレスの場合は、標準ドメイン名解決によって特定される第１のゲートウェイサーバ２０６へｅメールメッセージが送達される。

ｅメールメッセージは第１のゲートウェイサーバ２０６によって受信される。ルーティングソフトウェアは第１のマップ済みＡＳＣＩＩ ｅメールアドレスが第１のゲートウェイサーバ２０６に関連付けされていると判断し、第１および第２のマップ済みＡＳＣＩＩ ｅメールアドレスの国際化ｅメールアドレスを復元する。ルーティングソフトウェアはその後、第１のユーザへｅメールメッセージを送信する。第１のユーザによって受信されたｅメールメッセージのヘッダは次の通りに表示される。

差出人：ｕｓｅｒ３＠Ａ１
宛先：ｕｓｅｒ１＠Ｉ１
Ｃｃ：ｕｓｅｒ２＠Ｉ１
第２のマップ済みＡＳＣＩＩ ｅメールアドレスのドメインはＤＮＳレジストリにて第１のゲートウェイサーバ２０６に関連付けされているため、第２のマップ済みｅメールアドレスの場合は、標準ドメイン名解決によって特定される第１のゲートウェイサーバ２０６へｅメールメッセージが送達される。

ｅメールメッセージは第１のゲートウェイサーバ２０６によって受信される。ルーティングソフトウェアは第２のマップ済みＡＳＣＩＩ ｅメールアドレスが第１のゲートウェイサーバ２０６に関連付けされていると判断し、第１および第２のマップ済みＡＳＣＩＩ ｅメールアドレスの国際化ｅメールアドレスを復元する。ルーティングソフトウェアはその後、第２のユーザへｅメールメッセージを送信する。第２のユーザによって受信されたｅメールメッセージのヘッダは次の通りに表示される。

差出人：ｕｓｅｒ３＠Ａ１
宛先：ｕｓｅｒ１＠Ｉ１
Ｃｃ：ｕｓｅｒ２＠Ｉ１
第３のユーザが第１のユーザではなく第２のユーザ（第２の事例で説明したメッセージ）に応答した場合でも送信は上記と同様となる。ただし、ｅメールメッセージは第１のゲートウェイサーバ２０６ではなく第２のゲートウェイサーバ２０６へ送信され、第１のユーザと第２のユーザによって受信されたｅメールメッセージのヘッダは次の通りに表示される。

差出人：ｕｓｅｒ３＠Ａ１
宛先：ｕｓｅｒ１＠Ｉ１
Ｃｃ：ｕｓｅｒ２＠Ｉ１
ＡＳＣＩＩ限定ｅメールアドレスの受信者と国際化ｅメールアドレスの受信者がｅメールメッセージに混在する場合に、本発明が国際化ｅメールサーバ４０４と従来型ｅメールサーバ４０２とのｅメール伝送を促進することは理解されよう。

上述したゲートウェイサーバ２０６は、国際化ｅメールサーバ２０４からの全てｅメールメッセージが必ず通過するゲートウェイとして実装できる。あるいはゲートウェイサーバ２０６は、ｅメールメッセージの受信者のうち少なくとも１名が従来型ｅメールサーバ２０２を使用すると判断される場合に「必要に応じ」実装できる。

代替実施形態では、国際化ｅメールアドレスを有するｅメールユーザがＡＳＣＩＩ ｅメールアドレスをも有する場合がある。この場合、ゲートウェイサーバ２０６は、生成されるアドレスより受信者にとって読みやすく分かりやすい既存のＡＳＣＩＩ ｅメールアドレスを使用したほうがよいかもしれない。

これをサポートするため、ゲートウェイサーバ２０６はアドレス構成表を含む。アドレス構成表の１列には国際化ｅメールアドレスが列記される。アドレス構成表の第２の列には国際化ｅメールアドレスに対応するＡＳＣＩＩ ｅメールアドレスが列記される。本実施形態でアドレス構成表の内容はシステム管理者によって埋められる。

例えば下の表２に示すように、国際化ｅメールアドレス

にはＡＳＣＩＩ ｅメールアドレス”Ｅｒｎｉｅ Ｄａｉｎｏｗ ＜Ｅ．Ｄａｉｎｏｗ＠ａｆｉｌｉａｓ．ｉｎｆｏ＞”が対応する。本実施形態では、構成済みＡＳＣＩＩ ｅメールアドレスとマップ済みＡＳＣＩＩ ｅメールアドレスとの衝突を防ぐため、構成プロセスは構成済みＡＳＣＩＩ ｅメールアドレスで上記例の「＊」および「＃」記号等のアルゴリズム識別子の使用を制限する。つまり、構成済みＡＳＣＩＩ ｅメールアドレスの少なくとも第１のバイトには、アルゴリズム識別子として使用される文字やアルゴリズム識別子として予約された文字を使用できないようにする。

表２

この機能を促進するため、ルーティングソフトウェアは次の通りに修正される。ステップ３１８でｅメールヘッダの全てのｅメールアドレスがマップされるときには、アドレス構成表を解析してｅメールアドレスの有無を確認する。アドレス構成表の中にｅメールアドレスがなければ、ステップ３１８ａ、３１８ｂ、および３１８ｃを参照して上述したように、ルーティングソフトウェアは必要に応じそのｅメールアドレスを格下げする。アドレス構成表の中にｅメールアドレスがある場合は、ｅメールヘッダ内のｅメールアドレスがアドレス構成表内の対応するＡＳＣＩＩ ｅメールアドレスに取り替えられる。実装次第では、上述したようにルーティングソフトウェアは、対応するＡＳＣＩＩ ｅメールアドレスがゲートウェイサーバに関連付けされていない場合に、対応するＡＳＣＩＩ ｅメールアドレスを格下げする。

さらに、ステップ３０５および３１０を参照して説明したルーティングソフトウェアは次の通りに修正される。ｅメールアドレスにゲートウェイサーバ２０６が関連付けされている場合は、上述したようにゲートウェイサーバがｅメールアドレスを逆マップする。逆マップされたｅメールアドレスがＡＳＣＩＩ ｅメールアドレスなら、ルーティングソフトウェアはアドレス構成表のＡＳＣＩＩ ｅメールアドレス列を解析する。ＡＳＣＩＩ ｅメールアドレスが見つかる場合は、対応する国際化アドレス列の値が使用される。ＡＳＣＩＩ ｅメールアドレスが見つからない場合は、逆マップされたｅメールアドレスが使用される。

ＡＳＣＩＩ ｅメールアドレスがゲートウェイサーバ２０６に関連付けされていなければ、ルーティングソフトウェアはアドレス構成表のＡＳＣＩＩ ｅメールアドレス列を解析する。ＡＳＣＩＩ ｅメールアドレスが見つかる場合は、国際アドレス列の対応する値が使用される。ＡＳＣＩＩ ｅメールアドレスが見つからない場合は、受信されたＡＳＣＩＩ ｅメールが使用される。

代替実施形態では、対応するＡＳＣＩＩ ｅメールアドレスのマップ済みＡＳＣＩＩ ｅメールアドレスを、アドレス構成表が作成されたら、アドレス構成表に保管できる。その後の探索では、対応するｅメールアドレスを無視してマップ済みＡＳＣＩＩ ｅメールアドレスを直接引き出すことができる。さらなる代替実施形態では、非ＡＳＣＩＩ ｅメールアドレスのマップ済みＡＳＣＩＩ ｅメールアドレスをアドレス構成表に保管することもできる。

当業者にとって明白なように、ここで説明する方法には本発明を損なうことなく修正を加えることができる。例えば、実施形態ではｅメールメッセージの残りの部分を格下げするゲートウェイサーバ２０６が説明されているが、この機能は、国際化ｅメールサーバ２０４等、ゲートウェイサーバ２０６以外のサーバで遂行できる。もうひとつの例として、説明ではｅメール管理手段としてＤＮＳに具体的に言及しているが、ライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）や他の公知の方法や独自の方法を使用することもできる。

上記の明細書に基づき、標準プログラミングおよび／またはエンジニアリング技法を用いてプログラミングソフトウェア、ファームウェア、ハードウェア、またはこれらの組合せを作ることにより、機械、プロセス、または製造品として本発明を実装できる。

コンピュータ可読プログラムコードを有するプログラムを記憶装置や伝送装置等の１つ以上のコンピュータ用媒体の中で具現することにより、本発明によるコンピュータプログラム製品または製造品を作ることができる。本書で使用されている用語「ソフトウェア」および「アプリケーション」は、記憶装置や伝送装置等のコンピュータ用媒体に（永続的に、臨時に、または一時的に）存在するコンピュータプログラムを含む。

記憶装置の例は、ハードディスクドライブ、ディスケット、光ディスク、磁気テープ、ＦＬＡＳＨ、ＲＡＭ、ＲＯＭ、ＰＲＯＭＳ等の半導体メモリ等を含む。ネットワークの例は、インターネット、イントラネット、電話／モデム方式ネットワーク通信、有線／ケーブル通信ネットワーク、セルラー通信、電波通信、衛星通信、他の静止または移動ネットワークシステム／通信リンクを含み、ただしこれらに限定されない。

本発明を具現する機械には、請求項に記載された通りに本発明を具現するソフトウェア、ファームウェア、ハードウェア、またはこれらの組合せまたは部分的組合せを含む、ＣＰＵ、記憶／蓄積装置、通信リンク、通信／伝送装置、サーバ、Ｉ／Ｏ装置、または１つ以上の処理システムのサブコンポーネントまたは部品を含む、１つ以上のプロセッサが組み込まれてよい。

当業者は、本書に記載された説明に基づき、説明の通りに作られたソフトウェアを適切な汎用または専用コンピュータハードウェアに組み合わせることで、本発明を具現するコンピュータシステムおよび／またはコンピュータサブコンポーネントを作ることができ、また本発明の方法を遂行するコンピュータシステムおよび／またはコンピュータサブコンポーネントを作ることができるであろう。

本書では本発明の好適な実施形態を説明したが、本発明の趣旨と添付の請求項の範囲から逸脱することなく好適な実施形態に変更を加えることができることは、当業者によって理解されよう。

本書では本発明の好適な実施形態を説明したが、本発明の趣旨と添付の請求項の範囲から逸脱することなく好適な実施形態に変更を加えることができることは、当業者によって理解されよう。
以下に、本願出願時の特許請求の範囲に記載された発明を付記する。
［１］送信者から被選択受信者へｅメールメッセージを送信するコンピュータ実装方法であって、前記被選択受信者は情報交換用米国標準コード（ＡＳＣＩＩ）に準拠する複数のｅメールメッセージだけを受信でき、前記送信者または他の複数の受信者のうち１名以上は非ＡＳＣＩＩ ｅメールアドレスを有し、前記方法は、
既定マッピングアルゴリズムを使用し前記非ＡＳＣＩＩ ｅメールアドレスのマッピングとしてユーザ名を生成することと、
既定ゲートウェイサーバまで解決されるよう各々構成された１つ以上の既定ドメイン名からドメイン名を選択することと、
マップ済みＡＳＣＩＩ ｅメールアドレスを作成するため前記ユーザ名と前記ドメイン名を連結することと、によって、
前記複数の非ＡＳＣＩＩ ｅメールアドレスの各々につき前記複数の対応するマップ済みＡＳＣＩＩ ｅメールアドレスを作成することと、
前記複数の非ＡＳＣＩＩ ｅメールアドレスを前記対応するマップ済みＡＳＣＩＩ ｅメールアドレスに差し替えることと、
被選択受信者へ前記ｅメールメッセージを送信することと、
の各ステップを備える、方法。
［２］既定マッピングアルゴリズムを使用し前記ＡＳＣＩＩ ｅメールアドレスのマッピングとしてユーザ名を生成することと、
前記既定ゲートウェイサーバまで解決されるよう各々構成された前記１つ以上の既定ドメイン名からドメイン名を選択することと、
前記マップ済みＡＳＣＩＩ ｅメールアドレスを作成するため前記ユーザ名と前記ドメイン名を連結することと、によって、
前記受信者を除く前記複数のＡＳＣＩＩ ｅメールアドレスの各々につき複数の対応するマップ済みＡＳＣＩＩ ｅメールアドレスを作成することと、
前記複数のＡＳＣＩＩ ｅメールアドレスを前記対応するマップ済みＡＳＣＩＩ ｅメールアドレスに差し替えることと、
のさらなる各ステップを備える、前記［１］に記載の方法。
［３］必要に応じ、既定プロトコルを使用し前記ｅメールメッセージの残りの部分を格下げするステップをさらに備える、前記［２］に記載の方法。
［４］前記ユーザ名はさらに、使用する前記既定マッピングアルゴリズムを識別するアルゴリズム識別子を含む、前記［２］に記載の方法。
［５］前記マップ済みＡＳＣＩＩ ｅメールアドレスはさらに、前記送信者を識別する表示名を備える、前記［２］に記載の方法。
［６］前記表示名はさらに、マップ元にあたる前記対応するＡＳＣＩＩ ｅメールアドレスを識別する、前記［５］に記載の方法。
［７］前記表示名はさらに、マップ元にあたる前記対応する非ＡＳＣＩＩ ｅメールアドレスを識別し、前記表示名は前記ｅメールメッセージの前記残りの部分とともに格下げされる、前記［５］に記載の方法。
［８］前記複数のマップ済みＡＳＣＩＩ ｅメールアドレスは、複数の国際化ｅメールサーバによって処理される前記複数のＡＳＣＩＩ ｅメールアドレスに限り作成される、前記［２］に記載の方法。
［９］前記マップ済みＡＳＣＩＩ ｅメールアドレスを作成する前に、
既定ｅメールアドレス表から前記非ＡＳＣＩＩ ｅメールアドレスに関連付けされた対応するＡＳＣＩＩ ｅメールアドレスを判断することと、
前記非ＡＳＣＩＩ ｅメールアドレスを前記対応するＡＳＣＩＩ ｅメールアドレスに差し替えることと、の各ステップをさらに備える、前記［１］に記載の方法。
［１０］前記符号化アルゴリズムは、１６進符号化、Ｂａｓｅ６４符号化、またはＢａｓｅ３２符号化のいずれか１つである、前記［１］に記載の方法。
［１１］前記複数のドメイン名の各々は、ドメイン名システム（ＤＮＳ）かライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）を使用し前記既定ゲートウェイサーバまで解決されるよう構成される、前記［１］に記載の方法。
［１２］複数のユーザ間でｅメールメッセージを送るよう構成されたゲートウェイサーバであって、前記複数のユーザの少なくとも１名は国際化ｅメールサーバによって応対され、前記複数のユーザの少なくとも１名は従来型ｅメールサーバによって応対され、前記ゲートウェイサーバは、
複数のコンピュータ可読命令を蓄積するメモリと、
前記複数の命令を実施するよう構成されたプロセッサとを、備え、前記複数の命令は、
既定マッピングアルゴリズムを使用し前記ユーザのｅメールアドレスのマッピングとしてユーザ名を生成することと、
前記ゲートウェイサーバまで解決されるよう各々構成された１つ以上の既定ドメイン名からドメイン名を選択することと、
マップ済みＡＳＣＩＩ ｅメールアドレスを作成するため前記ユーザ名と前記ドメイン名を連結することと、によって、
前記国際化ｅメールサーバによって応対される前記複数のユーザの各ｅメールアドレスにつき前記マップ済みＡＳＣＩＩ ｅメールアドレスを作成でき、
前記複数のユーザのｅメールアドレスを前記複数の対応するマップ済みＡＳＣＩＩ ｅメールアドレスに差し替えることができ、且つ
前記ｅメールメッセージを送信できる、
ゲートウェイサーバ。
［１３］前記複数の命令はさらに、必要に応じ、既定プロトコルを使用し前記ｅメールメッセージの残りの部分を格下げできる、前記［１２］に記載のゲートウェイサーバ。
［１４］前記国際化ｅメールサーバによって応対される前記複数のユーザの前記複数のｅメールアドレスは複数の非ＡＳＣＩＩ ｅメールアドレスである、前記［１２］に記載のゲートウェイサーバ。
［１５］前記国際化ｅメールサーバによって応対される前記複数のユーザの前記複数のｅメールアドレスは複数のＡＳＣＩＩ ｅメールアドレスである、前記［１２］に記載のゲートウェイサーバ。
［１６］前記複数の命令はさらに、
既定マッピングアルゴリズムを使用し前記ＡＳＣＩＩ ｅメールアドレスのマッピングとしてユーザ名を生成することと、
前記既定ゲートウェイサーバまで解決されるよう各々構成された前記１つ以上の既定ドメイン名からドメイン名を選択することと、
前記マップ済みＡＳＣＩＩ ｅメールアドレスを作成するため前記ユーザ名と前記ドメイン名を連結することと、によって、
前記受信者を除く前記複数のＡＳＣＩＩ ｅメールアドレスの各々につき前記マップ済みＡＳＣＩＩ ｅメールアドレスを作成でき、且つ
前記複数のＡＳＣＩＩ ｅメールアドレスを前記対応するマップ済みＡＳＣＩＩ ｅメールアドレスに差し替えることができる、前記［１２］に記載のゲートウェイサーバ。
［１７］前記ユーザ名はさらに、使用する前記既定マッピングアルゴリズムを識別するアルゴリズム識別子を含む、前記［１６］に記載のゲートウェイサーバ。
［１８］前記マップ済みＡＳＣＩＩ ｅメールアドレスはさらに、前記送信者を識別する表示名を備える、前記［１６］に記載のゲートウェイサーバ。
［１９］前記表示名はさらに、マップ元にあたる前記対応するＡＳＣＩＩ ｅメールアドレスを識別する、前記［１８］に記載のゲートウェイサーバ。
［２０］前記表示名はさらに、マップ元にあたる前記対応する非ＡＳＣＩＩ ｅメールアドレスを識別し、前記表示名は前記ｅメールメッセージの前記残りの部分とともに格下げされる、前記［１８］に記載のゲートウェイサーバ。
［２１］前記複数のマップ済みＡＳＣＩＩ ｅメールアドレスは、複数の国際化ｅメールサーバによって処理される前記複数のＡＳＣＩＩ ｅメールアドレスに限り作成される、前記［１６］に記載のゲートウェイサーバ。
［２２］前記複数の命令はさらに、前記マップ済みＡＳＣＩＩ ｅメールアドレスを作成する前に、
既定アドレス構成表から前記ｅメールアドレスに関連付けされた対応するＡＳＣＩＩ ｅメールアドレスを判断でき、且つ
前記ｅメールアドレスを前記対応するＡＳＣＩＩ ｅメールアドレスに差し替えることができる、前記［１２］に記載のゲートウェイサーバ。
［２３］前記複数のドメイン名の各々は、ドメイン名システム（ＤＮＳ）かライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）を使用し前記既定ゲートウェイサーバまで解決されるよう構成される、前記［１２］に記載のゲートウェイサーバ。
［２４］プロセッサによって実行され前記プロセッサに前記［１］の前記方法を実施させる複数の命令を蓄積したコンピュータ可読媒体。

Claims (24)

1. 送信者から被選択受信者へｅメールメッセージを送信するコンピュータ実装方法であって、前記被選択受信者は情報交換用米国標準コード（ＡＳＣＩＩ）に準拠する複数のｅメールメッセージだけを受信でき、前記送信者または他の複数の受信者のうち１名以上は非ＡＳＣＩＩ ｅメールアドレスを有し、前記方法は、
   既定マッピングアルゴリズムを使用し前記非ＡＳＣＩＩ ｅメールアドレスのマッピングとしてユーザ名を生成することと、
   既定ゲートウェイサーバまで解決されるよう各々構成された１つ以上の既定ドメイン名からドメイン名を選択することと、
   マップ済みＡＳＣＩＩ ｅメールアドレスを作成するため前記ユーザ名と前記ドメイン名を連結することと、によって、
   前記複数の非ＡＳＣＩＩ ｅメールアドレスの各々につき前記複数の対応するマップ済みＡＳＣＩＩ ｅメールアドレスを作成することと、
   前記複数の非ＡＳＣＩＩ ｅメールアドレスを前記対応するマップ済みＡＳＣＩＩ ｅメールアドレスに差し替えることと、
   被選択受信者へ前記ｅメールメッセージを送信することと、
   の各ステップを備える、方法。
2. 既定マッピングアルゴリズムを使用し前記ＡＳＣＩＩ ｅメールアドレスのマッピングとしてユーザ名を生成することと、
   前記既定ゲートウェイサーバまで解決されるよう各々構成された前記１つ以上の既定ドメイン名からドメイン名を選択することと、
   前記マップ済みＡＳＣＩＩ ｅメールアドレスを作成するため前記ユーザ名と前記ドメイン名を連結することと、によって、
   前記受信者を除く前記複数のＡＳＣＩＩ ｅメールアドレスの各々につき複数の対応するマップ済みＡＳＣＩＩ ｅメールアドレスを作成することと、
   前記複数のＡＳＣＩＩ ｅメールアドレスを前記対応するマップ済みＡＳＣＩＩ ｅメールアドレスに差し替えることと、
   のさらなる各ステップを備える、請求項１に記載の方法。
3. 必要に応じ、既定プロトコルを使用し前記ｅメールメッセージの残りの部分を格下げするステップをさらに備える、請求項２に記載の方法。
4. 前記ユーザ名はさらに、使用する前記既定マッピングアルゴリズムを識別するアルゴリズム識別子を含む、請求項２に記載の方法。
5. 前記マップ済みＡＳＣＩＩ ｅメールアドレスはさらに、前記送信者を識別する表示名を備える、請求項２に記載の方法。
6. 前記表示名はさらに、マップ元にあたる前記対応するＡＳＣＩＩ ｅメールアドレスを識別する、請求項５に記載の方法。
7. 前記表示名はさらに、マップ元にあたる前記対応する非ＡＳＣＩＩ ｅメールアドレスを識別し、前記表示名は前記ｅメールメッセージの前記残りの部分とともに格下げされる、請求項５に記載の方法。
8. 前記複数のマップ済みＡＳＣＩＩ ｅメールアドレスは、複数の国際化ｅメールサーバによって処理される前記複数のＡＳＣＩＩ ｅメールアドレスに限り作成される、請求項２に記載の方法。
9. 前記マップ済みＡＳＣＩＩ ｅメールアドレスを作成する前に、
   既定ｅメールアドレス表から前記非ＡＳＣＩＩ ｅメールアドレスに関連付けされた対応するＡＳＣＩＩ ｅメールアドレスを判断することと、
   前記非ＡＳＣＩＩ ｅメールアドレスを前記対応するＡＳＣＩＩ ｅメールアドレスに差し替えることと、の各ステップをさらに備える、請求項１に記載の方法。
10. 前記符号化アルゴリズムは、１６進符号化、Ｂａｓｅ６４符号化、またはＢａｓｅ３２符号化のいずれか１つである、請求項１に記載の方法。
11. 前記複数のドメイン名の各々は、ドメイン名システム（ＤＮＳ）かライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）を使用し前記既定ゲートウェイサーバまで解決されるよう構成される、請求項１に記載の方法。
12. 複数のユーザ間でｅメールメッセージを送るよう構成されたゲートウェイサーバであって、前記複数のユーザの少なくとも１名は国際化ｅメールサーバによって応対され、前記複数のユーザの少なくとも１名は従来型ｅメールサーバによって応対され、前記ゲートウェイサーバは、
    複数のコンピュータ可読命令を蓄積するメモリと、
    前記複数の命令を実施するよう構成されたプロセッサとを、備え、前記複数の命令は、
    既定マッピングアルゴリズムを使用し前記ユーザのｅメールアドレスのマッピングとしてユーザ名を生成することと、
    前記ゲートウェイサーバまで解決されるよう各々構成された１つ以上の既定ドメイン名からドメイン名を選択することと、
    マップ済みＡＳＣＩＩ ｅメールアドレスを作成するため前記ユーザ名と前記ドメイン名を連結することと、によって、
    前記国際化ｅメールサーバによって応対される前記複数のユーザの各ｅメールアドレスにつき前記マップ済みＡＳＣＩＩ ｅメールアドレスを作成でき、
    前記複数のユーザのｅメールアドレスを前記複数の対応するマップ済みＡＳＣＩＩ ｅメールアドレスに差し替えることができ、且つ
    前記ｅメールメッセージを送信できる、
    ゲートウェイサーバ。
13. 前記複数の命令はさらに、必要に応じ、既定プロトコルを使用し前記ｅメールメッセージの残りの部分を格下げできる、請求項１２に記載のゲートウェイサーバ。
14. 前記国際化ｅメールサーバによって応対される前記複数のユーザの前記複数のｅメールアドレスは複数の非ＡＳＣＩＩ ｅメールアドレスである、請求項１２に記載のゲートウェイサーバ。
15. 前記国際化ｅメールサーバによって応対される前記複数のユーザの前記複数のｅメールアドレスは複数のＡＳＣＩＩ ｅメールアドレスである、請求項１２に記載のゲートウェイサーバ。
16. 前記複数の命令はさらに、
    既定マッピングアルゴリズムを使用し前記ＡＳＣＩＩ ｅメールアドレスのマッピングとしてユーザ名を生成することと、
    前記既定ゲートウェイサーバまで解決されるよう各々構成された前記１つ以上の既定ドメイン名からドメイン名を選択することと、
    前記マップ済みＡＳＣＩＩ ｅメールアドレスを作成するため前記ユーザ名と前記ドメイン名を連結することと、によって、
    前記受信者を除く前記複数のＡＳＣＩＩ ｅメールアドレスの各々につき前記マップ済みＡＳＣＩＩ ｅメールアドレスを作成でき、且つ
    前記複数のＡＳＣＩＩ ｅメールアドレスを前記対応するマップ済みＡＳＣＩＩ ｅメールアドレスに差し替えることができる、請求項１２に記載のゲートウェイサーバ。
17. 前記ユーザ名はさらに、使用する前記既定マッピングアルゴリズムを識別するアルゴリズム識別子を含む、請求項１６に記載のゲートウェイサーバ。
18. 前記マップ済みＡＳＣＩＩ ｅメールアドレスはさらに、前記送信者を識別する表示名を備える、請求項１６に記載のゲートウェイサーバ。
19. 前記表示名はさらに、マップ元にあたる前記対応するＡＳＣＩＩ ｅメールアドレスを識別する、請求項１８に記載のゲートウェイサーバ。
20. 前記表示名はさらに、マップ元にあたる前記対応する非ＡＳＣＩＩ ｅメールアドレスを識別し、前記表示名は前記ｅメールメッセージの前記残りの部分とともに格下げされる、請求項１８に記載のゲートウェイサーバ。
21. 前記複数のマップ済みＡＳＣＩＩ ｅメールアドレスは、複数の国際化ｅメールサーバによって処理される前記複数のＡＳＣＩＩ ｅメールアドレスに限り作成される、請求項１６に記載のゲートウェイサーバ。
22. 前記複数の命令はさらに、前記マップ済みＡＳＣＩＩ ｅメールアドレスを作成する前に、
    既定アドレス構成表から前記ｅメールアドレスに関連付けされた対応するＡＳＣＩＩ ｅメールアドレスを判断でき、且つ
    前記ｅメールアドレスを前記対応するＡＳＣＩＩ ｅメールアドレスに差し替えることができる、請求項１２に記載のゲートウェイサーバ。
23. 前記複数のドメイン名の各々は、ドメイン名システム（ＤＮＳ）かライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）を使用し前記既定ゲートウェイサーバまで解決されるよう構成される、請求項１２に記載のゲートウェイサーバ。
24. プロセッサによって実行され前記プロセッサに請求項１の前記方法を実施させる複数の命令を蓄積したコンピュータ可読媒体。

Images