Such policy changes are expected to be infrequent for any given
domain, whereas more stringent policy monitoring requirements on the
Mail Receiver would produce a very large burden at Internet scale.
Therefore, it is the responsibility of report consumers and Domain
Owners to be aware of this situation and allow for such mixed reports
during the propagation of the new policy to Mail Receivers.
そのようなポリシー変更はどのドメインに対してもほとんど起きないと考えられるが、メール受信者のポリシー監視要件が厳しくなると、インターネットにかかる負荷がきわめて大きくなると考えられる。それゆえ、このような状況に配慮し、メール受信者に新しいポリシーを通知する間は、通常時とポリシー更新時の両レポートを許可することは、レポート消費者およびドメイン所有者の責任である。
Aggregate reports are most useful when they all cover a common time
period. By contrast, correlation of these reports from multiple
generators when they cover incongruent time periods is difficult or
impossible. Report generators SHOULD, wherever possible, adhere to
hour boundaries for the reporting period they are using. For
example, starting a per-day report at 00:00; starting per-hour
reports at 00:00, 01:00, 02:00; etc. Report generators using a
24-hour report period are strongly encouraged to begin that period at
00:00 UTC, regardless of local timezone or time of report production,
in order to facilitate correlation.
集約レポートは、共通の時間をカバーする場合に最も有用である。一方、複数のレポート作成者からのレポートが異なる周期で生成される場合、これらのレポートを相互に関連付けることは、困難または不可能である。レポート作成者は、可能な限り、使用している報告期間の時間境界を忠実に守るべきである（SHOULD）。例えば、1日1回のレポートは00:00に開始し、1時間毎のレポートは00:00、01:00、02:00などに開始する。24時間のレポート期間を適用するレポート作成者は、ローカルタイムゾーンまたはレポート作成時間を問わず、相互に関連付けることを容易にするため、UTC時間の00:00に開始することを強く推奨する。
A Mail Receiver discovers reporting requests when it looks up a DMARC
policy record that corresponds to an RFC5322.From domain on received
mail. The presence of the “rua” tag specifies where to send
feedback.
メール受信者は、受信メールのRFC5322.Fromドメインに対応するDMARCポリシーレコードを参照する際に報告要求を検索する。「rua」タグが存在すれば、フィードバックの送信先を特定することができる。
7.2.1. Transport
Where the URI specified in a “rua” tag does not specify otherwise, a
Mail Receiver generating a feedback report SHOULD employ a secure
transport mechanism.
7.2.1. レポート送信
「rua」タグに指定されるURIが明記されていない場合、フィードバックレポートを作成するメール受信者は安全な送信メカニズムを用いるべきである（SHOULD）。
The Mail Receiver, after preparing a report, MUST evaluate the
provided reporting URIs in the order given. Any reporting URI that
includes a size limitation exceeded by the generated report (after
compression and after any encoding required by the particular
transport mechanism) MUST NOT be used. An attempt MUST be made to
deliver an aggregate report to every remaining URI, up to the
Receiver’s limits on supported URIs.
メール受信者は、レポートを作成後に所定の順で、提供された報告URIを評価しなければならない（MUST）。(圧縮後、特定の送信メカニズムが要求するエンコード後の)生成したレポートのサイズ制限を超過した報告URIは使用してはならない（MUST NOT）。メール受信者がサポートするURIの制限数までは、残りすべてのURIに集約レポートの配信を試みなければならない（MUST）。
If transport is not possible because the services advertised by the
published URIs are not able to accept reports (e.g., the URI refers
to a service that is unreachable, or all provided URIs specify size
limits exceeded by the generated record), the Mail Receiver SHOULD
send a short report (see Section 7.2.2) indicating that a report is
available but could not be sent. The Mail Receiver MAY cache that
data and try again later, or MAY discard data that could not be sent.
公開したURIによって通知されたサービスが、レポートを受け付けることができない
(例えば、URIが到達不能のサービスを参照するか、あるいは特定されたURIがすべて特定するサイズ制限を、生成されたレコードが超えている)ために送信ができない場合、メール受信者は、レポートは有効であるが送信できなかったことを示す短いレポート(7.2.2節を参照)を送信するべきである（SHOULD）。メール受信者はそのデータをキャッシュして後で再試行してよいし（MAY）、送信できなかったデータを破棄してもよい（MAY）。
[Page 32]
| 《PREV》 |