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

From: S Moonesamy <[email-masked]>
Date: Tue, 23 Apr 2013 16:08:39 -0700

Hello,

Here's my review as Document Shepherd.  draft-ietf-spfbis-4408bis is 
nearly ready for publication as a Proposed Standard.  I took into 
consideration the restrictions in the SPFBIS Charter and the 
controversial working group discussions in making this assessment.

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

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.

    '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 SPF check can only be performed when the "HELO" string is a
    valid fully qualified domain."

What is a valid fully qualified domain?

In Section 2.2:

   'SPF verifiers MUST check the ""MAIL FROM" identity if a completed
    "HELO" check has not reached a definitive policy result by applying
    the check_host() function to the "MAIL FROM" identity as the
    <sender>.'

As a note this RFC 2119 MUST is already in RFC 4408.

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.

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

The RFC 2119 MUST is a substantive change.  Why is this a MUST?

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.

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

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.

   'Although invalid, malformed, or non-existent domains cause SPF checks
    to return "none" because no SPF record can be found, it has long been
    the policy of many MTAs to reject email from such domains, especially
    in the case of invalid "MAIL FROM".  Rejecting email will prevent one
    method of circumventing of SPF records.'

This text is already in RFC 4408.

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

In Section 2.5:

   "The authorization check SHOULD be performed during the processing of
    the SMTP transaction that sends the mail."

This RFC 2119 SHOULD is already in RFC 4408.

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

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

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.

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

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

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?

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?

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

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

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

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?

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?

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

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

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

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?

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

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

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.

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

   "Properly formed domains are fully qualified email domains as
    described in [RFC5321] Section 2.3.5."

What are "properly qualified email domains"?

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

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.

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

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.

In Section 4.6.4:

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

This was discussed on the mailing list [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 read the first paragraph of Section 4.6.4.  I am not sure how the 
absolute requirement will be interpreted by the reader.

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

   'SPF implementations SHOULD limit "void lookups" to two.'

What are void lookups?

   "In this case, a default of two is RECOMMENDED."

Why is "two" recommended?

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

In Section 4.8:

   'e.g., "foo..example.com") or overlong labels (more than 63
    characters).'

I suggest octets.

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.

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.

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.

In Section 5.5:

  "This mechanism SHOULD NOT be used."

I suggest providing a reason for this.

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

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

In Section 5.6:

   "ip6-network      = <as per [RFC 4291], section 2.2>"

I suggest that the above reference be verified for correctness.

In Section 5.7:

   'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all'

I'll flag this for review by DNS folks.

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.

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.

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

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.

In Section 7.3:

   "-exists:%(ir).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.

  "so trailing dots SHOULD NOT be published by domain owners"

Why is it "domain owners"?

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

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

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

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

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

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?

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?

In Section 9:

   "An operator could choose to use both to serve different downstream
    agents.  In such cases, care needs to be taken to ensure both fields
    are conveying the same details, or unexpected results can occur."

This has been discussed on the mailing list.  I don't think that it 
encourages interoperability but the working group decided otherwise [10].

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 MUST appear above all other Received-SPF fields in the message."

How does this fit into the previous RFC 2119 SHOULD?

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?

In Section 10.1.1:

There was a comment from Authur Thisell about the table [11] in this 
sub-section.

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"

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?

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.

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

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.

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

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

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.

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?

Section 12:

I note that Murray S. Kucherawy has contributed significantly to 
draft-ietf-spfbis-4408bis.  If I am not mistaken it is IETF practice 
to acknowledge such contributions.  I don't recall who sent text at 
the moment.  If you did, please send an (off-list) email to the 
SPFBIS WG Chairs.

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.

In Section 13.2:

   "Per [RFC3864], the "Received-SPF:" header field is added to the IANA
    Permanent Message Header Field Registry."

Note to self: request removal from the provisional message  header 
field registry.

The "status:" should be "standard"

In Section 13.3:

   "Their status should not be changed."

I suggest "Their status is unchanged".  BTW, it should be "SPF 
Modifier Registry".  I suggest following RFC 6652 Section 5.1.

An "Updates:" for RFC 6652 may be needed.

References:

Why is RFC 1123 a normative reference?

Why is RFC 3864 a normative reference?

Where can I find "Designated Mailers Protocol"?

Where can I find "Domain-Authorized SMTP Mail"?

ABNF:

Did anyone verify the ABNF?

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?

I note that there are 48 pages in RFC 4408.  There are 78 pages in 
this draft.  A significant amount of text has been added in the 
Appendix (over 20 pages).  I doubt that the text has been carefully 
reviewed.  I may be asked for an explanation about all that once the 
draft leaves this working group.

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

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

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

Regards,
S. Moonesamy (as document shepherd)

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00928.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg01810.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg03378.html
5. http://trac.tools.ietf.org/wg/spfbis/trac/ticket/1
6. http://www.ietf.org/mail-archive/web/spfbis/current/msg00630.html
7. http://www.ietf.org/mail-archive/web/spfbis/current/msg00199.html
8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02279.html
9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02308.html
10. http://www.ietf.org/mail-archive/web/spfbis/current/msg02526.html
11. http://www.ietf.org/mail-archive/web/spfbis/current/msg02763.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 29 Apr 2013 01:21:22 -0700

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 <[email-masked]> wrote:

> ADMD should be expanded in the above.  This was pointed out in a review
> posted on August 26, 2012 [1].
>

Agree.

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

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

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

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

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

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

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

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

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

> Shouldn't that be "authorization check"?

Yes.

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

> John Levine commented about this during the WGLC [4].  I am listing this
> as a reminder for myself.
>

I agree with John.

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

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

> What is "manual intervention" in the above?

"Operator intervention" might be more consistent with common IETF usage.

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

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

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

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

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

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

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

> This RFC 2119 MUST is also in RFC 4408.  I suggest removing the "MUST" in
> the example.
>

I disagree.  It's required for interoperability.

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

> specification.  Is the SPFBIS WG working on compliance for SPF

 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.

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

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

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

>    zero-length label not at the end, etc.)"

Since the DNS is all in ASCII, they're synonymous.  That said, we may as
well be consistent.

> What are "properly qualified email domains"?

Is the reference defining that term not appropriate?

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

> I don't understand the sentence.

Query the HELO domain or the MAIL FROM domain, as described in Section 3.

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

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

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

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

Last paragraph of Section 4.6.

> Why is "two" recommended?

Interoperability; if one is two while another is 10, different SPF results
can be returned.

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

>   'e.g., "foo..example.com") or overlong labels (more than 63

Again, synonymous.

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

> 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 suggest providing a reason for this.

The very next sentence is "See below for discussion."

> The above restates a previous RFC 2119 MUST.

Agreed.

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

> What is a compliant check_host() implementation?

One that complies with this specification.

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

What's the specific question being asked of DNSDIR here?

> This text is in RFC 4408.  I would label the RFC 2119 usage as defective.

Why?

> requirement in this draft.  I note that this requirement was not in RFC

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

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

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

> Why is it "domain owners"?

ADMDs is fine here.

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

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

> Where is it specified that the maximum length of a domain name is 253

RFC1035 says it's 255.

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

> Why is an existing RFC 2119 restated?

Agreed.

>    to make a strong policy statement."

ADMD.

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

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

> What is the meaning of the RFC 2119 SHOULD in the above?

Agreed, it's inappropriate here.

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

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

> The "as stated elsewhere" is vague.

Section 8 discusses it, if you're saying you'd like a specific reference.

> What are "nonsense" domain names?

"arbitrary", "discardable", something like that.

> The sentence seems incomplete, i.e. similar to what.

The original message.

>    address in the 5321.MailFrom command for the new message."

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.

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

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

> How are DNS queries sent to domain owners?

"to the ADMD infrastructure"

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

> 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 "Domain-Authorized SMTP Mail"?

Agree, those need fixing.

> Did anyone verify the ABNF?

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

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

> Proposed Standard. From an IETF perspective that is what it will be.
>  Describing it as something different can be misleading.
>

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.

> 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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Apr 2013 07:36:26 -0700

On 4/29/2013 1:21 AM, Murray S. Kucherawy wrote:

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

+1.  2119 terms are case-insensitive.

>     What is a valid fully qualified domain?

    Internet Users' Glossary", FYI 18, RFC 1983
    http://tools.ietf.org/html/rfc1983

    Fully Qualified Domain Name (FQDN)
       The FQDN is the full name of a system, rather than just its
       hostname.  For example, "venera" is a hostname and
       "venera.isi.edu" is an FQDN.  See also: hostname, Domain Name
       System.

I suggest merely citing this RFC.

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

On reflection, it might avoid some reader confusion to define have the 
label be something like <spf-domain>, so that <domain> isn't overloaded 
with a specialized definition for this document.

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

+1

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

I don't understand the confusion either;.  The text looks reasonable, 
clear and reasonably concise.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 29 Apr 2013 17:32:16 +0200

> opinion about the points made, so this is only a nearly-complete reply.

I add a few lines, in case consensus needs to be gauged.

>> posted on August 26, 2012 [1].

+1, good style.

> be consistant and uppercase-ize it, or use some other word.

+1 for some other word.

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

+1, sanitizing input is part of any protocol.

> the Introduction or Definitions?

"What is a Fully Qualified Domain Name?" is the title of Section 5.2
of RFC 1594.

> it's shouting."  I guess that means changing "MUST publish" to "publishes"

+1, that would be the definition of an SPF-compliant domain.

> I think they're synonymous.  Going with ADMD is probably a good idea.

Just mentioning that they they are synonyms, e.g. in the 1st paragraph
of the introduction, might be handier to readers who are not familiar
with the term.

> determinations to occur.  It is an interoperability requirement.  I believe

+1, an equivalent wording could be:

   An SPF-compliant domain needing to support receivers making
   negative authorization determinations MUST...

> I agree; the redundancy should be resolved.  The cited sentence in 2.4 can

-1, Section 2.4 is the proper place to say that.  Sections 2.1 and 2.2
should be just definitions.  They are garbled and it's they who
deserve corrections.

> Adding "out-of-band" or "private" after "explicit" would probably clear

How about defining the concept of (private or standard) "extension"?

+1

> suggest some other text that accomplishes the intent?

I don't think we need to specify how to treat archaic input.  To
mention it is right and proper, though.

+1

> its use.  I suggest changing SHOULD to "needs to".

+1, note that both RFC 5321 (silent dropping of messages should be
considered) and RFC 3464 (should take appropriate precautions) have
lowercase "should".

>> as a reminder for myself.

+1 for "semantically equivalent".

+1

+1

> "Operator intervention" might be more consistent with common IETF usage.

Either wording tends to imply that it is clear who should do what in
order to resolve the permerror.  That's not always the case (e.g.
multiple void lookups).

> "which hosts are, and thus also which are not," or something like that.

Well, not authorized is "-", authorized is "+", but we cannot make it
clear without mentioning the other qualifiers too.  I suggest leaving
that as is.

> "An SPF policy statement is expressed as a single string of text encoded in

Leave off "single string" (Section 3.3 title is "Multiple Strings in a
Single DNS record").  We could reuse "string of octects" from RFC
1035, e.g.:

   The SPF record is a variable length string of octets encoded in
   a DSN TXT record.

> technique unless you absolutely need it".

Yes, that sense is conveyed with "SHOULD try" --must consider some
alternative ways that result in a smaller number of include/redirect.

> minimize" is probably fine, however.

"SHOULD minimize" conflicts with one intended use, namely

   v=spf1 redirect=_spf.example.com

Exemplified in Section 6.1, that use does not attain the minimum.

> The text is not incorrect, but it's also not necessary.  Dropping "only" is

+1, we don't need to stress that the other type was discontinued.

> The reference is indeed incorrect.

Should we say "is described along with its interpretation in Section
4.5"?  How about changing the title of Section 4.5 to "Record Format"?

> more than one "v=spf1" record published.

Yup

> "character-strings" as defined in RFC1035.

+1, but I wouldn't mention the level of strings in the I-D...

> I disagree.  It's required for interoperability.

+1, are there DNS libraries that do otherwise?

> a stylistic issue at best.

+1 for s/byte/octet/, even if it's stylistic:

   The size of the byte has historically been hardware dependent and
   no definitive standards existed that mandated the size.
                                   http://en.wikipedia.org/wiki/Byte

>> In Section 4:
>>
>>   "A compliant SPF implementation MUST do something semantically
>>    equivalent to this description."
>>

Would it be better to s/do something/behave in a way/?

> I agree with the second point.

I propose to remove that sentence.

> This seems to me to be another stylistic question, since MAY in RFC2119

It helps understanding the previous MUST, they are two poles that
implementations have to stay in between.

> other points in the document reference it.

+1, Section 2.4 can refer to Section 4.1.  However, Section 2.4 needs
to mention how the <sender> parameter should be set in each of the checks.

> Since the DNS is all in ASCII, they're synonymous.  That said, we may as

Yeah, but ASCII is 7-bit...

> Is the reference defining that term not appropriate?

IMHO the reference is fine.  The term "email domain" lacks a formal
definition, and is used improperly in Section 4.3 since HELO needs not
be an email domain in some sense.  I'd s/fully qualified email
domains/fully-qualified domain names/.

> up another document (which we're not chartered to do) that discusses use of

Fully agree with Murray.  However, it is not layer-wise clear whether
any A-label conversion is to be carried out as initial processing
within check_host().

> Query the HELO domain or the MAIL FROM domain, as described in Section 3.

In this case, I'd keep the trailing "only" as is.

> justification; it's practical experience.  If not, we should consider

+1 for dropping it.  This would be needed for type 99, where bad
firewall rules could produce effects similar to network errors except
that they'd never get resolved.  For "normal" SERVFAIL cases, the
meaning of temperror as derived from RFC 2308 is just fine.

> found, the result is determined according to Section 4.7."

+1, better style.

> important for interoperability.

+1, while it is possible to say "MUST return permerror if more than
10", the resulting text would be less readable.

> common factor the SHOULD and then present three bullets in a list, but the

+1, for the same readability reason.

> Interoperability; if one is two while another is 10, different SPF results

This is a protocol change, marked as such in Appendix C, 2nd bullet.

> debugging, I think I agree since the advice is not specific to the protocol

Scott removed the "Note that".

>>   'e.g., "foo..example.com") or overlong labels (more than 63

+1 for SM, again.

> for an A record for the same name."

+1, s/A/A or AAAA/

>> The above restates a previous RFC 2119 MUST.

+1, since we collected those limits.  I propose to replace the second
sentence in that bullet with something like:

   This is where to apply the rule of Section 4.6.4 to ignore records
   other than the first 10.

> it, so this has to be just a plain IPv6 address, so that's the right

I'd rather import IPv6address and IPv4address from
http://tools.ietf.org/html/rfc3986#section-3.2.2

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

-1, it means the value of "exp" must be ASCII.

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

+1, something like "implementers are advised to make it clear..."

> I'm pretty sure it's referring to common TLD conventions.

The "LDH rule" is explained in the Informational RFC.  It is the
Letter-Digit-Hyphen convention defined in RFC 952 and later modified
by RFC 1123 [http://www.icann.org/en/node/1145376]

> Agreed, it's inappropriate here.

I think Scott removed it already.

> statement made in the draft.

It doesn't mean there's a BCP.  s/best/good/?

> The format is indeed identical, right down to the octet.

The format of RDATA, that is.  I'd leave the definition of the
obsolete type with the obsolete RFC 4408.

> It's otherwise unchanged.

See http://www.ietf.org/mail-archive/web/spfbis/current/msg02276.html

>> being out of scope.  The "document widely deployed extensions" is

Yes, in some sense.  I'd s/extensions/changes/.

---

From: Pete Resnick <[email-masked]>
Date: Mon, 29 Apr 2013 11:10:12 -0500

> +1.  2119 terms are case-insensitive.

That 2119 terms are case-insensitive is at least a controversial claim. 
And if I were doing a review, my concern here would be that 4408 could 
have meant "must" colloquially and not as a 2119 requirement. Whether 
it's a substantive change or not comes down to how it was originally 
intended.

It seems to me that interpreting the above as 2119 language is a bit 
weird: This is in a sentence that starts "Note that...", which doesn't 
seem terribly requirement laden. Also "MUST be prepared" is a weird 
construct: MUSTs are normally instructions for protocol actions or 
implementation coding, and "be prepared" seems like an odd one of those. 
And of course, was this intended as a new requirement of SPF, or was it 
just reiterating something from SMTP? If the latter, that would sound 
like the "must" was meant colloquially and "need to" might be a 
reasonable substitute.

As many of you know, 2119 misuse is a pet peeve of mine, so I presume SM 
was going through looking for things that might pique my interest. But I 
have already decided that when I do my "Ready to go to Last Call" AD 
review, I am going to explicitly ignore 2119 misuse when (a) it was in 
4408 already and (b) won't cause serious problems. So it's only changes 
to the text of 4408 when 2119 terms are used that are going to get any 
"are they using it right?" scrutiny. If SM has identified any of those, 
an explanation would be useful.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Apr 2013 09:34:32 -0700

> it's a substantive change or not comes down to how it was originally

As you know, I'm a fan of using the vocabulary only normatively, 
specifically to avoid both the controversy and, more importantly, 
possible/likely reader confusion:

    http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119-02

> weird:This is in a sentence that starts "Note that...", which
 > doesn't

My overriding point on this topic is that making the interpretation of 
normative vocabulary be context sensitive in stupidly fragile for a 
standards organization.  So the fact that your otherwise reasonable 
analysis relies on a reader's needing to realize that it doesn't make 
"sense" to treat the words as normative strikes me as the core problem.

This is in a sentence that starts "Note that...", which doesn't
> implementation coding, and "be prepared" seems like an odd one of those.

Well, I thoroughly agree that normative language needs to specify 
something concrete.  Using such language to direct vague awareness or 
action that has no specific details isn't specifying.

d/

---

From: Hector Santos <[email-masked]>
Date: Mon, 29 Apr 2013 12:39:55 -0400

It sure would be nice if we can apply common-sense (software) 
engineering and not get bogged down on semantics all in the name of 
enforcing, or not, things!

Look at it this way, unless your mail or page reader has a SFI (Speech 
Friendly Interface) technology where it will YELL the uppercase words, 
the visually impaired won't know (or not won't care of) the difference 
between must and MUST.

--
HLS

---

From: "John Levine" <[email-masked]>
Date: 29 Apr 2013 17:12:44 -0000

>>>     This RFC 2119 "MUST" is not in RFC 4408.  It is a substantive change

Seems to me it's simply stating a fact -- clients can legitimately
send an IP address and a broken client can send any random garbage in
the HELO, so deal with it.  It's certainly not a change in the
protocol, just advice to avoid software crashes.

On the other hand, it is generally the case that competent software
libraries do sanity checks on all of their input, so I don't see any
compelling reason to call out this case.  I don't see any warnings in
the MAIL FROM section about how to deal with garbage like this:

  MAIL FROM:<foo@!#MCU&$..!?x?x>

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Mon, 29 Apr 2013 13:59:21 -0700

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.

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

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

>I think they're synonymous.  Going with ADMD is probably a good idea.

Ok.

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

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

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

>This RFC 2119 requirement states the obvious.  It basically says 
>that there is a requirement in draft-ietf-spfbis-4408bis-14 to use a 

Ok.

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

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

>"DNS TXT records" is fine but probably not necessary at this point 
>in the document.
>

I'll leave this one to Andrew.

>This definition of "none" is more precise than it was in 
>RFC4408.  The 4408 definition was:
>
>
>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.

>"Operator intervention" might be more consistent with common IETF usage.

Ok.

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

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

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

>I agree with "SHOULD try", as that's arguably not 
>actionable.  "SHOULD minimize" is probably fine, however.

Ok.

>The text is not incorrect, but it's also not necessary.  Dropping 
>"only" is probably sufficient.
>

Ok.

>I believe it is an advisory to publishers of the consequences of 
>having more than one "v=spf1" record published.

Ok.

>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 

I'll leave this to Andrew.

>I disagree.  It's required for interoperability.

Interoperability requirements are not specified through examples.

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

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

>I agree with the second point.

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

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

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

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

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

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

>justification; it's practical experience.  If not, we should 
>consider dropping it.

I'll wait for feedback on this.

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

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

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

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

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

>debugging, I think I agree since the advice is not specific to the 
>protocol itself.

I suggest removing the RFC 2119 SHOULD.

>   'e.g., "foo..example.com") or overlong labels (more than 63

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

>This was covered in a different thread.  I believe a proposed text 
>fix was made that people seemed to like.

Yes.

>That happens sometimes.  :-)

:-)

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

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

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

>One that complies with this specification.

Ok. :-)

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

>What's the specific question being asked of DNSDIR here?

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

>This text is in RFC 4408.  I would label the RFC 2119 usage as defective.

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.

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

>I think it's fine, though I suggest changing "the discussion about 
>why not" to just "discussion".

Please turn it into one sentence.

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

>Where is it specified that the maximum length of a domain name is 
>253 characters?
>
>
>RFC1035 says it's 255.
>

I suggest using Section 2.3.4.

>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 SHOULD be prepended to the whole header block, but even if it 
>isn't, it MUST appear above any other Received-SPF field.

Ok.

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

>When MAIL FROM is null, it's important that HELO be right in order 
>to get any useful result from SPF.

Ok.

>Section 8 discusses it, if you're saying you'd like a specific reference.

I suggest a reference.

>"arbitrary", "discardable", something like that.

"discardable" sounds the better one of the two.

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

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

>Agreed.  A second sentence indicating most of that input is 
>unverified is probably in order, with references if possible.

Ok.

>The format is indeed identical, right down to the octet.

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

>It defines the "%"-hack, of which implementers need to be aware 
>(i.e., code needs to be able to handle that syntax).

Ok.

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

I guess it is a matter of style.

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

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

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

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

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 29 Apr 2013 16:21:57 -0700

> Hi Murray,

Hello!

Replying only to the parts that need further discussion:

>> This RFC 2119 "MUST" is not in RFC 4408.  It is a substantive change in
>> my opinion.
>>
>
>> 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.

I suggest asking the ADs for guidance about the "must" vs. "MUST" issue.  I
believe Pete may have already commented on it.  However, I also believe the
"fix" is pretty easy, which avoids the issue altogether, for cases where we
used "must" in RFC4408 without meaning "MUST" in the RFC2119 sense.  My
original review of RFC4408bis focused on changing "must" (where it was
meant normatively) to "MUST", and to some other word otherwise.

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

Ditto.  :-)

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

Well, it has to resolve.  SPF doesn't give you a definitive answer where
the FQDN can't be resolved.  One could argue that the check can't be
performed when that happens.  I think that's why "valid" is used there.  Is
there a better way to say it?

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

How is it not a definition?

I do agree with having it in one place, however.

>> 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 RFC4408 paints an incomplete picture of the decision-making process
when handling rejections other than at SMTP time, and thus this qualifies
as clarifying language.  I understand your concern here, but I suggest we
push it up the chain under that argument.

> Interoperability requirements are not specified through examples.

It isn't, it's in the prose.  The example is illustrative, not normative.

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

Sure.

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

Labels are, and that's what <domain> is.

> I'll wait for feedback on this.

I think in retrospect that this runs into the clarifications restriction,
which this isn't.  Though useful advice, the charter may not allow it.

> receivers", "SPF implementations" and "SPF verifiers" are used.  That looks
> inconsistent to me.
>
>   (a) impose a limit on the maximum amount of elapsed time to evaluate
> check_host().
>
> 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.

Now that you say it that way, I have to agree.  However, that text appeared
in RFC4408, so it's a matter of removing or reworking text that was there
before.  Weren't we favouring no changes?

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

I believe all of those questions have been answered; it's just a matter of
adding some prose to cover it.

>    cases of DNS errors, and it places a large burden on the .arpa name
> servers.

As long as that's not redundant to the referenced discussion, sure.

> I suggest reading RFC 5952.

 Yes, that one's better.

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

I'm not sure that's a good question for them as they'll have to try to
figure out our intent.  I'm worried that they'll come back with a "You
shouldn't do it this way" and some encouragement to replace the mechanism
with something else.  That would be a protocol change, and that's out of
scope.

I suggest a more restricted question, like "Is this harmful?"

> This text is in RFC 4408.  I would label the RFC 2119 usage as defective.

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.

If you mean "get rid of the MAY" clause, I'm fine with that because it
doesn't add anything.  An explanation of why would be helpful here too.

> group looks for a simple sentence to replace the existing one.
I think any reduction beyond what I suggested above loses information.

>> Where is it specified that the maximum length of a domain name is 253
...which is to say I agree that I don't understand why it says 253 there.

> I suggest using Section 2.3.4.

Either's fine.

> The claim is being made without any supporting material.

But it's a true claim, and applicability statements and technical
specifications describe best practices all the time.  What evidence could
we include to support it?

> I guess it is a matter of style.

...or precedent.  :-)

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

But this just a relocation of text already in 4408.  I don't think removing
it is justified even if it's part of the (original) clutter.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 30 Apr 2013 00:11:01 -0000

>the FQDN can't be resolved. 

It could just have a TXT record (presumably v=spf1 -all) and no A or MX.
I agree that taking "valid" out is the easiest approach.

>> I'll wait for feedback on this.

Not that I'm aware of.  That looks to me like an optimization to do in
the DNS cache, not in the client.

>>> I am not aware of that best practice.  I did a few DNS queries:

Now, now, what Microsoft does isn't by definition a best practice (or
worst, for that matter.)

I certainly publish SPF -all for hosts with A records that have shown
up in spam lists, typically old scraped message-IDs that look like
addresses.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 29 Apr 2013 20:42:09 -0400

> the DNS cache, not in the client.

This was issue #1 in the tracker:

http://trac.tools.ietf.org/wg/spfbis/trac/ticket/1

It was discussed as a resolution to an operational issue discovered during SPF 
deployment.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Tue, 30 Apr 2013 09:14:03 -0700

Hi Murray,
At 16:21 29-04-2013, Murray S. Kucherawy wrote:
>I suggest asking the ADs for guidance about the "must" vs. "MUST" 
>issue.  I believe Pete may have already commented on it.  However, I 
>also believe the "fix" is pretty easy, which avoids the issue 
>altogether, for cases where we used "must" in RFC4408 without 
>meaning "MUST" in the RFC2119 sense.  My original review of 
>RFC4408bis focused on changing "must" (where it was meant 
>normatively) to "MUST", and to some other word otherwise.

Pete Resnick commented about RFC 2119 [1].  I was looking for things 
which might pique his interest. :-)

I am ok with not cleaning the "must".  I think that the fix is easy.

>Ditto.  :-)

I'll keep this one (RFC 2119 second paragraph of Section 2.1) listed 
as an issue :-)

>Well, it has to resolve.  SPF doesn't give you a definitive answer 
>where the FQDN can't be resolved.  One could argue that the check 
>can't be performed when that happens.  I think that's why "valid" is 
>used there.  Is there a better way to say it?

I'll pick up one of John Levine's messages [2].

  "On the other hand, it is generally the case that competent software
   libraries do sanity checks on all of their input, so I don't see any
   compelling reason to call out this case.  I don't see any warnings in
   the MAIL FROM section about how to deal with garbage like this:

     MAIL FROM:<foo at !#MCU&$..!?x?x>"

I hope that it illustrates what is not called out in some specifications.

Here's the text from the draft:

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

I get the "HELO" string.  I have to perform sanity checks on it, or I 
am using a library it may do it for me.  If I say "can only be 
performed on valid FQDN"  I have to explain the details.  If I say 
"look out, there can nasty stuff here as I encountered problems when 
I implemented this", it is useful guidance.  I might have to say that 
for several other input if I take that approach and I end up with an 
EULA. :-)  The other approach is to call out only issues which have 
been causing deployment problems.

The second paragraph of Section 2.1 already says "be prepared for 
malformed or an IP address literal".  That's usual guidance in my opinion.

I would start the first paragraph with:

   The "HELO" identity is a fully-qualified domain name.

>How is it not a definition?

After spending much more than a day for this review I don't want to know. :-)

>I do agree with having it in one place, however.

Ok, I suggest doing that.

>I think RFC4408 paints an incomplete picture of the decision-making 
>process when handling rejections other than at SMTP time, and thus 
>this qualifies as clarifying language.  I understand your concern 
>here, but I suggest we push it up the chain under that argument.

After reading of RFC 5321, I believe that that a rejection can only 
occur during the SMTP session.  It was previously explained to me 
that the text documents operational experience.  It was then 
explained to me that it qualifies as clarifying language.  I can push 
it up the chain if I am provided with references to discussion about that text.

>It isn't, it's in the prose.  The example is illustrative, not normative.

Pete Resnick commented about RFC 2119.  I suggest following his guidance.

>I think in retrospect that this runs into the clarifications 
>restriction, which this isn't.  Though useful advice, the charter 
>may not allow it.

I missed the DNS angle.  Ted Lemon, as an individual, commented about 
it if I recall correctly.  I suggest dropping the text.

>receivers", "SPF implementations" and "SPF verifiers" are 
>used.  That looks inconsistent to me.
>
>Now that you say it that way, I have to agree.  However, that text 
>appeared in RFC4408, so it's a matter of removing or reworking text 
>that was there before.  Weren't we favouring no changes?

I'll go with "no change".  If I am asked, the explanation will be 
"the SPFBIS WG does not want to fix the text".

>I believe all of those questions have been answered; it's just a 
>matter of adding some prose to cover it.

I'll wait for the working group to suggest text.

>I suggest reading RFC 5952.

Alessandro Vesely commented about this [3].  I suggest that the 
working group reviews this issue as it's in the ABNF.

>I'm not sure that's a good question for them as they'll have to try 
>to figure out our intent.  I'm worried that they'll come back with a 
>"You shouldn't do it this way" and some encouragement to replace the 
>mechanism with something else.  That would be a protocol change, and 
>that's out of scope.
>

That text is part of an example.  In my opinion a protocol is not 
specified through an example.  I prefer to avoid asking about what is 
harmful as it is difficult to make assess the views.  As there is a 
thread that made it to ietf@ it may be too late to worry.

>If you mean "get rid of the MAY" clause, I'm fine with that because 
>it doesn't add anything.  An explanation of why would be helpful here too.

Ok.

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

Ok.

>...which is to say I agree that I don't understand why it says 253 there.

Hmm, there's is another angle to this.  I'll skip that discussion.

>specifications describe best practices all the time.  What evidence 
>could we include to support it?

It's not that I do not believe you.  A few references might be 
helpful to support a claim.

:-)

>concern about "a tendency to include an example of every possible 
>use of SPF to solve some problem".  I suggest removing the example.
>
>
>But this just a relocation of text already in 4408.  I don't think 
>removing it is justified even if it's part of the (original) clutter.

I read Section 9.3 of RFC 4408 again before writing this message.  I 
did not find the text.  I suggest removing the text from the draft.

Regards,

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg03642.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg03646.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg03639.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 30 Apr 2013 10:57:05 -0700

How are we tracking the issues that have resolved in the direction of
adjustments to the document before requesting publication?  It seems like
there's a large number of small changes that need to be either adopted or
discussed further.  I'm sure I've lost track of some (maybe most) of them;
we should do what we can to help Scott here.

-MSK

On Tue, Apr 30, 2013 at 9:14 AM, S Moonesamy <[email-masked]> wrote:

>> I suggest asking the ADs for guidance about the "must" vs. "MUST" issue.
>>  I believe Pete may have already commented on it.  However, I also believe
>> the "fix" is pretty easy, which avoids the issue altogether, for cases
>> where we used "must" in RFC4408 without meaning "MUST" in the RFC2119
>> sense.  My original review of RFC4408bis focused on changing "must" (where
>> it was meant normatively) to "MUST", and to some other word otherwise.
>>
>
> Pete Resnick commented about RFC 2119 [1].  I was looking for things which
> might pique his interest. :-)
>
> I'll keep this one (RFC 2119 second paragraph of Section 2.1) listed as an
> issue :-)
>
>
> I get the "HELO" string.  I have to perform sanity checks on it, or I am
> using a library it may do it for me.  If I say "can only be performed on
> valid FQDN"  I have to explain the details.  If I say "look out, there can
> nasty stuff here as I encountered problems when I implemented this", it is
> useful guidance.  I might have to say that for several other input if I
> take that approach and I end up with an EULA. :-)  The other approach is to
> call out only issues which have been causing deployment problems.
>
>> process when handling rejections other than at SMTP time, and thus this
>> qualifies as clarifying language.  I understand your concern here, but I
>> suggest we push it up the chain under that argument.
>>
>
> After reading of RFC 5321, I believe that that a rejection can only occur
> during the SMTP session.  It was previously explained to me that the text
> documents operational experience.  It was then explained to me that it
> qualifies as clarifying language.  I can push it up the chain if I am
> provided with references to discussion about that text.
>
>
>
> I missed the DNS angle.  Ted Lemon, as an individual, commented about it
> if I recall correctly.  I suggest dropping the text.
>
>
>> appeared in RFC4408, so it's a matter of removing or reworking text that
>> was there before.  Weren't we favouring no changes?
>>
>
> I'll go with "no change".  If I am asked, the explanation will be "the
> SPFBIS WG does not want to fix the text".
>
>
>> I believe all of those questions have been answered; it's just a matter
>> of adding some prose to cover it.
>>
>
> Alessandro Vesely commented about this [3].  I suggest that the working
> group reviews this issue as it's in the ABNF.
>
>
>  In Section 5.7:
>>
> harmful as it is difficult to make assess the views.  As there is a thread
> that made it to ietf@ it may be too late to worry.
>
>
>  In Section 6:
>>
> It's not that I do not believe you.  A few references might be helpful to
> support a claim.
>
>  ...or precedent.  :-)
>>
>
> :-)
>
>  In Appendix C:
>>
>> In Section E.1:
>>
> I read Section 9.3 of RFC 4408 again before writing this message.  I did
> not find the text.  I suggest removing the text from the draft.
>
>
> Regards,
> 1. http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03642.html<http://www.ietf.org/mail-archive/web/spfbis/current/msg03642.html>
> 2. http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03646.html<http://www.ietf.org/mail-archive/web/spfbis/current/msg03646.html>
> 3. http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03639.html<http://www.ietf.org/mail-archive/web/spfbis/current/msg03639.html>
>

---

From: S Moonesamy <[email-masked]>
Date: Tue, 30 Apr 2013 11:32:45 -0700

Hi Murray,
At 10:57 30-04-2013, Murray S. Kucherawy wrote:
>How are we tracking the issues that have resolved in the direction 
>of adjustments to the document before requesting publication?  It 
>seems like there's a large number of small changes that need to be 
>either adopted or discussed further.  I'm sure I've lost track of 
>some (maybe most) of them; we should do what we can to help Scott here.

That's a good question.  I am tracking the issues raised in my review 
locally.  I will also be tracking the directorate/review teams 
reviews locally.  I am ok with going with what Scott finds easier to 
do his work.

Note that I consider your review as not addressed.

There has only been one comment about the AppsDir review ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03633.html 
).  There hasn't been any comments (excluding one question) about the 
Gen-ART review ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03647.html 
).  I forwarded the SecDir review a few minutes ago.

The discussion has been mostly centered on a specific issue.  The 
other issues which the working group will also have to address are 
not receiving any attention.

Regards,

---

From: S Moonesamy <[email-masked]>
Date: Tue, 30 Apr 2013 11:40:05 -0700

Hi John,
>I agree that taking "valid" out is the easiest approach.

I suggested some text for this.

>the DNS cache, not in the client.

Thanks for pointing this out.

:-)

Regards,

---

From: S Moonesamy <[email-masked]>
Date: Tue, 30 Apr 2013 12:22:21 -0700

Hi Alessandro,
>I add a few lines, in case consensus needs to be gauged.

Thanks.  I'll comment below.

>+1, sanitizing input is part of any protocol.

I gather that it is part of any implementation.

>"What is a Fully Qualified Domain Name?" is the title of Section 5.2

That's not the usual reference.  I am not getting into details to 
avoid side-discussions.

>of the introduction, might be handier to readers who are not familiar

There is already a reference to RFC 5598.

>should be just definitions.  They are garbled and it's they who

I noticed some slight document inconsistencies.  My preference is not 
to go over them at this stage to avoid reopening other issues.

>How about defining the concept of (private or standard) "extension"?

That might be outside the scope.

>+1 for "semantically equivalent".

I suggest going with that.

>    The SPF record is a variable length string of octets encoded in

I suggest going for simple. :-)

>Exemplified in Section 6.1, that use does not attain the minimum.

I don't recall this being raised as an issue previously.  Let me know 
if this is not addressed.

>4.5"?  How about changing the title of Section 4.5 to "Record Format"?

That affects the paragraphs in that section.

>    no definitive standards existed that mandated the size.

If I recall correctly there is some other reason too.  I'll avoid the 
side-discussion.

>Would it be better to s/do something/behave in a way/?

That's a bit vague.

>to mention how the <sender> parameter should be set in each of the checks.

Can the working group please review this?

>definition, and is used improperly in Section 4.3 since HELO needs not

Yes.  That's why I preferred to avoid it.

Yes.

>any A-label conversion is to be carried out as initial processing

I leave it to the implementers to comment.

Ok.

>    This is where to apply the rule of Section 4.6.4 to ignore records

I commented about the table in the review.

>http://tools.ietf.org/html/rfc3986#section-3.2.2

I don't know about this one.

>+1, something like "implementers are advised to make it clear..."

I would have to say no. :-)

:-)

>It doesn't mean there's a BCP.  s/best/good/?

I commented about this in one of my messages.

>See http://www.ietf.org/mail-archive/web/spfbis/current/msg02276.html

Thanks for the reference.

Sorry for being terse.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 30 Apr 2013 19:26:54 -0400

> ).  I forwarded the SecDir review a few minutes ago.

Those, msk's review, and yours are outstanding.  In other cases where there's 
been on list discussion that led me to think a change was merited, I've 
mentioned it.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Tue, 30 Apr 2013 17:43:35 -0700

Hi Scott,
>been on list discussion that led me to think a change was merited, I've

I am not sure I understood the above correctly.  My reading of the 
quoted text (excluding the first sentence) is that you would comment 
on the AppsDir, SecDir and Gen-ART reviews if a change was 
merited.  I don't see any messages from you in the SPFBIS mailing 
list archive.  I presume in your opinion that no change is merited.

There are 74 pages in draft-ietf-spfbis-4408bis-14.  The reviewers 
from AppsDir, SecDir and Gen-ART have taken the time to read these 74 
pages and comment about the draft.  There are some questions in the 
Gen-ART review.  I also see minor issues listed in the AppsDir 
review.  As there wasn't any response I consider that these reviews 
have not been addressed.

There are also some comments received during the WGLC which are outstanding.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 30 Apr 2013 21:05:19 -0400

No.  What I meant was that I would reply to each of those and indicate if I thought change was warranted.  I haven't done this yet.  In some cases there was follow-on commentary about one of the reviews.  If it makes sense I'll try to comment on each issue in only one place.

For avoidance of doubt,  I didn't read anything in the stack of messages about removing type SPF that caused me to consider changes needed.

Scott K

S Moonesamy <[email-masked]> wrote:

>_______________________________________________
>spfbis mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/spfbis

---

From: Mark Andrews <[email-masked]>
Date: Wed, 01 May 2013 11:38:46 +1000

In message <CAL0qLwYWBff0QxUxpN2+X2pq_=PZ=[email-masked]>
> > Hmm, there's is another angle to this.  I'll skip that discussion.

255 is the maximum WIRE length of a domain name.
253 is the maximum LDH domain name (no trailing period).
254 is the maximum LDH domain name (with trailing period).
1007 is the maxumum RFC 1035 presentation format (no trailing period).
	3*63*4 + 3 + 62*4

If you need a buffer to hold all potential a nul terminated domains as
a string you need 1009 bytes.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]