hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail
Oct 5, 2011, 7:40 PM
Post #3 of 3
(713 views)
Permalink
|
On 5 October 2011 22:50, Stuart D. Gathman wrote:
> mailfrom: "foobar [at] hosed"
> 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.
+1 IDN (internationalized domain names) would be encoded with
the IDNA2008 rules (punycode introduced by xn--) in SPF policies.
Caveat: Local parts in the first or soon second set of EAI RFCs
can be UTF-8, in that case you should treat the "binary" UTF-8
output of the local part macro "as is". But that doesn't affect
what you find directly (before macro expansion) in SPF policies.
And you won't care about "raw UTF-8 octets" in obscure EAI local
parts before you can handle UTF8SMTP and IDNA forward, sideward,
and backward; always punycoding U-labels into A-labels, where "U"
stands for IDNA2008 UTF-8, and "A" for ASCII compatible xn--LDH.
> The important thing is that non-ascii bytes in the SPF policy
> are a syntax error.
Yes, at least not directly. And indirectly only as U-label (=>
A-label) or as EAI local part (=> raw UTF-8 treated as a binary
DNS label, still with the known length limit for all DNS labels)
> related question is whether spfv3 should continue that policy.
Sure, folks will manage to punycode their U-labels. For normal
SPF business (= host names) the corresponding A-labels will do.
If receivers start to support UTF8SMTP they'd also need an SPF
implementation supporting punycode "somewhere". Ideally that's
done outside of check_host():
As the name says check_host() is for host names, IOW it expects
LDH including A-labels. Converting U-labels to A-labels can be
done before check_host(), and any invalid cruft is a PermError.
The only difference of an EAI check_host() would be to permit
EAI local parts for the purposes of the local part macro in an
SPF policy.
> 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.
NAK, "binary labels" are binary labels, using octets that happen
to be a BOM if interpreted as UTF-8 does not change this. For
starters this would be a syntax error even in UTF8SMTP and EAI.
It is no valid IDNA2008 host name (A-label), and it is also no
valid U-label (never used directly in DNS -- the "A" in IDNA is
for IDN in Applications, there is no "IDNB" with BOMs in DNS ;-)
-Frank
-------------------------------------------
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=20111005224116:A829D8A0-EFC4-11E0-9274-FDCC0922F49A
Powered by Listbox: http://www.listbox.com
|
