IETF Logo Mail Archive

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

Dave Crocker <dhc@dcrocker.net> Wed, 28 August 2013 14:21 UTC

Return-Path: <dhc@dcrocker.net>
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 D3C4B11E813A for <ietf@ietfa.amsl.com>; Wed, 28 Aug 2013 07:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.556
X-Spam-Level:
X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 qbxiPKea9hE6 for <ietf@ietfa.amsl.com>; Wed, 28 Aug 2013 07:21:22 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 287FE11E811F for <ietf@ietf.org>; Wed, 28 Aug 2013 07:21:21 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7SELHdx032577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <ietf@ietf.org>; Wed, 28 Aug 2013 07:21:20 -0700
Message-ID: <521E0759.7090504@dcrocker.net>
Date: Wed, 28 Aug 2013 07:21:13 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
References: <9884B9CD-0ED3-4D89-A100-58D05EA4BC98@gmail.com> <6.2.5.6.2.20130823234808.0b7cfed0@elandnews.com> <C5D75C5C-D468-4104-A478-0A055F43AED9@gmail.com> <6.2.5.6.2.20130826182352.0cac3298@elandnews.com> <330A924C-17DA-4082-92AD-FDB6EF09192A@hopcount.ca> <6.2.5.6.2.20130827090837.0d7b3e18@elandnews.com> <6.2.5.6.2.20130828044224.06ee3980@resistor.net>
In-Reply-To: <6.2.5.6.2.20130828044224.06ee3980@resistor.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 28 Aug 2013 07:21:20 -0700 (PDT)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
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, 28 Aug 2013 14:21:28 -0000

On 8/28/2013 5:24 AM, S Moonesamy wrote:
> It's difficult, some might say impossible, to get agreement on
> draft-ietf-spfbis-4408bis.  I would like to ask each of you, and anyone
> else, to provide your opinion about the following:
>
> RFC 5507 primarily raises three concerns about TXT records:


RFC 5507 is irrelevant to consideration of the SPFbis draft.

Really.

RFC 5507 concerns approaches to design.  However the SPFbis draft is not 
designing a new capability.  It is documenting a mechanism that has 
existed for quite a long time, is very widely deployed, and has become 
an essential part of Internet Mail's operational infrastructure that 
works to counter abuse.

Internet Mail already relies on SPF and has for many years.

To consider RFC 5507 with respect to SPFbis is to treat the current 
draft as a matter of new work, which it isn't.

No one is arguing that SPF's use of the TXT record is preferable.  All 
newer uses of the TXT record use a scoping mechanism (through an 
underscore-based node name) to avoid all of the classic TXT record 
ambiguity concerns.

My professional assessment of SPF is that there are many ways it could 
have been designed better.  My other professional assessment is that the 
design quality of SPF ceased to be a relevant consideration, as soon as 
it gained widespread traction.

Wide deployment equals very large-scale consensus and quite a lot of 
running code.  The IETF says it cares about those two attributes.

If IETF technical work is to have any relation to the operational 
Internet, it needs to treat solid, real-world deployment as having 
higher priority than theoretical technical perfection.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

v2.23.0 | Report a Bug | By Email