Last pending wannabe erratum: Invalid <target-name>

Hi, 

with 2821bis in Last Call I removed "<target-name> is a valid TLD"
as potential erratum, if 2821bis permits it we'll follow suite.

Syntactically SPF policies can't talk directly about this case, 
a <domain-spec> ends with a dot-separated <toplabel>, plus the
optional trailing dot (that's certainly no 2821bis construct ;-)

IOW we can't have "v=spf1 a:museum" or similar, this won't kill
e-mail.  I think that deserves two test cases in the test suite:

1 - "v=spf1 a:museum" is a PERMERROR (missing dot)
2 - "v=spf1 -a:%{h} all" for h=museum or similar should be PASS,
    if the address doesn't exist or at least doesn't match.  I
    forgot how the test suite arranges this.  Maybe these tests
    already exist.

We could note that future SPF versions (4408bis or otherwise) 
need a syntax where "v=spf1 a:museum" is no syntax error, but
IMO that's no 4408 erratum, it wasn't predictable that 2821bis
changes the rules.  
-----------------------------------------------------------------
The last pending erratum:  What do real implementations if the
<target-name> has a form unsuited for DNS queries, e.g. adjacent
dots ?  Just ignore the <target-name> as "no match" ?  

For the test suite:  With "v=spf1 exists:%{l}.%{d}" and mail from
"ugly..dots"@valid.domain.test what are implementations supposed
to do ?  A dot (like any other octet) is permitted in a label, of
course that's no host name, and it might be tricky to construct 
a DNS query, but maybe "ugly\.\.dots.valid.domain.test" works.

It's not as esoteric as you might think, for UTF8SMTP local parts
can contain "raw" UTF-8 octets.

 Frank



   

  






 



 


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/1007/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1007/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=6959932&id_secret=71356872-3d375a
Powered by Listbox: http://www.listbox.com