Re: [spfbis] Proposed spf TXT record change

Scott Kitterman <> Thu, 11 February 2016 23:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5C8331B3C8D for <>; Thu, 11 Feb 2016 15:43:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.602
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EaUafYDMBb6S for <>; Thu, 11 Feb 2016 15:42:55 -0800 (PST)
Received: from ( [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 96B901B3C7E for <>; Thu, 11 Feb 2016 15:42:55 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 2C3CDC40159 for <>; Thu, 11 Feb 2016 17:42:54 -0600 (CST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; 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: <>
References: <20160210022525.98482.qmail@ary.lan> <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: Scott Kitterman <>
Date: Thu, 11 Feb 2016 18:42:48 -0500
Message-ID: <>
Archived-At: <>
Subject: Re: [spfbis] Proposed spf TXT record change
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SPFbis discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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" <>; 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
>> saying that I am), why shouldn't the behavior be changed. RFC's
>> 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
>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