From presnick@qti.qualcomm.com Wed Aug 14 13:11:27 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 7E8F621E80F4 for ; Wed, 14 Aug 2013 13:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 EJVfqNP89nKq for ; Wed, 14 Aug 2013 13:11:23 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id B330221E80ED for ; Wed, 14 Aug 2013 13:11:08 -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=1376511068; x=1408047068; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=YSWEc1UgL7rjSLVp9p7hYLchaGXToqTv/su4lXjTbiY=; b=oWN8RjsOjq8IW72cNHNZ41WA+jVXTTW/J8ckakQO3mYgmBh2HplD4R7W NprPvxx55vHjAGaioTM62gV//KY1CxptsIFWiQ3dJMbiIBbgGf1PsiDQ6 WrR+OriKihuN7640kmofmShgVMh75BTMHrKZvnFjQl/yKShphxYK6AF2I g=; X-IronPort-AV: E=Sophos;i="4.89,879,1367996400"; d="scan'208";a="49485965" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 14 Aug 2013 13:11:07 -0700 X-IronPort-AV: E=Sophos;i="4.89,879,1367996400"; d="scan'208";a="584387777" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Aug 2013 13:11:07 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.146.2; Wed, 14 Aug 2013 13:11:06 -0700 Message-ID: <520BE458.3060807@qti.qualcomm.com> Date: Wed, 14 Aug 2013 15:11:04 -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: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Subject: [spfbis] AD Review of 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: Wed, 14 Aug 2013 20:11:27 -0000 Folks, I first want to apologize for the inordinate and unacceptable delay in processing the publication request. Between the IETF meeting and some personal travel, I just failed to prioritize this appropriately. That said, my AD Review of the document is done and I'm pleased to say that I am very happy with the document. Well done! I have a few comments below, but none of them warrant holding up the document from Last Call. I will initiate that today and will put the document (tentatively) on the IESG telechat in two weeks. Also note: All of the items below are comments, not demands. Please treat these as you would any other WG participant's comments. If what I suggest goes against WG consensus, the answer to me should be "Thanks, but we'll pass on that one." So, for your edification: --- 2.5 and forward: You introduce the term "operator" without ever defining it. Most of the time, operator refers to the deployer of the SPF record. Other times, operator refers to the interpreter. I think using two different terms throughout the document (neither of which is "operator") would be better. 2.6: I've never been clear why this section isn't simply part of section 4, but that's simply an editorial preference. 2.6.1: Reference to "TXT records" here doesn't make sense. Prior to this, all references have been to "SPF records" (which is fine), and it isn't until section 4 that you mention TXT records at all. Either strike "TXT" or replace it with "SPF". 3.4: s/falling/failing 4.6.1: A forward reference to sections 5 & 6 would be helpful to tell readers that the definitions of mechanisms and modifiers appear later. 5: I think "ptr" should be separated out. The current notation in parentheses is not very clear. I suggest something like: There is an additional designated sender mechanism that was defined in the earlier experimental version of this specification, but for reasons described in section 5.x, it SHOULD NOT be used: ptr Similar text should appear in 5.5, and maybe even in 7.2. If you make this change, moving 5.5 to the end of section 5 would also make sense. 6: The modifiers defined in this document ("redirect" and "exp") MAY appear anywhere in the record, but SHOULD appear at the end, after all mechanisms. That use of MAY and SHOULD together isn't correct. You can either replace the "MAY" with "can", or rewrite the sentence: The modifiers defined in this document ("redirect" and "exp") SHOULD appear at the end of the record, after all mechanisms, though syntactically they can appear anywhere in the record. 7.3: *DIGIT = zero or more digits r = reverse value, splitting on dots by default For some reason, those equal signs bother me. (They look too much like part of the ABNF.) I suggest either a "-" or a ":", or just tabbing over instead. It's no big deal either way. 8.2: I suggest changing "A 'neutral' result MUST be treated exactly like the 'none' result;" to "A 'neutral' result is operationally equivalent to a 'none' result". The MUST doesn't seem to be making an interoperability claim. 9: I really dislike the use of the word "forensic" in this section. The first can simply be removed. The second can be changed to "reconstructive". 14.1: Why is RFC 1983 a normative reference? I will call it out in the Last Call just in case, but it seems perfectly reasonable for this to be informative. E.3, second bullet: s/MAY/can --- That's it. You should feel free to treat these as Last Call comments and buffer them until Last Call is complete, but if you have responses to any of them, please let me know. Thanks again for a solid document. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From sm@elandsys.com Wed Aug 14 14:16:26 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 4A99211E815C for ; Wed, 14 Aug 2013 14:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUXacEyWP6yL for ; Wed, 14 Aug 2013 14:16:25 -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 9DC4311E80A2 for ; Wed, 14 Aug 2013 14:16:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.226]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7ELGCUq000797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Aug 2013 14:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376514984; bh=bwnFx7LK4N+aaLvFoorwFC+g9/B90pnBI+yeAxQmcWg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NFzk2MmQc2Nxk4ZfAsP/Weo10VG1dMsYD1nTft5ZLhK9C0wqx2dFE8XWExVpMSO3k +DkLIjddTUEHcCYceza2M36ID+JC6ezmjvOUb5JWUhviLSw+ikQc4n0BmPQxw5HK0P k1Kt/4yOo+WLJnb06rN6d22S2zaR0hVt7KXdR/Tk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1376514984; i=@elandsys.com; bh=bwnFx7LK4N+aaLvFoorwFC+g9/B90pnBI+yeAxQmcWg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Dz5oQOPJhp0d3uODKYcVHGEAnsJlXmtSr20Rp/BHX4p1gcl9ueJAAt4olR6uW5YvH dofdpzyyl199TboyVd4sgIJzMg2Lm7UNVKXV2wXYCc3zoOM5rg8SubM370bLlKizQ1 tktSiV9ywW80BHUMvNK5OBgIWhCG5mZZIV7DsFnw= Message-Id: <6.2.5.6.2.20130814140705.0a2a5f10@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Aug 2013 14:15:51 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <520BE458.3060807@qti.qualcomm.com> References: <520BE458.3060807@qti.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Pete Resnick Subject: Re: [spfbis] AD Review of 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: Wed, 14 Aug 2013 21:16:26 -0000 At 13:11 14-08-2013, Pete Resnick wrote: >That said, my AD Review of the document is done and I'm pleased to >say that I am very happy with the document. Well done! I have a few >comments below, but none of them warrant holding up the document >from Last Call. I will initiate that today and will put the document >(tentatively) on the IESG telechat in two weeks. Pete, thanks for the AD review. >Also note: All of the items below are comments, not demands. Please >treat these as you would any other WG participant's comments. If >what I suggest goes against WG consensus, the answer to me should be >"Thanks, but we'll pass on that one." As a note to the working group, please comment about the review. >14.1: Why is RFC 1983 a normative reference? I will call it out in >the Last Call just in case, but it seems perfectly reasonable for >this to be informative. During my review I asked "What is a valid fully qualified domain?". Dave Crocker suggested citing RFC 1983. Would the working group be okay with moving the RFC 1983 reference to Informative? Regards, S. Moonesamy (as document shepherd) From presnick@qti.qualcomm.com Wed Aug 14 14:21: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 1AD1211E818D for ; Wed, 14 Aug 2013 14:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXebaQp7T5kp for ; Wed, 14 Aug 2013 14:21:10 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 91BA921F8A38 for ; Wed, 14 Aug 2013 14:21:10 -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=1376515270; x=1408051270; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=12hvvuNFGXzgKmrcv5p8DUEqvBdgpVP4uYPbqBdXY9E=; b=X93jA7ngOIxTxJfVHwUxrALKSngE8fIsvwxhysxEze9xS2eH1T35Snrx ZQrtFV/oo1Dx9S3i8uVuW6tWui1wP5zluIl4BDZ/ngHlWkiRWBxP3f2nu oVG9CXhn2WtC5kRvN+0XD3D1k6rZZJRSnnUz/xpDQzakpcU2gmiTr77I3 Q=; X-IronPort-AV: E=Sophos;i="4.89,879,1367996400"; d="scan'208";a="49490014" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 14 Aug 2013 14:20:59 -0700 X-IronPort-AV: E=Sophos;i="4.89,879,1367996400"; d="scan'208";a="584429937" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Aug 2013 14:20:58 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.146.2; Wed, 14 Aug 2013 14:20:58 -0700 Message-ID: <520BF4B8.1020305@qti.qualcomm.com> Date: Wed, 14 Aug 2013 16:20:56 -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: <520BE458.3060807@qti.qualcomm.com> <6.2.5.6.2.20130814140705.0a2a5f10@resistor.net> In-Reply-To: <6.2.5.6.2.20130814140705.0a2a5f10@resistor.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org Subject: Re: [spfbis] AD Review of 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: Wed, 14 Aug 2013 21:21:17 -0000 On 8/14/13 4:15 PM, S Moonesamy wrote: >> 14.1: Why is RFC 1983 a normative reference? I will call it out in >> the Last Call just in case, but it seems perfectly reasonable for >> this to be informative. > > During my review I asked "What is a valid fully qualified domain?". > Dave Crocker suggested citing RFC 1983. Would the working group be > okay with moving the RFC 1983 reference to Informative? I also notice that 5782 is normatively referenced, and that is almost certainly just an error. If there are no objections, I'll just move those two from normative to informative in an RFC Editor note and explain in the Last Call. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From sm@elandsys.com Wed Aug 14 14:34:41 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 DCD1021F962D for ; Wed, 14 Aug 2013 14:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj1F32XivsCn for ; Wed, 14 Aug 2013 14:34:41 -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 7411A21F8FAC for ; Wed, 14 Aug 2013 14:34:40 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.226]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7ELYQrf021763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Aug 2013 14:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376516079; bh=vxXt8x0jQqIo1WoQDo0Vfgk/X1ym+wLCNGDQo0trMLg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ITqOaI/0PvhbfOfM3lb7ptfPXZo1728rWyaKjd6Jee3yHkYPmQE9XvFfdUsrVGhva Tmi3K9IvVtm1aIsQXOLacADz0p658prNRIWcSxcSQ3e+DO2NbWWZD+Hm0L8uXwOKEn cq8JFSkafcAJBCS9Zt12A86e3nwB6YTQtfcUmj+A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1376516079; i=@elandsys.com; bh=vxXt8x0jQqIo1WoQDo0Vfgk/X1ym+wLCNGDQo0trMLg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kdHwyNp26RmaRjO6LPDGX4VFRPrlfe7JZlihps2BqC5WYqgPuNJAvaPmaqwoX45dN ZIT3RWnR8ehKzXWDqxJ74YCcXzRXZm8//O3FIHlQH+LyjnbkfiY2bHdWDjoaizwBlM Fy2EySotKGZ+yegr3ehS52Shu5cs8cnYLs5VoilE= Message-Id: <6.2.5.6.2.20130814142546.0a203070@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Aug 2013 14:34:06 -0700 To: Pete Resnick From: S Moonesamy In-Reply-To: <520BF4B8.1020305@qti.qualcomm.com> References: <520BE458.3060807@qti.qualcomm.com> <6.2.5.6.2.20130814140705.0a2a5f10@resistor.net> <520BF4B8.1020305@qti.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] AD Review of 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: Wed, 14 Aug 2013 21:34:42 -0000 Hi Pete, At 14:20 14-08-2013, Pete Resnick wrote: >I also notice that 5782 is normatively referenced, and that is >almost certainly just an error. The RFC 5782 normative reference is an error. Scott Kitterman mentioned that he would fix it in -18. >If there are no objections, I'll just move those two from normative >to informative in an RFC Editor note and explain in the Last Call. I am waiting for the working group to comment on the other reference. Regards, S. Moonesamy (as document shepherd) From superuser@gmail.com Wed Aug 14 16:26: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 4A6B921E8051 for ; Wed, 14 Aug 2013 16:26:15 -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, 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 lkpRjkVHurAU for ; Wed, 14 Aug 2013 16:26:14 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9095721E804D for ; Wed, 14 Aug 2013 16:26:14 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so67774wes.26 for ; Wed, 14 Aug 2013 16:26: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=XMdQ5PzL934KGW+GCimGFU+1MDdlwjzPvjpAV6W5kZ8=; b=EPey3Dlac2cRjmrB0bS4sLyV8J4v06vO9BC/5oUq+c2mkJM/vehWGjRFHoFyNBH6nx 5KRbo5BW/sDEAceWEcoYbfz/MigfnglsLgou6F5sH3rOiy16q7JkUWp3p6ogaYEp00Dk qeeiMYrEQKltmxSzq62pI0KdHTx2PszMeQWDKh5sD5o6BgtWNZ1XtkgBbIUqeECDGro2 7s5wzT7G2/G1mdJxGOT/800/lLLnI/z3hKeEszXPrIOzMj7buzUK6s8Bp8U/gCZxLYEZ 6/r5T8jEwMwzlgXCWjTZz6fssd1d4EPSgKdfCHmIORELN8kFtWkIb2B6st/IqJtt1a+a 39XA== MIME-Version: 1.0 X-Received: by 10.180.189.132 with SMTP id gi4mr60555wic.19.1376522773593; Wed, 14 Aug 2013 16:26:13 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Wed, 14 Aug 2013 16:26:13 -0700 (PDT) In-Reply-To: <520BF4B8.1020305@qti.qualcomm.com> References: <520BE458.3060807@qti.qualcomm.com> <6.2.5.6.2.20130814140705.0a2a5f10@resistor.net> <520BF4B8.1020305@qti.qualcomm.com> Date: Wed, 14 Aug 2013 16:26:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c35294f204ac04e3f0ae09 Cc: "spfbis@ietf.org" , S Moonesamy Subject: Re: [spfbis] AD Review of 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: Wed, 14 Aug 2013 23:26:15 -0000 --001a11c35294f204ac04e3f0ae09 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 14, 2013 at 2:20 PM, Pete Resnick wrote: > On 8/14/13 4:15 PM, S Moonesamy wrote: > >> 14.1: Why is RFC 1983 a normative reference? I will call it out in the >>> Last Call just in case, but it seems perfectly reasonable for this to be >>> informative. >>> >> >> During my review I asked "What is a valid fully qualified domain?". Dave >> Crocker suggested citing RFC 1983. Would the working group be okay with >> moving the RFC 1983 reference to Informative? >> > > I also notice that 5782 is normatively referenced, and that is almost > certainly just an error. > > If there are no objections, I'll just move those two from normative to > informative in an RFC Editor note and explain in the Last Call. It's cool that I get to say this to an IESG member: No objection. -MSK --001a11c35294f204ac04e3f0ae09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 14, 2013 at 2:20 PM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
On 8/14/13 4:15 PM, S Moon= esamy wrote:
14.1: Why is RFC 1983 a normative reference? I will call it out in the Last= Call just in case, but it seems perfectly reasonable for this to be inform= ative.

During my review I asked "What is a valid fully qualified domain?"= ;. =A0Dave Crocker suggested citing RFC 1983. =A0Would the working group be= okay with moving the RFC 1983 reference to Informative?

I also notice that 5782 is normatively referenced, and that is almost certa= inly just an error.

If there are no objections, I'll just move those two from normative to = informative in an RFC Editor note and explain in the Last Call.

It's cool that I get to say this to an IESG member= :

No objection.

-MSK
--001a11c35294f204ac04e3f0ae09-- From spf2@kitterman.com Fri Aug 16 19:22: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 826AB11E81FA for ; Fri, 16 Aug 2013 19:22:07 -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 hWJ9t+c7bDCe for ; Fri, 16 Aug 2013 19:22:02 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4490C11E81F6 for ; Fri, 16 Aug 2013 19:22:02 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 57A8820E40D2; Fri, 16 Aug 2013 22:22:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1376706120; bh=pdZuOcjPRk3rJLkFGoMuLMdcMhU3Z3urh4WTK+GwA8U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=j8/3JgZmtdrnEGVO1Nl/GPxXuRw+84JZRoL18oHb8GhvWVbOXtC0xXu6fLpST0rPV Ae/MEBcgYdApbFBGfOvuATp3SDW0moBfGpmkyu09tu/rmoH7JSuj4ovnppvh16NRvp rju3iVRYlBjEj3GsWflUXwHwg391bKZhMkuW+sdo= 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 39CDB20E40A4; Fri, 16 Aug 2013 22:21:59 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 16 Aug 2013 22:21:59 -0400 Message-ID: <2740178.6b98xEoijR@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-27-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <520BE458.3060807@qti.qualcomm.com> References: <520BE458.3060807@qti.qualcomm.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] AD Review of 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: Sat, 17 Aug 2013 02:22:07 -0000 Comments inline. Scott K On Wednesday, August 14, 2013 15:11:04 Pete Resnick wrote: > Folks, > > I first want to apologize for the inordinate and unacceptable delay in > processing the publication request. Between the IETF meeting and some > personal travel, I just failed to prioritize this appropriately. > > That said, my AD Review of the document is done and I'm pleased to say > that I am very happy with the document. Well done! I have a few comments > below, but none of them warrant holding up the document from Last Call. > I will initiate that today and will put the document (tentatively) on > the IESG telechat in two weeks. > > Also note: All of the items below are comments, not demands. Please > treat these as you would any other WG participant's comments. If what I > suggest goes against WG consensus, the answer to me should be "Thanks, > but we'll pass on that one." > > So, for your edification: > > --- > > 2.5 and forward: You introduce the term "operator" without ever defining > it. Most of the time, operator refers to the deployer of the SPF record. > Other times, operator refers to the interpreter. I think using two > different terms throughout the document (neither of which is "operator") > would be better. Actually it's the other way around. The only time it's in reference to the sending side of the equation is the initial reference. If it would help, I think we could change the first one to DNS operator and the rest to SPF verifier operator. I'm not sure this is worth fixing, so I'll wait for feedback. > 2.6: I've never been clear why this section isn't simply part of section > 4, but that's simply an editorial preference. I think of section 2 as more about what and section 4 more about how, but what we have now is roughly consistent with RFC 4408, so we shouldn't change it without a good reason. > 2.6.1: Reference to "TXT records" here doesn't make sense. Prior to > this, all references have been to "SPF records" (which is fine), and it > isn't until section 4 that you mention TXT records at all. Either strike > "TXT" or replace it with "SPF". Now it has, "(b) no TXT records were retrieved from the DNS that appeared to be intended for use by SPF verifiers." That's another way of saying SPF records. If we were to replace the current text, it would be "(b) no SPF records were retrieved from the DNS." Is that better? > 3.4: s/falling/failing Fixed locally > 4.6.1: A forward reference to sections 5 & 6 would be helpful to tell > readers that the definitions of mechanisms and modifiers appear later. Added locally. > 5: I think "ptr" should be separated out. The current notation in > parentheses is not very clear. I suggest something like: > > There is an additional designated sender mechanism that was defined > in the earlier experimental version of this specification, but for > reasons described in section 5.x, it SHOULD NOT be used: > > ptr > > Similar text should appear in 5.5, and maybe even in 7.2. If you make > this change, moving 5.5 to the end of section 5 would also make sense. We had stronger text about this at one point, but went back to where we are now. A verifier still needs to implement ptr processing for backward compatibility, so from an implementation perspective, it is still required. I don't think we ought to segregate it out like this. > 6: > > The modifiers defined in this document ("redirect" and "exp") MAY > appear anywhere in the record, but SHOULD appear at the end, after > all mechanisms. > > That use of MAY and SHOULD together isn't correct. You can either > replace the "MAY" with "can", or rewrite the sentence: > > The modifiers defined in this document ("redirect" and "exp") SHOULD > appear at the end of the record, after all mechanisms, though > syntactically they can appear anywhere in the record. IIRC, we had struggled with this a bit, I think this is a good formulation. Changed locally. > 7.3: > > *DIGIT = zero or more digits > r = reverse value, splitting on dots by default > > For some reason, those equal signs bother me. (They look too much like > part of the ABNF.) I suggest either a "-" or a ":", or just tabbing over > instead. It's no big deal either way. This is almost exactly what was in RFC 4408. It had: Optional transformers are the following: *DIGIT = zero or more digits 'r' = reverse value, splitting on dots by default I've gone ahead and changed my local copy to add the quotes back to 'r', but I don't think we should change it further. I'm open to being wrong on that. What do others think? > 8.2: I suggest changing "A 'neutral' result MUST be treated exactly like > the 'none' result;" to "A 'neutral' result is operationally equivalent > to a 'none' result". The MUST doesn't seem to be making an > interoperability claim. We debated this extensively in the working group. There were arguments in favor of more extensive treatment of receiver policy and arguments in favor of removing even the very limited text about it that was in RFC 4408. In the end, we compromised on leaving it just like RFC 4408, which is what this is. The interoperability argument is that if receivers treat neutral more harshly than than none, it would be an impediment to deployment. > 9: I really dislike the use of the word "forensic" in this section. The > first can simply be removed. The second can be changed to "reconstructive". Done. > 14.1: Why is RFC 1983 a normative reference? I will call it out in the > Last Call just in case, but it seems perfectly reasonable for this to be > informative. It's used as a reference in the ABNF: domain = I had put it as normative for that reason. Given that, is it still OK to move it? > E.3, second bullet: s/MAY/can Done. > I also notice that 5782 is normatively referenced, and that is almost > certainly just an error. As mentioned by sm, I've already corrected this locally for the to be -18. > --- > > That's it. You should feel free to treat these as Last Call comments and > buffer them until Last Call is complete, but if you have responses to > any of them, please let me know. See above. I do have a few questions in response to the comments. Scott K From sm@elandsys.com Fri Aug 16 19:58: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 E88AB11E8205 for ; Fri, 16 Aug 2013 19:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Arm5f0oACddr for ; Fri, 16 Aug 2013 19:58:09 -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 3F33F11E80F4 for ; Fri, 16 Aug 2013 19:58:07 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.196]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7H2vo4F007542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 19:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376708282; bh=ksLVCK9xROeb504AKnnKKbkhUsU6zktpW7E9sNCrv/c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ki/k1lINbDi1jPenTrUR5eEWu/mRUBmBDd+w8bKMY76EysicjF9NUd/87SrCBj66d KoDNeUwPSUGjPOdeiyYUSET6Q2RE61n8xH6E3/QdLVYm0QgA8idjPTex4D0sQeUNB0 L1oCAkOBj3Bvh9lB4OIKLbK85VNhmeKi5wugk94s= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1376708282; i=@elandsys.com; bh=ksLVCK9xROeb504AKnnKKbkhUsU6zktpW7E9sNCrv/c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qGy41U4WqHGYNrQQP0hn3fSDA0CAnU+vupcZ23laYyHBerB5FSh9c+A1M/in3FjKA gTyNNJECOabEsKr/xZRL611PeTI8UYy6lK10cpN/bynDFGhaHVLmztMqL6Hv6qnp8J 64TxoHRUBRc4v4y5n8/8new9WoHrhcS4A/iunwow= Message-Id: <6.2.5.6.2.20130816193641.0bd60190@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 16 Aug 2013 19:56:45 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <2740178.6b98xEoijR@scott-latitude-e6320> References: <520BE458.3060807@qti.qualcomm.com> <2740178.6b98xEoijR@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] AD Review of 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: Sat, 17 Aug 2013 02:58:10 -0000 Hi Scott, Thanks for responding to the comments. At 19:21 16-08-2013, Scott Kitterman wrote: >It's used as a reference in the ABNF: > >domain = > >I had put it as normative for that reason. Given that, is it still >OK to move >it? I'll comment on this so that the IETF Last Call can be initiated. In Section 4.4 there is: "Properly formed domains are fully qualified domains as defined in [RFC1983]" I suggest moving the RFC 1993 reference to informative with the following changes: Properly formed domains are fully qualified domains as defined in RFC 1035. In Appendix A: domain = Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Fri Aug 16 20:03:25 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 7C25F11E80F4 for ; Fri, 16 Aug 2013 20:03:25 -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 ISX7AHpXdJon for ; Fri, 16 Aug 2013 20:03:20 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6685411E8201 for ; Fri, 16 Aug 2013 20:03:20 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id B5A36D04087; Fri, 16 Aug 2013 23:03:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1376708598; bh=5QmVbk6NSiYl0+iBWS95fP9N4cKr4bk4ZVELNvDC+1w=; h=In-Reply-To:References:Subject:From:Date:To:From; b=JzYkra/ddx4OStkKwUo3yblqG8zP2dqWRACM6zUJ33k5AtAW7M5IvgTMPsDT7zJpj w8kIvgo02FIDkCh+iVlnr9MAug5rr0pFrfS5HKVcjg7zH7gBEB6jO14kxX3DKKgEt8 bm6/GjCYB++7TU4NWFnV1O45p2BZbkaQg418oNxQ= 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 6BDA4D0403E; Fri, 16 Aug 2013 23:03:18 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130816193641.0bd60190@resistor.net> References: <520BE458.3060807@qti.qualcomm.com> <2740178.6b98xEoijR@scott-latitude-e6320> <6.2.5.6.2.20130816193641.0bd60190@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 16 Aug 2013 23:03:16 -0400 To: spfbis@ietf.org Message-ID: <18f15ccc-bc4e-40de-9394-8059935da837@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] AD Review of 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: Sat, 17 Aug 2013 03:03:25 -0000 S Moonesamy wrote: >Hi Scott, > >Thanks for responding to the comments. > >At 19:21 16-08-2013, Scott Kitterman wrote: >>It's used as a reference in the ABNF: >> >>domain = >> >>I had put it as normative for that reason. Given that, is it still >>OK to move >>it? > >I'll comment on this so that the IETF Last Call can be initiated. > >In Section 4.4 there is: > > "Properly formed domains are fully qualified domains as defined > in [RFC1983]" > >I suggest moving the RFC 1993 reference to informative with the >following changes: > > Properly formed domains are fully qualified domains as defined > in RFC 1035. > >In Appendix A: > > domain = OK. I just wanted to make sure that everyone knew it was in the ABNF. I'll change it locally. To be clear: Do you want me to post -18 before you start IETF Last Call or are you starting it with -17? Scott K From sm@elandsys.com Fri Aug 16 20:23: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 BE2A411E8217 for ; Fri, 16 Aug 2013 20:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HfmqHv6GWsa for ; Fri, 16 Aug 2013 20:23:58 -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 3586F11E8210 for ; Fri, 16 Aug 2013 20:23:56 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.196]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7H3NhqX001860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 20:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376709835; bh=m8tFjCElQL09ofhbc3SIY+sVt/QWr0TgKBRrvzd3BSc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YejkbegxC1x3sXTLNoPGU8tUMBG4qjAmwGDTkbmtlwlJbWLhNXNHKciaSTlqQ6onO 63Hd4qD1pLKX6XZh5vN6uLYsf58bfO/3mfZrF6ElBPisOIw6BwYl54TdeEHhnCNnha 7MNr3jKeQ0OQtLjcGfDYRGAGAI9oFlQVsNV0b5vk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1376709835; i=@elandsys.com; bh=m8tFjCElQL09ofhbc3SIY+sVt/QWr0TgKBRrvzd3BSc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XXiTCBBxRISafQnf2stE3WAnmS5O0Pymb4wpET13TD+T3JKAM+Pf7LKObxLIfBp9J /lPe0qxZt3VlSkc+NMPHEmM9KuRdcEv4K1EKaV1CMiQq8FT/1cOtZRtV5nXAN5WThG mMvyVbHMYhUz8SA3lTRQIonzUOSVTjPQX1h12RLA= Message-Id: <6.2.5.6.2.20130816201453.0bd60568@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 16 Aug 2013 20:23:35 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <18f15ccc-bc4e-40de-9394-8059935da837@email.android.com> References: <520BE458.3060807@qti.qualcomm.com> <2740178.6b98xEoijR@scott-latitude-e6320> <6.2.5.6.2.20130816193641.0bd60190@resistor.net> <18f15ccc-bc4e-40de-9394-8059935da837@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] AD Review of 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: Sat, 17 Aug 2013 03:23:58 -0000 Hi Scott, At 20:03 16-08-2013, Scott Kitterman wrote: >OK. I just wanted to make sure that everyone knew it was in the >ABNF. I'll change it locally. Thanks. >To be clear: Do you want me to post -18 before you start IETF Last >Call or are you starting it with -17? Could you please submit -18? I'll ask Pete Resnick to use -18 for the Last Call. I'll edit the document shepherd write-up and remove the sentence mentioning RFC 1983. Regards, S. Moonesamy (as document shepherd) From internet-drafts@ietf.org Fri Aug 16 20:27:48 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 7828811E8217; Fri, 16 Aug 2013 20:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.016, 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 wVxADk1UWSyP; Fri, 16 Aug 2013 20:27:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B6511E8210; Fri, 16 Aug 2013 20:27:47 -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.70.p1 Message-ID: <20130817032747.28661.14414.idtracker@ietfa.amsl.com> Date: Fri, 16 Aug 2013 20:27:47 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-18.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: Sat, 17 Aug 2013 03:27:48 -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-18.txt Pages : 75 Date : 2013-08-16 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-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sm@elandsys.com Fri Aug 16 20:57:29 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 B1DF411E8217 for ; Fri, 16 Aug 2013 20:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 CLHuRE9n0txh for ; Fri, 16 Aug 2013 20:57:29 -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 362BF11E80FE for ; Fri, 16 Aug 2013 20:57:28 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.196]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7H3vExf003791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 20:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376711846; bh=YymrokTiSBJHRSeXElzXLC1QPJJAMGTgzx10/6SYZiU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Q4DCo6KJnNunuTWFqywyCHBktG0elHQdA1m7IIpGZbx6a09l9krt61UwxLKnygOOJ wJUEKtcQrhkJWn1KokQWB7omzFAMniQ0D5IL9cjMPJPEo0AV0vOhO8dbSJEeETUZE4 IZt25Rk/7/2UPZxoi6KoAfDOWvi2mufYDdkIZ1Ys= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1376711846; i=@elandsys.com; bh=YymrokTiSBJHRSeXElzXLC1QPJJAMGTgzx10/6SYZiU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VdUT6n3utOFw9/Nqj4sWhj+KqmjclutsVsZvbaAKXloZisCDkVbgBDeg4dU3Klm4s I+J9NkiveL/HnNGcdqLG+YS61SGv849jAvvmpNTBcfK+9xtt+S1EbPZzDPizV/+Akv /RseMdXwZXdMpEQ5b1JFIY/f/cCF7AxXHED8By2w= Message-Id: <6.2.5.6.2.20130816203908.0bfdf4a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 16 Aug 2013 20:47:50 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <20130817032748.28661.8091.idtracker@ietfa.amsl.com> References: <20130817032748.28661.8091.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] New Version Notification - draft-ietf-spfbis-4408bis-18.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: Sat, 17 Aug 2013 03:57:29 -0000 Hi Scott, At 20:27 16-08-2013, internet-drafts@ietf.org wrote: >A new version (-18) has been submitted for draft-ietf-spfbis-4408bis: >http://www.ietf.org/internet-drafts/draft-ietf-spfbis-4408bis-18.txt I see that the RFC 1983 is now informative. There is still the following: In Section 4.3: "Properly formed domains are fully qualified domains as defined in [RFC1983]." And in Appendix A: "domain = " As you mentioned previously, the reference would be normative if it is referenced in the ABNF. Could you change RFC 1983 to RFC 1035 in the above text? The reason I am asking this is so that the question of whether RFC 1983 should be normative or not does not arise with the suggested change. If you are okay with the above, please submit -19. Thanks, S. Moonesamy (as document shepherd) From presnick@qti.qualcomm.com Fri Aug 16 21:43:51 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 EABDB11E81C9 for ; Fri, 16 Aug 2013 21:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.417 X-Spam-Level: X-Spam-Status: No, score=-106.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 ST0jJ3akezmT for ; Fri, 16 Aug 2013 21:43:47 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id C0B6311E80D2 for ; Fri, 16 Aug 2013 21:43:47 -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=1376714627; x=1408250627; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1kHcXVcutuSQI4+8LbVn5PvJkLo2RFpVPJZxtb1U2sY=; b=lqbVQzNsPOm7xVAsxx3D/nyn51Z8TtuiUAt5D0kPy8IytHOqKDN7RdWM qcvVy7YMCN8AfbFXZJSW5c4PslZZse9aemC7IcocJvi2eRlb9a9REJrGK NctGGJwV2lwm+IPE/gWYLGSY8psPQuJtiQAnQFVWxZgrG87r85Xhegibc c=; X-IronPort-AV: E=Sophos;i="4.89,899,1367996400"; d="scan'208";a="69102903" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 16 Aug 2013 21:43:46 -0700 X-IronPort-AV: E=Sophos;i="4.89,899,1367996400"; d="scan'208";a="585668941" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Aug 2013 21:43:46 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.146.2; Fri, 16 Aug 2013 21:43:45 -0700 Message-ID: <520EFF7F.4030703@qti.qualcomm.com> Date: Fri, 16 Aug 2013 23:43:43 -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: <20130817032748.28661.8091.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130816203908.0bfdf4a8@elandnews.com> In-Reply-To: <6.2.5.6.2.20130816203908.0bfdf4a8@elandnews.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] New Version Notification - draft-ietf-spfbis-4408bis-18.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: Sat, 17 Aug 2013 04:43:52 -0000 On 8/16/13 10:47 PM, S Moonesamy wrote: > In Section 4.3: > > "Properly formed domains are fully qualified domains as defined > in [RFC1983]." > > And in Appendix A: > > "domain = " > > As you mentioned previously, the reference would be normative if it is > referenced in the ABNF. Could you change RFC 1983 to RFC 1035 in the > above text? The reason I am asking this is so that the question of > whether RFC 1983 should be normative or not does not arise with the > suggested change. > > If you are okay with the above, please submit -19. The problem is that 1035 never defines "fully qualified domain name". I think the definition in 4.3 is fine without making 1983 normative. But I also now think that putting 1983 in the ABNF is not so good: 1983 never gives the syntax for an FQDN; it only defines it. So I say let's leave the (informative) reference to 1983 in 4.3. As far as the ABNF in appendix A, I don't see anywhere in the document that the ABNF terminal "domain" is used, so why is it there in the first place. Perhaps that ABNF definition can simply be removed. BTW: While hunting through the document, I found an error in section 7.2: , , and are defined in Section 2.2. They are defined in 4.1. You should probably do a scrub of internal reference numbers before it gets to the RFC Editor. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From sm@elandsys.com Fri Aug 16 22:13: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 0781B11E8208 for ; Fri, 16 Aug 2013 22:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 q3nzr7ReTueS for ; Fri, 16 Aug 2013 22:13:06 -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 5DA4F11E81CE for ; Fri, 16 Aug 2013 22:13:06 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.196]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7H5Cote011282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 22:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376716383; bh=GagKwYvQ59o9De+g8f2mYTz9s1dzeFGqj8qENMhLS0M=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XQ/BN1R9ROMx+gbc6UwowP1erj94wJDbtVcqYgFlJS2WjFofn2LTB399UEJgRvJYj 63LmqQT41lK1fRo9R3GnnXpt+MNQ9K348WYBBaCgqsgi2+SRhE2qFUnwPxuDEv9DB4 cFOMDV/g7tPMmD2EQ3j0HeaNGdmI+qYYPFfTnWlI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1376716383; i=@elandsys.com; bh=GagKwYvQ59o9De+g8f2mYTz9s1dzeFGqj8qENMhLS0M=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=h8aZMxwrTHxzWHCFDAgn4b7VXpaJisgw1sgZk56KFuAK0IbvQBNWwrKl9mEhgsRGR mFi4yJHnxYZq8dtth3uGQsv67C6KzICLL7AgvoKepreTypXc4gY7XHGJbX/MOcEmFY r3i/qRoyOsCLMp8jSY+8/TJoJroXRk9Au9Zxknpw= Message-Id: <6.2.5.6.2.20130816214917.0ad41fe8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 16 Aug 2013 22:12:28 -0700 To: Pete Resnick From: S Moonesamy In-Reply-To: <520EFF7F.4030703@qti.qualcomm.com> References: <20130817032748.28661.8091.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130816203908.0bfdf4a8@elandnews.com> <520EFF7F.4030703@qti.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] New Version Notification - draft-ietf-spfbis-4408bis-18.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: Sat, 17 Aug 2013 05:13:07 -0000 Hi Pete, At 21:43 16-08-2013, Pete Resnick wrote: >The problem is that 1035 never defines "fully qualified domain >name". I think the Yes. > definition in 4.3 is fine without making 1983 normative. But I > also now think that putting 1983 in the ABNF is not so good: 1983 > never gives the syntax for an FQDN; it only defines it. There isn't any ABNF in RFC 1983. The BNF in RFC 1035 could be used but then your comment (see first line) applies. >So I say let's leave the (informative) reference to 1983 in 4.3. As >far as the ABNF in appendix A, I don't see anywhere in the document >that the ABNF terminal "domain" is used, so why is it there in the >first place. Perhaps that ABNF definition can simply be removed. I went through the draft-ietf-spfbis-4408bis-18 and I did not see a requirement for "domain". >BTW: While hunting through the document, I found an error in section 7.2: > >, , and are defined in Section 2.2. > >They are defined in 4.1. You should probably do a scrub of internal >reference numbers before it gets to the RFC Editor. Yes. To summarize: (a) Fix the error in Section 7.2 (b) Drop the "domain" line in the ABNF in Appendix A If Scott and you are okay with that, a -19 can be generated and the Last Call initiated. Regards, S. Moonesamy From spf2@kitterman.com Fri Aug 16 22:13:54 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 E992711E8225 for ; Fri, 16 Aug 2013 22:13:54 -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 p0nw2LgyJWpN for ; Fri, 16 Aug 2013 22:13:34 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 916A211E8208 for ; Fri, 16 Aug 2013 22:13:34 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7EB7520E40D2; Sat, 17 Aug 2013 01:13:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1376716412; bh=2dW07Z/jRYt11aRC1+XDb3f0Ai3LWymTQ3SFBUD/QzY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DQryUJWMMr4cDkePOSQPZdv8K1X5eix8s8Q8LglBO++kg40RmkkwgilurSQHgh9oR /4aECvIawICKXdy21dRe8ZwuHuRSbWrgVTQVxMBjvFt1cRWsRYu8ni+fSPPQNMx2kL SXb/d90qCGLoKWBo1RPfewRgl9/Mf1YZyKIZDlxs= 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 6205E20E40A4; Sat, 17 Aug 2013 01:13:31 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 17 Aug 2013 01:13:31 -0400 Message-ID: <2137632.0B3z2kpqv3@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-27-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <520EFF7F.4030703@qti.qualcomm.com> References: <20130817032748.28661.8091.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130816203908.0bfdf4a8@elandnews.com> <520EFF7F.4030703@qti.qualcomm.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] New Version Notification - draft-ietf-spfbis-4408bis-18.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: Sat, 17 Aug 2013 05:13:55 -0000 On Friday, August 16, 2013 23:43:43 Pete Resnick wrote: > On 8/16/13 10:47 PM, S Moonesamy wrote: > > In Section 4.3: > > "Properly formed domains are fully qualified domains as defined > > > > in [RFC1983]." > > > > And in Appendix A: > > "domain = " > > > > As you mentioned previously, the reference would be normative if it is > > referenced in the ABNF. Could you change RFC 1983 to RFC 1035 in the > > above text? The reason I am asking this is so that the question of > > whether RFC 1983 should be normative or not does not arise with the > > suggested change. > > > > If you are okay with the above, please submit -19. > > The problem is that 1035 never defines "fully qualified domain name". I > think the definition in 4.3 is fine without making 1983 normative. But I > also now think that putting 1983 in the ABNF is not so good: 1983 never > gives the syntax for an FQDN; it only defines it. > > So I say let's leave the (informative) reference to 1983 in 4.3. As far > as the ABNF in appendix A, I don't see anywhere in the document that the > ABNF terminal "domain" is used, so why is it there in the first place. > Perhaps that ABNF definition can simply be removed. > > BTW: While hunting through the document, I found an error in section 7.2: > > , , and are defined in Section 2.2. > > They are defined in 4.1. You should probably do a scrub of internal > reference numbers before it gets to the RFC Editor. I'm inferring from this I shouldn't submit -19? Well clean it up later? Scott K From spf2@kitterman.com Fri Aug 16 22:26:32 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 7357E21F8F07 for ; Fri, 16 Aug 2013 22:26:32 -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 55rjCgLMnvXV for ; Fri, 16 Aug 2013 22:26:27 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBD521F8EFE for ; Fri, 16 Aug 2013 22:26:27 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DA7C720E40D2; Sat, 17 Aug 2013 01:26:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1376717186; bh=BE9vf/6hCY/UKjXzTVAw6d+Myy+lMkDKgT+M1JL0jLo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bErJnnpRfpogLDI0Hkwn1+OrMA9OA+Bz0LkEb1ukkJdj5/dNuWhfT/1mfVIwcB2w2 mCnQcViyePQJAwO8BC2gSbCVY7UYhdg3MzTUqJJs5uclv3e1sM4OalTP1Kg0i4n+Y0 3dqRfRz9rZI2dTdPp5IR2XcrkisoMfvtU8baJ74o= 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 BF19820E40A4; Sat, 17 Aug 2013 01:26:26 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 17 Aug 2013 01:26:26 -0400 Message-ID: <5277966.5He8UusIjb@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-27-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130816214917.0ad41fe8@elandnews.com> References: <20130817032748.28661.8091.idtracker@ietfa.amsl.com> <520EFF7F.4030703@qti.qualcomm.com> <6.2.5.6.2.20130816214917.0ad41fe8@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] New Version Notification - draft-ietf-spfbis-4408bis-18.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: Sat, 17 Aug 2013 05:26:32 -0000 On Friday, August 16, 2013 22:12:28 S Moonesamy wrote: > Hi Pete, > > At 21:43 16-08-2013, Pete Resnick wrote: > >The problem is that 1035 never defines "fully qualified domain > >name". I think the > > Yes. > > > definition in 4.3 is fine without making 1983 normative. But I > > > > also now think that putting 1983 in the ABNF is not so good: 1983 > > never gives the syntax for an FQDN; it only defines it. > > There isn't any ABNF in RFC 1983. The BNF in RFC 1035 could be used > but then your comment (see first line) applies. > > >So I say let's leave the (informative) reference to 1983 in 4.3. As > >far as the ABNF in appendix A, I don't see anywhere in the document > >that the ABNF terminal "domain" is used, so why is it there in the > >first place. Perhaps that ABNF definition can simply be removed. > > I went through the draft-ietf-spfbis-4408bis-18 and I did not see a > requirement for "domain". As Pete mentioned, it's one of the inputs to check_host() listed in 4.1. And is used many times as throughout the document. > >BTW: While hunting through the document, I found an error in section 7.2: > > > >, , and are defined in Section 2.2. > > > >They are defined in 4.1. You should probably do a scrub of internal > >reference numbers before it gets to the RFC Editor. > > Yes. > > To summarize: > > (a) Fix the error in Section 7.2 > > (b) Drop the "domain" line in the ABNF in Appendix A > > If Scott and you are okay with that, a -19 can be generated and the > Last Call initiated. No. I'm not. It's part of the ABNF introduced in 4.1 and properly part of the collected ABNF in Appendix A. We did discuss this before which is how we got where we are not. Removing it does not make sense to me and is contrary to the prior conclusion of the group. Scott K From sm@elandsys.com Fri Aug 16 23:00: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 331E921F89FF for ; Fri, 16 Aug 2013 23:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwaUSQN7Jg2Y for ; Fri, 16 Aug 2013 23:00:35 -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 76BC921F89EB for ; Fri, 16 Aug 2013 23:00:35 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.196]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7H60IH2025321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 23:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376719232; bh=BEDcz/BfleBkGttUW7asMeSbRrwz4dL0m+dwhUY2kHQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZwJOQbu0+cpjRFJuMwqiiZbNEMWUrdYu+0J/OsTzGEDhBMA1Qn0Bp5wjuenUrxbFU WJg/UY/464pCSi0ylxlAZ0wC5B87xTH4dNhkKbEUiiGkSYK27NKQQ8utufG+V+ftWr AxQBY3F6AQdlkMm07Kpt8oMkFY4VGLrFGIdg41Ok= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1376719232; i=@elandsys.com; bh=BEDcz/BfleBkGttUW7asMeSbRrwz4dL0m+dwhUY2kHQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fHpbNGsNR4tfs/IVGLWZZpEVe7JsZ297QG6rsFT/rbLEdeT3agHFLGEnkOaeD+pJ3 +js1pyQU+4PK2P27jyLj8RED9+KxfMEWOXhLgEiGmHUx3UYUb97mqCp6kLJO3Ywu1b DXghl5Lyq34A2fdwD0rTbNrXjQGAoA29OtZPr64M= Message-Id: <6.2.5.6.2.20130816223156.0bfc3d30@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 16 Aug 2013 22:59:25 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <5277966.5He8UusIjb@scott-latitude-e6320> References: <20130817032748.28661.8091.idtracker@ietfa.amsl.com> <520EFF7F.4030703@qti.qualcomm.com> <6.2.5.6.2.20130816214917.0ad41fe8@elandnews.com> <5277966.5He8UusIjb@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] New Version Notification - draft-ietf-spfbis-4408bis-18.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: Sat, 17 Aug 2013 06:00:36 -0000 Hi Scott, At 22:26 16-08-2013, Scott Kitterman wrote: >As Pete mentioned, it's one of the inputs to check_host() listed in 4.1. And >is used many times as throughout the document. [snip] >No. I'm not. It's part of the ABNF introduced in 4.1 and properly part of >the collected ABNF in Appendix A. We did discuss this before which is how we >got where we are not. Removing it does not make sense to me and is contrary >to the prior conclusion of the group. Here's Section 4.1 from version -18: The check_host() function takes these arguments: - the IP address of the SMTP client that is emitting the mail, either IPv4 or IPv6. - the domain that provides the sought-after authorization information; initially, the domain portion of the "MAIL FROM" or "HELO" identity. - the "MAIL FROM" or "HELO" identity. For recursive evaluations, the domain portion of might not be the same as the argument when check_host() is initially evaluated. In most other cases it will be the same. (See Section 5.2 below). Note that the argument might not be a well-formed domain name. For example, if the reverse-path was null, then the EHLO/HELO domain is used, with its associated problems (see Section 2.3). In these cases, check_host() is defined in Section 4.3 to return a "none" result. I understand your (and Pete's) point about the input to check_host() listed in Section 4.1. The possible issue is that there isn't any ABNF in Section 4.1. According to RFC 1983: "The FQDN is the full name of a system, rather than just its hostname." There isn't any ABNF in RFC 1983. Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Fri Aug 16 23:08: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 BD0E521F9C28 for ; Fri, 16 Aug 2013 23:08:15 -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 66whSuzvSoYy for ; Fri, 16 Aug 2013 23:08:10 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6E77421F9B0A for ; Fri, 16 Aug 2013 23:08:10 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A1DBB20E40D2; Sat, 17 Aug 2013 02:08:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1376719689; bh=LaRx9aEsCs5Lw9EMMxBOADcDdoipX9KhRB2A0ifk6GE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jJiMaCVoUXRjDPcC/+nAAtqfxIocmP47+CJ6VTeDbNq404KZaM8imKX3iz08BFuHm ODbpE6Lnby6niAsDO5TLQOD+bKuZI4jVRGYsjxtPLeVwywkC2fnP7BJD1ZleYSukNh 93C6TkY5EXP6egr7a79UwJjtZSktAKIxPxT+mVVY= 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 8540920E40A4; Sat, 17 Aug 2013 02:08:09 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 17 Aug 2013 02:08:08 -0400 Message-ID: <1422486.btPxgsSBz4@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-27-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130816223156.0bfc3d30@resistor.net> References: <20130817032748.28661.8091.idtracker@ietfa.amsl.com> <5277966.5He8UusIjb@scott-latitude-e6320> <6.2.5.6.2.20130816223156.0bfc3d30@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] New Version Notification - draft-ietf-spfbis-4408bis-18.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: Sat, 17 Aug 2013 06:08:16 -0000 On Friday, August 16, 2013 22:59:25 S Moonesamy wrote: > Hi Scott, > > At 22:26 16-08-2013, Scott Kitterman wrote: > >As Pete mentioned, it's one of the inputs to check_host() listed in 4.1. > >And is used many times as throughout the document. > > [snip] > > >No. I'm not. It's part of the ABNF introduced in 4.1 and properly part of > >the collected ABNF in Appendix A. We did discuss this before which is how > >we got where we are not. Removing it does not make sense to me and is > >contrary to the prior conclusion of the group. > > Here's Section 4.1 from version -18: > > The check_host() function takes these arguments: > > - the IP address of the SMTP client that is emitting the > mail, either IPv4 or IPv6. > > - the domain that provides the sought-after authorization > information; initially, the domain portion of the "MAIL > FROM" or "HELO" identity. > > - the "MAIL FROM" or "HELO" identity. > > For recursive evaluations, the domain portion of might not > be the same as the argument when check_host() is initially > evaluated. In most other cases it will be the same. (See > Section 5.2 below). > > Note that the argument might not be a well-formed domain > name. For example, if the reverse-path was null, then the EHLO/HELO > domain is used, with its associated problems (see Section 2.3). In > these cases, check_host() is defined in Section 4.3 to return a > "none" result. > > I understand your (and Pete's) point about the input to check_host() > listed in Section 4.1. The possible issue is that there isn't any > ABNF in Section 4.1. > > According to RFC 1983: > > "The FQDN is the full name of a system, rather than just its hostname." > > There isn't any ABNF in RFC 1983. That's true of many older RFCs. IIRC that's the best reference for it we could come up with. Scott K From sm@elandsys.com Fri Aug 16 23:53:08 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 ACC8521F9C54 for ; Fri, 16 Aug 2013 23:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voYxD51Vw1ld for ; Fri, 16 Aug 2013 23:53:08 -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 26D9F21F9C37 for ; Fri, 16 Aug 2013 23:53:06 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.196]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7H6qnhb018834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 23:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376722382; bh=ZnR4GAajNaQcfPyAtfn+ccaxjKQZ5DTip6pIfb5IkMQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vghnPYdSm8ZirU5YfUY0c9nmFFKpl0GWy/9iPeEPBTYRHR2/k/mI24blK59zGs4EO qkT5H1P/T6lmojgFekyxrxIefqnB/1wKdD9fILB2uifx0dgFBMrTqsTvirMUrT8/+6 7jZHS8S0Pk2owL1z7U07yPsT6lr6wnFmJV2T1T/E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1376722382; i=@elandsys.com; bh=ZnR4GAajNaQcfPyAtfn+ccaxjKQZ5DTip6pIfb5IkMQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bi0IDtdH7aWviinX0Dfeml7GxtmaCDx6NZ7cZ3pejxaTcLbFJvxGaAgc/BjexQvEp hMQMnmQTmIhNYjRbbflZjXBxU62FxmFteisDMVVsVmepEYsnRVTVc6EVr5hPAnn4ha A0pQzHlPDDNwuLF0Oqqu9W6+QbjQOIwZQN+ZokLU= Message-Id: <6.2.5.6.2.20130816234036.0d2f32d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 16 Aug 2013 23:52:38 -0700 To: Pete Resnick From: S Moonesamy In-Reply-To: <1422486.btPxgsSBz4@scott-latitude-e6320> References: <20130817032748.28661.8091.idtracker@ietfa.amsl.com> <5277966.5He8UusIjb@scott-latitude-e6320> <6.2.5.6.2.20130816223156.0bfc3d30@resistor.net> <1422486.btPxgsSBz4@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] New Version Notification - draft-ietf-spfbis-4408bis-18.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: Sat, 17 Aug 2013 06:53:08 -0000 Hi Pete, Can the Last Call for draft-ietf-spfbis-4408bis-18 be initiated? Thanks, S. Moonesamy (as document shepherd) From hsantos@isdg.net Sat Aug 17 05:46:49 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 8441321F9D21 for ; Sat, 17 Aug 2013 05:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[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 il-y+muGztB3 for ; Sat, 17 Aug 2013 05:46:45 -0700 (PDT) Received: from secure.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 016CB21F9BA4 for ; Sat, 17 Aug 2013 05:46:44 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2049; t=1376743591; h=Received:Received: Message-ID:Date:From:Subject:To:Organization:List-ID; bh=wDhOsSr +cX928gsPHfkEgEnYxEU=; b=dlq1lAuRXBM9lobAdO75aSxhM9MVoPLRMlvfs8F F5KJjenUL/lIMk3AdW5Or87CMLIa9PmiY5a5jIU1728Hkuec8t3ulr1aIfFJtopd 4f/MCPFJcjyzzmkhnoXWw21HD3F1ZYEoykI0Dx8c+8gtr8b4crDfW7n0pQswRlH6 qcfk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 17 Aug 2013 08:46:31 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3206111255.10543.1496; Sat, 17 Aug 2013 08:46:30 -0400 Message-ID: <520F6FC4.6000404@isdg.net> Date: Sat, 17 Aug 2013 08:42:44 -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 CC: spfbis@ietf.org References: <20130817032747.28661.14414.idtracker@ietfa.amsl.com> In-Reply-To: <20130817032747.28661.14414.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-18.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: Sat, 17 Aug 2013 12:46:49 -0000 I posted back in July 15, the numerous spelling mistakes you had in rev 17. You completely ignore it despite a direct CC email was sent to you. As a side note, lets talk about diversity and improving electronic participation; first step - stop ignoring input, no scratch that - PEOPLE! On 8/16/2013 11:27 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-18.txt > Pages : 75 > Date : 2013-08-16 > > 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-18 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-18 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > 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 presnick@qti.qualcomm.com Sat Aug 17 05:54:57 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 210FE11E810A for ; Sat, 17 Aug 2013 05:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 cp0EJohPSheN for ; Sat, 17 Aug 2013 05:54:53 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id E955D11E8104 for ; Sat, 17 Aug 2013 05:54:52 -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=1376744092; x=1408280092; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zeQvB1clUizFLak9EtPTNZEPl/FuxKTTpbYK1lE6ssU=; b=uyOPmzWFCkb+25qEvr8T5TjOKSIWMegiriQFH0AMI9w6REebdktf7x9f LRs90raqjFhd9KahhPp1IuD+IfQpY3deizJ+rDsJG60l6iq1rqWqlVQfq 5k2KkyozaDMfDzXUUqaas/mHElfK2YTH5v4DZX2loGWLTsTnEg0DcnD1u 4=; X-IronPort-AV: E=Sophos;i="4.89,901,1367996400"; d="scan'208";a="49782791" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP; 17 Aug 2013 05:54:51 -0700 X-IronPort-AV: E=Sophos;i="4.89,901,1367996400"; d="scan'208";a="532051929" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Aug 2013 05:54:51 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.146.2; Sat, 17 Aug 2013 05:54:51 -0700 Message-ID: <520F7298.6090202@qti.qualcomm.com> Date: Sat, 17 Aug 2013 07:54:48 -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: Scott Kitterman References: <20130817032748.28661.8091.idtracker@ietfa.amsl.com> <520EFF7F.4030703@qti.qualcomm.com> <6.2.5.6.2.20130816214917.0ad41fe8@elandnews.com> <5277966.5He8UusIjb@scott-latitude-e6320> In-Reply-To: <5277966.5He8UusIjb@scott-latitude-e6320> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org Subject: Re: [spfbis] New Version Notification - draft-ietf-spfbis-4408bis-18.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: Sat, 17 Aug 2013 12:54:57 -0000 On 8/17/13 12:26 AM, Scott Kitterman wrote: >> I went through the draft-ietf-spfbis-4408bis-18 and I did not see a >> requirement for "domain". >> > As Pete mentioned, it's one of the inputs to check_host() listed in 4.1. And > is used many times as throughout the document. > The *term* "domain" is used throughout the document, but it's never used as an ABNF terminal. >> To summarize: >> >> (a) Fix the error in Section 7.2 >> >> (b) Drop the "domain" line in the ABNF in Appendix A >> >> If Scott and you are okay with that, a -19 can be generated and the >> Last Call initiated. >> > No. I'm not. It's part of the ABNF introduced in 4.1 and properly part of > the collected ABNF in Appendix A. We did discuss this before which is how we > got where we are not. Removing it does not make sense to me and is contrary > to the prior conclusion of the group. > But this reasoning means that you have a different problem: There is no ABNF for "sender" or "ip". By your argument, those are missing and need to be added. I don't think you need any of them. They are all described well enough in 4.1 and providing ABNF is unnecessary in my opinion. But if the WG really thinks that providing ABNF for these is required, then a reference to 1983 (which provides no syntax) is not appropriate. I'd instead refer to 5321 definition of "Domain" for domain, the 5321 definition of "Mailbox" for sender, and simply create the ABNF for ip. BTW: In 1.1.2, you incorrectly identify "local-part" as imported from 5321. That's wrong. 5321 has "Local-part". Easy enough to fix that. I'm not worried about the rest of the references to it throughout the document as lowercase "local-part"; 5321 does that too. So, here would be my list of changes to accomplish this: - In 1.1.2, change the second sentence to: "The tokens "Local-part", "Domain", and "Mailbox" are defined in [RFC5321]." - Remove "domain" from Appendix A; it's now imported from 5321. - Add "sender = Mailbox" to Appendix A - Add "ip = ip4-network / ip6-network" to Appendix A pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From presnick@qti.qualcomm.com Sat Aug 17 06:12:32 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 120A711E810A for ; Sat, 17 Aug 2013 06:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 MjIYpx3J9vBj for ; Sat, 17 Aug 2013 06:12:27 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id C56AE21F9A4B for ; Sat, 17 Aug 2013 06:12:27 -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=1376745147; x=1408281147; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=STjMGw7XU+ypXTyoKtoHgOs5G2DEmU98JA5JMPiCGGs=; b=eWgOdGbTXu1w3iMw9kEwZ1TBwc3kXfWuHopNb7dZ7OQx7jFJTpZqj6If xeafLT6CtRoJ8+o5C12vhLseNwUSlLKfRFiXu2/C3omFJjNfWiwPLmoLO eMZnMc+oLwI6NgJVvQBZ1iQ0okbOm8h7RA6IqWxwd0WLOBVFoALqF/TD7 k=; X-IronPort-AV: E=Sophos;i="4.89,901,1367996400"; d="scan'208";a="49783484" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 17 Aug 2013 06:12:24 -0700 Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Aug 2013 06:12:23 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.146.2; Sat, 17 Aug 2013 06:12:23 -0700 Message-ID: <520F76B6.1030106@qti.qualcomm.com> Date: Sat, 17 Aug 2013 08:12:22 -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: Scott Kitterman References: <520BE458.3060807@qti.qualcomm.com> <2740178.6b98xEoijR@scott-latitude-e6320> In-Reply-To: <2740178.6b98xEoijR@scott-latitude-e6320> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org Subject: Re: [spfbis] AD Review of 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: Sat, 17 Aug 2013 13:12:32 -0000 [Skipping the obvious bits that you're just fixing, and the ABNF discussion we're having elsewhere.] On 8/16/13 9:21 PM, Scott Kitterman wrote: > On Wednesday, August 14, 2013 15:11:04 Pete Resnick wrote: > > >> 2.5 and forward: You introduce the term "operator" without ever defining >> it. Most of the time, operator refers to the deployer of the SPF record. >> Other times, operator refers to the interpreter. I think using two >> different terms throughout the document (neither of which is "operator") >> would be better. >> > Actually it's the other way around. The only time it's in reference to the > sending side of the equation is the initial reference. No. The initial use is section 2.5. In that one, it's the verifier, not the DNS operator. In 2.6.6 and 2.6.7, I think the operator in question is the DNS operator. In 8, it's the verifier. In 8.7, it's the DNS operator. In 9, both occurrences are the verifier. In 11.7 it's the verifier. In H.3 and H.4, it looks like all six references are to the verifier. > If it would help, I > think we could change the first one to DNS operator and the rest to SPF verifier > operator. I'm not sure this is worth fixing, so I'll wait for feedback. I will leave it up to the WG. I think it's a bit confusing, but not a huge deal. >> 2.6: I've never been clear why this section isn't simply part of section >> 4, but that's simply an editorial preference. >> > I think of section 2 as more about what and section 4 more about how, but what > we have now is roughly consistent with RFC 4408, so we shouldn't change it > without a good reason. > Understood. >> 2.6.1: Reference to "TXT records" here doesn't make sense. Prior to >> this, all references have been to "SPF records" (which is fine), and it >> isn't until section 4 that you mention TXT records at all. Either strike >> "TXT" or replace it with "SPF". >> > Now it has, "(b) no TXT records were retrieved from the DNS that appeared to > be intended for use by SPF verifiers." That's another way of saying SPF > records. If we were to replace the current text, it would be "(b) no SPF > records were retrieved from the DNS." Is that better? > That would be my preference. >> 5: I think "ptr" should be separated out. The current notation in >> parentheses is not very clear. I suggest something like: >> >> There is an additional designated sender mechanism that was defined >> in the earlier experimental version of this specification, but for >> reasons described in section 5.x, it SHOULD NOT be used: >> >> ptr >> >> Similar text should appear in 5.5, and maybe even in 7.2. If you make >> this change, moving 5.5 to the end of section 5 would also make sense. >> > We had stronger text about this at one point, but went back to where we are > now. A verifier still needs to implement ptr processing for backward > compatibility, so from an implementation perspective, it is still required. I > don't think we ought to segregate it out like this. > If this was a conscious decision of the WG, I will defer. >> 7.3: >> >> *DIGIT = zero or more digits >> r = reverse value, splitting on dots by default >> >> For some reason, those equal signs bother me. (They look too much like >> part of the ABNF.) I suggest either a "-" or a ":", or just tabbing over >> instead. It's no big deal either way. >> > This is almost exactly what was in RFC 4408. It had: > > Optional transformers are the following: > > *DIGIT = zero or more digits > 'r' = reverse value, splitting on dots by default > > I've gone ahead and changed my local copy to add the quotes back to 'r', but I > don't think we should change it further. I'm open to being wrong on that. > What do others think? > This is purely editorial nonsense, so I'm happy to leave it as it was in 4408. >> 8.2: I suggest changing "A 'neutral' result MUST be treated exactly like >> the 'none' result;" to "A 'neutral' result is operationally equivalent >> to a 'none' result". The MUST doesn't seem to be making an >> interoperability claim. >> > We debated this extensively in the working group. There were arguments in > favor of more extensive treatment of receiver policy and arguments in favor of > removing even the very limited text about it that was in RFC 4408. In the > end, we compromised on leaving it just like RFC 4408, which is what this is. > The interoperability argument is that if receivers treat neutral more harshly > than than none, it would be an impediment to deployment. > Well, "impediment to deployment" here is more of a psychological issue than a technical issue. But I'm not willing to re-open a big debate about this. If this is what the WG settled on, I'll hold my nose. :-) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From spf2@kitterman.com Sat Aug 17 06:15:38 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 85D5721F86B1 for ; Sat, 17 Aug 2013 06:15:38 -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 ZiNpLGOs2Y83 for ; Sat, 17 Aug 2013 06:15:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 709F221F8617 for ; Sat, 17 Aug 2013 06:15:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BE35020E40D4; Sat, 17 Aug 2013 09:15:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1376745324; bh=YRr1uwxSqICZsE5E8TnN9jBgpdkBRc+78isE6x+SPPw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=abjjnMAwLJ7rpi4kj0wh0+HMUGEm6FKnFN4Nne2eOuyGQglg5QdDZZ51DAKrLlTuj +7002xWShQWswEaDwIc4+Wzg2WvRdgD0Xhq/KkGMjloYEAJsW5JTVuYQ1TwPfAP/8M /lU/hTeeWE9I/cpuqCcKVsAYN+Bfxj1oqn3Idh6w= 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 A91F020E4043; Sat, 17 Aug 2013 09:15:24 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 17 Aug 2013 09:15:23 -0400 Message-ID: <1781928.SAPAyZxOk9@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-27-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <520F6FC4.6000404@isdg.net> References: <20130817032747.28661.14414.idtracker@ietfa.amsl.com> <520F6FC4.6000404@isdg.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] I-D Action: draft-ietf-spfbis-4408bis-18.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: Sat, 17 Aug 2013 13:15:38 -0000 On Saturday, August 17, 2013 08:42:44 Hector Santos wrote: > I posted back in July 15, the numerous spelling mistakes you had in rev > 17. You completely ignore it despite a direct CC email was sent to you. > > As a side note, lets talk about diversity and improving electronic > participation; first step - stop ignoring input, no scratch that - PEOPLE! I didn't ignore it, I forgot about it, please don't assume malice. Here are the changes Hector mentioned: > - 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 Any objections to any of these anyone? I think they are fine. Scott K From spf2@kitterman.com Sat Aug 17 06:31: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 67C4121F9DAF for ; Sat, 17 Aug 2013 06:31:18 -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 qnK0ZPObRBSY for ; Sat, 17 Aug 2013 06:31:13 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 51C9121F9B9F for ; Sat, 17 Aug 2013 06:31:13 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D49FF20E40D4; Sat, 17 Aug 2013 09:31:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1376746272; bh=ARnHaOXd7Z9ys1YB5rJEiniISOEXP/jM4tKwpQRK7C8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gDusY9yQj214T6NzDl96ynerPPhq4c6bowHPikbxOqQXRv2nxuGAZLhWAYZlFIFMg eHmYZENLAILmwvkkstvvjYfXM5C+J2UyxGIDiLQ7OEGZoyNCmMAwWEiDczsFfSkjgM RvcUa3a7O40aYnFxQAQimXH2RyziMpZ797lNcvgQ= 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 BA6DC20E4043; Sat, 17 Aug 2013 09:31:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 17 Aug 2013 09:31:09 -0400 Message-ID: <1514435.4FbWI0P7br@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-27-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <520F7298.6090202@qti.qualcomm.com> References: <20130817032748.28661.8091.idtracker@ietfa.amsl.com> <5277966.5He8UusIjb@scott-latitude-e6320> <520F7298.6090202@qti.qualcomm.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] New Version Notification - draft-ietf-spfbis-4408bis-18.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: Sat, 17 Aug 2013 13:31:18 -0000 On Saturday, August 17, 2013 07:54:48 Pete Resnick wrote: > On 8/17/13 12:26 AM, Scott Kitterman wrote: > >> I went through the draft-ietf-spfbis-4408bis-18 and I did not see a > >> requirement for "domain". > > > > As Pete mentioned, it's one of the inputs to check_host() listed in 4.1. > > And is used many times as throughout the document. > > The *term* "domain" is used throughout the document, but it's never used > as an ABNF terminal. > > >> To summarize: > >> (a) Fix the error in Section 7.2 > >> > >> (b) Drop the "domain" line in the ABNF in Appendix A > >> > >> If Scott and you are okay with that, a -19 can be generated and the > >> Last Call initiated. > > > > No. I'm not. It's part of the ABNF introduced in 4.1 and properly part > > of > > the collected ABNF in Appendix A. We did discuss this before which is how > > we got where we are not. Removing it does not make sense to me and is > > contrary to the prior conclusion of the group. > > But this reasoning means that you have a different problem: There is no > ABNF for "sender" or "ip". By your argument, those are missing and need > to be added. > > I don't think you need any of them. They are all described well enough > in 4.1 and providing ABNF is unnecessary in my opinion. > > But if the WG really thinks that providing ABNF for these is required, > then a reference to 1983 (which provides no syntax) is not appropriate. > I'd instead refer to 5321 definition of "Domain" for domain, the 5321 > definition of "Mailbox" for sender, and simply create the ABNF for ip. > > BTW: In 1.1.2, you incorrectly identify "local-part" as imported from > 5321. That's wrong. 5321 has "Local-part". Easy enough to fix that. I'm > not worried about the rest of the references to it throughout the > document as lowercase "local-part"; 5321 does that too. > > So, here would be my list of changes to accomplish this: > > - In 1.1.2, change the second sentence to: "The tokens "Local-part", > "Domain", and "Mailbox" are defined in [RFC5321]." > - Remove "domain" from Appendix A; it's now imported from 5321. > - Add "sender = Mailbox" to Appendix A > - Add "ip = ip4-network / ip6-network" to Appendix A All done locally for -19. Scott K From spf2@kitterman.com Sat Aug 17 06:48:27 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 B5BD811E8110 for ; Sat, 17 Aug 2013 06:48: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.001, BAYES_00=-2.599, HTML_MESSAGE=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 pp-0uOHDDNv3 for ; Sat, 17 Aug 2013 06:48:23 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA8311E80F8 for ; Sat, 17 Aug 2013 06:48:22 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A5C4E20E40D4; Sat, 17 Aug 2013 09:48:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1376747297; bh=yxRGiw63FJR4JsHAERUJprP2hfQ6EYc/fJzD7q+YCCg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cZjskk3+HFKXTiCEQ+8XG8wSs3ES+UlHxq+Hg3MswTn5RKqxgJ5xbY2tdOVCTp0Hn ZrjDpHlOZpDbPsKorls9Ed9mBGie8nCrCYqY0Vw3J+nETnPhIddZ5Yh5Zni90j1szk fx66/LQVRPftv73KYErtX7nwemfHJueBsrEAOAUY= 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 8369820E4043; Sat, 17 Aug 2013 09:48:17 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 17 Aug 2013 09:48:16 -0400 Message-ID: <196681373.R9HtK96ds2@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-27-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <520F76B6.1030106@qti.qualcomm.com> References: <520BE458.3060807@qti.qualcomm.com> <2740178.6b98xEoijR@scott-latitude-e6320> <520F76B6.1030106@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart3146446.rz794kpdr7" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] AD Review of 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: Sat, 17 Aug 2013 13:48:27 -0000 This is a multi-part message in MIME format. --nextPart3146446.rz794kpdr7 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Saturday, August 17, 2013 08:12:22 Pete Resnick wrote: > [Skipping the obvious bits that you're just fixing, and the ABNF > discussion we're having elsewhere.] > > On 8/16/13 9:21 PM, Scott Kitterman wrote: > > On Wednesday, August 14, 2013 15:11:04 Pete Resnick wrote: > >> 2.5 and forward: You introduce the term "operator" without ever defining > >> it. Most of the time, operator refers to the deployer of the SPF record. > >> Other times, operator refers to the interpreter. I think using two > >> different terms throughout the document (neither of which is "operator") > >> would be better. > > > > Actually it's the other way around. The only time it's in reference to > > the > > sending side of the equation is the initial reference. > > No. The initial use is section 2.5. In that one, it's the verifier, not > the DNS operator. In 2.6.6 and 2.6.7, I think the operator in question > is the DNS operator. In 8, it's the verifier. In 8.7, it's the DNS > operator. In 9, both occurrences are the verifier. In 11.7 it's the > verifier. In H.3 and H.4, it looks like all six references are to the > verifier. > > > If it would help, I > > think we could change the first one to DNS operator and the rest to SPF > > verifier operator. I'm not sure this is worth fixing, so I'll wait for > > feedback. > I will leave it up to the WG. I think it's a bit confusing, but not a > huge deal. I think I'd prefer to leave it. I can see how it's not 100% clear, but I think it's reasonably so from context. I'm afraid if I change it now, I'll worsen it. Anyone else have an opinion? I don't feel strongly about it. > >> 2.6: I've never been clear why this section isn't simply part of section > >> 4, but that's simply an editorial preference. > > > > I think of section 2 as more about what and section 4 more about how, but > > what we have now is roughly consistent with RFC 4408, so we shouldn't > > change it without a good reason. > > Understood. > > >> 2.6.1: Reference to "TXT records" here doesn't make sense. Prior to > >> this, all references have been to "SPF records" (which is fine), and it > >> isn't until section 4 that you mention TXT records at all. Either strike > >> "TXT" or replace it with "SPF". > > > > Now it has, "(b) no TXT records were retrieved from the DNS that appeared > > to be intended for use by SPF verifiers." That's another way of saying > > SPF records. If we were to replace the current text, it would be "(b) no > > SPF records were retrieved from the DNS." Is that better? > > That would be my preference. Done. > >> 5: I think "ptr" should be separated out. The current notation in > >> > >> parentheses is not very clear. I suggest something like: > >> There is an additional designated sender mechanism that was defined > >> in the earlier experimental version of this specification, but for > >> > >> reasons described in section 5.x, it SHOULD NOT be used: > >> ptr > >> > >> Similar text should appear in 5.5, and maybe even in 7.2. If you make > >> this change, moving 5.5 to the end of section 5 would also make sense. > > > > We had stronger text about this at one point, but went back to where we > > are > > now. A verifier still needs to implement ptr processing for backward > > compatibility, so from an implementation perspective, it is still > > required. I don't think we ought to segregate it out like this. > > If this was a conscious decision of the WG, I will defer. I'm going to leave it as is unless someone else suggests I should do otherwise. > >> 7.3: > >> *DIGIT = zero or more digits > >> > >> r = reverse value, splitting on dots by default > >> > >> For some reason, those equal signs bother me. (They look too much like > >> part of the ABNF.) I suggest either a "-" or a ":", or just tabbing over > >> instead. It's no big deal either way. > > > > This is almost exactly what was in RFC 4408. It had: > > Optional transformers are the following: > > *DIGIT = zero or more digits > > 'r' = reverse value, splitting on dots by default > > > > I've gone ahead and changed my local copy to add the quotes back to 'r', > > but I don't think we should change it further. I'm open to being wrong > > on that. What do others think? > > This is purely editorial nonsense, so I'm happy to leave it as it was in > 4408. > > >> 8.2: I suggest changing "A 'neutral' result MUST be treated exactly like > >> the 'none' result;" to "A 'neutral' result is operationally equivalent > >> to a 'none' result". The MUST doesn't seem to be making an > >> interoperability claim. > > > > We debated this extensively in the working group. There were arguments in > > favor of more extensive treatment of receiver policy and arguments in > > favor of removing even the very limited text about it that was in RFC > > 4408. In the end, we compromised on leaving it just like RFC 4408, which > > is what this is. The interoperability argument is that if receivers treat > > neutral more harshly than than none, it would be an impediment to > > deployment. > > Well, "impediment to deployment" here is more of a psychological issue > than a technical issue. But I'm not willing to re-open a big debate > about this. If this is what the WG settled on, I'll hold my nose. :-) Thanks. I've also gone ahead and applied Hector's typo fixes. I've attached an rfcdiff from the published -18 to my local copy of the to be -19 so we can ensure we're on the same page before I upload it. Let me know if I got it right. Scott K --nextPart3146446.rz794kpdr7 Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-19-from-18.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-spfbis-4408bis-19-from-18.diff.html" Diff: draft-ietf-spfbis-4408bis-18.txt - draft-ietf-spfbis-4408bis-19.txt
 draft-ietf-spfbis-4408bis-18.txt   draft-ietf-spfbis-4408bis-19.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft Kitterman Technical Services Internet-Draft Kitterman Technical Services
Obsoletes: 4408 (if approved) August 16, 2013 Obsoletes: 4408 (if approved) August 17, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: February 17, 2014 Expires: February 18, 2014
Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,
Version 1 Version 1
draft-ietf-spfbis-4408bis-18 draft-ietf-spfbis-4408bis-19
Abstract Abstract
Email on the Internet can be forged in a number of ways. In Email on the Internet can be forged in a number of ways. In
particular, existing protocols place no restriction on what a sending 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 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 SMTP HELO/EHLO commands. This document describes version 1 of
the Sender Policy Framework (SPF) protocol, whereby ADministrative the Sender Policy Framework (SPF) protocol, whereby ADministrative
Management Domains (ADMDs) can explicitly authorize the hosts that Management Domains (ADMDs) can explicitly authorize the hosts that
are allowed to use its domain names, and a receiving host can check are allowed to use its domain names, and a receiving host can check
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 17, 2014. This Internet-Draft will expire on February 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 48 skipping to change at page 6, line 48
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
1.1.2. Imported Definitions 1.1.2. Imported Definitions
ABNF (Augmented Backus-Naur Form) ABNF is defined in [RFC5234], as ABNF (Augmented Backus-Naur Form) ABNF is defined in [RFC5234], as
are the tokens "ALPHA", "DIGIT", and "SP" (space). are the tokens "ALPHA", "DIGIT", and "SP" (space).
The token "local-part" is defined in [RFC5321]. The tokens "Local-part", "Domain", and "Mailbox are defined in
[RFC5321].
"dot-atom", "quoted-string", "comment", "CFWS" (comment folded white "dot-atom", "quoted-string", "comment", "CFWS" (comment folded white
space), "FWS" (folded white space), and "CRLF" (carriage-return/ space), "FWS" (folded white space), and "CRLF" (carriage-return/
line-feed) are defined in [RFC5322]. line-feed) are defined in [RFC5322].
1.1.3. MAIL FROM Definition 1.1.3. MAIL FROM Definition
This document is concerned with the portion of a mail message This document is concerned with the portion of a mail message
commonly called "envelope sender", "return path", "reverse path", commonly called "envelope sender", "return path", "reverse path",
"bounce address", "5321 FROM", "MAIL FROM", or RFC5321.MailFrom. "bounce address", "5321 FROM", "MAIL FROM", or RFC5321.MailFrom.
skipping to change at page 10, line 28 skipping to change at page 10, line 28
[RFC5321]). In this case, there is no explicit sender mailbox, and [RFC5321]). In this case, there is no explicit sender mailbox, and
such a message can be assumed to be a notification message from the such a message can be assumed to be a notification message from the
mail system itself. When the reverse-path is null, this document mail system itself. When the reverse-path is null, this document
defines the "MAIL FROM" identity to be the mailbox composed of the defines the "MAIL FROM" identity to be the mailbox composed of the
local-part "postmaster" and the "HELO" identity (which might or might local-part "postmaster" and the "HELO" identity (which might or might
not have been checked separately before). not have been checked separately before).
2.5. Location of Checks 2.5. Location of Checks
The authorization check SHOULD be performed during the processing of The authorization check SHOULD be performed during the processing of
the SMTP transaction that recieves the mail. This reduces the the SMTP transaction that receives the mail. This reduces the
complexity of determining the correct IP address to use as an input complexity of determining the correct IP address to use as an input
to check_host() and allows errors to be returned directly to the to check_host() and allows errors to be returned directly to the
sending MTA by way of SMTP replies. Appendix C of [RFC5451] provides sending MTA by way of SMTP replies. Appendix C of [RFC5451] provides
a more thorough discussion of this topic. a more thorough discussion of this topic.
Performing the authorization check other than using the MAIL FROM and Performing the authorization check other than using the MAIL FROM and
client address at the time of the MAIL command during the SMTP client address at the time of the MAIL command during the SMTP
transaction can cause problems, such as the following: (1) It might transaction can cause problems, such as the following: (1) It might
be difficult to accurately extract the required information from be difficult to accurately extract the required information from
potentially deceptive headers; (2) legitimate email might fail potentially deceptive headers; (2) legitimate email might fail
skipping to change at page 11, line 17 skipping to change at page 11, line 17
This section enumerates and briefly defines the possible outputs of This section enumerates and briefly defines the possible outputs of
that function. Note, however, that the protocol establishes no that function. Note, however, that the protocol establishes no
normative requirements for handling any particular result. normative requirements for handling any particular result.
Discussion of handling options for each result can be found in Discussion of handling options for each result can be found in
Section 8. Section 8.
2.6.1. None 2.6.1. None
A result of "none" means either (a) no syntactically valid DNS domain A result of "none" means either (a) no syntactically valid DNS domain
name was extracted from the SMTP session that could be used as the name was extracted from the SMTP session that could be used as the
one to be authorized, or (b) no TXT records were retrieved from the one to be authorized, or (b) no SPF records were retrieved from the
DNS that appeared to be intended for use by SPF verifiers. DNS.
2.6.2. Neutral 2.6.2. Neutral
The ADMD has explicitly stated that it is not asserting whether the The ADMD has explicitly stated that it is not asserting whether the
IP address is authorized. IP address is authorized.
2.6.3. Pass 2.6.3. Pass
A "pass" result means that the client is authorized to inject mail A "pass" result means that the client is authorized to inject mail
with the given identity. with the given identity.
skipping to change at page 34, line 15 skipping to change at page 34, line 15
1970, UTC) at the time of the evaluation. This is the same value as 1970, UTC) at the time of the evaluation. This is the same value as
is returned by the POSIX time() function in most standards-compliant is returned by the POSIX time() function in most standards-compliant
libraries. libraries.
When the result of macro expansion is used in a domain name query, if When the result of macro expansion is used in a domain name query, if
the expanded domain name exceeds 253 characters (the maximum length the expanded domain name exceeds 253 characters (the maximum length
of a domain name in this format), the left side is truncated to fit, of a domain name in this format), the left side is truncated to fit,
by removing successive domain labels (and their following dots) until by removing successive domain labels (and their following dots) until
the total length does not exceed 253 characters. the total length does not exceed 253 characters.
Uppercased macros expand exactly as their lowercased equivalents, and Uppercase macros expand exactly as their lowercase equivalents, and
are then URL escaped. URL escaping MUST be performed for characters are then URL escaped. URL escaping MUST be performed for characters
not in the "unreserved" set, which is defined in [RFC3986]. not in the "unreserved" set, which is defined in [RFC3986].
Care has to be taken by the sending ADMD so that macro expansion for Care has to be taken by the sending ADMD so that macro expansion for
legitimate email does not exceed the 63-character limit on DNS legitimate email does not exceed the 63-character limit on DNS
labels. The local-part of email addresses, in particular, can have labels. The local-part of email addresses, in particular, can have
more than 63 characters between dots. more than 63 characters between dots.
To minimize DNS lookup resource requirements, it is better if sending To minimize DNS lookup resource requirements, it is better if sending
ADMDs avoid using the "s", "l", "o", or "h" macros in conjunction ADMDs avoid using the "s", "l", "o", or "h" macros in conjunction
skipping to change at page 57, line 47 skipping to change at page 57, line 47
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key = "client-ip" / "envelope-from" / "helo" / key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" / "problem" / "receiver" / "identity" /
"mechanism" / name "mechanism" / name
identity = "mailfrom" ; for the "MAIL FROM" identity identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity / "helo" ; for the "HELO" identity
/ name ; other identities / name ; other identities
sender = Mailbox
ip = ip4-network / ip6-network
ALPHA = <A-Z / a-z as per [RFC5234]> ALPHA = <A-Z / a-z as per [RFC5234]>
DIGIT = <0-9 as per [RFC5234]> DIGIT = <0-9 as per [RFC5234]>
SP = <space character as per [RFC5234]> SP = <space character as per [RFC5234]>
domain = <fully qualified domain as per [RFC1983]>
dot-atom = <unquoted word as per [RFC5322]> dot-atom = <unquoted word as per [RFC5322]>
quoted-string = <quoted string as per [RFC5322]> quoted-string = <quoted string as per [RFC5322]>
comment = <comment string as per [RFC5322]> comment = <comment string as per [RFC5322]>
CFWS = <comment or folding white space as per [RFC5322]> CFWS = <comment or folding white space as per [RFC5322]>
FWS = <folding white space as per [RFC5322]> FWS = <folding white space as per [RFC5322]>
CRLF = <standard end-of-line token as per [RFC5322]> CRLF = <standard end-of-line token as per [RFC5322]>
Appendix B. Extended Examples Appendix B. Extended Examples
These examples are based on the following DNS setup: These examples are based on the following DNS setup:
skipping to change at page 66, line 20 skipping to change at page 66, line 20
check described in this document. If the domain part of the "MAIL check described in this document. If the domain part of the "MAIL
FROM" identity used for such email uses the domain of one of the MSPs FROM" identity used for such email uses the domain of one of the MSPs
domain, then the provider needs only to ensure that its sending host domain, then the provider needs only to ensure that its sending host
is authorized by its own SPF record, if any. is authorized by its own SPF record, if any.
If the "MAIL FROM" identity does not use the MSP's domain, then extra If the "MAIL FROM" identity does not use the MSP's domain, then extra
care has to be taken. The SPF record format has several options for care has to be taken. The SPF record format has several options for
the third-party domain to authorize the service provider's MTAs to the third-party domain to authorize the service provider's MTAs to
send mail on its behalf. For MSPs, such as ISPs, that have a wide send mail on its behalf. For MSPs, such as ISPs, that have a wide
variety of customers using the same MTA, steps are required to variety of customers using the same MTA, steps are required to
mitiate the risk of cross-customer forgery (see Section 11.4). mitigate the risk of cross-customer forgery (see Section 11.4).
Appendix G. MTA Relays Appendix G. MTA Relays
Relays are described in [RFC5598] Section 2.2.2. The authorization Relays are described in [RFC5598] Section 2.2.2. The authorization
check generally precludes the use of arbitrary MTA relays between check generally precludes the use of arbitrary MTA relays between
sender and receiver of an email message. sender and receiver of an email message.
Within an organization, MTA relays can be effectively deployed. Within an organization, MTA relays can be effectively deployed.
However, for purposes of this document, such relays are effectively However, for purposes of this document, such relays are effectively
transparent. The SPF authorization check is a check between border transparent. The SPF authorization check is a check between border
skipping to change at page 68, line 48 skipping to change at page 68, line 48
have the advantages of resource conservation and immediate feedback have the advantages of resource conservation and immediate feedback
to the sender associated with SMTP rejection, but could produce fewer to the sender associated with SMTP rejection, but could produce fewer
undesirable rejections in a well designed system. Such an approach undesirable rejections in a well designed system. Such an approach
might result in email that was not authorized by the sending ADMD might result in email that was not authorized by the sending ADMD
being unknowingly delivered to end users. being unknowingly delivered to end users.
Either general approach can be used as they both leave a clear Either general approach can be used as they both leave a clear
disposition of emails. They are either delivered in some manner or disposition of emails. They are either delivered in some manner or
the sender is notified of the failure. Other dispositions such as the sender is notified of the failure. Other dispositions such as
"dropping" or deleting email after acceptance are inappropriate "dropping" or deleting email after acceptance are inappropriate
because they leave uncertainty and reduce the overall reliabilility because they leave uncertainty and reduce the overall reliability and
and utility of email across the Internet. utility of email across the Internet.
H.3. Policy For SPF Permerror H.3. Policy For SPF Permerror
The "permerror" result (see Section 2.6.7) indicates the SPF The "permerror" result (see Section 2.6.7) indicates the SPF
processing module at the receiver determined that the retrieved SPF processing module at the receiver determined that the retrieved SPF
policy record could not be interpreted. This gives no true policy record could not be interpreted. This gives no true
indication about the authorized use of the data found in the indication about the authorized use of the data found in the
envelope. envelope.
As with all results, implementers have a choice to make regarding As with all results, implementers have a choice to make regarding
skipping to change at page 70, line 16 skipping to change at page 70, line 16
receiver can do to draw attention to the difficulty encountered while receiver can do to draw attention to the difficulty encountered while
protecting itself from messages that do not have a definite SPF protecting itself from messages that do not have a definite SPF
result of some kind. However, if the SPF implementation is defective result of some kind. However, if the SPF implementation is defective
and returns spurious "temperror" results, only the sender is actively and returns spurious "temperror" results, only the sender is actively
notified of the defect (in the form of mail rejected after it times notified of the defect (in the form of mail rejected after it times
out of the sending queue), and not the receiver making use of SPF. out of the sending queue), and not the receiver making use of SPF.
Because of long queue lifetimes, it is possible that mail will be Because of long queue lifetimes, it is possible that mail will be
repeatedly deferred for several days and so any awareness by the repeatedly deferred for several days and so any awareness by the
sender of a problem could be quite delayed. If "temperrors" persist sender of a problem could be quite delayed. If "temperrors" persist
for multiple delivery attempts, it might be perferable to treat the for multiple delivery attempts, it might be preferable to treat the
error as permanent and reduce the amount of time the message is in error as permanent and reduce the amount of time the message is in
transit. transit.
The less intrusive handling choice is to deliver the message, perhaps The less intrusive handling choice is to deliver the message, perhaps
with some kind of annotation of the difficulty encountered and/or with some kind of annotation of the difficulty encountered and/or
logging of a similar nature. However, this will not be desirable to logging of a similar nature. However, this will not be desirable to
operators that wish to implement SPF checking as strictly as operators that wish to implement SPF checking as strictly as
possible, nor is this sort of passive problem reporting typically possible, nor is this sort of passive problem reporting typically
effective. effective.
 End of changes. 13 change blocks. 
14 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart3146446.rz794kpdr7-- From john@jlc.net Sat Aug 17 14:49:30 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 BF3B111E820B for ; Sat, 17 Aug 2013 14:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.882 X-Spam-Level: X-Spam-Status: No, score=-105.882 tagged_above=-999 required=5 tests=[AWL=0.717, 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 YpnWUeZMSNS1 for ; Sat, 17 Aug 2013 14:49:25 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8850A11E824A for ; Sat, 17 Aug 2013 14:49:25 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 681D333C24; Sat, 17 Aug 2013 17:49:24 -0400 (EDT) Date: Sat, 17 Aug 2013 17:49:24 -0400 From: John Leslie To: Scott Kitterman Message-ID: <20130817214924.GL68553@verdi> References: <520BE458.3060807@qti.qualcomm.com> <2740178.6b98xEoijR@scott-latitude-e6320> <520F76B6.1030106@qti.qualcomm.com> <196681373.R9HtK96ds2@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <196681373.R9HtK96ds2@scott-latitude-e6320> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] AD Review of 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: Sat, 17 Aug 2013 21:49:30 -0000 Scott Kitterman wrote: > On Saturday, August 17, 2013 08:12:22 Pete Resnick wrote: >> On 8/16/13 9:21 PM, Scott Kitterman wrote: >>> On Wednesday, August 14, 2013 15:11:04 Pete Resnick wrote: >>>> >>>> 2.5 and forward: You introduce the term "operator" without ever defining >>>> it. Most of the time, operator refers to the deployer of the SPF record. >>>> Other times, operator refers to the interpreter. I think using two >>>> different terms throughout the document (neither of which is "operator") >>>> would be better. >>> >>> Actually it's the other way around. The only time it's in reference to >>> the sending side of the equation is the initial reference. >> >> No. The initial use is section 2.5. In that one, it's the verifier, not >> the DNS operator. In 2.6.6 and 2.6.7, I think the operator in question >> is the DNS operator. In 8, it's the verifier. In 8.7, it's the DNS >> operator. In 9, both occurrences are the verifier. In 11.7 it's the >> verifier. In H.3 and H.4, it looks like all six references are to the >> verifier. >>... > > I think I'd prefer to leave it. I can see how it's not 100% clear, but I > think it's reasonably so from context. IMHO, if Pete and you can read it differently, I think it should be clarified. At the very least, the term now refers to different actors. > I'm afraid if I change it now, I'll worsen it. It's much better to face that problem now. -- John Leslie From presnick@qti.qualcomm.com Sat Aug 17 15:47:06 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 7412021F9967 for ; Sat, 17 Aug 2013 15:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0YROO5ttI5UV for ; Sat, 17 Aug 2013 15:47:02 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5D66711E819B for ; Sat, 17 Aug 2013 15:46:56 -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=1376779616; x=1408315616; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Sv5ZTr4ZLTAcd7Le0Ukihve+jw2iwysvsNnbf4kLOSk=; b=FYtoVM0ebvbcJ2qmIUkPpm0FvaOA+EB7HanSZdkbDP259U7dxX91MKRs Y+/Go1Fra4to46//v2wkw79X/pLIisWCXZuY0e8cmDXBf4BjeGwJ5Jkgq uQb16LQxg0V06f0dmYpxpedcF10/bFUgUmM/yT3SdlGUaPbx1JaueJmh1 Y=; X-IronPort-AV: E=Sophos;i="4.89,903,1367996400"; d="scan'208";a="49688758" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 17 Aug 2013 15:46:55 -0700 Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Aug 2013 15:46:54 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.146.2; Sat, 17 Aug 2013 15:46:54 -0700 Message-ID: <520FFD5C.5010705@qti.qualcomm.com> Date: Sat, 17 Aug 2013 17:46:52 -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: Scott Kitterman References: <520BE458.3060807@qti.qualcomm.com> <2740178.6b98xEoijR@scott-latitude-e6320> <520F76B6.1030106@qti.qualcomm.com> <196681373.R9HtK96ds2@scott-latitude-e6320> In-Reply-To: <196681373.R9HtK96ds2@scott-latitude-e6320> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org Subject: Re: [spfbis] AD Review of 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: Sat, 17 Aug 2013 22:47:06 -0000 On 8/17/13 8:48 AM, Scott Kitterman wrote: > I've attached an rfcdiff from the published -18 to my local copy of the to be > -19 so we can ensure we're on the same page before I upload it. Let me know > if I got it right. > This looks fine. I'll leave it to SM to give you the official go-ahead, but with this I'm happy to put it out for Last Call. Anything outstanding from my comments are things that the WG can decide on just as any other comments that come in during Last Call. No reason to hold anything up. As soon as you get the OK from SM, post -19 and I'll assume that -19 is the one to Last Call. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From spf2@kitterman.com Sat Aug 17 21:03:20 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 896AA21F9ADC for ; Sat, 17 Aug 2013 21:03:20 -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 OdZV4r-wWlOo for ; Sat, 17 Aug 2013 21:03:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6923F21F9005 for ; Sat, 17 Aug 2013 21:03:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 48F8420E40D4; Sun, 18 Aug 2013 00:03:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1376798593; bh=8ojOuch/JFU70Mcj4SD2uuFJO+foTURAyYVJ3IKyclI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Cra0ghxa6ErwdBqIkzO27HHxFsH3Ln0Cz5Zhc2CFIPOvrhx8GbzcDJ5bGtxXzSn/B hfwUECqePR1H3OuCNbrJBNpdZ7o2APmTgbzmta8KP8rjv8aqaf4bm/+pLFXqlE/4Id mD795lf9ExmyvFDbCpiQLhC0dlxFf/5MhUBONwlA= 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 2FC6620E4043; Sun, 18 Aug 2013 00:03:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 18 Aug 2013 00:03:12 -0400 Message-ID: <3948169.6N92Gkn6ob@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-27-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <20130817214924.GL68553@verdi> References: <520BE458.3060807@qti.qualcomm.com> <196681373.R9HtK96ds2@scott-latitude-e6320> <20130817214924.GL68553@verdi> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] AD Review of 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: Sun, 18 Aug 2013 04:03:20 -0000 On Saturday, August 17, 2013 17:49:24 John Leslie wrote: > Scott Kitterman wrote: > > On Saturday, August 17, 2013 08:12:22 Pete Resnick wrote: > >> On 8/16/13 9:21 PM, Scott Kitterman wrote: > >>> On Wednesday, August 14, 2013 15:11:04 Pete Resnick wrote: > >>>> 2.5 and forward: You introduce the term "operator" without ever > >>>> defining > >>>> it. Most of the time, operator refers to the deployer of the SPF > >>>> record. > >>>> Other times, operator refers to the interpreter. I think using two > >>>> different terms throughout the document (neither of which is > >>>> "operator") > >>>> would be better. > >>> > >>> Actually it's the other way around. The only time it's in reference to > >>> the sending side of the equation is the initial reference. > >> > >> No. The initial use is section 2.5. In that one, it's the verifier, not > >> the DNS operator. In 2.6.6 and 2.6.7, I think the operator in question > >> is the DNS operator. In 8, it's the verifier. In 8.7, it's the DNS > >> operator. In 9, both occurrences are the verifier. In 11.7 it's the > >> verifier. In H.3 and H.4, it looks like all six references are to the > >> verifier. > >> > >>... > >> > > I think I'd prefer to leave it. I can see how it's not 100% clear, but I > > think it's reasonably so from context. > > IMHO, if Pete and you can read it differently, I think it should be > clarified. At the very least, the term now refers to different actors. > > > I'm afraid if I change it now, I'll worsen it. > > It's much better to face that problem now. Makes sense. I'll wait and see what sm says, although you now tipped my feeling in the direction of I should change it. Scott K From sm@elandsys.com Sat Aug 17 22:26:31 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 7B4CB11E8218 for ; Sat, 17 Aug 2013 22:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 DJ5WnzzjmJu3 for ; Sat, 17 Aug 2013 22:26:28 -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 C651911E81C9 for ; Sat, 17 Aug 2013 22:26:28 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.108]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7I5QBbv018252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Aug 2013 22:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376803585; bh=sfuDya9iflKG4QIveA9kdvmPTUjNRBshI644zN9TgE8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4oBvY+2tmDHQFBfCz1J3ZTJmuzXzaFsLHQSSZ78yVCpcCtYqMxfGf0K57UmfoN2CW acdsbfu67BgAkzDvVxyIA8aHDshDRD7o1v78FdYJJOsHHBtYyoCUzc3OviqX/od2aV 5ulTrJYtlSO1hQ1/vVTzStQHBFh8az8JdGu0zbyI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1376803585; i=@elandsys.com; bh=sfuDya9iflKG4QIveA9kdvmPTUjNRBshI644zN9TgE8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pF/6jo34eZrW2z8tuOlN7+H+kFlZ5++CSaneMUQUPWmIq6FXiv55594uur+cEm22y HNOmDCR3Q+Q4PHmeFe2zvRIlpyXUgPgsNZM3CNBrVAQ5HhW6gb+ZoeAvw0c81xZYG9 G2mIgfmj4cZ6CE2tlFKww0B9SmaXedUVrSOxWwog= Message-Id: <6.2.5.6.2.20130817221118.0b49d798@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 17 Aug 2013 22:25:43 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <520FFD5C.5010705@qti.qualcomm.com> References: <520BE458.3060807@qti.qualcomm.com> <2740178.6b98xEoijR@scott-latitude-e6320> <520F76B6.1030106@qti.qualcomm.com> <196681373.R9HtK96ds2@scott-latitude-e6320> <520FFD5C.5010705@qti.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Pete Resnick , John Leslie Subject: Re: [spfbis] AD Review of 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: Sun, 18 Aug 2013 05:26:31 -0000 Hi Scott, At 15:46 17-08-2013, Pete Resnick wrote: >This looks fine. I'll leave it to SM to give you the official >go-ahead, but with this I'm happy to put it out for Last Call. >Anything outstanding from my comments are things that the WG can >decide on just as any other comments that come in during Last Call. >No reason to hold anything up. As soon as you get the OK from SM, >post -19 and I'll assume that -19 is the one to Last Call. I would follow John Leslie's suggestion (see http://www.ietf.org/mail-archive/web/spfbis/current/msg03907.html ). Here's what I suggest: (i) Submit version -19 so that Pete Resnick can start the Last Call. (ii) Propose text on the SPFBIS mailing list for the change. Regards, S. Moonesamy (as document shepherd) From internet-drafts@ietf.org Sun Aug 18 03:29:54 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 3B29011E8284; Sun, 18 Aug 2013 03:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.020, 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 Yil6uwjxUYKM; Sun, 18 Aug 2013 03:29:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B33511E8279; Sun, 18 Aug 2013 03:29:53 -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.70.p1 Message-ID: <20130818102953.17305.51222.idtracker@ietfa.amsl.com> Date: Sun, 18 Aug 2013 03:29:53 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-19.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: Sun, 18 Aug 2013 10:29:54 -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-19.txt Pages : 75 Date : 2013-08-18 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-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Sun Aug 18 03:53:20 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 0EA7A11E80D9 for ; Sun, 18 Aug 2013 03:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 RTEacdQ5xQkJ for ; Sun, 18 Aug 2013 03:53:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 11BCC11E80D5 for ; Sun, 18 Aug 2013 03:53:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 347FF20E412A; Sun, 18 Aug 2013 06:53:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1376823193; bh=fdfuDMndUo6ZPa7WOLizsFlWDjNdxFLT8rgVHPxPDtM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Yqbj1RUrQQ6AaDzR3oZZMIhUCJ+aF3bQHRK2Jhuph8wVYrH/Nn/e+YroZtmPZuw7H 4x3WEoZVT9az32AdkQUonxbq1HueGpWWKrJadm3JCecYV9O3oTCvQOGylkbMCLJWQ0 L5CpRg+6KRwwPASjiOHJSlFepVvyJ/joLkzElnHE= 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 10BD820E40D3; Sun, 18 Aug 2013 06:53:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 18 Aug 2013 06:53:10 -0400 Message-ID: <1918035.C1U6nOh5SO@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-27-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130817221118.0b49d798@resistor.net> References: <520BE458.3060807@qti.qualcomm.com> <520FFD5C.5010705@qti.qualcomm.com> <6.2.5.6.2.20130817221118.0b49d798@resistor.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart34423700.eQWLIkv4RN" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] AD Review of 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: Sun, 18 Aug 2013 10:53:20 -0000 This is a multi-part message in MIME format. --nextPart34423700.eQWLIkv4RN Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Saturday, August 17, 2013 22:25:43 S Moonesamy wrote: > Hi Scott, > > At 15:46 17-08-2013, Pete Resnick wrote: > >This looks fine. I'll leave it to SM to give you the official > >go-ahead, but with this I'm happy to put it out for Last Call. > >Anything outstanding from my comments are things that the WG can > >decide on just as any other comments that come in during Last Call. > >No reason to hold anything up. As soon as you get the OK from SM, > >post -19 and I'll assume that -19 is the one to Last Call. > > I would follow John Leslie's suggestion (see > http://www.ietf.org/mail-archive/web/spfbis/current/msg03907.html > ). Here's what I suggest: > > (i) Submit version -19 so that Pete Resnick can start the Last Call. Done. > (ii) Propose text on the SPFBIS mailing list for the change. Proposed changes attached for comment. Scott K --nextPart34423700.eQWLIkv4RN Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-20-from-19.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-spfbis-4408bis-20-from-19.diff.html" Diff: draft-ietf-spfbis-4408bis-19.txt - draft-ietf-spfbis-4408bis-20.txt
 draft-ietf-spfbis-4408bis-19.txt   draft-ietf-spfbis-4408bis-20.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft Kitterman Technical Services Internet-Draft Kitterman Technical Services
Obsoletes: 4408 (if approved) August 17, 2013 Obsoletes: 4408 (if approved) August 18, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: February 18, 2014 Expires: February 19, 2014
Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,
Version 1 Version 1
draft-ietf-spfbis-4408bis-19 draft-ietf-spfbis-4408bis-20
Abstract Abstract
Email on the Internet can be forged in a number of ways. In Email on the Internet can be forged in a number of ways. In
particular, existing protocols place no restriction on what a sending 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 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 SMTP HELO/EHLO commands. This document describes version 1 of
the Sender Policy Framework (SPF) protocol, whereby ADministrative the Sender Policy Framework (SPF) protocol, whereby ADministrative
Management Domains (ADMDs) can explicitly authorize the hosts that Management Domains (ADMDs) can explicitly authorize the hosts that
are allowed to use its domain names, and a receiving host can check are allowed to use its domain names, and a receiving host can check
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2014. This Internet-Draft will expire on February 19, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 11, line 45 skipping to change at page 11, line 45
2.6.5. Softfail 2.6.5. Softfail
The ADMD has published a weak statement that the host is probably not The ADMD has published a weak statement that the host is probably not
authorized. It has not published a stronger, more definitive policy authorized. It has not published a stronger, more definitive policy
that results in a "fail". that results in a "fail".
2.6.6. Temperror 2.6.6. Temperror
A "temperror" result means the SPF verifier encountered a transient A "temperror" result means the SPF verifier encountered a transient
(generally DNS) error while performing the check. A later retry may (generally DNS) error while performing the check. A later retry may
succeed without further operator action. succeed without further DNS operator action.
2.6.7. Permerror 2.6.7. Permerror
A "permerror" result means the domain's published records could not A "permerror" result means the domain's published records could not
be correctly interpreted. This signals an error condition that be correctly interpreted. This signals an error condition that
definitely requires operator intervention to be resolved. definitely requires DNS operator intervention to be resolved.
3. SPF Records 3. SPF Records
An SPF record is a DNS record that declares which hosts are, and are An SPF record is a DNS record that declares which hosts are, and are
not, authorized to use a domain name for the "HELO" and "MAIL FROM" not, authorized to use a domain name for the "HELO" and "MAIL FROM"
identities. Loosely, the record partitions hosts into permitted and identities. Loosely, the record partitions hosts into permitted and
not-permitted sets (though some hosts might fall into neither not-permitted sets (though some hosts might fall into neither
category). category).
The SPF record is expressed as a single string of text found in the The SPF record is expressed as a single string of text found in the
skipping to change at page 36, line 7 skipping to change at page 36, line 7
%{d2}.trusted-domains.example.net %{d2}.trusted-domains.example.net
example.com.trusted-domains.example.net example.com.trusted-domains.example.net
IPv6: IPv6:
%{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com
8. Result Handling 8. Result Handling
This section provides guidance for operators in response to the This section provides guidance for SPF verifier operators in response
various possible outputs of check_host() on a message. Definitions to the various possible outputs of check_host() on a message.
of SPF results are presented in Section 2.6; this section provides Definitions of SPF results are presented in Section 2.6; this section
more detail on each for use in developing local policy for message provides more detail on each for use in developing local policy for
handling. message handling.
Every operating environment is different. There are some receivers Every operating environment is different. There are some receivers
for whom strict adherence to SPF is appropriate, and definitive for whom strict adherence to SPF is appropriate, and definitive
treatment of messages that are evaluated to be explicitly treatment of messages that are evaluated to be explicitly
unauthorized ("fail" and sometimes "softfail") is the norm. There unauthorized ("fail" and sometimes "softfail") is the norm. There
are others for which the "false negative" cases are more of a are others for which the "false negative" cases are more of a
concern. This concern is typically handled by merely recording the concern. This concern is typically handled by merely recording the
result in the header and allowing the message to pass on for result in the header and allowing the message to pass on for
additional processing. There are still others where SPF is one of additional processing. There are still others where SPF is one of
several inputs to the message handling decision. As such, there is several inputs to the message handling decision. As such, there is
skipping to change at page 38, line 28 skipping to change at page 38, line 28
software SHOULD use an SMTP reply code of 451 and, if supported, the software SHOULD use an SMTP reply code of 451 and, if supported, the
4.4.3 enhanced status code (see [RFC3463], Section 3.5). These 4.4.3 enhanced status code (see [RFC3463], Section 3.5). These
errors can be caused by problems in either the sender's or receiver's errors can be caused by problems in either the sender's or receiver's
DNS software. See Appendix H.4 for considerations on developing DNS software. See Appendix H.4 for considerations on developing
local policy. local policy.
8.7. Permerror 8.7. Permerror
A "permerror" result means the domain's published records could not A "permerror" result means the domain's published records could not
be correctly interpreted. This signals an error condition that be correctly interpreted. This signals an error condition that
definitely requires operator intervention to be resolved. If the definitely requires DNS operator intervention to be resolved. If the
message is rejected during the SMTP transaction for this reason, the message is rejected during the SMTP transaction for this reason, the
software SHOULD use an SMTP reply code of 550 and, if supported, the software SHOULD use an SMTP reply code of 550 and, if supported, the
5.5.2 enhanced status code (see [RFC3463], Section 3.6). Be aware 5.5.2 enhanced status code (see [RFC3463], Section 3.6). Be aware
that if the ADMD uses macros (Section 7), it is possible that this that if the ADMD uses macros (Section 7), it is possible that this
result is due to the checked identities having an unexpected format. result is due to the checked identities having an unexpected format.
It is also possible that this result is generated by certain SPF It is also possible that this result is generated by certain SPF
verifiers due to the input arguments having an unexpected format; see verifiers due to the input arguments having an unexpected format; see
Section 4.8. See Appendix H.3 for considerations on developing local Section 4.8. See Appendix H.3 for considerations on developing local
policy. policy.
9. Recording the Result 9. Recording the Result
To provide downstream agents, such as MUAs, with the information they To provide downstream agents, such as MUAs, with the information they
might need in terms of evaluating or representing the apparent safety might need in terms of evaluating or representing the apparent safety
of the message content, it is RECOMMENDED that SMTP receivers record of the message content, it is RECOMMENDED that SMTP receivers record
the result of SPF processing in the message header. For operators the result of SPF processing in the message header. For SPF verifier
that choose to record SPF results in the header of the message for operators that choose to record SPF results in the header of the
processing by internal filters or MUAs, two methods are presented. message for processing by internal filters or MUAs, two methods are
Section 9.1 defines the Received-SPF field, which is the results presented. Section 9.1 defines the Received-SPF field, which is the
field originally defined for SPF use. Section 9.2 discusses results field originally defined for SPF use. Section 9.2 discusses
Authentication-Results [RFC5451] which was specified more recently Authentication-Results [RFC5451] which was specified more recently
and is designed for use by SPF and other authentication methods. and is designed for use by SPF and other authentication methods.
Both are in common use, and hence both are included here. However, Both are in common use, and hence both are included here. However,
it is important to note that they were designed to serve slightly it is important to note that they were designed to serve slightly
different purposes. Received-SPF is intended to include enough different purposes. Received-SPF is intended to include enough
information to enable reconstruction of the SPF evaluation of the information to enable reconstruction of the SPF evaluation of the
message, while Authentication-Results is designed only to relay the message, while Authentication-Results is designed only to relay the
result itself and related output details of likely use to end users result itself and related output details of likely use to end users
(e.g., what property of the message was actually authenticated and (e.g., what property of the message was actually authenticated and
what it contained), leaving reconstructive work to the purview of what it contained), leaving reconstructive work to the purview of
system logs and the Received field contents. Also, Received-SPF system logs and the Received field contents. Also, Received-SPF
relies on compliance of agents within the receiving ADMD to adhere to relies on compliance of agents within the receiving ADMD to adhere to
the header field ordering rules of [RFC5321] and [RFC5322], while the header field ordering rules of [RFC5321] and [RFC5322], while
Authentication-Results includes some provisions to protect against Authentication-Results includes some provisions to protect against
non-compliant implementations. non-compliant implementations.
An operator could choose to use both to serve different downstream An SPF verifier operator could choose to use both to serve different
agents. In such cases, care needs to be taken to ensure both fields downstream agents. In such cases, care needs to be taken to ensure
are conveying the same details, or unexpected results can occur. both fields are conveying the same details, or unexpected results can
occur.
9.1. The Received-SPF Header Field 9.1. The Received-SPF Header Field
The Received-SPF header field is a trace field (see [RFC5322] Section The Received-SPF header field is a trace field (see [RFC5322] Section
3.6.7) and SHOULD be prepended to the existing header, above the 3.6.7) and SHOULD be prepended to the existing header, above the
Received: field that is generated by the SMTP receiver. It MUST Received: field that is generated by the SMTP receiver. It MUST
appear above all other Received-SPF fields in the message. The appear above all other Received-SPF fields in the message. The
header field has the following format: header field has the following format:
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
skipping to change at page 69, line 28 skipping to change at page 69, line 28
receiver can do to draw attention to the difficulty encountered while receiver can do to draw attention to the difficulty encountered while
protecting itself from messages that do not have a definite SPF protecting itself from messages that do not have a definite SPF
result of some kind. However, if the SPF implementation is defective result of some kind. However, if the SPF implementation is defective
and returns spurious "permerror" results, only the sender is actively and returns spurious "permerror" results, only the sender is actively
notified of the defect (in the form of rejected mail), and not the notified of the defect (in the form of rejected mail), and not the
receiver making use of SPF. receiver making use of SPF.
The less intrusive handling choice is to deliver the message, perhaps The less intrusive handling choice is to deliver the message, perhaps
with some kind of annotation of the difficulty encountered and/or with some kind of annotation of the difficulty encountered and/or
logging of a similar nature. However, this will not be desirable to logging of a similar nature. However, this will not be desirable to
operators that wish to implement SPF checking as strictly as SPF verifier operators that wish to implement SPF checking as
possible, nor is this sort of passive problem reporting typically strictly as possible, nor is this sort of passive problem reporting
effective. typically effective.
There is of course the option placing this choice in the hands of the There is of course the option placing this choice in the hands of the
operator rather than the implementer since this kind of choice is SPF verifier operator rather than the implementer since this kind of
often a matter of local policy rather than a condition with a choice is often a matter of local policy rather than a condition with
universal solution, but this adds one more piece of complexity to an a universal solution, but this adds one more piece of complexity to
already non-trivial environment. an already non-trivial environment.
Both implementers and operators need to be cautious of all choices Both implementers and SPF verfier operators need to be cautious of
and outcomes when handling SPF results. all choices and outcomes when handling SPF results.
H.4. Policy For SPF Temperror H.4. Policy For SPF Temperror
The "temperror" result (see Section 2.6.6) indicates the SPF The "temperror" result (see Section 2.6.6) indicates the SPF
processing module at the receiver could not retrieve and SPF policy processing module at the receiver could not retrieve and SPF policy
record due to a (probably) transient condition. This gives no true record due to a (probably) transient condition. This gives no true
indication about the authorized use of the data found in the indication about the authorized use of the data found in the
envelope. envelope.
As with all results, implementers have a choice to make regarding As with all results, implementers have a choice to make regarding
skipping to change at page 70, line 23 skipping to change at page 70, line 23
Because of long queue lifetimes, it is possible that mail will be Because of long queue lifetimes, it is possible that mail will be
repeatedly deferred for several days and so any awareness by the repeatedly deferred for several days and so any awareness by the
sender of a problem could be quite delayed. If "temperrors" persist sender of a problem could be quite delayed. If "temperrors" persist
for multiple delivery attempts, it might be preferable to treat the for multiple delivery attempts, it might be preferable to treat the
error as permanent and reduce the amount of time the message is in error as permanent and reduce the amount of time the message is in
transit. transit.
The less intrusive handling choice is to deliver the message, perhaps The less intrusive handling choice is to deliver the message, perhaps
with some kind of annotation of the difficulty encountered and/or with some kind of annotation of the difficulty encountered and/or
logging of a similar nature. However, this will not be desirable to logging of a similar nature. However, this will not be desirable to
operators that wish to implement SPF checking as strictly as SPF verifier operators that wish to implement SPF checking as
possible, nor is this sort of passive problem reporting typically strictly as possible, nor is this sort of passive problem reporting
effective. typically effective.
There is of course the option placing this choice in the hands of the There is of course the option placing this choice in the hands of the
operator rather than the implementer since this kind of choice is SPF verifier operator rather than the implementer since this kind of
often a matter of local policy rather than a condition with a choice is often a matter of local policy rather than a condition with
universal solution, but this adds one more piece of complexity to an a universal solution, but this adds one more piece of complexity to
already non-trivial environment. an already non-trivial environment.
Both implementers and operators need to be cautious of all choices Both implementers and SPF verifier operators need to be cautious of
and outcomes when handling SPF results. all choices and outcomes when handling SPF results.
Appendix I. Protocol Status Appendix I. Protocol Status
NOTE TO RFC EDITOR: To be removed prior to publication. NOTE TO RFC EDITOR: To be removed prior to publication.
SPF has been in development since the summer of 2003 and has seen SPF has been in development since the summer of 2003 and has seen
deployment beyond the developers beginning in December 2003. The deployment beyond the developers beginning in December 2003. The
design of SPF slowly evolved until the spring of 2004 and has since design of SPF slowly evolved until the spring of 2004 and has since
stabilized. There have been quite a number of forms of SPF, some stabilized. There have been quite a number of forms of SPF, some
written up as documents, some submitted as Internet Drafts, and many written up as documents, some submitted as Internet Drafts, and many
 End of changes. 16 change blocks. 
38 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart34423700.eQWLIkv4RN-- From iesg-secretary@ietf.org Mon Aug 19 06:19: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 C0F0E11E822F; Mon, 19 Aug 2013 06:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.148, 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 rFssCfTszYRd; Mon, 19 Aug 2013 06:19:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6310E11E80E3; Mon, 19 Aug 2013 06:19:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Sender: Message-ID: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 06:19:16 -0700 Cc: spfbis@ietf.org Subject: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 13:19:16 -0000 The IESG has received a request from the SPF Update WG (spfbis) to consider the following document: - 'Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1698/ From mansaxel@besserwisser.org Mon Aug 19 08:05:24 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 ED11311E82A9; Mon, 19 Aug 2013 08:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 JLsE8axdJROK; Mon, 19 Aug 2013 08:05:24 -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 475A111E829F; Mon, 19 Aug 2013 08:05:24 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id C10729E98; Mon, 19 Aug 2013 17:05:21 +0200 (CEST) Date: Mon, 19 Aug 2013 17:05:21 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: ietf@ietf.org Message-ID: <20130819150521.GB21088@besserwisser.org> References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5I6of5zJg18YgZEa" Content-Disposition: inline In-Reply-To: <20130819131916.22579.36328.idtracker@ietfa.amsl.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, IETF-Announce Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 19 Aug 2013 15:05:25 -0000 --5I6of5zJg18YgZEa Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: [spfbis] Last Call: (Sender Pol= icy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to = Proposed Standard Date: Mon, Aug 19, 2013 at 06:19:16AM -0700 Quoting The I= ESG (iesg-secretary@ietf.org) >=20 > The IESG has received a request from the SPF Update WG (spfbis) to > consider the following document: > - 'Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, > Version 1' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. I strongly OPPOSE draft-ietf-spfbis-4408bis-19.txt being published as RFC unless substantial parts are reworked. * The charter disallows major protocol changes -- removing the SPF RR type is a direct charter violation; since SPF is being used on the Internet. * The overloading of the TXT record is a hack at best, aimed at circumventing DNS management systems vendors that fail to ship support. Breaking the DNS model with specific resource records is not the way to get better application support. (besides, the major argument at the time was "it's so hard and takes ages to get a RR type", which isn't true anymore and also, the RRtype is allocated, what's the fuss? ) * The empirical data that was gathered and the conclusions from which that where published as RFC 6686 are IMNSHO flawed and rushed in that they set far too optimistic deadlines for adaptation before declaring failure. The IESG should send draft-ietf-spfbis-4408bis-19 back to spfbis wg and tell the wg that instead of deprecating SPF it should be algorithmically preferred while maintaining support for TXT. Thanks,=20 --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 It was a JOKE!! Get it?? I was receiving messages from DAVID LETTERMAN!! YOW!! --5I6of5zJg18YgZEa 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) iEYEARECAAYFAlISNDEACgkQ02/pMZDM1cXK+gCfYQ1Mv1CHjy9DDn7sA7DC7dF3 b48An1b49Zqf/du3dvN6pmj6in+CEujB =soFG -----END PGP SIGNATURE----- --5I6of5zJg18YgZEa-- From dotzero@gmail.com Mon Aug 19 12:03:08 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 236F921F8F2E; Mon, 19 Aug 2013 12:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 M-jF1ch2k3sk; Mon, 19 Aug 2013 12:03:07 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 49EB021F8E40; Mon, 19 Aug 2013 12:03:07 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id o17so6693698oag.35 for ; Mon, 19 Aug 2013 12:03:06 -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:content-transfer-encoding; bh=QZ1iaIX8m+MUQkSa4EvO7vfMH3GS8ltrxzSDM1qvPAM=; b=lgIdo9js0J6wyvNhw8yqmpJgt8S25tSF3VFOxCnbONT59305/x7t2H3CCj9hd4sAKs tyMy/8Uh7Avj3HSPb+LTE1Virm1htSn5eYY7OwKGSQ+J8Y5IoaDlZbiCdDxT+UAnBxdL YgWvAed3X1D1gZOSpIKXBOSitM3ymd8lo8+1176itKvUwRVPMhn3/xonYayHMQhMV7ye dsL+gWTF5rCC7DJWEdbQvpA/X9M4EmMouk43lvylEsnUQAeGUGltYXsOpEkwD5eZSN1Y qKoH1DwWAYXh2HQkLvWQ8BFzX7+Acy8+rfC9JBH11J97zvF5+NAr/vqTVkvD0576L7BM ofYw== MIME-Version: 1.0 X-Received: by 10.182.121.137 with SMTP id lk9mr14801490obb.32.1376938986737; Mon, 19 Aug 2013 12:03:06 -0700 (PDT) Received: by 10.182.34.232 with HTTP; Mon, 19 Aug 2013 12:03:06 -0700 (PDT) In-Reply-To: <20130819150521.GB21088@besserwisser.org> References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> Date: Mon, 19 Aug 2013 15:03:06 -0400 Message-ID: From: Dotzero To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 19 Aug 2013 19:03:08 -0000 The issue M=E5ns Nilsson raises was discussed extensively on the SPFbis list prior to as well as during last call on the list and I believe the appropriate decision was reached by the working group. If there is any doubt in the minds of the IESG regarding whether the working group reached the correct decision, I would urge those IESG members to review the threads in the archives related to this issue. Several related issues, including a race condition, were identified and the solution to go with TXT only records is IMHO the correct one under the circumstances. The relatively small uptake of Type 99 records in the wild (both on the publishing side AND on the validation side) in comparison to the implementation for TXT records made a compelling case for the decision of the working group. With regard to the limitations of the working group charter, some significant change was required to eliminate the race condition regardless of what that change would be. The decision of the working group (IMHO - I do not want to put words into anyones mouth) was to go with the approach which had the least impact on what is arguably a very large installed existing base on both the sender AND the validator sides of implementation. Based on this I would ask that tehe IESG move draft-ietf-spfbis-4408bis-19.txt to Proposed Standard. Michael Hammer On Mon, Aug 19, 2013 at 11:05 AM, M=E5ns Nilsson wrote: > Subject: [spfbis] Last Call: (Sender P= olicy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) t= o Proposed Standard Date: Mon, Aug 19, 2013 at 06:19:16AM -0700 Quoting The= IESG (iesg-secretary@ietf.org) >> >> The IESG has received a request from the SPF Update WG (spfbis) to >> consider the following document: >> - 'Sender Policy Framework (SPF) for Authorizing Use of Domains in Email= , >> Version 1' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, comments may b= e >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. > > I strongly OPPOSE draft-ietf-spfbis-4408bis-19.txt being published as > RFC unless substantial parts are reworked. > > * The charter disallows major protocol changes -- removing the SPF RR typ= e > is a direct charter violation; since SPF is being used on the Internet. > > * The overloading of the TXT record is a hack at best, aimed at > circumventing DNS management systems vendors that fail to ship > support. Breaking the DNS model with specific resource records is not > the way to get better application support. (besides, the major argument > at the time was "it's so hard and takes ages to get a RR type", which > isn't true anymore and also, the RRtype is allocated, what's the fuss? ) > > * The empirical data that was gathered and the conclusions from which > that where published as RFC 6686 are IMNSHO flawed and rushed in that the= y > set far too optimistic deadlines for adaptation before declaring failure. > > The IESG should send draft-ietf-spfbis-4408bis-19 back to spfbis wg and t= ell > the wg that instead of deprecating SPF it should be algorithmically > preferred while maintaining support for TXT. > > Thanks, > -- > M=E5ns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > It was a JOKE!! Get it?? I was receiving messages from DAVID LETTERMAN!= ! > YOW!! > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAlISNDEACgkQ02/pMZDM1cXK+gCfYQ1Mv1CHjy9DDn7sA7DC7dF3 > b48An1b49Zqf/du3dvN6pmj6in+CEujB > =3DsoFG > -----END PGP SIGNATURE----- > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From ajs@anvilwalrusden.com Mon Aug 19 13:08:04 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 B8BFA11E82BA; Mon, 19 Aug 2013 13:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[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 5jEGDFnwNCss; Mon, 19 Aug 2013 13:07:59 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id F02CC11E82CB; Mon, 19 Aug 2013 13:07:58 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3506D8A031; Mon, 19 Aug 2013 20:07:58 +0000 (UTC) Date: Mon, 19 Aug 2013 16:08:02 -0400 From: Andrew Sullivan To: spfbis@ietf.org, ietf@ietf.org Message-ID: <20130819200802.GI19481@mx1.yitter.info> References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130819150521.GB21088@besserwisser.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 19 Aug 2013 20:08:04 -0000 Note that I am not the shepherd for this draft, but I am the WG co-chair. On Mon, Aug 19, 2013 at 05:05:21PM +0200, MÃ¥ns Nilsson wrote: > * The charter disallows major protocol changes -- removing the SPF RR type > is a direct charter violation; since SPF is being used on the Internet. That argument doesn't work, because the WG had to make a major protocol change in this area no matter what, since 4408 has an interoperability problem. If you wish to argue that the WG decided on the wrong protocol change, that line is open to you; but nobody can argue that the change is wrong because of our charter. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From presnick@qti.qualcomm.com Mon Aug 19 13:49:33 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 8C6FD11E82FC; Mon, 19 Aug 2013 13:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.282 X-Spam-Level: X-Spam-Status: No, score=-106.282 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 dJFNkHPwyHlO; Mon, 19 Aug 2013 13:49:27 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 20C0011E82EB; Mon, 19 Aug 2013 13:49:26 -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=1376945366; x=1408481366; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=HJwcwlVb/h+TZki1Udc4848GKWpUSIWBVyX+e//igyc=; b=f/AaDV/31RoDETFzTWGspi80j74tUFKwJ794XS7rrtgiO3rb0lMlH4E2 w7okEF/iS8ccl2m3hZUz+TuZO23cmO1ZxlXYAROpgaUFutCLSyEKVFLul RJguSImSvOIhpojsKwTbFBUyjdMCsdNO0lzT9YB++dLr5Ppqltf1ld6Lh A=; X-IronPort-AV: E=McAfee;i="5400,1158,7172"; a="69459219" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 19 Aug 2013 13:49:25 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7172"; a="523607167" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2013 13:49:23 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.146.2; Mon, 19 Aug 2013 13:48:39 -0700 Message-ID: <521284A4.4050901@qti.qualcomm.com> Date: Mon, 19 Aug 2013 15:48:36 -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: Andrew Sullivan , =?ISO-8859-1?Q?M=E5ns_Nil?= =?ISO-8859-1?Q?sson?= References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> In-Reply-To: <20130819200802.GI19481@mx1.yitter.info> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org, ietf@ietf.org Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 19 Aug 2013 20:49:34 -0000 Speaking in my capacity as responsible AD for this WG and document, and the one who is going to have to judge the consensus of this Last Call and report to the IESG. On 8/19/13 3:08 PM, Andrew Sullivan wrote: > Note that I am not the shepherd for this draft, but I am the WG > co-chair. > > On Mon, Aug 19, 2013 at 05:05:21PM +0200, Måns Nilsson wrote: > > >> * The charter disallows major protocol changes -- removing the SPF RR type >> is a direct charter violation; since SPF is being used on the Internet. >> > That argument doesn't work, because the WG had to make a major > protocol change in this area no matter what, since 4408 has an > interoperability problem. If you wish to argue that the WG decided on > the wrong protocol change, that line is open to you; but nobody can > argue that the change is wrong because of our charter. > To reinforce this point: Nowhere does the charter "disallow major protocol changes"; words to that effect do not appear in the charter. It does say that features in current use cannot be removed, but it also says that errors can be corrected. In this case the WG concluded that fixing the interoperability problem fell under the auspices of "correction of errors". The chairs agreed, and I saw no reason to disagree. >> * The overloading of the TXT record is a hack at best, aimed at >> circumventing DNS management systems vendors that fail to ship >> support. Breaking the DNS model with specific resource records is not >> the way to get better application support. (besides, the major argument >> at the time was "it's so hard and takes ages to get a RR type", which >> isn't true anymore and also, the RRtype is allocated, what's the fuss? ) >> This issue *was* considered and extensively discussed on the spfbis list. AFAICT, the conclusion the WG came to was *not* based on the argument that "it's so hard and takes ages to get an RR type". (Yes, the original decision to use TXT included that argument, but that was not the basis for the decision in the current WG.) And I don't know that anyone in the WG would disagree that "the use of the TXT record is a hack". The conclusion was that it was a hack that we are stuck with due to the current deployment profile. I think you will have to find something that the WG missed in that discussion to be convincing that a substantial change is needed. There is no doubt the consensus in the WG was rough on the above two issues, but it was, by my reading, solid. >> * The empirical data that was gathered and the conclusions from which >> that where published as RFC 6686 are IMNSHO flawed and rushed in that they >> set far too optimistic deadlines for adaptation before declaring failure. I think you're going to need substantially more explanation (and perhaps some data) to make a convincing case that RFC 6686 needs to be reconsidered, thereby affecting this last call. The above states a conclusion, but provides no data or explanation. I don't know how to evaluation this. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From presnick@qti.qualcomm.com Mon Aug 19 13:55:27 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 50E9F21F9EA9; Mon, 19 Aug 2013 13:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.284 X-Spam-Level: X-Spam-Status: No, score=-106.284 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 phQk19rjmBnX; Mon, 19 Aug 2013 13:55:22 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3B18B11E8300; Mon, 19 Aug 2013 13:55:22 -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=1376945722; x=1408481722; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=u97Vd1UZXIXyxbQ1crEZpKNZgAChr6bluYXkIQ8WKOw=; b=XN8zQgcLvXa0V54xZNY17hDyMGkY8txoq/ritAbMIH+KJBCy9T1NQXBH 2pBCPpv9JX9cSW6vCOt6GQ7/HTSFMA561/aY0CvlmP65xJ99YeorSVJkk t48KY7ZO63TueRqWWvlRDhFaeegi1OzzWRg/zk+dOTATmBQQ86Pnkx+sx E=; X-IronPort-AV: E=McAfee;i="5400,1158,7172"; a="69460139" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 19 Aug 2013 13:55:13 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7172"; a="587109484" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2013 13:55:13 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.146.2; Mon, 19 Aug 2013 13:55:13 -0700 Message-ID: <5212862F.3080507@qti.qualcomm.com> Date: Mon, 19 Aug 2013 15:55:11 -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: Andrew Sullivan , =?ISO-8859-1?Q?M=E5ns_Nil?= =?ISO-8859-1?Q?sson?= References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> In-Reply-To: <521284A4.4050901@qti.qualcomm.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org, ietf@ietf.org Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 19 Aug 2013 20:55:27 -0000 My apologies: A typo rendering a sentence incoherent that I missed before hitting "Send": On 8/19/13 3:48 PM, Pete Resnick wrote: >>> * The empirical data that was gathered and the conclusions from which >>> that where published as RFC 6686 are IMNSHO flawed and rushed in >>> that they >>> set far too optimistic deadlines for adaptation before declaring >>> failure. > > I think you're going to need substantially more explanation (and > perhaps some data) to make a convincing case that RFC 6686 needs to be > reconsidered, thereby affecting this last call. The above states a > conclusion, but provides no data or explanation. I don't know how to > evaluation this. Of course, I meant, "I don't know how to *evaluate* this." pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From dhc@dcrocker.net Mon Aug 19 14:00: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 4C7CA21F8540; Mon, 19 Aug 2013 14:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adv326cZSmpB; Mon, 19 Aug 2013 14:00:32 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 474E421F89D8; Mon, 19 Aug 2013 14:00:10 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7JL022Z008905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Aug 2013 14:00:05 -0700 Message-ID: <5212873B.1010007@dcrocker.net> Date: Mon, 19 Aug 2013 13:59:39 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Pete Resnick References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> <5212862F.3080507@qti.qualcomm.com> In-Reply-To: <5212862F.3080507@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 19 Aug 2013 14:00:06 -0700 (PDT) Cc: spfbis@ietf.org, =?ISO-8859-1?Q?M=E5ns_Nil?= =?ISO-8859-1?Q?sson?= , ietf@ietf.org, Andrew Sullivan Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 21:00:37 -0000 > On 8/19/13 3:48 PM, Pete Resnick wrote: >>>> * The empirical data that was gathered and the conclusions from which >>>> that where published as RFC 6686 are IMNSHO flawed and rushed in >>>> that they >>>> set far too optimistic deadlines for adaptation before declaring >>>> failure. >> >> I think you're going to need substantially more explanation (and >> perhaps some data) to make a convincing case that RFC 6686 needs to be >> reconsidered, thereby affecting this last call. The above states a >> conclusion, but provides no data or explanation. I don't know how to >> evaluation this. > > Of course, I meant, "I don't know how to *evaluate* this." From earlier exchanges about this concern, the assertion that I recall is that 7 years is not long enough, to determine whether a feature will be adopted. That is, failure to gain deployment traction after 7 years from the time of publication should not be taken as a sufficient waiting period. I do not recall anyone (else) showing support for that view, but certainly not any substantial constituency. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Mon Aug 19 14:04: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 CBE2A21F9C99; Mon, 19 Aug 2013 14:04:12 -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, 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 b3devI204NW3; Mon, 19 Aug 2013 14:04:12 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A485421F8481; Mon, 19 Aug 2013 14:04:11 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w62so1515635wes.15 for ; Mon, 19 Aug 2013 14:04: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=+4ddx6O5F/ju5AQE0dKT5GrqEnwvOPbrMPngd2i3A+I=; b=B9iNjoHBUajP/yfJWYC83iXEPgYPttkHvlZqlhDyu9pLcLIvhlsH40kDhNaTSLI9aT yALlUQMCxG3XTDyrErP2LbHbFOWCpqKzmXAAXXv8zfolLM7Ply1We20QkWXauxrOCHdA sdGVuMqysRtbzftTxFF6aP8jUscgzdZSCGyDsAoZ3NQuFrH/UOZ4NJcuCZVYEI2aoWNT EvBD/h2qe2DTTldyF309+iSQICdkZIieSBqQctzJbNvostBzMMMlH/IlVq8gKSdBqhyG YwbLmTtnwck4U/xTL0nv+EqiSesD6VexIz0UOA8shiBBmDgqqTkO3l8rDghfSxbEdWm4 SUqg== MIME-Version: 1.0 X-Received: by 10.180.183.51 with SMTP id ej19mr9886856wic.60.1376946250594; Mon, 19 Aug 2013 14:04:10 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Mon, 19 Aug 2013 14:04:10 -0700 (PDT) In-Reply-To: <5212873B.1010007@dcrocker.net> References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> <5212862F.3080507@qti.qualcomm.com> <5212873B.1010007@dcrocker.net> Date: Mon, 19 Aug 2013 14:04:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11c2409e243f5704e4534896 Cc: "spfbis@ietf.org" , Pete Resnick , =?ISO-8859-1?Q?M=E5ns_Nilsson?= , ietf Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 19 Aug 2013 21:04:13 -0000 --001a11c2409e243f5704e4534896 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 19, 2013 at 1:59 PM, Dave Crocker wrote: > On 8/19/13 3:48 PM, Pete Resnick wrote: > >> * The empirical data that was gathered and the conclusions from which >>>>> that where published as RFC 6686 are IMNSHO flawed and rushed in >>>>> that they >>>>> set far too optimistic deadlines for adaptation before declaring >>>>> failure. >>>>> >>>> >>> I think you're going to need substantially more explanation (and >>> perhaps some data) to make a convincing case that RFC 6686 needs to be >>> reconsidered, thereby affecting this last call. The above states a >>> conclusion, but provides no data or explanation. I don't know how to >>> evaluation this. >>> >> >> Of course, I meant, "I don't know how to *evaluate* this." >> > > > From earlier exchanges about this concern, the assertion that I recall is > that 7 years is not long enough, to determine whether a feature will be > adopted. That is, failure to gain deployment traction after 7 years from > the time of publication should not be taken as a sufficient waiting period. > > I do not recall anyone (else) showing support for that view, but certainly > not any substantial constituency. > > Moreover: What is the premise for seven years being "not long enough"? And what does constitute "long enough"? And upon what is that last answer based? It would be wonderful if the boundaries for this test were written down somewhere, so that we would've had that information when we did the research for RFC6686. -MSK --001a11c2409e243f5704e4534896 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 19, 2013 at 1:59 PM, Dave Crocker <dhc@dcrocke= r.net> wrote:
On 8/19/13 3:48 PM, Pete R= esnick wrote:
* The empirical data that was gathered and the conclusions from which
that where published as RFC 6686 are IMNSHO flawed and rushed in
that they
set far too optimistic deadlines for adaptation before declaring
failure.

I think you're going to need substantially more explanation (and
perhaps some data) to make a convincing case that RFC 6686 needs to be
reconsidered, thereby affecting this last call. The above states a
conclusion, but provides no data or explanation. I don't know how to evaluation this.

Of course, I meant, "I don't know how to *evaluate* this."


>From earlier exchanges about this concern, the assertion that I recall is t= hat 7 years is not long enough, to determine whether a feature will be adop= ted. =A0That is, failure to gain deployment traction after 7 years from the= time of publication should not be taken as a sufficient waiting period.
I do not recall anyone (else) showing support for that view, but certainly = not any substantial constituency.


Moreover:

<= div>What is the premise for seven years being "not long enough"?= =A0 And what does constitute "long enough"?=A0 And upon what is t= hat last answer based?

It would be wonderful if the boundaries for this test were w= ritten down somewhere, so that we would've had that information when we= did the research for RFC6686.

-MSK

--001a11c2409e243f5704e4534896-- From dhc@dcrocker.net Mon Aug 19 14:06:43 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 9CCFB11E8128; Mon, 19 Aug 2013 14:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFUCPQ24DTXN; Mon, 19 Aug 2013 14:06:38 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 992B111E82EA; Mon, 19 Aug 2013 14:06:38 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7JL6UEv009011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Aug 2013 14:06:33 -0700 Message-ID: <521288BF.20005@dcrocker.net> Date: Mon, 19 Aug 2013 14:06:07 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> <5212862F.3080507@qti.qualcomm.com> <5212873B.1010007@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 19 Aug 2013 14:06:34 -0700 (PDT) Cc: "spfbis@ietf.org" , Pete Resnick , =?ISO-8859-1?Q?M=E5ns_Nilsson?= , Dave Crocker , ietf Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 21:06:43 -0000 On 8/19/2013 2:04 PM, Murray S. Kucherawy wrote: > Moreover: > > What is the premise for seven years being "not long enough"? And what > does constitute "long enough"? And upon what is that last answer based? > > It would be wonderful if the boundaries for this test were written down > somewhere, so that we would've had that information when we did the > research for RFC6686. Well, they were written down 15 years ago, but they haven't gained traction yet, though I remain hopeful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Mon Aug 19 14:14: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 4ED3411E8129 for ; Mon, 19 Aug 2013 14:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.547 X-Spam-Level: X-Spam-Status: No, score=-101.547 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, SARE_LWSHORTT=1.24, 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 ekDxi0q81kim for ; Mon, 19 Aug 2013 14:14:30 -0700 (PDT) Received: from mail.catinthebox.net (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0B20421F93BF for ; Mon, 19 Aug 2013 14:14:29 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5970; t=1376946857; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=Xww1xRK K0v2Eu/uK8tzvdAqO67I=; b=LTL6wAGM8dDlmo1UUk0aAWTc0BlcU7kFNg5/3mY Vy+/StArMaoPnqexH6Ov8KjE2fjuKiIW9EWLOILjzYIoaOlznNfkQfqM+n6YGG0W Dnc6jkGz1On65+5qhEHb5IK8L+noMPizlQJKuEav0e/HvxLWpyeWN8YWRtSPcvjh XIWU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 19 Aug 2013 17:14:17 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3409374411.13144.5448; Mon, 19 Aug 2013 17:14:16 -0400 Message-ID: <521289C3.9070500@isdg.net> Date: Mon, 19 Aug 2013 17:10:27 -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: Pete Resnick References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> In-Reply-To: <521284A4.4050901@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org, =?ISO-8859-1?Q?M=E5ns_Nil?= =?ISO-8859-1?Q?sson?= , ietf@ietf.org, Andrew Sullivan Subject: [spfbis] SPF TYPE support 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, 19 Aug 2013 21:14:35 -0000 Hi, I'm having a hard time with both sides of the argument, especially the supposed existence of an "interop problem" which seems to only highlight how to "procedurally" stump the SPF type advocates with a "error correction" standpoint. What is that error by the way? I don't believe there was an adequate answer from the advocates of removing the SPF RR type and the repeated assertion that its been discussed at length has not been convincing it was appropriately addressed. It all seem to be a "Shut up" approach to the problem (always suggest that its been discussed already). This seems to be one of the reasons why the issue will not go away. My take is that the initial MARID design expectations were being met. This fact is a very important design consideration in all this; the original expectation for a TXT/SPF migration, although very slowly, there were some deployments administratively (publishers) and technically (processors). I would like to point out the lack of a majority does not/should not represent a lack of interest. In my estimation, the WG did receive positive support expressing sincere technical interest in adding support for the SPF record type primarily because there was some level of adoption discovered during the "interop" report work. Please include us (SSI) as having interest in enabling/adding SPF record support. I recommend the following to be considered to basically allow implementators to decide: 1) Continue with the TXT/SPF migration plan, fix up this plan, 2) Address any technical protocol issue with using an SPF type, 3) Add implementation designs notes on the pros and cons. This will allow coders to add the optimized logic for usage. It will also allow for new problem solving seeds to be laid down. It will hopefully get the DNS software vendors to finally add direct support for unnamed TYPE support (query and passthru) not only for SPF but for future DNS application protocols. Finally, which is what I have been trying to get - why hasn't the IETF taking this issue (unnamed type support) very serious? This is an integration DNS issue - not just an SPF issue. If the DNS vendors don't address this, this, to me, would be the only logical and feasible reason to remove the SPF type or even bother with any new RR type concept. The interop problem cited to exist within RFC 4408 is not convincing to me. Overall, as an early adopter, the only reason my package doesn't have SPF support was purely for short term optimizations and lack of servers with unnamed type processing support - no mas. If we remove SPF support, then we lost it forever. I don't think we have viewed a possible long term solution from an integrated protocol standpoint. -- HLS On 8/19/2013 4:48 PM, Pete Resnick wrote: > Speaking in my capacity as responsible AD for this WG and document, and > the one who is going to have to judge the consensus of this Last Call > and report to the IESG. > > On 8/19/13 3:08 PM, Andrew Sullivan wrote: > >> Note that I am not the shepherd for this draft, but I am the WG >> co-chair. >> >> On Mon, Aug 19, 2013 at 05:05:21PM +0200, Måns Nilsson wrote: >> >>> * The charter disallows major protocol changes -- removing the SPF RR >>> type >>> is a direct charter violation; since SPF is being used on the Internet. >> That argument doesn't work, because the WG had to make a major >> protocol change in this area no matter what, since 4408 has an >> interoperability problem. If you wish to argue that the WG decided on >> the wrong protocol change, that line is open to you; but nobody can >> argue that the change is wrong because of our charter. > > To reinforce this point: Nowhere does the charter "disallow major > protocol changes"; words to that effect do not appear in the charter. It > does say that features in current use cannot be removed, but it also > says that errors can be corrected. In this case the WG concluded that > fixing the interoperability problem fell under the auspices of > "correction of errors". The chairs agreed, and I saw no reason to disagree. > >>> * The overloading of the TXT record is a hack at best, aimed at >>> circumventing DNS management systems vendors that fail to ship >>> support. Breaking the DNS model with specific resource records is not >>> the way to get better application support. (besides, the major argument >>> at the time was "it's so hard and takes ages to get a RR type", which >>> isn't true anymore and also, the RRtype is allocated, what's the fuss? ) > > This issue *was* considered and extensively discussed on the spfbis > list. AFAICT, the conclusion the WG came to was *not* based on the > argument that "it's so hard and takes ages to get an RR type". (Yes, the > original decision to use TXT included that argument, but that was not > the basis for the decision in the current WG.) And I don't know that > anyone in the WG would disagree that "the use of the TXT record is a > hack". The conclusion was that it was a hack that we are stuck with due > to the current deployment profile. I think you will have to find > something that the WG missed in that discussion to be convincing that a > substantial change is needed. > > There is no doubt the consensus in the WG was rough on the above two > issues, but it was, by my reading, solid. > >>> * The empirical data that was gathered and the conclusions from which >>> that where published as RFC 6686 are IMNSHO flawed and rushed in that >>> they >>> set far too optimistic deadlines for adaptation before declaring >>> failure. > > I think you're going to need substantially more explanation (and perhaps > some data) to make a convincing case that RFC 6686 needs to be > reconsidered, thereby affecting this last call. The above states a > conclusion, but provides no data or explanation. I don't know how to > evaluation this. > > pr > From presnick@qti.qualcomm.com Mon Aug 19 14:48:06 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 5FB1011E8304; Mon, 19 Aug 2013 14:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 UAvm8zBpo+Ov; Mon, 19 Aug 2013 14:48:02 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 59B3A11E8301; Mon, 19 Aug 2013 14:47:59 -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=1376948879; x=1408484879; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gswrRaznl74WiE6jFjdOp3cow2nHmdFpODk6oU1yAoA=; b=FNvzJxSiThTBzNA/8EEflkKBizB+GBATQBO0gT1rZWHQXnbv3mUp+k1H DuaYPPjePywpiqFSJb3DQ3H+5+6hKz9ns84q+UTj3zyFAeOm1GzcrIk03 K2QDT+umQjQqj0hhvx1/YA1TSKwygYkdV1tA/HrZFBFxu0m3HTOvxeY2C 8=; X-IronPort-AV: E=McAfee;i="5400,1158,7172"; a="49906240" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 19 Aug 2013 14:47:57 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7172"; a="18249364" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2013 14:47:57 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.146.2; Mon, 19 Aug 2013 14:47:57 -0700 Message-ID: <5212928B.3010502@qti.qualcomm.com> Date: Mon, 19 Aug 2013 16:47:55 -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: Hector Santos References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> <521289C3.9070500@isdg.net> In-Reply-To: <521289C3.9070500@isdg.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org, =?ISO-8859-1?Q?M=E5ns_Nilsson?= , ietf@ietf.org Subject: Re: [spfbis] SPF TYPE support 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, 19 Aug 2013 21:48:06 -0000 I will let the document shepherd/editor address particular points in this and other messages, but on one procedural point: On 8/19/13 4:10 PM, Hector Santos wrote: > I don't believe there was an adequate answer from the advocates of > removing the SPF RR type... That's an appropriate issue to raise during Last Call, and I expect the shepherd to elaborate on why the WG came to its conclusion, and you to follow up with more explanation if you still think it is inadequate. However: > ...and the repeated assertion that its been discussed at length has > not been convincing it was appropriately addressed. It all seem to be > a "Shut up" approach to the problem (always suggest that its been > discussed already). This seems to be one of the reasons why the issue > will not go away. The above is *not* appropriate to raise. The first part is attributing motives to folks, which is out of line. Even if the motives of folks asserting these things *were* malicious, I am expected to call the consensus on the basis of the technical arguments and to ignore the motives, and that is what I plan to do. And the last sentence above is trying to divine the psychological state of the IETF as to why or why not it continues to discuss an issue, an equally inappropriate and unproductive thing to do during Last Call. Let's stick to issues and not delve into these areas please. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From sm@elandsys.com Mon Aug 19 16:48:54 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 AC6BE11E81A2; Mon, 19 Aug 2013 16:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 e12fMdPBfJqb; Mon, 19 Aug 2013 16:48:54 -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 070C811E81CA; Mon, 19 Aug 2013 16:48:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.26]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7JNmSFU000073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 16:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376956127; bh=Xpbdv8WaJBbH6yb3/jO9GLiat9Ff/VGjQOZm3Ah6qjk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HRt8HnEEl672W/fUpI0Lv2/p6K/CIVLBYddgup5QnUwXuIesEiWsTvfdnO+clWL/C +vqvAg6lagV27wBN0AaARZJirleAMXxaxhgElwqXpij75xNYjbsqjutErloW1xOeq1 d/9hlpL+vSJGpnJpVJYHN1vqSYAo+vgyGUMJlIJQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1376956127; i=@elandsys.com; bh=Xpbdv8WaJBbH6yb3/jO9GLiat9Ff/VGjQOZm3Ah6qjk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Ai1ZgEZvR3DKAkdH+AgZEEM+82/LC8qTxUM6bJ6cmkb/4yt1pzzhfDTVLen708KIW /YxiOgPthn4JFQ6e0IVb3Cifz8Ug0RcWP5tba0cygTNTvLveLI68JmWeyvlioU5ml2 MsLnMOIhJ4vyeKN+1M88MK4SwguyEt9P9DpBVMx8= Message-Id: <6.2.5.6.2.20130819151912.0b861e98@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 19 Aug 2013 16:42:42 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <521289C3.9070500@isdg.net> References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> <521289C3.9070500@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Pete Resnick , =?iso-8859-1?Q?M=E5ns?= Nilsson , ietf@ietf.org Subject: Re: [spfbis] SPF TYPE support 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, 19 Aug 2013 23:48:54 -0000 Hi Hector, At 14:10 19-08-2013, Hector Santos wrote: >I'm having a hard time with both sides of the argument, especially >the supposed existence of an "interop problem" which seems to only >highlight how to "procedurally" stump the SPF type advocates with a >"error correction" standpoint. What is that error by the way? In a message dated February 27, 2012, the SPFBIS Chairs commented that the discussion about Issue #9 (SPF RRTYPE) has revealed an interoperability concern in the existing RFC (4408). From RFC 6686: "RFC 4408 itself included a faulty transition plan, likely because of the late addition of a requirement to develop one -- it said: An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at least one type. which means both can claim to be fully compliant while failing utterly to interoperate." The consensus of the SPFBIS WG was that this is an interoperability issue and it would have to be corrected. That is what was considered as an error correction. >I don't believe there was an adequate answer from the advocates of >removing the SPF RR type and the repeated assertion that its been >discussed at length has not been convincing it was appropriately >addressed. It all seem to be a "Shut up" approach to the problem >(always suggest that its been discussed already). This seems to be >one of the reasons why the issue will not go away. I personally do not think that it is appropriate to ask any working group participant to "shut up". I welcome hearing arguments and I expect a working group to carefully consider them. Regards, S. Moonesamy (as document shepherd) From Ted.Lemon@nominum.com Mon Aug 19 17:16: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 9272A11E8306; Mon, 19 Aug 2013 17:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 auiyXffX+CXY; Mon, 19 Aug 2013 17:16:04 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id AA0D211E8186; Mon, 19 Aug 2013 17:16:02 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUhK1QrfikoBIor7fjl2JxChARSKJZjrT@postini.com; Mon, 19 Aug 2013 17:16:02 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2DD891B827D; Mon, 19 Aug 2013 17:16:02 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1200A19006C; Mon, 19 Aug 2013 17:16:02 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 19 Aug 2013 17:16:02 -0700 From: Ted Lemon To: Hector Santos Thread-Topic: [spfbis] SPF TYPE support Thread-Index: AQHOnSEdAUqJkK3Ia0WBBOtw9V8i3Jmdr/wA Date: Tue, 20 Aug 2013 00:16:01 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077525C6EC@mbx-01.win.nominum.com> References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> <521289C3.9070500@isdg.net> In-Reply-To: <521289C3.9070500@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1902D2A849168A468FAF5616FEF2AF84@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Pete Resnick , =?iso-8859-1?Q?M=E5ns_Nilsson?= , "" , Andrew Sullivan Subject: Re: [spfbis] SPF TYPE support 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, 20 Aug 2013 00:16:14 -0000 On Aug 19, 2013, at 5:10 PM, Hector Santos wrote: > This will allow coders to add the optimized logic for usage. It will als= o allow for new problem solving seeds to be laid down. It will hopefully ge= t the DNS software vendors to finally add direct support for unnamed TYPE s= upport (query and passthru) not only for SPF but for future DNS application= protocols. It would help if you would go review the working group discussion on this p= oint; if you had done so, I do not believe you could make this point with a= straight face, because it was soundly refuted by the working group. I tr= ied to make the same point to the working group, and they successfully argu= ed me around. Although I'm sure you're aware that I am quite stubborn, it= 's possible that they would not succeed in arguing you around as they did m= e. But you ought at least to do us the service of allowing them to try by = reviewing the discussion yourself. From mansaxel@besserwisser.org Mon Aug 19 20:01:55 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 82DE711E8188; Mon, 19 Aug 2013 20:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 qtuxRSlwdMwT; Mon, 19 Aug 2013 20:01:55 -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 E88B811E8199; Mon, 19 Aug 2013 20:01:54 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id DEC7B9E98; Tue, 20 Aug 2013 05:01:52 +0200 (CEST) Date: Tue, 20 Aug 2013 05:01:52 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: S Moonesamy Message-ID: <20130820030152.GC30516@besserwisser.org> References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> <521289C3.9070500@isdg.net> <6.2.5.6.2.20130819151912.0b861e98@resistor.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nmemrqcdn5VTmUEE" Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20130819151912.0b861e98@resistor.net> 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, Pete Resnick , Hector Santos , ietf@ietf.org Subject: Re: [spfbis] SPF TYPE support 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, 20 Aug 2013 03:01:55 -0000 --nmemrqcdn5VTmUEE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: SPF TYPE support Date: Mon, Aug 19, 2013 at 04:42:42PM -0700 Q= uoting S Moonesamy (sm+ietf@elandsys.com): =20 > I personally do not think that it is appropriate to ask any working > group participant to "shut up". I welcome hearing arguments and I > expect a working group to carefully consider them. The repeated assertions of "This has been discussed already" are in effect "shut up", but slightly more polite. I complied until last call. As was recommended by wg chairs. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Yes, but will I see the EASTER BUNNY in skintight leather at an IRON MAIDEN concert? --nmemrqcdn5VTmUEE 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) iEUEARECAAYFAlIS3CAACgkQ02/pMZDM1cV6kwCfbRy/S/AGPhXrSixfEM5fYmOZ kOEAliPBhSu/DZGtS5vrTOlTyshy6YM= =T9xe -----END PGP SIGNATURE----- --nmemrqcdn5VTmUEE-- From sm@elandsys.com Mon Aug 19 22:13:48 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 2E8E011E8101; Mon, 19 Aug 2013 22:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rx9kIs+M-Cqx; Mon, 19 Aug 2013 22:13:47 -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 528A111E80E9; Mon, 19 Aug 2013 22:13:47 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.26]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7K5DUMX029943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 22:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376975624; bh=8ayir6hEw2MQ7y66ZKEvseITCib7UNg3Lq+9r/bxuXo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IGGmNpYS+NapXOJj0l8ZIRNK25uvIGN0z3NVYFJgBPKgSOEE/3KcQTXfKdJgD5ep9 atwW71CxRDKZk/tJlpHR2lepi0gM4ARNo4usgU+9UrT7cemA5hrTBZIlkl71wwUozC PhFKplsInhM93E5DiGdMdLkUzMKZiFbyVOURxwUM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1376975624; i=@elandsys.com; bh=8ayir6hEw2MQ7y66ZKEvseITCib7UNg3Lq+9r/bxuXo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=R5KrY1yM5qWOpRSiaosAPXUFhTUaEDdRYQMismve9kdKVy1UykeTtE3dybLqbIbh4 n87V1AJwwZHz5h2aZQdKD+EhgZ3PsGqAj+LXpg2b3Y24SzxYGB9E4COeoVAjhFfOTp 7IRPUOLOv27771S/xOcJoQy0MjPLjLyVKLOQ5Bjo= Message-Id: <6.2.5.6.2.20130819202422.0d1756a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 19 Aug 2013 22:12:18 -0700 To: mansaxel@besserwisser.org, ietf@ietf.org From: S Moonesamy In-Reply-To: <20130819150521.GB21088@besserwisser.org> References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 20 Aug 2013 05:13:48 -0000 At 08:05 19-08-2013, M=C3ns Nilsson wrote: >I strongly OPPOSE draft-ietf-spfbis-4408bis-19.txt being published as >RFC unless substantial parts are reworked. > >* The charter disallows major protocol changes -- removing the SPF RR type >is a direct charter violation; since SPF is being used on the Internet. > >* The overloading of the TXT record is a hack at best, aimed at >circumventing DNS management systems vendors that fail to ship >support. Breaking the DNS model with specific resource records is not >the way to get better application support. (besides, the major argument >at the time was "it's so hard and takes ages to get a RR type", which >isn't true anymore and also, the RRtype is allocated, what's the fuss? ) > >* The empirical data that was gathered and the conclusions from which >that where published as RFC 6686 are IMNSHO flawed and rushed in that they >set far too optimistic deadlines for adaptation before declaring failure. > >The IESG should send draft-ietf-spfbis-4408bis-19 back to spfbis wg and= tell >the wg that instead of deprecating SPF it should be algorithmically >preferred while maintaining support for TXT. I read the SPFBIS charter (=20 https://datatracker.ietf.org/wg/spfbis/charter/ )=20 again. The charter violation the above may be referring might be about: "Specifically out-of-scope for this working group: * Removal of existing features that are in current use." There is a message from the Responsible Area=20 Director at=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html=20 which might shine some light about that part of the charter. Both RR Type 16 and RR Type 99 are in use on the=20 Internet. Tony Hansen mentioned during the IETF 83 session that: "when you write a protocol, there is definite harm if there is a choice in what you publish and what you look for. He is of the view that there is a definite bug in RFC 4408." Fixing that bug falls within the scope of the SPFBIS charter, specifically: "Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language. " The fourth paragraph (see quoted text) states=20 that the conclusions from that where RFC 6866=20 were flawed and rushed. The explanation given is=20 because the working group declared failure too=20 soon. The SPFBIS WG discovered a bug during the=20 review of the SPF specification. One of the main=20 considerations for the decision was to fix the=20 bug. The working group had to choose one RRTYPE=20 as the conclusion was that it was the appropriate=20 way to fix the bug and ensure interoperability. The comments posted up to now for the Last Call=20 points to a disagreement about the choice of RRTYPE. Regards, S. Moonesamy (as document shepherd) =20 From dhc@dcrocker.net Mon Aug 19 22:17:26 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 C079721F9B8D; Mon, 19 Aug 2013 22:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 AP7UA5tpOcA4; Mon, 19 Aug 2013 22:17:20 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C899421F842B; Mon, 19 Aug 2013 22:17:20 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7K5HECd016397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Aug 2013 22:17:18 -0700 Message-ID: <5212FBB8.60200@dcrocker.net> Date: Mon, 19 Aug 2013 22:16:40 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?UTF-8?B?TcOlbnMgTmlsc3Nvbg==?= References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> <521289C3.9070500@isdg.net> <6.2.5.6.2.20130819151912.0b861e98@resistor.net> <20130820030152.GC30516@besserwisser.org> In-Reply-To: <20130820030152.GC30516@besserwisser.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 19 Aug 2013 22:17:18 -0700 (PDT) Cc: spfbis@ietf.org, Pete Resnick , ietf@ietf.org Subject: Re: [spfbis] SPF TYPE support X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 05:17:27 -0000 On 8/19/2013 8:01 PM, MÃ¥ns Nilsson wrote: > The repeated assertions of "This has been discussed already" are in effect > "shut up", but slightly more polite. I complied until last call. As was > recommended by wg chairs. There is a fundamental difference between telling someone to shut up and asking the person to familiarize themselves with the group's history before speaking up. It's a question of who is being required to carry the primary burden for making their case. In the current circumstance, the burden is on the person lodging the concern, namely you, rather than on the group. The alternative is, effectively, a denial of service attack on the group's progress, by requiring that it be (potentially constantly) required to re-visit old and resolved topics. Since there is, in fact, an extensive -- possibly even complete -- public archive of discussions, placing the burden on the person lodging the concern is singularly reasonable. As others have attempted to point out, this reduces to requiring that someone raising a concern during the last call start with the group's context and, therefore, either point out what the group missed or explain how it assessed reality incorrectly or otherwise made a problematic engineering choice. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Tue Aug 20 06:34: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 3E71611E80C5 for ; Tue, 20 Aug 2013 06:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.042 X-Spam-Level: X-Spam-Status: No, score=-102.042 tagged_above=-999 required=5 tests=[AWL=0.557, 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 qukZ9xOMsvqi for ; Tue, 20 Aug 2013 06:34:07 -0700 (PDT) Received: from dkim.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 88B2611E80D9 for ; Tue, 20 Aug 2013 06:34:07 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6693; t=1377005645; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=WiPx4sB 0K5X2MSqtCoMDjVj5Pew=; b=d+09euuTbpt/5jR5NfQSpISlobthsw7eo6vEUWc cHQSe7zsIOkv4oBPvXxPESMFKM4AD8DfUNlAFLJunbymJU4Y1v104TlzhVlERVG6 SO2Ztl2tHxjvz0fh9K/HjWYdO5rsp3exYl0lQuzdMPcPGfw953tvmRczuej6UE64 cjs4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 20 Aug 2013 09:34:05 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3468161282.3.2612; Tue, 20 Aug 2013 09:34:03 -0400 Message-ID: <52136F65.6020703@isdg.net> Date: Tue, 20 Aug 2013 09:30:13 -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: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> <521289C3.9070500@isdg.net> <6.2.5.6.2.20130819151912.0b861e98@resistor.net> In-Reply-To: <6.2.5.6.2.20130819151912.0b861e98@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Pete Resnick , =?ISO-8859-1?Q?M=E5ns_Nilsson?= , ietf@ietf.org Subject: Re: [spfbis] SPF TYPE support 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, 20 Aug 2013 13:34:12 -0000 On 8/19/2013 7:42 PM, S Moonesamy wrote:> > At 14:10 19-08-2013, Hector Santos wrote: >> I'm having a hard time with both sides of the argument, especially >> the supposed existence of an "interop problem" which seems to only >> highlight how to "procedurally" stump the SPF type advocates with a >> "error correction" standpoint. What is that error by the way? > > In a message dated February 27, 2012, the SPFBIS Chairs commented > that the discussion about Issue #9 (SPF RRTYPE) has revealed an > interoperability concern in the existing RFC (4408). > > From RFC 6686: > > "RFC 4408 itself included a faulty transition plan, likely because of > the late addition of a requirement to develop one -- it said: > > An SPF-compliant domain name SHOULD have SPF records of both RR > types. A compliant domain name MUST have a record of at least > one type. > > which means both can claim to be fully compliant while failing > utterly to interoperate." > > The consensus of the SPFBIS WG was that this is an interoperability > issue and it would have to be corrected. That is what was considered as > an error correction. I have a few questions and points: May I ask why was the above was not an area for clarification as oppose as the presumed stated technical reason for removal? There was adequate information for the expected and original optimal migration plan but it could of been further codified and clarified. It would of been on par with BIS level of work. Issue #9 should not have been a reason for removal. I reported issue #25 [1] regarding the complexity of the recommended parallel processing approach. I believe most folks agreed the ideal and optimal migration approach was: Query SPF type first, Fallback to TXT secord. It was common sense, at least to me. Second, I was under the impression interop reports (RFC 6686) were not making any conclusions or recommendations? Is that a correct basic understanding of interop reports? They were observations, collection of available data and while it might be eventually used to rethink a protocol design, I don't think the above RFC 4408 statement is a serious "error" in the functional description to justify removal. There are other parts of 4408 which helped clarify the migration path. But overall, a correction (not removal) would of suffice. It would of been on par for BIS-like corrections and protocol updates. Third, I believe removal required a more deeper IETF discussion about the initial presumed engineering expectation that DNS servers (all top DNS servers, including and especially Microsoft DNS servers) would eventually directly support a new registered SPF type or at the very least support RFC 3597 (Handling of Unknown DNS Resource Record (RR) Type) [2]. If this is no longer the expectation, then it would make sense to remove the SPF type but also be aware that in general, this will also nix (not help) any future idea for successfully adopting new RR types. It would be added statement that TXT based applications are acceptable. I think the DNS community continues to have a problem with this. >> I don't believe there was an adequate answer from the advocates of >> removing the SPF RR type and the repeated assertion that its been >> discussed at length has not been convincing it was appropriately >> addressed. It all seem to be a "Shut up" approach to the problem >> (always suggest that its been discussed already). This seems to be one >> of the reasons why the issue will not go away. > > I personally do not think that it is appropriate to ask any working > group participant to "shut up". I welcome hearing arguments and I > expect a working group to carefully consider them. > > Regards, > S. Moonesamy (as document shepherd) SM, Pete, thank you for the opportunity to clarify my point. For the record, there was no intent to imply it occurred but quite frankly when it is repeatedly stated, this deeply divided issue has not be resolved at any point, it does have an intimidation factor. As Mr. Crocker stated, the burden is on the those who oppose the removal. But my question was always why was the decision made to remove in the first place done when in fact it was quite obvious it would not have industry wide endorsement. The burden should of been to justify removal. Now it has become difficult to effectively add it back. This is why I posed the question in two forums to get community input over the last few years. It was quite obvious to me that the DNS community would be against this removal. So in this vain, it was prematurely removed in the WG without early IETF/IESG/DNS concerns adequately dealt with. Unfortunately, we were advise to raise the issue again in LC, but by that point, all the IETF procedural moves were made making it it a very high burden to add something that should not been removed in the first place. The only reason our own early adoption package did not support the SPF type was because we could not; the Microsoft DNS server (NT 4.0 at the time) had not directly support the SPF type but more importantly it did not support RFC 3597. Unfortunately, not even MS DNS 5.0 which did add direct support for other new RR types (SRV, DNSSEC, AAAA, etc). In my engineering opinion, the implications of the SPF type removal are wide spread as it implies a no confidence in the future of DNS servers to support safe, transparent passthru, recursive queries of unnamed types. If such is the case with the IETF DNS community, then it makes engineering sense to remove the SPF type but also keep in mind new RR types are also unrealistic as well. All future DNS DOMAIN policy based applications will be TXT only based which may be the acceptable reality today. It wasn't yester-years (during MARID). The endorsement of DKIM as an IS specification is testament of this TXT based solution acceptability in the market place. To me, that would be the reason for removal. Otherwise, if we still have confidence in the future of RFC 3597 support in DNS servers across the board out of the box, then we should correct and clarify the SPF/TXT query method migration path in RFC 4408-bis. As stated a number of times in the SPF WG, I would support SPF type in our implementation once Microsoft DNS server supported at the very least unnamed RR type processing. It can't be provisional software, i.e. custom, that would not cut it. It needs to be out of the box for wide network query support. Thanks -- HLS [1] http://www.ietf.org/mail-archive/web/spfbis/current/msg00586.html [2] http://tools.ietf.org/html/rfc3597 From hsantos@isdg.net Tue Aug 20 07:20:32 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 7A46A11E8115 for ; Tue, 20 Aug 2013 07:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=0.334, 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 AdCCshIwWXhF for ; Tue, 20 Aug 2013 07:20:28 -0700 (PDT) Received: from dkim.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 773D411E8223 for ; Tue, 20 Aug 2013 07:20:27 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3869; t=1377008418; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=O9w8Mr3 HUNMnCv6ZtJDW8wkFRRM=; b=vUu339HSe+y6TSfu3WxCfoRpfMeCeNlojOEMRcu ++ZpCjTwfMIKDJWlUj5M1WxOppa7GC5GG0hEcgYB5aQY9NOdKf1d0KCjGf/V0lyC i//56GUf+7v3JKe6+oc8fi2jPFLsLAMFWpvsl8/xWpW1Nk/oZIqHgpw7sQvalP9L qqY0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 20 Aug 2013 10:20:18 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3470934637.3.4580; Tue, 20 Aug 2013 10:20:17 -0400 Message-ID: <52137A3B.6040200@isdg.net> Date: Tue, 20 Aug 2013 10:16:27 -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: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <6.2.5.6.2.20130819202422.0d1756a8@resistor.net> In-Reply-To: <6.2.5.6.2.20130819202422.0d1756a8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, mansaxel@besserwisser.org, ietf@ietf.org Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 20 Aug 2013 14:20:32 -0000 On 8/20/2013 1:12 AM, S Moonesamy wrote: > There is a message from the Responsible Area Director at > http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html which > might shine some light about that part of the charter. > > Both RR Type 16 and RR Type 99 are in use on the Internet. Tony Hansen > mentioned during the IETF 83 session that: > > "when you write a protocol, there is definite harm if there is a > choice in what you publish and what you look for. He is of > the view that there is a definite bug in RFC 4408." > > Fixing that bug falls within the scope of the SPFBIS charter, specifically: > > "Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any enhancements > that have already gained widespread support, and addition of > clarifying language. " This doesn't seem to be correct. My apology if I don't follow or see the logic. The only real issue as it was since day zero in MARID was the infrastructure support for recursive passthru queries which is what RFC 3597 (Handling of Unknown DNS Resource Record (RR) Type). Without this, which allows for servers to delay/plan direct new RR type support yet still not error out on an unnamed type, there COULD NOT be any reasonable expectation to even only suggest a dual query migration approach, either in serial or parallel. It is very important to consider the mindset when it was first considered and written for RFC 4408 because to me, that is the mindset that has changed. If we don't think the infrastructure, the DNS vendors primarily, will support RFC 3497, then it seems proper to me to finally forget the idea. But if we still think its desirable and possible, then I would prefer to keep the protocol feature/option, corrected of course, and allow implementers the design choice to support it. The way I see it, if more implementations did begin to add support of a clarified BIS specification, that doesn't mean they may enabled it (default ON) out of the box. I would want to initially offer the lowest overheard operational setup out of the box. It will still be a long term migration path, shorter if we can encourage the major DNS vendors to add at least RFC 3597 support. Without, no new RR type will work across the board. > The fourth paragraph (see quoted text) states that the conclusions from > that where RFC 6866 were flawed and rushed. The explanation given is > because the working group declared failure too soon. The SPFBIS WG > discovered a bug during the review of the SPF specification. One of the > main considerations for the decision was to fix the bug. The working > group had to choose one RRTYPE as the conclusion was that it was the > appropriate way to fix the bug and ensure interoperability. > > The comments posted up to now for the Last Call points to a disagreement > about the choice of RRTYPE. I hope I am reading this incorrectly. It may be too procedural oriented to me at this point. I would like to see a simple just distinctive consensus on what the entire IETF/DNS community believes is the future of DNS servers offering unnamed RR type processing because that is the main barrier for any kind success. We knew this as far back as MARID. I don't quite understand why this key point seems to be left out, instead MARID was deemed off topic. That was an error because if there is no future in unnamed RR type support, then it really doesn't matter and the problem is solved. TXT only will be the only fast entry point for new DNS DOMAIN policy applications. If the community still believes it possible, then clarifying and codifying the SPF/TYPE lookup procedure seems to me to be the only real correction to make here. Thanks -- HLS [1] http://tools.ietf.org/html/rfc3597 From ajs@anvilwalrusden.com Tue Aug 20 07:26:56 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 DDD2C21F99CD for ; Tue, 20 Aug 2013 07:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[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 GREega5L+36s for ; Tue, 20 Aug 2013 07:26:46 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 14E8021F9962 for ; Tue, 20 Aug 2013 07:26:44 -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 47AE78A031 for ; Tue, 20 Aug 2013 14:26:38 +0000 (UTC) Date: Tue, 20 Aug 2013 10:26:37 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130820142636.GC20618@mx1.yitter.info> References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> <521289C3.9070500@isdg.net> <6.2.5.6.2.20130819151912.0b861e98@resistor.net> <52136F65.6020703@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52136F65.6020703@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] SPF TYPE support 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, 20 Aug 2013 14:26:56 -0000 This seems like business for the spfbis list, not the ietf list, so that's where I'm replying. I am writing my impressions as one co-chair who had to make a consensus determination, but I have not consulted with SM on these remarks so they should be considered mine alone. On Tue, Aug 20, 2013 at 09:30:13AM -0400, Hector Santos wrote: > the complexity of the recommended parallel processing approach. I > believe most folks agreed the ideal and optimal migration approach > was: > > Query SPF type first, > Fallback to TXT secord. > > It was common sense, at least to me. The argument at the time -- and this is prominent in the archives, I note -- was that the additional query for RRTYPE 99 was a waste, given that nobody seemed to be using it. Moreover, the above strategy incorporates additional complexity for all SPF software. Given that some change to the protocol was required anyway, and given that the TXT record couldn't seriously be deprecated when the overwhelming majority of actual deployment used it, the WG concluded that the additional complexity and additional load on the network for no apparent benefit might as well be removed. I am aware that you didn't agree with that conclusion (and, frankly, if I had my druthers, we'd have come to a different conclusion; but I was persuaded by the evidence). I nevertheless came to the conclusion that this was rough consensus, as did some others who seemed to have a clue about the DNS. > Third, I believe removal required a more deeper IETF discussion > about the initial presumed engineering expectation that DNS servers > (all top DNS servers, including and especially Microsoft DNS > servers) would eventually directly support a new registered SPF type > or at the very least support RFC 3597 (Handling of Unknown DNS > Resource Record (RR) Type) [2]. There was, as near as I can tell, never any argument that most or even an important minority of DNS servers were incapable of supporting RRTYPE 99. The argument was, instead, that many provisioning tools don't have such support, and are unlikely to get it any time soon. That position seemed to me to be pretty strong, so I'd be interested if you have counterarguments. > It would be added statement that TXT based applications are > acceptable. I do not think that this draft sets any kind of precedent, because as a general strategy the IETF has clearly settled on scoped TXT records using underscore labels. There are in fact problems with them, but they're nothing compared to the way SPF treads on the namespace. So I'm not sure why this seems to be an issue. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Tue Aug 20 10:32: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 26AD721F898A; Tue, 20 Aug 2013 10:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 1ixsfsm85tAV; Tue, 20 Aug 2013 10:32:21 -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 D3E8F11E80E4; Tue, 20 Aug 2013 10:32:19 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.26]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7KHVw1U028951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 10:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377019935; bh=dxpdIwRik6URiwtaZvpZf517giZhDxMaF7N1utnK5uM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2gmaLJHoMVI3QHgYXvviZ2flzfH6nG3fOeXA0GJuQrC1l3rBA2gPyKTP0zqsnJIUN vB69+yUv5bNf42QV2LT5FYGs+qTg7uNdldU2hHdbVjRHMqDaI2azcVG3BVYbLb+qEE vskSX7FUpl2KTxDf+VwSw9Sdqx7QeLm8OSmmblhY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377019935; i=@elandsys.com; bh=dxpdIwRik6URiwtaZvpZf517giZhDxMaF7N1utnK5uM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=s57CIEuQY8t24I//DDOQr/z495YWkZh/ZVItTQrxsdkkV6ptbBbjomi6mbWmFtHnh inyE3KZh1CTjA3yaUziYe+wVD0RlrdqA+EhdDb+6Lr0yOiKUjocxU6aSvo1+nQIIDl gnMJ1mD9nbrv6crQ7RqfaUxQh02FX10YrwY4pOng= Message-Id: <6.2.5.6.2.20130820074828.0df2aac8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 20 Aug 2013 10:02:57 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <52136F65.6020703@isdg.net> References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> <521289C3.9070500@isdg.net> <6.2.5.6.2.20130819151912.0b861e98@resistor.net> <52136F65.6020703@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, =?iso-8859-1?Q?M=E5ns?= Nilsson , ietf@ietf.org Subject: Re: [spfbis] SPF TYPE support 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, 20 Aug 2013 17:32:23 -0000 Hi Hector, At 06:30 20-08-2013, Hector Santos wrote: >I have a few questions and points: > >May I ask why was the above was not an area for clarification as >oppose as the presumed stated technical reason for removal? The SPFBIS WG had a session at IETF 83. The minutes for that session is at http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt Item C on the agenda is about "SPF RR Type and TXT RR (issue #9)". Andrew Sullivan, as SPFBIS Chair, explained that: 'The were people on the mailing list in favor of using the TXT RR appeared to be a modest majority and there were people who argued for SPF RR Type on the grounds of DNS hygiene. The Chair explained that it appears as an empirical matter, overwhelmingly, the TXT RR is used but RRTYPE 99 does not qualify under the unused provision of the SPFBIS charter.' Pete Resnick, as Area Director, commented that: 'the deal with the IESG, as a general statement, the working can removed what is unused and put in what is widely deployed. He pointed out that saying that TXT RR is part of an experiment is contrary to the agreement made with the IESG. His opinion is that either way, the proposal is stuck with TXT RR and that it is not an issue. The only issue is whether the proposal can remove the SPF RRTYPE as unused.' On February 26, 2012, Barry Leiba, as a participant, posted a message ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00654.html ) which I will quote: "These two statements make a pretty compelling case that there is, indeed, an error in RFC4408. There are, of course, multiple ways to resolve it, and I have no immediate opinion on which is best." My opinion, as one of the SPFBIS WG Chairs, was that there was an error. As Barry Leiba mentioned, there were several possible ways to fix that. The SPFBIS Chair stated at the meeting that: "The conclusion reached by the Chair was that the document will say SHOULD NOT publish RRTYPE 99 and MUST NOT query RRTYPE 99." That statement was posted to the SPFBIS mailing list ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01369.html ). Nobody disagreed. >There was adequate information for the expected and original optimal >migration plan but it could of been further codified and clarified. >It would of been on par with BIS level of work. Issue #9 should not >have been a reason for removal. I reported issue #25 [1] regarding >the complexity of the recommended parallel processing approach. I >believe most folks agreed the ideal and optimal migration approach was: > > Query SPF type first, > Fallback to TXT secord. > >It was common sense, at least to me. Both Issue #9 and Issue #25 (see SPFBIS tracker) were well-discussed. Was every technical point carefully considered? I don't think so as it is possible that a technical point may have been missed. There is an opportunity for anyone to comment during the Last Call if the person believes that a technical point has been missed or was not addressed appropriately by the working group. In my opinion the SPFBIS WG carefully considered all the comments which were made in reaching its decision. >Second, I was under the impression interop reports (RFC 6686) were >not making any conclusions or recommendations? Is that a correct >basic understanding of interop reports? They were observations, >collection of available data and while it might be eventually used >to rethink a protocol design, I don't think the above RFC 4408 >statement is a serious "error" in the functional description to >justify removal. There are other parts of 4408 which helped clarify >the migration path. From the Introduction Section of RFC 6686: "In line with the IESG's request to evaluate after a period of time, this document concludes the experiments by presenting evidence regarding both deployment and comparative effect of the two protocols. At the end, it presents conclusions based on the data collected." In my opinion RFC 6686 does make conclusions (see Section 6 of RFC 6686). There is some background information about the RRTYPE issue in Appendix A. >But overall, a correction (not removal) would of suffice. It would >of been on par for BIS-like corrections and protocol updates. Andrew Sullivan, as SPFBIS WG Chair, mentioned that "We have to do _something_, though any action would introduce a backward incompatibility ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03595.html ). >Third, I believe removal required a more deeper IETF discussion >about the initial presumed engineering expectation that DNS servers >(all top DNS servers, including and especially Microsoft DNS >servers) would eventually directly support a new registered SPF type >or at the very least support RFC 3597 (Handling of Unknown DNS >Resource Record (RR) Type) [2]. There were comments about RFC 3567 during the working group discussions (see http://www.ietf.org/mail-archive/web/spfbis/current/msg00545.html http://www.ietf.org/mail-archive/web/spfbis/current/msg00820.html ). >If this is no longer the expectation, then it would make sense to >remove the SPF type but also be aware that in general, this will >also nix (not help) any future idea for successfully adopting new RR types. >It would be added statement that TXT based applications are >acceptable. I think the DNS community continues to have a problem with this. Noted. >SM, Pete, thank you for the opportunity to clarify my point. For the >record, there was no intent to imply it occurred but quite frankly >when it is repeatedly stated, this deeply divided issue has not be >resolved at any point, it does have an intimidation factor. As Mr. >Crocker stated, the burden is on the those who oppose the removal. >But my question was always why was the decision made to remove in >the first place done when in fact it was quite obvious it would not >have industry wide endorsement. The burden should of been to justify >removal. Now it has become difficult to effectively add it back. >This is why I posed the question in two forums to get community >input over the last few years. It was quite obvious to me that the >DNS community would be against this removal. So in this vain, it >was prematurely removed in the WG without early IETF/IESG/DNS >concerns adequately dealt with. Unfortunately, we were advise to >raise the issue again in LC, but by that point, all the IETF >procedural moves were made making it it a very high burden to add >something that should not been removed in the first place. There are two SPFBIS WG Chairs. The way we work is: I read the mailing list messages, the other Chair reads the mailing list messages, each chair reaches his own conclusion and we discuss about it. Once the Chairs agree a message is posted to the WG mailing list. Let's assume that the Chairs did not carefully consider the comments or their determination was incorrect. There is a Last Call where the matter can be raised again. That is the advice that was given. There is indeed a high burden as the person raising the issue again will have to read the mailing list messages to determine whether they have been carefully considered. Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Tue Aug 20 10:32:24 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 36C0711E80E4; Tue, 20 Aug 2013 10:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHMDZ2WfnNJb; Tue, 20 Aug 2013 10:32:23 -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 A0DC821F898A; Tue, 20 Aug 2013 10:32:23 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.26]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7KHVw1W028951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 10:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377019941; bh=fN+2exVJPVJjd6houtZMULSPqKVytijD2xJnY+LWCsw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kNDmrnGQ13NrlkJEGfEfQTaLs9qSzCgmHByBwQH6Pbfv7/Z7GKheh26eMwgujvSno xOru3DBPa6+gC6c7umwYFn93k3kJSD0XFlTrxz1TMwUncQ6itMPL95aJEjHjsVDqJD B412a/p7wNZpeROaOxfKVaFWZdeHVy0Yg63jKrBs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377019941; i=@elandsys.com; bh=fN+2exVJPVJjd6houtZMULSPqKVytijD2xJnY+LWCsw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=r4e+02j6UMRZIMSwDczD4C4++yDDpXPKpqxHTibMW8aWB1t5kZI9+bWNbxgaFR56B XD+vGoQCi11nWTYRJoVsJ9QZcRo7oTQ/JtT+QpP2Tu22V844hKnkbGW4ohNAj1EP8z E3KEMiTa/0BmZf3ihjbRhqnlLvC7ix/BKVwmZ2io= Message-Id: <6.2.5.6.2.20130820100431.0df2aea0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 20 Aug 2013 10:30:41 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <52137A3B.6040200@isdg.net> References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <6.2.5.6.2.20130819202422.0d1756a8@resistor.net> <52137A3B.6040200@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, mansaxel@besserwisser.org, ietf@ietf.org Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 20 Aug 2013 17:32:24 -0000 Hi Hector, At 07:16 20-08-2013, Hector Santos wrote: >This doesn't seem to be correct. My apology if I don't follow or see >the logic. The only real issue as it was since day zero in MARID >was the infrastructure support for recursive passthru queries which >is what RFC 3597 (Handling of Unknown DNS Resource Record (RR) >Type). Without this, which allows for servers to delay/plan direct >new RR type support yet still not error out on an unnamed type, >there COULD NOT be any reasonable expectation to even only suggest a >dual query migration approach, either in serial or parallel. It is >very important to consider the mindset when it was first considered >and written for RFC 4408 because to me, that is the mindset that has changed. This would be a process issue then as the SPFBIS Chairs determination was made on the basic of the text from the SPFBIS Charter which was cited. A person can raise an objection (I am okay with that as that's part of the work) with substantive comments to support the objection. >I hope I am reading this incorrectly. It may be too procedural >oriented to me at this point. > >I would like to see a simple just distinctive consensus on what the >entire IETF/DNS community believes is the future of DNS servers >offering unnamed RR type processing because that is the main barrier >for any kind success. We knew this as far back as MARID. I don't >quite understand why this key point seems to be left out, instead >MARID was deemed off topic. That was an error because if there is no >future in unnamed RR type support, then it really doesn't matter and >the problem is solved. TXT only will be the only fast entry point >for new DNS DOMAIN policy applications. > >If the community still believes it possible, then clarifying and >codifying the SPF/TYPE lookup procedure seems to me to be the only >real correction to make here. My reading of the SPFBIS Charter is that the working group was not tasked to work on the future of DNS servers. That does not mean that arguments about the future of DNS servers are not relevant. There are several questions: (a) Was there an error in RFC 4408? (b) What was the error in RFC 4408? (c) Why was there an error in RFC 4408? (d) What should be done about the error? There isn't anything that can be done about question (c) except not to repeat the same mistake. Is there disagreement on the answers to questions (a) and (b)? Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Tue Aug 20 22:44:51 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 86BB011E8373 for ; Tue, 20 Aug 2013 22:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.88 X-Spam-Level: X-Spam-Status: No, score=-101.88 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 DrI1hfxsJP+q for ; Tue, 20 Aug 2013 22:44:49 -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 C78CD11E81B2 for ; Tue, 20 Aug 2013 22:44:49 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.108]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7L5iZtG013640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Aug 2013 22:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377063887; bh=Q6lgEjOTsg9I/mnSLRjOVkcWGrYQqrGYxQAf+jRBHK0=; h=Date:To:From:Subject:In-Reply-To:References; b=zbQvjDW6dUSJciAaDviNLZrj8VkZwElSg7Sf2fQGzKZGZm7/Rm13G0PJw+fmDSquy z4lvlRchv+hCHdYGzN65KWSdqFMV3oXQpgL1IowhNiwIR80BvaJMZII/Cxs7+id1sW yssyrrBY4RB09cpgryZHG+1Z9XZL1tnmJ/q52aq0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377063887; i=@elandsys.com; bh=Q6lgEjOTsg9I/mnSLRjOVkcWGrYQqrGYxQAf+jRBHK0=; h=Date:To:From:Subject:In-Reply-To:References; b=hKgAP2JIV5lWxPUGhqpJTsLAhjCF1NptmNf56303Rhyf8UiSvsGI8Tdt/7pjaBSg0 D2q6QVJkyV/67HuXvONEUN9QmBpkQhzC7Qy1hWvkI7Q5i9J1hkQpEZj1f0f1U+iNUG j2jMb2dRqJlxt3SD9zi1Fbt55PK5SfQGT20D1wzQ= Message-Id: <6.2.5.6.2.20130820214927.0c6cb6d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 20 Aug 2013 22:43:16 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <6DEE47E1-885D-4F12-A766-D9BB2284BA09@frobbit.se> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <521385AA.9080401@qti.qualcomm.com> <933357EA-6472-4C77-AED3-E6411BC684B6@frobbit.se> <6.2.5.6.2.20130820110057.0bead1e8@resistor.net> <6DEE47E1-885D-4F12-A766-D9BB2284BA09@frobbit.se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy 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, 21 Aug 2013 05:44:51 -0000 At 11:58 20-08-2013, Patrik F=E4ltstr=F6m wrote: >As the bottle is opened, I hereby state my=20 >objection to Section 3.1 of=20 >draft-ietf-spfbis-4408bis-19 for the reasons=20 >explained below. I do agree (as stated below)=20 >that the section of RFC 4408 that specify how to=20 >use both SPF and TXT resource record types=20 >include an error as it does not lead to interoperability. > >As the intention with use of both TXT and SPF=20 >originally was to migrate from TXT to SPF I=20 >instead of what is outlined in the draft suggest=20 >that a proper migration strategy is laid out=20 >(look up mandatory to implement SPF and fall=20 >back to TXT). This instead of deprecation of the SPF record. > >In general I do believe, for example when=20 >looking at IPv6 and DNSSEC and similar=20 >technologies, that the lifetime of RFC 4408 is=20 >too short to deprecate any of the proposed=20 >records that are in use, specifically as RFC=20 >4408 explicitly do allow use of both. I posted the a message about "Revisiting past=20 technical arguments where consensus was reached"=20 (see SPFBIS Charter) in response to a comment=20 about the RFC 4408 transition strategy (=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg01558.html=20 ). I have been reviewing some of the comments=20 which have been made about the topic (see thread=20 at=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg00651.html=20 ). There is a comment from the Responsible Area=20 Director ( http://www.ietf.org/mail-archive/web/dnsext/current/msg13064.html= ): "This discussion should have happened at SPFBIS *chartering* time, as it is crystal clear from the charter that existing features currently in use in SPF are not going away. Indeed, the TXT record was= specifically mentioned in the charter." The Responsible Area Director also mentioned (=20 http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt ) that: "The only issue is whether the proposal can remove the SPF RRTYPE as unused." The decisions taken were to: 1. Fix the error 2. Not to put in a migration strategy I suggest that the working group carefully=20 consider whether there should be a migration=20 strategy or not and whether there are substantive=20 arguments to support the decision. Regards, S. Moonesamy (as document shepherd)=20 From spf2@kitterman.com Tue Aug 20 23:13: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 643D311E81BB for ; Tue, 20 Aug 2013 23:13:07 -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 hCJ9-I90mCb7 for ; Tue, 20 Aug 2013 23:13:03 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D85BE11E81B2 for ; Tue, 20 Aug 2013 23:13:02 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C7F4920E4114; Wed, 21 Aug 2013 02:13:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377065580; bh=JKePaQ+3STtie0FDge2GL03WYqxmNc1khhewQdkbbg8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=StMBN1BVNLxpAeMjqYVD6bfdUj9e9txBW0DqfvUMelJrIZW0ZG3/aCH+sdOCKpccO gX5G83AufvlvL5CypFONwy5HbbX0WsR6p+v5EFlUdZGJFQ32pJRdTQXfbuCMPqIFR5 xxNaa5MLoRweNHrOpulaJb5Rb5oi3Ohl9BGhGoN4= 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 AA0C020E40C6; Wed, 21 Aug 2013 02:13:00 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 21 Aug 2013 02:12:59 -0400 Message-ID: <2419171.1CfTPBYD1t@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-27-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130820214927.0c6cb6d0@resistor.net> References: <6DEE47E1-885D-4F12-A766-D9BB2284BA09@frobbit.se> <6.2.5.6.2.20130820214927.0c6cb6d0@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy 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, 21 Aug 2013 06:13:07 -0000 On Tuesday, August 20, 2013 22:43:16 S Moonesamy wrote: > At 11:58 20-08-2013, Patrik F=E4ltstr=F6m wrote: > >As the bottle is opened, I hereby state my > >objection to Section 3.1 of > >draft-ietf-spfbis-4408bis-19 for the reasons > >explained below. I do agree (as stated below) > >that the section of RFC 4408 that specify how to > >use both SPF and TXT resource record types > >include an error as it does not lead to interoperability. > > > >As the intention with use of both TXT and SPF > >originally was to migrate from TXT to SPF I > >instead of what is outlined in the draft suggest > >that a proper migration strategy is laid out > >(look up mandatory to implement SPF and fall > >back to TXT). This instead of deprecation of the SPF record. > > > >In general I do believe, for example when > >looking at IPv6 and DNSSEC and similar > >technologies, that the lifetime of RFC 4408 is > >too short to deprecate any of the proposed > >records that are in use, specifically as RFC > >4408 explicitly do allow use of both. >=20 > I posted the a message about "Revisiting past > technical arguments where consensus was reached" > (see SPFBIS Charter) in response to a comment > about the RFC 4408 transition strategy ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01558.html > ). I have been reviewing some of the comments > which have been made about the topic (see thread > at > http://www.ietf.org/mail-archive/web/spfbis/current/msg00651.html > ). There is a comment from the Responsible Area > Director ( http://www.ietf.org/mail-archive/web/dnsext/current/msg130= 64.html > ): >=20 > "This discussion should have happened at SPFBIS *chartering* time,= as > it is crystal clear from the charter that existing features curre= ntly > in use in SPF are not going away. Indeed, the TXT record was > specifically mentioned in the charter." >=20 > The Responsible Area Director also mentioned ( > http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt ) th= at: >=20 > "The only issue is whether the proposal can remove the SPF RRTYPE > as unused." >=20 > The decisions taken were to: >=20 > 1. Fix the error >=20 > 2. Not to put in a migration strategy >=20 > I suggest that the working group carefully > consider whether there should be a migration > strategy or not and whether there are substantive > arguments to support the decision. I'm a bit confused by this message. Is this meant to be purely a recit= ation=20 of past events or, in the last paragraph, are you asking us to take thi= s up=20 now? I think we've done that already. Scott K From sm@elandsys.com Wed Aug 21 00:04:24 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 5B04311E81B1 for ; Wed, 21 Aug 2013 00:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 2yagCGQQCL5V for ; Wed, 21 Aug 2013 00:04:23 -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 A4EA811E81CD for ; Wed, 21 Aug 2013 00:04:19 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.108]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7L744kk003376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 00:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377068656; bh=cRkVVgDPdJplp2Fo+hxJCgnge5bL07MVqCu+hbVhqaQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RHqsEd7KBIcl7Yw2TLVA0FOiNE0exJUhfGp0Fu98ovm9amCaQSNJ6xazSeDNjLsUt /1KqWjiC2yGHwFQd0aS9o1BdVNDAFbXJMkjizhY8n0MuHIJ/VLjqdJywVpBbLlWJhD 0Q1FihwceLgRHPsqaR2PsIyf2NiTTwtwPQZ5p2mU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377068656; i=@elandsys.com; bh=cRkVVgDPdJplp2Fo+hxJCgnge5bL07MVqCu+hbVhqaQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fO+1upEojFKPbrBNK5eF0KFGaPkNDLWJij6uaGAMonwGh7fLi1NcH4+WyiTV8i4vw VjmBYki6osHBFj5VNlfC1Ud9/rgMLz/zdcWLhJI6IeBaA5kl3e5ODK/Nm/MIPJyUr1 shm1DuK9W7YgHmTQyKhlLQuXFJSgOOAQcX1hikF0= Message-Id: <6.2.5.6.2.20130820234024.0c6cb068@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 21 Aug 2013 00:00:38 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <2419171.1CfTPBYD1t@scott-latitude-e6320> References: <6DEE47E1-885D-4F12-A766-D9BB2284BA09@frobbit.se> <6.2.5.6.2.20130820214927.0c6cb6d0@resistor.net> <2419171.1CfTPBYD1t@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy 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, 21 Aug 2013 07:04:24 -0000 Hi Scott, At 23:12 20-08-2013, Scott Kitterman wrote: >I'm a bit confused by this message. Is this meant to be purely a recitation >of past events or, in the last paragraph, are you asking us to take this up >now? I think we've done that already. I am asking the working group to review the discussion and comment about whether there are strong arguments to support the decision not to have a migration strategy. Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Wed Aug 21 00:32:20 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 9C76711E81C0 for ; Wed, 21 Aug 2013 00:32:20 -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 l9yWt-uk8ZOx for ; Wed, 21 Aug 2013 00:32:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6A46721F9D0F for ; Wed, 21 Aug 2013 00:32:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6E1E720E4114; Wed, 21 Aug 2013 03:32:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377070333; bh=9Ye9GFKF7fW5r4xM9Tpbi5GfM6VZJU+LoxqPpv1fJmM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=V6ONA5HEi5zh5Ao9+EfWoUgIquC3OqycCLfcekLnioV+9MWuoxzHptrm/txkeU/l8 4wqbAPdsUG/YaFuFdrLm7K+3AcEIZanPAcL757oqWMhFZnYu40JHVnvvuAJ8TEDMTI shujvsJzBrZEUkpBXAL3w3z55KT2qZNq9YjCIi14= 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 5017420E40C6; Wed, 21 Aug 2013 03:32:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 21 Aug 2013 03:32:12 -0400 Message-ID: <19129243.7z7OTnRij9@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-27-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130820234024.0c6cb068@resistor.net> References: <2419171.1CfTPBYD1t@scott-latitude-e6320> <6.2.5.6.2.20130820234024.0c6cb068@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] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy 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, 21 Aug 2013 07:32:20 -0000 On Wednesday, August 21, 2013 00:00:38 S Moonesamy wrote: > Hi Scott, > > At 23:12 20-08-2013, Scott Kitterman wrote: > >I'm a bit confused by this message. Is this meant to be purely a > >recitation of past events or, in the last paragraph, are you asking us to > >take this up now? I think we've done that already. > > I am asking the working group to review the discussion and comment > about whether there are strong arguments to support the decision not > to have a migration strategy. There is no migration strategy. The comparison to IPv6 in the last call discussion is almost apt. This migration would be like IPv6 migration if IPv4 addresses weren't running out. In fact, not that good. There are real operational issues experienced with trying to use type SPF. That's why, at least in the open source world, people are backing away from it. Users complain about issues and there is an obvious fix. It's impossible to write an RFC that captures the flavor of the suggested migration strategy without engaging in magical thinking or not caring about the installed base (which we're required by charter to do). If we were to follow the approach of having 4408bis say something like: - MUST publish type SPF, should publish type TXT - MUST check type SPF, should check type TXT Then a few things would happen: - We would have, on paper solved the interoperability bug of not having a common type mandated for publishing and verifications. - Many people would know were weren't really serious and continue using TXT - New implementers, without experience in the protocol would likely read the text and conclude that supporting type SPF was more important and they should code/publish that first. - These same new implementers would then be left wondering where are all they to other people doing SPF. They might have read that SPF covered more than half of the email on the internet and wonder why their local statistics were substantially smaller (hint: it would be because 4408bis told them to deploy SPF in a way that's completely the opposite of interoperating with the installed base). In case you're left in doubt, I think this would be a ridiculous situation. One counter to the "more queries won't affect DNS, so who cares about doubling hte query load" is that for email processing it's not DNS load that drives performance, it's DNS latency. Latency can hang the entire mail process. In high volume operations, latency is what kills. So even if the dual SPF/TXT transitional model has no real effect on DNS (not that I buy that) it's still a performance issue in the mail stack and it substantially complicated the code/design requirement. I do wonder where these people who claim DNS query loads don't matter where when Doug Otis was busy claiming 111 queries potentially from an SPF check would melt the internet? I would also suggest turning it around a bit. Why would people migrate? "It makes the DNS more pure" isn't something many administrators would find motivating. As far as I know there really aren't any operational incentives to migration. That's my limit for 3:30AM (local). Scott K From mansaxel@besserwisser.org Wed Aug 21 03:01: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 C2A0711E81BA; Wed, 21 Aug 2013 03:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 zsjy1P75zr92; Wed, 21 Aug 2013 03:01:07 -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 3108511E80ED; Wed, 21 Aug 2013 03:01:07 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 191BF9E98; Wed, 21 Aug 2013 12:00:56 +0200 (CEST) Date: Wed, 21 Aug 2013 12:00:56 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: S Moonesamy Message-ID: <20130821100055.GF30516@besserwisser.org> References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <6.2.5.6.2.20130819202422.0d1756a8@resistor.net> <52137A3B.6040200@isdg.net> <6.2.5.6.2.20130820100431.0df2aea0@elandnews.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zs/RYxT/hKAHzkfQ" Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20130820100431.0df2aea0@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, Hector Santos , ietf@ietf.org Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 21 Aug 2013 10:01:07 -0000 --Zs/RYxT/hKAHzkfQ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] Last Call: (Sender= Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1)= to Proposed Standard Date: Tue, Aug 20, 2013 at 10:30:41AM -0700 Quoting S= Moonesamy (sm+ietf@elandsys.c =20 > My reading of the SPFBIS Charter is that the working group was not > tasked to work on the future of DNS servers. That does not mean > that arguments about the future of DNS servers are not relevant. The codification of a pessimistic view of the ability of the DNS installed base to adapt to new RRtypes is - in itself - a statement that influences the future of DNS. That this was not completely understood in terms of influence weight is one of the reasons for this debate. =20 > There are several questions: >=20 > (a) Was there an error in RFC 4408? Yes.=20 =20 > (b) What was the error in RFC 4408? The TXT rrtype was not properly decommissioned; it lacked definitiveness, and neither publication instructions nor selection/query algorithm satisfy this (originally intended, I suppose and believe) sunset view of the TXT record r=C3=B4le vis =C3=A0 vis SPF. > (c) Why was there an error in RFC 4408? >=20 > (d) What should be done about the error? 4408bis needs a better defined depreciation statement for TXT, accompanied by publication and query methods that will ensure the continous phasing-out of SPF data in TXT records. A clarification here will help in making DNS UI vendors doing the right thing. I'm quite confident that presently, the UI vendors sleep soundly after reading 4408 and continuing to ignore SPF/99. That is not=20 desirable.=20 =20 > There isn't anything that can be done about question (c) except not > to repeat the same mistake. >=20 > Is there disagreement on the answers to questions (a) and (b)? Apparently.=20 --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm using my X-RAY VISION to obtain a rare glimpse of the INNER WORKINGS of this POTATO!! --Zs/RYxT/hKAHzkfQ 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) iEYEARECAAYFAlIUj9cACgkQ02/pMZDM1cWoRQCfdvStmypCAbYiuhp8hxkMM9oJ 82IAn21zIW8Jlt1CR9yPIZUpNU1Xdk6u =Rde7 -----END PGP SIGNATURE----- --Zs/RYxT/hKAHzkfQ-- From johnl@iecc.com Wed Aug 21 07:25:50 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 798A411E80F1 for ; Wed, 21 Aug 2013 07:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.753 X-Spam-Level: X-Spam-Status: No, score=-102.753 tagged_above=-999 required=5 tests=[AWL=-0.154, 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 oBGtOTTA0+jm for ; Wed, 21 Aug 2013 07:25:45 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id BEF8211E81FF for ; Wed, 21 Aug 2013 07:25:44 -0700 (PDT) Received: (qmail 40938 invoked from network); 21 Aug 2013 14:25:43 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 21 Aug 2013 14:25:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5214cde7.xn--i8sz2z.k1308; i=johnl@user.iecc.com; bh=/YU79cQIBEaN4+J9/5ZWP75I42ThiqYhjF4ouKfNlJM=; b=ppZ/QNEsYP/YeQl6wnMLXrP1Vrd9sylV3M0BvBiFgaYF6S37rtrbPPDYvMEcbvXPNfeO26a7231TR4lMph3rAE6l6RgeVhCdzzyrUdWGSkxVClH4oh4QhFXrlyRVMXRTaiZoSnT/ekvRCHj6uc4oXHkuCnIT7rbW8EHvqGqOj18QyJGc+nODgd7KOlbGPelQ7QLSF96nJ1tL1oPW0iPns+effYMEwNxlJpTPN0Ln7mPcYqQlYjKveV9eVJLCwv0G DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5214cde7.xn--i8sz2z.k1308; olt=johnl@user.iecc.com; bh=/YU79cQIBEaN4+J9/5ZWP75I42ThiqYhjF4ouKfNlJM=; b=GmH1VGYSyYpU4H7QT21xZvPbUJLdWnXET88YeiiF/AhBpQ/PWXuKUsb1Rw2mz/gMffytiOo7j6B/JnhogfejVpDvWjlcATdxkTYD6PRURTe1/5qSKI/KhCQhIQYIxY9TEuD3TGtUBrE7MsSzhXzP+yQ3rIXgjWxxoozZQfXWRCT1vH2d6/g9oVqzjgCypNnGnSPKBNSKJiJkiZjj6LPph5Fc9WY60vjGJedSX9EP2e625aQ4epeSfVR/EUntHHWC Date: 21 Aug 2013 14:25:21 -0000 Message-ID: <20130821142521.89430.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <19129243.7z7OTnRij9@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: spf2@kitterman.com Subject: Re: [spfbis] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy 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, 21 Aug 2013 14:25:50 -0000 >> I am asking the working group to review the discussion and comment >> about whether there are strong arguments to support the decision not >> to have a migration strategy. > >There is no migration strategy. I entirely agree with Scott's arguments. Regardless of what one might think about the technical issues, there is no way the very large base of SPF users with TXT records that work just fine, and always will work just fine, is going to migrate anywhere. R's, John From dotzero@gmail.com Wed Aug 21 07:31:47 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 08BEF11E83BE for ; Wed, 21 Aug 2013 07:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 ohAggOgve3Jq for ; Wed, 21 Aug 2013 07:31:46 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0555F11E80F1 for ; Wed, 21 Aug 2013 07:31:42 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id er7so895760obc.31 for ; Wed, 21 Aug 2013 07:31:41 -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=U6hvh/HGe3repZGUHFVhizchiJRDfeXtZADhDPs8uTk=; b=RPl1OkqK4bH+VtXvatNf+e0EGe1B7wCJ+PNA6rEsg5zlcBeViQY7xctcb8fScSuARp 5fnGoE0mw7sQt6TA4aWZiOoNKlHZjiaO+v7P2BK3gGD07rhiuS378iqSS1ypwDrQ69Eb HYMKqDedGvngiwD0jTjAVDEZ6bwvgvpntLGL54F6lFECsl6PDSqc5fHOpXpsFHIWltl5 QkxtkeDIGkSJJBJsTl/7kb+3EyeOqlhFu14koJDD19++0Q1560LyZ5MKgrDxNgR21NLy hDHqi2ubZ8yUZgZo/BJN44K3yZJCNSxTkrF6nCyMIP8Nb1xihXZVxsjJIYsixxIhdYaE FlqA== MIME-Version: 1.0 X-Received: by 10.60.17.136 with SMTP id o8mr8297151oed.7.1377095493881; Wed, 21 Aug 2013 07:31:33 -0700 (PDT) Received: by 10.182.34.232 with HTTP; Wed, 21 Aug 2013 07:31:33 -0700 (PDT) In-Reply-To: <20130821142521.89430.qmail@joyce.lan> References: <19129243.7z7OTnRij9@scott-latitude-e6320> <20130821142521.89430.qmail@joyce.lan> Date: Wed, 21 Aug 2013 10:31:33 -0400 Message-ID: From: Dotzero To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy 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, 21 Aug 2013 14:31:47 -0000 +1 to Scott's arguments. We have had these discussions ad nauseum. Mike On Wed, Aug 21, 2013 at 10:25 AM, John Levine wrote: >>> I am asking the working group to review the discussion and comment >>> about whether there are strong arguments to support the decision not >>> to have a migration strategy. >> >>There is no migration strategy. > > I entirely agree with Scott's arguments. > > Regardless of what one might think about the technical issues, there > is no way the very large base of SPF users with TXT records that work > just fine, and always will work just fine, is going to migrate > anywhere. > > R's, > John > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From marka@isc.org Wed Aug 21 07:55: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 8701911E8236 for ; Wed, 21 Aug 2013 07:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, 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 tS3rNa8JTbWV for ; Wed, 21 Aug 2013 07:55:11 -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 929EC11E80D9 for ; Wed, 21 Aug 2013 07:55:11 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 46081C9428; Wed, 21 Aug 2013 14:54:58 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377096911; bh=rc07Q7DuoVP2WyxKz2BEb71wCESRXRxPWWKYs0AkbYg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=YG6G0dZMFwOWg1GhPDv6iU+rAeOj4sxJmgbGXMMhgiHROg2+X1zArTxEvGYtAQMkZ wLMj4RMvc0+9xxyOV2c1WGAHwDcdpRZsKppFKbFskWfD+wnT5n24s8LiSjzpglFfd6 7prORuTwP06WZPyIFGyQrzGTs7VJ3ODfktMcQza0= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 21 Aug 2013 14:54:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CABFA1602E9; Wed, 21 Aug 2013 14:55:08 +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 96D5D1602B4; Wed, 21 Aug 2013 14:55:08 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 26DE938BF1C5; Thu, 22 Aug 2013 00:54:55 +1000 (EST) To: "John Levine" From: Mark Andrews References: <20130821142521.89430.qmail@joyce.lan> In-reply-to: Your message of "21 Aug 2013 14:25:21 +0000." <20130821142521.89430.qmail@joyce.lan> Date: Thu, 22 Aug 2013 00:54:55 +1000 Message-Id: <20130821145455.26DE938BF1C5@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org, spf2@kitterman.com Subject: Re: [spfbis] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy 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, 21 Aug 2013 14:55:17 -0000 In message <20130821142521.89430.qmail@joyce.lan>, "John Levine" writes: > >> I am asking the working group to review the discussion and comment > >> about whether there are strong arguments to support the decision not > >> to have a migration strategy. > > > >There is no migration strategy. > > I entirely agree with Scott's arguments. > > Regardless of what one might think about the technical issues, there > is no way the very large base of SPF users with TXT records that work > just fine, and always will work just fine, is going to migrate > anywhere. You get the nameserver vendors to add code look for TXT SPF records and add SPF SPF records when they find them if there isn't a record there when loading / updating a master zone. I'll write the code for BIND even if I have to do it on my own time. The only reason it isn't written completely at the moment is that their isn't a document recommending that it be done. It is trivial to keep the records in sync as spf supports extensions that are supposed to be ignored and we just tag the copy by adding a extra string to the end e.g. " original=txt". If we were copying from a SPF record then it is " original=spf". Named already checks for "SHOULD publish both" in 4408 and warns when they are not both present. When the message comes up on bind-users about what does this message mean we point to the text that says publish both and that is what usually happens. Now can we please stop saying things are impossible when they are not. You just need to be a little proactive. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From johnl@taugh.com Wed Aug 21 08:07:06 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 337A411E83BB for ; Wed, 21 Aug 2013 08:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, 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 z+X9Ut+0exNc for ; Wed, 21 Aug 2013 08:07:05 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 11AE311E823C for ; Wed, 21 Aug 2013 08:07:04 -0700 (PDT) Received: (qmail 49375 invoked from network); 21 Aug 2013 15:07:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=c0de.5214d798.k1308; bh=oqCvnZPxGCTBGcLyUHMj52dyW4YKMMc6DD3sx6xdS/0=; b=dv4wnXORZeAGTzx96pcJMqc9w+L8VhwA7Ke4b0mYZhUK0J5flDt0/WUgUpUJ9Xr2Brzf8PxwWhZeOYwXRytgZL7mw+FcIntgCVtEVa3zOfxMSMJGGtEtpUBnuLu/nAsCjILSo/h/dR4EwCmbYoEUCqR6+MV8eEGhAHJ5w+8ljn0dO0V2QhC/HlPsGguzxZeMNaqdRI1Nxe+j1UnhqR0wgKC58HTShkNhSfvHmYemCX6uQ92N7w1/zXwn0j1QNEPc DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=c0de.5214d798.k1308; bh=oqCvnZPxGCTBGcLyUHMj52dyW4YKMMc6DD3sx6xdS/0=; b=cF8CTH3xksl/yLBOBmhKr2BoMiUDMtPcKYNkVaU/5Qoek8aBSYCP9Tk1q6mocNMSrlztMbIds2U75lgMDtVZdD0dDy7f4ss9XMcBsSd6i5ij/MsJeBaHm/RqShWFgKGcjmmn+mP5vHXQ8qu6OLxkA1spaQigVLRM8tdH8d+FlZw7rbxnHjsDzq04iSrnMAThgnu+4tdBmjX8PhLsPH/Jfs1JhHCdO5MzG8U71OsZ9ls4dHBReG30dxi5JfZGcpLl Received: (ofmipd 127.0.0.1); 21 Aug 2013 15:06:42 -0000 Date: 21 Aug 2013 11:07:04 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" In-Reply-To: <20130821145455.26DE938BF1C5@drugs.dv.isc.org> References: <20130821142521.89430.qmail@joyce.lan> <20130821145455.26DE938BF1C5@drugs.dv.isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: spfbis@ietf.org Subject: Re: [spfbis] not a migration strategy 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, 21 Aug 2013 15:07:06 -0000 > You get the nameserver vendors to add code look for TXT SPF records > and add SPF SPF records when they find them if there isn't a record > there when loading / updating a master zone. Believe it or not, you are not the first person to think of that hack. I did it for a while, and found that it caused more problems than it solved. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From tim@eudaemon.net Wed Aug 21 08:19:50 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 8BBF611E8112 for ; Wed, 21 Aug 2013 08:19:50 -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 7aqRA5sZw0zm for ; Wed, 21 Aug 2013 08:19:44 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id C460E21F9C68 for ; Wed, 21 Aug 2013 08:19:37 -0700 (PDT) Received: from [10.0.1.8] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id A07D5CB46; Wed, 21 Aug 2013 11:20:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Draegen In-Reply-To: Date: Wed, 21 Aug 2013 11:19:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <19129243.7z7OTnRij9@scott-latitude-e6320> <20130821142521.89430.qmail@joyce.lan> To: Dotzero X-Mailer: Apple Mail (2.1508) Cc: "spfbis@ietf.org" , John Levine , Scott Kitterman Subject: Re: [spfbis] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy 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, 21 Aug 2013 15:19:50 -0000 On Aug 21, 2013, at 10:31 AM, Dotzero wrote: > +1 to Scott's arguments. We have had these discussions ad nauseum. Also +1 to Scott's arguments. I'm a bit of an odd soul, though, as I think all of the SPF vs TXT = record discussion is simply wrong. There should not be a "type SPF", as = SPF records are just text strings. If I had a magic wand, I'd wave it and change where SPF is discovered to = be of the form "_spf.example.org", with TXT records serving out text spf = records. Problem solved! =3D- Tim From dhc@dcrocker.net Wed Aug 21 08:48:56 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 1D2E511E8233 for ; Wed, 21 Aug 2013 08:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.909 X-Spam-Level: X-Spam-Status: No, score=-5.909 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 GBvExnPNoxyO for ; Wed, 21 Aug 2013 08:48:51 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7A411E8227 for ; Wed, 21 Aug 2013 08:48:51 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7LFmlhY020390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 21 Aug 2013 08:48:51 -0700 Message-ID: <5214E146.40303@dcrocker.net> Date: Wed, 21 Aug 2013 08:48:22 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 CC: "spfbis@ietf.org" References: <19129243.7z7OTnRij9@scott-latitude-e6320> <20130821142521.89430.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 21 Aug 2013 08:48:51 -0700 (PDT) Subject: Re: [spfbis] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 15:48:56 -0000 On 8/21/2013 7:31 AM, Dotzero wrote: > +1 to Scott's arguments. We have had these discussions ad nauseum. +1 Working on migration is useful when the market has expressed interest in migration. Absent that, it's an exercise in waste and delay. And we are profoundly lacking in any market demonstration of needing to change from the current use of the TXT record for SPF, no matter how architecturally impure or operationally offensive it might seem. Frankly, being required to pursue such a thing would mostly demonstrate the IETF as a denial of service attack on utility. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From marka@isc.org Wed Aug 21 16:49:46 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 A7E2211E8129 for ; Wed, 21 Aug 2013 16:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 0JOy9BHMkryV for ; Wed, 21 Aug 2013 16:49:42 -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 904FB21F99D0 for ; Wed, 21 Aug 2013 16:49:42 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 521FFC9497; Wed, 21 Aug 2013 23:49:29 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377128982; bh=2IagWoHmkpXbsvlEzUcJaanonBV6OuVZNYKyZeJe0kk=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=hxu9TEq8QepkdOU+E8RgRrYaKwCJtUiWxJsHeLQQeMc0tbp1TWdd+02CkvEroPo4g gRx9Ye0yu4icHXA1eQ7IY2y20tyuoldCtJNUtjKV2QvnQAU+tFdQxq3Hy+0PrRdFg/ mxlYL4Zo1Isn7EEdJmEqnOAMUiybRDe8vIdHKwZo= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 21 Aug 2013 23:49:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 79B501602E9; Wed, 21 Aug 2013 23:49:41 +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 4C3D81602B4; Wed, 21 Aug 2013 23:49:41 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id E020D38C0BCE; Thu, 22 Aug 2013 09:49:26 +1000 (EST) To: dcrocker@bbiw.net From: Mark Andrews References: <19129243.7z7OTnRij9@scott-latitude-e6320> <20130821142521.89430.qmail@joyce.lan> <5214E146.40303@dcrocker.net> In-reply-to: Your message of "Wed, 21 Aug 2013 08:48:22 -0700." <5214E146.40303@dcrocker.net> Date: Thu, 22 Aug 2013 09:49:26 +1000 Message-Id: <20130821234926.E020D38C0BCE@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy 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, 21 Aug 2013 23:49:46 -0000 In message <5214E146.40303@dcrocker.net>, Dave Crocker writes: > On 8/21/2013 7:31 AM, Dotzero wrote: > > +1 to Scott's arguments. We have had these discussions ad nauseum. > > +1 > > Working on migration is useful when the market has expressed interest in > migration. Absent that, it's an exercise in waste and delay. > > And we are profoundly lacking in any market demonstration of needing to > change from the current use of the TXT record for SPF, no matter how > architecturally impure or operationally offensive it might seem. > > Frankly, being required to pursue such a thing would mostly demonstrate > the IETF as a denial of service attack on utility. Bumpkin. We already have code that looks for both records. We already have support in nameservers and resolvers. We can make authoritative servers for the zone publish SPF when they see a TXT/v=spf1 record. Where is the denial of service attack? Mark > d/ > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Wed Aug 21 17:02: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 E98B021F850D for ; Wed, 21 Aug 2013 17:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 SqTw+LfG94yk for ; Wed, 21 Aug 2013 17:02:24 -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 B132A21F85A1 for ; Wed, 21 Aug 2013 17:02:23 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 8E89FC94A6; Thu, 22 Aug 2013 00:02:10 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377129743; bh=V7aIYbV0s3+ex0UWsYzRzH/eKp4cEHjJwmPUSrBy3o4=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=X24+o5KTtxeMJEMvsJUo0pInhXm59bzYKTQK/ixsf51sGyowTVjjmJwo5LbuFjkF0 F+HmqS0scndgljqfurYHAw59NQ0M35A6gpni/N/qPvspefGnAx+G/ntiLIMeb+WzCS BKf8X+3XHUtoOQiG2SS685EhKGRy7VLf6p8JDhcc= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 22 Aug 2013 00:02:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C15291602E9; Thu, 22 Aug 2013 00:02:22 +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 936761602B4; Thu, 22 Aug 2013 00:02:22 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id D59A738C189D; Thu, 22 Aug 2013 10:02:07 +1000 (EST) To: "John R Levine" From: Mark Andrews References: <20130821142521.89430.qmail@joyce.lan> <20130821145455.26DE938BF1C5@drugs.dv.isc.org> In-reply-to: Your message of "21 Aug 2013 11:07:04 -0400." Date: Thu, 22 Aug 2013 10:02:07 +1000 Message-Id: <20130822000207.D59A738C189D@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org Subject: Re: [spfbis] not a migration strategy 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: Thu, 22 Aug 2013 00:02:29 -0000 In message , "John R Levine" wri tes: > > You get the nameserver vendors to add code look for TXT SPF records > > and add SPF SPF records when they find them if there isn't a record > > there when loading / updating a master zone. > > Believe it or not, you are not the first person to think of that hack. > > I did it for a while, and found that it caused more problems than it > solved. With code to identify the original record or without? I was thinking "with code to identify the original record". The SPF format supports extensions. Adding " original=", where is spf or text, to the end of the replicated record allows for fully automated replication to be done. Mark > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From johnl@iecc.com Wed Aug 21 17:41: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 9205D21F938E for ; Wed, 21 Aug 2013 17:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.706 X-Spam-Level: X-Spam-Status: No, score=-102.706 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 rbcOi6NLtiAv for ; Wed, 21 Aug 2013 17:41:05 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2D66B21F8F3C for ; Wed, 21 Aug 2013 17:41:04 -0700 (PDT) Received: (qmail 67475 invoked from network); 22 Aug 2013 00:40:57 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Aug 2013 00:40:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52155e19.xn--btvx9d.k1308; i=johnl@user.iecc.com; bh=xd0JNS6TLBFA0MgoHTVhrB+SBNthwQwcd4D79VUAZ7w=; b=UpwVGyNevc3m2rerYIrh+YqPZNBqIGiomyGfXXU3IzmW27enhenOpVIgE0VlYfMcpDTb+7TZ2kveOTHMgpTA+Tn0KvSrJpcqwrSA5B+SnW2pzicf0+AcoEFzyt8jQQMEmRb5ZWkEWlpimGJy3lsBa2D47wVCD8NWDx0h4hxxMzMxTxfS+UzIBuIMR8HTHDeqQTdlFsRulhyAMayY+R2BvDFHLOqlfPqaLw/RyC9cd2y5rJKtOocl93UdpIbneq4p DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52155e19.xn--btvx9d.k1308; olt=johnl@user.iecc.com; bh=xd0JNS6TLBFA0MgoHTVhrB+SBNthwQwcd4D79VUAZ7w=; b=MVrV62y3TezPU4gpKD8XCpL2x8mtdZOdqvJ6oUbmzo/rtPQELvkVIMkX8Y79gYSA6t2DviVD+XLblQWsAE0a3PBYBm6vzUJZp0RvwJ/2v6LKOwqpY/2rQ0ygYfL2brLi39JOUAKwP8kn7ALnqhPjcw9GcKtzZQmfZT8WpJsASL5WT0YusqKznyoMRC0YGR0BqRbucfCjFv1p0Sb/z3nDoh4AuDmqeNNIgslXomQcnSCVA6j5GhsvFl6MoUgME5iX Date: 22 Aug 2013 00:40:35 -0000 Message-ID: <20130822004035.91384.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20130822000207.D59A738C189D@drugs.dv.isc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: marka@isc.org Subject: Re: [spfbis] not a migration strategy 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: Thu, 22 Aug 2013 00:41:09 -0000 >> > You get the nameserver vendors to add code look for TXT SPF records >> > and add SPF SPF records when they find them if there isn't a record >> > there when loading / updating a master zone. >> >> Believe it or not, you are not the first person to think of that hack. >> >> I did it for a while, and found that it caused more problems than it >> solved. > >With code to identify the original record or without? Without, but the problems had nothing to do with the contents of the type 99 records. R's, John From marka@isc.org Wed Aug 21 17:56:13 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 624A811E8178 for ; Wed, 21 Aug 2013 17:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 lQ5yzt1Jwl30 for ; Wed, 21 Aug 2013 17:56:08 -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 878D111E817D for ; Wed, 21 Aug 2013 17:56:08 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 764ECC9424; Thu, 22 Aug 2013 00:55:55 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377132967; bh=8voIG6ZlB/4Fm3Lq4iE6N6nySCa4L8jTk+STNKiyrbg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=UT21LYJlgt99NGhlBardpciLxWSkdLLyZTdoKH9hxhhnnWINXKB/UXkNUpjTmzEmA zFWe9Q/L8XHWzWM/4+CV47A+dgSz8Butn6YSVfA/0lLnsIflPjxFmQKpuXF5l3/dsq RH28BYNDRFwEI9lePFpEea9FSfVo5aVnVHV5K6Ho= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 22 Aug 2013 00:55:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CD724160482; Thu, 22 Aug 2013 00:56:07 +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 A00041603E9; Thu, 22 Aug 2013 00:56:07 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1400438C346C; Thu, 22 Aug 2013 10:55:53 +1000 (EST) To: "John Levine" From: Mark Andrews References: <20130822004035.91384.qmail@joyce.lan> In-reply-to: Your message of "22 Aug 2013 00:40:35 +0000." <20130822004035.91384.qmail@joyce.lan> Date: Thu, 22 Aug 2013 10:55:52 +1000 Message-Id: <20130822005553.1400438C346C@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org Subject: Re: [spfbis] not a migration strategy 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: Thu, 22 Aug 2013 00:56:13 -0000 In message <20130822004035.91384.qmail@joyce.lan>, "John Levine" writes: > >> > You get the nameserver vendors to add code look for TXT SPF records > >> > and add SPF SPF records when they find them if there isn't a record > >> > there when loading / updating a master zone. > >> > >> Believe it or not, you are not the first person to think of that hack. > >> > >> I did it for a while, and found that it caused more problems than it > >> solved. > > > >With code to identify the original record or without? > > Without, but the problems had nothing to do with the contents of the > type 99 records. Yet you don't enumerate the problems. Did you modify the nameserver to make the changes? When I say put it in the nameserver. That covers loading master zones from disk, updating the zone using UPDATE, fixing the external tools that manipulate/check the zone the zone like dnssec-signzone, named-checkzone and named-compilezone. It also mean have the inline signer code add the records. This also means fix NSEC/NSEC3 records add RRSIGs etc. A simpler step would be to just refuse to serve the zone if SPF records are not present when v=sfp1 TXT records are. Not accept updates that put the zone into this state. Make it a concious decision to break the SHOULD in RFC 4408. I believe most people break that SHOULD unintentionally. Mark > R's, > John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From johnl@taugh.com Wed Aug 21 18:03: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 2BED511E8196 for ; Wed, 21 Aug 2013 18:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, 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 03mRb+9c-cKg for ; Wed, 21 Aug 2013 18:03:17 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4226A11E818F for ; Wed, 21 Aug 2013 18:03:17 -0700 (PDT) Received: (qmail 71732 invoked from network); 22 Aug 2013 01:03:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=11833.52156354.k1308; bh=ooYCaqerLlZB25G9QgKZ1HFFzX6OmWnU3WWxOkK5WfU=; b=INPMywCyr7cBjixfk4Qihdl+zUm1jJLASMitMbHJAn5ryQml2dcZDmgDYPn9pksEW8SQAI6V3wKQChR2IlMYfnM/RQd5KGwrNBmET7kisNKqSo0AfDDj2OfQv2er8wXtffp5r8qdx2riRRD1210r+/iWL+roLs7W+eCERYCuWgU/mcTPywMS4GMjaonnDrvo6tQxDso/mpmo9LIc4d2hHXQt77yRwpmm52P5/KYXBRLbEdiXXuyL7ApY7OhKcpwU DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=11833.52156354.k1308; bh=ooYCaqerLlZB25G9QgKZ1HFFzX6OmWnU3WWxOkK5WfU=; b=k4MyHWqz5O7/xxFfeeu83/UiCciMayduj4+gQkjlZNAYqetwiD8h6qIS3awbAflNufUy0EaJZ3MFamVSFbvDwDItZCmb6Xo1UqxOTHtTkrQKNg/XtAa+QC8lLryKAsncZUN/q5RM2VjuUF1vSsc6a+G7CLN4DbUYbCgLDzIUliXRM94+hoeX9aJ3t+6bnEdFqU29xx91tfL5QTaMyK0krMjDCQbYdH+S/vhSzVU2xuze813gzZWUMMnKg4hqDcdd Received: (ofmipd 127.0.0.1); 22 Aug 2013 01:02:54 -0000 Date: 21 Aug 2013 21:03:16 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" In-Reply-To: <20130822005553.1400438C346C@drugs.dv.isc.org> References: <20130822004035.91384.qmail@joyce.lan> <20130822005553.1400438C346C@drugs.dv.isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] not a migration strategy 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: Thu, 22 Aug 2013 01:03:18 -0000 >> Without, but the problems had nothing to do with the contents of the >> type 99 records. > > Yet you don't enumerate the problems. I was a while ago and I don't remember exactly what went wrong, but it was the same sort of stuff that Scott described. > Did you modify the nameserver to make the changes? No, of course not. The input from my DNS server is generated by scripts from a database, and it was a three line tweak to one of the scripts. The servers published type 99 just fine, the problems were elsewhere. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From WebMaster@Commerco.Net Wed Aug 21 18:15: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 8B40C11E81A5 for ; Wed, 21 Aug 2013 18:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 aTC+qxAg1HJv for ; Wed, 21 Aug 2013 18:15:32 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB4211E81A8 for ; Wed, 21 Aug 2013 18:15:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=RbSUpLr+OqL9HR4chxJ9RDdBBlRatzVOhtPO6rJsjwXEqBRH2X0F9D4MhZgBclbk8XrSuTMRjP4tcl4xO4H/f50+jvrRBh52CvXHDe4L5IykXrBWC7NYxHMXwT6Cg7ec7ZNEHnP7nf3dLaycbHlBuw3s7bUKhvIFfZiCPZs3LC8= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.6) with ESMTP (EHLO [10.240.241.49]); Thu, 22 Aug 2013 01:15:15 +0000 Message-ID: <5215661D.507@Commerco.Net> Date: Wed, 21 Aug 2013 19:15:09 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130822004035.91384.qmail@joyce.lan> In-Reply-To: <20130822004035.91384.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: John R Levine , Mark Andrews Subject: Re: [spfbis] not a migration strategy 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: Thu, 22 Aug 2013 01:15:37 -0000 On 8/21/2013 6:40 PM, John Levine wrote: >>>> You get the nameserver vendors to add code look for TXT SPF records >>>> and add SPF SPF records when they find them if there isn't a record >>>> there when loading / updating a master zone. >>> >>> Believe it or not, you are not the first person to think of that hack. >>> >>> I did it for a while, and found that it caused more problems than it >>> solved. >> >> With code to identify the original record or without? > > Without, but the problems had nothing to do with the contents of the > type 99 records. > > R's, > John Actually, I think some of the problems did have something to do with the contents of the SPF (type 99) RRs insofar as, if memory serves, there were concerns posted about the synchronization issue when both were supported by a DNS publisher (e.g., which do you choose to believe if they are different, etc). The other major problem discussed, as I recall, was that abandoning TXT might cause some trouble with older hardware which did not have the ability to support or handle an SPF (type 99) RR. That problem is at least partially addressed by the DNS changes that Mark Andrews mentioned. Addressed, in that a modern version DNS server (resolver) will go check the SPF RR and, finding no answer, will go check the TXT RR. Thus continuing to even breath life into devices which probably should get updated or be replaced and doing it without breaking things. Best, Alan M. From johnl@taugh.com Wed Aug 21 18:20:34 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 851C211E81A5 for ; Wed, 21 Aug 2013 18:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, 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 L-7Os7YnBTeq for ; Wed, 21 Aug 2013 18:20:34 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id CD5BC11E818F for ; Wed, 21 Aug 2013 18:20:33 -0700 (PDT) Received: (qmail 74618 invoked from network); 22 Aug 2013 01:20:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=12379.52156761.k1308; bh=pqFPgpDOitP0TokMmg9PFph7efy0DO8oqHkYEbkn2O4=; b=LhSH3Cz64f49Y65r4vCHA6G1Q7nGuiECczBzYWdzMjH2yc02EahPt64VveaBDfqvZ9mFofr480Q7RXBPiXfy9ymMzUXN+q16UHV1OwTQzPufrjczAJDLxneScYV814/A4wd4IaQj0oE2VE6yTcVRTHIOTFgfg1693vP1uBXyqBvQzZ3eJae6qteqMfS+lmqsC3qW1ZaQHcMmfw/VedQ3pUMcgKmO3BsNFI5Up6KAP3xrhNJYryX7QCJwgAMw/4Xp DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=12379.52156761.k1308; bh=pqFPgpDOitP0TokMmg9PFph7efy0DO8oqHkYEbkn2O4=; b=wBy6FM1zPN0dSMRgDRRmd842H4jKIsBY4910qXN3Gs79yDAAAbGfTLk4F6ylFxNIVeUfBgt5IZ9cZFSDfFdq/PJ9z4yi0xY03WBgsyVe1rtIPb6euLT2kg9HX9MbOLIM4AY4VqCnI/hJkMwckr1oe3kM9AOwAPJLdbXKwmWLOwaqCJI+bAo5RQOrnEc8Ctfj3Rhkoc+Gs9NLVMSTDUMSpakc7taguJqXo1bLChv0tg9c3NhJQ8YD3jAulX6Ki4K9 Received: (ofmipd 127.0.0.1); 22 Aug 2013 01:20:11 -0000 Date: 21 Aug 2013 21:20:33 -0400 Message-ID: From: "John R Levine" To: "Commerco WebMaster" In-Reply-To: <5215661D.507@Commerco.Net> References: <20130822004035.91384.qmail@joyce.lan> <5215661D.507@Commerco.Net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] not a migration strategy 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: Thu, 22 Aug 2013 01:20:34 -0000 >> Without, but the problems had nothing to do with the contents of the >> type 99 records. > Actually, I think some of the problems did have something to do with the > contents of the SPF (type 99) RRs insofar as, if memory serves, there were > concerns posted about the synchronization issue when both were supported by a > DNS publisher (e.g., which do you choose to believe if they are different, > etc). In my case, it was various things in other places doing unfortunate things with type99 queries and/or replies. It was a while ago, I don't remember the details. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From sm@elandsys.com Wed Aug 21 19:20:55 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 55C1F11E81A5 for ; Wed, 21 Aug 2013 19:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 CWfquqFKIsGn for ; Wed, 21 Aug 2013 19:20:54 -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 D86D311E81A2 for ; Wed, 21 Aug 2013 19:20:52 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.102]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7M2KYm5011803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 19:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377138046; bh=jNJlfZ0PPm7cwClyHM6NYOZA3YBXV1UBJYumTgvVbis=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=WwE4BylYwg7yV2E0xSEzcu2ZT1dn8F2I/qz2wIxSixxZO7NfmAS2NAnaqifO815ZC CzJWo6OBlI50tdYgwp4fHDcLNV0iIzsDa05H7I/ryuT4GmYzHs9vggyF7gJwXYjjdt aAtJGU/JMXkdP6xAPUcvR5u9W0c/WTdedOLwQQec= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377138046; i=@elandsys.com; bh=jNJlfZ0PPm7cwClyHM6NYOZA3YBXV1UBJYumTgvVbis=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RoyipQuNQ8044yAQrkhBYA+A4+i54zQcx3JEWoXQEjfRvYHaBZK7i2Zpg3p4TS7f1 J5bAPNZSiIxRZIn0raga+vzqt2AfKUcs84CsfVGcNKBind8KrkcJ57CZkh0oRXFHSM 8rFQgtTIUT07EXb/e9B9CWITn98qN0YBwS1ccGg0= Message-Id: <6.2.5.6.2.20130821185309.0cadf930@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 21 Aug 2013 19:20:11 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominu m.com> References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Ted Lemon Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 02:20:55 -0000 At 09:22 21-08-2013, Ted Lemon wrote: >I am curious if the folks who did the analysis of query rates know >the answers to the following questions: > >1. Per unit of mail delivered (as opposed to per domain), for what >percentage of delivered mail for which SPF TXT records exist do SPF >RRtype records _also_ exist? I wasn't clear on whether an attempt >was made to come up with an answer to this question. > >2. Per unit of mail received, for what percentage of received mail >does the receiver currently issue SPF RRtype queries. > >The reason I ask these questions is that the rationale for the >decision made by the working group was that the data supported it, >and I think that was a good rationale, but only if the data >_actually_ supports it. But I don't think that the data was >analyzed on the basis of units of mail delivered, but rather on the >basis of number of queries seen. I don't recall whether the SPFBIS WG considering the angle mentioned above. It would help if someone could provide some answers to the above questions. Regards, S. Moonesamy (as document shepherd) From dhc@dcrocker.net Wed Aug 21 19:26:34 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 2507E11E81A2 for ; Wed, 21 Aug 2013 19:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oS6pyzaXPtpu for ; Wed, 21 Aug 2013 19:26:29 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 17AB311E8172 for ; Wed, 21 Aug 2013 19:26:29 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7M2QD7v000312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Aug 2013 19:26:17 -0700 Message-ID: <521576AC.6090100@dcrocker.net> Date: Wed, 21 Aug 2013 19:25:48 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: S Moonesamy References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> In-Reply-To: <6.2.5.6.2.20130821185309.0cadf930@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 21 Aug 2013 19:26:17 -0700 (PDT) Cc: spfbis@ietf.org, Ted Lemon Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 02:26:34 -0000 On 8/21/2013 7:20 PM, S Moonesamy wrote: > I don't recall whether the SPFBIS WG considering the angle mentioned > above. It would help if someone could provide some answers to the above > questions. I suggest, instead, that Ted review the research that the wg already did and if he believes it inadequate he should explain how so, what is needed beyond it, and why it is essential to expend the added effort and time. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Wed Aug 21 20:03:22 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 8449911E81CA for ; Wed, 21 Aug 2013 20:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.695 X-Spam-Level: X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 a-HaVoQq5KeM for ; Wed, 21 Aug 2013 20:03:18 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DC94D11E8208 for ; Wed, 21 Aug 2013 20:03:03 -0700 (PDT) Received: (qmail 94454 invoked from network); 22 Aug 2013 03:03:03 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Aug 2013 03:03:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52157f67.xn--30v786c.k1308; i=johnl@user.iecc.com; bh=RbEieSAL0P3K6Fph/gLuavXh1U3yaVqE6EHiRgWiyV0=; b=vS/fFIa/C2OPIPzrEKeuy4YHdEGVhcum23Xth5ls/0hj25LbVAOBtPuh0l7d4xpJbfazSQ0qb57/0nsLI7kqSWBGN2E1k4sxAPOmcOKKTbes3W+lF42rxvwz5W+ZDzS3HGyR2PqMYc9rYkzbl0APAtKoyo4xnIHtSt1Mt5dodeTZicQtti9RdknzRZyYSfDT+uvEfunfOSaE71BfHhiBh5wMVfv/HWhr/lOzVBzQ/BaFy4LyjdZisM4DmCuVAE7q DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52157f67.xn--30v786c.k1308; olt=johnl@user.iecc.com; bh=RbEieSAL0P3K6Fph/gLuavXh1U3yaVqE6EHiRgWiyV0=; b=L4NSR4mdSFCw+33GUd7FtBH4H/RFMS313EMrkqPIwCiKyUWBWub1a7XpK878xqMZsISb7uLHIVfR/Lbmh87K6Szv2gLs+tA5hDTb+ZFUWAfyfh2JK9s2S4MP0PZdQBDQQoMA9xqIVXIjfaMLu4L6darR8mMAckpCMPDiL5rM8extTmXP3Uq31nkSGSjMLewbEI5BPRmCp66U2FGLaKeoxyJYpISDL7YnY8fnFyDksdfoupPl8MWK+UeDHr+80e5o Date: 22 Aug 2013 03:02:40 -0000 Message-ID: <20130822030240.92142.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20130821185309.0cadf930@resistor.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: sm+ietf@elandsys.com Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 03:03:22 -0000 >>1. Per unit of mail delivered (as opposed to per domain), for what >>percentage of delivered mail for which SPF TXT records exist do SPF >>RRtype records _also_ exist? I wasn't clear on whether an attempt >>was made to come up with an answer to this question. >> >>2. Per unit of mail received, for what percentage of received mail >>does the receiver currently issue SPF RRtype queries. I'm not aware of any statistics, and it would be a challenge to collect any meaningful ones since there's no straightforward way to get information about any mailstream other than your own, but it's not hard to make some estimates. The SMTP mail world has a few giants and a very long tail. The giants are Google, Yahoo, and Microsoft, each of which does mail under their own familiar names, and also provides outsourced mail for huge numbers of other people. Then there's some pretty big mail systems like Comcast, AOL, at&t, and GMX (mail.com and a lot of other private and vanity domains.) Then there's a very long tail of about 100,000 other mail servers. The number of domains vastly exceeds the number of servers since most mail servers handle mail for many domains. None of the big three publish or check type 99 records, and I'm not aware of anyone in the next tier who does either. If you weighted the numbers by mail volume, most if not all of the systems that publish and check type 99 are out in the tail, so the percentage would be considerably less than you'd get from just counting domains. This is just an estimate, but it's an educated one based on a lot of experience so if anyone disagrees, please provide data. R's, John From spf2@kitterman.com Wed Aug 21 20:25: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 1AE8411E81D0 for ; Wed, 21 Aug 2013 20:25:02 -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 9bqbIsdrVnVX for ; Wed, 21 Aug 2013 20:24:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0646311E8179 for ; Wed, 21 Aug 2013 20:24:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7DBE920E40FD; Wed, 21 Aug 2013 23:24:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377141896; bh=ke+Q4WnP4N/trOk9J5jBl+riBHXV+OzGBSvv+6n6zzE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=oM5Zwtnmz+TpExJPPYkmVf+CW/VSssrh3POgnx2/mvJbb882hCMipjl3fsPJaaSUi +gPSWEJRH1OiLx8p53ueRcn6ISAMCrsZsFPpk7yGzG7FIIIWktDub8MQKtX9HVB7hb 7JUQ8J8i7uNqLTwWe8opwyaCmtUtpAnIZjK2mD7c= 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 6437B20E40C2; Wed, 21 Aug 2013 23:24:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 21 Aug 2013 23:24:55 -0400 Message-ID: <2511589.WuLlCIhmhR@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130821185309.0cadf930@resistor.net> References: <20130819150521.GB21088@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@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] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 03:25:02 -0000 On Wednesday, August 21, 2013 19:20:11 S Moonesamy wrote: > At 09:22 21-08-2013, Ted Lemon wrote: > >I am curious if the folks who did the analysis of query rates know > >the answers to the following questions: > > > >1. Per unit of mail delivered (as opposed to per domain), for what > >percentage of delivered mail for which SPF TXT records exist do SPF > >RRtype records _also_ exist? I wasn't clear on whether an attempt > >was made to come up with an answer to this question. > > > >2. Per unit of mail received, for what percentage of received mail > >does the receiver currently issue SPF RRtype queries. > > > >The reason I ask these questions is that the rationale for the > >decision made by the working group was that the data supported it, > >and I think that was a good rationale, but only if the data > >_actually_ supports it. But I don't think that the data was > >analyzed on the basis of units of mail delivered, but rather on the > >basis of number of queries seen. > > I don't recall whether the SPFBIS WG considering the angle mentioned > above. It would help if someone could provide some answers to the > above questions. I don't think it's either possible or useful to answer those questions. The key point is we needed to pick a common mandatory to publish/mandatory to receive RRTYPE. I cannot imagine any way to look at the data that would make it reasonable to pick RRTYPE SPF. Scott K From Ted.Lemon@nominum.com Wed Aug 21 20:29:06 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 257FC11E81D0 for ; Wed, 21 Aug 2013 20:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.584 X-Spam-Level: X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 ISBAGZ8k8Da7 for ; Wed, 21 Aug 2013 20:28:59 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 6CED011E810C for ; Wed, 21 Aug 2013 20:28:59 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUhWFexgCBY4zZX7GQhdl6C61U+NbWu8n@postini.com; Wed, 21 Aug 2013 20:28:59 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DB13F1B82BC for ; Wed, 21 Aug 2013 20:28:58 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3F12D19006E; Wed, 21 Aug 2013 20:28:58 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 21 Aug 2013 20:28:58 -0700 From: Ted Lemon To: "" , Dave Crocker Thread-Topic: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Thread-Index: AQHOnt8CSYFjulBN10Cqc2E5OcP8BZmhBxKA Date: Thu, 22 Aug 2013 03:28:57 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> In-Reply-To: <521576AC.6090100@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1375FAB99F79A64AB1DEAC9C872A4DA6@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , S Moonesamy Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 03:29:06 -0000 On Aug 21, 2013, at 7:25 PM, Dave Crocker wrote: > I suggest, instead, that Ted review the research that the wg already did = and if he believes it inadequate he should explain how so, what is needed b= eyond it, and why it is essential to expend the added effort and time. I did review the research back when we had the discussion during the last c= all (or possibly before), and I am fairly sure that the research I am askin= g about did not in fact happen. But my point, as I expressed to John earl= ier, was not to say that spfbis made a mistake, but rather that if people w= ant to _assert_ that spfbis made a mistake, there's some obvious homework t= hey should do before making that assertion. From dhc@dcrocker.net Wed Aug 21 20:36:04 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 9426F21F9B7E for ; Wed, 21 Aug 2013 20:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg4onOjR-dKu for ; Wed, 21 Aug 2013 20:35:58 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 80AAF21F991E for ; Wed, 21 Aug 2013 20:35:58 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7M3Zs6X001588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Aug 2013 20:35:57 -0700 Message-ID: <52158701.3010802@dcrocker.net> Date: Wed, 21 Aug 2013 20:35:29 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ted Lemon References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 21 Aug 2013 20:35:58 -0700 (PDT) Cc: "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 03:36:04 -0000 On 8/21/2013 8:28 PM, Ted Lemon wrote: > On Aug 21, 2013, at 7:25 PM, Dave Crocker wrote: >> I suggest, instead, that Ted review the research that the wg >> already did and if he believes it inadequate he should explain how >> so, what is needed beyond it, and why it is essential to expend >> the added effort and time. > > I did review the research back when we had the discussion during the > last call (or possibly before), and I am fairly sure that the > research I am asking about did not in fact happen. But my point, > as I expressed to John earlier, was not to say that spfbis made a > mistake, but rather that if people want to _assert_ that spfbis made > a mistake, there's some obvious homework they should do before > making that assertion. On that I entirely agree. To wit, my point is not whether the specifics you are suggesting were done. There is an infinite number of possible things to research for an activity. We could go on for a long time inventing things to study. So the first requirement when finding an existing set of work deficient is to carefully explain what the deficiency is and how the deficiency affects might affect decisions that were based on it. If there is then a recommendation for additional research, it needs to be explained both in its nature and how it will remedy the deficiencies, in terms of having a better basis for decision-making. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Ted.Lemon@nominum.com Wed Aug 21 20:57:59 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 468A311E81BC for ; Wed, 21 Aug 2013 20:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 UhhEmZmJ9BFX for ; Wed, 21 Aug 2013 20:57:52 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD8811E811D for ; Wed, 21 Aug 2013 20:57:42 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUhWMNnq9ZrzSMpmbRhbVF1e7Q5f4MF1F@postini.com; Wed, 21 Aug 2013 20:57:42 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 11E671B81C7 for ; Wed, 21 Aug 2013 20:57:42 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0B601190043; Wed, 21 Aug 2013 20:57:42 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 21 Aug 2013 20:57:42 -0700 From: Ted Lemon To: "" Thread-Topic: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Thread-Index: AQHOnt8CSYFjulBN10Cqc2E5OcP8BZmhBxKAgAAB1ICAAAYyAA== Date: Thu, 22 Aug 2013 03:57:41 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> In-Reply-To: <52158701.3010802@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <672EDE79494B8046A794F074B0B853F8@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 03:57:59 -0000 On Aug 21, 2013, at 8:35 PM, Dave Crocker wrote: > If there is then a recommendation for additional research, it needs to > be explained both in its nature and how it will remedy the deficiencies, > in terms of having a better basis for decision-making. If you can figure out who is triggering most of the queries, and get a suff= iciency of them to install SPF RRtype RRs, then you can make the argument t= hat spfbis ought not to deprecate the SPF RRtype. If you can't, then your= argument is pretty empty. E.g., we haven't just been sitting on our hand= s waiting for someone to adopt IPv6=97we've been actively working to make i= t happen. But we didn't see that kind of effort with the SPF RRtype, either during th= e years it's been deployed prior to proposing that it be deprecated, nor in= response to the proposal that it be deprecated. Which suggests to me tha= t the people who don't want it to be deprecated aren't serious about it=97t= hey are trying to win an argument, not change the world. This is a perfectly understandable position, because in fact it just isn't = worth the kind of effort that would be needed. And my point is that the p= roponents of keeping the SPF RRtype, de facto, agree with this. I count m= yself in that number=97all things being equal, I would prefer that the SPF = RRtype _not_ be deprecated. But it's not worth my time to do what it woul= d take to get a different outcome, because it's just not that important, an= d we have better things to do. Anyone who disagrees with what I just said should evidence that by working = furiously to get SPF RRtype adoption going with at least the big three, not= by castigating spfbis for being pragmatic. From dhc@dcrocker.net Wed Aug 21 21:17: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 8077411E823F for ; Wed, 21 Aug 2013 21:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.24 X-Spam-Level: X-Spam-Status: No, score=-6.24 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 qAae-mSdBNWr for ; Wed, 21 Aug 2013 21:17:07 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6814C11E8237 for ; Wed, 21 Aug 2013 21:17:07 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7M4H3n1002320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Aug 2013 21:17:06 -0700 Message-ID: <521590A6.5010309@dcrocker.net> Date: Wed, 21 Aug 2013 21:16:38 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ted Lemon References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 21 Aug 2013 21:17:07 -0700 (PDT) Cc: "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 04:17:12 -0000 On 8/21/2013 8:57 PM, Ted Lemon wrote: > On Aug 21, 2013, at 8:35 PM, Dave Crocker wrote: >> If there is then a recommendation for additional research, it needs >> to be explained both in its nature and how it will remedy the >> deficiencies, in terms of having a better basis for >> decision-making. > > If you can figure out who is triggering most of the queries, and get > a sufficiency of them to install SPF RRtype RRs, then you can make > the argument that spfbis ought not to deprecate the SPF RRtype. If > you can't, then your argument is pretty empty. E.g., we haven't > just been sitting on our hands waiting for someone to adopt > IPv6—we've been actively working to make it happen. By 'you' I hope you don't mean me. The IETF does not promote adoption of its technologies. Folks in industry do that. However whether they do it or not does not affect the /criteria/ for success. Adoption is the measure, not whether the technology was well marketed. If the community did a poor job of marketing and got poor results, that is its own measure of the technology's worth. And the need for such marketing efforts varies. For example, there was essentially no marketing effort for MIME and yet it garnered very large market adoption very quickly. By reasonable measures, especially given the high levels of industry marketing effort so far, the very low adoption of of DNSSec and IPv6 actually warrant calling them failures (so far.) In any event, anti-abuse industry trade groups, like M3AAWG and APWG, have ongoing discussions about de jure and de facto standards, like DKIM and SPF. So there's been plenty of community review of the technologies by potential adopters. If they chose not to implement a port of a spec, it was an informed choice. > Anyone who disagrees with what I just said should evidence that by > working furiously to get SPF RRtype adoption going with at least the > big three, not by castigating spfbis for being pragmatic. They should have done that over the last seven years. Not now. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From marka@isc.org Thu Aug 22 00:04:24 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 45BE811E810D for ; Thu, 22 Aug 2013 00:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.568 X-Spam-Level: X-Spam-Status: No, score=-0.568 tagged_above=-999 required=5 tests=[AWL=-1.569, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_61=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6] 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 rX6J21c7H6yF for ; Thu, 22 Aug 2013 00:04:19 -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 C98F711E80FD for ; Thu, 22 Aug 2013 00:04:19 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 69A51C941E; Thu, 22 Aug 2013 07:04:05 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377155059; bh=WZHax3p/lTE/O6QAJ80Reb10DuUhJgIGCqG9Wv76rYc=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=jV66EGtE+DC1xXQ0lfsCZi0vSlrnot/F3cGHpHM3rUk6WbL1BpjvgGjhL2fQzzgQl lS/KCQC68v6/Ji21OH7t8D5nIaZeCDz2eKPUTMd11APcPjuclGctDxJJmOC4VeK0zu zWGet9MgTP32j+t3J9m71e+OmEAte9k70iHYPQWA= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 22 Aug 2013 07:04:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DE1AA1602E9; Thu, 22 Aug 2013 07:04:18 +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 405AA1602B4; Thu, 22 Aug 2013 07:04:18 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5A1AC38C7B54; Thu, 22 Aug 2013 17:03:59 +1000 (EST) To: Ted Lemon From: Mark Andrews References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> In-reply-to: Your message of "Thu, 22 Aug 2013 03:57:41 +0000." <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> Date: Thu, 22 Aug 2013 17:03:58 +1000 Message-Id: <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "" , "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 07:04:24 -0000 In message <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com>, T ed Lemon writes: > On Aug 21, 2013, at 8:35 PM, Dave Crocker wrote: > > If there is then a recommendation for additional research, it needs to > > be explained both in its nature and how it will remedy the deficiencies, > > in terms of having a better basis for decision-making. > > If you can figure out who is triggering most of the queries, and get a > sufficiency of them to install SPF RRtype RRs, then you can make the > argument that spfbis ought not to deprecate the SPF RRtype. If you > can't, then your argument is pretty empty. E.g., we haven't just been > sitting on our hands waiting for someone to adopt IPv6-we've been > actively working to make it happen. > > But we didn't see that kind of effort with the SPF RRtype, either during > the years it's been deployed prior to proposing that it be deprecated, > nor in response to the proposal that it be deprecated. Which suggests > to me that the people who don't want it to be deprecated aren't serious > about it-they are trying to win an argument, not change the world. Well there has been. Named complains about there not being both SPF and TXT records present. I've got code in the BIND review queue to answer SPF queries by looking at the TXT records for unsigned zones if there is no SPF record (see below). One can argue about whether to make the synthesised SPF records identifyable or not. The process is very similar to DNS64 synthesis. That aside why did there have to be until Microsoft fully supports SPF / unknown records? They are slowly moving in that direction. Once that happens would be the time to push the people to publish SPF records in ernest, until that happens you just need to deploy code that supports both. Additionally please point out the text in RFC 4408 that says there was a deadline to the migration. I saw RFC 4408 as testing whether the *contents* of the record worked or not. It was never as far as I was concerned a test of whether one could migrate to SPF or not quickly. If I had know that there would be a deadline imposed on migration then I would have added lots of other code to BIND to push the process along. > This is a perfectly understandable position, because in fact it just > isn't worth the kind of effort that would be needed. And my point is > that the proponents of keeping the SPF RRtype, de facto, agree with this. > I count myself in that number-all things being equal, I would prefer > that the SPF RRtype _not_ be deprecated. But it's not worth my time to > do what it would take to get a different outcome, because it's just not > that important, and we have better things to do. > > Anyone who disagrees with what I just said should evidence that by > working furiously to get SPF RRtype adoption going with at least the big > three, not by castigating spfbis for being pragmatic. > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis diff --git a/bin/named/include/named/query.h b/bin/named/include/named/query.h index a14d516..88fbdd6 100644 --- a/bin/named/include/named/query.h +++ b/bin/named/include/named/query.h @@ -67,6 +67,8 @@ struct ns_query { unsigned int dns64_aaaaoklen; unsigned int dns64_options; unsigned int dns64_ttl; + dns_rdataset_t * spf; + dns_rdataset_t * spfsig; }; #define NS_QUERYATTR_RECURSIONOK 0x0001 diff --git a/bin/named/include/named/server.h b/bin/named/include/named/server.h index b586f5c..50571a6 100644 --- a/bin/named/include/named/server.h +++ b/bin/named/include/named/server.h @@ -174,7 +174,9 @@ enum { dns_nsstatscounter_rpz_rewrites = 40, - dns_nsstatscounter_max = 41 + dns_nsstatscounter_spf = 41, + + dns_nsstatscounter_max = 42 }; void diff --git a/bin/named/query.c b/bin/named/query.c index 6ba5093..194b294 100644 --- a/bin/named/query.c +++ b/bin/named/query.c @@ -359,6 +359,11 @@ query_reset(ns_client_t *client, isc_boolean_t everything) { client->query.dns64_aaaaoklen = 0; } + if (client->query.spf != NULL) + query_putrdataset(client, &client->query.spf); + if (client->query.spfsig != NULL) + query_putrdataset(client, &client->query.spfsig); + query_freefreeversions(client, everything); for (dbuf = ISC_LIST_HEAD(client->query.namebufs); @@ -623,6 +628,8 @@ ns_query_init(ns_client_t *client) { client->query.dns64_sigaaaa = NULL; client->query.dns64_aaaaok = NULL; client->query.dns64_aaaaoklen = 0; + client->query.spf = NULL; + client->query.spfsig = NULL; query_reset(client, ISC_FALSE); result = query_newdbversion(client, 3); if (result != ISC_R_SUCCESS) { @@ -2182,6 +2189,170 @@ query_addrdataset(ns_client_t *client, dns_name_t *fname, CTRACE("query_addrdataset: done"); } +static isc_boolean_t +isspf(const dns_rdata_t *rdata) { + char buf[1024]; + const unsigned char *data = rdata->data; + unsigned int rdl = rdata->length, i = 0, tl, len; + + while (rdl > 0U) { + len = tl = *data; + ++data; + --rdl; + INSIST(tl <= rdl); + if (len > sizeof(buf) - i - 1) + len = sizeof(buf) - i - 1; + memcpy(buf + i, data, len); + i += len; + data += tl; + rdl -= tl; + } + + if (i < 6U) + return(ISC_FALSE); + + buf[i] = 0; + if (strncasecmp(buf, "v=spf1", 6) == 0 && + (buf[6] == 0 || buf[6] == ' ')) + return (ISC_TRUE); + return (ISC_FALSE); +} + +static isc_result_t +query_spf(ns_client_t *client, dns_name_t **namep, dns_rdataset_t *rdataset, + isc_buffer_t *dbuf) +{ + dns_name_t *name, *mname; + dns_rdata_t *spf_rdata; + dns_rdatalist_t *spf_rdatalist; + dns_rdataset_t *spf_rdataset; + dns_rdataset_t *mrdataset; + isc_buffer_t *buffer; + isc_region_t r; + isc_result_t result; + const char syn[] = " comment=synthesised"; + + CTRACE("query_spf"); + name = *namep; + mname = NULL; + mrdataset = NULL; + buffer = NULL; + spf_rdata = NULL; + spf_rdataset = NULL; + spf_rdatalist = NULL; + result = dns_message_findname(client->message, DNS_SECTION_ANSWER, + name, dns_rdatatype_spf, + rdataset->covers, + &mname, &mrdataset); + if (result == ISC_R_SUCCESS) { + /* + * We've already got an RRset of the given name and type. + * There's nothing else to do; + */ + CTRACE("query_spf: dns_message_findname succeeded: done"); + if (dbuf != NULL) + query_releasename(client, namep); + return (ISC_R_SUCCESS); + } else if (result == DNS_R_NXDOMAIN) { + /* + * The name doesn't exist. + */ + if (dbuf != NULL) + query_keepname(client, name, dbuf); + dns_message_addname(client->message, name, DNS_SECTION_ANSWER); + *namep = NULL; + mname = name; + } else { + RUNTIME_CHECK(result == DNS_R_NXRRSET); + if (dbuf != NULL) + query_releasename(client, namep); + } + + if (rdataset->trust != dns_trust_secure) + client->query.attributes &= ~NS_QUERYATTR_SECURE; + + result = dns_message_gettemprdataset(client->message, &spf_rdataset); + if (result != ISC_R_SUCCESS) + goto cleanup; + result = dns_message_gettemprdatalist(client->message, + &spf_rdatalist); + if (result != ISC_R_SUCCESS) + goto cleanup; + + dns_rdataset_init(spf_rdataset); + dns_rdatalist_init(spf_rdatalist); + spf_rdatalist->rdclass = dns_rdataclass_in; + spf_rdatalist->type = dns_rdatatype_spf; + spf_rdatalist->ttl = rdataset->ttl; + + for (result = dns_rdataset_first(rdataset); + result == ISC_R_SUCCESS; + result = dns_rdataset_next(rdataset)) { + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_rdataset_current(rdataset, &rdata); + if (!isspf(&rdata)) + continue; + result = isc_buffer_allocate(client->mctx, &buffer, + rdata.length + sizeof(syn)); + if (result != ISC_R_SUCCESS) + goto cleanup; + result = dns_message_gettemprdata(client->message, &spf_rdata); + if (result != ISC_R_SUCCESS) + goto cleanup; + dns_rdata_init(spf_rdata); + isc__buffer_putmem(buffer, rdata.data, rdata.length); + isc_buffer_putuint8(buffer, sizeof(syn) - 1); + isc_buffer_putstr(buffer, syn); + isc__buffer_usedregion(buffer, &r); + dns_rdata_fromregion(spf_rdata, dns_rdataclass_in, + dns_rdatatype_spf, &r); + ISC_LIST_APPEND(spf_rdatalist->rdata, spf_rdata, link); + spf_rdata = NULL; + dns_message_takebuffer(client->message, &buffer); + } + if (result != ISC_R_NOMORE) + goto cleanup; + + if (ISC_LIST_EMPTY(spf_rdatalist->rdata)) + goto cleanup; + + result = dns_rdatalist_tordataset(spf_rdatalist, spf_rdataset); + if (result != ISC_R_SUCCESS) + goto cleanup; + client->query.attributes |= NS_QUERYATTR_NOADDITIONAL; + spf_rdataset->trust = rdataset->trust; + query_addrdataset(client, mname, spf_rdataset); + spf_rdataset = NULL; + spf_rdatalist = NULL; + inc_stats(client, dns_nsstatscounter_spf); + result = ISC_R_SUCCESS; + + cleanup: + if (buffer != NULL) + isc_buffer_free(&buffer); + + if (spf_rdata != NULL) + dns_message_puttemprdata(client->message, &spf_rdata); + + if (spf_rdataset != NULL) + dns_message_puttemprdataset(client->message, &spf_rdataset); + + if (spf_rdatalist != NULL) { + for (spf_rdata = ISC_LIST_HEAD(spf_rdatalist->rdata); + spf_rdata != NULL; + spf_rdata = ISC_LIST_HEAD(spf_rdatalist->rdata)) + { + ISC_LIST_UNLINK(spf_rdatalist->rdata, + spf_rdata, link); + dns_message_puttemprdata(client->message, &spf_rdata); + } + dns_message_puttemprdatalist(client->message, &spf_rdatalist); + } + + CTRACE("query_spf: done"); + return (result); +} + static isc_result_t query_dns64(ns_client_t *client, dns_name_t **namep, dns_rdataset_t *rdataset, dns_rdataset_t *sigrdataset, isc_buffer_t *dbuf, @@ -5993,7 +6164,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) dns_rpz_st_t *rpz_st; isc_boolean_t resuming; int line = -1; - isc_boolean_t dns64_exclude, dns64; + isc_boolean_t dns64_exclude, dns64, spf; dns_clientinfomethods_t cm; dns_clientinfo_t ci; @@ -6026,6 +6197,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) resuming = ISC_FALSE; is_zone = ISC_FALSE; is_staticstub_zone = ISC_FALSE; + spf = ISC_FALSE; dns_clientinfomethods_init(&cm, ns_client_sourceip); dns_clientinfo_init(&ci, client); @@ -6879,10 +7051,37 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) iszone_nxrrset: INSIST(is_zone); + if (spf) { + /* + * Restore the answers from the previous SPF lookup. + */ + if (rdataset != NULL) + query_putrdataset(client, &rdataset); + if (sigrdataset != NULL) + query_putrdataset(client, &sigrdataset); + rdataset = client->query.spf; + sigrdataset = client->query.spfsig; + client->query.spf = NULL; + client->query.spfsig = NULL; + if (fname == NULL) { + dbuf = query_getnamebuf(client); + if (dbuf == NULL) { + QUERY_ERROR(DNS_R_SERVFAIL); + goto cleanup; + } + fname = query_newname(client, dbuf, &b); + if (fname == NULL) { + QUERY_ERROR(DNS_R_SERVFAIL); + goto cleanup; + } + } + dns_name_copy(client->query.qname, fname, NULL); + spf = ISC_FALSE; + } else #ifdef dns64_bis_return_excluded_addresses - if (dns64) + if (dns64) #else - if (dns64 && !dns64_exclude) + if (dns64 && !dns64_exclude) #endif { /* @@ -6947,6 +7146,34 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) } dns64 = ISC_TRUE; goto db_find; + } else if (result == DNS_R_NXRRSET && + client->message->rdclass == dns_rdataclass_in && + qtype == dns_rdatatype_spf && + !dns_db_issecure(db)) { + /* + * Look to see if there are TXT records for this + * name. + */ + INSIST(client->query.spf == NULL); + INSIST(client->query.spfsig == NULL); + client->query.spf = rdataset; + client->query.spfsig = sigrdataset; + query_releasename(client, &fname); + dns_db_detachnode(db, &node); + rdataset = NULL; + sigrdataset = NULL; + type = qtype = dns_rdatatype_txt; + rpz_st = client->query.rpz_st; + if (rpz_st != NULL) { + /* + * Arrange for RPZ rewriting of any A records. + */ + if ((rpz_st->state & DNS_RPZ_REWRITTEN) != 0) + is_zone = rpz_st->q.is_zone; + rpz_st_clear(client); + } + spf = ISC_TRUE; + goto db_find; } /* @@ -7762,7 +7989,18 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) dns_name_equal(client->query.qname, dns_rootname)) client->query.attributes &= ~NS_QUERYATTR_NOADDITIONAL; - if (dns64) { + if (spf) { + qtype = type = dns_rdatatype_spf; + result = query_spf(client, &fname, rdataset, dbuf); + dns_rdataset_disassociate(rdataset); + dns_message_puttemprdataset(client->message, &rdataset); + if (result == ISC_R_NOMORE) { + goto iszone_nxrrset; + } else if (result != ISC_R_SUCCESS) { + eresult = result; + goto cleanup; + } + } else if (dns64) { qtype = type = dns_rdatatype_aaaa; result = query_dns64(client, &fname, rdataset, sigrdataset, dbuf, diff --git a/bin/named/statschannel.c b/bin/named/statschannel.c index d3c74f9..8573f74 100644 --- a/bin/named/statschannel.c +++ b/bin/named/statschannel.c @@ -217,6 +217,7 @@ init_desc(void) { "RateSlipped"); SET_NSSTATDESC(rpz_rewrites, "response policy zone rewrites", "RPZRewrites"); + SET_NSSTATDESC(spf, "synthesised SPF responses", "SynSPF"); INSIST(i == dns_nsstatscounter_max); /* Initialize resolver statistics */ diff --git a/bin/tests/system/spf/clean.sh b/bin/tests/system/spf/clean.sh index 2e3a0ee..5810930 100644 --- a/bin/tests/system/spf/clean.sh +++ b/bin/tests/system/spf/clean.sh @@ -14,3 +14,4 @@ rm -f ns1/named.run rm -f ns1/named.memstats +rm -f dig.out.test* diff --git a/bin/tests/system/spf/ns1/spf.db b/bin/tests/system/spf/ns1/spf.db index ffa850a..7956e5f 100644 --- a/bin/tests/system/spf/ns1/spf.db +++ b/bin/tests/system/spf/ns1/spf.db @@ -14,8 +14,9 @@ @ 0 IN SOA . . 0 0 0 0 0 @ 0 IN NS . -@ 0 IN TXT "v=spf1 -all" -@ 0 IN SPF "v=spf1 -all" -x 0 IN TXT "v=spf1" -y 0 IN SPF "v=spf1" +@ 0 IN TXT "v=spf1 -all comment=txt" +@ 0 IN SPF "v=spf1 -all comment=spf" +x 0 IN TXT "v=spf1 comment=txt-only" +y 0 IN SPF "v=spf1 comment=spf-only" y 0 IN TXT "a non spf record" +z 0 IN TXT "a non spf record" diff --git a/bin/tests/system/spf/tests.sh b/bin/tests/system/spf/tests.sh index 6acd283..494a657 100644 --- a/bin/tests/system/spf/tests.sh +++ b/bin/tests/system/spf/tests.sh @@ -41,5 +41,44 @@ n=`expr $n + 1` if [ $ret != 0 ]; then echo "I:failed"; fi status=`expr $status + $ret` +echo "I:checking that the SPF record is returned if there is both SPF and v=spf1 TXT records present ($n)" +ret=0 +$DIG -p 5300 @10.53.0.1 -t spf -q spf > dig.out.test$n +grep "ANSWER: 1" dig.out.test$n > /dev/null || ret=1 +grep "comment=spf" dig.out.test$n > /dev/null || ret=1 +grep "status: NOERROR" dig.out.test$n > /dev/null || ret=1 +n=`expr $n + 1` +if [ $ret != 0 ]; then echo "I:failed"; fi +status=`expr $status + $ret` + +echo "I:checking that we synthesis a SPF record if there is a v=spf1 TXT record ($n)" +ret=0 +$DIG -p 5300 @10.53.0.1 -t spf -q x.spf > dig.out.test$n +grep "ANSWER: 1" dig.out.test$n > /dev/null || ret=1 +grep "comment=txt-only" dig.out.test$n > /dev/null || ret=1 +grep "status: NOERROR" dig.out.test$n > /dev/null || ret=1 +n=`expr $n + 1` +if [ $ret != 0 ]; then echo "I:failed"; fi +status=`expr $status + $ret` + +echo "I:checking that a lone SPF record at a node is returned ($n)" +ret=0 +$DIG -p 5300 @10.53.0.1 -t spf -q y.spf > dig.out.test$n +grep "ANSWER: 1" dig.out.test$n > /dev/null || ret=1 +grep "comment=spf-only" dig.out.test$n > /dev/null || ret=1 +grep "status: NOERROR" dig.out.test$n > /dev/null || ret=1 +n=`expr $n + 1` +if [ $ret != 0 ]; then echo "I:failed"; fi +status=`expr $status + $ret` + +echo "I:checking that a SPF record is not synthesised if there are no v=spf1 TXT records ($n)" +ret=0 +$DIG -p 5300 @10.53.0.1 -t spf -q z.spf > dig.out.test$n +grep "ANSWER: 0" dig.out.test$n > /dev/null || ret=1 +grep "status: NOERROR" dig.out.test$n > /dev/null || ret=1 +n=`expr $n + 1` +if [ $ret != 0 ]; then echo "I:failed"; fi +status=`expr $status + $ret` + echo "I:exit status: $status" exit $status -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ted.Lemon@nominum.com Thu Aug 22 08:03: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 3325C11E80D5 for ; Thu, 22 Aug 2013 08:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 jdNAc23P1tUQ for ; Thu, 22 Aug 2013 08:03:05 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5E52921F9D99 for ; Thu, 22 Aug 2013 08:03:05 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUhYoJxjGp6m8l8hHPCElHc/OYS9iLYkQ@postini.com; Thu, 22 Aug 2013 08:03:05 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CEEE51B82B6 for ; Thu, 22 Aug 2013 08:03:03 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 83B14190071; Thu, 22 Aug 2013 08:03:02 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 08:03:02 -0700 From: Ted Lemon To: Mark Andrews Thread-Topic: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Thread-Index: AQHOnt8CSYFjulBN10Cqc2E5OcP8BZmhBxKAgAAB1ICAAAYyAP//vtJngAD7FQA= Date: Thu, 22 Aug 2013 15:03:01 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775261957@mbx-01.win.nominum.com> References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> In-Reply-To: <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <2BA1C87BB12E8D41A5CFE537EC3AD0EF@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 15:03:12 -0000 On Aug 22, 2013, at 12:03 AM, Mark Andrews wrote: > Well there has been. Named complains about there not being both > SPF and TXT records present. I mean advocacy, not a warning message from a daemon that nobody with any p= ower to do anything sees. While Dave points out that the IETF doesn't do = advocacy, IETF participants certainly do as part of their work. Nobody ha= s done any advocacy on this point. If you care so deeply about it, why ha= ven't you? Or is it the case that you have, and it hasn't worked? From tim@eudaemon.net Thu Aug 22 08:16:22 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 9650711E820B for ; Thu, 22 Aug 2013 08:16:22 -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 4yQWTmhnr3Ez for ; Thu, 22 Aug 2013 08:16:16 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 4041611E821A for ; Thu, 22 Aug 2013 08:16:12 -0700 (PDT) Received: from [10.0.1.8] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 0B619CB46; Thu, 22 Aug 2013 11:16:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Draegen In-Reply-To: Date: Thu, 22 Aug 2013 11:16:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <261D62C8-3B98-4643-83FB-9ADE3D5F1901@eudaemon.net> References: <20130822004035.91384.qmail@joyce.lan> <5215661D.507@Commerco.Net> To: "John R Levine" X-Mailer: Apple Mail (2.1508) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] not a migration strategy 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: Thu, 22 Aug 2013 15:16:22 -0000 On Aug 21, 2013, at 9:20 PM, "John R Levine" wrote: >>> Without, but the problems had nothing to do with the contents of the >>> type 99 records. >=20 >> Actually, I think some of the problems did have something to do with = the contents of the SPF (type 99) RRs insofar as, if memory serves, = there were concerns posted about the synchronization issue when both = were supported by a DNS publisher (e.g., which do you choose to believe = if they are different, etc). >=20 > In my case, it was various things in other places doing unfortunate = things with type99 queries and/or replies. It was a while ago, I don't = remember the details. I've already brought up my own experience long ago, but since we're = rehashing this.. While implementing SPF checking for a high volume email server, it = turned out everything worked nicely in a lab, but in field testing, = there were enough DNS servers out there that just did nothing with = queries of type SPF. That is, timeouts had to be relied upon to supply = a response. Even with a huge pool of connections available to service SPF lookup = requests, under volume eventually the entire pool would find itself in = some state of waiting for a reply to a type 99 lookup. This is after = caching responses, caching if a DNS server would be known to stall, and = blocking incoming connections at an IP-reputation level. Just to roll SPF checking out, the fix was to make type 99 lookups = optional and off by default. Otherwise I would had to implement a bunch = of hacks... all of which added up to "why bother, the world is using = TXT records anyway". =3D- Tim PS. I've written this before, but I think a type-specific DNS record for = text-based SPF records is wrong. If anything, migration to prefixing = DNS labels using "_spf." is superior. But this better approach is out = of scope and we're all OK with this. From sm@elandsys.com Thu Aug 22 08:53:55 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 215D611E821B for ; Thu, 22 Aug 2013 08:53:55 -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.060, 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 awaLleJjYETj for ; Thu, 22 Aug 2013 08:53:54 -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 4810D11E820C for ; Thu, 22 Aug 2013 08:53:53 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.102]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7MFrcJE002001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 08:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377186830; bh=QFV2ocXBC4y7uqI1VCh957Av4vu+IZ1AUu2oRdr191I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IT+OUK7ccuI/9teiyXgYJ6qJ/S5k4XcXzXRdEa0VItUD8oJ0KWXXrYIcZMJaRz6r0 mx1VyF16Fw49YE20GlLwN9LXkFZ+ySzkgPGeW4QKB+3NqfnyofqA1GEi7VArIHHLOR Q4CO56DoPzT/smmHwTUub60av/OvaqfXzGq+DLaM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377186830; i=@elandsys.com; bh=QFV2ocXBC4y7uqI1VCh957Av4vu+IZ1AUu2oRdr191I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=d3XDgrbHk/jDvAvkuWk74zUNtJEuplQXdLJ+WhTCWyjsTFDBjQbTuLJmGcYqsct1u pirKxilL7vDsbJn3nJ76ozqOZgdFXseu17IqOkiNn0PndJ99Cs8zlP5NdBTBViAs6L FqvqDfBEygNPXAJUDehDMCKffm78AFjtw3b3zqSY= Message-Id: <6.2.5.6.2.20130822072146.0b7e6940@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 Aug 2013 07:37:22 -0700 To: Tim Draegen From: S Moonesamy In-Reply-To: References: <19129243.7z7OTnRij9@scott-latitude-e6320> <20130821142521.89430.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy 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: Thu, 22 Aug 2013 15:53:55 -0000 Hi Tim, At 08:19 21-08-2013, Tim Draegen wrote: >If I had a magic wand, I'd wave it and change where SPF is >discovered to be of the form "_spf.example.org", with TXT records >serving out text spf records. Problem solved! The SPFBIS WG did not discuss the above alternative. I will have to discuss with Andrew Sullivan to see whether it falls within the scope of the charter or not. I suggest discussing the above alternative. Regards, S. Moonesamy (as document shepherd) From tim@eudaemon.net Thu Aug 22 09:06: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 3E72B11E819A for ; Thu, 22 Aug 2013 09:06: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=[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 jlUM1lL1fmrB for ; Thu, 22 Aug 2013 09:06:05 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD6411E80ED for ; Thu, 22 Aug 2013 09:06:05 -0700 (PDT) Received: from [10.0.1.8] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 0FFB9CB46; Thu, 22 Aug 2013 12:06:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Draegen In-Reply-To: <6.2.5.6.2.20130822072146.0b7e6940@resistor.net> Date: Thu, 22 Aug 2013 12:06:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <19129243.7z7OTnRij9@scott-latitude-e6320> <20130821142521.89430.qmail@joyce.lan> <6.2.5.6.2.20130822072146.0b7e6940@resistor.net> To: S Moonesamy X-Mailer: Apple Mail (2.1508) Cc: spfbis@ietf.org Subject: Re: [spfbis] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy 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: Thu, 22 Aug 2013 16:06:11 -0000 On Aug 22, 2013, at 10:37 AM, S Moonesamy wrote: > Hi Tim, > At 08:19 21-08-2013, Tim Draegen wrote: >> If I had a magic wand, I'd wave it and change where SPF is discovered = to be of the form "_spf.example.org", with TXT records serving out text = spf records. Problem solved! >=20 > The SPFBIS WG did not discuss the above alternative. I will have to = discuss with Andrew Sullivan to see whether it falls within the scope of = the charter or not. >=20 > I suggest discussing the above alternative. I don't believe the above falls in scope. =46rom a clean-room = development perspective (starting from scratch), I'd prefer using = "_spf." prefix when it comes to "How to discover SPF data". Given the scope of the charter and what already exists in terms of How = to discover SPF data: 1. SPF TXT 2. SPF type-99 It's clear to me that #1 is the way to go, for all reasons already = argued. I guess my point is, even if the charter allowed us explore, from = scratch, How to discover SPF data.. going the "SPF type-99" route = wouldn't be on my list of viable schemes. HTH, =3D- Tim From johnl@iecc.com Thu Aug 22 10:10:20 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 D52AB11E8126 for ; Thu, 22 Aug 2013 10:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.691 X-Spam-Level: X-Spam-Status: No, score=-102.691 tagged_above=-999 required=5 tests=[AWL=-0.092, 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 hSSVqAa2XN5g for ; Thu, 22 Aug 2013 10:10:15 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9AE11E81F5 for ; Thu, 22 Aug 2013 10:10:15 -0700 (PDT) Received: (qmail 1640 invoked from network); 22 Aug 2013 17:10:13 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Aug 2013 17:10:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521645f5.xn--9vv.k1308; i=johnl@user.iecc.com; bh=H7DpR6O3uE+a4+dsaeuUvuZr/zeBj5ncICTnsNzbZJQ=; b=MGysUG456TkjCiC3P17qvCMFkWouvCK8okGxyQC76giMZg8hjidLQ2n9A9sWXIw+tSWnvkVYlPjaCyfFFxukB7F7YwPpE4TJMqJnxIgjJCcbLa7DRlxX6vt0N9MQOlDOCEsrIL61ZsNJTtWYtBG2zm3dHsDCw2NtJaCjkb1IAXI4VgHwSj7pccU5CZlIKnqiTKF7NVqkViodKbZ4zM3nzj2oaKsxGU+gRmrOPSvy4hGXBzIwJP6+jJy5uHPUVEJw DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521645f5.xn--9vv.k1308; olt=johnl@user.iecc.com; bh=H7DpR6O3uE+a4+dsaeuUvuZr/zeBj5ncICTnsNzbZJQ=; b=l00BYEkOfDdGBQEXSYRFWbZXoSoN2ZeHquBQ6hGnvKs06IxMK5lMWWoYA34sOTuAwffAem8zi7mcPer0Oo2cviSO5lOMN9BU4oE//FGC+PWoIZboG+Pl/xlEObVg/sao6eJPr7H7JskCUdQE55wvQ8KRIqOas58wiYXVIOSG4Azyps4Z3Nz1HUwxn0IiFdlOjPdct/vlrQDCfDo1700Yr55Jo/XB48gwwVkKm5J2YPrXrZiImOUoqYzEDZXS+KZu Date: 22 Aug 2013 17:09:51 -0000 Message-ID: <20130822170951.5075.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20130822072146.0b7e6940@resistor.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: sm+ietf@elandsys.com Subject: Re: [spfbis] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy 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: Thu, 22 Aug 2013 17:10:20 -0000 >>If I had a magic wand, I'd wave it and change where SPF is >>discovered to be of the form "_spf.example.org", with TXT records >>serving out text spf records. Problem solved! > >The SPFBIS WG did not discuss the above alternative. I will have to >discuss with Andrew Sullivan to see whether it falls within the scope >of the charter or not. I'm not Andrew, but it clearly does not. It's a change that is incompatible both with the existing spec and with current practice. Once again, if we were doing this from scratch, it wouldn't be an unreasonable idea, but we aren't, so it's not. R's, John From hsantos@isdg.net Thu Aug 22 10:12:27 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 F299511E8200 for ; Thu, 22 Aug 2013 10:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.763 X-Spam-Level: X-Spam-Status: No, score=-101.763 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, SARE_LWSHORTT=1.24, 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 CFDevIjyv-tk for ; Thu, 22 Aug 2013 10:12:21 -0700 (PDT) Received: from ntbbs.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9162311E8126 for ; Thu, 22 Aug 2013 10:12:21 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1239; t=1377191535; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=KtFd8v4k9jPzTmQUiZSp4QapUmY=; b=Y0SeVlRI2Me1isL0lHK6 tD4NaDIhUloBKNLaaXp+hbFOyf3LuOLNB8BLmB0MuW4Drt/YB0burWnV8nG0UuhG uItXzib7Q+clZoEK68TERrc8x5pfZU/aC+7K1LBnue8aVHAIXu2YY0uhjSRXh8fk dxItm4Xi768NQB0XiVqthBo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 22 Aug 2013 13:12:15 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3654049624.1759.3232; Thu, 22 Aug 2013 13:12:14 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1239; t=1377191222; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0GTn0l3 uaWk9noykXeSMlZTKreOW59lRk/CWpZROgTo=; b=Gr24m/rlVfltTyEjvWkMScT m3VSftAAGAFTiFwEPEcRCl+B1tJVeNTY+ZFaAL7bTYhIP4ImOjRjhrQDe4mjG37W 6AGy04QACh/PRoLDeMOpmOEy9yEE1Iz4Itf4bo63GcN/CqQa8GRRJ/GCGcoStvn0 iVUG9t9VUvE5NfvcqzSI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 22 Aug 2013 13:07:02 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3100469908.9.7804; Thu, 22 Aug 2013 13:07:01 -0400 Message-ID: <52164664.2030807@isdg.net> Date: Thu, 22 Aug 2013 13:12:04 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <19129243.7z7OTnRij9@scott-latitude-e6320> <20130821142521.89430.qmail@joyce.lan> <6.2.5.6.2.20130822072146.0b7e6940@resistor.net> In-Reply-To: <6.2.5.6.2.20130822072146.0b7e6940@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Tim Draegen Subject: Re: [spfbis] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy 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: Thu, 22 Aug 2013 17:12:27 -0000 S Moonesamy wrote: > Hi Tim, > At 08:19 21-08-2013, Tim Draegen wrote: >> If I had a magic wand, I'd wave it and change where SPF is discovered >> to be of the form "_spf.example.org", with TXT records serving out >> text spf records. Problem solved! > > The SPFBIS WG did not discuss the above alternative. I will have to > discuss with Andrew Sullivan to see whether it falls within the scope of > the charter or not. > > I suggest discussing the above alternative. > > Regards, > S. Moonesamy (as document shepherd) This was discussed as I recall and/or it was obvious in the overhead concerns, or the similar overhead was raised in the floods of list discussions. Idea: Query TXT at _SPF.example.com Fallback Query TXT at example.com It would be promoting a migration path with an ideal expected short term high redundancy overhead in failures. When you consider that some of the domains organize their SPF network with includes and redirects, we are talking about even more TXT calls. I prefer a minimal amount, like one call. Maybe what is possibly needed is a yet another TXT based discovery call to tell the world where all these TXT-based DNS application records are located. -- HLS From spf2@kitterman.com Thu Aug 22 11:42: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 8D66711E81C5 for ; Thu, 22 Aug 2013 11:42:23 -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 gwTC6M86Cqtk for ; Thu, 22 Aug 2013 11:42:19 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA8211E812D for ; Thu, 22 Aug 2013 11:42:19 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id B3AD7D04085; Thu, 22 Aug 2013 14:42:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377196938; bh=4Sccn0yevluXrMzbISzPrlZOBHG8HqNBUyQpjtFnB5w=; h=In-Reply-To:References:Subject:From:Date:To:From; b=RAs9yvJOW53Om5920CiO1O+TjYM6AulXMzEJif7pyizsVIyN5bSRwh003hZiQUAfA bznhuFUK32JfIaCZhqg9UHAv4hDH43pUS59yNkmu31DW5GoU79gpcJzbNeHghWoh0b EcLmfGhAeMD99wRxJA8dqosnHLuwewagEbTuogSA= Received: from [IPV6:2600:1003:b115:a541:eea2:2b78:d982:b07f] (unknown [IPv6:2600:1003:b115:a541:eea2:2b78:d982:b07f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CFB95D0405B; Thu, 22 Aug 2013 14:42:17 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775261957@mbx-01.win.nominum.com> References: <20130819150521.GB21088@besserwisser.org> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B630775261957@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 22 Aug 2013 14:42:19 -0400 To: "" Message-ID: <9668323b-9239-4b7a-a0ce-b6d6819898a9@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 18:42:23 -0000 Ted Lemon wrote: >On Aug 22, 2013, at 12:03 AM, Mark Andrews wrote: >> Well there has been. Named complains about there not being both >> SPF and TXT records present. > >I mean advocacy, not a warning message from a daemon that nobody with >any power to do anything sees. While Dave points out that the IETF >doesn't do advocacy, IETF participants certainly do as part of their >work. Nobody has done any advocacy on this point. If you care so >deeply about it, why haven't you? Or is it the case that you have, >and it hasn't worked? It's not correct that nobody has done any advocacy. The major FOSS SPF libraries all support type SPF and have done so since shortly after it was allocated (or in the case of Mail::SPF it's initial release). This was all done as free time work. No one was paid for it. I have run what I have reason to believe is the most popular web based SPF validator. Since very shortly after the type was allocated it has checked for it and included in its results. You've got no idea how many e-mails I get from people that are confused about it. I also did this in my 'spare' time. You may have noted FAQ entries on openspf.org presenting type SPF as the right thing to do. I wrote that. We tried. It didn't work out for a variety of reasons that I won't rehash, but it's not like we didn't try. What I didn't do was engage in intellectually dishonest advocacy to push people to favor type SPF over TXT knowing it would work less well for them. Scott K From spf2@kitterman.com Thu Aug 22 11:48:04 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 E081B11E80F8 for ; Thu, 22 Aug 2013 11:48: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 wAvbhf05BOn1 for ; Thu, 22 Aug 2013 11:48:04 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 293DD21F9D53 for ; Thu, 22 Aug 2013 11:48:03 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 56E93D04085; Thu, 22 Aug 2013 14:48:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377197282; bh=tTDFiEUIMXgkIdRHCp5gPHr0nrrPv5E3d/3haRhNhA8=; h=In-Reply-To:References:Subject:From:Date:To:From; b=O2TdQmCn7xM3GBnTErKTh0HOvoOU9BM6bzSzinmdyxjM9twdPuz+Un/p/89jskHeJ +pcfNJ/81aMpfKxDuzzEd3/UCKMoBljiV6DMNgyQvDH+PBH37UHeLTbM6zF020K1XZ d59cPcuNZXOp8t5rs73sc+hF6ZvyfC3Bgfral6Jw= Received: from [IPV6:2600:1003:b115:a541:eea2:2b78:d982:b07f] (unknown [IPv6:2600:1003:b115:a541:eea2:2b78:d982:b07f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CD564D0405B; Thu, 22 Aug 2013 14:48:01 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130822072146.0b7e6940@resistor.net> References: <19129243.7z7OTnRij9@scott-latitude-e6320> <20130821142521.89430.qmail@joyce.lan> <6.2.5.6.2.20130822072146.0b7e6940@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 22 Aug 2013 14:48:04 -0400 To: spfbis@ietf.org Message-ID: <35d41832-780f-4699-b9d3-15cd8f5b0cda@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy 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: Thu, 22 Aug 2013 18:48:05 -0000 S Moonesamy wrote: >Hi Tim, >At 08:19 21-08-2013, Tim Draegen wrote: >>If I had a magic wand, I'd wave it and change where SPF is >>discovered to be of the form "_spf.example.org", with TXT records >>serving out text spf records. Problem solved! > >The SPFBIS WG did not discuss the above alternative. I will have to >discuss with Andrew Sullivan to see whether it falls within the scope >of the charter or not. > >I suggest discussing the above alternative. We did discuss it both when RFC 4408 was written and in SPFbis. It wasn't done for 4408 because, at the time, it was felt it would be a barrier to deployment since most provisioning systems didn't allow domain names with an underscore. Now you can't mandate it without breaking backward compatibility. Scott K From hsantos@isdg.net Thu Aug 22 12:20: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 CD6A421F9EAF for ; Thu, 22 Aug 2013 12:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.302 X-Spam-Level: X-Spam-Status: No, score=-102.302 tagged_above=-999 required=5 tests=[AWL=0.297, 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 7nMxEm85MHDZ for ; Thu, 22 Aug 2013 12:20:13 -0700 (PDT) Received: from secure.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1E52B11E8112 for ; Thu, 22 Aug 2013 12:20:12 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2882; t=1377199210; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=dS/9+pgAbbUpmA425TByWhTvlrQ=; b=D0QXERkS+o/7A7QPuX0x 4w+Ku08FKpmuc/+bNqf9tMIXYCA+o6Gqg0fvYZsCEVxSrGqlq8qDfMaxJV9v1srv b0yHxQhcX6zsgzAyof8SHwdPhfVr6xVECBhYVdzdKEUYKUhzuNIWzFQiN/dqVrjz o24TDheY78SrnamdZw8hknM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 22 Aug 2013 15:20:10 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3661725014.1759.2364; Thu, 22 Aug 2013 15:20:09 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2882; t=1377198899; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=EWjLvqS fu9PYt8yKKVrSZbIlRDQvJ/FaBL4VN6z4zk8=; b=UPgE5l439JmCF6EiZCw5T3l 0uC19V6j4y89z33x+AW7FEgLHOP/G/AA4SezydJiVJ0vl/w7AiubzrWfM5FDSY6T EueGF0KrYXowsdERaTvdklm0nJmIbVe4kK0mtSJXrJSNGZ+StfTj62LED+EXMxUB kSBtMmVnRkHTl3h6JSeE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 22 Aug 2013 15:14:59 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3108146924.9.1136; Thu, 22 Aug 2013 15:14:58 -0400 Message-ID: <52166462.4050205@isdg.net> Date: Thu, 22 Aug 2013 15:20:02 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <20130819150521.GB21088@besserwisser.org> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B630775261957@mbx-01.win.nominum.com> <9668323b-9239-4b7a-a0ce-b6d6819898a9@email.android.com> In-Reply-To: <9668323b-9239-4b7a-a0ce-b6d6819898a9@email.android.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 19:20:17 -0000 Dishonest? Ouch! I don't think I was dishonest in my engineering agreements with others that new RR types should be used and there was really no reason to remove it first and make it a burden on the rest of the community to add it back. I won't call this dishonest, but the burden should of been on you to remove first by asking the entire interfacing community first, not just with WG. This was highly predictable, yet the WG went on to remove it without consulting the related IETF groups. I understand that is the current procedure, but this decision does not provide the design confidence that new RR types are still valid to consider. If you believe they still are, then in my opinion, the SPFBIS should not had removed it. And lets just say that after all these discussions, someone writes a serious and accepted RFC addressed at the DNS industry, Levine is write a I-D for unnamed types, etc, and we begin to get big traction and finally the changes to the infrastructure begin, SPFBIS will be without its SPF type99 and that would be unfortunate. I don't think that is dishonest. -- HLS Scott Kitterman wrote: > > Ted Lemon wrote: >> On Aug 22, 2013, at 12:03 AM, Mark Andrews wrote: >>> Well there has been. Named complains about there not being both >>> SPF and TXT records present. >> I mean advocacy, not a warning message from a daemon that nobody with >> any power to do anything sees. While Dave points out that the IETF >> doesn't do advocacy, IETF participants certainly do as part of their >> work. Nobody has done any advocacy on this point. If you care so >> deeply about it, why haven't you? Or is it the case that you have, >> and it hasn't worked? > > It's not correct that nobody has done any advocacy. > > The major FOSS SPF libraries all support type SPF and have done so since shortly after it was allocated (or in the case of Mail::SPF it's initial release). This was all done as free time work. No one was paid for it. > > I have run what I have reason to believe is the most popular web based SPF validator. Since very shortly after the type was allocated it has checked for it and included in its results. You've got no idea how many e-mails I get from people that are confused about it. I also did this in my 'spare' time. > > You may have noted FAQ entries on openspf.org presenting type SPF as the right thing to do. I wrote that. > > We tried. It didn't work out for a variety of reasons that I won't rehash, but it's not like we didn't try. What I didn't do was engage in intellectually dishonest advocacy to push people to favor type SPF over TXT knowing it would work less well for them. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From angel@16bits.net Thu Aug 22 12:29:01 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 4092311E821C for ; Thu, 22 Aug 2013 12:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 8I92ByLAC6x7 for ; Thu, 22 Aug 2013 12:28:56 -0700 (PDT) Received: from mailer.hiddenmail.net (mailer.hiddenmail.net [199.195.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id D2B5811E81C5 for ; Thu, 22 Aug 2013 12:28:48 -0700 (PDT) Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from ) id 1VCEJt-0004mG-1V for spfbis@ietf.org; Wed, 21 Aug 2013 21:44:11 +0200 Message-ID: <1377114552.2465.8.camel@localhost.localdomain> From: =?ISO-8859-1?Q?=C1ngel?= To: spfbis@ietf.org Date: Wed, 21 Aug 2013 21:49:12 +0200 In-Reply-To: <20130821145455.26DE938BF1C5@drugs.dv.isc.org> References: <20130821142521.89430.qmail@joyce.lan> <20130821145455.26DE938BF1C5@drugs.dv.isc.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.8.5 Mime-Version: 1.0 Subject: Re: [spfbis] Last call of draft-ietf-spfbis-4408bis-19 - migration strategy 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: Thu, 22 Aug 2013 19:29:01 -0000 I came late to the discussion, and thinking it closed wasn't going to reopen it, but since it has sprung again, I am adding my views on the subject. I have read the =C2=ABObsoleting SPF RRTYPE=C2=BB thread (starting Apr 23) = ands its follow-ups (when obvious from its subject) as well as the =C2=ABIssue #= 9=C2=BB threads of February 2012 (where contrary to what I expected from later mails, I don't see consensus, btw. The thread finished with Feb and then continued on June 30/Jul 01 just to word type 99 removal, with no objections). IMHO the solution should be pushed into the dns software. * A spf implementation MUST perform one query for SPF RR to a resolver which complies with the below algorithm. * A dns resolver when receiving a query for SPF (99) recordset MUST: a) Perform the usual resolution process with that record type. If this yields a positive answer, return that. Skip the other steps. b) If the answer was a timeout/No data/Not implemented [also=20 include SERVFAIL?], retry the query changing the type from SPF (99)=20 to TXT (16). c) Filter out all the answers not beginning with v=3Dspf1 d) If there's any answer left, return that else return the spf null record. * A dns authoritative server responsible for TXT and SPF records that when loading its zone, finds a TXT record beginning with=20 v=3Dspf1 and there's no SPF record for that domain MUST store it=20 with type SPF as it is a legacy record really intended for SPF=20 usage (it is implementation-defined if the record is also published with TXT type or not). It is recommended to emit a diagnostic when=20 fixing the zone. * A dns authoritative server that is asked for a SPF record but=20 doesn't have one such record for that domain MUST return the spf=20 null record, using as ttl the default negative-ttl for the domain. The spf null record is defined as a record with TYPE SPF and content "v=3Dspf0". Its semantic - The bigger TXT deployment base and provisioning tools not supporting SPF arguments are fixed on next dns server upgrade. - The resolver update means that the update of an intermediate caching=20 server already improves the situation. - An old authoritative server forcing the use of legacy TXT records will look nicely to the internet as soon as you put a modern dns cache in front of it. - SPF records inside TXT on old dns servers continue working. The only problem remaining is the passthru server/firewall rejecting/dropping the unknown RRTYPE (aka. rfc 3597 uncompliance). - If you are checking SPF records, you must have a resolver supporting SPF with TXT fallback (which may be embedded with the libspf, or needed to install separatedly if your normal resolver is one of the buggy ones) and a clean network which isn't filtering out spf queries (else, talk with your network admin). - If you are publishing type 99 records but your outbound dns server / firewall strips then, you need to have that fixed, it should be simple to discover that you have problems when you use a spf validator on your domain (because you are testing it, right?). Yes, this is still a kludge, but a smaller one than doubling the dns requests and storage, and moving in the right direction. (However, the resolver changes might be skipped) Unlike TXT, which is a shared space, the spf record allows for more tweaks, and adding special code for it is not that different than if eg. spfbis mandated that spf records generate additional section processing.=20 Regards From spf2@kitterman.com Thu Aug 22 13:22:10 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 DC62011E820C for ; Thu, 22 Aug 2013 13:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, GB_ABOUTYOU=0.5] 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 fqM2ElT4-Dxa for ; Thu, 22 Aug 2013 13:22:09 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9B011E8149 for ; Thu, 22 Aug 2013 13:22:05 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 8C9CED04085; Thu, 22 Aug 2013 16:22:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377202923; bh=VrEU26ksJ1R37PhO7DXqdQQyLOC2A4NgALf7xbmmngU=; h=In-Reply-To:References:Subject:From:Date:To:From; b=HrhbToBkToZfKExfxeGtLLLT3/a/GSXOMFvC6YxQjTRLI5OwMf6jojshXXIllkNWM TISU6VooyE3+EAJm485csMauJALEru317ddFqHp4MfKU6xnJpaEJogKBimb8DpoyQK 4x9iU7eOzo4a0IYhbI9YvaenhCE4A2YIjkT9PmsU= Received: from [IPV6:2600:1003:b115:a541:eea2:2b78:d982:b07f] (unknown [IPv6:2600:1003:b115:a541:eea2:2b78:d982:b07f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 0B2E6D0405B; Thu, 22 Aug 2013 16:22:02 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <52166462.4050205@isdg.net> References: <20130819150521.GB21088@besserwisser.org> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B630775261957@mbx-01.win.nominum.com> <9668323b-9239-4b7a-a0ce-b6d6819898a9@email.android.com> <52166462.4050205@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 22 Aug 2013 16:22:05 -0400 To: "" Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 20:22:10 -0000 Hector, Not everything is about you. Scott K Hector Santos wrote: >Dishonest? Ouch! > >I don't think I was dishonest in my engineering agreements with others >that new RR types should be used and there was really no reason to >remove it first and make it a burden on the rest of the community to >add it back. > >I won't call this dishonest, but the burden should of been on you to >remove first by asking the entire interfacing community first, not >just with WG. This was highly predictable, yet the WG went on to >remove it without consulting the related IETF groups. I understand >that is the current procedure, but this decision does not provide the >design confidence that new RR types are still valid to consider. If >you believe they still are, then in my opinion, the SPFBIS should not >had removed it. > >And lets just say that after all these discussions, someone writes a >serious and accepted RFC addressed at the DNS industry, Levine is >write a I-D for unnamed types, etc, and we begin to get big traction >and finally the changes to the infrastructure begin, SPFBIS will be >without its SPF type99 and that would be unfortunate. > >I don't think that is dishonest. > >-- >HLS > >Scott Kitterman wrote: >> >> Ted Lemon wrote: >>> On Aug 22, 2013, at 12:03 AM, Mark Andrews wrote: >>>> Well there has been. Named complains about there not being both >>>> SPF and TXT records present. >>> I mean advocacy, not a warning message from a daemon that nobody >with >>> any power to do anything sees. While Dave points out that the IETF >>> doesn't do advocacy, IETF participants certainly do as part of their >>> work. Nobody has done any advocacy on this point. If you care so >>> deeply about it, why haven't you? Or is it the case that you >have, >>> and it hasn't worked? >> >> It's not correct that nobody has done any advocacy. >> >> The major FOSS SPF libraries all support type SPF and have done so >since shortly after it was allocated (or in the case of Mail::SPF it's >initial release). This was all done as free time work. No one was >paid for it. >> >> I have run what I have reason to believe is the most popular web >based SPF validator. Since very shortly after the type was allocated >it has checked for it and included in its results. You've got no idea >how many e-mails I get from people that are confused about it. I also >did this in my 'spare' time. >> >> You may have noted FAQ entries on openspf.org presenting type SPF as >the right thing to do. I wrote that. >> >> We tried. It didn't work out for a variety of reasons that I won't >rehash, but it's not like we didn't try. What I didn't do was engage in >intellectually dishonest advocacy to push people to favor type SPF over >TXT knowing it would work less well for them. >> >> Scott K >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> >> > > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From marka@isc.org Thu Aug 22 13:23:38 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 9E78D21F9F23 for ; Thu, 22 Aug 2013 13:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 giSlhPe75bCU for ; Thu, 22 Aug 2013 13:23:33 -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 C935621F9EDB for ; Thu, 22 Aug 2013 13:23:33 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 0F597C9422; Thu, 22 Aug 2013 20:23:21 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377203013; bh=PlKXTFnpKqzgWXUbQ+YviSsI2UUA8v6E86tPj0WrNKw=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=e7gRiaUl6NtgczjsRDezziRZd3sej2epjoBWibMHvXpa4q3ORhZZBmgZflFVjy/ta 9S1tTTnCIZCR1UeGrzS6G0oVq9rG63RKMX0TOdlx4EpSSBqKJTy1D/ZDdL2gj91c8Z Ldnz7QVY7WNX6lkURcZi/HtqncqNHtFv/GFaXChM= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 22 Aug 2013 20:23:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id EC4E21602E9; Thu, 22 Aug 2013 20:23:36 +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 BD02C1602B4; Thu, 22 Aug 2013 20:23:36 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id C4A8F38CBA08; Fri, 23 Aug 2013 06:23:14 +1000 (EST) To: Ted Lemon From: Mark Andrews References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B 63077526 1957@mbx-01.win.nominum.com> In-reply-to: Your message of "Thu, 22 Aug 2013 15:03:01 +0000." <8D23D4052ABE7A4490E77B1A012B630775261957@mbx-01.win.nominum.com> Date: Fri, 23 Aug 2013 06:23:14 +1000 Message-Id: <20130822202314.C4A8F38CBA08@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "" , "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 20:23:38 -0000 In message <8D23D4052ABE7A4490E77B1A012B630775261957@mbx-01.win.nominum.com>, T ed Lemon writes: > On Aug 22, 2013, at 12:03 AM, Mark Andrews wrote: > > Well there has been. Named complains about there not being both > > SPF and TXT records present. > > I mean advocacy, not a warning message from a daemon that nobody with any > power to do anything sees. While Dave points out that the IETF doesn't > do advocacy, IETF participants certainly do as part of their work. > Nobody has done any advocacy on this point. If you care so deeply about > it, why haven't you? Or is it the case that you have, and it hasn't > worked? We can make it refuse to load the zone without being fixed. We can make it a MUST for if there isn't a SPF record. i.e. you can only disable the warning if you are missing the TXT version. And by the way we issue this only on master servers which is where the data is entered. We prevent lots of other DNS issues this way for our users. You can't load a zone without the address record for in zone servers being present. We block the loading of zones without required glue being present. We block the loading of zones for other reason. All these blocks are for master zones. Slave servers don't perform the checks. SERVFAIL from the master server is a powerful tool. You see it and you have to fix it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From hsantos@isdg.net Thu Aug 22 13:34:08 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 5181911E80FA for ; Thu, 22 Aug 2013 13:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.102 X-Spam-Level: X-Spam-Status: No, score=-102.102 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, GB_ABOUTYOU=0.5, 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 0gehbDsHVy9R for ; Thu, 22 Aug 2013 13:34:03 -0700 (PDT) Received: from pop3.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A227211E810A for ; Thu, 22 Aug 2013 13:34:03 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3640; t=1377203640; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=kf0Cah8L2+5dpTJUuRTZH0YeES4=; b=oTJRoht4IOttdLy/atLs bnuhrOKawtz5+Ag9jc1ZaU9kqYOMFHvU7cfK+lhDlvbfGMieke9Gcz+VzK9bj09y riFRPx9JPR4M72H3mNDz3TbwdmwUuST76tiYKJLJRizXk9GtW40ckWd2MKluKIQf n1pRQYGdQzhD8xU0AoNsFDw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 22 Aug 2013 16:34:00 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3666155161.1759.1620; Thu, 22 Aug 2013 16:33:59 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3640; t=1377203327; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=24weumS 2a+z81owUpIP/RjVeAmMafUqXw7dWjILkvaM=; b=Ju7qYqa4RKH7nkuSJCAmHex 4GSuCf5up8cfBaOSTtfYuJ7pA73VkiDMsa4bvglHNxKTEH7PuleFukKF59CS6tre 46qvsVZfvj7EHmY4cwPz9ClF8CEFe+RpyfZR6q6ofHCyV0kMd1WaA2dFLDGcuzrc ZaF+9KrxTON0Jv4J6ko8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 22 Aug 2013 16:28:47 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3112575377.9.1056; Thu, 22 Aug 2013 16:28:46 -0400 Message-ID: <521675A7.4030202@isdg.net> Date: Thu, 22 Aug 2013 16:33:43 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <20130819150521.GB21088@besserwisser.org> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B630775261957@mbx-01.win.nominum.com> <9668323b-9239-4b7a-a0ce-b6d6819898a9@email.android.com> <52166462.4050205@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 20:34:08 -0000 So who was dishonest? The group of SPF type advocates or a specific individual? Nonetheless, maybe I am wrong, but its not cool to be labeling anyone dishonest. Scott Kitterman wrote: > Hector, > > Not everything is about you. > > Scott K > > Hector Santos wrote: >> Dishonest? Ouch! >> >> I don't think I was dishonest in my engineering agreements with others >> that new RR types should be used and there was really no reason to >> remove it first and make it a burden on the rest of the community to >> add it back. >> >> I won't call this dishonest, but the burden should of been on you to >> remove first by asking the entire interfacing community first, not >> just with WG. This was highly predictable, yet the WG went on to >> remove it without consulting the related IETF groups. I understand >> that is the current procedure, but this decision does not provide the >> design confidence that new RR types are still valid to consider. If >> you believe they still are, then in my opinion, the SPFBIS should not >> had removed it. >> >> And lets just say that after all these discussions, someone writes a >> serious and accepted RFC addressed at the DNS industry, Levine is >> write a I-D for unnamed types, etc, and we begin to get big traction >> and finally the changes to the infrastructure begin, SPFBIS will be >> without its SPF type99 and that would be unfortunate. >> >> I don't think that is dishonest. >> >> -- >> HLS >> >> Scott Kitterman wrote: >>> Ted Lemon wrote: >>>> On Aug 22, 2013, at 12:03 AM, Mark Andrews wrote: >>>>> Well there has been. Named complains about there not being both >>>>> SPF and TXT records present. >>>> I mean advocacy, not a warning message from a daemon that nobody >> with >>>> any power to do anything sees. While Dave points out that the IETF >>>> doesn't do advocacy, IETF participants certainly do as part of their >>>> work. Nobody has done any advocacy on this point. If you care so >>>> deeply about it, why haven't you? Or is it the case that you >> have, >>>> and it hasn't worked? >>> It's not correct that nobody has done any advocacy. >>> >>> The major FOSS SPF libraries all support type SPF and have done so >> since shortly after it was allocated (or in the case of Mail::SPF it's >> initial release). This was all done as free time work. No one was >> paid for it. >>> I have run what I have reason to believe is the most popular web >> based SPF validator. Since very shortly after the type was allocated >> it has checked for it and included in its results. You've got no idea >> how many e-mails I get from people that are confused about it. I also >> did this in my 'spare' time. >>> You may have noted FAQ entries on openspf.org presenting type SPF as >> the right thing to do. I wrote that. >>> We tried. It didn't work out for a variety of reasons that I won't >> rehash, but it's not like we didn't try. What I didn't do was engage in >> intellectually dishonest advocacy to push people to favor type SPF over >> TXT knowing it would work less well for them. >>> Scott K >>> _______________________________________________ >>> spfbis mailing list >>> spfbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/spfbis >>> >>> >> >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From spf2@kitterman.com Thu Aug 22 14:06:20 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 34D4611E821C for ; Thu, 22 Aug 2013 14:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, GB_ABOUTYOU=0.5] 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 X0BhG5b6Kw8u for ; Thu, 22 Aug 2013 14:06:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9ED11E8210 for ; Thu, 22 Aug 2013 14:06:14 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7009E20E40FC; Thu, 22 Aug 2013 17:06:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377205571; bh=pT+63qmHdYFv9tbtgLdOsiMwL7o8UhH10EVJglQq7Ns=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MifBANsA/cwD9KbwY8Ds4I1LD9RlOBHQWpx8Kw+hJ+zrIm8l3V+HL9NQlf2Dv7YTG FJupZwgi/FeDuIBbkiUe4iUUiu7f6boaiDzPt/irY4QjaOFz18GogfScaE4el6hvHo iMsBBaeKQDPsCn/KHuPTrKTB22wKvci8L7nXd96o= Received: from scott-latitude-e6320.localnet (62.sub-70-208-156.myvzw.com [70.208.156.62]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3EB6D20E40C8; Thu, 22 Aug 2013 17:06:10 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 22 Aug 2013 17:06:08 -0400 Message-ID: <8249873.3l6btIhhja@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <521675A7.4030202@isdg.net> References: <20130819150521.GB21088@besserwisser.org> <521675A7.4030202@isdg.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] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 21:06:20 -0000 I didn't have anyone in particular in mind, but I think that writing in 4408bis that one MUST use RRTYPE SPF and MAY/SHOULD use RRTYPE TXT is an intentionally suboptimiized design (I know others disagree). I think putting that in an RFC would not be intellectually honest. Someone reading such a spec might go and implement just the SPF part of the spec and then wonder why it seems like SPF usage is so much lower than they'd heard. Note that I'm not accusing anyone of not telling the truth. Relax. It's fine. Scott K On Thursday, August 22, 2013 16:33:43 Hector Santos wrote: > So who was dishonest? The group of SPF type advocates or a specific > individual? > > Nonetheless, maybe I am wrong, but its not cool to be labeling anyone > dishonest. > > Scott Kitterman wrote: > > Hector, > > > > Not everything is about you. > > > > Scott K > > > > Hector Santos wrote: > >> Dishonest? Ouch! > >> > >> I don't think I was dishonest in my engineering agreements with others > >> that new RR types should be used and there was really no reason to > >> remove it first and make it a burden on the rest of the community to > >> add it back. > >> > >> I won't call this dishonest, but the burden should of been on you to > >> remove first by asking the entire interfacing community first, not > >> just with WG. This was highly predictable, yet the WG went on to > >> remove it without consulting the related IETF groups. I understand > >> that is the current procedure, but this decision does not provide the > >> design confidence that new RR types are still valid to consider. If > >> you believe they still are, then in my opinion, the SPFBIS should not > >> had removed it. > >> > >> And lets just say that after all these discussions, someone writes a > >> serious and accepted RFC addressed at the DNS industry, Levine is > >> write a I-D for unnamed types, etc, and we begin to get big traction > >> and finally the changes to the infrastructure begin, SPFBIS will be > >> without its SPF type99 and that would be unfortunate. > >> > >> I don't think that is dishonest. > >> > >> -- > >> HLS > >> > >> Scott Kitterman wrote: > >>> Ted Lemon wrote: > >>>> On Aug 22, 2013, at 12:03 AM, Mark Andrews wrote: > >>>>> Well there has been. Named complains about there not being both > >>>>> SPF and TXT records present. > >>>> > >>>> I mean advocacy, not a warning message from a daemon that nobody > >> > >> with > >> > >>>> any power to do anything sees. While Dave points out that the IETF > >>>> doesn't do advocacy, IETF participants certainly do as part of their > >>>> work. Nobody has done any advocacy on this point. If you care so > >>>> deeply about it, why haven't you? Or is it the case that you > >> > >> have, > >> > >>>> and it hasn't worked? > >>> > >>> It's not correct that nobody has done any advocacy. > >>> > >>> The major FOSS SPF libraries all support type SPF and have done so > >> > >> since shortly after it was allocated (or in the case of Mail::SPF it's > >> initial release). This was all done as free time work. No one was > >> paid for it. > >> > >>> I have run what I have reason to believe is the most popular web > >> based SPF validator. Since very shortly after the type was allocated > >> it has checked for it and included in its results. You've got no idea > >> how many e-mails I get from people that are confused about it. I also > >> did this in my 'spare' time. > >> > >>> You may have noted FAQ entries on openspf.org presenting type SPF as > >> the right thing to do. I wrote that. > >> > >>> We tried. It didn't work out for a variety of reasons that I won't > >> rehash, but it's not like we didn't try. What I didn't do was engage in > >> intellectually dishonest advocacy to push people to favor type SPF over > >> TXT knowing it would work less well for them. From Ted.Lemon@nominum.com Thu Aug 22 14:44:27 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 7227D21F9E6B for ; Thu, 22 Aug 2013 14:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 g1dUN+ECVjdi for ; Thu, 22 Aug 2013 14:44:20 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id BE91821F8895 for ; Thu, 22 Aug 2013 14:43:34 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUhaGBgSLLFYvy+Gmz0U3WNOAUHbmMLKd@postini.com; Thu, 22 Aug 2013 14:43:34 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 151261B82C1 for ; Thu, 22 Aug 2013 14:43:34 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id BE00A190071; Thu, 22 Aug 2013 14:43:32 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 14:43:32 -0700 From: Ted Lemon To: Mark Andrews Thread-Topic: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Thread-Index: AQHOnt8CSYFjulBN10Cqc2E5OcP8BZmhBxKAgAAB1ICAAAYyAP//vtJngADfTOyAAIuugA== Date: Thu, 22 Aug 2013 21:43:31 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com> References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B 63077526 1957@mbx-01.win.nominum.com> <20130822202314.C4A8F38CBA08@drugs.dv.isc.org> In-Reply-To: <20130822202314.C4A8F38CBA08@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <97D0642A62F03747A8C0E3B2410010AD@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 21:44:27 -0000 On Aug 22, 2013, at 1:23 PM, Mark Andrews wrote: > We can make it refuse to load the zone without being fixed. We can make > it a MUST for if there isn't a SPF record. i.e. you can only disable the > warning if you are missing the TXT version. Who is this "we," Mark? I'd be happy if ISC decided to do that=97it would = help Nominum to sell more servers! From marka@isc.org Thu Aug 22 15:30:00 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 A20E621F9CF5 for ; Thu, 22 Aug 2013 15:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.272, 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 AxCiGsq8lx9l for ; Thu, 22 Aug 2013 15:29:55 -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 CB7B121F9CC3 for ; Thu, 22 Aug 2013 15:29:55 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id E292EC949D; Thu, 22 Aug 2013 22:29:39 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377210592; bh=s2PBzF/iRPeJPcTHiQpaQpqY+Sx1OOOR+HfV7yEYvsw=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=EWfb1QGAoL34apmddx50s8Ejagm++x1sqFzO3znJu6i+CehSd/qB2Yo6RK3ZNVgeO Nqm942tukoKcmRRvJxEG+PfuxhfiH6SnasQbn/geema7QLs1GS/kMc+ZoPilhR23/r 7dcpaFOcJ9JP0+Vsri53YQU0WpXl00g6SA9/fMYM= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 22 Aug 2013 22:29:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 34CF11602E9; Thu, 22 Aug 2013 22:29:56 +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 03CDA1602B4; Thu, 22 Aug 2013 22:29:56 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 535B138CC1E9; Fri, 23 Aug 2013 08:29:35 +1000 (EST) To: Ted Lemon From: Mark Andrews References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B 6307752 6 1957@mbx-01.win.nominum.com> <20130822202314.C4A8F38CBA08@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com> In-reply-to: Your message of "Thu, 22 Aug 2013 21:43:31 +0000." <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com> Date: Fri, 23 Aug 2013 08:29:34 +1000 Message-Id: <20130822222935.535B138CC1E9@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "" , "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 22:30:00 -0000 In message <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com>, T ed Lemon writes: > On Aug 22, 2013, at 1:23 PM, Mark Andrews wrote: > > We can make it refuse to load the zone without being fixed. We can make > > it a MUST for if there isn't a SPF record. i.e. you can only disable the > > warning if you are missing the TXT version. > > Who is this "we," Mark? I'd be happy if ISC decided to do that=97it would = > help Nominum to sell more servers! We in this case would be a request from the IETF to the DNS nameserver vendors. Raising the default to fail rather than warn I think I can argue that ISC to does alone. That would just be making people think about the "MUST publish both" that was in 4408. At the moment they really don't make that decision because most people are not aware of the SPF RR type, they think TXT record. If the SPF WG had wanted a fast migration they could have ask for nameserver vendors to issue warning when SPF was not present or to refuse to load unless configured otherwise. Fail with no config file fix needs IETF backing. The failure log message would need to reference a RFC MUST. As for nameservers not answering the IETF should ask ICANN to get COM and all the other ICANN affiliated zones to audit delegated nameservers for RFC 4035 Section 4.1.1 compliance with respect to SPF records and are causing operational problems. A nameserver that fails to answer is out of spec. The technical contacts for the zones should be contacted to request a fix. If after a month the servers are not fixed, the delegations should be withdrawn. Withdrawing delegation is the prescribed fix for nameservers which are cause operation problem and are not being fixed. This is consistent with RFC 1033 COMPLAINTS. We can play "Whack a Mole" or we can ask those that are supposed to be managing the DNS to actually manage the DNS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ted.Lemon@nominum.com Thu Aug 22 15:35:54 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 875AD11E8226 for ; Thu, 22 Aug 2013 15:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 4ldMJ5CH1+Iz for ; Thu, 22 Aug 2013 15:35:43 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id B2B3211E8225 for ; Thu, 22 Aug 2013 15:35:43 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUhaSP2AG8KVbxE+UbBxxU/KRH21/uh1Z@postini.com; Thu, 22 Aug 2013 15:35:43 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1595D1B82C4 for ; Thu, 22 Aug 2013 15:35:43 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id ECC0F190061; Thu, 22 Aug 2013 15:35:42 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 15:35:43 -0700 From: Ted Lemon To: Mark Andrews Thread-Topic: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Thread-Index: AQHOnt8CSYFjulBN10Cqc2E5OcP8BZmhBxKAgAAB1ICAAAYyAP//vtJngADfTOyAAIuugP//l53YgAB29wA= Date: Thu, 22 Aug 2013 22:35:42 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307752629C9@mbx-01.win.nominum.com> References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B 6307752 6 1957@mbx-01.win.nominum.com> <20130822202314.C4A8F38CBA08@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com> <20130822222935.535B138CC1E9@drugs.dv.isc.org> In-Reply-To: <20130822222935.535B138CC1E9@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D6C374056655342B439F3AC1CAA058A@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 22:35:55 -0000 On Aug 22, 2013, at 3:29 PM, Mark Andrews wrote: > We in this case would be a request from the IETF to the DNS nameserver > vendors. How would "the IETF" make such a request? From dhc@dcrocker.net Thu Aug 22 15:57:46 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 C556921F9A6D for ; Thu, 22 Aug 2013 15:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KiGFje76aGq for ; Thu, 22 Aug 2013 15:57:40 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 707A921F999D for ; Thu, 22 Aug 2013 15:57:39 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7MMvZhv022832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Aug 2013 15:57:39 -0700 Message-ID: <52169745.9040808@dcrocker.net> Date: Thu, 22 Aug 2013 15:57:09 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark Andrews References: <20130819150521.GB21088@besserwisser.org> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B 6307752 6 1957@mbx-01.win.nominum.com> <20130822202314.C4A8F38CBA08@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com> <20130822222935.535B138CC1E9@drugs.dv.isc.org> In-Reply-To: <20130822222935.535B138CC1E9@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 22 Aug 2013 15:57:39 -0700 (PDT) Cc: "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 22:57:46 -0000 On 8/22/2013 3:29 PM, Mark Andrews wrote: > We in this case would be a request from the IETF to the DNS nameserver > vendors. "The IETF" doesn't do such things. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From marka@isc.org Thu Aug 22 16:00:30 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 CEB7011E8169 for ; Thu, 22 Aug 2013 16:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 hgdJXafSMTQq for ; Thu, 22 Aug 2013 16:00:26 -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 098AD11E8230 for ; Thu, 22 Aug 2013 16:00:26 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 051C5C948E; Thu, 22 Aug 2013 23:00:14 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377212425; bh=/M+80vtYVR4dESxDIMM1P8ce5eUyPc2LI0pm/1w2gzM=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=uvOvft1ER2etuYviviPHrmdevchpFosrsf6qdwJSbykPKE/9p525auLWjGBaiMQ8U KgzIOPpzVvyxj0Jl/4xTqYj7ECsr6UxpytmhUifMq1iX4W3cXhrRnzjZy0+eu+O+Ex 5zMkVOUcvHv+6MgNVAf20xkr0HCGQt1zDcxcyWbs= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 22 Aug 2013 23:00:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 618861602E9; Thu, 22 Aug 2013 23:00:30 +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 322A41602B4; Thu, 22 Aug 2013 23:00:30 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id A63F138CC3C5; Fri, 23 Aug 2013 09:00:11 +1000 (EST) To: Ted Lemon From: Mark Andrews References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B 6307752 6 1957@mbx-01.win.nominum.com> <20130822202314.C4A8F38CBA08@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com> <20130822222935.535B138CC1E9@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B6307752629C9@mbx-01.win.nominum.com> In-reply-to: Your message of "Thu, 22 Aug 2013 22:35:42 +0000." <8D23D4052ABE7A4490E77B1A012B6307752629C9@mbx-01.win.nominum.com> Date: Fri, 23 Aug 2013 09:00:11 +1000 Message-Id: <20130822230011.A63F138CC3C5@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "" , "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 23:00:30 -0000 In message <8D23D4052ABE7A4490E77B1A012B6307752629C9@mbx-01.win.nominum.com>, T ed Lemon writes: > On Aug 22, 2013, at 3:29 PM, Mark Andrews wrote: > > We in this case would be a request from the IETF to the DNS nameserver > > vendors. > > How would "the IETF" make such a request? The same way it makes all its other requests of vendors. They get written down in RFC format and it get ratified by a IETF last call. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ted.Lemon@nominum.com Thu Aug 22 16:42: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 E08A111E8239 for ; Thu, 22 Aug 2013 16:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.586 X-Spam-Level: X-Spam-Status: No, score=-106.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 jP-27aM+dRXF for ; Thu, 22 Aug 2013 16:42:17 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id ACA6911E823B for ; Thu, 22 Aug 2013 16:42:13 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUhah04Xma/sidwVZ7e926coYxuf41nEN@postini.com; Thu, 22 Aug 2013 16:42:14 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 44FD81B82C1 for ; Thu, 22 Aug 2013 16:42:11 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id EE5E2190064; Thu, 22 Aug 2013 16:42:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 16:42:10 -0700 From: Ted Lemon To: Mark Andrews Thread-Topic: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Thread-Index: AQHOnt8CSYFjulBN10Cqc2E5OcP8BZmhBxKAgAAB1ICAAAYyAP//vtJngADfTOyAAIuugP//l53YgAB29wD//5GSPAAQH/WA Date: Thu, 22 Aug 2013 23:42:09 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775262B95@mbx-01.win.nominum.com> References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B 6307752 6 1957@mbx-01.win.nominum.com> <20130822202314.C4A8F38CBA08@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com> <20130822222935.535B138CC1E9@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B6307752629C9@mbx-01.win.nominum.com> <20130822230011.A63F138CC3C5@drugs.dv.isc.org> In-Reply-To: <20130822230011.A63F138CC3C5@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <583B52AE7451CA46A455231F5B8D6919@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 23:42:24 -0000 On Aug 22, 2013, at 4:00 PM, Mark Andrews wrote: > The same way it makes all its other requests of vendors. They get writte= n > down in RFC format and it get ratified by a IETF last call. Okay, then we've already made that request, and it's been ignored. From mansaxel@besserwisser.org Thu Aug 22 16:44: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 99CFC11E823B for ; Thu, 22 Aug 2013 16:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 emE3YILoBSXe for ; Thu, 22 Aug 2013 16:44:11 -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 94AA311E8239 for ; Thu, 22 Aug 2013 16:44:11 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 1286A9EEA; Fri, 23 Aug 2013 01:44:00 +0200 (CEST) Date: Fri, 23 Aug 2013 01:44:00 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: dcrocker@bbiw.net Message-ID: <20130822234359.GL30516@besserwisser.org> References: <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <20130822202314.C4A8F38CBA08@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com> <20130822222935.535B138CC1E9@drugs.dv.isc.org> <52169745.9040808@dcrocker.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="c8JyeaiReRNoiMDS" Content-Disposition: inline In-Reply-To: <52169745.9040808@dcrocker.net> 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: "" , Mark Andrews Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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: Thu, 22 Aug 2013 23:44:12 -0000 --c8JyeaiReRNoiMDS Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] Last Call: (Sender= Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1)= to Proposed Standard Date: Thu, Aug 22, 2013 at 03:57:09PM -0700 Quoting D= ave Crocker (dhc@dcrocker.net > On 8/22/2013 3:29 PM, Mark Andrews wrote: > >We in this case would be a request from the IETF to the DNS nameserver > >vendors. >=20 >=20 > "The IETF" doesn't do such things. As Mark explained in a later message, the IETF codifies behaviour by using 2119 terms like MUST and SHOULD.=20 Vendors and operators are from what I can tell eager to get what amounts to a perceived IETF seal of approval by actually implementing RFC specifications. It mostly works like that. (look, for instance, at the archives for the payload wg, where vendors arrive in a steady stream urging standardisation work in order to increase interoperability. ) Returning to the issue at hand: The fuzzy language in 4408, which supposedly is to be clarified in 4408bis is a major contributor to the mess we see today. As I've written before, this language (original 4408) allows the vendors of DNS management systems to ignore SPF/99. That, as far as I can tell (but I did not participate in getting 4408 published and I have not read the archives; my interpretation is from reading 4408), does not seem to have been the intention of the 4408 authors. The charter of spfbis, feature removal notwithstanding, seems spot on to=20 correct this language, and thus 4408bis should be directing implementors to not ignore SPF/99 but instead implement it in name servers, full-service resolvers, provisioning systems, and SPF validator suites. Further, validators should actively prefer SPF rrtype in validation queries. I believe that TXT will be with us for a long time, so validation suites should be configurable to ask for TXT records. These configuration options, though, must not allow for the disabling of SPF record lookup.=20 Text on suitable TTL values for SPF records (regardless of rrtype used) could perhaps be useful. A long TTL (24h+) would -- providing the resolver chain is not completely brain-dead -- allow the validation data to be cached and blocking behaviour associated with non-compliant middleboxes avoided for repeated lookups. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 My vaseline is RUNNING... --c8JyeaiReRNoiMDS 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) iEYEARECAAYFAlIWoj8ACgkQ02/pMZDM1cV1lwCfXsPbxS6GwzIzpssYHhU5P/nc De4An0WZmI43CVf6E9gZcu5L61G5FmzP =fgfP -----END PGP SIGNATURE----- --c8JyeaiReRNoiMDS-- From marka@isc.org Thu Aug 22 17:25:13 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 5143411E8297 for ; Thu, 22 Aug 2013 17:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 Zl1NjmpigmUf for ; Thu, 22 Aug 2013 17:25:08 -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 CC44E11E812E for ; Thu, 22 Aug 2013 17:25:07 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 5BE83C9493; Fri, 23 Aug 2013 00:24:54 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377217507; bh=hF7gcHyIlqg36vdwPQ/291ypdCHP1jVIxAYSkEO5zRc=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=vHMIrbODdrhORV0p/pnmeviGF4Z+zXyfu35PP+IF7MSDzNy5/cILwUtp/5+5PVB8L lc3pwc00f2tkw90dYMFcKieyovUBbaimRL9ZWpNHUOIPIFsPotv5B7BYRaQoZej2er PduJeVAr2GQrBIiPdqpWViasf+fP1SKJaVDOHe2s= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 23 Aug 2013 00:24:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0410F1602E9; Fri, 23 Aug 2013 00:25:11 +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 C09A51602B4; Fri, 23 Aug 2013 00:25:10 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4BC5E38CD236; Fri, 23 Aug 2013 10:24:48 +1000 (EST) To: Ted Lemon From: Mark Andrews References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B 6307752 6 1957@mbx-01.win.nominum.com> <20130822202314.C4A8F38CBA08@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com> <20130822222935.535B138CC1E9@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B6307752629C9@mbx-01.win.nominum.com> <20130822230011.A63F138CC3C5@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B630775262B95@mbx-01.win.nominum.com> In-reply-to: Your message of "Thu, 22 Aug 2013 23:42:09 +0000." <8D23D4052ABE7A4490E77B1A012B630775262B95@mbx-01.win.nominum.com> Date: Fri, 23 Aug 2013 10:24:48 +1000 Message-Id: <20130823002448.4BC5E38CD236@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "" , "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 23 Aug 2013 00:25:13 -0000 In message <8D23D4052ABE7A4490E77B1A012B630775262B95@mbx-01.win.nominum.com>, T ed Lemon writes: > On Aug 22, 2013, at 4:00 PM, Mark Andrews wrote: > > The same way it makes all its other requests of vendors. They get writte= > n > > down in RFC format and it get ratified by a IETF last call. > > Okay, then we've already made that request, and it's been ignored. Where were the words "Nameservers SHOULD enforce the presence of SPF records"? RFC 4408 Section 3.1 was directed to "Domain owners". That said we do warn about it. The warnings do get noticed. https://lists.isc.org/pipermail/bind-users/2013-July/091176.html And people notice the feature change. https://lists.isc.org/pipermail/bind-users/2013-May/090700.html We have code that has passed technical review that will synthesize SPF records when there TXT v=spf1 records. There is still debate about whether to commit it or not. This would address part of the web forms don't support SPF records. One could add a recommendation that servers do such synthesis with a sunset date so that there is some presure on getting the web interfaces fixed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From superuser@gmail.com Thu Aug 22 21:45:51 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 78C9311E818F for ; Thu, 22 Aug 2013 21:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 4bZ2RORInZ4g for ; Thu, 22 Aug 2013 21:45:48 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7FC11E8169 for ; Thu, 22 Aug 2013 21:45:45 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so190051pab.41 for ; Thu, 22 Aug 2013 21:45:40 -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=cc6MVVSCfPxMn4i3AwZ9gQ3D5GuuQ1IM4deLgdB2uH0=; b=06CEW03EsZGkJDqwk1CF0+ek3O63przBTe7LUbvCRaydduBTExnjyfVdhHBo1w4jRY tw466rWvfk46wtcBZYPHq5ODGRQ2Q5wMw36lBhtZnycp3LjXEjJ9CDhXjI4QC4vgEyhs Z4YTyjpaUBRNVma6xE5zwENh5L1ZbJs37aS49fjeBxhzDeI0lksN3QhXiAzGcrsHFDhd wB66/LlmB9eUpcUGDqZ92E14lgo2+LxCOUFr235TeQN+FiLPCA+hN3UWGNrxAw+MXpWN ruU147f716kgtOocVW8SlmrhhZNhFEtbF3WUji1t2HB4qiEOL+CbBxy46xNkgmosw2Yt oZ/g== MIME-Version: 1.0 X-Received: by 10.66.161.229 with SMTP id xv5mr9193601pab.87.1377233139975; Thu, 22 Aug 2013 21:45:39 -0700 (PDT) Received: by 10.67.5.225 with HTTP; Thu, 22 Aug 2013 21:45:39 -0700 (PDT) In-Reply-To: <20130822222935.535B138CC1E9@drugs.dv.isc.org> References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <20130822202314.C4A8F38CBA08@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com> <20130822222935.535B138CC1E9@drugs.dv.isc.org> Date: Thu, 22 Aug 2013 21:45:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: Mark Andrews Content-Type: multipart/alternative; boundary=047d7b86f30614d29b04e49614e1 Cc: "" , Ted Lemon , "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 23 Aug 2013 04:45:52 -0000 --047d7b86f30614d29b04e49614e1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 22, 2013 at 3:29 PM, Mark Andrews wrote: > We in this case would be a request from the IETF to the DNS nameserver > vendors. > > Raising the default to fail rather than warn I think I can argue > that ISC to does alone. That would just be making people think > about the "MUST publish both" that was in 4408. At the moment they > really don't make that decision because most people are not aware > of the SPF RR type, they think TXT record. > > If the SPF WG had wanted a fast migration they could have ask for > nameserver vendors to issue warning when SPF was not present or to > refuse to load unless configured otherwise. > [...] > Doesn't this approach presuppose rather a lot of cooperation from the DNS vendors (i.e., just about all of them), and a pretty "keep totally current" posture among pretty much all operators? That seems like a high bar. Fail with no config file fix needs IETF backing. The failure log > message would need to reference a RFC MUST. > > As for nameservers not answering the IETF should ask ICANN to get > COM and all the other ICANN affiliated zones to audit delegated > nameservers for RFC 4035 Section 4.1.1 compliance with respect to > SPF records and are causing operational problems. A nameserver > that fails to answer is out of spec. The technical contacts for > the zones should be contacted to request a fix. > Why would ICANN want to get involved in this? We can play "Whack a Mole" or we can ask those that are supposed to > be managing the DNS to actually manage the DNS. > > Unfortunately, I don't think either the IETF or ICANN wield such hammers. -MSK --047d7b86f30614d29b04e49614e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 22, 2013 at 3:29 PM, Mark Andrews <marka@isc.org<= /a>> wrote:
We in this case would be a request from the IETF to the DNS nameserver
vendors.

Raising the default to fail rather than warn I think I can argue
that ISC to does alone. =A0That would just be making people think
about the "MUST publish both" that was in 4408. =A0At the moment = they
really don't make that decision because most people are not aware
of the SPF RR type, they think TXT record.

If the SPF WG had wanted a fast migration they could have ask for
nameserver vendors to issue warning when SPF was not present or to
refuse to load unless configured otherwise.
[...]

Doesn't this approach presupp= ose rather a lot of cooperation from the DNS vendors (i.e., just about all = of them), and a pretty "keep totally current" posture among prett= y much all operators?=A0 That seems like a high bar.

Fail with no config file fix needs IETF backing. =A0The failure log
message would need to reference a RFC MUST.

As for nameservers not answering the IETF should ask ICANN to get
COM and all the other ICANN affiliated zones to audit delegated
nameservers for RFC 4035 Section 4.1.1 compliance with respect to
SPF records and are causing operational problems. =A0A nameserver
that fails to answer is out of spec. =A0The technical contacts for
the zones should be contacted to request a fix.

Why would ICANN want to get involved in this?

We can play "Whack a Mole" or we can ask those that are supposed = to
be managing the DNS to actually manage the DNS.


Unfortu= nately, I don't think either the IETF or ICANN wield such hammers.
<= br>
-MSK

--047d7b86f30614d29b04e49614e1-- From marka@isc.org Thu Aug 22 22:03:46 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 24D3921F9A99 for ; Thu, 22 Aug 2013 22:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, 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 89hIW7Ym7+VU for ; Thu, 22 Aug 2013 22:03:40 -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 E102111E80FF for ; Thu, 22 Aug 2013 22:03:39 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 9D793C9450; Fri, 23 Aug 2013 05:03:26 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377234219; bh=bIqyGC0hTsX4v7r0of720eZbkcqfvZ6KH9Js8JXJZ3M=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=jO1VmztqrOPfWEuhjGJehZDdppQ5u0pApGNdfWnc5F1/BeL6wjw0I2XFKuzz7Pd6G Ggp3BHZHk5bQZis1Z1RT0jSoaAIS7iNYzoQwD/hNg6P4BHQTtOMTACANU9xSRRrnFQ 6+ZI2/bwrStlSmBU3W26zcAbFC5GxC7/ZfJJteH0= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 23 Aug 2013 05:03:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1DC701602E9; Fri, 23 Aug 2013 05:03:44 +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 ADC0B1602B4; Fri, 23 Aug 2013 05:03:43 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 95EF838CF945; Fri, 23 Aug 2013 15:03:23 +1000 (EST) To: "Murray S. Kucherawy" From: Mark Andrews References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <20130822202314.C4A8F38CBA08@ drugs.dv .isc.org> <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com> <20130822222935.535B138CC1E9@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 22 Aug 2013 21:45:39 -0700." Date: Fri, 23 Aug 2013 15:03:23 +1000 Message-Id: <20130823050323.95EF838CF945@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "" , Ted Lemon , "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 23 Aug 2013 05:03:46 -0000 In message , "Murray S. Kucherawy" writes: > > On Thu, Aug 22, 2013 at 3:29 PM, Mark Andrews wrote: > > > We in this case would be a request from the IETF to the DNS nameserver > > vendors. > > > > Raising the default to fail rather than warn I think I can argue > > that ISC to does alone. That would just be making people think > > about the "MUST publish both" that was in 4408. At the moment they > > really don't make that decision because most people are not aware > > of the SPF RR type, they think TXT record. > > > > If the SPF WG had wanted a fast migration they could have ask for > > nameserver vendors to issue warning when SPF was not present or to > > refuse to load unless configured otherwise. > > [...] > > > > Doesn't this approach presuppose rather a lot of cooperation from the DNS > vendors (i.e., just about all of them), and a pretty "keep totally current" > posture among pretty much all operators? That seems like a high bar. ISC added SPF support in the first .0 release after RFC 4408 was published. We had coded it before RFC 4408 was published. You had support from ISC and other DNS vendors. > Fail with no config file fix needs IETF backing. The failure log > > message would need to reference a RFC MUST. > > > > As for nameservers not answering the IETF should ask ICANN to get > > COM and all the other ICANN affiliated zones to audit delegated > > nameservers for RFC 4035 Section 4.1.1 compliance with respect to > > SPF records and are causing operational problems. A nameserver > > that fails to answer is out of spec. The technical contacts for > > the zones should be contacted to request a fix. > > Why would ICANN want to get involved in this? I think ICANN would prefer to not have to deal with this because it is a thorny issue. However they are responsible for establishing the contracts gTLD registries and registrars work under. It is within their purview to ensure that checks like these get made. > We can play "Whack a Mole" or we can ask those that are supposed to > > be managing the DNS to actually manage the DNS. > > Unfortunately, I don't think either the IETF or ICANN wield such hammers. > > -MSK > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From superuser@gmail.com Thu Aug 22 22: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 8728311E821F for ; Thu, 22 Aug 2013 22:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 SWVbRe+DgXSE for ; Thu, 22 Aug 2013 22:49:23 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DF24911E81C6 for ; Thu, 22 Aug 2013 22:49:22 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lj1so251875pab.1 for ; Thu, 22 Aug 2013 22:49:22 -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=4y6aDs/bNV78XvqfhzhOpXPsZyzJBpfFNmG/3tzRi7k=; b=GjTcPXhRgHslyirKQde/B52wBqAne99M+y9JTfNUI6euWADfRm6BQnjdgvd3blPGm5 oo+sE9C8QHRlq/8Bj/DPJMMCP08aDnprDKOFPFkKrE8xD8kT293roxXVVA/EJS5/5epf e0GnM9QKYPPB2J5zjo/qkh9ILdhcVAE9+yoddhnzHc6vnRB+FdGG30EIKJLftIIMhhbS GBwG8O+fSbZ0n8NmmqNQ0OLC27HfJKRy4naUHgh0WphnlhgjmCt2XfZ9i7sW4YVdWxO2 1yD5pdP6G7PwJwfMi6Iv3ul7LCPKZmJVsV+X3uvteUXtCkGG2Ed6Jr9OilUn2LvO/RgV o+eA== MIME-Version: 1.0 X-Received: by 10.68.111.35 with SMTP id if3mr1186050pbb.181.1377236962538; Thu, 22 Aug 2013 22:49:22 -0700 (PDT) Received: by 10.67.5.225 with HTTP; Thu, 22 Aug 2013 22:49:22 -0700 (PDT) In-Reply-To: <20130823050323.95EF838CF945@drugs.dv.isc.org> References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com> <20130822222935.535B138CC1E9@drugs.dv.isc.org> <20130823050323.95EF838CF945@drugs.dv.isc.org> Date: Thu, 22 Aug 2013 22:49:22 -0700 Message-ID: From: "Murray S. Kucherawy" To: Mark Andrews Content-Type: multipart/alternative; boundary=047d7b676928ec7a8604e496f7aa Cc: "" , Ted Lemon , "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 23 Aug 2013 05:49:23 -0000 --047d7b676928ec7a8604e496f7aa Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 22, 2013 at 10:03 PM, Mark Andrews wrote: > > Doesn't this approach presuppose rather a lot of cooperation from the DNS > > vendors (i.e., just about all of them), and a pretty "keep totally > current" > > posture among pretty much all operators? That seems like a high bar. > > ISC added SPF support in the first .0 release after RFC 4408 was > published. We had coded it before RFC 4408 was published. You had > support from ISC and other DNS vendors. > You appear to have ignored the second part, which is a pretty strong dependence that operators will upgrade quickly once this is out, and be comfortable with this sort of thing forced upon them. > > Why would ICANN want to get involved in this? > > I think ICANN would prefer to not have to deal with this because > it is a thorny issue. However they are responsible for establishing > the contracts gTLD registries and registrars work under. It is > within their purview to ensure that checks like these get made. > They have no such contracts with the ccTLDs, and as you said, they probably don't want to get involved in this particular issue either way. -MSK --047d7b676928ec7a8604e496f7aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 22, 2013 at 10:03 PM, Mark Andrews <marka@isc.o= rg> wrote:
> Doesn't this approach presuppose rather a lot of cooperation from = the DNS
> vendors (i.e., just about all of them), and a pretty "keep totall= y current"
> posture among pretty much all operators? =A0That seems like a high bar= .

ISC added SPF support in the first .0 release after RFC 4408 was
published. =A0We had coded it before RFC 4408 was published. =A0You had
support from ISC and other DNS vendors.

You appear to have ignored the second part, which is a pretty strong depen= dence that operators will upgrade quickly once this is out, and be comforta= ble with this sort of thing forced upon them.
=A0
> Why would ICANN want to get involved in this?

I think ICANN would prefer to not have to deal with this because
it is a thorny issue. =A0However they are responsible for establishing
the contracts gTLD registries and registrars work under. =A0It is
within their purview to ensure that checks like these get made.

They have no such contracts with the ccTLDs, and a= s you said, they probably don't want to get involved in this particular= issue either way.

-MSK
--047d7b676928ec7a8604e496f7aa-- From marka@isc.org Thu Aug 22 23:15:22 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 479B111E824F for ; Thu, 22 Aug 2013 23:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 SJTXI8h4-Sco for ; Thu, 22 Aug 2013 23:15:10 -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 5614C21F9FF3 for ; Thu, 22 Aug 2013 23:15:09 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 56398C94D0; Fri, 23 Aug 2013 06:14:55 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377238508; bh=o5wNdUHgUASkqoRZ1e5A8Z4KIEm78fYo8Z3NhSgTwO8=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=uF/RDFIMcaYM+xUMkK8w+ZiqHPn/Gct5NkmF0cNtyO2XY7XCRxoF8D65Xe33bC8bs WQCW8EWVh/Vr+HYm1TAch7Dr8JmXjPPpoJc4b+66zLaLyury+D3XCxPUQ9xBKH1NqE V8mHu5DzQALl534KN9MFyA2Lz+n5oDbbWw6D2kbI= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 23 Aug 2013 06:14:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 09B80160363; Fri, 23 Aug 2013 06:15:13 +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 0ABD81602E9; Fri, 23 Aug 2013 06:15:11 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id C4ECE38CFF14; Fri, 23 Aug 2013 16:14:36 +1000 (EST) To: "Murray S. Kucherawy" From: Mark Andrews References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B 63077526 274C@mbx-01.win.nominum.com> <20130822222935.535B138CC1E9@drugs.dv.isc.org> <20130823050323.95EF838CF945@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 22 Aug 2013 22:49:22 -0700." Date: Fri, 23 Aug 2013 16:14:36 +1000 Message-Id: <20130823061436.C4ECE38CFF14@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "" , Ted Lemon , "" Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 23 Aug 2013 06:15:22 -0000 In message , "Murray S. Kucherawy" writes: > > On Thu, Aug 22, 2013 at 10:03 PM, Mark Andrews wrote: > > > > Doesn't this approach presuppose rather a lot of cooperation from the DNS > > > vendors (i.e., just about all of them), and a pretty "keep totally > > current" > > > posture among pretty much all operators? That seems like a high bar. > > > > ISC added SPF support in the first .0 release after RFC 4408 was > > published. We had coded it before RFC 4408 was published. You had > > support from ISC and other DNS vendors. > > > > You appear to have ignored the second part, which is a pretty strong > dependence that operators will upgrade quickly once this is out, and be > comfortable with this sort of thing forced upon them. Lots of operators keep current. The package maintainers help here in that there are new packages available within days of a release for *BSD and Linux. We ship Windows binaries so they are available when we do a release. The appliance vendors that incorporate named aren't far behind either. Yes there is a long tail, but most operators are reasonably current. > > > Why would ICANN want to get involved in this? > > > > I think ICANN would prefer to not have to deal with this because > > it is a thorny issue. However they are responsible for establishing > > the contracts gTLD registries and registrars work under. It is > > within their purview to ensure that checks like these get made. > > They have no such contracts with the ccTLDs, and as you said, they probably > don't want to get involved in this particular issue either way. > > -MSK -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From angel@16bits.net Fri Aug 23 14:55:44 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 3757611E812C for ; Fri, 23 Aug 2013 14:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 imD-ATlUp5pL for ; Fri, 23 Aug 2013 14:55:26 -0700 (PDT) Received: from mailer.hiddenmail.net (mailer.hiddenmail.net [199.195.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6D521F9EDB for ; Fri, 23 Aug 2013 14:55:23 -0700 (PDT) Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from ) id 1VCzK3-0005WQ-Eq for spfbis@ietf.org; Fri, 23 Aug 2013 23:55:18 +0200 Message-ID: <1377295232.4167.24.camel@localhost.localdomain> From: =?ISO-8859-1?Q?=C1ngel?= To: spfbis@ietf.org Date: Sat, 24 Aug 2013 00:00:32 +0200 In-Reply-To: <20130822222935.535B138CC1E9@drugs.dv.isc.org> References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B 6307752 6 1957@mbx-01.win.nominum.com> <20130822202314.C4A8F38CBA08@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com> <20130822222935.535B138CC1E9@drugs.dv.isc.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.8.5 Mime-Version: 1.0 Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 23 Aug 2013 21:55:44 -0000 Mark Andrews wrote: > As for nameservers not answering the IETF should ask ICANN to get > COM and all the other ICANN affiliated zones to audit delegated > nameservers for RFC 4035 Section 4.1.1 compliance with respect to > SPF records and are causing operational problems. A nameserver > that fails to answer is out of spec. The technical contacts for > the zones should be contacted to request a fix. >=20 > If after a month the servers are not fixed, the delegations should > be withdrawn. Withdrawing delegation is the prescribed fix for > nameservers which are cause operation problem and are not being > fixed. >=20 > This is consistent with RFC 1033 COMPLAINTS. >=20 > We can play "Whack a Mole" or we can ask those that are supposed to > be managing the DNS to actually manage the DNS. >=20 > Mark It's much easier than this, and can be accomplished by the community, without a controversial top-down imposition by ICANN. a) Create a "RRTYPE 99 wall of shame site", to be used as central place for reports and checks of broken nameservers. b) Attempt to reach out those dns administrators. This will need a few people, but can be mostly automated, and given a proper FAQ at (a), shouldn't be a problem. After several months: c) Start rejecting mails from domains whose nameservers don't support SPF 99. Just to be explicit: not to return a spf record to the query would be perfectly fine, but leaving the mail server to timeout would not. This is completely justified as a "rejection for policy reasons". And a very reasonable one, given that the nameservers blocking the delivery while the smtpd is waiting for a reply are a problem for mail administrators. In order to avoid false positives due to the occasionally dropped packet, the following algorithm could be used: i) Following the spf process, if the type 99 query times out, record the domain and the current time at a local db. ii) If there were at least 3 failed checks for this domain with the earliest being no less than 24 hours ago, return a permanent error with a message pointing to a page explaining the condition at (a) site. iii) Else return a temporary failure. Purge the records after one week, or when a spf reply is received. You may insist on a broken nameserver which impacts MTAs, but in that case we will refuse serving your emails. I expect most sysadmins to happily update their nameservers to rfc3597 compliant ones, but c) ensures that domains with broken nameservers (due to ignorance, malice, lazyness... or sudden death of the only one in the company knowing what dns is) won't harm the email ecosystem (as well as providing a sidechannel for alerting the dns admins). From marka@isc.org Fri Aug 23 17:23: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 2C7C621F9D4C for ; Fri, 23 Aug 2013 17:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 0QYVPYvTpH2T for ; Fri, 23 Aug 2013 17:23:13 -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 E6A1E21F9A0C for ; Fri, 23 Aug 2013 17:23:11 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 46C15C94C0; Sat, 24 Aug 2013 00:22:59 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377303791; bh=RmoEGI+Fa7y8C+Z7NV+tt1ZqekA24L6qwtAOLodq0tE=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=SBckTxrTc47lAEXbqGPBRTwyZxvuDsrDhsLW5SuiJKmh9xAD0RVrH4ZIN7ytjJeHa qxNwyVHK+qd5CE5DnAh2Y12YcBh8OW9BTwUGQ9pk+hmnetUbJ0Pa7gxbhykxTy5mhr N5rGu01yvKVgABaB+QR+1LWjjzyYkSmefZOH4COM= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Sat, 24 Aug 2013 00:22:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4992B160363; Sat, 24 Aug 2013 00:23:20 +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 D92521602B4; Sat, 24 Aug 2013 00:23:19 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7662338D39D5; Sat, 24 Aug 2013 10:22:53 +1000 (EST) To: =?ISO-8859-1?Q?=C1ngel?= From: Mark Andrews References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B 6307752 6 1957@mbx-01.win.nominum.com> <20130822202314.C4A8F38CBA08@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com> <20130822222935.535B138CC1E9@drugs.dv.isc.org> <1377295232.4167.24.camel@localhost.localdomain> In-reply-to: Your message of "Sat, 24 Aug 2013 00:00:32 +0200." <1377295232.4167.24.camel@localhost.localdomain> Date: Sat, 24 Aug 2013 10:22:53 +1000 Message-Id: <20130824002253.7662338D39D5@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 24 Aug 2013 00:23:18 -0000 In message <1377295232.4167.24.camel@localhost.localdomain>, =?ISO-8859-1?Q?=C1 ngel?= writes: > Mark Andrews wrote: > > As for nameservers not answering the IETF should ask ICANN to get > > COM and all the other ICANN affiliated zones to audit delegated > > nameservers for RFC 4035 Section 4.1.1 compliance with respect to > > SPF records and are causing operational problems. A nameserver > > that fails to answer is out of spec. The technical contacts for > > the zones should be contacted to request a fix. > > > > If after a month the servers are not fixed, the delegations should > > be withdrawn. Withdrawing delegation is the prescribed fix for > > nameservers which are cause operation problem and are not being > > fixed. > > > > This is consistent with RFC 1033 COMPLAINTS. > > > > We can play "Whack a Mole" or we can ask those that are supposed to > > be managing the DNS to actually manage the DNS. > > > > Mark > > It's much easier than this, and can be accomplished by the community, > without a controversial top-down imposition by ICANN. > > a) Create a "RRTYPE 99 wall of shame site", to be used as central place > for reports and checks of broken nameservers. > > b) Attempt to reach out those dns administrators. This will need a few > people, but can be mostly automated, and given a proper FAQ at (a), > shouldn't be a problem. > > > After several months: > c) Start rejecting mails from domains whose nameservers don't support > SPF 99. Just to be explicit: not to return a spf record to the query > would be perfectly fine, but leaving the mail server to timeout would > not. > This is completely justified as a "rejection for policy reasons". And a > very reasonable one, given that the nameservers blocking the delivery > while the smtpd is waiting for a reply are a problem for mail > administrators. > > In order to avoid false positives due to the occasionally dropped > packet, the following algorithm could be used: > > i) Following the spf process, if the type 99 query times out, record the > domain and the current time at a local db. > ii) If there were at least 3 failed checks for this domain with the > earliest being no less than 24 hours ago, return a permanent error with > a message pointing to a page explaining the condition at (a) site. > iii) Else return a temporary failure. > > Purge the records after one week, or when a spf reply is received. > > > You may insist on a broken nameserver which impacts MTAs, but in that > case we will refuse serving your emails. > > > > I expect most sysadmins to happily update their nameservers to rfc3597 > compliant ones, but c) ensures that domains with broken nameservers (due > to ignorance, malice, lazyness... or sudden death of the only one in the > company knowing what dns is) won't harm the email ecosystem (as well as > providing a sidechannel for alerting the dns admins). That helps with legitimate email. It doesn't help with spoofed email using domains with addresses that don't send email and have a non rfc compliant nameserver or a misconfigured nameserver. > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From lear@cisco.com Sun Aug 25 08:14:06 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 14BB421F9D34; Sun, 25 Aug 2013 08:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.553 X-Spam-Level: X-Spam-Status: No, score=-110.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 yxHlSZ7F5dAV; Sun, 25 Aug 2013 08:14:01 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 28BB621F9D1C; Sun, 25 Aug 2013 08:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22053; q=dns/txt; s=iport; t=1377443640; x=1378653240; h=message-id:date:from:mime-version:to:cc:subject; bh=63RzhhBwE9BwEbEMjbEPUdN19on/Fz96G+8oyNYlE4M=; b=CFdL9KxFequpgz+Mj/fIx1mGiA2kfKiRVPco7Bs/M0/v+8ZMsD6WOEW1 Uufa4MAuUFWj1ie3+yonk15eJGrPLMpBbN/lH0ngGdpkgjKe1dMkGrT+L KqZjkYHMM/CCpNkEmizl+BchS1L2HBHHZiKAlXMd5YYfhPoNT9hEKp7Uz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAI4eGlKQ/khN/2dsb2JhbABZgwc1g3iFXbcRgRoWdIIkAQEBAyRVAQUqDRYLAgsDAgECASstAQcBARABBodgBgykSpFtjy8QgSgREIJfgTEDl26BLZA0gyA6gTU X-IronPort-AV: E=Sophos;i="4.89,951,1367971200"; d="scan'208,217";a="17482101" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 25 Aug 2013 15:13:56 +0000 Received: from mctiny.local ([10.61.174.183]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7PFDrwA018248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 15:13:53 GMT Message-ID: <521A1F31.8080402@cisco.com> Date: Sun, 25 Aug 2013 17:13:53 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: draft-ietf-spfbis-4408bis.all@tools.ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------050408030003090400090000" X-Mailman-Approved-At: Sun, 25 Aug 2013 08:59:12 -0700 Cc: spfbis@ietf.org, Apps Discuss , 'IESG' Subject: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 15:14:06 -0000 This is a multi-part message in MIME format. --------------050408030003090400090000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​ http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-spfbis-4408bis-19 Title: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 Reviewer: Eliot Lear Review Date: 25 Aug 2013 IETF Last Call Date: 19 Aug 2013 IESG Telechat Date: 12 Sep 2013 Summary: This draft is not yet ready for publication as a Proposed Standard and should be revised before publication. Major issues: 1. Deprecation of SPF record not properly justified in text and in the wrong place Deprecation of the SPF record is given short shrift in Section 13.1 which is the IANA considerations section. A persistent reader would not understand why the record was in fact deprecated. Here's what is 13.1 (there are a few words about 6686 in 3.1 as well, but nobody would care if this was simply a matter of low implementation/deployment). > Studies have shown that RRTYPE 99 has not seen any substantial use, > and in fact its existence and mechanism defined in [RFC4408] has led > to some interoperability issues. First, this text should be moved out of the IANA considerations sections and forward to Section 3.1. Second it should explain what those interoperability issues are or have a normative (and retrievable) reference. At the very least, the winning argument(s) should be elucidated, and not just for posterity: the claim is that there is an interoperability problem. If so, then might administrators want to know that? The matter of handling garbage in garbage out is not well enough specified in Section 3. I would go considerably further and state that (a) records that do not begin with "v=spf1" MUST NOT be processed further, and (b) that any record that does not conform to the stated grammar MUST be ignored. Also, did the working group consider a DKIM-like solution? They all but establish an _spf label in this document (I'll come to that in a moment). There is a general issue about when to deprecate an RR and the ability to add new RRs into the DNS. That issue has to be addressed in the longer term, no matter what the IESG and community decide here. Furthermore, to be clear, please do not read into the above comments an opinion about deprecation of the record itself, which I am withholding until there is clear text about the interoperability issues that are mentioned. 2. So-called "Utility Labels" Throughout the document _spf.example.com is used, as is the term "common utility labels". Maybe bind doesn't cough up blood on underscores, but this is also not what we would call a sanctioned practice by our RFCs. If this is truly first use (and I could be wrong), then the utility of utility labels need to be made clear. As this is, IMHO, *not* the focus of this standard, my suggestion would be to change the example. 3. Retain a summary of changes since 4408. A -bis document usually has a change list that can assist implementers familiar with previous work. Appendix J is pretty close to what I would want, but it needs some editing. Minor Issues: There are areas where the document seems to go to lengths to avoid the use of normative language. If either the WG or the IESG cares, I can go through a few that could stand to be MAYs, but here is but one example: > A mail receiver can perform a set of SPF checks for each mail message > it receives. As I say below, this text actually adds nothing to the document, but if the author decides to leave it in, this is a prime example of where MAY was intended to be useful. Similarly, there is the occasional "ought to", such as that found in Section 3. If the WG considered normative text and rejected it, fine. But if they didn't, they should. This is a complex specification, and our normative language definitions are there to provide clarity and consistency. Throughout the document is used as the macro expansion of . I don't recommend that. While much of SPF seems an exercise in indirection, the actual RFC should not be. Better to simply say " or its macro-expansion." And no, I wouldn't care about this in most documents, but the sheer number of forward and backward references in this document has me (and will have other readers) constantly flipping backward and forward. Section 2.2, 1st para > Typically, such checks are done > by a receiving MTA, but can be performed elsewhere in the mail > processing chain so long as the required information is available and > reliable People may infer a traipse through Received headers for HELO information. Is that the intent, and is that acceptable, given that they could be forged? My point: the above is vague. Section 2.5: title > 2.5. Location of Checks I don't think you mean location. I think you mean "When to perform checks". Section 4.7, 2nd para, 2nd sentence. > Although the latter > has a default (specifically "?all"), it aids debugging efforts if it > is explicitly provided. How does it aid in debugging? Section 5.6, ABNF: You've gone to some lengths to get ipv4 correct, but you don't do the same with CIDR prefixes. > ip4-cidr-length = "/" 1*DIGIT > ip6-cidr-length = "/" 1*DIGIT Strictly speaking the value range is from 1 to 32, for v4, and 1 to 128 for v6. This isn't quite all legal, but at least it's bounded: ip4-cidr-length = "/" 1*2DIGIT ; value must be > 0 and may not exceed 32 ip6-cidr-length = "/" 1*3DIGIT ; value must be > 0 may not exceed 128 You could do the same as you did with qnum, but perhaps that is overkill. Section 6.2, last para: The following text is confusing: > Note: During recursion into an "include" mechanism, an "exp" modifier > from the MUST NOT be used. In contrast, when executing > a "redirect" modifier, an "exp" modifier from the original domain > MUST NOT be used. When "MUST NOT be used" do you mean MUST NOT be evaluated or processed or MUST NOT be present in the record? e.g., does this MUST apply to operators, implementers, or both? Appendix A: > This section is normative and any discrepancies with the ABNF > fragments in the preceding text are to be resolved in favor of this > grammar. Normally we don't normatively reference Appendices, and it represents a bit of a cultural cognitive dissidence for some. One possible fix: don't make it an Appendix, but the last section. But also, Section 7.1 is entitled "Formal Specification". Don't have two of those. Appendix E: There's probably a case not covered here, but it's close. E.1 describes originating ADMD behavior. Think of the case of a university or professional organization that offers forwarding. The advice given in the first bullet of E.1 is probably applicable, but requires that a new whitelist entry be created for new aliases that contain new hosts on the RHS. I would go just that bit further to explain. Nits: Please stop creating acronyms. Spam = unsolicited bulk email. UBE is obfuscation in this case. Similarly, I'd ask the authors to trying speaking out loud "domain owning ADMDs,", expanding out the acronym. How about just saying "domain owners"? In general your definitions section is unnecessarily verbose and could go for a good "haircut". For example, how about these: Imported Definitions: * MAIL FROM: The RFC5321.MailFrom, as defined in [RFC5321] * HELO: The parameter specified in the HELO or EHLO commands as specified in [RFC5321]. Page 7, Section 1.2: This forward reference is unnecessary, and I would remove the section. 2.1 2nd para, 2nd sentence: > If ADMDs > choose to publish SPF records and want to support receivers making > negative authorization determinations, it is necessary for them to > publish records that end in "-all", or redirect to other records that > do, otherwise, no definitive determination of authorization can be > made. That's grammatically incorrect. Remove everything after "do," and you are fine. Same section further down, please clarify "While offline checks are possible". I think you mean "deferred" or "checks made after delivery" or some such. Section 2.2 first para, first sentence: > A mail receiver can perform a set of SPF checks for each mail message > it receives. What value does this sentence offer the reader? Personally I say none, and would remove. Section 5.4: "mx" > Then it performs an address lookup on each MX name returned. To be precise: "It then performs an address lookup on of the name found in the RDATA of each answer." Section 8.5, 2nd sentence: > The ADMD believes the host is not authorized but is not willing to > make a strong policy statement Which ADMD? Eliot --------------050408030003090400090000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-spfbis-4408bis-19
Title: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
Reviewer: Eliot Lear
Review Date: 25 Aug 2013
IETF Last Call Date: 19 Aug 2013
IESG Telechat Date: 12 Sep 2013

Summary: This draft is not yet ready for publication as a Proposed Standard and should be revised before publication.

Major issues:

1. Deprecation of SPF record not properly justified in text and in the wrong place

Deprecation of the SPF record is given short shrift in Section 13.1 which is the IANA considerations section.  A persistent reader would not understand why the record was in fact deprecated.  Here's what is 13.1 (there are a few words about 6686 in 3.1 as well, but nobody would care if this was simply a matter of low implementation/deployment).

   Studies have shown that RRTYPE 99 has not seen any substantial use,
   and in fact its existence and mechanism defined in [RFC4408] has led
   to some interoperability issues.

First, this text should be moved out of the IANA considerations sections and forward to Section 3.1.  Second it should explain what those interoperability issues are or have a normative (and retrievable) reference.  At the very least, the winning argument(s) should be elucidated, and not just for posterity: the claim is that there is an interoperability problem.  If so, then might administrators want to know that?

The matter of handling garbage in garbage out is not well enough specified in Section 3.  I would go considerably further and state that (a) records that do not begin with "v=spf1" MUST NOT be processed further, and (b) that any record that does not conform to the stated grammar MUST be ignored.  Also, did the working group consider a DKIM-like solution?  They all but establish an _spf label in this document (I'll come to that in a moment).

There is a general issue about when to deprecate an RR and the ability to add new RRs into the DNS.  That issue has to be addressed in the longer term, no matter what the IESG and community decide here.  Furthermore, to be clear, please do not read into the above comments an opinion about deprecation of the record itself, which I am withholding until there is clear text about the interoperability issues that are mentioned.

2.  So-called "Utility Labels"

Throughout the document _spf.example.com is used, as is the term "common utility labels".  Maybe bind doesn't cough up blood on underscores, but this is also not what we would call a sanctioned practice by our RFCs.  If this is truly first use (and I could be wrong), then the utility of utility labels need to be made clear.  As this is, IMHO, not the focus of this standard, my suggestion would be to change the example.

3.  Retain a summary of changes since 4408.

A -bis document usually has a change list that can assist implementers familiar with previous work.  Appendix J is pretty close to what I would want, but it needs some editing.

Minor Issues:

There are areas where the document seems to go to lengths to avoid the use of normative language.   If either the WG or the IESG cares, I can go through a few that could stand to be MAYs, but here is but one example:

   A mail receiver can perform a set of SPF checks for each mail message
   it receives. 
As I say below, this text actually adds nothing to the document, but if the author decides to leave it in, this is a prime example of where MAY was intended to be useful.

Similarly, there is the occasional "ought to", such as that found in Section 3.  If the WG considered normative text and rejected it, fine.  But if they didn't, they should.  This is a complex specification, and our normative language definitions are there to provide clarity and consistency.

Throughout the document <target-name> is used as the macro expansion of <domain-spec>.  I don't recommend that.  While much of SPF seems an exercise in indirection, the actual RFC should not be.  Better to simply say "<domain-spec> or its macro-expansion."  And no, I wouldn't care about this in most documents, but the sheer number of forward and backward references in this document has me (and will have other readers) constantly flipping backward and forward.

Section 2.2, 1st para

   Typically, such checks are done
   by a receiving MTA, but can be performed elsewhere in the mail
   processing chain so long as the required information is available and
   reliable
People may infer a traipse through Received headers for HELO information.  Is that the intent, and is that acceptable, given that they could be forged?  My point: the above is vague.

Section 2.5: title

2.5.  Location of Checks
I don't think you mean location.  I think you mean "When to perform checks".

Section 4.7, 2nd para, 2nd sentence.

   Although the latter
   has a default (specifically "?all"), it aids debugging efforts if it
   is explicitly provided.

How does it aid in debugging?

Section 5.6, ABNF:

You've gone to some lengths to get ipv4 correct, but you don't do the same with CIDR prefixes.

   ip4-cidr-length  = "/" 1*DIGIT
   ip6-cidr-length  = "/" 1*DIGIT
Strictly speaking the value range is from 1 to 32, for v4, and 1 to 128 for v6.  This isn't quite all legal, but at least it's bounded:

    ip4-cidr-length = "/" 1*2DIGIT ; value must be > 0 and may not exceed 32
    ip6-cidr-length = "/" 1*3DIGIT ; value must be > 0 may not exceed 128

You could do the same as you did with qnum, but perhaps that is overkill.

Section 6.2, last para:

The following text is confusing:

   Note: During recursion into an "include" mechanism, an "exp" modifier
   from the <target-name> MUST NOT be used.  In contrast, when executing
   a "redirect" modifier, an "exp" modifier from the original domain
   MUST NOT be used.

When "MUST NOT be used" do you mean MUST NOT be evaluated or processed or MUST NOT be present in the record?  e.g., does this MUST apply to operators, implementers, or both?

Appendix A:

   This section is normative and any discrepancies with the ABNF
   fragments in the preceding text are to be resolved in favor of this
   grammar.
Normally we don't normatively reference Appendices, and it represents a bit of a cultural cognitive dissidence for some.  One possible fix: don't make it an Appendix, but the last section.  But also, Section 7.1 is entitled "Formal Specification".  Don't have two of those.

Appendix E:

There's probably a case not covered here, but it's close.  E.1 describes originating ADMD behavior.  Think of the case of a university or professional organization that offers forwarding.  The advice given in the first bullet of E.1 is probably applicable, but requires that a new whitelist entry be created for new aliases that contain new hosts on the RHS.  I would go just that bit further to explain.

Nits:

Please stop creating acronyms.  Spam = unsolicited bulk email.  UBE is obfuscation in this case.  Similarly, I'd ask the authors to trying speaking out loud "domain owning ADMDs,", expanding out the acronym.  How about just saying "domain owners"?

In general your definitions section is unnecessarily verbose and could go for a good "haircut".  For example, how about these:

Imported Definitions:

  • MAIL FROM: The RFC5321.MailFrom, as defined in [RFC5321]
  • HELO: The parameter specified in the HELO or EHLO commands as specified in [RFC5321].

Page 7, Section 1.2:

This forward reference is unnecessary, and I would remove the section.


2.1 2nd para, 2nd sentence:

If ADMDs
   choose to publish SPF records and want to support receivers making
   negative authorization determinations, it is necessary for them to
   publish records that end in "-all", or redirect to other records that
   do, otherwise, no definitive determination of authorization can be
   made. 

That's grammatically incorrect.  Remove everything after "do," and you are fine.



Same section further down, please clarify "While offline checks are possible".  I think you mean "deferred" or "checks made after delivery" or some such.

Section 2.2 first para, first sentence:

   A mail receiver can perform a set of SPF checks for each mail message
   it receives. 

What value does this sentence offer the reader?  Personally I say none, and would remove.

Section 5.4: "mx"

Then it performs an address lookup on each MX name returned.

To be precise:

"It then performs an address lookup on of the name found in the RDATA of each answer."

Section 8.5, 2nd sentence:

The ADMD believes the host is not authorized but is not willing to make a strong policy statement

Which ADMD?

Eliot

--------------050408030003090400090000-- From sm@elandsys.com Sun Aug 25 09:01:01 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 EFB0621F9D4C for ; Sun, 25 Aug 2013 09:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.361 X-Spam-Level: X-Spam-Status: No, score=-102.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 AewQQo94wd2I for ; Sun, 25 Aug 2013 09:00:58 -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 569A321F9D56 for ; Sun, 25 Aug 2013 09:00:38 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.135.173]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7PG0IvZ009518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 09:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377446435; bh=jvpJ/FwJgDxuQ30C0mogdS/Vn14/mUOMpDh4yBMoxXY=; h=Date:To:From:Subject:In-Reply-To:References; b=GV+EZ2s7TcC62LE2N7Cn7baBnuJQV5FNmSJjY9EAf45jN75MLk6nSXMNUkftUz8OJ G4XAY+O4dhw0gsUK7CVqhukm2sNXtWR92WIuPXQ/E+3YZph1S+/2/NEbc0WkhvtTzP yTCHuLAszdeTwY5NKzccn9M6vgMw1K/+3VjwplaM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377446435; i=@elandsys.com; bh=jvpJ/FwJgDxuQ30C0mogdS/Vn14/mUOMpDh4yBMoxXY=; h=Date:To:From:Subject:In-Reply-To:References; b=uf0IM2b1X84XAohBSeE8YJ8BbIntpsACi+Ht5nlMptDuBNXkeogGJPTqn4IbHblvM DiQByWI+n2oP7Z8Vww9NHBAvzoBWSz+MxniiS3grZMm3mvlcIX1RPvdx3KpM6JMqG6 ZNcfeP5HBl2mqbhUjrnXgytpztD7EZd7TvSXd1P0= Message-Id: <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 25 Aug 2013 08:58:15 -0700 To: spfbis@ietf.org, Scott Kitterman From: S Moonesamy In-Reply-To: <521A1F31.8080402@cisco.com> References: <521A1F31.8080402@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 16:01:01 -0000 Hello, I'll comment about the Applications Directorate Review. At 08:13 25-08-2013, Eliot Lear wrote: >Summary: This draft is not yet ready for=20 >publication as a Proposed Standard and should be revised before= publication. > >Major issues: > >1. Deprecation of SPF record not properly=20 >justified in text and in the wrong place >Deprecation of the SPF record is given short=20 >shrift in Section 13.1 which is the IANA=20 >considerations section. A persistent reader=20 >would not understand why the record was in fact=20 >deprecated. Here's what is 13.1 (there are a=20 >few words about 6686 in 3.1 as well, but nobody=20 >would care if this was simply a matter of low implementation/deployment). > >> Studies have shown that RRTYPE 99 has not seen any substantial use, >> and in fact its existence and mechanism defined in [RFC4408] has led >> to some interoperability issues. > >First, this text should be moved out of the IANA=20 >considerations sections and forward to Section=20 >3.1. Second it should explain what those=20 >interoperability issues are or have a normative=20 >(and retrievable) reference. At the very least,=20 >the winning argument(s) should be elucidated,=20 >and not just for posterity: the claim is that=20 >there is an interoperability problem. If so,=20 >then might administrators want to know that? The above refers to the second paragraph of=20 Section 13.1 of draft-ietf-spfbis-4408bis-19. In=20 my opinion the reviewer is correct in his comment=20 about the text in IANA Considerations=20 Section. If anyone disagrees with that I suggest=20 that the person explains why the text has to be in that section. Section 3.1 of draft-ietf-spfbis-4408bis-19 mentions that: "Use of alternative DNS RR types was supported in SPF's experimental phase, but has been discontinued. See Appendix A of [RFC6686] for further information." The explanation in RFC 6686 is: "[SPF] itself included a faulty transition plan, likely because of the late addition of a requirement to develop one -- it said: An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at least one type. which means both can claim to be fully compliant while failing utterly to interoperate. Publication occurred without proper IETF review, so this was not detected prior to publication." What is the interoperability issue? >The matter of handling garbage in garbage out is=20 >not well enough specified in Section 3. I would=20 >go considerably further and state that (a)=20 >records that do not begin with "v=3Dspf1" MUST NOT=20 >be processed further, and (b) that any record=20 >that does not conform to the stated grammar MUST be > ignored. Also, did the working group consider=20 > a DKIM-like solution? They all but establish=20 > an _spf label in this document (I'll come to that in a moment). Can the working group please comment about the above? The working group did not discuss about a=20 DKIM-like solution. There is a thread at=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg03963.html >There is a general issue about when to deprecate=20 >an RR and the ability to add new RRs into the=20 >DNS. That issue has to be addressed in the=20 >longer term, no matter what the IESG and=20 >community decide here. Furthermore, to be=20 >clear, please do not read into the above=20 >comments an opinion about deprecation of the=20 >record itself, which I am withholding until=20 >there is clear text about the interoperability issues that are mentioned. I'll wait for the working group to comment. >2. So-called "Utility Labels" > >Throughout the document _spf.example.com is=20 >used, as is the term "common utility=20 >labels". Maybe bind doesn't cough up blood on=20 >underscores, but this is also not what we would=20 >call a sanctioned practice by our RFCs. If this=20 >is truly first use (and I could be wrong), then=20 >the utility of utility labels need to be made=20 >clear. As this is, IMHO, not the focus of this=20 >standard, my suggestion would be to change the example. I'll wait for the working group to comment. >3. Retain a summary of changes since 4408. > >A -bis document usually has a change list that=20 >can assist implementers familiar with previous=20 >work. Appendix J is pretty close to what I=20 >would want, but it needs some editing. Scott, can you look into this? >Minor Issues: > >There are areas where the document seems to go=20 >to lengths to avoid the use of normative=20 >language. If either the WG or the IESG cares, I=20 >can go through a few that could stand to be MAYs, but here is but one= example: >> A mail receiver can perform a set of SPF checks for each mail message >> it receives. >As I say below, this text actually adds nothing=20 >to the document, but if the author decides to=20 >leave it in, this is a prime example of where MAY was intended to be= useful. I'll wait for the working group to comment. >Similarly, there is the occasional "ought to",=20 >such as that found in Section 3. If the WG=20 >considered normative text and rejected it,=20 >fine. But if they didn't, they should. This is=20 >a complex specification, and our normative=20 >language definitions are there to provide clarity and consistency. The answer I suggest for this one is the restrictions in the charter. >Throughout the document is used as=20 >the macro expansion of . I don't=20 >recommend that. While much of SPF seems an=20 >exercise in indirection, the actual RFC should=20 >not be. Better to simply say " or=20 >its macro-expansion." And no, I wouldn't care=20 >about this in most documents, but the sheer=20 >number of forward and backward references in=20 >this document has me (and will have other=20 >readers) constantly flipping backward and forward. I'll wait for the working group to comment. >Section 2.2, 1st para > >> Typically, such checks are done >> by a receiving MTA, but can be performed elsewhere in the mail >> processing chain so long as the required information is available and >> reliable >People may infer a traipse through Received=20 >headers for HELO information. Is that the=20 >intent, and is that acceptable, given that they=20 >could be forged? My point: the above is vague. I'll wait for the working group to comment. >Section 2.5: title > >>2.5.=C2 Location of Checks >I don't think you mean location. I think you mean "When to perform= checks". > >Section 4.7, 2nd para, 2nd sentence. > >> Although the latter >> has a default (specifically "?all"), it aids debugging efforts if it >> is explicitly provided. > >How does it aid in debugging? I'll wait for the working group to comment. >Section 5.6, ABNF: > >You've gone to some lengths to get ipv4 correct,=20 >but you don't do the same with CIDR prefixes. > >> ip4-cidr-length =3D "/" 1*DIGIT >> ip6-cidr-length =3D "/" 1*DIGIT >Strictly speaking the value range is from 1 to=20 >32, for v4, and 1 to 128 for v6. This isn't=20 >quite all legal, but at least it's bounded: > > ip4-cidr-length =3D "/" 1*2DIGIT ; value must be > 0 and may not= exceed 32 > ip6-cidr-length =3D "/" 1*3DIGIT ; value must be > 0 may not exceed= 128 > >You could do the same as you did with qnum, but perhaps that is overkill. I suggest considering this change. >Section 6.2, last para: > >The following text is confusing: > >> Note: During recursion into an "include" mechanism, an "exp" modifier >> from the MUST NOT be used. In contrast, when executing >> a "redirect" modifier, an "exp" modifier from the original domain >> MUST NOT be used. > >When "MUST NOT be used" do you mean MUST NOT be=20 >evaluated or processed or MUST NOT be present in=20 >the record? e.g., does this MUST apply to operators, implementers, or= both? I'll wait for the working group to comment. >Appendix A: > >> This section is normative and any discrepancies with the ABNF >> fragments in the preceding text are to be resolved in favor of this >> grammar. >Normally we don't normatively reference=20 >Appendices, and it represents a bit of a=20 >cultural cognitive dissidence for some. One=20 >possible fix: don't make it an Appendix, but the=20 >last section. But also, Section 7.1 is entitled=20 >"Formal Specification". Don't have two of those. I suggest moving Appendix A to a section. >Appendix E: > >There's probably a case not covered here, but=20 >it's close. E.1 describes originating ADMD=20 >behavior. Think of the case of a university or=20 >professional organization that offers=20 >forwarding. The advice given in the first=20 >bullet of E.1 is probably applicable, but=20 >requires that a new whitelist entry be created=20 >for new aliases that contain new hosts on the=20 >RHS. I would go just that bit further to explain. I'll wait for the working group to comment. >Nits: >Please stop creating acronyms. Spam =3D=20 >unsolicited bulk email. UBE is obfuscation in=20 >this case. Similarly, I'd ask the authors to=20 >trying speaking out loud "domain owning ADMDs,",=20 >expanding out the acronym. How about just saying "domain owners"? > >In general your definitions section is=20 >unnecessarily verbose and could go for a good=20 >"haircut". For example, how about these: > >Imported Definitions: >MAIL FROM: The RFC5321.MailFrom, as defined in [RFC5321] >HELO: The parameter specified in the HELO or=20 >EHLO commands as specified in [RFC5321]. > >Page 7, Section 1.2: > >This forward reference is unnecessary, and I would remove the section. > >2.1 2nd para, 2nd sentence: > >>If ADMDs >> choose to publish SPF records and want to support receivers making >> negative authorization determinations, it is necessary for them to >> publish records that end in "-all", or redirect to other records that >> do, otherwise, no definitive determination of authorization can be >> made. > >That's grammatically incorrect.=C2 Remove=20 >everything after "do," and you are fine. > >Same section further down, please clarify "While=20 >offline checks are possible". I think you mean=20 >"deferred" or "checks made after delivery" or some such. > >Section 2.2 first para, first sentence: >> A mail receiver can perform a set of SPF checks for each mail message >> it receives. > >What value does this sentence offer the=20 >reader? Personally I say none, and would remove. > >Section 5.4: "mx" > >>Then it performs an address lookup on each MX name returned. > >To be precise: > >"It then performs an address lookup on of the=20 >name found in the RDATA of each answer." > >Section 8.5, 2nd sentence: > >>The ADMD believes the host is not authorized=20 >>but is not willing to make a strong policy statement > >Which ADMD? Please comment about the above. Regards, S. Moonesamy=20 From ajs@anvilwalrusden.com Sun Aug 25 09:16: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 C9ED721F9D62 for ; Sun, 25 Aug 2013 09:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.83 X-Spam-Level: X-Spam-Status: No, score=-0.83 tagged_above=-999 required=5 tests=[AWL=0.010, 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 amIehcCLZ5bO for ; Sun, 25 Aug 2013 09:16:07 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 01AB521F9D5C for ; Sun, 25 Aug 2013 09:16:06 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 4B1698A031 for ; Sun, 25 Aug 2013 16:16:05 +0000 (UTC) Date: Sun, 25 Aug 2013 12:16:03 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130825161603.GB8259@mx1.yitter.info> References: <521A1F31.8080402@cisco.com> <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 16:16:12 -0000 No hat. On Sun, Aug 25, 2013 at 08:58:15AM -0700, S Moonesamy wrote: > The explanation in RFC 6686 is: > > "[SPF] itself included a faulty transition plan, likely because of > the late addition of a requirement to develop one -- it said: > > An SPF-compliant domain name SHOULD have SPF records of both RR > types. A compliant domain name MUST have a record of at least > one type. > > which means both can claim to be fully compliant while failing > utterly to interoperate. Publication occurred without proper > IETF review, so this was not detected prior to publication." > > What is the interoperability issue? I guess the WG sort of hoped that readers would be able to do elementary entailment for themselves. It says that two implementations might follow the same MUST and decide for their own reasons that the SHOULD cannot be met. By implication, they could pick different results of the MUST, and they wouldn't interoperate. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Sun Aug 25 09:23:40 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 1E0FE21F9D1C; Sun, 25 Aug 2013 09:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.831 X-Spam-Level: X-Spam-Status: No, score=-0.831 tagged_above=-999 required=5 tests=[AWL=0.009, 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 lCfT2y3u+Zh8; Sun, 25 Aug 2013 09:23:34 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 50C0521F8E40; Sun, 25 Aug 2013 09:23:34 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 93CEF8A031; Sun, 25 Aug 2013 16:23:33 +0000 (UTC) Date: Sun, 25 Aug 2013 12:23:32 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org, spfbis@ietf.org, iesg@ietf.org Message-ID: <20130825162331.GC8259@mx1.yitter.info> References: <521A1F31.8080402@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <521A1F31.8080402@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] [apps-discuss] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 16:23:40 -0000 No hat. On Sun, Aug 25, 2013 at 05:13:53PM +0200, Eliot Lear wrote: > 2. So-called "Utility Labels" > > Throughout the document _spf.example.com is used, as is the term "common > utility labels". Maybe bind doesn't cough up blood on underscores, but > this is also not what we would call a sanctioned practice by our RFCs. > If this is truly first use (and I could be wrong), then the utility of > utility labels need to be made clear. As this is, IMHO, *not* the focus > of this standard, my suggestion would be to change the example. I don't think I understand this critique, but I think your claim is that underscores are somehow not scanctioned by RFC. I think you are mistaken about this. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Sun Aug 25 09:40: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 39EC621F98AC for ; Sun, 25 Aug 2013 09:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 xRyqESriouQz for ; Sun, 25 Aug 2013 09:40:27 -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 E36BB21F9B0D for ; Sun, 25 Aug 2013 09:40:19 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.135.173]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7PGe5jG010406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 09:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377448817; bh=xqLJ9vDFns6IMLsSpz6NDubsoYxf1aumS2E5qeiALHY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OA9ZKOL86jZ372Zz4g2573cftMgCwgyI9/06vEP3pvssvIgbdqwQBETKWc4IMOWiq BHuSeGfiGiw0m/eBgJ+V6V4mHjePczSpB6tShfbsX84w2ZVXN5WZdq+jATw6MzxaxJ wNLAQFPAMVHUquSI/9RxMLZ8NS8lAU+x14EEvDoU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377448817; i=@elandsys.com; bh=xqLJ9vDFns6IMLsSpz6NDubsoYxf1aumS2E5qeiALHY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=d5FyPTROtKOuRvA+UZuEt1XNSP+6shtcB1udpk3mFrVqzsJfVrbD+vpLvTgPzjIK0 wchw/90+VsT7HkNSooeFC4Ea48Ur+a27WzE/7lO5maPSmyF31oxSfvboY4uCSzXMCm 4oafm38oW0fwYkxz3uP+N8XgYo8J5Y17lEvvRy0k= Message-Id: <6.2.5.6.2.20130825092522.0ae97f78@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 25 Aug 2013 09:39:15 -0700 To: Andrew Sullivan From: S Moonesamy In-Reply-To: <20130825161603.GB8259@mx1.yitter.info> References: <521A1F31.8080402@cisco.com> <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> <20130825161603.GB8259@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 16:40:28 -0000 Hi Andrew, At 09:16 25-08-2013, Andrew Sullivan wrote: >No hat. [snip] >I guess the WG sort of hoped that readers would be able to do >elementary entailment for themselves. It says that two >implementations might follow the same MUST and decide for their own >reasons that the SHOULD cannot be met. By implication, they could >pick different results of the MUST, and they wouldn't interoperate. Thanks, I understand what you wrote. I think what the APPSDIR reviewer is asking for is to document the issue so that an administrator can understand the interoperability problem. As an alternative I suggest explaining it in terms of SPF publisher and SPF verifier. Regards, S. Moonesamy From johnl@iecc.com Sun Aug 25 10:58:54 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 306F221F8E70 for ; Sun, 25 Aug 2013 10:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 FeU1H26dNeHo for ; Sun, 25 Aug 2013 10:58:50 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8C79F21F866E for ; Sun, 25 Aug 2013 10:58:48 -0700 (PDT) Received: (qmail 79546 invoked from network); 25 Aug 2013 17:58:46 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Aug 2013 17:58:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521a45d6.xn--i8sz2z.k1308; i=johnl@user.iecc.com; bh=SJs2DXScHNvfw/x3NsRuNwCeJrzKtlkNwAIB1AyzsyQ=; b=nvdMcnwbAIfTXyjZk+48FELvBFOwRiOoKd3LXqji66w+xZY1bC+CJx3DR9mmR5p+HiWX1CQZXHkecp6pB77sisDXsp59thrWsnmFaDU4vMPXyythKu9nPdGxy1Uv07EZCBCuwL6SuYkT6KPvcrwCaPvO5lrxRONCq5tCRf1nk0Y3hEycECCBfK8YVYgoPOc+s7tAITxGcp3dq/HuzA5Ot9DA9qlTnlcVP1HwXaxOo86xe7SfJIbeDr3yv7c02MPu DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521a45d6.xn--i8sz2z.k1308; olt=johnl@user.iecc.com; bh=SJs2DXScHNvfw/x3NsRuNwCeJrzKtlkNwAIB1AyzsyQ=; b=o+NdvNNzzVOvkigR3gVK2L0D3aMr7E3Q57c3V3F/Z5xuIFznbcS78OW/dOg2YhsPX+tyIaeZCTAqV9tZPglylRZ8rw5ffiyJWDxF3x82w0JkNWrQ8mGnAPpj1K3Ux5C3/hlXGPRdPeY0NUh8ZszRNiD1v+M/ZHJDxqU2lCwEg9FToDAQqyNloYususKpJtsuXIA4zWSQqXe8KTq7CRadF1X0S20bfbYqZ13pvCu/tomLwYPXDDsfOr/GnmoUy3m0 Date: 25 Aug 2013 17:58:24 -0000 Message-ID: <20130825175824.68451.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [spfbis] Applications Directorate Review: deprecation 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, 25 Aug 2013 17:58:54 -0000 [ I'm breaking this up into separate messages so there can be separate threads ] >>1. Deprecation of SPF record not properly >>justified in text and in the wrong place >>Deprecation of the SPF record is given short >>shrift in Section 13.1 which is the IANA >>considerations section. A persistent reader >>would not understand why the record was in fact >>deprecated. I don't understand the issue. It has always been my impression that the point of a standards track RFC is to tell readers how to implement the spec so it'll interoperate, not to document the history of how it got there. Five years from now, it's hard to imagine that people reading the RFC will want to know about the current food fight. Or if they do, that's why we have mailing list archives. I agree that the discussion would better be in the appendix about post-4408 changes, perhaps with a sentence noting that 4408 had inconsistent instructions about publishing and checking type 99 records, which would have caused interop problems if anyone had actually followed them. R's, John From johnl@iecc.com Sun Aug 25 11:10: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 3174621F9D70 for ; Sun, 25 Aug 2013 11:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 VqWUb-Ziw3mc for ; Sun, 25 Aug 2013 11:10:01 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9B45321F9D69 for ; Sun, 25 Aug 2013 11:10:00 -0700 (PDT) Received: (qmail 82170 invoked from network); 25 Aug 2013 18:09:59 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Aug 2013 18:09:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521a4877.xn--yuvv84g.k1308; i=johnl@user.iecc.com; bh=1x0ELR3iDwpKAfG+FWxjq4Pob0WE6Cdp9nFfK0BrJb8=; b=QxROCsu1alAx2gYlHRJmtwGSyHISyD3I0yc4u7QgomTFHT77/o5SfT82dvb+1zP6DhrC3x0RZQUJPpVgDDZ/0BU22Sef84vGBY+lCumg/+XDReMOwEgN1JpHOguAmkT1VA7W23tpMf+8acjnZpPkSr7iWZBEJAEZ00Y3Kob03/fE17bw6biDrKl3SxjNE0gJzLoeM7fm51dBOlZVPO7ddJW5Rf1mtbqudHeWXKP4PwNYDXFUnYRL9A0VRh81uPRr DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521a4877.xn--yuvv84g.k1308; olt=johnl@user.iecc.com; bh=1x0ELR3iDwpKAfG+FWxjq4Pob0WE6Cdp9nFfK0BrJb8=; b=dD0HmNY7+O5ZHl6c57dkGIy9j8cPz94OK2eM6eFGinFwrRcaLZWZ790ux2thfcUvgG1BPnAF3bkxA5YO3NtIjZl3jiDB/zCdoDU53+a9di5kWLcAdC26aJfjh/x8dZ0CRKD9WoEKW2LiVQ4HuHjoR3JHkcEOtHwnuesjso6BLc1M/flDj3Xr7GOicaiT2Cax/8+m4T2JdaghFm9Dek8clBUARR35srD6NOiJaLxiHvyd4ua95ry9b1ETgbP+nBit Date: 25 Aug 2013 18:09:36 -0000 Message-ID: <20130825180936.68506.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [spfbis] Applications Directorate Review: record selection 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, 25 Aug 2013 18:10:05 -0000 >>The matter of handling garbage in garbage out is >>not well enough specified in Section 3. I would >>go considerably further and state that (a) >>records that do not begin with "v=spf1" MUST NOT >>be processed further, and (b) that any record >>that does not conform to the stated grammar MUST be >>ignored. The (a) part is in there now, or if it's not, that's what the wording is supposed to mean. (Actually, it's "v=spf1 " with a following space.) The (b) is more of a can of worms than you might think. Many implementations interpret SPF records incrementally and stop as soon as they have a result. If there are syntax errors farther along, or in included records referenced farther along, they don't care and often don't even notice. This change would likely present an interop issue by requiring changes in behavior by systems using existing libraries that interpret SPF incrementally, which I think is most of them. Standards don't usually offer detailed advice about what to do if the other end screws up, and I don't see any reason to do that here. If you want to interoperate, publish correct SPF. If you don't, you take your chances. R's, John From johnl@iecc.com Sun Aug 25 11:32: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 60C2E21F9D17 for ; Sun, 25 Aug 2013 11:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.618 X-Spam-Level: X-Spam-Status: No, score=-102.618 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 TtBJOSSYUMYD for ; Sun, 25 Aug 2013 11:32:24 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B5E2021F9D75 for ; Sun, 25 Aug 2013 11:32:23 -0700 (PDT) Received: (qmail 87191 invoked from network); 25 Aug 2013 18:32:20 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Aug 2013 18:32:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521a4db4.xn--3zv.k1308; i=johnl@user.iecc.com; bh=7+Ecq3Vqbg+LGy5osfTljJmm+q0X7OT13+nj1hlUdKA=; b=HhTiL9jtZ/s4vexODBcof7V9B4t50YaO4yLzDdfSwc/0E/3DV12SIHzk+kDXWVokDSBgGik4YZKEE/rEMrauIs4BBIbB9VxygeCD1XRGoa/JonQfl/pSIZFJJv9Gh2hyFvzjsLo6pgmxmF+qXctQoXSGSYeQLsc8UcnzoN0YEyp8J15Q/FFF/Bd8nI0sHdWXAPOrwWotpUhV4BUkf0/SRfiAffBQNW648BgGFcdlnb4F0uzS7hNMOAEwz5LER9bv DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521a4db4.xn--3zv.k1308; olt=johnl@user.iecc.com; bh=7+Ecq3Vqbg+LGy5osfTljJmm+q0X7OT13+nj1hlUdKA=; b=NTMBST+KUt+utZsSObBp/V2Ck0e2TR+0I7kx8p7J0EYMoGqK3fyvJ64SGl6NsM4ptBcC266DJaS7zEX5o/IH6+QpfzuIZtWWycvPLjye6J63LiUviBTjb5exNN61KzGm8BoOv2SOm7JribfdfUrK5T5kAG0nXG1aFWBXqqDc6oi1aqAOHJLwEeEHWMcMK7lufpYmXICmxsUZxiCHZXLtDBVGeWm95UBs5eLm3b60VvjjPHQ+SftSENqOr88ZHxvS Date: 25 Aug 2013 18:31:58 -0000 Message-ID: <20130825183158.68589.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [spfbis] Applications Directorate Review: prefixed records 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, 25 Aug 2013 18:32:28 -0000 >> Also, did the working group consider >> a DKIM-like solution? They all but establish >> an _spf label in this document (I'll come to that in a moment). >>2. So-called "Utility Labels" >> >>Throughout the document _spf.example.com is >>used, as is the term "common utility >>labels". Maybe bind doesn't cough up blood on >>underscores, but this is also not what we would >>call a sanctioned practice by our RFCs. If this >>is truly first use (and I could be wrong), then >>the utility of utility labels need to be made >>clear. As this is, IMHO, not the focus of this >>standard, my suggestion would be to change the example. To the first part, Scott says they considered an _spf prefix back in 2003 and rejected it because a decade ago too much provisioning crudware choked on underscores. That problem is long gone, but changing the initial lookup name now would be a huge and extremely incompatible change both to the spec and to existing practice. It's true that some SPF records redirect to _spf.name, but most don't, or include multiple names with various names and prefixes. See the SPF for google.com and hotmail.com for examples. As far as underscored names not being sanctioned, I don't understand that at all. Underscores aren't valid in hostnames, but they are entirely valid and widely used in non-host names. I suppose it might be worth mentioning that the targets of include: and redirect= need not be hostnames, and if the target name isn't intended to be one that sends mail, it's better if it's not. R's, John PS: Re changes to the spec and to practice, deprecating type 99 is a somewhat significant change to the spec, but an insignificant change to existing practice because everyone publishes and checks TXT now. Nobody checks _spf. now. From sm@elandsys.com Sun Aug 25 11:41: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 12E4321F9D95 for ; Sun, 25 Aug 2013 11:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 URc1T2bG5a0N for ; Sun, 25 Aug 2013 11:41: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 4C32221F9D96 for ; Sun, 25 Aug 2013 11:41:11 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.135.173]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7PIewXq003164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 11:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377456070; bh=6fB9K7sPxW2TMdOFajGMweptvF52m0xm91zFJ/oyjuw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RIOd1mNEOlhDjEiXy5JHxC4X6jH2Sw8PjT7gtOYXkZseTdJri6wJLQ2HJWxhHBoo8 dOS0bfUhBOWmZUdIBlg+yuGwo5n2/VqyeZHU2cAOoqGEPW04XLDaEEwat2O+vUuOo9 i05u7orOJLgqZOB3RmFuLjrpI566M43Pdm1fsKGw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377456070; i=@elandsys.com; bh=6fB9K7sPxW2TMdOFajGMweptvF52m0xm91zFJ/oyjuw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FuFHcRj6y0Yu0Q31zOG98fQrvM70VBQxGm0D+GWHh54B2dqYGv9PxKbluKRxDOxQN 6OOxW3qqc4YS0wuw8VnypE3nVZ01dn717Q90rqNbidh0lV/Olr8rB+aPj6mZPqjp+7 8ZMhCA2NA9/WNBQsPtcV5jJM3Qhx9xipfa7ZlukY= Message-Id: <6.2.5.6.2.20130825111105.0af1d550@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 25 Aug 2013 11:40:21 -0700 To: John Levine From: S Moonesamy In-Reply-To: <20130825175824.68451.qmail@joyce.lan> References: <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> <20130825175824.68451.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review: deprecation 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, 25 Aug 2013 18:41:15 -0000 Hi John, At 10:58 25-08-2013, John Levine wrote: > [ I'm breaking this up into separate messages so there can be > separate threads ] Thanks, it makes the discussion easier. > >>1. Deprecation of SPF record not properly > >>justified in text and in the wrong place > >>Deprecation of the SPF record is given short > >>shrift in Section 13.1 which is the IANA > >>considerations section. A persistent reader > >>would not understand why the record was in fact > >>deprecated. > >I don't understand the issue. It has always been my impression that >the point of a standards track RFC is to tell readers how to implement >the spec so it'll interoperate, not to document the history of how it >got there. Five years from now, it's hard to imagine that people >reading the RFC will want to know about the current food fight. Or if >they do, that's why we have mailing list archives. > >I agree that the discussion would better be in the appendix about >post-4408 changes, perhaps with a sentence noting that 4408 had >inconsistent instructions about publishing and checking type 99 >records, which would have caused interop problems if anyone had >actually followed them. The depreciation of SPF RR is a bit convoluted. The SPF specification is no longer using SPF RR. Section 13.1 is the requested IANA action to mark it as obsolete. The working group does not have text in other sections of the draft to explain why the SPF RR is no longer needed. What Eliot may be saying is to have some text in another section about that. The interoperability problem could be separated from the depreciation of the SPF record. The explanation could be in an appendix. Regards, S. Moonesamy From johnl@iecc.com Sun Aug 25 11:41:51 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 E66F821F9D98 for ; Sun, 25 Aug 2013 11:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.618 X-Spam-Level: X-Spam-Status: No, score=-102.618 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 f0s6L7p0t16n for ; Sun, 25 Aug 2013 11:41:47 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 54DD221F9D96 for ; Sun, 25 Aug 2013 11:41:47 -0700 (PDT) Received: (qmail 89244 invoked from network); 25 Aug 2013 18:41:46 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Aug 2013 18:41:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521a4fea.xn--9vv.k1308; i=johnl@user.iecc.com; bh=navA4wrurYhORwUXntofHMC9eIM/4ZVqQ87sTEdulWk=; b=uzSoLODQoId3Kbn/O2Cva9ezxw7/4+CH/zXm0Xk3fjH2rYNlvhdJTt6n6/3FQzdci0VG7yqnr1TqU6HnVd8Kc1NqSrkoiCSGsjM8bW7IoMP4sJ9rOccPklzy7nnMCQA21LzWycD9ep/3RSdDDQ/epFxtUqiblcev95/xCmQJlc9X9iJpDPrUCaUeLS8kJqAcT7SiWkgsiH6mUKvHozEDEwYeLF/HtBtkbmqseVJ3UOQZnSmi8uI4d4w/L+9Q4rFv DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521a4fea.xn--9vv.k1308; olt=johnl@user.iecc.com; bh=navA4wrurYhORwUXntofHMC9eIM/4ZVqQ87sTEdulWk=; b=HH+POwgmYylQM/V5Dqp3cWmFmEjYxc2HX1dKNWGaWZ1L8G1xkiXPHl0YS083dR5C4RIWfC4J89h4vSTEsJISaSO7rnHY86Fep5rQw96wb3Ckeny9R6T5sd5ICk2p2aMsESQF2dkdNDFqohHTLpBoDe9J0zWXOyntiW/Xx0Fi3ja1wIAKDETZAd12uj823BuQpiyXaXyGD3MZpyXoqMMUrtjiLucMYvQuZEIBeZ+MSalSkqT7AGq2AByNTunGwObx Date: 25 Aug 2013 18:41:24 -0000 Message-ID: <20130825184124.68628.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [spfbis] Applications Directorate Review: editing issues 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, 25 Aug 2013 18:41:52 -0000 >>There are areas where the document seems to go >>to lengths to avoid the use of normative >>language. If either the WG or the IESG cares, I >>can go through a few that could stand to be MAYs, but here is but one example: >>> A mail receiver can perform a set of SPF checks for each mail message >>> it receives. >>As I say below, this text actually adds nothing >>to the document, but if the author decides to >>leave it in, this is a prime example of where MAY was intended to be useful. >>Similarly, there is the occasional "ought to", >>such as that found in Section 3. If the WG >>considered normative text and rejected it, >>fine. But if they didn't, they should. This is >>a complex specification, and our normative >>language definitions are there to provide clarity and consistency. >> etc. I agree that the document is not fabulously written, inheriting that problem from 4408, but we had significant concerns about rewrites changing the semantics. I'd be willing to take a whack at it, but it's hard to do and not run the risk of screwing something up. >>> Typically, such checks are done >>> by a receiving MTA, but can be performed elsewhere in the mail >>> processing chain so long as the required information is available and >>> reliable >>People may infer a traipse through Received >>headers for HELO information. Is that the >>intent, and is that acceptable, given that they >>could be forged? My point: the above is vague. A typical example would be a delivery-time filter like spamassassin looking at the topmost Received: applied by the local MTA which is known to be real. I don't recall anyone else finding this section confusing, and it reflects existing practice. >>You've gone to some lengths to get ipv4 correct, >>but you don't do the same with CIDR prefixes. >> >>> ip4-cidr-length = "/" 1*DIGIT >>> ip6-cidr-length = "/" 1*DIGIT >>Strictly speaking the value range is from 1 to >>32, for v4, and 1 to 128 for v6. This isn't >>quite all legal, but at least it's bounded: >> >> ip4-cidr-length = "/" 1*2DIGIT ; value must be > 0 and may not exceed 32 >> ip6-cidr-length = "/" 1*3DIGIT ; value must be > 0 may not exceed 128 >> >>You could do the same as you did with qnum, but perhaps that is overkill. That would be an incompatible change. What's wrong with this? ip4:1.2.3.0/00024 R's, John From sm@elandsys.com Sun Aug 25 12:12:08 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 71F4F21F9DF7 for ; Sun, 25 Aug 2013 12:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 RcphNsjetZZu for ; Sun, 25 Aug 2013 12:12:07 -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 A674E21F8C40 for ; Sun, 25 Aug 2013 12:12:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.135.173]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7PJBkRw012622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 12:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377457918; bh=3WbIpciyN810OTYvstyE5DCHP/oXclNeTyTjXbnxO+o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uW2J11m+q4+FZk3wPkunId3WZHqsVf0HD9EMRMwQ/2/5dlp9aydQLVHWV+zbsHAcX sVyWsWvAHZLYMYIvjiOn38YOyOKgzdXi1l7n0a5yKd9EBGheVu+/mVZ/A7vX6fXZya 4FX3t4wo5Bd6zlrmNbBRqlrdyhGFz/o/+vRuxODY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377457918; i=@elandsys.com; bh=3WbIpciyN810OTYvstyE5DCHP/oXclNeTyTjXbnxO+o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JiXKYEwUH4Zu6qLzrBu3pKhEdyuavfSoUdN9GogN/rXQ5z2RdQz6cXJRhN2Hhx1IU znP59BJTsWHq7eVZTJgcukuF1V9A9viAU+Kc1l0NujkT4Pq5peSaIpdGorMlh/832Q HmuhD9vF2MBQ7PfsaEkLyddwNGba2IIAIGDqIMJQ= Message-Id: <6.2.5.6.2.20130825115051.0af1b548@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 25 Aug 2013 12:11:18 -0700 To: John Levine From: S Moonesamy In-Reply-To: <20130825183158.68589.qmail@joyce.lan> References: <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> <20130825183158.68589.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review: prefixed records 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, 25 Aug 2013 19:12:08 -0000 Hi John, At 11:31 25-08-2013, John Levine wrote: > >> Also, did the working group consider > >> a DKIM-like solution? They all but establish > >> an _spf label in this document (I'll come to that in a moment). > > >>2. So-called "Utility Labels" > >> > >>Throughout the document _spf.example.com is > >>used, as is the term "common utility > >>labels". Maybe bind doesn't cough up blood on > >>underscores, but this is also not what we would > >>call a sanctioned practice by our RFCs. If this > >>is truly first use (and I could be wrong), then > >>the utility of utility labels need to be made > >>clear. As this is, IMHO, not the focus of this > >>standard, my suggestion would be to change the example. > >To the first part, Scott says they considered an _spf prefix back in >2003 and rejected it because a decade ago too much provisioning >crudware choked on underscores. That problem is long gone, but >changing the initial lookup name now would be a huge and extremely >incompatible change both to the spec and to existing practice. It's >true that some SPF records redirect to _spf.name, but most don't, or >include multiple names with various names and prefixes. See the SPF >for google.com and hotmail.com for examples. > >As far as underscored names not being sanctioned, I don't understand >that at all. Underscores aren't valid in hostnames, but they are >entirely valid and widely used in non-host names. I suppose it might >be worth mentioning that the targets of include: and redirect= need >not be hostnames, and if the target name isn't intended to be one that >sends mail, it's better if it's not. It would be an incompatible change. The other part of the issue is that the document uses "_spf.example.com" in the examples. If too many provisioning systems choked on underscores it is questionable why it was used in examples. There is a note that refers to a label with an underscore prefix as a common utility labels. I read that as saying that the "utility label" was in common use. >PS: Re changes to the spec and to practice, deprecating type 99 is a >somewhat significant change to the spec, but an insignificant change >to existing practice because everyone publishes and checks TXT now. >Nobody checks _spf. now. Ok. Regards, S. Moonesamy From johnl@taugh.com Sun Aug 25 12:14:31 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 0F3F021F9D69 for ; Sun, 25 Aug 2013 12:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, 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 Xo5hcVZubEp5 for ; Sun, 25 Aug 2013 12:14:30 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0137221F9D7A for ; Sun, 25 Aug 2013 12:14:29 -0700 (PDT) Received: (qmail 96675 invoked from network); 25 Aug 2013 19:14:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=179a1.521a5795.k1308; bh=48NA5LlOQuTm4uIcPhwUk1s3VRMTwXy2jTqVuhYLY0s=; b=iWdL2PFl5kkRhxweTbsTP5Zw1v63uh321vDWnb/VYLckYh3MKnQWvq+hXXftzNUgIx7fVQt4RjX4i4p264uo/G/yA1W+LRuTrEA2bWzb4KMXQ0qWuhs3Z8rQ48gZwLmXVr421VMlY5/38pO3G3t24kLEWgM6WMWJ234tT2z7UzaEAlK7fEOSEB/YvugRXD3JhXUDVgwtdghmu3IvpGV2lIhdBdcHRlLcwzI15yDuPNY7LXEKqeYHbBg1myQtui2c DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=179a1.521a5795.k1308; bh=48NA5LlOQuTm4uIcPhwUk1s3VRMTwXy2jTqVuhYLY0s=; b=q8EThKDMe9J1j8oZJV/XOArmvdIpxu4OT3Z1mQe62BhWQJGIM+yVX2LkEOIwg3HuMdCbonkyVRb0tLKC2rTiAH4n97+xiiECFzS9VWEADbA40ua8nIGx2+s88uwyIpKbEt+vtWqXKJ+1OlluFjbHAWwia95RWoqA6ahP5WVhz5u/RafJfkS+B3Ld364pRWqPkSqyUwxTcRNKqmAOwmmInd9GC1EsWF/S2y+jJqVE/OLkC2cRPahtqS/8TK+ji7Te Received: (ofmipd 127.0.0.1); 25 Aug 2013 19:14:06 -0000 Date: 25 Aug 2013 15:14:28 -0400 Message-ID: From: "John R Levine" To: "S Moonesamy" In-Reply-To: <6.2.5.6.2.20130825115051.0af1b548@resistor.net> References: <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> <20130825183158.68589.qmail@joyce.lan> <6.2.5.6.2.20130825115051.0af1b548@resistor.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review: prefixed records 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, 25 Aug 2013 19:14:31 -0000 > It would be an incompatible change. The other part of the issue is that the > document uses "_spf.example.com" in the examples. If too many provisioning > systems choked on underscores it is questionable why it was used in examples. It always worked in the DNS, and it always worked if you weren't stuck with cruddy provisioning software. I suppose we could change the examples to something else, but I still don't understand what problem that would solve. Again, I don't see much use in putting 2003 history in a 2013 standards track document. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From ajs@anvilwalrusden.com Sun Aug 25 12:23:49 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 E49B221F9DA0 for ; Sun, 25 Aug 2013 12:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.831 X-Spam-Level: X-Spam-Status: No, score=-0.831 tagged_above=-999 required=5 tests=[AWL=0.009, 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 llopBhg3NyRd for ; Sun, 25 Aug 2013 12:23:44 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2873F21F9C56 for ; Sun, 25 Aug 2013 12:23:44 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B346B8A031 for ; Sun, 25 Aug 2013 19:23:42 +0000 (UTC) Date: Sun, 25 Aug 2013 15:23:39 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130825192339.GD8259@mx1.yitter.info> References: <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> <20130825183158.68589.qmail@joyce.lan> <6.2.5.6.2.20130825115051.0af1b548@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Applications Directorate Review: prefixed records 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, 25 Aug 2013 19:23:50 -0000 No hat. On Sun, Aug 25, 2013 at 03:14:28PM -0400, John R Levine wrote: > It always worked in the DNS This is a key point, and I do not think that the SPFBIS WG is a place to reiterate the STD13 point that labels are supposed to be bags of octets (modulo the issue of case handling, which is admittedly a mess). A -- Andrew Sullivan ajs@anvilwalrusden.com From dhc@dcrocker.net Sun Aug 25 13: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 0A9CB21F9EB8; Sun, 25 Aug 2013 13:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiO3xgDp-hAS; Sun, 25 Aug 2013 13:24:53 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 21F6421F9E7C; Sun, 25 Aug 2013 13:24:50 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7PKOgeG030417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Aug 2013 13:24:45 -0700 Message-ID: <521A67E9.7040104@dcrocker.net> Date: Sun, 25 Aug 2013 13:24:09 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Eliot Lear References: <521A1F31.8080402@cisco.com> In-Reply-To: <521A1F31.8080402@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 25 Aug 2013 13:24:48 -0700 (PDT) Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, 'IESG' , Apps Discuss Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 20:24:58 -0000 These are meant as targeted responses, rather than to the review in general: On 8/25/2013 8:13 AM, Eliot Lear wrote: > 1. Deprecation of SPF record not properly justified in text and in the > wrong place > > Deprecation of the SPF record is given short shrift in Section 13.1 > which is the IANA considerations section. A persistent reader would not > understand why the record was in fact deprecated. This is confusing. These are specifications, not historical explanations. IETF specifications /permit/ far more commentary than do most standards groups' documents. However the degree of expectation -- nevermind requirement -- for extended rationale about choices that is being called for here does not match my sense of what is typical for IETF specifications. Can you provide some pointers to recent exemplars that match what you are calling for? > 2. So-called "Utility Labels" > > Throughout the document _spf.example.com is used, as is the term "common > utility labels". Perhaps my search function is off, but I'm only finding one occurrence of "common utility labels". > Maybe bind doesn't cough up blood on underscores, but > this is also not what we would call a sanctioned practice by our RFCs. Use of underscores is not sanctioned? Huh? It's been a standardized practice for more than 10 years. See SRV. If you mean something else, what is it? > There are areas where the document seems to go to lengths to avoid the > use of normative language. If either the WG or the IESG cares, I can > go through a few that could stand to be MAYs, but here is but one example: > >> A mail receiver can perform a set of SPF checks for each mail message >> it receives. > As I say below, this text actually adds nothing to the document, but if > the author decides to leave it in, this is a prime example of where MAY > was intended to be useful. Probably not. It has nothing to do with interoperability. It is, in fact, purely advisory text about possible use. As such, it's actually rather important that it /not/ use normative language. (The text does need to be clear about the line between normative and advisory text, of course.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Sun Aug 25 13:27: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 BA38521F9EE0 for ; Sun, 25 Aug 2013 13:27: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 GyWegfb2EgrS for ; Sun, 25 Aug 2013 13:27:11 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id A4E4E21F9EC8 for ; Sun, 25 Aug 2013 13:27:11 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 98CABD0407F; Sun, 25 Aug 2013 16:27:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377462430; bh=aNEggl4BPm7zpRBuDPS89/X1MaWyXdClJgdN3PJmsGI=; h=In-Reply-To:References:Subject:From:Date:To:From; b=BveGQTYru7uuey7s4yMysw8WatGkTa6Ob0At/EbFmoL7W+FwmdVZcS6rIwB0TxRja QSLOprPZeypmdRc7Eb6nMqg5rk3UtbfthfBVFf5/OEP14I9avOLwUIVB3JILeg3V4j 1h+4oP5N2H/6eIdt9jqq98PpNEEuNK24h+Fw4vqo= Received: from [IPV6:2600:1016:b12f:f227:3000:8b9:1d18:68b] (unknown [IPv6:2600:1016:b12f:f227:3000:8b9:1d18:68b]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 03463D0401E; Sun, 25 Aug 2013 16:27:09 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130825111105.0af1d550@resistor.net> References: <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> <20130825175824.68451.qmail@joyce.lan> <6.2.5.6.2.20130825111105.0af1d550@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 25 Aug 2013 16:27:14 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Applications Directorate Review: deprecation 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, 25 Aug 2013 20:27:16 -0000 S Moonesamy wrote: >Hi John, >At 10:58 25-08-2013, John Levine wrote: >> [ I'm breaking this up into separate messages so there can be >> separate threads ] > >Thanks, it makes the discussion easier. > >> >>1. Deprecation of SPF record not properly >> >>justified in text and in the wrong place >> >>Deprecation of the SPF record is given short >> >>shrift in Section 13.1 which is the IANA >> >>considerations section. A persistent reader >> >>would not understand why the record was in fact >> >>deprecated. >> >>I don't understand the issue. It has always been my impression that >>the point of a standards track RFC is to tell readers how to implement >>the spec so it'll interoperate, not to document the history of how it >>got there. Five years from now, it's hard to imagine that people >>reading the RFC will want to know about the current food fight. Or if >>they do, that's why we have mailing list archives. >> >>I agree that the discussion would better be in the appendix about >>post-4408 changes, perhaps with a sentence noting that 4408 had >>inconsistent instructions about publishing and checking type 99 >>records, which would have caused interop problems if anyone had >>actually followed them. > >The depreciation of SPF RR is a bit convoluted. The SPF >specification is no longer using SPF RR. Section 13.1 is the >requested IANA action to mark it as obsolete. The working group does >not have text in other sections of the draft to explain why the SPF >RR is no longer needed. What Eliot may be saying is to have some >text in another section about that. > >The interoperability problem could be separated from the depreciation >of the SPF record. The explanation could be in an appendix. We did discuss this point and concluded it didn't belong in 4408bis. Scott K From marka@isc.org Sun Aug 25 14:15:49 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 6406F11E80C5 for ; Sun, 25 Aug 2013 14:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 1atdRwrtH9Qk for ; Sun, 25 Aug 2013 14:15:45 -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 12D6D11E80AD for ; Sun, 25 Aug 2013 14:15:45 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 8C437C9423; Sun, 25 Aug 2013 21:15:31 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377465344; bh=nxJIDfqsXsKBdCqehUQyyyjVAcGaqdCKFb1nSDhazGs=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=mQHFHFYR8OvYeKFNzDtItLJF8PtssHHUo3pklwLAf4GzR5CTs+adg6LkDlm3pWSl5 ixRedSL3Ur5DhEGaAj5gtDGzVZ/WXJ730iAHp5jeuxp509+COY8wkrS3QHz6XGJNQV pJLY6YM6jC/N+sZgzM6OZmNaJ5jejNPhN2Fsqk2c= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Sun, 25 Aug 2013 21:15:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B8548160435; Sun, 25 Aug 2013 21:16:00 +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 84EED16042E; Sun, 25 Aug 2013 21:16:00 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 453E638DB50E; Mon, 26 Aug 2013 07:15:24 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <521A1F31.8080402@cisco.com> <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> <20130825161603.GB8259@mx1.yitter.info> In-reply-to: Your message of "Sun, 25 Aug 2013 12:16:03 -0400." <20130825161603.GB8259@mx1.yitter.info> Date: Mon, 26 Aug 2013 07:15:24 +1000 Message-Id: <20130825211524.453E638DB50E@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 21:15:49 -0000 In message <20130825161603.GB8259@mx1.yitter.info>, Andrew Sullivan writes: > No hat. > > On Sun, Aug 25, 2013 at 08:58:15AM -0700, S Moonesamy wrote: > > > The explanation in RFC 6686 is: > > > > "[SPF] itself included a faulty transition plan, likely because of > > the late addition of a requirement to develop one -- it said: > > > > An SPF-compliant domain name SHOULD have SPF records of both RR > > types. A compliant domain name MUST have a record of at least > > one type. > > > > which means both can claim to be fully compliant while failing > > utterly to interoperate. Publication occurred without proper > > IETF review, so this was not detected prior to publication." > > > > What is the interoperability issue? > > I guess the WG sort of hoped that readers would be able to do > elementary entailment for themselves. It says that two > implementations might follow the same MUST and decide for their own > reasons that the SHOULD cannot be met. By implication, they could > pick different results of the MUST, and they wouldn't interoperate. Actually they do interoperate with the set they DECIDE to interopate with. This comes done to not letting people live with the consquences of their actions. There is NOTHING wrong with someone deciding they don't want to interoperate with EVERYONE. Truly. There are very clear instruction in 4408 about what SHOULD happen. Not following a SHOULD has always has the risk of breaking something. In this case you don't get to stop quite as much forged email. Everybody has the choice to decide if they want to interoperate with everyone. This is and always has been a NON PROBLEM. A non problem which when trying to "fix" causes real problems elsewhere. Mark > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- 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 Sun Aug 25 14:45:03 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 7A8A111E80EA; Sun, 25 Aug 2013 14:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.483 X-Spam-Level: X-Spam-Status: No, score=-106.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 XV3Ej0IczRnz; Sun, 25 Aug 2013 14:44:59 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5C57711E80E7; Sun, 25 Aug 2013 14:44:56 -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=1377467096; x=1409003096; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=SqCo+wPvVrsAHzLCXGTyGSuPncruUSUapmooTDTnQN8=; b=GHR6MQhzZ3zXNBc9PVdLSxJwbzJ6xnoWY259bmiVrDn2assJTimtAycV lNrfuCMCb4/6AY4nnXHaJ/L6RUc+368F/+6oHGan+FuupQ9fsZE8102dx PBebuveWL6rwydHqjxdNevDm5wpG5PWA9BgxTlqCrep/REXiJIwnkgzH4 4=; X-IronPort-AV: E=McAfee;i="5400,1158,7178"; a="70390897" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 25 Aug 2013 14:44:55 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7178"; a="501418358" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Aug 2013 14:44:54 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.146.2; Sun, 25 Aug 2013 14:44:54 -0700 Message-ID: <521A7AD3.9000704@qti.qualcomm.com> Date: Sun, 25 Aug 2013 16:44:51 -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: Eliot Lear References: <521A1F31.8080402@cisco.com> In-Reply-To: <521A1F31.8080402@cisco.com> Content-Type: multipart/alternative; boundary="------------090401070903030101000308" X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, 'IESG' , Apps Discuss Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 21:45:03 -0000 --------------090401070903030101000308 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 8/25/13 10:13 AM, Eliot Lear wrote: > > Major issues: > > 1. Deprecation of SPF record not properly justified in text and in the > wrong place > > 2. So-called "Utility Labels" > Eliot, I would like to hear some followups to the folks who have posted so far before more folks pile on. I'm hearing for the two above major issues: On 1: Others have said that the document already points to 6686 where quite a bit of justification is made, and in any event the present document isn't the correct place for such justifications. Also, folks have said that the document already says that syntactically incorrect records will fail processing (with a "permerror" -- see section 4.6). On 2: Folks have said that you are incorrect about underscore in labels being a problem as they are already widely used (e.g. SRV). Were your comments misunderstood? I'm not sure why major issue 3 is "major", but I think the WG can consider it (if it has not already) like some of the other things you've mentioned. But like I said, before more people respond on the first two, I'd like to understand what you mean. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------090401070903030101000308 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 8/25/13 10:13 AM, Eliot Lear wrote:

Major issues:

1. Deprecation of SPF record not properly justified in text and in the wrong place

2.  So-called "Utility Labels"


Eliot, I would like to hear some followups to the folks who have posted so far before more folks pile on. I'm hearing for the two above major issues:

On 1: Others have said that the document already points to 6686 where quite a bit of justification is made, and in any event the present document isn't the correct place for such justifications. Also, folks have said that the document already says that syntactically incorrect records will fail processing (with a "permerror" -- see section 4.6).

On 2: Folks have said that you are incorrect about underscore in labels being a problem as they are already widely used (e.g. SRV).

Were your comments misunderstood?

I'm not sure why major issue 3 is "major", but I think the WG can consider it (if it has not already) like some of the other things you've mentioned.

But like I said, before more people respond on the first two, I'd like to understand what you mean.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------090401070903030101000308-- From lear@cisco.com Sun Aug 25 12:51:29 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 4939B21F9E43; Sun, 25 Aug 2013 12:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.558 X-Spam-Level: X-Spam-Status: No, score=-110.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 TOrjBJJBUVEO; Sun, 25 Aug 2013 12:51:24 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6371421F9E3F; Sun, 25 Aug 2013 12:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=875; q=dns/txt; s=iport; t=1377460283; x=1378669883; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mp7Rd1OVFZRKVs6JiCJ2QBTorsqNHF0GsNOQQIqMKtQ=; b=Df/ecVjyNYjV6wwDZAvcwhBx7u3ar9uFKBPZ2KHiN07aZ6CQJd1TIahX tzrf6ZwuKD0j4yc1sQAWl0+kPp+5mzj/vS02evotiwq/87hcXMzxLzTrd pwmjhc3TGVyYMtDopQlkEu9KNXgJVHLs+Ghh8QD8v90GDMtUrR4A2xrxq A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIFAENfGlKQ/khN/2dsb2JhbABZgwc1gzFHvHCBGhZ0giQBAQEEI1UBEAsOCgICBRYLAgIJAwIBAgErGgYNAQcBAYd9pG2Rc4Epj08HgmiBMQOXboEtkDSBY4E9Og X-IronPort-AV: E=Sophos;i="4.89,952,1367971200"; d="scan'208";a="17484622" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 25 Aug 2013 19:51:22 +0000 Received: from mctiny.local ([10.61.174.183]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7PJpJjk009932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 19:51:20 GMT Message-ID: <521A6037.8030208@cisco.com> Date: Sun, 25 Aug 2013 21:51:19 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andrew Sullivan References: <521A1F31.8080402@cisco.com> <20130825162331.GC8259@mx1.yitter.info> In-Reply-To: <20130825162331.GC8259@mx1.yitter.info> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 25 Aug 2013 15:11:42 -0700 Cc: spfbis@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [spfbis] [apps-discuss] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 19:51:29 -0000 You're correct. For some reason I thought they were reserved. Eliot On 8/25/13 6:23 PM, Andrew Sullivan wrote: > No hat. > > On Sun, Aug 25, 2013 at 05:13:53PM +0200, Eliot Lear wrote: > >> 2. So-called "Utility Labels" >> >> Throughout the document _spf.example.com is used, as is the term "common >> utility labels". Maybe bind doesn't cough up blood on underscores, but >> this is also not what we would call a sanctioned practice by our RFCs. >> If this is truly first use (and I could be wrong), then the utility of >> utility labels need to be made clear. As this is, IMHO, *not* the focus >> of this standard, my suggestion would be to change the example. > I don't think I understand this critique, but I think your claim is > that underscores are somehow not scanctioned by RFC. I think you are > mistaken about this. > > Best, > > A From sm@elandsys.com Sun Aug 25 15:31:00 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 1A0F911E8104 for ; Sun, 25 Aug 2013 15:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 q1ItgEbhVvLc for ; Sun, 25 Aug 2013 15:30:59 -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 7DB4B11E8103 for ; Sun, 25 Aug 2013 15:30:58 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.47]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7PMUj0F023790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 15:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377469857; bh=4NiFSjujNoFSU2sypZFDWUWbEnwBfz2y2n1R5gwuafo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AdECGuxcNaNHrpZOGsUo8Jeb1Wu3CDmbl+iOH+WvmVmdwq5nDKQOZu9WVfMvy/i88 OZJOZURhxResBhZpJFzS/6BhJXzUJQkd6m8rM2OUAwMr+1wdRgnFgFLKqSK4rs44X5 OcmJgQFXgjziiL6HmKfdylkQTO0RhvyJhnEQJs4U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377469857; i=@elandsys.com; bh=4NiFSjujNoFSU2sypZFDWUWbEnwBfz2y2n1R5gwuafo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xVgdnioyN5eE44HCrS1brv20t3SzacjpCJ+Cm9Z1WMcbEOLskq0s1DAAeHbLv8VKs Uk5EMFVPkdx3JHg3afofS3uU3l/ghvXevDbQBp2/M0SjghDV9/5Fhkxq7eVJX2WjXy IvZRlGSURFyMBNtJZKs1CIiFIqFaD14dOJyHffgc= Message-Id: <6.2.5.6.2.20130825151345.0b4553a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 25 Aug 2013 15:26:46 -0700 To: Mark Andrews From: S Moonesamy In-Reply-To: <20130825211524.453E638DB50E@drugs.dv.isc.org> References: <521A1F31.8080402@cisco.com> <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> <20130825161603.GB8259@mx1.yitter.info> <20130825211524.453E638DB50E@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 22:31:00 -0000 Hi Mark, At 14:15 25-08-2013, Mark Andrews wrote: >Actually they do interoperate with the set they DECIDE to interopate >with. > >This comes done to not letting people live with the consquences of >their actions. There is NOTHING wrong with someone deciding they >don't want to interoperate with EVERYONE. Truly. There are very >clear instruction in 4408 about what SHOULD happen. Not following >a SHOULD has always has the risk of breaking something. In this >case you don't get to stop quite as much forged email. > >Everybody has the choice to decide if they want to interoperate with >everyone. > >This is and always has been a NON PROBLEM. A non problem which when >trying to "fix" causes real problems elsewhere. The problem is when the text in Section 3.1.1 is read with: 'In accordance with how the records are published (see Section 3.1 above), a DNS query needs to be made for the name, querying for either RR type TXT, SPF, or both.' Regards, S. Moonesamy From marka@isc.org Sun Aug 25 16:44: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 5043121F9EC8 for ; Sun, 25 Aug 2013 16:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 RfoXTZWRIgkv for ; Sun, 25 Aug 2013 16:44:15 -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 0A29521F9E94 for ; Sun, 25 Aug 2013 16:44:15 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id BB6E3C9423; Sun, 25 Aug 2013 23:44:01 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377474254; bh=YBVDTB09aY+zLG1ThLHHeQ3+xPH7qLTHCVWV+lIVfAU=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=nyAl6rXf3PrYy6ODE20C2WxQ+LVxkw9Bv2oPYntZPqETv88Wm2d7FXcR7aKZsexQe kbZplQY3TD+A1/5FNRWTFHORN0VA6kfCS9XE9UtteqnetMBohfLy/vj4wX95ebWHph B6BVWOOari//s/C1w5dD+Gs4oAN4BHW+oING9pKI= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Sun, 25 Aug 2013 23:44:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5A56E160435; Sun, 25 Aug 2013 23:44:31 +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 2825F16042E; Sun, 25 Aug 2013 23:44:31 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 229D438DBB45; Mon, 26 Aug 2013 08:42:04 +1000 (EST) To: "John Levine" From: Mark Andrews References: <20130825180936.68506.qmail@joyce.lan> In-reply-to: Your message of "25 Aug 2013 18:09:36 +0000." <20130825180936.68506.qmail@joyce.lan> Date: Mon, 26 Aug 2013 08:42:03 +1000 Message-Id: <20130825224204.229D438DBB45@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review: record selection 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, 25 Aug 2013 23:44:19 -0000 In message <20130825180936.68506.qmail@joyce.lan>, "John Levine" writes: > >>The matter of handling garbage in garbage out is > >>not well enough specified in Section 3. I would > >>go considerably further and state that (a) > >>records that do not begin with "v=spf1" MUST NOT > >>be processed further, and (b) that any record > >>that does not conform to the stated grammar MUST be > >>ignored. > > The (a) part is in there now, or if it's not, that's what the wording > is supposed to mean. (Actually, it's "v=spf1 " with a following > space.) It is a record consisting of "v=spf1" only or a record starting with "v=spf1 ". This is from 4408 and if it has change in the draft it is a introduced iteroperabilty problem. I'm offline so I can't check the draft. 1. Records that do not begin with a version section of exactly "v=spf1" are discarded. Note that the version section is terminated either by an SP character or the end of the record. A record with a version section of "v=spf10" does not match and must be discarded. It would also be useful to specify "case insensitive" to reinforce that all of the record is case insensitive. > The (b) is more of a can of worms than you might think. Many > implementations interpret SPF records incrementally and stop as soon > as they have a result. If there are syntax errors farther along, or > in included records referenced farther along, they don't care and > often don't even notice. > > This change would likely present an interop issue by requiring changes > in behavior by systems using existing libraries that interpret SPF > incrementally, which I think is most of them. Standards don't usually > offer detailed advice about what to do if the other end screws up, and > I don't see any reason to do that here. If you want to interoperate, > publish correct SPF. If you don't, you take your chances. > > R's, > John > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From johnl@taugh.com Sun Aug 25 16:48: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 CA14211E810D for ; Sun, 25 Aug 2013 16:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, 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 CLI06hMR3Od8 for ; Sun, 25 Aug 2013 16:48:35 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C7B5411E810C for ; Sun, 25 Aug 2013 16:48:34 -0700 (PDT) Received: (qmail 54198 invoked from network); 25 Aug 2013 23:48:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=d3b5.521a97cf.k1308; bh=kfOlIopCYFrfvWj9XyMc+sKP6BJwICx18sVGG+teX+E=; b=jvI6TzVlvl1XKII99DL8ECCm7fOTQ5LuZk+TPGao3WRYdjpNFiOROPAVixhNsJkZykJow5b5RurBz33G6f8n7irr/fECbbQz2x+zgQEWukUcA0ZIIwda9vzIBLT87ZmraDH4oCLN3oygtic/JVCF70qpe0OuBXG5ZLnuIqom7uqwLBoL5xtPx5cEz7nmV3xKP1PpK8+BDi5ThJLJ+NLZpFNiakJfC9VRw+s0GD2DxZIkP54TK4+dYGyjvgmmFJ2a DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=d3b5.521a97cf.k1308; bh=kfOlIopCYFrfvWj9XyMc+sKP6BJwICx18sVGG+teX+E=; b=FGDy6RJF3L/cs9IIYpa6FZLzw4iwJEuyFFgoOuj2LMAvBzohGhSX62+lNtPbpyzo6UCVwxrpyA7c31kvugdJqspY+Ug14KYqozk3SP2uHgp6e7qh9w6JjeGEY8DL0HaFE2kw19HENBiwnb0XWbzV+q668ptP27QWTWpB41yohjEXk7/G3R53cyasCXMZk1GTaT8fR2CEq2swFHE4Tv0T7RAXBb6Z4fMhQqvExuMZEhZUIStEskDMv68XgBd9yWeO Received: (ofmipd 127.0.0.1); 25 Aug 2013 23:48:09 -0000 Date: 25 Aug 2013 19:48:31 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" In-Reply-To: <20130825224204.229D438DBB45@drugs.dv.isc.org> References: <20130825180936.68506.qmail@joyce.lan> <20130825224204.229D438DBB45@drugs.dv.isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review: record selection 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, 25 Aug 2013 23:48:36 -0000 > It is a record consisting of "v=spf1" only or a record starting with > "v=spf1 ". > > This is from 4408 and if it has change in the draft it is a introduced > iteroperabilty problem. I'm offline so I can't check the draft. The ABNF hasn't changed, I was wrong about the space, which is only needed is there's something following. > It would also be useful to specify "case insensitive" to reinforce that > all of the record is case insensitive. That's implicit in the ABNF. R's, John From sm@elandsys.com Sun Aug 25 16:51:42 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 B73FB11E810E; Sun, 25 Aug 2013 16:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 DHkksllPgngt; Sun, 25 Aug 2013 16:51:42 -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 87B8511E810C; Sun, 25 Aug 2013 16:51:42 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.47]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7PNpPln004066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 16:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377474699; bh=N8crGbG1m2IdozqVRsEq1S5pjUx3oxx0P9CYmk1gWsk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZhOJElNCzDbodJ2JDKHxWw9ARSp+XzS08iPmaJ2KnVApvZGHG7QQkUBo+XLwLiS3B cj4Nw5cQCWvKSM7r/hJoC0I7Xqyj/zyCAcvvUq5khAt3V3tiRGhYW+N4x8a+J3c8el CcTh6EcC+O7uJacHwOTB5vMjbd9bpYWwhHnYgE5Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377474699; i=@elandsys.com; bh=N8crGbG1m2IdozqVRsEq1S5pjUx3oxx0P9CYmk1gWsk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2X17E1HK1Kv62iJrhOxUaWk2vxlqh2B3/cs2OszMje7KZMSxvnOSjx2X5zuya0aSJ YBkVAk9on8L4v/Ru76LQ7YMlGkzFesG6PXA8flXF0W0AttcEHo2u5THrr4TzFciRe7 mQYZZLTF6i3XwOofdI853gAAHCYzIbtUKQ/zEcUs= Message-Id: <6.2.5.6.2.20130825155516.0ae42960@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 25 Aug 2013 16:49:50 -0700 To: Eliot Lear , draft-ietf-spfbis-4408bis.all@tools.ietf.org From: S Moonesamy In-Reply-To: <521A1F31.8080402@cisco.com> References: <521A1F31.8080402@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Apps Discuss , IESG Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 23:51:42 -0000 Hi Eliot, At 08:13 25-08-2013, Eliot Lear wrote: >Summary: This draft is not yet ready for publication as a Proposed >Standard and should be revised before publication. I'll respond to part of the comments. The SPFBIS WG has a tightly-scoped charter. Suggested changes to RFC 2119 keywords, for example, were carefully considered. One of the problems was the way RFC 4408 was written. draft-ietf-spfbis-4408bis is not a complete rewrite of RFC 4408. The clarifications were kept as narrow as possible. >Major issues: [snip] >the stated grammar MUST be ignored. Also, did the working group >consider a DKIM-like solution? They all but establish an _spf label >in this document (I'll come to that in a moment). There is a thread at http://www.ietf.org/mail-archive/web/spfbis/current/msg03964.html about the "_spf" prefix. I went over some of the messages posted during the WG charter discussion to see whether the WG could have considered a DKIM-like solution. In my opinion it would be out-of-scope. >2. So-called "Utility Labels" > >Throughout the document _spf.example.com is used, as is the term >"common utility labels". Maybe bind doesn't cough up blood on >underscores, but this is also not what we would call a sanctioned >practice by our RFCs. If this is truly first use (and I could be >wrong), then the utility of utility labels need to be made >clear. As this is, IMHO, not the focus of this standard, my >suggestion would be to change the example. There is a thread at http://www.ietf.org/mail-archive/web/spfbis/current/msg03996.html in response to your review. The "Utility labels" is a note in the draft. _spf.example.com was used in RFC 4408 for some examples and the text is similar in the draft. My reading of the message at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10272.html is that the examples do not have to be changed (re. not sanctioned by RFC). >3. Retain a summary of changes since 4408. > >A -bis document usually has a change list that can assist >implementers familiar with previous work. Appendix J is pretty >close to what I would want, but it needs some editing. Did you mean merging some of Appendix J into Appendix C? >Minor Issues: > >There are areas where the document seems to go to lengths to avoid >the use of normative language. If either the WG or the IESG cares, >I can go through a few that could stand to be MAYs, but here is but >one example: >> A mail receiver can perform a set of SPF checks for each mail message >> it receives. >As I say below, this text actually adds nothing to the document, but >if the author decides to leave it in, this is a prime example of >where MAY was intended to be useful. Please refer to my opening comment. >Similarly, there is the occasional "ought to", such as that found in >Section 3. If the WG considered normative text and rejected it, >fine. But if they didn't, they should. This is a complex >specification, and our normative language definitions are there to >provide clarity and consistency. The SPFBIS WG considered whether having the normative text was within scope. I agree with your argument about clarity and consistency. The document shepherd review is at http://www.ietf.org/mail-archive/web/spfbis/current/msg03414.html I did a pass of the RFC 2119 keywords and compared them against what is in RFC 4408. Adding normative language can entail a significant rewrite of the draft. It can create incompatible changes. As you mentioned this is a complex specification and significant changes would require a level of review beyond what has been done up to now to achieve better clarity and consistency. This draft has been a significant effort. I'll leave it to the IESG to assess whether asking the SPFBIS WG to go beyond that is doable. Thanks for the careful review. Regards, S. Moonesamy From marka@isc.org Sun Aug 25 17:53:24 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 564DD21F9223 for ; Sun, 25 Aug 2013 17:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 OAt+-3YvwBWN for ; Sun, 25 Aug 2013 17:53:19 -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 5FA6F21F8FCE for ; Sun, 25 Aug 2013 17:53:19 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 9DA53C94B7; Mon, 26 Aug 2013 00:53:06 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377478399; bh=NvEP7SRM7Sd2KhNCkFxI4w9hZPDkfdv9kC9lrawpbz0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=dc4AYV6wjCfnI2Nr0PuK6yliVjNHcPvz6OV0++P0F5TIN3FpkkDZiyhRasxM33Gq/ FRse9yOjkNB0RvRedRPfVNoucYLTE5CLibAAByUYYLzb7PH2CAvm/M1EBmeH814r0l n6oxjjO+c8ARTGfyU02l+PGE1wSqhCY4uyT3BVC8= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 26 Aug 2013 00:53:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 707CB16043C; Mon, 26 Aug 2013 00:53:36 +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 4221C16042E; Mon, 26 Aug 2013 00:53:36 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id E265D38DD639; Mon, 26 Aug 2013 10:53:01 +1000 (EST) To: S Moonesamy From: Mark Andrews References: <521A1F31.8080402@cisco.com> <6.2.5.6.2.20130825082323.0aedb028@elandnews.com> <20130825161603.GB8259@mx1.yitter.info> <20130825211524.453E638DB50E@drugs.dv.isc.org> <6.2.5.6.2.20130825151345.0b4553a8@resistor.net> In-reply-to: Your message of "Sun, 25 Aug 2013 15:26:46 -0700." <6.2.5.6.2.20130825151345.0b4553a8@resistor.net> Date: Mon, 26 Aug 2013 10:53:01 +1000 Message-Id: <20130826005301.E265D38DD639@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 00:53:24 -0000 In message <6.2.5.6.2.20130825151345.0b4553a8@resistor.net>, S Moonesamy writes : > Hi Mark, > At 14:15 25-08-2013, Mark Andrews wrote: > >Actually they do interoperate with the set they DECIDE to interopate > >with. > > > >This comes done to not letting people live with the consquences of > >their actions. There is NOTHING wrong with someone deciding they > >don't want to interoperate with EVERYONE. Truly. There are very > >clear instruction in 4408 about what SHOULD happen. Not following > >a SHOULD has always has the risk of breaking something. In this > >case you don't get to stop quite as much forged email. > > > >Everybody has the choice to decide if they want to interoperate with > >everyone. > > > >This is and always has been a NON PROBLEM. A non problem which when > >trying to "fix" causes real problems elsewhere. > > The problem is when the text in Section 3.1.1 is read with: > > 'In accordance with how the records are published (see Section 3.1 > above), a DNS query needs to be made for the name, querying > for either RR type TXT, SPF, or both.' > > Regards, > S. Moonesamy Again there is no problem. Because if your read the entire document it is clear that one is migrating from TXT to SPF. Note the wording didn't stop spf library developers adding SPF lookups. Sure the wording could have been stronger. I read "In accordance with" to put a SHOULD in SPF lookup and a MAY on TXT lookup only / both lookup. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From spf2@kitterman.com Sun Aug 25 21:13:40 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 8A21311E8145; Sun, 25 Aug 2013 21:13:40 -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 FphtUbqiWial; Sun, 25 Aug 2013 21:13:35 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 698A721F9D8D; Sun, 25 Aug 2013 21:13:35 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5599720E40D5; Mon, 26 Aug 2013 00:13:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377490414; bh=scqWCiEe6qCfbf8qWwxAthCOMkgTClDNDzWYUk2/xQg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NxmWkYuRLi+UPikgGXjelDB4MDvtyZDPGxMtik7Nzf8F7GVhz17KqFBqP+9ljE9Zu v5JwTT20+tPpT+CbLOKO/a9bVnDtZedB3m5zDCI82wi7C4r/3DyWcgicydGbh0TXq9 wMPbdBHc0fsTyQLUOfOernW1cleTXIqCECG6zhYs= 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 3971920E4076; Mon, 26 Aug 2013 00:13:33 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 26 Aug 2013 00:13:31 -0400 Message-ID: <2454227.xOQCZa8CLT@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <521A1F31.8080402@cisco.com> References: <521A1F31.8080402@cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: draft-ietf-spfbis-4408bis.all@tools.ietf.org, 'IESG' , Eliot Lear , Apps Discuss Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 04:13:40 -0000 On Sunday, August 25, 2013 17:13:53 Eliot Lear wrote: > 3. Retain a summary of changes since 4408. > > A -bis document usually has a change list that can assist implementers > familiar with previous work. Appendix J is pretty close to what I would > want, but it needs some editing. That's what Appendix C is meant to accomplish. Appendix J is not meant to be included in the final document. As far as I've noticed, the items that aren't listed in Appendix C that are in Appendix J don't directly affect implementers. Is there something specific missing from Appendix C? Scott K From spf2@kitterman.com Sun Aug 25 21:16:06 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 A38E211E8145 for ; Sun, 25 Aug 2013 21:16:06 -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 EiP-YF7lMRYs for ; Sun, 25 Aug 2013 21:16:01 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9397B21F9D8D for ; Sun, 25 Aug 2013 21:16:01 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 171BD20E40D5; Mon, 26 Aug 2013 00:16:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377490561; bh=j4IlM09XE6bqVWgBTzPggoajNbznvunA65i9/ER7Yzc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=AuJ/PYWpIjpnyWEUIuZB/ziTopGQWALD+j1ZTWSO1ld0tV0hzy5SpdrZL85EwsRFi welAN7Z3DuKTZgekJx4GflQ6lZc9KI1+8LGbn+Si+tiQwI9JI+bEbujBc+ULZ+/vG0 ZlBk06nAwjPYupNqV7z449jh04pFrqF2HQ1Sfui8= 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 EDD2A20E4076; Mon, 26 Aug 2013 00:16:00 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 26 Aug 2013 00:16 -0400 Message-ID: <2872949.4qZhT9hEkk@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <521A1F31.8080402@cisco.com> References: <521A1F31.8080402@cisco.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] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 04:16:06 -0000 On Sunday, August 25, 2013 17:13:53 Eliot Lear wrote: > Section 5.6, ABNF: > > You've gone to some lengths to get ipv4 correct, but you don't do the > same with CIDR prefixes. > > > ip4-cidr-length = "/" 1*DIGIT > > ip6-cidr-length = "/" 1*DIGIT > > Strictly speaking the value range is from 1 to 32, for v4, and 1 to 128 > for v6. This isn't quite all legal, but at least it's bounded: > > ip4-cidr-length = "/" 1*2DIGIT ; value must be > 0 and may not exceed 32 > ip6-cidr-length = "/" 1*3DIGIT ; value must be > 0 may not exceed 128 > > You could do the same as you did with qnum, but perhaps that is overkill. Would someone with a fully ABNF enabled brain comment on this suggestion please? Seems reasonable to me. Scott K From dhc@dcrocker.net Sun Aug 25 21:19: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 A8EAB21F9D0E for ; Sun, 25 Aug 2013 21:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BL-Q0furL-BB for ; Sun, 25 Aug 2013 21:19:14 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B227F21F9CD9 for ; Sun, 25 Aug 2013 21:19:14 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7Q4JAkZ006146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Aug 2013 21:19:13 -0700 Message-ID: <521AD71E.2050701@dcrocker.net> Date: Sun, 25 Aug 2013 21:18:38 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Scott Kitterman References: <521A1F31.8080402@cisco.com> <2872949.4qZhT9hEkk@scott-latitude-e6320> In-Reply-To: <2872949.4qZhT9hEkk@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 25 Aug 2013 21:19:14 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 04:19:19 -0000 On 8/25/2013 9:16 PM, Scott Kitterman wrote: > On Sunday, August 25, 2013 17:13:53 Eliot Lear wrote: >> Section 5.6, ABNF: >> >> You've gone to some lengths to get ipv4 correct, but you don't do the >> same with CIDR prefixes. >> >>> ip4-cidr-length = "/" 1*DIGIT >>> ip6-cidr-length = "/" 1*DIGIT >> >> Strictly speaking the value range is from 1 to 32, for v4, and 1 to 128 >> for v6. This isn't quite all legal, but at least it's bounded: >> >> ip4-cidr-length = "/" 1*2DIGIT ; value must be > 0 and may not exceed 32 >> ip6-cidr-length = "/" 1*3DIGIT ; value must be > 0 may not exceed 128 >> >> You could do the same as you did with qnum, but perhaps that is overkill. > > Would someone with a fully ABNF enabled brain comment on this suggestion > please? Seems reasonable to me. offhand, seems reasonable to me too, although I'd probably do the comment more tersely: ip4-cidr-length = "/" 1*2DIGIT ; value range 1-32 ip6-cidr-length = "/" 1*3DIGIT ; value range 1-128 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Sun Aug 25 21:25: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 59E9611E8150 for ; Sun, 25 Aug 2013 21:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 f3YMiWhCvvcn for ; Sun, 25 Aug 2013 21:25:11 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id AC03F11E8145 for ; Sun, 25 Aug 2013 21:25:10 -0700 (PDT) Received: (qmail 15448 invoked from network); 26 Aug 2013 04:25:09 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Aug 2013 04:25:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521ad8a5.xn--30v786c.k1308; i=johnl@user.iecc.com; bh=lQX0GgZMBKtggSUClbL8UtXB80mEiZblICzQuzK0guc=; b=mzFDtjNjfvtZ4PpH5TkkbW2YvWLqcHChYAlgC48HV4LJY8iavGHvqr41pXNCh+HqUpNf45cfLwCX8V/xjZyNnr6iL6cnMQJPxhPqP3xNF3H0jQva4jXk26+E4UrPhyAs9UqmfBbgfVk+PENSNzeblSaBOlMD9kmR21r1Hkr182Ced7JX2wc0CwIlrxRgxOaeyNGXOl+Kn7zTxzUySLShFZ+qB/0maLFJqoA02w09mMFSKk4OK+i43gpOTqTVAo6p DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521ad8a5.xn--30v786c.k1308; olt=johnl@user.iecc.com; bh=lQX0GgZMBKtggSUClbL8UtXB80mEiZblICzQuzK0guc=; b=gQ213AcLplANBQLMMn5eJcAWlt/UauXcmWAqXcmjCdEYkA+UzEgWSQRxWdRSi6BUFTDgPUyEk+g5KeeIM27ILhp2lISoZMr5RDYOa7r34mzRQtqTsUhC6jUwtghUKkJPSLDR2olk10yf2T8Q89k6JB+Ju4fpRB9EZP6wvmS2f9vek/fMv9PL5PEAlokM4ef/a4QQeRA7lpQ6NN7u0oTiFfQYfJb7OQ5PQjgFeyCav1Qsh2XWYbTq715hykBKVnwW Date: 26 Aug 2013 04:24:47 -0000 Message-ID: <20130826042447.70841.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <2872949.4qZhT9hEkk@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: spf2@kitterman.com Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 04:25:16 -0000 >> > ip4-cidr-length = "/" 1*DIGIT >> > ip6-cidr-length = "/" 1*DIGIT >> >> Strictly speaking the value range is from 1 to 32, for v4, and 1 to 128 >> for v6. This isn't quite all legal, but at least it's bounded: >> >> ip4-cidr-length = "/" 1*2DIGIT ; value must be > 0 and may not exceed 32 >> ip6-cidr-length = "/" 1*3DIGIT ; value must be > 0 may not exceed 128 >> >> You could do the same as you did with qnum, but perhaps that is overkill. > >Would someone with a fully ABNF enabled brain comment on this suggestion >please? Seems reasonable to me. Are these valid? ip4:1.2.3.0/0024 ip6:1111:2222:3333:4444::/0064 If so, the current ABNF is fine and the suggested stuff isn't, other than perhaps adding the comments about the value ranges. R's, John From spf2@kitterman.com Sun Aug 25 21:31:27 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 2291611E8151 for ; Sun, 25 Aug 2013 21:31: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 k-mNour-01GJ for ; Sun, 25 Aug 2013 21:31:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1C911E8150 for ; Sun, 25 Aug 2013 21:31:22 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8771620E40D5; Mon, 26 Aug 2013 00:31:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377491481; bh=fk5e9pueLsJjAK7wedJklNSL3mzzNPIXuounmautoQw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pEp/Z0btLqan2S1YHHqlUUIktFw+YDp/G/Xq5Zd34+NNJn8yQKHtdb412M74SKyYS 9DhgntgPXfMLpvirUGISOKsfkAOZwg85JNHAh5UFYij+r5L3Gpadb8TWZhTpm5nXYi 0olABU1EJdbz4gHfIiutxGqAd8OD3xPh1wrX6W78= 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 6335B20E4076; Mon, 26 Aug 2013 00:31:21 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 26 Aug 2013 00:31:20 -0400 Message-ID: <3077934.Ro9QPd6kt1@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <20130826042447.70841.qmail@joyce.lan> References: <20130826042447.70841.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 04:31:27 -0000 On Monday, August 26, 2013 04:24:47 John Levine wrote: > >> > ip4-cidr-length = "/" 1*DIGIT > >> > ip6-cidr-length = "/" 1*DIGIT > >> > >> Strictly speaking the value range is from 1 to 32, for v4, and 1 to 128 > >> > >> for v6. This isn't quite all legal, but at least it's bounded: > >> ip4-cidr-length = "/" 1*2DIGIT ; value must be > 0 and may not exceed 32 > >> ip6-cidr-length = "/" 1*3DIGIT ; value must be > 0 may not exceed 128 > >> > >> You could do the same as you did with qnum, but perhaps that is overkill. > > > >Would someone with a fully ABNF enabled brain comment on this suggestion > >please? Seems reasonable to me. > > Are these valid? > > ip4:1.2.3.0/0024 ip6:1111:2222:3333:4444::/0064 > > If so, the current ABNF is fine and the suggested stuff isn't, other > than perhaps adding the comments about the value ranges. I wouldn't have thought they were valid. In pyspf, which is most convenient for me to quickly check, they both cause a permerror. Scott K From johnl@iecc.com Sun Aug 25 21:40:21 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 D506E21F9F8E for ; Sun, 25 Aug 2013 21:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 Co5CsWrEmFWH for ; Sun, 25 Aug 2013 21:40:17 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4A42021F9F50 for ; Sun, 25 Aug 2013 21:40:16 -0700 (PDT) Received: (qmail 18130 invoked from network); 26 Aug 2013 04:40:13 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Aug 2013 04:40:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521adc2d.xn--9vv.k1308; i=johnl@user.iecc.com; bh=rTxtPE0UuF0G6LOIrwsooLIyTUnUVJLzqdM4QJaVjb0=; b=A30zgTVKBdm+/i4dFs9glRk/ax8yZ/tPTMsZXk44IElc13+g9kPxM6XqY3BR77KTyAF3N9nlNVXxtUzPvWYz3rz3zq4Qc1M7TExbxrjkyFoQmtfE+YmOvS0xwwrWXfUtDHa7cnV4rjAsykltIr/sgWrQ/ljJqWaIdtDaBworGJSVh83PAkXytVqrhDPzd4u9rKh3u7A4fHpmTXTEvRPhntlKCAO1SEmMaTL6uYIr+6OMl6pdnlPOYSUwlOrUi579 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521adc2d.xn--9vv.k1308; olt=johnl@user.iecc.com; bh=rTxtPE0UuF0G6LOIrwsooLIyTUnUVJLzqdM4QJaVjb0=; b=o+nmJIpC9SYcfUa1WbVBVW82cC2SySX7U9PIHd3s2QILTxBDV+35pTGK+G5ZSSa1MDLbnEjhmJPVCl3a8Yhaod36JKAEk66C9F/zUHY0th/SxFn4iifVPJXAYIgHsddBWDSC8lNU3Nx8ePR8PzkBBziS2j/M1vFNWIaqclewEgPlDA+6YJ1XAaQ/4m6du7QkOT9aknCyE9uO/sYGsYvbIjdUBSdDdfE0ZIK7By3SKpDXrO/0siC7tYce7XNlI/Vj Date: 26 Aug 2013 04:39:51 -0000 Message-ID: <20130826043951.71092.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20130826042447.70841.qmail@joyce.lan> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 26 Aug 2013 04:40:21 -0000 >Are these valid? > > ip4:1.2.3.0/0024 ip6:1111:2222:3333:4444::/0064 I looked at the code in libspf2 spf_compile.c, and it looks to me like it accepts any integer string after the slash, then checks the value to be sure it's in the 0-32 or 0-128 range. So the current ABNF matches the code, and the suggested change doesn't. R's, John From johnl@iecc.com Sun Aug 25 21:58: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 6207021F99CD for ; Sun, 25 Aug 2013 21:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 lGXrImaxmrhF for ; Sun, 25 Aug 2013 21:58:12 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 66D4F21F99A8 for ; Sun, 25 Aug 2013 21:58:11 -0700 (PDT) Received: (qmail 21449 invoked from network); 26 Aug 2013 04:58:10 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Aug 2013 04:58:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521ae062.xn--3zv.k1308; i=johnl@user.iecc.com; bh=bkhgfe5+3Ky469Vizpvwf4GQq9/lzi//LwX/JiTbmZ8=; b=N+mC12gVmAdtPybALl4a4l+5E9BTqfgjzCy9N8q9MQ4CrIg+7EqinJDtIhXu6lmb5boDxzt3zTCpCBaniEAq175tR89okLsuPpSPP1KtBdpcRSTAWG1z+b0fzIprkNWYXdBSNILASJHNSgrKCi7kT0b8VKtY0o5aZC9uThd0Yz587unPTbWbZAEClqfM8mwERtdR7Noxl3w91pK/wTIKmg3oVWdtETCR41DnCbh9JJ1sTKrVSMxSky5SaVV9evvY DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521ae062.xn--3zv.k1308; olt=johnl@user.iecc.com; bh=bkhgfe5+3Ky469Vizpvwf4GQq9/lzi//LwX/JiTbmZ8=; b=MmQViie8ZsBonZcboX4uIueL6yyZqb8DhR9vAmvIikzre2ZyIxp0PQzSB+hom+/KwbMsbvIBHjPT1C33at+xKnKUFM/m6ubIK2uiosGUodWH87c6sJnk4hegQiAltE0B3cJsfBaKUh0OVbyLRjr4Qmhnfjz6wwqnn2MDyKj/Lefasfsbo/ach6kz3/zq49cqx3leH2dLiRPG8CmBzJ5NSRJnrkN+QeNosVA7CibGpJ40Wf+6hbvVsEDszTjxmF65 Date: 26 Aug 2013 04:57:48 -0000 Message-ID: <20130826045748.71179.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <3077934.Ro9QPd6kt1@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: spf2@kitterman.com Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 26 Aug 2013 04:58:17 -0000 >> Are these valid? >> >> ip4:1.2.3.0/0024 ip6:1111:2222:3333:4444::/0064 >> >> If so, the current ABNF is fine and the suggested stuff isn't, other >> than perhaps adding the comments about the value ranges. > >I wouldn't have thought they were valid. In pyspf, which is most convenient >for me to quickly check, they both cause a permerror. I looked at pyspf and the regexp it uses to match a CIDR doesn't match the current ABNF. The current ABNF is: ip4-cidr-length = "/" 1*DIGIT Its pattern matches approximately this: ip4-cidr-length = "/" ("0" | %x31-39 0*DIGIT) That is, the number after the slash has to be 0, or start with a non-zero. It uses the same pattern for ip4 and ip6 CIDRs, and range checks the values later. So now we have the existing ABNF and libspf2, which match. Then we have pyspf and the proposed ABNF, which are both different from the existing ABNF in different ways. I suggest we leave it alone, other than perhaps adding the comment about allowed values. R's, John From lear@cisco.com Sun Aug 25 22:44:31 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 AEFB421F9D18; Sun, 25 Aug 2013 22:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.561 X-Spam-Level: X-Spam-Status: No, score=-110.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 U8ZkiYatTfdM; Sun, 25 Aug 2013 22:44:26 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id D0B3721F9D75; Sun, 25 Aug 2013 22:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7385; q=dns/txt; s=iport; t=1377495866; x=1378705466; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=VMw+96AhMLqJwfn/ISGNjahcabTSrq0g3NAZXHAUe3I=; b=j5PZHjoQrrbVd31w+eXsUQ+CVmcdrQhaxTrx1xFZfwJv736ymTwXNTZE /sFfKDgfre2ha17D8wL73JMBIpW5Mu4i/hEv+vVofkpZQJ2Z0K6zpkMxN E3IB+rc9QV+pjJtpvfh+/bowPpDsuci9F+38ifmtoPsUrS6tWAbpImtWi k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FALfqGlKQ/khL/2dsb2JhbABagweELYVdtw6BIBZ0giQBAQEDASNVARAJAg4KCRYLAgIJAwIBAgErGgYNAQcBAYd3Bolsm0qRfZB4B4JogTEDl26RYYMgOg X-IronPort-AV: E=Sophos;i="4.89,956,1367971200"; d="scan'208,217";a="158892784" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 26 Aug 2013 05:44:22 +0000 Received: from mctiny.local ([10.61.174.183]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7Q5iKYR020884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Aug 2013 05:44:20 GMT Message-ID: <521AEB34.2030909@cisco.com> Date: Mon, 26 Aug 2013 07:44:20 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Pete Resnick References: <521A1F31.8080402@cisco.com> <521A7AD3.9000704@qti.qualcomm.com> In-Reply-To: <521A7AD3.9000704@qti.qualcomm.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------030507010107060701070506" X-Mailman-Approved-At: Sun, 25 Aug 2013 23:01:45 -0700 Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, 'IESG' , Apps Discuss Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 05:44:31 -0000 This is a multi-part message in MIME format. --------------030507010107060701070506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 8/25/13 11:44 PM, Pete Resnick wrote: > > Eliot, I would like to hear some followups to the folks who have > posted so far before more folks pile on. I'm hearing for the two above > major issues: > > On 1: Others have said that the document already points to 6686 where > quite a bit of justification is made, and in any event the present > document isn't the correct place for such justifications. Also, folks > have said that the document already says that syntactically incorrect > records will fail processing (with a "permerror" -- see section 4.6). The reference is to Appendix A. Unfortunately, the text there doesn't go far enough. All it says is: > 4. [SPF] itself included a faulty transition plan, likely because of > the late addition of a requirement to develop one -- it said: > > An SPF-compliant domain name SHOULD have SPF records of both RR > types. A compliant domain name MUST have a record of at least > one type. > > which means both can claim to be fully compliant while failing > utterly to interoperate. This reads as if somehow a record is a protocol. What I would suggest (at the very least) is the following: "Because ADMDs have in the past published either SPF or TXT records, and because some MTAs query for only one or the other, it is possible that an MTA will not find a published record. When both records are published it is possible for them to differ." I *think* these are the interoperability issues (I can't say because 6686 isn't clear). Because we know people are querying SPF records (there is ample empirical evidence), the text could even go further and say something like this: "While we are deprecating the SPF record, any ADMD that continues to publish an SPF record at this point MUST also publish the semantically equivalent TXT record." I don't know of instances in the wild where this was a problem, and if it wasn't then this isn't really an interoperability issue worth considering. That goes to a more substantial debate about whether the record should be deprecated. Again, I'm not taking a position about that here. There is matching text for MTAs: "MTAs MUST NOT query for RRTYPE 99 records." The text ALMOST says that in Section 4.4 and again in 13.2, but for some reason stops short. This goes to my other issue, that normative language is not appropriately used. > > On 2: Folks have said that you are incorrect about underscore in > labels being a problem as they are already widely used (e.g. SRV). I withdraw that issue. See exchange between Andrew, John and me. > > Were your comments misunderstood? > > I'm not sure why major issue 3 is "major", but I think the WG can > consider it (if it has not already) like some of the other things > you've mentioned. It's in Appendix C. I was looking at Appendix J. Withdrawn. Eliot --------------030507010107060701070506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 8/25/13 11:44 PM, Pete Resnick wrote:

Eliot, I would like to hear some followups to the folks who have posted so far before more folks pile on. I'm hearing for the two above major issues:

On 1: Others have said that the document already points to 6686 where quite a bit of justification is made, and in any event the present document isn't the correct place for such justifications. Also, folks have said that the document already says that syntactically incorrect records will fail processing (with a "permerror" -- see section 4.6).

The reference is to Appendix A.  Unfortunately, the text there doesn't go far enough.  All it says is:
   4.  [SPF] itself included a faulty transition plan, likely because of
       the late addition of a requirement to develop one -- it said:

         An SPF-compliant domain name SHOULD have SPF records of both RR
         types.  A compliant domain name MUST have a record of at least
         one type.

       which means both can claim to be fully compliant while failing
       utterly to interoperate.

This reads as if somehow a record is a protocol.  What I would suggest (at the very least) is the following:

"Because ADMDs have in the past published either SPF or TXT records, and because some MTAs query for only one or the other, it is possible that an MTA will not find a published record.  When both records are published it is possible for them to differ."

I *think* these are the interoperability issues (I can't say because 6686 isn't clear).

Because we know people are querying SPF records (there is ample empirical evidence), the text could even go further and say something like this:

"While we are deprecating the SPF record, any ADMD that continues to publish an SPF record at this point MUST also publish the semantically equivalent TXT record."  I don't know of instances in the wild where this was a problem, and if it wasn't then this isn't really an interoperability issue worth considering.  That goes to a more substantial debate about whether the record should be deprecated.  Again, I'm not taking a position about that here.

There is matching text for MTAs: "MTAs MUST NOT query for RRTYPE 99 records."  The text ALMOST says that in Section 4.4 and again in 13.2, but for some reason stops short.  This goes to my other issue, that normative language is not appropriately used.


On 2: Folks have said that you are incorrect about underscore in labels being a problem as they are already widely used (e.g. SRV).

I withdraw that issue.  See exchange between Andrew, John and me.

Were your comments misunderstood?

I'm not sure why major issue 3 is "major", but I think the WG can consider it (if it has not already) like some of the other things you've mentioned.

It's in Appendix C.  I was looking at Appendix J.  Withdrawn.

Eliot
--------------030507010107060701070506-- From sm@elandsys.com Sun Aug 25 23:04: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 34BCB11E8147 for ; Sun, 25 Aug 2013 23:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 q9hsjjjfNYMs for ; Sun, 25 Aug 2013 23:04:34 -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 1436D11E8131 for ; Sun, 25 Aug 2013 23:04:34 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.47]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7Q64FFl006186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 23:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377497068; bh=86+LOFl/x072xG4HYxDz2Ae1WezfEvoGnup8wYQO5jw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2QpJ21mYChjmRt6I9kt2WH4/r3ycFraEX3GDBHVl762RhviEe3eCHYMtMZqDjza/F Yvta4K0XotGVcbj7sggiXYK/UsnRe2ppZ/cRWfPoG5FG30bC1hwaugj5M0qetsIPpg oZAbpWkJqJSLcbLeAq2DfbjpZMYykzX5D7nNf+RE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377497068; i=@elandsys.com; bh=86+LOFl/x072xG4HYxDz2Ae1WezfEvoGnup8wYQO5jw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NhtEqa+xV9iW8pPku9pHv8Po+Z9v7rvQ2+uREBi7n3o4KT2KkADW7ybxwcOskc04L vZkEWmDZ603Um7ztc9Bv9ohB/38K52bZV/MdqQIFvfpaMzi9YkDJQ7Vn0O9a0JZz7V K2Q8XrHsizSDdPWOC64dxqAQKqx5nbINHH5SvorI= Message-Id: <6.2.5.6.2.20130825224004.0ae44070@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 25 Aug 2013 22:52:24 -0700 To: John Levine , spfbis@ietf.org From: S Moonesamy In-Reply-To: <20130826045748.71179.qmail@joyce.lan> References: <3077934.Ro9QPd6kt1@scott-latitude-e6320> <20130826045748.71179.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Dave Crocker , spf2@kitterman.com Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 26 Aug 2013 06:04:35 -0000 Hi John, At 21:57 25-08-2013, John Levine wrote: >I looked at pyspf and the regexp it uses to match a CIDR doesn't match >the current ABNF. > >The current ABNF is: > > ip4-cidr-length = "/" 1*DIGIT > >Its pattern matches approximately this: > > ip4-cidr-length = "/" ("0" | %x31-39 0*DIGIT) > >That is, the number after the slash has to be 0, or start with a >non-zero. It uses the same pattern for ip4 and ip6 CIDRs, and range >checks the values later. > >So now we have the existing ABNF and libspf2, which match. Then we >have pyspf and the proposed ABNF, which are both different from the >existing ABNF in different ways. > >I suggest we leave it alone, other than perhaps adding the comment >about allowed values. Thanks for the effort to help address the issues. The current ABNF is: ip4-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" 1*DIGIT Based on what you wrote I'll suggest: ip4-cidr-length = "/" 1*DIGIT ; value range 1-32 ip6-cidr-length = "/" 1*DIGIT ; value range 1-128 I am not trying to address the question mentioned in the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg04015.html Dave Crocker suggested: ip4-cidr-length = "/" 1*2DIGIT ; value range 1-32 ip6-cidr-length = "/" 1*3DIGIT ; value range 1-128 I'll have to explain the choice to Eliot. Could you make the choice? Regards, S. Moonesamy From sm@elandsys.com Sun Aug 25 23:04: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 48A6E11E815F; Sun, 25 Aug 2013 23:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 DmihhjDQeNe0; Sun, 25 Aug 2013 23:04:37 -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 0AB7111E8131; Sun, 25 Aug 2013 23:04:37 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.47]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7Q64FFn006186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 23:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377497074; bh=In+ExFq9zr5Hgj8KgKDaO4WBYpZSclm8Unf2vm/750s=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=nc5sXsIDF8LJUax9gD7/PzTfryRz/MwYF+kWHbVMHO9piIDJBAD+Z/7AbAMBBhipS XgfJ2NYhDIduhPT6UQzJsuOYhZw2l+dYx++dREVl3zt/xaxUltZHVoN0Ys0H+hijFv vkQhdPW21598IdKvusN4CuW6Z124ppyGiZV0qclM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377497074; i=@elandsys.com; bh=In+ExFq9zr5Hgj8KgKDaO4WBYpZSclm8Unf2vm/750s=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=WQv2VqZ+jgYZn9q+I0uEVj1rSHpeh0osg4hFW0HMxk49amc02ZRoxOjR2T2jbVNF5 ram5zAjG6dSlvVkDy6gw9thYNdxRj8ImRLZTzjV6AFEK0fwXXWjgLaHa2JDwRbvuU9 1eP2jpCzpQ8XSoCYw63dHM090+vMjEy8qCRK+Fpo= Message-Id: <6.2.5.6.2.20130825225335.0ae44820@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 25 Aug 2013 23:01:17 -0700 To: Eliot Lear , Pete Resnick From: S Moonesamy In-Reply-To: <521AEB34.2030909@cisco.com> References: <521A1F31.8080402@cisco.com> <521A7AD3.9000704@qti.qualcomm.com> <521AEB34.2030909@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, IESG , Apps Discuss Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 06:04:37 -0000 Hi Eliot, At 22:44 25-08-2013, Eliot Lear wrote: >The reference is to Appendix A. Unfortunately, the text there >doesn't go far enough. All it says is: >> 4. [SPF] itself included a faulty transition plan, likely because of >> the late addition of a requirement to develop one -- it said: >> >> An SPF-compliant domain name SHOULD have SPF records of both RR >> types. A compliant domain name MUST have a record of at least >> one type. >> >> which means both can claim to be fully compliant while failing >> utterly to interoperate. > >This reads as if somehow a record is a protocol. What I would >suggest (at the very least) is the following: Yes, that text might be read in different ways. Your review brought a fresh perspective to the discussion. I'll ask the SPFBIS WG about the text. >I withdraw that issue. See exchange between Andrew, John and me. I'll list Issue 2 ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10270.html ) as addressed. >It's in Appendix C. I was looking at Appendix J. Withdrawn. I'll list Issue 3 ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10270.html ) as addressed. Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Sun Aug 25 23:16: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 A71A311E815E for ; Sun, 25 Aug 2013 23:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 wfXG6G8L-tD2 for ; Sun, 25 Aug 2013 23:16:09 -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 E64FB11E8156 for ; Sun, 25 Aug 2013 23:16:07 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.47]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7Q6FsCa011221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 23:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377497765; bh=xk/Xi8cdx3GVo20z+mxcw0YsVaDoXYpmJcY9Ub7HvPM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=w7wppe3bQzLU5+ASNAJl+cT6ME6kHDDLzFEllvm78JH55LCZO1OZRH/8lKP9hpfjn txMEU3zCyBrzXNRqHMOz99t7XiUymraBywZzk+/cwygA8IhyFPMs4Ds7xeltQYJZ5O +qXpZoaSuqByH9rLBcIeuHsrpIn+D/6mGW0JSiyI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377497765; i=@elandsys.com; bh=xk/Xi8cdx3GVo20z+mxcw0YsVaDoXYpmJcY9Ub7HvPM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ot/m39s4KfW7DU4tcPPIKgXKDnr6nN0KANtYpnitgy8MeGzqUwASpiGRGJQb4tTf8 M3/EHtC8l7fJVWklxCZfvSktQldXIY3c7D7hYXj3gAy8a/XAL4whxOZsfuWhlXsRPe N8hD5/2hLd2yDoaXbbqUD8V/ArlA/H71hrCH8lcU= Message-Id: <6.2.5.6.2.20130825230155.0ae43f28@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 25 Aug 2013 23:15:35 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <521AEB34.2030909@cisco.com> References: <521A1F31.8080402@cisco.com> <521A7AD3.9000704@qti.qualcomm.com> <521AEB34.2030909@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Pete Resnick Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 06:16:10 -0000 At 22:44 25-08-2013, Eliot Lear wrote: >On 8/25/13 11:44 PM, Pete Resnick wrote: >> >>Eliot, I would like to hear some followups to the folks who have >>posted so far before more folks pile on. I'm hearing for the two >>above major issues: >> >>On 1: Others have said that the document already points to 6686 >>where quite a bit of justification is made, and in any event the >>present document isn't the correct place for such justifications. >>Also, folks have said that the document already says that >>syntactically incorrect records will fail processing (with a >>"permerror" -- see section 4.6). > >The reference is to Appendix A. Unfortunately, the text there >doesn't go far enough. All it says is: >> 4. [SPF] itself included a faulty transition plan, likely because of >> the late addition of a requirement to develop one -- it said: >> >> An SPF-compliant domain name SHOULD have SPF records of both RR >> types. A compliant domain name MUST have a record of at least >> one type. >> >> which means both can claim to be fully compliant while failing >> utterly to interoperate. > >This reads as if somehow a record is a protocol. What I would >suggest (at the very least) is the following: > >"Because ADMDs have in the past published either SPF or TXT records, >and because some MTAs query for only one or the other, it is >possible that an MTA will not find a published record. When both >records are published it is possible for them to differ." > >I *think* these are the interoperability issues (I can't say because >6686 isn't clear). The suggested text (Because ADMDs) looks okay to me, minus the "MTA" term. Would the working group be okay with retaining that with some minor editing? >Because we know people are querying SPF records (there is ample >empirical evidence), the text could even go further and say >something like this: > >"While we are deprecating the SPF record, any ADMD that continues to >publish an SPF record at this point MUST also publish the >semantically equivalent TXT record." I don't know of instances in >the wild where this was a problem, and if it wasn't then this isn't >really an interoperability issue worth considering. That goes to a >more substantial debate about whether the record should be >deprecated. Again, I'm not taking a position about that here. > >There is matching text for MTAs: "MTAs MUST NOT query for RRTYPE 99 >records." The text ALMOST says that in Section 4.4 and again in >13.2, but for some reason stops short. This goes to my other issue, >that normative language is not appropriately used. Can the working group suggest what to do about this part? Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Mon Aug 26 05:51:38 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 DFF0021E8054 for ; Mon, 26 Aug 2013 05:51:37 -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 97blBahw74Jt for ; Mon, 26 Aug 2013 05:51:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 06C7C11E8194 for ; Mon, 26 Aug 2013 05:51:27 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BD2C720E40F6; Mon, 26 Aug 2013 08:51:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377521485; bh=XTGxpVnIOD7V4TANhNbZnrHZu2ZBlr0OdCQDYhPYxYI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=n/An/npaAe6Vil8e5n/0cA2MaeaRh0O53NGWYY/2EKPTtC+2Brxa11a21jXSD36cz 9LyUHWqHlBfW3JessxfeGHhtpQeSHcKfHP1dvMBBwgu2ZIiF4+fu13zdZ3W0f80Fwr 6gU61Nvkc13wRG8coRpmaaGtdGXYZqofNHSqp1X0= 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 A2B0C20E4043; Mon, 26 Aug 2013 08:51:13 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 26 Aug 2013 08:51:11 -0400 Message-ID: <1810938.1elvvlGtPX@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130825224004.0ae44070@resistor.net> References: <3077934.Ro9QPd6kt1@scott-latitude-e6320> <20130826045748.71179.qmail@joyce.lan> <6.2.5.6.2.20130825224004.0ae44070@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] Applications Directorate Review: ABNF 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, 26 Aug 2013 12:51:38 -0000 On Sunday, August 25, 2013 22:52:24 S Moonesamy wrote: > Hi John, > > At 21:57 25-08-2013, John Levine wrote: > >I looked at pyspf and the regexp it uses to match a CIDR doesn't match > >the current ABNF. > > > >The current ABNF is: > > ip4-cidr-length = "/" 1*DIGIT > > > >Its pattern matches approximately this: > > ip4-cidr-length = "/" ("0" | %x31-39 0*DIGIT) > > > >That is, the number after the slash has to be 0, or start with a > >non-zero. It uses the same pattern for ip4 and ip6 CIDRs, and range > >checks the values later. > > > >So now we have the existing ABNF and libspf2, which match. Then we > >have pyspf and the proposed ABNF, which are both different from the > >existing ABNF in different ways. > > > >I suggest we leave it alone, other than perhaps adding the comment > >about allowed values. > > Thanks for the effort to help address the issues. > > The current ABNF is: > > ip4-cidr-length = "/" 1*DIGIT > ip6-cidr-length = "/" 1*DIGIT > > Based on what you wrote I'll suggest: > > ip4-cidr-length = "/" 1*DIGIT ; value range 1-32 > ip6-cidr-length = "/" 1*DIGIT ; value range 1-128 > > I am not trying to address the question mentioned in the message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg04015.html > > Dave Crocker suggested: > > ip4-cidr-length = "/" 1*2DIGIT ; value range 1-32 > ip6-cidr-length = "/" 1*3DIGIT ; value range 1-128 > > I'll have to explain the choice to Eliot. Could you make the choice? I think John is correct: > So now we have the existing ABNF and libspf2, which match. Then we > have pyspf and the proposed ABNF, which are both different from the > existing ABNF in different ways. > > I suggest we leave it alone, other than perhaps adding the comment > about allowed values. Here's my suggestion: ip4-cidr-length = "/" 1*DIGIT ; value range 1-32 ip6-cidr-length = "/" 1*DIGIT ; value range 1-128 dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] ; Avoid leading zeros in cidr-lengths since not all ; implementations recognize them as valid. Does that work? My intent there is to make libspf2 correct, but warn about more strict implementations. Scott K From hsantos@isdg.net Mon Aug 26 05:55:40 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 6328B21F9C53 for ; Mon, 26 Aug 2013 05:55:40 -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.300, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=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 UhNKcfMSH1pg for ; Mon, 26 Aug 2013 05:55:40 -0700 (PDT) Received: from catinthebox.net (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 281B311E8192 for ; Mon, 26 Aug 2013 05:55:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3419; t=1377521720; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=VEqa0igEiNPAPszmhRQsR0G55kE=; b=dLNqBqFCC3xOlnk7s7du yFfYAlklQpu2hEJtyDxEYmX2nX3Tu6UNAzyhM3GhubIkRXoOgICZyWh6eRFU+tF7 a06RmmDisULOHMMJEQEhpci8Il9mbTlh2jHOPfznSP8FSpAVXcM+s5CSHresXmvy Fibsjd/uuVXai9YdBZbcUZM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 26 Aug 2013 08:55:20 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3984230982.7373.2328; Mon, 26 Aug 2013 08:55:19 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3419; t=1377521398; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=JaVgqxQ R3DSrk8AF81h8Fddowx+lvGfakKZzkpBTUg8=; b=E94e3x8Qe3fdVy+I5c3MN0i Zqvfah2cR6VG3g2c6VYg2x/NxR6K/xTCXcXOyyOcQ6EzdS+xQxVRopNTHVG6utvZ bb9g7fkb5FLo8C0IvmLCZYuKWS4RdivUAyjfnh+C/PtWh9ERUeDbISlvBfmyjPr9 Oxw635hvs6y0VRy0r3HA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 26 Aug 2013 08:49:58 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3430647018.9.5076; Mon, 26 Aug 2013 08:49:58 -0400 Message-ID: <521B502D.5010106@isdg.net> Date: Mon, 26 Aug 2013 08:55:09 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Eliot Lear References: <521A1F31.8080402@cisco.com> In-Reply-To: <521A1F31.8080402@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, 'IESG' , Apps Discuss Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 12:55:40 -0000 Hi Eliot, I appreciate your review of SPFBIS. I only have a few small input bits to provide: Eliot Lear wrote: > Summary: This draft is not yet ready for publication as a Proposed > Standard and should be revised before publication. +1 > Major issues: > > 1. Deprecation of SPF record not properly justified in text and in the > wrong place > > Deprecation of the SPF record is given short shrift in Section 13.1 > which is the IANA considerations section. A persistent reader would not > understand why the record was in fact deprecated. Here's what is 13.1 > (there are a few words about 6686 in 3.1 as well, but nobody would care > if this was simply a matter of low implementation/deployment). > >> Studies have shown that RRTYPE 99 has not seen any substantial use, >> and in fact its existence and mechanism defined in [RFC4408] has led >> to some interoperability issues. > > First, this text should be moved out of the IANA considerations sections > and forward to Section 3.1. Second it should explain what those > interoperability issues are or have a normative (and retrievable) > reference. At the very least, the winning argument(s) should be > elucidated, and not just for posterity: the claim is that there is an > interoperability problem. If so, then might administrators want to know > that? > > The matter of handling garbage in garbage out is not well enough > specified in Section 3. I would go considerably further and state that > (a) records that do not begin with "v=spf1" MUST NOT be processed > further, and (b) that any record that does not conform to the stated > grammar MUST be ignored. I think the documentation usage of the term "SPF record" can be confusing if the type99 is going to be removed. It can suggest that this "SPF record" is unique and is not residing with other "records." I think the term should be more specific to say the SPF TXT resultant record contains multiple EOL (CRLF or CR or LF terminators) strings and and only a string beginning with the *token* "v=spf1" is a considered a SPF record string. In theory, the parser should tokenizing it to check for "v=" and then only process the v= value "spf1" Perhaps a more specific term such as "SPF Line Record" or String would be clearer. > Also, did the working group consider a > DKIM-like solution? They all but establish an _spf label in this > document (I'll come to that in a moment). Yes. It was but I didn't think it was taken serious. I can see now the draft was leaning towards to publishing method. My particular concern with this is that it also yields a TXT/TXT dual call waste and high redundancy if it doesn't become a learned processed (a domain is known to use _spf. zone). In other words, for large ESP using this method, it will yield a very high overhead in at least TWO TXT lookups. Keep in mind one of the SPF99/TXT concerns is the wasted SPF99 call. > There is a general issue about when to deprecate an RR and the ability > to add new RRs into the DNS. That issue has to be addressed in the > longer term, no matter what the IESG and community decide here. > Furthermore, to be clear, please do not read into the above comments an > opinion about deprecation of the record itself, which I am withholding > until there is clear text about the interoperability issues that are > mentioned. +1. -- HLS From spf2@kitterman.com Mon Aug 26 06:03:45 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 8373721E8086 for ; Mon, 26 Aug 2013 06:03:45 -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 6Hii3X8bE4ra for ; Mon, 26 Aug 2013 06:03:40 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 496B021E8084 for ; Mon, 26 Aug 2013 06:03:40 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C5F3B20E40F6; Mon, 26 Aug 2013 09:03:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377522219; bh=INs8PteRSyC3raVZJ+czWCohwGI0Id+kGhebgu7NAvw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GCtrG619sV14bijJLv5Iypi/ouAf1NeZRB20KQa/5JBdhNHOmdAHGB7FcNv/SlQMD JrLgZzmQBNjhs+4PwNM/RcZTZeqDmhbxFeWE+iifbe+YW2OyePG9PUUcY0hnlUjFzg +Shr9dKmClg6YQjgIn5u5/9hTce3cpadKGzm7zco= 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 A927120E4043; Mon, 26 Aug 2013 09:03:39 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 26 Aug 2013 09:03:39 -0400 Message-ID: <3787569.VibHSKzExA@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130825230155.0ae43f28@elandnews.com> References: <521A1F31.8080402@cisco.com> <521AEB34.2030909@cisco.com> <6.2.5.6.2.20130825230155.0ae43f28@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] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 13:03:45 -0000 On Sunday, August 25, 2013 23:15:35 S Moonesamy wrote: > At 22:44 25-08-2013, Eliot Lear wrote: > >On 8/25/13 11:44 PM, Pete Resnick wrote: > >>Eliot, I would like to hear some followups to the folks who have > >>posted so far before more folks pile on. I'm hearing for the two > >>above major issues: > >> > >>On 1: Others have said that the document already points to 6686 > >>where quite a bit of justification is made, and in any event the > >>present document isn't the correct place for such justifications. > >>Also, folks have said that the document already says that > >>syntactically incorrect records will fail processing (with a > >>"permerror" -- see section 4.6). > > > >The reference is to Appendix A. Unfortunately, the text there > > > >doesn't go far enough. All it says is: > >> 4. [SPF] itself included a faulty transition plan, likely because of > >> > >> the late addition of a requirement to develop one -- it said: > >> An SPF-compliant domain name SHOULD have SPF records of both RR > >> types. A compliant domain name MUST have a record of at least > >> one type. > >> > >> which means both can claim to be fully compliant while failing > >> utterly to interoperate. > > > >This reads as if somehow a record is a protocol. What I would > >suggest (at the very least) is the following: > > > >"Because ADMDs have in the past published either SPF or TXT records, > >and because some MTAs query for only one or the other, it is > >possible that an MTA will not find a published record. When both > >records are published it is possible for them to differ." > > > >I *think* these are the interoperability issues (I can't say because > >6686 isn't clear). > > The suggested text (Because ADMDs) looks okay to me, minus the "MTA" > term. Would the working group be okay with retaining that with some > minor editing? I think we discussed this before and, as several people have re-iterated, concluded that 4408bis wasn't the place to document the rationale for this decision. I don't understand what problem adding the text solves? If we need to go back and add rationale for all the changes we made, it's going to delay the document significantly for, IMO, no good purpose. If we aren't, then I don't think this change deserves to be treated differently. > >Because we know people are querying SPF records (there is ample > >empirical evidence), the text could even go further and say > >something like this: > > > >"While we are deprecating the SPF record, any ADMD that continues to > >publish an SPF record at this point MUST also publish the > >semantically equivalent TXT record." I don't know of instances in > >the wild where this was a problem, and if it wasn't then this isn't > >really an interoperability issue worth considering. That goes to a > >more substantial debate about whether the record should be > >deprecated. Again, I'm not taking a position about that here. > > > >There is matching text for MTAs: "MTAs MUST NOT query for RRTYPE 99 > >records." The text ALMOST says that in Section 4.4 and again in > >13.2, but for some reason stops short. This goes to my other issue, > >that normative language is not appropriately used. > > Can the working group suggest what to do about this part? We aren't deprecating type SPF. We're removing it from the protocol. We did discuss this. IIRC, we had something very like MUST NOT publish, MUST NOT query ..., but removed it in favor of just removing type SPF from the protocol description. I think it might be reasonable to be more verbose in Appendix C, which currently says: o Use of DNS RR type SPF (99) has been removed from the protocol, see [RFC6686] for background. Personally, I think it's accurate and succinct and I'm not sure what to change that would amount to the same thing in a lot more words. To me, ... has been removed ... . .... MUST NOT query ... . ... MUST NOT publish ... . Is redundant, but I don't strongly object if people think it would be better. Scott K From johnl@taugh.com Mon Aug 26 07:27:45 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 16DF411E81A3 for ; Mon, 26 Aug 2013 07:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, 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 Uhd+I0tEC8Kc for ; Mon, 26 Aug 2013 07:27:44 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 941E311E81A9 for ; Mon, 26 Aug 2013 07:27:43 -0700 (PDT) Received: (qmail 47278 invoked from network); 26 Aug 2013 14:27:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=b8ad.521b65dd.k1308; bh=KrFMBQbINFVeye7JjgIKul9clo39rnLBghSPW0c9iWo=; b=YEJqEiBmINXdK+DVfkA1AZJs0QYAEGGwfjFLAjLgF8JZqhjcuCzap2/k5Xu7QVMZij8B31qMRP+nKZn3jBwYUZwEmEQlD2n18Ff34RAxLfK/qmmHYgf/taRZEad43riiFxSJXhvWOjhIEzJF+6tdCBXl27BS4VkGRodZvx4WYVgyv8gtMF2LnLbwS2d4ewapH3p+JLoZqVJJOS+Ny/yn6kyokNP60Ab2Eyv5h5TnNQ+/rtoJperYAkrmEm0NR1Wk DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=b8ad.521b65dd.k1308; bh=KrFMBQbINFVeye7JjgIKul9clo39rnLBghSPW0c9iWo=; b=NCcKYrlk6rkCV66Qlg0E100TNNSdppDxxsuoMrg3ML1xNACHOgf7QskRtw9UrJE7Y9KB7QRgIrl151qkudD1oRok8QA+z4MPsuElRaGW+UbuZuIbD9CntONqtgMcr5HDdMOe42xelLmYvaHjWlCtg47mnQ0nZnH3zQkiNEgzZWoNxaHzFagbkrsAQIMZJ0H+xiWCYZRkEQrSVoDTCD+fD/cWihlgfF+ZdDE3uKWzn8DcLQbwlwQkoEjVuoI3WsQw Received: (ofmipd 127.0.0.1); 26 Aug 2013 14:27:19 -0000 Date: 26 Aug 2013 10:27:41 -0400 Message-ID: From: "John R Levine" To: "S Moonesamy" In-Reply-To: <6.2.5.6.2.20130825224004.0ae44070@resistor.net> References: <3077934.Ro9QPd6kt1@scott-latitude-e6320> <20130826045748.71179.qmail@joyce.lan> <6.2.5.6.2.20130825224004.0ae44070@resistor.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-236100256-1377527261=:76238" Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 26 Aug 2013 14:27:45 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-236100256-1377527261=:76238 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > Based on what you wrote I'll suggest: > > ip4-cidr-length = "/" 1*DIGIT ; value range 1-32 > ip6-cidr-length = "/" 1*DIGIT ; value range 1-128 > > I am not trying to address the question mentioned in the message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg04015.html > > Dave Crocker suggested: > > ip4-cidr-length = "/" 1*2DIGIT ; value range 1-32 > ip6-cidr-length = "/" 1*3DIGIT ; value range 1-128 > > I'll have to explain the choice to Eliot. Could you make the choice? This seems to match the least badly: > ip4-cidr-length = "/" 1*DIGIT ; value range 0-32 > ip6-cidr-length = "/" 1*DIGIT ; value range 0-128 Although it doesn't explicitly say so in 4408 or the current draft, both pyspf and libspf2 accept /0 and treat it as equivalent to /32 or /128. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-236100256-1377527261=:76238 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODI2MTQyNzQxWjAjBgkqhkiG 9w0BCQQxFgQUv4F9wGM3kRLBpuZWGC77AdP07SsweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAm3DNqt7TkLnr g1hXEG2OZBe8uCkc8Dq0UAaO7gIRD9KEqkSrWZ0uktcuiTPKcc/xv+FmkL15 7xPpsl8BYh7p5M98Em2+A4548Qxn9y22QHgDr8oe/C9nuz57Yih/3RtcvN3a oJXd2X5Hu2wxkTIsYBAMzjxdyrnAOkqKWrDmxRK+z+UW1wQNVGvb8ru8cxgS /1aaqYcDuDOLM4WRCWkX6s6K00+y8rCG/kaiXr4+HMkPMx5KRRoooUi0JQ7b iVLkg5AiBflOl/DICkCvHfGidr9XBWR5cooPnl1NXM3ytiF2Qk64Q6BGIsu4 VWM0qzrX2vqnks6sshPGDIGdTEJpjQ== --3825401791-236100256-1377527261=:76238-- From dhc@dcrocker.net Mon Aug 26 07:33: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 ADED211E81AA for ; Mon, 26 Aug 2013 07:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2THvbuvv9-v for ; Mon, 26 Aug 2013 07:33:18 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C068A21F9B92 for ; Mon, 26 Aug 2013 07:33:18 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7QEX02K015225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Aug 2013 07:33:03 -0700 Message-ID: <521B6714.9090707@dcrocker.net> Date: Mon, 26 Aug 2013 07:32:52 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John R Levine References: <3077934.Ro9QPd6kt1@scott-latitude-e6320> <20130826045748.71179.qmail@joyce.lan> <6.2.5.6.2.20130825224004.0ae44070@resistor.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 26 Aug 2013 07:33:03 -0700 (PDT) Cc: spfbis@ietf.org, S Moonesamy Subject: Re: [spfbis] Applications Directorate Review: ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 14:33:23 -0000 On 8/26/2013 7:27 AM, John R Levine wrote: > This seems to match the least badly: > >> ip4-cidr-length = "/" 1*DIGIT ; value range 0-32 >> ip6-cidr-length = "/" 1*DIGIT ; value range 0-128 > > Although it doesn't explicitly say so in 4408 or the current draft, both > pyspf and libspf2 accept /0 and treat it as equivalent to /32 or /128. 1. Why don't you like specifying the limit on number of digits? I think it makes the rule more informative to the reader, as well as creating a slightly more accurate parser. 2. I had wondered about permitting zero, so that change makes sense to me. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Mon Aug 26 07:41:47 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 7E34C21E8056 for ; Mon, 26 Aug 2013 07:41:47 -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 s2M6Jk3OIqPC for ; Mon, 26 Aug 2013 07:41:43 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 109EE21F9FD5 for ; Mon, 26 Aug 2013 07:41:43 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1529720E40F6; Mon, 26 Aug 2013 10:41:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377528101; bh=ia+N1v9JeijPbmhSKXFl43LLcaqQfKX02ne6qGtR7sU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nDas9u2qiEfhBVjQJHiFzYvbIt4u0eUUw74YrDfYhDB08C5eNUbtLLbdNhget2j0/ fOkdpY+qDRpW1dc4v1YlLz2fhHEH6rTGRR7rpP1qxaqvLIrPR8xsM2n+FZ4U9NsCYC 7lf0fNfLqOZ1dcRGSmAi+7IiNK+vSHq/IhI37moA= 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 ED7F920E4043; Mon, 26 Aug 2013 10:41:40 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 26 Aug 2013 10:41:40 -0400 Message-ID: <1654880.IYAKZHZZ4B@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: References: <3077934.Ro9QPd6kt1@scott-latitude-e6320> <6.2.5.6.2.20130825224004.0ae44070@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] Applications Directorate Review: ABNF 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, 26 Aug 2013 14:41:47 -0000 On Monday, August 26, 2013 10:27:41 John R Levine wrote: > > Based on what you wrote I'll suggest: > > ip4-cidr-length = "/" 1*DIGIT ; value range 1-32 > > ip6-cidr-length = "/" 1*DIGIT ; value range 1-128 > > > > I am not trying to address the question mentioned in the message at > > http://www.ietf.org/mail-archive/web/spfbis/current/msg04015.html > > > > Dave Crocker suggested: > > ip4-cidr-length = "/" 1*2DIGIT ; value range 1-32 > > ip6-cidr-length = "/" 1*3DIGIT ; value range 1-128 > > > > I'll have to explain the choice to Eliot. Could you make the choice? > > This seems to match the least badly: > > ip4-cidr-length = "/" 1*DIGIT ; value range 0-32 > > ip6-cidr-length = "/" 1*DIGIT ; value range 0-128 > > Although it doesn't explicitly say so in 4408 or the current draft, both > pyspf and libspf2 accept /0 and treat it as equivalent to /32 or /128. I just checked pyspf 2.0.7 and 2.0.8 and they both accept /0 and will match it to anything. If I am reading RFC 4632 correctly, that's expected behavior. I don't expect /0 to be particularly useful, but I think it's not technically wrong. Scott K From superuser@gmail.com Mon Aug 26 08:15:27 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 8BDD121F9F6F for ; Mon, 26 Aug 2013 08:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 dXampaLfabaQ for ; Mon, 26 Aug 2013 08:15:26 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C754B21F9D28 for ; Mon, 26 Aug 2013 08:15:25 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so818373wgg.10 for ; Mon, 26 Aug 2013 08:15:25 -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=TIIMcOpgazTMWHUbPbkaLjA3cdswGukvmcBy8ALosCI=; b=Dr4wbFFtGxFdcRUF2Jy/HIYkCqKhF8CwAkohXr5MnJZ9jrAkXKAND+j4ZRdXThzhNT nIHnBPoPVrM64wvySMQw5IpOsRklaoNpaiwoYp0zJYMK9lF4dWI1Eu7YkiIc414Zz91i FMSsGg4iV21J7wSL1CNBr9Z+10axQfNIGcKLvk4l1FZSm2tTy8tG5duPmHyWowSmfqjl LUzT5KSlZYDsGNWfWGIOzkg4I6nV+qEfDhX6AQmftI+jYsKZL1UUA7wYouvxUvW0ds3z J8bqakqbSvKoAxkM9dgO+nr0vh/UwiZxkTAk19KHOdbZjyqAnVIDq+BobXU9iPEWw8gC JDGA== MIME-Version: 1.0 X-Received: by 10.194.240.101 with SMTP id vz5mr56176wjc.69.1377530124948; Mon, 26 Aug 2013 08:15:24 -0700 (PDT) Received: by 10.180.75.144 with HTTP; Mon, 26 Aug 2013 08:15:24 -0700 (PDT) In-Reply-To: <521B6714.9090707@dcrocker.net> References: <3077934.Ro9QPd6kt1@scott-latitude-e6320> <20130826045748.71179.qmail@joyce.lan> <6.2.5.6.2.20130825224004.0ae44070@resistor.net> <521B6714.9090707@dcrocker.net> Date: Mon, 26 Aug 2013 08:15:24 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11c28a40c3d93b04e4db392e Cc: "spfbis@ietf.org" , John R Levine , S Moonesamy Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 26 Aug 2013 15:15:27 -0000 --001a11c28a40c3d93b04e4db392e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 26, 2013 at 7:32 AM, Dave Crocker wrote: > On 8/26/2013 7:27 AM, John R Levine wrote: > >> This seems to match the least badly: >> >> ip4-cidr-length = "/" 1*DIGIT ; value range 0-32 >>> ip6-cidr-length = "/" 1*DIGIT ; value range 0-128 >>> >> >> Although it doesn't explicitly say so in 4408 or the current draft, both >> pyspf and libspf2 accept /0 and treat it as equivalent to /32 or /128. >> > > > 1. Why don't you like specifying the limit on number of digits? I think > it makes the rule more informative to the reader, as well as creating a > slightly more accurate parser. > > 2. I had wondered about permitting zero, so that change makes sense to me. > > I concur: I like 1*2DIGIT and 1*3DIGIT, with a range that includes 0. -MSK --001a11c28a40c3d93b04e4db392e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 26, 2013 at 7:32 AM, Dave Crocker <dhc@dcrocke= r.net> wrote:
On 8/26/2013 7:27 AM, John= R Levine wrote:
This seems to match the least badly:

=A0ip4-cidr-length =A0=3D "/" 1*DIGIT ; value range 0-32
=A0ip6-cidr-length =A0=3D "/" 1*DIGIT ; value range 0-128

Although it doesn't explicitly say so in 4408 or the current draft, bot= h
pyspf and libspf2 accept /0 and treat it as equivalent to /32 or /128.


1. Why don't you like specifying the limit on number of digits? =A0I th= ink it makes the rule more informative to the reader, as well as creating a= slightly more accurate parser.

2. I had wondered about permitting zero, so that change makes sense to me.<= span class=3D"HOEnZb">


I concur:=A0 I like 1*2D= IGIT and 1*3DIGIT, with a range that includes 0.

-MSK

--001a11c28a40c3d93b04e4db392e-- From johnl@iecc.com Mon Aug 26 08:36:39 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 4D2A411E81C5 for ; Mon, 26 Aug 2013 08:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 q1t8SU41acdB for ; Mon, 26 Aug 2013 08:36:35 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D621611E81A2 for ; Mon, 26 Aug 2013 08:36:34 -0700 (PDT) Received: (qmail 64125 invoked from network); 26 Aug 2013 15:36:32 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Aug 2013 15:36:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521b7600.xn--yuvv84g.k1308; i=johnl@user.iecc.com; bh=teR9EJMp4kiBq7XoHd5fgtJ8RCnLipLieDdHCWtew9g=; b=afS87Dw8BOdtb7weZV/ZVnx2WZx5mgMUZeFSdcz78xulWwnfhGWXZQxy0AlzCTsBbZ3+glcZuW0juGnN0hdBANf86YZyOM2yeOw2f2uhvQQf/BQCg7iDVa91bz1wtIh7ykP2QR1kwTHKP7OtPDiT9O4+zb0IlSbhrB/w0xkknXYeBlCxErQUghMTxMC/Anhj565izLwPlpvo5kbpWJKbtpXJfTsIdIwA2D195Ji8qs4HRWLHhqCr5XdqfRTPnpMO DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521b7600.xn--yuvv84g.k1308; olt=johnl@user.iecc.com; bh=teR9EJMp4kiBq7XoHd5fgtJ8RCnLipLieDdHCWtew9g=; b=Y57xFZM10hc6C+Feemk91hoqkaqoMSIQu/AqaSNw6YyIHGseCfZMPH3TJxqagDQ1dIpsSlC0eTWupAtACR3sIVyH3in/xYvtEpa7n4SkTs8ILKuOxD4kUkPKdpD6038CGnKqmawIffsReAAEhgBFpbwGOPMgx6KpHFGPxFC0cmHVlYQmvV+xUwNz8HxAZ0mF1xy6KSpUvFs56zHsiDaEz2tGEdfbnNuqhJVddEmYlM//I3sH6wydCnNGszzysSs0 Date: 26 Aug 2013 15:36:10 -0000 Message-ID: <20130826153610.81071.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <521B6714.9090707@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: dcrocker@bbiw.net Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 26 Aug 2013 15:36:39 -0000 >1. Why don't you like specifying the limit on number of digits? I think >it makes the rule more informative to the reader, as well as creating a >slightly more accurate parser. Installed base. But I took a look at perl Mail::SPF which I think is more widely used than pyspf, since it's what spamassassin uses to do a SPF check. It also has code to prohibit leading zeros, so it looks like the best match to the installed base is this: ip4-cidr-length = "/" ("0" | %x31-39 0*DIGIT) ; value range 0-32 ip6-cidr-length = "/" ("0" | %x31-39 0*DIGIT) ; value range 0-128 Even though 0*DIGIT doesn't explicitly limit the number of digits, the value range does it for you, and that's how pyspf and Mail::SPF do it. R's, John From tony@att.com Mon Aug 26 08:38:10 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 2B7CC11E81C6 for ; Mon, 26 Aug 2013 08:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.894 X-Spam-Level: X-Spam-Status: No, score=-105.894 tagged_above=-999 required=5 tests=[AWL=0.705, 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 iucZX5kzAK5g for ; Mon, 26 Aug 2013 08:38:03 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 27C6D11E81C5 for ; Mon, 26 Aug 2013 08:38:03 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id a567b125.0.1367863.00-484.3729390.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 26 Aug 2013 15:38:03 +0000 (UTC) X-MXL-Hash: 521b765b121682e4-524e379e8b5d88b34ccd34535571ad1c7098d7c8 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7QFc2mx020468 for ; Mon, 26 Aug 2013 11:38:02 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7QFbqlG020393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Aug 2013 11:37:58 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Mon, 26 Aug 2013 15:37:41 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7QFbfRs014840 for ; Mon, 26 Aug 2013 11:37:41 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7QFbZWJ014638 for ; Mon, 26 Aug 2013 11:37:36 -0400 Received: from [135.91.110.247] (ds135-91-110-247.dhcps.ugn.att.com[135.91.110.247]) by maillennium.att.com (mailgw1) with ESMTP id <20130826153735gw1004nh80e> (Authid: tony); Mon, 26 Aug 2013 15:37:35 +0000 X-Originating-IP: [135.91.110.247] Message-ID: <521B763E.4090307@att.com> Date: Mon, 26 Aug 2013 11:37:34 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John R Levine References: <3077934.Ro9QPd6kt1@scott-latitude-e6320> <20130826045748.71179.qmail@joyce.lan> <6.2.5.6.2.20130825224004.0ae44070@resistor.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=EZl/toaC c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=VAG9_9YYm2gA:10 a=sCfsyOEanakA:10 a=dBqptANV09QA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=t_sxTune5RMA:10 a=sAhhcdh1qWtQX1ezL-AA:9 a=wPNLv] X-AnalysisOut: [fGTeEIA:10 a=0thF2PhejpMA:10 a=6ajUA_JZetUA:10 a=wGFMHrTpf] X-AnalysisOut: [glnVu4b:21 a=NXjip7h_sNBrsBku:21] Cc: spfbis@ietf.org, S Moonesamy Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 26 Aug 2013 15:38:10 -0000 On 8/26/2013 10:27 AM, John R Levine wrote: > ip4-cidr-length = "/" 1*DIGIT ; value range 0-32 >> ip6-cidr-length = "/" 1*DIGIT ; value range 0-128 > > Although it doesn't explicitly say so in 4408 or the current draft, > both pyspf and libspf2 accept /0 and treat it as equivalent to /32 or > /128. RFC 4632 section 3.1 specifically allows 0. It's not taken as equivalent to /32|/128, but instead as a complete wildcard for the address. Tony From dhc@dcrocker.net Mon Aug 26 08:42: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 B5C9A21F9C60 for ; Mon, 26 Aug 2013 08:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV5T6Y5qQboR for ; Mon, 26 Aug 2013 08:41:57 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9761121F9C28 for ; Mon, 26 Aug 2013 08:41:57 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7QFfr03016937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Aug 2013 08:41:56 -0700 Message-ID: <521B7740.8070403@dcrocker.net> Date: Mon, 26 Aug 2013 08:41:52 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Levine References: <20130826153610.81071.qmail@joyce.lan> In-Reply-To: <20130826153610.81071.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 26 Aug 2013 08:41:56 -0700 (PDT) Cc: spfbis@ietf.org, dcrocker@bbiw.net Subject: Re: [spfbis] Applications Directorate Review: ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 15:42:07 -0000 On 8/26/2013 8:36 AM, John Levine wrote: >> 1. Why don't you like specifying the limit on number of digits? I think >> it makes the rule more informative to the reader, as well as creating a >> slightly more accurate parser. > > Installed base. But I took a look at perl Mail::SPF which I think is > more widely used than pyspf, since it's what spamassassin uses to do a > SPF check. > > It also has code to prohibit leading zeros, so it looks like the best match > to the installed base is this: > > ip4-cidr-length = "/" ("0" | %x31-39 0*DIGIT) ; value range 0-32 > > ip6-cidr-length = "/" ("0" | %x31-39 0*DIGIT) ; value range 0-128 > > Even though 0*DIGIT doesn't explicitly limit the number of digits, the > value range does it for you, and that's how pyspf and Mail::SPF do it. 1. 0* means that there can be /no/ digits. However in the context the rule is used, there must be at least one digit. Otherwise, for example, you could get 1.2..3 2. I don't understand why you are resisting an iteration count that matches the actual number of digits appropriate for each address type. 3. Other elaborations, such as prohibiting leading zeroes, sound fine. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Mon Aug 26 11:36:06 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 90A5221F9C89 for ; Mon, 26 Aug 2013 11:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 X3kUN0GKpyPt for ; Mon, 26 Aug 2013 11:36:05 -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 B8EEC21F90A7 for ; Mon, 26 Aug 2013 11:36:05 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.47]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7QIZrP9007485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Aug 2013 11:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377542164; bh=/jhmBPMXECtsoVNYVJUxCzxWzL71HoUeXXhrHdqdFzo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NSwUCRMdc8b7dLVJ9RizdGVORjY6lhert+pLelfDJWgFMtCs4FjQ9GY6ZvtE31qV/ q1sGSAoxo3BOg7NKdi3kjx+nRyVwMJv9uZiMmYSli0mfOMn6spxH4T9YuTQf0RGY/D MGQglJRmS4RCWqpJcHuoOFISzSjkalTrjnAjfYFw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377542164; i=@elandsys.com; bh=/jhmBPMXECtsoVNYVJUxCzxWzL71HoUeXXhrHdqdFzo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MDSdJmgbLxDYJevbgPFtkXtHXh4SNkjlGTy2vlFL0k5gr1aLjxP0yeoyOurzn7+MT 0wJgMRiRRd8CKLBN1EUNMbDaEGs3WLD6NwBuPU7dA9Mfr3B3dPQN3MZpaAf3Spd6BA H8rUxCzEpW0TqeQIEGUmaEiZFNvmus19oozlZ+ZA= Message-Id: <6.2.5.6.2.20130826105233.0b8981c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 26 Aug 2013 11:35:26 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <3787569.VibHSKzExA@scott-latitude-e6320> References: <521A1F31.8080402@cisco.com> <521AEB34.2030909@cisco.com> <6.2.5.6.2.20130825230155.0ae43f28@elandnews.com> <3787569.VibHSKzExA@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 18:36:06 -0000 Hi Scott, I am adding back the Cc so that someone who has not provided input might be able to comment. At 06:03 26-08-2013, Scott Kitterman wrote: >I think we discussed this before and, as several people have re-iterated, >concluded that 4408bis wasn't the place to document the rationale for this >decision. I don't understand what problem adding the text >solves? If we need >to go back and add rationale for all the changes we made, it's going to delay >the document significantly for, IMO, no good purpose. If we aren't, then I >don't think this change deserves to be treated differently. If I understood the review, the argument is about an explanation for the administrator. The reviewer is not asking for a rationale for all the changes which was made. This is about Issue 1 only. I only need to address the review. I can go with "4408bis is not the place to document the rationale". >We aren't deprecating type SPF. We're removing it from the protocol. We did >discuss this. IIRC, we had something very like MUST NOT publish, MUST NOT >query ..., but removed it in favor of just removing type SPF from >the protocol >description. I think it might be reasonable to be more verbose in >Appendix C, >which currently says: > > o Use of DNS RR type SPF (99) has been removed from the protocol, > see [RFC6686] for background. > >Personally, I think it's accurate and succinct and I'm not sure what >to change >that would amount to the same thing in a lot more words. To me, ... has been >removed ... . .... MUST NOT query ... . ... MUST NOT publish ... . Is >redundant, but I don't strongly object if people think it would be better. Yes. I'll wait a day before closing this one. Regards, S. Moonesamy (as document shepherd) From angel@16bits.net Mon Aug 26 13:53:47 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 CF79711E8227 for ; Mon, 26 Aug 2013 13:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, MIME_8BIT_HEADER=0.3] 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 Zf93bYNg9GZA for ; Mon, 26 Aug 2013 13:53:36 -0700 (PDT) Received: from mailer.hiddenmail.net (mailer.hiddenmail.net [199.195.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1519D11E821F for ; Mon, 26 Aug 2013 13:53:36 -0700 (PDT) Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from ) id 1VE3mp-0007uD-Fq for spfbis@ietf.org; Mon, 26 Aug 2013 22:53:24 +0200 Message-ID: <1377550726.905.4.camel@localhost.localdomain> From: =?ISO-8859-1?Q?=C1ngel?= To: spfbis@ietf.org Date: Mon, 26 Aug 2013 22:58:46 +0200 In-Reply-To: <20130824002253.7662338D39D5@drugs.dv.isc.org> References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se> <521495EB.7060207@cisco.com> <1C40FB10-3705-4E80-8DEB-D14B63D24C97@frobbit.se> <5214A593.8030907@cisco.com> <8D23D4052ABE7A4490E77B1A012B63077525FC8E@mbx-01.win.nominum.com> <6.2.5.6.2.20130821185309.0cadf930@resistor.net> <521576AC.6090100@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B63077526138F@mbx-01.win.nominum.com> <52158701.3010802@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307752614A8@mbx-01.win.nominum.com> <20130822070359.5A1AC38C7B54@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B 6307752 6 1957@mbx-01.win.nominum.com> <20130822202314.C4A8F38CBA08@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B63077526274C@mbx-01.win.nominum.com> <20130822222935.535B138CC1E9@drugs.dv.isc.org> <1377295232.4167.24.camel@localhost.localdomain> <20130824002253.7662338D39D5@drugs.dv.isc.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.8.5 Mime-Version: 1.0 Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 26 Aug 2013 20:53:48 -0000 Mark Andrews wrote: > That helps with legitimate email. It doesn't help with spoofed > email using domains with addresses that don't send email and have > a non rfc compliant nameserver or a misconfigured nameserver. Quite the opposite! For spoofed mail, bouncing them *is* the appropiate step. You don't want to accept such mail as if it had no spf. Plus, the spammers wouldn't be interested in spoofing such domains (after they notice that leads to them being dropped). It depends highly on volume, but it can be expected that such domain pool would only shrink, so a "nightly blacklist" should end up covering all of them. From angel@16bits.net Mon Aug 26 14:11:41 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 43D1D11E8249; Mon, 26 Aug 2013 14:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 1VER23mIuoYa; Mon, 26 Aug 2013 14:11:36 -0700 (PDT) Received: from mailer.hiddenmail.net (mailer.hiddenmail.net [199.195.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD1611E824A; Mon, 26 Aug 2013 14:11:36 -0700 (PDT) Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from ) id 1VE44K-0007v2-06; Mon, 26 Aug 2013 23:11:26 +0200 Message-ID: <1377551823.905.7.camel@localhost.localdomain> From: =?ISO-8859-1?Q?=C1ngel?= To: Hector Santos Date: Mon, 26 Aug 2013 23:17:03 +0200 In-Reply-To: <521B502D.5010106@isdg.net> References: <521A1F31.8080402@cisco.com> <521B502D.5010106@isdg.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.8.5 Mime-Version: 1.0 Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, 'IESG' , Eliot Lear , Apps Discuss Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 21:11:41 -0000 Hector Santos wrote: > I think the documentation usage of the term "SPF record" can be=20 > confusing if the type99 is going to be removed. It can suggest that=20 > this "SPF record" is unique and is not residing with other "records." >=20 > I think the term should be more specific to say the SPF TXT resultant=20 > record contains multiple EOL (CRLF or CR or LF terminators) strings=20 > and and only a string beginning with the *token* "v=3Dspf1" is a=20 > considered a SPF record string. In theory, the parser should=20 > tokenizing it to check for "v=3D" and then only process the v=3D value "s= pf1" >=20 > Perhaps a more specific term such as "SPF Line Record" or String would= =20 > be clearer. However, there could be one TXT record with embedded line breaks. I don't think a spf parser should try to extract that. From angel@16bits.net Mon Aug 26 14:25: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 5907511E8213 for ; Mon, 26 Aug 2013 14:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 h0ls59VKWASj for ; Mon, 26 Aug 2013 14:25:30 -0700 (PDT) Received: from mailer.hiddenmail.net (mailer.hiddenmail.net [199.195.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB5E11E80A2 for ; Mon, 26 Aug 2013 14:25:30 -0700 (PDT) Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from ) id 1VE4Hr-0007vW-Lj; Mon, 26 Aug 2013 23:25:28 +0200 Message-ID: <1377552669.905.12.camel@localhost.localdomain> From: =?ISO-8859-1?Q?=C1ngel?= To: Scott Kitterman Date: Mon, 26 Aug 2013 23:31:09 +0200 In-Reply-To: <1810938.1elvvlGtPX@scott-latitude-e6320> References: <3077934.Ro9QPd6kt1@scott-latitude-e6320> <20130826045748.71179.qmail@joyce.lan> <6.2.5.6.2.20130825224004.0ae44070@resistor.net> <1810938.1elvvlGtPX@scott-latitude-e6320> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.8.5 Mime-Version: 1.0 Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 26 Aug 2013 21:25:35 -0000 Scott Kitterman wrote: > Here's my suggestion: >=20 > ip4-cidr-length =3D "/" 1*DIGIT ; value range 1-32 > ip6-cidr-length =3D "/" 1*DIGIT ; value range 1-128 > dual-cidr-length =3D [ ip4-cidr-length ] [ "/" ip6-cidr-length ] > ; Avoid leading zeros in cidr-lengths since not all > ; implementations recognize them as valid. >=20 > Does that work? My intent there is to make libspf2 correct, but warn abo= ut=20 > more strict implementations. >=20 > Scott K I think the right way would be to use this grammar: ip4-cidr-length =3D "/" 1*2DIGIT / obs-cidr-length ; value range 0-32 ip6-cidr-length =3D "/" 1*3DIGIT / obs-cidr-length ; value range 0-128 obs-cidr-length =3D "/" 1*DIGIT and declare in the text that the cidr length MUST not be written with leading digits, obsoleting the 4408 syntax which allowed them. The use of obs- prefix for obsoleted tokens is common on other RFC (eg. rfc5322 section 3.1). From sm@elandsys.com Mon Aug 26 14:38:22 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 7AE8021F9E69 for ; Mon, 26 Aug 2013 14:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 EfIjT1bcGU58 for ; Mon, 26 Aug 2013 14:38: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 E60FB21F94FF for ; Mon, 26 Aug 2013 14:38:20 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.47]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7QLc6j3016924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Aug 2013 14:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377553098; bh=hqXziCk/k++boaYwVBGrXIuAS2gjIGUCfKCnTlIhHV8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=U/yKyDA1JYlNkDcc3sjmp5whjVqOIjm9LmRBSgSJ80LLgTjrb23YeBXaQmuYmBmef V+bjeVarPrkNi0tgW+PhpfN6jnP2btqtIsHA1MB2O2cBeoj+loG7RJPRV+9TFJH2gX 63AOMU4GJomRL7pt4DdTJL3dX8NHAxm/3r4GnGmA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377553098; i=@elandsys.com; bh=hqXziCk/k++boaYwVBGrXIuAS2gjIGUCfKCnTlIhHV8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=N6v7mEyqgtdMPvlqm+hUwEDtPbY+/U3t/zariViozTG/0+zXPCrmlDyugO6SjFirn RPR8hrRXC23pT95VintoM0rFaYkkBnfZoL6RLFxbN4ERhig+E69r9aqIpPEn9tAWr7 ABxj1qXVYKymHe9u/zZ880je8C/FeTKWZUi8GdRU= Message-Id: <6.2.5.6.2.20130826143227.0c8fe098@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 26 Aug 2013 14:37:09 -0700 To: =?iso-8859-1?Q?=C1ngel?= From: S Moonesamy In-Reply-To: <1377552669.905.12.camel@localhost.localdomain> References: <3077934.Ro9QPd6kt1@scott-latitude-e6320> <20130826045748.71179.qmail@joyce.lan> <6.2.5.6.2.20130825224004.0ae44070@resistor.net> <1810938.1elvvlGtPX@scott-latitude-e6320> <1377552669.905.12.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 26 Aug 2013 21:38:22 -0000 Hi Angel, At 14:31 26-08-2013, =C1ngel wrote: >I think the right way would be to use this grammar: > > ip4-cidr-length =3D "/" 1*2DIGIT / obs-cidr-length ; value range 0-32 > ip6-cidr-length =3D "/" 1*3DIGIT / obs-cidr-length ; value range 0-128 > obs-cidr-length =3D "/" 1*DIGIT > >and declare in the text that the cidr length MUST not be written with >leading digits, obsoleting the 4408 syntax which allowed them. > >The use of obs- prefix for obsoleted tokens is common on other RFC (eg. >rfc5322 section 3.1). Thanks for suggesting a fix for the ABNF. On what grounds would obsoleting the 4408 syntax be allowed? I am asking the question as an explanation is needed for such a change. Regards, S. Moonesamy (as document shepherd)=20 From spf2@kitterman.com Mon Aug 26 15:13: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 7639911E8224 for ; Mon, 26 Aug 2013 15:13:36 -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 gmyNDJnFptHw for ; Mon, 26 Aug 2013 15:13:31 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 65D8611E80E9 for ; Mon, 26 Aug 2013 15:13:26 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 26BF120E40F6; Mon, 26 Aug 2013 18:13:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377555204; bh=cxvF/77zm0ybcAv4Ei8Zd8wATtaJIWOhpNY4nV/MyhY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=dzMSXrQGm9JmKgs1OmfzR0SzB62OAiRDh3qZ3br4QCZZHrqJVZXPNJ8wFeBfAungl CxpJ0X3dn8dvaHXkEbFaFjfjC8Z65SUsQ+b23/JGRowIrzFGlqB2yxyi5y6groaKZk YuUP8nL4L2Hv/Q4byFIeCawTaIqwCAqbeu/yepyc= 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 0F6E920E4043; Mon, 26 Aug 2013 18:13:23 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 26 Aug 2013 18:13:23 -0400 Message-ID: <23351561.OZE5zlNVuU@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130826143227.0c8fe098@resistor.net> References: <3077934.Ro9QPd6kt1@scott-latitude-e6320> <1377552669.905.12.camel@localhost.localdomain> <6.2.5.6.2.20130826143227.0c8fe098@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 26 Aug 2013 22:13:36 -0000 On Monday, August 26, 2013 14:37:09 S Moonesamy wrote: > Hi Angel, >=20 > At 14:31 26-08-2013, =C1ngel wrote: > >I think the right way would be to use this grammar: > > ip4-cidr-length =3D "/" 1*2DIGIT / obs-cidr-length ; value rang= e 0-32 > > ip6-cidr-length =3D "/" 1*3DIGIT / obs-cidr-length ; value rang= e 0-128 > > obs-cidr-length =3D "/" 1*DIGIT > > > >and declare in the text that the cidr length MUST not be written wit= h > >leading digits, obsoleting the 4408 syntax which allowed them. > > > >The use of obs- prefix for obsoleted tokens is common on other RFC (= eg. > >rfc5322 section 3.1). >=20 > Thanks for suggesting a fix for the ABNF. >=20 > On what grounds would obsoleting the 4408 syntax be allowed? >=20 > I am asking the question as an explanation is needed for such a chang= e. Multiple implementations use the more strict construction, so it would,= I=20 think, make sense to specify it more tightly so that record publishers = don't=20 publish records that we know won't be fully interoperable. I don't thi= nk I=20 like this one any better than what we were already discussing. Scott K From johnl@iecc.com Mon Aug 26 16:12:27 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 D4EE511E80FD for ; Mon, 26 Aug 2013 16:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 4PWBH-zUEZTI for ; Mon, 26 Aug 2013 16:12:23 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 568FE11E80FE for ; Mon, 26 Aug 2013 16:12:22 -0700 (PDT) Received: (qmail 69123 invoked from network); 26 Aug 2013 23:12:22 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Aug 2013 23:12:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521be0d6.xn--yuvv84g.k1308; i=johnl@user.iecc.com; bh=2POdVdkuKaiGb+xI5R4bzj0FXJF7Mk0t+N7Fu0NP0a0=; b=nEI4gVDbWceEBhtWjJGgDxwga+yB6zkLc9UyMJc2YWVlJ/eJTYaGM+6+Iq7cm/E9Toa2g/OwjawvpnM+3dr1apV+IdFVMMk6xqqZCwZq+LUkiI1xXtDmBYU5TNZC4IvgEft5nY/6kXTZFENAs8kUtkWppMu4ivCb3yoP9E1qg/Fc2ku75Da1a64wa20PT9C9VPeMoUI3zu1ONO0LC3T7N/rQzxN2WrhRTPfJqmfrgKDoLVPhJ4erluvyGWH9FKx3 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521be0d6.xn--yuvv84g.k1308; olt=johnl@user.iecc.com; bh=2POdVdkuKaiGb+xI5R4bzj0FXJF7Mk0t+N7Fu0NP0a0=; b=EqOncLqpAI0Gw8ywEpRboB3uFs78VcOuQC7s3eHImPHGId5qzmTxWG70/vZvG1P0+NhqWU1g63ohmlG2BpKEShk1y+bDtiNQorQPcNDX9YuW6AugJEllLrk105bpt9Cx3BxzzDxuDl4x+XQRKND+SeCFYs6ABN6INy5mjXaDSWRud+LP0LNEl4QR5NGYH9Dsk8VXDfAGZlEq6T8bncbjEoJRcRJ1DhLs/b5JD2K98xYA03r77hkd8lleF0naEOQO Date: 26 Aug 2013 23:12:00 -0000 Message-ID: <20130826231200.82891.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <23351561.OZE5zlNVuU@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: spf2@kitterman.com Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 26 Aug 2013 23:12:27 -0000 >> At 14:31 26-08-2013, Ángel wrote: >> >I think the right way would be to use this grammar: >> > ip4-cidr-length = "/" 1*2DIGIT / obs-cidr-length ; value range 0-32 >> > ip6-cidr-length = "/" 1*3DIGIT / obs-cidr-length ; value range 0-128 >> > obs-cidr-length = "/" 1*DIGIT >> > >> >and declare in the text that the cidr length MUST not be written with >> >leading digits, obsoleting the 4408 syntax which allowed them. This seems unduly messy. Now that I've lookeed at Mail::SPF and pyspf, I see that leading zeros have never worked. The obs- stuff means that new code has to support leading zeros for backward compatibility, which just seems wrong. This describes what actually works now, and what I think people want the spec to be: ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 or equivalently: ip4-cidr-length = "/" ("0" | %x31-39 0*DIGIT) ; value range 0-32 ip6-cidr-length = "/" ("0" | %x31-39 0*DIGIT) ; value range 0-128 R's, John From sm@elandsys.com Mon Aug 26 16: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 9614D11E821C for ; Mon, 26 Aug 2013 16:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 Tr1y7cBOEDz3 for ; Mon, 26 Aug 2013 16:26:51 -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 C56E011E820D for ; Mon, 26 Aug 2013 16:26:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.139.183]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7QNQYem012528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Aug 2013 16:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377559607; bh=J7uj7N2d2pWEjRE/bxa2eizVscLtHjXqgbzJ001LEsA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=g1QSgN+tAeEvSwQedEJCzVaxkJfxRa9nl0VyK7lYff0YAjLm+6INifzOqrJ7D+RtS xBSFIhRytCkmhcIqAVtFmADln5XywkEvMDK+tjif05GSl4LxfmAWjwVkG8GEieJf/P Uzq9mVODwKIvhwiuqsGKr+vSsTYDRHCegYeZEHSQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377559607; i=@elandsys.com; bh=J7uj7N2d2pWEjRE/bxa2eizVscLtHjXqgbzJ001LEsA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QjthFCoTT50UWEeTkOTVfWMMhlpDBwPilPTfhNzIR/QB8Ap6aKc9OLWw9Av8ez6+s FqnfxKH/TGWArDPBMoq/42Cmf5B1i8nQVnJK4tLYFO821SHDN+GTlhLYkjFLjC9D57 0tNZleQfL/Yd/VipycLdR6LmV7FfB/NCiiq4+FFE= Message-Id: <6.2.5.6.2.20130826153723.0cc63d58@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 26 Aug 2013 15:57:29 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <23351561.OZE5zlNVuU@scott-latitude-e6320> References: <3077934.Ro9QPd6kt1@scott-latitude-e6320> <1377552669.905.12.camel@localhost.localdomain> <6.2.5.6.2.20130826143227.0c8fe098@resistor.net> <23351561.OZE5zlNVuU@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, John Levine Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 26 Aug 2013 23:26:52 -0000 Hi Scott, At 15:13 26-08-2013, Scott Kitterman wrote: >Multiple implementations use the more strict construction, so it would, I >think, make sense to specify it more tightly so that record publishers don't >publish records that we know won't be fully interoperable. I don't think I >like this one any better than what we were already discussing. The ABNF would have to be changed in Section 5.6 and Appendix A. Are you okay with: ip4-cidr-length = "/" 1*DIGIT ; value range 0-32 ip6-cidr-length = "/" 1*DIGIT ; value range 0-128 It is specified more tightly without affecting the two implementations which John Levine verified. Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Mon Aug 26 16:41: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 F162D11E8261 for ; Mon, 26 Aug 2013 16:41: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=[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 q-4VP89T1jbW for ; Mon, 26 Aug 2013 16:41:27 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5749411E822B for ; Mon, 26 Aug 2013 16:41:27 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id D2629D0407F; Mon, 26 Aug 2013 19:41:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377560485; bh=EzZcihrSxLOtOt4aecAU2ST0lPVUfVyiouVX/kCReac=; h=In-Reply-To:References:Subject:From:Date:To:From; b=hXjXMtc5vrIB8pES/b5D+X9Eq7sucrMskVNcLkqeSPvYF8/KPafsWWbRusBtCCQlx d2ukeKHVwQmxofkS8fDVM1kU38ZAVw5w5xoCP9PxWfR03ruSbW+sLD+mSa+sW/86ZI 8p6uB++park6Fm4crRGVGp+pfKrB/XLDTehlLJCc= Received: from [192.168.111.106] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 72194D0401E; Mon, 26 Aug 2013 19:41:25 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130826153723.0cc63d58@resistor.net> References: <3077934.Ro9QPd6kt1@scott-latitude-e6320> <1377552669.905.12.camel@localhost.localdomain> <6.2.5.6.2.20130826143227.0c8fe098@resistor.net> <23351561.OZE5zlNVuU@scott-latitude-e6320> <6.2.5.6.2.20130826153723.0cc63d58@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Mon, 26 Aug 2013 19:41:33 -0400 To: spfbis@ietf.org Message-ID: <3871ad2c-7dd7-4bdf-ae17-38656fd4aa48@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 26 Aug 2013 23:41:28 -0000 S Moonesamy wrote: >Hi Scott, >At 15:13 26-08-2013, Scott Kitterman wrote: >>Multiple implementations use the more strict construction, so it >would, I >>think, make sense to specify it more tightly so that record publishers >don't >>publish records that we know won't be fully interoperable. I don't >think I >>like this one any better than what we were already discussing. > >The ABNF would have to be changed in Section 5.6 and Appendix A. > >Are you okay with: > > ip4-cidr-length = "/" 1*DIGIT ; value range 0-32 > ip6-cidr-length = "/" 1*DIGIT ; value range 0-128 > >It is specified more tightly without affecting the two >implementations which John Levine verified. I'm ok with either this or the one that John just suggested. I'm not an ABNF expert though. Since we have several in the group, I'd rather they arm wrestle to decide the right answer. Scott K From johnl@iecc.com Mon Aug 26 16:55:21 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 638FF11E80EA for ; Mon, 26 Aug 2013 16:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 2tqi0cb5q4zc for ; Mon, 26 Aug 2013 16:55:20 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6A22621F991F for ; Mon, 26 Aug 2013 16:55:19 -0700 (PDT) Received: (qmail 87058 invoked from network); 26 Aug 2013 23:55:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=15410.521beae7.k1308; bh=A10g+ZHEZ1TFPQm/X14uG7iVNckkrpjsorZgxBkHqoc=; b=Xcgh63aNG47cWXgYlKyhjWymCJwQlz3i9nkCKUnN85k/cNCEn4rnYf8FzlSTp/S/dgTFR9qRAClHPqWcbCptkej+eUNswy+oaYOKcg0pgWY4XaSy6UqeUdKD3zQBxaoOweZ3U68Q7jqs5Jkdc8kdPH4JdxIKnIR6T4NF8x2EFVD6h4oF5xZ4qK8OUDDC8c2jqy3z1nZfzISh8SeXrDcYTG2NxftlyPd/qljP5VjfP32Z5HhowT2fE54tL2sl4hCD Received: (ofmipd 127.0.0.1); 26 Aug 2013 23:54:56 -0000 Date: 26 Aug 2013 19:55:18 -0400 Message-ID: From: "John R. Levine" To: "S Moonesamy" In-Reply-To: <6.2.5.6.2.20130826153723.0cc63d58@resistor.net> References: <3077934.Ro9QPd6kt1@scott-latitude-e6320> <1377552669.905.12.camel@localhost.localdomain> <6.2.5.6.2.20130826143227.0c8fe098@resistor.net> <23351561.OZE5zlNVuU@scott-latitude-e6320> <6.2.5.6.2.20130826153723.0cc63d58@resistor.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 26 Aug 2013 18:15:23 -0700 Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 26 Aug 2013 23:55:21 -0000 > Are you okay with: > > ip4-cidr-length = "/" 1*DIGIT ; value range 0-32 > ip6-cidr-length = "/" 1*DIGIT ; value range 0-128 No, this is the current ABNF which turns out to be wrong. It would permit 1.2.3.0/00024 which pyspf and Mail::SPF don't accept. I've sent in the correct ABNF three times now. If someone has specific objections to it, I'd appreciate knowing specifically what they are. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@taugh.com Mon Aug 26 18:19:04 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 2975221F9A6A for ; Mon, 26 Aug 2013 18:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, 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 WwqDHc7fET+X for ; Mon, 26 Aug 2013 18:19:03 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EB3C921F9A64 for ; Mon, 26 Aug 2013 18:19:02 -0700 (PDT) Received: (qmail 30885 invoked from network); 27 Aug 2013 01:19:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent:cleverness; s=78a3.521bfe86.k1308; bh=M2z7vVwbL8jb7LRvZq4oVytJw/vaE8GB1yJKmsJ80m8=; b=s70qc8PLuNYE03Ijz0bvHGwjPFA9YRcUUPBhHsDX4tFd5QygPQRVg+KC5LHwkuBBuIWjIvS+JHZVkKAnvoH/SWnAkvgGCmpDQaJrJclLv8vJw7V1EJ9u2+BKFtq3HfNZ8y7JCWFKzmzxfRmXYu/64Xrt04siB7005rZuzAKY0l6HviZyrKr5VWWW6Gm6A2oCXAzf6JY9JTHtnun04mwTjp8T5HU62t3JvFW0XWjuKci58K+uPmNme1gYKfvtoOp3 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent:cleverness; s=78a3.521bfe86.k1308; bh=M2z7vVwbL8jb7LRvZq4oVytJw/vaE8GB1yJKmsJ80m8=; b=BhmUV+52aODkqXQo5kKvZ2CFRAMavtvYy9o8PkOrZ15+jkvLdUI57HRxBaSuoKlArQ9dUADJVwHDGKGcptziQVL4cVJtNagYjXS2EQnFIJNrpJy9T1YSx1hcHnmMX1cCZtESzf7zzJA549l3abCT28ZecWhJ0ee/P1Eo/KusWEjkBFjVb9QRsEqN08t57AS4uFOW/vYottClrGFiKGoHN9BouRDejapFMJELGeETGUBqgjFXs38+vvMjXZsd+Iak Received: (ofmipd 127.0.0.1); 27 Aug 2013 01:18:39 -0000 Date: 26 Aug 2013 21:19:01 -0400 Message-ID: From: "John R Levine" To: spfbis@ietf.org User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 01:19:04 -0000 > Are you okay with: > > ip4-cidr-length = "/" 1*DIGIT ; value range 0-32 > ip6-cidr-length = "/" 1*DIGIT ; value range 0-128 No, this is the current ABNF which turns out to be wrong. It permits 1.2.3.0/00024 which pyspf and Mail::SPF don't accept. I've sent in ABNF three times now that matches the code and what I think people want. If someone has specific objections to it, I'd appreciate knowing what they are. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From dhc@dcrocker.net Mon Aug 26 18:20:06 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 CBF1F21F9B11 for ; Mon, 26 Aug 2013 18:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsvyK7NnyVnl for ; Mon, 26 Aug 2013 18:20:01 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E3AC121F9A6A for ; Mon, 26 Aug 2013 18:20:01 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7R1Jvfj026143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Aug 2013 18:20:00 -0700 Message-ID: <521BFEBC.7090204@dcrocker.net> Date: Mon, 26 Aug 2013 18:19:56 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Levine References: <20130826231200.82891.qmail@joyce.lan> In-Reply-To: <20130826231200.82891.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 26 Aug 2013 18:20:01 -0700 (PDT) Cc: spfbis@ietf.org, spf2@kitterman.com Subject: Re: [spfbis] Applications Directorate Review: ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 01:20:06 -0000 On 8/26/2013 4:12 PM, John Levine wrote: > ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 > ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 I prefer this form. I think it provides the most parsing precision and the most reader information. I think all the alternatives (that aren't just plain wrong) offer less. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Mon Aug 26 18:21:20 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 C235D21F9B11 for ; Mon, 26 Aug 2013 18:21:20 -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 EgJ3xdmACWNR for ; Mon, 26 Aug 2013 18:21:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AFE6321F9A6A for ; Mon, 26 Aug 2013 18:21:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EDF1C20E40F6; Mon, 26 Aug 2013 21:21:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377566475; bh=voqR7c64KD5C6PyyxYx1Jw1NL8+zQ9rAdZ9hTuWs/Go=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qeFf1IDFthaBIr0d/OHOMdK7obrPm8cW/C1e5GIZytp5b1iO7Vp3SRU837Hj1hZXs GExJEuUsBKUNuFOhPKiOErUfR3oTlV/hfnU+PPnmcmn7B3LOS0ItgSLLO1Pl6j7WpW Ke4RiDZYGUCZxgoH8V6dJ3943T0U1bjmFx19uPe8= 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 D403D20E4043; Mon, 26 Aug 2013 21:21:14 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 26 Aug 2013 21:21:12 -0400 Message-ID: <1597036.9RGUBu0FQb@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <521BFEBC.7090204@dcrocker.net> References: <20130826231200.82891.qmail@joyce.lan> <521BFEBC.7090204@dcrocker.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] Applications Directorate Review: ABNF 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, 27 Aug 2013 01:21:20 -0000 On Monday, August 26, 2013 18:19:56 Dave Crocker wrote: > On 8/26/2013 4:12 PM, John Levine wrote: > > ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 > > ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 > > I prefer this form. I think it provides the most parsing precision and > the most reader information. I think all the alternatives (that aren't > just plain wrong) offer less. I sense a tide starting to flow. Unless people start objecting, I'll go with this. Scott K From sm@elandsys.com Mon Aug 26 18:22: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 ABC1C11E8120 for ; Mon, 26 Aug 2013 18:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 aBv6tJUh7fzf for ; Mon, 26 Aug 2013 18:22:10 -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 F0A9511E811E for ; Mon, 26 Aug 2013 18:22:09 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.139.183]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7R1Lmaj029984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Aug 2013 18:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377566520; bh=ADyJk1rIyJHeshW/3hVTxLFdGplOwoGpg5X7OvZvpkQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FeKSi4I9dRQwRQpwJ18FFIF/n7a5u+A3/nIXQk4CDVA+DZ40haSuAeQ5kDbItG/II SMSzo6zrG4MneEQYg3HrBFjlTPFjUtCQ56pxsWz0hxItvy+EuFtGebVfJt0SojCbs9 GjsXwFFDKYRl0r4xryJCcqz7tnEPQJBYX8YpSV9A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377566520; i=@elandsys.com; bh=ADyJk1rIyJHeshW/3hVTxLFdGplOwoGpg5X7OvZvpkQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=e/cqYoVa7vgCIppM0r60ySd6Z3PIHuWu3uIRRmeuj81C3q49dGlrE1diYscDgD6y6 cHWFLQ6TQ2RAVcLNvVm/kwVDkUS2OS9YjtYNHFOXSMhoSD1w406PPKah45EMtNYigJ PRf08XjgsEBsnaSv7vAu9xx5HoyHHKZpOE5rn7YY= Message-Id: <6.2.5.6.2.20130826181546.0b890950@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 26 Aug 2013 18:21:26 -0700 To: "John R. Levine" From: S Moonesamy In-Reply-To: References: <3077934.Ro9QPd6kt1@scott-latitude-e6320> <1377552669.905.12.camel@localhost.localdomain> <6.2.5.6.2.20130826143227.0c8fe098@resistor.net> <23351561.OZE5zlNVuU@scott-latitude-e6320> <6.2.5.6.2.20130826153723.0cc63d58@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 01:22:11 -0000 Hi John, At 16:55 26-08-2013, John R. Levine wrote: >I've sent in the correct ABNF three times now. If someone has >specific objections to it, I'd appreciate knowing specifically what they are. Sorry about that. I see two alternatives in the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg04039.html Which one should I use in my response to Eliot's review? Thanks, S. Moonesamy (as document shepherd) From johnl@iecc.com Mon Aug 26 18:26: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 F260E11E811D for ; Mon, 26 Aug 2013 18:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 wMXeQaJJh65d for ; Mon, 26 Aug 2013 18:26:24 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id BB5DD11E80EC for ; Mon, 26 Aug 2013 18:26:23 -0700 (PDT) Received: (qmail 35014 invoked from network); 27 Aug 2013 01:26:22 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 Aug 2013 01:26:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521c003e.xn--hew.k1308; i=johnl@user.iecc.com; bh=dmdQFK0mfRCrMpY4/mXxpq2VE3T1PqFuUnPbL/W/JKw=; b=k+lPegqdsxEzsOqJqYN9X/Vi8NCAQN6At1kHvaT4Xc105g/1wtd9hQlAwWbEFtXkazZ5gEd/gSfNfwQ9Y6RzoZ6EQqqcQHSRkz8V/NxhwPMq7z9XekJ6XKXSQkEGWC4Vhg5dHAH7PWPYUw5oAVBserYVDI8hau3B/0LuyJB/28gY0TDyhJh6OqRP/BVIX60tAA/n0LhrOlYRjH7HZM9GZTfdSocyDeCZOvR39NjkUbnoAV96bvVWzjjfkuUcWump DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521c003e.xn--hew.k1308; olt=johnl@user.iecc.com; bh=dmdQFK0mfRCrMpY4/mXxpq2VE3T1PqFuUnPbL/W/JKw=; b=ZmQExay0ZPln2el5j8p4S1NMHl856gZstWBVsldSDSGFvULTQqwUCVCXLCRWWk7obafEvN2HsVFu5v+hT4vs0KAIzH6jGzN+ihpy4D1zmOlQaVMKpaiLqrlBi5D5RYmoLoiJN8gwG5MzMlpFseSSd7zCMkdWazsAmOQjQBkuQmYJ+Hgd9JzVupNS8oBRHQFdqexXOjrwqAD4nSE9OghSCfZEIBq5+9XKq8TFr+Ttx8+U5SSrwqGInwl/ZX8Zw9ZH Date: 27 Aug 2013 01:26:00 -0000 Message-ID: <20130827012600.83309.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20130826181546.0b890950@elandnews.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: sm+ietf@elandsys.com Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 01:26:28 -0000 >I see two alternatives in the message at >http://www.ietf.org/mail-archive/web/spfbis/current/msg04039.html >Which one should I use in my response to Eliot's review? ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 R's, John From tony@att.com Mon Aug 26 19:30:53 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 1F80911E811F for ; Mon, 26 Aug 2013 19:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.168 X-Spam-Level: X-Spam-Status: No, score=-106.168 tagged_above=-999 required=5 tests=[AWL=0.431, 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 Vrq0vNAZ3Zmo for ; Mon, 26 Aug 2013 19:30:47 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECF011E8121 for ; Mon, 26 Aug 2013 19:30:46 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 55f0c125.0.3150555.00-343.8670706.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 27 Aug 2013 02:30:47 +0000 (UTC) X-MXL-Hash: 521c0f573b524176-918e7933f0a69f80695c927df237d4b7173c3fb8 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7R2UjZ3002672 for ; Mon, 26 Aug 2013 22:30:45 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7R2UZM6002533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Aug 2013 22:30:44 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Tue, 27 Aug 2013 02:30:17 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7R2UHdX029251 for ; Mon, 26 Aug 2013 22:30:17 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7R2UCTe029062 for ; Mon, 26 Aug 2013 22:30:14 -0400 Received: from [135.70.82.71] (vpn-135-70-82-71.vpn.swst.att.com[135.70.82.71]) by maillennium.att.com (mailgw1) with ESMTP id <20130827023010gw1004nh8de> (Authid: tony); Tue, 27 Aug 2013 02:30:12 +0000 X-Originating-IP: [135.70.82.71] Message-ID: <521C0F32.1050107@att.com> Date: Mon, 26 Aug 2013 22:30:10 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130827012600.83309.qmail@joyce.lan> In-Reply-To: <20130827012600.83309.qmail@joyce.lan> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=Ru1y2laK c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=KSYLlGse_LsA:10 a=sCfsyOEanakA:10 a=dBqptANV09QA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=t_sxTune5RMA:10 a=48vgC7mUAAAA:8 a=CliDHCtK6eWnt] X-AnalysisOut: [RtLWtEA:9 a=wPNLvfGTeEIA:10 a=GwwvCvx9KPAA:10 a=IU7r5du6o5] X-AnalysisOut: [IA:10 a=MVNgbWY1MGsA:10 a=ctUETmWqs2QMq7PU:21 a=Ia50ScwatB] X-AnalysisOut: [uXaRiY:21] Cc: sm+ietf@elandsys.com Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 02:30:53 -0000 On 8/26/2013 9:26 PM, John Levine wrote: >> I see two alternatives in the message at >> http://www.ietf.org/mail-archive/web/spfbis/current/msg04039.html >> Which one should I use in my response to Eliot's review? > ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 > ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 > +1 Tony Hansen From sm@elandsys.com Mon Aug 26 19:41: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 4639111E8123 for ; Mon, 26 Aug 2013 19:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 NNYx942kWdR8 for ; Mon, 26 Aug 2013 19:41: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 0767E11E8121 for ; Mon, 26 Aug 2013 19:41:13 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.139.183]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7R2eumS020826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Aug 2013 19:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377571267; bh=SG2c7a7tMQ+NT+wt91ETdmwZ1GNlInS0PKqvfKufB5w=; h=Date:To:From:Subject:In-Reply-To:References; b=kd3NQcQ514hFq3kykz9ylE//+2Nq0lyJ5ftO1Fk8rxwSbkcyN11STRlEfxNR8Du7q G0A44TWkG5Jh8AV1yuIDmeY47UHW98/HE0Bde3jvvquNJNq5iu7WwY6Be68zyhyTu/ 0BePhYrptQCCRFgtRe9h+suR8igMU3VAnH5ctgxo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377571267; i=@elandsys.com; bh=SG2c7a7tMQ+NT+wt91ETdmwZ1GNlInS0PKqvfKufB5w=; h=Date:To:From:Subject:In-Reply-To:References; b=STyRMhQIJOBdkk8RL7ZfMklK5j+nmOVem2zVCDLrgDhW3Mz64BfN1pYqgfE/XaMJ1 2tcfzdzhXjaqP4jekLrQ4n1f5ETUiw9T4OTm1USvDey6ZBMXSFA38shcQRytbLXaoy V2r6LFCbA7Na2UpIbK6fGZeeLbivJ63Y1I2ok0IE= Message-Id: <6.2.5.6.2.20130826193846.0cd49ec0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 26 Aug 2013 19:40:29 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <9884B9CD-0ED3-4D89-A100-58D05EA4BC98@gmail.com> References: <9884B9CD-0ED3-4D89-A100-58D05EA4BC98@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 27 Aug 2013 02:41:15 -0000 Hello, At 13:07 23-08-2013, Douglas Otis wrote: >4.6.4. DNS Lookup Limits > >Was: >,-- >SPF implementations MUST limit the total number of mechanisms and >modifiers ("terms") that cause any DNS query to 10 during SPF >evaluation. >'-- > >Change to: >,--- >SPF evaluation must limit the number of mechanisms, and the modifier >term 'redirect' to occur in no more than10 instances within the >evaluation process. The mechanisms 'ip4', ip6', and 'all' are >excluded from this instance limitation. Each mechanism is permitted >to resolve subsequent resource record sets (RRsets) that MUST not >contain more than 10 resource records to complete a match check. >When the number of instances exceeds 10, or when subsequent >resolutions exceeds 10, check_host() MUST produce a "permerror" >result. > >The maximum number of DNS transactions initiated by an SPF >evaluation is therefore 1 for the initial SPF resource record, 10 for >each mechanism times 10 transactions needed to complete a matching >process for a total of 111 DNS transactions. This number excludes >those required by DNS to fulfill a request and those required by an >EXP modifier. Can the working group address the above comments? Thanks, S. Moonesamy (as document shepherd) From spf2@kitterman.com Mon Aug 26 20:04:45 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 9C5FA11E8136 for ; Mon, 26 Aug 2013 20:04:45 -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 OjcVhTWVTEol for ; Mon, 26 Aug 2013 20:04:35 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 54DB111E8129 for ; Mon, 26 Aug 2013 20:04:35 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 951F220E40F6; Mon, 26 Aug 2013 23:04:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377572674; bh=S4fVad5V08qlAvTauE0QWvNbfN9cYt73k2OZuOBIB7k=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Q1sWbloM0NJoHqQgn8lYFQUWzakTadVneNo7CAkXrPzFy1sNsNLf7RsAib3HQayYg G4h6WFVWKKEGKyp5oe1hhiKLLX0q+HtBdXDstIUcIsogtBKD9oBK7WAEnevWS8LMsL 8qGROWOTtnNXMBo3t6OHdHplIk2iTymCf5qsWSs4= 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 75FD120E4043; Mon, 26 Aug 2013 23:04:34 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 26 Aug 2013 23:04:33 -0400 Message-ID: <2102711.sFStFl6lDQ@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130826193846.0cd49ec0@elandnews.com> References: <9884B9CD-0ED3-4D89-A100-58D05EA4BC98@gmail.com> <6.2.5.6.2.20130826193846.0cd49ec0@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] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 27 Aug 2013 03:04:45 -0000 On Monday, August 26, 2013 19:40:29 S Moonesamy wrote: > Hello, > > At 13:07 23-08-2013, Douglas Otis wrote: > >4.6.4. DNS Lookup Limits > > > >Was: > >,-- > >SPF implementations MUST limit the total number of mechanisms and > >modifiers ("terms") that cause any DNS query to 10 during SPF > >evaluation. > >'-- > > > >Change to: > >,--- > >SPF evaluation must limit the number of mechanisms, and the modifier > >term 'redirect' to occur in no more than10 instances within the > >evaluation process. The mechanisms 'ip4', ip6', and 'all' are > >excluded from this instance limitation. Each mechanism is permitted > >to resolve subsequent resource record sets (RRsets) that MUST not > >contain more than 10 resource records to complete a match check. > >When the number of instances exceeds 10, or when subsequent > >resolutions exceeds 10, check_host() MUST produce a "permerror" > >result. > > > >The maximum number of DNS transactions initiated by an SPF > >evaluation is therefore 1 for the initial SPF resource record, 10 for > >each mechanism times 10 transactions needed to complete a matching > >process for a total of 111 DNS transactions. This number excludes > >those required by DNS to fulfill a request and those required by an > >EXP modifier. > > Can the working group address the above comments? We worked through the language of that section closely in the WG to try and make it more comprehensible while retaining correctness. I don't find the proposed text an improvement over the working group's effort. Scott K From dhc@dcrocker.net Mon Aug 26 20:21: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 5984711E8141 for ; Mon, 26 Aug 2013 20:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwgm0K4tso+e for ; Mon, 26 Aug 2013 20:21:05 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D253211E8263 for ; Mon, 26 Aug 2013 20:21:04 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7R3L1UR027734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Aug 2013 20:21:04 -0700 Message-ID: <521C1B1C.5000300@dcrocker.net> Date: Mon, 26 Aug 2013 20:21:00 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Scott Kitterman References: <9884B9CD-0ED3-4D89-A100-58D05EA4BC98@gmail.com> <6.2.5.6.2.20130826193846.0cd49ec0@elandnews.com> <2102711.sFStFl6lDQ@scott-latitude-e6320> In-Reply-To: <2102711.sFStFl6lDQ@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 26 Aug 2013 20:21:04 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 03:21:12 -0000 X-List-Received-Date: Tue, 27 Aug 2013 03:21:12 -0000 On 8/26/2013 8:04 PM, Scott Kitterman wrote: > I don't find the > proposed text an improvement over the working group's effort. I'll in fact suggest that any proposed text change needs to be based on specific assertions of needs and benefits that have gotten rough consensus, prior to worrying about the wording. Get agreement on the nature of the problem with the current text, before haggling over how it's fixed. I haven't seen any of the foundational work that might justify making a change. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Mon Aug 26 21:14: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 1A98121F8A38 for ; Mon, 26 Aug 2013 21:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 6rl70oV7F5cP for ; Mon, 26 Aug 2013 21:14:04 -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 11E7721F8994 for ; Mon, 26 Aug 2013 21:14:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.139.183]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7R4Ddej001060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Aug 2013 21:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377576837; bh=NWuFJY5+2MtuT8pr9ErYIRLMi/m4TNFKbSMTsAf/5K0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=a03idYwvUelxCbqcZoozWnnhAdAEnwEtXTwWFNvJ9fi32NX9VzhyI+JRyk+gzwgzV HxKIY8pfQjR6lNra1ebEMxsfxcUxUeEQaC21K+MsudoLG+O5Bo1bcsOAmPuKDdQy4O 9NLYVuB5UjZAL+jLSgyfeTcvpuDazTpijQtEzODA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377576837; i=@elandsys.com; bh=NWuFJY5+2MtuT8pr9ErYIRLMi/m4TNFKbSMTsAf/5K0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dfs9JX3ABgXTr88uTuvjbygdKIyaUAWxiOwozDa09N8KLkQyY4FaFs2tfVwmTL0Ah HfIUpwl7hOQXSaqJBV3rCS8OihAU/SlYBvqicyLvfX4P/UUOApi3qHdyg3DmWLagqZ ay3SHI85YZSjKgGWO4ecKfxBPYyKCwASyWCAmbpg= Message-Id: <6.2.5.6.2.20130826210232.0ba9d5d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 26 Aug 2013 21:13:23 -0700 To: dcrocker@bbiw.net, Scott Kitterman From: S Moonesamy In-Reply-To: <521C1B1C.5000300@dcrocker.net> References: <9884B9CD-0ED3-4D89-A100-58D05EA4BC98@gmail.com> <6.2.5.6.2.20130826193846.0cd49ec0@elandnews.com> <2102711.sFStFl6lDQ@scott-latitude-e6320> <521C1B1C.5000300@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 27 Aug 2013 04:14:05 -0000 Hi Dave, Scott, The comments are at http://www.ietf.org/mail-archive/web/ietf/current/msg81811.html The comment which I should have included is: "Section 4.6.4 fails to offer a sufficiently clear warning about potential magnitudes of DNS transactions initiated by a single SPF evaluation where two are recommended to occur one for the separate identifiers. In fact, this section appears to make assurances no more that 10 DNS queries will result and is widely misunderstood." There wasn't any response to this on the Last Call thread. Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Mon Aug 26 21:18:06 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 10D4911E8142 for ; Mon, 26 Aug 2013 21:18:06 -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 UWi7vn5FBAQH for ; Mon, 26 Aug 2013 21:18:01 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9895E11E8138 for ; Mon, 26 Aug 2013 21:18:01 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D974420E40F6; Tue, 27 Aug 2013 00:17:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377577079; bh=iSGtsnBRmcjB4Yzil+IxMX2iwkbnbEW06MKyOF75sb0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=f4+ZZdaLe7JAUeqvftuyVWdV73LZm8Iq0XipsCvVORrE+u+doH5gqnecoLcdbsRdZ VQGpqLE4nZ4JjDP1pC57DMDgCqHhROKkh4wS2kGThzd17IrzbPbjM5+Q3Xw/FXLtFd TTXPwoiiqb3avIAIWjpP7bRkJ4rWQ6E0ifnLV53E= 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 C146220E4043; Tue, 27 Aug 2013 00:17:59 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 27 Aug 2013 00:17:59 -0400 Message-ID: <2228656.1ZsXPuf7bA@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130826210232.0ba9d5d0@resistor.net> References: <9884B9CD-0ED3-4D89-A100-58D05EA4BC98@gmail.com> <521C1B1C.5000300@dcrocker.net> <6.2.5.6.2.20130826210232.0ba9d5d0@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] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 27 Aug 2013 04:18:06 -0000 On Monday, August 26, 2013 21:13:23 S Moonesamy wrote: > Hi Dave, Scott, > > The comments are at > http://www.ietf.org/mail-archive/web/ietf/current/msg81811.html > > The comment which I should have included is: > > "Section 4.6.4 fails to offer a sufficiently clear warning about > potential magnitudes of DNS transactions initiated by a single SPF > evaluation where two are recommended to occur one for the separate > identifiers. In fact, this section appears to make assurances no more that > 10 DNS queries will result and is widely misunderstood." > > There wasn't any response to this on the Last Call thread. It's wrong (the comment). Now you have a response. Scott K P.S. If you gather I'm getting tired of dealing with the same comments over and over again, I am. From dhc@dcrocker.net Mon Aug 26 22:02:30 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 B601511E8153 for ; Mon, 26 Aug 2013 22:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8thjAX8B6Aa for ; Mon, 26 Aug 2013 22:02:25 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A9D0511E814D for ; Mon, 26 Aug 2013 22:02:25 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7R525ZY029488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Aug 2013 22:02:09 -0700 Message-ID: <521C32CC.3090701@dcrocker.net> Date: Mon, 26 Aug 2013 22:02:04 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: S Moonesamy References: <9884B9CD-0ED3-4D89-A100-58D05EA4BC98@gmail.com> <6.2.5.6.2.20130826193846.0cd49ec0@elandnews.com> <2102711.sFStFl6lDQ@scott-latitude-e6320> <521C1B1C.5000300@dcrocker.net> <6.2.5.6.2.20130826210232.0ba9d5d0@resistor.net> In-Reply-To: <6.2.5.6.2.20130826210232.0ba9d5d0@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 26 Aug 2013 22:02:09 -0700 (PDT) Cc: spfbis@ietf.org, dcrocker@bbiw.net, Scott Kitterman Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 05:02:30 -0000 On 8/26/2013 9:13 PM, S Moonesamy wrote: > There wasn't any response to this on the Last Call thread. Exactly my point... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Tue Aug 27 09:23: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 740BF11E835F for ; Tue, 27 Aug 2013 09:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 ZRAH9FsJs7Df for ; Tue, 27 Aug 2013 09:23:13 -0700 (PDT) Received: from winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3E211E81CF for ; Tue, 27 Aug 2013 09:23:12 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2521; t=1377620577; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=JViQCA1lwXiN4DwLXbjRNwdhie4=; b=PaxqOEf0+qX+N4Qyr0wY PasTAiW5gfv4gIPwOQKJjAvI6lPxxVeRjmQ83MjeQjGReuwrEgHr4n5cXTw1gxw9 UasrgwXQvqRa1UNkBqpyuZEJAqCH/RHyOe5O87RLNleQvJA7bpk81kjXOTYcCDk8 NM7feJFDRn5cKTrf9bfboDI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 27 Aug 2013 12:22:57 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4083087115.8864.912; Tue, 27 Aug 2013 12:22:56 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2521; t=1377620257; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=rLjzewh P9UnCB0AwDeC5ReVDc5MUewKJ/1plQN92GvQ=; b=0bCb9JMb7h6lmxr1NNYtIVW gMkYry+aDcx8u6U/YkBvJyEJsSNCsUZxN633tJkQ9/Isx0O27krCKeyHnO0e2Q2K ePN85y0r8gFEPFmyMQmsm0feBt0XHlqGp9Y/lxeJAJPJaYP2QtkVDnt+mJVldqqt qX1CiXnXG9+cZz95p694= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 27 Aug 2013 12:17:37 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3529504783.9.6900; Tue, 27 Aug 2013 12:17:36 -0400 Message-ID: <521CD259.7010800@isdg.net> Date: Tue, 27 Aug 2013 12:22:49 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: spfbis@ietf.org, S Moonesamy , Scott Kitterman References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> In-Reply-To: <521C0F32.1050107@att.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 16:23:18 -0000 On 8/26/2013 10:30 PM, Tony Hansen wrote: > On 8/26/2013 9:26 PM, John Levine wrote: >>> I see two alternatives in the message at >>> http://www.ietf.org/mail-archive/web/spfbis/current/msg04039.html >>> Which one should I use in my response to Eliot's review? >> >> ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 >> ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 >> > > +1 > To simplify the above and to further codify existing parsers in the wild, may I suggest the ABNF be: ip4-cidr-length = "/" [ ip4-cidr-value ] ip6-cidr-length = "/" [ ip6-cidr-value ] ip4-cidr-value = 2*DIGIT ; value range 0-32 ip6-cidr-value = 3*2DIGIT ; value range 0-128 This allows for the possible omission of the alphanumeric after the slash. Both RFC4408 & 4408BIS says: If ip4-cidr-length is omitted, it is taken to be "/32". If ip6-cidr-length is omitted, it is taken to be "/128". It is not permitted to omit parts of the IP address instead of using CIDR notations. That is, use 192.0.2.0/24 instead of 192.0.2. What it doesn't say is when the cidr-length is just "/". My suggestion will also codify existing spf processing code where it handles SPF mechanism examples such as: v=spf1 ip4:192.0.2.2/ -all The following simple C code will treat this condition with a cidr=0: int cidr = 32; // default per rfc4408 for ip4 char *slash = strchr(mechanism,'/'); if (slash) cidr = atoi(slash+1); and continues with the ip/cidr masking calculation against the connecting ip address. Another could see this as an error: if (slash && !strlen(slash+1)) return SPF_IP4_PERMERROR; or it could probably try to fit the Levine's proposed ABNF a little better which checks for a non-blank string: if (slash && strlen(slash+1)) cidr = atoi(slash+1); which would use a cidr=32 as a default perhaps. So we have three possible parsing possibilities: cidr = 0 cidr = 32 or 128 return a permanent error The ABNF should allow for the partial omission of the cidr-length or it should be specific to say what should be the default consideration. Levine's proposed ABNF, while technically valid, could enforce an error condition for a parser where it is not today. Overall, these are well tested case scenarios for long time SPF parsers. As long as there is no security loophole (and I don't see it), I think my proposed change better fits the market place of implementations across the board. Thanks -- HLS From hsantos@isdg.net Tue Aug 27 10:05:29 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 31A141F0ED2 for ; Tue, 27 Aug 2013 10:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 22zeEcz3GKHu for ; Tue, 27 Aug 2013 10:05:23 -0700 (PDT) Received: from winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 192641F0D1A for ; Tue, 27 Aug 2013 10:05:23 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2774; t=1377623113; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=CbLF31OaEpDA9/XU8tcsTFueN3k=; b=dkJkWlTbvMPq2BdmmXft yVL1Cvc9o5GzbbvVpyNQe6QbgHjmmtfG8L22+96xx3bs6lJpkGXDAswmqt8SwAvh Y1tUfXkxBR7uDw8QlND6o+vXKYc+QIKYxo8qwQMV5EntSaF7FDuQjQUWgcm0lVtf X6QsQvB8f78Ghti8A2M9FCE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 27 Aug 2013 13:05:13 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4085622428.8864.5708; Tue, 27 Aug 2013 13:05:11 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2774; t=1377622792; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=1c7gm8M 7HPP39I9Yqy2JWPFyR77v6Ee7JNJtlr6A9QE=; b=Zsdo6brDcc1ck6ZAeUDQS2E MjGnTwqs7cu+gDYHctOAuekXjtLKcl8nCPNM11DRCXhfD0nrio01zZK2nPp5jqcg +WerXHnuk9T5G768U0DuCjXnzlUoL7bPF1Te/8mZEGurNCgy1LzWSWl7Pcr3Sixu 8nFPXpDob0Xpeq3rkuNw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 27 Aug 2013 12:59:52 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3532039908.9.2896; Tue, 27 Aug 2013 12:59:51 -0400 Message-ID: <521CDC41.7090008@isdg.net> Date: Tue, 27 Aug 2013 13:05:05 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> In-Reply-To: <521CD259.7010800@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Cc: spfbis@ietf.org, S Moonesamy , Scott Kitterman Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 17:05:29 -0000 Small correction with my proposed ABNF: On 8/27/2013 12:22 PM, Hector Santos wrote: > On 8/26/2013 10:30 PM, Tony Hansen wrote: >> On 8/26/2013 9:26 PM, John Levine wrote: >>>> I see two alternatives in the message at >>>> http://www.ietf.org/mail-archive/web/spfbis/current/msg04039.html >>>> Which one should I use in my response to Eliot's review? >>> >>> ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 >>> ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 >>> >> >> +1 >> > > To simplify the above and to further codify existing parsers in the > wild, may I suggest the ABNF be: > > ip4-cidr-length = "/" [ ip4-cidr-value ] > ip6-cidr-length = "/" [ ip6-cidr-value ] > ip4-cidr-value = 2*DIGIT ; value range 0-32 > ip6-cidr-value = 3*2DIGIT ; value range 0-128 should be: ip6-cidr-value = 3*DIGIT ; value range 0-128 > > This allows for the possible omission of the alphanumeric after the > slash. Both RFC4408 & 4408BIS says: > > If ip4-cidr-length is omitted, it is taken to be "/32". If > ip6-cidr-length is omitted, it is taken to be "/128". It is not > permitted to omit parts of the IP address instead of using CIDR > notations. That is, use 192.0.2.0/24 instead of 192.0.2. > > What it doesn't say is when the cidr-length is just "/". My > suggestion will also codify existing spf processing code where it > handles SPF mechanism examples such as: > > v=spf1 ip4:192.0.2.2/ -all > > The following simple C code will treat this condition with a cidr=0: > > int cidr = 32; // default per rfc4408 for ip4 > char *slash = strchr(mechanism,'/'); > > if (slash) cidr = atoi(slash+1); > > and continues with the ip/cidr masking calculation against the > connecting ip address. > > Another could see this as an error: > > if (slash && !strlen(slash+1)) return SPF_IP4_PERMERROR; > > or it could probably try to fit the Levine's proposed ABNF a little > better which checks for a non-blank string: > > if (slash && strlen(slash+1)) cidr = atoi(slash+1); > > which would use a cidr=32 as a default perhaps. > > So we have three possible parsing possibilities: > > cidr = 0 > cidr = 32 or 128 > return a permanent error > > The ABNF should allow for the partial omission of the cidr-length or > it should be specific to say what should be the default consideration. > Levine's proposed ABNF, while technically valid, could enforce an > error condition for a parser where it is not today. > > Overall, these are well tested case scenarios for long time SPF > parsers. As long as there is no security loophole (and I don't see > it), I think my proposed change better fits the market place of > implementations across the board. > > Thanks > -- HLS From tony@att.com Tue Aug 27 10:31:32 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 BFF1511E829E for ; Tue, 27 Aug 2013 10:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.276 X-Spam-Level: X-Spam-Status: No, score=-106.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 Glw4RbbIFKp3 for ; Tue, 27 Aug 2013 10:31:22 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 20E4211E81CD for ; Tue, 27 Aug 2013 10:31:12 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id f52ec125.0.3513584.00-409.9684763.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 27 Aug 2013 17:31:12 +0000 (UTC) X-MXL-Hash: 521ce2604aa3a7cd-04177026d76f1c8fac615964cfc6f3c1658127a8 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7RHVBHC029916 for ; Tue, 27 Aug 2013 13:31:11 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7RHV3QI029800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Aug 2013 13:31:07 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for ; Tue, 27 Aug 2013 17:30:44 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7RHUi4I032044 for ; Tue, 27 Aug 2013 13:30:44 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7RHUgvr031988 for ; Tue, 27 Aug 2013 13:30:42 -0400 Received: from [135.70.126.95] (vpn-135-70-126-95.vpn.swst.att.com[135.70.126.95]) by maillennium.att.com (mailgw1) with ESMTP id <20130827173042gw1004nh8re> (Authid: tony); Tue, 27 Aug 2013 17:30:42 +0000 X-Originating-IP: [135.70.126.95] Message-ID: <521CE240.60407@att.com> Date: Tue, 27 Aug 2013 13:30:40 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> In-Reply-To: <521CD259.7010800@isdg.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=Ru1y2laK c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=urxWXrdT53wA:10 a=sCfsyOEanakA:10 a=dBqptANV09QA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=t_sxTune5RMA:10 a=48vgC7mUAAAA:8 a=lxQfiAiZEZcnk] X-AnalysisOut: [1xdQI0A:9 a=wPNLvfGTeEIA:10 a=GwwvCvx9KPAA:10 a=Q_Ck-PMu46] X-AnalysisOut: [HUbM53:21 a=H0OVOn-qqTAActme:21] Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 17:31:32 -0000 On 8/27/2013 12:22 PM, Hector Santos wrote: > On 8/26/2013 10:30 PM, Tony Hansen wrote: >> On 8/26/2013 9:26 PM, John Levine wrote: >>>> I see two alternatives in the message at >>>> http://www.ietf.org/mail-archive/web/spfbis/current/msg04039.html >>>> Which one should I use in my response to Eliot's review? >>> >>> ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 >>> ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 >>> >> >> +1 >> > > To simplify the above and to further codify existing parsers in the > wild, may I suggest the ABNF be: > > ip4-cidr-length = "/" [ ip4-cidr-value ] > ip6-cidr-length = "/" [ ip6-cidr-value ] > ip4-cidr-value = 2*DIGIT ; value range 0-32 > ip6-cidr-value = 3*2DIGIT ; value range 0-128 > > This allows for the possible omission of the alphanumeric after the > slash. Both RFC4408 & 4408BIS says: > > If ip4-cidr-length is omitted, it is taken to be "/32". If > ip6-cidr-length is omitted, it is taken to be "/128". It is not > permitted to omit parts of the IP address instead of using CIDR > notations. That is, use 192.0.2.0/24 instead of 192.0.2. > > What it doesn't say is when the cidr-length is just "/". My > suggestion will also codify existing spf processing code where it > handles SPF mechanism examples such as: A cidr-length of just "/" is not permitted by the 4408 ABNF. Any parsers that follow the 4408 ABNF will reject the bare "/". Are you saying that there are parsers in the wild that accept already accept a bare "/", or that there are sites that are using a bare "/" ? Tony Hansen From spf2@kitterman.com Tue Aug 27 10:52:01 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 E03C511E81E2 for ; Tue, 27 Aug 2013 10:52:00 -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 w-++bG4vYAFc for ; Tue, 27 Aug 2013 10:51:59 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id EC79311E8243 for ; Tue, 27 Aug 2013 10:51:55 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 333A1D0407F; Tue, 27 Aug 2013 13:51:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377625915; bh=NEcwXE/j3i5A0r9rFol3bObWhxn3YXeQZEZys3twcHc=; h=In-Reply-To:References:Subject:From:Date:To:From; b=QJr4QOkl8x5yVD3PN0fp77JUmWsZFuDhHrnPols9LREocI1VqoYv4+FaS6/d0gxjE SC+CARJZOVmOBWO2VHQqhF0jkFkxhFfKyop3rbCDdKl6DwgonaulToxpSnkXdNeU7m WdVQ4u2IRZ2bK4a126/mbT47vWWuzZ7ClP4RjEHg= Received: from [IPV6:2600:1003:b008:aca8:673f:3fdc:6b2f:f9dd] (unknown [IPv6:2600:1003:b008:aca8:673f:3fdc:6b2f:f9dd]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B1096D04056; Tue, 27 Aug 2013 13:51:54 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <521CE240.60407@att.com> References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CE240.60407@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 27 Aug 2013 13:52:00 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 17:52:01 -0000 Tony Hansen wrote: >On 8/27/2013 12:22 PM, Hector Santos wrote: >> On 8/26/2013 10:30 PM, Tony Hansen wrote: >>> On 8/26/2013 9:26 PM, John Levine wrote: >>>>> I see two alternatives in the message at >>>>> http://www.ietf.org/mail-archive/web/spfbis/current/msg04039.html >>>>> Which one should I use in my response to Eliot's review? >>>> >>>> ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range >0-32 >>>> ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range >0-128 >>>> >>> >>> +1 >>> >> >> To simplify the above and to further codify existing parsers in the >> wild, may I suggest the ABNF be: >> >> ip4-cidr-length = "/" [ ip4-cidr-value ] >> ip6-cidr-length = "/" [ ip6-cidr-value ] >> ip4-cidr-value = 2*DIGIT ; value range 0-32 >> ip6-cidr-value = 3*2DIGIT ; value range 0-128 >> >> This allows for the possible omission of the alphanumeric after the >> slash. Both RFC4408 & 4408BIS says: >> >> If ip4-cidr-length is omitted, it is taken to be "/32". If >> ip6-cidr-length is omitted, it is taken to be "/128". It is not >> permitted to omit parts of the IP address instead of using CIDR >> notations. That is, use 192.0.2.0/24 instead of 192.0.2. >> >> What it doesn't say is when the cidr-length is just "/". My >> suggestion will also codify existing spf processing code where it >> handles SPF mechanism examples such as: > >A cidr-length of just "/" is not permitted by the 4408 ABNF. Any >parsers >that follow the 4408 ABNF will reject the bare "/". > >Are you saying that there are parsers in the wild that accept already >accept a bare "/", or that there are sites that are using a bare "/" ? There are not that I'm aware of. Scott K From hsantos@isdg.net Tue Aug 27 12:55: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 BAF2B21F9BD3 for ; Tue, 27 Aug 2013 12:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 G-1PZG-xHoSG for ; Tue, 27 Aug 2013 12:55:06 -0700 (PDT) Received: from news.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E902321F89A6 for ; Tue, 27 Aug 2013 12:54:11 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1790; t=1377633238; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ifO5ZtlKcDmM13l7BmvpCfYJSX8=; b=tjY+oYR6nEd81e6TTbta 4tS8abvDTpIGvta4ZdWbxPuALOyItGqzRXqnDumDoQpX8HrsqRZtz1inKEjszFkf Lrh04GaNQSXnUZLZSKeH7RfSmSyuk+PtL62FIpsmpuoPEf/8/VcWx19ZryHXrtRK IUEKLxiiaLTuMP1349rFnt8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 27 Aug 2013 15:53:58 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4095747891.8864.3544; Tue, 27 Aug 2013 15:53:57 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1790; t=1377632916; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=zh0agyP dNIPwQZCdP6tgttHI1fGrYJYZA5gRAjvOMXg=; b=0gnv4qdSso0E3Ck+HrxzKXH pO2wg2maDWt8LcSvRGUTv2C8fqieN5NTskfM7fvvnNSLP1eTot5rzgf0Ywpx40Yr pioTKsJ2h0W7Yy+DUcJsKQa/xdYqziibwNyPuKHjybmBcOXdATOtehZRb5mFGWYM +5li9YvQ/UGH76ihcABc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 27 Aug 2013 15:48:36 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3542165002.9.5596; Tue, 27 Aug 2013 15:48:36 -0400 Message-ID: <521D03CE.5040101@isdg.net> Date: Tue, 27 Aug 2013 15:53:50 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tony Hansen References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CE240.60407@att.com> In-Reply-To: <521CE240.60407@att.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 19:55:11 -0000 On 8/27/2013 1:30 PM, Tony Hansen wrote: >> Hector Santos >> To simplify the above and to further codify existing parsers in the >> wild, may I suggest the ABNF be: >> >> ip4-cidr-length = "/" [ ip4-cidr-value ] >> ip6-cidr-length = "/" [ ip6-cidr-value ] >> ip4-cidr-value = 2*DIGIT ; value range 0-32 >> ip6-cidr-value = 3*DIGIT ; value range 0-128 >> >> This allows for the possible omission of the alphanumeric after the >> slash. Both RFC4408 & 4408BIS says: >> >> If ip4-cidr-length is omitted, it is taken to be "/32". If >> ip6-cidr-length is omitted, it is taken to be "/128". It is not >> permitted to omit parts of the IP address instead of using CIDR >> notations. That is, use 192.0.2.0/24 instead of 192.0.2. >> >> What it doesn't say is when the cidr-length is just "/". My >> suggestion will also codify existing spf processing code where it >> handles SPF mechanism examples such as: > > A cidr-length of just "/" is not permitted by the 4408 ABNF. Any parsers > that follow the 4408 ABNF will reject the bare "/". > > Are you saying that there are parsers in the wild that accept already > accept a bare "/", or that there are sites that are using a bare "/" ? From what I can see, our commercial WCSMTP/SPF c/c++ library and implementation, it treats it as a cidr=0 rather than return an error because of the code shown: if (slash) cidr = atoi(slash+1); Long ago it was tested again libspf2. It produces the same masking result that was compared with libspf2 output to cover this use case scenarios when it was "/0" or "/" from a masking standpoint. Libspf2 even has a: if (cidr == 0) cidr=32; check in its IP4 masking function. I think it should cover all market bases; "/" and "/0" are treat the same. -- HLS From presnick@qti.qualcomm.com Tue Aug 27 13:34:08 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 ABBC621F91AB; Tue, 27 Aug 2013 13:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 ZdbNDF3qDmxw; Tue, 27 Aug 2013 13:34:04 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 0798C21E8084; Tue, 27 Aug 2013 13:33:57 -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=1377635638; x=1409171638; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2tIRNLVDj2/eKQRC5D78Bhuxa+FSE76aGXKKBHk9dM0=; b=YoIHwwTOeu0eEIgIFlQL8iS3hSTVGhGX3S6u4m91501XAULwmhpJAeJm bLd075xjhwkoSkThx3zsaMR5kS2nXmiT95OIi3C6XMx2eLXpsg0rsowFh VxJBKXToZYuU61bg3PtaGoaFs4lVpZdiiHthGJ4KKaO35NAmTY40gfYem 0=; X-IronPort-AV: E=McAfee;i="5400,1158,7180"; a="50428746" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP; 27 Aug 2013 13:33:57 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7180"; a="538012734" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 27 Aug 2013 13:33:57 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.146.2; Tue, 27 Aug 2013 13:33:57 -0700 Message-ID: <521D0D32.3000406@qti.qualcomm.com> Date: Tue, 27 Aug 2013 15:33:54 -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: References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> In-Reply-To: <20130819150521.GB21088@besserwisser.org> 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 Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 27 Aug 2013 20:34:08 -0000 I probably should have sent out this message over the weekend, but I was hoping I would complete a bigger message soon. Since I'm still working on that, a quick note to level set: I have been reading all of the Last Call responses as they have come in. I am in the process of reviewing the comments and making a summary of the issues and responses. I have asked SM as document shepherd to do the same. (Being far more diligent than I, SM has completed his review already and is waiting on me.) We will be comparing notes and posting a summary of the issues and how they were addressed, along with whether we think they are resolved. That will give folks who disagree with my assessment one last chance to say, "Pete, you completely misunderstood what my objection / response was saying and you should re-evaluate your consensus determination on this issue." After that all shakes out, I'll make the final call on consensus. An important thing to note is that I am seeing scant little I would call a "new argument" since late last week, so I would suggest that you are probably not adding to my understanding of the consensus by continuing to post. I'd like to think that everyone would be able to notice that things have gotten repetitive, both the folks who are repeating things as well as the folks who think they have to keep answering, but there does seem to be a bit of "getting the last word in" going on. Doing so isn't likely to add to my understanding or sway my opinion of the consensus (since I'm making a list of independent issues and their answers, not counting posts), but it does make it take longer for me to get through my review. So I'd recommend posting judiciously, at least until you see my summary. Thanks, pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From superuser@gmail.com Tue Aug 27 14:00:21 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 99B2A11E8204 for ; Tue, 27 Aug 2013 14:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 W+CneKYBRe6W for ; Tue, 27 Aug 2013 14:00:21 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E117311E81FF for ; Tue, 27 Aug 2013 14:00:20 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id ex4so2888648wid.11 for ; Tue, 27 Aug 2013 14:00:20 -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=XYiVkNYXnuqTq9WtxFejoDZwu6SNjWRTlVrR5l2olzo=; b=jHoI/00eCEX+Cthq/urS6qW0DdwbNvVM91PUJdlcCqnKFxPuC0Jd41SN8on0soVOe9 TXXOg52qHPRU3/XYW0t3i7sybfDzrx0VFe2N+O9SqMwbXYJ5ypSHXMPezX0BY3P7o/4i 3jFgjwYlr3nY2ZHjuhAXa+vs5XUNzMl9GFsHqq0Rh5sb0jKOUiHv8O1mtfS4//MgPPga vkoCmscjVKkZLnJ5ankvVVr4mldSc8vNmoFSXAGxCGjCl9j/oSU2Z7t1aQzqCoMpI3ed 2307SBAR0ubRh0sL5zoJEQQquZ/DgsmNgXS6bk6VvNUTi1db/R3AJerxlhMZZZqxmlbq BZzQ== MIME-Version: 1.0 X-Received: by 10.180.189.9 with SMTP id ge9mr13110442wic.52.1377637219955; Tue, 27 Aug 2013 14:00:19 -0700 (PDT) Received: by 10.180.75.144 with HTTP; Tue, 27 Aug 2013 14:00:19 -0700 (PDT) In-Reply-To: <521CE240.60407@att.com> References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CE240.60407@att.com> Date: Tue, 27 Aug 2013 14:00:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: Tony Hansen Content-Type: multipart/alternative; boundary=001a11c34302200dce04e4f42926 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 21:00:21 -0000 --001a11c34302200dce04e4f42926 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 27, 2013 at 10:30 AM, Tony Hansen wrote: > A cidr-length of just "/" is not permitted by the 4408 ABNF. Any parsers > that follow the 4408 ABNF will reject the bare "/". > > Are you saying that there are parsers in the wild that accept already > accept a bare "/", or that there are sites that are using a bare "/" ? > > An IP address followed by a slash and nothing else is a syntax error, both in the SPF context and the context of CIDR expressions in general. Even if there are implementations that tolerate this by effectively applying a default, I disagree that the ABNF should be changed to allow it. -MSK --001a11c34302200dce04e4f42926 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --001a11c34302200dce04e4f42926-- From spf2@kitterman.com Tue Aug 27 14:04: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 83A0221F8C9D for ; Tue, 27 Aug 2013 14:04:12 -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 JWC9q0fSwQzV for ; Tue, 27 Aug 2013 14:04:12 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB5011E8204 for ; Tue, 27 Aug 2013 14:04:09 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id BBF27D0407F; Tue, 27 Aug 2013 17:04:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377637445; bh=xjfZvab6lRg4BELWvDu+GvkYdSpskLGAHNPzLkg8Bsg=; h=In-Reply-To:References:Subject:From:Date:To:From; b=UTOLON9EQrCowPDW5iegY1Z6eLSvYLDrwhqrflw6Pi31SRCqbdUthl6O8Hn/2z7wO g2VFgzmov4Hrwy7NFZ8Op3j+BAsMkT00jFtHJmMTyy+tpyZ/RzQbzrZ7LLa4fZGCqW h/wbGdv+iGrMblC1N2cHEmbIZB9LLE7bAz+O+5dE= Received: from [IPV6:2600:1003:b11d:fb4b:858d:2f0a:3b19:89d6] (unknown [IPv6:2600:1003:b11d:fb4b:858d:2f0a:3b19:89d6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E0358D0401E; Tue, 27 Aug 2013 17:04:04 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CE240.60407@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 27 Aug 2013 17:04:10 -0400 To: "spfbis@ietf.org" Message-ID: <870a83e6-c4f2-49fc-bb33-adad1b3de00e@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 21:04:12 -0000 "Murray S. Kucherawy" wrote: >On Tue, Aug 27, 2013 at 10:30 AM, Tony Hansen wrote: > >> A cidr-length of just "/" is not permitted by the 4408 ABNF. Any >parsers >> that follow the 4408 ABNF will reject the bare "/". >> >> Are you saying that there are parsers in the wild that accept already >> accept a bare "/", or that there are sites that are using a bare "/" >? >> >> >An IP address followed by a slash and nothing else is a syntax error, >both >in the SPF context and the context of CIDR expressions in general. >Even if >there are implementations that tolerate this by effectively applying a >default, I disagree that the ABNF should be changed to allow it. +1. Scott K From sm@elandsys.com Tue Aug 27 14:38: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 E958B11E824C for ; Tue, 27 Aug 2013 14:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 helJxTFPEyeJ for ; Tue, 27 Aug 2013 14:38:07 -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 0B68711E822F for ; Tue, 27 Aug 2013 14:38:05 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.139.183]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7RLbo1X020075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 14:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377639483; bh=pUNMbJSOndYz5Y3l/UOMIp+rrh6enF3YlWhsPxMp5kU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=o4acXHyiLaeveGOU6zz91D2kaoRrdnHZHDyBeWRkuceEZOHJky88rflCepMblHjyu PIIGboE/jpA+/LCtsWrIPBeWNWu/f0t4eXMlgPsMVlNgnLDU+I9RKe0KV0mi+ALh9f AhI4gQLdPRGZB+wqsz4PEeq1416xb/zjMAUQgkkY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377639483; i=@elandsys.com; bh=pUNMbJSOndYz5Y3l/UOMIp+rrh6enF3YlWhsPxMp5kU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=G8LuDOb/Rovn1J/RBGoByw4br1qqQUY+dDU81a8IvEtKULZut/urbal8CKdyGYXSP apaicVxb2Emiu0WDuefF+GR1Ds+ENlb7fZu4j31iqRTZR4u5ZnJWtIcsb/qDl+W10j 1jJmXrnHt6eqxw5PZBOIGQ29XCPOVeVGcAnc8a1c= Message-Id: <6.2.5.6.2.20130827140934.0ca33680@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 27 Aug 2013 14:36:29 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <521CDC41.7090008@isdg.net> References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CDC41.7090008@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Hector Santos Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 21:38:08 -0000 At 10:05 27-08-2013, Hector Santos wrote: >>The ABNF should allow for the partial omission of the cidr-length or >>it should be specific to say what should be the default consideration. >> Levine's proposed ABNF, while technically valid, could enforce an >>error condition for a parser where it is not today. >> >>Overall, these are well tested case scenarios for long time SPF >>parsers. As long as there is no security loophole (and I don't see >>it), I think my proposed change better fits the market place of >>implementations across the board. The ABNF suggested by John Levine is technically correct. The SPFBIS working group is supposed to correct errors in the specification. It is going to be extremely difficult to convince Eliot Lear or the Routing Area Directors that "192.0.2.2/" is in accordance with CIDR notation. I'll use the technically correct ABNF in my response to Eliot Lear. Regards, S. Moonesamy (as document shepherd) From hsantos@isdg.net Tue Aug 27 14:59: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 C64CF21F9DFC for ; Tue, 27 Aug 2013 14:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.146 X-Spam-Level: X-Spam-Status: No, score=-102.146 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, 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 TGRV18zDtLlE for ; Tue, 27 Aug 2013 14:59:23 -0700 (PDT) Received: from mail.santronics.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 564B621F9DF0 for ; Tue, 27 Aug 2013 14:59:23 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1781; t=1377640748; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=gwPmcU1wBuv4W6MGDxnjiuQo5yU=; b=F7tiUOcPA/iElj8Iuids 1CCVpMrbzzlk00tLKjY6Vw+RDKMQA2FGPWXNB728J+0jbb66czVy1hPm7R1aBpfn b1pnGWKCAxTLtPPxb+KiHWVlHFTDlkRV/2HUim+F9Y6OeCjvr4L3rNBB5nm8Ja5t rdPzTINvlXy1ALnhwi7qC/o= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 27 Aug 2013 17:59:08 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4103258216.8864.3200; Tue, 27 Aug 2013 17:59:07 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1781; t=1377640425; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=pvNqk5U U4/b3iuX8Xfr/w5lV7P9PKJKubtWT2bKwET8=; b=JLCTv9fw0PlvLBMoIlHnr0f ugQtQeIi8j3nve3RjHlAK4wwTakRhV04sfHtgBUh/F26wWEDWFc+W6FMsUuNDcVX Zlo9vgr8rwggxmYllNTPKO3d+RD5iyCsTDfwTtQGMDj5he4+RfXaR6sLkcdU5oUo vFJNNkCrj/nNEJFbXjGs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 27 Aug 2013 17:53:45 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3549672924.9.1352; Tue, 27 Aug 2013 17:53:44 -0400 Message-ID: <521D2122.40204@isdg.net> Date: Tue, 27 Aug 2013 17:58:58 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CE240.60407@att.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 21:59:29 -0000 On 8/27/2013 5:00 PM, Murray S. Kucherawy wrote: > On Tue, Aug 27, 2013 at 10:30 AM, Tony Hansen wrote: > >> A cidr-length of just "/" is not permitted by the 4408 ABNF. Any parsers >> that follow the 4408 ABNF will reject the bare "/". >> >> Are you saying that there are parsers in the wild that accept already >> accept a bare "/", or that there are sites that are using a bare "/" ? >> >> > An IP address followed by a slash and nothing else is a syntax error, both > in the SPF context and the context of CIDR expressions in general. A reference would help please for the latter assertion. > Even if there are implementations that tolerate this by effectively > applying a default, I disagree that the ABNF should be changed to > allow it. It was just changed to satisfy an implementation. Why can't we codify it to satisfy existing implementations which do not error and may tolerate it? I mean if we want to look at libspf2, from what I can see, it doesn't even like a ABNF valid "/0" and treats it a mask_len = 0 string to integer conversion as an SPF_E_INVALID_CIDR error. SPF_c_parse_cidr_ip4(SPF_response_t *spf_response, unsigned char *maskp, const char *src) { int mask; /* if (spf_server->debug > 2) SPF_debugf("Parsing ip4 CIDR starting at %s", src); */ mask = strtoul(src + 1, NULL, 10); if ( mask > 32 ) { return SPF_response_add_error_ptr(spf_response, SPF_E_INVALID_CIDR, NULL, src, "Invalid IPv4 CIDR netmask (>32)"); } else if ( mask == 0 ) { return SPF_response_add_error_ptr(spf_response, SPF_E_INVALID_CIDR, NULL, src, "Invalid IPv4 CIDR netmask (=0)"); } else if ( mask == 32 ) { mask = 0; } *maskp = mask; return SPF_E_SUCCESS; } -- HLS From hsantos@isdg.net Tue Aug 27 15:15:30 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 590B811E80C5 for ; Tue, 27 Aug 2013 15:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 eaf3fm0DnJC4 for ; Tue, 27 Aug 2013 15:15:24 -0700 (PDT) Received: from mail.santronics.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C216811E80D9 for ; Tue, 27 Aug 2013 15:15:23 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1152; t=1377641719; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=5oCotj+oiVOGuLbJZkwtX/fFENA=; b=RPpTPjxwquw3qFqQUX8j bvWw0LUD36CDSi/n/pDSqNB9axQaUhMXvjQC31o4EGC9HFUn0zeE11o0a0mlSIE4 NSCnFgWL8hG2KWyDTep/grekQmVKG8IlpZK7DCTHcXvzaCBn1BIkRcBTtrGaJi6h waIjZqrRouCMimhhpG+0zNI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 27 Aug 2013 18:15:19 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4104228277.8864.5440; Tue, 27 Aug 2013 18:15:18 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1152; t=1377641396; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=xTkSOzW C7/eQ1I85nMm8ibc336M2M8U7TUIcr3Vk/m8=; b=X+HZoJx9x5TQbpC84PTdIxv DjPDp7TUAEH6E5RNcaSrX+uxnvTomOY0DKbb3pOoBpDLX7WUlj9Wf0heO6LzCHb4 v9rJUc8SDZ7WNhtgAf037vdrwCHQlKMDqjzM+GZuDSpxKNeOUtEVtKklsOo1Zfal 3Y3lTGtnZmFceQ794dZ4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 27 Aug 2013 18:09:56 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3550643533.9.1988; Tue, 27 Aug 2013 18:09:54 -0400 Message-ID: <521D24ED.7090804@isdg.net> Date: Tue, 27 Aug 2013 18:15:09 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: spfbis@ietf.org, S Moonesamy References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CDC41.7090008@isdg.net> <6.2.5.6.2.20130827140934.0ca33680@elandnews.com> In-Reply-To: <6.2.5.6.2.20130827140934.0ca33680@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 22:15:31 -0000 On 8/27/2013 5:36 PM, S Moonesamy wrote: > > The ABNF suggested by John Levine is technically correct. The SPFBIS > working group is supposed to correct errors in the specification. It > is going to be extremely difficult to convince Eliot Lear or the > Routing Area Directors that "192.0.2.2/" is in accordance with CIDR > notation. Can we reference a CIDR notation guide/RFC? > I'll use the technically correct ABNF in my response to > Eliot Lear. From what I see, its not technically correct and currently reflective of all the parsers. Not all parsers will treat it as an error and LibSPF2 will in fact, treat the ABNF correct "/0" as an error as well. According to the libSPF2 web site, the following packages use LIBSPF2: Sendmail, Postfix, Exim, Zmailer and MS Exchange. Are they now not compliant packages? At the very least, it should be tolerated "/" == "/0" or describe this exception just like the short circuits exception is currently described (not allowed): It is not permitted to omit parts of the IP address instead of using CIDR notations. That is, use 192.0.2.0/24 instead of 192.0.2. -- HLS From marka@isc.org Tue Aug 27 15:39:32 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 8DB1721F9B4D for ; Tue, 27 Aug 2013 15:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] 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 NafnSJxZEP03 for ; Tue, 27 Aug 2013 15:39:28 -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 516AE21F9A0C for ; Tue, 27 Aug 2013 15:39:28 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id F3CD7C94AF; Tue, 27 Aug 2013 22:38:58 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377643152; bh=+AdS1AH67TPkkuoAHkt8hb7EQnr7HUqtYjKccB4F6s4=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=AXFfUGZaXdQx1Rlig7eCS274D1d51BkuxynclZ2wzymOIX9ubN/wJ/f7WMxHPRPBO 0t3Izo6SRajQUDWRBWCIm4BvTgLll7ZlBYS/KlysnU2hjNqarCXm0NXThQTDmx3/or XjGQWZ1Rp5R0Fl5n2FsyHjidFToXzEK1vjfG0CmU= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 27 Aug 2013 22:38:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2A041160446; Tue, 27 Aug 2013 22:39:37 +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 EEEAD16043C; Tue, 27 Aug 2013 22:39:36 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2753F38ECCD3; Wed, 28 Aug 2013 08:38:52 +1000 (EST) To: Hector Santos From: Mark Andrews References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CE240.60407@att.com> <521D2122.40204@isdg.net> In-reply-to: Your message of "Tue, 27 Aug 2013 17:58:58 -0400." <521D2122.40204@isdg.net> Date: Wed, 28 Aug 2013 08:38:52 +1000 Message-Id: <20130827223852.2753F38ECCD3@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 22:39:32 -0000 In message <521D2122.40204@isdg.net>, Hector Santos writes: > On 8/27/2013 5:00 PM, Murray S. Kucherawy wrote: > > On Tue, Aug 27, 2013 at 10:30 AM, Tony Hansen wrote: > > > >> A cidr-length of just "/" is not permitted by the 4408 ABNF. Any parsers > >> that follow the 4408 ABNF will reject the bare "/". > >> > >> Are you saying that there are parsers in the wild that accept already > >> accept a bare "/", or that there are sites that are using a bare "/" ? > >> > >> > > An IP address followed by a slash and nothing else is a syntax error, both > > in the SPF context and the context of CIDR expressions in general. > > A reference would help please for the latter assertion. > > > Even if there are implementations that tolerate this by effectively > > applying a default, I disagree that the ABNF should be changed to > > allow it. > > It was just changed to satisfy an implementation. Why can't we codify > it to satisfy existing implementations which do not error and may > tolerate it? Because it looks likes and is a error. If SPF_c_parse_cidr_ip4 is supposed to be checking src is a valid prefix length well it doesn't as the coding is sloppy. % cat lllll.c #include #include int main() { long mask; char src[] ="/xxxx"; mask = strtoul(src + 1, NULL, 10); printf("mask=%lu\n", mask); } % cc lllll.c % ./a.out mask=0 % > I mean if we want to look at libspf2, from what I can see, it doesn't > even like a ABNF valid "/0" and treats it a mask_len = 0 string to > integer conversion as an SPF_E_INVALID_CIDR error. > > SPF_c_parse_cidr_ip4(SPF_response_t *spf_response, > unsigned char *maskp, > const char *src) > { > int mask; > > /* > if (spf_server->debug > 2) > SPF_debugf("Parsing ip4 CIDR starting at %s", src); > */ > > mask = strtoul(src + 1, NULL, 10); > > > if ( mask > 32 ) { > return SPF_response_add_error_ptr(spf_response, SPF_E_INVALID_C > IDR, > NULL, src, > "Invalid IPv4 CIDR netmask (>32 > )"); > } > else if ( mask == 0 ) { > return SPF_response_add_error_ptr(spf_response, SPF_E_INVALID_C > IDR, > NULL, src, > "Invalid IPv4 CIDR netmask (=0) > "); > } > else if ( mask == 32 ) { > mask = 0; > } > > *maskp = mask; > > return SPF_E_SUCCESS; > } > > > > > -- > HLS > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sm@elandsys.com Tue Aug 27 15:54:48 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 40D7B21F9C6F for ; Tue, 27 Aug 2013 15:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 CePDg9QUwoOF for ; Tue, 27 Aug 2013 15:54:47 -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 3D51221F9BAD for ; Tue, 27 Aug 2013 15:54:36 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.239]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7RMsLlP006425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 15:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377644073; bh=9Z9Z1QSiY9PtX6MJxHTGxSmO4PHpgA7noPVqyBDBnn4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jVkVhql+eH/YOFe5tPk2lhYlKiwv/CEIC+yAV0ipjYmw2R4bZee99Mn7tc9dpZY5t N2BehHRxG/ebcWk1/aI2OPBvEkd6N2DPW7SLAsiL9aot/y3fgvVGqbQCshfspgA4AM C1X47ja9QO2ObcuOinIWAuWpSBa3jpOugGk1UBMI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377644073; i=@elandsys.com; bh=9Z9Z1QSiY9PtX6MJxHTGxSmO4PHpgA7noPVqyBDBnn4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wSZtglVnZF3suvcUv93vOJPNmUryjj273yxv7o/+0/qatn751sU3PgyOd8XPBuEUz tHBGsRMpvaaD6KPtK8MEh75E1LiPxruQU14poBE9s3WvSUVcUnwgHr4Q7ls2+h0F6L IjahkIMKfMf/inf5dTEVq1yYT01X/rJsWKI9mS3I= Message-Id: <6.2.5.6.2.20130827152917.0ca4c4f8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 27 Aug 2013 15:47:35 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <521D24ED.7090804@isdg.net> References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CDC41.7090008@isdg.net> <6.2.5.6.2.20130827140934.0ca33680@elandnews.com> <521D24ED.7090804@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 22:54:48 -0000 Hi Hector, At 15:15 27-08-2013, Hector Santos wrote: >Can we reference a CIDR notation guide/RFC? There is already a reference to RFC 4632. > From what I see, its not technically correct and currently > reflective of all the parsers. Not all parsers will treat it as an > error and LibSPF2 will in fact, treat the ABNF correct "/0" as an > error as well. According to the libSPF2 web site, the following > packages use LIBSPF2: Sendmail, Postfix, Exim, Zmailer and MS > Exchange. Are they now not compliant packages? I don't have an opinion about compliance. I'll have to read the code again to determine whether there may be an interoperability issue. >At the very least, it should be tolerated "/" == "/0" or describe >this exception just like the short circuits exception is currently >described (not allowed): > > It is not permitted to omit parts of the IP address > instead of using CIDR notations. That is, use > 192.0.2.0/24 instead of 192.0.2. The IESG will comment about the issue if what I mentioned is not technically correct as its members will be reviewing the specification. In my personal opinion it's not worthwhile to get into that level of detail (see text from the draft). It's the working group opinion that matters as it will be up to it to discuss the text with the IESG if there is a DISCUSS. Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Tue Aug 27 16:01:55 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 3CB5A11E80F4 for ; Tue, 27 Aug 2013 16:01:55 -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 7oGObe7WAy-v for ; Tue, 27 Aug 2013 16:01:54 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id B7F7611E80E6 for ; Tue, 27 Aug 2013 16:01:54 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id D16FCD0407F; Tue, 27 Aug 2013 19:01:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377644513; bh=pVj1ld3ilkFNE4iD9RJsykG4U6LHRQcvmDLy8m8sPMY=; h=In-Reply-To:References:Subject:From:Date:To:From; b=ZiGDl7CRDweuS3n672vfIGB0uX/8rovsVIL2JLLq8uSmPFqeSD+JGpfwHd5hp11Gb nexFwh/uTugUz8zZub+3Ph4bTTxWdUviHU+WE2ltuEI2qr7gJC7TebrFXnQ/8w6z+m 9KeUqW975mdAGHaJqYVjkKdmOMEV/qktCq78LS7E= Received: from [IPV6:2600:1003:b00e:a195:674c:3277:4395:811] (unknown [IPv6:2600:1003:b00e:a195:674c:3277:4395:811]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 78AEED0401E; Tue, 27 Aug 2013 19:01:53 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <521D24ED.7090804@isdg.net> References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CDC41.7090008@isdg.net> <6.2.5.6.2.20130827140934.0ca33680@elandnews.com> <521D24ED.7090804@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 27 Aug 2013 19:02:01 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 27 Aug 2013 23:01:55 -0000 Hector Santos wrote: >On 8/27/2013 5:36 PM, S Moonesamy wrote: >> >> The ABNF suggested by John Levine is technically correct. The SPFBIS >> working group is supposed to correct errors in the specification. It >> is going to be extremely difficult to convince Eliot Lear or the >> Routing Area Directors that "192.0.2.2/" is in accordance with CIDR >> notation. > >Can we reference a CIDR notation guide/RFC? > >> I'll use the technically correct ABNF in my response to >> Eliot Lear. > > From what I see, its not technically correct and currently reflective >of all the parsers. Not all parsers will treat it as an error and >LibSPF2 will in fact, treat the ABNF correct "/0" as an error as well. > According to the libSPF2 web site, the following packages use >LIBSPF2: Sendmail, Postfix, Exim, Zmailer and MS Exchange. Are they >now not compliant packages? At least with Sendmail and Postfix, it's not common to use it. There are alternatives. At worst, it may fail to detect a few record errors. If that's"non-compliant", then I guess so, but it's a minor bug. We shouldn't write standards around implementation errors. Scott K From superuser@gmail.com Tue Aug 27 17:30:41 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 3A17611E83C4 for ; Tue, 27 Aug 2013 17:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 mvX6qULPBcu8 for ; Tue, 27 Aug 2013 17:30:40 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 743D711E810E for ; Tue, 27 Aug 2013 17:30:40 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id l12so4611549wiv.1 for ; Tue, 27 Aug 2013 17:30:39 -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=+btqG5SZ09Yd/1TXGj1GpqPtUYU78zI3/XuBzmln3Ds=; b=KjwI+B+uxWME2M3+LOnnt5ZJWtXZTdfA248whOjbjDMA7Dsywe7Jp/AZXEgDut4oEa iUWIx3O4PfvGKFizSSc4qVeWpQc1g8R8CUalLKr1qkWsPLzRWxiskHYWrg0PtogMqQ3V WMQNmp/OcEtAoPn7Gj8qY3p75RpMa7DbEqVo0vc4GW7Y1dXxW8R7SC4dHvMVtyRWTn+3 O87isE9npgcbpaXUe95b6lfQjU6zDYAcxUQ1zcsN6kO2NZtBPyqlFDM2MRvPDcSZmt7X TorS1AOSa5vEt4aOCE76DYc/5GFYac3Bd/6F8SyckWfyvQ/fB7G8k4jXILN9+ZPZ+ehI BIkQ== MIME-Version: 1.0 X-Received: by 10.180.183.51 with SMTP id ej19mr13706335wic.60.1377649839547; Tue, 27 Aug 2013 17:30:39 -0700 (PDT) Received: by 10.180.75.144 with HTTP; Tue, 27 Aug 2013 17:30:39 -0700 (PDT) In-Reply-To: References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CDC41.7090008@isdg.net> <6.2.5.6.2.20130827140934.0ca33680@elandnews.com> <521D24ED.7090804@isdg.net> Date: Tue, 27 Aug 2013 17:30:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a11c2409e4fa94f04e4f71970 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 28 Aug 2013 00:30:41 -0000 --001a11c2409e4fa94f04e4f71970 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 27, 2013 at 4:02 PM, Scott Kitterman wrote: > We shouldn't write standards around implementation errors. > > +1. There's a bug in the code, not a bug in the specification. Let's fix the right thing, please. "/0" is not wrong according to RFC4632. "/" is. So yes, if libspf2 (or anything) accepts "/" with no digits after it, then it needs to be fixed. Of 180,000+ records found during the RFC6686 surveys, not one contained any portion of a "v=spf1" record (TXT or 99) that included "/" followed by something other than a digit, or "/" at the end of the record. The likelihood that someone out there is relying on the existence of this bug in implementations seems to be, at best, vanishingly small. Thus, the fact that this bug has been in some implementations all along is not a good argument for augmenting the standard. Finally, I take the libspf2 page to mean the add-on modules that use it are affected by this bug, but not that the MTAs themselves are impacted, because they don't use it directly. -MSK --001a11c2409e4fa94f04e4f71970 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 27, 2013 at 4:02 PM, Scott Kitterman <spf2@k= itterman.com> wrote:
=A0We shouldn't write= standards around implementation errors.


+1.=A0 There's a bug in the code, not a bug in the specification.=A0 Le= t's fix the right thing, please.

"/0" is not wrong according to RFC4632.=A0 "/" is.=A0= So yes, if libspf2 (or anything) accepts "/" with no digits afte= r it, then it needs to be fixed.

Of 180,000+= =20 records found during the RFC6686 surveys, not one contained any portion of = a "v=3Dspf1" record (TXT or 99) that included "/" follow= ed by something other than a digit, or "/" at the end of the reco= rd. The likelihood that someone out there is relying on the existence of th= is bug in implementations seems to be, at best, vanishingly small.=A0 Thus,= the fact that this bug has been in some implementations all along is not a= good argument for augmenting the standard.

Finally, I take the libspf2 page= to mean the add-on modules that use it are affected by this bug, but not t= hat the MTAs themselves are impacted, because they don't use it directl= y.

-MSK
--001a11c2409e4fa94f04e4f71970-- From superuser@gmail.com Tue Aug 27 17:35:39 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 BCEEA11E8108 for ; Tue, 27 Aug 2013 17:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 KOHQSPi3J7ZI for ; Tue, 27 Aug 2013 17:35:39 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6547C11E8103 for ; Tue, 27 Aug 2013 17:35:38 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id ex4so2821343wid.2 for ; Tue, 27 Aug 2013 17:35:34 -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=i9F7TtdCMDsQJgT2Dj967zgtxwV33ErzN4q3dYKVjGo=; b=oFdKzHHMWGktdOrBoJlPeXtxpaWMwW6tWn+cCkrRHjLGe6rM5LzOs11l0dN9Pw0jVL udZgkAZtSDehJWmVLKfj5FGxUELJDb+7imkLd2gSlbo0MunMP3ea7VemKbqahqlLh/rM 3qN2uksNFvihrXh6WbGHz9Eg6VRXbUAGM0ww5QhrY32BghK5xixgsswZBakVQdGN23eT VKVMcEQ1h5ZqRzUSj86nZeHAAquVeO+BJI00Z9ptt4va5xyySnEtciOrv2YuOmvdKtfb +dwUnl9C4OdDSD8kl9kBAJLz+HG/Zeswi48cKs+/ShgKb3A/f6LO0WKSRbN4D68deIaE JLdQ== MIME-Version: 1.0 X-Received: by 10.195.12.170 with SMTP id er10mr16533174wjd.5.1377650134507; Tue, 27 Aug 2013 17:35:34 -0700 (PDT) Received: by 10.180.75.144 with HTTP; Tue, 27 Aug 2013 17:35:34 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130827152917.0ca4c4f8@elandnews.com> References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CDC41.7090008@isdg.net> <6.2.5.6.2.20130827140934.0ca33680@elandnews.com> <521D24ED.7090804@isdg.net> <6.2.5.6.2.20130827152917.0ca4c4f8@elandnews.com> Date: Tue, 27 Aug 2013 17:35:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7bb04c92e4690d04e4f72acd Cc: "spfbis@ietf.org" , Hector Santos Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 28 Aug 2013 00:35:39 -0000 --047d7bb04c92e4690d04e4f72acd Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 27, 2013 at 3:47 PM, S Moonesamy wrote: > > It is not permitted to omit parts of the IP address >> instead of using CIDR notations. That is, use >> 192.0.2.0/24 instead of 192.0.2. >> > > Interestingly enough, the BSD inet_aton() function would accept the latter version, treating it as 192.0.0.2. This is a documented property of that function and has been there for as long as I can remember. Any software that uses that function without also checking for three dots in the input string is probably forgiving that syntax shortcut. That said, I don't think that's ever been declared as a standard alternative way to express an IP address, so I'm not suggesting anything be changed here. This just stirred a possibly relevant memory. -MSK --047d7bb04c92e4690d04e4f72acd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 27, 2013 at 3:47 PM, S Moonesamy <sm+ietf@= elandsys.com> wrote:

=A0 =A0 =A0 It is not permitted to omit parts of the IP address
=A0 =A0 =A0 instead of using CIDR notations. =A0That is, use
=A0 =A0 =A0 192.0.2.0/24<= /a> instead of 192.0.2.


--047d7bb04c92e4690d04e4f72acd-- From marka@isc.org Tue Aug 27 17:48:47 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 9BC1511E8108 for ; Tue, 27 Aug 2013 17:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 iuTRJKFhuQ0G for ; Tue, 27 Aug 2013 17:48:42 -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 CDFF911E8103 for ; Tue, 27 Aug 2013 17:48:42 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 7AFF3C94B4; Wed, 28 Aug 2013 00:48:27 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377650922; bh=lGGuwHLsZrEpxmE9ltEd+1CCX38Fld4E3EBxhw4RAvg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=rwiWAxYcR3kKM3GIOmm+SA8Qre5iELx1ispQ+mBkS8rUgkG9IgvgcA3yVLvWUmY4G XNTcVVgnnRJ9f8Gb7l3agL01DUp17XuQbGLYBSXqHZyowF+NQHu5yAosxH2zWHlOhh Vkusc5D8f4ZCiD9RtKvK3IoQQqQ304FVyS3X81/M= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 28 Aug 2013 00:48:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0AD6D160446; Wed, 28 Aug 2013 00:49:06 +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 D012B16043C; Wed, 28 Aug 2013 00:49:05 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0FDEA38EE5DA; Wed, 28 Aug 2013 10:48:21 +1000 (EST) To: "Murray S. Kucherawy" From: Mark Andrews References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CDC41.7090008@isdg.net> <6.2.5.6.2.20130827140934.0ca33680@elandnews.com> <521D24ED.7090804@isdg.net> <6.2.5.6.2.20130827152917.0ca4c4f8@elandnews.com> In-reply-to: Your message of "Tue, 27 Aug 2013 17:35:34 -0700." Date: Wed, 28 Aug 2013 10:48:21 +1000 Message-Id: <20130828004822.0FDEA38EE5DA@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "spfbis@ietf.org" , Hector Santos , S Moonesamy Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 28 Aug 2013 00:48:47 -0000 In message , "Murray S. Kucherawy" writes: > On Tue, Aug 27, 2013 at 3:47 PM, S Moonesamy wrote: > > > > > It is not permitted to omit parts of the IP address > >> instead of using CIDR notations. That is, use > >> 192.0.2.0/24 instead of 192.0.2. > >> > > > > > Interestingly enough, the BSD inet_aton() function would accept the latter > version, treating it as 192.0.0.2. This is a documented property of that > function and has been there for as long as I can remember. Any software > that uses that function without also checking for three dots in the input > string is probably forgiving that syntax shortcut. > > That said, I don't think that's ever been declared as a standard > alternative way to express an IP address, so I'm not suggesting anything be > changed here. This just stirred a possibly relevant memory. Actually it is standard but for class B addresses. e.g. 130.155.1 For class A you have a single period. e.g. 127.1 If you want to check dotted decimal quad you need to use inet_pton. Unless you OS vendor has hacked it (broken it) inet_pton only accepts dotted decimal quad without leading zeros. Mark > -MSK > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From superuser@gmail.com Tue Aug 27 18:14:43 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 7170D21E8105 for ; Tue, 27 Aug 2013 18:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 evKgqFNeZzAA for ; Tue, 27 Aug 2013 18:14:43 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B2CFD11E8110 for ; Tue, 27 Aug 2013 18:14:42 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t60so4733150wes.3 for ; Tue, 27 Aug 2013 18:14:41 -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=gdQo22vHXpG/GZAKFVVthTMmhKLx9+PL0uiktfHTN98=; b=VU2cIlKCXmPh4EAFX94VOAYW4+MhFQGQQqjSqDornRe7oEfdVQVrUXQ8WQWZuhT1Gz VFZ7J5ImzGLqefBe4zVxGf8Y+42ewCEfkJx9EdMydpJ3XiulwlDwzDUT8dgdtp+YGN3v 11JVLXGja3TGeHF7kzyvGbHpL9ZngNd2eo6Ps1kkD56DWK/5BOCT8PtKrzXAohiU+UgV LyoLJIS/6ngzjFvy1wwT/ifEOPF7J8M16nbrzC0tBzPa33nsFQcK5IiDCwazNSfhnsx4 nygjJLEEv4mICwSjW6vYkz3hYhnSmzLi0WYj4LE8pF6/rWM4SwAXXrFmoIc/UbjtO0Ft drxA== MIME-Version: 1.0 X-Received: by 10.180.183.51 with SMTP id ej19mr13812866wic.60.1377652480443; Tue, 27 Aug 2013 18:14:40 -0700 (PDT) Received: by 10.180.75.144 with HTTP; Tue, 27 Aug 2013 18:14:40 -0700 (PDT) In-Reply-To: <20130828004822.0FDEA38EE5DA@drugs.dv.isc.org> References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CDC41.7090008@isdg.net> <6.2.5.6.2.20130827140934.0ca33680@elandnews.com> <521D24ED.7090804@isdg.net> <6.2.5.6.2.20130827152917.0ca4c4f8@elandnews.com> <20130828004822.0FDEA38EE5DA@drugs.dv.isc.org> Date: Tue, 27 Aug 2013 18:14:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: Mark Andrews Content-Type: multipart/alternative; boundary=001a11c2409eb88c7d04e4f7b694 Cc: "spfbis@ietf.org" , Hector Santos , S Moonesamy Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 28 Aug 2013 01:14:43 -0000 --001a11c2409eb88c7d04e4f7b694 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 27, 2013 at 5:48 PM, Mark Andrews wrote: > Actually it is standard but for class B addresses. > > e.g. 130.155.1 > > For class A you have a single period. > > e.g. 127.1 > > If you want to check dotted decimal quad you need to use inet_pton. > Unless you OS vendor has hacked it (broken it) inet_pton only accepts > dotted decimal quad without leading zeros. > Which standard allows that expression? I know what inet_aton() accepts, but I never found an RFC or similar document that codified it. The closest thing I found was the inet_aton() man page, which is pretty specific to one family of operating systems. -MSK --001a11c2409eb88c7d04e4f7b694 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --001a11c2409eb88c7d04e4f7b694-- From marka@isc.org Tue Aug 27 18:46: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 DACDA11E810F for ; Tue, 27 Aug 2013 18:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 P-Q4aXFf0XD6 for ; Tue, 27 Aug 2013 18:46:31 -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 996E321F9C33 for ; Tue, 27 Aug 2013 18:46:31 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id DA5C5C94AC; Wed, 28 Aug 2013 01:45:40 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377654387; bh=VU8Tf+J9IVM8JwITH7BhkG1lmm3bEEbDsw69rJ7vnnE=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Jn+Os1jMmtH+dBX0Hec+S/Tilg6VjLhk1Th6X0cPekkymkXA+JcCx978yuFmxv5yb wYcvJ5OYdmTC7mXjzeNBCqHPbsKst0Cm6D/SJlueymBhCOzfrpYCZfMwJ/sfDQGkrI ZDTwNCaFhvj3AFPvhQy5VcuwprJeB3I2JTWyPaO8= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 28 Aug 2013 01:45:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 85A6F160446; Wed, 28 Aug 2013 01:46:19 +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 55AFE16043C; Wed, 28 Aug 2013 01:46:19 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 866DD38EEA3A; Wed, 28 Aug 2013 11:45:33 +1000 (EST) To: "Murray S. Kucherawy" From: Mark Andrews References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CDC41.7090008@isdg.net> <6.2.5.6.2.20130827140934.0ca33680@elandnews.com> <521D24ED.7090804@isdg.net> <6.2.5.6.2.20130827152917.0ca4c4f8@elandnews.com> <20130828004822.0FDEA38EE5DA@drugs.dv.isc.org> In-reply-to: Your message of "Tue, 27 Aug 2013 18:14:40 -0700." Date: Wed, 28 Aug 2013 11:45:33 +1000 Message-Id: <20130828014533.866DD38EEA3A@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "spfbis@ietf.org" , Hector Santos , S Moonesamy Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 28 Aug 2013 01:46:36 -0000 In message , "Mu rray S. Kucherawy" writes: > --001a11c2409eb88c7d04e4f7b694 > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Aug 27, 2013 at 5:48 PM, Mark Andrews wrote: > > > Actually it is standard but for class B addresses. > > > > e.g. 130.155.1 > > > > For class A you have a single period. > > > > e.g. 127.1 > > > > If you want to check dotted decimal quad you need to use inet_pton. > > Unless you OS vendor has hacked it (broken it) inet_pton only accepts > > dotted decimal quad without leading zeros. > > > > Which standard allows that expression? I know what inet_aton() accepts, > but I never found an RFC or similar document that codified it. The closest > thing I found was the inet_aton() man page, which is pretty specific to one > family of operating systems. Last I heard POSIX was a standards body. http://pubs.opengroup.org/onlinepubs/009695399/functions/inet_ntoa.html > -MSK -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dhc@dcrocker.net Tue Aug 27 19:40:47 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 6139721E8108 for ; Tue, 27 Aug 2013 19:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvIXPAiF6ja2 for ; Tue, 27 Aug 2013 19:40:41 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 18EA311E821D for ; Tue, 27 Aug 2013 19:40:41 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7S2eLFt021216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Aug 2013 19:40:25 -0700 Message-ID: <521D6312.8000302@dcrocker.net> Date: Tue, 27 Aug 2013 19:40:18 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark Andrews References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CDC41.7090008@isdg.net> <6.2.5.6.2.20130827140934.0ca33680@elandnews.com> <521D24ED.7090804@isdg.net> <6.2.5.6.2.20130827152917.0ca4c4f8@elandnews.com> <20130828004822.0FDEA38EE5DA@drugs.dv.isc.org> <20130828014533.866DD38EEA3A@drugs.dv.isc.org> In-Reply-To: <20130828014533.866DD38EEA3A@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 27 Aug 2013 19:40:25 -0700 (PDT) Cc: "spfbis@ietf.org" , Hector Santos , "Murray S. Kucherawy" , S Moonesamy Subject: Re: [spfbis] Applications Directorate Review: ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 02:40:47 -0000 On 8/27/2013 6:45 PM, Mark Andrews wrote: > Last I heard POSIX was a standards body. You are trying to offer a standard for a parameter to a specific Unix function call as a format that should affect the work in the IETF? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From marka@isc.org Tue Aug 27 19:53:48 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 D3F4B11E811A for ; Tue, 27 Aug 2013 19:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 rN8yAoMX0PY0 for ; Tue, 27 Aug 2013 19:53:44 -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 153C211E8106 for ; Tue, 27 Aug 2013 19:53:44 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id F3A8BC94B2; Wed, 28 Aug 2013 02:53:31 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377658423; bh=NQUCUUf8bRDthVWaVZq4VXNxWWX05q9k5ZWLH64Qucs=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=JWGIZu2UuRgtniRmGlTDjPprNQ4CTEScjdfyUVL9P5HRXRN+ndlPDjpwNxyG1z5nY Th18EDfL0lX3gmODsL8fvefXHYWZjHIt78Xeb9CC2HaeD5XyTqVMap34pOOcumcSQH zrlG+nhsVP9/BXyAG3yVcay7C8oxKg/VkUDqbelQ= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 28 Aug 2013 02:53:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E2713160459; Wed, 28 Aug 2013 02:54:10 +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 B25C516043C; Wed, 28 Aug 2013 02:54:10 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4EB4F38EF22C; Wed, 28 Aug 2013 12:53:27 +1000 (EST) To: dcrocker@bbiw.net From: Mark Andrews References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CDC41.7090008@isdg.net> <6.2.5.6.2.20130827140934.0ca33680@elandnews.com> <521D24ED.7090804@isdg.net> <6.2.5.6.2.20130827152917.0ca4c4f8@elandnews.com> <20130828004822.0FDEA38EE5DA@drugs.dv.isc.org> <20130828014533.866DD38EEA3A@drugs.dv.isc.org> <521D6312.8000302@dcrocker.net> In-reply-to: Your message of "Tue, 27 Aug 2013 19:40:18 -0700." <521D6312.8000302@dcrocker.net> Date: Wed, 28 Aug 2013 12:53:27 +1000 Message-Id: <20130828025327.4EB4F38EF22C@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "spfbis@ietf.org" , Hector Santos , "Murray S. Kucherawy" , S Moonesamy Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 28 Aug 2013 02:53:48 -0000 In message <521D6312.8000302@dcrocker.net>, Dave Crocker writes: > On 8/27/2013 6:45 PM, Mark Andrews wrote: > > Last I heard POSIX was a standards body. > > You are trying to offer a standard for a parameter to a specific Unix > function call as a format that should affect the work in the IETF? I think it should be dotted decimal quad with no leading zeros. There exists standard functions that only accept that as input. Having had to deal with the problems causes by people not being aware of what inet_addr() accepts as input I want this to be a straight forward definition. There was a claim that "127.1" was not a standardised format for a IP address and that claim was wrong. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From spf2@kitterman.com Tue Aug 27 20:05:27 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 1367411E8106 for ; Tue, 27 Aug 2013 20:05: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 g8kXDlAKowD5 for ; Tue, 27 Aug 2013 20:05:21 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B25A711E8120 for ; Tue, 27 Aug 2013 20:05:21 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4DC6420E40FE; Tue, 27 Aug 2013 23:05:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377659119; bh=OOWYh7SpMXQUN/1Ayx/GIay5nP3dvWPbmyjKlWJmmP0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=d2fRFzAiOj08+/9VbRviRgVnUSI6k/SFtIWBy+Iwn7l3VX6kP0SFgrDPtU7W38kUy yaQZDvSa1aNmeCKZ7kRjb5Bq3ijQiTly0Qhs4Hpm4uzAYRWE6miuhfgiv039GLcaZf 8/SQ3NRMXSJHLTGqMsrBD+bc74OkIYR7cIWVOidQ= 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 374DD20E40D3; Tue, 27 Aug 2013 23:05:06 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 27 Aug 2013 23:05:06 -0400 Message-ID: <5343023.3bpNPXJNY8@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <521D6312.8000302@dcrocker.net> References: <20130827012600.83309.qmail@joyce.lan> <20130828014533.866DD38EEA3A@drugs.dv.isc.org> <521D6312.8000302@dcrocker.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] Applications Directorate Review: ABNF 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, 28 Aug 2013 03:05:27 -0000 On Tuesday, August 27, 2013 19:40:18 Dave Crocker wrote: > On 8/27/2013 6:45 PM, Mark Andrews wrote: > > Last I heard POSIX was a standards body. > > You are trying to offer a standard for a parameter to a specific Unix > function call as a format that should affect the work in the IETF? It was pretty clear to me that the conversation was about inet_aton(), which is specific to a family of operating systems (Linux is the same), so it was just about how some systems function, not any kind of a call for change. Scott K From dhc@dcrocker.net Tue Aug 27 20:16: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 631E021E8108 for ; Tue, 27 Aug 2013 20:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YomkB8ieJzr for ; Tue, 27 Aug 2013 20:16:18 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE4111E8120 for ; Tue, 27 Aug 2013 20:16:18 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7S3G2OT021727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Aug 2013 20:16:05 -0700 Message-ID: <521D6B6E.3000001@dcrocker.net> Date: Tue, 27 Aug 2013 20:15:58 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark Andrews References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CDC41.7090008@isdg.net> <6.2.5.6.2.20130827140934.0ca33680@elandnews.com> <521D24ED.7090804@isdg.net> <6.2.5.6.2.20130827152917.0ca4c4f8@elandnews.com> <20130828004822.0FDEA38EE5DA@drugs.dv.isc.org> <20130828014533.866DD38EEA3A@drugs.dv.isc.org> <521D6312.8000302@dcrocker.net> <20130828025327.4EB4F38EF22C@drugs.dv.isc.org> In-Reply-To: <20130828025327.4EB4F38EF22C@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 27 Aug 2013 20:16:05 -0700 (PDT) Cc: "spfbis@ietf.org" , Hector Santos , S Moonesamy Subject: Re: [spfbis] Applications Directorate Review: ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 03:16:35 -0000 On 8/27/2013 7:53 PM, Mark Andrews wrote: > I think it should be dotted decimal quad with no leading zeros. > There exists standard functions that only accept that as input. I think you are confusing a programming convention with a protocol convention. Just to be clear, the current discussion is about the latter. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Tue Aug 27 20:17: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 7CA6221E810A for ; Tue, 27 Aug 2013 20:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Dhlo2jGSQ8L for ; Tue, 27 Aug 2013 20:17:10 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7785811E8106 for ; Tue, 27 Aug 2013 20:17:05 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7S3H1Mr021765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Aug 2013 20:17:05 -0700 Message-ID: <521D6BAA.9040307@dcrocker.net> Date: Tue, 27 Aug 2013 20:16:58 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Scott Kitterman References: <20130827012600.83309.qmail@joyce.lan> <20130828014533.866DD38EEA3A@drugs.dv.isc.org> <521D6312.8000302@dcrocker.net> <5343023.3bpNPXJNY8@scott-latitude-e6320> In-Reply-To: <5343023.3bpNPXJNY8@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 27 Aug 2013 20:17:05 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review: ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 03:17:15 -0000 On 8/27/2013 8:05 PM, Scott Kitterman wrote: > so it was > just about how some systems function, not any kind of a call for change. whereas it sounded to me like an attempt to get the SPF spec changed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Tue Aug 27 20:20:29 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 CFCCC11E8106 for ; Tue, 27 Aug 2013 20:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.613 X-Spam-Level: X-Spam-Status: No, score=-102.613 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 fQVRLppR3qTD for ; Tue, 27 Aug 2013 20:20:25 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3269A11E8121 for ; Tue, 27 Aug 2013 20:20:24 -0700 (PDT) Received: (qmail 30176 invoked from network); 28 Aug 2013 03:20:23 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Aug 2013 03:20:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521d6c77.xn--30v786c.k1308; i=johnl@user.iecc.com; bh=0xur/8SVh4fRos8fFIEmsaEf2XoKbQ6iiaSDE0EQLrw=; b=N63ATIR9NyV2MwMc2m95s5rwxNHt4HKEFfZ5p6GKOytiH0QcgVdrovEtzLOTcOoueN5wAKKN793RFJ9ivb8pjkapS7khiCmcEeJACpPpdiKads/OTgeO8Obh8hgc/iOpWvsxHDsZsMTP5XaFkwipJOr9KLpEb9RlbLhKUs2LZ/6b68FphwIV3eKlE+ctPSrh2+eKt845pMAliJoFza9DcvfHv3ksc+/4MBB1J2MyiYU6yOctX8kAL5YSL51hVyOD DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521d6c77.xn--30v786c.k1308; olt=johnl@user.iecc.com; bh=0xur/8SVh4fRos8fFIEmsaEf2XoKbQ6iiaSDE0EQLrw=; b=gK1cULLwiSjozGqcrdYNG0AEK1SnrF3zK0Q2zA0J94vDfz/X1nDn+/FOTM802viJAgHyX0dc8UT/y38Ogy3Dd/C0yeUKSf/VqfzmOdLK5JX3OyDc+Ih1qcC77ma3F4iZ7CKxbuBpNhmqysPhu8ocx62zKfC+iGruBg6K/wY0ICldsHC3CBgUhhYiQs7Fnt3hmU3tvkGGYF/nwkVKldJo9BAR2tCObtPyKz9+KQpxqiRyPKjg+ogH5YbHVSfcFRYq Date: 28 Aug 2013 03:20:01 -0000 Message-ID: <20130828032001.92562.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20130828004822.0FDEA38EE5DA@drugs.dv.isc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: marka@isc.org Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 28 Aug 2013 03:20:29 -0000 >Actually it is standard but for class B addresses. > > e.g. 130.155.1 > >For class A you have a single period. > > e.g. 127.1 Yes, that was a fairly common syntax for classful network numbers before CIDR was invented. Since the syntax for SPF address ranges has always been CIDR and nothing by CIDR, the history of other ways to write other stuff doesn't seem the least bit useful or relevant. R's, John From marka@isc.org Tue Aug 27 20:28:39 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 F2B9D21E811D for ; Tue, 27 Aug 2013 20:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 HArkg6YyqtW1 for ; Tue, 27 Aug 2013 20:28:34 -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 92D5121E811E for ; Tue, 27 Aug 2013 20:28:34 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 5FCFDC942B; Wed, 28 Aug 2013 03:28:21 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377660514; bh=FyErXf2otCZuTDqqcuJtje+UTg72qsZzF5qxzBIcSGI=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=bO3sM5greLGlMIKg7+Zr79nikqrmUhIxF5BxwiSM69nlM3pil0MM+cFrdjYYNMkCA +/eJw/uZBisWPxN68Rcsb64g9yIjjty2OlHUkMDLUGi/Ubyq1B+cw0jba9ZRsTVDvd E/1ytKyBI646gtwYVwzzKTVqBjffpeBGg8spHOhw= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 28 Aug 2013 03:28:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 55619160446; Wed, 28 Aug 2013 03:29:00 +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 1F1C616043C; Wed, 28 Aug 2013 03:29:00 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2A86138EF509; Wed, 28 Aug 2013 13:28:16 +1000 (EST) To: dcrocker@bbiw.net From: Mark Andrews References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CDC41.7090008@isdg.net> <6.2.5.6.2.20130827140934.0ca33680@elandnews.com> <521D24ED.7090804@isdg.net> <6.2.5.6.2.20130827152917.0ca4c4f8@elandnews.com> <20130828004822.0FDEA38EE5DA@drugs.dv.isc.org> <20130828014533.866DD38EEA3A@drugs.dv.isc.org> <521D6312.8000302@dcrocker.net> <20130828025327.4EB4F38EF22C@drugs.dv.isc.org> <521D6B6E.3000001@dcrocker.net> In-reply-to: Your message of "Tue, 27 Aug 2013 20:15:58 -0700." <521D6B6E.3000001@dcrocker.net> Date: Wed, 28 Aug 2013 13:28:16 +1000 Message-Id: <20130828032816.2A86138EF509@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "spfbis@ietf.org" , Hector Santos , S Moonesamy Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 28 Aug 2013 03:28:39 -0000 In message <521D6B6E.3000001@dcrocker.net>, Dave Crocker writes: > On 8/27/2013 7:53 PM, Mark Andrews wrote: > > I think it should be dotted decimal quad with no leading zeros. > > There exists standard functions that only accept that as input. > > > I think you are confusing a programming convention with a protocol > convention. > > Just to be clear, the current discussion is about the latter. I thought I was being clear. I wanting a extremely tight definition as then it doesn't matter what parsing code is used for valid records as you won't get unintended results. Leading zero's lead to unexpected results some of the time. Additionally if you are trying to reject invalid records there already exists code that can do it. Mark > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sm@elandsys.com Wed Aug 28 01:54: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 AB2EC21F9DCB for ; Wed, 28 Aug 2013 01:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.252 X-Spam-Level: X-Spam-Status: No, score=-102.252 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, J_CHICKENPOX_71=0.6, 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 pSv5lo0+NhX1 for ; Wed, 28 Aug 2013 01:54:37 -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 1206E21F9D98 for ; Wed, 28 Aug 2013 01:54:36 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.239]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7S8sMNT000936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Aug 2013 01:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377680075; bh=bGcpt0v+XwDV/Odvl/SQIf9m/d6mxTJCftTYEqPp2UE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=w6oyAwgdgewZsJOnodpyjl/JOUp+GsAQjNKmTVwpDxqm1OHnjaiMTCXsjbEEnGna0 FlKELqv+HzAsMZ36XquuPbPag+jVZyO1Wk2MaVOF86vBJ28cOHKHlNMGbo3Q2jvFKK 1DxdPjKZUlgg3dqMbV2+KcvSbRDFo2DIXcyBgI/Q= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377680075; i=@elandsys.com; bh=bGcpt0v+XwDV/Odvl/SQIf9m/d6mxTJCftTYEqPp2UE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3gsu2trJRrmgPuUz44jcTYtBgesN/iyE2ZnMWfGNYU66nz8JxXyTXWhjKAmKKe2/l t2qsubDMBfKKzwA74Tu8wN+WiWueVkFUC/+9vncl1zIgrPd7b+TEAz8/gFscRwX0jt oOqWpefaQmlvtgiRPBqZxyptoB+V8/aK+nVMj/NQ= Message-Id: <6.2.5.6.2.20130828013935.0cb0c5f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 28 Aug 2013 01:44:37 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <196681373.R9HtK96ds2@scott-latitude-e6320> References: <520BE458.3060807@qti.qualcomm.com> <2740178.6b98xEoijR@scott-latitude-e6320> <520F76B6.1030106@qti.qualcomm.com> <196681373.R9HtK96ds2@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Pete Resnick , Hector Santos Subject: Re: [spfbis] AD Review of 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: Wed, 28 Aug 2013 08:54:37 -0000 Hi Scott, At 06:48 17-08-2013, Scott Kitterman wrote: >I think I'd prefer to leave it. I can see how it's not 100% clear, but I >think it's reasonably so from context. I'm afraid if I change it now, I'll >worsen it. Anyone else have an opinion? I don't feel strongly about it. Ok. >I'm going to leave it as is unless someone else suggests I should do >otherwise. Ok. >I've also gone ahead and applied Hector's typo fixes. > >I've attached an rfcdiff from the published -18 to my local copy of the to be >-19 so we can ensure we're on the same page before I upload it. Let me know >if I got it right. Ok. As an overall comment,l I'll leave the above open for one more day. If nobody expresses an opinion I suggest choosing what seems reasonable to you. Regards, S. Moonesamy (as document shepherd) From angel@16bits.net Wed Aug 28 03:31:45 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 848B911E817B for ; Wed, 28 Aug 2013 03:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 7xG0k5NX8OQ0 for ; Wed, 28 Aug 2013 03:31:40 -0700 (PDT) Received: from mailer.hiddenmail.net (mailer.hiddenmail.net [199.195.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 813A111E816F for ; Wed, 28 Aug 2013 03:31:40 -0700 (PDT) Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from ) id 1VEd28-00010z-Gm; Wed, 28 Aug 2013 12:31:33 +0200 Message-ID: <1377686230.1044.3.camel@localhost.localdomain> From: =?ISO-8859-1?Q?=C1ngel?= To: spfbis@ietf.org Date: Wed, 28 Aug 2013 12:37:10 +0200 In-Reply-To: <20130826231200.82891.qmail@joyce.lan> References: <20130826231200.82891.qmail@joyce.lan> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.8.5 Mime-Version: 1.0 Cc: superuser@gmail.com Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 28 Aug 2013 10:31:45 -0000 John Levine wrote: > >> At 14:31 26-08-2013, ngel wrote: > >> >I think the right way would be to use this grammar: > >> > ip4-cidr-length =3D "/" 1*2DIGIT / obs-cidr-length ; value range= 0-32 > >> > ip6-cidr-length =3D "/" 1*3DIGIT / obs-cidr-length ; value range= 0-128 > >> > obs-cidr-length =3D "/" 1*DIGIT > >> > > >> >and declare in the text that the cidr length MUST not be written with > >> >leading digits, obsoleting the 4408 syntax which allowed them. >=20 > This seems unduly messy. >=20 > Now that I've lookeed at Mail::SPF and pyspf, I see that leading zeros > have never worked. The obs- stuff means that new code has to support > leading zeros for backward compatibility, which just seems wrong. The rfc could state that the parsers may accept the obs- tokens but are not required to. And as it would state that new records MUST NOT use it... Murray, can you check the SPF records surveyed for cidr-lengths with leading zeroes? I suspect we may be discussing how not to break use of a feature that nobody is using (in addition of not working on all spf implementations). From hsantos@isdg.net Wed Aug 28 07:24:55 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 E07E521F9F8E for ; Wed, 28 Aug 2013 07:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 uVp-p5jwcDzV for ; Wed, 28 Aug 2013 07:24:49 -0700 (PDT) Received: from groups.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 638AC21F9FDA for ; Wed, 28 Aug 2013 07:24:49 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4392; t=1377699880; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=oUngvXCyqpAadFYrJBRdrmsSg/I=; b=WSeNWfh5q3aKzrrbUJ8I ZjXsdQJfHnA9246XjFhKpO4xkSJhiTGq4TcIfXokm/MKjzWcfFMgSiUTxXSxhJjM dDah+y70JsL+k5ZZz3VrPizVckcvlUxgyhTcENvSeIbf5K3bCRRwAeimivgVI+eV ColwdPAlMHJFskD+EgefrN4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 28 Aug 2013 10:24:40 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4162389147.10011.4408; Wed, 28 Aug 2013 10:24:39 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4392; t=1377699557; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=92r5Tbm wfdnHsELV3zY889CV0VNYBl3iTCu5BpV+fQY=; b=ncy+OyYN7lPRmdGF+Ud9Tqa Y/q2A05jqP3K2aWE3K9l5auJskKRfvIGa0XEFFq1y2cXZ8Lx3mWhODDOWAnI9DAb s7PGmWkqf3WKVknDxLMe7g84tvdOmrdXCmGvFYbMg9e8k37a8xBL3EWKYyrTo7wo v3GbqSai9TN0zBD94iuw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 28 Aug 2013 10:19:17 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3608805705.9.6064; Wed, 28 Aug 2013 10:19:16 -0400 Message-ID: <521E081F.3020101@isdg.net> Date: Wed, 28 Aug 2013 10:24:31 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tony Hansen References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CE240.60407@att.com> In-Reply-To: <521CE240.60407@att.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, S Moonesamy Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 28 Aug 2013 14:24:55 -0000 On 8/27/2013 1:30 PM, Tony Hansen wrote: >> To simplify the above and to further codify existing parsers in the >> wild, may I suggest the ABNF be: >> >> ip4-cidr-length = "/" [ ip4-cidr-value ] >> ip6-cidr-length = "/" [ ip6-cidr-value ] >> ip4-cidr-value = 2*DIGIT ; value range 0-32 >> ip6-cidr-value = 3*DIGIT ; value range 0-128 >> >> This allows for the possible omission of the alphanumeric after the >> slash. Both RFC4408 & 4408BIS says: >> >> If ip4-cidr-length is omitted, it is taken to be "/32". If >> ip6-cidr-length is omitted, it is taken to be "/128". It is not >> permitted to omit parts of the IP address instead of using CIDR >> notations. That is, use 192.0.2.0/24 instead of 192.0.2. >> >> What it doesn't say is when the cidr-length is just "/". My >> suggestion will also codify existing spf processing code where it >> handles SPF mechanism examples such as: > > A cidr-length of just "/" is not permitted by the 4408 ABNF. Any parsers > that follow the 4408 ABNF will reject the bare "/". > > Are you saying that there are parsers in the wild that accept already > accept a bare "/", or that there are sites that are using a bare "/" ? The parsing I am sure came from the sites that were found to have it in the field and done long ago. Perhaps reported by customers and relaxed for future updates to help minimize and preempt such customer interop reports. There is 10 years of wide deployment history here and RFC6686 with its helpful 180,000+ records is not the definitive all encompassing sample of complete learned SPF history here. Too much leaning on the larger systems when the majority are the small to mid systems that may not fully represented in the group. Not every site gets the same type of domains connecting to them. That is not suggesting all systems are not considered or not represented widely, but we have some additional exceptions to consider just as the leading zero ("/0x") behavior with one package was corrected with the ABNF. Tony, just like with SMTP, we had the similar ABNF versus deployment issue with accepting the "MAIL FROM: " syntax (space after the colon is invalid). Hopefully you recall this specific 2821BIS discussion. We added the implementation notes and a reminder that the space is invalid. However, the note indirectly gives insight to all SMTP developers that a SPACE is possible in the field and every system is very likely to come across it. Its better for developers to know this upfront rather than learn the hard way. By far, the major majority of SMTP receivers, if not all, tolerant the space. I suppose local policy offer STRICT5321 options like ours which is off by default (no surprise principle). This is the text added for RFC5321: New text from 2821BIS discussions added to RFC5321: Since it has been a common source of errors, it is worth noting that spaces are not permitted on either side of the colon following FROM in the MAIL command or TO in the RCPT command. The syntax is exactly as given above. All SMTP developers remember this issue with the Outlook client. It doesn't pay to be strict and reject this "MAIL FROM: " command for syntax reasons. What I am suggesting that we relax the ABNF (with an obs- token) and add the similar semantics and language to 4408BIS regarding "/" and also "/0" which is ABNF/CIDR valid but the popular LIBSPF2 will reject it (due to cidr=0). Angel had a good idea to use obs- tokens. Perhaps 4408BIS can document the token "/" as obsolete and state parsers MAY accept the obs- token but are not required to with a cidr value of zero. It will also state the publisher MUST be compliant with standardized CIDR notations. I suggest the following: obs-ip4-cidr-length = "/" [ip4-cidr-value] obs-ip6-cidr-length = "/" [ip6-cidr-value] ip4-cidr-length = "/" ip4-cidr-value ip6-cidr-length = "/" ip6-cidr-value ip4-cidr-value = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 ip6-cidr-value = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 and with some draft text added: It is noted some implementations issue an perm error when cidr-length is "/0" and some implementations tolerant cidr-length "/" with a cidr-value of "0". It is not permitted to have a "/" for the cidr-length. The syntax is exactly as given above. Thanks -- HLS From spf2@kitterman.com Wed Aug 28 07:36: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 912C111E81AB for ; Wed, 28 Aug 2013 07:36: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=[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 akKcErYXmtul for ; Wed, 28 Aug 2013 07:36:11 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5300E11E81A1 for ; Wed, 28 Aug 2013 07:36:11 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 71EF920E410F; Wed, 28 Aug 2013 10:35:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377700569; bh=QtNMmPMy01kCiBqG3BeDy7DH/ilrD+1kAyfeWStx+So=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LREDqRAiOQnN3aoSVEGYhBBwSNcAFKJlNI83tq+ba3eIA6K8DU5lZJooNnopaOfD1 muBytJ1U8teMRBPx/Fmefql37pb/R3JpN3+8B1sAADqfo7sJL7F92srKlztAxuWNhM G6KSYoCzj4kZ/eaYTjmw7D5i5+48IM8cuqlSLPT0= 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 559B220E40CB; Wed, 28 Aug 2013 10:35:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 28 Aug 2013 10:35:56 -0400 Message-ID: <1552915.aJAV4gMSz7@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <521E081F.3020101@isdg.net> References: <20130827012600.83309.qmail@joyce.lan> <521CE240.60407@att.com> <521E081F.3020101@isdg.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] Applications Directorate Review: ABNF 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, 28 Aug 2013 14:36:16 -0000 On Wednesday, August 28, 2013 10:24:31 Hector Santos wrote: > On 8/27/2013 1:30 PM, Tony Hansen wrote: > >> To simplify the above and to further codify existing parsers in the > >> > >> wild, may I suggest the ABNF be: > >> ip4-cidr-length = "/" [ ip4-cidr-value ] > >> ip6-cidr-length = "/" [ ip6-cidr-value ] > >> ip4-cidr-value = 2*DIGIT ; value range 0-32 > >> ip6-cidr-value = 3*DIGIT ; value range 0-128 > >> > >> This allows for the possible omission of the alphanumeric after the > >> > >> slash. Both RFC4408 & 4408BIS says: > >> If ip4-cidr-length is omitted, it is taken to be "/32". If > >> ip6-cidr-length is omitted, it is taken to be "/128". It is not > >> permitted to omit parts of the IP address instead of using CIDR > >> notations. That is, use 192.0.2.0/24 instead of 192.0.2. > >> > >> What it doesn't say is when the cidr-length is just "/". My > >> suggestion will also codify existing spf processing code where it > > > >> handles SPF mechanism examples such as: > > A cidr-length of just "/" is not permitted by the 4408 ABNF. Any parsers > > that follow the 4408 ABNF will reject the bare "/". > > > > Are you saying that there are parsers in the wild that accept already > > accept a bare "/", or that there are sites that are using a bare "/" ? > > The parsing I am sure came from the sites that were found to have it > in the field and done long ago. Perhaps reported by customers and > relaxed for future updates to help minimize and preempt such customer > interop reports. There is 10 years of wide deployment history here and > RFC6686 with its helpful 180,000+ records is not the definitive all > encompassing sample of complete learned SPF history here. Too much > leaning on the larger systems when the majority are the small to mid > systems that may not fully represented in the group. Not every site > gets the same type of domains connecting to them. That is not > suggesting all systems are not considered or not represented widely, > but we have some additional exceptions to consider just as the leading > zero ("/0x") behavior with one package was corrected with the ABNF. > > Tony, just like with SMTP, we had the similar ABNF versus deployment > issue with accepting the "MAIL FROM: " syntax (space after the > colon is invalid). Hopefully you recall this specific 2821BIS > discussion. We added the implementation notes and a reminder that the > space is invalid. However, the note indirectly gives insight to all > SMTP developers that a SPACE is possible in the field and every system > is very likely to come across it. Its better for developers to know > this upfront rather than learn the hard way. By far, the major > majority of SMTP receivers, if not all, tolerant the space. I suppose > local policy offer STRICT5321 options like ours which is off by > default (no surprise principle). This is the text added for RFC5321: > > New text from 2821BIS discussions added to RFC5321: > > Since it has been a common source of errors, it is worth noting that > spaces are not permitted on either side of the colon following FROM > in the MAIL command or TO in the RCPT command. The syntax is exactly > as given above. > > All SMTP developers remember this issue with the Outlook client. It > doesn't pay to be strict and reject this "MAIL FROM: " command > for syntax reasons. > > What I am suggesting that we relax the ABNF (with an obs- token) and > add the similar semantics and language to 4408BIS regarding "/" and > also "/0" which is ABNF/CIDR valid but the popular LIBSPF2 will reject > it (due to cidr=0). > > Angel had a good idea to use obs- tokens. Perhaps 4408BIS can document > the token "/" as obsolete and state parsers MAY accept the obs- token > but are not required to with a cidr value of zero. It will also state > the publisher MUST be compliant with standardized CIDR notations. > > I suggest the following: > > obs-ip4-cidr-length = "/" [ip4-cidr-value] > obs-ip6-cidr-length = "/" [ip6-cidr-value] > ip4-cidr-length = "/" ip4-cidr-value > ip6-cidr-length = "/" ip6-cidr-value > ip4-cidr-value = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 > ip6-cidr-value = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 > > and with some draft text added: > > It is noted some implementations issue an perm error when cidr-length > is "/0" and some implementations tolerant cidr-length "/" with a > cidr-value of "0". It is not permitted to have a "/" for the > cidr-length. The syntax is exactly as given above. No. Once you add the obs-* elements they are mandatory to support. We shouldn't do that. If some verifiers are slightly less tight than the ABNF, it's not an issue. Imposing non-standard CIDR syntax is an issue. I'm currently using the standard python ipaddress module for all this processing and I'm certainly not go to replace standard library code for a custom implementation to accommodate something like "/". Scott K From hsantos@isdg.net Wed Aug 28 07:49:46 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 AC26C21F847C for ; Wed, 28 Aug 2013 07:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 fOjDAUy9H0lx for ; Wed, 28 Aug 2013 07:49:41 -0700 (PDT) Received: from groups.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6447D21F8475 for ; Wed, 28 Aug 2013 07:49:09 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2789; t=1377701340; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=O9KY1xhnDloqOu9hGyOY6JINURs=; b=N5PS2CPnPaJTOUse/Ynt Tv6nkxIKkCCYxb8/0FdpZ9t5jN7L2qkDWjZYf2ddvRGipq0y4vHMXEisX5gKbRMB 7JIKMO60Z41sDqlQIRYJmRDa48uZO+00elAKl+E0sEWNzR1oav+L4HEzkZjhyrl3 d5/k1zvYRUK2qtzpAnoA1z4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 28 Aug 2013 10:49:00 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4163849488.10011.5796; Wed, 28 Aug 2013 10:48:59 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2789; t=1377701015; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=bScRAqV 1iaR0zBjYoyAX28SnwcjVO3R4BJUM7LeJ2mU=; b=oUcbEHKxLcPKjr36viEv1UE 4dmIeKJmVQ7LXls9Yr3yCv7lpU78RrGDf4yVIQcxWLJFLvQRvN4Ke8jPoX5SzddZ wHuCV3MFhMHCTalLxdS7rKFzdx08jmmNGojboqHJhU52w9H6szCbCfLnw/mnC+zI C3UztfNhLPIQ0KwytYAE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 28 Aug 2013 10:43:35 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3610263002.9.920; Wed, 28 Aug 2013 10:43:34 -0400 Message-ID: <521E0DD1.30508@isdg.net> Date: Wed, 28 Aug 2013 10:48:49 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130827012600.83309.qmail@joyce.lan> <521C0F32.1050107@att.com> <521CD259.7010800@isdg.net> <521CDC41.7090008@isdg.net> <6.2.5.6.2.20130827140934.0ca33680@elandnews.com> <521D24ED.7090804@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 28 Aug 2013 14:49:46 -0000 On 8/27/2013 8:30 PM, Murray S. Kucherawy wrote: > On Tue, Aug 27, 2013 at 4:02 PM, Scott Kitterman wrote: > >> We shouldn't write standards around implementation errors. >> >> > +1. There's a bug in the code, not a bug in the specification. Let's fix > the right thing, please. > > "/0" is not wrong according to RFC4632. "/" is. So yes, if libspf2 (or > anything) accepts "/" with no digits after it, then it needs to be fixed. Murray, we are talking about humans vs software. While RFC6686 may not have recorded the use case scenario, there is a rich 10 year history among many implementations. So we very keen this report did an good job, but must be open to the idea it didn't cover everything. It only takes one case, one customer complaint, report, etc and its determined it is better to be relaxed than to be strict. I'm suggesting 4408BIS document this field implementation note. See my last post tony with some ideas where I am proposing similar action done to RFC5321 in regards to the invalid syntax of using an space after the "MAIL FROM:" or "RCPT TO:" commands. > Of 180,000+ records found during the RFC6686 surveys, not one contained any > portion of a "v=spf1" record (TXT or 99) that included "/" followed by > something other than a digit, or "/" at the end of the record. The > likelihood that someone out there is relying on the existence of this bug > in implementations seems to be, at best, vanishingly small. The sample didn't cover every SPF scenario. I agree, it would be rare but thats the whole idea of long time engineering refinements - it covers and/or considers those rare situations. Sometimes it only takes one report case to take action in business. The automated parser needs to be robust, yet tolerant. Generally, in general, a 100% strict parser will not be very strict for long. > Thus, the fact that this bug has been in some implementations all > along is not a good argument for augmenting the standard. Augmentation for this case is not the suggestion. Codifying, adding implementation notes and a reminder what is the expected syntax for both the publisher and parser is what I am suggesting. > Finally, I take the libspf2 page to mean the add-on modules that use it are > affected by this bug, but not that the MTAs themselves are impacted, > because they don't use it directly. Sure. Good point. Lets keep in mind libspf2 was one of the original open source C SPF packages and also very likely used to get a proof of concept, exploration into SPF and to also port the logic to another package, other languages and scripting tools, etc. So chances are good, while many don't directly use it, translated SPF knowledge and logic was carried over. -- HLS From spf2@kitterman.com Wed Aug 28 08:20:00 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 DA17221F9ECA for ; Wed, 28 Aug 2013 08:20:00 -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 2sWlhF9uZGLB for ; Wed, 28 Aug 2013 08:19:55 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C1C6421F9D38 for ; Wed, 28 Aug 2013 08:19:55 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 20E7820E410F; Wed, 28 Aug 2013 11:19:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377703195; bh=qcrIMePRq9QJ1XkKSB4Pubxa1qJyJL42b2PoD/w9d34=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Vl/TjMg///eJ5QCtT9duqS1BEEt6jBC5VYvzYElZI6ZsCz+u8IikwMrnUc+dv9QNd Lce67053tmBZYjJMqhgpkjXM2yR6lKTP0x7+MFFYRqlI20Q3BPO5HSmeiZoVFg/zf9 rcC7RPIp7APmZhcbHbT96xch0zk9TInQUGgB/QCI= 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 0659F20E40CB; Wed, 28 Aug 2013 11:19:54 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 28 Aug 2013 11:19:54 -0400 Message-ID: <23354097.Hv5sIPIv5A@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <521E0DD1.30508@isdg.net> References: <20130827012600.83309.qmail@joyce.lan> <521E0DD1.30508@isdg.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] Applications Directorate Review: ABNF 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, 28 Aug 2013 15:20:01 -0000 On Wednesday, August 28, 2013 10:48:49 Hector Santos wrote: > Lets keep in mind libspf2 was one of the original open source C SPF > packages and also very likely used to get a proof of concept, > exploration into SPF and to also port the logic to another package, > other languages and scripting tools, etc. So chances are good, while > many don't directly use it, translated SPF knowledge and logic was > carried over. Just as a historical note: The original reference implementation was in Perl, Mail::SPF::Query. In C, libspf (a completely different code base than libspf2) was first. Neither of these are in wide use anymore. They were replaced by Mail::SPF and libspf2 respectively. The area where libspf2 was important for protocol development was processing limits. The current concept of a DNS lookup based set of limits was first implemented in libspf2 and then standardized in RFC 4408. These limits replaced an earlier concept of recursion depth limits that was not very effective. >From a lineage perspective, the Python library, pyspf, derived it's design from Mail::SPF::Query, but was then updated for RFC 4408 support in a way that wasn't feasible in the Mail::SPF::Query code base (which is why Mail::SPF exists). Scott k From hsantos@isdg.net Wed Aug 28 08:59:45 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 47A2221F9BF7 for ; Wed, 28 Aug 2013 08:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.026 X-Spam-Level: X-Spam-Status: No, score=-102.026 tagged_above=-999 required=5 tests=[AWL=-0.291, 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 rnvMk-1EIY0m for ; Wed, 28 Aug 2013 08:59:39 -0700 (PDT) Received: from pop3.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7886621F86B1 for ; Wed, 28 Aug 2013 08:59:24 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2162; t=1377705546; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=SLurAVF1nLpA0I2nnF/aP6dKXSY=; b=dTnDXIad0WZjgJQDc2WY gwI2lZ5UsJNRMd7W1w5Twf4XKijas+Gew0WIcOUizeFW5RRCbd4kDtRkKq6Jwvtw oo1OcGGSdraTgwWL5LjwlKi60IRF2yA95DrMYg0uBNVNZ/rxrU0mLkNZxglIs0Nm RBW4szuEc9M5AFBiSd1BBfo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 28 Aug 2013 11:59:06 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4168054620.10011.2880; Wed, 28 Aug 2013 11:59:05 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2162; t=1377705222; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=AAvJOTf 7wy3HeBt03gV6IUdLFaVsqQBHoUSxbl4zBgM=; b=YSSbHEKTFP3mCQNPTOR9qn0 C9CAHJPpsE7UQBHofZH1BxD2VCsppZ6pLwgaPG800HUbB7sP2Nahf6MSnAKDM3Ah 0XPrhED5ipcfkmknNrP6CJePeaIOi54TGNsa3Ez53U4TLHt+iXOGtmgua16Z8RN+ Ukqu8M6B26VeOVXpK5Jk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 28 Aug 2013 11:53:42 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3614470612.9.6856; Wed, 28 Aug 2013 11:53:41 -0400 Message-ID: <521E1E40.1060505@isdg.net> Date: Wed, 28 Aug 2013 11:58:56 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 References: <20130827012600.83309.qmail@joyce.lan> <521CE240.60407@att.com> <521E081F.3020101@isdg.net> <1552915.aJAV4gMSz7@scott-latitude-e6320> In-Reply-To: <1552915.aJAV4gMSz7@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Cc: spfbis@ietf.org, S Moonesamy Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 28 Aug 2013 15:59:45 -0000 On 8/28/2013 10:35 AM, Scott Kitterman wrote: > On Wednesday, August 28, 2013 10:24:31 Hector Santos wrote: >> I suggest the following: >> >> obs-ip4-cidr-length = "/" [ip4-cidr-value] >> obs-ip6-cidr-length = "/" [ip6-cidr-value] >> ip4-cidr-length = "/" ip4-cidr-value >> ip6-cidr-length = "/" ip6-cidr-value >> ip4-cidr-value = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 >> ip6-cidr-value = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 >> >> and with some draft text added: >> >> It is noted some implementations issue an perm error when cidr-length >> is "/0" and some implementations tolerant cidr-length "/" with a >> cidr-value of "0". It is not permitted to have a "/" for the >> cidr-length. The syntax is exactly as given above. > > No. Once you add the obs-* elements they are mandatory to support. We > shouldn't do that. If some verifiers are slightly less tight than the ABNF, > it's not an issue. BIS specs are better when they tell the future reader about learned experiences and the potential market place interfacing issues. A similar consideration was done for RFC5321 in regards to the space after "MAIL FROM:". The ABNF was not refined to support it, but it functionally described the protocol design issue. It made you aware of the potential. >Imposing non-standard CIDR syntax is an issue. 4408BIS still enforces a strict spec, but it has to also make note of the possible implementations which do exist. > I'm > currently using the standard python ipaddress module for all this processing > and I'm certainly not go to replace standard library code for a custom > implementation to accommodate something like "/". But speaking in general, with improved functional specifications, one may decide to add a SPFSTRICT_INVALID_CIDR_SLASH option to offer strict versus relaxed operations. Of course, not every implementator uses 3rd party software. Not every site is a *nix operation. There are proprietary, in-house, commercial systems out there that don't use any of these 3rd party open source tools you mention and for many cases, just for legal reasons. Thanks -- HLS From spf2@kitterman.com Wed Aug 28 09:02:42 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 4B7AC11E81DB for ; Wed, 28 Aug 2013 09:02:42 -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 2MQ8jqiQH7lO for ; Wed, 28 Aug 2013 09:02:35 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDC611E81F3 for ; Wed, 28 Aug 2013 09:02:31 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8966A20E410F; Wed, 28 Aug 2013 12:02:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377705750; bh=gHO0xcnGFEWD+KFRboCVT3gLsUpRMj2FjF6SD+oHtOA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=L5Di0ge/OEfpaTAU7oHKa5gH4qYnWHkH7pL2ljGQ6Q5VfDpfHMEfaqftWEW1kRaRA 7FvH/wEEBFTfixxjYrmX4pxVWUIzZ58O3+f5xOilXNgkFrmUgr5OEFDnVJ3qW3bKdP qKlZAB4sWEdQFd8uzP/YQ+26zdPI9sV+6toucq6U= 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 6BAB120E40CB; Wed, 28 Aug 2013 12:02:30 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 28 Aug 2013 12:02:29 -0400 Message-ID: <3619221.jr7HmlbTDF@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <521E1E40.1060505@isdg.net> References: <20130827012600.83309.qmail@joyce.lan> <1552915.aJAV4gMSz7@scott-latitude-e6320> <521E1E40.1060505@isdg.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] Applications Directorate Review: ABNF 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, 28 Aug 2013 16:02:42 -0000 On Wednesday, August 28, 2013 11:58:56 Hector Santos wrote: > On 8/28/2013 10:35 AM, Scott Kitterman wrote: > > On Wednesday, August 28, 2013 10:24:31 Hector Santos wrote: > >> I suggest the following: > >> obs-ip4-cidr-length = "/" [ip4-cidr-value] > >> obs-ip6-cidr-length = "/" [ip6-cidr-value] > >> ip4-cidr-length = "/" ip4-cidr-value > >> ip6-cidr-length = "/" ip6-cidr-value > >> ip4-cidr-value = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 > >> ip6-cidr-value = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 > >> > >> and with some draft text added: > >> It is noted some implementations issue an perm error when cidr-length > >> is "/0" and some implementations tolerant cidr-length "/" with a > >> cidr-value of "0". It is not permitted to have a "/" for the > >> cidr-length. The syntax is exactly as given above. > > > > No. Once you add the obs-* elements they are mandatory to support. We > > shouldn't do that. If some verifiers are slightly less tight than the > > ABNF, it's not an issue. > > BIS specs are better when they tell the future reader about learned > experiences and the potential market place interfacing issues. A > similar consideration was done for RFC5321 in regards to the space > after "MAIL FROM:". The ABNF was not refined to support it, but it > functionally described the protocol design issue. It made you aware of > the potential. > > >Imposing non-standard CIDR syntax is an issue. > > 4408BIS still enforces a strict spec, but it has to also make note of > the possible implementations which do exist. > > > I'm > > currently using the standard python ipaddress module for all this > > processing and I'm certainly not go to replace standard library code for > > a custom implementation to accommodate something like "/". > > But speaking in general, with improved functional specifications, one > may decide to add a SPFSTRICT_INVALID_CIDR_SLASH option to offer > strict versus relaxed operations. > > Of course, not every implementator uses 3rd party software. Not every > site is a *nix operation. There are proprietary, in-house, commercial > systems out there that don't use any of these 3rd party open source > tools you mention and for many cases, just for legal reasons. I'm not objecting to the note, or something like it. I don't think it's necessary, but I don't find it problematic. I do object to adding anything to the ABNF that requires accepting non-standard CIDR, which this proposal does. Scott K From superuser@gmail.com Wed Aug 28 09:44:47 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 0A6CC11E81F7 for ; Wed, 28 Aug 2013 09:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 5xajS-ghrZ1E for ; Wed, 28 Aug 2013 09:44:45 -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 A81A721F9A3B for ; Wed, 28 Aug 2013 09:44:44 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hi5so1531264wib.4 for ; Wed, 28 Aug 2013 09:44:43 -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=1IDfZ2Ldc3xHWz5TfslI72Z047LQW0wIMFRdPQxHtg4=; b=cWTbv2FtCREdivAS/0RToov9kVZODEt8H3WZFFu1I8VCmkAhQG2/WR/sGe0CwGxo9x AG/D4KVcEka1b5Iv945MrBZABH7m4kwWN5gzyojnXnANN20XuKtQ0hb0kZ0E7QdKIyEX fnboYo0lgab5TLntIhB5WU7hnc1v0+NjxDafmpG0iFo+4rEc4XcMIsHtUbGBSpdX6n5R JewKo2K1hBVJSuMMjc0xoBASy4cfETBKfZbHZ4R83RkO1ghHxWbaP2ZbIfzTGlf2ST8j sor84k2JOKgqkec+Y5QmbmaF1YN8mLqGxWP4iOWOyRHYPV7O+dO6FMn30rsfMVYIWt/R IFlw== MIME-Version: 1.0 X-Received: by 10.194.205.164 with SMTP id lh4mr4288103wjc.46.1377708283833; Wed, 28 Aug 2013 09:44:43 -0700 (PDT) Received: by 10.180.75.144 with HTTP; Wed, 28 Aug 2013 09:44:43 -0700 (PDT) In-Reply-To: <3619221.jr7HmlbTDF@scott-latitude-e6320> References: <20130827012600.83309.qmail@joyce.lan> <1552915.aJAV4gMSz7@scott-latitude-e6320> <521E1E40.1060505@isdg.net> <3619221.jr7HmlbTDF@scott-latitude-e6320> Date: Wed, 28 Aug 2013 09:44:43 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bae4738dcb36e04e504b4ab Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 28 Aug 2013 16:44:47 -0000 --047d7bae4738dcb36e04e504b4ab Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 28, 2013 at 9:02 AM, Scott Kitterman wrote: > I'm not objecting to the note, or something like it. I don't think it's > necessary, but I don't find it problematic. I do object to adding > anything to > the ABNF that requires accepting non-standard CIDR, which this proposal > does. > > I object even to the note. I don't see the benefit in documenting a (potentially large) list of ways various pre-bis implementations did things incorrectly in the first place unless it's clear that their use became common. There's no evidence to support that. The argument that this is just like the MAIL FROM debate in RFC2821 doesn't work for me, because that form was contained completely within SMTP. CIDR format pre-dates SPF and has numerous other applications. If instead it's the case that lots of CIDR parsers got this wrong, then that's possibly interesting, but RFC4408bis is the wrong place to say so. -MSK --047d7bae4738dcb36e04e504b4ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 28, 2013 at 9:02 AM, Scott Kitterman <spf2@k= itterman.com> wrote:
I'm not objecting to the note, or someth= ing like it. =A0I don't think it's
necessary, but I don't find it problematic. =A0I do object to adding an= ything to
the ABNF that requires accepting non-standard CIDR, which this proposal doe= s.


I object even to the note.=A0 I don= 9;t see the benefit in documenting a (potentially large) list of ways vario= us pre-bis implementations did things incorrectly in the first place unless= it's clear that their use became common.=A0 There's no evidence to= support that.

The argument that this is just like the MAIL FROM debate in = RFC2821 doesn't work for me, because that form was contained completely= within SMTP.=A0 CIDR format pre-dates SPF and has numerous other applicati= ons.=A0 If instead it's the case that lots of CIDR parsers got this wro= ng, then that's possibly interesting, but RFC4408bis is the wrong place= to say so.

-MSK
--047d7bae4738dcb36e04e504b4ab-- From hsantos@isdg.net Wed Aug 28 10:17: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 9615321F9C54 for ; Wed, 28 Aug 2013 10:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.015 X-Spam-Level: X-Spam-Status: No, score=-102.015 tagged_above=-999 required=5 tests=[AWL=-0.280, 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 l6Q-wKYN5Tfv for ; Wed, 28 Aug 2013 10:17:02 -0700 (PDT) Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CC1E021F9AA8 for ; Wed, 28 Aug 2013 10:17:00 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1239; t=1377710211; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=xQHjzLEEBQ7pziXRmvFmF6JrSkU=; b=CMV5HkBLMHNHFGB7aLHZ slpoJ4OoZOsCLaCqBzFljpJS9FiAk1Zq9syEmku0F4iU+bJYpuFQPuzb+s1cp30J 6cmfRcnYT36W4BUE4kREQf3j8ta861s1J/IaIiPP0TYinYeMdO4XXSTtKX9LXLlR qef5cyv5vNUwocc4jh7zuGI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 28 Aug 2013 13:16:51 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4172719845.10011.5444; Wed, 28 Aug 2013 13:16:50 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1239; t=1377709887; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=okFcupK ToFoekfjSiScQkNM0teHKBqlzljKmLe7IhE8=; b=vlX9KANDyZEebOBkJx31p57 sAB7hPbQu9O6+fR9RU1Ch7JR26+KghqCIGI8Bv5kI7nTsDdcU1hbV4UOaTrAdpu0 Szy9q624lZYOfkxBPP7eOfVafOO2Het0RFVxVklq0QZ0+htxlgbDLGKKG1IxPx6M +7VGx9awYc+gp0z9jBww= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 28 Aug 2013 13:11:27 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3619136283.9.3216; Wed, 28 Aug 2013 13:11:27 -0400 Message-ID: <521E307A.1010505@isdg.net> Date: Wed, 28 Aug 2013 13:16:42 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Scott Kitterman References: <20130827012600.83309.qmail@joyce.lan> <1552915.aJAV4gMSz7@scott-latitude-e6320> <521E1E40.1060505@isdg.net> <3619221.jr7HmlbTDF@scott-latitude-e6320> In-Reply-To: <3619221.jr7HmlbTDF@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 28 Aug 2013 17:17:07 -0000 On 8/28/2013 12:02 PM, Scott Kitterman wrote: > > I'm not objecting to the note, or something like it. I don't think it's > necessary, but I don't find it problematic. I do object to adding anything to > the ABNF that requires accepting non-standard CIDR, which this proposal does. Overall I agree, but for the record... Where is that its documented that leading zero padding support is accepted standard CIDR notation for a SOFTWARE PARSER? In other words, parsers MUST support this syntax. As I see it, it was changed here to better support a package that bugged out on the leading zero. Using your position, why bother? One may consider it common sense and only that is needed is the simpler notation: ip4-cidr-length: "/" 1*2DIGIT; range 0-32 ip6-cidr-length: "/" 1*3DIGIT; range 0-128 By changing it, you are telling PARSERS not to barf out on a leading zero token which I agree with. So an immediate fix to the broken parser is done with new ABNF. But where is the empirical SPF record history that shows publishers are using leading zeros? I don't recall any more self. I agree with it in principle, but a description would resolved it. IMO, we need to be more consistent. Thanks -- HLS From hsantos@isdg.net Wed Aug 28 11:48: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 54E1D21E8055 for ; Wed, 28 Aug 2013 11:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 ID27B7K+Utkj for ; Wed, 28 Aug 2013 11:48:31 -0700 (PDT) Received: from ftp.catinthebox.net (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E723E21E8054 for ; Wed, 28 Aug 2013 11:48:30 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=468; t=1377715706; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=H2uN6I/raA90M/4qIGdYYkY3VSA=; b=IfubS8g57mb2U+/+S683 nzLbl3JbvIvxaPiqaM/V3c+1RqaTjALXGcJ9fT9nmkx7nnwbKzl33o3KwFkO3aoD y7fek9GjRGMeeQCtyO27h9MCwHfb1kdfTkeyqYZ5YyEZGYtRE5xokdnZzQ7HyT6W flyKUZaLuASMSQVxQStVk4o= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 28 Aug 2013 14:48:26 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4178215012.10011.6052; Wed, 28 Aug 2013 14:48:25 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=468; t=1377715385; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=mdpPygS uyRw6cg8fhLwredsgd4VIbABaiIiUePze17w=; b=y8KEhQgAUNLc/+Wf4GQ3tiT uATzf+qyuc4hu50ljTAW88AgWTdYNWjfOsdoYmMusLUvHfVIKRffZ0WvuZeBYZOv +VjlL4bXm5ZnVjDVQwR8rmAskg3yJjdQqAV3fyNzCKxydJaozs7Amjt66BQI95nE 5RJdjhg09dX5eQwQyNdI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 28 Aug 2013 14:43:05 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3624633580.9.2928; Wed, 28 Aug 2013 14:43:04 -0400 Message-ID: <521E45F4.8060107@isdg.net> Date: Wed, 28 Aug 2013 14:48:20 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130827012600.83309.qmail@joyce.lan> <1552915.aJAV4gMSz7@scott-latitude-e6320> <521E1E40.1060505@isdg.net> <3619221.jr7HmlbTDF@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Applications Directorate Review: ABNF 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, 28 Aug 2013 18:48:36 -0000 On 8/28/2013 12:44 PM, Murray S. Kucherawy wrote: > The argument that this is just like the MAIL FROM debate in RFC2821 doesn't > work for me, because that form was contained completely within SMTP. Don't follow you, its exactly the same protocol/parser strict/relaxed design issue and consideration. Relaxed wins in practice even though RFC5321 did not want to relax it via the ABNF. That particular statement was added in RFC5321 for a reason. -- HLS From sm@elandsys.com Wed Aug 28 13:47:00 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 51C9521E809C for ; Wed, 28 Aug 2013 13:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 IMAZuGyFjiHm for ; Wed, 28 Aug 2013 13:46:59 -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 0DDB221E8095 for ; Wed, 28 Aug 2013 13:46:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.239]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7SKkbNt015459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Aug 2013 13:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377722814; bh=wGLFHfDrajBKjbVkdrH4zYSPxprgzurTxTaY2D+4s3E=; h=Date:To:From:Subject:In-Reply-To:References; b=a3AuyUfZ2/HyDn7j4i/Noon4dbqh1YXsPpk96NB/46yS+ddjaQ3W86VStE1ilIxNJ tQgXCOf6jSN6KThe7nxYxYvnNiJmLOVQBo9M0HF2en3nh3T4snBJWaXe/yuf945OhX xxaMZpn75krZL89/ph6nh1k1AfazEUZFjLALwRfM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377722814; i=@elandsys.com; bh=wGLFHfDrajBKjbVkdrH4zYSPxprgzurTxTaY2D+4s3E=; h=Date:To:From:Subject:In-Reply-To:References; b=V4zXL3YgvU8q4WY3+LrKgiQR1tJe40+b/t8v7B/G7bFpkgKnWSDgzayg00HBj0j/1 ul6WqLMEBLc3OrycGrxyBqrLphz8rZSAuQv9VXkyyqwSKqcrgKxgf5xwcNc6hoYxr4 MJNEQUK0Mm2xbJvy/lucdbKddA/1V2vLN5895Bto= Message-Id: <6.2.5.6.2.20130828131133.0dcdbce8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 28 Aug 2013 13:46:05 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <521A1F31.8080402@cisco.com> References: <521A1F31.8080402@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 28 Aug 2013 20:47:00 -0000 Hello, I intend to use the inline reponses to address=20 this review. Please comment if there is anything=20 you disagree with. There are some points on=20 which the author would like the working group to comment about. At 08:13 25-08-2013, Eliot Lear wrote: >Major issues: > >1. Deprecation of SPF record not properly=20 >justified in text and in the wrong place >Deprecation of the SPF record is given short=20 >shrift in Section 13.1 which is the IANA=20 >considerations section.=C2 A persistent reader=20 >would not understand why the record was in fact=20 >deprecated.=C2 Here's what is 13.1 (there are a=20 >few words about 6686 in 3.1 as well, but nobody=20 >would care if this was simply a matter of low implementation/deployment). > >> Studies have shown that RRTYPE 99 has not seen any substantial use, >> and in fact its existence and mechanism defined in [RFC4408] has led >> to some interoperability issues. > >First, this text should be moved out of the IANA=20 >considerations sections and forward to Section=20 >3.1. Second it should explain what those=20 >interoperability issues are or have a normative=20 >(and retrievable) reference. At the very least,=20 >the winning argument(s) should be elucidated,=20 >and not just for posterity: the claim is that=20 >there is an interoperability problem. If so,=20 >then might administrators want to know that? > >The matter of handling garbage in garbage out is=20 >not well enough specified in Section 3. I would=20 >go considerably further and state that (a)=20 >records that do not begin with "v=3Dspf1" MUST NOT=20 >be processed further, and (b) that any record=20 >that does not conform to the stated grammar MUST=20 >be ignored. Also, did the working group=20 >consider a DKIM-like solution? They all but=20 >establish an _spf label in this document (I'll come to that in a moment). > >There is a general issue about when to deprecate=20 >an RR and the ability to add new RRs into the=20 >DNS. That issue has to be addressed in the=20 >longer term, no matter what the IESG and=20 >community decide here. Furthermore, to be=20 >clear, please do not read into the above=20 >comments an opinion about deprecation of the=20 >record itself, which I am withholding until=20 >there is clear text about the interoperability issues that are mentioned. The SPFBIS WG is not deprecating type=20 SPF. RRTYPE 99 has been removed from the (draft)=20 protocol. The working group discussion was=20 something very like MUST NOT publish, MUST NOT=20 query ... The author thinks it might be=20 reasonable to be more verbose in Appendix C, which currently says: o Use of DNS RR type SPF (99) has been removed from the protocol, see [RFC6686] for background. Personally, he thinks it's accurate and succinct=20 and he is not sure what to change that would=20 amount to the same thing in a lot more words. In=20 his opinion, ... has been removed ... . .... MUST=20 NOT query ... . ... MUST NOT publish ... . Is=20 redundant, but I don't strongly object if people think it would be better. There has been some discussion of the _spf label=20 on the SPFBIS mailing list. If I recall=20 correctly I commented about that in one of my responses to the APPSDIR= review. >Section 2.2, 1st para > >> Typically, such checks are done >> by a receiving MTA, but can be performed elsewhere in the mail >> processing chain so long as the required information is available and >> reliable >People may infer a traipse through Received=20 >headers for HELO information.=C2 Is that the=20 >intent, and is that acceptable, given that they=20 >could be forged?=C2 My point: the above is vague. It's, most importantly, the actual connect IP=20 from outside the receiving ADMD. Finding the=20 trust boundary reliably while groveling through=20 the message header is hard, but people do=20 it. Since post-SMTP checks are quite common, it=20 wouldn't be appropriate to try and disallow=20 them. The author thinks the current language is=20 a reasonable compromise and, IIRC, subject to=20 some intense WG debate that he prefers not to revisit. >Section 2.5: title > >>2.5. Location of Checks >I don't think you mean location. I think you mean "When to perform= checks". Location in the sequence of events. Where would=20 work as well. The author thinks Location/When/Where are all equivalent. He=20 prefers not to change it unless the WG supports a change. >Section 4.7, 2nd para, 2nd sentence. > >> Although the latter >> has a default (specifically "?all"), it aids debugging efforts if it >> is explicitly provided. > >How does it aid in debugging? It makes it clearer to the human eye what's=20 intended. People handle explicit better than implicit. >Section 5.6, ABNF: > >You've gone to some lengths to get ipv4 correct,=20 >but you don't do the same with CIDR prefixes. > >> ip4-cidr-length =3D "/" 1*DIGIT >> ip6-cidr-length =3D "/" 1*DIGIT >Strictly speaking the value range is from 1 to=20 >32, for v4, and 1 to 128 for v6. This isn't=20 >quite all legal, but at least it's bounded: > > ip4-cidr-length =3D "/" 1*2DIGIT ; value must be > 0 and may not= exceed 32 > ip6-cidr-length =3D "/" 1*3DIGIT ; value must be > 0 may not exceed= 128 > >You could do the same as you did with qnum, but perhaps that is overkill. There has been some discussion of the ABNF on the=20 SPFBIS mailing list (=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg04047.html=20 ). This is the suggested ABNF (credits to John Levine): ip4-cidr-length =3D "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 ip6-cidr-length =3D "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 >Section 6.2, last para: > >The following text is confusing: > >> Note: During recursion into an "include" mechanism, an "exp" modifier >> from the MUST NOT be used.=C2 In contrast, when= executing >> a "redirect" modifier, an "exp" modifier from the original domain >> MUST NOT be used. > >When "MUST NOT be used" do you mean MUST NOT be=20 >evaluated or processed or MUST NOT be present in=20 >the record? e.g., does this MUST apply to operators, implementers, or= both? Recursion into an include or execution of a=20 redirect is part of the evaluation that a=20 verifier does. Must not be processed/evaluated=20 by a verifier. Since record publishers won't=20 always know if others will use point to their=20 records using include/redirect, there's no way a=20 publisher could satisfy this requirement. Given=20 it can only work one way, the author don't understand the confusion. The author is open to improved text, but he does not see the problem. >Appendix A: > >> This section is normative and any discrepancies with the ABNF >> fragments in the preceding text are to be resolved in favor of this >> grammar. >Normally we don't normatively reference=20 >Appendices, and it represents a bit of a=20 >cultural cognitive dissidence for some. One=20 >possible fix: don't make it an Appendix, but the=20 >last section. But also, Section 7.1 is entitled=20 >"Formal Specification". Don't have two of those. The ABNF collection will be moved to a section. >Appendix E: > >There's probably a case not covered here, but=20 >it's close. E.1 describes originating ADMD=20 >behavior. Think of the case of a university or=20 >professional organization that offers=20 >forwarding. The advice given in the first=20 >bullet of E.1 is probably applicable, but=20 >requires that a new whitelist entry be created=20 >for new aliases that contain new hosts on the=20 >RHS. I would go just that bit further to explain. Forwarders are mediators in the terms used here and E.2 is applicable, not= E.1. >Nits: >Please stop creating acronyms. Spam =3D=20 >unsolicited bulk email. UBE is obfuscation in=20 >this case. Similarly, I'd ask the authors to=20 >trying speaking out loud "domain owning ADMDs,",=20 >expanding out the acronym. How about just saying "domain owners"? That's unchanged from RFC 4408. The author does not think we should change= it. RFC 5598 is the mail architecture document the=20 working group used got. The author agrees it's=20 trained, but we tried to stick with terminology=20 from 5598. Ripping out the 5598 terminology=20 would be a bunch of work that he does not think would be worth it. >In general your definitions section is=20 >unnecessarily verbose and could go for a good=20 >"haircut". For example, how about these: > >Imported Definitions: >MAIL FROM: The RFC5321.MailFrom, as defined in [RFC5321] >HELO: The parameter specified in the HELO or=20 >EHLO commands as specified in [RFC5321]. Possibly. The longer definition is largely from RFC 4408. Can the working group comment on this if it is going to change it? >Page 7, Section 1.2: > >This forward reference is unnecessary, and I would remove the section. The author agrees but the working group does. >2.1 2nd para, 2nd sentence: > >>If ADMDs >> choose to publish SPF records and want to support receivers making >> negative authorization determinations, it is necessary for them to >> publish records that end in "-all", or redirect to other records that >> do, otherwise, no definitive determination of authorization can be >> made. > >That's grammatically incorrect. Remove=20 >everything after "do," and you are fine. The author is ok with the suggestion. >Same section further down, please clarify "While=20 >offline checks are possible". I think you mean=20 >"deferred" or "checks made after delivery" or some such. The author thinks post-delivery would be=20 better. Obviously literal offline checks aren't possible. >Section 2.2 first para, first sentence: >> A mail receiver can perform a set of SPF checks for each mail message >> it receives. > >What value does this sentence offer the=20 >reader? Personally I say none, and would remove. That's there in response to people complaining=20 4408 was somehow making SPF checks=20 mandatory. The author does not care if it is=20 removed it as long as someone else deals with the=20 crazies convinced it's removal means something sinister. >Section 5.4: "mx" > >>Then it performs an address lookup on each MX name returned. > >To be precise: > >"It then performs an address lookup on of the=20 >name found in the RDATA of each answer." The author is ok with changing this. >Section 8.5, 2nd sentence: > >>The ADMD believes the host is not authorized=20 >>but is not willing to make a strong policy statement > >Which ADMD? The sending one. It's their record. Regards, S. Moonesamy (as document shpeherd)=20 From dhc@dcrocker.net Wed Aug 28 14:01: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 7B20F21F9EFB for ; Wed, 28 Aug 2013 14:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwjodsGyIp6W for ; Wed, 28 Aug 2013 14:01:46 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5D07621F9EE5 for ; Wed, 28 Aug 2013 14:01:46 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7SL1dum015432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Aug 2013 14:01:44 -0700 Message-ID: <521E6529.1040106@dcrocker.net> Date: Wed, 28 Aug 2013 14:01:29 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20130827012600.83309.qmail@joyce.lan> <1552915.aJAV4gMSz7@scott-latitude-e6320> <521E1E40.1060505@isdg.net> <3619221.jr7HmlbTDF@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 28 Aug 2013 14:01:44 -0700 (PDT) Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] Applications Directorate Review: ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 21:01:52 -0000 On 8/28/2013 9:44 AM, Murray S. Kucherawy wrote: > On Wed, Aug 28, 2013 at 9:02 AM, Scott Kitterman > wrote: > > I'm not objecting to the note, or something like it. I don't think it's > necessary, but I don't find it problematic. I do object to adding > anything to > the ABNF that requires accepting non-standard CIDR, which this > proposal does. > > > I object even to the note. I don't see the benefit in documenting a > (potentially large) list of ways various pre-bis implementations did > things incorrectly in the first place unless it's clear that their use > became common. There's no evidence to support that. +10. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Thu Aug 29 01:19:33 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 E502021E8098; Thu, 29 Aug 2013 01:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 cVYs9jUm7zNf; Thu, 29 Aug 2013 01:19:30 -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 43FFE21E8082; Thu, 29 Aug 2013 01:19:26 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.80]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7T8J5eO017219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Aug 2013 01:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377764361; bh=4JAA6N3cHUJ+HmDmGKp16PDKdpml9EDghdfkIKvnH1E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jDP820dahxeH4zGTnoel2KD3OWbAUU5xGp5Tr/uWSnRr7+FkYtix8/BiCdO4NkSZu e8q7ds/K4OGU7AVZc1EFx8Ham8Bz+GblkejZmTZZxj3hCbaIFwYeNNqlH99Cvt+l1+ 9Chp9gJyAdfMjTnt+VMpTiy8LbF5kpNbANdg8QHo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377764361; i=@elandsys.com; bh=4JAA6N3cHUJ+HmDmGKp16PDKdpml9EDghdfkIKvnH1E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ySnP2wnz/eUrkS8/R1qvAe88JItE5YZP0EVfwhaKl8mdW4sBgNzHuPUoGDtYNAd84 AoBosmEFXxQcFFHMSYeqkGYjfwifiFlGCeKLsdhtwwQ885lJA9kFcixOrssVjcEdOj xhTh5fpuxGhl2D8eBCshbig2eWmm1M5zhUjJ12ZU= Message-Id: <6.2.5.6.2.20130829005602.0ba8c530@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 29 Aug 2013 01:03:54 -0700 To: Eliot Lear , apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <521E6529.1040106@dcrocker.net> References: <20130827012600.83309.qmail@joyce.lan> <1552915.aJAV4gMSz7@scott-latitude-e6320> <521E1E40.1060505@isdg.net> <3619221.jr7HmlbTDF@scott-latitude-e6320> <521E6529.1040106@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, iesg@ietf.org Subject: Re: [spfbis] Applications Directorate Review: ABNF 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: Thu, 29 Aug 2013 08:19:33 -0000 Hi Eliot, The following is to address the rest of the=20 review. There was one major issue which I did=20 not comment about in my previous message. At 08:13 25-08-2013, Eliot Lear wrote: >Major issues: > >1. Deprecation of SPF record not properly=20 >justified in text and in the wrong place >Deprecation of the SPF record is given short=20 >shrift in Section 13.1 which is the IANA=20 >considerations section.=C2 A persistent reader=20 >would not understand why the record was in fact=20 >deprecated. Here's what is 13.1 (there are a few=20 >words about 6686 in 3.1 as well, but nobody=20 >would care if this was simply a matter of low implementation/deployment). > >> Studies have shown that RRTYPE 99 has not seen any substantial use, >> and in fact its existence and mechanism defined in [RFC4408] has led >> to some interoperability issues. > >First, this text should be moved out of the IANA=20 >considerations sections and forward to Section=20 >3.1. Second it should explain what those=20 >interoperability issues are or have a normative=20 >(and retrievable) reference. At the very least,=20 >the winning argument(s) should be elucidated,=20 >and not just for posterity: the claim is that=20 >there is an interoperability problem. If so,=20 >then might administrators want to know that? > >The matter of handling garbage in garbage out is=20 >not well enough specified in Section 3. I would=20 >go considerably further and state that (a)=20 >records that do not begin with "v=3Dspf1" MUST NOT=20 >be processed further, and (b) that any record=20 >that does not conform to the stated grammar MUST=20 >be ignored. Also, did the working group=20 >consider a DKIM-like solution? They all but=20 >establish an _spf label in this document (I'll come to that in a moment). > >There is a general issue about when to deprecate=20 >an RR and the ability to add new RRs into the=20 >DNS. That issue has to be addressed in the=20 >longer term, no matter what the IESG and=20 >community decide here. Furthermore, to be=20 >clear, please do not read into the above=20 >comments an opinion about deprecation of the=20 >record itself, which I am withholding until=20 >there is clear text about the interoperability issues that are mentioned. The SPFBIS WG is not deprecating type=20 SPF. RRTYPE 99 has been removed from the (draft)=20 protocol. The working group discussion was=20 something very like MUST NOT publish, MUST NOT=20 query ... The author thinks it might be=20 reasonable to be more verbose in Appendix C, which currently says: o Use of DNS RR type SPF (99) has been removed from the protocol, see [RFC6686] for background. Personally, he thinks it's accurate and succinct=20 and he is not sure what to change that would=20 amount to the same thing in a lot more words. In=20 his opinion, ... has been removed ... . .... MUST=20 NOT query ... . ... MUST NOT publish ... . Is=20 redundant, but he don't strongly object if people think it would be better. There has been some discussion of the _spf label=20 on the SPFBIS mailing list. If I recall=20 correctly I commented about that in one of my responses to the APPSDIR= review. >Section 2.2, 1st para > >> Typically, such checks are done >> by a receiving MTA, but can be performed elsewhere in the mail >> processing chain so long as the required information is available and >> reliable >People may infer a traipse through Received=20 >headers for HELO information.=C2 Is that the=20 >intent, and is that acceptable, given that they=20 >could be forged?=C2 My point: the above is vague. It's, most importantly, the actual connect IP=20 from outside the receiving ADMD. Finding the=20 trust boundary reliably while groveling through=20 the message header is hard, but people do=20 it. Since post-SMTP checks are quite common, it=20 wouldn't be appropriate to try and disallow=20 them. The author thinks the current language is=20 a reasonable compromise and, IIRC, subject to=20 some intense WG debate that he prefers not to revisit. >Section 2.5: title > >>2.5. Location of Checks >I don't think you mean location. I think you mean "When to perform= checks". Location in the sequence of events. Where would=20 work as well. The author thinks Location/When/Where are all equivalent. He=20 prefers not to change it. The SPFBIS did not support a change. >Section 4.7, 2nd para, 2nd sentence. > >> Although the latter >> has a default (specifically "?all"), it aids debugging efforts if it >> is explicitly provided. > >How does it aid in debugging? It makes it clearer to the human eye what's=20 intended. People handle explicit better than implicit. >Section 5.6, ABNF: > >You've gone to some lengths to get ipv4 correct,=20 >but you don't do the same with CIDR prefixes. > >> ip4-cidr-length =3D "/" 1*DIGIT >> ip6-cidr-length =3D "/" 1*DIGIT >Strictly speaking the value range is from 1 to=20 >32, for v4, and 1 to 128 for v6. This isn't=20 >quite all legal, but at least it's bounded: > > ip4-cidr-length =3D "/" 1*2DIGIT ; value must be > 0 and may not= exceed 32 > ip6-cidr-length =3D "/" 1*3DIGIT ; value must be > 0 may not exceed= 128 > >You could do the same as you did with qnum, but perhaps that is overkill. There has been some discussion of the ABNF on the=20 SPFBIS mailing list (=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg04047.html=20 ). This is the suggested ABNF (credits to John Levine): ip4-cidr-length =3D "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 ip6-cidr-length =3D "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 >Section 6.2, last para: > >The following text is confusing: > >> Note: During recursion into an "include" mechanism, an "exp" modifier >> from the MUST NOT be used.=C2 In contrast, when= executing >> a "redirect" modifier, an "exp" modifier from the original domain >> MUST NOT be used. > >When "MUST NOT be used" do you mean MUST NOT be=20 >evaluated or processed or MUST NOT be present in=20 >the record? e.g., does this MUST apply to operators, implementers, or= both? Recursion into an include or execution of a=20 redirect is part of the evaluation that a=20 verifier does. Must not be processed/evaluated=20 by a verifier. Since record publishers won't=20 always know if others will use point to their=20 records using include/redirect, there's no way a=20 publisher could satisfy this requirement. Given=20 it can only work one way, the author don't understand the confusion. The author is open to improved text, but he does not see the problem. >Appendix A: > >> This section is normative and any discrepancies with the ABNF >> fragments in the preceding text are to be resolved in favor of this >> grammar. >Normally we don't normatively reference=20 >Appendices, and it represents a bit of a=20 >cultural cognitive dissidence for some. One=20 >possible fix: don't make it an Appendix, but the=20 >last section. But also, Section 7.1 is entitled=20 >"Formal Specification". Don't have two of those. The ABNF collection will be moved to a section. >Appendix E: > >There's probably a case not covered here, but=20 >it's close. E.1 describes originating ADMD=20 >behavior. Think of the case of a university or=20 >professional organization that offers=20 >forwarding. The advice given in the first=20 >bullet of E.1 is probably applicable, but=20 >requires that a new whitelist entry be created=20 >for new aliases that contain new hosts on the=20 >RHS. I would go just that bit further to explain. Forwarders are mediators in the terms used here and E.2 is applicable, not= E.1. >Nits: >Please stop creating acronyms. Spam =3D=20 >unsolicited bulk email. UBE is obfuscation in=20 >this case. Similarly, I'd ask the authors to=20 >trying speaking out loud "domain owning ADMDs,",=20 >expanding out the acronym. How about just saying "domain owners"? That's unchanged from RFC 4408. The author does not think we should change= it. RFC 5598 is the mail architecture document the=20 working group used got. The author agrees it's=20 trained, but we tried to stick with terminology=20 from 5598. Ripping out the 5598 terminology=20 would be a bunch of work that he does not think would be worth it. >In general your definitions section is=20 >unnecessarily verbose and could go for a good=20 >"haircut". For example, how about these: > >Imported Definitions: >MAIL FROM: The RFC5321.MailFrom, as defined in [RFC5321] >HELO: The parameter specified in the HELO or=20 >EHLO commands as specified in [RFC5321]. Possibly. The longer definition is largely from RFC 4408. The SPFBIS WG did not suggest any change to this. >Page 7, Section 1.2: > >This forward reference is unnecessary, and I would remove the section. The author agrees but the working group doesn't. >2.1 2nd para, 2nd sentence: > >>If ADMDs >> choose to publish SPF records and want to support receivers making >> negative authorization determinations, it is necessary for them to >> publish records that end in "-all", or redirect to other records that >> do, otherwise, no definitive determination of authorization can be >> made. > >That's grammatically incorrect. Remove=20 >everything after "do," and you are fine. The author is ok with the suggestion. >Same section further down, please clarify "While=20 >offline checks are possible". I think you mean=20 >"deferred" or "checks made after delivery" or some such. The author thinks post-delivery would be=20 better. Obviously literal offline checks aren't possible. >Section 2.2 first para, first sentence: >> A mail receiver can perform a set of SPF checks for each mail message >> it receives. > >What value does this sentence offer the=20 >reader? Personally I say none, and would remove. That's there in response to people complaining=20 4408 was somehow making SPF checks=20 mandatory. The author does not care if it is=20 removed it as long as someone else deals with the=20 crazies convinced it's removal means something sinister. >Section 5.4: "mx" > >>Then it performs an address lookup on each MX name returned. > >To be precise: > >"It then performs an address lookup on of the=20 >name found in the RDATA of each answer." The author is ok with changing this. >Section 8.5, 2nd sentence: > >>The ADMD believes the host is not authorized=20 >>but is not willing to make a strong policy statement > >Which ADMD? The sending one. It's their record. Regards, S. Moonesamy (as document shepherd) =20