Re: Last pending wannabe erratum: Invalid <target-name>

Julian Mehnle wrote:
 
> "a:foo..bar" is not a syntax error.

Ugh, right, it's  2*<macro-literal> "." <toplabel>  

If we ever try "SSP" (simple sender policy) let's kill those
annoying macros, their only real purpose outside of theoretical
SES and "per user policy" discussions is trolling for Doug's
"SPF script" flames :-(

We could even do that "by definition", a v=spf1 policy without
macros and with at most one mx mechanism is "by definition" a
simple sender policy.  

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

>>> Following RFC 4408, behavior would have to be the same as for a
>>> literal "exists:ugly..dots.valid.domain.test".

>> Interesting, you (kind of) ignored the quoted-string "ugly..dots".
 
> I think the quoting of localparts only serves to enable the use
> of additional characters that are otherwise reserved.  The quotes
> themselves are not part of the localpart's value if I understand
> it correctly.

Yes, you have to quote anything that is no <dot-atom-text>.  That's
as you said anything containing non-<atext> characters, including
any <quoted-pair>, necessary or otherwise, down to <quoted-pair>
with NO-WS-CTL and worse 2822 obs-cenities.  But it also covers any
leading / trailing / adjacent dots, that's also no <dot-atom-text>.

> we should stay as far away as possible from EVER introducing 
> sophisticated (de)quoting/(un)escaping rules into SPF.  Stuff
> like this has caused generations of broken implementations (see
> RFC 2047 MIME encoded words for a prime example).

We should, but we can't without ruling out certain kinds of local
parts.  Or radically killing %{l} as bad idea.  EAI even kept the
<quoted-pair> construct in conjunction with UTF-8 characters, one
of the three EAI lunacies I hope to address in the IETF Last Call.

There are more issues with %{l}, local parts are by definition
case sensitive, but LDH-labels in something that could be a host
name are not.  Or rather they are, but you can have at most one
spelling of a host name in DNS, and that's supposed to match any
other spelling.  Adding this %[l} can of worms to SPF wasn't a
smart move, putting it mildly.  What does it really buy outside
of Doug's DDoS drafts ?

> "%{h}.foo" with HELO = "quux..bar" will always get expanded to
> "quux..bar.foo", which is likely to be rejected, rather than
> actually parsed and looked up, by very most resolver libraries.

Maybe a %{l} example with this effect is more compelling, as HELO
it's an SMTP syntax error justifying GiGo results.  As local part
implementations could look up quux\.\.bar.foo (two labels) to get
it right.  Similar "space me" could be space\ me.foo (two labels).

Or whatever makes the API accept embedded spaces, dots, NO-WS-CTL,
the works.  We should have some test cases in this direction, for
"DNS can do" and "SPF doesn't say DON'T" I get a "permitted", no
matter how much sh*t real SPF implementations are willing to eat.

> IDNA, in all its unbelievable ugliness, was invented for exactly
> this reason: network/transport-layer applications NOT having to
> care about it.  Thus it's not our problem.

It's a problem for users wishing to use SPF and participate in the
EAI experiment, what their UTF8SMTP MTA sends / gets as MAIL FROM
can use U-labels (UTF-8) in the right hand side.

IOW SPF implementations wishing to support EAI have to know how to
transform U-labels into A-labels, or they need an EAI layer between
UTF8SMTP and SPF with this effect, or they need a DNS resolver API
doing that on the fly.
  
 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=71640397-342f60
Powered by Listbox: http://www.listbox.com