7.3. Failure Reports
Failure reports are normally generated and sent almost immediately
after the Mail Receiver detects a DMARC failure. Rather than waiting
for an aggregate report, these reports are useful for quickly
notifying the Domain Owners when there is an authentication failure.
Whether the failure is due to an infrastructure problem or the
message is inauthentic, failure reports also provide more information
about the failed message than is available in an aggregate report.
7.3. 失敗レポート
失敗レポートは、通常はメール受信者がDMARC判定の失敗を検出したほぼ直後に作成して送信する。失敗レポートは、認証失敗時にドメイン所有者に速やかに通知されるため、集約レポートが送られてくるのを待つよりは有用である。失敗レポートは、失敗がインフラの問題によるものか、あるいはメッセージが偽物であることによるものかについて、失敗となったメッセージに関する詳細情報を集約レポートよりも詳細に提供します。
These reports SHOULD include any URI(s) from the message that failed
authentication. These reports SHOULD include as much of the message
and message header as is reasonable to support the Domain Owner’s
investigation into what caused the message to fail authentication and
track down the sender.
失敗レポートには、認証失敗となったメッセージのURIを含めるべきである（SHOULD）。失敗レポートには、何が原因でメッセージが認証失敗となり、送信者を突き止めるドメイン所有者の調査をサポートするのに妥当な量のメッセージとメッセージヘッダを含めるべきである（SHOULD）。
When a Domain Owner requests failure reports for the purpose of
forensic analysis, and the Mail Receiver is willing to provide such
reports, the Mail Receiver generates and sends a message using the
format described in [AFRF]; this document updates that reporting
format, as described in Section 7.3.1.
ドメイン所有者が調査分析のために失敗レポートを要求し、かつ、メール受信者が失敗レポートを提供しても構わないと考える場合、メール受信者は、[AFRF]に記載されるフォーマットを使用してメッセージを生成して送信する。本文書では、7.3.1節に記載するように、報告フォーマットを更新している。
The destination(s) and nature of the reports are defined by the “ruf”
and “fo” tags as defined in Section 6.3.
Where multiple URIs are selected to receive failure reports, the
report generator MUST make an attempt to deliver to each of them.
レポートの送信先と種類は、6.3節で定義するように、「ruf」タグおよび「fo」タグによって定義される。
複数のURIが失敗レポートを受信する選択をしている場合、レポート作成者は各URIに配信を試行しなければならない（MUST）。
An obvious consideration is the denial-of-service attack that can be
perpetrated by an attacker who sends numerous messages purporting to
be from the intended victim Domain Owner but that fail both SPF and
DKIM; this would cause participating Mail Receivers to send failure
reports to the Domain Owner or its delegate in potentially huge
volumes. Accordingly, participating Mail Receivers are encouraged to
aggregate these reports as much as is practical, using the Incidents
field of the Abuse Reporting Format ([ARF]). Various aggregation
techniques are possible, including the following:
この際の検討事項は明らかに、狙われた被害者であるドメイン所有者からのものと称して、SPFおよびDKIMの両判定に失敗となるメッセージを多数送信する攻撃者によるサービス妨害攻撃である。この攻撃によって、DMARCを適用するメール受信者がドメイン所有者またはその代理者に失敗レポートを大量に送信される可能性がある。したがって、DMARCを適用するメール受信者には、不正使用報告フォーマット([ARF]))のIncidentsフィールドを使用して、これらのレポートをできるだけ実用的となるように集約することを推奨する。さまざまな集約処理方法が可能であり、以下に例を挙げる。
o only send a report to the first recipient of multi-recipient
messages;
o store reports for a period of time before sending them, allowing
detection, collection, and reporting of like incidents;
o apply rate limiting, such as a maximum number of reports per
minute that will be generated (and the remainder discarded).
o 単に、複数のメッセージ受信者の最初の受信者にレポートを送信する。
o 送信前に一定期間レポートを保存し、同じようなエラーの検出、収集および報告を許可する。
o 1分当りの最大レポート作成数(それ以上は破棄)などの作成量の制限を適用する。
[Page 36]
| 《PREV》 |