From ajs@anvilwalrusden.com Tue Jul 2 07:23:15 2013 Return-Path: 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 84B2821F9EF3 for ; Tue, 2 Jul 2013 07:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 eyMgO3EW0PMk for ; Tue, 2 Jul 2013 07:23:11 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id B2D4F21F9DDB for ; Tue, 2 Jul 2013 07:23:09 -0700 (PDT) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id AB7A68A031 for ; Tue, 2 Jul 2013 14:22:58 +0000 (UTC) Date: Tue, 2 Jul 2013 10:22:57 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130702142257.GB30186@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Nomcom still beating bushes X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 14:23:15 -0000 Hi all, In case you missed it, the Nomcom is still looking for volunteers for the pool. Please consider submitting your name. You can send a message to nomcom-chair-2013@ietf.org to do so. Some background about the nomcom is at https://www.ietf.org/nomcom/. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From internet-drafts@ietf.org Tue Jul 2 22:07:11 2013 Return-Path: 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 A909321F9BB6; Tue, 2 Jul 2013 22:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 IdaZrNaG1FGN; Tue, 2 Jul 2013 22:07:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0E821F9BB3; Tue, 2 Jul 2013 22:07:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130703050710.22552.60029.idtracker@ietfa.amsl.com> Date: Tue, 02 Jul 2013 22:07:10 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-16.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 05:07:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Sender Policy Framework (SPF) for Authorizing Use of Dom= ains in Email, Version 1 Author(s) : Scott Kitterman Filename : draft-ietf-spfbis-4408bis-16.txt Pages : 75 Date : 2013-07-02 Abstract: Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a ADMDs (ADministrative Management Domains) can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. This document obsoletes RFC4408. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sm@elandsys.com Fri Jul 12 05:39:37 2013 Return-Path: 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 2365411E80F9 for ; Fri, 12 Jul 2013 05:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 71Hpnv7KL3yK for ; Fri, 12 Jul 2013 05:39:36 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C279621E805E for ; Fri, 12 Jul 2013 05:39:31 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.156.131]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6CCdJfB004223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 05:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373632770; bh=oxvPLfRQNiVYQ61aDJ2SCQRK23On6uvG0aw5Lfsg9HI=; h=Date:To:From:Subject:Cc; b=EOSCWBg1Matt02MZwLkRO1U6BfxOUk7jX4Q4qPqvzGeFepSOpG08mIxv6bYDkBC/P lm+EZfABs7z1g7n5KUHJ+M+KKU1Dywt44rgmntHM3sg3zQjxS/wZCTMdsag8y/rnS9 N7DbskoiNTRb8vu1p9IpxhEHRs8egbgjq7AGJVjw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1373632770; i=@elandsys.com; bh=oxvPLfRQNiVYQ61aDJ2SCQRK23On6uvG0aw5Lfsg9HI=; h=Date:To:From:Subject:Cc; b=csoPhbUps/KUmHDXnVMyuAwK28BmqkqIG/vY0C4XvbYRQFpMcQ7pU6Ijk9ALvg1SE cWjwCqwOiRJiNrP+Cp529FAezGHVvtKblRTJ/1s+NQC16jnndmtuewd3Z2bC2ozO4L +O7I0KwuZgeiLQnLvCCk8w2HnugEAskjunpxeeKk= Message-Id: <6.2.5.6.2.20130712053440.0c58a878@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 12 Jul 2013 05:38:33 -0700 To: Scott Kitterman From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: [spfbis] IPR disclosure - draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 12:39:37 -0000 Hi Scott, As you are the document editor for draft-ietf-spfbis-4408bis-16, can you confirm that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed? Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Fri Jul 12 07:28:52 2013 Return-Path: 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 96C0221F9929 for ; Fri, 12 Jul 2013 07:28:52 -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=[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 ziyuIBHNIHgv for ; Fri, 12 Jul 2013 07:28:52 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6869521F996A for ; Fri, 12 Jul 2013 07:28:51 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id E041FD04067; Fri, 12 Jul 2013 10:28:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1373639330; bh=yAZse8qmf2o25UE1bz1U/aTnIi5upXsFH4C1VY1EAMs=; h=In-Reply-To:References:Subject:From:Date:To:CC:From; b=JFBmswrbFxcuxbse27AH86SBEUWgY+6Cde3VsEjMR3TKWjndYMC7rXysAnVOhl2r2 Nuabt1gxmsYmG2l02oL+QUlze6e+ti7xtR7kvig25rrJ1wt3qhg8vzRckUjx52oJnq npLObaRfUZcK/xazgyZdePKUJtDj85LzLb2y3WB4= Received: from [192.168.111.2] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9F0CCD04065; Fri, 12 Jul 2013 10:28:50 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130712053440.0c58a878@elandnews.com> References: <6.2.5.6.2.20130712053440.0c58a878@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 12 Jul 2013 10:28:51 -0400 To: S Moonesamy Message-ID: X-AV-Checked: ClamAV using ClamSMTP Cc: spfbis@ietf.org Subject: Re: [spfbis] IPR disclosure - draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 14:28:52 -0000 To the best of my knowledge, yes. Scott K S Moonesamy wrote: >Hi Scott, > >As you are the document editor for draft-ietf-spfbis-4408bis-16, can >you confirm that any and all appropriate IPR disclosures required for >full conformance with the provisions of BCP 78 and BCP 79 have >already been filed? > >Regards, >S. Moonesamy >SPFBIS WG co-chair > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From sm@elandsys.com Fri Jul 12 08:49:23 2013 Return-Path: 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 296A121F9E29 for ; Fri, 12 Jul 2013 08:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5NkoSbn807M8 for ; Fri, 12 Jul 2013 08:49:22 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7CE21F9E1D for ; Fri, 12 Jul 2013 08:49:22 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.156.131]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6CFn8Ev018691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 08:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373644160; bh=NNNHwTtatHeoAnnKxpnWukNb/fXXuP/UbMX+5YIcE6c=; h=Date:To:From:Subject:Cc; b=4B6uwS+K7gUaLR11wXAMili4ZfW2pHM3Hb9L4YN0emwo7lek0z39PJ/6kbHNVYA8r epJP4//7zo55/0YTGuK9Gkhlc7HBr96YaN5Svk/61PXI2BkCWnS22VaDd8rplyTnes yS7Yo3C3ezGz+vx3SPD5GtEZaKYU9O9/KKiaPZTs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1373644160; i=@elandsys.com; bh=NNNHwTtatHeoAnnKxpnWukNb/fXXuP/UbMX+5YIcE6c=; h=Date:To:From:Subject:Cc; b=MWke49Ez+kYyjimbWPSBYrpY8Hxd7iw6BNK6LLTU7gZA8emqcCACZykk3X6BPGwt8 wpgYrGXL7EoAkSOd11e/2/SujVFHVEbxwqkswPZqdlXnROuX6Or3y4xyfL0XpRqrG9 17gpGDGWcjukktUT9CmyjKqoELEl75J+5uAT3j0w= Message-Id: <6.2.5.6.2.20130712075649.0b252608@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 12 Jul 2013 08:43:10 -0700 To: Scott Kitterman From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: [spfbis] Nits about draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 15:49:23 -0000 Hi Scott, I ran draft-ietf-spfbis-4408bis-16 through id-nits and it flagged two errors. The error about RFC 5598 can be ignored. RFC 5782, flagged as an error, should be an informative reference instead of a normative one. In the Abstract: "This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a ADMDs(ADministrative Management Domains) can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization." I suggest: "This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby an Administrative Management Domain can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization." You could add the abbreviation after the expanded form if you prefer to keep it. Section 4 mentions "Receiving ADMDs". You could use that instead of "receiving host". There is a typo in Section 2.5: "Appencix C of [RFC5451] provides". I'll suggest a change to Section 13.3. This is to make it clear to IANA and make their work easier. IANA is requested to change the reference for the exp and redirect modifiers in the Modifier Names registry, under Sender Policy Framework Parameters, from [RFC4408] to this document. Their status is unchanged. Could you add a "NOTE TO RFC EDITOR:" at the beginning of Appendix I and Appendix J? If you are okay with any of the above you could make the changes to your local copy. A draft can be submitted if the Responsible Area Director requests that. Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Fri Jul 12 09:04:09 2013 Return-Path: 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 9ECE311E814D for ; Fri, 12 Jul 2013 09:04:09 -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=[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 T+sJ9Ag67Au4 for ; Fri, 12 Jul 2013 09:04:04 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 70A8F21E8053 for ; Fri, 12 Jul 2013 09:04:04 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 66FE020E40D3; Fri, 12 Jul 2013 12:04:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1373645042; bh=xF7980Vz/JDlsXN+ivJFnoetDzPzKMIw8wFHNSjKmpA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LRysx/YJTC3bDttfP54LY3iuTXTgI/56t+9TmIDkJPcFrq9z8YKL511+/VYZMcEnh nq9m7o562LP3YAu6h6RGnV/qTTTgEt3EvaoCxFRnxvuswtEscZfYXKqD5mn9CvNz5G i0Epbkuc9tptR4ft9iv/uejRzwlB5MlPAKRxWA90= 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 491F220E40CC; Fri, 12 Jul 2013 12:04:01 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 12 Jul 2013 12:03:59 -0400 Message-ID: <44326576.noGqvk3AaU@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-26-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130712075649.0b252608@elandnews.com> References: <6.2.5.6.2.20130712075649.0b252608@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Nits about draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 16:04:09 -0000 On Friday, July 12, 2013 08:43:10 AM S Moonesamy wrote: > Hi Scott, > > I ran draft-ietf-spfbis-4408bis-16 through id-nits and it flagged two > errors. The error about RFC 5598 can be ignored. RFC 5782, flagged > as an error, should be an informative reference instead of a normative one. > > In the Abstract: > > "This document describes version 1 of the Sender Policy Framework > (SPF) protocol, whereby a ADMDs(ADministrative Management Domains) > can explicitly authorize the hosts that are allowed to use its > domain names, and a receiving host can check such authorization." > > I suggest: > > "This document describes version 1 of the Sender Policy Framework > (SPF) protocol, whereby an Administrative Management Domain can > explicitly authorize the hosts that are allowed to use its > domain names, and a receiving host can check such authorization." > > You could add the abbreviation after the expanded form if you prefer > to keep it. I'll put it after. At some point there was a comment about that text and dealing with the abbreviation in it's first appearance, so I don't want to remove it. > Section 4 mentions "Receiving ADMDs". You could use that instead of > "receiving host". The check is done at a specific host, so I think it's correct as is. The decision to make such a check and the policy applied based on the results of the check are an ADMD decision, but the actual implementation is in a specific receiving host. > There is a typo in Section 2.5: "Appencix C of [RFC5451] provides". I don't see the typo. What specifically? > I'll suggest a change to Section 13.3. This is to make it clear to > IANA and make their work easier. > > IANA is requested to change the reference for the exp and redirect > modifiers in the Modifier Names registry, under Sender Policy > Framework Parameters, from [RFC4408] to this document. Their > status is unchanged. OK. > Could you add a "NOTE TO RFC EDITOR:" at the beginning of Appendix I > and Appendix J? OK. > If you are okay with any of the above you could make the changes to > your local copy. A draft can be submitted if the Responsible Area > Director requests that. OK. I mostly agree, but please let me know what you think about receiving host and give me more specificity about the typo you see in 2.5. Scott K From hsantos@isdg.net Fri Jul 12 12:48:14 2013 Return-Path: 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 2744221F9C60 for ; Fri, 12 Jul 2013 12:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 FWzRGijQtJbo for ; Fri, 12 Jul 2013 12:48:09 -0700 (PDT) Received: from mail.santronics.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CD73E21F9C2D for ; Fri, 12 Jul 2013 12:48:07 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1630; t=1373658477; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=hSK1Vrp aZKTwZnca9DfIYgUfTNE=; b=dlgJM+N+OEqIg0aw9lwLvTScFg3D+flgrk4wUeO 2GJWuk45qMRVLtKvv6kw8CAWzYyrTaec4qTPwFwZ9oW43MPnTx3Oj0oUl1oeUrTn eZhnsyHueKeKx9eWPJsOGeqPFbXN2jGQLS7u56Bbuu1p15BLz3BLRQ6twZNRcxjw Ekvs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 12 Jul 2013 15:47:57 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 121032753.11061.4916; Fri, 12 Jul 2013 15:47:56 -0400 Message-ID: <51E05CB8.9000700@isdg.net> Date: Fri, 12 Jul 2013 15:44:56 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Kitterman References: <6.2.5.6.2.20130712075649.0b252608@elandnews.com> <44326576.noGqvk3AaU@scott-latitude-e6320> In-Reply-To: <44326576.noGqvk3AaU@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Nits about draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 19:48:14 -0000 On 7/12/2013 12:03 PM, Scott Kitterman wrote: > On Friday, July 12, 2013 08:43:10 AM S Moonesamy wrote: >> Hi Scott, >> >> I ran draft-ietf-spfbis-4408bis-16 through id-nits and it flagged two >> errors. The error about RFC 5598 can be ignored. RFC 5782, flagged >> as an error, should be an informative reference instead of a normative one. >> >> In the Abstract: >> >> "This document describes version 1 of the Sender Policy Framework >> (SPF) protocol, whereby a ADMDs(ADministrative Management Domains) >> can explicitly authorize the hosts that are allowed to use its >> domain names, and a receiving host can check such authorization." >> >> I suggest: >> >> "This document describes version 1 of the Sender Policy Framework >> (SPF) protocol, whereby an Administrative Management Domain can >> explicitly authorize the hosts that are allowed to use its >> domain names, and a receiving host can check such authorization." >> >> You could add the abbreviation after the expanded form if you prefer >> to keep it. > > I'll put it after. At some point there was a comment about that text and > dealing with the abbreviation in it's first appearance, so I don't want to > remove it. The proper technical writing style is to spell it out first, followed by the parenthetical acronym: Administrative Management Domain (ADMD) However, since its just the abstract, you will to repeat it once more in the intro and there you can begin again as above before just using the acronym in the reminder of the doc. The same is true for other abbreviated terms and their acronyms. -- HLS From sm@elandsys.com Fri Jul 12 13:43:19 2013 Return-Path: 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 28D8221F9E98 for ; Fri, 12 Jul 2013 13:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 drzzPkJwntTA for ; Fri, 12 Jul 2013 13:43:18 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8195721F9E70 for ; Fri, 12 Jul 2013 13:43:17 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.156.131]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6CKh4Fl000209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 13:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373661796; bh=LZ89NZNqBq4+uAWQnoEwbRMoA9jnPQU+pBt2E92lFpE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=C01bZFgUjhau5BqwA5YgZoKgN7OAG9PLKJUO6yj9/7nhM1hxl1ij7+NsErgoh3hdr hIhIidGe8oos6ViGvS7ajjnnWFCmjZVZm6PKIakLTIY604hZGuiK+K0xdFSGCO18Pm ocueYus3qtl/LYujVIhkUITMJ2UAjFNkVLFhI5MI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1373661796; i=@elandsys.com; bh=LZ89NZNqBq4+uAWQnoEwbRMoA9jnPQU+pBt2E92lFpE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XMJPbbSM0TY5l3oSidBgJ6t5xlSsA+Hv700tTcXmWzE8VICmTNoy4BEOkzLzGx/+0 7xQJ/DKVKnqkks0a7Zezk8smmRK+T07fvkiUP99KZn32GxHXLCSpXO5wOkVWHTaeKf 6IItjbDcRpo0Xipb3biLqr2dMXAYYlIf2GmhIboQ= Message-Id: <6.2.5.6.2.20130712130527.0d975a08@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 12 Jul 2013 13:41:19 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <44326576.noGqvk3AaU@scott-latitude-e6320> References: <6.2.5.6.2.20130712075649.0b252608@elandnews.com> <44326576.noGqvk3AaU@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Nits about draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 20:43:19 -0000 Hi Scott, At 09:03 12-07-2013, Scott Kitterman wrote: >I'll put it after. At some point there was a comment about that text and >dealing with the abbreviation in it's first appearance, so I don't want to >remove it. Ok. >The check is done at a specific host, so I think it's correct as is. The >decision to make such a check and the policy applied based on the results of >the check are an ADMD decision, but the actual implementation is in >a specific >receiving host. Ok. > > There is a typo in Section 2.5: "Appencix C of [RFC5451] provides". > >I don't see the typo. What specifically? "Appendix" instead of "Appencix". >OK. I mostly agree, but please let me know what you think about receiving >host and give me more specificity about the typo you see in 2.5. I am ok if you think that the "receiving host" correct. I noticed that the reference to RFC 1983 should be normative instead of informative. It's going to cause a downward reference. I was doing a final ABNF check for my write-up. I saw the following defined in Appendix A but not used: authserv-id reasonspec Could someone please verify that? Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Fri Jul 12 14:13:12 2013 Return-Path: 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 0050B21F9F6D for ; Fri, 12 Jul 2013 14:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5yVJ20Fu3zBw for ; Fri, 12 Jul 2013 14:13:11 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A0621F9F6F for ; Fri, 12 Jul 2013 14:13:10 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.156.131]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6CLCv26010568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Jul 2013 14:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373663589; bh=rPWBurKkEQc1KngRCGQNN6b5ANetmTG1Y3Xova0NM34=; h=Date:To:From:Subject; b=KWX8LPr+r5o5z3RNkshl+ULQJFy1Tf42yU08oy20E+p6bT7k8e/wjbjcEg0mS08Gd DJHSsy6kCJPuWUVTnRsfCmlDK/F10jBwD8vvt5i65ukDghM1YLLbM0iWWSJCg3E3eu 0x96uGY0g6h9r2NO/AFghcCj7dt4r0AiZJgwk1uU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1373663589; i=@elandsys.com; bh=rPWBurKkEQc1KngRCGQNN6b5ANetmTG1Y3Xova0NM34=; h=Date:To:From:Subject; b=cxfFU4AJEEI+5qWnJymGA8yq2WmUgxI/7GRUT0ztddhNIwEo4pnYTogagzcGb5WWd eOqccH123Qw6iWgcypE+gx/KZdsYicyYqbSDiuBV90UL737zoOHXdYgkYYYw3NjxcM tXjDi4Aw9zYuZnvBY+nXR7wu/csAOmfJg219tUH4= Message-Id: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 12 Jul 2013 14:11:22 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 21:13:12 -0000 Hello, This is a draft of the Document Shepherd Write-Up. Please let me know if I missed anything important. I added a comment in (10) about extreme discontent during the WGLC. Please email me off-list if you are of the opinion that there is an issue which has not been addressed correctly. (1) The type of RFC being requested is Proposed Standard. The draft describes version 1 of the Sender Policy Framework (SPF) protocol, whereby an Administrative Management Domain can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. The type is indicated in the title page header. (2) The approval announcement contains the following sections: Technical Summary This document describes version 1 ofthe Sender Policy Framework (SPF) protocol, whereby an Administrative Management Domain can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. Working Group Summary The decision about whether the SPF protocol has to reject mail or not when the result of the evaluation is "Fail" was controversial. There was WG consensus not to standardize SPF Best-guess processing. The issue of mail forwarding and mailing lists in respect to the SPF protocol was not too controversial in comparison with the other controversies. There was some controversy about whether the use of macros was a security risk and whether to deprecate the PTR feature. There was a formal appeal of the SPFBIS WG chair' interpretation of the charter, specifically regarding the removal of "unused" features. The two features in particular which drove the appeal were the PTR feature and the local-part macro feature. These features were not removed from the document given that the appeal was denied by the Responsible Area Director. There was significant discussion about whether to use the "Received-SPF:" header field or whether to use the "Authentication-Results" header field to record the results of a SPF evaluation. The working group decided to add both header fields in the document as they are in common use. There was a suggestion to reorganize the document. It was argued that the document had become somewhat bloated with documentation of nuance and other text that has nothing to do with defining a protocol and enabling interoperability. This led to a stalemate. Based on the discussion during the SFPBIS WG session at IETF 85 the WG decided to proceed with a reorganization of the document while ensuring that the reorganization did not create any text changes apart from moving text around. The topic of obsoleting the SPF RRTYPE generated a lot of controversy near the end of the WGLC. There was an intermediate conclusion about the topic before the WGLC and it was followed by an objection. After the discussion of the topic at the IETF 83 SPFBIS WG session the conclusion reached was that the decision would be not to publish RRTYPE 99 and and not to query RRTYPE 99. The WG consensus about the RRTYPE can be described as particularly rough. There were a very high number of messages about the topic on the SPFBIS mailing list and the DNSEXT mailing list as the DNSEXT WG participants were not aware of RFC 6686. Document Quality There are multiple existing implementations of the SPF protocol. The document was reviewed by the SPFBIS working group. Dave Crocker, Cyrus Daboo, Stuart Gathman, Murray Kucherawy, John Levine, Andrew Sullivan, Arthur Thisell, and Alessandro Vesely reviewed the document. Simon Perreault helped to clarify the meaning of IPv4 mapped IPv6 addresses. Murray Kucherawy deserves a special mention for his contributions. Personnel S. Moonesamy is the Document Shepherd for this document. Pete Resnick is the Responsible Area Director. (3) I have personally reviewed draft-ietf-spfbis-4408bis-16. I believe that the draft is reading for forwarding to the IESG for publication. (4) This document has been reviewed by several SPFBIS WG participants. The document has also been reviewed by Andrew Sullivan. I do not have any concerns about the depth and breath of the reviews performed. (5) The document was reviewed by Cyrus Daboo on behalf of the Applications Area Directorate. Simon Perreault reviewed the IPv6-related text in Section 5. I suggest further review of the document from a DNS perspective. (6) I do not have any specific concerns or issues with the document. (7) The author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. (8) There are no IPR disclosures referencing this document. (9) There is rough consensus within the WG to publish the document. The decision to obsolete the SPF RRTYPE was very controversial. (10) Nobody has threatened an appeal during the WGLC. Some WG participants have mentioned that they may express extreme discontent during the Last Call. (11) Id-nits lists a non-RFC2606-compliant FQDN, six non-RFC5735-compliant IPv4 addresses and one instance of a private range IPv4 address. These warnings can be ignored. The warning about CFWS is incorrect. The reference to RFC 2671 is intentional; the document also references RFC 6891. (12) The document does not require any formal review. (13) All references within this document been identified as either normative or informative. (14) The document normatively references RFCs. (15) There is a downward reference to RFC 5598. (16) The publication of this document changes the status of RCC 4408 to obsolete. (17) IANA action is requested to update the Resource Record (RR) TYPEs registry. The "Received-SPF:" header field is being added to the Permanent Message Header Field Registry. Action is requested to update the SPF Modifier Registry. (18) The document does not create any IANA registries. (19) An automated check of the ABNF in Appendix A was performed. Regards, S. Moonesamy From superuser@gmail.com Fri Jul 12 22:10:17 2013 Return-Path: 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 5FDE81F0D3E for ; Fri, 12 Jul 2013 22:10:17 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 4dIU3C2yHJT8 for ; Fri, 12 Jul 2013 22:10:16 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B6CE421F9BA6 for ; Fri, 12 Jul 2013 22:10:15 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so1322632wiv.2 for ; Fri, 12 Jul 2013 22:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PoF4qv3/X+ZOBtoLBoGND5mJJQ1GRxE6Sua6CHCcOBI=; b=Si8rMS02z1ThI2he1RgfbZ/vk2ww9W3aKsBLs+GA7L5lY2lmDCCrLV4o/btq/kTYbj 1iljz6zvGaj1ub81eOJSMrtipM6fHvul6A0awy06lZvuD0xit7nnLiDo59dcIw6Z8Av0 7u8KqqduJWs+Ok0gQbNrSHpkSdE5QKrKkky1ub9qM0175TA4F+MTf8phrVYY/ezUjKQ4 2TMigYKNQvisE3FFt0IcpkDeKGDWBgw7wBOslaoC8FHi7epfifbjyq+h5szpRMjXtDhw bIBEExSte/qFtH3NoVOlH5uToPV0KHG3sufrqcs/w4GoIamMXbyY/22i9BH9guGYWS4i IpCQ== MIME-Version: 1.0 X-Received: by 10.180.189.102 with SMTP id gh6mr3435366wic.19.1373692212996; Fri, 12 Jul 2013 22:10:12 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Fri, 12 Jul 2013 22:10:12 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> Date: Fri, 12 Jul 2013 22:10:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=001a11c3436a62f08404e15da462 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 05:10:17 -0000 --001a11c3436a62f08404e15da462 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 12, 2013 at 2:11 PM, S Moonesamy wrote: > Hello, > > This is a draft of the Document Shepherd Write-Up. Please let me know if > I missed anything important. I added a comment in (10) about extreme > discontent during the WGLC. Please email me off-list if you are of the > opinion that there is an issue which has not been addressed correctly. > There's a simplified shepherd write-up that the Applications Area ADs are asking us to use. I'll post a link to it later this evening if you can't find it yourself, but I think it's on the Applications Area wiki. Assuming you stick with the old one: > > (1) The type of RFC being requested is Proposed Standard. The draft > describes > version 1 of the Sender Policy Framework (SPF) protocol, whereby an > Administrative Management Domain can explicitly authorize the hosts > that are allowed to use its domain names, and a receiving host can > check > such authorization. The type is indicated in the title page header. > Shouldn't this also mention the status and history of RFC4408 in a sentence or two? > > (2) The approval announcement contains the following sections: > > Technical Summary > > This document describes version 1 ofthe Sender Policy Framework > s/ofthe/of the/ > (SPF) protocol, whereby an Administrative Management Domain can > explicitly authorize the hosts that are allowed to use its > domain names, and a receiving host can check such authorization. > > Working Group Summary > > The decision about whether the SPF protocol has to reject mail or not > when the result of the evaluation is "Fail" was controversial. There > was WG consensus not to standardize SPF Best-guess processing. > > The issue of mail forwarding and mailing lists in respect to the SPF > protocol was not too controversial in comparison with the other > controversies. There was some controversy about whether the use of > macros was a security risk and whether to deprecate the PTR feature. > > There was a formal appeal of the SPFBIS WG chair' interpretation of the > charter, specifically regarding the removal of "unused" features. The > two features in particular which drove the appeal were the PTR feature > and the local-part macro feature. These features were not removed from > the > document given that the appeal was denied by the Responsible Area > Director. > > There was significant discussion about whether to use the "Received-SPF:" > header field or whether to use the "Authentication-Results" header field > to record the results of a SPF evaluation. The working group decided to > add both header fields in the document as they are in common use. > > There was a suggestion to reorganize the document. It was argued that > the > document had become somewhat bloated with documentation of nuance and > other > text that has nothing to do with defining a protocol and enabling > interoperability. This led to a stalemate. Based on the discussion > during > the SFPBIS WG session at IETF 85 the WG decided to proceed with a > reorganization of the document while ensuring that the reorganization did > not create any text changes apart from moving text around. > > The topic of obsoleting the SPF RRTYPE generated a lot of controversy > near > the end of the WGLC. There was an intermediate conclusion about the > topic > before the WGLC and it was followed by an objection. After the > discussion > of the topic at the IETF 83 SPFBIS WG session the conclusion reached was > that the decision would be not to publish RRTYPE 99 and and not to query > RRTYPE 99. The WG consensus about the RRTYPE can be described as > particularly rough. There were a very high number of messages about the > topic on the SPFBIS mailing list and the DNSEXT mailing list as the > DNSEXT WG participants were not aware of RFC 6686. > > Document Quality > > There are multiple existing implementations of the SPF protocol. The > document was reviewed by the SPFBIS working group. Dave Crocker, > Cyrus Daboo, Stuart Gathman, Murray Kucherawy, John Levine, > Andrew Sullivan, Arthur Thisell, and Alessandro Vesely reviewed the > document. Simon Perreault helped to clarify the meaning of > IPv4 mapped IPv6 addresses. Murray Kucherawy deserves a special > mention for his contributions. > > Personnel > > S. Moonesamy is the Document Shepherd for this document. Pete Resnick > is the Responsible Area Director. > > (3) I have personally reviewed draft-ietf-spfbis-4408bis-16. I believe > that > the draft is reading for forwarding to the IESG for publication. > > (4) This document has been reviewed by several SPFBIS WG participants. > The document has also been reviewed by Andrew Sullivan. I do not have > any concerns about the depth and breath of the reviews performed. > > (5) The document was reviewed by Cyrus Daboo on behalf of the Applications > Area Directorate. Simon Perreault reviewed the IPv6-related text in > Section 5. I suggest further review of the document from a DNS > perspective. > > (6) I do not have any specific concerns or issues with the document. > > (7) The author confirmed that any and all appropriate IPR disclosures > required for full conformance with the provisions of BCP 78 and > BCP 79 have already been filed. > > (8) There are no IPR disclosures referencing this document. > > (9) There is rough consensus within the WG to publish the document. > The decision to obsolete the SPF RRTYPE was very controversial. > You mentioned that already. > > (10) Nobody has threatened an appeal during the WGLC. Some WG > participants have mentioned that they may express extreme > discontent during the Last Call. > > (11) Id-nits lists a non-RFC2606-compliant FQDN, six non-RFC5735-compliant > IPv4 addresses and one instance of a private range IPv4 address. > These warnings can be ignored. The warning about CFWS is incorrect. > The reference to RFC 2671 is intentional; the document also > references RFC 6891. > > (12) The document does not require any formal review. > > (13) All references within this document been identified as either > normative or informative. > > (14) The document normatively references RFCs. > > (15) There is a downward reference to RFC 5598. > > (16) The publication of this document changes the status of RCC 4408 > to obsolete. > > (17) IANA action is requested to update the Resource Record (RR) > TYPEs registry. The "Received-SPF:" header field is > being added to the Permanent Message Header Field Registry. > Action is requested to update the SPF Modifier Registry. > > (18) The document does not create any IANA registries. > > (19) An automated check of the ABNF in Appendix A was performed. > > > Based on this, Jari may complain that the ABNF checking was not more thorough. I would also add that the reviewers checked the ABNF. -MSK --001a11c3436a62f08404e15da462 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 12, 2013 at 2:11 PM, S Moonesamy <sm+ietf@= elandsys.com> wrote:
Hello,

This is a draft of the Document Shepherd Write-Up. =A0Please let me know if= I missed anything important. =A0I added a comment in (10) about extreme di= scontent during the WGLC. =A0Please email me off-list if you are of the opi= nion that there is an issue which has not been addressed correctly.

There's a simplified shepherd write-up= that the Applications Area ADs are asking us to use.=A0 I'll post a li= nk to it later this evening if you can't find it yourself, but I think = it's on the Applications Area wiki.

Assuming you stick with the old one:
=A0

(1) The type of RFC being requested is Proposed Standard. =A0The draft desc= ribes
=A0 =A0 version 1 of the Sender Policy Framework (SPF) protocol, whereby an=
=A0 =A0 Administrative Management Domain can explicitly authorize the =A0ho= sts
=A0 =A0 that are allowed to use its domain names, and a receiving host can = check
=A0 =A0 such authorization. =A0The type is indicated in the title page head= er.

Shouldn't this also mention the= status and history of RFC4408 in a sentence or two?
=A0

(2) The approval announcement contains the following sections:

Technical Summary

=A0 This document describes version 1 ofthe Sender Policy Framework

s/ofthe/of the/
=A0
=A0 (SPF) protocol, whereby an Administrative Management Domain can
=A0 explicitly authorize the hosts that are allowed to use its
=A0 domain names, and a receiving host can check such authorization.

Working Group Summary

=A0 The decision about whether the SPF protocol has to reject mail or not =A0 when the result of the evaluation is "Fail" was controversial= . =A0There
=A0 was WG consensus not to standardize SPF Best-guess processing.

=A0 The issue of mail forwarding and mailing lists in respect to the SPF =A0 protocol was not too controversial in comparison with the other
=A0 controversies. =A0There was some controversy about whether the use of =A0 macros was a security risk and whether to deprecate the PTR feature.
=A0 There was a formal appeal of the SPFBIS WG chair' interpretation of= the
=A0 charter, specifically regarding the removal of "unused" featu= res. =A0The
=A0 two features in particular which drove the appeal were the PTR feature<= br> =A0 and the local-part macro feature. =A0These features were not removed fr= om the
=A0 document given that the appeal was denied by the Responsible Area Direc= tor.

=A0 There was significant discussion about whether to use the "Receive= d-SPF:"
=A0 header field or whether to use the "Authentication-Results" h= eader field
=A0 to record the results of a SPF evaluation. =A0The working group decided= to
=A0 add both header fields in the document as they are in common use.

=A0 There was a suggestion to reorganize the document. =A0It was argued tha= t the
=A0 document had become somewhat bloated with documentation of nuance and o= ther
=A0 text that has nothing to do with defining a protocol and enabling
=A0 interoperability. =A0This led to a stalemate. =A0Based on the discussio= n during
=A0 the SFPBIS WG session at IETF 85 the WG decided to proceed with a
=A0 reorganization of the document while ensuring that the reorganization d= id
=A0 not create any text changes apart from moving text around.

=A0 The topic of obsoleting the SPF RRTYPE generated a lot of controversy n= ear
=A0 the end of the WGLC. =A0There was an intermediate conclusion about the = topic
=A0 before the WGLC and it was followed by an objection. =A0After the discu= ssion
=A0 of the topic at the IETF 83 SPFBIS WG session the conclusion reached wa= s
=A0 that the decision would be not to publish RRTYPE 99 and and not to quer= y
=A0 RRTYPE 99. =A0The WG consensus about the RRTYPE can be described as
=A0 particularly rough. =A0There were a very high number of messages about = the
=A0 topic on the SPFBIS mailing list and the DNSEXT mailing list as the
=A0 DNSEXT WG participants were not aware of RFC 6686.

Document Quality

=A0 There are multiple existing implementations of the SPF protocol. =A0The=
=A0 document was reviewed by the SPFBIS working group. =A0Dave Crocker,
=A0 Cyrus Daboo, Stuart Gathman, Murray Kucherawy, John Levine,
=A0 Andrew Sullivan, Arthur Thisell, and Alessandro Vesely reviewed the
=A0 document. =A0Simon Perreault helped to clarify the meaning of
=A0 IPv4 mapped IPv6 addresses. =A0Murray Kucherawy deserves a special
=A0 mention for his contributions.

Personnel

=A0 S. Moonesamy is the Document Shepherd for this document. Pete Resnick =A0 is the Responsible Area Director.

(3) I have personally reviewed draft-ietf-spfbis-4408bis-16. =A0I believe t= hat
=A0 =A0 the draft is reading for forwarding to the IESG for publication.
(4) This document has been reviewed by several SPFBIS WG participants.
=A0 =A0 The document has also been reviewed by Andrew Sullivan. I do not ha= ve
=A0 =A0 any concerns about the depth and breath of the reviews performed.
(5) The document was reviewed by Cyrus Daboo on behalf of the Applications<= br> =A0 =A0 Area Directorate. =A0Simon Perreault reviewed the IPv6-related text= in
=A0 =A0 Section 5. =A0I suggest further review of the document from a DNS =A0 =A0 perspective.

(6) I do not have any specific concerns or issues with the document.

(7) The author confirmed that any and all appropriate IPR disclosures
=A0 =A0 required for full conformance with the provisions of BCP 78 and
=A0 =A0 BCP 79 have already been filed.

(8) There are no IPR disclosures referencing this document.

(9) =A0There is rough consensus within the WG to publish the document.
=A0 =A0 =A0The decision to obsolete the SPF RRTYPE was very controversial.<= br>

You mentioned that already.
=A0
<= /div>

(10) Nobody has threatened an appeal during the WGLC. =A0Some WG
=A0 =A0 =A0participants have mentioned that they may express extreme
=A0 =A0 =A0discontent during the Last Call.

(11) Id-nits lists a non-RFC2606-compliant FQDN, six non-RFC5735-compliant<= br> =A0 =A0 =A0IPv4 addresses and one instance of a private range IPv4 address.=
=A0 =A0 =A0These warnings can be ignored. =A0The warning about CFWS is inco= rrect.
=A0 =A0 =A0The reference to RFC 2671 is intentional; =A0the document also =A0 =A0 =A0references RFC 6891.

(12) The document does not require any formal review.

(13) All references within this document been identified as either
=A0 =A0 =A0normative or informative.

(14) The document normatively references RFCs.

(15) There is a downward reference to RFC 5598.

(16) The publication of this document changes the status of RCC 4408
=A0 =A0 =A0to obsolete.

(17) IANA action is requested to update the Resource Record (RR)
=A0 =A0 =A0TYPEs registry. =A0The "Received-SPF:" header field is=
=A0 =A0 =A0being added to the Permanent Message Header Field Registry.
=A0 =A0 =A0Action is requested to update the SPF Modifier Registry.

(18) The document does not create any IANA registries.

(19) An automated check of the ABNF in Appendix A was performed.



Based on this, Jari may complain t= hat the ABNF checking was not more thorough.=A0 I would also add that the r= eviewers checked the ABNF.

-MSK

--001a11c3436a62f08404e15da462-- From sm@elandsys.com Fri Jul 12 23:24:58 2013 Return-Path: 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 3717521E80D8 for ; Fri, 12 Jul 2013 23:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 RpnpEU7JntBc for ; Fri, 12 Jul 2013 23:24:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 842E121E80D1 for ; Fri, 12 Jul 2013 23:24:56 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.156.131]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6D6Ob3Z003955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 23:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373696689; bh=FEzTeMYaTaJQE7O7B611wAFFkhdmopLDgOIiifg7qTc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IOy3dmO9b+UN1csXu+r0w4gZYYszs/N4mPheFy9olrYtr9MIr7CgIBgZFrqTSuUMC FqaaEkJeZPEfzrKjsQy4ptTStsKsCwNz4Xf66RD5EUCB2VfyhKvHriNypL1XayXz39 tx2TGWu03oNiXZyUrMPdmw8XbXs7kurLqLEJXSQQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1373696689; i=@elandsys.com; bh=FEzTeMYaTaJQE7O7B611wAFFkhdmopLDgOIiifg7qTc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JhAnY4RwePQLtU4CQwgz44V9GCpkErXPzQc03Il7C4tvRvc6ni4ChpVAz/2xy38yI nRGL6XF/9UrF4vj2lgyj+WZhT1g4NlG+sLng1D+vqUqid7IZSnQtQQ6Cs8ou581YVO vevcqn4/PZ7W4krTuV47LuUiti9icF/PaPWaCqRw= Message-Id: <6.2.5.6.2.20130712230437.0c345080@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 12 Jul 2013 23:22:17 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 06:24:58 -0000 Hi Murray, At 22:10 12-07-2013, Murray S. Kucherawy wrote: >There's a simplified shepherd write-up that the Applications Area >ADs are asking us to use. I'll post a link to it later this evening >if you can't find it yourself, but I think it's on the Applications Area wiki. I'll try and fit the answers in the new write-up template. >Assuming you stick with the old one: > >(1) The type of RFC being requested is Proposed Standard. The draft describes > version 1 of the Sender Policy Framework (SPF) protocol, whereby an > Administrative Management Domain can explicitly authorize the hosts > that are allowed to use its domain names, and a receiving host can check > such authorization. The type is indicated in the title page header. > > >Shouldn't this also mention the status and history of RFC4408 in a >sentence or two? The answer to (1) is to say why the intended status is Proposed Standard. > (2) The approval announcement contains the following sections: > >Technical Summary > > This document describes version 1 ofthe Sender Policy Framework > > >s/ofthe/of the/ Thanks for catching this. >Based on this, Jari may complain that the ABNF checking was not more >thorough. I would also add that the reviewers checked the ABNF. It is up to the document shepherd to do the verification. :-) The ABNF checker flagged "authserv-id" "reasonspec", among others, as not used. I could not find any reference to them in the draft. Could you double-check that? Regards, S. Moonesamy From mansaxel@besserwisser.org Fri Jul 12 23:35:07 2013 Return-Path: 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 26BA511E814E for ; Fri, 12 Jul 2013 23:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 KJNv4pPMR7hg for ; Fri, 12 Jul 2013 23:35:06 -0700 (PDT) Received: from jaja.besserwisser.org (jaja.besserwisser.org [IPv6:2a01:298:4:0:211:43ff:fe36:1299]) by ietfa.amsl.com (Postfix) with ESMTP id 9A46811E80FF for ; Fri, 12 Jul 2013 23:35:06 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 3ECDE9E7E; Sat, 13 Jul 2013 08:35:04 +0200 (CEST) Date: Sat, 13 Jul 2013 08:35:04 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: S Moonesamy Message-ID: <20130713063503.GE15374@besserwisser.org> References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AjmyJqqohANyBN/e" Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: spfbis@ietf.org Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 06:35:07 -0000 --AjmyJqqohANyBN/e Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-44= 08bis-16 Date: Fri, Jul 12, 2013 at 02:11:22PM -0700 Quoting S Moonesamy (s= m+ietf@elandsys.com): > Hello, >=20 > This is a draft of the Document Shepherd Write-Up. Please let me >=20 > The topic of obsoleting the SPF RRTYPE generated a lot of controversy n= ear > the end of the WGLC. There was an intermediate conclusion about the to= pic > before the WGLC and it was followed by an objection. After the discuss= ion > of the topic at the IETF 83 SPFBIS WG session the conclusion reached was > that the decision would be not to publish RRTYPE 99 and and not to query > RRTYPE 99. The WG consensus about the RRTYPE can be described as > particularly rough. There were a very high number of messages about the > topic on the SPFBIS mailing list and the DNSEXT mailing list as the > DNSEXT WG participants were not aware of RFC 6686. The DNSEXT participants have read, understood and dismissed 6686 as obsolet= e and incomplete. =20 --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Now I'm having INSIPID THOUGHTS about the beatiful, round wives of HOLLYWOOD MOVIE MOGULS encased in PLEXIGLASS CARS and being approached by SMALL BOYS selling FRUIT ... --AjmyJqqohANyBN/e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlHg9RcACgkQ02/pMZDM1cUGDwCferaM3hFlH6wf24NsPP/0/Zb9 makAn2KCkCUeerztKDq/4cHhtdhNJ8Ko =EOMA -----END PGP SIGNATURE----- --AjmyJqqohANyBN/e-- From superuser@gmail.com Sat Jul 13 00:23:11 2013 Return-Path: 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 F116E11E818C for ; Sat, 13 Jul 2013 00:23:11 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 WCbfnj3pV+D8 for ; Sat, 13 Jul 2013 00:23:11 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 36FBE11E8181 for ; Sat, 13 Jul 2013 00:23:11 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so1367336wid.4 for ; Sat, 13 Jul 2013 00:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cFqbaddq8p9U/w2hR2tCjuhJobHDZGjtoj2U4p3J+z0=; b=BhbmSe/Uff6MagGZ5OqnT3DV9dUNIanzqJmjHFat7XxoQS0dnF3y7trPgZHsrkQmmP fTQq999S9WxznqTBpb7RO+5ByT2cQPL7pDiWdSOUrqTV9kRvppXaC/cDLA2703Crq/L2 SBo/o1hPvhyS7nE3K3/zm5b1SAfZJZ4YPYUlCYZJGUSq5ywAv8XFk6HCeU/r3PxusPWL 3+ipHie8Nv8LfDQxFsUXL9k0+aTDsDWFKo/Ge2vvU6+HYIEVzQ1fGHMgilpip5hWnjsd VwLVvPv6spgyC9+5D90DTPjy6akMBks4u6knpNQbjMz2wuCp6IzHSwEnYLWn5iZWPDUu cbZw== MIME-Version: 1.0 X-Received: by 10.194.239.225 with SMTP id vv1mr26283880wjc.63.1373700189182; Sat, 13 Jul 2013 00:23:09 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Sat, 13 Jul 2013 00:23:09 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130712230437.0c345080@elandnews.com> References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> <6.2.5.6.2.20130712230437.0c345080@elandnews.com> Date: Sat, 13 Jul 2013 00:23:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=089e01493384cde0ae04e15f7f9d Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 07:23:12 -0000 --089e01493384cde0ae04e15f7f9d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 12, 2013 at 11:22 PM, S Moonesamy wrote: > > The ABNF checker flagged "authserv-id" "reasonspec", among others, as not > used. I could not find any reference to them in the draft. Could you > double-check that? > > They can be removed. Scott can confirm, but I think they were present in an example that has since been removed. -MSK --089e01493384cde0ae04e15f7f9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 12, 2013 at 11:22 PM, S Moonesamy <sm+ietf= @elandsys.com> wrote:

The ABNF checker flagged "authserv-id" "reasonspec", am= ong others, as not used. =A0I could not find any reference to them in the d= raft. =A0Could you double-check that?

=A0
They can be removed.=A0 Scott can confi= rm, but I think they were present in an example that has since been removed= .

-MSK

--089e01493384cde0ae04e15f7f9d-- From sm@elandsys.com Sat Jul 13 00:39:36 2013 Return-Path: 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 EF14C11E8181 for ; Sat, 13 Jul 2013 00:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 lLO+iRRiGJIH for ; Sat, 13 Jul 2013 00:39:36 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8084921F9433 for ; Sat, 13 Jul 2013 00:39:35 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.156.131]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6D7dGMM012185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Jul 2013 00:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373701168; bh=hNDsuaseer5SMF171UsgWEq9iPw5gwTIVgAjfpO862Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=d4Vniurvh6BC0SA1HH/5YG77G5w76TyRFLZE1800AXUul3kja612INFHHRRY9kYY2 hOGQDXu+nSUlYfwdLi9PZubeR043sHMdJ+v+VI/2KL0+wpYVTjKC/IiPrFjU9++nDZ PBJyi646wgz4pCd5sWToAvjv8J3GLl1v3VLqOJbo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1373701168; i=@elandsys.com; bh=hNDsuaseer5SMF171UsgWEq9iPw5gwTIVgAjfpO862Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JxUNIQsUC9UJ9rrF2v1vrWBDzbYvgtjRj1U12+MUbypg+yMGF9Y8/scHx45v/PpYu TStP5t1T9i/MTELRBgwsnKEoDySsBh40htZYV1YuKqLMezHE4dchK2HCoBv7QNJC2E HqoOZLt1hHMWnso1srLadnlBa9Frv+WTXiXWC8Bc= Message-Id: <6.2.5.6.2.20130713002931.0b394798@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 13 Jul 2013 00:39:04 -0700 To: "Murray S. Kucherawy" , Scott Kitterman From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> <6.2.5.6.2.20130712230437.0c345080@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 07:39:37 -0000 At 00:23 13-07-2013, Murray S. Kucherawy wrote: >They can be removed. Scott can confirm, but I think they were >present in an example that has since been removed. Murray, thanks. Scott, could you please review the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg03860.html and submit a revision of the draft? Please note that the cut-off for I-D submission is July 15 at 24:00 UTC. I'll send the publication request to the Responsible Area Director once the new version of the draft is available. Regards, S. Moonesamy (as document shepherd) From barryleiba.mailing.lists@gmail.com Sat Jul 13 11:36:52 2013 Return-Path: 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 8F88121F9CB9 for ; Sat, 13 Jul 2013 11:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 c8Ui-aOXGb65 for ; Sat, 13 Jul 2013 11:36:52 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2079721F9C96 for ; Sat, 13 Jul 2013 11:36:51 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w16so2315665vbb.37 for ; Sat, 13 Jul 2013 11:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5a/ZEi30etuF+uhuIxCLHNot1u0EvLjtL5N8qd2nfzI=; b=PnCQLnvEXsOJog1eFHc27aBoKAcAORREgzr+79IzynShO6DA8yvrO05gBJ6TPSgqwo keVldd78xq0hbA0DuFwTf5bC6g3PbwNspWkSL3wqIVfvmOTsaLivYgDb0XWAxBATHwI7 s9d9qmdyR9gvlH2gjwmvF9YtzEVLeiAxoc9S0MGyF1jI67NsQ2Cl9ezWYUAlhK1Xa82N osRvLoKKzrrCbw/WeaUoh/UK2RkBtIgmx5KphJhy2Rhr2/euri35Lv3/iac1o4iuVLuJ SE7bHbwHGURAsnZA9EF+T+Je0IgZGSB88Vlt/fiUsuWjYUOqjBF+08+8h8rqNPeXwsEo 1TUQ== MIME-Version: 1.0 X-Received: by 10.58.211.7 with SMTP id my7mr26457816vec.54.1373740610525; Sat, 13 Jul 2013 11:36:50 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Sat, 13 Jul 2013 11:36:50 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130712230437.0c345080@elandnews.com> References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> <6.2.5.6.2.20130712230437.0c345080@elandnews.com> Date: Sat, 13 Jul 2013 14:36:50 -0400 X-Google-Sender-Auth: mXUCOZJOQJIRQzl0RgDxDfTScy8 Message-ID: From: Barry Leiba To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7bd6b2b21a9e4f04e168e961 Cc: "spfbis@ietf.org" , "Murray S. Kucherawy" Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 18:36:52 -0000 --047d7bd6b2b21a9e4f04e168e961 Content-Type: text/plain; charset=ISO-8859-1 > > > There's a simplified shepherd write-up that the Applications Area ADs are >> asking us to use. I'll post a link to it later this evening if you can't >> find it yourself, but I think it's on the Applications Area wiki. >> > > I'll try and fit the answers in the new write-up template. Yes, please, unless Pete has specifically told you he prefers this one. (1) The type of RFC being requested is Proposed Standard. The draft >> describes >> version 1 of the Sender Policy Framework (SPF) protocol, whereby an >> Administrative Management Domain can explicitly authorize the hosts >> that are allowed to use its domain names, and a receiving host can >> check >> such authorization. The type is indicated in the title page header. >> >> Shouldn't this also mention the status and history of RFC4408 in a >> sentence or two? >> > > The answer to (1) is to say why the intended status is Proposed Standard. Yes, and a key reason is that this is specifically intended to bring the experimental RFC 4408 to Standards Track. I think most ADs know that, but that is key information for them to know. So yes, Murray is right. Barry --047d7bd6b2b21a9e4f04e168e961 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

There's a simplified shepherd write-up that the Applications Area ADs a= re asking us to use. =A0I'll post a link to it later this evening if yo= u can't find it yourself, but I think it's on the Applications Area= wiki.

I'll try and fit the answers in the new write-up template.
=

Yes, please, unless Pete has specifically told you he p= refers this one.

(1) The type of RFC being requested is Proposed Standard. =A0The draft desc= ribes
=A0 =A0 version 1 of the Sender Policy Framework (SPF) protocol, whereby an=
=A0 =A0 Administrative Management Domain can explicitly authorize the =A0ho= sts
=A0 =A0 that are allowed to use its domain names, and a receiving host can = check
=A0 =A0 such authorization. =A0The type is indicated in the title page head= er.

Shouldn't this also mention the status and history of RFC4408 in a sent= ence or two?

The answer to (1) is to say why the intended status is Proposed Standard.

Yes, and a key reason is that this is specif= ically intended to bring the experimental RFC 4408 to Standards Track. =A0I= think most ADs know that, but that is key information for them to know. = =A0So yes, Murray is right.

Barry=A0
--047d7bd6b2b21a9e4f04e168e961-- From hsantos@isdg.net Sun Jul 14 09:14:16 2013 Return-Path: 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 91A2921F9CEF for ; Sun, 14 Jul 2013 09:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 jhP5s1Is2vfM for ; Sun, 14 Jul 2013 09:14:11 -0700 (PDT) Received: from listserv.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0996C21F9E9C for ; Sun, 14 Jul 2013 09:14:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4359; t=1373818445; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=frBtAMd +9Foovi0cS5tpvraxwjQ=; b=H7ZgGp1wjIr1a+3tVZbMoL7BOAIKYj2cw43KlAF NRprV4/JtQlslUFSxORpsCvgGn17Q9q/Dyvj9XaWjUBLUamR5rmudsSegO43cwMk AvOiGreJOSvNGZnw6A65yZuKYwUHe9IqKuSeaK6ijcnD5rPvOd44MCZbvPLGuIfP sS0U= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 14 Jul 2013 12:14:05 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 280997816.13163.1192; Sun, 14 Jul 2013 12:14:03 -0400 Message-ID: <51E2CD94.2060408@isdg.net> Date: Sun, 14 Jul 2013 12:11:00 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> In-Reply-To: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 16:14:16 -0000 > Working Group Summary > > The decision about whether the SPF protocol has to reject mail or not > when the result of the evaluation is "Fail" was controversial. There > was WG consensus not to standardize SPF Best-guess processing. I don't think you intended to do this, but these are two different concepts. The way you have it can provide the erroneous implication that the SPF FAIL message rejection operations are some form of subjective "best-guessing" process. You need to clearly separate them and point out that Best-Guess is an independent concept outside the SPF protocol process, completely unrelated to actionable deterministic SPF FAIL policy. I think it is important to note that SPF FAIL rejection policies was the dominant inclination when it was invented, written early into the draft specifications and RFC 4408 documentation and that it is only a reflection of some modern deployments that DO NOT honor the policy, in the name of depending on user-based policies, hence the new highlights in the security concerns. > There was a suggestion to reorganize the document. It was argued > that the > document had become somewhat bloated with documentation of nuance and > other > text that has nothing to do with defining a protocol and enabling > interoperability. This led to a stalemate. Based on the discussion > during > the SFPBIS WG session at IETF 85 the WG decided to proceed with a > reorganization of the document while ensuring that the reorganization > did > not create any text changes apart from moving text around. Which I do not believe was fully achieved. Any current deployment who reads this doc will need to ignore it if he doesn't wish to impose change work for his SPF operation. > > The topic of obsoleting the SPF RRTYPE generated a lot of controversy > near > the end of the WGLC. There was an intermediate conclusion about the > topic > before the WGLC and it was followed by an objection. After the > discussion > of the topic at the IETF 83 SPFBIS WG session the conclusion reached was > that the decision would be not to publish RRTYPE 99 and and not to query > RRTYPE 99. The WG consensus about the RRTYPE can be described as > particularly rough. There were a very high number of messages about the > topic on the SPFBIS mailing list and the DNSEXT mailing list as the > DNSEXT WG participants were not aware of RFC 6686. It should be noted that this was a long time understood design and development issue and the migration path initially envisioned was on par with what has occurred in the market albeit slow. A note should be stated with how TXT based solution is more acceptable today than yester-years, hence why its allowed to be used. > Document Quality > > There are multiple existing implementations of the SPF protocol. The > document was reviewed by the SPFBIS working group. Dave Crocker, > Cyrus Daboo, Stuart Gathman, Murray Kucherawy, John Levine, > Andrew Sullivan, Arthur Thisell, and Alessandro Vesely reviewed the > document. Simon Perreault helped to clarify the meaning of > IPv4 mapped IPv6 addresses. Murray Kucherawy deserves a special > mention for his contributions. There are a lot of folks who contributed to this, even if it was done with resistance. No one here acts by him/her-self. Synergism is in effect. > (16) The publication of this document changes the status of RCC 4408 > to obsolete. I believe the draft is updated enough to warrant TWO different declarations of supports; RFC4408 level only or this new RFC4408BIS level of support. So until current 4408 implementations are ready to begin supporting all or some of the new changes in BIS, RFC4408 will not be "obsolete" to them. For me, this 4408BIS is not an easy PLUG AND PLAY update to 4408. For example, one can stay with 4408 and remain compliant, and make the CLAIM he is compliant without adding AUTH-RES and REJECTING with FAIL. The don't have to worry about the security concerns of attempted to accept SPF failed mail in the name of using AUTH-RES results and crossing fingers, post-processing components will negatively classify the SPF FAILed-by-policy message. In short, I don't think this document is ready for any future "Internet Standard" promotion declaration without additional changes. -- HLS From sm@elandsys.com Sun Jul 14 17:27:11 2013 Return-Path: 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 DE69421F99DB for ; Sun, 14 Jul 2013 17:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 oUQP6wiDwYuz for ; Sun, 14 Jul 2013 17:27:11 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EA921F99F8 for ; Sun, 14 Jul 2013 17:27:10 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.153.203]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6F0Ql9X025440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jul 2013 17:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373848021; bh=k0dHTgvbjfIxgJJ/vBMYgR6S8wwEiamtchSbKkEhCE8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=z0m2FFc/S5qSY30sMtrt8r2LUfr/Wuxd64izHP38SkPBXwZ/tmhxpZ44uIlizkVRT wD6DTFea5bs+ux4q7OOlC5o4sSd3toh0R2dlXG4EzmBDbjF+sDO+RV6WFotuo/ekkK g55P2+ICP66/3QYxxDiB8DYweTROIwhppy0OySXI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1373848021; i=@elandsys.com; bh=k0dHTgvbjfIxgJJ/vBMYgR6S8wwEiamtchSbKkEhCE8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4Y75plPRjRprnfabRWWXsetvOZ5dA0NpqNiHvMhW2oiMhtGfSGu8WXJ/GntdYk2TV sl1thlslPotNZHM/ZOsIivZXe+qWaHRFgLVTvbbQIizHLeAi8riccQkzSLlY80g6su tGq2wElUV1QYDML+tVHE6spZDEYoxYBSAA3G7RRs= Message-Id: <6.2.5.6.2.20130714145601.075e3838@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 14 Jul 2013 15:33:48 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20130713063503.GE15374@besserwisser.org> References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> <20130713063503.GE15374@besserwisser.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: mansaxel@besserwisser.org, Hector Santos , Barry Leiba Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 00:27:12 -0000 At 23:35 12-07-2013, Nilsson wrote: >The DNSEXT participants have read, understood and dismissed 6686 as >obsolete and incomplete. Ok. The text I wrote says is based on comments I saw in the SPFBIS mailing list archive. At 11:36 13-07-2013, Barry Leiba wrote: >Yes, please, unless Pete has specifically told you he prefers this one. I'll use the new write-up. >Yes, and a key reason is that this is specifically intended to bring >the experimental RFC 4408 to Standards Track. I think most ADs know >that, but that is key information for them to know. So yes, Murray is right. I'll add that. At 09:11 14-07-2013, Hector Santos wrote: >I don't think you intended to do this, but these are two different >concepts. The way you have it can provide the erroneous implication >that the SPF FAIL message rejection operations are some form of >subjective "best-guessing" process. Ok. I read the text again and I see that it can be misinterpreted. I'll fix that. >Which I do not believe was fully achieved. Any current deployment >who reads this doc will need to ignore it if he doesn't wish to >impose change work for his SPF operation. If there is any strong discontent, other than for the SPF RRTYPE, please send me a message with details so that I can explain the problem to the Area Director. >It should be noted that this was a long time understood design and >development issue and the migration path initially envisioned was on >par with what has occurred in the market albeit slow. A note >should be stated with how TXT based solution is more acceptable >today than yester-years, hence why its allowed to be used. The write-up I wrote is to give a quick summary of the WG discussions. The persons taking the decision about the draft can ask for more information if they consider it as useful. >I believe the draft is updated enough to warrant TWO different >declarations of supports; RFC4408 level only or this new RFC4408BIS >level of support. So until current 4408 implementations are ready >to begin supporting all or some of the new changes in BIS, RFC4408 >will not be "obsolete" to them. That text was about RFC details and "obsolete" is applicable within a RFC context. >In short, I don't think this document is ready for any future >"Internet Standard" promotion declaration without additional changes. The intended status of the draft is not "Internet Standard". Regards, S. Moonesamy From spf2@kitterman.com Sun Jul 14 18:21:05 2013 Return-Path: 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 99F1621F9A37 for ; Sun, 14 Jul 2013 18:21:04 -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=[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 hZ4bRc3lRwFE for ; Sun, 14 Jul 2013 18:21:00 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0B15A21F9A38 for ; Sun, 14 Jul 2013 18:21:00 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 94E8B20E40D6; Sun, 14 Jul 2013 21:20:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1373851257; bh=MFpQTZ17FzrGCdyy+kVrc+EK+nuxja9sgpVYK3XMWQA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JxSetQAUnzN7+9Q3B92F4Mc15X206qzEn6DjTtJBJ38xf8/ape5LY+EkoukwHcItt iG/X0eBTyYVDmIjqlcGfs63K8te0zqGpzD4aO9TcxIMDoLnbZjauDxKPjViaVsZIPv ouf0POGi53KS6KNGBC9vBzXrKjIMq71kmlp9YA7w= Received: from scott-latitude-e6320.localnet (unknown [97.89.236.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5449520E40B0; Sun, 14 Jul 2013 21:20:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 14 Jul 2013 21:20:54 -0400 Message-ID: <2610013.0CK9LB9p0Z@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-26-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 01:21:05 -0000 On Friday, July 12, 2013 02:11:22 PM S Moonesamy wrote: > Hello, > > This is a draft of the Document Shepherd Write-Up. Please let me > know if I missed anything important. I added a comment in (10) about > extreme discontent during the WGLC. Please email me off-list if you > are of the opinion that there is an issue which has not been > addressed correctly. > > (1) The type of RFC being requested is Proposed Standard. The draft > describes version 1 of the Sender Policy Framework (SPF) protocol, whereby > an Administrative Management Domain can explicitly authorize the hosts > that are allowed to use its domain names, and a receiving host can check > such authorization. The type is indicated in the title page header. > > (2) The approval announcement contains the following sections: > > Technical Summary > > This document describes version 1 ofthe Sender Policy Framework > (SPF) protocol, whereby an Administrative Management Domain can > explicitly authorize the hosts that are allowed to use its > domain names, and a receiving host can check such authorization. > > Working Group Summary Most of the SPF protocol was non-controversial and supported by the WG. I think the summary should start out to this effect. By just listing issues and their resolution, I think the summary reads far too negatively. > The decision about whether the SPF protocol has to reject mail or not > when the result of the evaluation is "Fail" was controversial. There > was WG consensus not to standardize SPF Best-guess processing. This should be split into two paragraphs as it's two different contexts (as Hector said). I think it was the question of what 4408bis should say about receiver policy that was controversial. Here's what I'd recommend: RFC 4408 (the experimental RFC for SPF that this obsoletes) says very little about policy actions for mail receivers. It was a matter of some significant discussion whether 4408bis should provide more or less guidance. The (rough) consensus was to keep the level of guidance to receivers consistent with what RFC 4408 provides. There was discussion about standardizing so called "best guess" heuristics to guess possible SPF policies for domains that do not publish an SPF record. The consensus of the group was not to do this. > The issue of mail forwarding and mailing lists in respect to the SPF > protocol was not too controversial in comparison with the other > controversies. There was some controversy about whether the use of > macros was a security risk and whether to deprecate the PTR feature. > > There was a formal appeal of the SPFBIS WG chair' interpretation of the > charter, specifically regarding the removal of "unused" features. The > two features in particular which drove the appeal were the PTR feature > and the local-part macro feature. These features were not removed from > the document given that the appeal was denied by the Responsible Area > Director. I think it's more correct to say that removal wasn't considered by the WG since it was out of scope based on the charter. We never really go to the merits of it they should be removed or not. > There was significant discussion about whether to use the "Received-SPF:" > header field or whether to use the "Authentication-Results" header field to > record the results of a SPF evaluation. The working group decided to add > both header fields in the document as they are in common use. > > There was a suggestion to reorganize the document. It was argued that > the document had become somewhat bloated with documentation of nuance and > other text that has nothing to do with defining a protocol and enabling > interoperability. This led to a stalemate. Based on the discussion during > the SFPBIS WG session at IETF 85 the WG decided to proceed with a > reorganization of the document while ensuring that the reorganization did > not create any text changes apart from moving text around. > > The topic of obsoleting the SPF RRTYPE generated a lot of controversy > near the end of the WGLC. There was an intermediate conclusion about the > topic before the WGLC and it was followed by an objection. After the > discussion of the topic at the IETF 83 SPFBIS WG session the conclusion > reached was that the decision would be not to publish RRTYPE 99 and and not > to query RRTYPE 99. The WG consensus about the RRTYPE can be described as > particularly rough. There were a very high number of messages about the > topic on the SPFBIS mailing list and the DNSEXT mailing list as the DNSEXT > WG participants were not aware of RFC 6686. You might add something like: RFC 4408 suffers from an interoperability deficiency. SPF records can be published in either type TXT or type SPF (99). SPF record queries can be done in either type TXT or type SPF (99). There is no common mandatory RR type for both publishing and retrieving SPF records. Based on current deployment (virtually all domains that publish SPF records publish type TXT records), the working group concluded that the only logical type to make mandatory for publishing and receiving was, from the perspective of interoperability, was TXT. The working group also reviewed inputs from multiple participants with operational and implementation experience regarding the usability of type SPF. The rough consensus of the group was that continuing to provide the alternate type SPF RR type would only promote continued interoperability issues and was unlikely to gain significant deployment in the future. > > Document Quality > > There are multiple existing implementations of the SPF protocol. The > document was reviewed by the SPFBIS working group. Dave Crocker, > Cyrus Daboo, Stuart Gathman, Murray Kucherawy, John Levine, > Andrew Sullivan, Arthur Thisell, and Alessandro Vesely reviewed the > document. Simon Perreault helped to clarify the meaning of > IPv4 mapped IPv6 addresses. Murray Kucherawy deserves a special > mention for his contributions. > > Personnel > > S. Moonesamy is the Document Shepherd for this document. Pete Resnick > is the Responsible Area Director. > > (3) I have personally reviewed draft-ietf-spfbis-4408bis-16. I believe that > the draft is reading for forwarding to the IESG for publication. > > (4) This document has been reviewed by several SPFBIS WG participants. > The document has also been reviewed by Andrew Sullivan. I do not have > any concerns about the depth and breath of the reviews performed. > > (5) The document was reviewed by Cyrus Daboo on behalf of the Applications > Area Directorate. Simon Perreault reviewed the IPv6-related text in > Section 5. I suggest further review of the document from a DNS > perspective. > > (6) I do not have any specific concerns or issues with the document. > > (7) The author confirmed that any and all appropriate IPR disclosures > required for full conformance with the provisions of BCP 78 and > BCP 79 have already been filed. > > (8) There are no IPR disclosures referencing this document. I think this one is relevant: https://datatracker.ietf.org/ipr/1698/ > (9) There is rough consensus within the WG to publish the document. > The decision to obsolete the SPF RRTYPE was very controversial. > > (10) Nobody has threatened an appeal during the WGLC. Some WG > participants have mentioned that they may express extreme > discontent during the Last Call. > > (11) Id-nits lists a non-RFC2606-compliant FQDN, six non-RFC5735-compliant > IPv4 addresses and one instance of a private range IPv4 address. > These warnings can be ignored. The warning about CFWS is incorrect. > The reference to RFC 2671 is intentional; the document also > references RFC 6891. > > (12) The document does not require any formal review. > > (13) All references within this document been identified as either > normative or informative. > > (14) The document normatively references RFCs. > > (15) There is a downward reference to RFC 5598. > > (16) The publication of this document changes the status of RCC 4408 > to obsolete. > > (17) IANA action is requested to update the Resource Record (RR) > TYPEs registry. The "Received-SPF:" header field is > being added to the Permanent Message Header Field Registry. > Action is requested to update the SPF Modifier Registry. > > (18) The document does not create any IANA registries. > > (19) An automated check of the ABNF in Appendix A was performed. > > Regards, > S. Moonesamy > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Sun Jul 14 18:26:35 2013 Return-Path: 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 0346721F93F3 for ; Sun, 14 Jul 2013 18:26: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=[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 GgJID1xmub2r for ; Sun, 14 Jul 2013 18:26:30 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E4E0021F9346 for ; Sun, 14 Jul 2013 18:26:29 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7989B20E40D6; Sun, 14 Jul 2013 21:26:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1373851589; bh=b7zkzqjPHz2XKRIznNY+Iu35IU3Sp4gtVvwOVqFD5qA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=M4yq7c+JIcP3fBb0P66HpV/UxCHfAT0CgGUCtwepbi/02ENIdrC5ql8bSVouA3O/b p4V4hsrb0oe2v4vzQooFIcSP0SPw4ZsGR537/yGRZAPN+pLTGodzQAqhpFc4WdH8Iy X3QldtYcGjhppAXZFs7IW0p4z/g5XSKY04Y7q2ug= Received: from scott-latitude-e6320.localnet (unknown [97.89.236.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 58D2720E40B0; Sun, 14 Jul 2013 21:26:28 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 14 Jul 2013 21:26:26 -0400 Message-ID: <10411051.c4ViuD1v35@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-26-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130712230437.0c345080@elandnews.com> References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> <6.2.5.6.2.20130712230437.0c345080@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 01:26:35 -0000 On Friday, July 12, 2013 11:22:17 PM S Moonesamy wrote: > The ABNF checker flagged "authserv-id" "reasonspec", among others, as > not used. I could not find any reference to them in the > draft. Could you double-check that? They were used at one point, but aren't now. I'll remove them. Scott K From spf2@kitterman.com Sun Jul 14 18:31:16 2013 Return-Path: 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 2A61A21F8F38 for ; Sun, 14 Jul 2013 18:31:16 -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=[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 S0Gr8YPgFEx8 for ; Sun, 14 Jul 2013 18:31:11 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 174EA21F8F2E for ; Sun, 14 Jul 2013 18:31:11 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9CA9B20E40D6; Sun, 14 Jul 2013 21:31:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1373851870; bh=zzvYha4S9vsLUoql8QdnQ100mRUAlQIlrMr+MfdoedE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pLe8bnK1IcZXO3yeChLPpqcZ8qW3yPCjnTWQTWFnMQ7/4lYwZ6WJ6KS1+2Gip+UkW gdoukCgtSOEfCpvB0G2r5xDlbtRrXR6kgUTooo8i0hIoS1VhDZMmPP4mdbl33ZQqc4 RKR/0jpS1D/jTqSdJhMylTaHAp/JKRdG8kYVsEys= Received: from scott-latitude-e6320.localnet (unknown [97.89.236.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7813920E40B0; Sun, 14 Jul 2013 21:31:10 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 14 Jul 2013 21:31:09 -0400 Message-ID: <5874246.RZdXFB3LMN@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-26-generic; KDE/4.10.5; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> <6.2.5.6.2.20130712230437.0c345080@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 01:31:16 -0000 On Saturday, July 13, 2013 12:23:09 AM Murray S. Kucherawy wrote: > On Fri, Jul 12, 2013 at 11:22 PM, S Moonesamy wrote: > > The ABNF checker flagged "authserv-id" "reasonspec", among others, as not > > used. I could not find any reference to them in the draft. Could you > > double-check that? > > They can be removed. Scott can confirm, but I think they were present in > an example that has since been removed. That's correct. Scott K From spf2@kitterman.com Sun Jul 14 18:45:28 2013 Return-Path: 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 E612B21F9D66 for ; Sun, 14 Jul 2013 18:45:27 -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 LwopNGZOf4dx for ; Sun, 14 Jul 2013 18:45:23 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 772A621F9D65 for ; Sun, 14 Jul 2013 18:45:23 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 863CF20E40D6; Sun, 14 Jul 2013 21:45:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1373852716; bh=RtXLhr0grEG03Pt/NkVNkQVRYLN+1QQvLY2Hobldfy4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TYbJG/HSL4Poc+r/L6CnhtpKaz58kKvsZyVTCZKH0r/hIw6sXL6iIn9VMVLBHfRAj ZO5MQ3Zv9spRH45pWSLYR6F7vIq0IoDFehPW0HlX6y/1HEgoZI7W/bOhs1Ato5ahW2 Gcu4s5LFJQtd6NfN6VoPSpyiaq88NVO4TtB+mCeM= Received: from scott-latitude-e6320.localnet (unknown [97.89.236.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6308720E40B0; Sun, 14 Jul 2013 21:45:16 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 14 Jul 2013 21:45:14 -0400 Message-ID: <20819035.zX95EMerxB@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-26-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130713002931.0b394798@elandnews.com> References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> <6.2.5.6.2.20130713002931.0b394798@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 01:45:28 -0000 On Saturday, July 13, 2013 12:39:04 AM S Moonesamy wrote: > At 00:23 13-07-2013, Murray S. Kucherawy wrote: > >They can be removed. Scott can confirm, but I think they were > >present in an example that has since been removed. > > Murray, thanks. > > Scott, could you please review the message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg03860.html and > submit a revision of the draft? Please note that the cut-off for I-D > submission is July 15 at 24:00 UTC. Done. Submitting momentarily. Scott K From internet-drafts@ietf.org Sun Jul 14 19:04:18 2013 Return-Path: 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 C1B5721F9546; Sun, 14 Jul 2013 19:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 Mc-hCYSa+Maj; Sun, 14 Jul 2013 19:04:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D92D21F9D7E; Sun, 14 Jul 2013 19:04:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715020414.6955.65151.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 19:04:14 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-17.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 02:04:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Sender Policy Framework (SPF) for Authorizing Use of Dom= ains in Email, Version 1 Author(s) : Scott Kitterman Filename : draft-ietf-spfbis-4408bis-17.txt Pages : 75 Date : 2013-07-14 Abstract: Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. This document obsoletes RFC4408. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sm@elandsys.com Mon Jul 15 07:19:15 2013 Return-Path: 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 7E7A421F9C4F for ; Mon, 15 Jul 2013 07:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 eJT-C4Ay38jU for ; Mon, 15 Jul 2013 07:19:14 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9036521F9AA3 for ; Mon, 15 Jul 2013 07:19:14 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.130.81]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6FEJ1Pa006050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 07:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373897953; bh=FtmErNWNwVNO86heNez3vJ2XcmDDxWE7dj6eQ4NoAfk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=WR07qk8loDz9Iu9SSDShx0MpqXOkgL/7Y65OLZsZ7zrMg3nk6Y8py9aO5JiYnxhoB pc4aMmPEeLqf+lNrTgLdka0QywN3G3Xt+ck/g8F7tG5KROzAtRKcdbBua/rgqSPSHv xAkXOB73CrXorGgeZHXDvUBbr0/lXLn8Os1CKh2g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1373897953; i=@elandsys.com; bh=FtmErNWNwVNO86heNez3vJ2XcmDDxWE7dj6eQ4NoAfk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dKRk3Rj8OXMOlJ4yPWERxMTGHEUaJFx2gjCGD4RFyMZAbnbDZQU8Sh8gbiXxwFtOK Fp0Hw8A6AGs/yH8gpE1AdIH755W4A6bvx7+WV2Syvr5tfRlpl4jSeYOizFIwZvSUgd nmFQWj3FMcbDdCgr3lU4dxRqAlhf6SyIsz5RxOyc= Message-Id: <6.2.5.6.2.20130715061909.0c8b9380@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 15 Jul 2013 07:04:57 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <2610013.0CK9LB9p0Z@scott-latitude-e6320> References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> <2610013.0CK9LB9p0Z@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 14:19:15 -0000 Hi Scott, At 18:20 14-07-2013, Scott Kitterman wrote: >Most of the SPF protocol was non-controversial and supported by the WG. I >think the summary should start out to this effect. By just listing >issues and >their resolution, I think the summary reads far too negatively. The summary is to provide information about anything in the WG process that is worth writing about. I prefer to focus on the issues as that is the information which I may be asked about. >This should be split into two paragraphs as it's two different contexts (as >Hector said). I think it was the question of what 4408bis should say about Yes. >receiver policy that was controversial. Here's what I'd recommend: > >RFC 4408 (the experimental RFC for SPF that this obsoletes) says very little >about policy actions for mail receivers. It was a matter of some significant >discussion whether 4408bis should provide more or less guidance. The (rough) >consensus was to keep the level of guidance to receivers consistent with what >RFC 4408 provides. I may reuse some of the text you recommended. I have to go through the SPFBIS mail archives again to review the discussion. >I think it's more correct to say that removal wasn't considered by the WG >since it was out of scope based on the charter. We never really go to the >merits of it they should be removed or not. I reused some text from messages posted to this mailing list. >You might add something like: > >RFC 4408 suffers from an interoperability deficiency. SPF records can be >published in either type TXT or type SPF (99). SPF record queries >can be done >in either type TXT or type SPF (99). There is no common mandatory >RR type for >both publishing and retrieving SPF records. Based on current deployment >(virtually all domains that publish SPF records publish type TXT >records), the >working group concluded that the only logical type to make mandatory for >publishing and receiving was, from the perspective of interoperability, was >TXT. The working group also reviewed inputs from multiple participants with >operational and implementation experience regarding the usability of >type SPF. >The rough consensus of the group was that continuing to provide the alternate >type SPF RR type would only promote continued interoperability issues and was >unlikely to gain significant deployment in the future. My preference is to keep it short as the working group already documented the above. >I think this one is relevant: > >https://datatracker.ietf.org/ipr/1698/ Thanks for catching this. I'll mention the IPR disclosure in the write-up. I'll post the write-up today. Thanks for submitting draft-ietf-spfbis-4408bis-17. I'll mention the downward-reference for RFC 1983. The next step is for the Responsible Area Director to review the draft. Regards, S. Moonesamy From ajs@anvilwalrusden.com Mon Jul 15 07:54:35 2013 Return-Path: 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 D4C8C11E8132 for ; Mon, 15 Jul 2013 07:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.757 X-Spam-Level: X-Spam-Status: No, score=-0.757 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 0etjHDO0LzZ6 for ; Mon, 15 Jul 2013 07:54:30 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7671011E813A for ; Mon, 15 Jul 2013 07:54:22 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id EDEE08A031 for ; Mon, 15 Jul 2013 14:54:19 +0000 (UTC) Date: Mon, 15 Jul 2013 10:54:27 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130715145427.GB14831@mx1.yitter.info> References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> <20130713063503.GE15374@besserwisser.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130713063503.GE15374@besserwisser.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 14:54:36 -0000 On Sat, Jul 13, 2013 at 08:35:04AM +0200, Måns Nilsson wrote: > > The DNSEXT participants have read, understood and dismissed 6686 as obsolete and incomplete I think it would be extraordinarily inappropriate for the shepherd of a doc from one WG to include in a PROTO write-up such a strong claim about consensus on another mailing list -- particularly since no such consensus call has been made there. A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Mon Jul 15 08:54:05 2013 Return-Path: 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 2BFE221E80D8 for ; Mon, 15 Jul 2013 08:54:05 -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=[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 MItA3w+43elQ for ; Mon, 15 Jul 2013 08:54:00 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 325E611E8174 for ; Mon, 15 Jul 2013 08:53:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6BDDC20E40F6; Mon, 15 Jul 2013 11:53:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1373903611; bh=GGe5XKCfzQHROaLN0VEkfmEHrfX+FS0m8HIKMPXFwzg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nDCw5FYXfUuRaUd4rhrtvEQhHmYWdrRrX9KP2duePgu189O0XMhCQ6KB77pEpR5Nd u6LLAHtnc7ZGu5hi9FN+iNASw0tZRACZPK5RMv7XlQK5Dm2Qd+9MR5KYXU0dV4KrQ/ Uu8JF+HHJeRmCfVa0wPi5QXAyfjpXuE8m0p3sbbc= Received: from scott-latitude-e6320.localnet (unknown [97.89.236.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 48DFB20E4076; Mon, 15 Jul 2013 11:53:30 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 15 Jul 2013 11:53:30 -0400 Message-ID: <1596926.ihyzVcu2sP@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-26-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130715061909.0c8b9380@resistor.net> References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> <2610013.0CK9LB9p0Z@scott-latitude-e6320> <6.2.5.6.2.20130715061909.0c8b9380@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:54:05 -0000 On Monday, July 15, 2013 07:04:57 AM S Moonesamy wrote: > Hi Scott, > > At 18:20 14-07-2013, Scott Kitterman wrote: > >Most of the SPF protocol was non-controversial and supported by the WG. I > >think the summary should start out to this effect. By just listing > >issues and > >their resolution, I think the summary reads far too negatively. > > The summary is to provide information about anything in the WG > process that is worth writing about. I prefer to focus on the issues > as that is the information which I may be asked about. Your call obviously, since it's your writeup, but I think taking the experimental protocol and generally agreeing it should move forward is certainly relevant. Scott K From hsantos@isdg.net Mon Jul 15 09:24:09 2013 Return-Path: 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 3349311E8186 for ; Mon, 15 Jul 2013 09:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.056 X-Spam-Level: X-Spam-Status: No, score=-102.056 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] 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 yC33b20sTXsi for ; Mon, 15 Jul 2013 09:24:04 -0700 (PDT) Received: from groups.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 76A0211E812C for ; Mon, 15 Jul 2013 09:23:20 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2759; t=1373905393; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=IIWsxmI hE25c7DlIzCxG5g4emsA=; b=C83MOg4Cczui/cnwYmEOiHNLa9DP7ZRLugbfe4Y rDG3ViuYTnU3LCudzm1msz5FXVI4UvCMFNpaXgc8achI27IuhO89UVhc2uG8UFs8 PaDl9ezw4tjbDOQtYSxytVX9EvCrg12dA1KM8ehEBN7/9w9W8Y5SJUNVsRBGMoAd FeWg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 15 Jul 2013 12:23:13 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 367945722.3.800; Mon, 15 Jul 2013 12:23:12 -0400 Message-ID: <51E42138.1000701@isdg.net> Date: Mon, 15 Jul 2013 12:20:08 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130715020414.6955.65151.idtracker@ietfa.amsl.com> In-Reply-To: <20130715020414.6955.65151.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Scott Kitterman , S Moonesamy Subject: [spfbis] Spelling errors [was: I-D Action: draft-ietf-spfbis-4408bis-17.txt] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:24:09 -0000 I ran a spell checker and found a number of typos: - section 2.5, 1st sentence "recieves" spelling error. Remember, i before e accept after c. - section 7.3, I don't think the past tense usage "uppercased" and "lowercased" are valid here. I think it should be: Uppercase macros expand exactly as their lowercase equivalents, ... - Appendix F, 2nd para "mitiate" spelling error - Section H.2, 3rd para. Spelling error with the word "reliabilility" - H.4. 4th para, "perferable' spelling error Small Nit: - Section B.4, I don't see how "De Morgan's Law" applies here. De Morgan's law as I was taught to use it and have applied it over the decades of software development allows for the expansion or reduction of complex boolean logic to its SIMPLEST wiring, circuitry, logic PHYSICALLY possible . This is because there is no such things as OR gates, only AND gates and using De Morgan's theorem you can reproduce, emulate, etc, the desired OR, NOR, XOR gates, etc circuitry, e.g.; an notted OR gate is equal to notted input AND gate. I don't quite see how this applies nor necessary for the example cited. -- HLS On 7/14/2013 10:04 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SPF Update Working Group of the IETF. > > Title : Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 > Author(s) : Scott Kitterman > Filename : draft-ietf-spfbis-4408bis-17.txt > Pages : 75 > Date : 2013-07-14 > > Abstract: > Email on the Internet can be forged in a number of ways. In > particular, existing protocols place no restriction on what a sending > host can use as the "MAIL FROM" of a message or the domain given on > the SMTP HELO/EHLO commands. This document describes version 1 of > the Sender Policy Framework (SPF) protocol, whereby ADministrative > Management Domains (ADMDs) can explicitly authorize the hosts that > are allowed to use its domain names, and a receiving host can check > such authorization. > > This document obsoletes RFC4408. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-17 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-17 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From vesely@tana.it Mon Jul 15 11:26:52 2013 Return-Path: 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 9C31711E8105 for ; Mon, 15 Jul 2013 11:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.032 X-Spam-Level: X-Spam-Status: No, score=-5.032 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 T0fDGcWHetaH for ; Mon, 15 Jul 2013 11:26:48 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1608C11E81BD for ; Mon, 15 Jul 2013 11:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1373912806; bh=JUqykbQiI+YGDxxtjoN1cYRMw+7v72p5EfNucqibbfo=; l=1533; h=Date:From:To:References:In-Reply-To; b=hNVZz/6i4SFrqFuo9h0YhyuNHeVgapsjJA4Ie+j5NgUVroWBunDAq8w6CISNVsvk7 7CJGLT5oHTYYGFPF8vRPlH6avjVsGNJhtRZwKJq0KxU0OD89dASwInZCkzUqChA04e e9cI/1vkt2s8aZ880rB08AoubqaVddyIwPRn17I4= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 15 Jul 2013 20:26:46 +0200 id 00000000005DC039.0000000051E43EE6.0000108A Message-ID: <51E43EE6.7070507@tana.it> Date: Mon, 15 Jul 2013 20:26:46 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130704 Icedove/17.0.7 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> <2610013.0CK9LB9p0Z@scott-latitude-e6320> <6.2.5.6.2.20130715061909.0c8b9380@resistor.net> In-Reply-To: <6.2.5.6.2.20130715061909.0c8b9380@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:26:52 -0000 On Mon 15/Jul/2013 16:04:57 +0200 S Moonesamy wrote: > At 18:20 14-07-2013, Scott Kitterman wrote: > >> You might add something like: >> >> RFC 4408 suffers from an interoperability deficiency. SPF >> records can be published in either type TXT or type SPF (99). >> SPF record queries can be done in either type TXT or type SPF >> (99). There is no common mandatory RR type for both publishing >> and retrieving SPF records. Based on current deployment >> (virtually all domains that publish SPF records publish type TXT >> records), the working group concluded that the only logical type >> to make mandatory for publishing and receiving was, from the >> perspective of interoperability, was TXT. The working group also >> reviewed inputs from multiple participants with operational and >> implementation experience regarding the usability of type SPF. >> The rough consensus of the group was that continuing to provide >> the alternate type SPF RR type would only promote continued >> interoperability issues and was unlikely to gain significant >> deployment in the future. > > My preference is to keep it short as the working group already > documented the above. I agree that Scott's text is too long. However, I too recollect that the WG rough consensus was that directing new or revised implementations to query TXT type only is the most stable solution for the foreseeable future. That consensus was reached before the end of the WGLC. IMHO, it oughts to be mentioned. Thanks for shepherding From sm@elandsys.com Mon Jul 15 12:15:02 2013 Return-Path: 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 60A5A21E811D for ; Mon, 15 Jul 2013 12:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 B+s3cOtrNP4I for ; Mon, 15 Jul 2013 12:15:01 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AF521E8133 for ; Mon, 15 Jul 2013 12:14:59 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.130.81]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6FJEjmA014321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 12:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373915698; bh=MGgrQ2BC+Ge0uvygQzARjY+NqM3Qz79LDLxmqQWowe0=; h=Date:To:From:Subject:Cc; b=z/drIwn7+J3CE9PmsHwnCqvtbmhThtI5I8ryXxsmVNyJV83K0xnAyaIUD4+5TE2nA SBmFXWxWHOMrU/LCmQgjjSYnz/3TNIU9sdlG9oTBUDot924jEPgEGuqAiHwPqVmAQE jbDdNx+bFGfzsPimCKDvVWhgzTJtm62VyztUto4k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1373915698; i=@elandsys.com; bh=MGgrQ2BC+Ge0uvygQzARjY+NqM3Qz79LDLxmqQWowe0=; h=Date:To:From:Subject:Cc; b=BFSmIrpkPpMbNatBoXCYPN8aSKB+WQWmT/MJuXhMVbUdxnUKR6wHuMzVPExNf/vfs 4Aylr/D/egJ0kyHTtmav8PCKy/B7pG6T6hMk1QsIqHc9V9xcdScF82ivBxn4ZoK7tK OTN4MmGYsOYjNjHRFwe3WBcMzxh9zksT2AjHwq78= Message-Id: <6.2.5.6.2.20130715072155.0c8d3f70@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 15 Jul 2013 09:53:40 -0700 To: Pete Resnick From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: [spfbis] Publication request for draft-ietf-spfbis-4408bis-17 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:15:02 -0000 Hi Pete, The SPFBIS working group requests publication of draft-ietf-spfbis-4408bis-17. The Document Shepherd Write-Up is below. Summary S. Moonesamy is the Document Shepherd for this document. Pete Resnick is the Responsible Area Director. draft-ietf-spfbis-4408bis describes version 1 of the Sender Policy Framework (SPF) protocol, whereby Administrative Management Domains can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. The working group was chartered to produce a document as a Proposed Standard defining the SPF protocol based upon RFC 4408 (Experimental). Review and Consensus This document is a product of the SPFBIS working group, and has been through a large number of revisions including a complete reorganization of the document. The working group dealt with a number of controversial topics. The following outlines how those were resolved: There was an intermediate conclusion about the topic of whether the SPF protocol should use the SPF RRTYPE or the TXT resource record. It was followed by an objection. After discussion of the topic at the IETF 83 SPFBIS WG session the conclusion reached was that the decision would be not to publish RRTYPE 99 and and not to query RRTYPE 99. The WG consensus about the RRTYPE can be described as particularly rough. The topic of obsoleting the SPF RRTYPE generated a lot of controversy near the end of the WGLC. There were a very high number of messages about the topic on the SPFBIS mailing list and the DNSEXT mailing list as some DNSEXT WG participants were not aware of RFC 6686. The topic of whether the SPF protocol has to reject mail or not when the result of the evaluation is "Fail" was actively discussed. It was determined that it was a matter of local policy. There was discussion about standardizing the "best guess" heuristics to guess possible SPF policies for domains that do not publish an SPF record. The WG consensus was not to standardize the heuristics. The topic of mail forwarding and mailing lists in respect to the SPF protocol was not too controversial in comparison with the other controversies. The WG consensus was to have the document discuss about the topic in a non-normative manner. There was some controversy about whether the use of macros was a security risk and whether to deprecate the PTR feature. There was a formal appeal of the SPFBIS WG chair' interpretation of the charter, specifically regarding the removal of "unused" features. The two features in particular which drove the appeal were the PTR feature and the local-part macro feature. These features were not removed from the document given that the appeal was denied by the Responsible Area Director. There was significant discussion about whether to use the "Received-SPF:" header field or whether to use the "Authentication-Results" header field to record the results of a SPF evaluation. The working group decided to add both header fields in the document as they are in common use. There was a suggestion to reorganize the document. It was argued that the document had become somewhat bloated with documentation of nuance and other text that has nothing to do with defining a protocol and enabling interoperability. This led to a stalemate. Based on the discussion during the SFPBIS WG session at IETF 85 the WG decided to proceed with a reorganization of the document while ensuring that the reorganization did not create any text changes apart from moving text around. There is rough consensus within the SPFBIS WG to publish the document. There are multiple existing implementations of the SPF protocol. The document was reviewed by the SPFBIS working group. Dave Crocker, Stuart Gathman, Murray Kucherawy, John Levine, Hector Santos, Andrew Sullivan, Arthur Thisell, and Alessandro Vesely reviewed the document. Simon Perreault helped to clarify the meaning of IPv4 mapped IPv6 addresses. Murray Kucherawy deserves a special mention for his contributions. The document was reviewed by Cyrus Daboo on behalf of the Applications Area Directorate. Meral Shirazipour reviewed the document for Gen-ART and Phillip Hallam-Baker performed the Security Directorate review. I suggest further review of the document from a DNS perspective. Intellectual Property The author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. The working group was informed about an IPR disclosure filed for RFC 4408 ( https://datatracker.ietf.org/ipr/1698/ ) before the WGLC. There wasn't any noteworthy discussion about the IPR disclosure. Other Points There is a downward reference to RFC 1983. RFC 5598 is already in the DOWNREF registry. The US-ASCII reference is already used in standards track documents. IANA action is requested to update the Resource Record (RR) TYPEs registry. The "Received-SPF:" header field is being added to the Permanent Message Header Field Registry. IANA is requested to update the SPF Modifier Registry. The document does not create any IANA registries. An automated check of the ABNF in Appendix A was performed. Id-nits lists a non-RFC2606-compliant FQDN, six non-RFC5735-compliant IPv4 addresses and one instance of a private range IPv4 address. These warnings can be ignored. The warning about CFWS is incorrect. The reference to RFC 2671 is intentional; the document also references RFC 6891. Some WG participants have mentioned that they may express extreme discontent about the decision to obsolete the SPF RRTYPE during the Last Call. Regards, S. Moonesamy (as document shepherd) From marka@isc.org Mon Jul 15 17:25:17 2013 Return-Path: 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 7223021F9ED6 for ; Mon, 15 Jul 2013 17:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 S24xduSa7I7d for ; Mon, 15 Jul 2013 17:25:12 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5A98821F9D5D for ; Mon, 15 Jul 2013 17:25:12 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id D807CC947F; Tue, 16 Jul 2013 00:24:56 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1373934310; bh=AF37BMGtFxjuzibXXcYnVPMS73LuwRqYRwmbbCWjETw=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=JoX6TE94DYut/2L6cb7ZsFM0cDu5PvyIEs3X0ueGZBTbb9Io2fmzr79M5MKHPmoQT jJumOKZiKKtbiiIfmwJ+6Gqp0c+/7kRp9y2jWVAsVQg0kdcXrR5kyIa2UZj4n5QDg5 acVTFaZ7XWYgZ11rXRKO6kDM9quGxSZiHaBNa5w0= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 16 Jul 2013 00:24:56 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 448821601D1; Tue, 16 Jul 2013 00:27:34 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Not5fqiN7ziz; Tue, 16 Jul 2013 00:27:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A1A981600F7; Tue, 16 Jul 2013 00:27:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jKoiMUZVyxUR; Tue, 16 Jul 2013 00:27:33 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 6193F1601CF; Tue, 16 Jul 2013 00:27:33 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5AF07375518A; Tue, 16 Jul 2013 10:24:47 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <6.2.5.6.2.20130712054023.0cd0f6a0@elandnews.com> <20130713063503.GE15374@besserwisser.org> <20130715145427.GB14831@mx1.yitter.info> In-reply-to: Your message of "Mon, 15 Jul 2013 10:54:27 -0400." <20130715145427.GB14831@mx1.yitter.info> Date: Tue, 16 Jul 2013 10:24:47 +1000 Message-Id: <20130716002447.5AF07375518A@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org Subject: Re: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 00:25:17 -0000 In message <20130715145427.GB14831@mx1.yitter.info>, Andrew Sullivan writes: > On Sat, Jul 13, 2013 at 08:35:04AM +0200, Mns Nilsson wrote: > > > > The DNSEXT participants have read, understood and dismissed 6686 as > obsolete and incomplete > > I think it would be extraordinarily inappropriate for the shepherd of > a doc from one WG to include in a PROTO write-up such a strong claim > about consensus on another mailing list -- particularly since no such > consensus call has been made there. While I agree with this, I believe if such a call was made it would result in such a determination. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From presnick@qti.qualcomm.com Mon Jul 15 20:12:52 2013 Return-Path: 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 1582D11E818E for ; Mon, 15 Jul 2013 20:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.445 X-Spam-Level: X-Spam-Status: No, score=-106.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Qmwmf1xYoo52 for ; Mon, 15 Jul 2013 20:12:48 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id CCE2021F9FFC for ; Mon, 15 Jul 2013 20:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1373944364; x=1405480364; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hqYfhdQ+/jrSMYqHGwAyBavNwTVNUJ59bmrZhuhHgK4=; b=HyirkLj1gpgptEVmusPAGpvUygHoYTPDI8JLiyWQBYVYFyyilYMfIS3y QsoTqZetWjzm00yYufl8NC2bdTSOS2MjM9FxRmx3fRQrjGwBS0Spt1cGT cuetYBGXY8jtVbePOMZ/kBSM/UqyR+WlrHpbcdoLsHXCfm9i4GCdHM5CF M=; X-IronPort-AV: E=Sophos;i="4.89,673,1367996400"; d="scan'208";a="62850106" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 15 Jul 2013 20:12:44 -0700 X-IronPort-AV: E=Sophos;i="4.89,673,1367996400"; d="scan'208";a="568784626" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Jul 2013 20:12:44 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc11.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 15 Jul 2013 20:12:44 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 15 Jul 2013 20:12:43 -0700 Message-ID: <51E4BA29.7010802@qti.qualcomm.com> Date: Mon, 15 Jul 2013 22:12:41 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130715072155.0c8d3f70@elandnews.com> In-Reply-To: <6.2.5.6.2.20130715072155.0c8d3f70@elandnews.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Publication request for draft-ietf-spfbis-4408bis-17 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 03:12:52 -0000 On 7/15/13 11:53 AM, S Moonesamy wrote: > The SPFBIS working group requests publication of > draft-ietf-spfbis-4408bis-17. The Document Shepherd Write-Up is below. Thanks SM. The secretariat has put it in my "Publication Requested" queue. I will get it reviewed ASAP, hopefully by the end of the week. If we can get the Last Call out in the next week or so, with luck it might even make the first IESG telechat after Berlin. Thanks to everyone for the hard work. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478