spf-discuss
[Top] [All Lists]

[spf-discuss] Re: TLDs

2007-03-25 17:06:32
Julian Mehnle wrote:

I don't know a million other weird cases, I know that one:  At the
moment "oemcomputer" is no TLD under ICANN's root, unlike "museum",
"aero", "arpa", "travel", "asia", "mobi", "coop", etc.  For a less
volatile test I'd replace "oemcomputer" by "invalid".

Now what does _that_ have to do with testing for crashes?

I don't know, it's your point.  I only said that some outcomes like
crash / dead loop / NONE / SOFTFAIL for "v=spf1 a:%{h} -all" are
wrong, and certified SPF implementations must not do that, no matter
what the HELO identity referenced by %{h} is.

In RFC 4408, there is no such thing as an "invalid <target-name>".
It says that <t-n> "is an FQDN", but it doesn't say anything else

What, did it forget to update RFC 1035 ?  Seriously, it says very
clearly what to do with an invalid <target-name> wrt exp= modifiers,
and for affected mechanisms it offers at least _some_ instructions
how to deal with DNS problems.

the cost of rendering certain implementations incompliant because
they chose to do something other than what _you_ want to specify
retroactively, is simply too high.

I say bull.  Predictable and deterministic results were a goal for
SPF since Wayne took over, and the "add new mechanisms to 'embrace
and extend' new ideas whenever they emerge" fraction was thrown out.

It's a Wiki, it has an edit history, and whoever added it likely
tried to track one of those convoluted test suite threads.  If
it's bogus we can throw it out.

I suggest that whoever added it either explain whose idea it was,
adopt the idea as their own, or remove it from the proposed errata
list.

+1  If nothing happens with it until say May let's move to kick it.

If some implementations can handle a:%{h} for an existing A record
for say "museum", others treat it as "ignore, no match, move on",
and some throw PermError, then it obviously harms interoperability.

Note that this is a very cornery corner case.  It happens only if
<helo> is in some way "not an FQDN" (as the spec says)

NAK, it happens for _any_ <target-name> resulting in a single label,
with any mechanism or modifier allowing a <target-name>.  The %{h}
is only the simplest example to nail it.  %{l} etc. also can result
in single labels.  Taking a part of an IPv6 can do it (DE, AF, ...).

what's the problem with some implementations making a (potentially
bogus) TLD query (which is likely to fail), some mismatching the
mechanism, and some throwing PermError?  The only real type of
case I can see is the "legit TLD used as host or MX domain name"
one, and as far as I can see, no TLD actually does it.

Besides, throwing PermError in this case is hardly justifiable
from what the spec says.

Fine, we're making progress, so you consider PermError as bad idea.
That leaves "ignore single labels" or "try to match as always".

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

<Prev in Thread] Current Thread [Next in Thread>