2. Operational Overview (操作概述)

2.1 Publishing Authorization (发布授权)

符合 SPF 标准的域按照第 3 节所述发布有效的 SPF 记录。这些记录授权其中指定的 MTA 在 "HELO" 和 "MAIL FROM" 标识中使用相关的域名。

SPF 结果可用于做出正面（来源已授权）和负面（来源未授权）的判定。如果 ADMD 选择发布 SPF 记录并希望支持接收方做出负面授权判定, 则需要发布以 "-all" 结尾的记录, 或重定向到这样做的其他记录; 否则, 无法对授权做出明确的判定。第 10 节讨论了与负面判定相关的潜在问题和缓解措施。

希望声明在 SMTP 会话期间没有主机被授权在 HELO 或 MAIL FROM 命令中使用其 DNS 域名的 ADMD, 可以为那些既不在电子邮件地址的域部分中使用也不期望发送邮件的域名发布这样的 SPF 记录。

在更改 SPF 记录时, 必须注意确保有一个过渡期, 以便旧策略保持有效, 直到所有合法电子邮件都可以合理地预期已被检查。[RFC5321] 第 4.5.4.1 节讨论了消息可能在传输中停留的时间。虽然离线检查是可能的, 但检查越接近原始传输时间, 就越有可能获得与发送 ADMD 在发送消息时的意图相匹配的 SPF 结果。

2.2 Checking Authorization (检查授权)

邮件接收方可以对其接收的每封邮件执行一组 SPF 检查。SPF 检查测试客户端主机以给定标识发送邮件的授权。通常, 此类检查由接收 MTA 执行, 但只要所需信息可用且可靠, 就可以在邮件处理链的其他地方执行。"MAIL FROM" 和 "HELO" 标识分别按照第 2.4 节和第 2.3 节所述进行检查。

在没有发布 ADMD 明确批准的情况下, 不建议根据 SPF 版本 1 记录检查其他标识, 因为已知有些情况会给出不正确的结果。例如, 几乎所有邮件列表都会重写 "MAIL FROM" 标识（参见第 10.3 节）, 但有些不会更改消息中的任何其他标识。定义其他标识的文档必须定义明确批准的方法。

邮件接收方可能会将 SPF 检查作为对传入邮件的更大测试集的一部分。其他测试的结果可能会影响是否执行特定的 SPF 检查。例如, 在本地白名单上找到发送主机的 IP 地址可能会导致跳过所有其他测试, 并接受来自该主机的所有邮件。

当邮件接收方决定执行 SPF 检查时, 它必须使用正确实现的 check_host() 函数（第 4 节）并使用正确的参数进行评估。虽然整个测试是可选的, 但一旦决定执行测试, 就必须按照规定执行, 以便在发布者和接收者之间保留正确的语义。

要进行测试, 邮件接收方必须使用第 4.1 节中描述的参数评估 check_host() 函数。

虽然无效、格式错误或不存在的域会导致 SPF 检查返回 "none"（因为找不到 SPF 记录）, 但长期以来, 许多 MTA 的策略是拒绝来自此类域的电子邮件, 特别是在无效的 "MAIL FROM" 的情况下。拒绝电子邮件将防止绕过 SPF 记录的一种方法。

实现必须注意从与 SMTP MAIL FROM 命令一起给出的数据中正确提取 <domain>, 因为许多 MTA 仍然接受诸如源路由（参见 [RFC5321] 的附录 C）, %-hack（参见 [RFC1123]）, 和 bang 路径（参见 [RFC1983]）之类的东西。这些古老的特性已被恶意使用来绕过安全系统。

2.3 The "HELO" Identity ("HELO" 标识)

建议 SPF 验证器不仅检查 "MAIL FROM" 标识, 而且还通过将 check_host() 函数（第 4 节）应用于 "HELO" 标识作为 <domain> 来单独检查 "HELO" 标识。检查 "HELO" 可以促进结果的一致性, 并可以减少 DNS 资源的使用。如果可以基于 "HELO" 的检查对消息做出明确的判定, 那么可以避免使用 DNS 资源来处理通常更复杂的 "MAIL FROM"。此外, 由于为 "HELO" 标识发布的 SPF 记录指的是单个主机, 因此当可用时, 它们是非常可靠的主机授权状态来源。如果两者都要检查, 建议先检查 "HELO" 再检查 "MAIL FROM"。

请注意, 对于发送方来说, EHLO 或 HELO 命令中呈现的域的要求并不总是清晰的, SPF 验证器必须准备好标识是 IP 地址文字（参见 [RFC5321] 第 4.1.3 节）或者只是格式错误的。此 SPF 检查只能在 "HELO" 字符串是有效的多标签域名时执行。

2.4 The "MAIL FROM" Identity ("MAIL FROM" 标识)

如果未执行 "HELO" 检查或未达到明确的策略结果, 则 SPF 验证器必须通过将 check_host() 函数应用于 "MAIL FROM" 标识作为 <domain> 来检查 "MAIL FROM" 标识。

[RFC5321] 允许反向路径为空（参见 [RFC5321] 中的第 4.5.5 节）。在这种情况下, 没有明确的发件人邮箱, 此类消息可以假定为来自邮件系统本身的通知消息。当反向路径为空时, 本文档将 "MAIL FROM" 标识定义为由本地部分 "postmaster" 和 "HELO" 标识（可能在之前已经单独检查过, 也可能没有）组成的邮箱。

2.5 Location of Checks (检查的位置)

授权检查应该在处理接收邮件的 SMTP 事务期间执行。这降低了确定用作 check_host() 输入的正确 IP 地址的复杂性, 并允许通过 SMTP 回复将错误直接返回给发送 MTA。[RFC7001] 的附录 D 对此主题进行了更全面的讨论。

授权检查在 SMTP 事务期间在 MAIL 命令时执行, 并使用 MAIL FROM 值和客户端 IP 地址。在稍后的时间或使用其他输入执行检查可能会导致以下问题:

可能难以从潜在的欺骗性标头中准确提取所需的信息。
由于发件人的策略已更改, 合法的电子邮件可能会未通过授权检查。

向未通过授权检查的伪造标识生成未送达通知通常构成退信（backscatter）, 即无法操作的骚扰拒绝通知。强烈建议操作员避免此类做法。[RFC3834] 的第 2 节描述了退信及其引起的问题。

2.6 Results of Evaluation (评估结果)

第 4 节定义了 check_host(), 这是一个模型函数定义, 它使用上面定义的输入和在 DNS 中发布的发件人策略来得出关于客户端授权的结论。SPF 验证器实现了与此处定义的函数在语义上等效的东西。

本节列举并简要定义了该函数的可能输出。但是, 请注意, 该协议没有为处理任何特定结果建立规范性要求。第 8 节中讨论了每个结果的处理选项。

2.6.1 None

结果为 "none" 意味着（a）没有从 SMTP 会话中提取可以用作要授权的 <domain> 的语法上有效的 DNS 域名, 或（b）没有从 DNS 中检索到 SPF 记录。

2.6.2 Neutral (中立)

"neutral" 结果意味着 ADMD 已明确声明它不断言 IP 地址是否已授权。

2.6.3 Pass (通过)

"pass" 结果是客户端被授权以给定标识注入邮件的明确声明。

2.6.4 Fail (失败)

"fail" 结果是客户端未被授权在给定标识中使用域的明确声明。

2.6.5 Softfail (软失败)

"softfail" 结果是发布 ADMD 的弱声明, 表示主机可能未被授权。它没有发布更强、更明确的导致 "fail" 的策略。

2.6.6 Temperror (临时错误)

"temperror" 结果意味着 SPF 验证器在执行检查时遇到了瞬态（通常是 DNS）错误。稍后重试可能会成功, 而无需 DNS 操作员的进一步操作。

2.6.7 Permerror (永久错误)

"permerror" 结果意味着域的发布记录无法正确解释。这表明一个错误条件, 肯定需要 DNS 操作员的干预才能解决。