Re: [dnsext] SPF, a cautionary tale

bmanning@vacation.karoshi.com Mon, 06 May 2013 12:58 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 B0D3621F8F87 for <dnsext@ietfa.amsl.com>; Mon, 6 May 2013 05:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.389
X-Spam-Level:
X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=-0.105, 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 dSZxIOjQ-kTJ for <dnsext@ietfa.amsl.com>; Mon, 6 May 2013 05:58:36 -0700 (PDT)
Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3862D21F8F24 for <dnsext@ietf.org>; Mon, 6 May 2013 05:58:36 -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 r46CwTFo013465; Mon, 6 May 2013 12:58:29 GMT
Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r46CwS8f013463; Mon, 6 May 2013 12:58:28 GMT
Date: Mon, 06 May 2013 12:58:23 +0000
From: bmanning@vacation.karoshi.com
To: "Murray S. Kucherawy" <superuser@gmail.com>
Message-ID: <20130506125823.GA13430@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> <51861e2f.62a3420a.11ed.ffffc5c1SMTPIN_ADDED_BROKEN@mx.google.com> <CAL0qLwY2t3Hgb85yOuqhNLRW5rcZkMt5dKNoWnLmSkKES391Ug@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAL0qLwY2t3Hgb85yOuqhNLRW5rcZkMt5dKNoWnLmSkKES391Ug@mail.gmail.com>
User-Agent: Mutt/1.4.1i
Cc: bmanning@vacation.karoshi.com, "dnsext@ietf.org Group" <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: Mon, 06 May 2013 12:58:50 -0000

On Sun, May 05, 2013 at 05:34:00PM -0700, Murray S. Kucherawy wrote:
> On Sun, May 5, 2013 at 1:53 AM, <bmanning@vacation.karoshi.com> wrote:
> 
> > > 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%.
> >
> 
> Isn't "domains that appear to be sending mail" a more useful universe from
> which to sample than "registered domains"?


	Probably - but I was following Johns usage.


> 
>         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.
> >
> 
> I'm an existence proof that your claim is false.  I've read RFC5507 and I'm
> familiar with its contents.  I've already said that, were we writing this
> anew, I think we'd likely be taking a different path here, one that would
> make the members of dnsext much happier.  But since the former is false,
> and there's a substantial deployed base much of which is unlikely to change
> its behaviour for various reasons, we have to look at this a different way.


	there is this wonderful thing called "O'Dells Law" which, paraphrased
	is:  "The installed based doesn't matter".   However, there is nothing
	preventing the SPF community from using TXT to store thier particularly
	unique stuff.  But there can be zero whining when other folks use TXT for
	their own purposes and confuse the heck out of SPF processors which get 
	(for thier purposes) malformed SPF data...

> > > 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.
> 
> His pessimism is founded in reality.  I have similar contact with the same
> people, and I reach the same conclusion.

	Sounds very much like the folks who hijacked net 1.0.0.0/8 for their
	wireless/NAT space.  (Or pretty much anyone who has "borrowed" IP space
	because it was too hard to get/justify the space properly.)  They have no
	incentive to change their installed base...  except for interoperability
	problems.

/bill

> 
> -MSK