Re: [dnsext] SPF, a cautionary tale

bmanning@vacation.karoshi.com Sun, 05 May 2013 08:53 UTC

Return-Path: <bmanning@karoshi.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E8221F8A11 for <dnsext@ietfa.amsl.com>; Sun, 5 May 2013 01:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.442
X-Spam-Level:
X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKwEtnMnLV96 for <dnsext@ietfa.amsl.com>; Sun, 5 May 2013 01:53:52 -0700 (PDT)
Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3AD21F8A0C for <dnsext@ietf.org>; Sun, 5 May 2013 01:53:50 -0700 (PDT)
Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id r458rnFo006166; Sun, 5 May 2013 08:53:50 GMT
Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r458rmRb006165; Sun, 5 May 2013 08:53:48 GMT
Date: Sun, 05 May 2013 08:53:48 +0000
From: bmanning@vacation.karoshi.com
To: John R Levine <johnl@taugh.com>
Message-ID: <20130505085348.GA6061@vacation.karoshi.com.>
References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> <alpine.BSF.2.00.1305041103360.8602@joyce.lan> <20130505012216.GA29079@vacation.karoshi.com.> <alpine.BSF.2.00.1305042223280.10848@joyce.lan> <20130505032549.GA30757@vacation.karoshi.com.> <alpine.BSF.2.00.1305042327490.11044@joyce.lan>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.BSF.2.00.1305042327490.11044@joyce.lan>
User-Agent: Mutt/1.4.1i
Cc: bmanning@vacation.karoshi.com, dnsext@ietf.org
Subject: Re: [dnsext] SPF, a cautionary tale
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 May 2013 08:53:56 -0000

On Sun, May 05, 2013 at 12:51:52AM -0400, John R Levine wrote:
> Re CNAME and SPF looping, whatever you call them, the loop breaking issues 
> are the same.  This really isn't a complicated idea.  SPF is slightly 
> uglier since a single SPF record can have multiple includes, but the 
> solution, a fixed limit on the iterations, is the same.

	one vs. many ...  and the number of includes in SPF is bounded
	at the upper limit of...?

> > Please enumerate "all of the large systems" that use SPF. etc, etc
> 
> Sorry, it's not my job to do your homework.  You can get a pretty good 
> idea of whether a system uses SPF by seeing it if publishes SPF records 
> (the TXT records mail systems actually use, not the type 99 they don't.) 
> I expect you can do that better than I can.  I'll be pretty surprised if 
> you find a large system that doesn't other than Yahoo, who doesn't for 
> internal political reasons, but we know they check SPF since they do 
> queries for the records when you send them mail.

	Not my job to prove your unfounded assertions.

> >	John, your lack of crispness and accuracy suggest that you are 
> >	conflating
> >	any number of concepts.  While the number of messages surrounding 
> >	this
> >	topic is large, I am confident that your estimates are off by several
> >	orders of magnitude.
> 
> If you're saying that the author of RFC 6686 is lying about the data he 
> presents, including 400,000 domains that publish TXT SPF records and the 
> few thousand that publish type 99, I'll pass the message along.

	I'm saying that your claim of millions of messages is flawed.
	No as to the claims for RFC 6686, I'll be happy to take those numbers
	at face value. (but, yeah, pass my concerns along)
	402,000 domains using SPF is barely statistically relevent, considering
	there are over 350 million domains in existance.  just over 1%.

> >   If the SPF WG had actually read the DNS RFCs, they
> >   would have known about the formal advice regarding overloading TXT.
> >   Why did the WG reject this RFC?
> 
> As you would know if you had read the recent traffic in dnsxet and spfbis, 
> or looked at the spfbis charter, the WG is updating RFC 4408 and 
> documenting existing practice.  Nobody claims that it was a swell idea to 
> use unprefixed TXT records a decade ago, but unless you can provide us 
> with a time machine, there's nothing to be done about it now.

	apparently no one in the spfbis wg bothered to read http://tools.ietf.org/html/rfc5507
	and there is no time limit to the choice of a good idea v. a bad idea.
	a bad idea can and should be questioned at any time - there is no
	"its too late" arguemnt that should hold, particularly when there is
	roughly 1% penetration of the service against the number of existing domains.

> Despite what the fantasists in dnsext imagine, there is no chance 
> whatsoever of getting those hundreds of thousands of existing mail systems 
> to change the way they publish and check SPF data, particularly a change 
> that has less than no operational benefit.  (Don't argue unless you know 
> more people who run large mail systems than I do, and I meet pretty much 
> all of them at MAAWG meetings.)  The only recent changes I can think of 
> are that Yahoo used to check both TXT and type 99 and now only checks TXT, 
> and Micsosoft mail properties including Hotmail gave up on Sender ID and 
> just check SPF.

	my what a pessemistic/fatalistic attitude you have there.
	and again with your unsupported assertions.  

> >	To be clear - at this point I'd really like to see you document any
> >	formal study of the impact of SPF on the DNS.  From any credible 
> >	source.
> >	Anything.
> 
> The closest thing to a study is what's described in RFC 6686, and it 
> wasn't looking for effects on the DNS other than to observe in passing the 
> *fact* that in 2012, when it was published, a lot of DNS servers didn't 
> respond to type 99 requests at all (no NODATA, no NXDOMAIN, no nothing), 
> despite that being obviously, painfully wrong.  Again, if you don't 
> believe it, I'll be happy to let the author know you think he's lying.
> 
> Beyond that there is none.  No study, no effect.  Feel free to prove 
> otherwise.


	"No effect"???  You've just completely flipped from your original
	assertion back on May 3rd, "interpreting SPF records requires more 
	DNS queries than any other DNS application I know."  Which is it?

	I don't need to prove your assertions, I want some proof that your 
	assertions about the impact on the DNS are based on actual facts.

/bill
	
> 
> R's,
> John