Alex van den Bogaerdt wrote:
>>| If the <target-name> after macro exapnsion is a single label
>>| (e.g. a top level domain ) with or without trailing dot, or
>>| an invalid domain (e.g. strings with adjecent dots), then the
>>| corresponding mechanism does not match.
> This is weird.
Weird or not, it's consistent with <domain-spec>. And we can't
change <domain-spec> _again_, the last AUTH48 mutilation was bad
enough. I begin to hope that this change didn't break older SPF
implementations, AFAIK nobody reported problems with SPF policies
using the optional trailing dot in <domain-spec> so far.
> We're writing an add-on for email, not for RFC2821.
The issue isn't about mail, it's about syntactically good policies
where <target-name> results after macro expansion into something
that's an SPF syntax error if used directly in a <domain-spec>
without macros.
Mechanisms like "a:foo" or "mx:bar." are SPF syntax errors. And
"a:foo..bar" (adjacent dots) is no syntax error as far as the ABNF
is concerned.
In other words a:foo..bar gets no PermError, but e.g. a:localhost
or mx:museum are PermErrors.
After macro expansion of say a:%{h} or mx:%{L} the <target-name>
can have the same forms, foo..bar, museum, oemcomputer, etc. And
clearly museum is no "invalid domain", and oemcomputer also isn't
an "invalid domain" (it's just no registered ICANN TLD (yet)).
OTOH foo..bar is clearly crap, you don't get NXDOMAIN. I guess
we're not interested to revisit <domain-spec>, that gives us:
"domain" | as <domain-spec> | as <target-name> | 2821 | 821
------------+------------------+------------------+------+----
foo | PERMERROR | possible FQDN | bad | ok.
bar. | PERMERROR | possible FQDN | bad | bad
museum | PERMERROR | possible FQDN | bad | ok.
oemcomputer | PERMERROR | possible FQDN | bad | ok.
localhost | PERMERROR | possible FQDN | bad | ok.
foo..bar | no syntax error | impossible FQDN | bad | bad
The (2)821 columns are only for comparison. Not modifying the
<domain-spec> means that the PERMERRORs stay PERMERRORs, and
a direct foo..bar doesn't trigger a syntax error.
After that decision all SPF implementations can still face the
corresponding <target-name>s either after expanding macros, or
because <domain-spec> foo..bar wasn't caught as an ABNF error.
SPF implementations have to do something at this point in the
evaluation. For the single labels they could just ask DNS, and
in rare cases like museum they might even get an answer that's
not NXDOMAIN.
For foo..bar they can't query DNS because that's no domain. To
get predictable results with different implementations we have
to say what's the "correct" behaviour in these cases:
Apparently folks like to ignore foo..bar, the mechanism simply
doesn't match, and move on (next directive).
Apparently folks don't like to query DNS for single labels as
<target-name>, and wish to ignore them just like foo..bar.
It's IMO a plausible choice, maybe not nice for single labels,
but being nice to TLDs operated as host was obviously never an
SPF goal, otherwise <domain-spec> wouldn't insist on "the dot"
or PERMERROR.
> Please see the relevant RFC, first listed normative reference
> in RFC4408.
If you think that <domain-spec> should be changed to allow TLDs
please post a proposal how that's supposed to work in the ABNF.
IIRC the last (2004) attempts in this direction caused an ABNF
ambiguity identified on the MARID list by an expert:
<
http://article.gmane.org/gmane.ietf.mxcomp/2846>
> What if the RFC2821bis people suddenly change their mind and
> do allow "user@ws" ?
Won't change <domain-spec> in RFC 4408, unless we say so in an
erratum or 4408bis. And I don't intend to "fix" <domain-spec>,
but if you have an idea that works with yacc, bison or similar,
let's see.
The <target-name> foo..bar issue is not necessarily related to
the single label issues, even with an improved <domain-spec>
we'd still have to address <target-name> foo..bar separately -
at least I see now again why there was an old separate erratum:
I'll add the "rationale" (= example foo..bar) to the Web page
later, explaining that this can happen directly and also after
macro expansion... <sigh />
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/?list_id=735