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

Scott Kitterman <scott@kitterman.com> Thu, 11 August 2011 19:45 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 5271B11E808A for <apps-discuss@ietfa.amsl.com>; Thu, 11 Aug 2011 12:45:35 -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 fuczNbSyniiD for <apps-discuss@ietfa.amsl.com>; Thu, 11 Aug 2011 12:45:34 -0700 (PDT)
Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8B86F11E807C for <apps-discuss@ietf.org>; Thu, 11 Aug 2011 12:45:34 -0700 (PDT)
Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 4893938C131; Thu, 11 Aug 2011 15:46:09 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1313091969; bh=dTRqxKwZgyF+dtt2CGd6mYXuJxgmnBSWtPOPAGnn2Pw=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=prs8kMc87LtV9Q3weznwCN2bhEPyxQMPH+ukwhQt69WzBbc86ohRpXM4etqo5bFsS qjA8YFsam3zo1VxB2PvbhZf8fw1G9Liif1aX3X4BFhJ1Zo772jUYsjjICTuG1vN5SI f+NR9Igiyq+DsLfb24aUo1eEQPUeE5FTQu2fsjQE=
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Thu, 11 Aug 2011 15:46:05 -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> <F5833273385BB34F99288B3648C4F06F13512DF6CD@EXCH-C2.corp.cloudmark.com> <CAHhFybqGT8z8ZM7LUP2B7YTVKi-bPH37ZQN896en1DaEpsTTjA@mail.gmail.com>
In-Reply-To: <CAHhFybqGT8z8ZM7LUP2B7YTVKi-bPH37ZQN896en1DaEpsTTjA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201108111546.05901.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 19:45:35 -0000

On Thursday, August 11, 2011 03:10:40 PM Frank Ellermann wrote:
> On 11 August 2011 19:59, Murray S. Kucherawy wrote:
> > WFM so far.
> 
> Same here after figuring out that this means "works for me".  There used to
> be a kind of consensus in the OpenSPF community, that any future version
> (neither v=spf1 nor spf2.0/anything) shall use only DNS SPF RRs (not TXT),
> and the WG should be free to say so in 4408bis if desired.

I disagree.  Type SPF has almost zero deployment, so using only Type SPF is 
not consistent with preserving the installed base.

> The WG should be also free to say that spf2.0/anything for "mfrom" is now
> considered as obsolescete for the purposes of v=spf1, with more details
> to be determined by the WG as desired.  I'd like to have it clear that
> 4408bis does not require or care about any spf2.0/mfrom records as noted
> in RFC 4406 section 4.4 clause 3, and that 4408bis shall be interpreted
> as specified in 4408bis, notably not as in RFC 4406 section 4.4 clause 4.
> 
> This issue is already covered in the RFC 4408 security considerations, and
> in its IESG note at the begin, therefore 440bis should have this as clear
> as possible.  An attempt to combine this proposal with Barry's concerns:
> 
> "The WG shall not try to update other RFCs, notably 4405, 4406, 4407, or
>  5321/5322, but may address the spf2.0/mfrom or hypothetical spf2.0/helo
>  scopes wrt 4408bis security considerations."

I don't think the WG should do anything in 4408bis beyond updating 4408.  I 
don't think there's a need for any drafts relative to 4405/6/7 other than the 
one that declares them historic.

We can debate the DNS type issue later on the appropriate list once we have a 
solid charter.

If you feel the need, I think "The WG shall not try to update other RFCs." is 
sufficient.

Scott K