メインコンテンツまでスキップ

5. Mechanism Definitions (メカニズム定義)

5. Mechanism Definitions (メカニズム定義)​

このセクションでは、2つのタイプのメカニズムを定義します:基本言語フレームワークメカニズムと送信者指定メカニズム。

基本メカニズムは言語フレームワークを容易にします。特定のタイプの認証スキームを指定しません。基本メカニズムは次のとおりです:

all
include

送信者指定メカニズムは、<domain>でメールを送信することが許可されている、または許可されていない<ip>アドレスのセットを識別するために使用されます。送信者指定メカニズムは次のとおりです:

a
mx
ptr (do not use)
ip4
ip6
exists

次の規則は、<target-name>とIPアドレスの比較をいつでも実行するすべてのメカニズムに適用されます:

ディレクティブにCIDRプレフィックス長が指定されていない場合、<target-name>はIPアドレスと等しいかどうかで比較されます。(ここで、CIDRは[RFC4632]で説明されているクラスレスドメイン間ルーティングです。)

CIDRプレフィックス長が指定されている場合、<target-name>の指定された数の上位ビットのみがIPアドレスと等しいかどうかで比較されます。

メカニズムが<ip>と比較するホストアドレスを取得する場合、<ip>がIPv4の場合は"A"レコードが取得され、<ip>がIPv6アドレスの場合は"AAAA"レコードが取得されます。IPv6サーバー上のSPF実装は、IPv4マップIPv6アドレス上のクライアントの"AAAA"と"A"レコードの両方を処理する必要があります[RFC4291]。IPv4アドレスは、"ip4"メカニズムを使用してSPFレコードにのみリストされます。

いくつかのメカニズムは、DNSから取得された情報に依存しています。これらのDNSクエリについて、特に指定されていない限り、DNSサーバーがエラーを返す場合(RCODEが0でも3でもない)、またはクエリがタイムアウトする場合、メカニズムは停止し、最上位のcheck_host()は"temperror"を返します。サーバーが"Name Error"(RCODE 3)を返す場合、メカニズムの評価は、サーバーがエラーなし(RCODE 0)とゼロ応答レコードを返したかのように続行されます。

5.1 "all"​

all = "all"

"all"メカニズムは常に一致するテストです。レコード内の最も右のメカニズムとして使用され、明示的なデフォルト値を提供します。

例:

v=spf1 a mx -all

"all"の後のメカニズムはテストされません。"all"の後にリストされているメカニズムは無視する必要があります。レコードに"all"メカニズムが存在する場合、用語の相対的な順序に関係なく、すべての"redirect"修飾子(セクション6.1)を無視する必要があります。

5.2 "include"​

include = "include" ":" domain-spec

"include"メカニズムは、check_host()の再帰的評価をトリガーします。

  1. <domain-spec>はセクション7に従って展開されます。

  2. check_host()は、結果の文字列を<domain>として評価されます。<ip>および<sender>パラメータは、check_host()の現在の評価と同じままです。

  3. 再帰的評価は、一致、不一致、またはエラーを返します。

  4. 一致を返す場合、"include"メカニズムは適切な結果を使用します(たとえば、includeまたは+includeは"pass"結果を生成し、-includeは"fail"を生成します)。

  5. 不一致またはエラーを返す場合、親check_host()は次の表に従って処理を再開し、以前の<domain>値を復元します。

振り返ってみると、"include"という名前は悪い選択でした。参照されたSPFレコードの評価結果のみが使用され、最初のレコードに参照されたレコードのメカニズムを文字通り含めるのではありません。たとえば、参照されたレコードで"-all"ディレクティブを評価しても、全体的な処理は終了せず、必ずしも全体的な"fail"にはなりません。(このメカニズムのより良い名前は"if-match"、"on-match"などだったでしょう。)

"include"メカニズムにより、ドメインは複数の管理上独立したドメインを指定できます。たとえば、バニティドメイン"example.net"は、管理上独立したドメインexample.comとexample.orgのサーバーを使用してメールを送信できます。

Example.netは次のように言えます

IN TXT "v=spf1 include:example.com include:example.org -all"

これにより、check_host()はexample.comとexample.orgのレコードを効果的にチェックして"pass"結果を得るように指示されます。これら2つのドメインのいずれによってもホストが許可されていない場合にのみ、結果は"fail"になります。

このメカニズムが一致するか、一致しないか、または例外を返すかは、check_host()の再帰的評価の結果に依存します:

+---------------------------------+---------------------------------+
| A recursive check_host() result | Causes the "include" mechanism |
| of:                             | to:                            |
+---------------------------------+---------------------------------+
| pass                            | match                          |
|                                 |                                |
| fail                            | not match                      |
|                                 |                                |
| softfail                        | not match                      |
|                                 |                                |
| neutral                         | not match                      |
|                                 |                                |
| temperror                       | return temperror               |
|                                 |                                |
| permerror                       | return permerror               |
|                                 |                                |
| none                            | return permerror               |
+---------------------------------+---------------------------------+

"include"メカニズムは、管理境界を越えることを目的としています。単一の管理当局内にとどまる場合、"include"は通常最良の選択ではありません。たとえば、example.comとexample.orgが同じエンティティによって管理されており、両方のドメインの許可されたホストのセットが"mx:example.com"である場合、example.orgは"include:example.com"を指定できますが、"redirect=example.com"または"mx:example.com"を指定する方が良いでしょう。

"include"メカニズムを使用すると、管理上外部のホストのセットを承認できますが、送信者ポリシーの決定は元のドメインのSPFレコードの機能のままです(そのレコードの"all"メカニズムによって決定されます)。"redirect"修飾子は、ADMD内で共有される共通のセットに認証とポリシーを統合するのにより適しています。Redirectは、単一のADMD内のレコード間で共有される共通のコード要素に似ています。任意の数のドメインの承認されたホストとポリシーは、単一のレコードから制御できます。

5.3 "a"​

このメカニズムは、<ip>が<target-name>のIPアドレスの1つである場合に一致します。明確にするために、これは"a"メカニズムがAAAAレコードにも一致することを意味します。

a = "a" [ ":" domain-spec ] [ dual-cidr-length ]

<target-name>のアドレスクエリが実行され、接続タイプ(IPv4またはIPv6)に適したクエリタイプ(AまたはAAAA)が使用されます。<ip>は返されたアドレスと比較されます。アドレスが一致する場合、メカニズムは一致します。

5.4 "mx"​

このメカニズムは、<ip>がドメイン名のMXホストの1つである場合に一致します。

mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ]

check_host()は最初に<target-name>のMXクエリを実行します。次に、返された各MX名のアドレスクエリを実行します。<ip>は返された各IPアドレスと比較されます。サービス拒否(DoS)攻撃を防ぐために、セクション4.6.4で定義された処理制限を遵守する必要があります。MXクエリ制限を超えた場合、"permerror"が返され、評価は終了します。アドレスが一致する場合、メカニズムは一致します。

暗黙のMXに関する注意:<target-name>にMXレコードがない場合、check_host()は[RFC5321]の暗黙のMXルールを適用してはなりません。つまり、同じ名前のAまたはAAAAレコードを照会してはなりません。

5.5 "ptr" (do not use) ("ptr" (使用しない))​

このメカニズムは、<ip>のDNS逆マッピングが存在し、特定のドメイン内のドメイン名に正しく指しているかどうかをテストします。このメカニズムは公開すべきではありません。詳細については、このセクションの最後の注記を参照してください。

ptr = "ptr" [ ":" domain-spec ]

<ip>の名前は、次の手順を使用して検索されます:

  • <ip>のDNS逆マッピングを実行します:アドレスがIPv4の場合は"in-addr.arpa."で対応するPTRレコードを検索し、IPv6の場合は"ip6.arpa."で検索します。

  • 返された各レコードについて、そのIPアドレスを検索してドメイン名を検証します。DoS攻撃を防ぐために、セクション4.6.4で定義されたPTR処理制限を適用する必要があります。制限を超えた場合、処理を終了し、メカニズムは一致しません。

  • <ip>が返されたIPアドレスにある場合、このドメイン名は検証されます。

すべての検証されたドメイン名をチェックして、それらが<target-name>と一致するか、<target-name>のサブドメインであるかを確認します。一致がある場合、このメカニズムは一致します。検証されたドメイン名が見つからない場合、または検証されたドメイン名が<target-name>と一致しないか、そのサブドメインでない場合、このメカニズムは一致できません。PTR RRクエリの実行中にDNSエラーが発生した場合、このメカニズムは一致できません。A RRクエリの実行中にDNSエラーが発生した場合、そのドメイン名はスキップされ、検索は続行されます。

このメカニズムは次の場合に一致します:

  • <target-name>が検証されたドメイン名のサブドメインである、または

  • <target-name>と検証されたドメイン名が同一である。

たとえば、"mail.example.com"はドメイン"example.com"内にありますが、"mail.bad-example.com"はそうではありません。

注意:このメカニズムは遅く、DNSエラーの場合に他のメカニズムほど信頼性がなく、.arpaネームサーバーに大きな負荷をかけます。使用する場合、ドメインのホストに適切なPTRレコードを設定する必要があり、"ptr"メカニズムは最後にチェックされるメカニズムの1つである必要があります。数年間のSPF展開経験の後、それは不要であり、より信頼性の高い代替手段を使用すべきであるという結論に達しました。ただし、それはSPFプロトコルの一部として残っているため、適合するcheck_host()実装はそれをサポートする必要があります。

5.6 "ip4" and "ip6" ("ip4"と"ip6")​

これらのメカニズムは、<ip>が指定されたIPネットワークに含まれているかどうかをテストします。

ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]

ip4-cidr-length = "/" ("0" / %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" ("0" / %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT                      ; 0-9
     / %x31-39 DIGIT              ; 10-99
     / "1" 2DIGIT                 ; 100-199
     / "2" %x30-34 DIGIT          ; 200-249
     / "25" %x30-35               ; 250-255
     ; as per conventional dotted-quad notation, e.g., 192.0.2.0

ip6-network = <as per [RFC5952], Section 4>
            ; e.g., 2001:db8::cd30

<ip>を指定されたネットワークと比較します。CIDRプレフィックス長の上位ビットが一致する場合、メカニズムは一致します。

ip4-cidr-lengthが省略されている場合、"/32"として扱われます。ip6-cidr-lengthが省略されている場合、"/128"として扱われます。CIDR表記を使用する代わりにIPアドレスの一部を省略することは許可されていません。つまり、192.0.2の代わりに192.0.2.0/24を使用します。

5.7 "exists"​

このメカニズムは、DNS Aレコードクエリ用の任意のドメイン名を構築するために使用されます。メールエンベロープの任意の部分を含む複雑なスキームを許可して、何が許可されるかを決定します。

exists = "exists" ":" domain-spec

<domain-spec>はセクション7に従って展開されます。結果のドメイン名は、DNS A RRクエリに使用されます(接続タイプがIPv6であっても)。Aレコードが返された場合、このメカニズムは一致します。

ドメインは、このメカニズムを使用して任意に複雑なクエリを指定できます。たとえば、example.comが次のレコードを公開しているとします:

v=spf1 exists:%\{ir}.%\{l1r+-}._spf.%\{d} -all

<target-name>は"1.2.0.192.someuser._spf.example.com"に展開される可能性があります。これにより、ユーザーとクライアントIPアドレスレベルできめ細かい決定を行うことができます。

に最終更新