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: "foobar@hosed.example.com"
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 <stuart@bmsi.com>
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.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20111005165041:AE030642-EF93-11E0-A9B1-BB3AC529DFB4
Powered by Listbox: http://www.listbox.com
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: "foobar@hosed.example.com"
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 <stuart@bmsi.com>
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.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20111005165041:AE030642-EF93-11E0-A9B1-BB3AC529DFB4
Powered by Listbox: http://www.listbox.com