I think all of the following options have been blessed by previous
specs and/or major SPF implementations. In the case of PermError
(aka "unknown"), which should we do?
Thank you for your enumeration of some of the most likely choices. It's
helping me think through what I think is right.
One of the reasons I first started worrying about syntax errors was
simply during the manual testing of the SPF engine in our code. When
doing the tests found in test.txt, I found that test #122 (using
99.spf1-test.mailzone.com and 99txt.spf1-test.mailzone.com) would fail
because of syntax errors like a mechanism "moo" and use of a "%{u}"
macro, neither of which were in the SPF draft.
1) Treat PermError as "None"
When we're processing the macros in the result of an exp= modifier, it's
not entirely clear wfrom the draft whether macro expansion failure
constitutes a PermError. It would probably make more sense that in the
case of the exp= modifier, a syntax error from the macro expansion of
the secondary TXT record lookup simply results in "None" because it
doesn't change the outcome of the SPF record itself.
2) Treat PermError as "Fail"
This is wrong because the "Fail" message has a particular meaning that
does not apply here.
3) RECOMMEND PermError be rejected via SMTP 5xx responses
As much as I may dislike this option (and my dislike is fading as I find
and read more convincing evidence), I am now tending to believe that for
an error in the SPF record it needs to be a 5xx response. This is
similar in behavior both to trying to send mail to a domain that has
faulty MX records (such as "IN MX 10 192.168.1.4", using an IP address
instead of a domain) or trying to send mail from a domain that does not
even have an A or MX record (for those servers performing basic DNS
validation on the MAIL FROM: domain).
4) RECOMMEND PermError be temporarily rejected via SMTP 4xx responses
I like Daniel's assessment that 4xx errors should be limited to those
that are transient in nature and should be able to resolve themselves. A
syntax error isn't necessarily transient.
--Marc