SPF 的神话传说

SPF 的神话传说

原文：https://medium.com/hackernoon/myths-and-legends-of-spf-d17919a9e817

SPF 是发件人策略框架(SPF)的缩写，用于授权使用电子邮件中的域。电子邮件域使用此协议来指定哪些 Internet 主机有权在 SMTP HELO 和 MAIL FROM 命令中使用此域。您不必使用任何额外的软件来发布 SPF 策略，因此此过程非常简单:只需将包含该策略的 TXT 记录添加到 DNS 区域。本文末尾给出了这种类型条目的示例。有许多使用 SPF 的手册甚至在线构造函数。

SPF 标准的第一个版本是在 10 多年前批准的。在此期间，开发了许多实现和应用实践。此外，该标准的新版本已经发布。但最令人惊讶的是，由于某种原因，SPF 比任何其他标准都要高，在过去的 10 年里，随着大量的神话和误解在一篇篇文章中传播，并以令人羡慕的规律性出现在论坛上的讨论和问题回答中。同时，协议本身似乎非常简单:实现只需要几分钟。让我们试着回忆和分析一下最常见的误解。

TL；DR——请查看最后的建议。

1.误解:SPF 将保护我的域名免受欺骗

事实: SPF 不保护用户可见的发件人地址。

解释: SPF 不处理用户看到的消息内容，尤其是发件人的地址。SPF 在两个 MTA(envelope-from，RFC5321)之间的邮件传输层(SMTP)上授权和验证地址。MailFrom 又名返回路径)。这些地址对用户是不可见的，它们可能与用户看到的 from 头中的地址不同(RFC5322。来自)。因此，无法阻止在“发件人”标头中带有假冒发件人的邮件获得 SPF 授权。

使用 DMARC 保护可见域名免受欺骗。

2.误解:实施后，SPF 将提高安全性并打击垃圾邮件

事实:最有可能的是，在安全性和垃圾邮件方面，你不会看到任何重大变化。

解释: SPF 本来就是一个利他协议，所以它不会给任何发布 SPF 政策的人提供任何好处。从理论上讲，如果你实现了 SPF，这个协议可以保护其他人从你的域名收到假邮件。但事实上，即使这个假设也不成立，因为应用 SPF 的结果很少被直接使用(这些我们后面都会讨论)。此外，即使所有域都发布了 SPF，并且所有收件人都禁止接收未经 SPF 授权的邮件，这种方法也很难减少垃圾邮件的数量。

SPF 并不直接防止欺骗或垃圾邮件，然而，该协议被积极而成功地用于部署垃圾邮件过滤系统，以及防止假冒电子邮件，因为它允许您根据特定的域及其信誉检查每封邮件。

3.误解:SPF 对电子邮件的送达率有负面(正面)影响

事实:这完全取决于信息的类型、传递方式和你的声誉

解释: SPF 并不意味着影响标准流程内的电子邮件可送达性，并且当用户从不同于发送邮件的服务器接收此类邮件时，会对邮件的不当实施或间接流程产生负面影响，例如，这适用于重定向电子邮件。但是垃圾邮件过滤系统和基于信誉的分类器考虑了 SPF 的可用性和授权域的信誉，并且这通常给出关于标准消息流的正面结果。当然，除非你自己就是垃圾邮件发送者。

4.误解:SPF 为电子邮件发件人提供授权

事实: SPF 为代表域发送邮件的电子邮件服务器提供授权

解释:首先，SPF 只在域级别起作用，在个人邮件地址级别不起作用。其次，即使你是一个特定域的合法电子邮件用户，SPF 也不允许你从任何地方发送邮件。为了使您的邮件成功通过 SPF 验证，您必须只从授权的服务器发送邮件。第三，如果您使用 SPF 授权了一个服务器(例如，您可以允许通过任何 ESP 或主机提供商从您的域发送电子邮件)，并且该服务器没有施加任何附加限制，则该服务器的所有用户都有权代表您的域发送邮件。在实施 SPF 和提供一般电子邮件的身份验证时，请记住这一点。

5.误解:未经 SPF 授权的电子邮件将被拒绝

事实:一般来说，SPF 授权与否对电子邮件的传递没有重大影响。

解释: SPF 只是一个授权标准，它明确指出应用于未经授权的电子邮件的操作不在该标准的范围之内，而是由收件人的本地策略管理。如果禁止接收此类邮件，这会导致邮件通过间接传递路径出现问题，例如，当使用重定向或邮件列表时，您应该在本地策略中考虑这一事实。在实践中，不建议在 SPF 授权失败的情况下使用严格的 ban。只有在没有其他过滤器的情况下，当域发布-all (hardfail)策略时，标准才允许(但不要求)严格禁止。在大多数情况下，SPF 授权被用作加权系统中的一个因素。与此同时，这个因素将具有微不足道的权重，因为违反 SPF 授权通常不是垃圾邮件的可靠指标:许多垃圾邮件成功地通过 SPF 授权，而合法的垃圾邮件通常无法做到这一点，我们不太可能在这个领域见证重大变化。如果我们这样看的话，-all和~all没有区别。

SPF 授权在邮件传递或垃圾邮件过滤方面并不重要，但它允许确认发件人的地址和与域的关系，以及使用域的信誉而不是此邮件的 ip 信誉。

DMARC 策略对有关处理未通过授权的消息的进一步行动的决策有更大的影响。DMARC 允许您拒绝(或隔离)所有或部分未经授权的邮件。

6.误解:SPF 建议使用-all (hardfail)，因为它比？全部或全部

事实:事实上，-all对安全性没有任何影响，但是对消息的传递有负面影响。

解释: -all导致少数直接使用 SPF 的收件人通过间接路由发送的邮件被拦截，并拦截邮件。同时，这一政策不会对大多数垃圾短信和虚假短信产生明显影响。目前，~all (softfail)被认为是最合适的策略，几乎所有大型域名都在使用它，即使是那些有非常严格的安全要求的域名(如 paypal.com)。-all可用于不用于发送合法电子邮件的域。DMARC 将-、~和?视为等同物。

7.误解:只为用于发送邮件的域配置 SPF 就足够了

事实:在邮件服务器上为 HELO 中使用的域配置 SPF 也是必要的。此外，建议对不用于发送电子邮件的 MX、A 记录和通配符应用阻止策略。

说明:在某些情况下，特别是在投递 NDR(未送达报告)、DSN(投递状态通知)和某些自动回复时，SMTP 信封(envelope-from)中的发件人地址将为空。在这种情况下，SPF 从 HELO/EHLO 命令检查主机名。您需要通过该命令检查名称(例如，通过打开服务器配置或通过向公共服务器发送电子邮件并检查邮件头),并为此名称启用 SPF。

垃圾邮件制造者不仅可以使用您用来发送邮件的相同域，他们还可以代表任何具有 A-或 MX 记录的主机发送垃圾邮件。因此，如果您出于利他的考虑发布 SPF，那么您需要为所有这样的记录添加 SPF，并且为不存在的记录添加通配符(*)也是可取的。

8.误解:最好在 DNS 中添加一个特殊的 SPF 类型记录(而不是 TXT)

事实:一定是 TXT 记录。

说明:根据当前版本的 SPF 标准(RFC 7208)，SPF 类型 DNS 记录已被弃用，不应再使用。

9.误解:建议您在 SPF 中包含尽可能多的可用元素(a、mx、ptr、include)，因为这可以降低出错的可能性

事实:需要最小化 SPF 记录，建议仅通过ip4 / ip6指定网络地址。

解释:解析 SPF 策略最多只能进行 10 次 DNS 查询。超过此限制将导致永久性策略错误(permerror)。此外，DNS 是一种不可靠的服务，因此每个请求都有失败(temperror)的可能性，这种可能性随着请求数量的增加而增加。每个额外的a或include记录需要一个额外的 DNS 请求；至于include，也需要请求包含记录中指定的所有元素。mx要求为每个 MX 服务器请求 MX 记录和额外的 A 记录请求。需要一个额外的请求，而且，它本身就是不安全的。只有通过ip4 / ip6列出的网络地址不需要额外的 DNS 请求。

10.误解:SPF 记录的 TTL 应该更小(更大)

事实:对于大多数 DNS 记录，最好选择 1 小时到 1 天范围内的 TTL，并在部署或实施计划更改时提前减少，或在策略稳定时增加。

解释:较高的 TTL 降低了 DNS 错误的可能性，从而降低了 SPF 临时错误的可能性，但是当需要对 SPF 记录进行更改时，它增加了响应时间。

11.误解:如果我不知道哪些 IP 地址可以用来发送我的消息，那么最好用+all 发布策略

事实:具有明确+all或隐含规则的政策允许从任何 IP 地址代表域名发送邮件，这将对电子邮件的发送产生负面影响。

解释:这样的策略没有意义，它经常被垃圾邮件制造者用来确保通过僵尸网络发送的垃圾邮件的 SPF 认证。因此，发布此类策略的域有被阻止的风险。

12.误解:使用 SPF 是没有意义的

事实:使用 SPF 很有必要。

说明: SPF 是邮件中授权发件人的机制之一，也是基于信誉的系统中识别域的方式。目前，大型电子邮件服务提供商逐渐开始要求对消息进行授权，并且没有授权的消息在向用户传送或显示方面会受到“惩罚”。此外，对于未通过 SPF 授权的邮件，可能没有关于传递或未传递的自动响应和通知。原因是这样的响应通常被准确地发送到 SPF 授权的 SMTP 信封地址，并要求它被授权。因此，即使所有消息都由 DKIM 授权，也需要 SPF。此外，SPF 对于 IPv6 网络和云服务是必须的:在这样的网络中，使用 IP 地址的信誉几乎是不可能的，并且来自没有 SPF 授权的地址的消息通常不会被接受。根据该标准，SPF 的主要任务之一是使用域名的信誉而不是 IP 信誉。

13.误解:SPF 是自给自足的

事实: DKIM 和 DMARC 也是必须的。

说明: DKIM 需要成功转发电子邮件。需要 DMARC 来保护发件人的地址不被盗用。此外，DMARC 允许您接收有关违反 SPF 政策的报告。

14.误解:两份 SPF 记录比一份好

事实:记录必须正好是一条。

说明:本要求在标准中有描述。如果有多条记录，这将导致永久错误(permerror)。如果需要合并几个 SPF 记录，只需用几个include操作符发布一个记录即可。

15.误解:spf1 好，但 spf2.0 更好

事实:你应该用v=spf1。

说明: spf2.0 不存在。通过发布 spf2.0 记录，您可能会面临不可预知结果的风险。spf2.0 从未存在过，它也不是一个标准，但是在实验标准 RFC 4406(发送者 ID)中提到了它，它是基于这样一个假设，即这样一个标准将被采用，因为相应的讨论确实发生了。寄件人 ID，本应解决地址欺骗的问题，却没有成为普遍接受的标准，您应该使用 DMARC 来代替。即使您决定使用发件人 ID 并发布 spf2.0 条目，它也不会替代 spf1 条目。

我几乎写完了这篇文章，突然我被我们的客户支持人员截住了，他们强烈地(明确地)建议我回忆一下他们在解决各种问题时经常要处理的 SPF 的以下细微差别:

1. SPF 政策应以all或redirect指令结束。这些指令之后绝对不应该有任何内容。
2. all或redirect指令在该策略中只能使用一次，并且相互替换(即一个策略不能同时包含all和redirect)。
3. include指令不能取代all或redirect。include可以多次使用，但是您的策略仍然应该以all或redirect指令终止。include或redirect应用于包含以all或redirect终止的有效策略。与此同时，include并不关注包含策略中用于all的规则(-all、~all、?all)，然而对于redirect来说却有所不同。
4. include与冒号(include:example.com)连用，redirect需要等号(redirect=example.com)。
5. SPF 不包括子域。SPF 在子域上不с。防晒系数。确实如此。不是。掩护。子域名。(默认情况下，DMARC 涵盖了它们)。如果 DNS 中的每个 A 或 MX 记录用于或可以用于传递电子邮件，您应该为这些记录发布 SPF。

摘要

• 您应该确保为所有 MX，最好是所有 A 记录创建一个策略。
• 为邮件服务器的 HELO/EHLO 中使用的名称添加 SPF 策略。
• 在 DNS 中将 SPF 策略发布为带有v=spf1的 TXT 记录。
• 尝试在您的策略中将这些地址用作ip4 / ip6网络。在策略的开头指定它们，以避免不必要的 DNS 请求。尽量少用include，尽量不用a，只有在极端和不可抗拒的必要情况下才使用mx，千万不要使用ptr。
• 为真正用于发送电子邮件的域指定~all，为未使用的域和记录指定-all。
• 在实施和测试期间使用小 TTL，然后将 TTL 增加到适当的值。在进行任何更改之前，请先降低 TTL。
• 一定要验证你的 SPF 政策，例如这里。
• 不要把自己局限在 SPF 的部署上，尽量实现 DKIM，永远实现 DMARC。DMARC 保护您的消息免受欺骗，并允许您接收有关违反 SPF 的信息。您将能够检测伪造、间接消息流和配置错误。
• 如果你在实现 SPF、DKIM 和/或 DMARC 后阅读俄语(或只是为了好玩)，使用https://postmaster.mail.ru/security/检查它们。根据当前状态验证 SPF 和 DMARC 仅当与邮件上的信箱一致时，才使用前一天的统计数据检查 DKIM。Ru 在前一天或之前。
• M3AAWG 有好的 SPF BCP

SPF 政策示例:@ IN TXT “v=spf1 ip4:1.2.3.0/24 include:_spf.myesp.example.com ~all”