Re: [spfbis] Proposed spf TXT record change

"Stuart D. Gathman" <stuart@gathman.org> Wed, 10 February 2016 19:32 UTC

Return-Path: <SRS0=52O0n=OJ==stuart@gathman.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 6745A1B2EFF for <spfbis@ietfa.amsl.com>; Wed, 10 Feb 2016 11:32:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 hofUR5wKaUZu for <spfbis@ietfa.amsl.com>; Wed, 10 Feb 2016 11:32:58 -0800 (PST)
Received: from mail.gathman.org (mail.gathman.org [IPv6:2001:470:5:c85::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1406B1B2EC5 for <spfbis@ietf.org>; Wed, 10 Feb 2016 11:32:57 -0800 (PST)
Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1455132776; h=Date : From : To : cc : Subject : In-Reply-To : Message-ID : References : MIME-Version : Content-Type : Date : From : Subject; bh=d60K+RClSn10EjKQ1Zr9V9jn8PhkaqZ2Y+L2SMCM7R8=; b=d3BeaDkkIDkD8/291AkE+P0uTg5inrgbZcMEei57U6DUjg3oqnUAr902j0qq6/LkFopLRN 5J8BPuDZsxEcbwe9A0802oc4Vr7X6Qss3/o6oelbyakLUiYZaBiljfpp+Pcf+cBCaq2V0NqW thXJeGdpdwop4K9OmaJsN6DurgeIk=
Received: from sdgathman-1-pt.tunnel.tserv13.ash1.ipv6.he.net (sdgathman-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:809::2] (may be forged)) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id u1AJWoJU016618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Feb 2016 14:32:55 -0500
Date: Wed, 10 Feb 2016 14:32:50 -0500 (EST)
From: "Stuart D. Gathman" <stuart@gathman.org>
To: "Roy A. Gilmore" <rag@ragged-software.com>
In-Reply-To: <56BAB3D8.8060607@ragged-software.com>
Message-ID: <alpine.LRH.2.20.1602101428440.13845@fairfax.gathman.org>
References: <20160210022525.98482.qmail@ary.lan> <56BAB3D8.8060607@ragged-software.com>
User-Agent: Alpine 2.20 (LRH 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <http://mailarchive.ietf.org/arch/msg/spfbis/mDjAYEIKt_Kn0Xosy8GMlDlo4Vo>
Cc: 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: Wed, 10 Feb 2016 19:32:59 -0000

On Tue, 9 Feb 2016, Roy A. Gilmore wrote:

> Why should it matter if I'm a decade too late? If I'm right (and I'm not
> saying that I am), why shouldn't the behavior be changed. RFC's aren't
> set in stone, they are updated and/or obsoleted all the time. This
> proposed change is trivial to implement.

As a pyspf developer, the _spf idea is *not* trivial to implement. 
The SPF RR is trivial to implement.  The problem was braindead DNS
servers.

I still publish both SPF and TXT records (no SPF police are stopping
me).  I still have the type99 code in my SPF implementation.
Type99 is only deprecated.  If you can convince DNS server providers
to operate correctly for unknown RR types (or failing that, to
recognize SPF RR), and convince lots of people to publish both,
then a switch could be reconsidered.  Especially if there is a new
backward incompatible SPF version.