These to sections seem to conflict.
Note:
4.6
"Implementations MAY choose to parse the entire record first"
6
"While unrecognized mechanisms cause an immediate "PermError" abort"
During parsing the entire record, immediate is before processing.
Maybe as a reminder, section 6 should also say:
Implementations MAY choose to parse the entire record first and
return "PermError" if the record is not syntactically well formed.
Note: Unrecognized mechanisms are still syntactically well formed.
See Section 7.1.
I think it is confusing to have 2 sections that describe the same thing, but
differently. Maybe the 2 sections should be combined.
Thanks,
Guy
4.6 Record Evaluation
After one SPF record has been selected, the check_host() function
parses and interprets it to find a result for the current test. If
at any point a syntax error is encountered, check_host() returns
immediately with the result "PermError".
Implementations MAY choose to parse the entire record first and
return "PermError" if the record is not syntactically well formed.
Note: Unrecognized mechanisms are still syntactically well formed.
See Section 7.1.
From section 6. Modifier Definitions
While unrecognized mechanisms cause an immediate "PermError" abort,
unrecognized modifiers MUST be simply ignored. Modifiers therefore
provide a way to extend the record format in the future with backward
compatibility.
-----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 Mark
Lentczner
Sent: Thursday, October 14, 2004 12:59 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Unrecognized Mechanisms and Modifiers
On Oct 14, 2004, at 8:41 AM, guy wrote:
I don't like supporting unrecognized mechanisms. This will allow
typos and
other error to be ignored. I am not the first to say this. But if
someone
uses "ipv4", or "prt", these will be ignored. I think an error should
be
returned.
Please read the draft carefully. They are not ignored if processing
proceeds as far as trying to interpret them. If preceding directives
match, the unrecognized mechanism is never evaluated, and so yes it is
ignored. If the preceding directives all don't match, then the
processing the unrecognized mechanism fails with PermError.
Now, it has been proposed that it would better return PermError at the
start of processing if any mechanism is unrecognized. I actually agree
with this logic. However, the draft documents the SPF v1 common
understanding, and the above logic has been in SPF drafts for ages.
When we move forward with a new version of SPF, I'm all for changing
the language to be more strict.
- Mark
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com