For SPF council review: Syntax error = Perm error = Message should be re

In the pre-MARID specs, a syntax error would result in an unknown result.
Unknown was to be treated exactly like None.

Now, a syntax error results in PermError and SHOULD be rejected.

I feel pretty strongly that rejecting messages from a domain with a
malformed SPF record is a really bad idea.  People new to SPF make all kinds
of mistakes.  If after the first mistake, they start getting messages
rejected, they'll just give up and go home.

Rejecting messages based on a syntax error makes SPF deployment much more
risky.

Instead of SHOULD reject, it should be treated as None.

Here is the current language:

2.5.7  PermError

   A "PermError" result means that the domain's published records
   couldn't be correctly interpreted.  Checking software SHOULD reject
   the message with an SMTP reply code of 550 and, if supported, the
   5.5.2 DSN code.

4.6  Record Evaluation

   After one SPF record has been selected, the check_host() function
   parses and interprets it to find a result for the current test.  If
   there are any syntax errors, check_host() returns immediately with
   the result "PermError".

   Implementations MAY choose to parse the entire record first and
   return "PermError" if the record is not syntactically well formed.
   However, in all cases, any syntax errors anywhere in the record MUST
   be detected.

Instead of the above 2.5.7, I recommend this instead (based on the wording
for Neutral):

2.5.7  PermError

   A "PermError" result means that the domain's published records
   couldn't be correctly interpreted.  A "PermError" result MUST be
   treated exactly like the "None" result; the distinction exists only
   for informational purposes.

This gets us back to the pre-MARID behaviour, reduces risk for SPF
deployment, and does NOT make the spec an longer.

Scott Kitterman