Subject: Re: [apps-discuss] [spfbis] Applications Directorate Review: ABNF

From: S Moonesamy <[email-masked]>
Date: Thu, 29 Aug 2013 01:03:54 -0700

Hi Eliot,

The following is to address the rest of the 
review.  There was one major issue which I did 
not comment about in my previous message.

At 08:13 25-08-2013, Eliot Lear wrote:
>Major issues:
>
>1. Deprecation of SPF record not properly 
>justified in text and in the wrong place
>Deprecation of the SPF record is given short 
>shrift in Section 13.1 which is the IANA 
>considerations section.Â  A persistent reader 
>would not understand why the record was in fact 
>deprecated. Here's what is 13.1 (there are a few 
>words about 6686 in 3.1 as well, but nobody 
>would care if this was simply a matter of low implementation/deployment).
>
>>    Studies have shown that RRTYPE 99 has not seen any substantial use,
>>    and in fact its existence and mechanism defined in [RFC4408] has led
>>    to some interoperability issues.
>
>First, this text should be moved out of the IANA 
>considerations sections and forward to Section 
>3.1.  Second it should explain what those 
>interoperability issues are or have a normative 
>(and retrievable) reference.  At the very least, 
>the winning argument(s) should be elucidated, 
>and not just for posterity: the claim is that 
>there is an interoperability problem.  If so, 
>then might administrators want to know that?
>
>The matter of handling garbage in garbage out is 
>not well enough specified in Section 3.  I would 
>go considerably further and state that (a) 
>records that do not begin with "v=spf1" MUST NOT 
>be processed further, and (b) that any record 
>that does not conform to the stated grammar MUST 
>be ignored.  Also, did the working group 
>consider a DKIM-like solution?  They all but 
>establish an _spf label in this document (I'll come to that in a moment).
>
>There is a general issue about when to deprecate 
>an RR and the ability to add new RRs into the 
>DNS.  That issue has to be addressed in the 
>longer term, no matter what the IESG and 
>community decide here.  Furthermore, to be 
>clear, please do not read into the above 
>comments an opinion about deprecation of the 
>record itself, which I am withholding until 
>there is clear text about the interoperability issues that are mentioned.

The SPFBIS WG is not deprecating type 
SPF.  RRTYPE 99 has been removed from the (draft) 
protocol.  The working group discussion was 
something very like MUST NOT publish, MUST NOT 
query ...  The author thinks it might be 
reasonable to be more verbose in Appendix C,
which currently says:

    o  Use of DNS RR type SPF (99) has been removed from the protocol,
       see [RFC6686] for background.

Personally, he thinks it's accurate and succinct 
and he is not sure what to change that would 
amount to the same thing in a lot more words.  In 
his opinion, ... has been removed ... . .... MUST 
NOT query ... . ... MUST NOT publish ... . Is 
redundant, but he don't strongly object if people think it would be better.

There has been some discussion of the _spf label 
on the SPFBIS mailing list.  If I recall 
correctly I commented about that in one of my responses to the APPSDIR review.

>Section 2.2, 1st para
>
>>    Typically, such checks are done
>>    by a receiving MTA, but can be performed elsewhere in the mail
>>    processing chain so long as the required information is available and
>>    reliable
>People may infer a traipse through Received 
>headers for HELO information.Â  Is that the 
>intent, and is that acceptable, given that they 
>could be forged?Â  My point: the above is vague.

It's, most importantly, the actual connect IP 
from outside the receiving ADMD.  Finding the 
trust boundary reliably while groveling through 
the message header is hard, but people do 
it.  Since post-SMTP checks are quite common, it 
wouldn't be appropriate to try and disallow 
them.  The author thinks the current language is 
a reasonable compromise and, IIRC, subject to 
some intense WG debate that he prefers not to revisit.

>Section 2.5: title
>
>>2.5.  Location of Checks
>I don't think you mean location.  I think you mean "When to perform checks".

Location in the sequence of events.  Where would 
work as well.  The author thinks
Location/When/Where are all equivalent.  He 
prefers not to change it.  The SPFBIS did not support a change.

>Section 4.7, 2nd para, 2nd sentence.
>
>>    Although the latter
>>    has a default (specifically "?all"), it aids debugging efforts if it
>>    is explicitly provided.
>
>How does it aid in debugging?

It makes it clearer to the human eye what's 
intended.  People handle explicit better than implicit.

>Section 5.6, ABNF:
>
>You've gone to some lengths to get ipv4 correct, 
>but you don't do the same with CIDR prefixes.
>
>>    ip4-cidr-length  = "/" 1*DIGIT
>>    ip6-cidr-length  = "/" 1*DIGIT
>Strictly speaking the value range is from 1 to 
>32, for v4, and 1 to 128 for v6.  This isn't 
>quite all legal, but at least it's bounded:
>
>     ip4-cidr-length = "/" 1*2DIGIT ; value must be > 0 and may not exceed 32
>     ip6-cidr-length = "/" 1*3DIGIT ; value must be > 0 may not exceed 128
>
>You could do the same as you did with qnum, but perhaps that is overkill.

There has been some discussion of the ABNF on the 
SPFBIS mailing list ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04047.html 
).  This is the suggested ABNF (credits to John Levine):

   ip4-cidr-length  = "/" ("0" |  %x31-39 0*1DIGIT) ; value range 0-32
   ip6-cidr-length  = "/" ("0" |  %x31-39 0*2DIGIT) ; value range 0-128

>Section 6.2, last para:
>
>The following text is confusing:
>
>>    Note: During recursion into an "include" mechanism, an "exp" modifier
>>    from the <target-name> MUST NOT be used.Â  In contrast, when executing
>>    a "redirect" modifier, an "exp" modifier from the original domain
>>    MUST NOT be used.
>
>When "MUST NOT be used" do you mean MUST NOT be 
>evaluated or processed or MUST NOT be present in 
>the record?  e.g., does this MUST apply to operators, implementers, or both?

Recursion into an include or execution of a 
redirect is part of the evaluation that a 
verifier does.  Must not be processed/evaluated 
by a verifier.  Since record publishers won't 
always know if others will use point to their 
records using include/redirect, there's no way a 
publisher could satisfy this requirement.  Given 
it can only work one way, the author don't understand the confusion.

The author is open to improved text, but he does not see the problem.

>Appendix A:
>
>>    This section is normative and any discrepancies with the ABNF
>>    fragments in the preceding text are to be resolved in favor of this
>>    grammar.
>Normally we don't normatively reference 
>Appendices, and it represents a bit of a 
>cultural cognitive dissidence for some.  One 
>possible fix: don't make it an Appendix, but the 
>last section.  But also, Section 7.1 is entitled 
>"Formal Specification".  Don't have two of those.

The ABNF collection will be moved to a section.

>Appendix E:
>
>There's probably a case not covered here, but 
>it's close.  E.1 describes originating ADMD 
>behavior.  Think of the case of a university or 
>professional organization that offers 
>forwarding.  The advice given in the first 
>bullet of E.1 is probably applicable, but 
>requires that a new whitelist entry be created 
>for new aliases that contain new hosts on the 
>RHS.  I would go just that bit further to explain.

Forwarders are mediators in the terms used here and E.2 is applicable, not E.1.

>Nits:
>Please stop creating acronyms.  Spam = 
>unsolicited bulk email.  UBE is obfuscation in 
>this case.  Similarly, I'd ask the authors to 
>trying speaking out loud "domain owning ADMDs,", 
>expanding out the acronym.  How about just saying "domain owners"?

That's unchanged from RFC 4408.  The author does not think we should change it.

RFC 5598 is the mail architecture document the 
working group used got.  The author agrees it's 
trained, but we tried to stick with terminology 
from 5598.  Ripping out the 5598 terminology 
would be a bunch of work that he does not think would be worth it.

>In general your definitions section is 
>unnecessarily verbose and could go for a good 
>"haircut".  For example, how about these:
>
>Imported Definitions:
>MAIL FROM: The RFC5321.MailFrom, as defined in [RFC5321]
>HELO: The parameter specified in the HELO or 
>EHLO commands as specified in [RFC5321].
Possibly.  The longer definition is largely from RFC 4408.

The SPFBIS WG did not suggest any change to this.

>Page 7, Section 1.2:
>
>This forward reference is unnecessary, and I would remove the section.

The author agrees but the working group doesn't.

>2.1 2nd para, 2nd sentence:
>
>>If ADMDs
>>    choose to publish SPF records and want to support receivers making
>>    negative authorization determinations, it is necessary for them to
>>    publish records that end in "-all", or redirect to other records that
>>    do, otherwise, no definitive determination of authorization can be
>>    made.
>
>That's grammatically incorrect.  Remove 
>everything after "do," and you are fine.

The author is ok with the suggestion.

>Same section further down, please clarify "While 
>offline checks are possible".  I think you mean 
>"deferred" or "checks made after delivery" or some such.

The author thinks post-delivery would be 
better.  Obviously literal offline checks aren't
possible.

>Section 2.2 first para, first sentence:
>>    A mail receiver can perform a set of SPF checks for each mail message
>>    it receives.
>
>What value does this sentence offer the 
>reader?  Personally I say none, and would remove.

That's there in response to people complaining 
4408 was somehow making SPF checks 
mandatory.  The author does not care if it is 
removed it as long as someone else deals with the 
crazies convinced it's removal means something sinister.

>Section 5.4: "mx"
>
>>Then it performs an address lookup on each MX name returned.
>
>To be precise:
>
>"It then performs an address lookup on of the 
>name found in the RDATA of each answer."

The author is ok with changing this.

>Section 8.5, 2nd sentence:
>
>>The ADMD believes the host is not authorized 
>>but is not willing to make a strong policy statement
>
>Which ADMD?

The sending one.  It's their record.

Regards,
S. Moonesamy (as document shepherd)