Hi,
we got three pending errata on <http://www.openspf.org/RFC_4408/Errata>.
One of those pending errata is actually simple, it's about an "empty"
exp= modifier. We have it clear that exp= is in fact an exp-modifier,
not an unknown modifier, see (5c) "greedy unnown" in the minutes:
<http://www.openspf.org/Council_Meeting/2007-04-21>
<http://www.openspf.org/RFC_4408/Errata#greedy-unknown>
So now we've to decide what to do with it, three possible solutions
are listed: <http://www.openspf.org/RFC_4408/Errata#empty-exp>.
(1) The grammar for exp should be:
| explanation = "exp" "=" [ domain-spec ]
(2) Section 6.2/4 should be changed to say:
| If there are any DNS processing errors (any RCODE other than 0), or
| if no records are returned, or if more than one record is returned,
| or if there are syntax errors in the explanation string, then
| proceed as if no exp modifier was given.
(3)
| In section 6.2/4 replace <domain-spec> by <target-name>.
====================================================================
(1) is KISS, and generally I like KISS. But I'm not convinced that
it's what the spec. really wanted. It would allow policies like
"v=spf1 a -all exp=" with the same meaning as "v=spf1 a -all".
The empty exp= would have no effect, especially it would not disable
any default explanation provided by the checker. IMO if a syntax
construct has no effect at all (also not the only plausible effect),
then it's an obscure error on the side of the publisher.
====================================================================
(2) and (3) are very similar, both would flag exp= as syntax error.
The relevant paragraphs 6.2/3 and 6.2/4 in RFC 4408 about exp are:
| The <domain-spec> is macro expanded (see Section 8) and becomes the
| <target-name>. The DNS TXT record for the <target-name> is fetched.
|
| If <domain-spec> is empty, or there are any DNS processing errors
| (any RCODE other than 0), or if no records are returned, or if more
| than one record is returned, or if there are syntax errors in the
| explanation string, then proceed as if no exp modifier was given.
Solution (2) simply removes "<domain-spec> is empty, or" from the
picture, keeping the rest as is.
Solution (3) additionally keeps odd cases with an empty <target-name>
(after macro-expansion) as is, e.g. exp=%h could result in an empty
<target name> for an empty or missing HELO. In all cases the effect
of (2) and (3) is the same.
====================================================================
Before the Council starts its odd "toss a coin" ritual also known as
"Council meeting" - the Internet at large will survive any possible
outcome about this erratum - do you have an opinion as input ?
The proponents for this erratum can't directly recuse themselves as
long as Scott and Stuart alone have no quorum. Maybe the Council
could disable that rule exceptionally, but if then Scott and Stuart
don't pick the same solution we'd be in a procedural mess. This
problem isn't interesting enough for a "community vote", or is it ?
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
Powered by Listbox: http://www.listbox.com
we got three pending errata on <http://www.openspf.org/RFC_4408/Errata>.
One of those pending errata is actually simple, it's about an "empty"
exp= modifier. We have it clear that exp= is in fact an exp-modifier,
not an unknown modifier, see (5c) "greedy unnown" in the minutes:
<http://www.openspf.org/Council_Meeting/2007-04-21>
<http://www.openspf.org/RFC_4408/Errata#greedy-unknown>
So now we've to decide what to do with it, three possible solutions
are listed: <http://www.openspf.org/RFC_4408/Errata#empty-exp>.
(1) The grammar for exp should be:
| explanation = "exp" "=" [ domain-spec ]
(2) Section 6.2/4 should be changed to say:
| If there are any DNS processing errors (any RCODE other than 0), or
| if no records are returned, or if more than one record is returned,
| or if there are syntax errors in the explanation string, then
| proceed as if no exp modifier was given.
(3)
| In section 6.2/4 replace <domain-spec> by <target-name>.
====================================================================
(1) is KISS, and generally I like KISS. But I'm not convinced that
it's what the spec. really wanted. It would allow policies like
"v=spf1 a -all exp=" with the same meaning as "v=spf1 a -all".
The empty exp= would have no effect, especially it would not disable
any default explanation provided by the checker. IMO if a syntax
construct has no effect at all (also not the only plausible effect),
then it's an obscure error on the side of the publisher.
====================================================================
(2) and (3) are very similar, both would flag exp= as syntax error.
The relevant paragraphs 6.2/3 and 6.2/4 in RFC 4408 about exp are:
| The <domain-spec> is macro expanded (see Section 8) and becomes the
| <target-name>. The DNS TXT record for the <target-name> is fetched.
|
| If <domain-spec> is empty, or there are any DNS processing errors
| (any RCODE other than 0), or if no records are returned, or if more
| than one record is returned, or if there are syntax errors in the
| explanation string, then proceed as if no exp modifier was given.
Solution (2) simply removes "<domain-spec> is empty, or" from the
picture, keeping the rest as is.
Solution (3) additionally keeps odd cases with an empty <target-name>
(after macro-expansion) as is, e.g. exp=%h could result in an empty
<target name> for an empty or missing HELO. In all cases the effect
of (2) and (3) is the same.
====================================================================
Before the Council starts its odd "toss a coin" ritual also known as
"Council meeting" - the Internet at large will survive any possible
outcome about this erratum - do you have an opinion as input ?
The proponents for this erratum can't directly recuse themselves as
long as Scott and Stuart alone have no quorum. Maybe the Council
could disable that rule exceptionally, but if then Scott and Stuart
don't pick the same solution we'd be in a procedural mess. This
problem isn't interesting enough for a "community vote", or is it ?
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
Powered by Listbox: http://www.listbox.com