Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14

[S Moonesamy <[e-mail]>]

Hi Murray,
At 01:21 29-04-2013, Murray S. Kucherawy wrote:
>Scott and I talked a bit about some of these points, and I thought 
>it might help if I went through the whole thing and commented on 
>it.  I hope this is helpful.  I've chopped out stuff where I have no 
>specific response or opinion about the points made, so this is only 
>a nearly-complete reply.

Thanks.  It's helpful.  I'll comment below.  My quoting is broken as 
some of my previous comments might be read as yours.

>You made these notes throughout your review.  I take it there's no 
>action for the WG here; you are just auditing "out loud" what 
>normative things in 4408bis were also present as-is in 4408, and 
>which have changed.

Yes.  It may also save other reviewers some work if they are auditing 
the normative things.

>
>    'Note that requirements for the domain presented in the EHLO or HELO
>     command are not always clear to the sending party, and SPF verifiers
>     MUST be prepared for the "HELO" identity to be malformed or an IP
>     address literal.'
>
>This RFC 2119 "MUST" is not in RFC 4408.  It is a substantive change 
>in my opinion.

>This was probably at my suggestion.  The issue here is that RFC2119 
>doesn't say "must" has any different meaning than "MUST" does, so we 
>should either be consistant and uppercase-ize it, or use some other word.

Authur Thisell mentioned that some of the lower-case (RFC 2119) words 
in RFC 4408 were intentional.  Barry Leiba, as Area Director, 
commented about "[treating] changes with due scepticism, with the 
idea that the change was made to fix a real problem, and it had 
better be right" [1].  I prefer not to bring the usual RFC 2119 
discussion into this working group.  RFC 4408 has been around for 
several years.  If there is a real problem there would be some 
discussion about it.  I would appreciate if someone points me to that 
discussion.

>In any event, I don't agree that this is actually a substantive change.

See above.

>    "This SPF check can only be performed when the "HELO" string is a
>    valid fully qualified domain."
>
>What is a valid fully qualified domain?
>
>I believe it means "a name comprising a sequence of DNS labels, 
>separated by dot characters, which when queried resolve to an A or 
>MX record".  It may have a proper definition in some other RFC 
>too.  Should we add one in the Introduction or Definitions?

I suggest dropping "valid" as the quick fix (see below).  I'll defer 
to RFC 5321 instead of having to add more text.

   This SPF check can only be performed when the "HELO" string is a
   fully-qualified domain name.

>In Section 2.3:
>
>   "An SPF-compliant domain MUST have valid SPF records as described in
>    Section 3."
>
>As a note the RFC 4408 text is:
>
>   "An SPF-compliant domain MUST publish a valid SPF record as described
>    in Section 3."
>
>The RFC 2119 MUST is redundant.
>
>
>In a recent conversation, Pete described this as "not really wrong, 
>but it's shouting."  I guess that means changing "MUST publish" to 
>"publishes" or something like that.

I am ok with the "publishes".

>   'If domain owners choose to publish SPF records and want to support
>    receivers making negative authorization determinations, then they MUST
>    publish records that end in "-all", or redirect to other records that do,
>    otherwise, no definitive determination of authorization can be made.'
>
>The document uses ADMD while there is "domain owners" in the 
>above.  I suggest reviewing that.
>
>I think they're synonymous.  Going with ADMD is probably a good idea.

Ok.

>  The RFC 2119 MUST is a substantive change.  Why is this a MUST?
>
>It is the only way within the protocol to cause negative 
>authorization determinations to occur.  It is an interoperability 
>requirement.  I believe this is correct.

Andrew Sullivan, as an individual, commented about the text [2].  I 
suggest going with what was suggested or else the working group will 
be discussing Issue #33 again.

>In Section 2.4:
>
>   'At least the "MAIL FROM" identity MUST be checked, but it
>    is RECOMMENDED that the "HELO" identity also be checked beforehand.'
>
>There is already a RFC 2119 MUST in Section 2.2.  There is also a 
>RFC 2119 RECOMMENDED in Section 2.1.  The above text restates 
>existing RFC 2119 requirements or recommendations.
>
>I agree; the redundancy should be resolved.  The cited sentence in 
>2.4 can probably go.

Ok.

>
>   'Without explicit approval of the domain owner, checking other
>    identities against SPF version 1 records is NOT RECOMMENDED because
>    there are cases that are known to give incorrect results.'
>
>How should this explicit approval be sought?  This recommendation 
>does not make sense.
>
>Adding "out-of-band" or "private" after "explicit" would probably 
>clear this one up.

Please use ADMD as we discussed previously (see above).  I am ok with 
either of the words suggested.

>In Section 2.4:
>
>   'When a mail receiver decides to perform an SPF check, it MUST use a
>    correctly-implemented check_host() function (Section 4) evaluated
>    with the correct parameters.'
>
>This RFC 2119 requirement states the obvious.  It basically says 
>that there is a requirement in draft-ietf-spfbis-4408bis-14 to use a 
>correct implementation of draft-ietf-spfbis-4408bis-14.
>
>I agree, that sentence can probably go.

Ok.

>
>   "Implementations have to take care to correctly extract the <domain>
>    from the data given with the SMTP MAIL FROM command as many MTAs will
>    still accept such things as source routes ..."
>
>The definition of <domain> is:
>
>   'the domain portion of the "MAIL FROM" or "HELO" identity.'
>
>I am not sure whether it is even a definition.  From an 
>implementation perspective the last paragraph of Section 2.4 is unclear.
>
>I don't agree.  I imagine by now you're aware of what this is for; 
>can you suggest some other text that accomplishes the intent?

<domain> definitions (not sure whether it is a definition) are 
mentioned in two places.  I suggest fixing that and then getting back 
to the above.

>   'Generating non-delivery notifications to forged identities that have
>    failed the authorization check is a source of backscatter and SHOULD
>    be avoided.'
>
>This RFC 2119 SHOULD is not in RFC 4408.  The above does not have 
>anything to do with Sender Policy Framework.  It was mentioned 
>during WG discussions that "SPF can help the backscatter problem" 
>[2].  This text may have been introduced in response to a review 
>[3].  Is this an enhancement or a clarification?
>
>
>I think it documents operational experience acquired since RFC4408 
>was published.  As for whether RFC2119 language is appropriate, I 
>agree that it isn't; it has nothing to do with SPF itself, though it 
>is a side effect of its use.  I suggest changing SHOULD to "needs to".

My reading of the above is that it is neither an enhancement or a 
clarification.  I suggest removing the text.

>In Section 2.6.1:
>
>   'A result of "none" means either (a) no syntactically valid DNS domain
>    name was extracted from the SMTP session that could be used as the
>    one to be authorized, or (b) no TXT records were retrieved from the
>    DNS that appeared to be intended for use by SPF verifiers.'
>
>I suggest "DNS TXT records".  What is a syntactically valid DNS 
>domain name?  The definition of "none" in RFC 4408 is clear (to me).
>
>
>"DNS TXT records" is fine but probably not necessary at this point 
>in the document.
>
>We discussed the "syntactically valid" thing above.

I'll leave this one to Andrew.

>This definition of "none" is more precise than it was in 
>RFC4408.  The 4408 definition was:
>
>
>    A result of "None" means that no records were published by the domain
>    or that no checkable sender domain could be determined from the given
>    identity.  The checking software cannot ascertain whether or not the
>    client host is authorized.
>
>This text did not account for the notion that TXT records were 
>returned that didn't start "v=spf1".  It also wasn't clear about 
>what "checkable" meant.  I believe the bis definition is better.

Ok.  By the way, if anyone disagrees, please comment.

>In Section 2.6.7:
>
>   'A "permerror" result means the domain's published records could not
>    be correctly interpreted.  This signals an error condition that
>    definitely requires manual intervention to be resolved.'
>
>What is "manual intervention" in the above?
>
>
>"Operator intervention" might be more consistent with common IETF usage.

Ok.

>In Section 3:
>
>   'An SPF record is a DNS record that declares which hosts are, and are
>    not, authorized to use a domain name for the "HELO" and "MAIL FROM"
>    identities.'
>
>How are hosts which are not authorized to use a domain name listed 
>in a SPF record?
>
>It's implicit in that the set that is not authorized is the 
>complement to the set that is authorized.  If we want to make it 
>clear, we could say "which hosts are, and thus also which are not," 
>or something like that.

Ok.  This can be "no action required" if the working group agrees.

>   "The SPF record is a single string of text."
>
>What is a single string of text?  It may be easier to state this in 
>terms of record format.
>
>I don't think that statement is unclear, but I agree with the 
>improvement suggestion.  Maybe:
>
>"An SPF policy statement is expressed as a single string of text 
>encoded in a DNS TXT record."

That sounded better.  I'll leave it to Andrew to catch my mistake if 
I got this one wrong.

>    'ADMDs publishing SPF records SHOULD try to keep the number of
>    "include" mechanisms and chained "redirect" modifiers to a minimum.'
>
>What is the minimum?  Note that this RFC 2119 SHOULD is in RFC 4408.
>
>
>There isn't a specific minimum.  The expression means "don't use 
>this technique unless you absolutely need it".

I didn't understand that as there wasn't any explanation for the RFC 
2119 SHOULD.  I suggest adding an explanation or rewriting the text 
so that the expression (see above) is clear.

>
>   'ADMDs SHOULD also try to minimize the amount of other DNS information
>    needed to evaluate a record.'
>
>This RFC 2119 SHOULD is also in RFC 4408.  There are two RFC 2119 
>SHOULDs in the last paragraph of Section 3.  This usage of RFC 2119 
>key words does not help the SPF "publisher".   In my opinion the 
>"SHOULD try" in this context uses the RFC 2119 key word in unorthodox ways.
>
>I agree with "SHOULD try", as that's arguably not 
>actionable.  "SHOULD minimize" is probably fine, however.

Ok.

>In Section 3.1:
>
>   'SPF records MUST be published as a DNS TXT (type 16) Resource Record
>    (RR) [RFC1035] only.'
>
>I would ask why "MUST be published ... only".  By the way, Section 3 
>has a reference to Section 4 for record format instead of Section 
>3.1.  Is that correct?
>
>The text is not incorrect, but it's also not necessary.  Dropping 
>"only" is probably sufficient.
>
>The reference is indeed incorrect.

Ok.

>In Section 3.2:
>
>   "A domain name MUST NOT have multiple records that would cause an
>    authorization check to select more than one record."
>
>This RFC 2119 MUST NOT was in RFC 4408.  Is this to help the SPF 
>"publisher" and if so, how does it help?
>
>I believe it is an advisory to publishers of the consequences of 
>having more than one "v=spf1" record published.

Ok.

>In Section 3.3:
>
>   "As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS
>    record can be composed of more than one string."
>
>See previous comment about " a single string".
>
>
>This use is correct, as it describes the fact that there are many 
>ways to encode a single high-level string into multiple low-level 
>"character-strings" as defined in RFC1035.

I'll leave this to Andrew.

>   "If a published record contains multiple character-strings, then the
>    record MUST be treated as if those strings are concatenated together
>    without adding spaces."
>
>This RFC 2119 MUST is also in RFC 4408.  I suggest removing the 
>"MUST" in the example.
>
>I disagree.  It's required for interoperability.

Interoperability requirements are not specified through examples.

>
>   "TXT records containing multiple strings are useful in constructing
>    records that would exceed the 255-byte maximum length of a character-
>    string within a single TXT record."
>
>I suggest using "octet" instead of "byte".  I'll point the working 
>group to CVE-2008-2469 in case it might wish to consider that issue.
>
>
>How is an octet different from a byte in this context?  This strikes 
>me as a stylistic issue at best.

It's a term of art used in DNS-related specifications.

>In Section 4:
>
>   "A compliant SPF implementation MUST do something semantically 
> equivalent to
>   this description."
>
>It's unusual to see a "do something" RFC 2119 requirement in a 
>specification.  Is the SPFBIS WG working on compliance for SPF implementations?
>
>
>  RFC6376 is an example of a standards track document that uses 
> RFC2119 MUST in this way.  I'm sure I've seen others but I can't 
> think of them at this hour.  I think it's fine.

I suggest fixing the "do something".

>   "Mail receivers that perform this check MUST correctly evaluate the
>    check_host() function as described here."
>
>Where does "mail receivers" fit in the Sender Policy Framework?  The 
>"MUST correctly evaluate" is stating the obvious.
>
>
>I'm not understanding how the answer to the first question isn't obvious.
>
>I agree with the second point.

There was a problem of terminology previously.  SPF verifiers is used 
in other parts of the specification.

>
>   "Implementations MAY use a different algorithm than the canonical
>    algorithm defined here, so long as the results are the same in all
>    cases."
>
>Why is this a RFC 2119 MAY?  I am aware that the text is in RFC 4408.
>
>This seems to me to be another stylistic question, since MAY in 
>RFC2119 terms doesn't mean much.

I'll say ok as the text is already in RFC 4408.

>In Section 4.1:
>
>   '<domain> - the domain that provides the sought-after authorization
>               information; initially, the domain portion of the "MAIL
>               FROM" or "HELO" identity.'
>
>The above text is different from the text in Section 2.4.
>
>I think I agree; I would prefer to have it defined in one place, and 
>have other points in the document reference it.

I mentioned this previously (see above).

>In Section 4.3:
>
>   "If the <domain> is malformed (e.g. label longer than 63 characters,
>    zero-length label not at the end, etc.)"
>
>  That should be "octets".
>
>Since the DNS is all in ASCII, they're synonymous.  That said, we 
>may as well be consistent.

DNS is not all in ASCII but let's avoid that side-discussion.

>
>   "Properly formed domains are fully qualified email domains as
>    described in [RFC5321] Section 2.3.5."
>
>What are "properly qualified email domains"?
>
>Is the reference defining that term not appropriate?

The reference is correct, the wording could be kept simple:

   Properly formed domains are described in [RFC5321] Section 2.3.5.

The wording is not that good but I could not think of anything better.

>In Section 4.4:
>
>   "In accordance with how the records are published (see Section 3
>    above), a DNS query needs to be made for the <domain> name, querying
>    for type TXT only."
>
>I don't understand the sentence.
>
>Query the HELO domain or the MAIL FROM domain, as described in Section 3.

I read the first paragraph of Section 4.4 as meaning that the DNS 
query is for Type TXT only.  I suggest explaining that the record 
lookup is done by query for the SPF record described in Section 
3.  By the way, the text you suggested for Section 3 fits in nicely.

>   'Alternatively, for a server failure (RCODE 2) result, check_host()
>    MAY track failures and treat multiple failures within 24 hours for
>    the same domain as "permerror".'
>
>This text is not in RFC 4408.  I found a note in Issue #1 [5] and in 
>a message [6].
>
>Are there any implementations that do this?  If so, that's the 
>justification; it's practical experience.  If not, we should 
>consider dropping it.

I'll wait for feedback on this.

>In Section 4.6.2:
>
>   "If there are no more mechanisms, the result is specified in
>    Section 4.7."
>
>This sentence does not make sense.
>
>
>How about: "After all mechanisms have been processed and no matches 
>are found, the result is determined according to Section 4.7."

Thanks, that's better.

>   "If this number is exceeded during a check, a permerror MUST be returned."
>
>I read this as if an implementation-specific limit is reached a 
>permerror is returned.  There are two RFC 2119 MUST in the 
>above.  That can be reduced to one MUST.
>
>
>I'm not sure I agree.  SecDir has pushed the fixed query limit on 
>other topics in the past, which is the first MUST, and the second 
>MUST prescribes a specific result that has to occur when the limit 
>is reached which is important for interoperability.

For context we are at Section 4.6.4.  I'll quote some text from it:

  "If this number is exceeded during a check, a permerror MUST be returned."

  'If this limit is exceeded, the "mx" mechanism MUST produce a
   "permerror" result.'

  'If this limit is exceeded, all records other than the first 10
   MUST be ignored.'

I prefer not to discuss about the last one (see quoted text) 
again.  In terms of coding it is easier if I am told to return a 
"permerror" results when DNS limit X is exceeded.  That can be 
specified with one RFC 2119 MUST.  I am taking in consideration the 
SecDir recommendation and interoperability.  Speaking of 
interoperability the following text:

   'SPF implementations MUST limit the total number of mechanisms and
    modifiers ("terms") that cause any DNS query to at most 10 during SPF
    evaluation.'

does not encourage it because of the "at most".  Section 4.6.4 does 
not make things easier for DNS operations as the reader cannot 
identify the limits easily due to the exceptions.  I am ok with the 
exceptions.  What I am suggesting is not to use two RFC 2119 MUST if 
it there is a way for it to be done with one RFC 2119 MUST.

>    'MTAs or other processors SHOULD impose a limit on the maximum amount
>    of elapsed time to evaluate check_host().  Such a limit SHOULD allow
>    at least 20 seconds.  If such a limit is exceeded, the result of
>    authorization SHOULD be "temperror".'
>
>There are three RFC 2119 SHOULDs in the above.  I suggest rewriting 
>the text to reduce that.
>
>All three of them seem to be important interoperability points.  We 
>could common factor the SHOULD and then present three bullets in a 
>list, but the meaning is the same.

Throughout the document the words "MTA", "other processors", "mail 
receivers", "SPF implementations" and "SPF verifiers" are used.  That 
looks inconsistent to me.

Here's an example of a rewrite:

   MTA or other processors SHOULD:

   (a) impose a limit on the maximum amount of elapsed time to 
evaluate check_host().

   (b) allow for at least 20 seconds.

   (c) return a result of authorization of "temperror".

I don't see what Points (a) or (b) has to do with 
interoperability.  Trying to common factor the RFC 2119 SHOULD 
reduces occurrences of the word instead of addressing the issue.  I 
suggest understanding the intent first before working on the text to be added.

>   'SPF implementations SHOULD limit "void lookups" to two.'
>
>What are void lookups?
>
>
>Last paragraph of Section 4.6.

That would be 'These are sometimes collectively referred to as "void 
lookups".' in Section 4.6.4.  Here's is a rewrite:

   SPF implementations SHOULD limit what is sometimes collectively referred
   to as "void lookups" to two.

See comment below.


>   "In this case, a default of two is RECOMMENDED."
>
>Why is "two" recommended?
>
>Interoperability; if one is two while another is 10, different SPF 
>results can be returned.

Here is the text:

   "An implementation MAY choose to make such a limit configurable.  In
    this case, a default of two is RECOMMENDED."

There is the RFC 2119 SHOULD and the RFC 2119 RECOMMENDED.

Here's how I look at it: Is the working group recommending a limit 
which is configurable?  What's the recommended value?  Is the value 
some arbitrary number?

>
>   'Note that records SHOULD always use either a "redirect" modifier or
>    an "all" mechanism to explicitly terminate processing.'
>
>Why is there a RFC 2119 key word in a note?
>
>
>Since the explanation I've been given is that it's better for human 
>debugging, I think I agree since the advice is not specific to the 
>protocol itself.

I suggest removing the RFC 2119 SHOULD.

>In Section 4.8:
>
>   'e.g., "foo..example.com") or overlong labels (more than 63
>    characters).'
>
>I suggest octets.
>
>
>Again, synonymous.

My guess is that someone might file an erratum about this after 
publication and the erratum will not be rejected.

>in Section 5:
>
>   'SPF implementations on IPv6 servers need to handle both "AAAA" and "A"
>    secords, for clients on IPv4 mapped IPv6 addresses [RFC4291].'
>
>
>There is a typo, "records".
>
>I'll flag the above for review by people with IPv6 expertise.
>
>
>This was covered in a different thread.  I believe a proposed text 
>fix was made that people seemed to like.

Yes.

>In Section 5.3:
>
>   'a   = "a"      [ ":" domain-spec ] [ dual-cidr-length ]'
>
>"dual-cidr-length" is introduced in this sub-section.  I had to 
>search through the draft to find out what it means.
>
>That happens sometimes.  :-)

:-)

>In Section 5.4:
>
>   'Note regarding implicit MXs: If the <target-name> has no MX records,
>    check_host() MUST NOT pretend the target is its single MX, and MUST
>    NOT default to an A or AAAA lookup on the <target-name> directly.'
>
>There are two RFC 2119 MUSTs in the above.  This is over-usage of 
>RFC 2119 key words.  This text was in RFC 4408.  This is not a 
>divergence from RFC 5321, it is a contrary to Section 5 of RFC 5321.
>
>
>I believe the advice should remain, but it could be simplified:
>
>"Note regarding implicit MXes: If the <target-name> has no MX 
>records, check_host() MUST NOT apply the implicit MX rules of 
>RFC5321 by querying for an A record for the same name."

I would suggest removing the RFC 2119 MUST if the suggested text is a 
note.  The specification mentions "compliance" and yet it does not 
follow RFC 5321.  According to RFC 4408 "This behavior breaks with 
the legacy "implicit MX" rule".  I'll discuss this with the 
Responsible Area Director before saying more.

>In Section 5.5:
>
>  "This mechanism SHOULD NOT be used."
>
>I suggest providing a reason for this.
>
>
>The very next sentence is "See below for discussion."

It would be clearer to have:

    This mechanism SHOULD NOT be used it is not as reliable as other 
mechanisms in
    cases of DNS errors, and it places a large burden on the .arpa 
name servers.

>   "If used, proper PTR records MUST be in place for the domain's hosts
>    and the "ptr" mechanism SHOULD be one of the last mechanisms checked."
>
>Those RFC 2119 key words are not in RFC 4408.  I don't see how this 
>RFC 2119 change qualifies as a clarification or explanation.
>
>It was "must" vs. MUST in RFC4408.  It's otherwise unchanged.

It's a change.  I suggest reverting it.  Telling people who are using 
the "ptr" mechanism that they must have PTR records is stating the obvious.

>   "It is, however, still in use and part of the SPF protocol, so compliant
>   check_host() implementations MUST support it."
>
>What is a compliant check_host() implementation?
>
>
>One that complies with this specification.

Ok. :-)

>
>In Section 5.6:
>
>   "ip6-network      = <as per [RFC 4291], section 2.2>"
>
>I suggest that the above reference be verified for correctness.
>
>
>Looks right to me.  The CIDR expression is in the optional token 
>next to it, so this has to be just a plain IPv6 address, so that's 
>the right reference.

I suggest reading RFC 5952.

>In Section 5.7:
>
>   'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all'
>
>I'll flag this for review by DNS folks.
>
>What's the specific question being asked of DNSDIR here?

My question would be: "Is Section 5.7 of the draft correct?".

>In Section 6:
>
>   'The modifiers defined in this document ("redirect" and "exp") MAY
>    appear anywhere in the record, but SHOULD appear at the end, after
>    all mechanisms.'
>
>This text is in RFC 4408.  I would label the RFC 2119 usage as defective.
>
>
>Why?

The text tells me that it is ok if the modifiers appear anywhere but 
they should appear at the end after all mechanisms.  It would be 
clearer to say that it should appear after all mechanisms.

>In Section 7.1:
>
>   'The "toplabel" construction is subject to the LDH rule plus
>    additional top-level domain (TLD) restrictions.'
>
>Where can I find these restrictions?  Please note that I have read 
>the Informational RFC.
>
>
>I'm pretty sure it's referring to common TLD conventions.

The text tells me that there are restrictions.  I'll ask Andrew how 
this is usually handled.

>   "This macro SHOULD NOT be used.  See Section 5.5 for the discussion
>    about why not."
>
>This comes out as a flippant explanation for the RFC 2119 SHOULD.
>
>
>I think it's fine, though I suggest changing "the discussion about 
>why not" to just "discussion".

Please turn it into one sentence.

>
>   "This SHOULD be a fully qualified domain name, but if one does not
>    exist (as when the checking is done by a MUA) or if policy restrictions
>    dictate otherwise, the word "unknown" SHOULD be substituted."
>
>The RFC 2119 key words are in RFC 2119.  I don't know what to say.
>
>
>I think that looks fine as-is, though we could change the first 
>SHOULD to "ought to" because it's a transformation of other input 
>and not an implementation choice.  (And I assume you mean they were 
>in RFC4408.)

Yes, I meant that there were in RFC 4408.  I suggest that the working 
group looks for a simple sentence to replace the existing one.

>   "When the result of macro expansion is used in a domain name query, if
>    the expanded domain name exceeds 253 characters (the maximum length
>    of a domain name), the left side is truncated to fit, by removing
>    successive domain labels (and their following dots) until the total
>    length does not exceed 253 characters."
>
>Where is it specified that the maximum length of a domain name is 
>253 characters?
>
>
>RFC1035 says it's 255.
>
>   "Care has to be taken by the sending ADMD so that macro expansion for
>    legitimate email does not exceed the 63-character limit on DNS labels."
>
>Where is that 63-character limit specified?
>
>
>RFC1035, Section 2.3.1.

I suggest using Section 2.3.4.

>In Section 9.1:
>
>   "The Received-SPF header field is a trace field (see [RFC5322] Section
>    3.6.7) and SHOULD be prepended to the existing header, above the
>    Received: field that is generated by the SMTP receiver."
>
>"prepended to the existing header" does not sound right.
>
>
>It's correct; "header" is the entire header block, while "header 
>field" is one field in it.  (Section 2.1 of RFC5322.)

Thanks for explaining this.

>    "It MUST appear above all other Received-SPF fields in the message."
>
>How does this fit into the previous RFC 2119 SHOULD?
>
>
>It SHOULD be prepended to the whole header block, but even if it 
>isn't, it MUST appear above any other Received-SPF field.

Ok.


>In Section 10.1.2:
>
>   "Publishing SPF records for domains that send no mail is
>    a well established best practice."
>
>I am not aware of that best practice.  I did a few DNS queries:
>
>;; QUESTION SECTION:
>;bing.com.                      IN      TXT
>
>;; ANSWER SECTION:
>bing.com.               3600    IN      TXT     "v=msv1 
>t=6097A7EA-53F7-4028-BA76-6869CB284C54"
>
>;; QUESTION SECTION:
>;com.com.                       IN      TXT
>
>;; ANSWER SECTION:
>com.com.                293     IN      TXT 
>"google-site-verification:esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k"
>
>
>What are you saying here?  This is an existence proof of non-mailing 
>domains that don't publish SPF records, but it doesn't contradict 
>the statement made in the draft.

The claim is being made without any supporting material.

>In Section 10.1.3:
>
>   "SPF functionality is enhanced by administrators ensuring this
>   identity is set correctly and has an appropriate SPF record."
>
>How is SPF functionality enhanced?
>
>
>When MAIL FROM is null, it's important that HELO be right in order 
>to get any useful result from SPF.

Ok.

>In Section 10.2:
>
>   "As stated elsewhere in this document, there is no normative requirement
>    for specific handling of a message based on any SPF result."
>
>The "as stated elsewhere" is vague.
>
>
>Section 8 discusses it, if you're saying you'd like a specific reference.

I suggest a reference.

>   'The primary considerations are that SPF might return "pass" for mail
>    that is ultimately harmful (e.g., spammers that arrange for SPF to
>    pass using nonsense domain names'
>
>What are "nonsense" domain names?
>
>
>"arbitrary", "discardable", something like that.

"discardable" sounds the better one of the two.

>In Section 10.3:
>
>   "The mediator can make the newly-posted message be as similar or as
>    different from the original message as they wish."
>
>The sentence seems incomplete, i.e. similar to what.
>
>
>The original message.
>
>   "For the operation of SPF, the essential concern is the email
>    address in the 5321.MailFrom command for the new message."
>
>What does this mean?
>
>
>In the context of mediators (which is the title of this subsection), 
>the RFC5321.MailFrom field used by the mediator to inject a new 
>message is the most important consideration.

I suggest writing the sentence clearly instead of relying on the title.

>
>   'Because SPF evaluation is based on the IP Address of the "last"
>    sending SMTP server, the address of the mediator will be used, rather
>    than the address of the SMTP server that sent the message to the
>    mediator.'
>
>I'll note that this is a mix of RFC 5321 and RFC 5598.  The result 
>is clear or unclear depending on the background of the reader.
>
>
>I think this is clear.  You're familiar with the architecture here; 
>what do you think would fix it?

Dave Crocker commented about this.  I suggest leaving it as it if 
there isn't any disagreement.

>In Section 11.5:
>
>   "An SPF compliant receiver gathers information from the SMTP commands
>    it receives and from the published DNS records of the sending domain
>    holder"
>
>I suggest explaining the untrusted part.
>
>
>Agreed.  A second sentence indicating most of that input is 
>unverified is probably in order, with references if possible.

Ok.

>In Section 13.1:
>
>   "The format of this type is identical to the TXT RR [RFC1035]"
>
>The format is not identical, i.e. it's a different RR.  I suggest 
>keeping the IANA Considerations Section simple, i.e. clearly explain 
>to IANA what action is requested.
>
>
>The format is indeed identical, right down to the octet.

Andrew explained this to me.  I'll say ok.

>References:
>
>Why is RFC 1123 a normative reference?
>
>
>It defines the "%"-hack, of which implementers need to be aware 
>(i.e., code needs to be able to handle that syntax).

Ok.

>Why is RFC 3864 a normative reference?
>
>A BCP (e.g., a registration procedure) followed is always a 
>normative reference, I believe.

I guess it is a matter of style.


>ABNF:
>
>Did anyone verify the ABNF?
>
>
>It's been some time but I did a full pass over it previously.

Thanks for doing that.  I did not spot any mistakes.

>In Appendix C:
>
>In Section E.1:
>
>   'This would cause a lookup on an DNS white list (DNSWL) and cause a
>    result of "fail" only for email not either coming from the
>    domain's mx host(s) (SPF pass) or white listed sources (SPF
>    neutral).'
>
>I didn't find any discussion about this on the SPFBIS mailing 
>list.  is there an explanation for this change between RFC 4408 and this draft?
>
>
>It was in 9.3 in the previous document and has been reworded a 
>little.  It's otherwise unchanged.

The text from Section 9.3 is already in the draft.  This is 
additional material instead of a little rewording.  There was a 
concern about "a tendency to include an example of every possible use 
of SPF to solve some problem".  I suggest removing the example.

>   "This document updates and replaces RFC 4408 that was part of a group
>    of simultaneously published Experimental RFCs (RFC 4405, RFC 4406,
>    RFC 4407, and RFC 4408) in 2006.  At that time the IESG requested the
>    community observe the success or failure of the two approaches
>    documented in these RFCs during the two years following publication,
>    in order that a community consensus could be reached in the future."
>
>Why is this needed?  The SPFBIS WG produced RFC 6686 to resolve the 
>experiment.
>
>   "SPF is widely deployed by large and small email providers alike.
>    There are multiple, interoperable implementations."
>
>Someone might point out that this is marketing instead of text 
>relevant to a protocol.  I'll mention that one or more significant 
>issues (e.g. Issue #9) was identified during the WG 
>discussions.  Issue #9 was not listed as the errata.  I suggest 
>removing the section as it will be less text and there is already 
>two informative references to help the reader find background information.
>
>
>I propose leaving this stuff in there as information to the 
>IESG.  If they think it's unnecessary, they can ask that we remove 
>it, or they can do so in a note to the RFC Editor.

I'll comment about this later.

I'll add a credit for you in the write-up.

Regards,
S. Moonesamy (as document shepherd)


1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02240.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02784.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02281.html