跳到主要内容

3.5. 报告投递

Mail Receiver 在准备好 report 后, MUST 按给定顺序评估所提供的 reporting URIs. 参见 [RFC9989]. 如果任何 URI 格式错误, 则 SHOULD 忽略它们. MUST 尝试向每个剩余 URI 投递 aggregate report, 直到达到 Receiver 对受支持 URIs 的限制.

如果由于已发布 URIs 所通告的服务无法接受 reports 而不能投递, 例如 URI 指向不可达服务, Mail Receiver MAY 缓存该数据并稍后重试, 或者 MAY 丢弃无法发送的数据.

当 "rua" tag 中指定的 URI 未另行说明时, 生成 feedback report 的 Mail Receiver SHOULD 使用安全传输机制, 即 report 应通过采用 TLS 的 channel 投递 (SMTP+STARTTLS).

3.5.1. Report-ID 的定义​

此 identifier 对发送到同一 domain 的 reports MUST 唯一, 以便 receivers 在 duplicate reports 发生时识别它们. Report-ID 值应使用以下 ABNF 构造:

ridfmt =  (dot-atom-text ["@" dot-atom-text]) ; from RFC 5322

ridtxt =  ("<" ridfmt ">") / ridfmt

此处指定的格式并不非常严格, 因为核心目标是唯一性. 为了创建这种唯一性, Mail Receiver 可能希望组合使用 receiving domain, sending domain, timestamp 等元素. 示例字符串可以是 "[email protected]". 另一种形式可以使用日期字符串, 例如 "[email protected]".

3.5.2. Email​

Mail Receiver 生成的消息 MUST 如 [RFC5322] 所述, 并按 [RFC2045] 格式化. aggregate report 本身 MUST 包含在消息的某个 part 中, 作为带有下列相应 media type 的 attachment. MAY 将 human-readable annotation 作为 body part 包含在内, 并使用面向人类友好的 content-type, 例如 "text/plain" 或 "text/html".

aggregate data MUST 是 XML file, 且 SHOULD 经 GZIP [RFC1952] 压缩. 拒绝应用压缩可能导致 report 过大而 receiver 无法处理, 例如 total message size 可能超过 receiver SMTP size limit. 执行压缩会以一定计算成本提高 report 被接受的概率. 如果经过压缩, aggregate data MUST 使用 media type "application/gzip" 呈现. 参见 [RFC6713]. 否则 MUST 使用 "text/xml". attachment filename MUST 使用以下 ABNF 构造:

filename = receiver "!" policy-domain "!" begin-timestamp
           "!" end-timestamp [ "!" unique-id ] "." extension

receiver = domain-name
           ; imported from RFC 6376

policy-domain   = domain-name

begin-timestamp = 1*DIGIT
                  ; seconds since 00:00:00 UTC January 1, 1970
                  ; indicating start of the time range contained
                  ; in the report

end-timestamp = 1*DIGIT
                ; seconds since 00:00:00 UTC January 1, 1970
                ; indicating end of the time range contained
                ; in the report

unique-id = 1*(ALPHA / DIGIT)

extension = "xml" / "xml.gz"

以下使用但未另行指定的 primitive tokens 取自 "Core Rules" ([RFC5234] Appendix B.1): DIGIT, ALPHA.

extension 对于普通 XML file MUST 为 "xml", 对于使用 GZIP 压缩的 XML file MUST 为 "xml.gz".

"unique-id" 允许 Mail Receiver 生成可选的唯一 ID, 以区分同一 Domain Owner 内不同来源同时生成的多个 reports. 一个可行选项是探索 Universally Unique Identifiers (UUIDs) [RFC9562].

如果 report generator 需要重新发送 report, 系统 MUST 使用与原始 report 相同的 filename. 这将允许 receiver 覆盖原始数据, 或丢弃 report 的第二个实例.

例如, 以下是从 Mail Receiver "mail.receiver.example" 发往 Domain Owner "example.com" 的 report gzip file 示例 filename:

mail.receiver.example!example.com!1013662812!1013749130.xml.gz

消息正文不要求特定 MIME message structure. 假定 aggregate reporting address 将能够提取具有规定 media type 和 filename 的 body parts, 并忽略其余部分.

承载 DMARC feedback data 的 mail streams MUST 符合 DMARC mechanism, 从而产生 aligned "pass". 参见 [RFC9989] Section 4.4. 这种做法可最大限度降低 Report Consumers 处理欺诈 reports 的风险.

单个 report submissions 的 RFC5322.Subject field MUST 符合以下 ABNF:

; FWS is imported from RFC 5322
dmarc-subject = %s"Report" 1*FWS %s"Domain:"
                1*FWS domain-name 1*FWS         ; policy domain
                %s"Submitter:" 1*FWS
                domain-name 1*FWS               ; report generator
                [ %s"Report-ID:" 1*FWS ridtxt ] ; defined above

第一个 domain-name 表示生成 report 所针对的 DNS domain name. 第二个 domain-name 表示生成 report 的 Mail Receiver 所代表的 DNS domain name. 该 field 中 Report-ID: 部分的目的是使 Domain Owner 能够识别并忽略 Mail Receiver 可能发送的 duplicate reports.

例如, 以下是从 Mail Receiver "mail.receiver.example" 发往 Domain Owner "example.com" 的 report 的可能 Subject field. 它按照 [RFC5322] 允许的方式折叠:

Subject: Report Domain: example.com
    Submitter: mail.receiver.example
    Report-ID: <[email protected]>

当 feedback data size 超过 generator 或 consumer 允许的最大 attachment sizes 时, 此 transport mechanism 可能遇到问题.

可选地, report sender MAY 选择将同一 "ridtxt" 用作 report 所含 RFC5322.Message-Id header 的一部分或全部. 这样做可以帮助 receivers 区分某条消息是 re-transmission 还是 duplicate report.

3.5.3. 其他方法​

按现有写法, 本规范允许在后续版本中添加对其他已注册 URI schemes 的支持.

3.5.4. Duplicates 的处理​

可能出现 report generator 尝试向 receiver 投递 duplicate information 的情况. 这可能表现为 report 的完全重复, 或两个 reports 之间的信息重复. 在这些情况下, 如何处理 duplicate data 的决定权属于 receiver. 如上所述, sender 在发送 report 时 MUST 使用相同的 unique identifiers. 这使 receiver 能更好地理解何时发生 duplicates.

以下是处理该 duplicate information 的几个选项:

  • 向 sender 拒绝, 理想情况下带有说明 duplicate receipt 的 permfail error.

  • 收到后丢弃.

  • 检查内容以评估 timestamps 和 reported data, 并采取适当行动.

  • 接受 duplicate data.

接受数据时, duplicate data 很可能尚未被注意到, 且属于一次性体验. 长期 duplicate data 并不理想. 在 partial time frame overlap 的情况下, 没有明确方法区分 overlap 的影响. receiver 需要整体接受或拒绝 duplicate data.

最后于 更新