3. Prepend the domain name from which the policy was retrieved,
after conversion to an A-label if needed.
4. Query the DNS for a TXT record at the constructed name. If the
result of this request is a temporary DNS error of some kind
(e.g., a timeout), the Mail Receiver MAY elect to temporarily
fail the delivery so the verification test can be repeated later.
3. ポリシーが読み出されたドメイン名を、必要に応じてAラベルに変換後、先頭に追加する。
4. 作成された名前のTXTレコードをDNSに問い合わせる。この要求の結果がDNSの一時的なエラー(例えば、タイムアウト)である場合、メール受信者は、再度検証判定を行うことができるように、配信が一時的に失敗するように選択してもよい（MAY）。
5. For each record returned, parse the result as a series of
“tag=value” pairs, i.e., the same overall format as the policy
record (see Section 6.4). In particular, the “v=DMARC1” tag is
mandatory and MUST appear first in the list. Discard any that do
not pass this test.
5. 返された各レコードに対して、一連の「タグ=値」のペア、すなわち、ポリシーレコード(6.4節を見る)と全体として同じフォーマットとして結果を解析する。特に、「v=DMARC1」タグは必須であり、リストの最初に現れなければならない（MUST）。この判定に成功しないレコードは破棄する。
6. If the result includes no TXT resource records that pass basic
parsing, a positive determination of the external reporting
relationship cannot be made; stop.
7. If at least one TXT resource record remains in the set after
parsing, then the external reporting arrangement was authorized
by the Report Receiver.
6. 基本的な解析に成功するTXTリソースレコードが結果に含まれていない場合、外部の報告関係に対して肯定判定をすることができず、処理は終了する。
7. 解析後に少なくとも1つのTXTリソースレコードが結果に含まれている場合、外部の報告構成はレポート受信者によって許可されたことになる。
8. If a “rua” or “ruf” tag is thus discovered, replace the
corresponding value extracted from the domain’s DMARC policy
record with the one found in this record. This permits the
Report Receiver to override the report destination. However, to
prevent loops or indirect abuse, the overriding URI MUST use the
same destination host from the first step.
8. 「rua」タグまたは「ruf」タグが検索される場合、そのドメインのDMARCポリシーレコードから抽出した対応値をこのレコードに存在する値で置き換える。これによって、レポート受信者はレポート送信先をオーバーライドすることができる。しかし、ループや間接的な不正使用を防ぐため、オーバーライドするURIはステップ1と同じ送信先ホストを使用しなければならない（MUST）。
For example, if a DMARC policy query for “blue.example.com” contained
“rua=mailto:reports@red.example.net”, the host extracted from the
latter (“red.example.net”) does not match “blue.example.com”, so this
procedure is enacted. A TXT query for
“blue.example.com._report._dmarc.red.example.net” is issued. If a
single reply comes back containing a tag of “v=DMARC1”, then the
relationship between the two is confirmed. Moreover,
“red.example.net” has the opportunity to override the report
destination requested by “blue.example.com” if needed.
例えば、「blue.example.com」のDMARCポリシークエリが「rua=mailto: reports@red.example.net 」を含んでいた場合、後者から抽出したホスト(「red.example.net」)は「blue.example.com」と一致しないため、オーバーライドの手続きを実行する。「blue.example.com._report._dmarc.red.example.net」を問い合わせるTXTクエリを発行する。「v=DMARC1」タグを含んだ応答がただ1つ返される場合、両者の間の関係は確認されたことになる。さらに必要に応じて、「red.example.net」は、「blue.example.com」によって要求されたレポート送信先をオーバーライドすることが可能である。
Where the above algorithm fails to confirm that the external
reporting was authorized by the Report Receiver, the URI MUST be
ignored by the Mail Receiver generating the report. Further, if the
confirming record includes a URI whose host is again different than
the domain publishing that override, the Mail Receiver generating the
report MUST NOT generate a report to either the original or the
override URI.
上記のアルゴリズムによって、外部の報告構成がレポート受信者によって許可されたことが確認できない場合、レポートを作成するメール受信者は、そのURIを無視しなければならない（MUST）。さらに、ホストがそのオーバーライドを公開するドメインと依然として異なるURIが、確認するレコードに含まれている場合、レポートを作成するメール受信者は、元のURIまたはオーバーライドしたURIに対してレポートを作成してはならない（MUST NOT）。
[Page 29]
| 《PREV》 |