-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of wayne
Sent: Tuesday, July 19, 2005 2:47 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Re:MX/PTR Max Lookup error was( "/" inside an
exists: domain-spec?)
In <NGBBLEIJOEEEBMEIAPBKAEGIIJAA(_dot_)scott(_at_)kitterman(_dot_)com> Scott
Kitterman <spf2(_at_)kitterman(_dot_)com> writes:
It isn't a PermError because the spec doesn't explicitly say it is a
PermError.
Send patches for all the cases where there can be some sort of "error"
that doesn't generate a PermError and if it is short enough and clear
enough, I'll strongly think about adding it to the spec during the
AUTH48 review.
OK. Will do.
I've pondered this a little more and have two comments:
First, I think it would be productive to try and track down all the
cases where "errors" are silently ignored. I put "errors" in quotes
because I think we should be very liberal with what gets put on the
list and include things that some people would argue are not real
"errors".
Second, as far as the spec goes, I think it would be a bad idea to put
in a lot of notes that say "This error is silent, it doesn't generate
a PermError". If we miss a spot, someone down the line will look at
it and say "yeah, but that must be a PermError because if it wasn't,
it would be noted as not being a PermError!"
Instead, maybe we should put some sort of note by the defintions of
TempError and PermError that says something like:
Note: The PermError and TempError conditions MUST only be
generated in conditions that are explicitly defined in this
document to do so. There are conditions that are arguably
"errors" that do not trigger an error condition.
Thoughts?
-wayne
I agree with that. You might also explicitly note, since it's one of your
examples that B.4 is a case where these non-error incomplete processing type
problems can cause trouble:
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02.html#anc
hor46
Perhaps we can call them "Processing inconsistencies".
Scott K