I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).


Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-spfbis-4408bis-19
Title: Sender Policy Framework (SPF) for Authorizing Use of Domains in
Email, Version 1
Reviewer: Eliot Lear
Review Date: 25 Aug 2013
IETF Last Call Date: 19 Aug 2013
IESG Telechat Date: 12 Sep 2013

Summary: This draft is not yet ready for publication as a Proposed
Standard and should be revised before publication.

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.

2.  So-called "Utility Labels"

Throughout the document _spf.example.com is used, as is the term "common
utility labels".  Maybe bind doesn't cough up blood on underscores, but
this is also not what we would call a sanctioned practice by our RFCs. 
If this is truly first use (and I could be wrong), then the utility of
utility labels need to be made clear.  As this is, IMHO, *not* the focus
of this standard, my suggestion would be to change the example.

3.  Retain a summary of changes since 4408.

A -bis document usually has a change list that can assist implementers
familiar with previous work.  Appendix J is pretty close to what I would
want, but it needs some editing.

Minor Issues:

There are areas where the document seems to go to lengths to avoid the
use of normative language.   If either the WG or the IESG cares, I can
go through a few that could stand to be MAYs, but here is but one example:

>    A mail receiver can perform a set of SPF checks for each mail message
>    it receives. 
As I say below, this text actually adds nothing to the document, but if
the author decides to leave it in, this is a prime example of where MAY
was intended to be useful.

Similarly, there is the occasional "ought to", such as that found in
Section 3.  If the WG considered normative text and rejected it, fine. 
But if they didn't, they should.  This is a complex specification, and
our normative language definitions are there to provide clarity and
consistency.

Throughout the document <target-name> is used as the macro expansion of
<domain-spec>.  I don't recommend that.  While much of SPF seems an
exercise in indirection, the actual RFC should not be.  Better to simply
say "<domain-spec> or its macro-expansion."  And no, I wouldn't care
about this in most documents, but the sheer number of forward and
backward references in this document has me (and will have other
readers) constantly flipping backward and forward.

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.

Section 2.5: title

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

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?

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.

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?

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.

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.

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

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

Page 7, Section 1.2:

This forward reference is unnecessary, and I would remove the section.


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.



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

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.

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

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?

Eliot