Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 21 August 2013 04:00 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A2611E8388 for <ietf@ietfa.amsl.com>; Tue, 20 Aug 2013 21:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.84
X-Spam-Level:
X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgj4uvWZNa1V for <ietf@ietfa.amsl.com>; Tue, 20 Aug 2013 21:00:06 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2921411E8384 for <ietf@ietf.org>; Tue, 20 Aug 2013 21:00:06 -0700 (PDT)
Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id A0E8F8A031 for <ietf@ietf.org>; Wed, 21 Aug 2013 04:00:05 +0000 (UTC)
Date: Wed, 21 Aug 2013 00:00:04 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: ietf@ietf.org
Subject: Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Message-ID: <20130821040003.GL607@mx1.yitter.info>
References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <B443E973-858A-4958-964B-B0F0FBDF5A7A@virtualized.org> <CAMm+LwhcHOeUv0iqZmZ6wX-jOD1r-mRR0x8sbxaKrsU3k4CNBQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMm+LwhcHOeUv0iqZmZ6wX-jOD1r-mRR0x8sbxaKrsU3k4CNBQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2013 04:00:12 -0000

No hat.

On Tue, Aug 20, 2013 at 05:16:56PM -0400, Phillip Hallam-Baker wrote:
> >From a pure protocol point of view the SPF record does have one major
> advantage over TXT and that is in the use of wildcard records.

This is an extremely interesting point, and I'm ashamed to admit I
hadn't really thought about it from quite this perspective.  I say
that even though the draft contains some text that attempts to deal
with wildcards and the WG discussed the issue from a slightly
different perspective.  I think it is worth considering.  Note,
however, that …

> This has not been much of a problem because most of the other TXT overloads
> don't have a use for a wildcard. There is not much point in a wildcard DANE
> record. But it could be an issue.

…it wouldn't be an issue for most of the cases where TXT is
overloaded, because (partly due to the mess that SPF caused) most of
the TXT overloads we see are now scoped using underscore labels, where
the wildcard at a superordinate place in the FQDN isn't going to
matter.  Phill's is still a valuable observation, and one I think the
WG actually didn't consider in every dimension.
 
> The criteria to use to decide is not the proportion of SPF records
> published as TXT vs SPF but what the validators look for. 

The WG had a hard time coming up with really good data about what
validators look for, but to the extent we were able to draw
conclusions about that the evidence was that virtually nobody is
looking for SPF records.  This is mentioned at the end of section 3.1
of RFC 6686.  If someone else with some busy nameservers wants to
provide different evidence now, it wouldn't hurt.  We were unable to
find anyone among the participating validators in the SPFBIS WG who
was willing to argue in public that they felt the SPF lookup was more
valuable to them, but we did have some large participants who said
they did _not_ do the TYPE99 lookup except under unusual circumstances
(the draft author, who is also the maintainer of an important SPF
library, has already made this point elsewhere in this thread).

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com