Alfred:
I have taken the liberty to include the spf-discuss mailing list in
this reply since that will reach many more developers who may have
insight into these issues.
As I mentioned to you in my earlier email, I greatly appreciate you
taking the time to review and make comments on this RFC.
I think most of the discussion about your comments will take place on
the spf-discuss mailing list. Please consider joining the list, if
you can. See: http://new.openspf.org/Forums for how to join and to
see the public archives if you just want to see the the discussion.
If you don't join the list, I'll summarize the discussion and email
you before contacting the RFC-editor.
SPF-discuss folks:
I received an email from Alfred HÎnes with comments on the recently
published RFC4408 suggesting some erratas.
Note that I have already sent the RFC-editor the following list of
erratas for RFC4408:
: Hi.
:
: It has come to my attention that there are at least three errors in
: RFC4408.
:
: 1) On page 1, in the IESG notes, "aParticipants" should be
: "Participants".
:
: 2) On page 40, the US-ASCII normative reference has an incorrectly
: indented second paragraph. Instead of:
:
: [US-ASCII] American National Standards Institute (formerly United
: States of America Standards Institute), "USA Code for
: Information Interchange, X3.4", 1968.
:
: ANSI X3.4-1968 has been replaced by newer versions with slight
: modifications, but the 1968 version remains definitive for
: the Internet.
:
: it should be:
:
: [US-ASCII] American National Standards Institute (formerly United
: States of America Standards Institute), "USA Code for
: Information Interchange, X3.4", 1968.
:
: ANSI X3.4-1968 has been replaced by newer versions with
: slight modifications, but the 1968 version remains
: definitive for the Internet.
:
:
: 3) On page 46, the DNS zone file example incorrectly had line breaks
: removed.
:
: Instead of:
:
: $ORIGIN _spf.example.com. mary.mobile-users A
: 127.0.0.2 fred.mobile-users A 127.0.0.2
: 15.15.168.192.joel.remote-users A 127.0.0.2
: 16.15.168.192.joel.remote-users A 127.0.0.2
:
: it should be:
:
: $ORIGIN _spf.example.com.
: mary.mobile-users A 127.0.0.2
: fred.mobile-users A 127.0.0.2
: 15.15.168.192.joel.remote-users A 127.0.0.2
: 16.15.168.192.joel.remote-users A 127.0.0.2
:
: All of these were correct in the original text submitted to the
: rfc-editor and the errors were the result of the rfc editing process.
: The first error, Meng and I couldn't have even known about because we
: were never given the chance to review the IESG note for errors.
: Fortunately, I don't think either of the other two errors are very
: serious.
:
: -wayne
Ok, on to Alfred's comments. I haven't trimmed anything so that everyone
will have the full context.
In <200605171834(_dot_)UAA04235(_at_)TR-Sys(_dot_)de> Alfred HÎnes
<ah(_at_)tr-sys(_dot_)de> writes:
Hello,
reading the recently published RFC 4408 (SPF) authored by you,
I found a few issues worth noting.
I use change bars (`|` in column 1) and ('^^^/vvv' style) up/down
pointing tags to emphasize the location of proposed changes in
the text fragments presented.
The items below are listed in ascending text order for ease of
reference.
(1) typo !
In the IESG Note for RFC 4408, the last 3 lines on page 1 saying:
v
aParticipants publishing SPF experiment DNS records should consider
the advice given in section 3.4 of RFC 4406 and may wish to publish
both v=spf1 and spf2.0 records to avoid the conflict.
should say:
| Participants publishing SPF experiment DNS records should consider
the advice given in section 3.4 of RFC 4406 and may wish to publish
both v=spf1 and spf2.0 records to avoid the conflict.
Yes, this typo was noticed by quite a few people and it is clearly an
error.
(2) misleading text ?
At the beginning of Section 6.1, RFC 4408 (on page 23) says:
If all mechanisms fail to match, and a "redirect" modifier is
present, then processing proceeds as follows:
redirect = "redirect" "=" domain-spec
The domain-spec portion of the redirect section is expanded as per
the macro rules in Section 8. Then check_host() is evaluated with
the resulting string as the <domain>. The <ip> and <sender>
arguments remain the same as current evaluation of check_host().
It should perhaps better say:
If all mechanisms fail to match, and a "redirect" modifier is
| present:
redirect = "redirect" "=" domain-spec
| then processing proceeds as follows:
The domain-spec portion of the redirect section is expanded as per
the macro rules in Section 8. Then check_host() is evaluated with
the resulting string as the <domain>. The <ip> and <sender>
| arguments remain the same as for the current evaluation of
check_host().
In my opinion, your suggested changes would make things slightly
clearer, but I don't think it is worth listing as an errata.
(3) [suspected] ABNF issue (#1)
The ABNF for the Received-SPF header field given in Section 7,
on page 25, contains the production:
key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" /
mechanism / "x-" name / name
Due to the lack of matching examples it remains unclear whether
this was really intended; I strongly suspect that the <key>
`mechanism` should be taken literally as well, i.e.:
key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" /
| "mechanism" / "x-" name / name
^^ ^^
This means that something like
mechanism="ip4:192.0.2.1"
might appear as a <key-value-pair> in a Received-SPF header field,
with the <mechanism> included after the "=" as a <quoted-string>
-- pretty in line with the explanations on page 26.
If this proposed correction indeed is appropriate, it must be
applied to the Collected ABNF in Appendix A, on page 43, as well.
It was my understanding that the 'mechanism' was in reference to the
<mechanism> ABNF term and that this would result in something like:
ip4:192.0.2.1
I confess that I'm really not sure though. Earlier versions of SPF
had support for "unknown mechanisms", and the actual mechanism was
displayed before the comment, rather than as a key-value-pair, so I
may have been confused.
My was also based off of reading of the Mail::SPF::Query header_pairs
function, but I'm not an expert in perl and I may have misread it. I
have also searched, and I can't and implementation that actually
creates either the "mechanism=" or the "ip4:..." form.
From what I can tell, the <key> ABNF term was introduced in
draft-schlitt-spf-classic-01pre1.xml on March 4th, 2005. Before then,
the key could be any <name>, and earlier drafts had *VCHAR.
(4) ABNF issue (#2)
The ABNF for the macro mechanism given in Section 8.1, on page 27,
contains the production:
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t"
According to the semantics presented at the bottom of page 27 and
subsequently in the text, the <macro-letter> "v" has been omitted
from this production.
Hence it should be replaced by:
vvvvvv
| macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "v" / "h" /
"c" / "r" / "t"
This modification must be applied to the Collected ABNF
in Appendix A, on page 43, as well.
This appears to be an error to me. good catch.
(5) typo ?
Again on page 27, below the ABNF, the RFC says:
The following macro letters are expanded in term arguments:
The words, `term arguments` seem to be imprecise:
- `term` does not appear in the published ABNF, only `terms`;
[perhaps the ABNF in Section 4.6.1,
terms = *( 1*SP ( directive / modifier ) )
once was written:
terms = *( 1*SP term )
term = directive / modifier
and the text has not been updated when the ABNF got reformulated]
- I am concerned that the word `arguments' might rise confusion
with the arguments of the check_host() function.
I therefore propose to enhance the above sentence to say:
The following macro letters are expanded in `terms` (cf. 4.5/4.6):
This wording dates back to at least draft-ietf-marid-protocol-00.txt
from July 12th, 2004. No one has commented on it before, but I guess
I can see that your wording is slightly clearer. I'm not sure that it
is worth making an errata over though.
(6) inconsistent style for literal characters
While, according to ABNF style, references to literal characters
are written with surrounding double quotes throughout the text,
on page 28 these are written with surrounding single quotes
("C" language style). That is inconsistent.
There are 7 occurrences (14 single quotes) on page 28 that should
be aligned with the remainder of the text.
The 5th text line:
A '%' character not followed by a '{', '%', '-', or '_' character is
a syntax error. [...]
should say:
| A "%" character not followed by a "{", "%", "-", or "_" character is
a syntax error. [...]
The 13th text line:
'r' = reverse value, splitting on dots by default
should say:
"r" = reverse value, splitting on dots by default
The first line of the second-to-last paragraph on page 28:
The 'r' transformer indicates a reversal operation: if the client IP
should say:
The "r" transformer indicates a reversal operation: if the client IP
Again, I guess I agree, but I don't know if it is a big deal.
(7) incomplete text in example
The preconditions for the examples in Section 8.2 on page 30
are incomplete
(to recall from the text, in the general case, <domain> is
independent from <sender>, and hence must be passed as an
argument to check_host(); therefore it needs to be specified
for the purpose of the examples),
and there's another deviation from the ABNF production names
(which is inconsistent, cf. top of page 31!).
Thus, the text lines,
The <sender> is strong-bad(_at_)email(_dot_)example(_dot_)com(_dot_)
The IPv4 SMTP client IP is 192.0.2.3.
The IPv6 SMTP client IP is 2001:DB8::CB01.
The PTR domain name of the client IP is mx.example.org.
macro expansion
------- ----------------------------
should say:
The <sender> is strong-bad(_at_)email(_dot_)example(_dot_)com(_dot_)
| The <domain> is email.example.com.
The IPv4 SMTP client IP is 192.0.2.3.
The IPv6 SMTP client IP is 2001:DB8::CB01.
The PTR domain name of the client IP is mx.example.org.
| macro-string expansion
| ------------ ----------------------------
While <sender> and <domain> can be different, none of the examples use
the the include: mechanism, so I think it is reasonable to assume they
the same.
I don't quite understand what you mean by "and there's another
deviation from the ABNF production names". Can you explain?
(8) typo in Reference
In Section 13.2, on page 41, there is a small typo in the
author name of the Ref. [RMX]: "Danish" should be "Danisch".
Furthermore, it would perhaps help the reader to more precisely
annotate this Ref., [RMX], and the subsequent one, [DMP], as
"expired Work in Progress" or
"Work in Progress (expired)"
instead of
"Work in Progress"
which might lead to the misconception of expected RFC publication.
*blush*
Yes, we got Hadmut's name wrong in this spot (but right in another
spot). This error appears to have been introduced in
draft-ietf-marid-protocol-02.txt, and never corrected. Maybe this was
when MarkL converted the drafts from flat text to XML? Dunno.
As far as RFC publication, when the MARID group was formed, the IETF
promised to have all of the input documents published as experimental
RFCs. That doesn't look like it will ever happen though.
We clearly need to have Hadmut's name corrected, I'm not sure about the
expired thing though.
(9) Appendix A
See item (4) and item (4) above for corrections to Appendix A,
on page 43.
(10) improper line folding
In Appendix B.3, the initial DNS zone file snippit is improper
folded; the lines,
$ORIGIN _spf.example.com. mary.mobile-users A
127.0.0.2 fred.mobile-users A 127.0.0.2
should read:
$ORIGIN _spf.example.com.
mary.mobile-users A 127.0.0.2
fred.mobile-users A 127.0.0.2
Agreed, I noticed and reported this error to the RFC-editor earlier.
Please comment.
I propose that you make freely use of the material presented above
to post an Author's Errata Note for RFC 4408 to the RFC Editor's
RFC Errata web pages.
But if you prefer, I can prepare this note and submit it on my own,
with your consent mailed to the RFC-Ed.
Thanks again for such going over the document in such close detail. I
wish we could have incorporated many of the changes much earlier.
Best regards,
Alfred HÎnes.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah(_at_)TR-Sys(_dot_)de
|
+------------------------+--------------------------------------------+
-------
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/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com