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

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

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 <[e-mail]> wrote:

> 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.
>
>
>    'Generating non-delivery notifications to forged identities that have
>>    failed the authorization check is a source of backscatter and SHOULD
>>    be avoided.'
>>
>> This RFC 2119 SHOULD is not in RFC 4408.  The above does not have
>> anything to do with Sender Policy Framework.  It was mentioned during WG
>> discussions that "SPF can help the backscatter problem" [2].  This text may
>> have been introduced in response to a review [3].  Is this an enhancement
>> or a clarification?
>>
>>
>> I think it documents operational experience acquired since RFC4408 was
>> published.  As for whether RFC2119 language is appropriate, I agree that it
>> isn't; it has nothing to do with SPF itself, though it is a side effect of
>> its use.  I suggest changing SHOULD to "needs to".
>>
>>
>> My reading of the above is that it is neither an enhancement or a
>> clarification.  I suggest removing the text.
>>
>> 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.
>
>
>
>    "If a published record contains multiple character-strings, then the
>>    record MUST be treated as if those strings are concatenated together
>>    without adding spaces."
>>
>> This RFC 2119 MUST is also in RFC 4408.  I suggest removing the "MUST" in
>> the example.
>>
>> I disagree.  It's required for interoperability.
>>
>>
>> Interoperability requirements are not specified through examples.
>>
>> 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.
>
>
>    'Alternatively, for a server failure (RCODE 2) result, check_host()
>>    MAY track failures and treat multiple failures within 24 hours for
>>    the same domain as "permerror".'
>>
>> This text is not in RFC 4408.  I found a note in Issue #1 [5] and in a
>> message [6].
>>
>> Are there any implementations that do this?  If so, that's the
>> justification; it's practical experience.  If not, we should consider
>> dropping it.
>>
>>
>> I'll wait for feedback on this.
>>
>>
>> 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.
>
>
>     'MTAs or other processors SHOULD impose a limit on the maximum amount
>>    of elapsed time to evaluate check_host().  Such a limit SHOULD allow
>>    at least 20 seconds.  If such a limit is exceeded, the result of
>>    authorization SHOULD be "temperror".'
>>
>> There are three RFC 2119 SHOULDs in the above.  I suggest rewriting the
>> text to reduce that.
>>
>> All three of them seem to be important interoperability points.  We could
>> common factor the SHOULD and then present three bullets in a list, but the
>> meaning is the same.
>>
>>
>> Throughout the document the words "MTA", "other processors", "mail
>> receivers", "SPF implementations" and "SPF verifiers" are used.  That looks
>> inconsistent to me.
>>
>> Here's an example of a rewrite:
>>
>>   MTA or other processors SHOULD:
>>
>>   (a) impose a limit on the maximum amount of elapsed time to evaluate
>> check_host().
>>
>>   (b) allow for at least 20 seconds.
>>
>>   (c) return a result of authorization of "temperror".
>>
>> I don't see what Points (a) or (b) has to do with interoperability.
>>  Trying to common factor the RFC 2119 SHOULD reduces occurrences of the
>> word instead of addressing the issue.  I suggest understanding the intent
>> first before working on the text to be added.
>>
>>
>> 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".
>
>
>    "In this case, a default of two is RECOMMENDED."
>>
>> Why is "two" recommended?
>>
>> Interoperability; if one is two while another is 10, different SPF
>> results can be returned.
>>
>>
>> Here is the text:
>>
>>   "An implementation MAY choose to make such a limit configurable.  In
>>
>>    this case, a default of two is RECOMMENDED."
>>
>> There is the RFC 2119 SHOULD and the RFC 2119 RECOMMENDED.
>>
>> Here's how I look at it: Is the working group recommending a limit which
>> is configurable?  What's the recommended value?  Is the value some
>> arbitrary number?
>>
>>
>> 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.
>
>
>
>  In Section 5.6:
>>
>>   "ip6-network      = <as per [RFC 4291], section 2.2>"
>>
>> I suggest that the above reference be verified for correctness.
>>
>>
>> Looks right to me.  The CIDR expression is in the optional token next to
>> it, so this has to be just a plain IPv6 address, so that's the right
>> reference.
>>
>>
>> I suggest reading RFC 5952.
>>
>>
>>  Yes, that one's better.
>>
>
> 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:
>>
>>   'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{**d} -all'
>>
>> I'll flag this for review by DNS folks.
>>
>> What's the specific question being asked of DNSDIR here?
>>
>>
>> My question would be: "Is Section 5.7 of the draft correct?".
>>
>>
>> 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?"
>>
>
> 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.
>
>
>  In Section 6:
>>
>>   'The modifiers defined in this document ("redirect" and "exp") MAY
>>    appear anywhere in the record, but SHOULD appear at the end, after
>>    all mechanisms.'
>>
>> This text is in RFC 4408.  I would label the RFC 2119 usage as defective.
>>
>>
>> Why?
>>
>>
>> The text tells me that it is ok if the modifiers appear anywhere but they
>> should appear at the end after all mechanisms.  It would be clearer to say
>> that it should appear after all mechanisms.
>>
>>
>> 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.
>
>
>     "This SHOULD be a fully qualified domain name, but if one does not
>>    exist (as when the checking is done by a MUA) or if policy restrictions
>>    dictate otherwise, the word "unknown" SHOULD be substituted."
>>
>> The RFC 2119 key words are in RFC 2119.  I don't know what to say.
>>
>>
>> I think that looks fine as-is, though we could change the first SHOULD to
>> "ought to" because it's a transformation of other input and not an
>> implementation choice.  (And I assume you mean they were in RFC4408.)
>>
>>
>> Yes, I meant that there were in RFC 4408.  I suggest that the working
>> group looks for a simple sentence to replace the existing one.
>>
>>
>> I think any reduction beyond what I suggested above loses information.
>>
>
> Ok.
>
>
>    "When the result of macro expansion is used in a domain name query, if
>>    the expanded domain name exceeds 253 characters (the maximum length
>>    of a domain name), the left side is truncated to fit, by removing
>>    successive domain labels (and their following dots) until the total
>>    length does not exceed 253 characters."
>>
>> Where is it specified that the maximum length of a domain name is 253
>> characters?
>>
>>
>> RFC1035 says it's 255.
>>
>>
>> ...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.
>
>
>   In Section 10.1.2:
>>
>>   "Publishing SPF records for domains that send no mail is
>>    a well established best practice."
>>
>> I am not aware of that best practice.  I did a few DNS queries:
>>
>> ;; QUESTION SECTION:
>> ;bing.com.                      IN      TXT
>>
>> ;; ANSWER SECTION:
>> bing.com.               3600    IN      TXT     "v=msv1
>> t=6097A7EA-53F7-4028-BA76-**6869CB284C54"
>>
>> ;; QUESTION SECTION:
>> ;com.com.                       IN      TXT
>>
>> ;; ANSWER SECTION:
>> com.com.                293     IN      TXT "google-site-verification:**
>> esSnoZdChIkkfCfS9MMgqNhE0yaXfn**nZWdZPuBf7e8k"
>>
>>
>> What are you saying here?  This is an existence proof of non-mailing
>> domains that don't publish SPF records, but it doesn't contradict the
>> statement made in the draft.
>>
>>
>> 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?
>>
>
> 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:
>>
>>   'This would cause a lookup on an DNS white list (DNSWL) and cause a
>>    result of "fail" only for email not either coming from the
>>    domain's mx host(s) (SPF pass) or white listed sources (SPF
>>    neutral).'
>>
>> I didn't find any discussion about this on the SPFBIS mailing list.  is
>> there an explanation for this change between RFC 4408 and this draft?
>>
>>
>> It was in 9.3 in the previous document and has been reworded a little.
>>  It's otherwise unchanged.
>>
>>
>> The text from Section 9.3 is already in the draft.  This is additional
>> material instead of a little rewording.  There was a concern about "a
>> tendency to include an example of every possible use of SPF to solve some
>> problem".  I suggest removing the example.
>>
>>
>> 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,
> S. Moonesamy (as document shepherd)
>
> 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>
>