Re: non-ascii SPF policy

On 5 October 2011 22:50, Stuart D. Gathman wrote:

>    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.

+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