我无法理解 policyd-spf 的默认 HELO 检查策略。RFC 4408 在第 2.5.2 节中指出
“中性”结果必须与“无”结果完全一样处理
但是policyd-spf的man page定义SPF_Not_pass如下：
SPF_Not_Pass（默认）- 如果结果不是 Pass、None 或 Temperror，则拒绝（换句话说，如果 SPF 结果为 Fail、Softfail、Neutral、PermError，则拒绝）。与 Mail From 检查不同，如果存在 HELO 名称的 SPF 记录（例如，透明转发不是问题），则不存在 HELO 检查不应通过的标准电子邮件用例。从技术上讲，此选项并不完全符合 RFC 4408，因为必须对邮件发件人身份进行 SPF 检查，并且中立和无结果必须同等对待。HELO/EHLO 在 SMTP 对话中首先被识别，如果 HELO 检查已经导致邮件被拒绝，则没有实际理由浪费资源进行 Mail From 检查。这些偏差在用于 HELO 时不应导致互操作性问题。
该描述解释了为什么可以省略邮件发件人身份的 SPF 检查，但没有回答这个问题：为什么被Neutral拒绝？
答案1
我不确定你想要什么答案。Neutral 被拒绝，因为守护进程表示，如果你调用该配置选项，它将执行该操作。正如你所强调的那样，它指出这不符合 RFC 标准。但问题在于：你没有义务在你的服务器上接受任何特定的电子邮件中央互联网法院不存在，在严肃的乔恩·波斯特尔，一张长凳七々老兵们裁定某个服务器运营商是否错误地拒绝了一封电子邮件。
RFC 包括技术上具有约束力，但不操作上所以；你越违反这些规则，你就越无法与他人正常沟通——但如果你想这样做，你可以自由地这样做。你可以选择将服务器配置为拒绝 SPF 中性结果的电子邮件、长度超过 750 kB 的电子邮件或包含多个埃在标题发件人地址中，或者不包含短语胆小的骨鳖。这是你的服务器；你可以接受你喜欢的。
编辑：这些地区的一些管理员认为 SPF 记录未结束-all是垃圾邮件发送者的活跃迹象，并惩罚或拒绝来自此类域名的邮件；我提到这一点是为了说明如何人们使用 SPF 衍生信息的方式因管理员而异。
推测作者policyd-spf认为拒收Neutral邮件比不拒收邮件能带来更好的结果（垃圾邮件更少，正常邮件更多）。但这只是我的猜测；只有他们才能确定。