hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail
Aug 16, 2008, 10:44 AM
Post #7 of 7
(1805 views)
Permalink
|
Julian Mehnle wrote:
Hi Julian,
> a move and a new job.
Hopefully that went well.
> 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. Maybe add my new "macro mania" test
cases fixed by Stuart, see:
<http://article.gmane.org/gmane.mail.spam.spf.devel/1938>
The rationale for the new "macro mania" tests was a
developer trying to use a seriously limited .NET DNS
API.
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...25[at]789...50.example.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
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1007/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1007/
Powered by Listbox: http://www.listbox.com
|
rfc4408-invalid-dns-names.diff
