我尝试了解 RFC7208 (SPF) 中定义的 HELO Identity 的好处。
有一个邮件服务器，假设为 mail.example.com。此服务器用作不同域的中继。
在第 2.4 节中：
如果尚未执行“HELO”检查，或者未通过将 check_host() 函数应用于作为 <sender> 的“MAIL FROM”身份得出明确的策略结果，SPF 验证器必须检查“MAIL FROM”身份。
我明白，如果HELO已经通过，就不需要检查MAIL FROM了。
类似2.3节：
勾选“HELO”可提高结果的一致性，并可减少 DNS 资源使用量。如果可以根据“HELO”的勾选对邮件做出最终判断，则可以避免使用 DNS 资源来处理通常更复杂的“MAIL FROM”。
这是否会导致 MAIL FROM 身份不受检查？
问候，亚历克斯
答案1
一些可能的用途：
您可以尽早拒绝失败的 HELO 身份。由于
HELOSMTP 命令在对话的早期发生，因此您可以拒绝立即评估的 HELO 身份fail。（我在自己的邮件主机上使用此方法，发现很多声称是这个邮件主机的客户在早期就被拒绝了。）您可以评估 HELO 身份和 MAIL FROM 身份，并使用两者来增加合法性的“分数”。例如，您可以为 HELO 为 1 的发件人分配更多信任和MAIL FROM 身份评估为
pass。pass如果您对 HELO 身份或感到满意fail，则可以决定跳过对 MAIL FROM 身份的评估softfail，作为一种快捷方式，可以这么说：您不需要有如果您对 MAIL FROM 不感兴趣，请检查。但是请注意，HELO 身份很容易被伪造，就像 MAIL FROM 身份一样（发件人可以发送任何他们想要的邮件），因此通常您会对 MAIL FROM 身份感兴趣（并且可能将其输入到 DMARC 组件中）。另外，虽然这不能直接回答你的问题，但请记住，HELO 身份也会被评估代替当您的邮件服务器发送退回邮件（即带有空信封发件人的邮件）时，MAIL FROM 标识
<>。因此，无论如何，正确设置它都是必要的。
这一切都取决于您的要求。这还取决于您的 SPF 实现允许什么（以上所有内容均由我自己的实现支持，SPF 乳液）。
fail在实践中，也许将 HELO 身份视为主要在负面结果（ 、softfail、 ）时有用的东西会有所帮助permerror，而在正面结果（ ）时则没有太大用处pass。当邮件服务器检查 HELO 身份并遇到负面结果时，它可以立即结束对话，也可以将负面 HELO 结果记录为标题中的最终 SPF 结果。在这样的策略下，在这些情况下确实不需要评估 MAIL FROM 身份。这样的策略确实会导致上述 DNS 资源的减少，因此，这就是我认为提供和检查 SPF HELO 身份的直接实际好处所在。
答案2
HELO 检查仅在“如果可以根据您自己对 RFC 的引用做出结论性决定”时才足够——除非您信任域、连接和 DNS，否则情况并非如此。
对于我来说，RFC 为何要这样写是一个谜。
尽管如此我会确保我的服务器发送合法的 HELO 身份吗？原因：邮件服务器开始拒绝来自我的域的邮件（毫无根据的垃圾邮件怀疑），但仍接受合法邮件，我的服务器只会将这些邮件正确转发到特定帐户。（对于这些邮件，MAIL FROM SPF 始终会失败。）
也许大多数邮件子系统还没有做到这一点：但如果他们（现在或将来）跨单个邮件边界评估（我的）服务器，我希望他们信任我的域/服务器。如果他们接受我的转发并开始信任来自这里的邮件，或者如果他们继续信任我的转发，因为来自这里的邮件在所有 SPF 检查中都有效，那么我就会全力支持 SPF。
在接收端：
如果 HELO 身份检查结果为否定，则严格拒绝服务等同于拒绝向 SPF 未知的客户端提供服务。如果 HELO 检查结果为肯定，则做出反应等同于完全不做出反应，即继续会话。
所以总而言之：也许 HELO SPF 身份可以作为您邮件系统中垃圾邮件控制等的一个小部件。如果可以，那就太好了。在我的系统中，它不行。