6. Modifier Definitions (修飾子定義)

修飾子は、追加情報を提供する名前と値のペアです。修飾子には常に名前と値を区切る"="があります。

このドキュメントで定義されている修飾子("redirect"と"exp")は、レコードの最後、すべてのメカニズムの後に表示されるべきですが、構文的にはレコード内のどこにでも表示できます。これら2つの修飾子の順序は無関係です。これら2つの修飾子は、レコード内に絶対に1回を超えて表示してはなりません。もし表示された場合、check_host()は"permerror"結果で終了します。

認識されない修飾子は、どこに表示されても、何回表示されても、無視する必要があります。これにより、このドキュメントに準拠する実装は、他の仕様で定義された修飾子を持つレコードを適切に処理できます。

6.1 redirect: Redirected Query (redirect: リダイレクトされたクエリ)

"redirect"修飾子は、単一のADMD内で共有される共通のセットに認証とポリシーを統合することを目的としています。任意の数のドメインの承認されたホストとポリシーは、単一のレコードから制御できます。

redirect = "redirect" "=" domain-spec

すべてのメカニズムが一致せず、"redirect"修飾子が存在する場合、処理は次のように進行します:

redirectの<domain-spec>部分は、セクション7のマクロルールに従って展開されます。次に、check_host()は結果の文字列を<domain>として評価されます。<ip>および<sender>パラメータは、check_host()の現在の評価と同じままです。

この新しいcheck_host()評価の結果は、現在の評価の結果として扱われますが、SPFレコードが見つからない場合、または<target-name>が誤って形式化されている場合、結果は"none"ではなく"permerror"です。

新しいクエリのドメイン自体がredirect処理を指定できることに注意してください。

このツールは、同じレコードを複数のドメインに適用したい組織を対象としています。例:

la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"

この例では、これら3つのドメインのいずれかからのメールは、同じレコードによって記述されます。これは管理上の利点となる可能性があります。

注意:一般的に、ドメイン"A"は、同じ管理制御下にない別のドメイン"B"へのリダイレクトを確実に使用できません。<domain>は変更されないため、ドメイン"B"のレコードがドメイン"A"のメールボックスに対して正しく機能する保証はありません。特に、ドメイン"B"がlocal-partを含むメカニズムを使用している場合です。"include"ディレクティブの方が一般的に適切です。

明確にするために、すべての"redirect"修飾子は、レコードの最後の用語として表示されるべきです。レコード内のどこかに"all"メカニズムが存在する場合、すべての"redirect"修飾子を無視する必要があります。

6.2 exp: Explanation (exp: 説明)

explanation = "exp" "=" domain-spec

check_host()が一致するメカニズム("-all"など)のために"fail"になり、"exp"修飾子が存在する場合、返される説明文字列は以下のように計算されます。"exp"修飾子が存在しない場合、デフォルトの説明文字列または空の説明文字列を呼び出し元アプリケーションに返す必要があります。

<domain-spec>はマクロ展開を受けます(セクション7を参照)、そして<target-name>になります。<target-name>のDNS TXT RRsetが取得されます。

DNSの処理エラーがある場合(RCODE 0以外)、レコードが返されない場合、複数のレコードが返される場合、または説明文字列に構文エラーがある場合、"exp"修飾子が与えられていないかのように続行します。

取得されたTXTレコードの文字列は、スペースなしで連結され、その後explain-stringとして処理され、マクロ展開を受けます。この最終結果が説明文字列です。実装は、他のプロトコル制約および/または合理的な処理制限を考慮して、結果の説明文字列の長さを制限できます(MAY)。説明文字列はSMTP応答で使用することを目的としており、[RFC5321]のセクション2.4は応答が[US-ASCII]であると述べているため、説明文字列は[US-ASCII]に制限する必要があります。

check_host()を評価するソフトウェアは、この文字列を使用して、短いメッセージまたはURLの形式で公開ドメインから情報を伝達できます。ソフトウェアは、説明文字列が第三者から来ていることを明確にする必要があります。たとえば、セクション8.4の例に示されているように、マクロ文字列"%\{o} explains: "を説明の前に付けることができます。

example.comに次のレコードがあるとします:

v=spf1 mx -all exp=explain._spf.%\{d}

以下は、explain._spf.example.comでの可能な説明TXTレコードの例です:

"Mail from example.com should only be sent by its own servers."

-- シンプルで一定のメッセージ

"%\{i} is not one of %\{d}'s designated mail servers."

-- チェックに失敗したIPアドレスを含む、より多くの情報を含むメッセージ

"See http://%\{d}/why.html?s=%\{S}&i=%\{I}"

-- check_host()のパラメータを使用してURLを構築する複雑な例で、詳細でカスタマイズされた手順を含むWebページを生成できるようにします

注意:"include"メカニズムへの再帰中、<target-name>からの"exp"修飾子は絶対に使用してはなりません。逆に、"redirect"修飾子を実行する場合、元のドメインからの"exp"修飾子は絶対に使用してはなりません。これは、"include"が管理境界を越えることを目的としており、提供される説明は受信ADMDからのものであるべきであるのに対し、"redirect"はADMD内でポリシーレコードを統合するツールとして意図されており、したがってリダイレクトされた説明が優先されるべきものだからです。