JP2018508169A - Ｅｈｌｏ名およびｉｐアドレスターゲティングによる電子メール送信者の集中型検証 - Google Patents

Abstract

ＤＮＳサーバは、ＤＮＳサーバに記憶されている電子メールドメインに対するＤＮＳ照会を受信電子メールシステムから受信し、ＤＮＳ照会は、電子メールの送信者の識別情報を含む。ＤＮＳサーバは、ＤＮＳ照会から電子メール送信者の識別情報を抽出し、その情報から複数の配信機構の１つを識別する。ＤＮＳサーバは、識別された配信機構が、電子メールドメインに代わって電子メールを配信することが許可されているかどうかを判定する。識別された配信機構が、電子メールドメインに代わって電子メールを配信することが許可されていると決定したことに応答し、ＤＮＳサーバは、許可された配信機構および電子メールドメインの識別に基づいて、ターゲット妥当性検証レコードを生成し、ターゲット妥当性検証レコードは、配信機構が、電子メールドメインに対する電子メールの許可された送信者であるかどうかを受信電子メールシステムに示す１または複数のルールを含む。

Description

本開示は、一般に、電子的なメッセージングの分野に関し、詳細には、ＥＨＬＯ名およびＩＰアドレスターゲティングによる電子メール送信者の集中型検証に関する。

関連出願への相互参照
本出願は、２０１５年２月１４日に出願された米国特許仮出願第６２／１１６、４０９号明細書の利益を主張するものであり、その全体が参照により本明細書に組み込まれる。

電子メールなどの分散メッセージングシステムにおいては、メッセージの実際の発信者は、不正なメッセージをなくすために、メッセージの主張された識別に対する妥当性が検証され得る。このような不正なメッセージの例は、特定の送信者からのものであると称しているが、実際は詐称された送信者アドレスを有し、かつ受取人に対して何らかの不正な作業を実施する（例えば、個人情報を盗む）ことを望む可能性のある悪意のあるエンティティから送られた「フィッシング」電子メールを含む可能性がある。この妥当性検証問題に対する１つの手法は、送信識別の所有者に、どのコンピュータが、受取人の電子メールサーバに電子メールを中継可能であるかを定義するルールのセットを作成できるようにすることである。送信者ポリシーフレームワーク（ＳＰＦ）は、電子メールに対するこの手法の標準の実装形態である。送信識別は、受信メールサーバが、受信されたメッセージの送信者の識別の妥当性を検証するために、それらにアクセスすることが可能であるようなドメイン名システム（ＤＮＳ）を介してこれらのＳＰＦルールをパブリッシュする。

この手法は有効であり得るが、それは、受信システムに対してかなりの負担を与え、かつ有効な媒介（例えば、メーリングリスト、「ライフタイム」電子メールアカウントなど）を使用することに課題を生ずる。例えば、メーリングリストサーバは、発信元の送信者からのメッセージを転送するように求められ得るが、メーリングリストサーバは、発信元の送信者により有効な送信者として識別されない。メッセージの妥当性を検証するとき、完全なルールセットが、数百の、またはさらに数千のルールを要求するとしても、受信システムは、いくつかのこのようなルールよりも多くの検査を実質的に実行することはできない。

ＳＰＦはまた、受信システムに対する負担を制限するために、可能なドメイン名システム（ＤＮＳ）参照数に対する厳しい制限を含むが、これは、いくつかの正当なメッセージの妥当性の検証に失敗する犠牲を払うことになる。送信者書換えスキーム（ＳＲＳ）などの他の技法は、元の送信者を、より制限されたルールセットによって妥当性が検証され得る中間的な識別へと置き換える。こうすることにより、受信システムに対する負担は最小化するが、発信者の識別に対するメッセージの妥当性を検証することにならない。

したがって、欠けているのは、受信システムに不当に負担をかけることがなく、既存のフレームワークと互換性があり、かつ相互運用可能な、送信者識別検証のための任意に多量の複雑なルールセットを定義できる能力である。

いくつかの実施形態では、システムおよび方法は、ネットワークまたはＩＰレベルからの電子メールに関する認証質問を、送信機構レベルへと再フレーム化すること、既存の送信者ポリシーフレームワーク（ＳＰＦ）プロトコルの能力を用いて、ＳＭＴＰ接続から利用可能なネットワーク情報をターゲテッドドメイン名へと符号化すること、およびそれを、そのネットワーク情報を既知の機構のリストへとマップするデータベースにより支援されたカスタムのＤＮＳシステムと組み合わせることを含むことができる。

いくつかの実施形態では、システムおよび方法は、ドメインマネジャに、許可された機構に対するＳＰＦレコードの手動の参照、ドメインに対するＤＮＳ ＴＸＴレコードの変更など、何らかのさらなる作業を必要とすることなく、それ自体のために、電子メールを送ることのできる機構のセットを定義できるようにする。それはまた、ドメインマネジャに、任意の数の送信機構を許可できるようにし、かつ許可された送信者に対するＳＰＦ構成への変更を追跡する必要性をドメインマネジャから開放する。

いくつかの実施形態では、システムおよび方法は、ドメインの所有者が、そのドメインから発信された電子メールをどのメールサーバが配信できるかを指定するルールのセット（ディレクティブとして知られている）を、ＤＮＳ ＴＸＴレコードで定義できるプロトコルとすることのできる送信者ポリシーフレームワーク（ＳＰＦ）を含むことができる。受信メールサーバは、これらのルールを評価し、かつ配信サーバのＩＰアドレスに基づき、問題のメッセージが、そのドメインから発信できるかどうかを判定する。

いくつかの実施形態では、システムおよび方法は、ＳＰＦの２つの機能を利用することができる。第１に「ｉｎｃｌｕｄｅ」メカニズムであり、それにより、ＳＰＦレコードは、さらなるＤＮＳ ＳＰＦレコードが定義されているターゲットドメインを参照し、かつこの参照レコードで定義されたルールを、評価されたルールセットの中に含めることができる。第２に、マクロシステムであり、それによって、ＳＭＴＰ接続に関連付けられたＩＰアドレスおよびＥＨＬＯ名などの要求特有の値が、ターゲットドメインに補間され得る。

いくつかの実施形態では、ドメインを構成するとき、ＳＰＦレコードは、電子メールが許可されているドメインの名前、ならびにＳＭＴＰ接続のＥＨＬＯ名および／またはＩＰアドレスを、ターゲットドメイン名へと符号化するためにＳＰＦマクロを使用する「ｉｎｃｌｕｄｅ」ディレクティブを組込むドメインに対して構成され得る。ターゲットドメイン名は、ネットワーク情報を既知の機構のリストにマッピングする責任を担うＤＮＳシステムである、ターゲテッドＳＰＦ ＤＮＳリゾルバにより管理されるＤＮＳゾーン内にあるように構成され得る。

さらなる実施形態では、ターゲテッドＳＰＦ ＤＮＳリゾルバは、ターゲットドメインに対するＤＮＳ照会に応ずる責任を担うことができる。それはまた、既知の機構に対するネットワーク情報の正確な、最新のマッピングを維持する責任を担うことができ、それは、ドメイン登録レコード、パブリックＤＮＳエントリ、および精選された情報などのパブリック情報を組み合わせることを含むことができる。

さらなる実施形態において、送信者ポリシーフレームワーク（ＳＰＦ）を向上させるためのシステムおよび方法は、ドメインマネジャに提示される全体的な複雑さ、および維持負担を低減し、かつ同様の認証を提供するための最新システムの既存の制限を除くことにより、電子メールを認証する技術を進歩させることができる。さらに、本方法は、電子メールを受信するシステムに対して何らかの変更を必要とする可能性がなく、またインストールされたソフトウェアの既存の、かつ広範囲なベースと両立性を有することができる。

開示される実施形態は、詳細な説明、添付の特許請求の範囲、および添付図（または図面）から容易に明らかになる利点および特徴を有する。諸図の簡単な紹介は以下のようになる。
図１は、実施形態によるＥＨＬＯ名およびＩＰアドレスターゲティングにより媒介を通じて電子メール送信者の妥当性を検証できるシステム例を示す図である。 図２は、一実施形態によるサードパーティ配信機構で使用するための電子メールドメイン妥当性検証レコードを作成するプロセス例を示すインタラクション図およびフローチャートである。 図３は、一実施形態によるＤＮＳを用いる電子メールドメイン妥当性検証レコードによる解決についてのプロセス例を示すインタラクション図およびフローチャートである。 図４は、マシン可読媒体から命令を読み取り、かつプロセッサ（またはコントローラ）により命令を実行することのできるマシンの例の構成を示すブロック図である。

図（ＦＩＧＳ．）および以下の説明は、より好ましい実施形態に関する。以下の論議から、本明細書で開示される構造および方法の代替的実施形態は、特許請求される原理から逸脱することなく使用され得る実行可能な代替形態として容易に理解されるはずであることに留意されたい。

いくつかの実施形態、また添付図において示されている例に対して、まず、詳細に言及が行われる。図は、例示のためだけに、開示されるシステム（または方法）の実施形態を示している。当業者であれば、以下の説明から、本明細書で示される構造および方法の代替的実施形態が、本明細書で述べられる原理から逸脱することなく使用され得ることを容易に理解されよう。

構成の概観
例として開示される実施形態は、ＥＨＬＯ名およびＩＰアドレスターゲティングにより、媒介を通じて電子メール送信者の妥当性を検証することのできるシステムおよびプロセスである。実施形態では、ＤＮＳサーバは、受信電子メールシステムから、ＤＮＳサーバに記憶された電子メールドメインに対するＤＮＳ照会を受信し、ＤＮＳ照会は、電子メールの送信者の識別情報を含み、かつ電子メールは、電子メールドメインからのものとしてそれ自体を識別する。ＤＮＳサーバは、ＤＮＳ照会から電子メール送信者の識別情報を抽出し、かつ識別情報から、複数の配信機構の１つを識別する。ＤＮＳサーバは、識別された配信機構が、電子メールドメインに代わって電子メールを配信することが許可されているかどうかを判定する。識別された配信機構が、電子メールドメインに代わって、電子メールを配信することが許可されていると決定したことに応答して、ＤＮＳサーバは、許可された配信機構および電子メールドメインの識別に基づき、ターゲット妥当性検証レコードを生成し、ターゲット妥当性検証レコードは、配信機構が電子メールドメインに対する電子メールの許可された送信者であることを、受信電子メールシステムに示す１または複数のルールを含み、かつＤＮＳ照会に応答して、受信電子メールシステムに、ターゲット妥当性検証レコードを送る。

一実施形態では、送信電子メールシステムは、電子メールドメインのＤＮＳレコードに含めるために、電子メール妥当性検証レコードを作成するように構成され、電子メールドメイン妥当性検証レコードは、ターゲットドメインから電子メールを受信したとき、受信電子メールシステムにより構文解析され、受信電子メールシステムに、電子メールの送信者が、電子メールドメインに対する許可された送信者であるかどうかを示す。電子メールドメイン妥当性検証レコードを作成するために、送信電子メールシステムは、電子メールドメインとは別個のドメインであるターゲットドメインを含むように電子メールドメイン妥当性検証レコードを構成し、電子メールドメイン妥当性検証レコードの構文解析を行うとき、受信電子メールシステムに、妥当性検証レコードを求める第２の要求をターゲットドメインに提出させる。送信電子メールシステムはまた、識別情報を指定する１または複数のマクロ文を含めるように電子メールドメイン妥当性検証レコードを構成し、マクロ文は、受信電子メールシステムに、電子メールドメイン妥当性検証レコードの構文解析を行うとき、電子メールの送信者の識別情報を第２の要求に含めるようにさせる。送信電子メールシステムは、この作成された電子メールドメイン妥当性検証レコードを電子メールドメインのＤＮＳレコードとしてパブリッシュするように構成される。

導入
送信者ポリシーフレームワーク（ＳＰＦ）は、電子メールを認証するための強力なツールであるが、今日使用されるように、構成するのを困難にし、かつ実際には、所与の電子メールドメインに対して電子メールを配信することが認証され得るサービスの数に対して大幅な制限を加えるいくつかの実質的な制限を有する。いくつかの実施形態では、システムおよび方法は、電子メールドメイン所有者が、ａ）ネットワーキングプリミティブではなく、サービスに関するそれらの電子メールドメインのＳＰＦ認証の構成、およびｂ）これらの無制限な数の構成をサポートできる方法を提供することができる。

例示的な主要な代表システム
図１は、実施形態によるＥＨＬＯ名およびＩＰアドレスターゲティングにより媒介を通じて電子メール送信者の妥当性を検証できる例示的なシステム１００を示している。システム１００は、ネットワーク１５０、１または複数のクライアントデバイス１６０、許可するＤＮＳサーバ１３０、ドメイン所有者ＤＮＳサーバ１４０、ドメイン所有者システム１１０、配信電子メールシステム１１５、および受信電子メールシステム１２０を含む。示されたシステム１００は、図１で示された要素を含むが、他の実施形態では、システム１００は、異なる要素を含むこともある。さらに各要素の機能は、他の実施形態における要素の中では異なる形で配分され得る。

有線、無線、またはそれらの組合せとすることのできるネットワーク１５０は、クライアントデバイス１６０、ＤＮＳシステム１３０／１４０、ドメイン所有者システム１１０、およびサードパーティシステム１２０の中で通信を可能にし、かつインターネット、ＬＡＮ、ＶＬＡＮ（例えば、ＶＰＮを有する）、ＷＡＮ、または他のネットワークを含むことができる。一実施形態では、ネットワーク１５０は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、伝達制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、ユニフォームリソースロケータ（ＵＲＬ）、およびドメイン名システム（ＤＮＳ）など、標準の通信技術および／またはプロトコルを使用する。他の実施形態では、エンティティは、上記で述べたものに代えて、またはそれに加えて、カスタムかつ／または専用のデータ通信技術を使用することができる。

ドメイン所有者システム１１０は、特定のドメイン（例えば、ｅｘａｍｐｌｅｃｏｒｐ．ｃｏｍ）の１または複数のコンピューティングシステムを含み、図４を参照して述べられるコンピューティングシステムと同様に構成され得る。

一実施形態では、ドメイン所有者システム１１０は、受信電子メールシステム１２０などの受信電子メールシステムが、ドメイン所有者システム１１０のドメインを電子メールの送信者として示す電子メールの正当性を検証できるようにする妥当性検証ルールを生成するルール作成器１１１を含む。受信電子メールシステム１２０がこのような電子メールを受信したとき、それは、その電子メールが、実際にドメイン所有者システム１１０から正当に送られたかどうかを調べるために、これらの妥当性検証ルールを検査することができる。一実施形態では、ルールは、ドメイン所有者システム１１０のインターネットプロトコル（ＩＰ）アドレスを示し、したがって、受信電子メールシステム１２０は、電子メールが、ルールで示されたＩＰアドレスから受信されたかどうかを検証する。

これらのルールは、検出されたネットワーク特性（例えば、送信電子メールシステムの検出されたＩＰアドレス、ドメイン名情報など）に基づいて自動的に生成され得る、またはユーザインターフェースを介して管理者からルール作成器１１１により受信され得る。ルールが生成された後、ルール作成器１１１は、公開されたアクセス可能な場所で、そのルールをパブリッシュする。この公開されたアクセス可能な場所とは、ドメイン所有者システム１１０のドメインに対するドメイン所有者だけがパブリッシュできる信頼できる場所のことである。その場合、どの受信電子メールシステム１２０も、ルールを取得するためにこの公開の場所にアクセスすることができる、一実施形態では、公開の場所は、ドメイン名システム（ＤＮＳ）である。したがって、これらのルールは、ドメイン所有者ＤＮＳサーバ１４０上の電子メールドメイン妥当性検証レコード１４１に記憶され得る。一実施形態では、ルールは、送信者ポリシーフレームワーク（ＳＰＦ）ルールである（それは、ＲＦＣ４４０８および７２０８で文書化され、本明細書に参照により組み込まれる）。

配信電子メールシステム１１５は、ドメイン所有者システム１１０のために電子メールを送信する。配信電子メールシステム１１５は、図４を参照して述べられるコンピューティングシステムと同様に構成され得る１または複数のコンピューティングシステムを備える。例として、配信電子メールシステム１１５は、メーリングリストサーバ、ドメインに代わって電子メールを送信するバルクメーラプロバイダ、ドメインに代わって電子メールを送るサードバーティにより管理されるトランザクション電子メールシステム、またはドメインに代わって電子メールを走査するセキュリティシステムとすることができる。配信電子メールシステム１１５は、配信電子メールシステム１１５が、電子メールに対してさらなる処理または機能を提供できるように、ドメイン所有者システム１１０に代えて電子メールを送信することができる。

配信電子メールシステム１１５は、電子メールを送るための電子メール送信器１１６を含む。一実施形態では、電子メール送信器１１６は、簡易メール転送プロトコル（ＳＭＴＰ）など、標準のメールプロトコルを使用する。ＳＭＴＰは、様々な機能をサポートする。特に、送信電子メールシステムが、受信電子メールシステムと通信するとき、ＳＭＴＰは、送信電子メールシステムが、受信電子メールシステムに対して、ＨＥＬＯ、または拡張ＨＥＬＯ（ＥＨＬＯ）メッセージを送信できることを示す。このＨＥＬＯ／ＥＨＬＯメッセージは、送信電子メールシステムの識別子（例えば、ドメイン名）を含み、またＥＨＬＯメッセージの場合、送信電子メールシステムのサポートされる拡張および機能を示すさらなる識別子を含むことができる。

最初はドメイン所有者システム１１０により送られたメッセージまたは電子メールを送る、またはその他の形で転送するとき、ドメイン所有者システム１１０に関連付けられた、かつ電子メールドメイン妥当性検証レコード１４１として記憶され得る妥当性検証ルールは、配信電子メールシステム１１５の認証に適応できるように修正される。

受信電子メールシステム１２０は、配信電子メールシステム１１５から、１または複数の電子メールを受信する電子メールシステムである。受信電子メールシステム１２０は、図４を参照して述べられるコンピューティングシステムと同様に構成され得る１または複数のコンピューティングシステムを備える。

受信電子メールシステム１２０は、電子メールを受信するための電子メール受信器１２２を含む。一実施形態では、電子メール受信器１２２は、簡易メール転送プロトコル（ＳＭＴＰ）など、標準的なメールプロトコルを使用する。

受信電子メールシステム１２０は、電子メールが不正なものではないことを保証するために、どの受信された電子メールの送信者の識別も妥当性を検証する電子メール認証器１２１を備える。電子メールを受信すると、電子メール認証器１２１は、（例えば、ＨＥＬＯコマンドにより）電子メールが受信されたサーバにより提供される識別、または電子メールのリターンパスアドレスに示されたドメイン（例えば、「ｇｍａｉｌ．ｃｏｍ」）、もしくは何らかの他の識別子によるドメインのいずれかに関連付けられた任意の関連する電子メールドメイン妥当性検証レコードを調べることができる。電子メール認証器１２１は、送信者のＩＰアドレスなど、電子メールから識別された情報が、関連する電子メールドメイン妥当性検証レコードのいずれか１つに示されたルールのいずれかにマッチするか、それともそれにより許可されるかどうかを判定する。ルールにおいてマッチが見出された場合、電子メール認証器１２１は、電子メールメッセージは有効である可能性が高く、送信者と称されるものからのものであり、不正なソースからのものではないと決定する。

一実施形態では、電子メールドメイン妥当性検証レコードで示されるルールは、ＳＰＦルールである。ＳＰＦルールは、ＩＰアドレスを示すことができ、したがって、電子メール認証器１２１は、ＳＰＦルールで示されたＩＰアドレスが、電子メールを受信電子メールシステム１２０に送ったサーバのＩＰアドレスまたは他の識別情報にマッチするかどうかを検証することができる。ＳＰＦルールはまた、別のドメインを示すことができ、その場合、電子メール認証器１２１は、その別のドメインに対するＳＰＦルールレコードを調べて、そのレコードにおけるいずれかのルールが、電子メールを送ったサーバの識別情報にマッチするかどうかを調べることができる。さらにいくつかの場合、ＳＰＦルールは、電子メール認証器１２１が電子メールの受信時に動的に決定されるデータで置き換える特別のプレースホルダインジケータであるマクロをサポートする。例えば、電子メール認証器１２１は、電子メールのリターンパスドメイン（例えば、「ａｃｍｅ．ｃｏｍ」）に対するルールで示される「％｛ｄ｝」などのマクロを拡張することができる。さらなるマクロコマンドは、ＳＰＦ ＲＦＣ７２０８、および４４０８でさらに詳細に述べられる。

ＤＮＳサーバ１３０および１４０は、ＤＮＳシステムで使用するためのＤＮＳレコードを記憶する。各ＤＮＳサーバは、図４を参照して述べられるコンピューティングシステムなどの１または複数のコンピューティングシステムを備えることができる。

各ＤＮＳサーバは、当技術分野で知られているように、Ａレコード、ＭＸレコード、以下同様のものなど、特定のドメインに対して複数のＤＮＳレコードを記憶することができる。レコードは、図１で示されているように、複数のエントリへと分離され、複数のサーバ上にあるが、他の実施形態では、レコードは、より少ないエントリ、単一のサーバ、単一のエントリに、または何らかの他の組合せへと組み合わされる。さらに、各ドメインに対して一定数のレコードが図１で示されているが、他の実施形態では、各ドメインは、複数のレコードを有することができる。

図１で示されるように、ドメイン所有者ＤＮＳサーバ１４０は、電子メールドメイン妥当性検証レコード１４１を含む。この電子メールドメイン妥当性検証レコード１４１は、受信電子メールシステム１２０が、受信した電子メールの正当性の妥当性を検証できるようにする１または複数のルールを含むことができる。上記で述べたように、電子メールドメイン妥当性検証レコード１４１は、ドメインに関連付けられた送信者に関するＩＰアドレスまたは他の識別子を示すことができ、したがって、受信電子メールシステム１２０は、電子メールの送信者のＩＰアドレス（または他の識別子）が、電子メールで示されたドメインに対応している（例えば、「ａｃｍｅｂａｎｋ．ｃｏｍ」からの電子メールが、実際にＡｃｍｅ Ｂａｎｋからのものである）ことを検証することができる。しかし、このような簡単なルールは、サードパーティの配信電子メールシステム１１５が、送信電子メールシステムもしくはドメイン所有者の代わりにメールを送るために使用される場合は、不利になり得る。これは、電子メールドメイン妥当性検証レコード１４１におけるルールは、配信電子メールシステム１１５が特定のドメインに対する有効な送信者であることを示さない可能性があるためである。

それに代えて、電子メールドメイン妥当性検証レコード１４１は、別個のドメインを有するルールを含めることができる。この別個のドメインに対するＤＮＳレコードは、許可するＤＮＳサーバ１３０上など、どこか他に存在することができる。さらに、別個のドメインを用いるこのルールはまた、１または複数のマクロを含み、受信電子メールシステム１２０により構文解析されたとき、受信電子メールシステム１２０に、受信電子メールシステム１２０が電子メールを受信したサーバを識別するさらなる情報、または電子メールに関する他の識別情報でマクロを置き換えさせる。一実施形態では、この情報は、受信電子メールシステム１２０が電子メールを受信したサーバからのＥＨＬＯメッセージにおけるいずれかの識別子、ならびに同じサーバのＩＰアドレスを含む。ルールが構文解析された後、受信電子メールシステム１２０は、ルールで示された別個のドメインのＤＮＳレコードをルールにより照会する。例えば、ルールは、「％｛ｉ｝．＿ｉｐ．ｖｅｒｉｆｉｅｒ．ｃｏｍ」のマクロを備えるドメインを示すことができる。拡張された後、マクロ「％｛ｉ｝」は、受信電子メールシステム１２０に電子メールを送ったサーバ（例えば、これは配信電子メールシステム１１５になり得る）のＩＰアドレスにより置き換えられることができ、また受信電子メールシステム１２０は、ドメイン「ｖｅｒｉｆｉｅｒ．ｃｏｍ」のＤＮＳレコードを求めて照会し、ＩＰアドレスを、問題のＤＮＳレコードを提供できるＤＮＳサーバに渡す。

この別個のドメインに対するＤＮＳレコードは、許可するＤＮＳサーバ１３０に存在することができる（またはそこに照会され得る）。許可するＤＮＳサーバ１３０は、配信電子メールシステムに関する情報、ならびにそれらの関連するＩＰアドレスおよびＥＨＬＯ情報を記憶する配信者／ＩＰ記憶装置１３１を含む。許可するＤＮＳサーバ１３０はまた、様々な配信電子メールシステムを認証するルールを記憶する配信者／レコード記憶装置を含む。許可するＤＮＳサーバ１３０はまた、様々なドメインに対して許可された配信電子メールシステムを示す許可された配信者リスト１３２を含む。

上記で述べられたように、電子メールを送ったサーバの識別情報によりマクロが置き換えられると、ドメイン情報が、ＤＮＳ照会で受信電子メールシステム１２０から、許可するＤＮＳサーバ１３０により受信される。許可するＤＮＳサーバ１３０は、識別情報で示されたサーバが、識別情報で示されたドメインのために電子メールを送ることが許可されるかどうかを判定する許可評価器１３５を含む。一実施形態では、ドメインは、許可するＤＮＳサーバ１３０に（マクロを使用することにより）渡されるＥＨＬＯ情報から示され、またサーバに関する識別情報は、ＩＰアドレスにより渡される。許可評価器１３５は、識別情報に関連付けられた配信電子メールシステム１１５の識別を決定するために、配信者／ＩＰ記憶装置１３１にアクセスする。このような情報が見出された場合、許可評価器は、その配信電子メールシステムが、ＤＮＳ照会の識別情報で示されたドメインに対する許可された配信エージェントであるかどうかを判定するために、許可された配信者リスト１３２にアクセスする。

そうである場合、許可するＤＮＳサーバ１３０は、受信電子メールシステム１３０への（送信するための）応答として配信者／レコード記憶装置１３４を用いてルールのセットを構成するターゲットレコード構成器１３３を含む。この構成されたルールのセットは、電子メールを送った配信電子メールシステム（例えば、配信電子メールシステム１１５）が、電子メールで示されたドメインに対して有効な送信者であることを示す。受信電子メールシステム１３０は、次いで、その応答における情報を使用して、配信電子メールシステムが有効な送信者であり、この電子メールをその意図された受取人により受信され得ることを検証することができる。その他の場合、配信電子メールシステムがその応答により有効ではないことが示された場合、受信電子メールシステム１３０は、それに代えて電子メールを破棄する、またはそれにフラグを付けることができる。

クライアントデバイス１６０は、受信電子メールシステム１２０により受信され、かつ認証された電子メールを見るために使用され得る。クライアントデバイス１６０は、図４を参照して述べられるコンピューティングシステムなど、コンピューティングシステムを備えることができる。

具体的には、クライアントデバイス１６０は、受信電子メールシステム１２０とインターフェースを取るための電子メールクライアント１６５を含む。電子メールクライアント１６５は、受信電子メールシステム１２０と通信するために、ポストオフィスプロトコル３（ＰＯＰ３）、インターネットメッセージアクセスプロトコル（ＩＭＡＰ）、メッセージングＡＩＰ（ＭＡＩＰ）、ＳＭＴＰ、以下同様のものなどの標準の電子メールプロトコルを使用することができる。一実施形態では、電子メールが、受信電子メールシステム１２０により適正に認証されない場合、電子メールクライアント１６５は、電子メールを受信することはない。他の実施形態では、電子メールクライアント１６５は、電子メールを受信できるが、さらに電子メールは不正なものであることが疑われる、または疑わしいとの指示を受け取ることができる。

上記で述べたシステム１００を使用すると、ドメインの所有者は、電子メールを送信するために、他のサードパーティ配信機構、およびそれらの配信電子メールシステムのサービスを利用することができ、かつさらに、受信電子メールシステム１２０に、これらの電子メールが正当なものであるとの妥当性を検証させることができる。様々な電子メールドメイン妥当性検証レコードを更新することに代えて、ＤＮＳサーバは、集中化された場所において、電子メールを送った配信電子メールシステム１１５に関する、受信電子メールシステム１２０から受信された識別情報に応じて、簡単なルールのセットを構成することができる。さらに受信電子メールシステム１２０は、電子メールドメイン妥当性検証レコードにおけるルールに存在する可能性のある多数のＤＮＳレコードに照会する必要がない。こうすることは、性能を向上させ、かつサードパーティエージェントによる電子メールを送ることの管理を簡単化するが、なお、セキュリティを提供し、かつ不正な、または疑わしいメッセージが受信されるのを阻止する。上記で述べたシステムおよび処理に関するさらなる詳細は、図２〜図３を参照して述べられる。

電子メールドメイン妥当性検証レコード作成に関する例示的な対話図
図２は、一実施形態によるサードパーティ配信機構で使用するための電子メールドメイン妥当性検証レコードを作成する例示的なプロセスを示す対話図および流れ図である。一実施形態では、図２は、プロセス中のオペレーションを、示された要素に帰属させる。しかし、ステップのいくつか、またはすべてのものは、他の要素により実施され得る。加えて、いくつかの実施形態は、オペレーションを並列に実施する、オペレーションを異なる順序で実施する、または異なるオペレーションを実施することもあり得る。さらに、例示的な一実施形態では、ステップおよび／またはモジュールは、図４に関して述べられるプロセッサ４０２により実行され得る、例えば、命令４２４などの命令として実施され得ることに留意されたい。

この論議において、電子メールドメインとは、着信する電子メールメッセージに対してＳＰＦを評価するとき、受信電子メールシステム１２０が、「ドメイン」として使用できる任意のドメインを指すことになる。通常、これは、メッセージに対するリターンパスで見出されるドメインとなる。

電子メールドメイン所有者、または指定されたパーティであるドメイン所有者システム１１０は、電子メールドメインに対するＤＮＳレコードを構成することができる。これは、電子メールドメインで使用するための電子メールドメイン妥当性検証レコード１４１（ＳＰＦレコードであり得る）を作成する（または生成する）２１０ことを含むことができる。レコードは、特定の送信者が、電子メールドメインからの電子メールに対する有効な送信者であることを示す。一実施形態では、レコードは、ＳＰＦレコードであり、かつ特有の「ｉｎｃｌｕｄｅ」ディレクティブを組込むことができるように構成される。ｉｎｃｌｕｄｅディレクティブは、別のドメインを示すターゲテッドＳＰＦドメイン仕様（specification）を示すことができ、したがって、メッセージに対するＳＰＦ認証決定のいくつか、またはすべては、他のドメインで見出されるＳＰＦレコードへと遅延される（deferred）。言い換えると、前述のように、レコードは、最終的なＳＰＦ認証情報を決定するために別々に照会される別個のドメインを含む。

一実施形態では、電子メールドメイン妥当性検証レコード１４１におけるターゲテッドＳＰＦドメイン仕様は、そのメッセージに関するＳＭＴＰ接続属性に基づき、電子メールメッセージに対する挙動を動的に変更するように構成され得る。この変更は、受信サーバに、ＳＭＴＰ接続属性および電子メールドメインを使用させて、解決されたとき、処理されるメッセージに適用されるターゲット設定化ＳＰＦレコードを生ずるカスタムのドメイン名を構築することにより達成され得る。

これを達成するために、一実施形態では、ターゲテッドＳＰＦドメイン仕様は、３つの特性を含むことができる。第１に、それは、ターゲテッドＳＰＦドメイン仕様から解決されるいずれのドメイン名に対する最終的な権限を有するものは、ターゲテッドＤＮＳ ＳＰＦリゾルバ（例えば、許可するＤＮＳサーバ１３０）である。

これは、ターゲテッドドメイン仕様が、最終的、１または複数の特定の固定ドメインのサブドメインに分解されることを保証することにより達成され得る。いくつかの実装形態では、ターゲテッドＳＰＦドメイン仕様を含むＤＮＳレコードは、他のドメインを参照する１または複数のＤＮＳ ＣＮＡＭＥまたはＮＳレコードの背後に隠すことができ、ターゲテッドＤＮＳ ＳＰＦリゾルバにより管理されない。これは、最終的なＤＮＳ照会ターゲットの転送またはマスキングを可能にする。言い換えると、他のドメインは、最終的なＤＮＳ照会ターゲットが決定される前に、受信電子メールシステムにより照会される必要があり得る。

第２に、ターゲテッドＳＰＦドメイン仕様は、受信電子メールシステム１２０に、ＳＭＴＰ接続に対するＥＨＬＯ名および／またはＩＰアドレスを取り込むようにさせることができる。これらの値は、ＳＰＦマクロシステムを用いて取り込まれ得る。％｛ｈ｝マクロは、ＥＨＬＯ名を取り込むために使用することができ、また％｛ｉ｝または％｛ｐ｝マクロは、ＩＰアドレス、またはＩＰアドレスの妥当性が検証されたドメイン名を取り込むために使用することができる。いくつかの実施形態では、ドメイン所有者システム１１０はまた、受信電子メールシステム１２０に、％｛ｌ｝および／または％｛ｓ｝マクロを用いて、送信者アドレスのローカルパート、または完全な送信者アドレスを取り込ませて、得られた値をターゲテッドＳＰＦドメイン仕様へと符号化するように、ターゲテッドＳＰＦドメイン仕様を構成することができる。

システムの正確な構成に応じて、ＳＰＦマクロ言語で記述された任意選択の変換器の１または複数のものが、ターゲテッドＳＰＦドメイン仕様に適用され得る。同様に、結果が符号化されたＵＲＬであるように、大文字の変形体％｛Ｈ｝、％｛Ｉ｝、％｛Ｐ｝、％｛Ｌ｝、または％｛Ｓ｝をそれに代えて使用することができる。

第３に、ターゲテッドＳＰＦドメイン仕様は、ＳＭＴＰ接続属性が、得られたドメインから明瞭に構文解析され得るように構成することができ、それは、実際に、現実世界のシステムに対して達成され得る。

これを示すために、これらの３つの要件を満たすターゲテッドＳＰＦドメイン仕様に対するフォーマットが構成され得る。例えば、ターゲテッドＤＮＳ ＳＰＦリゾルバ（例えば許可するＤＮＳサーバ１３０）は、ドメイン「ｒｅｓｏｌｖｅｒ．ｃｏｍ」により定義されるゾーンにおけるすべてのＤＮＳ ＴＸＴ照会に対応するものと仮定する。さらに、電子メールドメインは、「ｅｍａｉｌｄｏｍａｉｎ．ｃｏｍ」であると仮定する。最後にＥＨＬＯ名とＩＰアドレスの両方が取り込まれると仮定する。

この場合、ホスト名に対して、文字−数字−ハイフン（ＬＤＨ）ルールが使用され得る。これらのルールは、完全修飾ドメイン名（ＦＱＤＮ）が、ＡＳＣＩＩ文字、数字、またはハイフン記号だけを含むことのできる制限を含む。より一般的には、ＳＰＦレコード参照で使用されるものを含むドメインは、この制限を満たす必要はない。ＥＨＬＯ名と電子メールドメインは共にＦＱＤＮであることが必要なので、「＿」などの非ＬＤＨ記号を含むラベルを用いてターゲテッドＳＰＦドメイン仕様を作成する場合、これらのフィールドは、ドメイン所有者システム１１０により分離され得る。ＩＰアドレスは、数字（ＩＰｖ４）から、または数字および文字ａ〜ｆ（ＩＰｖ６）からだけ構成され得るので、ＩＰアドレスを含むラベルも「＿」を含むことはできない。したがって、「＿」を含むラベルは、同様に、これらの値に対する分離文字として使用され得る。

上記の内容のすべてを組み合わせると、例示的なコンテキストに含まれる要件を満たす１つのターゲテッドＳＰＦドメイン仕様は、「％｛ｉ｝．＿ｉｐａｄｄｒ．％｛ｈ｝．＿ｅｈｌｏ．ｅｍａｉｌｄｏｍａｉｎ．ｃｏｍ．＿ｔｓｐｆ．ｒｅｓｏｌｖｅｒ．ｃｏｍ」である。このドメイン仕様からのＳＰＦプロセス中に補間されたいずれのドメイン名も、「ｒｅｓｏｌｖｅｒ．ｃｏｍ」（右端に示されているドメイン）に基づくことになる。それは、ドメイン名にＥＨＬＯ名とＩＰアドレスを共に含む。さらに、「＿」を含むラベルの使用は、このようなドメイン名から、ＳＭＴＰ属性の明瞭な構文解析をサポートする。

これらの要件を満たす可能性のあるフォーマットは多数あり、この特定の例は、非限定的なものであると見なされるべきであることに留意されたい。

その場合、電子メールドメイン妥当性検証レコード１４１は、上記で述べたターゲテッドＳＰＦドメイン仕様を参照するｉｎｃｌｕｄｅディレクティブを有するＳＰＦルールを有するべきである。上記で述べた例示的なターゲテッドＳＰＦドメイン仕様を使用するこのようなレコードの簡単な、非限定的な例は、「ｖ＝ｓｐｆ１ ｉｎｃｌｕｄｅ：％｛ｉ｝．＿ｉｐａｄｄｒ．％｛ｈ｝．＿ｅｈｌｏ．ｅｍａｉｌｄｏｍａｉｎ．ｃｏｍ．＿ｔｓｐｆ．ｒｅｓｏｌｖｅｒ．ｃｏｍ」である。再度、このレコードは、我々の例に関して現実的なものであるが、非限定的なものであると見なされるべきである。「ｖ」は、ＳＰＦバージョンを指すこと、またｉｎｃｌｕｄｅディレクティブは、示されたドメインが電子メールドメインに対して有効な送信者であることを示していることに留意されたい。

電子メールドメイン妥当性検証レコード１４１が構成された後、それは、電子メールドメインに対するＤＮＳ ＴＸＴレコードとして（例えば、ドメイン所有者ＤＮＳサーバ１４０で）パブリッシュされ得る２１５。これは、このドメインを示す電子メールを受信する任意のサーバにより照会できるようにする。

電子メール検証ルール解決に関する例示的な対話図
図３は、一実施形態によるＤＮＳを用いる電子メールドメイン妥当性検証レコードの解決のための例示的プロセスを示す対話図および流れ図である。一実施形態では、図３は、プロセス中のオペレーションを、示された要素に帰属させる。しかしステップのいくつかまたはすべては、他の要素により実施され得る。加えて、いくつかの実施形態は、オペレーションを並列に実施する、オペレーションを異なる順序で実施する、または異なるオペレーションを実施することもあり得る。さらに、例示的な一実施形態では、ステップおよび／またはモジュールは、図４に関して述べられるプロセッサ４０２により実行され得る、例えば、命令４２４などの命令として実施され得ることに留意されたい。本明細書で述べられるプロセスは、受信電子メールシステム１２０の何らかのさらなる変更、または構成を必ずしも必要としないことに留意されたい。そうではなくて、受信電子メールシステム１２０がＳＰＦまたは同様の送信者認証方式をサポートする限り、それは、変更される必要はない。

最初に、受信電子メールシステム１２０は、特定の電子メールドメインに対応するリターンパスを備えた電子メールを受信する３１０。受信電子メールシステム１２０は、この電子メールメッセージを（例えば、ＳＰＦを用いて）認証しようと試みることができる。受信電子メールシステム１２０は、まず、その電子メールドメインに対する何らかの電子メール妥当性検証レコードに関してＤＮＳに照会することができる３１５。これらのものは、ＳＰＦレコードとすることができる。ドメイン所有者ＤＮＳサーバ１４０は、図２を参照して述べたように、電子メールドメインの所有者がパブリッシュしている電子メールドメイン妥当性検証レコード１４１を応答で返すことができる２８２。

受信電子メールシステム１２０は、電子メール妥当性検証レコードを構文解析して、ターゲットドメイン照会を生成する３２０。このプロセスは、現在のＳＭＴＰ接続に対する値（例えば、ＥＨＬＯ、ＩＰアドレス）を用いて、返されたＤＮＳレコードにおけるターゲットドメインＳＰＦ仕様を有するｉｎｃｌｕｄｅディレクティブを評価すること、およびターゲットドメインを構成するために、ターゲットドメインＳＰＦ仕様の中にこれらの値を補間することを含むことができる。例えば、レコードが、「％｛ｉ｝．＿ｉｐａｄｄｒ．％｛ｈ｝．＿ｅｈｌｏ．ｅｍａｉｌｄｏｍａｉｎ．ｃｏｍ．＿ｔｓｐｆ．ｒｅｓｏｌｖｅｒ．ｃｏｍ」のルールを示した場合、受信電子メールシステム１２０は、これを、「１２３．１２３．１２３．１２３．＿ｉｐａｄｄｒ．ｄｅｌｉｖｅｒｉｎｇｄｏｍａｉｎ．ｃｏｍ．＿ｅｈｌｏ．ｅｍａｉｌｄｏｍａｉｎ．ｃｏｍ．＿ｔｓｐｆ．ｒｅｓｏｌｖｅｒ．ｃｏｍ」へと評価することができるが、１２３．１２３．１２３．１２３は、送信者のＩＰアドレス、ｅｍａｉｌｄｏｍａｉｎ．ｃｏｍは、発信元の送信者のドメインであり、またｄｅｌｉｖｅｒｉｎｇｄｏｍａｉｎ．ｃｏｍは、送信者に対するＥＨＬＯメッセージで示されたドメイン名である。

受信電子メールシステム１２０は、次いで、ターゲットドメインをＤＮＳに照会する３２５。この照会は、許可するＤＮＳサーバ１３０（ターゲットドメインに対する権威サーバとすることができる）により応ずることができる。ドメイン所有者ＤＮＳサーバ１３０は、照会から識別情報を抽出する３４０．この識別情報は、ＥＨＬＯ名およびＩＰアドレスを含むことができ、またターゲットドメイン照会から構文解析され得る。一実施形態では、ドメイン所有者ＤＮＳサーバ１３０はまた、スタンドアロンの値として、または符号化された完全な送信者アドレスの一部として、照会のターゲットドメインからのリターンパスアドレスのローカルパートを構文解析することができる。

一実施形態では、ドメイン所有者ＤＮＳサーバ１３０はまた、ターゲットドメイン照会から電子メールドメインを抽出する（それがマクロにより照会中に含まれている場合）。電子メールドメインが存在する場合、かつドメイン所有者ＤＮＳサーバ１３０が限定されたドメインのセットに対する要求だけを処理するように構成されている場合、ドメイン所有者ＤＮＳサーバ１３０は、電子メールドメインが既知であるかどうかを判定することができる。この場合において、その電子メールドメインが既知ではない場合、ドメイン所有者ＤＮＳサーバ１３０は、デフォルトＳＰＦレコードを返すことができる。返されたレコードは、どのＩＰアドレスも認めないレコードである可能性が高く、例は「ｖ＝ｓｐｆ１−〜ａｌｌ」となる。

ドメイン所有者ＤＮＳサーバ１３０は、照会から抽出された識別情報を使用して、配信機構を識別する３４５。配信機構は、配信電子メールシステム１１５の所有者であり、それは電子メールドメインの一部ではない可能性がある。ドメイン所有者ＤＮＳサーバ１３０は、電子メールメッセージのＳＭＴＰ接続に関連付けられたネットワーク特有の情報（例えば、ＥＨＬＯ名および／または送信サーバＩＰアドレス）が、配信機構の高レベルの抽象化に関連付けられ得るように、照会から抽出された識別情報を配信機構に関連付ける配信者／ＩＰ記憶装置１３１を含む。

一般的な配信機構のいくつかの例は、電子メールドメイン所有者により、電子メールを送るように契約したサードパーティ送信者、電子メールドメインから発信されたメッセージをいくつかの受信アドレスに中継しているメーリングリスト、または１つの受信器アドレスに別名を付けるように設計された転送システムである。この例のセットは網羅的なものと見なすべきではなく、リストは、非限定的なものであると見なされるべきである。

一実施形態では、電子メールの実質的な（すなわち、統計的に有意な）コーパス（何億またはそれ以上のメッセージ）のヘッダ情報へのアクセスは、ドメイン所有者ＤＮＳサーバ１３０または他のエンティティに、電子メールヘッダ（特に「受信された」および「認証結果」ヘッダ）で見出された情報を用いることにより、配信者／ＩＰ記憶装置１３１を構成できるようにする。他の実施形態では、配信機構のリストを調べて、その結果を適切な配信者／ＩＰ記憶装置１３１へと組込むこともできる。さらなる実施形態では、特にＷＨＯＩＳデータベースに記憶された情報であるドメイン登録レコードは、配信者／ＩＰ記憶装置１３１に対するこのマッピングを構築するのに有用であり得る。これらの例示的な方法は、非限定的なものと見なされるべきであり、また本明細書で述べられるプロセスは、配信者／ＩＰ記憶装置１３１を構成するために、他の方法、または複数の方法の組合せの使用を排除するものではない。

さらなる実施形態では、ドメイン所有者ＤＮＳサーバ１３０により受信されたＤＮＳ照会の着信ストリームは、調査を必要とするＥＨＬＯ名およびＩＰアドレスのソースとして使用され得る。完全なデータベースのために、正当な電子メールから発信されたすべての（ＥＨＬＯ名およびＩＰアドレス）の組合せは、既知の配信機構にマップされるべきである。既知の配信機構にマップされることのできないいずれの着信データも、一般に、ａ）データベースにおける失われた正当な値、またはｂ）不正なソース電子メールを示すことができる。この「失われている（ｍｉｓｓ）」は、したがって、データベースにおけるギャップを埋めるための情報源として、または脅威情報源として働くことができる。

要求が配信機構にマップされた後、一実施形態では、ドメイン所有者ＤＮＳサーバ１３０は、配信機構が既知のものであるかどうかを判定することができる３４８。既知ではない場合、すべてのＩＰアドレスが不適切であるＳＰＦレコードに関するいくつかの変形など、デフォルトのレコードを返すことができる。例えば、「ｖ＝ｓｐｆ１〜ａｌｌ」は、可能性のある選択肢である。

配信機構が既知であると仮定すると、ドメイン所有者ＤＮＳサーバ１３０は、ターゲットドメインに関する照会で示された電子メールドメインに対して、配信機構が電子メールを配信することが許可されるかどうかを判定することができる３５０。一実施形態では、ドメイン所有者ＤＮＳサーバ１３０は、どの識別された配信機構も、任意の電子メールドメインに対して電子メールを配信できるようにする。他の実施形態では、許可された配信機構に対する電子メールドメインのマッピングは、許可された配信者リスト１３２に記憶される、またはウェブＡＰＩを介して利用可能にされることもでき、またドメイン所有者ＤＮＳサーバ１３０は、配信機構が許可されるかどうかを判定するためにそのリストもしくはＡＰＩにアクセスする。

識別された配信機構が、電子メールドメインに対して許可されることが見出されない場合、ドメイン所有者ＤＮＳサーバ１３０は、デフォルトレコードを返すことができる。概して、これは、すべてのＩＰアドレスに対する配信を拒否するレコードとすることができる（例えば、「ｖ＝ｓｐｆ１〜ａｌｌ」）。

上記で述べたように、一実施形態では、リターンパスアドレスのローカルパートは、スタンドアロンの値として、または送信者アドレスの一部として、ターゲットドメインの照会中に符号化されている可能性がある。これらの実施形態では、ドメイン所有者ＤＮＳサーバ１３０は、配信機構が、特定のメッセージを配信することが許可されるかどうかを判定するために、電子メールドメインと組み合わせて、電子メールアドレスのローカルパートを使用する。例えば、配信機構は、ａｃｍｅ．ｃｏｍにおける従業員の電子メールアドレスを示すローカルパートを有するリターンパスアドレスのためではなく、「ｎｅｗｓｌｅｔｔｅｒ＠ａｃｍｅ．ｃｏｍ」のためにメールを送ることが許可され得る。

配信機構が、電子メールドメインに対する電子メールを配信することが許可された場合、ドメイン所有者ＤＮＳサーバ１３０は、配信機構および電子メールドメインに基づき、ターゲット妥当性検証レコード（ＳＰＦレコードとすることができる）を生成する３５５。このレコードを構成するために、ドメイン所有者ＤＮＳサーバ１３０は、配信機構のターゲット妥当性検証レコードへのマップを含む配信者／レコード記憶装置１３４に照会することができる。

各配信機構に対して、その配信機構（例えば、配信電子メールシステム１１５）により使用されるサーバからの電子メールを可能にし、いずれかの他から発信された電子メールを拒否することになる何らかの仮想的な電子メール妥当性検証レコードが存在することができる。配信機構に対して、既存の電子メールドメイン妥当性検証レコードが使用され得るので、このことは、適正に構成された電子メールドメイン妥当性検証レコード（例えば、ＳＰＦレコード）を有するいずれの配信機構に対しても当てはまるべきである。

配信機構が、適正に構成された電子メールドメイン妥当性検証レコードを有していない場合であっても、ドメイン所有者ＤＮＳサーバ１３０または管理者は、基礎となるネットワーク構成の十分な知識が与えられると、このようなレコードを構築することが可能である。一実施形態では、ドメイン所有者ＤＮＳサーバ１３０は、配信機構に対する、および／または配信機構によりその他の形で利用可能ではない電子メールドメインに対する電子メールドメイン妥当性検証レコードを作成し、かつ記憶する。

いくつかの実施形態では、またいくつかの構成に対して、配信者／レコード記憶装置１３４はまた、配信機構の関連付けに対する置換え、または捕捉として、電子メールドメインおよび／またはローカルパスを、ターゲット妥当性検証レコードと関連付ける。このような変形形態が望ましい可能性のある例として、電子メールドメインにより、メールサーバのそのクラウドをさらに分割する配信機構を考える。このような状況においては、最適なターゲット妥当性検証レコードを配信するために、配信機構と組み合わせて、電子メールドメインを知ることが必要になり得る。

いくつかの実施形態では、既存の電子メールドメイン妥当性検証レコードは、配信者／レコード記憶装置１３４を構成するための重要な情報源とすることができる。例えば、ＳＰＦレコードの場合、配信機構に対する既存のレコードは、ディレクティブのリストを得るために使用され得る。他の実施形態では、配信機構の手動の調査はまた、この情報の良好なソースとすることができる。さらなる実施形態では、ソースの組合せを使用するさらなる方法がまた実行可能である。ここに列挙したソースは、非限定的なものであると見なされるべきである。

配信者／レコード記憶装置１３４を構成するために、これらの、またはいずれか他の方法を使用する場合、その基礎となるネットワーク構成は時間と共に変化するので、データを更新することが必要になり得る。いくつかの実施形態では、ドメイン所有者ＤＮＳサーバ１３０は、配信者／レコード記憶装置１３４を更新するために、ポーリングメカニズムを使用することができるが、他の実施形態では異なる。このようなポーリングメカニズムの非限定的な例は、既知の送信者によりパブリッシュされたＤＮＳレコードに対する更新を検出するために、定期的に（例えば、毎日）ＤＮＳ照会を実行するドメイン所有者ＤＮＳサーバ１３０上のソフトウェア構成要素となるはずである。これらの更新は、次いで、ドメイン所有者ＤＮＳサーバ１３０によりデータベースの中に組み込まれ得る。

ターゲット妥当性検証レコードを生成した後、ドメイン所有者ＤＮＳサーバ１３０は、レコードを、元の照会への応答として、受信メールシステム１２０に送り返す３６０。

受信メールシステム１２０は、受信されたターゲット妥当性検証レコードを用いて電子メールメッセージを認証する３３０。

一実施形態では、上記で述べたように、ＳＰＦの「ｉｎｃｌｕｄｅ」メカニズムを使用することに代えて、本明細書で述べるシステムは、ＳＰＦの一部である「ａ」、「ｍｘ」、または「ｅｘｉｓｔｓ」メカニズムを使用するように構成され得る。これらのメカニズムの１つが使用される場合、電子メールドメイン所有者の挙動は、ほとんど不変であり得る、すなわち、「ａ」、「ｍｘ」、または「ｅｘｉｓｔｓ」メカニズムは、この場合、「ｉｎｃｌｕｄｅ」メカニズムの代わりに置き換えるだけである。

この変形形態の下では、ドメイン所有者ＤＮＳサーバ１３０の挙動は、その返す値を除き、大部分変化しない。ドメイン所有者ＤＮＳサーバ１３０が、メッセージは認証されないことを示す場合、ドメイン所有者ＤＮＳサーバ１３０は、ＮＸＤＯＭＡＩＮコードを返すことができる。またターゲット妥当性検証レコードを返す代わりに、許可するＤＮＳサーバ１３０は、ターゲット妥当性検証レコードに対してＩＰアドレスをマッチさせることができる。ＩＰアドレスがそのレコードにマッチしない場合、ドメイン所有者ＤＮＳサーバ１３０は、ＮＸＤＯＭＡＩＮを返すことができる。あるいは、ＩＰアドレスがマッチすることが見出された場合、ドメイン所有者ＤＮＳサーバ１３０は、Ａ、ＭＸ、またはＩＰアドレスを含むＡレコードを返すことができる。

一実施形態では、ドメイン所有者ＤＮＳサーバ１３０は、遠隔のＳＰＦ監査ツールとして使用される。ＳＰＦ解決は、受信電子メールシステム１２０上で行われ、したがって、その評価の結果は、専用のソフトウェアがインストールされない限り、概して、外部の監査システムで利用可能にはなり得ない。ターゲテッドＳＰＦドメイン仕様が、ＥＨＬＯ名とＩＰアドレスの両方を含むように構造化されている場合、ドメイン所有者ＤＮＳサーバ１３０は、メッセージがそこから配信される各（ＥＨＬＯ名、ＩＰアドレス）組合せに対して少なくとも１回呼び出され得る。この情報を用いて、リゾルバは、受信電子メールシステム１２０により実施されるＳＰＦ評価をミラーリングし、対応する結果を記録することができる。

例示的なマシンアーキテクチャ
図４は、マシン可読媒体から命令を読み取り、かつプロセッサ（またはコントローラ）で命令を実行することのできる例示的なマシンの構成要素を示すブロック図である。具体的には、図４は、マシンの図式的な表現を、コンピュータシステム４００の例示的な形態で示している。コンピュータシステム４００は、マシンに、本明細書で述べられた方法（またはプロセス）のうちの任意の１または複数のものを実施させるための命令４２４（例えば、プログラムコードまたはソフトウェア）を実行するために使用され得る。代替的実施形態では、マシンは、スタンドアロンのデバイスとして、または他のマシンに接続される接続された（例えば、ネットワーク化された）デバイスとして動作する。ネットワーク化された展開において、マシンは、サーバ／クライアントネットワーク環境におけるサーバマシンまたはクライアントマシンの役割で、またはピアツーピア（もしくは分散された）ネットワーク環境におけるピアマシンとして動作することができる。

マシンは、サーバコンピュータ、クライアントコンピュータ、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、セットトップボックス（ＳＴＢ）、スマートフォン、モノのインターネット（ＩｏＴ）機器、ネットワークルータ、スイッチもしくはブリッジ、またはそのマシンにより行われるアクションを指定する命令４２４を（順次に、またはその他の形で）実行できる任意のマシンとすることができる。さらに、単一のマシンだけが示されているが、用語「マシン」はまた、個々に、または共同で命令４２４を実行して、本明細書で論じられる方法の任意の１または複数のものを実施するマシンの任意の集合体を含むように解釈されるべきである。

例示的なコンピュータシステム４００は、１または複数の処理ユニット（一般的に、プロセッサ４０２）を含む。プロセッサ４０２は、例えば、中央演算処理装置（ＣＰＵ）、グラフィックス処理装置（ＧＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、状態マシン、１または複数の特定用途向けＩＣ（ＡＳＩＣ）、１または複数の高周波集積回路（ＲＦＩＣ）、またはこれらの任意の組合せである。コンピュータシステム４００はまた、主メモリ４０４を含む。コンピュータシステムは、記憶ユニット４１６を含むことができる。プロセッサ４０２、メモリ４０４、および記憶ユニット４１６は、バス４０８を介して通信する。

さらにコンピュータシステム４０６は、スタティックメモリ４０６、ディスプレイドライバ４１０（例えば、プラズマディスプレイパネル（ＰＤＰ）、液晶ディスプレイ（ＬＣＤ）、またはプロジェクタを駆動するためのもの）を含むことができる。コンピュータシステム４００はまた、英数字入力デバイス４１２（例えば、キーボード）、カーソル制御デバイス４１４（例えば、マウス、トラックボール、ジョイスティック、モーションセンサ、または他の指示機器）、信号生成デバイス４１８（例えば、スピーカ）、およびネットワークインターフェースデバイス４２０を含むことができ、それらはまた、バス４０８を介して通信するように構成される。

記憶ユニット４１６は、本明細書で述べられる方法または機能の任意の１または複数のものを実施する命令４２４（例えば、ソフトウェア）が記憶されるマシン可読媒体４２２を含む。命令４２４はまた、完全に、または少なくとも部分的に、主メモリ４０４内に、またはコンピュータシステム４００によるその実行中にはプロセッサ４０２内に（例えば、プロセッサのキャッシュメモリ内に）常駐することができ、主メモリ４０４およびプロセッサ４０２はまた、マシン可読媒体を構成する。命令４２４は、ネットワークインターフェースデバイス４２０により、ネットワーク４２６を介して送信または受信され得る。

マシン可読媒体４２２が、例示的な実施形態で、単一の媒体であるように示されているが、用語「マシン可読媒体」は、命令４２４を記憶できる単一の媒体、または複数の媒体（例えば、集中化された、もしくは分散されたデータベース、または関連するキャッシュおよびサーバ）を含むものと解釈されるべきである。用語「マシン可読媒体」はまた、マシンにより実行するための、かつ本明細書で開示される方法の任意の１または複数のものをマシンに実施させる命令４２４を記憶できる任意の媒体を含むように解釈されるべきである。用語「マシン可読媒体」は、これだけに限らないが、ソリッドステートメモリ、光学的な媒体、および磁気的な媒体の形態のデータリポジトリを含む。

さらなる考慮事項
上記で述べられたシステムおよびプロセスを用いて、ドメイン所有者は、電子メールを送るために、他のサードパーティの配信機構およびそれらの配信電子メールシステムのサービスを利用することができ、なおこれらの電子メールが、正当なものであるとして受信電子メールシステムにより妥当性が検証されることができる。様々な電子メールドメイン妥当性検証レコードを更新することに代えて、ＤＮＳサーバは、集中化された場所で、電子メールを送った配信電子メールシステムに対して、受信電子メールシステムから受信された識別情報に応じて簡単なルールのセットを生成する。さらに、受信電子メールシステムは、電子メールドメイン妥当性検証レコードにおけるルールに存在し得る多数のＤＮＳレコードを照会する必要がない。こうすることは、性能を向上させ、かつサードパーティエージェントにより電子メールを送る管理を簡単化するが、なお、セキュリティを提供し、不正な、または疑わしいメッセージが受信されるのを阻止する。

本明細書の全体を通して、複数の例は、単一の例として述べられた構成要素、動作、または構造を実施することができる。１または複数の方法の個々のオペレーションが、別々のオペレーションとして示され、かつ述べられているが、個々のオペレーションの１または複数のものは、同時に実施されることも可能であり、またオペレーションが、示された順序で実施される必要はない。例示的な構成において、別々の構成要素として示された構造および機能は、組み合わされた構造または構成要素として実施されることができる。同様に、単一の構成要素として提示された構造および機能は、別々の構成要素として実施され得る。これらの、および他の変形、変更、追加、および改良は、本明細書の主題の範囲に含まれる。

いくつかの実施形態が、例えば、図１〜図４で示されるように、論理、またはいくつかの構成要素、モジュール、もしくはメカニズムを含むものとして本明細書に記述されている。モジュールは、ソフトウェアモジュール（例えば、マシン可読媒体上で、または送信信号で実施されるコードなど）、またはハードウェアモジュールのいずれかを構成することができる。ハードウェアモジュールは、いくつかのオペレーションを実施できる有形なユニットであり、一定の方法で構成され、または配置され得る。例示的な実施形態では、１または複数のコンピュータシステム（例えば、スタンドアロンの、クライアント、またはサーバコンピュータシステム）、またはコンピュータシステムの１または複数のハードウェアモジュール（例えば、プロセッサ、もしくはプロセッサの群）は、本明細書で述べられるいくつかのオペレーションを実施するように動作するハードウェアモジュールとして、ソフトウェア（例えば、アプリケーションもしくはアプリケーション部分）により構成され得る。

様々な実施形態では、ハードウェアモジュールは、機械的に、または電子的に実施され得る。例えば、ハードウェアモジュールは、いくつかのオペレーションを実施するように、（例えば、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または特定用途向けＩＣ（ＡＳＩＣ）など、専用のプロセッサとして）恒久的に構成される専用の回路もしくは論理を備えることができる。ハードウェアモジュールはまた、ソフトウェアによりいくつかのオペレーションを実施するように一時的に構成されるプログラム可能な論理もしくは回路（例えば、汎用プロセッサまたは他のプログラム可能なプロセッサ内に含まれる）を含むことができる。ハードウェアモジュールを、専用かつ恒久的に構成された回路で機械的に、または一時的に構成された（例えば、ソフトウェアで構成された）回路で実施する判断は、コストおよび時間を考慮することにより行われ得る。

本明細書で述べられる例示的な方法の様々なオペレーションは、関連するオペレーションを実施するように一時的に（ソフトウェアにより）構成された、または恒久的に構成された１または複数のプロセッサによって、少なくとも部分的に実施され得る。一時的に構成されるか、それとも恒久的に構成されるかにかかわらず、このようなプロセッサは、１または複数のオペレーションもしくは機能を実施するように動作するプロセッサで実施されるモジュールを構成することができる。本明細書で称されるモジュールとは、いくつかの例示的な実施形態において、プロセッサで実施されるモジュールを含むことができる。

１または複数のプロセッサはまた、「クラウドコンピューティング」環境における、または「サービスとしてのソフトウェア」（ＳａａＳ：ｓｏｆｔｗａｒｅ ａｓ ａ ｓｅｒｖｉｃｅ）として、関連するオペレーションの実施をサポートするように動作することができる。例えば、少なくともいくつかのオペレーションは、コンピュータの群（例として、プロセッサを含むマシンなど）により実施することができ、これらのオペレーションは、ネットワーク（例えば、インターネット）を介して、また１または複数の適切なインターフェース（例えば、アプリケーションプログラムインターフェース（ＡＰＩ））を介して、アクセス可能である。

いくつかのオペレーションの実施は、単一のマシン内に常駐するだけではなく、いくつかのマシンにわたって展開された、１または複数のプロセッサの中で分散され得る。いくつかの例示的な実施形態では、１または複数のプロセッサ、またはプロセッサで実施されるモジュールは、単一の地理的場所に（例えば、ホーム環境、オフィス環境、またはサーバファーム内など）位置することができる。他の例示的な実施形態では、１または複数のプロセッサ、またはプロセッサで実施されるモジュールは、いくつかの地理的場所にわたって分散され得る。

本明細書のいくつかの部分は、マシンメモリ（例えば、コンピュータメモリ）内に、ビットまたは２値デジタル信号として記憶されたデータに対するオペレーションのアルゴリズムもしくは記号表現により提示される。これらのアルゴリズムもしくは記号表現は、データ処理技術における当業者により使用される技法の例であり、当業者の成果の内容を他の当業者に伝える。本明細書で使用される場合、「アルゴリズム」とは、望ましい結果へと導く、自己矛盾のないオペレーションのシーケンス、または同様の処理のことである。本コンテキストでは、アルゴリズムおよびオペレーションは、物理量の物理的な操作を含む。必ずしもそうではないが、通常、このような量は、記憶され、アクセスされ、転送され、組み合わされ、比較され、またはマシンによりその他の形で操作できる電気的、磁気的、または光学的な信号の形態を取ることができる。「データ」、「コンテンツ」、「ビット」、「値」、「要素」、「記号」、「キャラクタ」、「項」、「番号」、「数」、または同様のものなどの用語を用いてこのような信号を参照することは、主として一般に使用するために便利なことが多い。しかし、これらの用語は、単に便宜的なラベルに過ぎず、適切な物理量に関連付けられるべきである。

その他の形で特に述べられない限り、本明細書で「処理する」、「コンピュータを使用する」、「計算する」、「決定する」、「提示する」、「表示する」、または同様のものなどの用語を用いる論議は、１または複数のメモリ（例えば、揮発性メモリ、不揮発性メモリ、またはそれらの組合せ）、レジスタ、または情報を受信し、記憶し、送信し、もしくは表示する他のマシン構成要素に含まれる物理的な（例えば、電子、磁気、または光学的な）量として表現されるデータを操作もしくは変換するマシン（例えば、コンピュータ）のアクションもしくはプロセスを指すことができる。

本明細書で使用される場合、「一実施形態」、または「実施形態」への何らかの参照は、実施形態に関連して述べられた特定の要素、機能、構造、または特性が、少なくとも１つの実施形態に含まれることを意味する。本明細書の様々な場所で、「一実施形態では」というフレーズが出現することは、必ずしもすべてが同じ実施形態を参照するものではない。

いくつかの実施形態は、「結合される」、および「接続される」という表現を、それらの派生語と共に用いて述べることができる。例えば、いくつかの実施形態は、２つ以上の要素が直接、物理的に、または電気的に接触していることを示すために、「結合される」という用語を用いて述べることができる。しかし「結合される」という用語はまた、２つ以上の要素が、互いに直接接触していないが、なお互いに協動する、または相互作用することを意味することができる。諸実施形態は、このコンテキストに限定されない。

本明細書で使用される場合、用語「含む／備える（ｃｏｍｐｒｉｓｅｓ）」、「含む／備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｅｓ）」、「含む（ｉｎｃｌｕｄｉｎｇ）」、「有する（ｈａｓ）」、「有する（ｈａｖｉｎｇ）」、またはそれらの任意の他の変形形態は、非排他的に含めることを包含するように意図されている。例えば、要素のリストを含むプロセス、方法、物品、もしくは装置は、必ずしもこれらの要素だけに限定されるものではなく、明示的に列挙されていない他の要素、またはこのようなプロセス、方法、物品、もしくは装置などに固有の他の要素を含むことができる。さらに、その反対のことが明示的に述べられていない限り、「または」は、包含的なまたはを指し、排他的なまたはを指すものではない。例えば、条件ＡまたはＢは、以下のいずれか１つにより満たされる、すなわち、Ａは真（または存在する）であり、Ｂは偽（または存在しない）であること、Ａは偽（または存在しない）であり、Ｂは真（または存在する）であること、およびＡとＢは共に真（または存在する）であること。

さらに、「ａ」、または「ａｎ」の使用は、本明細書の実施形態の要素および構成要素を記述するために使用される。これは、単に便宜上行われるものであり、本発明の一般的な意味を与えるに過ぎない。この記述は、１つ、または少なくとも１つのものを含むように読まれるべきであり、単数形はまた、それが他の形を意味することが明らかではない限り複数も含む。

本開示を読めば、当業者であれば、ＥＨＬＯ名およびＩＰアドレスターゲティングにより媒介を通じて電子メール送信者の妥当性を検証できるシステムおよびプロセスに関する付加的で代替的な構造的かつ機能的な設計を理解されよう。したがって、特定の実施形態および用途が示され、かつ述べられてきたが、開示された実施形態は、本明細書で開示された正確な構成および構成要素に限定されないことを理解されたい。当業者には明らかなはずの様々な修正、変更、および変形は、添付の特許請求の範囲で定義される趣旨および範囲から逸脱することなく、本明細書で開示される方法および装置の配置、オペレーション、ならびにその細部に行うことができる。

本開示は、一般に、電子的なメッセージングの分野に関し、詳細には、ＥＨＬＯ名およびＩＰアドレスターゲティングによる電子メール送信者の集中型検証に関する。

関連出願への相互参照
本出願は、２０１５年２月１４日に出願された米国特許仮出願第６２／１１６、４０９号明細書の利益を主張するものであり、その全体が参照により本明細書に組み込まれる。

電子メールなどの分散メッセージングシステムにおいては、メッセージの実際の発信者は、不正なメッセージをなくすために、メッセージの主張された識別に対する妥当性が検証され得る。このような不正なメッセージの例は、特定の送信者からのものであると称しているが、実際は詐称された送信者アドレスを有し、かつ受取人に対して何らかの不正な作業を実施する（例えば、個人情報を盗む）ことを望む可能性のある悪意のあるエンティティから送られた「フィッシング」電子メールを含む可能性がある。この妥当性検証問題に対する１つの手法は、送信識別の所有者に、どのコンピュータが、受取人の電子メールサーバに電子メールを中継可能であるかを定義するルールのセットを作成できるようにすることである。送信者ポリシーフレームワーク（ＳＰＦ）は、電子メールに対するこの手法の標準の実装形態である。送信識別は、受信メールサーバが、受信されたメッセージの送信者の識別の妥当性を検証するために、それらにアクセスすることが可能であるようなドメイン名システム（ＤＮＳ）を介してこれらのＳＰＦルールをパブリッシュする。

この手法は有効であり得るが、それは、受信システムに対してかなりの負担を与え、かつ有効な媒介（例えば、メーリングリスト、「ライフタイム」電子メールアカウントなど）を使用することに課題を生ずる。例えば、メーリングリストサーバは、発信元の送信者からのメッセージを転送するように求められ得るが、メーリングリストサーバは、発信元の送信者により有効な送信者として識別されない。メッセージの妥当性を検証するとき、完全なルールセットが、数百の、またはさらに数千のルールを要求するとしても、受信システムは、いくつかのこのようなルールよりも多くの検査を実質的に実行することはできない。

ＳＰＦはまた、受信システムに対する負担を制限するために、可能なドメイン名システム（ＤＮＳ）参照数に対する厳しい制限を含むが、これは、いくつかの正当なメッセージの妥当性の検証に失敗する犠牲を払うことになる。送信者書換えスキーム（ＳＲＳ）などの他の技法は、元の送信者を、より制限されたルールセットによって妥当性が検証され得る中間的な識別へと置き換える。こうすることにより、受信システムに対する負担は最小化するが、発信者の識別に対するメッセージの妥当性を検証することにならない。

したがって、欠けているのは、受信システムに不当に負担をかけることがなく、既存のフレームワークと互換性があり、かつ相互運用可能な、送信者識別検証のための任意に多量の複雑なルールセットを定義できる能力である。

いくつかの実施形態では、システムおよび方法は、ネットワークまたはＩＰレベルからの電子メールに関する認証質問を、送信機構レベルへと再フレーム化すること、既存の送信者ポリシーフレームワーク（ＳＰＦ）プロトコルの能力を用いて、ＳＭＴＰ接続から利用可能なネットワーク情報をターゲテッドドメイン名へと符号化すること、およびそれを、そのネットワーク情報を既知の機構のリストへとマップするデータベースにより支援されたカスタムのＤＮＳシステムと組み合わせることを含むことができる。

いくつかの実施形態では、システムおよび方法は、ドメインマネジャに、許可された機構に対するＳＰＦレコードの手動の参照、ドメインに対するＤＮＳ ＴＸＴレコードの変更など、何らかのさらなる作業を必要とすることなく、それ自体のために、電子メールを送ることのできる機構のセットを定義できるようにする。それはまた、ドメインマネジャに、任意の数の送信機構を許可できるようにし、かつ許可された送信者に対するＳＰＦ構成への変更を追跡する必要性をドメインマネジャから開放する。

いくつかの実施形態では、システムおよび方法は、ドメインの所有者が、そのドメインから発信された電子メールをどのメールサーバが配信できるかを指定するルールのセット（ディレクティブとして知られている）を、ＤＮＳ ＴＸＴレコードで定義できるプロトコルとすることのできる送信者ポリシーフレームワーク（ＳＰＦ）を含むことができる。受信メールサーバは、これらのルールを評価し、かつ配信サーバのＩＰアドレスに基づき、問題のメッセージが、そのドメインから発信できるかどうかを判定する。

いくつかの実施形態では、システムおよび方法は、ＳＰＦの２つの機能を利用することができる。第１に「ｉｎｃｌｕｄｅ」メカニズムであり、それにより、ＳＰＦレコードは、さらなるＤＮＳ ＳＰＦレコードが定義されているターゲットドメインを参照し、かつこの参照レコードで定義されたルールを、評価されたルールセットの中に含めることができる。第２に、マクロシステムであり、それによって、ＳＭＴＰ接続に関連付けられたＩＰアドレスおよびＥＨＬＯ名などの要求特有の値が、ターゲットドメインに補間され得る。

いくつかの実施形態では、ドメインを構成するとき、ＳＰＦレコードは、電子メールが許可されているドメインの名前、ならびにＳＭＴＰ接続のＥＨＬＯ名および／またはＩＰアドレスを、ターゲットドメイン名へと符号化するためにＳＰＦマクロを使用する「ｉｎｃｌｕｄｅ」ディレクティブを組込むドメインに対して構成され得る。ターゲットドメイン名は、ネットワーク情報を既知の機構のリストにマッピングする責任を担うＤＮＳシステムである、ターゲテッドＳＰＦ ＤＮＳリゾルバにより管理されるＤＮＳゾーン内にあるように構成され得る。

さらなる実施形態では、ターゲテッドＳＰＦ ＤＮＳリゾルバは、ターゲットドメインに対するＤＮＳ照会に応ずる責任を担うことができる。それはまた、既知の機構に対するネットワーク情報の正確な、最新のマッピングを維持する責任を担うことができ、それは、ドメイン登録レコード、パブリックＤＮＳエントリ、および精選された情報などのパブリック情報を組み合わせることを含むことができる。

さらなる実施形態において、送信者ポリシーフレームワーク（ＳＰＦ）を向上させるためのシステムおよび方法は、ドメインマネジャに提示される全体的な複雑さ、および維持負担を低減し、かつ同様の認証を提供するための最新システムの既存の制限を除くことにより、電子メールを認証する技術を進歩させることができる。さらに、本方法は、電子メールを受信するシステムに対して何らかの変更を必要とする可能性がなく、またインストールされたソフトウェアの既存の、かつ広範囲なベースと両立性を有することができる。

開示される実施形態は、詳細な説明、添付の特許請求の範囲、および添付図（または図面）から容易に明らかになる利点および特徴を有する。諸図の簡単な紹介は以下のようになる。
図１は、実施形態によるＥＨＬＯ名およびＩＰアドレスターゲティングにより媒介を通じて電子メール送信者の妥当性を検証できるシステム例を示す図である。 図２は、一実施形態によるサードパーティ配信機構で使用するための電子メールドメイン妥当性検証レコードを作成するプロセス例を示すインタラクション図およびフローチャートである。 図３は、一実施形態によるＤＮＳを用いる電子メールドメイン妥当性検証レコードによる解決についてのプロセス例を示すインタラクション図およびフローチャートである。 図４は、マシン可読媒体から命令を読み取り、かつプロセッサ（またはコントローラ）により命令を実行することのできるマシンの例の構成を示すブロック図である。

図（ＦＩＧＳ．）および以下の説明は、より好ましい実施形態に関する。以下の論議から、本明細書で開示される構造および方法の代替的実施形態は、特許請求される原理から逸脱することなく使用され得る実行可能な代替形態として容易に理解されるはずであることに留意されたい。

いくつかの実施形態、また添付図において示されている例に対して、まず、詳細に言及が行われる。図は、例示のためだけに、開示されるシステム（または方法）の実施形態を示している。当業者であれば、以下の説明から、本明細書で示される構造および方法の代替的実施形態が、本明細書で述べられる原理から逸脱することなく使用され得ることを容易に理解されよう。

構成の概観
例として開示される実施形態は、ＥＨＬＯ名およびＩＰアドレスターゲティングにより、媒介を通じて電子メール送信者の妥当性を検証することのできるシステムおよびプロセスである。実施形態では、ＤＮＳサーバは、受信電子メールシステムから、ＤＮＳサーバに記憶された電子メールドメインに対するＤＮＳ照会を受信し、ＤＮＳ照会は、電子メールの送信者の識別情報を含み、かつ電子メールは、電子メールドメインからのものとしてそれ自体を識別する。ＤＮＳサーバは、ＤＮＳ照会から電子メール送信者の識別情報を抽出し、かつ識別情報から、複数の配信機構の１つを識別する。ＤＮＳサーバは、識別された配信機構が、電子メールドメインに代わって電子メールを配信することが許可されているかどうかを判定する。識別された配信機構が、電子メールドメインに代わって、電子メールを配信することが許可されていると決定したことに応答して、ＤＮＳサーバは、許可された配信機構および電子メールドメインの識別に基づき、ターゲット妥当性検証レコードを生成し、ターゲット妥当性検証レコードは、配信機構が電子メールドメインに対する電子メールの許可された送信者であることを、受信電子メールシステムに示す１または複数のルールを含み、かつＤＮＳ照会に応答して、受信電子メールシステムに、ターゲット妥当性検証レコードを送る。

一実施形態では、送信電子メールシステムは、電子メールドメインのＤＮＳレコードに含めるために、電子メール妥当性検証レコードを作成するように構成され、電子メールドメイン妥当性検証レコードは、ターゲットドメインから電子メールを受信したとき、受信電子メールシステムにより構文解析され、受信電子メールシステムに、電子メールの送信者が、電子メールドメインに対する許可された送信者であるかどうかを示す。電子メールドメイン妥当性検証レコードを作成するために、送信電子メールシステムは、電子メールドメインとは別個のドメインであるターゲットドメインを含むように電子メールドメイン妥当性検証レコードを構成し、電子メールドメイン妥当性検証レコードの構文解析を行うとき、受信電子メールシステムに、妥当性検証レコードを求める第２の要求をターゲットドメインに提出させる。送信電子メールシステムはまた、識別情報を指定する１または複数のマクロ文を含めるように電子メールドメイン妥当性検証レコードを構成し、マクロ文は、受信電子メールシステムに、電子メールドメイン妥当性検証レコードの構文解析を行うとき、電子メールの送信者の識別情報を第２の要求に含めるようにさせる。送信電子メールシステムは、この作成された電子メールドメイン妥当性検証レコードを電子メールドメインのＤＮＳレコードとしてパブリッシュするように構成される。

導入
送信者ポリシーフレームワーク（ＳＰＦ）は、電子メールを認証するための強力なツールであるが、今日使用されるように、構成するのを困難にし、かつ実際には、所与の電子メールドメインに対して電子メールを配信することが認証され得るサービスの数に対して大幅な制限を加えるいくつかの実質的な制限を有する。いくつかの実施形態では、システムおよび方法は、電子メールドメイン所有者が、ａ）ネットワーキングプリミティブではなく、サービスに関するそれらの電子メールドメインのＳＰＦ認証の構成、およびｂ）これらの無制限な数の構成をサポートできる方法を提供することができる。

例示的な主要な代表システム
図１は、実施形態によるＥＨＬＯ名およびＩＰアドレスターゲティングにより媒介を通じて電子メール送信者の妥当性を検証できる例示的なシステム１００を示している。システム１００は、ネットワーク１５０、１または複数のクライアントデバイス１６０、許可するＤＮＳサーバ１３０、ドメイン所有者ＤＮＳサーバ１４０、ドメイン所有者システム１１０、配信電子メールシステム１１５、および受信電子メールシステム１２０を含む。示されたシステム１００は、図１で示された要素を含むが、他の実施形態では、システム１００は、異なる要素を含むこともある。さらに各要素の機能は、他の実施形態における要素の中では異なる形で配分され得る。

有線、無線、またはそれらの組合せとすることのできるネットワーク１５０は、クライアントデバイス１６０、ＤＮＳシステム１３０／１４０、ドメイン所有者システム１１０、およびサードパーティシステム１２０の中で通信を可能にし、かつインターネット、ＬＡＮ、ＶＬＡＮ（例えば、ＶＰＮを有する）、ＷＡＮ、または他のネットワークを含むことができる。一実施形態では、ネットワーク１５０は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、伝達制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、ユニフォームリソースロケータ（ＵＲＬ）、およびドメイン名システム（ＤＮＳ）など、標準の通信技術および／またはプロトコルを使用する。他の実施形態では、エンティティは、上記で述べたものに代えて、またはそれに加えて、カスタムかつ／または専用のデータ通信技術を使用することができる。

ドメイン所有者システム１１０は、特定のドメイン（例えば、ｅｘａｍｐｌｅｃｏｒｐ．ｃｏｍ）の１または複数のコンピューティングシステムを含み、図４を参照して述べられるコンピューティングシステムと同様に構成され得る。

一実施形態では、ドメイン所有者システム１１０は、受信電子メールシステム１２０などの受信電子メールシステムが、ドメイン所有者システム１１０のドメインを電子メールの送信者として示す電子メールの正当性を検証できるようにする妥当性検証ルールを生成するルール作成器１１１を含む。受信電子メールシステム１２０がこのような電子メールを受信したとき、それは、その電子メールが、実際にドメイン所有者システム１１０から正当に送られたかどうかを調べるために、これらの妥当性検証ルールを検査することができる。一実施形態では、ルールは、ドメイン所有者システム１１０のインターネットプロトコル（ＩＰ）アドレスを示し、したがって、受信電子メールシステム１２０は、電子メールが、ルールで示されたＩＰアドレスから受信されたかどうかを検証する。

これらのルールは、検出されたネットワーク特性（例えば、送信電子メールシステムの検出されたＩＰアドレス、ドメイン名情報など）に基づいて自動的に生成され得る、またはユーザインターフェースを介して管理者からルール作成器１１１により受信され得る。ルールが生成された後、ルール作成器１１１は、公開されたアクセス可能な場所で、そのルールをパブリッシュする。この公開されたアクセス可能な場所とは、ドメイン所有者システム１１０のドメインに対するドメイン所有者だけがパブリッシュできる信頼できる場所のことである。その場合、どの受信電子メールシステム１２０も、ルールを取得するためにこの公開の場所にアクセスすることができる、一実施形態では、公開の場所は、ドメイン名システム（ＤＮＳ）である。したがって、これらのルールは、ドメイン所有者ＤＮＳサーバ１４０上の電子メールドメイン妥当性検証レコード１４１に記憶され得る。一実施形態では、ルールは、送信者ポリシーフレームワーク（ＳＰＦ）ルールである（それは、ＲＦＣ４４０８および７２０８で文書化され、本明細書に参照により組み込まれる）。

配信電子メールシステム１１５は、ドメイン所有者システム１１０のために電子メールを送信する。配信電子メールシステム１１５は、図４を参照して述べられるコンピューティングシステムと同様に構成され得る１または複数のコンピューティングシステムを備える。例として、配信電子メールシステム１１５は、メーリングリストサーバ、ドメインに代わって電子メールを送信するバルクメーラプロバイダ、ドメインに代わって電子メールを送るサードバーティにより管理されるトランザクション電子メールシステム、またはドメインに代わって電子メールを走査するセキュリティシステムとすることができる。配信電子メールシステム１１５は、配信電子メールシステム１１５が、電子メールに対してさらなる処理または機能を提供できるように、ドメイン所有者システム１１０に代えて電子メールを送信することができる。

配信電子メールシステム１１５は、電子メールを送るための電子メール送信器１１６を含む。一実施形態では、電子メール送信器１１６は、簡易メール転送プロトコル（ＳＭＴＰ）など、標準のメールプロトコルを使用する。ＳＭＴＰは、様々な機能をサポートする。特に、送信電子メールシステムが、受信電子メールシステムと通信するとき、ＳＭＴＰは、送信電子メールシステムが、受信電子メールシステムに対して、ＨＥＬＯ、または拡張ＨＥＬＯ（ＥＨＬＯ）メッセージを送信できることを示す。このＨＥＬＯ／ＥＨＬＯメッセージは、送信電子メールシステムの識別子（例えば、ドメイン名）を含み、またＥＨＬＯメッセージの場合、送信電子メールシステムのサポートされる拡張および機能を示すさらなる識別子を含むことができる。

最初はドメイン所有者システム１１０により送られたメッセージまたは電子メールを送る、またはその他の形で転送するとき、ドメイン所有者システム１１０に関連付けられた、かつ電子メールドメイン妥当性検証レコード１４１として記憶され得る妥当性検証ルールは、配信電子メールシステム１１５の認証に適応できるように修正される。

受信電子メールシステム１２０は、配信電子メールシステム１１５から、１または複数の電子メールを受信する電子メールシステムである。受信電子メールシステム１２０は、図４を参照して述べられるコンピューティングシステムと同様に構成され得る１または複数のコンピューティングシステムを備える。

受信電子メールシステム１２０は、電子メールを受信するための電子メール受信器１２２を含む。一実施形態では、電子メール受信器１２２は、簡易メール転送プロトコル（ＳＭＴＰ）など、標準的なメールプロトコルを使用する。

受信電子メールシステム１２０は、電子メールが不正なものではないことを保証するために、どの受信された電子メールの送信者の識別も妥当性を検証する電子メール認証器１２１を備える。電子メールを受信すると、電子メール認証器１２１は、（例えば、ＨＥＬＯコマンドにより）電子メールが受信されたサーバにより提供される識別、または電子メールのリターンパスアドレスに示されたドメイン（例えば、「ｇｍａｉｌ．ｃｏｍ」）、もしくは何らかの他の識別子によるドメインのいずれかに関連付けられた任意の関連する電子メールドメイン妥当性検証レコードを調べることができる。電子メール認証器１２１は、送信者のＩＰアドレスなど、電子メールから識別された情報が、関連する電子メールドメイン妥当性検証レコードのいずれか１つに示されたルールのいずれかにマッチするか、それともそれにより許可されるかどうかを判定する。ルールにおいてマッチが見出された場合、電子メール認証器１２１は、電子メールメッセージは有効である可能性が高く、送信者と称されるものからのものであり、不正なソースからのものではないと決定する。

一実施形態では、電子メールドメイン妥当性検証レコードで示されるルールは、ＳＰＦルールである。ＳＰＦルールは、ＩＰアドレスを示すことができ、したがって、電子メール認証器１２１は、ＳＰＦルールで示されたＩＰアドレスが、電子メールを受信電子メールシステム１２０に送ったサーバのＩＰアドレスまたは他の識別情報にマッチするかどうかを検証することができる。ＳＰＦルールはまた、別のドメインを示すことができ、その場合、電子メール認証器１２１は、その別のドメインに対するＳＰＦルールレコードを調べて、そのレコードにおけるいずれかのルールが、電子メールを送ったサーバの識別情報にマッチするかどうかを調べることができる。さらにいくつかの場合、ＳＰＦルールは、電子メール認証器１２１が電子メールの受信時に動的に決定されるデータで置き換える特別のプレースホルダインジケータであるマクロをサポートする。例えば、電子メール認証器１２１は、電子メールのリターンパスドメイン（例えば、「ａｃｍｅ．ｃｏｍ」）に対するルールで示される「％｛ｄ｝」などのマクロを拡張することができる。さらなるマクロコマンドは、ＳＰＦ ＲＦＣ７２０８、および４４０８でさらに詳細に述べられる。

ＤＮＳサーバ１３０および１４０は、ＤＮＳシステムで使用するためのＤＮＳレコードを記憶する。各ＤＮＳサーバは、図４を参照して述べられるコンピューティングシステムなどの１または複数のコンピューティングシステムを備えることができる。

各ＤＮＳサーバは、当技術分野で知られているように、Ａレコード、ＭＸレコード、以下同様のものなど、特定のドメインに対して複数のＤＮＳレコードを記憶することができる。レコードは、図１で示されているように、複数のエントリへと分離され、複数のサーバ上にあるが、他の実施形態では、レコードは、より少ないエントリ、単一のサーバ、単一のエントリに、または何らかの他の組合せへと組み合わされる。さらに、各ドメインに対して一定数のレコードが図１で示されているが、他の実施形態では、各ドメインは、複数のレコードを有することができる。

図１で示されるように、ドメイン所有者ＤＮＳサーバ１４０は、電子メールドメイン妥当性検証レコード１４１を含む。この電子メールドメイン妥当性検証レコード１４１は、受信電子メールシステム１２０が、受信した電子メールの正当性の妥当性を検証できるようにする１または複数のルールを含むことができる。上記で述べたように、電子メールドメイン妥当性検証レコード１４１は、ドメインに関連付けられた送信者に関するＩＰアドレスまたは他の識別子を示すことができ、したがって、受信電子メールシステム１２０は、電子メールの送信者のＩＰアドレス（または他の識別子）が、電子メールで示されたドメインに対応している（例えば、「ａｃｍｅｂａｎｋ．ｃｏｍ」からの電子メールが、実際にＡｃｍｅ Ｂａｎｋからのものである）ことを検証することができる。しかし、このような簡単なルールは、サードパーティの配信電子メールシステム１１５が、送信電子メールシステムもしくはドメイン所有者の代わりにメールを送るために使用される場合は、不利になり得る。これは、電子メールドメイン妥当性検証レコード１４１におけるルールは、配信電子メールシステム１１５が特定のドメインに対する有効な送信者であることを示さない可能性があるためである。

それに代えて、電子メールドメイン妥当性検証レコード１４１は、別個のドメインを有するルールを含めることができる。この別個のドメインに対するＤＮＳレコードは、許可するＤＮＳサーバ１３０上など、どこか他に存在することができる。さらに、別個のドメインを用いるこのルールはまた、１または複数のマクロを含み、受信電子メールシステム１２０により構文解析されたとき、受信電子メールシステム１２０に、受信電子メールシステム１２０が電子メールを受信したサーバを識別するさらなる情報、または電子メールに関する他の識別情報でマクロを置き換えさせる。一実施形態では、この情報は、受信電子メールシステム１２０が電子メールを受信したサーバからのＥＨＬＯメッセージにおけるいずれかの識別子、ならびに同じサーバのＩＰアドレスを含む。ルールが構文解析された後、受信電子メールシステム１２０は、ルールで示された別個のドメインのＤＮＳレコードをルールにより照会する。例えば、ルールは、「％｛ｉ｝．＿ｉｐ．ｖｅｒｉｆｉｅｒ．ｃｏｍ」のマクロを備えるドメインを示すことができる。拡張された後、マクロ「％｛ｉ｝」は、受信電子メールシステム１２０に電子メールを送ったサーバ（例えば、これは配信電子メールシステム１１５になり得る）のＩＰアドレスにより置き換えられることができ、また受信電子メールシステム１２０は、ドメイン「ｖｅｒｉｆｉｅｒ．ｃｏｍ」のＤＮＳレコードを求めて照会し、ＩＰアドレスを、問題のＤＮＳレコードを提供できるＤＮＳサーバに渡す。

この別個のドメインに対するＤＮＳレコードは、許可するＤＮＳサーバ１３０に存在することができる（またはそこに照会され得る）。許可するＤＮＳサーバ１３０は、配信電子メールシステムに関する情報、ならびにそれらの関連するＩＰアドレスおよびＥＨＬＯ情報を記憶する配信者／ＩＰ記憶装置１３１を含む。許可するＤＮＳサーバ１３０はまた、様々な配信電子メールシステムを認証するルールを記憶する配信者／レコード記憶装置を含む。許可するＤＮＳサーバ１３０はまた、様々なドメインに対して許可された配信電子メールシステムを示す許可された配信者リスト１３２を含む。

上記で述べられたように、電子メールを送ったサーバの識別情報によりマクロが置き換えられると、ドメイン情報が、ＤＮＳ照会で受信電子メールシステム１２０から、許可するＤＮＳサーバ１３０により受信される。許可するＤＮＳサーバ１３０は、識別情報で示されたサーバが、識別情報で示されたドメインのために電子メールを送ることが許可されるかどうかを判定する許可評価器１３５を含む。一実施形態では、ドメインは、許可するＤＮＳサーバ１３０に（マクロを使用することにより）渡されるＥＨＬＯ情報から示され、またサーバに関する識別情報は、ＩＰアドレスにより渡される。許可評価器１３５は、識別情報に関連付けられた配信電子メールシステム１１５の識別を決定するために、配信者／ＩＰ記憶装置１３１にアクセスする。このような情報が見出された場合、許可評価器は、その配信電子メールシステムが、ＤＮＳ照会の識別情報で示されたドメインに対する許可された配信エージェントであるかどうかを判定するために、許可された配信者リスト１３２にアクセスする。

そうである場合、許可するＤＮＳサーバ１３０は、受信電子メールシステム１２０への（送信するための）応答として配信者／レコード記憶装置１３４を用いてルールのセットを構成するターゲットレコード構成器１３３を含む。この構成されたルールのセットは、電子メールを送った配信電子メールシステム（例えば、配信電子メールシステム１１５）が、電子メールで示されたドメインに対して有効な送信者であることを示す。受信電子メールシステム１２０は、次いで、その応答における情報を使用して、配信電子メールシステムが有効な送信者であり、この電子メールをその意図された受取人により受信され得ることを検証することができる。その他の場合、配信電子メールシステムがその応答により有効ではないことが示された場合、受信電子メールシステム１２０は、それに代えて電子メールを破棄する、またはそれにフラグを付けることができる。

クライアントデバイス１６０は、受信電子メールシステム１２０により受信され、かつ認証された電子メールを見るために使用され得る。クライアントデバイス１６０は、図４を参照して述べられるコンピューティングシステムなど、コンピューティングシステムを備えることができる。

具体的には、クライアントデバイス１６０は、受信電子メールシステム１２０とインターフェースを取るための電子メールクライアント１６５を含む。電子メールクライアント１６５は、受信電子メールシステム１２０と通信するために、ポストオフィスプロトコル３（ＰＯＰ３）、インターネットメッセージアクセスプロトコル（ＩＭＡＰ）、メッセージングＡＩＰ（ＭＡＩＰ）、ＳＭＴＰ、以下同様のものなどの標準の電子メールプロトコルを使用することができる。一実施形態では、電子メールが、受信電子メールシステム１２０により適正に認証されない場合、電子メールクライアント１６５は、電子メールを受信することはない。他の実施形態では、電子メールクライアント１６５は、電子メールを受信できるが、さらに電子メールは不正なものであることが疑われる、または疑わしいとの指示を受け取ることができる。

上記で述べたシステム１００を使用すると、ドメインの所有者は、電子メールを送信するために、他のサードパーティ配信機構、およびそれらの配信電子メールシステムのサービスを利用することができ、かつさらに、受信電子メールシステム１２０に、これらの電子メールが正当なものであるとの妥当性を検証させることができる。様々な電子メールドメイン妥当性検証レコードを更新することに代えて、ＤＮＳサーバは、集中化された場所において、電子メールを送った配信電子メールシステム１１５に関する、受信電子メールシステム１２０から受信された識別情報に応じて、簡単なルールのセットを構成することができる。さらに受信電子メールシステム１２０は、電子メールドメイン妥当性検証レコードにおけるルールに存在する可能性のある多数のＤＮＳレコードに照会する必要がない。こうすることは、性能を向上させ、かつサードパーティエージェントによる電子メールを送ることの管理を簡単化するが、なお、セキュリティを提供し、かつ不正な、または疑わしいメッセージが受信されるのを阻止する。上記で述べたシステムおよび処理に関するさらなる詳細は、図２〜図３を参照して述べられる。

電子メールドメイン妥当性検証レコード作成に関する例示的な対話図
図２は、一実施形態によるサードパーティ配信機構で使用するための電子メールドメイン妥当性検証レコードを作成する例示的なプロセスを示す対話図および流れ図である。一実施形態では、図２は、プロセス中のオペレーションを、示された要素に帰属させる。しかし、ステップのいくつか、またはすべてのものは、他の要素により実施され得る。加えて、いくつかの実施形態は、オペレーションを並列に実施する、オペレーションを異なる順序で実施する、または異なるオペレーションを実施することもあり得る。さらに、例示的な一実施形態では、ステップおよび／またはモジュールは、図４に関して述べられるプロセッサ４０２により実行され得る、例えば、命令４２４などの命令として実施され得ることに留意されたい。

この論議において、電子メールドメインとは、着信する電子メールメッセージに対してＳＰＦを評価するとき、受信電子メールシステム１２０が、「ドメイン」として使用できる任意のドメインを指すことになる。通常、これは、メッセージに対するリターンパスで見出されるドメインとなる。

電子メールドメイン所有者、または指定されたパーティであるドメイン所有者システム１１０は、電子メールドメインに対するＤＮＳレコードを構成することができる。これは、電子メールドメインで使用するための電子メールドメイン妥当性検証レコード１４１（ＳＰＦレコードであり得る）を作成する（または生成する）２１０ことを含むことができる。レコードは、特定の送信者が、電子メールドメインからの電子メールに対する有効な送信者であることを示す。一実施形態では、レコードは、ＳＰＦレコードであり、かつ特有の「ｉｎｃｌｕｄｅ」ディレクティブを組込むことができるように構成される。ｉｎｃｌｕｄｅディレクティブは、別のドメインを示すターゲテッドＳＰＦドメイン仕様（specification）を示すことができ、したがって、メッセージに対するＳＰＦ認証決定のいくつか、またはすべては、他のドメインで見出されるＳＰＦレコードへと遅延される（deferred）。言い換えると、前述のように、レコードは、最終的なＳＰＦ認証情報を決定するために別々に照会される別個のドメインを含む。

一実施形態では、電子メールドメイン妥当性検証レコード１４１におけるターゲテッドＳＰＦドメイン仕様は、そのメッセージに関するＳＭＴＰ接続属性に基づき、電子メールメッセージに対する挙動を動的に変更するように構成され得る。この変更は、受信サーバに、ＳＭＴＰ接続属性および電子メールドメインを使用させて、解決されたとき、処理されるメッセージに適用されるターゲット設定化ＳＰＦレコードを生ずるカスタムのドメイン名を構築することにより達成され得る。

これを達成するために、一実施形態では、ターゲテッドＳＰＦドメイン仕様は、３つの特性を含むことができる。第１に、それは、ターゲテッドＳＰＦドメイン仕様から解決されるいずれのドメイン名に対する最終的な権限を有するものは、ターゲテッドＤＮＳ ＳＰＦリゾルバ（例えば、許可するＤＮＳサーバ１３０）である。

これは、ターゲテッドドメイン仕様が、最終的、１または複数の特定の固定ドメインのサブドメインに分解されることを保証することにより達成され得る。いくつかの実装形態では、ターゲテッドＳＰＦドメイン仕様を含むＤＮＳレコードは、他のドメインを参照する１または複数のＤＮＳ ＣＮＡＭＥまたはＮＳレコードの背後に隠すことができ、ターゲテッドＤＮＳ ＳＰＦリゾルバにより管理されない。これは、最終的なＤＮＳ照会ターゲットの転送またはマスキングを可能にする。言い換えると、他のドメインは、最終的なＤＮＳ照会ターゲットが決定される前に、受信電子メールシステムにより照会される必要があり得る。

第２に、ターゲテッドＳＰＦドメイン仕様は、受信電子メールシステム１２０に、ＳＭＴＰ接続に対するＥＨＬＯ名および／またはＩＰアドレスを取り込むようにさせることができる。これらの値は、ＳＰＦマクロシステムを用いて取り込まれ得る。％｛ｈ｝マクロは、ＥＨＬＯ名を取り込むために使用することができ、また％｛ｉ｝または％｛ｐ｝マクロは、ＩＰアドレス、またはＩＰアドレスの妥当性が検証されたドメイン名を取り込むために使用することができる。いくつかの実施形態では、ドメイン所有者システム１１０はまた、受信電子メールシステム１２０に、％｛ｌ｝および／または％｛ｓ｝マクロを用いて、送信者アドレスのローカルパート、または完全な送信者アドレスを取り込ませて、得られた値をターゲテッドＳＰＦドメイン仕様へと符号化するように、ターゲテッドＳＰＦドメイン仕様を構成することができる。

システムの正確な構成に応じて、ＳＰＦマクロ言語で記述された任意選択の変換器の１または複数のものが、ターゲテッドＳＰＦドメイン仕様に適用され得る。同様に、結果が符号化されたＵＲＬであるように、大文字の変形体％｛Ｈ｝、％｛Ｉ｝、％｛Ｐ｝、％｛Ｌ｝、または％｛Ｓ｝をそれに代えて使用することができる。

第３に、ターゲテッドＳＰＦドメイン仕様は、ＳＭＴＰ接続属性が、得られたドメインから明瞭に構文解析され得るように構成することができ、それは、実際に、現実世界のシステムに対して達成され得る。

これを示すために、これらの３つの要件を満たすターゲテッドＳＰＦドメイン仕様に対するフォーマットが構成され得る。例えば、ターゲテッドＤＮＳ ＳＰＦリゾルバ（例えば許可するＤＮＳサーバ１３０）は、ドメイン「ｒｅｓｏｌｖｅｒ．ｃｏｍ」により定義されるゾーンにおけるすべてのＤＮＳ ＴＸＴ照会に対応するものと仮定する。さらに、電子メールドメインは、「ｅｍａｉｌｄｏｍａｉｎ．ｃｏｍ」であると仮定する。最後にＥＨＬＯ名とＩＰアドレスの両方が取り込まれると仮定する。

この場合、ホスト名に対して、文字−数字−ハイフン（ＬＤＨ）ルールが使用され得る。これらのルールは、完全修飾ドメイン名（ＦＱＤＮ）が、ＡＳＣＩＩ文字、数字、またはハイフン記号だけを含むことのできる制限を含む。より一般的には、ＳＰＦレコード参照で使用されるものを含むドメインは、この制限を満たす必要はない。ＥＨＬＯ名と電子メールドメインは共にＦＱＤＮであることが必要なので、「＿」などの非ＬＤＨ記号を含むラベルを用いてターゲテッドＳＰＦドメイン仕様を作成する場合、これらのフィールドは、ドメイン所有者システム１１０により分離され得る。ＩＰアドレスは、数字（ＩＰｖ４）から、または数字および文字ａ〜ｆ（ＩＰｖ６）からだけ構成され得るので、ＩＰアドレスを含むラベルも「＿」を含むことはできない。したがって、「＿」を含むラベルは、同様に、これらの値に対する分離文字として使用され得る。

上記の内容のすべてを組み合わせると、例示的なコンテキストに含まれる要件を満たす１つのターゲテッドＳＰＦドメイン仕様は、「％｛ｉ｝．＿ｉｐａｄｄｒ．％｛ｈ｝．＿ｅｈｌｏ．ｅｍａｉｌｄｏｍａｉｎ．ｃｏｍ．＿ｔｓｐｆ．ｒｅｓｏｌｖｅｒ．ｃｏｍ」である。このドメイン仕様からのＳＰＦプロセス中に補間されたいずれのドメイン名も、「ｒｅｓｏｌｖｅｒ．ｃｏｍ」（右端に示されているドメイン）に基づくことになる。それは、ドメイン名にＥＨＬＯ名とＩＰアドレスを共に含む。さらに、「＿」を含むラベルの使用は、このようなドメイン名から、ＳＭＴＰ属性の明瞭な構文解析をサポートする。

これらの要件を満たす可能性のあるフォーマットは多数あり、この特定の例は、非限定的なものであると見なされるべきであることに留意されたい。

その場合、電子メールドメイン妥当性検証レコード１４１は、上記で述べたターゲテッドＳＰＦドメイン仕様を参照するｉｎｃｌｕｄｅディレクティブを有するＳＰＦルールを有するべきである。上記で述べた例示的なターゲテッドＳＰＦドメイン仕様を使用するこのようなレコードの簡単な、非限定的な例は、「ｖ＝ｓｐｆ１ ｉｎｃｌｕｄｅ：％｛ｉ｝．＿ｉｐａｄｄｒ．％｛ｈ｝．＿ｅｈｌｏ．ｅｍａｉｌｄｏｍａｉｎ．ｃｏｍ．＿ｔｓｐｆ．ｒｅｓｏｌｖｅｒ．ｃｏｍ」である。再度、このレコードは、我々の例に関して現実的なものであるが、非限定的なものであると見なされるべきである。「ｖ」は、ＳＰＦバージョンを指すこと、またｉｎｃｌｕｄｅディレクティブは、示されたドメインが電子メールドメインに対して有効な送信者であることを示していることに留意されたい。

電子メールドメイン妥当性検証レコード１４１が構成された後、それは、電子メールドメインに対するＤＮＳ ＴＸＴレコードとして（例えば、ドメイン所有者ＤＮＳサーバ１４０で）パブリッシュされ得る２１５。これは、このドメインを示す電子メールを受信する任意のサーバにより照会できるようにする。

電子メール検証ルール解決に関する例示的な対話図
図３は、一実施形態によるＤＮＳを用いる電子メールドメイン妥当性検証レコードの解決のための例示的プロセスを示す対話図および流れ図である。一実施形態では、図３は、プロセス中のオペレーションを、示された要素に帰属させる。しかしステップのいくつかまたはすべては、他の要素により実施され得る。加えて、いくつかの実施形態は、オペレーションを並列に実施する、オペレーションを異なる順序で実施する、または異なるオペレーションを実施することもあり得る。さらに、例示的な一実施形態では、ステップおよび／またはモジュールは、図４に関して述べられるプロセッサ４０２により実行され得る、例えば、命令４２４などの命令として実施され得ることに留意されたい。本明細書で述べられるプロセスは、受信電子メールシステム１２０の何らかのさらなる変更、または構成を必ずしも必要としないことに留意されたい。そうではなくて、受信電子メールシステム１２０がＳＰＦまたは同様の送信者認証方式をサポートする限り、それは、変更される必要はない。

最初に、受信電子メールシステム１２０は、特定の電子メールドメインに対応するリターンパスを備えた電子メールを受信する３１０。受信電子メールシステム１２０は、この電子メールメッセージを（例えば、ＳＰＦを用いて）認証しようと試みることができる。受信電子メールシステム１２０は、まず、その電子メールドメインに対する何らかの電子メール妥当性検証レコードに関してＤＮＳに照会することができる３１５。これらのものは、ＳＰＦレコードとすることができる。ドメイン所有者ＤＮＳサーバ１４０は、図２を参照して述べたように、電子メールドメインの所有者がパブリッシュしている電子メールドメイン妥当性検証レコード１４１を応答で返すことができる２８２。

受信電子メールシステム１２０は、電子メール妥当性検証レコードを構文解析して、ターゲットドメイン照会を生成する３２０。このプロセスは、現在のＳＭＴＰ接続に対する値（例えば、ＥＨＬＯ、ＩＰアドレス）を用いて、返されたＤＮＳレコードにおけるターゲットドメインＳＰＦ仕様を有するｉｎｃｌｕｄｅディレクティブを評価すること、およびターゲットドメインを構成するために、ターゲットドメインＳＰＦ仕様の中にこれらの値を補間することを含むことができる。例えば、レコードが、「％｛ｉ｝．＿ｉｐａｄｄｒ．％｛ｈ｝．＿ｅｈｌｏ．ｅｍａｉｌｄｏｍａｉｎ．ｃｏｍ．＿ｔｓｐｆ．ｒｅｓｏｌｖｅｒ．ｃｏｍ」のルールを示した場合、受信電子メールシステム１２０は、これを、「１２３．１２３．１２３．１２３．＿ｉｐａｄｄｒ．ｄｅｌｉｖｅｒｉｎｇｄｏｍａｉｎ．ｃｏｍ．＿ｅｈｌｏ．ｅｍａｉｌｄｏｍａｉｎ．ｃｏｍ．＿ｔｓｐｆ．ｒｅｓｏｌｖｅｒ．ｃｏｍ」へと評価することができるが、１２３．１２３．１２３．１２３は、送信者のＩＰアドレス、ｅｍａｉｌｄｏｍａｉｎ．ｃｏｍは、発信元の送信者のドメインであり、またｄｅｌｉｖｅｒｉｎｇｄｏｍａｉｎ．ｃｏｍは、送信者に対するＥＨＬＯメッセージで示されたドメイン名である。

受信電子メールシステム１２０は、次いで、ターゲットドメインをＤＮＳに照会する３２５。この照会は、許可するＤＮＳサーバ１３０（ターゲットドメインに対する権威サーバとすることができる）により応ずることができる。許可するＤＮＳサーバ１３０は、照会から識別情報を抽出する３４０．この識別情報は、ＥＨＬＯ名およびＩＰアドレスを含むことができ、またターゲットドメイン照会から構文解析され得る。一実施形態では、許可するＤＮＳサーバ１３０はまた、スタンドアロンの値として、または符号化された完全な送信者アドレスの一部として、照会のターゲットドメインからのリターンパスアドレスのローカルパートを構文解析することができる。

一実施形態では、許可するＤＮＳサーバ１３０はまた、ターゲットドメイン照会から電子メールドメインを抽出する（それがマクロにより照会中に含まれている場合）。電子メールドメインが存在する場合、かつ許可するＤＮＳサーバ１３０が限定されたドメインのセットに対する要求だけを処理するように構成されている場合、許可するＤＮＳサーバ１３０は、電子メールドメインが既知であるかどうかを判定することができる。この場合において、その電子メールドメインが既知ではない場合、許可するＤＮＳサーバ１３０は、デフォルトＳＰＦレコードを返すことができる。返されたレコードは、どのＩＰアドレスも認めないレコードである可能性が高く、例は「ｖ＝ｓｐｆ１−〜ａｌｌ」となる。

許可するＤＮＳサーバ１３０は、照会から抽出された識別情報を使用して、配信機構を識別する３４５。配信機構は、配信電子メールシステム１１５の所有者であり、それは電子メールドメインの一部ではない可能性がある。許可するＤＮＳサーバ１３０は、電子メールメッセージのＳＭＴＰ接続に関連付けられたネットワーク特有の情報（例えば、ＥＨＬＯ名および／または送信サーバＩＰアドレス）が、配信機構の高レベルの抽象化に関連付けられ得るように、照会から抽出された識別情報を配信機構に関連付ける配信者／ＩＰ記憶装置１３１を含む。

一般的な配信機構のいくつかの例は、電子メールドメイン所有者により、電子メールを送るように契約したサードパーティ送信者、電子メールドメインから発信されたメッセージをいくつかの受信アドレスに中継しているメーリングリスト、または１つの受信器アドレスに別名を付けるように設計された転送システムである。この例のセットは網羅的なものと見なすべきではなく、リストは、非限定的なものであると見なされるべきである。

一実施形態では、電子メールの実質的な（すなわち、統計的に有意な）コーパス（何億またはそれ以上のメッセージ）のヘッダ情報へのアクセスは、許可するＤＮＳサーバ１３０または他のエンティティに、電子メールヘッダ（特に「受信された」および「認証結果」ヘッダ）で見出された情報を用いることにより、配信者／ＩＰ記憶装置１３１を構成できるようにする。他の実施形態では、配信機構のリストを調べて、その結果を適切な配信者／ＩＰ記憶装置１３１へと組込むこともできる。さらなる実施形態では、特にＷＨＯＩＳデータベースに記憶された情報であるドメイン登録レコードは、配信者／ＩＰ記憶装置１３１に対するこのマッピングを構築するのに有用であり得る。これらの例示的な方法は、非限定的なものと見なされるべきであり、また本明細書で述べられるプロセスは、配信者／ＩＰ記憶装置１３１を構成するために、他の方法、または複数の方法の組合せの使用を排除するものではない。

さらなる実施形態では、許可するＤＮＳサーバ１３０により受信されたＤＮＳ照会の着信ストリームは、調査を必要とするＥＨＬＯ名およびＩＰアドレスのソースとして使用され得る。完全なデータベースのために、正当な電子メールから発信されたすべての（ＥＨＬＯ名およびＩＰアドレス）の組合せは、既知の配信機構にマップされるべきである。既知の配信機構にマップされることのできないいずれの着信データも、一般に、ａ）データベースにおける失われた正当な値、またはｂ）不正なソース電子メールを示すことができる。この「失われている（ｍｉｓｓ）」は、したがって、データベースにおけるギャップを埋めるための情報源として、または脅威情報源として働くことができる。

要求が配信機構にマップされた後、一実施形態では、許可するＤＮＳサーバ１３０は、配信機構が既知のものであるかどうかを判定することができる３４８。既知ではない場合、すべてのＩＰアドレスが不適切であるＳＰＦレコードに関するいくつかの変形など、デフォルトのレコードを返すことができる。例えば、「ｖ＝ｓｐｆ１〜ａｌｌ」は、可能性のある選択肢である。

配信機構が既知であると仮定すると、許可するＤＮＳサーバ１３０は、ターゲットドメインに関する照会で示された電子メールドメインに対して、配信機構が電子メールを配信することが許可されるかどうかを判定することができる３５０。一実施形態では、許可するＤＮＳサーバ１３０は、どの識別された配信機構も、任意の電子メールドメインに対して電子メールを配信できるようにする。他の実施形態では、許可された配信機構に対する電子メールドメインのマッピングは、許可された配信者リスト１３２に記憶される、またはウェブＡＰＩを介して利用可能にされることもでき、また許可するＤＮＳサーバ１３０は、配信機構が許可されるかどうかを判定するためにそのリストもしくはＡＰＩにアクセスする。

識別された配信機構が、電子メールドメインに対して許可されることが見出されない場合、許可するＤＮＳサーバ１３０は、デフォルトレコードを返すことができる。概して、これは、すべてのＩＰアドレスに対する配信を拒否するレコードとすることができる（例えば、「ｖ＝ｓｐｆ１〜ａｌｌ」）。

上記で述べたように、一実施形態では、リターンパスアドレスのローカルパートは、スタンドアロンの値として、または送信者アドレスの一部として、ターゲットドメインの照会中に符号化されている可能性がある。これらの実施形態では、許可するＤＮＳサーバ１３０は、配信機構が、特定のメッセージを配信することが許可されるかどうかを判定するために、電子メールドメインと組み合わせて、電子メールアドレスのローカルパートを使用する。例えば、配信機構は、ａｃｍｅ．ｃｏｍにおける従業員の電子メールアドレスを示すローカルパートを有するリターンパスアドレスのためではなく、「ｎｅｗｓｌｅｔｔｅｒ＠ａｃｍｅ．ｃｏｍ」のためにメールを送ることが許可され得る。

配信機構が、電子メールドメインに対する電子メールを配信することが許可された場合、許可するＤＮＳサーバ１３０は、配信機構および電子メールドメインに基づき、ターゲット妥当性検証レコード（ＳＰＦレコードとすることができる）を生成する３５５。このレコードを構成するために、許可するＤＮＳサーバ１３０は、配信機構のターゲット妥当性検証レコードへのマップを含む配信者／レコード記憶装置１３４に照会することができる。

各配信機構に対して、その配信機構（例えば、配信電子メールシステム１１５）により使用されるサーバからの電子メールを可能にし、いずれかの他から発信された電子メールを拒否することになる何らかの仮想的な電子メール妥当性検証レコードが存在することができる。配信機構に対して、既存の電子メールドメイン妥当性検証レコードが使用され得るので、このことは、適正に構成された電子メールドメイン妥当性検証レコード（例えば、ＳＰＦレコード）を有するいずれの配信機構に対しても当てはまるべきである。

配信機構が、適正に構成された電子メールドメイン妥当性検証レコードを有していない場合であっても、許可するＤＮＳサーバ１３０または管理者は、基礎となるネットワーク構成の十分な知識が与えられると、このようなレコードを構築することが可能である。一実施形態では、許可するＤＮＳサーバ１３０は、配信機構に対する、および／または配信機構によりその他の形で利用可能ではない電子メールドメインに対する電子メールドメイン妥当性検証レコードを作成し、かつ記憶する。

いくつかの実施形態では、またいくつかの構成に対して、配信者／レコード記憶装置１３４はまた、配信機構の関連付けに対する置換え、または捕捉として、電子メールドメインおよび／またはローカルパスを、ターゲット妥当性検証レコードと関連付ける。このような変形形態が望ましい可能性のある例として、電子メールドメインにより、メールサーバのそのクラウドをさらに分割する配信機構を考える。このような状況においては、最適なターゲット妥当性検証レコードを配信するために、配信機構と組み合わせて、電子メールドメインを知ることが必要になり得る。

いくつかの実施形態では、既存の電子メールドメイン妥当性検証レコードは、配信者／レコード記憶装置１３４を構成するための重要な情報源とすることができる。例えば、ＳＰＦレコードの場合、配信機構に対する既存のレコードは、ディレクティブのリストを得るために使用され得る。他の実施形態では、配信機構の手動の調査はまた、この情報の良好なソースとすることができる。さらなる実施形態では、ソースの組合せを使用するさらなる方法がまた実行可能である。ここに列挙したソースは、非限定的なものであると見なされるべきである。

配信者／レコード記憶装置１３４を構成するために、これらの、またはいずれか他の方法を使用する場合、その基礎となるネットワーク構成は時間と共に変化するので、データを更新することが必要になり得る。いくつかの実施形態では、許可するＤＮＳサーバ１３０は、配信者／レコード記憶装置１３４を更新するために、ポーリングメカニズムを使用することができるが、他の実施形態では異なる。このようなポーリングメカニズムの非限定的な例は、既知の送信者によりパブリッシュされたＤＮＳレコードに対する更新を検出するために、定期的に（例えば、毎日）ＤＮＳ照会を実行する許可するＤＮＳサーバ１３０上のソフトウェア構成要素となるはずである。これらの更新は、次いで、許可するＤＮＳサーバ１３０によりデータベースの中に組み込まれ得る。

ターゲット妥当性検証レコードを生成した後、許可するＤＮＳサーバ１３０は、レコードを、元の照会への応答として、受信メールシステム１２０に送り返す３６０。

受信メールシステム１２０は、受信されたターゲット妥当性検証レコードを用いて電子メールメッセージを認証する３３０。

一実施形態では、上記で述べたように、ＳＰＦの「ｉｎｃｌｕｄｅ」メカニズムを使用することに代えて、本明細書で述べるシステムは、ＳＰＦの一部である「ａ」、「ｍｘ」、または「ｅｘｉｓｔｓ」メカニズムを使用するように構成され得る。これらのメカニズムの１つが使用される場合、電子メールドメイン所有者の挙動は、ほとんど不変であり得る、すなわち、「ａ」、「ｍｘ」、または「ｅｘｉｓｔｓ」メカニズムは、この場合、「ｉｎｃｌｕｄｅ」メカニズムの代わりに置き換えるだけである。

この変形形態の下では、許可するＤＮＳサーバ１３０の挙動は、その返す値を除き、大部分変化しない。許可するＤＮＳサーバ１３０が、メッセージは認証されないことを示す場合、許可するＤＮＳサーバ１３０は、ＮＸＤＯＭＡＩＮコードを返すことができる。またターゲット妥当性検証レコードを返す代わりに、許可するＤＮＳサーバ１３０は、ターゲット妥当性検証レコードに対してＩＰアドレスをマッチさせることができる。ＩＰアドレスがそのレコードにマッチしない場合、許可するＤＮＳサーバ１３０は、ＮＸＤＯＭＡＩＮを返すことができる。あるいは、ＩＰアドレスがマッチすることが見出された場合、許可するＤＮＳサーバ１３０は、Ａ、ＭＸ、またはＩＰアドレスを含むＡレコードを返すことができる。

一実施形態では、許可するＤＮＳサーバ１３０は、遠隔のＳＰＦ監査ツールとして使用される。ＳＰＦ解決は、受信電子メールシステム１２０上で行われ、したがって、その評価の結果は、専用のソフトウェアがインストールされない限り、概して、外部の監査システムで利用可能にはなり得ない。ターゲテッドＳＰＦドメイン仕様が、ＥＨＬＯ名とＩＰアドレスの両方を含むように構造化されている場合、許可するＤＮＳサーバ１３０は、メッセージがそこから配信される各（ＥＨＬＯ名、ＩＰアドレス）組合せに対して少なくとも１回呼び出され得る。この情報を用いて、リゾルバは、受信電子メールシステム１２０により実施されるＳＰＦ評価をミラーリングし、対応する結果を記録することができる。

例示的なマシンアーキテクチャ
図４は、マシン可読媒体から命令を読み取り、かつプロセッサ（またはコントローラ）で命令を実行することのできる例示的なマシンの構成要素を示すブロック図である。具体的には、図４は、マシンの図式的な表現を、コンピュータシステム４００の例示的な形態で示している。コンピュータシステム４００は、マシンに、本明細書で述べられた方法（またはプロセス）のうちの任意の１または複数のものを実施させるための命令４２４（例えば、プログラムコードまたはソフトウェア）を実行するために使用され得る。代替的実施形態では、マシンは、スタンドアロンのデバイスとして、または他のマシンに接続される接続された（例えば、ネットワーク化された）デバイスとして動作する。ネットワーク化された展開において、マシンは、サーバ／クライアントネットワーク環境におけるサーバマシンまたはクライアントマシンの役割で、またはピアツーピア（もしくは分散された）ネットワーク環境におけるピアマシンとして動作することができる。

マシンは、サーバコンピュータ、クライアントコンピュータ、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、セットトップボックス（ＳＴＢ）、スマートフォン、モノのインターネット（ＩｏＴ）機器、ネットワークルータ、スイッチもしくはブリッジ、またはそのマシンにより行われるアクションを指定する命令４２４を（順次に、またはその他の形で）実行できる任意のマシンとすることができる。さらに、単一のマシンだけが示されているが、用語「マシン」はまた、個々に、または共同で命令４２４を実行して、本明細書で論じられる方法の任意の１または複数のものを実施するマシンの任意の集合体を含むように解釈されるべきである。

例示的なコンピュータシステム４００は、１または複数の処理ユニット（一般的に、プロセッサ４０２）を含む。プロセッサ４０２は、例えば、中央演算処理装置（ＣＰＵ）、グラフィックス処理装置（ＧＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、状態マシン、１または複数の特定用途向けＩＣ（ＡＳＩＣ）、１または複数の高周波集積回路（ＲＦＩＣ）、またはこれらの任意の組合せである。コンピュータシステム４００はまた、主メモリ４０４を含む。コンピュータシステムは、記憶ユニット４１６を含むことができる。プロセッサ４０２、メモリ４０４、および記憶ユニット４１６は、バス４０８を介して通信する。

さらにコンピュータシステム４００は、スタティックメモリ４０６、ディスプレイドライバ４１０（例えば、プラズマディスプレイパネル（ＰＤＰ）、液晶ディスプレイ（ＬＣＤ）、またはプロジェクタを駆動するためのもの）を含むことができる。コンピュータシステム４００はまた、英数字入力デバイス４１２（例えば、キーボード）、カーソル制御デバイス４１４（例えば、マウス、トラックボール、ジョイスティック、モーションセンサ、または他の指示機器）、信号生成デバイス４１８（例えば、スピーカ）、およびネットワークインターフェースデバイス４２０を含むことができ、それらはまた、バス４０８を介して通信するように構成される。

記憶ユニット４１６は、本明細書で述べられる方法または機能の任意の１または複数のものを実施する命令４２４（例えば、ソフトウェア）が記憶されるマシン可読媒体４２２を含む。命令４２４はまた、完全に、または少なくとも部分的に、主メモリ４０４内に、またはコンピュータシステム４００によるその実行中にはプロセッサ４０２内に（例えば、プロセッサのキャッシュメモリ内に）常駐することができ、主メモリ４０４およびプロセッサ４０２はまた、マシン可読媒体を構成する。命令４２４は、ネットワークインターフェースデバイス４２０により、ネットワーク４２６を介して送信または受信され得る。

マシン可読媒体４２２が、例示的な実施形態で、単一の媒体であるように示されているが、用語「マシン可読媒体」は、命令４２４を記憶できる単一の媒体、または複数の媒体（例えば、集中化された、もしくは分散されたデータベース、または関連するキャッシュおよびサーバ）を含むものと解釈されるべきである。用語「マシン可読媒体」はまた、マシンにより実行するための、かつ本明細書で開示される方法の任意の１または複数のものをマシンに実施させる命令４２４を記憶できる任意の媒体を含むように解釈されるべきである。用語「マシン可読媒体」は、これだけに限らないが、ソリッドステートメモリ、光学的な媒体、および磁気的な媒体の形態のデータリポジトリを含む。

さらなる考慮事項
上記で述べられたシステムおよびプロセスを用いて、ドメイン所有者は、電子メールを送るために、他のサードパーティの配信機構およびそれらの配信電子メールシステムのサービスを利用することができ、なおこれらの電子メールが、正当なものであるとして受信電子メールシステムにより妥当性が検証されることができる。様々な電子メールドメイン妥当性検証レコードを更新することに代えて、ＤＮＳサーバは、集中化された場所で、電子メールを送った配信電子メールシステムに対して、受信電子メールシステムから受信された識別情報に応じて簡単なルールのセットを生成する。さらに、受信電子メールシステムは、電子メールドメイン妥当性検証レコードにおけるルールに存在し得る多数のＤＮＳレコードを照会する必要がない。こうすることは、性能を向上させ、かつサードパーティエージェントにより電子メールを送る管理を簡単化するが、なお、セキュリティを提供し、不正な、または疑わしいメッセージが受信されるのを阻止する。

本明細書の全体を通して、複数の例は、単一の例として述べられた構成要素、動作、または構造を実施することができる。１または複数の方法の個々のオペレーションが、別々のオペレーションとして示され、かつ述べられているが、個々のオペレーションの１または複数のものは、同時に実施されることも可能であり、またオペレーションが、示された順序で実施される必要はない。例示的な構成において、別々の構成要素として示された構造および機能は、組み合わされた構造または構成要素として実施されることができる。同様に、単一の構成要素として提示された構造および機能は、別々の構成要素として実施され得る。これらの、および他の変形、変更、追加、および改良は、本明細書の主題の範囲に含まれる。

いくつかの実施形態が、例えば、図１〜図４で示されるように、論理、またはいくつかの構成要素、モジュール、もしくはメカニズムを含むものとして本明細書に記述されている。モジュールは、ソフトウェアモジュール（例えば、マシン可読媒体上で、または送信信号で実施されるコードなど）、またはハードウェアモジュールのいずれかを構成することができる。ハードウェアモジュールは、いくつかのオペレーションを実施できる有形なユニットであり、一定の方法で構成され、または配置され得る。例示的な実施形態では、１または複数のコンピュータシステム（例えば、スタンドアロンの、クライアント、またはサーバコンピュータシステム）、またはコンピュータシステムの１または複数のハードウェアモジュール（例えば、プロセッサ、もしくはプロセッサの群）は、本明細書で述べられるいくつかのオペレーションを実施するように動作するハードウェアモジュールとして、ソフトウェア（例えば、アプリケーションもしくはアプリケーション部分）により構成され得る。

様々な実施形態では、ハードウェアモジュールは、機械的に、または電子的に実施され得る。例えば、ハードウェアモジュールは、いくつかのオペレーションを実施するように、（例えば、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または特定用途向けＩＣ（ＡＳＩＣ）など、専用のプロセッサとして）恒久的に構成される専用の回路もしくは論理を備えることができる。ハードウェアモジュールはまた、ソフトウェアによりいくつかのオペレーションを実施するように一時的に構成されるプログラム可能な論理もしくは回路（例えば、汎用プロセッサまたは他のプログラム可能なプロセッサ内に含まれる）を含むことができる。ハードウェアモジュールを、専用かつ恒久的に構成された回路で機械的に、または一時的に構成された（例えば、ソフトウェアで構成された）回路で実施する判断は、コストおよび時間を考慮することにより行われ得る。

本明細書で述べられる例示的な方法の様々なオペレーションは、関連するオペレーションを実施するように一時的に（ソフトウェアにより）構成された、または恒久的に構成された１または複数のプロセッサによって、少なくとも部分的に実施され得る。一時的に構成されるか、それとも恒久的に構成されるかにかかわらず、このようなプロセッサは、１または複数のオペレーションもしくは機能を実施するように動作するプロセッサで実施されるモジュールを構成することができる。本明細書で称されるモジュールとは、いくつかの例示的な実施形態において、プロセッサで実施されるモジュールを含むことができる。

１または複数のプロセッサはまた、「クラウドコンピューティング」環境における、または「サービスとしてのソフトウェア」（ＳａａＳ：ｓｏｆｔｗａｒｅ ａｓ ａ ｓｅｒｖｉｃｅ）として、関連するオペレーションの実施をサポートするように動作することができる。例えば、少なくともいくつかのオペレーションは、コンピュータの群（例として、プロセッサを含むマシンなど）により実施することができ、これらのオペレーションは、ネットワーク（例えば、インターネット）を介して、また１または複数の適切なインターフェース（例えば、アプリケーションプログラムインターフェース（ＡＰＩ））を介して、アクセス可能である。

いくつかのオペレーションの実施は、単一のマシン内に常駐するだけではなく、いくつかのマシンにわたって展開された、１または複数のプロセッサの中で分散され得る。いくつかの例示的な実施形態では、１または複数のプロセッサ、またはプロセッサで実施されるモジュールは、単一の地理的場所に（例えば、ホーム環境、オフィス環境、またはサーバファーム内など）位置することができる。他の例示的な実施形態では、１または複数のプロセッサ、またはプロセッサで実施されるモジュールは、いくつかの地理的場所にわたって分散され得る。

本明細書のいくつかの部分は、マシンメモリ（例えば、コンピュータメモリ）内に、ビットまたは２値デジタル信号として記憶されたデータに対するオペレーションのアルゴリズムもしくは記号表現により提示される。これらのアルゴリズムもしくは記号表現は、データ処理技術における当業者により使用される技法の例であり、当業者の成果の内容を他の当業者に伝える。本明細書で使用される場合、「アルゴリズム」とは、望ましい結果へと導く、自己矛盾のないオペレーションのシーケンス、または同様の処理のことである。本コンテキストでは、アルゴリズムおよびオペレーションは、物理量の物理的な操作を含む。必ずしもそうではないが、通常、このような量は、記憶され、アクセスされ、転送され、組み合わされ、比較され、またはマシンによりその他の形で操作できる電気的、磁気的、または光学的な信号の形態を取ることができる。「データ」、「コンテンツ」、「ビット」、「値」、「要素」、「記号」、「キャラクタ」、「項」、「番号」、「数」、または同様のものなどの用語を用いてこのような信号を参照することは、主として一般に使用するために便利なことが多い。しかし、これらの用語は、単に便宜的なラベルに過ぎず、適切な物理量に関連付けられるべきである。

その他の形で特に述べられない限り、本明細書で「処理する」、「コンピュータを使用する」、「計算する」、「決定する」、「提示する」、「表示する」、または同様のものなどの用語を用いる論議は、１または複数のメモリ（例えば、揮発性メモリ、不揮発性メモリ、またはそれらの組合せ）、レジスタ、または情報を受信し、記憶し、送信し、もしくは表示する他のマシン構成要素に含まれる物理的な（例えば、電子、磁気、または光学的な）量として表現されるデータを操作もしくは変換するマシン（例えば、コンピュータ）のアクションもしくはプロセスを指すことができる。

本明細書で使用される場合、「一実施形態」、または「実施形態」への何らかの参照は、実施形態に関連して述べられた特定の要素、機能、構造、または特性が、少なくとも１つの実施形態に含まれることを意味する。本明細書の様々な場所で、「一実施形態では」というフレーズが出現することは、必ずしもすべてが同じ実施形態を参照するものではない。

いくつかの実施形態は、「結合される」、および「接続される」という表現を、それらの派生語と共に用いて述べることができる。例えば、いくつかの実施形態は、２つ以上の要素が直接、物理的に、または電気的に接触していることを示すために、「結合される」という用語を用いて述べることができる。しかし「結合される」という用語はまた、２つ以上の要素が、互いに直接接触していないが、なお互いに協動する、または相互作用することを意味することができる。諸実施形態は、このコンテキストに限定されない。

本明細書で使用される場合、用語「含む／備える（ｃｏｍｐｒｉｓｅｓ）」、「含む／備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｅｓ）」、「含む（ｉｎｃｌｕｄｉｎｇ）」、「有する（ｈａｓ）」、「有する（ｈａｖｉｎｇ）」、またはそれらの任意の他の変形形態は、非排他的に含めることを包含するように意図されている。例えば、要素のリストを含むプロセス、方法、物品、もしくは装置は、必ずしもこれらの要素だけに限定されるものではなく、明示的に列挙されていない他の要素、またはこのようなプロセス、方法、物品、もしくは装置などに固有の他の要素を含むことができる。さらに、その反対のことが明示的に述べられていない限り、「または」は、包含的なまたはを指し、排他的なまたはを指すものではない。例えば、条件ＡまたはＢは、以下のいずれか１つにより満たされる、すなわち、Ａは真（または存在する）であり、Ｂは偽（または存在しない）であること、Ａは偽（または存在しない）であり、Ｂは真（または存在する）であること、およびＡとＢは共に真（または存在する）であること。

さらに、「ａ」、または「ａｎ」の使用は、本明細書の実施形態の要素および構成要素を記述するために使用される。これは、単に便宜上行われるものであり、本発明の一般的な意味を与えるに過ぎない。この記述は、１つ、または少なくとも１つのものを含むように読まれるべきであり、単数形はまた、それが他の形を意味することが明らかではない限り複数も含む。

本開示を読めば、当業者であれば、ＥＨＬＯ名およびＩＰアドレスターゲティングにより媒介を通じて電子メール送信者の妥当性を検証できるシステムおよびプロセスに関する付加的で代替的な構造的かつ機能的な設計を理解されよう。したがって、特定の実施形態および用途が示され、かつ述べられてきたが、開示された実施形態は、本明細書で開示された正確な構成および構成要素に限定されないことを理解されたい。当業者には明らかなはずの様々な修正、変更、および変形は、添付の特許請求の範囲で定義される趣旨および範囲から逸脱することなく、本明細書で開示される方法および装置の配置、オペレーション、ならびにその細部に行うことができる。

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