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?
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.
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.
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.
If you have a time machine, please go back to late 2003 and convince
Meng that the drafts should be changed. Otherwise, we are stuck with
what is, not what people might want to be.
I don't see why that logic holds in this case.
I for one have understood mx's resolving to more than 10 domain
names to be PermErrors.
If there is any ambiguity as to what the spec means, what is the
downside to having the with-hindsight interpretation being what folks
here are saying they wish the spec to have been more explicit about,
especially in cases relating to DOS-preventing limits.
To me, if the choice is between a result that will cause a receiver to
pick an answer at random with no feedback to a legitimate sender, versus
a situation where a receiver may or must legitimitely reject a message,
alerting the sender to the problem, then in my mind there is no question
that the later choice should be taken.
And it looks to me that at the very least there's ambiguity allowing for
such a choice to be made.
(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.)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com