Skip to main content

11. 安全考虑 (Security Considerations)

11.1. 处理限制 (Processing Limits)​

与电子邮件的大多数方面一样，恶意方可以通过多种方式将协议用作DoS攻击的途径。第4.6.4节中概述的处理限制旨在防止以下攻击：

  • DNS放大攻击：恶意方可以创建包含许多对受害者域的引用的SPF记录，并向不同的SPF验证器发送许多电子邮件；这些SPF验证器随后会创建DoS攻击。实际上，SPF验证器被用来通过在SMTP会话中使用较少的八位字节而在DNS查询中使用更多的八位字节来放大攻击者的带宽。使用SPF验证器还允许攻击者隐藏攻击的真实来源。这种潜在的攻击基于传输大量邮件。

  • 资源耗尽攻击：虽然check_host()的实现应该限制DNS查询的数量，但恶意域可以发布超过这些限制的记录，试图在向它们发送邮件时浪费目标的计算努力。恶意域还可以设计导致特定实现使用过多内存或CPU或触发错误的SPF记录。如果接收器配置为接受SPF结果为"temperror"的邮件，则这样的攻击可能导致原本会因SPF"fail"结果而被拒绝的邮件被接受。这种潜在的攻击基于使用特制的SPF记录来耗尽受害者的DNS资源。

  • 间接DNS负载：恶意方可以向各种合法邮件主机发送大量声称来自预期目标的邮件。这些合法机器在获取相关记录时会对目标施加DNS负载。

  • 查询放大攻击：理论上，恶意方可以使用SPF记录作为DoS攻击的DNS查询放大的载体。在这种情况下，攻击者在其自己的DNS中发布一个SPF记录，该记录使用针对预期受害者的"a"和"mx"机制，例如"a:example.com a:foo.example.com a:bar.example.com ..."，然后向各种目的地大量分发包含其自己域的MAIL FROM值的邮件。任何运行SPF验证器的这样的目的地都会开始查询该记录中与"a"机制关联的所有名称。记录中使用的名称无需存在即可使攻击有效。自[RFC4408]发布以来的运行经验表明，通过在遇到超过两个"void lookups"（在第4.6.4节中定义）时让验证器中止处理并返回"permerror"（第2.6.7节），可以在对已部署基础的影响最小的情况下缓解这类攻击。

在这些情况中，SPF记录中引用的第三方的情况是DoS攻击最容易有效利用的。因此，对于单个邮件服务器可能看起来合理的限制仍然可能允许不合理的带宽放大量。因此，处理限制需要非常低。

11.2. SPF 授权的电子邮件可能包含其他虚假身份​

"MAIL FROM"和"HELO"身份授权不提供关于消息中使用的其他身份的授权/真实性的保证。恶意发件人完全有可能在SPF使用的身份中使用其自己的域注入消息，并让该域的SPF记录授权发送主机，然而消息可以轻松地在其标头中列出其他身份。除非用户或MUA注意到授权身份与其他更常见呈现的身份（例如From:标头字段）不匹配，否则用户可能会被诱入虚假的安全感。

11.3. 伪造的 DNS 和 IP 数据 (Spoofed DNS and IP Data)​

恶意方可以利用此协议的两个方面来破坏check_host()函数的有效性：

  • DNS欺骗：check_host()的评估严重依赖DNS。恶意攻击者可以攻击DNS基础设施并导致check_host()看到伪造的DNS数据，然后返回不正确的结果。这可能包括为实际域的记录会评估为"fail"的值返回"pass"。有关DNS弱点的描述，请参见[RFC3833]，有关对策，请参见[RFC4033]。

  • IP地址欺骗：客户端IP地址被假设为正确。在现代正确配置的系统中，这不真实的风险为零。

11.4. 跨用户伪造 (Cross-User Forgery)​

根据定义，SPF策略只是将域名映射到授权MTA集，而不是将整个电子邮件地址映射到授权用户集。尽管"l"宏（第7节）提供了一种有限的方式来为特定电子邮件地址定义授权MTA的单独集，但通常不可能通过SPF验证同一MTA的各个用户对特定电子邮件地址的使用。

邮件服务及其MTA需要直接防止跨用户伪造：基于SMTP AUTH（[RFC4954]），用户必须被限制为仅使用实际在其控制下的那些电子邮件地址（参见[RFC6409]的第6.1节）。验证各个用户身份的另一种方法是消息加密，例如Pretty Good Privacy (PGP)（[RFC4880]）或S/MIME（[RFC5751]）。

11.5. 不可信的信息源 (Untrusted Information Sources)​

符合SPF的接收器从它接收的SMTP命令和发送域持有者的已发布DNS记录（例如，"HELO"域名、信封中的"MAIL FROM"地址，以及域持有者发布的SPF DNS记录）收集信息。这些参数在SMTP过程中未经验证。

所有这些信息都由接收器权限之外的参与者生成，因此不能保证准确或合法。

11.5.1. 记录的结果 (Recorded Results)​

在Received-SPF:或Authentication-Results:跟踪字段中传递给接收器的此信息可以作为SMTP拒绝消息返回给客户端MTA。如果生成这样的SMTP拒绝消息，则必须检查来自跟踪字段的信息是否存在诸如无效字符和过长行之类的问题。

11.5.2. 外部解释 (External Explanations)​

当授权检查失败时，拒绝响应中可以包含解释字符串。发件人和拒绝接收器都需要意识到解释是由检查的SPF记录的发布者确定的，一般来说，不是接收器。解释可能包含恶意URL，或者它可能是冒犯性的或误导性的。

由于"exp"修饰符（第6.2节）返回给发件人域的解释是由域持有者自己发布的发件人策略生成的。只要消息仅使用未传递通知（[RFC3464]）返回到从其自己的DNS SPF记录发布解释字符串的域，唯一受影响的方就是域的SPF记录的原始发布者。

实际上，此类未传递通知可能被误导，例如当MTA接受电子邮件并且仅在稍后向伪造地址生成通知时，或者当电子邮件转发器未将退信定向回原始发件人时。

11.5.3. 宏扩展 (Macro Expansion)​

宏（第7节）允许发件人向接收器DNS查询中注入任意文本（任何非空[US-ASCII]字符）。必须准备好应对敌对或意外的内容。

11.6. 隐私暴露 (Privacy Exposure)​

检查SPF记录会导致DNS查询被发送到域所有者。这些DNS查询，特别是如果它们是由"exists"机制引起的，可以包含关于谁在发送电子邮件以及可能向哪个MTA发送电子邮件的信息。这可能会引入一些隐私问题，根据当地法律以及ADMD与发送电子邮件的人之间的关系，这或多或少是一个问题。

11.7. 传递产生 "Fail" 结果的邮件 (Delivering Mail Producing a "Fail" Result)​

选择传递SPF产生"fail"结果的邮件的操作者需要理解，他们正在接纳声称的发件人明确未授权的内容。虽然存在可以被视为"假阴性"的已知故障模式，但接纳这些消息的明确选择会增加最终用户遭受可能伤害的风险。对于属于已知良好参与者的域尤其如此，这些域通常表现良好；来自这些来源的未授权邮件很可能会受到更高的怀疑和内容分析。

然而，SPF不包括区分良好参与者和不良参与者的能力，也不处理已知参与者与未知参与者的概念。这些概念超出了本规范的范围。

Last updated on