spf-discuss
[Top] [All Lists]

[spf-discuss] Re: Last erratum last call

2008-09-07 08:19:55
[Trimmed fwd from the devel list where it got no reply]:

[...] 
I think all of us are mostly on the same page now with
regard to the issue matter.

Yes, as far as possible.  Clearly an issue that needs a
better fix than the "last erratum" at some point in time.

Your proposal puts all the stuff in the "PermError"
definition in section 2.5.7.  I don't think that's
appropriate.

More like KISS than appropriate.  And your concern was
that some implementations don't return a PemError, but
ignore the directive.

How about the attached diff instead?

I've split the text in "variant 1" (as it was), adding
your text as "variant 2".  

"Variant 2" consists of two parts, the forward pointer
to section 8 (macros) is replaced by a forward pointer
to section 4.8 (domain-spec).

The second part of "variant 2" is a new paragraph to be
inserted at the end of section 4.8.  One statement in
your proposal IMO needs some wordsmithing before a new
consensus poll:

? Some implementations choose to treat as a no-match
? mechanisms, and ignore modifiers, with such names,
? whereas others throw a "PermError" exception.

| Some implementations treat such situations as "no
| match", i.e. ignore the directive, whereas others
| throw a "PermError" exception.

Is that what you mean ?  Simply edit it on the wiki
as it should be.  While you are at it, there are two
other points:

+ Note: Historically, this document has made no
+ provisions for how to handle <domain-spec>s, or
+ macro-expansions thereof, that are syntactically
+ invalid per [RFC1035]

"Historically, this document has made" sounds odd in
an erratum supposed to be a part of what the document
really does.  IOW, it sounds like text for a 4408bis.

How about "This document does not exactly specify
how to handle" ... ?  After all we are going to say
one thing, either "no match" or "PermError", in the
next statement.

In any case I have adjusted the test suite to
allow both the "PermError" and no-match behaviors

Great.  As we are clear about what we want, only the
precise way how to say it is still open, you could
publish it now.

[...]
The "quoted string" + "quoted pair" business will be
a bit more complex, it could go into an update of the
test suite when we have that clear.  

Using upper case %{S} in a <domain-spec> can also have
odd effects, especially in conjunction with the "last"
erratum limit 63:

mail from: 
<123(_dot_)(_dot_)(_dot_)25(_at_)789(_dot_)(_dot_)(_dot_)50(_dot_)example(_dot_)com>

"v=spf1 exists:%{S} ?all"

.example (8) + .com (4) + 25 + @ (1) + 24 => 62.  But
if the @ is URL encoded for an upper case S it is 64.

 Frank
-- 
For Julian, I haven't found a message where you talked
about the quoted string behaviour in my local folders,
but I have not yet tried to dig in the GMaNe archives.



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

<Prev in Thread] Current Thread [Next in Thread>
  • [spf-discuss] Re: Last erratum last call, Frank Ellermann <=