this MUST NOT be applied to the DMARC-generated reports, all of
which must be sent and received unhindered. The purpose of the
“pct” tag is to allow Domain Owners to enact a slow rollout
enforcement of the DMARC mechanism. The prospect of “all or
nothing” is recognized as preventing many organizations from
experimenting with strong authentication-based mechanisms. See
Section 6.6.4 for details. Note that random selection based on
this percentage, such as the following pseudocode, is adequate:
if (random mod 100) < pct then
selected = true
else
selected = false
但し、DMARCが作成したレポートは、全て制約を受けずに送受信されなければならないため、DMARCが作成したレポートに適用してはならない（MUST NOT）。pctタグの目的は、ドメイン所有者がDMARCのメカニズムのロールアウトに時間をかけることができるようにすることである。「オール・オア・ナッシング（ポリシーを適用する割合を、0か100とした場合）」の見通しは、多くの団体が強力な認証メカニズムを実験することを阻むことになると認識されている。詳細に関しては、6.6.4節を参照していただきたい。以下に示す擬似コードのように、この割合による無作為抽出が適切であることに留意していただきたい。
if (random mod 100) < pct then
selected = true
else
selected = false
rf: Format to be used for message-specific failure reports (colon-
separated plain-text list of values; OPTIONAL; default is "afrf").
The value of this tag is a list of one or more report formats as
requested by the Domain Owner to be used when a message fails both
[SPF] and [DKIM] tests to report details of the individual
failure. The values MUST be present in the registry of reporting
formats defined in Section 11; a Mail Receiver observing a
different value SHOULD ignore it or MAY ignore the entire DMARC
record. For this version, only "afrf" (the auth-failure report
type defined in [AFRF]) is presently supported. See Section 7.3
for details. For interoperability, the Authentication Failure
Reporting Format (AFRF) MUST be supported.
rf: メッセージ特有の失敗レポートに用いるフォーマット(コロンで区切ったプレーンテキストの値リスト、任意、デフォルト値：「afrf」)。このタグの値は、ドメイン所有者が要求する1つ以上のレポートフォーマットのリストであり、[SPF]および[DKIM]の判定に失敗となったメッセージに関して個々の失敗の詳細をレポートする場合に使用する。この値は、11節で定義する報告フォーマットのレジストリに存在していなければならない（MUST）。異なる値を観測したメール受信者は、このタグの値を無視するべきであり（SHOULD）、DMARCレコード全体を無視してもよい（MAY）。本バージョンでは、「afrf」([AFRF]で定義されるauth-failureレポートタイプ)のみをサポートする。詳細に関しては、7.3節を参照していただきたい。相互運用性の観点から、認証失敗報告フォーマット(AFRF)をサポートしなければならない（MUST）。
ri: Interval requested between aggregate reports (plain-text 32-bit
unsigned integer; OPTIONAL; default is 86400). Indicates a
request to Receivers to generate aggregate reports separated by no
more than the requested number of seconds. DMARC implementations
MUST be able to provide daily reports and SHOULD be able to
provide hourly reports when requested. However, anything other
than a daily report is understood to be accommodated on a best-
effort basis.
ri: 集約レポート作成の要求間隔(プレーンテキスト、32ビット符号なし整数型、任意、デフォルト値：86400)。指定した要求間隔を超えない間隔で集約レポートを作成するようにメール受信者に要求することを示す。DMARCを実装した場合、レポートは毎日1回提供しなければならず（MUST）、要求に応じて1時間毎に提供すべきである（SHOULD）。ただし、毎日1回のレポート以外は、最善努力の原則に基づいて提供されるものと解釈する。
rua: Addresses to which aggregate feedback is to be sent (comma-
separated plain-text list of DMARC URIs; OPTIONAL). A comma or
exclamation point that is part of such a DMARC URI MUST be encoded
per Section 2.1 of [URI] so as to distinguish it from the list
delimiter or an OPTIONAL size limit. Section 7.1 discusses
considerations that apply when the domain name of a URI differs
from that of the domain advertising the policy. See Section 12.5
for additional considerations. Any valid URI can be specified. A
Mail Receiver MUST implement support for a "mailto:" URI, i.e.,
the ability to send a DMARC report via electronic mail. If not
rua: 集約フィードバックが送信されるアドレス(プレーンテキスト、コンマで区切ったDMARC URIのリスト、任意)。そのようなDMARC URIに含まれるコンマまたは感嘆符は、リストのデリミターや任意のサイズ制限値と区別するために、[URI] の2.1節に従ってエンコードしなければならない（MUST）。7.1節に、URIのドメイン名がポリシーを通知するドメインと異なる場合に適用される検討事項に関して記載する。他の検討事項に関しては、12.5節を参照していただきたい。あらゆる有効なURIを指定することができる。メール受信者は、「mailto:」のURIのサポート、すなわち電子メールでDMARCレポートを送信する機能を実装しなければならない（MUST）。
[Page 19]
| 《PREV》 |