Appendix D. SPF/中介者交互 (SPF/Mediator Interactions)

有三个地方可以使用技术来改善与中介者的意外SPF失败。

D.1. 发起 ADMD (Originating ADMDs)

开始时，当电子邮件首次发送时：

为可能的转发器提供"Neutral"结果：可以为可能是转发器的IP地址提供"neutral"结果，而不是基于已知可靠转发器列表的"fail"结果。例如：

"v=spf1 mx ?exists:%{ir}.whitelist.example.org -all"

这将导致在DNS白名单（DNSWL）上查找，并且仅对不是来自域的mx主机（SPF pass）或白名单来源（SPF neutral）的电子邮件导致"fail"结果。这实际上是将发件人策略的一个要素外包给白名单的维护者。

在 "MAIL FROM" 身份中添加加密信息："MAIL FROM"身份可以在local-part中包含加密标识邮件来自授权来源的附加信息。在这种情况下，可以使用如下的SPF记录：

"v=spf1 mx exists:%{l}._spf_verify.%{d} -all"

然后，可以设置专门的DNS服务器来服务验证local-part的_spf_verify子域。尽管这需要额外的DNS查找，但这仅在电子邮件否则会被拒绝为不是来自已知良好来源时发生。

注意，由于域标签有63个字符的限制，此方法仅在local-part签名方案保证仅产生最多63个字符的local-parts或优雅地处理截断的local-parts时才能可靠工作。用于保护local-part的方法是本地实现问题；它不需要是标准的。可以在[BATV]中找到一种方法的示例。

"v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"

然后，专门的DNS服务器可以回答查询，以便允许有限数量的邮件通过来自特定IP地址的检查，然后开始返回NXDOMAIN。这具有降级伪造邮件的效果，这些邮件将开始因"fail"而被拒绝。

中间，在中介者转发邮件时：

中介者可以使用一种技术，例如Sender Rewriting Scheme (SRS)，在转发邮件之前重写发件人地址，使用它们自己的域。这样，中介者接受责任，并使用它们自己的SPF记录。

最后，当邮件最终被传递时：

接收域可以在其本地策略中为已知合法的中介者（例如众所周知的邮件列表）选择白名单处理。它们还可以识别未通过SPF检查的消息，并对其应用额外的启发式方法以确定邮件是否实际上是合法的。