Re: [spfbis] Proof of non-deployment [root@primary.se: Cron <root@primary> /usr/local/libexec/spf-txt.sh]

Mark Andrews <marka@isc.org> Tue, 07 October 2014 21:27 UTC

Return-Path: <marka@isc.org>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C291A8868 for <spfbis@ietfa.amsl.com>; Tue, 7 Oct 2014 14:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.687
X-Spam-Level:
X-Spam-Status: No, score=-7.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StH8bA_zHkGk for <spfbis@ietfa.amsl.com>; Tue, 7 Oct 2014 14:27:06 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C191A886A for <spfbis@ietf.org>; Tue, 7 Oct 2014 14:27:06 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 961161FCAA0; Tue, 7 Oct 2014 21:27:02 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2A459160068; Tue, 7 Oct 2014 21:30:02 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id E80E716005A; Tue, 7 Oct 2014 21:30:01 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DB75220DE476; Wed, 8 Oct 2014 08:26:57 +1100 (EST)
To: Andrew Sullivan <ajs@anvilwalrusden.com>
From: Mark Andrews <marka@isc.org>
References: <20141007063737.GA28581@besserwisser.org> <D6213AB4-ABB2-45C5-AA52-59369B03B88F@anvilwalrusden.com> <CAL0qLwYpA_snEkjnCeXFcxf6kzt-8rF1+Uovypn1yNe+5VVB+w@mail.gmail.com> <20141007164221.GF19697@mx1.yitter.info>
In-reply-to: Your message of "Tue, 07 Oct 2014 12:42:21 -0400." <20141007164221.GF19697@mx1.yitter.info>
Date: Wed, 08 Oct 2014 08:26:57 +1100
Message-Id: <20141007212657.DB75220DE476@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/2tBYv31sLPeJuBzGtitBiLoVzT8
Cc: spfbis@ietf.org
Subject: Re: [spfbis] Proof of non-deployment [root@primary.se: Cron <root@primary> /usr/local/libexec/spf-txt.sh]
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spfbis/>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Oct 2014 21:27:17 -0000

In message <20141007164221.GF19697@mx1.yitter.info>, Andrew Sullivan writes:
> On Tue, Oct 07, 2014 at 09:15:49AM -0700, Murray S. Kucherawy wrote:
> > 
> > Given the survey work recorded in RFC6686, I would be curious to hear
> > people's theories explaining the substantial uptick of TYPE99 queries in
> > the last two years while the industry has actually gone in the opposite
> > direction.  Of course, that presumes there's ample breadth and no bias in
> > the traffic seen by this one resolver.
> 
> We had methodological issues at the time of RFC 6686, too, so I think
> we ought to be careful about speculating too much.
> 
> But I seem to recall someone telling us, right around the time of
> 6686, that some new SPF checking code had just shipped that used
> TYPE99 as the default.  This news came too late in the publication
> cycle to change the text.  But it shouldn't be surprising that we see
> this now.

The working group got told repeatedly that they just had to wait
as new code went from being written to being deployed.  They got
given data that showed type spf queries were increasing.  They just
refused to listen and used the stupid excuse of type txt not "working"
with type spf to claim that they had to abandon the transition.

There was plenty of time to change the decision but they refused
to listen.

Transitions like this take about a decade and they abandoned the
transition early.
 
> None of that matters, however, because the original RFC had that
> interoperability bug in it, and the only reasonable thing to do was to
> pick one type to look up.  I'm unhappy about using TXT, too, and
> registered that unhappiness at the time.  But the deployed code is a
> strong argument.

When you jump to the end state of SPF only, of course it won't work
with TXT.  However there was nothing wrong with that.  Also there
was nothing preventing people publishing both types if they wanted
to during the transition.  There was nothing preventing the transition
continuing.

The real reason that most of the working group didn't want to move
from TXT and resented that DNS people said use a seperate type for
this and resisted changing things.

> A
> 
> -- 
> Andrew Sullivan
> ajs@anvilwalrusden.com
> 
> _______________________________________________
> spfbis mailing list
> spfbis@ietf.org
> https://www.ietf.org/mailman/listinfo/spfbis
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org