Subject: Re: [spfbis] SPF Draft 15.

From: [email-masked]
Date: Thu, 20 Jun 2013 22:40:41 -0700 (PDT)

OK.  Technically, I don't belong to the mailing list, but maybe it will let me post it.

--- On Thu, 6/20/13, Scott Kitterman <[email-masked]> wrote:
> The public discussion list for this draft is [email-masked]. 
> If you sent your comments there, it's more likely to get a review of
> your comments.
> 
> Scott K
> 
> On Thursday, June 20, 2013 06:34:52 PM you wrote:
> > Re - URL:  http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/?include_text=1
> > 
> > Comments (also posted to Usenet -> news:comp.mail.misc):
> > 
> > Section 3.1:  I would strongly DISAGREE with this and suggest that it is use
> > of TXT-RRs for SPF records that should be deprecated.  The TXT-RR was
> > conceived to convey HUMAN-READABLE information.  SPF information is
> > intended as machine readable (i.e. to be automatically processed as
> > needed).  The SPF-RR should be kept to prevent pollution of the TXT-RR with
> > non-human-readable information.  See also the RP resource record for an
> > additional use of the TXT-RR.
> > 
> > I do agree that it is past time that the transitional use of both types of
> > resource records should cease.  At the time of publication of the document
> > as an RFC, there will be some parties that both resource record types in
> > use.  Although you state that such practice should be discontinued, you
> > should include a specific "sunset date" where checking for both types
> > should also cease.
> > 
> > DomainKeys doesn't suffer this pollution effect because it defines specific
> > DNS labels for its use of the TXT-RR, while SPF requires that its label
> > match that of any subdomain in a given zone that is used as a mail source
> > in mailbox addresses (or outbound server names for the "HELO" SMTP
> > parameter).  This usage may overlap with human-readable usages.
> > 
> > 
> > Section 8.2:  Treating a "neutral" result the same as "none" may not be
> > appropriate in all contexts.  In fact, in my personal SpamAssassin scoring
> > functions, I assign the results DIFFERENT scores.  Therefore, I must
> > disagree with your comments about harshness.  Neutral is an explicit
> > expression while none is the absence of such.  They are not the same.
> > 
> > 
> > Section 8.4:  I disagree with the use of enhanced status code "5.7.1",
> > finding that "5.7.7" ("Message integrity failure") is a better response. 
> > "5.7.1" should be used for rejections per local policy, not remote policy.
> > 
> > 
> > Section 8.7:  I disagree with the use of enhanced status code "5.5.2" (SMTP
> > "syntax error"), finding that "5.7.8" ("Invalid authentication
> > credentials") is a better response.  The problem is not with the SMTP
> > transaction itself but with message source authentication.
> > 
> > 
> > Section 9.1 (and 13.2):  I also disagree with the inclusion of section 9.1
> > ("Received-SPF" header) in favor of ONLY the "Authentication-Results"
> > header described in RFC 5451 and referenced in section 9.2.  Note also that
> > RFC 5451 introduced an additional result:  "Policy"  (cf. my next
> > paragraph).
> > 
> > 
> > Additional (new section 11.8?):  In section 5.5, you indicate that use of
> > the "ptr" mechanism is discouraged.  However, you then fail to address
> > certain other potentially malicious constructs as "+all" or an equivalent
> > combination (e.g.) of "ip4:0.0.0.0/1 ip4:128.0.0.0/1"; in fact, any
> > mechanism that has a CIDR mask of less than "/8" (IPv4, or "/12" for IPv6).
> >  I reject these (CIDRs less than 8, including "+all") with "5.7.9"
> > ("Mechanism too weak").  You use this example in appendix section B.1
> > 
> > It appears as if you have not read the Wikipedia discussion about SPF at
> > http://en.wikipedia.org/wiki/Talk:Sender_Policy_Framework.  Maybe you
> > should review it.