☰

如果 SPF 限制过于严格，邮件列表是否会“中断”？

tag-icon • tag-icon security email smtp spf dkim
如果 SPF 限制过于严格，邮件列表是否会“中断”？

我最近配置了自己的邮件服务器（基于 Linux 的 postfix + dovecot 方案）。这仅供个人使用 - 我没有发送批量邮件，也没有从主机自动生成的出站邮件，没有这样的事情。我费尽心思配置了所有额外的有趣的电子邮件 DNS 记录：

@                 IN  TXT  v=spf1 +mx -all
_domainkey        IN  TXT  o=-; [email protected]
mail._domainkey   IN  TXT  v=DKIM1; h=sha256; k=rsa; s=email; p=deadbeef
_adsp._domainkey  IN  TXT  dkim=all
_dmarc            IN  TXT  adkim=s; aspf=s; fo=1; p=none; pct=100; rf=afrf; ri=86400; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=none; v=DMARC1;

我有一个不在任何黑名单上的 IP，一个正确配置的 PTR，DKIM 签名完美验证，我认为一切都设置正确。

但现在我无法向邮件列表投稿。当我向列表地址发送邮件时，有时邮件会进入黑洞，有时我会收到一封发送到我authfail@地址的电子邮件，而在其他情况下，我会在发送到的报告中看到我认为相关的条目aggrep@。

我认为 SPF 策略过于严格。邮递员（或其他）列表服务器充当了我邮件的 SMTP 中继，对吗？所以我更改了

@                 IN  TXT  v=spf1 +mx -all

到

@                 IN  TXT  v=spf1 +mx ~all

将默认操作设为软失败而不是硬失败。问题是，我不想无缘无故地到处发送垃圾邮件列表来测试此更改。有没有其他人来过这里并可以验证/反驳我的理论？

编辑1：

回想起来，感谢@Alex 纠正我，我确实没有提供足够的数据来做出准确的评估。以下是我authfail@在尝试发布到邮件列表时收到的通知示例：

This is a spf/dkim authentication-failure report for an email message received from IP 66.211.214.132 on Thu, 10 Jul 2014 20:58:52 +0800.
Below is some detail information about this message:
 1. SPF-authenticated Identifiers: archlinux.org;
 2. DKIM-authenticated Identifiers: none;
 3. DMARC Mechanism Check Result: Identifier non-aligned, DMARC mechanism check failures;

For more information please check Aggregate Reports or mail to [email protected].



Feedback-Type: auth-failure
User-Agent: NtesDmarcReporter/1.0
Version: 1
Original-Mail-From: <[email protected]>
Arrival-Date: Thu, 10 Jul 2014 20:58:52 +0800
Source-IP: 66.211.214.132
Reported-Domain: example.com
Original-Envelope-Id: w8mowEA5UUwMjr5TlWQfBA--.250S2
Authentication-Results: 126.com; dkim=fail (signature error: RSA verify failed) header.d=example.com; spf=pass [email protected]
DKIM-Domain: example.com
Delivery-Result: delivered

在我看来，这是 DKIM 签名失败，但我不知道原因。接收服务器是否正在尝试验证我的DKIM 签名与邮件列表服务器的密钥相对应，还是反之亦然？出于某些原因，我不希望这种情况发生 - 我记得在某处读到过，在这种情况下，中继等有时会删除/删除这样的标头，以确保不会发生此类故障？

编辑2：

感谢@Christopher Karel 引用 dmarcian.com 上的 DMARC 报告解析工具。大部分条目都列为转发器（这很有意义）。有一个服务器 (*.mailhop.org) 列为“保留 DKIM” - 我已成功通过一个 Ruby 语言论坛发送邮件，而且从我的研究中我知道他们使用 mailhop.org。

在“破坏 DKIM 签名（或创建伪造签名）的服务器”类别下，列出了、*.archlinux.org（不知道为什么会出现在这里，也许我所在的另一个列表也在不同的配置中使用它们），其中我最活跃的列表是 Arch 和一些由 Google Groups 托管的列表，所以这是有道理的。总共大约 400 条消息 - 我发送的消息并没有那么多，所以我想也许它正在计算重试次数。*.google.com*.mailhop.org

我很沮丧——目前看来我的选择是：

  1. 保留 SPF、DKIM、DMARC 和 ADSP，放弃使用邮件列表，或者
  2. 放弃此 DNS 安全/报告层，导致我的正常发送邮件被 Google、Yahoo!、Live 等拒绝。

答案1

电子邮件安全很糟糕。所以最后，你可能要面临一个决定，你所有的选择都很糟糕，而且会因为不同的原因破坏不同的东西。

具体到 SPF，如果邮件列表转发了以下消息，则会导致失败：无需重写标题。列表可以自行配置，以按照自己的意愿工作，因此没有一个好的通用答案。但是，如果列表中的消息似乎来自列表本身，则它正在重写标题。如果它似乎来自发件人，则可能不是。一般来说，邮件列表应该单独使用 SPF 即可很好地工作。而常规邮件转发则不行。

对于 DKIM，对邮件的任何修改都会导致失败。这几乎总是发生在邮件列表中。因此，DKIM 通常会因邮件列表而失败。但邮件转发应该没问题。

最重要的是，你已经实现了DMARC。这本质上是一个围绕 DKIM 和 SPF 的报告基础结构。如果您同时实施这两种身份验证措施，效果会更好，但只使用其中一种也可以。您可以配置 DMARC 来传达邮件的丢弃请求，但更重要的是，您可以指定一个地址来接收成功/失败报告。大多数主要电子邮件接收器都支持这些。（GMail、Hotmail、Yahoo）这可以让您了解哪些邮件未通过 SPF 检查以及原因。使用它来指导您的-allvs~all决策。

不幸的是，DMARC 规范要求发件人域和要检查的 SPF 记录保持一致。就您而言，邮件列表的 SPF 正在接受检查，并且通过了检查，但与您的域不一致。因此 DMARC 失败。以下是来自邮件列表管理员的推荐抱怨太多。

结论与我的开场白一样：电子邮件安全糟透了。而且您的所有选择也很糟糕。恕我直言，邮件列表也很糟糕，如果我们替换它们，生活会更好。;-)

答案2

我还没有看过 DKIM 部分。

关于 SPF 记录，我发现大多数示例中都使用了以下内容：

v=spf1 mx-全部

此处记录了这一点：http://www.openspf.org/SPF_Record_Syntax

但是根据 RFC 7208，“+mx”也应该是正确的（感谢 Chris 指出这一点）。也许还是值得一试的……

我真的不知道该建议什么……仔细检查您的所有 DNS 记录（A / PTR / MX）。您可能已经这样做了。了解实际域名可能会帮助人们排除故障 - 至少如果与 DNS 相关的话。

答案3

事实证明我的配置似乎没有任何问题。发生的事情是，我的邮件被邮递员正确处理，并被转发到列表中。然而，有几个接收者（无论出于什么原因）拒绝了这条消息。因为我实际上正确地配置了 SPF，我看到的是来自那些目标 SMTP 服务器的拒绝消息，而不是来自邮件列表中继本身的拒绝消息。

Arch 社区的一些优秀人士帮助我找到了这个问题，因为他们可以访问上述 ML 服务器。

相关内容