In <20050719204613(_dot_)GB18723(_at_)primefactor(_dot_)com> Mark Shewmaker
<mark(_at_)primefactor(_dot_)com> writes:
On Tue, Jul 19, 2005 at 01:08:52PM -0500, wayne wrote:
In <NGBBLEIJOEEEBMEIAPBKOEGAIJAA(_dot_)scott(_at_)kitterman(_dot_)com> Scott
Kitterman <spf2(_at_)kitterman(_dot_)com> writes:
Yes, those are "silent". So is "v=spf1 a:invalid.tld -all" and
"v=spf1 ip4:10.0.0.1 -all"
As to the first example: Wouldn't an evaluation of
"v=spf1 include:invalid.tld -all" return a PermError just like (I had
thought, especially after the permerror discussions of a few months ago)
that first example would?
Yes, "include:invalid.tld" will trigger a PermError because there will
be no SPF records at invalid.tld. However "a:invalid.tld" simply
returns no A records and thus does nothing. There is no syntax error
and PermError isn't raised.
And as for the second example, I've thought about doing just that, (for
an internal network as an kludge for internal authentication, with the
reasonable assumption that these internal ranges wouldn't be externally
routed anyway), so I don't consider that having any possibility of being
a "silent" error as it is potentially semantically valid in some
instances.
Ok, it may not be an error, but it is useless for almost all situations.
Now when I added all that up, it looked like PermError to me.
Well, that isn't what the spec says.
It's what I've always read the spec as saying.
Hmmm... Ok, but I don't see any of the SPF specs saying that.
Remember, PermError was originally named "unknown" and designed to
signal unknown mechanisms. The SPF spec has always had silent
"errors".
I came away from the whole PermError discussion a few months ago with
the conclusion that there was a consensus that errors would never be
silent.
Personally, I really don't like errors being silently ignored, but I
never suggested changing this part because it would be too significant
a change. I guess I'm listening, but I really don't like the idea of
changing stuff at this point in time.
(Note that while I would prefer if the spec could be ammended to specify
that this sort of behavior is acceptable, that's not really what I'm
going for here--I'm just suggesting that it should alreadly be
considered okay if code (record validation and spf libraries) handles
these cases with with actual PermErrors.)
I don't think the spec already says it is ok.
-wayne