为什么在SPF为“硬失败”的情况下仍可以正常发送电子邮件?


9

我试图弄清楚为什么即使将伪造的电子邮件标记为SPF,伪造的电子邮件仍会传递给主要电子邮件提供商(gmail.com,outlook.com)hardfail。该电子邮件也将传递给Microsoft Exchange,Microsoft Exchange PermError将为相同的SPF记录抛出。

我正在使用SOME_DOMAIN.com域发送电子邮件,该域定义了损坏的SPF记录。电子邮件是通过我自己的IP地址发送的,该地址未在SOME_DOMAIN.com的SPF记录中明确列出。SOME_DOMAIN.com的SPF记录具有以下三个属性,前两个属性违反了SPF RFC-4408:

  1. 由于,需要10个以上的DNS查询来解析整个SPF记录include:
  2. SPF记录之一中的语法错误,python-spf引发解析错误。
  3. SPF记录包含规则~all-all,都表示所有地址的集合都应softfailhardfail

发送到模拟admin@SOME_DOMAIN.com的Outlook.com地址的电子邮件将在已发送电子邮件的SMTP标头中包含以下错误。该电子邮件通常发送到用户的收件箱

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

Gmail还将电子邮件发送到用户的收件箱,但会引发不同的SPF错误:

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

那么这是怎么回事?为什么尽管有SPF仍会发送电子邮件hardfail?SPF记录破损是否意味着其他SMTP服务器完全忽略了SPF?还是我在这里想念的东西...

Answers:


16

SPF的配置如此之差,以至于接收MTA的站点通常hardfail仅被视为建议,而只是将其计入垃圾邮件检测分数中。最后,由MTA的管理员决定如何处理SPF故障。


2
同意 严重失败并不意味着电子邮件将自动被拒绝。这取决于接收服务器配置为处理SPF失败的方式。
joeqwerty 2014年

值得注意的是,Office 365(和Outlook.com同样,相同的平台)默认情况下已禁用SPF验证。您可以在EOP设置中启用此功能。
托马斯

6

SPF错误条件不表示任何有关所需策略的信息。因此,它们不提供有关是否接受该消息的指导。预期的策略可能是+all。在这种情况下,通常接受邮件。Google似乎对此域不遵守标准宽容。

-all验证发件人地址时,甚至SPF策略拒绝()都不可靠。在许多情况下,拒绝此类邮件是不合适的,包括:

  • 订约邮递员发送的邮件(这些人因违反政策而获得报酬。);
  • 从网络表单和其他此类自动化系统发送的邮件;
  • 通过邮件列表或其他转发机制转发的邮件;和
  • SPF记录只是简单的错误配置(不常见,但还不够罕见)。

我运行的服务器相当小,可以在发生严重故障时进行延迟。这使我可以将合法的失败列入白名单。如果发件人注意到邮件未送达,他们可以修复其配置。在某些情况下,我会尝试与相关的联系postmaster,但许多域都没有postmaster地址。

想要实施更强策略的用户可以使用DMARC,这不是一个标准。邮件仍然有可能被传递,但是可以按照该策略中的规定进行隔离或拒绝。未能通过该策略的邮件可能会传递到垃圾邮件文件夹,而不是普通的收件箱。

SPF硬故障似乎确实可以验证发送服务器的身份。不久前,我做了一些研究,发现即使HELO名称出现软件故障,也是造成失败或延迟传入消息的合理原因。

许多邮件服务器没有SPF记录。如果邮件服务器没有SPF记录,我将在父域中检查SPF记录。这是非标准的,但有效。我鼓励电子邮件管理员确保在PTR记录中列出服务器IP的SPF记录。您的服务器也应该通过其PTR记录返回的名称来标识自己。验证您是否具有用于反向DNS验证的相应A记录。


Outlook.com更宽大。我还没有听说过DMARC,这很有趣。
Rook
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.