I have troubles understanding the default HELO checking policy of policyd-spf. RFC 4408 states in section 2.5.2, that

A "Neutral" result MUST be treated exactly like the "None" result

But the man page of policyd-spf defines SPF_Not_pass as follows:

SPF_Not_Pass (default) - Reject if result not Pass, None, or Temperror (alternatively put, reject if the SPF result is Fail, Softfail, Neutral, PermError). Unlike Mail From checking, there are no standard e-mail use cases where a HELO check should not Pass if there is an SPF record for the HELO name (transparent forwarding, for example, is not an issue). Technically this option is not fully RFC 4408 compliant since the SPF check for the Mail From identity is mandatory and Neutral and None results must be treated the same. HELO/EHLO is known first in the SMTP dialogue and there is no practical reason to waste resources on Mail From checks if the HELO check will already cause the message to be rejected. These deviations should not cause interoperability problems when used for HELO.

This description explains why it is ok to omit the SPF check of the Mail From identity but does not answer the question: Why is Neutral rejected?


I'm not sure what answer you'd like. Neutral is rejected because that's what the daemon says it's going to do, if you invoke that configuration option. It notes, as you've highlighted, that this is not RFC-compliant. But here's the rub: you are not obligated to accept any particular email at your server. There is no Central Internet Court where, beneath a stern portrait of Jon Postel, a bench of nanae veterans rule on whether a particular server operator wrongly rejected an email.

The RFCs are technically binding, but not operationally so; the more you violate them, the more you'll fail to properly communicate with others - but you're free to do that if that's what you want to do. You can choose to configure your server to reject emails that have an SPF neutral result, or are over 750 kB in length, or that have more than one e in the header-From address, or that fail to contain the phrase squeamish ossifrage. It's your server; you can accept what you like.

Edit: some admins around these parts consider SPF records that don't end in -all to be an active sign of a spammer, and penalise or reject mail from such domains; I mention this to illustrate that how people use SPF-derived information varies a great deal from admin to admin.

Presumably, the authors of policyd-spf felt that rejecting Neutral mail led to better outcomes (less spam, more ham) than not doing so. But that's speculation on my part; only they can say for sure.

  • I do understand that I can decide which mail to accept or not. But I don't understand the reasoning behind this default setting. For example: A client of ours has an SPF record v=spf1 mx ?all and some mails originate from a server that is not MX for that domain - which results in a neutral SPF result. Now I changed the policy to Softfail because I do want to accept those mails. But why is policyd-spf designed to reject on Neutral SPF result by default? Isn't that quite pessimistic? – bran Jul 21 '16 at 12:16
  • See edit above. – MadHatter Jul 21 '16 at 12:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.