Re: [apps-discuss] Updating the status of SPF

Scott Kitterman <scott@kitterman.com> Thu, 11 August 2011 22:06 UTC

Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A3E11E8091 for <apps-discuss@ietfa.amsl.com>; Thu, 11 Aug 2011 15:06:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 VrDgkAMx3S6t for <apps-discuss@ietfa.amsl.com>; Thu, 11 Aug 2011 15:06:33 -0700 (PDT)
Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id C63C011E808E for <apps-discuss@ietf.org>; Thu, 11 Aug 2011 15:06:33 -0700 (PDT)
Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 7F44C38C131; Thu, 11 Aug 2011 18:07:07 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1313100427; bh=WnOpvXEAChduYENOfIGWzObnA0fens3No8BSJ32vgwo=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=SyHtHOTZLWwIgn9NzN4/HKfhhOwfZtGlecFdVPdZb1WorSFtmoCLhUdoLEywnc1eV FBf6A1wl34Rlmkqah5YxPO9N2Q47wmXgWpWO3mIs804lVgSiA2dak8OYODjeE1z9dr EqwrxF7GzZvCUQV/Bz7HZ0o27EK9JYZgCZyIy2sM=
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Thu, 11 Aug 2011 18:07:04 -0400
User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; )
References: <201108092337.39408.scott@kitterman.com> <CAHhFybp3K8HQU7gmDqpQmv+HLiSy+J4EoEb=gTCwt3wZi6jgWA@mail.gmail.com> <20110811213626.GU95640@shinkuro.com>
In-Reply-To: <20110811213626.GU95640@shinkuro.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201108111807.05405.scott@kitterman.com>
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] Updating the status of SPF
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Aug 2011 22:06:34 -0000

On Thursday, August 11, 2011 05:36:26 PM Andrew Sullivan wrote:
> On Thu, Aug 11, 2011 at 11:19:06PM +0200, Frank Ellermann wrote:
> > If you insist on it the WG should IMHO still be free to say whatever
> > it likes to say about the type 99 DNS SPF RR; maybe kill it for good.
> 
> The plain fact is that once a DNS RRTYPE is allocated, it can't be
> "killed".  You can deprecate its use and tell new software not to look
> it up.  But the code point will remain assigned, I predict, until we
> stop using the DNS (which, at the rate we are adding lard to spackle
> to baling-wire, might be any day now, but that's a digression for
> another list).
> 
> For the little it us no doubt worth, it is the "TXT is now used
> everywhere, and so we're not going to deprecate that even in new
> versions of the protocol, pppptttthhht" argument that annoys people
> who see the problems with TXT records whenever they're overloaded in
> yet another protocol.  In effect, once you adopt TXT, you're going to
> use it forever.  This same attitude is why we still have A-record MX
> fallback all these years later.
> 
> But I do agree that, if people are wedded to using their bad idea
> forever, one isn't going to change their mind, and it is silly to have
> two mechanisms for achieving the same goal one of which is never used
> (particularly if it causes additional DNS load).

I feel strongly that the 4408bis effort we are discussing now should be a 
minimal/backwards compatible_unless_it_is_impossible update.  Once that is 
complete there is a backlog of incompatible design ideas for simplifying and 
improving SPF.  In that context I think moving to Type SPF only makes a lot of 
sense and should be considered.  I don't want to get that mixed in with the 
current effort.

I, for one, am certainly not wedded to the idea of using TXT forever.

Scott K