Re: [spfbis] Proposed spf TXT record change

Alessandro Vesely <vesely@tana.it> Fri, 12 February 2016 10:16 UTC

Return-Path: <vesely@tana.it>
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 1D4131B42D2 for <spfbis@ietfa.amsl.com>; Fri, 12 Feb 2016 02:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.423
X-Spam-Level:
X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, 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 Zwg64rNOQCca for <spfbis@ietfa.amsl.com>; Fri, 12 Feb 2016 02:16:52 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1421B42D3 for <spfbis@ietf.org>; Fri, 12 Feb 2016 02:16:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1455272207; bh=RYV3W0igBero/950l+WCY7swHJrN6kcOO3tf440Vgv8=; l=1883; h=To:References:From:Date:In-Reply-To; b=H+QCu/J0us34B807PrYKv8JWbF2XNJxnopNQ9uLpMgbU/G2dn7BjoI6XFNJ7CGP6s xlgyA9+XtG3H2pkazWZPOo8qStXzk7xTl5ejVY519iDqv0EFeImFBzgzvNSEkuT2cE W4CNXy6fFi+OjA8JnJvTbtM0FPASSkUFleJq+R2Q=
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 12 Feb 2016 11:16:47 +0100 id 00000000005DC050.0000000056BDB10F.0000269F
To: spfbis@ietf.org
References: <20160210022525.98482.qmail@ary.lan> <56BAB3D8.8060607@ragged-software.com> <alpine.LRH.2.20.1602101428440.13845@fairfax.gathman.org> <E2B1CA13-E4F6-4BB0-92D0-A2C536B8B6DD@kitterman.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <56BDB10F.4070701@tana.it>
Date: Fri, 12 Feb 2016 11:16:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0
MIME-Version: 1.0
In-Reply-To: <E2B1CA13-E4F6-4BB0-92D0-A2C536B8B6DD@kitterman.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/spfbis/CPLviCmTT6wxCo008S7jIpIR6ow>
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: Fri, 12 Feb 2016 10:16:54 -0000

On Fri 12/Feb/2016 00:42:48 +0100 Scott Kitterman wrote:
> 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.
>>
>> As a pyspf developer, the _spf idea is *not* trivial to implement. The SPF
>> RR is trivial to implement.
>>
>> 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)

Those considerations don't have to be simultaneously valid for both the binary
on-the-wire format and the format used for declarations.  Records could be
compiled from high level directives.

> 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.

Whenever such an incompatible update will be needed, that is.  Paraphrasing
Roy, why should it matter if it will not arise within a decade?

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

One doesn't preclude another.  Possibly related to _spf, looking up helo
records by administrative domain --à la DMARC-- would greatly simplify deployment.

Ale