Subject: [spfbis] review of 4408bis-06

From: Arthur Thisell <[email-masked]>
Date: Sun, 26 Aug 2012 10:04:14 -0700 (PDT)

First, the list has been too busy for me to keep up.  I'm afraid I have only skimmed many messages, so I'm sorry if some of this is already covered.

Next, it appears my comments on -05 were neither rejected nor accepted, I suspect Scott missed them:  http://www.ietf.org/mail-archive/web/spfbis/current/msg02199.html

OK, last time I compared rfc 4408 with bis-05, this time I'm going through bis-06 as a whole...

* Overall, when RFC 4408 was drafted, care was taken to capitalize RFC 2119 keywords, and use the lower case words as regular English meaning.  While most of the lower case words have been changed to synonyms, a few have been changed into RFC 2119 keywords.  I think most (but sadly, not all) of these capitalizations are wrong.

* in the abstract, the abbreviation ADMD is used, but isn't defined until late.  I would just spell the abbreviation out in the abstract, and leave the introduction of ADMD to the introduction.

* I would get rid of the mention of "spf classic".   Enough time has transpired that I suspect this causes more confusion than helping to clarify "Pre-MARID SPF" vs "MARID SPF" vs "Sender-ID" vs "Post-MARID SPF".

* After further pondering, I would get rid of the Deprecated definition (section 1.3.5.).  The only thing that is deprecated is ptr:/%{p}, which were only "discouraged" in RFC 4408.   

I can not ever see version 1 of SPF having such an incompatible change as getting rid of ptr:/%{p}.   SPF has a version number for a reason.   If, in a new WG, we want to change such things, we should go to version 3.   We can adopt SPF version 2's magic number format of spf3.0 instead of v=spf3.  We can keep spf 2's notation for different identities and its positional modifiers.   We can get rid of ptr:/%{p}.  We can either get rid of macros that have a local part, or greatly simplify/eliminate macros all together. We can switch to using only type 99 SPF records.  We can do lots of things that can't be done to version 1 of SPF.

Declaring something as deprecated in this I-D seems contrary to the WG charter and contrary to version 1 of SPF. 

* In the last paragraph of section 2.4, it talks about dangers of bang paths and such.  That might be a good place to mention potential problems with SMTPUTF8, IDN, etc.

* In section 2.5.6 on temperror, new language seems to imply that temporary errors are only caused by DNS errors, but timeouts could be caused by local problems unrelated to the DNS.

* In section 2.5.7 on permerror, there is a warning about macros causing problems.  This might be a good place to add a warning about using local part macros, particularly with SMTPUTF8.

* RFC 4408 used lower case 2119 in a normal English usage fashion. In section 3.5 on wildcard records, the "not recommended" has been capitalized.  I think this changed the intent of RFC 4408, and instead it should be changed to "discouraged" or some similar language.   Actually, the first sentence of that paragraph is kind of redundant with the second sentence.

* In section 4.4, multiple DNS errors over a 24 hour period now can be called a permerror.   I'm pretty sure there are a couple of SPF implementations that do this, but if not, this would probably violate the WG charter.

* in section 4.6 Record Evaluation, the first sentence starts with "After one SPF record has been selected,".  I think this is left over from when there was a record selection procedure for TXT/SPF records.   I think saying "The check_host() function parses and interprets the SPF record to..." would be better.

* in section 4.6.4, there is a new requirement that there must not be more than 10 records for mx: or ptr:.   This completely wrong for ptr: because a spammer could choose to send spam from a host with more than 10 PTR records, thus forcing a domain's SPF record to return permerror, instead of fail.   If anything, more than 10 PTR records should cause the ptr: mechanism to automatically not-match.  It should also be made clear that the %{p} macro is valid no matter how many PTR records are returned.

To be honest, I think this new text should be removed from 4.6.5 and moved/reworded in the appropriate sections of 5.*.

* in section 5.2, there is a weird line break in "both domains was<brr>mx:example.com"

* in section 5.4 (MX) and section 5.5 (PTR), no mention is made of the new requirement that there must not be more than 10 records that was added to section 4.6.4

* in section 5.5 (PTR), step 1 and step 2 are really the same step.  In RFC 4408, this was in paragraph form, where these were two sentences describing a rDNS lookup.

* in section 5.7 (EXISTS), there news language saying "The query will either return NXDOMAIN (no match), any valid answer (match), or an error."  What happenss on an error?   I think this sentence is redundant and better fixed by rewording text above it.

Suggested text:

bis-06:
   The domain-spec is expanded as per Section 8.  The resulting domain
   name is used for a DNS A RR lookup.  If any A record is returned,
   this mechanism matches.  The lookup type is A even when the
   connection type is IPv6.

new:

   The domain-spec is expanded as per Section 8.  The resulting domain
   name is used for a DNS A RR lookup (even when the connection type is
   IPv6). If any A record is returned, this mechanism matches, otherwise
   the mechanism doesn't match.  

or new:

   The domain-spec is expanded as per Section 8.  The resulting domain
   name is used for a DNS A RR lookup (even when the connection type is
   IPv6). If any A record is returned, this mechanism matches.  In all
   other cases (no A records, DNS error, etc.), the mechanism doesn't
   match.

* in section 7. (recording the result), there is a lot of new text, here and I've seen a lot of discussion on the mailing list about it.   I'm not sure what the current consensus is, but here is my two cents.   First, I think the text should be made clearer that it is ok (maybe even RECOMMENDED?) to add both R-SPF and A-R fields.  Second, the beginning of the second paragraph says "if the SMTP receiver chooses to do so, ...".  I think it is unclear what "to do so" is referencing.  In RFC 4408, it was clear this meant "choose to add a R-SPF header".

* in section 8.1 (macro defs), there is a "Note: Care MUST be taken so that ...".  I think it should be clearer that it is the ADMD, not the SPF verifier that needs to take care.  That is, it should say "Note: The ADMD needs to take care so that..."  This wording also fixes what I think was an incorrect changing of an english language meaning of "must" to a RFC 2119 keyword.

* in section 8.1 (macro defs), there is a note that says "Note: Domains SHOULD avoid using ...".  Again, if RFC 4408 the "should" was lower case and I don't think it was meant to be an RFC 2119 keyword.  Maybe "Note: ADMDs are discouraged from using ..."?

* in section 9.1.2, first paragraph: s/over "a" or "a" or "mx"/over "a" or "mx"/

* in section 9.2.2, a blank line was removed before the paragraph beginning "Note that due to the 63-character limit..."

* In section 9.3.2, I think the following sentence is too long:
   
   SPF fail results can alternately be used as one input into a larger
   set of evaluations which might, based on the overall evaluation
   result in the email being marked negatively in some way (this might
   be via delivery to a special spam folder, modifying subject lines, or
   other locally determined means). 

Simply breaking out the parenthetical phrase into its own sentence would help.

* In section 10.2: s/authorizationsto/authorization to/

* In appendix A, the sentence "Hence, "mx" matches "mx", "MX", "mX", and "Mx"." should probably be moved/copied to section 4.6.1 (term evaluation).  This was a problem with RFC 4408 also.

* In appendix A, I was too lazy to check to see if this collected ABNF matches wat is in the rest of the document.  I hope someone will at least once before publication...

again, sorry for not replying to appropriate threads at appropriate times.  I hope this list will be helpful anyway.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 26 Aug 2012 10:20:35 -0700

Arthur,

Well, aren't you /diligent/?  Very nice.

My own tidbits to add to your notes:

On 8/26/2012 10:04 AM, Arthur Thisell wrote:
> * in the abstract, the abbreviation ADMD is used, but isn't defined
> until late.  I would just spell the abbreviation out in the abstract,
> and leave the introduction of ADMD to the introduction.

I think I am seeing people rather naturally use "administrative domain"
as the terse, prose version of the term, absent formal discussion.  For
something like an abstract, I think it's intuitive meaning is sufficient
to justify leaving out the "management'.

> * I would get rid of the mention of "spf classic".   Enough time has
> transpired that I suspect this causes more confusion than helping to
> clarify "Pre-MARID SPF" vs "MARID SPF" vs "Sender-ID" vs "Post-MARID
> SPF".

+1.

> * After further pondering, I would get rid of the Deprecated
> definition (section 1.3.5.).  The only thing that is deprecated is
> ptr:/%{p}, which were only "discouraged" in RFC 4408.

Well, we are starting to discuss some other uses of it...

> I can not ever see version 1 of SPF having such an incompatible
> change as getting rid of ptr:/%{p}.   SPF has a version number for a
> reason. 

Version numbers are never really as useful as people expect them to be.
 That's because a new version is either incompatible or is upward
compatible.  Incompatible creates massive interoperability problems,
absent a different port number of some other equally massive separation;
version numbers don't get seen soon enough.

Upward compatibility doesn't need the version number:  all the older
stuff still works and the mere presence of the newer stuff declares that
the record supports features of a later version.  This self-declaration
also avoids the problem of having to define what to do when there are
more than two versions.

There was an interesting exploration of this reality for MIME, long ago,
which realized that it would never change the version number.

> Declaring something as deprecated in this I-D seems contrary to the
> WG charter and contrary to version 1 of SPF.

Not really, since it doesn't remove anything.  Rather, it's a marker for
the future.

d/
-- 
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

---

From: S Moonesamy <[email-masked]>
Date: Sun, 26 Aug 2012 18:42:00 -0700

Hi Arthur,
At 10:04 26-08-2012, Arthur Thisell wrote:
>First, the list has been too busy for me to keep up.  I'm afraid I 
>have only skimmed many messages, so I'm sorry if some of this is 
>already covered.
>
>Next, it appears my comments on -05 were neither rejected nor 
>accepted, I suspect Scott missed 
>them:  http://www.ietf.org/mail-archive/web/spfbis/current/msg02199.html

Thanks for the review.  I made a note of the comments.

>through bis-06 as a whole...

There is Issue #34 to Issue #48 in the tracker.  I'll follow up on 
the issues that were not added to the tracker.

Thanks,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 27 Aug 2012 09:59:44 -0400

On Sunday, August 26, 2012 10:04:14 AM Arthur Thisell wrote:
> Next, it appears my comments on -05 were neither rejected nor accepted, I
> suspect Scott missed

I missed them.

Scott K