Re: [spfbis] Proposed spf TXT record change

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 11 February 2016 05:26 UTC

Return-Path: <superuser@gmail.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 501571A8F4B for <spfbis@ietfa.amsl.com>; Wed, 10 Feb 2016 21:26:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 fluFMCI3hgmw for <spfbis@ietfa.amsl.com>; Wed, 10 Feb 2016 21:26:45 -0800 (PST)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B111A8F45 for <spfbis@ietf.org>; Wed, 10 Feb 2016 21:26:44 -0800 (PST)
Received: by mail-vk0-x232.google.com with SMTP id e6so29292867vkh.2 for <spfbis@ietf.org>; Wed, 10 Feb 2016 21:26:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cKatrB9FoPJT6hpZcMEgRQdsut62BJyREC3RciYjMWk=; b=NII+TaGOT7oM5mYVdYimf9tlfolUr8w9mHJGOx+2a5+KyUYG+z63cDlXyFSM8R2+ND 3I2Z6bF356vmPCqo/NOO8yGjl2NSvG8mwWAOWz4t1ZkR3SBN8mnCPRa9PVqXibd1hiz8 9HeKvJs+dGhf5iF4tqSDKKFQjHC6l3my104wZhu1iWMzeoP4ZTARhcUlI/gRLhfVAJfD Li7NidOITrVFaFpLk9ti8WB2QrLkqvjyI1l0Z9ibojU1fYO6iHuCoTMj7RaWSmT5lwxg Jcsq3vy+cQA/5GCikf0yx0vqPo293vXTrE4ohsgU+ggt5Dopdh6lwbH477Kyjd+pIGPu UViw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cKatrB9FoPJT6hpZcMEgRQdsut62BJyREC3RciYjMWk=; b=RmeQkVVkiaWa3zTJV+SiB9ed2dLKwQPmfgK6/cPt6VH+F7fnFqTGXsJpRcccFrK5Zm VFjMbxKMRdWYg9JdHvdAyhcCyYfnH0Vwt2DQzdvrJsur2ojlbDBpGv4JxNg6deTc1hPQ 65aK/U58gVdZLPqN8k5cq6Guyu6JZ1TWVmsXZUruJhNGv/CecP1EK6AmmqQWNymAOKRj 6f4o2J5aCDyERnf+IGegomkFgKe/KuD6ywLgLUGt+Zgwqfsm8cZJrdsREjnnyg2HkSUD ywCvE8p43+WLHVnSyvOsFMcMwdGDTVqGh4Y3ssIYZccICn/DJlw22MocKsAEbDVs+V4B NVcA==
X-Gm-Message-State: AG10YOQuOBxJzQ4nDJDRDStaqi2xLBE55sccacHJgIAYY0UfnGIS00vjXfIQVFZSP90uKHuQujhy6nbUORF7jw==
MIME-Version: 1.0
X-Received: by 10.31.52.147 with SMTP id b141mr33556217vka.82.1455168403733; Wed, 10 Feb 2016 21:26:43 -0800 (PST)
Received: by 10.103.72.195 with HTTP; Wed, 10 Feb 2016 21:26:43 -0800 (PST)
In-Reply-To: <56BAAD71.8080009@ragged-software.com>
References: <56BA775B.9050109@ragged-software.com> <20160210003605.9A90F41C28F6@rock.dv.isc.org> <56BAAD71.8080009@ragged-software.com>
Date: Wed, 10 Feb 2016 21:26:43 -0800
Message-ID: <CAL0qLwZEd2xZYNY9qmHjNSmO-K-78BQBsbsCzCGreyGbSdE2Xw@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: "Roy A. Gilmore" <rag@ragged-software.com>
Content-Type: multipart/alternative; boundary="001a1143f846cb00e1052b77cb5c"
Archived-At: <http://mailarchive.ietf.org/arch/msg/spfbis/aXAqD_nBoRFAdE0ROGibqY6OImM>
Cc: "spfbis@ietf.org" <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: Thu, 11 Feb 2016 05:26:47 -0000

On Tue, Feb 9, 2016 at 7:24 PM, Roy A. Gilmore <rag@ragged-software.com>
wrote:

> Double query? What if a single domain query returns multiple TXT
> records.


Section 4.5 of RFC7208 covers that.


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


I don't think processing time is the concern here.


> Can you be
> sure you selected the right one?


Yes, because after discarding things that aren't SPF records, you evaluate
what's left: if there's none, you get a "none" result; if one, you get the
real result; if more, you get an error.


> 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 don't know that wildcard TXT records constitute a "degenerate" case.


> 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 rules for handling the DNS reply in RFC7208 cover all of these
possibilities, I believe.  They have to, given how much random stuff one
finds in the domain-level TXT reply sometimes.  Query for the TXT of "ut.edu",
for example.  And that's a bunch cleaner than what I found when I did the
RFC6686 surveys.  I found some that had valid SPF records mixed in with
junk like that.

SPF isn't making a claim to the domain level TXT record.  That's just where
it landed (again, see RFC6686 for the history), and it can easily coexist
with other things.

The spfbis archive, going back to early 2013 at least, documents the
extensive discussions we had on how we got here and why we should never do
it again, but fixing it now is simply not pragmatic.

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

Sure, transition periods could work if everyone is on board with making the
change.  Selling that is the challenge.

What problem are you really trying to solve here?

-MSK