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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> Julian Mehnle wrote:
> > how does 2821bis change the rules with regard to this?
>
> [...]

Thanks for the explanation.

> > > -----------------------------------------------------------------
> > > 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" ?
> >
> > - From a design theoretical PoV, that should be a PermError
> >   because it won't go away on retrying.
>
> Partially I agree:  A TempError certainly won't cut it.  You could
> however treat it like a (literal) "invalid", a reserved pseudo-TLD 
> without IP or MX, nowhere, never (unlike "localhost" or "test").

RFC 4408 -- as it is -- doesn't forbid this behavior.  As I said, I was 
speaking from a purely design theoretical PoV.

> [...]  But we normally _try_ that PermError is predictable, mainly used
> for syntax errors.  If Scott picks "invalid" (ignore), and you pick
> PermError, it's hard to find out what's wrong for an affected user.

Well, yes, PermError being used only for syntax error is an unwritten 
axiom of SPFv1, however it is an unwritten one, which (thankfully!) 
allows us to extend the PermError semantics in a future SPF revision.  
Again, as I said, I was speaking from a purely design theoretical PoV.

> > As for real implementation behavior, Mail::SPF currently treats
> > "a:foo..bar" as a simple mismatch.
>
> Wait a moment, I was talking about <target-name> foo..bar, are you
> talking about a <directive> a:foo..bar ? Adjacent dots before the macro
> expansion step directly written in a policy are a PermError, aren't
> they ?

I was talking about <target-name> = "foo..bar", but it's all the same, 
really.  "a:foo..bar" is not a syntax error.  In any case, according to 
RFC 4408, a PermError should not be thrown for that reason.

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

> > I have thought about defining (in a new specification -- SPFv3,
> > 4408bis, whatever) macro expansion to treat any expanded macro
> > as an atomic and opaque value when constructing a <target-name>,
> > which would enable "ugly..dots" to be considered as a domain
> > label of its own in "%{l}.%{d}".
>
> [...]
>
> > That, however, would break "%{ir}._spf.%{d}" and similar cases.
>
> Not necessarily, you could transform dots within a <quoted-string>
> local part to <quoted-pair>, and leave a sound <dot-atom-text> as
> is.  Of course you'd also keep <quoted-pair> \. in <quoted-string>,
> we don't want \\\. in this case.

I think 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).

> JFTR, RFC 4408 also doesn't allow to spell out "embedded dots" in
> a policy, we only can do VCHAR + SP - "." directly or with macros.

I don't think RFC 4408 allows dots-embedded-in-domain-labels even 
_implicitly_, through macro expansion or otherwise.  "%{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.

> For IDN (internationalized domain names) in a policy we can use a
> form with A-labels ("punycode").  For U-labels ("unencoded UTF-8")
> in an UTF8SMTP envelope sender address we need the draft mentioned
> above, that would also explain some fine print about <alt-address>:
>
> Inconsistent policies for an "I18N address" and the corresponding
> (optional) <alt-address> won't work as expected from the POV of a
> sender trying this stunt.  No SPF issue, only a new caveat.

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHVHYzwL7PKlBZWjsRAowrAKDncmIhbRJoBjBNnV0OirXZ4SMu4gCeOcfL
CvPCFtcLsrf3alPeQPc5evY=
=pZtE
-----END PGP SIGNATURE-----

-------------------------------------------
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=71616942-2c723b
Powered by Listbox: http://www.listbox.com