Re: [spfbis] Proposed spf TXT record change
"Roy A. Gilmore" <rag@ragged-software.com> Wed, 10 February 2016 03:24 UTC
Return-Path: <rag@ragged-software.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 4A7051B3623 for <spfbis@ietfa.amsl.com>; Tue, 9 Feb 2016 19:24:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 OE0d_M9gBPFH for <spfbis@ietfa.amsl.com>; Tue, 9 Feb 2016 19:24:37 -0800 (PST)
Received: from atl4mhob20.myregisteredsite.com (atl4mhob20.registeredsite.com [209.17.115.114]) by ietfa.amsl.com (Postfix) with ESMTP id E54F81B3624 for <spfbis@ietf.org>; Tue, 9 Feb 2016 19:24:36 -0800 (PST)
Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob20.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u1A3OYeQ032035 for <spfbis@ietf.org>; Tue, 9 Feb 2016 22:24:34 -0500
Received: (qmail 32700 invoked by uid 0); 10 Feb 2016 03:24:34 -0000
X-TCPREMOTEIP: 107.209.217.9
X-Authenticated-UID: rag@ragged-software.com
Received: from unknown (HELO thor.internal.ragged-software.com) (rag@ragged-software.com@107.209.217.9) by 0 with ESMTPA; 10 Feb 2016 03:24:33 -0000
To: spfbis@ietf.org
References: <56BA775B.9050109@ragged-software.com> <20160210003605.9A90F41C28F6@rock.dv.isc.org>
From: "Roy A. Gilmore" <rag@ragged-software.com>
X-Enigmail-Draft-Status: N1110
Organization: RAGged Software
Message-ID: <56BAAD71.8080009@ragged-software.com>
Date: Tue, 09 Feb 2016 19:24:33 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <20160210003605.9A90F41C28F6@rock.dv.isc.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/spfbis/8A7JDRo0ZIN25txqzOEH0ce-MB8>
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 03:24:39 -0000
I hope I don't come across as argumentative, that is not my intention. I don't have any idea how these workgroups work. I'm curious about a behavior that I THINK (I could be wrong) is incorrect with spf, and trying to learn, so I'm asking what I think are good questions. Double query? What if a single domain query returns multiple TXT records. How long will it take to process multiple free form (i.e. RFC 1035: "The semantics of the text depends on the domain where it is found.") TXT records to be sure you select the right one? Can you be sure you selected the right one? If you query for a _spf TXT record, you know you got the right one (well, I guess in the degenerate case where DNS has been misconfigured, you could get multiple TXT records). I suppose someone could say that only one TXT record should be returned. RFC 1035 doesn't say whether TXT is a singleton resource record or not. But, RFC 1035 has been updated by so many RFC's and BCP's that I'm not sure (I'll have to look into that). I know bind allows multiple TXT records per key (I'm not sure if "key" is the correct terminology here). Anyway, assume for a minute that only one TXT record should to be returned, should spfbis hijack that TXT record? I don't think so. What about all the other services that query for a service specific TXT record, are their workgroups "wrong", and the spfbis workgroup "right"? I'd willing to bet the other workgroups have some pretty smart people too (probably some of the same smart people). The double query argument was used with SRV records (RFC 2782) not allowing CNAMEs for targets, which effectively made the whole point of CNAMEs useless. If I have a CNAME record pointing to a LDAP server, and I replace the LDAP server, instead of just changing the CNAME record, I have to change all the SRV records too, so why even bother with a CNAME in the first place (rhetorical, don't bother answering)? I suppose it doesn't really matter, does anybody actually use SRV records on the internet (rhetorical again, bordering on sarcasm)? SRV records seem to be used mainly on intranets, particularly ones with Microsoft Active Directory Domains where a lot of the SRV record configuration happens "under the hood" with little human input. As to spurious interoperablity arguments, that's easy, set a transition period where either record is acceptable with a preference for the _spf TXT record (i.e. query for the _spf TXT record first, and fall back to the domain TXT record if the _spf TXT record doesn't exist). Maybe, even a "double" transition period where in the first transition period the domain TXT record was the preferred record. POP3 didn't replace POP2 overnight. And IMAP4 still hasn't replaced POP3 even though it has many advantages. Sorry about being so long winded. I'll try to be more concise in the future. On 02/09/2016 04:36 PM, Mark Andrews wrote: > In message <56BA775B.9050109@ragged-software.com>, "Roy A. Gilmore" writes: >> I'm not sure how to go about this, but, I'll start here and maybe >> 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 >> already has a history of being used by other services (i.e. >> _kerberos.example.com, _dmarc.example.com, etc.), and would make >> retrieving the spf information much easier and much more robust. This >> would also be a trivial change to implement. Any thoughts? > 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. > >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis
- Re: [spfbis] Proposed spf TXT record change Scott Kitterman
- [spfbis] Proposed spf TXT record change Roy A. Gilmore
- Re: [spfbis] Proposed spf TXT record change Mark Andrews
- Re: [spfbis] Proposed spf TXT record change Stuart D. Gathman
- Re: [spfbis] Proposed spf TXT record change John Levine
- Re: [spfbis] Proposed spf TXT record change Roy A. Gilmore
- Re: [spfbis] Proposed spf TXT record change John Levine
- Re: [spfbis] Proposed spf TXT record change John Levine
- Re: [spfbis] Proposed spf TXT record change Roy A. Gilmore
- Re: [spfbis] Proposed spf TXT record change Roy A. Gilmore
- Re: [spfbis] Proposed spf TXT record change Dotzero
- Re: [spfbis] Proposed spf TXT record change Mark Andrews
- Re: [spfbis] Proposed spf TXT record change Dave Crocker
- Re: [spfbis] Proposed spf TXT record change Mark Andrews
- Re: [spfbis] Proposed spf TXT record change John Levine
- Re: [spfbis] Proposed spf TXT record change William Leibzon
- Re: [spfbis] Proposed spf TXT record change Stuart D. Gathman
- Re: [spfbis] Proposed spf TXT record change Stuart D. Gathman
- Re: [spfbis] Proposed spf TXT record change Mark Andrews
- Re: [spfbis] Proposed spf TXT record change Murray S. Kucherawy
- Re: [spfbis] Proposed spf TXT record change Murray S. Kucherawy
- Re: [spfbis] Proposed spf TXT record change Murray S. Kucherawy
- Re: [spfbis] Proposed spf TXT record change Mark Andrews
- Re: [spfbis] Proposed spf TXT record change Murray S. Kucherawy
- Re: [spfbis] Proposed spf TXT record change Dotzero
- Re: [spfbis] Proposed spf TXT record change John Levine
- Re: [spfbis] Proposed spf TXT record change Hector Santos
- Re: [spfbis] Proposed spf TXT record change Alessandro Vesely
- Re: [spfbis] Proposed spf TXT record change Frank Ellermann