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

["Murray S. Kucherawy" <[e-mail]>]

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.

On Tue, Apr 23, 2013 at 4:08 PM, S Moonesamy <[e-mail]> wrote:

> In the Abstract:
>
>   "This document describes version 1 of the Sender Policy Framework
>    (SPF) protocol, whereby an ADMD can explicitly authorize the hosts
>    that are allowed to use its domain names, and a receiving host can
>    check such authorization."
>
> ADMD should be expanded in the above.  This was pointed out in a review
> posted on August 26, 2012 [1].
>

Agree.


> In Section 2.1:
>
>   'It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
>    identity, but also separately check the "HELO" identity by applying
>    the check_host() function (Section 4) to the "HELO" identity as the
>    <sender>.'
>
> As a note this "RECOMMENDED" is also in RFC 4408.
>

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.


>    '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.

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


>   "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?


> 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.


>   '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.


> 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.


> 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.


>   '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.


> 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.


>   "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?


>   'Performing the authorization other than using the return-path and
>    client address at the time of the MAIL command during the SMTP
>    transaction can cause problems, ..'
>
> Shouldn't that be "authorization check"?
>

Yes.


>   '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".


> In Section 2.6:
>
>   "An SPF verifier implements something semantically identical to the
>    function defined there."
>
> John Levine commented about this during the WGLC [4].  I am listing this
> as a reminder for myself.
>

I agree with John.


> 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.

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.


> In Section 2.6.2:
>
>   'The domain owner has explicitly stated that it is not asserting
>    whether the IP address is authorized.  This result MUST be treated
>    exactly like the "none" result; the distinction exists only for
>    informational purposes.'
>
> As a note, the RFC 2119 MUST is in RFC 4408.  The Introduction Section
> mentions "ADMDs can authorize hosts to use their domain names".  The above
> uses "domain owner".
>

Covered earlier.


> 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.


> 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.


>   "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."


>   '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".


>   '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.


> 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.


> 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.

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.


>   "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.


>   "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.


> 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.

  "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.



>   "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.


> 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.


> 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.


>   "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?


>   "Internationalized domain names MUST be encoded as A-labels, as
>   described in Section 2.3 of [RFC5890].on 2.3 of [RFC5890]."
>
> I'm listing the above and leave it to Area Director guidance.  Please note
> that it is a new RFC 2119 requirement.
>

I'm pretty sure RFC4408 pre-dates most of the IDN work, so this is a
modernization step.  I think it's important to include, and it also does
the same thing DKIM did, which is now Draft Standard.  If we don't, there's
no guidance for use of SPF in the IDN context.  The alternative is to spin
up another document (which we're not chartered to do) that discusses use of
SPF in the IDN context.


> 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.


>   '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.


> 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."

  "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.


>   '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.


>   'SPF implementations SHOULD limit "void lookups" to two.'
>
> What are void lookups?
>

Last paragraph of Section 4.6.


>   "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.


>   '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.


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

Again, synonymous.


> 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.

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."

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."


>   "To prevent DoS attacks, more than 10 PTR names
>    MUST NOT be looked up during the evaluation of a "ptr" mechanism
>    (see Section 4.6.4)."
>
> The above restates a previous RFC 2119 MUST.
>

Agreed.


>   "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 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.


> 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.


> 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?


> 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?


> In Section 6.2:
>
>   "Since the explanation string is intended for an SMTP response and
>    [RFC5321] Section 2.4 says that responses are in [US-ASCII], the
>    explanation string MUST be limited to US-ASCII.'
>
> It would be easier to defer to RFC 5321 instead of setting a RFC 2119
> requirement in this draft.  I note that this requirement was not in RFC
> 4408.
>

I agree that this could be expressed non-normatively (e.g. "needs to be").


>   "Software SHOULD make it clear that the explanation string
>    comes from a third party."
>
> I could not understand what that means in RFC 2119 terms.  The draft uses
> RFC 2119 key words by example instead of providing an explanation.
>

I agree; we're talking about interoperability between humans here, and not
between implementations.


> 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.

In Section 7.3:
>
>   "-exists:%(ir).sbl.spamhaus.**example.org<http://sbl.spamhaus.example.org>
> "
>
> I commented about vendor-neutral previously [8].  The above is a way to
> get around the objection [9].  I suggest cleaning this up.
>

Sure.


>  "so trailing dots SHOULD NOT be published by domain owners"
>
> Why is it "domain owners"?
>

ADMDs is fine here.


>   "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".


>   "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.)


>   "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.


> It is odd to have RFC 2119 requirements under a "Notes" heading.
>

Agreed.


> In Section 8.2:
>
>   'A "neutral" result MUST be treated exactly like the "none" result;
>    the distinction exists only for informational purposes.'
>
> Why is an existing RFC 2119 restated?
>

Agreed.


> In Section 8.5:
>
>   "The domain owner believes the host is not authorized but is not willing
>    to make a strong policy statement."
>
> Why is it domain owner?
>

ADMD.


> 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.)


>   "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.


> in Section 10:
>
>   "This section is not a "how-to" manual, or a "best practices" document,
>    and it is not a comprehensive list of what such entities SHOULD do in
>    light of this document."
>
> What is the meaning of the RFC 2119 SHOULD in the above?
>

Agreed, it's inappropriate here.


> 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:**
> esSnoZdChIkkfCfS9MMgqNhE0yaXfn**nZWdZPuBf7e8k"
>

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.


> 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.


> 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.


>   '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.


> 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.


>   '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?


> 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.


> In Section 11.6:
>
>   "Checking SPF records causes DNS queries to be sent to the domain
>    owner."
>
> How are DNS queries sent to domain owners?
>

"to the ADMD infrastructure"


> 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.


> 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).


> Why is RFC 3864 a normative reference?
>

A BCP (e.g., a registration procedure) followed is always a normative
reference, I believe.


> Where can I find "Designated Mailers Protocol"?
>
> Where can I find "Domain-Authorized SMTP Mail"?
>

Agree, those need fixing.


> ABNF:
>
> Did anyone verify the ABNF?
>

It's been some time but I did a full pass over it previously.


> 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.


> In Appendix I:
>
> Appendix I is about "Protocol Status".  This draft is intended as a
> Proposed Standard. From an IETF perspective that is what it will be.
>  Describing it as something different can be misleading.
>
>   "[RFC4408] was designed to clearly document the protocol defined by
>    earlier draft specifications of SPF as used in existing
>    implementations.  This updated specification is intended to clarify
>    identified ambiguities in [RFC4408], resolve techincal issues
>    identified in post-RFC 4408 deplyment experience, and document widely
>    deployed extensions to SPF that have been developed since [RFC4408]
>    was published."
>

There are two typos in there (techincal, deplyment).


> Extensions to the SPF protocol are clearly mentioned in the charter as
> being out of scope.  The "document widely deployed extensions" is
> problematic.
>

Agreed.


>   "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.

-MSK