Stuart D. Gathman wrote:
> the RFC simply doesn't address the issue. Except it
> *does* address the issue for looking up SPF records
> (initial processing) - long and empty labels result
> in pretending there was an NXDOMAIN.
At least a hint for a consistent solution.
> Julian is practically crying because he wants such
> things to be a PermError.
That's what we'd want before "AUTH48", PermError is
better than TempError in this situation. And the name
of the term is <domain-spec>, not <expanded-garbage>.
It's also explained in 4.8, the <target-name> is an
FQDN. But foo...bar isn't an FQDN.
We could claim that that's "obvious" (an "obvious" lie
after nobody saw it in more than two years), and that
adding one statement with "missing" MUSTard in 4.8 as
erratum is perfectly normal (actually it's not).
This "missing" MUSTard could also kill OEMCOMPUTER if
we insist on one dot _within_ FQDN. After all that's
the purpose of this 2821 rule, catch bare host names.
Managers of TLDs should know how to avoid that trap.
Another solution could be to start the 4408bis I-Ds
now, with strict compatibility for all normal policies,
not the oddities you find here.
And we finally have some "lessons learned" to offer,
creating a test suite is an excellent way to debug
specifications. Not only to debug implementations.
> However, such things are clearly not PermError in
> the current RFC.
Above you said "simply doesn't address", that's not
a clear TempError, that's more like unspecified. It
is not a "match". That leaves no match, TempError,
and PermError.
For a literal foo...bar in the policy a PermError is
in the spirit of other cases of broken policies. For
HELO foo...bar arriving in a:%[h} the policy is okay,
only the HELO is bogus, that's more like "no match".
We don't have this subtlety outside of 4.3, where it
only catches the domain of the checked identity, not
the other domain.
> What if the empty (or long) label shows up after
> macro expansion?
Yes, then it's no error in the policy. Reporting a
PermError could be misleading. Maybe not much, but
it would need new prose in the PermError chapter.
> I made nomatch the preferred result, because it is
> analogous to initial processing.
That avoids the worst issue, who's responsible, the
sender or the policy author. Without macro that's
clear, the author screwed up. With macro it can be
hard to determine.
> Do we want the preferred result for a:foo...bar in
> the test-suite to be temperror or nomatch?
You said that depending on the API some get RCODE x
(neither 0 nor 3), for that the spec. says TempError.
That this API probably lies (like my nslookup) and
never sent an impossible query doesn't change that.
You said others get a local res_mkquery error. For
that it's "simply doesn't address the issue", and
"no match" is also okay. For the literal foo...bar
a PermError is also plausible / desirable.
You could test that implementations can't "match"
for this case, and allow all other outcomes (?)
You could argue that you want the same result for
a:foo...bar and a:%{h} with HELO foo...bar, and an
a:{%h} is no PermError. The least harmful result
is apparently "no match" (?)
Frank
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to
http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com