from this practice introduces inconsistency among DMARC operators in
terms of handling of the message. However, such deviation is not
proscribed.
To enable Domain Owners to receive DMARC feedback without impacting
existing mail processing, discovered policies of “p=none” SHOULD NOT
modify existing mail disposition processing.
この認証プラクティスから逸脱した場合、メッセージ処理の観点からDMARC運用者間で矛盾が生じる。しかし、そのような逸脱は禁止されてはいない。
既存のメール処理に影響を及ぼすことなくドメイン所有者がDMARCフィードバックを受信できるようにするために、「p=none」で検索されるポリシーを使って既存のメール処理を変更すべきではない（SHOULD NOT）。
Mail Receivers SHOULD also implement reporting instructions of DMARC,
even in the absence of a request for DKIM reporting [AFRF-DKIM] or
SPF reporting [AFRF-SPF]. Furthermore, the presence of such requests
SHOULD NOT affect DMARC reporting.
メール受信者は、DKIM報告[AFRF-DKIM]またはSPF報告[AFRF-SPF]の要求がなくても、DMARC報告の命令を実行するべきである（SHOULD）。また、DKIMやSPFの報告要求があったとしても、DMARC報告に影響を及ぼすべきではない（SHOULD NOT）。
7. DMARC Feedback
Providing Domain Owners with visibility into how Mail Receivers
implement and enforce the DMARC mechanism in the form of feedback is
critical to establishing and maintaining accurate authentication
deployments. When Domain Owners can see what effect their policies
and practices are having, they are better willing and able to use
quarantine and reject policies.
7. DMARCフィードバック
メール受信者がどのようにしてDMARCのメカニズムを実装して実行するかをフィードバックの形でドメイン所有者に明らかにすることは、正確な認証展開を確立、維持するためにはきわめて重要である。ドメイン所有者は、ポリシーや認証プラクティスにどのような効果があるのかがわかれば、「quarantine」ポリシーや「reject」ポリシーをさらに進んで使用することができる。
7.1. Verifying External Destinations
It is possible to specify destinations for the different reports that
are outside the authority of the Domain Owner making the request.
This allows domains that do not operate mail servers to request
reports and have them go someplace that is able to receive and
process them.
7.1. 外部送信先の検証
さまざまなレポートの送信先として、要求を行うドメイン所有者の権限の及ばない送信先を指定することができる。これによって、メールサーバーが動作しないドメインがレポートを要求し、レポートを受信、処理することが可能な宛先に配信することができる。
Without checks, this would allow a bad actor to publish a DMARC
policy record that requests that reports be sent to a victim address,
and then send a large volume of mail that will fail both DKIM and SPF
checks to a wide variety of destinations; the victim will in turn be
flooded with unwanted reports. Therefore, a verification mechanism
is included.
このため、認証判定がない場合、悪意のある者が被害者のアドレスにレポートを送信するように要求するDMARCポリシーレコードを公開し、DKIMおよびSPFの判定に失敗となるメールを大量にさまざまな送信先に送信することが可能となり、そして被害者は、望まない大量のレポートを送りつけられることになる。したがって、外部送信先の検証メカニズムを含める。
When a Mail Receiver discovers a DMARC policy in the DNS, and the
Organizational Domain at which that record was discovered is not
identical to the Organizational Domain of the host part of the
authority component of a [URI] specified in the “rua” or “ruf” tag,
the following verification steps are to be taken:
メール受信者がDNSでDMARCポリシーを検索し、検索したレコードの組織ドメインが「rua」タグまたは「ruf」タグで指定される[URI]の権限コンポーネントのホスト部分の組織ドメインと同じではない場合、以下の検証ステップを実行する。
1. Extract the host portion of the authority component of the URI.
Call this the “destination host”, as it refers to a Report
Receiver.
2. Prepend the string “_report._dmarc”.
1. URIの権限コンポーネントのホスト部分を抽出する。
抽出された部分を「送信先ホスト」と呼び、これはレポート受信者を指す。
2. 文字列「_report._dmarc」を先頭に追加する。
[Page 28]
| 《PREV》 |