Re: [spfbis] Proposed spf TXT record change

"Stuart D. Gathman" <stuart@gathman.org> Wed, 10 February 2016 01:17 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 7E9011B34C4 for <spfbis@ietfa.amsl.com>; Tue, 9 Feb 2016 17:17:44 -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 emaIJ18kaXuA for <spfbis@ietfa.amsl.com>; Tue, 9 Feb 2016 17:17:42 -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 4ED451AD2D5 for <spfbis@ietf.org>; Tue, 9 Feb 2016 17:17:40 -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=1455067057; h=Date : From : To : cc : Subject : In-Reply-To : Message-ID : References : MIME-Version : Content-Type : Date : From : Subject; bh=jy+VgGzFkQFkF+kh22+hz3uCyGipToiC/32A3FANmAM=; b=OS+NfDk+bDvKQZJsEsi/Ztr9o6ftVtqQ0jU2pCVd6rA2XvdSnfX+9u1mKkBQg5m0TLBKs4 eD0dI6irWHRF96Np2U5CuqvL7AllZkPwKojhOyRHg/4bUPjDqwoh78c+1dXhLUXxGaKRzIVT ckbAwlLagcsDXGhhcrYtkSpztJqoY=
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 u1A1HQjd013651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Feb 2016 20:17:36 -0500
Date: Tue, 9 Feb 2016 20:17:26 -0500 (EST)
From: "Stuart D. Gathman" <stuart@gathman.org>
To: Mark Andrews <marka@isc.org>
In-Reply-To: <20160210003605.9A90F41C28F6@rock.dv.isc.org>
Message-ID: <alpine.LRH.2.20.1602092013070.4286@fairfax.gathman.org>
References: <56BA775B.9050109@ragged-software.com> <20160210003605.9A90F41C28F6@rock.dv.isc.org>
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/YT2eYxmbK2epEwvdoLMaHUUOYpo>
Cc: "Roy A. Gilmore" <rag@ragged-software.com>, 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 01:17:44 -0000

On Wed, 10 Feb 2016, Mark Andrews wrote:

> In message <56BA775B.9050109@ragged-software.com>;, "Roy A. Gilmore" writes:
>> somebody could point me in the right direction. I think placing the spf
>> information in a TXT record directly attached to the domain is a
>> mistake. I think the spf information should be placed in a TXT record
>> attached to a _spf selector (e.g. _spf.example.com). This behavior
>
> 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.

The big problem with the SPF record type was certain common DNS servers
that would completely ignore (read TIMEOUT) queries for an RR type they
didn't know about (instead of returning NXDOMAIN).

The _spf subdomain would not have that problem, and so would have some
legs for another try.  But I think having been burned by the SPF record
type, no one is anxious to try.