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, 9 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