spf-discuss
[Top] [All Lists]

[spf-discuss] Re: RFC 4408 <draft-schlitt-spf-classic-02.txt> -- AUTH48 changes

2006-04-01 16:02:39
Julian Mehnle wrote:

this change doesn't actually introduce an incompatibility.

Well, admittedly I didnt't check any sources, let alone _all_
sources, but the <toplabel> ABNF was always a piece of magic
back to the days of MARID.  Catch IPv4s styling themselves as
domains as syntax error was only one issue - not interesting
for SPF, but very important for root servers hit by useless
queries for digit-only wannabe-TLDs.

Another point was the CIDR syntax, it was important to make
sure that there can't be any slashes at this point of the ABNF
unrelated to CIDR lengths.  Simple to talk about, less simple
to get it right in ABNF - and some implementors might try to
use ABNF to regex output directly - the horrible stuff posted
by Wayne here months ago.

M:S:Q doesn't count

You put a lot of effort in it, and it's still the "reference"
implementation.  Nobody knows who copied it at which time now
trying to "fix" his implementation to get the same behaviour.

As an implementor (hypothetical wrt SPF) I wouldn't expect
modifications at this time, especially no unnecessary trailing
dots.  If you think that 1034 rules, you could be consequent
and forget "not only digits" <toplabel>, 1123 (the infamous
STD 3) 2.1 still says "alphabetic" about <toplabel>.  In an
apparently "informative" discussion, it's a messy subject.

get a 3rd opinion from John C. Klensin, the author of RFC
2821 and 3696.

The council has carefully weighted the pros and cons and has
concluded that, given the warning about publishing trailing
dots that has been added to the spec, the change benefits
more than it does harm.

Maybe he'd support you.  After all he was willing to add this
obscure dot to 2821bis.  And he hates dubious restrictions for
labels, because they won't fly with his IDNA xn-- labels.  But
that's guessing on my side, you'd better ask him.

RFC 3696 is an informational RFC, not suited for a normative
reference.

You do have a point, however we're only "Experimental" (yes,
this is an excuse, but not necessarily a bad one).

ACK, when we go for PS at least USEFOR should exist as a better
source for imported ABNF.

not even HTTP (RFC 2616) specifies in its ABNF grammar what
constitutes a host name, let alone a TLD.  It refers to RFC
2396, which has been replaced

The draft -02 ABNF copies the 2396 syntax.  2616 (like 3696) is
one of those RfCs you shouldn't touch without their "errata" -
quite a lot of typos, e.g. the language tag stuff is broken wrt
3066 and 3066bis (noted in the 2616 errata).

we don't have "label" defined, which is required by the
USEFOR definition of "toplabel", so we'd have to copy that,
too, just for the sake of an anal-retentive definition of
"toplabel".

It's horrible, but not really more anal retentive than what you
now have for the IPv4 CIDR - squeezing too many details into
ABNF gets horrible. <shrug />  We (= USEFOR, or rather Charles
and me) had also an unambiguous <toplabel> version, two lines
instead of three, but that allowed for singletons (one char.),
clearly not what will be allowed as <toplabel>, ever.

The "digit hyphen digit" cases are already utter dubios, so far
no such TLD exists, and John (see above) would prefer to get
rid of the hyphen for his UTF-8 dreams in I18N mail addresses.
If I got that correctly - another highly controversial issue.

If someone can come up with a TERSE and NOT OVERLY COMPLEX
definition of "toplabel"

Don't ask me, what you see in USEFOR is the best I found after
several rounds with subtle errors like forgetting "no alpha at
all".  You could claim that "singleton TLDs" are not exactly an
SPF problem, and reduce it to two lines based on label instead
of three.

In USEFOR I convinced them to pick the more complex solution,
because it would be the very first in a standard, and there's
a high danger that everybody copies it later.  With all warts.

                             Bye, Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com