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

[S Moonesamy <[e-mail]>]

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:esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k"
>
>
>What are you saying here?  This is an existence proof of non-mailing 
>domains that don't publish SPF records, but it doesn't contradict 
>the statement made in the draft.
>
>
>The claim is being made without any supporting material.
>
>
>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
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg03646.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg03639.html