Re: [spfbis] Proposed spf TXT record change

Mark Andrews <marka@isc.org> Thu, 11 February 2016 06:57 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 9EB601A9120 for <spfbis@ietfa.amsl.com>; Wed, 10 Feb 2016 22:57:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 Tdm0Nf3JKZGh for <spfbis@ietfa.amsl.com>; Wed, 10 Feb 2016 22:57:36 -0800 (PST)
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 372541A9124 for <spfbis@ietf.org>; Wed, 10 Feb 2016 22:57:36 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id E9EC21FCB11; Thu, 11 Feb 2016 06:57:32 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C00F816004B; Thu, 11 Feb 2016 06:57:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AE23616005C; Thu, 11 Feb 2016 06:57:31 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JwpXpg6f8Q-1; Thu, 11 Feb 2016 06:57:31 +0000 (UTC)
Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id 632A816004B; Thu, 11 Feb 2016 06:57:31 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8775E41E14C4; Thu, 11 Feb 2016 17:57:29 +1100 (EST)
To: "Murray S. Kucherawy" <superuser@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <56BA775B.9050109@ragged-software.com> <20160210003605.9A90F41C28F6@rock.dv.isc.org> <CAL0qLwZWaWbkfOpjceXcr0EYsQARjkjJsFWy3dDA0QS_V+J6pA@mail.gmail.com>
In-reply-to: Your message of "Wed, 10 Feb 2016 20:49:21 -0800." <CAL0qLwZWaWbkfOpjceXcr0EYsQARjkjJsFWy3dDA0QS_V+J6pA@mail.gmail.com>
Date: Thu, 11 Feb 2016 17:57:29 +1100
Message-Id: <20160211065729.8775E41E14C4@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/spfbis/VyLc0Vdv9NBilRTw08qIDV6wbS0>
Cc: "Roy A. Gilmore" <rag@ragged-software.com>, "spfbis@ietf.org" <spfbis@ietf.org>
Subject: Re: [spfbis] Proposed spf TXT record change
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 11 Feb 2016 06:57:37 -0000

In message <CAL0qLwZWaWbkfOpjceXcr0EYsQARjkjJsFWy3dDA0QS_V+J6pA@mail.gmail.com>;, "Murray S. Kucherawy" writes:
> --001a11437e362be933052b7746bc
> Content-Type: text/plain; charset=UTF-8
> 
> On Tue, Feb 9, 2016 at 4:36 PM, Mark Andrews <marka@isc.org>; wrote:
> 
> > This group won't allow the double query and will introduce spurious
> > interoperablity arguments.  See the history of the SPF record type
> > which if the group hadn't abandoned would be well on the way to
> > being done by now as they abandoned the process just as the libraries
> > using the new code point were being deployed.
> 
> 
> I am mystified that the bitterness on this topic remains impervious to
> things like evidence.
 
Basically because the experiment's terms of reference appeared to
change.  I doubt anyone in the DNS community thought it was going
to be "can we migrate a established base to a new code point in a
couple of years" when the experiment was "a examination of whether
Sender ID or SPF was the best model".  The code point being used
for SPF was irrelevent to the examination of Sender ID vs SPF.

The DNS community was worried about getting to the right point for
the DNS in the end if SPF won the experiment.  If we thought we
were in a experiment to move the code point in a couple of years
lots of things would have been done differently.

The evidence actually showed the transition was on track.  Nameservers
support SPF were deployed.  Libraries supporting SPF as well as TXT
were being deployed.  None of this is captured in RFC6686.  But hey
lets look at records that have been entered at the begin of what
was expected to be a long transition process and declare defeat.

Mark

> The history of the SPF record type is documented in RFC6686.   I'm happy to
> let that document and the data it contains speak for itself.
> 
> I also contend that the record shows that the working group and the
> community made an informed decision.
> 
> -MSK
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org