Subject: [apps-discuss] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.txt

From: Eliot Lear <[email-masked]>
Date: Sun, 25 Aug 2013 17:13:53 +0200

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

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 25 Aug 2013 12:23:32 -0400

No hat.

> of this standard, my suggestion would be to change the example.

I don't think I understand this critique, but I think your claim is
that underscores are somehow not scanctioned by RFC.  I think you are
mistaken about this.

Best,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Sun, 25 Aug 2013 21:51:19 +0200

You're correct.  For some reason I thought they were reserved.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Sun, 25 Aug 2013 13:24:09 -0700

These are meant as targeted responses, rather than to the review in general:

On 8/25/2013 8:13 AM, Eliot Lear wrote:
> understand why the record was in fact deprecated.

This is confusing.  These are specifications, not historical 
explanations.  IETF specifications /permit/ far more commentary than do 
most standards groups' documents. However the degree of expectation -- 
nevermind requirement -- for extended rationale about choices that is 
being called for here does not match my sense of what is typical for 
IETF specifications.

Can you provide some pointers to recent exemplars that match what you 
are calling for?

> utility labels".

Perhaps my search function is off, but I'm only finding one occurrence 
of "common utility labels".

> Maybe bind doesn't cough up blood on underscores, but

Use of underscores is not sanctioned?  Huh?

It's been a standardized practice for more than 10 years.  See SRV.

If you mean something else, what is it?

> was intended to be useful.

Probably not.  It has nothing to do with interoperability.  It is, in 
fact, purely advisory text about possible use.  As such, it's actually 
rather important that it /not/ use normative language.

(The text does need to be clear about the line between normative and 
advisory text, of course.)

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 25 Aug 2013 20:58:06 -0000

>You're correct.  For some reason I thought they were reserved.

There have been occasional efforts to set up a registry of prefixed
names to avoid collisions, but for now it's a free for all.
Fortunately, the space of prefixed names is large enough that collisions
haven't happened yet.

The most recent effort I can find is  draft-crocker-dns-attrleaf-06

R's,
John

---

From: Pete Resnick <[email-masked]>
Date: Sun, 25 Aug 2013 16:44:51 -0500

> 2.  So-called "Utility Labels"

Eliot, I would like to hear some followups to the folks who have posted 
so far before more folks pile on. I'm hearing for the two above major 
issues:

On 1: Others have said that the document already points to 6686 where 
quite a bit of justification is made, and in any event the present 
document isn't the correct place for such justifications. Also, folks 
have said that the document already says that syntactically incorrect 
records will fail processing (with a "permerror" -- see section 4.6).

On 2: Folks have said that you are incorrect about underscore in labels 
being a problem as they are already widely used (e.g. SRV).

Were your comments misunderstood?

I'm not sure why major issue 3 is "major", but I think the WG can 
consider it (if it has not already) like some of the other things you've 
mentioned.

But like I said, before more people respond on the first two, I'd like 
to understand what you mean.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: S Moonesamy <[email-masked]>
Date: Sun, 25 Aug 2013 16:49:50 -0700

Hi Eliot,
>Standard and should be revised before publication.

I'll respond to part of the comments.

The SPFBIS WG has a tightly-scoped charter.  Suggested changes to RFC 
2119 keywords, for example, were carefully considered.  One of the 
problems was the way RFC 4408 was written.  draft-ietf-spfbis-4408bis 
is not a complete rewrite of RFC 4408.  The clarifications were kept 
as narrow as possible.

>Major issues:

[snip]

>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 thread at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03964.html 
about the "_spf" prefix.  I went over some of the messages posted 
during the WG charter discussion to see whether the WG could have 
considered a DKIM-like solution.  In my opinion it would be out-of-scope.

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

There is a thread at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03996.html in 
response to your review.  The "Utility labels" is a note in the 
draft.  _spf.example.com was used in RFC 4408 for some examples and 
the text is similar in the draft.  My reading of the message at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10272.html 
is that the examples do not have to be changed (re. not sanctioned by RFC).

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

Did you mean merging some of Appendix J into Appendix C?

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

Please refer to my opening comment.

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

The SPFBIS WG considered whether having the normative text was within 
scope.  I agree with your argument about clarity and 
consistency.  The document shepherd review is at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03414.html I 
did a pass of the RFC 2119 keywords and compared them against what is 
in RFC 4408.  Adding normative language can entail a significant 
rewrite of the draft.  It can create incompatible changes.  As you 
mentioned this is a complex specification and significant changes 
would require a level of review beyond what has been done up to now 
to achieve better clarity and consistency.  This draft has been a 
significant effort.  I'll leave it to the IESG to assess whether 
asking the SPFBIS WG to go beyond that is doable.

Thanks for the careful review.

Regards,
S. Moonesamy

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Aug 2013 07:44:20 +0200

On 8/25/13 11:44 PM, Pete Resnick wrote:
>
> Eliot, I would like to hear some followups to the folks who have
> posted so far before more folks pile on. I'm hearing for the two above
> major issues:
>

The reference is to Appendix A.  Unfortunately, the text there doesn't
go far enough.  All it says is:
>    4.  [SPF] itself included a faulty transition plan, likely because of
>        the late addition of a requirement to develop one -- it said:
>
>          An SPF-compliant domain name SHOULD have SPF records of both RR
>          types.  A compliant domain name MUST have a record of at least
>          one type.
>
>        which means both can claim to be fully compliant while failing
>        utterly to interoperate.

This reads as if somehow a record is a protocol.  What I would suggest
(at the very least) is the following:

"Because ADMDs have in the past published either SPF or TXT records, and
because some MTAs query for only one or the other, it is possible that
an MTA will not find a published record.  When both records are
published it is possible for them to differ."

I *think* these are the interoperability issues (I can't say because
6686 isn't clear).

Because we know people are querying SPF records (there is ample
empirical evidence), the text could even go further and say something
like this:

"While we are deprecating the SPF record, any ADMD that continues to
publish an SPF record at this point MUST also publish the semantically
equivalent TXT record."  I don't know of instances in the wild where
this was a problem, and if it wasn't then this isn't really an
interoperability issue worth considering.  That goes to a more
substantial debate about whether the record should be deprecated. 
Again, I'm not taking a position about that here.

There is matching text for MTAs: "MTAs MUST NOT query for RRTYPE 99
records."  The text ALMOST says that in Section 4.4 and again in 13.2,
but for some reason stops short.  This goes to my other issue, that
normative language is not appropriately used.

>
> On 2: Folks have said that you are incorrect about underscore in
> labels being a problem as they are already widely used (e.g. SRV).

I withdraw that issue.  See exchange between Andrew, John and me.
> consider it (if it has not already) like some of the other things
> you've mentioned.

It's in Appendix C.  I was looking at Appendix J.  Withdrawn.

Eliot

---

From: S Moonesamy <[email-masked]>
Date: Sun, 25 Aug 2013 23:01:17 -0700

Hi Eliot,
At 22:44 25-08-2013, Eliot Lear wrote:
>The reference is to Appendix A.  Unfortunately, the text there 
>doesn't go far enough.  All it says is:
>This reads as if somehow a record is a protocol.  What I would 
>suggest (at the very least) is the following:

Yes, that text might be read in different ways.  Your review brought 
a fresh perspective to the discussion.  I'll ask the SPFBIS WG about the text.

>I withdraw that issue.  See exchange between Andrew, John and me.

I'll list Issue 2 ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10270.html 
) as addressed.

>It's in Appendix C.  I was looking at Appendix J.  Withdrawn.

I'll list Issue 3 ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10270.html 
) as addressed.

Regards,
S. Moonesamy (as document shepherd)

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 26 Aug 2013 00:13:31 -0400

> want, but it needs some editing.

That's what Appendix C is meant to accomplish.  Appendix J is not meant to be 
included in the final document.  As far as I've noticed, the items that aren't 
listed in Appendix C that are in Appendix J don't directly affect implementers.  
Is there something specific missing from Appendix C?

Scott K

---

From: Hector Santos <[email-masked]>
Date: Mon, 26 Aug 2013 08:55:09 -0400

Hi Eliot,

I appreciate your review of SPFBIS.  I only have a few small input 
bits to provide:

> Standard and should be revised before publication.

+1

> grammar MUST be ignored.  

I think the documentation usage of the term "SPF record" can be 
confusing if the type99 is going to be removed.  It can suggest that 
this "SPF record" is unique and is not residing with other "records."

I think the term should be more specific to say the SPF TXT resultant 
record contains multiple EOL (CRLF or CR or LF terminators) strings 
and and only a string beginning with the *token* "v=spf1" is a 
considered a SPF record string.   In theory, the parser should 
tokenizing it to check for "v=" and then only process the v= value "spf1"

Perhaps a more specific term such as "SPF Line Record" or String would 
be clearer.

> Also, did the working group consider a

Yes. It was but I didn't think it was taken serious. I can see now the 
draft was leaning towards to publishing method.  My particular concern 
with this is that it also yields a TXT/TXT dual call waste and high 
redundancy if it doesn't become a learned processed (a domain is known 
to use _spf. zone).

In other words, for large ESP using this method, it will yield a very 
high overhead in at least TWO TXT lookups. Keep in mind one of the 
SPF99/TXT concerns is the wasted SPF99 call.

> until there is clear text about the interoperability issues that are

+1.

--
HLS

---

From: Ángel <[email-masked]>
Date: Mon, 26 Aug 2013 23:17:03 +0200

> Perhaps a more specific term such as "SPF Line Record" or String would 

However, there could be one TXT record with embedded line breaks. I
don't think a spf parser should try to extract that.