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