IETF Logo Mail Archive

Re: [spfbis] Obsoleting SPF RRTYPE

Scott Kitterman <spf2@kitterman.com> Mon, 20 May 2013 05:12 UTC

Return-Path: <spf2@kitterman.com>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E3F21F8FF2 for <spfbis@ietfa.amsl.com>; Sun, 19 May 2013 22:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 qvADqvqPrQ7w for <spfbis@ietfa.amsl.com>; Sun, 19 May 2013 22:11:47 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D575F21F8FDD for <spfbis@ietf.org>; Sun, 19 May 2013 22:11:44 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E61E520E40D2; Mon, 20 May 2013 01:11:43 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369026703; bh=7wYnPhpUmmRP/RXTlLP/UeWn8U9XZ9aAqhrX+i/QWVE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CeFtE/+xPYt0clnhtph0VHfaVAbydYg+1UAcZHek7BastkZ7Rmxp0sUz4nONmqA4x Fo0ac6GGO46veLqFyYYV4RjnmvRLhHzjH+9xPgAMYZysUY+2+eliBfQbatBU1C++P5 Y+yAP/x99piqAAqevBSpuJ6QJQC4iOrJGeFd3gpM=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C8FA820E40CF; Mon, 20 May 2013 01:11:43 -0400 (EDT)
From: Scott Kitterman <spf2@kitterman.com>
To: spfbis@ietf.org
Date: Mon, 20 May 2013 01:11:40 -0400
Message-ID: <2568528.KYijAM7kNx@scott-latitude-e6320>
User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; )
In-Reply-To: <51999660.6070105@gathman.org>
References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <517ABBDA.2060201@dcrocker.net> <51999660.6070105@gathman.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] Obsoleting SPF RRTYPE
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 20 May 2013 05:12:00 -0000

On Sunday, May 19, 2013 11:20:00 PM Stuart Gathman wrote:
> New observation:  claims that spf libraries didn't support SPF RR are
> likely correct.
> 
> Long ago, Nostradamus foresaw that on 04/26/2013 01:39 PM, Dave Crocker
> 
> would write:
> > Even then, retention is a bad idea.  There is no current basis for
> > seeing any likelihood of utility for the RR.  None.
> 
> After seeing a complaint that spf libraries didn't support SPF RR, and
> protesting that pyspf did, I went and checked, and lo and behold, SPF
> RRs were disabled in pyspf at some point - and I hadn't noticed.  I
> turned them back on, and discovered that we were missing important SPF
> policies for business partners due to not checking SPF RRs!  I have not
> yet run into any of the braindead servers (that timeout on unknown RRs)
> that caused the initial difficulties with using the SPF RR.
> 
> Interestingly, I find that all the (rare) SPF RRs in the field I've
> encountered so far publish *only* SPF RR.  Probably a wise strategy.
> The "publish both" recommendation in rfc4408 is problematic.

It was turned off because I turned it off after it caused problems (Stuart and I 
are co-maintainers of pyspf).  This was several years ago, so either I 
misremember discussing the change with him when I did it or he's forgotten the 
discussion.

Until it's reliable enough to use, it shouldn't be used and, of course, no one 
will care if it's reliable if it's not used.

All of which is irrelevant to the rationale for removing it.

Scott K

v2.23.0 | Report a Bug | By Email