跳到主要内容

7. 隐私注意事项 (Privacy Considerations)

生成和传输 DMARC 失败报告 (failure reports) 会引发重大的隐私顾虑, 部署前必须仔细考虑这些问题.

鉴于这些因素, 许多大规模提供商会限制或完全禁用失败报告的生成, 更倾向于依赖聚合报告 (aggregate reports). 聚合报告可以提供统计层面的可见性, 同时不会暴露敏感内容. 强烈鼓励选择启用失败报告的运营者:

  • 将使用范围和持续时间限制在有针对性的诊断活动内.

  • 确保报告 URI (reporting URIs) 受到严格控制和验证.

  • 应用最小化技术, 例如对消息正文和头部字段 (header fields) 进行删减, 以减少敏感数据暴露.

  • 始终通过安全信道传输报告.

总之, 虽然 DMARC 失败报告可以提供诊断价值, 但相关隐私顾虑已经促使许多运营者限制其使用. 在保留最终用户通信机密性的同时获取认证结果可见性时, 聚合报告仍是推荐机制.

下文将进一步探讨具体的隐私相关问题.

7.1. 数据暴露注意事项 (Data Exposure Considerations)​

失败报告可能包含来自认证失败消息的个人可识别信息 (Personally Identifiable Information, PII) 和非公开信息 (non-public information, NPI), 因为这些报告可能包含消息内容以及跟踪头部字段 (trace header fields). 这些报告可能暴露发送方和接收方标识符, 例如 RFC5322.From 地址. 虽然用于失败消息报告的 [RFC5965] 格式支持删减 [RFC6590], 但失败消息报告能够向报告消费者 (Report Consumer) 暴露整封消息. 它们还可能向非预期接收方暴露 PII, 敏感业务数据或其他机密通信. 这种暴露可能给发送方和接收方带来监管, 法律和运营风险. 示例包括产品发布, 员工解雇通知或日历数据. 即使看似无害的失败, 例如格式错误或"损坏"的日历邀请, 也可能导致私密通信泄露.

请求报告的域所有者 (Domain Owners) 将收到有关使用其域的邮件的信息, 但这些邮件实际上并非由他们促成发送. 这可能为了解滥用消息中使用的内容提供有价值的洞察, 但也可能暴露因错误或意外而认证失败的合法消息中的 PII 或 NPI.

邮件最终目的地的信息可能通过失败报告暴露, 即使这些信息原本可能被中间系统遮蔽. 一个常被引用的示例是邮件列表成员暴露: 当一个列表成员向列表发送消息, 并且该消息投递给其他列表成员时生成失败报告. 这些失败报告会发送给发布该消息的列表成员所属的域所有者, 或其委托的报告消费者.

类似地, 当存在消息转发安排时, 请求报告的域所有者可能收到有关转发到某些域的邮件的信息, 而这些域最初并不在其消息的收件人列表中. 这意味着以前域所有者并不知道的目的地现在可能变得可见.

7.2. 报告接收方 (Report Recipients)​

DMARC 策略记录 (DMARC Policy Record) 可以指定报告应发送给代表域所有者运行的报告消费者. 当域所有者将报告发送给某个实体, 以便监控邮件流的可投递性, 性能问题或滥用情况时, 可能会采用这种做法. 邮件接收方 (Mail Receiver) 的隐私政策, 使用条款等可能允许也可能不允许第三方接收此类数据. 域所有者和邮件接收方都应当审查并理解其内部政策是否约束 DMARC 报告的使用和传输.

报告消费者在一定程度上可能执行流量分析 (traffic analysis), 从而获得邮件接收方流量的元数据 (metadata). 除了验证是否符合政策之外, 邮件接收方在向第三方发送报告前还需要考虑这一点. 另一方面, 域所有者可能发布一个看似为内部报告消费者 (Internal Report Consumer) 的目标地址, 但该地址实际上是转发地址. 在这种情况下, 报告的最终目的地无法得到保证.

7.3. 额外损害 (Additional Damage)​

与失败报告相关的风险会因数量和内容分发方面的顾虑而加剧. 部分删减或未删减的报告可能传播大量垃圾邮件, 网络钓鱼或恶意软件内容, 这些内容都可能要求报告消费者或其他接收方进行特殊处理以避免事件发生. 这凸显出需要避免 "ruf" 报告 URI 中目的地配置错误, 并遵循本文档中的删减建议, 例如使用 [RFC6590] 中描述的方法. 对于高流量域, 所有这些顾虑都会进一步加剧. 为缓解这些顾虑, 应考虑以下步骤:

报告生成方应:

  • 通过将 http 替换为 hxxp, 帮助防止意外访问潜在恶意 URI.

  • 移除可能嵌入恶意负载的附件.

报告消费者应:

  • 将报告流与其他邮件流隔离.

  • 在评估失败报告时使用沙箱.

  • 使用网络分段 (network segmentation).

  • 将失败报告的访问权限限制给经过适当安全培训的授权人员.

最后于 更新