我们的电子邮件被欺骗了。我们已经实施了 SPF/DKIM/DMARC p="quarantine" 政策，但我们的收件箱中仍然收到数千封未送达回执 (NDR)。
更改为 DMARC p="reject" 是否会阻止 NDR 反向散射？
关于如何防止 NDR 反向散射还有其他建议吗？
注意：我们使用 OpenSRS 托管电子邮件。
答案1
DMARC 不是防止反向散射的解决方案，p=reject实际上可能会导致更多的反向散射，这是服务器发送未送达回执 (NDR) 而不是使用连接阶段拒绝在 SMTP 连接期间。整个反向散射问题是由接收 MTA 或中间 MTA 上的配置不当引起的。即使 DMARC 有解决方案，这类管理员也不会是第一个采用它的人。
另一方面，DMARC 提供了接收故障报告（ruf=），可能会导致大量取证数据。建议为此设置一个完全独立的地址，并且最好将数据转发到可以自动进行分析的地方。
对抗背向散射的可能方法包括：
- 使用基于 DNS 的阻止列表来查找发送反向散射的已知服务器 (反向散射器）。
- 检查
Message-Id退回邮件的是否与您的邮件 ID 模式相匹配。 - 退回地址标签验证 (BATV) (互联网草案自 2008 年起，解释）。
首先：配置您自己的 SMTP 服务器，使其不会向可能伪造的返回地址发送 NDR：使用连接阶段拒绝在收件人验证或防伪造检查失败等之后，将为发送 MTA 上的本地用户生成 NDR。
答案2
我很感激这是一个迟来的答复。
按照规定，DMARC 无法防止反向散射......但这并不是故事的结束。
SPF、DKIM 和 DMARC 都减少了在接收服务器上实施的反向散射，因此问题比以前少了。然而，我们不能假设人们会实施这些技术中的任何一种。
@Esa - 您关于不向非本地用户生成 NDR 的评论意味着，如果有人设置了不负责最终交付的中继，那么发件人将永远不会收到 NDR。这种情况经常发生，原因很充分 - 将邮件边界（或垃圾邮件墙）与邮箱存储分开通常是一件好事（IMHO），并且还可以实现更灵活的处理。我不认为这是解决反向散射的可行方法。
当然，您说得对，DMARC 无法阻止反向散射，因为 NDR 是与原始欺骗邮件不同的邮件，因此 NDR 邮件可能符合 NDR 来源域的任何 DMARC 政策。但是，由于 NDR 包含原始邮件标头，因此这些标头中有关原始电子邮件的信息可用于识别反向散射。
曾经有一个名为 milter-null 的 milter，它会将计算后的标头插入到外发邮件中，并在 NDR 的邮件标头中检查相同的标头。如果不存在，则会阻止 NDR 邮件。此技术仅在接收邮件服务器知道由 milter-null 插入的标头时才有用全部发送服务器，我认为 miilter-null 仅在同一台服务器处理所有发送和接收邮件时才有效。它不再可用（我认为它来自 snertsoft），尽管您可能通过一些持续搜索在某处找到来源。
我们正在考虑实施一种解决方案，使用 NDR 中的原始邮件头来实现 DMARC，因为它应该在接收服务器上实施。当然，这不属于 DMARC 范围，虽然我们可以看到这种方法的一些弱点*，但这是我们发现的阻止反向散射的最佳方案。我们还没有这样做，但其他人可能已经实施了解决方案。
- 关键的缺点是，由于一条消息可能要排队好几天，因此无法保证我们评估该消息时所依据的记录与该消息发送时存在的记录相同。如果我们托管 DNS，我们可以解决这个问题，但它不符合标准。（我们有记录更改日志，因此我们可以确定在给定时间点的记录是什么）。