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

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

On Mon, Apr 29, 2013 at 1:59 PM, S Moonesamy <[e-mail]> wrote:

> Hi Murray,


Hello!

Replying only to the parts that need further discussion:


>
>     'Note that requirements for the domain presented in the EHLO or HELO
>>     command are not always clear to the sending party, and SPF verifiers
>>     MUST be prepared for the "HELO" identity to be malformed or an IP
>>     address literal.'
>>
>> This RFC 2119 "MUST" is not in RFC 4408.  It is a substantive change in
>> my opinion.
>>
>
>  This was probably at my suggestion.  The issue here is that RFC2119
>> doesn't say "must" has any different meaning than "MUST" does, so we should
>> either be consistant and uppercase-ize it, or use some other word.
>>
>
> Authur Thisell mentioned that some of the lower-case (RFC 2119) words in
> RFC 4408 were intentional.  Barry Leiba, as Area Director, commented about
> "[treating] changes with due scepticism, with the idea that the change was
> made to fix a real problem, and it had better be right" [1].  I prefer not
> to bring the usual RFC 2119 discussion into this working group.  RFC 4408
> has been around for several years.  If there is a real problem there would
> be some discussion about it.  I would appreciate if someone points me to
> that discussion.


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


Ditto.  :-)


>
>     "This SPF check can only be performed when the "HELO" string is a
>>    valid fully qualified domain."
>>
>> What is a valid fully qualified domain?
>>
>> I believe it means "a name comprising a sequence of DNS labels, separated
>> by dot characters, which when queried resolve to an A or MX record".  It
>> may have a proper definition in some other RFC too.  Should we add one in
>> the Introduction or Definitions?
>>
>
> I suggest dropping "valid" as the quick fix (see below).  I'll defer to
> RFC 5321 instead of having to add more text.


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?


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


How is it not a definition?

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


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


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


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


Sure.


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


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


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


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


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


>
>  In Section 5.5:
>>
>>  "This mechanism SHOULD NOT be used."
>>
>> I suggest providing a reason for this.
>>
>>
>> The very next sentence is "See below for discussion."
>>
>
> It would be clearer to have:
>
>    This mechanism SHOULD NOT be used it is not as reliable as other
> mechanisms in
>    cases of DNS errors, and it places a large burden on the .arpa name
> servers.


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


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


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

 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.


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


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


>
>>   "Care has to be taken by the sending ADMD so that macro expansion for
>>    legitimate email does not exceed the 63-character limit on DNS labels."
>>
>> Where is that 63-character limit specified?
>>
>>
>> RFC1035, Section 2.3.1.
>>
>
> I suggest using Section 2.3.4.


Either's fine.


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


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


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

-MSK