Re: [spfbis] Proposed spf TXT record change

Scott Kitterman <spf2@kitterman.com> Thu, 11 February 2016 23:43 UTC

Return-Path: <spf2@kitterman.com>
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 5C8331B3C8D for <spfbis@ietfa.amsl.com>; Thu, 11 Feb 2016 15:43:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.602
X-Spam-Level:
X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 EaUafYDMBb6S for <spfbis@ietfa.amsl.com>; Thu, 11 Feb 2016 15:42:55 -0800 (PST)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B901B3C7E for <spfbis@ietf.org>; Thu, 11 Feb 2016 15:42:55 -0800 (PST)
Received: from [10.58.168.93] (unknown [166.170.28.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 2C3CDC40159 for <spfbis@ietf.org>; Thu, 11 Feb 2016 17:42:54 -0600 (CST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1455234174; bh=s7UWOWTxWI4HYCoUnehDS5LrM3w+PxFnmmoDY9wmJ90=; h=In-Reply-To:References:Subject:From:Date:To:From; b=rLDinXH/zq/dDODDZgeviDo+RqAdmCtVGNMIgAWdIc1yGeB1D3cyMauYoqgdlweK5 WcvRnRzj8X9k3+zH0W85I678YXcWhi9VDjkR+XYsdF3OSjp0RJE3l5DIVBdCgjDA/V IfwWMLcmfDPPgtkj59K7e659QUzKWkTfAiZr1BLk=
User-Agent: K-9 Mail for Android
In-Reply-To: <alpine.LRH.2.20.1602101428440.13845@fairfax.gathman.org>
References: <20160210022525.98482.qmail@ary.lan> <56BAB3D8.8060607@ragged-software.com> <alpine.LRH.2.20.1602101428440.13845@fairfax.gathman.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
From: Scott Kitterman <spf2@kitterman.com>
Date: Thu, 11 Feb 2016 18:42:48 -0500
To: spfbis@ietf.org
Message-ID: <E2B1CA13-E4F6-4BB0-92D0-A2C536B8B6DD@kitterman.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/spfbis/DOe-HAaLq2RTwpFZjJWrbLCe9Wg>
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 23:43:00 -0000


On February 10, 2016 2:32:50 PM EST, "Stuart D. Gathman" <stuart@gathman.org> wrote:
>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.

I think a backward incompatible update is exactly the right time to reintroduce use of the SPF RR.  I think I can even describe much of what an update should contain:

 - Combine a:, ip4:, and ip6: into a single mechanism (in retrospect there was no need to make them separate and combining would simplify things)

 - Drop the PTR mechanism entirely

 - Drop (or possibly radically simplify macros)

I personally doubt it would get a lot of deployment, but that kind of incompatible update is what the SPF RR type should be used for.

In any case, I think the new RR type is a better idea than _spf.

Scott K