早在6月份,我就发现理论上我们也应该为EHLO主机名设置SPF记录。对此的传统解释(除了大型电子邮件提供商这么说,这是现代SMTP中做任何事情的通常原因)来自于,例如,这篇关于小型邮件服务器最佳当前实践的文章,是这样的(释义):
人们使用SPF来验证信封发件人域(SMTP MAIL FROM)。但是,当您发送退回时,它的发件人为空,因此没有可用于SPF检查的发送域。因此,发送者域名取自EHLO主机名,因为没有更好的地方获取它(因为没有SMTP级别,退回声称是由Xdomain发送的,尽管这通常在消息报头中)。
这当然是一种虚假的说法。这里实际发生的情况是,接收邮件服务器正在尝试验证EHLO/HELO主机名本身不是伪造的,并为此使用SPF。这是对SPF的完全再利用,我们可以看到这一点,因为发件人就在发件人策略框架的名称中,并且在SMTP级别上可以看到退回的发件人(并且也没有完全标准的方式使其在邮件头中可见),所以我们可以看到它的用途是完全不同的,因为发件人在发件人策略框架的名称中是正确的,并且在SMTP级别上可见的退回发件人是不存在的(并且也没有完全标准的方式使其在邮件头中可见)。
这里有一些与电子邮件相关的标准以及任何互联网标准的经验教训,我可以这样总结:如果人们认为有一个漏洞需要填补,那么附近的任何钉子都会被钉上,而不管钉子最初是为了什么而设计的。在这里,我可以这样总结:如果人们认为有一个漏洞需要填补,那么附近的任何钉子都会被钉进去,而不管钉子最初是为了什么而设计的。
PS:这详细介绍了我最近发布的一条推文,该推文为我们的EHLO主机名添加了SPF DNS记录(并为我们的记录写下了更改的官方解释)。
建议您始终(但要小心)检查HELO身份,并在检查“邮件发件人”之前这样做。
如果信封发件人为空发件人,邮件将被假定来自';postmaster@<;Helo Name>;';,这将用作邮件发件人检查(即使您已经检查了HELO身份)。
我还没有看过RFC 7208&39;关于做SPF检查的部分,看看它在算法上对待Helo和Mail From检查是否有些不同,因为坦白地说,我对此不够感兴趣。
这意味着RFC7208本身是我上面总结的常规解释的超集。在RFC 7208中,您有EHLO主机名的SPF记录,这既是因为退回,也是因为建议接收者始终检查它们。这意味着你所有的邮件发送机都应该有SPF记录,而不仅仅是那些可以发送退信的。
(现在我已经查过了,我可能需要更新一些DNS记录。(再次。)