A Mail Receiver implementing the DMARC mechanism SHOULD make a
best-effort attempt to adhere to the Domain Owner’s published DMARC
policy when a message fails the DMARC test. Since email streams can
be complicated (due to forwarding, existing RFC5322.From
domain-spoofing services, etc.), Mail Receivers MAY deviate from a
Domain Owner’s published policy during message processing and SHOULD
make available the fact of and reason for the deviation to the Domain
Owner via feedback reporting, specifically using the “PolicyOverride”
feature of the aggregate report (see Section 7.2).
DMARCのメカニズムを実装するメール受信者は、メッセージがDMARC判定に失敗となる場合、ドメイン所有者が公開したDMARCポリシーに従うように最大限の努力をすべきである（SHOULD）。電子メールストリームを複雑にすることが可能である(転送や、既存のRFC5322.Fromドメインなりすましサービスなど)ことから、メール受信者はメッセージ処理時にドメイン所有者が公開したポリシーに従わなくてもよいが（MAY）、フィードバック報告によって、具体的には、集約レポート(7.2節を参照)の「ポリシーオーバーライド」の機能を使用して、ドメイン所有者にその事実と理由を知らせるようにするべきである（SHOULD）。
6.1. DMARC Policy Record
Domain Owner DMARC preferences are stored as DNS TXT records in
subdomains named “_dmarc”. For example, the Domain Owner of
“example.com” would post DMARC preferences in a TXT record at
“_dmarc.example.com”. Similarly, a Mail Receiver wishing to query
for DMARC preferences regarding mail with an RFC5322.From domain of
“example.com” would issue a TXT query to the DNS for the subdomain of
“_dmarc.example.com”. The DNS-located DMARC preference data will
hereafter be called the “DMARC record”.
6.1. DMARCポリシーレコード
ドメイン所有者のDMARCのプリファレンスは、「_dmarc」という名のサブドメインにDNS TXTレコードとして保存される。例えば、「example.com」のドメイン所有者は、TXTレコードにDMARCのプリファレンスを記述して「_dmarc.example.com」とする。同じように、RFC5322.Fromドメインが「example.com」のメールに関してDMARCのプリファレンスの問い合わせを望むメール受信者は、「_dmarc.example.com」のサブドメインに対してTXTクエリをDNSに発行する。本文書では、DNSが見つけたDMARCのプリファレンスデータを「DMARCレコード」と呼ぶ。
DMARC’s use of the Domain Name Service is driven by DMARC’s use of
domain names and the nature of the query it performs. The query
requirement matches with the DNS, for obtaining simple parametric
information. It uses an established method of storing the
information, associated with the target domain name, namely an
isolated TXT record that is restricted to the DMARC context. Use of
the DNS as the query service has the benefit of reusing an extremely
well-established operations, administration, and management
infrastructure, rather than creating a new one.
DMARCによるドメインネームサービスの使用は、DMARCが使用するドメイン名とDMARCが実行するクエリの種類に左右される。簡単なパラメータ情報を取得するために、クエリの要件はDNSと一致させる。クエリの要件は、ターゲットドメイン名、すなわちその使用がDMARCの文脈に限定される単独のTXTレコードに関連付けて、情報を保存するという確立した方法を使用している。クエリサービスとしてDNSを使用すると、操作、運用および管理体制を新たに創り出すより、すでに十分確立したものを再利用できるという利点がある。
Per [DNS], a TXT record can comprise several “character-string”
objects. Where this is the case, the module performing DMARC
evaluation MUST concatenate these strings by joining together the
objects in order and parsing the result as a single string.
[DNS]に従って、TXTレコードにはいくつかの「文字列」オブジェクトを含めることができる。この場合、DMARC判定を実行するモジュールは、順番にオブジェクトを結合して、その結果を解析することによって、これらの文字列を連結して単一の文字列にしなければならない（MUST）。
6.2. DMARC URIs
[URI] defines a generic syntax for identifying a resource. The DMARC
mechanism uses this as the format by which a Domain Owner specifies
the destination for the two report types that are supported.
6.2. DMARC URI
[URI] はリソースを識別するための一般構文を定義する。DMARCのメカニズムは、サポートする2つのレポートタイプの送信先をドメイン所有者が指定するフォーマットとしてURIを使用する。
The place such URIs are specified (see Section 6.3) allows a list of
these to be provided. A report is normally sent to each listed URI
in the order provided by the Domain Owner. Receivers MAY impose a
limit on the number of URIs to which they will send reports but MUST
support the ability to send to at least two. The list of URIs is
separated by commas (ASCII 0x2C).
そのようなURIを記述する場所(6.3節を参照)には、URIをリスト化することが可能である。レポートは通常、ドメイン所有者がリスト内で指定した順に各URIに送信する。メール受信者は、レポートを送信するURIの数に制限を設けてもよいが（MAY）、少なくとも2つのURIに送信する機能をサポートしなければならない（MUST）。URIのリストは、コンマ(ASCIIコード0x2C)で区切る。
[Page 16]
| 《PREV》 |