Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-03.txt

From: [email-masked]
Date: Thu, 05 Jul 2012 13:17:33 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the SPF Update Working Group of the IETF.

	Title           : Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
	Author(s)       : Scott Kitterman
	Filename        : draft-ietf-spfbis-4408bis-03.txt
	Pages           : 57
	Date            : 2012-07-05

Abstract:
   E-mail on the Internet can be forged in a number of ways.  In
   particular, existing protocols place no restriction on what a sending
   host can use as the reverse-path of a message or the domain given on
   the SMTP HELO/EHLO commands.  This document describes version 1 of
   the Sender Policy Framework (SPF) protocol, whereby a domain can
   explicitly authorize the hosts that are allowed to use its domain
   name, and a receiving host can check such authorization.  This
   document obsoletes RFC4408.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-03

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 05 Jul 2012 16:33:56 -0400

On Thursday, July 05, 2012 01:17:33 PM [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the SPF Update Working Group of
> the IETF.
> 
> 	Title           : Sender Policy Framework (SPF) for Authorizing Use of
> Domains in Email, Version 1 Author(s)       : Scott Kitterman

Based on our recent discussion, I don't think anything in this revision will 
be a surprise:

             Update changes for Type SPF removal based on list feedback.

             Fix ABNF nits and add missing definitions per Bill's ABNF checker.	
 
 	      Make DNS lookup time limit SHOULD instead of MAY.	
 
 	      Reorganize and clarify processing limits.  Move hard limits to new	
 	      section 4.6.4, Evaluation Limits.  Move advice to non-normative	
 	      section 9.	
 
 	      Removed paragraph in section 10.1 about limiting total data	
 	      volumes as it is unused (and removable per the charter) and serves	
 	      no purpose (it isn't something that actually can be implemented in	
 	      any reasonable way).

I would particularly appreciate review on the reorganization/clarification of 
the processing limits as it's a significant editorial change (there are no 
intentional technical changes except the separately mentioned timeout 
MAY/SHOULD) and the refinement of the Type SPF language.  The rest I think it 
relatively uncontroversial.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 06 Jul 2012 13:23:19 +0200

> relatively uncontroversial.

I like how the document is getting shaped up.

3. *SPF Records*

I'd move the example away.  The rest could be merged with the
following subsection, possibly merging also the titles into, say,
"Publishing SPF Records".

3.1. *Publishing*

Ditto for the example.  There is too much redundancy among the first
paragraphs of Sections 3, 3.1, and 3.1.1.  There is a lowercase "must
publish".  Finally, "publishing via TXT" is the only way now.  I'd
propose:

 An SPF record is a DNS Resource Record (RR) that declares which
 hosts are, and are not, authorized to use a domain name for the
 "MAIL FROM" and "HELO" identities.  For each identity, an SPF
 evaluation starting at the relevant domain name associates an
 authorization result to each possible sender, based on the
 authentication token provided by lower level protocols, the IP
 address.  Therefore, SPF records to authorize the "MAIL FROM"
 identity have to be published in the DNS tree at the domain name
 corresponding to the domain part of the email address; for the
 "HELO" identity, at the domain used (or abused) in the EHLO or HELO
 SMTP commands.

 Domains publishing records SHOULD keep the number of "include"
 mechanisms and chained "redirect" modifiers to a minimum, albeit a
 single redirect might sometimes help size limits (see Section
 3.1.4).  Domains SHOULD also minimize the amount of other DNS
 information needed to evaluate a record.  Section 9.1.1 provides
 some suggestions on how to achieve this.

4.6.4. *Evaluation Limits*

There is a typo in the phrase "at most 10 per during SPF record
evaluation".  Saying "per SPF record" might convey the false
impression that the count is reset upon loading a new (included or
redirected) record.  How about "per SPF evaluation", where an SPF
evaluation is defined elsewhere as a run of the check_host algorithm?

The title "Evaluation Limits" is very similar to, but different from
"Processing Limits" of Section 10.1.  Putting exactly the same title
would convey that they treat the same subject from different angles.
In that case, the more-normative-than-explanatory last paragraph of
10.1 could be moved to 4.6.4.  Otherwise, "DNS Lookup Limits" would
seem to be more appropriate for the latter section.

9.1.1. *DNS Resource Considerations*

The first example is difficult to read, as it is not clear what are a,
b, and c.example.com.  I'd propose to make three figures with the
relevant part of the explanatory paragraph appearing as caption to
each one.

The second example doesn't say what mechanism to use.  s/'MX"/"mx"/.

A third example might be worth.  I'm going to write a separate message
for it.

9.3. *Mail Services*

I think you mean ESP, not MSP.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 06 Jul 2012 14:50:48 -0400

On Friday, July 06, 2012 01:23:19 PM Alessandro Vesely wrote:
> > I would particularly appreciate review on the reorganization/clarification
> > of the processing limits as it's a significant editorial change (there
> > are no intentional technical changes except the separately mentioned
> > timeout MAY/SHOULD) and the refinement of the Type SPF language.  The
> > rest I think it relatively uncontroversial.
> 

I think this section is important because it explains what an SPF record is.  
Introducing such an important concept for the protocol is very important and 
it's worth some text to make it clear, but I think a 3.1 without a 3.2 is a 
good sign the organization is poor.

> publish".  Finally, "publishing via TXT" is the only way now.  I'd

I fixed the publishing via TXT sentence to start "Since TXT records have 
multiple uses, beware ..." locally.  Good catch.

>  some suggestions on how to achieve this.

Let's try combining 3 and 3.1 (and then the third digit 3.1.x numbers move up 
a level).  I think it reads pretty well that way.  I don't think we ought to 
rewrite though unless we really need to.

> evaluation is defined elsewhere as a run of the check_host algorithm?

Make sense.  I think that's clearly better.  If I change the word "interprets" 
to "evaluates" in the first sentence of section 4, then it flows nicely.  Fixed 
the typo too.

> seem to be more appropriate for the latter section.

I think "DNS Lookup Limits" is good.

> relevant part of the explanatory paragraph appearing as caption to

Please provide text.  I'm not sure what you're suggesting.

> The second example doesn't say what mechanism to use.  s/'MX"/"mx"/.

Text here too.  Fixed the typo.

> I think you mean ESP, not MSP.

I would have thought that too, but I'm trying to stick to RFC5598, "Internet 
Mail Architecture", terms and it uses MSP, not ESP.  If 5598 is wrong, it 
should be fixed.

Scott K