non-ascii SPF policy

I just committed a test to the test suite for non-ascii-policy.  Pyspf
flunks this test, so I am running the expected result by the community
in the hopes of discovering that pyspf is right after all.  :-)

The test:
   non-ascii-policy:
     spec: 3.1.1/1
     helo: hosed
     host: 1.2.3.4
     mailfrom: "[email protected]"
     result: permerror
zonedata:
   hosed.example.com:
     - SPF:  "v=spf1 a:\xEF\xBB\xBFgarbage.example.net -all"

The spec states that SPF policies are USASCII.  What should an
implementation do when a policy is not, in fact, USASCII?  My
reading is that this is a syntax error and the result is PermError.

This situation came up in production.  The domain name was preceded
by a Unicode BOM coded as utf-8 (as in the test case).  The
domain really existed, utf-8 coded BOM and all.   The test case doesn't
reproduce this aspect (domain actually existing) as I wasn't immediately sure
how to code this in YAML.  The important thing is that non-ascii 
bytes in the SPF policy are a syntax error.

For speculation:

While I'm pretty sure rfc4408 says non-ascii domains are a syntax error,
a related question is whether spfv3 should continue that policy.  Since
DNS allows any sequence of 8-bit bytes for label, and there are
implementations by a large software vendor that can store labels as
unicode preceded by BOM and encoded as utf-8, perhaps SPF policies
should allow arbitrary bytes for domain-spec.  (The macro mechanism
already provides for quoting special chars.)  Alternatively, macro-literal
could be expanded to include %7f-ff so that non-ascii chars within a
domain-spec could be quoted.

-- 
 	      Stuart D. Gathman <[email protected]>
     Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.