scott at kitterman
May 23, 2007, 6:50 AM
Post #2 of 9
(2468 views)
Permalink
|
|
Re: "Last Call" pending exp= (empty) erratum
[In reply to]
|
|
On Sunday 13 May 2007 09:02, Frank Ellermann wrote:
> 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 ?
>
I don't think we need a community vote for this.
I like option 2 because I don't like the idea that messing up the explanation
causes SPF errors. The exp modifier is about why something happened and
shouldn't change what happens.
Scott K
-------------------------------------------
-----------------------------------------------------------------------
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
|
