[apps-discuss] Proposed "spfbis" working group charter

"Murray S. Kucherawy" <msk@cloudmark.com> Mon, 14 November 2011 05:46 UTC

Return-Path: <msk@blackops.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9325821F8CBC for <apps-discuss@ietfa.amsl.com>; Sun, 13 Nov 2011 21:46:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Byr++RMJp3+T for <apps-discuss@ietfa.amsl.com>; Sun, 13 Nov 2011 21:46:07 -0800 (PST)
Received: from medusa.blackops.org (medusa.blackops.org []) by ietfa.amsl.com (Postfix) with ESMTP id D98B121F846B for <apps-discuss@ietf.org>; Sun, 13 Nov 2011 21:46:06 -0800 (PST)
Received: from medusa.blackops.org (msk@localhost.blackops.org []) by medusa.blackops.org (8.14.4/8.14.4) with ESMTP id pAE5k2HC035232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Sun, 13 Nov 2011 21:46:03 -0800 (PST) (envelope-from msk@medusa.blackops.org)
X-DKIM: OpenDKIM Filter v2.4.2 medusa.blackops.org pAE5k2HC035232
X-SenderID: Sendmail Sender-ID Filter v1.0.0 medusa.blackops.org pAE5k2HC035232
Authentication-Results: medusa.blackops.org; sender-id=softfail header.from=msk@cloudmark.com; spf=none smtp.mfrom=msk@medusa.blackops.org
Received: (from msk@localhost) by medusa.blackops.org (8.14.4/8.14.2/Submit) id pAE5k1aW035215; Sun, 13 Nov 2011 21:46:01 -0800 (PST) (envelope-from msk)
Date: Sun, 13 Nov 2011 21:46:01 -0800
Message-Id: <201111140546.pAE5k1aW035215@medusa.blackops.org>
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: apps-discuss@ietf.org
Subject: [apps-discuss] Proposed "spfbis" working group charter
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: Mon, 14 Nov 2011 05:46:58 -0000

As discussed today in the APPSAWG meeting.  Comments welcome.

--- 8< --- snip --- 8< ---

Working Group Name:
	SPF Update (SPFBIS)

IETF Area:
	Applications Area


Applications Area Director(s):
	Pete Resnick <presnick@qualcomm.com>
	Peter Saint-Andre <stpeter@stpeter.im>

Applications Area Advisor:
	Pete Resnick <presnick@qualcomm.com>

Mailing Lists:
	General Discussion: spfbis@ietf.org
	To Subscribe:	    https://www.ietf.org/mailman/listinfo/spfbis
	Archive:	    http://www.ietf.org/mail-archive/web/spfbis/

Description of Working Group:
	The Sender Policy Framework (SPF, RFC4408) specifies the publication
	of a DNS record which states that a listed IP address is authorized
	to send mail on behalf of the listing domain name's owner.  SMTP
	servers extract the domain name in the SMTP "MAIL FROM" command for
	confirming this authorization.  The protocol has had Experimental
	status for some years and has become widely deployed.  This working
	group will revise the specification, based on deployment experience
	and listed errata, an will seek Standards Track status for the

	The MARID working group created two specifications for publication of 
	email-sending authorization:  Sender-ID (RFFC4405, RFC4406 and RFC4407)
	and SPF (RFC4408), with both having Experimental status.  By using
	IP addresses, both protocols specify authorization in terms of path,
	though unlike SPF, Sender-ID uses domain names found in the header of
	the message rather than the envelope.

	The two protocols rely on the same policy mechanism, namely a
	specific TXT resource record in the DNS.  This creates a basic 
        ambiguity about the interpretation of any specific instance of the TXT 
        record.  Because of this, there were concerns about conflicts between 
        the two in concurrent operation.  The IESG Note added to each invited
	an expression of community consensus in the period following these

	Both enjoyed initially large deployments.  Broad SPF use continues,
	and its linkage to the envelope -- rather than Sender-ID's linkage
	to identifiers in the message content -- has proven sufficient among
	operators.  This concludes the experiment.

	This working group will therefore refine the SPF specification based
	on deployment experience and listed errata, and will seek Standards
	Track status for the protocol.  Changes to the specification will be
	limited to the correction of errors, removal of unused features,
	addition of any enhancements that have already gained widespread
	support, and addition of clarifying language.

	The working group will also produce a document describing the
	course of the SPF/Sender-ID experiment (defined in the IESG note
	on the RFCs in question), bringing that experiment to a formal

	Specifically out-of-scope for this working group:

	* Revisiting past technical arguments that were covered
	  in the MARID working group, except where review is reasonably
	  warranted based on operational experience.

	* Discussion of the merits of SPF.

	* Discussion of the merits of Sender-ID in preference to SPF.

	* Extensions to SPF other than the one specified in the "scope"
	  document.  The working group will re-charter to process other
	  specific proposed extensions as they are identified.

	The initial draft set:

Goals and Milestones:
	MMM YYYY:	A standards track document defining SPF,
			based on RFC4408 and as amended above,
 			to the IESG for publication.

	MMM YYYY:	A document describing the SPF/Sender-ID experiment
			and its conclusions to the IESG for publication.

	MMM YYYY:	A standards track document creating the "scope"
			extension to the IESG for publication.