From hsantos@isdg.net Thu Mar 1 00:15:44 2012 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 A13AE21E802F for ; Thu, 1 Mar 2012 00:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.452, 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 pt5P91r--COs for ; Thu, 1 Mar 2012 00:15:43 -0800 (PST) Received: from mail.catinthebox.net (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 940F221E8019 for ; Thu, 1 Mar 2012 00:15:42 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=756; t=1330589733; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=KvQCxBjo6fTc8ZFr/ZRmR4WnqXI=; b=wqcbPhBKGPfA9yuRCxJT GVWGHDn0SIlMe0XusbwxVXLTx0kri+2apc+L0CKPcY46nKvpOkD5+y8LqUmJj8SH tU2uNtHb8CZxofwi8AFZB5G+pJsKBXCdqwJ+AtUBFInvOky9WhXFrJbsKJLzgPUs j0miDHq3IZrE2T5IjzkYq0k= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 01 Mar 2012 03:15:33 -0500 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 v6.4.454.1) with ESMTP id 3791570030.96536.1864; Thu, 01 Mar 2012 03:15:32 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=756; t=1330589478; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=zTOsqp8 voBoaN58HQKzPO2NDxBGCH9PBxSfJVFy44h0=; b=HS2xTz034D79qg2F9y+4hqi yz5qfOrv5NDb4eIsEeIeV4KCPZXbdoBYw13cWOHC/3xYRhSf/RestwgzufYPzpgX iz9dnhM24zZHVSDuBFBRJg7LOLncGt2wayh44Kh43wqT+a/IV35SwMFxHK/AktkO wkCxn9JkH4m+4yo8IjYY= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 01 Mar 2012 03:11:18 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 95532971.20089.5188; Thu, 01 Mar 2012 03:11:16 -0500 Message-ID: <4F4F3044.7090505@isdg.net> Date: Thu, 01 Mar 2012 03:16:04 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <233d984c-214e-4ae5-ab1c-73649018fd47@email.android.com> <6.2.5.6.2.20120229231251.0add09a8@elandnews.com> In-Reply-To: <6.2.5.6.2.20120229231251.0add09a8@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF 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, 01 Mar 2012 08:15:44 -0000 S Moonesamy wrote: > Hi Dave, > At 10:33 29-02-2012, Dave Crocker wrote: >> please at leat define it. > > I have been asked what "Hold for document update" means. The working > group does not have any WG draft up for discussion yet. When there is a > WG draft, the working group can discuss about the exact text that goes > into it. Just to confirm and inform the WG, the SPF-BIS WG charter concluding paragraph would be incorrect and the cited 4408bis draft is out of scope? An initial draft of an updated SPF specification document is draft-kitterman-4408bis. The working group may choose to use this document as a basis for their specification. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Thu Mar 1 03:54:40 2012 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 1D67821F8585 for ; Thu, 1 Mar 2012 03:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 kn3n3M1BduRz for ; Thu, 1 Mar 2012 03:54:39 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6840D21F858D for ; Thu, 1 Mar 2012 03:54:39 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id B5DA8D04083; Thu, 1 Mar 2012 05:54:38 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330602878; bh=vv+jHQfdI28ZvnuQeyIssBmv79iBlYX3ti8Ub1HROhQ=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=MY9JszrN8EdcgoP+PHCeTbRppv57pCa54D8QL057kk7Jn0YxVKNJdVXIrwYCveElt 2S0YfeZZ8olsQ1kDJi31oYvTqJgdI4knbWDjjYSHwc7yCSfSrP7MDy9fNek1mPU+uL xulvo9BbywnLvDiM824zXy/WelXortg5iOZUaMZY= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id BD423D0400C; Thu, 1 Mar 2012 05:54:37 -0600 (CST) References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <233d984c-214e-4ae5-ab1c-73649018fd47@email.android.com> <6.2.5.6.2.20120229231251.0add09a8@elandnews.com> User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20120229231251.0add09a8@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 01 Mar 2012 06:54:44 -0500 To: spfbis@ietf.org Message-ID: <1c441439-ce40-4707-a55a-4f2e4b99b05d@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF 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, 01 Mar 2012 11:54:40 -0000 S Moonesamy wrote: >Hi Dave, >At 10:33 29-02-2012, Dave Crocker wrote: >>please at leat define it. > >I have been asked what "Hold for document update" means. The working >group does not have any WG draft up for discussion yet. When there >is a WG draft, the working group can discuss about the exact text >that goes into it. How is that different than the issues we're discussing now? Is that the issue isn't expected to be controversial? Scott K From spf2@kitterman.com Thu Mar 1 03:59:00 2012 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 71DE021F85A4 for ; Thu, 1 Mar 2012 03:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 e3L0nJav9f6f for ; Thu, 1 Mar 2012 03:58:59 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id B0D3721F858D for ; Thu, 1 Mar 2012 03:58:59 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 51437D04083; Thu, 1 Mar 2012 05:58:59 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330603139; bh=tvjZ6OmUzDgRA+qXRwyLFbSq5OsbpUnibG5ZCwxzqyk=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=GorC4SM3aX4sLgraJfYinr8zK9zgguo/qEJGtaLE1UYXUXKuKVP8yAdDErtmyFMi0 Ksgd0MEfIL/dkSKeQDYuVULC7XA1WM3AWcBt84pzxqBeFBZ9b6SlYuisd30b9VF9ue Ru0HXAoAl6VFa96K7mJGLAJijXO0Ktwi2NE5pzqU= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 124C8D0400C; Thu, 1 Mar 2012 05:58:58 -0600 (CST) References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <233d984c-214e-4ae5-ab1c-73649018fd47@email.android.com> <6.2.5.6.2.20120229231251.0add09a8@elandnews.com> <4F4F3044.7090505@isdg.net> User-Agent: K-9 Mail for Android In-Reply-To: <4F4F3044.7090505@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 01 Mar 2012 06:59:08 -0500 To: spfbis@ietf.org Message-ID: <853e8b27-e0dc-41d9-b0e6-2c082c049da3@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF 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, 01 Mar 2012 11:59:00 -0000 Hector Santos wrote: >S Moonesamy wrote: >> Hi Dave, >> At 10:33 29-02-2012, Dave Crocker wrote: >>> please at leat define it. >> >> I have been asked what "Hold for document update" means. The working > >> group does not have any WG draft up for discussion yet. When there >is a >> WG draft, the working group can discuss about the exact text that >goes >> into it. > >Just to confirm and inform the WG, the SPF-BIS WG charter concluding >paragraph would be incorrect and the cited 4408bis draft is out of >scope? > > An initial draft of an updated SPF specification document is > draft-kitterman-4408bis. The working group may choose to > use this document as a basis for their specification. It says the working group may. For reasons that aren't clear to me, the working group hasn't even discussed it yet. Nothing wrong with the charter. Scott K From sm@elandsys.com Thu Mar 1 06:40:52 2012 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 372D821E82E9 for ; Thu, 1 Mar 2012 06:40:52 -0800 (PST) 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 v0jbzOeyejmG for ; Thu, 1 Mar 2012 06:40:49 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E302B21E8172 for ; Thu, 1 Mar 2012 06:40:49 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.232.175]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q21EeUAP022031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Mar 2012 06:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330612842; i=@elandsys.com; bh=MVzg05MNlfhjCXXqFM/9j2iHRYVgFysklgCCfRuSmwA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=4YFs/Vryl4sesI8mYEPB/XNyVLd+O0GtxWzBQXJbly1tRizk78m5fZ2iZ2Fx9Rr9d 7Y5Q29dqOjTaekY0XWgjP+WxQviWysU2A9S1I0sElWek8tCOB56IisOSa1dpixagaz 9nlHGgk71Z3B2sQzCdr/ymgM7n7dM0sYH74ZcdqM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330612842; i=@elandsys.com; bh=MVzg05MNlfhjCXXqFM/9j2iHRYVgFysklgCCfRuSmwA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=a9mUO9TuiRoG87S4zNGQf4XX/VCNal6uT1OdeJJ+M3/nCqCKAik384MxZDZzSRjkX 89kdPB4it1Tvv754eR6KnL0mZCGo4eG6yBrex9judLbDuZxs18WQeIPu2W0UUsY4Wd kw3zqiPCS4mkSpkm5KW0odwY9W8saj2GcYbxGsVI= Message-Id: <6.2.5.6.2.20120301043810.09b9be78@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 Mar 2012 05:30:59 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4F4F3044.7090505@isdg.net> References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <233d984c-214e-4ae5-ab1c-73649018fd47@email.android.com> <6.2.5.6.2.20120229231251.0add09a8@elandnews.com> <4F4F3044.7090505@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: [spfbis] Out of scope or off-topic 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, 01 Mar 2012 14:40:52 -0000 Hello, The SPFBIS WG Charter mentions the topics which are in scope or out of scope ( https://datatracker.ietf.org/wg/spfbis/charter/ ). A discussion about a topic can be off-topic for the moment although the topic itself is in scope. Discussions about any non-WG draft is off-topic for the moment. The draft mentioned in the charter is not a working group draft. Drafts which are SPFBIS working group drafts will have a filename which starts with "draft-ietf-spfbis-". The following issues are currently the being discussed: #1 http://www.ietf.org/mail-archive/web/spfbis/current/msg00538.html #4 http://www.ietf.org/mail-archive/web/spfbis/current/msg00694.html #13 http://www.ietf.org/mail-archive/web/spfbis/current/msg00715.html #17 http://www.ietf.org/mail-archive/web/spfbis/current/msg00718.html #19 http://www.ietf.org/mail-archive/web/spfbis/current/msg00716.html #23 http://www.ietf.org/mail-archive/web/spfbis/current/msg00717.html A thread was also opened in case the WG would like to comment on "widely deployed" ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00725.html ). Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Thu Mar 1 07:47:38 2012 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 7701921E81F2 for ; Thu, 1 Mar 2012 07:47:38 -0800 (PST) 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 150lfjIWz0it for ; Thu, 1 Mar 2012 07:47:37 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6D44721E81EC for ; Thu, 1 Mar 2012 07:47:37 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 974FFD04083; Thu, 1 Mar 2012 09:47:36 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330616856; bh=LUUEgofkynmufg+MvfxWWyHT2v2ezVZ4lSLN8mOewug=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=L2CiGRKFJmQ1Bh0ITc376ZENYqrw750KXupeEkxRw4jowzXyymKjoymPRZqwrfR69 Z1CMDz9WAll9sv05dI2zvRT1BcbGWrw0Gz6daZaxMpSxfknT8X6oTrH0I4lW+zhdeB 0/zuIxriE6gZFYhdZLtYZB+SQ7MmBEiyDJEHmIVM= Received: from 131.sub-97-129-104.myvzw.com (131.sub-97-129-104.myvzw.com [97.129.104.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id ECC62D04062; Thu, 1 Mar 2012 09:47:35 -0600 (CST) References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <233d984c-214e-4ae5-ab1c-73649018fd47@email.android.com> <6.2.5.6.2.20120229231251.0add09a8@elandnews.com> <4F4F3044.7090505@isdg.net> <6.2.5.6.2.20120301043810.09b9be78@resistor.net> User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20120301043810.09b9be78@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 01 Mar 2012 10:47:42 -0500 To: spfbis@ietf.org Message-ID: <27c72cff-8354-49cf-b23f-940343c2ee80@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Out of scope or off-topic 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, 01 Mar 2012 15:47:38 -0000 S Moonesamy wrote: >Hello, > >The SPFBIS WG Charter mentions the topics which are in scope or out >of scope ( https://datatracker.ietf.org/wg/spfbis/charter/ ). A >discussion about a topic can be off-topic for the moment although the >topic itself is in scope. > >Discussions about any non-WG draft is off-topic for the moment. The >draft mentioned in the charter is not a working group draft. Drafts >which are SPFBIS working group drafts will have a filename which >starts with "draft-ietf-spfbis-". > >The following issues are currently the being discussed: > > #1 http://www.ietf.org/mail-archive/web/spfbis/current/msg00538.html > #4 http://www.ietf.org/mail-archive/web/spfbis/current/msg00694.html > #13 http://www.ietf.org/mail-archive/web/spfbis/current/msg00715.html > #17 http://www.ietf.org/mail-archive/web/spfbis/current/msg00718.html > #19 http://www.ietf.org/mail-archive/web/spfbis/current/msg00716.html > #23 http://www.ietf.org/mail-archive/web/spfbis/current/msg00717.html > >A thread was also opened in case the WG would like to comment on >"widely deployed" ( >http://www.ietf.org/mail-archive/web/spfbis/current/msg00725.html ). I am confused. We've been discussing Murray's draft about concluding the 'experiment' and it's not, AFAIK, a working group document either. Is it off topic now too? Scott K From dhc@dcrocker.net Thu Mar 1 10:13:17 2012 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 55B3F21E80F2 for ; Thu, 1 Mar 2012 10:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.608 X-Spam-Level: X-Spam-Status: No, score=-6.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 jQvT99x2UQ-B for ; Thu, 1 Mar 2012 10:13:16 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C501F21E80D9 for ; Thu, 1 Mar 2012 10:13:16 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q21IDBrK027788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Mar 2012 10:13:16 -0800 Message-ID: <4F4FBC34.9080901@dcrocker.net> Date: Thu, 01 Mar 2012 10:13:08 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <233d984c-214e-4ae5-ab1c-73649018fd47@email.android.com> <6.2.5.6.2.20120229231251.0add09a8@elandnews.com> In-Reply-To: <6.2.5.6.2.20120229231251.0add09a8@elandnews.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.17]); Thu, 01 Mar 2012 10:13:16 -0800 (PST) Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF 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, 01 Mar 2012 18:13:17 -0000 On 2/29/2012 11:14 PM, S Moonesamy wrote > I have been asked what "Hold for document update" means. The working group does > not have any WG draft up for discussion yet. When there is a WG draft, the > working group can discuss about the exact text that goes into it. ack. tnx. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs@anvilwalrusden.com Mon Mar 5 09:51:27 2012 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 B9C0E21F879A for ; Mon, 5 Mar 2012 09:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 ADwAWnvMnHP0 for ; Mon, 5 Mar 2012 09:51:27 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 266B421F8778 for ; Mon, 5 Mar 2012 09:51:27 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5544D1ECB41D for ; Mon, 5 Mar 2012 17:51:26 +0000 (UTC) Date: Mon, 5 Mar 2012 12:51:24 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120305175124.GR76465@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 05 Mar 2012 17:51:27 -0000 Dear colleagues, We have received a request to adopt draft-kucherawy-spfbis-experiment as a WG draft, to be used as the basis for declaring the SPF experiment finished. The chairs have read the draft and believe it is a good basis for the WG's deliverable. That is not to say that the chairs agree with everything in it, nor to suggest that the draft as it stands is acceptable to the WG. We would like to adopt the draft as a WG document. We would like indications of participants' views about that. We require evidence that the WG will in fact work on this draft, and therefore would like at least five participants' commitment that they will work on the draft. Substantive comments on the draft itself will be counted as commitment to working on the draft as a WG document. If you object to adoption of the draft, please state both why you object and what your alternative proposal for completion of our first milestone is. Objections without an alternative proposal will be regarded with scepticism. Please remember that disagreeing with some particular claim in the draft is not a good reason to object to adopting the draft: the draft will probably need to be modified in order to reflect WG consensus. It is only an objection that the draft is by its nature unsuitable -- it covers entirely the wrong topics, for instance -- that has any force in the absence of an alternative adoption candidate. If the WG adopts the draft, we expect to appoint Murray as editor assuming that he is amenable and has time. Assuming we hear no reasonable objections, we will adopt the draft once the -00 queue re-opens during the Paris IETF meeting. If there is a reasonable objection and an alternative -00 draft is ready when the queue re-opens, we will consider the alternatives at that point; if no -00 alternative is available at the time the queue re-opens, we will take that as evidence of uninterest in proposing a real alternative, and proceed with adoption of draft-kucherawy-spfbis-experiment. Best regards, SM & AS (as chairs) -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Mon Mar 5 10:01:50 2012 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 F131221F8861 for ; Mon, 5 Mar 2012 10:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 k1GvRyWjozFb for ; Mon, 5 Mar 2012 10:01:50 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id BDD5E21F880D for ; Mon, 5 Mar 2012 10:01:43 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Mon, 5 Mar 2012 10:01:43 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment Thread-Index: AQHM+viuh+ryOLgSzUaSlnd8lXLsyZZb/eLw Date: Mon, 5 Mar 2012 18:01:43 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807ABC2@exch-mbx901.corp.cloudmark.com> References: <20120305175124.GR76465@crankycanuck.ca> In-Reply-To: <20120305175124.GR76465@crankycanuck.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 05 Mar 2012 18:01:51 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > Behalf Of Andrew Sullivan > Sent: Monday, March 05, 2012 9:51 AM > To: spfbis@ietf.org > Subject: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment >=20 > If the WG adopts the draft, we expect to appoint Murray as editor > assuming that he is amenable and has time. Yes, and yes. Do I count as one of the five? :-) -MSK From spf2@kitterman.com Mon Mar 5 10:14:02 2012 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 0CCAE21F8794 for ; Mon, 5 Mar 2012 10:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 oa7y2tjya0Vv for ; Mon, 5 Mar 2012 10:14:01 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB8721F8782 for ; Mon, 5 Mar 2012 10:14:01 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4346E20E4126; Mon, 5 Mar 2012 13:14:00 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330971240; bh=FCBhSf31o6cP8BJyQnAKNlcWnJSKwOovrlIKQziqPfg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=nk0W/e5KCh7SKxLSuxXoOAym0Ht4c8eB4/HIAHgDhpuIWwm1agySs2vmZx/pjx/QQ h/VnVR57AV4DXGqLhqj/uzuaQ0JHITCyixum3cAnOiNEX7oy75x2tLv5j5a56CnxFr /0JzpB918kMRai0o/edCzPcKeg2wKZQIGDiwVBu0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 23D9120E40A4; Mon, 5 Mar 2012 13:13:59 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 05 Mar 2012 13:13:59 -0500 Message-ID: <2934212.TfIHMJGsu2@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120305175124.GR76465@crankycanuck.ca> References: <20120305175124.GR76465@crankycanuck.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 05 Mar 2012 18:14:02 -0000 On Monday, March 05, 2012 12:51:24 PM Andrew Sullivan wrote: > Dear colleagues, > > We have received a request to adopt draft-kucherawy-spfbis-experiment > as a WG draft, to be used as the basis for declaring the SPF > experiment finished. > > The chairs have read the draft and believe it is a good basis for the > WG's deliverable. That is not to say that the chairs agree with > everything in it, nor to suggest that the draft as it stands is > acceptable to the WG. > > We would like to adopt the draft as a WG document. We would like > indications of participants' views about that. We require evidence > that the WG will in fact work on this draft, and therefore would like > at least five participants' commitment that they will work on the > draft. Substantive comments on the draft itself will be counted as > commitment to working on the draft as a WG document. > > If you object to adoption of the draft, please state both why you > object and what your alternative proposal for completion of our first > milestone is. Objections without an alternative proposal will be > regarded with scepticism. Please remember that disagreeing with some > particular claim in the draft is not a good reason to object to > adopting the draft: the draft will probably need to be modified in > order to reflect WG consensus. It is only an objection that the draft > is by its nature unsuitable -- it covers entirely the wrong topics, > for instance -- that has any force in the absence of an alternative > adoption candidate. > > If the WG adopts the draft, we expect to appoint Murray as editor > assuming that he is amenable and has time. Assuming we hear no > reasonable objections, we will adopt the draft once the -00 queue > re-opens during the Paris IETF meeting. If there is a reasonable > objection and an alternative -00 draft is ready when the queue > re-opens, we will consider the alternatives at that point; if no -00 > alternative is available at the time the queue re-opens, we will take > that as evidence of uninterest in proposing a real alternative, and > proceed with adoption of draft-kucherawy-spfbis-experiment. > > Best regards, > > SM & AS (as chairs) I don't object. I have contributed and expect to do so. I am confused about the process. Is lack of such a request we haven't looked into adopting an RFC 4408bis draft? Why five? Scott K From ajs@anvilwalrusden.com Mon Mar 5 10:30:22 2012 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 72C2621F87C9 for ; Mon, 5 Mar 2012 10:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 U8Ecyf5e1Bkn for ; Mon, 5 Mar 2012 10:30:21 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAAE21F87CB for ; Mon, 5 Mar 2012 10:30:20 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 49EB91ECB41D for ; Mon, 5 Mar 2012 18:30:19 +0000 (UTC) Date: Mon, 5 Mar 2012 13:30:17 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120305183017.GT76465@mail.yitter.info> References: <20120305175124.GR76465@crankycanuck.ca> <2934212.TfIHMJGsu2@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2934212.TfIHMJGsu2@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 05 Mar 2012 18:30:22 -0000 On Mon, Mar 05, 2012 at 01:13:59PM -0500, Scott Kitterman wrote: > > I am confused about the process. Is lack of such a request we haven't looked > into adopting an RFC 4408bis draft? No, it isn't. You may recall that we originally asked for reviews of 4408 (which has turned into a list of issues). The adoption of a 4408bis starting point will come once we have sorted out whether some of the issues are real issues or not. Please be patient. > Why five? It's an arbitrary number, large enough to suggest that there is meaningful participation and yet small enough that if people wander off we're still likely to have enough reviewers to indicate real consensus. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From hsantos@isdg.net Mon Mar 5 10:53:52 2012 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 9872F21F8857 for ; Mon, 5 Mar 2012 10:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_20=-0.74] 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 YiNRI6YGnezk for ; Mon, 5 Mar 2012 10:53:51 -0800 (PST) Received: from news.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AC94521F883B for ; Mon, 5 Mar 2012 10:53:50 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2611; t=1330973620; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=bR7nXxC6Elv3TNNbX2rSfpQWXMQ=; b=azm1FVvg5/q1KKzxp1AR YFZ0sIbzyhyM6IBxmp1C4zMAtqWnJhbFwQrhUdASX7G2eBhI3SbUmWvLDi87CUoA GmgJyzSM8G4pnbkHReitAayjrNNfhD9y6VlEG12u1oA0Tljr5N86EaNAL0nRCTWs phu9SZNEFtcanUdnGhRbK9g= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 05 Mar 2012 13:53:40 -0500 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 v6.4.454.1) with ESMTP id 4175453421.4276.1636; Mon, 05 Mar 2012 13:53:39 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2611; t=1330973361; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=QJ1SYUB lgAIAkBfIShvQqG7YNvweFC203MsNnof8B9A=; b=EnacRD/lld6q2zdnsvg3o82 uR4NH43QXXxwJFlh25vN7mVP3SA0QmpRGroJxBeLY1JCGFLBC3+FTWWwkZ+0o6DX JjfsAzyd5zxQJObWJXK3fRuBK5Us0scCkZMSp2CWTB2rP0PXwWXShLahVe48hSxU RE+DhjBT/Re2ZlEy21TA= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 05 Mar 2012 13:49:21 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 479416455.24833.3208; Mon, 05 Mar 2012 13:49:20 -0500 Message-ID: <4F550BAE.8050208@isdg.net> Date: Mon, 05 Mar 2012 13:53:34 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120305175124.GR76465@crankycanuck.ca> <2934212.TfIHMJGsu2@scott-latitude-e6320> <20120305183017.GT76465@mail.yitter.info> In-Reply-To: <20120305183017.GT76465@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 05 Mar 2012 18:53:52 -0000 While it is extremely overwhelming to see a single person take control of some many of the documented and related in form or another documents, which begins to alter the engineering insights and sense of cooperative competition, its not much of an bigger issue than to major conflict of interest issue being exhibited by including the concepts of using DKIM, AUTH-RES into SPF and also use DKIM to determine the faith of SENDER-ID, SUBMITTER. I can walk away from all this and have complete faith on my engineering peers to do the common sense engineering. But when its obvious done for a purpose that is very questionable, then it really leaves people with a bitter pill to swallow and an empathetic recourse when the WGC have a predisposition to filter discontent. Just consider the charter did have an document for review consideration. What was it not use as the basis to be fune tuned with all the same expected pros and cons, you say CAN HAPPEN for murray's document as well, but we all know is likely to be the case to occur because you can control the opposition. That said, I don't really care if Murray is the editor, wish he was more open minded, but I don't care as long as SPF-BIS is not used as a leverage to alter its fundamental design, replaced Received-SPF with AUTH-RES, make it less deterministic, and use DKIM to replaced SENDER-ID and eliminate SUBMITTER. Since when did the IETF get involved in the Product Support business? Don't worry Mr Sullivan. No need to issue more threats. I'm about to drop out of this SPF-BIS I knew from its beginning will be infested with fleas. I see it becoming another DKIM WG of isolated conflict of interest - after all, its the same group of people, and now the SAME EDITOR. Andrew Sullivan wrote: > On Mon, Mar 05, 2012 at 01:13:59PM -0500, Scott Kitterman wrote: >> I am confused about the process. Is lack of such a request we haven't looked >> into adopting an RFC 4408bis draft? > > No, it isn't. You may recall that we originally asked for reviews of > 4408 (which has turned into a list of issues). The adoption of a > 4408bis starting point will come once we have sorted out whether some > of the issues are real issues or not. Please be patient. > >> Why five? > > It's an arbitrary number, large enough to suggest that there is > meaningful participation and yet small enough that if people wander > off we're still likely to have enough reviewers to indicate real > consensus. > > Best, > > A > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From ajs@anvilwalrusden.com Mon Mar 5 11:12:48 2012 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 A467B21F88EA for ; Mon, 5 Mar 2012 11:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 7MidSgTwkKUG for ; Mon, 5 Mar 2012 11:12:47 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B250721F88E9 for ; Mon, 5 Mar 2012 11:12:47 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E3D611ECB41D for ; Mon, 5 Mar 2012 19:12:46 +0000 (UTC) Date: Mon, 5 Mar 2012 14:12:45 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120305191244.GX76465@mail.yitter.info> References: <20120305175124.GR76465@crankycanuck.ca> <2934212.TfIHMJGsu2@scott-latitude-e6320> <20120305183017.GT76465@mail.yitter.info> <4F550BAE.8050208@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F550BAE.8050208@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 05 Mar 2012 19:12:48 -0000 Dear colleagues, On Mon, Mar 05, 2012 at 01:53:34PM -0500, Hector Santos wrote: > Just consider the charter did have an document for review > consideration. As I already mentioned in my note to Scott, that document will come up in the future. The present issue is whether to adopt the proposed document in order to settle the question of the SPF/Sender-ID experiment. This is our first milestone: Aug 2012 - A document describing the SPF/Sender-ID experiment and its conclusions to the IESG for publication. Best regards, A PS: I acknowledge having read the rest of that message. -- Andrew Sullivan ajs@anvilwalrusden.com From pmidge@microsoft.com Mon Mar 5 11:19:29 2012 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 49DD421F891D for ; Mon, 5 Mar 2012 11:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.236 X-Spam-Level: X-Spam-Status: No, score=-4.236 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 2NvwlYNOtycN for ; Mon, 5 Mar 2012 11:19:28 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 49BEB21F8907 for ; Mon, 5 Mar 2012 11:19:28 -0800 (PST) Received: from mail19-am1-R.bigfish.com (10.3.201.241) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Mar 2012 19:19:27 +0000 Received: from mail19-am1 (localhost [127.0.0.1]) by mail19-am1-R.bigfish.com (Postfix) with ESMTP id 424A0801AC; Mon, 5 Mar 2012 19:19:27 +0000 (UTC) X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail19-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail19-am1 (localhost.localdomain [127.0.0.1]) by mail19-am1 (MessageSwitch) id 1330975165973868_5837; Mon, 5 Mar 2012 19:19:25 +0000 (UTC) Received: from AM1EHSMHS019.bigfish.com (unknown [10.3.201.240]) by mail19-am1.bigfish.com (Postfix) with ESMTP id DFCC44C004C; Mon, 5 Mar 2012 19:19:25 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS019.bigfish.com (10.3.206.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 5 Mar 2012 19:19:24 +0000 Received: from TK5EX14MBXC204.redmond.corp.microsoft.com ([169.254.5.122]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0283.004; Mon, 5 Mar 2012 19:19:21 +0000 From: Paul Midgen To: Andrew Sullivan , "spfbis@ietf.org" Thread-Topic: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment Thread-Index: AQHM+vibX/m59NP77k24jMyM2u4cyJZcE1kA Date: Mon, 5 Mar 2012 19:19:20 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E2050A083@TK5EX14MBXC204.redmond.corp.microsoft.com> References: <20120305175124.GR76465@crankycanuck.ca> In-Reply-To: <20120305175124.GR76465@crankycanuck.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 05 Mar 2012 19:19:29 -0000 I support adoption of the draft as a WG document. I will contribute to the draft officially as I have been unofficially. -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Andrew Sullivan Sent: Monday, March 05, 2012 9:51 AM To: spfbis@ietf.org Subject: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment Dear colleagues, We have received a request to adopt draft-kucherawy-spfbis-experiment as a = WG draft, to be used as the basis for declaring the SPF experiment finished= . The chairs have read the draft and believe it is a good basis for the WG's = deliverable. That is not to say that the chairs agree with everything in i= t, nor to suggest that the draft as it stands is acceptable to the WG. =20 We would like to adopt the draft as a WG document. We would like indicatio= ns of participants' views about that. We require evidence that the WG will= in fact work on this draft, and therefore would like at least five partici= pants' commitment that they will work on the draft. Substantive comments o= n the draft itself will be counted as commitment to working on the draft as= a WG document. If you object to adoption of the draft, please state both why you object an= d what your alternative proposal for completion of our first milestone is. = Objections without an alternative proposal will be regarded with scepticis= m. Please remember that disagreeing with some particular claim in the draf= t is not a good reason to object to adopting the draft: the draft will prob= ably need to be modified in order to reflect WG consensus. It is only an o= bjection that the draft is by its nature unsuitable -- it covers entirely t= he wrong topics, for instance -- that has any force in the absence of an al= ternative adoption candidate. If the WG adopts the draft, we expect to appoint Murray as editor assuming = that he is amenable and has time. Assuming we hear no reasonable objection= s, we will adopt the draft once the -00 queue re-opens during the Paris IET= F meeting. If there is a reasonable objection and an alternative -00 draft= is ready when the queue re-opens, we will consider the alternatives at tha= t point; if no -00 alternative is available at the time the queue re-opens,= we will take that as evidence of uninterest in proposing a real alternativ= e, and proceed with adoption of draft-kucherawy-spfbis-experiment. Best regards, SM & AS (as chairs) -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From vesely@tana.it Mon Mar 5 11:19:43 2012 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 17B9421F87D4 for ; Mon, 5 Mar 2012 11:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Rhk4NFmCQJe for ; Mon, 5 Mar 2012 11:19:42 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2142421F87D8 for ; Mon, 5 Mar 2012 11:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1330975181; bh=kmtgB57Ljs8DK5BzmkBS65zBnfZ0YQzFtQKpgMsnAHM=; l=259; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=GhNOB6LKK1tT7DT6veLUYpb6WLO73UVyyFPTCbIu+ZyfQby2Q5wvz1OIEgXGWPcnC 4k71w4+m9f0dXB0zLbFdxHMmTfVRENkCfzqPo6fQXKA1ZJ+Uji3X797iABDPPYIqSk ige7M+YgoSECNUV+3IshyIuexg0RmXV/kOUx6Xho= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 05 Mar 2012 20:19:41 +0100 id 00000000005DC039.000000004F5511CD.0000469C Message-ID: <4F5511CC.9070206@tana.it> Date: Mon, 05 Mar 2012 20:19:40 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120305175124.GR76465@crankycanuck.ca> In-Reply-To: <20120305175124.GR76465@crankycanuck.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 05 Mar 2012 19:19:43 -0000 On 05/Mar/12 18:51, Andrew Sullivan wrote: > If the WG adopts the draft, we expect to appoint Murray as editor > assuming that he is amenable and has time. +1 for adoption; Murray is a very patient and unwearied editor, IME. Thanks for his commitment. From johnl@iecc.com Mon Mar 5 11:37:30 2012 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 3D2C021F894E for ; Mon, 5 Mar 2012 11:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.18 X-Spam-Level: X-Spam-Status: No, score=-110.18 tagged_above=-999 required=5 tests=[AWL=1.019, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 o81GEsKl0LS3 for ; Mon, 5 Mar 2012 11:37:29 -0800 (PST) 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 74E9B21F894F for ; Mon, 5 Mar 2012 11:37:29 -0800 (PST) Received: (qmail 80063 invoked from network); 5 Mar 2012 19:37:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Mar 2012 19:37:25 -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:vbr-info; s=4f5515f5.xn--9vv.k1203; i=johnl@user.iecc.com; bh=Yc56p2+8KRcHq1hTj6hMa3PmNf/bBisiaap5cL+FX90=; b=GfQA3a/f+SNxDIFKYqqF4MOBPhJJ0UOgby2YqdFoF4gLQGhcGOM5OlI8V+VU/cnQQhQ8c18uP946Ga3viuVhX+2Dex7jnDhlS3S3rIHwTyVgpUjcv7AdU6F5ZOFZIar72IBYSGf7SG/dvvrv4gLxTg9wApemZBbeQYrt81rwQoU= 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:vbr-info; s=4f5515f5.xn--9vv.k1203; olt=johnl@user.iecc.com; bh=Yc56p2+8KRcHq1hTj6hMa3PmNf/bBisiaap5cL+FX90=; b=mKK338SGMHpdZui63ComAezkSSXxIMCbTNTFZjeTlVPUOM/HEBkVE9COUihnT7KWIEW02o4Neb+LExL0zFqxPq0w29sbJ7CNmA0TBecHR4pWBUgggnoD2MLqIf2VHtCmGuHpNoB1VyuFyOHGMwjPFKcZMEEqcFqH8XTkATWQrs4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 5 Mar 2012 19:37:03 -0000 Message-ID: <20120305193703.69475.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E00392807ABC2@exch-mbx901.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: msk@cloudmark.com Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 05 Mar 2012 19:37:30 -0000 >> If the WG adopts the draft, we expect to appoint Murray as editor >> assuming that he is amenable and has time. Definitely. No good deed goes unpunished. R's, John From hsantos@isdg.net Mon Mar 5 12:15:08 2012 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 0DB6121F8923 for ; Mon, 5 Mar 2012 12:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.448, 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 apjYSzBIlusn for ; Mon, 5 Mar 2012 12:15:06 -0800 (PST) Received: from secure.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C274121F893D for ; Mon, 5 Mar 2012 12:14:59 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2641; t=1330978491; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=jTaNJUtraNUN9OBxS/21N33+3JQ=; b=kCGoBZ34QB00smX2HWuC hdn+rBnHWx4NV6Mi9d0E/y0J1Dkp2hHaN6Wt7Ebq+bn2ZdXRXo5KhZYzF1lZ43TJ /g5iwCRIObbcrDIYfUROBdnfQbTF6xuxmB26ySK6B0JC8WQXTzv8xPXCMBUeesA6 1+5rSG9d2vlzPNL71WZ8hBM= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 05 Mar 2012 15:14:51 -0500 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 v6.4.454.1) with ESMTP id 4180323726.4276.4456; Mon, 05 Mar 2012 15:14:50 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2641; t=1330978232; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=Osqa+xz mC+36oxE8daMjtMsVOi8GB9rAHUoBhDHhq6Q=; b=l/KAW9ygOsDeOfwoSOdOxes Y2X/LAhYTwcdLIwpAqDRIdvAS28zLF18jrzbBACijSoZywG4e0FeuT8N5ALn1z7Y 1sn+Xca2YXbZ6u36G+J+KgW5N2AiQOQ5E5DSl3ofeeOGTi9NiDx3pH0tcOJiljTp wlp45/MCQzM8AliEmhyo= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 05 Mar 2012 15:10:32 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 484287612.24838.460; Mon, 05 Mar 2012 15:10:31 -0500 Message-ID: <4F551EBD.10309@isdg.net> Date: Mon, 05 Mar 2012 15:14:53 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <20120305175124.GR76465@crankycanuck.ca> <4F5511CC.9070206@tana.it> In-Reply-To: <4F5511CC.9070206@tana.it> 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 Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 05 Mar 2012 20:15:08 -0000 Alessandro Vesely wrote: > On 05/Mar/12 18:51, Andrew Sullivan wrote: >> If the WG adopts the draft, we expect to appoint Murray as editor >> assuming that he is amenable and has time. > > +1 for adoption; Murray is a very patient and unwearied editor, IME. > Thanks for his commitment. Alessandro, I believe the chairs and ADs understand my position about Murray, at least I hope they do. You may be surprise. But overall, this may help, at the 2nd ever ISP Trade conference (OneBBS CON, before Phil Becker and Boardwatch Magazine sold it and it was renamed to OneISP Con), I presented a paper to a pack room crowd on the concept of Cooperative Competition or CoComp which mean something to veterans of the mixed industry of standards, formats, adoption and strategic needs to converge, provide added-value yet not be used as a leverage against competition and especially the lower end (small to mid) of the market place. IETF is more of a Project R&D and less than a Product R&D environment, and the latter is becoming more of a concern. One can not use the tools of the IETF to put weight on implementators to move in an unclear and costly directions and I firmly believe we most of us believe that (otherwise I would be here), but yet at the same time, isolation and "Rough Consensus" is used to negate the Technical Merits concerns when warranted. Its not that I don't agree with the ideas of convergence and integration because in fact, SSI near 30 years existence in the market place, excels in it. Its what we long practice in our product lines with the integration of many technologies and protocols since the 80s. Our motto is "Providing tomorrow technologies... today." I recognize the issues and I am only providing input hoping it can reduce the "Out of the Gate" friction to make SPF-BIF a wild success. I provided an offlist suggestion of perhaps having an I-D "Deployment Guide" for SPF, SIDF and maybe perhaps use it to introduce DKIM and AUTH-RES. But to have a WG document that clearly had one goal to basically try to overwhelm and convince you to alter your course, well, I have a fundamental and ethical "Cooperative Competition" problem with that, not just for SSI, but for everyone that is not represented in this WG. I have a half glass full approach to problem solver and firmly believe we ALL can have our cake and eat it too. But it will not work when conflict of interest overwhelm everything else. I don't wish to say any more or feel I need to go any further. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From WebMaster@Commerco.Net Mon Mar 5 12:51:25 2012 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 4715421F8927 for ; Mon, 5 Mar 2012 12:51:25 -0800 (PST) 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 sVnpC77+0LXk for ; Mon, 5 Mar 2012 12:51:24 -0800 (PST) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7069121F8924 for ; Mon, 5 Mar 2012 12:51:24 -0800 (PST) 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:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=uwAoRwJaWpLOXFF/9F6+vWvy50opa0wccfJKU2r9gTLt/5YRMGLuc1vOTieFV4YBOTCUfNbVhKioCPqICWM2/gS5pRWFYRwDuBcz0M6W4LqbkRs+MzVNZ/vLIi4MxvF+PvU14qWTCBd3qgqLBaWKEKgCwW1u1pFtFLNhQV1i7ho= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Mon, 05 Mar 2012 20:51:23 +0000 Message-ID: <4F552745.5020507@Commerco.Net> Date: Mon, 05 Mar 2012 13:51:17 -0700 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120305175124.GR76465@crankycanuck.ca> In-Reply-To: <20120305175124.GR76465@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 05 Mar 2012 20:51:25 -0000 On 3/5/2012 10:51 AM, Andrew Sullivan wrote: > Dear colleagues, > > We have received a request to adopt draft-kucherawy-spfbis-experiment > as a WG draft, to be used as the basis for declaring the SPF > experiment finished. > > The chairs have read the draft and believe it is a good basis for the > WG's deliverable. That is not to say that the chairs agree with > everything in it, nor to suggest that the draft as it stands is > acceptable to the WG. > > We would like to adopt the draft as a WG document. We would like > indications of participants' views about that. We require evidence > that the WG will in fact work on this draft, and therefore would like > at least five participants' commitment that they will work on the > draft. Substantive comments on the draft itself will be counted as > commitment to working on the draft as a WG document. > > If you object to adoption of the draft, please state both why you > object and what your alternative proposal for completion of our first > milestone is. Objections without an alternative proposal will be > regarded with scepticism. Please remember that disagreeing with some > particular claim in the draft is not a good reason to object to > adopting the draft: the draft will probably need to be modified in > order to reflect WG consensus. It is only an objection that the draft > is by its nature unsuitable -- it covers entirely the wrong topics, > for instance -- that has any force in the absence of an alternative > adoption candidate. > > If the WG adopts the draft, we expect to appoint Murray as editor > assuming that he is amenable and has time. Assuming we hear no > reasonable objections, we will adopt the draft once the -00 queue > re-opens during the Paris IETF meeting. If there is a reasonable > objection and an alternative -00 draft is ready when the queue > re-opens, we will consider the alternatives at that point; if no -00 > alternative is available at the time the queue re-opens, we will take > that as evidence of uninterest in proposing a real alternative, and > proceed with adoption of draft-kucherawy-spfbis-experiment. > > Best regards, > > SM& AS (as chairs) > I would be pleased to help in working on draft-kucherawy-spfbis-experiment and providing feedback where I can. Best, Alan M. From sm@elandsys.com Mon Mar 5 14:33:59 2012 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 5003621E804E for ; Mon, 5 Mar 2012 14:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 nNZCE4wqt4+M for ; Mon, 5 Mar 2012 14:33:57 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E8D21E8059 for ; Mon, 5 Mar 2012 14:33:56 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.233.157]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q25MXfgT022019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Mar 2012 14:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330986834; i=@elandsys.com; bh=3zJWFx5/frfilpic2Tt1obaE4QlOawmphsd3SrJbDRI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=GFqEjqVLstPK4uHYSxG8s06fn8KcWFy/LJS6zqwu5CskJpJ1IKd02itVKTBrpIgHL WY15U7GAQffoBaM+RIvaHbDQTWYyPNXmoOG3G42lH4rCqGFgGIoaV662f8HwES/PmW E4ZDi0MzfIpJMxdOX3vxsWnv5Pri4o66Jn/ddgZM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330986834; i=@elandsys.com; bh=3zJWFx5/frfilpic2Tt1obaE4QlOawmphsd3SrJbDRI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=GU3+lJeWiZY4LEeKUnc1zet3/sL6rPAQTWg4DrdYe5mrOfVvtrbi9P3o9rgMCKbbL jNIe+A55n5J3zB/BPyXLiFeOBEPi0gvgTxvD7Mbe7tpxmK2NKw06KJOehwAb9furPl +7YdcQJtolJA+mPOpJ2AOKAepIFT0o1IoXmFcEL4= Message-Id: <6.2.5.6.2.20120305142958.09f03368@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 05 Mar 2012 14:33:34 -0800 To: Hector Santos From: S Moonesamy In-Reply-To: <4F551EBD.10309@isdg.net> References: <20120305175124.GR76465@crankycanuck.ca> <4F5511CC.9070206@tana.it> <4F551EBD.10309@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 05 Mar 2012 22:33:59 -0000 Dear Mr Santos, We have read the first message you posted to the SPFBIS working group mailing list on March 5, 2012 ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00751.html ). As SPFBIS Working Group Chairs, we are extremely concerned about the content of that message and your second message ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00756.html ). Could you please provide us with an explanation about: (a) the "threats" you are referring to in the first message? (b) the "conflict of interest" you are referring to in the first message and in the second message? Regards, Andrew Sullivan & S. Moonesamy, SPFBIS WG Chairs From hsantos@isdg.net Mon Mar 5 15:57:41 2012 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 A7C4521F8685 for ; Mon, 5 Mar 2012 15:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.445, 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 QbnX4Z5mpMKO for ; Mon, 5 Mar 2012 15:57:40 -0800 (PST) Received: from mail.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9D121F8611 for ; Mon, 5 Mar 2012 15:57:40 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1761; t=1330991851; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=pVLk1DYXLjaoZWOhU6jC9SSVriE=; b=Sh/SthvtWbxGq8e9QVNL ZjsyUJUIzoRMOxd7D+9eNQ51cg6yidArwJ7bwltKUKbeHsVw1P0MFoKoT5IsDqia en0O7BDNJcr2E8bnzu1tABuZImuKZbM8abrEB6TbJonY8v6bZyhyGtEM6izb+Uq2 j7NZFjy/wJ+vNrB00KNGbkc= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 05 Mar 2012 18:57:31 -0500 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 v6.4.454.1) with ESMTP id 4193683838.4276.3328; Mon, 05 Mar 2012 18:57:30 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1761; t=1330991589; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=xrgtbXm tWiz/2JiPyUk1r/n8w1Q8IT4d/G4zuKVWK7w=; b=xgdyxEOMea+f5D0iNQlfFGh x9AHqXEUZv3nu7dfgXiYEC4Bzg2OZBhiO4s1EOPQNKRYmEgfWYMcDeAJIVzmzLiU IFW2SFNpr7SMdg9MyUAj/blbKxRcN/w9qVvWiwaQ/i7kkQwqrIyfrFkJ7ZxQsXJt zSpI8c+chDoE805iSJCo= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 05 Mar 2012 18:53:09 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 497644768.24862.4320; Mon, 05 Mar 2012 18:53:08 -0500 Message-ID: <4F555303.6040802@isdg.net> Date: Mon, 05 Mar 2012 18:57:55 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120305175124.GR76465@crankycanuck.ca> <4F5511CC.9070206@tana.it> <4F551EBD.10309@isdg.net> <6.2.5.6.2.20120305142958.09f03368@resistor.net> In-Reply-To: <6.2.5.6.2.20120305142958.09f03368@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 05 Mar 2012 23:57:41 -0000 S Moonesamy wrote: > Dear Mr Santos, > > We have read the first message you posted to the SPFBIS working group > mailing list on March 5, 2012 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg00751.html ). As > SPFBIS Working Group Chairs, we are extremely concerned about the > content of that message and your second message ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg00756.html ). > Could you please provide us with an explanation about: > > (a) the "threats" you are referring to in the first message? I don't believe it is of value to repeat what was ready stated to you and AS offlist. In this "first message" it is filled with explicit statements of preemption of what is considered constructive or not. > (b) the "conflict of interest" you are referring to in the What is vexing to me is why it appears to be a burden or need to repeatedly restate the concerns on-list or off-list? I tried a new approach with the "Cooperative Competitive" statement in this 2nd message. I really don't know how else it can stated. Maybe this layman video on Pareto Optimality may help. Just substitute iPAD or Pecan Pies with the IETF Product trying to be produced here in IETF SPF-BIS: http://www.youtube.com/watch?v=wCuI-2LI6-M Point #1: A situation is efficient if no change is possible that will help some people without harming others. Point #2: Point #1 is only half the reality, requiring you to see the video because I can not see how else the issue can be stated. TIP: As you view the video, replace iPAD or PIES with an IETF "Product Line." If that doesn't do it, then nothing else will. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From sm@elandsys.com Mon Mar 5 16:48:13 2012 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 9696721F87BF for ; Mon, 5 Mar 2012 16:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 FTuI0lBZdiRw for ; Mon, 5 Mar 2012 16:48:12 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BC421F87B8 for ; Mon, 5 Mar 2012 16:48:12 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.233.157]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q260m0IT006031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Mar 2012 16:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330994891; i=@elandsys.com; bh=Nsz3c6SskwZYqLQ/kuHU1oBWmis3EE4GM9510pdUdUw=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=EiOjlxX8PovGCHDmj9+24Mvjw0bsnMUSqympSt5YrhLv47ZypeLF/V0cUs5ZVyeyz KxF/Z819wNXn80MeC8ijiSjfwVJSimvtlt0HHZ8VxMJuymA93ql2dx51htuN4bvykf mKzy+m7+sJlFRG67Z38iyobdmTKP3t1NfRE33Q7g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330994891; i=@elandsys.com; bh=Nsz3c6SskwZYqLQ/kuHU1oBWmis3EE4GM9510pdUdUw=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=rLS9hCuI5buCM3JlFk2RLoWrURT5+QlYP99V3CvmCkul5oozSHnq8pBPUiqsaE4ES t/K6iO8RV8yUa6xlCFf/ycL7TBVopou67mnETia+fhsX3mhTlqodv7F0XZ7FlyfyyU 5EB/Izo6kJbimE8cD2tS7Wd8d+kXEVMYCk7pXDgg= Message-Id: <6.2.5.6.2.20120305161554.0af9d860@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 05 Mar 2012 16:46:30 -0800 To: Hector Santos From: S Moonesamy In-Reply-To: <4F555303.6040802@isdg.net> References: <20120305175124.GR76465@crankycanuck.ca> <4F5511CC.9070206@tana.it> <4F551EBD.10309@isdg.net> <6.2.5.6.2.20120305142958.09f03368@resistor.net> <4F555303.6040802@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 06 Mar 2012 00:48:13 -0000 Hi Hector, At 15:57 05-03-2012, Hector Santos wrote: >I don't believe it is of value to repeat what was ready stated to >you and AS offlist. In this "first message" it is filled with >explicit statements of preemption of what is considered constructive or not. I have read Andrew's messages. What he has been trying to do is to provide fair notice. Could we please avoid such comments in future? >What is vexing to me is why it appears to be a burden or need to >repeatedly restate the concerns on-list or off-list? I tried a new >approach with the "Cooperative Competitive" statement in this 2nd >message. I really don't know how else it can stated. Andrew and I are here to ensure that your technical comments, as any other WG participant, is given due consideration. This is not based on four out of five comments. There will be a Working Group Last Call on all the drafts before they are submitted to the IESG. There will also be an IETF Last Call. If anyone considers that the working group made an incorrect decision, the person can raise the issues so that they are given due consideration. The comments submitted during an IETF Last Call are evaluated by the IESG. If you have any concern, please contact us at spfbis-chairs@tools.ietf.org. Regards, S. Moonesamy From hsantos@isdg.net Mon Mar 5 17:25:08 2012 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 B8B0121F867B for ; Mon, 5 Mar 2012 17:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.441, 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 LmC6gzCZZKXU for ; Mon, 5 Mar 2012 17:25:08 -0800 (PST) Received: from catinthebox.net (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D7BBB21F8628 for ; Mon, 5 Mar 2012 17:25:07 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1935; t=1330997101; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=oXOzUNIsM21QqainaTbLI/NLEIQ=; b=kCBDa2Pb4Mtrz4Ek4FaC iI8u6R21wjf2tOfLp3Kq9BD//sBhc4qwKS+CMuhm2CX9biluvOW8hmj603qPYICm VvII8dfIOnjPHcLrPBdK9bUmzKSzux85jLeVtmSDy2qxDaOcXPQWlvaZ+WLtdtkg fFafcQmTiBo1Kd7lVxAUE0I= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 05 Mar 2012 20:25:01 -0500 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 v6.4.454.1) with ESMTP id 4198934068.4276.4092; Mon, 05 Mar 2012 20:25:00 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1935; t=1330996838; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=HTs8e0Y eFejMJFvq5zA+wLccZn7P3jL6ZXYQUTrp59E=; b=0VS1CwmORrqwjucg8afIjdD C7QTM60kS/wNPHmv23CLaKQSu61lF2UXIxhLraKtUnKB1XoLxmfpkyDMSrmorTAX RZYslpuUJnUV7JT/6CxMiIteUSfxxFN/dE97BtiZ9maUAUCpb2ETs+b0DauJXHp+ FCjj5RlM2sgoFHqFMmXI= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 05 Mar 2012 20:20:38 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 502894299.24871.6100; Mon, 05 Mar 2012 20:20:38 -0500 Message-ID: <4F55678A.2000608@isdg.net> Date: Mon, 05 Mar 2012 20:25:30 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120305175124.GR76465@crankycanuck.ca> <4F5511CC.9070206@tana.it> <4F551EBD.10309@isdg.net> <6.2.5.6.2.20120305142958.09f03368@resistor.net> <4F555303.6040802@isdg.net> <6.2.5.6.2.20120305161554.0af9d860@resistor.net> In-Reply-To: <6.2.5.6.2.20120305161554.0af9d860@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 06 Mar 2012 01:25:08 -0000 S Moonesamy wrote: > Hi Hector, > At 15:57 05-03-2012, Hector Santos wrote: >> I don't believe it is of value to repeat what was ready stated to you >> and AS offlist. In this "first message" it is filled with explicit >> statements of preemption of what is considered constructive or not. > > I have read Andrew's messages. What he has been trying to do is to > provide fair notice. Could we please avoid such comments in future? Did you go again! But fair enough. I also suggest to not ask a direct question in public to me designed to put me in the defensive when in fact, you already knew the answer. > There will be a Working Group Last Call on all the drafts before they > are submitted to the IESG. There will also be an IETF Last Call. If > anyone considers that the working group made an incorrect decision, the > person can raise the issues so that they are given due consideration. Right, this is part of issue. The concerns has been stated, the outcome predetermined, the conflicts are obvious and this simply says to just puts it aside and its almost guaranteed to exclude the original concerns come LC. It leaves one in a very dead horse position with only one recourse - IETF Appeal which ironically I already been told "Don't bother!" So that said, I'm giving up. I don't need to support whatever SPF-BIF changes anyway. This is another DKIM situation, its all about DKIM, not SPF. It was really never about SPF. I already have a few off-list friendly wagers which I hope I would lose, but I doubt it. There is only way I see this being successful, change the charter to make explicitly out of scope: - DKIM - AUTH-RES - USING DKIM TO EVALUATE SENDER-ID/SUBMITTER FATE. Anyway the good news, I'm subscribing off this DKIM-SPF-BIS list. That should help drive it consensus by Osmosis. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From dhc@dcrocker.net Mon Mar 5 19:23:04 2012 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 3F50C21F8554 for ; Mon, 5 Mar 2012 19:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.607 X-Spam-Level: X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 rFWNqBPSUMy9 for ; Mon, 5 Mar 2012 19:23:03 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id AE61721F8516 for ; Mon, 5 Mar 2012 19:23:03 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q263MvxF015383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Mar 2012 19:23:03 -0800 Message-ID: <4F558307.10802@dcrocker.net> Date: Mon, 05 Mar 2012 19:22:47 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20120305175124.GR76465@crankycanuck.ca> <9452079D1A51524AA5749AD23E00392807ABC2@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392807ABC2@exch-mbx901.corp.cloudmark.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.17]); Mon, 05 Mar 2012 19:23:03 -0800 (PST) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 06 Mar 2012 03:23:04 -0000 On 3/5/2012 10:01 AM, Murray S. Kucherawy wrote: >> If the WG adopts the draft, we expect to appoint Murray as editor >> assuming that he is amenable and has time. > > Yes, and yes. Do I count as one of the five? :-) that sounds like a conflict of interest... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From john@jlc.net Tue Mar 6 08:22:47 2012 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 A59F721F8A0B for ; Tue, 6 Mar 2012 08:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.337 X-Spam-Level: X-Spam-Status: No, score=-106.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 4PO7h1eCN5qC for ; Tue, 6 Mar 2012 08:22:45 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2197021F8964 for ; Tue, 6 Mar 2012 08:22:45 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 42D3133C4A; Tue, 6 Mar 2012 11:22:45 -0500 (EST) Date: Tue, 6 Mar 2012 11:22:45 -0500 From: John Leslie To: dcrocker@bbiw.net Message-ID: <20120306162245.GG77987@verdi> References: <20120305175124.GR76465@crankycanuck.ca> <9452079D1A51524AA5749AD23E00392807ABC2@exch-mbx901.corp.cloudmark.com> <4F558307.10802@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F558307.10802@dcrocker.net> User-Agent: Mutt/1.4.1i Cc: "spfbis@ietf.org" , "Murray S. Kucherawy" Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 06 Mar 2012 16:22:47 -0000 Dave Crocker wrote: > On 3/5/2012 10:01 AM, Murray S. Kucherawy wrote: > >>> If the WG adopts the draft, we expect to appoint Murray as editor >>> assuming that he is amenable and has time. >> >> Yes, and yes. Do I count as one of the five? :-) > > that sounds like a conflict of interest... ... or an interest of conflict??? ;^) BTW, I will definitely comment once it's a WG draft. (Whether that will be "contributing" may be in the eye of the beholder...) -- John Leslie From dhc@dcrocker.net Tue Mar 6 08:33:38 2012 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 AC05921F86D5 for ; Tue, 6 Mar 2012 08:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.607 X-Spam-Level: X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 0xDvyBOekpsS for ; Tue, 6 Mar 2012 08:33:38 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id DEACA21F884A for ; Tue, 6 Mar 2012 08:33:36 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q26GXTcs005225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Mar 2012 08:33:34 -0800 Message-ID: <4F563C4F.3050706@dcrocker.net> Date: Tue, 06 Mar 2012 08:33:19 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "spfbis@ietf.org" References: <20120305175124.GR76465@crankycanuck.ca> <9452079D1A51524AA5749AD23E00392807ABC2@exch-mbx901.corp.cloudmark.com> <4F558307.10802@dcrocker.net> In-Reply-To: <4F558307.10802@dcrocker.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.17]); Tue, 06 Mar 2012 08:33:34 -0800 (PST) Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 06 Mar 2012 16:33:38 -0000 On 3/5/2012 7:22 PM, Dave Crocker wrote: > On 3/5/2012 10:01 AM, Murray S. Kucherawy wrote: >>> If the WG adopts the draft, we expect to appoint Murray as editor >>> assuming that he is amenable and has time. >> >> Yes, and yes. Do I count as one of the five? :-) > > that sounds like a conflict of interest... Just realized that I was so focused on being clever, that I forgot to add my unconflicted votes in favor of adopting the draft and assigning Murray as the editor for it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Tue Mar 6 08:34:58 2012 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 47BDE21F87C1 for ; Tue, 6 Mar 2012 08:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 rXwtz6TsBVKO for ; Tue, 6 Mar 2012 08:34:57 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CB48321F86C8 for ; Tue, 6 Mar 2012 08:34:48 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id F10F420E4126; Tue, 6 Mar 2012 11:34:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331051688; bh=96ZuMV+q7Pjc1bbyEAn0Gl30sDo5+J7k3wNWdNV7isU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=CIOn3I8qd/JeDejuJJ9+uXB/oPjJT4iHr0JojBlW+c5jkPUki3kpXtKQoDWCLu8Eq Amky/fHxyfq+rfe2URlWXe5Cdu8PDihqoRNd6K4iDTWH+1VEiPhh3vyS4ASObMj9ro JMsGNft7hIHnGPDjZ5VDgf8JmR3a0FrNXHv/RG04= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E4BE020E4043; Tue, 6 Mar 2012 11:34:47 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 06 Mar 2012 11:34:47 -0500 Message-ID: <1508272.ca9gNiCPaJ@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F563C4F.3050706@dcrocker.net> References: <20120305175124.GR76465@crankycanuck.ca> <4F558307.10802@dcrocker.net> <4F563C4F.3050706@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] Request adoption of draft-kucherawy-spfbis-experiment 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, 06 Mar 2012 16:34:58 -0000 On Tuesday, March 06, 2012 08:33:19 AM Dave Crocker wrote: > On 3/5/2012 7:22 PM, Dave Crocker wrote: > > On 3/5/2012 10:01 AM, Murray S. Kucherawy wrote: > >>> If the WG adopts the draft, we expect to appoint Murray as editor > >>> assuming that he is amenable and has time. > >> > >> Yes, and yes. Do I count as one of the five? :-) > > > > that sounds like a conflict of interest... > > Just realized that I was so focused on being clever, that I forgot to add my > unconflicted votes in favor of adopting the draft and assigning Murray as > the editor for it. Since we're being snarky today ... I thought the IETF didn't vote? Scott K From dhc@dcrocker.net Tue Mar 6 08:43:40 2012 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 B910321F864E for ; Tue, 6 Mar 2012 08:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.607 X-Spam-Level: X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 hMRo4P8tWVou for ; Tue, 6 Mar 2012 08:43:40 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0830821F8644 for ; Tue, 6 Mar 2012 08:43:40 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q26GhYQd005503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Mar 2012 08:43:39 -0800 Message-ID: <4F563EAC.6030500@dcrocker.net> Date: Tue, 06 Mar 2012 08:43:24 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120305175124.GR76465@crankycanuck.ca> <4F558307.10802@dcrocker.net> <4F563C4F.3050706@dcrocker.net> <1508272.ca9gNiCPaJ@scott-latitude-e6320> In-Reply-To: <1508272.ca9gNiCPaJ@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.17]); Tue, 06 Mar 2012 08:43:39 -0800 (PST) Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 06 Mar 2012 16:43:40 -0000 On 3/6/2012 8:34 AM, Scott Kitterman wrote: >> Just realized that I was so focused on being clever, that I forgot to add my >> unconflicted votes in favor of adopting the draft and assigning Murray as >> the editor for it. > > Since we're being snarky today ... > > I thought the IETF didn't vote? mumble. right. grrr. what do we call a +1? d/ ps. I was being snarky /yesterday/. Today I'm trying to be constructive. -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Tue Mar 6 09:14:23 2012 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 D81C921F8453 for ; Tue, 6 Mar 2012 09:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 vuptxgvxcxvY for ; Tue, 6 Mar 2012 09:14:21 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 648C421E80A4 for ; Tue, 6 Mar 2012 09:14:21 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.233.157]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q26HE8xQ001141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Mar 2012 09:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331054059; i=@elandsys.com; bh=6UNwV5oPmAajv8/f1syp1iyqXuxRcxM07g4X/IesMR8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=jiQmkfY9g4GgC+DkzuaE8eEbDkrLfM/PS0N9pXV0G/Yudv7Sz8+UnapmuERvAFM4j dz3uo7FLu8BQH7DEPGrtT2PeZpjzFYkMYJvsiSmVJ4ryTsvJZuuaYWXl5gBazxmTdB u9NqQlWB+kiOwWLFD/RkOj5RzXYJ6xl66Q6GQNCs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331054059; i=@elandsys.com; bh=6UNwV5oPmAajv8/f1syp1iyqXuxRcxM07g4X/IesMR8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=bQ7bmAMNSNMXsf3MWF6LHjWLrfYfsWrHnsRdMX1CmGaDv0kSRCzuY3uiVMczMoo5z 35nLqxlvElkkJmutsFJkjcQztTUEdIOPrTF0ORmetA9aWU51lXM15Sx+AwYDBbyoLT 67hb9iZu2YE1BowQ0V6Nv7u7/g/dRRQ1JfGrBVJQ= Message-Id: <6.2.5.6.2.20120306091044.0b9a15b0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 06 Mar 2012 09:13:24 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 06 Mar 2012 17:14:24 -0000 At 18:56 21-02-2012, spfbis issue tracker wrote: >#24: RFC 4408: Reasonable DNS error limits > > Message from Douglas otis on 21 Feb 2012: > > Each of 10 SPF mechanisms may require 10 separate reflected DNS > resolutions where SPF is insensitive to the number of No Data responses in > multiples of 100 DNS transactions. There is no limit for the number of No > Data results, which represents a likely method malefactors might use in > conjunction with local-part macros to implement DNS based attacks. The > gain of this attack depends on whether SPF/TXT, HELO/EHLO, Mail From, and > PRA checks are made for each message. Network amplification that could > result is substantial. This risk can be significantly mitigated by simply > imposing reasonable No Data limits. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00501.html [snip] >Ticket URL: Please comment on the above issue. As a reminder, please keep the subject line so that the discussion can be tracked easily. Regards, S. Moonesamy SPFBIS WG co-chair From pgladstone@cisco.com Tue Mar 6 09:23:27 2012 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 1147921E807F for ; Tue, 6 Mar 2012 09:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.728 X-Spam-Level: X-Spam-Status: No, score=-7.728 tagged_above=-999 required=5 tests=[AWL=2.870, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 rglBcYrbWnlm for ; Tue, 6 Mar 2012 09:23:26 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 495C821F8859 for ; Tue, 6 Mar 2012 09:23:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=1903; q=dns/txt; s=iport; t=1331054606; x=1332264206; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=l8/atlTNf5VDUI8yBS4hov6EfVQIMh9oD15wy4rkw60=; b=J5sRCpt6v+FR6MZ2T9pVR4+t07lc6vYOXiSWMu8ZApO5W1llhXGUtevl 6f+mzMLA428F+Wpy6MLliLLDeDEKsdls/J03LCvSnSBjgDgInLVr7+e3B JNcOV+hpWlWpSuJnyoNv4fBZHQigBLZ21KdH9L8jE9n+kMXMFVcSKaNth A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYFAN1HVk+rRDoG/2dsb2JhbABDhTSsOIMCgQeBdAUEAQEBBBIBEFURCwMBFAkWCwICCQMCAQIBRRMIAQEehSYHgicQAZpEAYxnkjKNPIIMgRYEiFKMbYVjijODAQ X-IronPort-AV: E=Sophos;i="4.73,540,1325462400"; d="scan'208,217";a="34810907" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 06 Mar 2012 17:23:25 +0000 Received: from [161.44.106.143] (dhcp-161-44-106-143.cisco.com [161.44.106.143]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q26HNPx6016857 for ; Tue, 6 Mar 2012 17:23:25 GMT Message-ID: <4F56480C.9040607@cisco.com> Date: Tue, 06 Mar 2012 12:23:24 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <6.2.5.6.2.20120306091044.0b9a15b0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120306091044.0b9a15b0@elandnews.com> Content-Type: multipart/alternative; boundary="------------010406090205090805080609" Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 06 Mar 2012 17:23:27 -0000 This is a multi-part message in MIME format. --------------010406090205090805080609 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/6/2012 12:13 PM, S Moonesamy wrote: > At 18:56 21-02-2012, spfbis issue tracker wrote: >> #24: RFC 4408: Reasonable DNS error limits >> > Please comment on the above issue. As a reminder, please keep the > subject line so that the discussion can be tracked easily. > The "exists" mechanism is designed to test for the existence of a DNS record. I do not believe that DNS errors should be counted for this mechanism. The number of "exists" mechanisms that can be invoked is small, so there doesn't appear to be a risk here. Philip --------------010406090205090805080609 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 3/6/2012 12:13 PM, S Moonesamy wrote:
At 18:56 21-02-2012, spfbis issue tracker wrote:
#24: RFC 4408: Reasonable DNS error limits

Please comment on the above issue.  As a reminder, please keep the subject line so that the discussion can be tracked easily.

The "exists" mechanism is designed to test for the existence of a DNS record. I do not believe that DNS errors should be counted for this mechanism. The number of "exists" mechanisms that can be invoked is small, so there doesn't appear to be a risk here.

Philip
--------------010406090205090805080609-- From spf2@kitterman.com Tue Mar 6 09:27:30 2012 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 0A3B821F88C5 for ; Tue, 6 Mar 2012 09:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 4BEROAzStUVX for ; Tue, 6 Mar 2012 09:27:29 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 47F7521F87B3 for ; Tue, 6 Mar 2012 09:27:29 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9B2A520E4126; Tue, 6 Mar 2012 12:27:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331054848; bh=u/YcL0cEC1eCoCiL0EX8v4nbvh/gmNd3fn1bxC45qkM=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=iERkp1x9mj7J4+N8rgGK8ggM62YDhcptb6aY5INSXkZn8aPCj3oUcwBUVicgg6zM1 X1JIayUCDMjaq0evMHllbZUJ7Fkx9hzbBCMswLWBko0XPTfeDjguW3LMyAkJo12YeM zH+iAlgkArJ04i2bh30FcLMnlQigX02lYKzvjjWU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7D00220E4043; Tue, 6 Mar 2012 12:27:28 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 06 Mar 2012 12:27:27 -0500 Message-ID: <3321896.9R8WsgF0d8@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120306091044.0b9a15b0@elandnews.com> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <6.2.5.6.2.20120306091044.0b9a15b0@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] #24: RFC 4408: Reasonable DNS error limits 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, 06 Mar 2012 17:27:30 -0000 On Tuesday, March 06, 2012 09:13:24 AM S Moonesamy wrote: I think the actionable part of the issue is: ... > This risk can be significantly mitigated by simply imposing reasonable No Data limits. ... This is an interesting idea. As I mentioned when this was suggested, this is already implemented in Mail::SPF max_void_dns_lookups. From the Mail::SPF documentation: > An I denoting the maximum number of "void" DNS look-ups per SPF > check, i.e. the number of DNS look-ups that were caused by DNS-interactive > terms and macros (as defined in RFC 4408, 10.1, paragraphs 6 and 7) and > that are allowed to return an empty answer with RCODE 0 or RCODE 3 > (C) before processing is aborted with a C result. > If B is specified, there is no stricter limit on the number of > void DNS look-ups beyond the usual processing limits. Defaults to B<2>. > > Specifically, the DNS look-ups that are subject to this limit are those > caused by the C, C, C, and C mechanisms and the C

> macro. > > A value of B<2> is likely to prevent effective DoS attacks against > third-party victim domains. However, a definite limit may cause > C results even with certain (overly complex) innocent sender > policies where useful results would normally be returned. This proposal may affect currently published and RFC 4408 compliant records as it is silent on this type of limitation. I suspect, however, that for an appropriate value as the limit, this type of limit could be added to 4408bis without affecting interoperability. In order to determine this, we'll need a survey of records to get a distribution of the number of void DNS lookups in SPF records. I'm not sure how much we can do with the issue until we have data. Scott K From pmidge@microsoft.com Tue Mar 6 09:29:21 2012 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 6F00C21F88C6 for ; Tue, 6 Mar 2012 09:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.900, 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 ug-xQx5tlX2T for ; Tue, 6 Mar 2012 09:29:21 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id CF58A21F88D6 for ; Tue, 6 Mar 2012 09:29:20 -0800 (PST) Received: from mail159-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 6 Mar 2012 17:29:20 +0000 Received: from mail159-tx2 (localhost [127.0.0.1]) by mail159-tx2-R.bigfish.com (Postfix) with ESMTP id 73802340160; Tue, 6 Mar 2012 17:29:20 +0000 (UTC) X-SpamScore: -41 X-BigFish: VS-41(zzbb2dI9371I1803M542M1432N98dKzz1202hzz8275ch1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail159-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail159-tx2 (localhost.localdomain [127.0.0.1]) by mail159-tx2 (MessageSwitch) id 1331054959183606_8494; Tue, 6 Mar 2012 17:29:19 +0000 (UTC) Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.252]) by mail159-tx2.bigfish.com (Postfix) with ESMTP id 24F4512004A; Tue, 6 Mar 2012 17:29:19 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 6 Mar 2012 17:29:15 +0000 Received: from TK5EX14MBXC204.redmond.corp.microsoft.com ([169.254.5.122]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0283.004; Tue, 6 Mar 2012 17:28:56 +0000 From: Paul Midgen To: "dcrocker@bbiw.net" , "spfbis@ietf.org" Thread-Topic: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment Thread-Index: AQHM+vibX/m59NP77k24jMyM2u4cyJZb/hqAgACcwoCAANzfgIAAAGmAgAACaQCAAAxqgA== Date: Tue, 6 Mar 2012 17:28:55 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E2050BD50@TK5EX14MBXC204.redmond.corp.microsoft.com> References: <20120305175124.GR76465@crankycanuck.ca> <4F558307.10802@dcrocker.net> <4F563C4F.3050706@dcrocker.net> <1508272.ca9gNiCPaJ@scott-latitude-e6320> <4F563EAC.6030500@dcrocker.net> In-Reply-To: <4F563EAC.6030500@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 06 Mar 2012 17:29:21 -0000 discrete cumulative non-parliamentary concurrence -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Dave Crocker Sent: Tuesday, March 06, 2012 8:43 AM To: spfbis@ietf.org Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment On 3/6/2012 8:34 AM, Scott Kitterman wrote: >> Just realized that I was so focused on being clever, that I forgot to=20 >> add my unconflicted votes in favor of adopting the draft and=20 >> assigning Murray as the editor for it. > > Since we're being snarky today ... > > I thought the IETF didn't vote? mumble. right. grrr. what do we call a +1? d/ ps. I was being snarky /yesterday/. Today I'm trying to be constructive. --=20 Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Tue Mar 6 09:36:58 2012 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 0D39D11E808A for ; Tue, 6 Mar 2012 09:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 bssZZqR1GAkU for ; Tue, 6 Mar 2012 09:36:57 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4E04811E8074 for ; Tue, 6 Mar 2012 09:36:57 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B1A0820E4126; Tue, 6 Mar 2012 12:36:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331055416; bh=IMnJ2eDQ7IP/BoUhwfWHhG3JGSdtgNk5UrQL1SF5Kxc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=FZDh2Km8mTYAAYtdq5z9I8+2RsXhvyTLGWndXpDK8QABbAbEhDgqOG5pay9ZtshNT 4lcORqQqyj8QmFLD2+7S6d8ofE6U2zLmxruXk+8FnisSVzpqhDX9MYUEAqc7sai1+J b08KN/hhZOZVpnSG3xfr0Xz39X68HAOsPSjVoV/o= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 92E2D20E4043; Tue, 6 Mar 2012 12:36:56 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 06 Mar 2012 12:36:55 -0500 Message-ID: <2366777.pcBLt6pdkU@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F56480C.9040607@cisco.com> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <6.2.5.6.2.20120306091044.0b9a15b0@elandnews.com> <4F56480C.9040607@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] #24: RFC 4408: Reasonable DNS error limits 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, 06 Mar 2012 17:36:58 -0000 On Tuesday, March 06, 2012 12:23:24 PM Philip Gladstone wrote: > On 3/6/2012 12:13 PM, S Moonesamy wrote: > > At 18:56 21-02-2012, spfbis issue tracker wrote: > >> #24: RFC 4408: Reasonable DNS error limits > > > > Please comment on the above issue. As a reminder, please keep the > > subject line so that the discussion can be tracked easily. > > The "exists" mechanism is designed to test for the existence of a DNS > record. I do not believe that DNS errors should be counted for this > mechanism. The number of "exists" mechanisms that can be invoked is > small, so there doesn't appear to be a risk here. It's either that or count it and you've effectively limited the number of exists mechanisms in one SPF record to ~whatever limit we set. Since exists is rarely used and rarely included, I think it would be OK to limit it to a few per record. OTOH, exists can't provoke further lookups, so it should be OK not to count. I think either approach would be OK (assuming we get a good survey that determines this type of limit is OK in general). It's probably marginally simpler to conceptualize not counting exists for users crafting records. It's probably marginally easier to implement counting all no data results than all but exists. Tossup. Since there's a lot more people writing SPF records than writing SPF libraries, I think I agree with you. Scott K From sm@elandsys.com Tue Mar 6 09:44:37 2012 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 4512821F85E4 for ; Tue, 6 Mar 2012 09:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 mG0dbXYAbXE9 for ; Tue, 6 Mar 2012 09:44:34 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CAC21E80A9 for ; Tue, 6 Mar 2012 09:44:33 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.233.157]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q26HiKSc025999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Mar 2012 09:44:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331055872; i=@elandsys.com; bh=ubKZWsL4fCO2oyPU9Z37mdkhOzki1d1/uOa3n4vrK4g=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=XsOKy36F0001d3+SmdWhCT+PZsC2HXlYBgtQ5wYzeotGo9n3FqgT2VVN7YGDRvIxF cBpmdjuRQ8D0UNnre+mB351inovqmaP4mduD5pjR4CcbUjxYWuy6GcpyapUYQprM02 HZbxFLBEQJT4CEVkPVk7eedVWvs6bEApjd1LUHpc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331055872; i=@elandsys.com; bh=ubKZWsL4fCO2oyPU9Z37mdkhOzki1d1/uOa3n4vrK4g=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=SBYA1rsBTTNIayGZ0GiDlL2cnyB3FOICCyn3MhzyH1jWFooKJ6y5mcHUjUCet82sL kKjEkUB4oaxcLqjAry1GzXAmmoIAWUjslKmajcUk0wAtvBVCwXWKv3tLNv54Yxvoz7 Ji1rmWkw8uH7JPNFTecLYN9hfIv5unqxpwW62D98= Message-Id: <6.2.5.6.2.20120306092159.0ac145d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 06 Mar 2012 09:37:50 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1330458545.56033.YahooMailClassic@web125403.mail.ne1.yahoo .com> References: <1330458545.56033.YahooMailClassic@web125403.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 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, 06 Mar 2012 17:44:37 -0000 Hello, I'll attempt to summarize the discussion of Issue #1. If I misinterpreted or misunderstood your comments, please let me know. The issue was based on the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg00279.html Scott Kitterman mentioned that it is out of scope and that SUBMITTER is a Sender ID concept unrelated to SPF [1]. Murray Kucherawy commented on adding SUBMITTER as an optional parameter to check_host() falls within none of those clauses of the charter [2]. Dotzero agreed that it should be considered out of scope [3]. Hector Santos mentioned that "enable the SUBMITTER SMTP extension in your SMTP server and there is clear evidence of wide client support". He also mentioned that if there is a possibility 4405/4406 is not going to be abandoned, then SPF-BIS has a clear role to consider it [4]. John Levine commented on it being a terrible idea [5]. Rolf Sonneveld commented that it was out of scope [6]. Alessandro Vesely mentioned that SPF already has two identities --mfrom and helo-- that maycomplement one another [7]. Hector Santos mentioned that SIDF/SUBMITTER offered the 3rd identity - PRA; he doesn't see it as out of scope if the charter includes consideration for the fate of 4405/4406/4407 [8]. Arthur Thisell mentioned that the change to add submitter to check_hosts is, in itself, obviously bogus since it adds a term that is not defined or used anywhere else in the document [9]. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00695.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00696.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00697.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00698.html 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg00700.html 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg00701.html 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg00702.html 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg00703.html 9. http://www.ietf.org/mail-archive/web/spfbis/current/msg00706.html From john@jlc.net Tue Mar 6 10:02:01 2012 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 DBE1411E808A for ; Tue, 6 Mar 2012 10:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.341 X-Spam-Level: X-Spam-Status: No, score=-106.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 GTfEtdeJYGpr for ; Tue, 6 Mar 2012 10:02:01 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4A17311E8087 for ; Tue, 6 Mar 2012 10:02:01 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 313E333CC1; Tue, 6 Mar 2012 13:02:01 -0500 (EST) Date: Tue, 6 Mar 2012 13:02:01 -0500 From: John Leslie To: S Moonesamy Message-ID: <20120306180201.GH77987@verdi> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <6.2.5.6.2.20120306091044.0b9a15b0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120306091044.0b9a15b0@elandnews.com> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 06 Mar 2012 18:02:02 -0000 S Moonesamy wrote: > > Please comment... >> >> Message from Douglas otis on 21 Feb 2012: >> >> Each of 10 SPF mechanisms may require 10 separate reflected DNS >> resolutions where SPF is insensitive to the number of No Data responses in >> multiples of 100 DNS transactions. There is no limit for the number of No >> Data results, which represents a likely method malefactors might use in >> conjunction with local-part macros to implement DNS based attacks. The >> gain of this attack depends on whether SPF/TXT, HELO/EHLO, Mail From, and >> PRA checks are made for each message. Network amplification that could >> result is substantial. This risk can be significantly mitigated by simply >> imposing reasonable No Data limits. Doug is calling out a possible abuse situation, wherein an SPF record can call for more than one DNS lookup to a domain quite unrelated to the sending MTA. This deserves discussion on one of our RFCs -- I shall leave it for others to argue which one... Be warned that "It hasn't happened yet" may not be a sufficient discussion. The essential point, IMHO, is that any no-data response is a hint of abuse; thus action to impose a limit on the rate of such queries after a no-data response may be appropriate. Likewise, no-response may mean that a DDoS is succeeding; and an even stricter limit might make sense. The other side of the argument is that these macros are _sometimes_ useful. We have seen them useful in gathering data on actual usage. And there are situations in which different policies _must_ apply to different local-parts. All this suggests to me that there may not _be_ a single limit which makes sense. I suggest we consider "MAY" language here -- admitting that we can't know how this issue might play out over the next decade. Instead of trying for a maximum number of such queries, could we consider instead what the _minimum_ might be to accomplish identified valid usage, and specify MAY for any queries beyond that minimum? -- John Leslie From spf2@kitterman.com Tue Mar 6 10:02:34 2012 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 242F311E8076 for ; Tue, 6 Mar 2012 10:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 7HPZ-Ny2IPG9 for ; Tue, 6 Mar 2012 10:02:33 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7EA11E8075 for ; Tue, 6 Mar 2012 10:02:33 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D5C1420E412E; Tue, 6 Mar 2012 13:02:32 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331056952; bh=sCusKFvn1hE1rtWXrYvZkStOzIMdYcmJGh4p6w6oVnw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=P+y29Dmd125fpD62Os+undWvZUPXHPQnwXmJqIaG8J2BrlyC6keon3eFtWLzgt7vy BwY6YjnM/TLoIgk83UntJxRrS+AeHbJlhkwIIjjvUt/Up5+6C9smuJCVVZsJguiAHO rxRKoXrxlZuuuzIOW2Sg8Mai1s5KRpxLNk3OPzfA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B8F6320E4043; Tue, 6 Mar 2012 13:02:32 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 06 Mar 2012 13:02:32 -0500 Message-ID: <13867734.712E7WYHa9@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120306092159.0ac145d0@resistor.net> References: <1330458545.56033.YahooMailClassic@web125403.mail.ne1.yahoo.com> <6.2.5.6.2.20120306092159.0ac145d0@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] #4: RFC 4408 Section 4.1 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, 06 Mar 2012 18:02:34 -0000 On Tuesday, March 06, 2012 09:37:50 AM S Moonesamy wrote: > Hello, > > I'll attempt to summarize the discussion of Issue #1. If I > misinterpreted or misunderstood your comments, please let me > know. The issue was based on the message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg00279.html > > Scott Kitterman mentioned that it is out of scope and that SUBMITTER > is a Sender ID concept unrelated to SPF [1]. Murray Kucherawy > commented on adding SUBMITTER as an optional parameter to > check_host() falls within none of those clauses of the charter > [2]. Dotzero agreed that it should be considered out of scope [3]. > > Hector Santos mentioned that "enable the SUBMITTER SMTP extension in > your SMTP server and there is clear evidence of wide client > support". He also mentioned that if there is a possibility 4405/4406 > is not going to be abandoned, then SPF-BIS has a clear role to consider it > [4]. > > John Levine commented on it being a terrible idea [5]. Rolf > Sonneveld commented that it was out of scope [6]. Alessandro Vesely > mentioned that SPF already has two identities --mfrom and helo-- that > maycomplement one another [7]. Hector Santos mentioned that > SIDF/SUBMITTER offered the 3rd identity - PRA; he doesn't see it as > out of scope if the charter includes consideration for the fate of > 4405/4406/4407 [8]. > > Arthur Thisell mentioned that the change to add submitter to > check_hosts is, in itself, obviously bogus since it adds a term that > is not defined or used anywhere else in the document [9]. > > Regards, > S. Moonesamy > > 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00695.html > 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00696.html > 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00697.html > 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00698.html > 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg00700.html > 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg00701.html > 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg00702.html > 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg00703.html > 9. http://www.ietf.org/mail-archive/web/spfbis/current/msg00706.html I think that's a fair summary of what I said. I'll add that in addition to being out of scope for this WG, I think it's a "really bad" idea anyway. Scott K From msk@cloudmark.com Tue Mar 6 10:10:40 2012 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 5917721F87EC for ; Tue, 6 Mar 2012 10:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 YKzb4YTSg9Jx for ; Tue, 6 Mar 2012 10:10:39 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 50D1D21F87F3 for ; Tue, 6 Mar 2012 10:10:39 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Tue, 6 Mar 2012 10:10:38 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #4: RFC 4408 Section 4.1 Thread-Index: AQHM9lIGsUlHNgOq+ECYdMs9Ra10P5ZdlP44gAAGy+A= Date: Tue, 6 Mar 2012 18:10:37 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807CAEC@exch-mbx901.corp.cloudmark.com> References: <1330458545.56033.YahooMailClassic@web125403.mail.ne1.yahoo.com> <6.2.5.6.2.20120306092159.0ac145d0@resistor.net> In-Reply-To: <6.2.5.6.2.20120306092159.0ac145d0@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 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, 06 Mar 2012 18:10:40 -0000 Hi SM, > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of S Moonesamy > Sent: Tuesday, March 06, 2012 9:38 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 >=20 > Hello, >=20 > I'll attempt to summarize the discussion of Issue #1. If I > misinterpreted or misunderstood your comments, please let me > know. The issue was based on the message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg00279.html I think your summary is accurate. I also suggest that the only two dissent= ing opinions (from the same person) conflated the SUBMITTER issue as being = in scope for the WG but out of scope for the RFC4408bis document. It is po= ssible for both to be true, as is the case now. -MSK =20 From vesely@tana.it Tue Mar 6 10:12:21 2012 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 3CE7D21F87F3 for ; Tue, 6 Mar 2012 10:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.654 X-Spam-Level: X-Spam-Status: No, score=-4.654 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTzv2cr78vPS for ; Tue, 6 Mar 2012 10:12:20 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 65AA721F87ED for ; Tue, 6 Mar 2012 10:12:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1331057539; bh=6tDaBlztjmZ1EXHP6uWTm8h9sHQxW2CD1YktfPQFlyc=; l=1293; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=SlE9INdehwucnKnT4OfD/BD0lwOmEMPdJoX6Xm1qrEgIypNNYRahHHPP6puNe1AUZ eren4/9WOV8u4XRYfWjrrdwKkxvg47gtzD+f357wUy9IaBIyrGuEyClg5IQG0pv8Z6 ASRdyRDhPfBwM3jBgK0djwrbswjrRzvTKxzE2I8o= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 06 Mar 2012 19:12:19 +0100 id 00000000005DC035.000000004F565383.0000136B Message-ID: <4F565382.20804@tana.it> Date: Tue, 06 Mar 2012 19:12:18 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <6.2.5.6.2.20120306091044.0b9a15b0@elandnews.com> <4F56480C.9040607@cisco.com> <2366777.pcBLt6pdkU@scott-latitude-e6320> In-Reply-To: <2366777.pcBLt6pdkU@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 06 Mar 2012 18:12:21 -0000 On 06/Mar/12 18:36, Scott Kitterman wrote: > On Tuesday, March 06, 2012 12:23:24 PM Philip Gladstone wrote: >> >> The "exists" mechanism is designed to test for the existence of a DNS >> record. I do not believe that DNS errors should be counted for this >> mechanism. The number of "exists" mechanisms that can be invoked is >> small, so there doesn't appear to be a risk here. > > It's either that or count it and you've effectively limited the number of > exists mechanisms in one SPF record to ~whatever limit we set. Since exists > is rarely used and rarely included, I think it would be OK to limit it to a > few per record. OTOH, exists can't provoke further lookups, so it should be > OK not to count. I'd rather have the limit set at 11 than saying which lookups don't count. No exception, just for the sake of clarity. Redirect and include count, don't they? And the count is global, per call... but that is ticket #6. But what's puzzling me is the distinction between errors, no data, cached responses, and similar. Does it serve any practical purpose? If at all possible, I'd avoid any exception, so that, given an SPF record and the records recursively looked up via redirect and include, it is possible to statically state whether it is valid or not. From msk@cloudmark.com Tue Mar 6 10:18:32 2012 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 2759421F88D0 for ; Tue, 6 Mar 2012 10:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 ukMOmj-QCH-H for ; Tue, 6 Mar 2012 10:18:31 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B3C6D21F88CA for ; Tue, 6 Mar 2012 10:18:31 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Tue, 6 Mar 2012 10:18:31 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #24: RFC 4408: Reasonable DNS error limits Thread-Index: AQHM+7yYx93ZDimmwkGuor51xQ56+JZdkr5w Date: Tue, 6 Mar 2012 18:18:30 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807CB20@exch-mbx901.corp.cloudmark.com> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <6.2.5.6.2.20120306091044.0b9a15b0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120306091044.0b9a15b0@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 06 Mar 2012 18:18:32 -0000 I need some clarification on this issue before I can give an opinion. Some= one help me out here... Is the issue that I could publish an SPF policy that causes queries to some= one else's DNS as a means of an attack, and the proposed mitigation is to a= bort the query if too many NOERROR replies with zero answers (which I think= is what people mean by "No Data") are received? -MSK From john@jlc.net Tue Mar 6 10:18:59 2012 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 BF8B021F88DF for ; Tue, 6 Mar 2012 10:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.345 X-Spam-Level: X-Spam-Status: No, score=-106.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 VOWM52Uof71Q for ; Tue, 6 Mar 2012 10:18:57 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC3E21F88CA for ; Tue, 6 Mar 2012 10:18:57 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id C3EDA33CB2; Tue, 6 Mar 2012 13:18:57 -0500 (EST) Date: Tue, 6 Mar 2012 13:18:57 -0500 From: John Leslie To: S Moonesamy Message-ID: <20120306181857.GI77987@verdi> References: <1330458545.56033.YahooMailClassic@web125403.mail.ne1.yahoo.com> <6.2.5.6.2.20120306092159.0ac145d0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120306092159.0ac145d0@resistor.net> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 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, 06 Mar 2012 18:18:59 -0000 S Moonesamy wrote: > > I'll attempt to summarize the discussion of Issue #1. This is a typo, right -- you mean Issue #4? http://trac.tools.ietf.org/wg/spfbis/trac/ticket/4 > If I misinterpreted or misunderstood your comments, please let me > know. I interpreted these comments the same way. IMHO, the issue can mostly be laid to rest. Even Hector didn't think such a change to check_host() is in-charter. However, let us not forget that some (hopefully brief) review of RFC 4405 in our "result-of-experiment" document is in-charter. (I was sort-of hoping to hear from Hector what benefit he imagined from passing SUBMITTER to check_host(); but I doubt he could have convinced me it's a good idea...) -- John Leslie From msk@cloudmark.com Tue Mar 6 10:19:21 2012 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 B5D8C21F88DB for ; Tue, 6 Mar 2012 10:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 dhXWK0VJlxAm for ; Tue, 6 Mar 2012 10:19:21 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 55FCC21F88CA for ; Tue, 6 Mar 2012 10:19:21 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Tue, 6 Mar 2012 10:19:20 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment Thread-Index: AQHM+viuh+ryOLgSzUaSlnd8lXLsyZZb/eLwgAEjFoCAANzggP//l2lg Date: Tue, 6 Mar 2012 18:19:20 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807CB3C@exch-mbx901.corp.cloudmark.com> References: <20120305175124.GR76465@crankycanuck.ca> <9452079D1A51524AA5749AD23E00392807ABC2@exch-mbx901.corp.cloudmark.com> <4F558307.10802@dcrocker.net> <4F563C4F.3050706@dcrocker.net> In-Reply-To: <4F563C4F.3050706@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 06 Mar 2012 18:19:21 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dave Crocker > Sent: Tuesday, March 06, 2012 8:33 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis- > experiment >=20 > >> Yes, and yes. Do I count as one of the five? :-) > > > > that sounds like a conflict of interest... >=20 > Just realized that I was so focused on being clever, that I forgot to > add my unconflicted votes in favor of adopting the draft and assigning > Murray as the editor for it. Second answer. :-) From msk@cloudmark.com Tue Mar 6 10:20:38 2012 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 3DFE421F86E1 for ; Tue, 6 Mar 2012 10:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 8iLB4uY2At9o for ; Tue, 6 Mar 2012 10:20:37 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 97DD621F8675 for ; Tue, 6 Mar 2012 10:20:37 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Tue, 6 Mar 2012 10:20:37 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #4: RFC 4408 Section 4.1 Thread-Index: AQHM9lIGsUlHNgOq+ECYdMs9Ra10P5ZdlP44gACPqoD//3oWEA== Date: Tue, 6 Mar 2012 18:20:36 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807CB53@exch-mbx901.corp.cloudmark.com> References: <1330458545.56033.YahooMailClassic@web125403.mail.ne1.yahoo.com> <6.2.5.6.2.20120306092159.0ac145d0@resistor.net> <20120306181857.GI77987@verdi> In-Reply-To: <20120306181857.GI77987@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 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, 06 Mar 2012 18:20:38 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of John Leslie > Sent: Tuesday, March 06, 2012 10:19 AM > To: S Moonesamy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 >=20 > However, let us not forget that some (hopefully brief) review of RFC > 4405 in our "result-of-experiment" document is in-charter. I do indeed already have some treatment of the data Hector provided in the = individual submission. It will of course find its way into the working gro= up version of the document. -MSK From spf2@kitterman.com Tue Mar 6 10:43:51 2012 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 9301321F8518 for ; Tue, 6 Mar 2012 10:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 kXyxh3QQEqcB for ; Tue, 6 Mar 2012 10:43:50 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4645721F84D7 for ; Tue, 6 Mar 2012 10:43:50 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A4EA120E4126; Tue, 6 Mar 2012 13:43:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331059429; bh=ooW4oyJo8rvhghePSfm5bZlfjgiUDqGJhPkq9yngMks=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=f+1QQxM0W9I+II/vpbaSWR01BvMOb6oUYIevoZOZkK17u99CPOnwRp5zOZvhGyGkq lpkpUK19IQDiNVtzfLyLDICqvem1j/y6f83TTQqELqV5DnljkCx3RihUmnuxwp4244 D0D59PjvMi0ZgMBU2Hdf+CsuQKjixdxD2aVtqktg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 87BD420E4043; Tue, 6 Mar 2012 13:43:49 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 06 Mar 2012 13:43:48 -0500 Message-ID: <1503188.cxsYnuchm5@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120306180201.GH77987@verdi> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <6.2.5.6.2.20120306091044.0b9a15b0@elandnews.com> <20120306180201.GH77987@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] #24: RFC 4408: Reasonable DNS error limits 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, 06 Mar 2012 18:43:51 -0000 On Tuesday, March 06, 2012 01:02:01 PM John Leslie wrote: > S Moonesamy wrote: > > Please comment... > > > >> Message from Douglas otis on 21 Feb 2012: > >> > >> Each of 10 SPF mechanisms may require 10 separate reflected DNS > >> resolutions where SPF is insensitive to the number of No Data > >> responses in multiples of 100 DNS transactions. There is no limit > >> for the number of No Data results, which represents a likely method > >> malefactors might use in conjunction with local-part macros to > >> implement DNS based attacks. The gain of this attack depends on > >> whether SPF/TXT, HELO/EHLO, Mail From, and PRA checks are made for > >> each message. Network amplification that could result is > >> substantial. This risk can be significantly mitigated by simply > >> imposing reasonable No Data limits. > > Doug is calling out a possible abuse situation, wherein an SPF record > can call for more than one DNS lookup to a domain quite unrelated to the > sending MTA. > > This deserves discussion on one of our RFCs -- I shall leave it for > others to argue which one... > > Be warned that "It hasn't happened yet" may not be a sufficient > discussion. > > The essential point, IMHO, is that any no-data response is a hint of > abuse; thus action to impose a limit on the rate of such queries after > a no-data response may be appropriate. Likewise, no-response may mean > that a DDoS is succeeding; and an even stricter limit might make sense. > > The other side of the argument is that these macros are _sometimes_ > useful. We have seen them useful in gathering data on actual usage. > And there are situations in which different policies _must_ apply to > different local-parts. > > All this suggests to me that there may not _be_ a single limit which > makes sense. > > I suggest we consider "MAY" language here -- admitting that we can't > know how this issue might play out over the next decade. Instead of > trying for a maximum number of such queries, could we consider instead > what the _minimum_ might be to accomplish identified valid usage, and > specify MAY for any queries beyond that minimum? Despite the rhetoric in the issue, I don't think any changes with regards to macros are being proposed here. The only SPF mechanism that expects a nodata response in normal operations is exists: and I don't think there's a use case for multiple exists: per SPF record (except via include: or redirect=). The basic theory is not new and a detailed assessment of it was done several years ago: http://www.openspf.org/draft-otis-spf-dos-exploit_Analysis Fundamentally, there is no news here. If someone intendend to do an amplification attack like the rhetorical part of this issue describes, there are easier ways to do it than an SPF record. That said, the specific operational piece of the comment is implemented and in widespread use (Mail::SPF is the most used, AFAIK, open source SPF implementation), so I think it's reasonable to consider adding the void lookup limit in some form. Scott K From spf2@kitterman.com Tue Mar 6 10:45:45 2012 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 6F3FE21E807C for ; Tue, 6 Mar 2012 10:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 XRwODi-hb8OK for ; Tue, 6 Mar 2012 10:45:45 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 97BF921E8056 for ; Tue, 6 Mar 2012 10:45:43 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2D9B720E4126; Tue, 6 Mar 2012 13:45:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331059543; bh=9QX7fK+1/UhIMW0+135qZIt/Kwg6zK6U0fAVyTQuCxo=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=HqTpe0Cj4TmytE5U6R+Ga5a4Ukax6FmTbeZmn9YsRuVFflobJA7Q0u01eSlZZw3z2 au5J7+BrHIFBTUpaxuzv6Pad98b+/Wb/xDKNLI+DMFtC7g/2uUtheGEaEoRkg7ykhf T6r0AjGbZmTLl6tph1gSUCiHnElbHcp8WQn6bPeQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 15F8220E4043; Tue, 6 Mar 2012 13:45:42 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 06 Mar 2012 13:45:42 -0500 Message-ID: <1463655.1U633HA6jI@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E00392807CB20@exch-mbx901.corp.cloudmark.com> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <6.2.5.6.2.20120306091044.0b9a15b0@elandnews.com> <9452079D1A51524AA5749AD23E00392807CB20@exch-mbx901.corp.cloudmark.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] #24: RFC 4408: Reasonable DNS error limits 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, 06 Mar 2012 18:45:45 -0000 On Tuesday, March 06, 2012 06:18:30 PM Murray S. Kucherawy wrote: > I need some clarification on this issue before I can give an opinion. > Someone help me out here... > > Is the issue that I could publish an SPF policy that causes queries to > someone else's DNS as a means of an attack, and the proposed mitigation is > to abort the query if too many NOERROR replies with zero answers (which I > think is what people mean by "No Data") are received? I believe that's correct. Scott K From msk@cloudmark.com Tue Mar 6 11:03:34 2012 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 0F37621E80A4 for ; Tue, 6 Mar 2012 11:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 nOerwX9ju+yL for ; Tue, 6 Mar 2012 11:03:33 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 97EBD21E8096 for ; Tue, 6 Mar 2012 11:03:33 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Tue, 6 Mar 2012 11:03:33 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #24: RFC 4408: Reasonable DNS error limits Thread-Index: AQHM+7yYx93ZDimmwkGuor51xQ56+JZdkr5wgACOjwD//35T0A== Date: Tue, 6 Mar 2012 19:03:32 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807CDBA@exch-mbx901.corp.cloudmark.com> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <6.2.5.6.2.20120306091044.0b9a15b0@elandnews.com> <9452079D1A51524AA5749AD23E00392807CB20@exch-mbx901.corp.cloudmark.com> <1463655.1U633HA6jI@scott-latitude-e6320> In-Reply-To: <1463655.1U633HA6jI@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 06 Mar 2012 19:03:34 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > Behalf Of Scott Kitterman > Sent: Tuesday, March 06, 2012 10:46 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits >=20 > On Tuesday, March 06, 2012 06:18:30 PM Murray S. Kucherawy wrote: > > I need some clarification on this issue before I can give an opinion. > > Someone help me out here... > > > > Is the issue that I could publish an SPF policy that causes queries to > > someone else's DNS as a means of an attack, and the proposed > > mitigation is to abort the query if too many NOERROR replies with zero > > answers (which I think is what people mean by "No Data") are received? >=20 > I believe that's correct. I think the mitigation is weak, then. It thwarts the attack scenario in wh= ich I point my SPF record at some stuff in your domain that doesn't actuall= y exist, but if I use "mx" or other mechanisms that do hit things that exis= t, the attack isn't stopped. So I'm fine with the idea of specifying NODATA cutoff limits, but it doesn'= t cover the full threat space here, and we'll have to admit that in Securit= y Considerations or suchlike. -MSK From spf2@kitterman.com Tue Mar 6 11:06:46 2012 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 341D021F87DB for ; Tue, 6 Mar 2012 11:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 hrjKoyRL2fS8 for ; Tue, 6 Mar 2012 11:06:44 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 52DF721E8045 for ; Tue, 6 Mar 2012 11:06:40 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DA93320E4126; Tue, 6 Mar 2012 14:06:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331060799; bh=LOmSyV+G5vn8ik49iy163R83wqLolyN7kD3JCtjf8Uw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=B/pf1HOioh+11gf4bFwQqZuhy6h0H7ygUbDj9B0ntHuOwvmtxnXn6KjlKeDz1PGWq MTJJbHs9ibFtOTkGt7AfHvpZA+ngTOo0eqxhNswIu43Jc4+AVAuoAqysYaxyYdCPhI Y+m5G1f155p+rM5ztR/hmJlrSEN+kofjNfmfLxC0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C03F520E4043; Tue, 6 Mar 2012 14:06:39 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 06 Mar 2012 14:06:39 -0500 Message-ID: <1363560.TliLWEahbT@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E00392807CDBA@exch-mbx901.corp.cloudmark.com> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <1463655.1U633HA6jI@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807CDBA@exch-mbx901.corp.cloudmark.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] #24: RFC 4408: Reasonable DNS error limits 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, 06 Mar 2012 19:06:46 -0000 On Tuesday, March 06, 2012 07:03:32 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > > Behalf Of Scott Kitterman > > Sent: Tuesday, March 06, 2012 10:46 AM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits > > > > On Tuesday, March 06, 2012 06:18:30 PM Murray S. Kucherawy wrote: > > > I need some clarification on this issue before I can give an > > > opinion. > > > Someone help me out here... > > > > > > Is the issue that I could publish an SPF policy that causes queries > > > to > > > someone else's DNS as a means of an attack, and the proposed > > > mitigation is to abort the query if too many NOERROR replies with > > > zero > > > answers (which I think is what people mean by "No Data") are > > > received? > > > > I believe that's correct. > > I think the mitigation is weak, then. It thwarts the attack scenario in > which I point my SPF record at some stuff in your domain that doesn't > actually exist, but if I use "mx" or other mechanisms that do hit things > that exist, the attack isn't stopped. > > So I'm fine with the idea of specifying NODATA cutoff limits, but it doesn't > cover the full threat space here, and we'll have to admit that in Security > Considerations or suchlike. Certainly. To the extent there's a threat we'll need to document it. This isn't news since all the processing limits in RFC 4408 are in security considerations. We have another issue on splitting them out and making both the limits an dthe security considerations clearer. Scott K From sm@elandsys.com Tue Mar 6 11:22:39 2012 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 8C1E321E80B4 for ; Tue, 6 Mar 2012 11:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 hL5C+33L6xjO for ; Tue, 6 Mar 2012 11:22:38 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B971021E80AE for ; Tue, 6 Mar 2012 11:22:38 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.233.157]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q26JMQhw000293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Mar 2012 11:22:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331061757; i=@elandsys.com; bh=2uXvrdlLgv3kWZlq0QbqKFortIzfp1D9Lv1F/KS0Tkg=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=kJZCNWukx6cGp4wOc4eiVn/Cjw4bOymQCxpduGX4r4/mwm0VLmrQnW/ANPg6uQIkh p+EEgIC6vXCes69z6jJHIij6WeoniZobPnt71pBW+I45UKJHORab/BVnw96fzxXd7F 7QmjJBZbbGT+yGkz56mQAZkF35P8dmSO0Ex2XvDg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331061757; i=@elandsys.com; bh=2uXvrdlLgv3kWZlq0QbqKFortIzfp1D9Lv1F/KS0Tkg=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=mHQ4REFxIo/rePAF7TdvaGwcLYt6dRo32NSskZcIqOD0n8f4VlpSDz5TrGMwi2Q8t tVK7Wqs8HAtwMZjTBDEZBbbK2cGdoJS8ttSLLPlZRpg9UliNRxTFNpYh9mKO8RMcB9 9F+VU48MucBnrDLxwD/IiRXHbZ+HjpeOpX4UH9Pk= Message-Id: <6.2.5.6.2.20120306102738.0b9e4e10@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 06 Mar 2012 11:11:04 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20120306181857.GI77987@verdi> References: <1330458545.56033.YahooMailClassic@web125403.mail.ne1.yahoo.com> <6.2.5.6.2.20120306092159.0ac145d0@resistor.net> <20120306181857.GI77987@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 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, 06 Mar 2012 19:22:39 -0000 At 10:18 06-03-2012, John Leslie wrote: > This is a typo, right -- you mean Issue #4? >http://trac.tools.ietf.org/wg/spfbis/trac/ticket/4 Sorry, that was a typo. I meant Issue #4. > However, let us not forget that some (hopefully brief) review of >RFC 4405 in our "result-of-experiment" document is in-charter. I'll give a quick okay as long as it fits within the "conclusions" document. At 10:10 06-03-2012, Murray S. Kucherawy wrote: >I think your summary is accurate. I also suggest that the only two >dissenting opinions (from the same person) conflated the SUBMITTER >issue as being in scope for the WG but out of scope for the >RFC4408bis document. It is possible for both to be true, as is the case now. I haven't discussed about what is in scope in relation to Issue #4 with Andrew. Arthur Thisell mentioned that SUBMITTER is not defined or used in RFC 4408. There will be questions during the AD review if it is added in the second deliverable (4408bis). Regards, S. Moonesamy From agthisell@yahoo.com Tue Mar 6 11:32:54 2012 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 D23B921F85AE for ; Tue, 6 Mar 2012 11:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_50=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 ZSY8cU2ZJoib for ; Tue, 6 Mar 2012 11:32:51 -0800 (PST) Received: from nm11-vm0.bullet.mail.ne1.yahoo.com (nm11-vm0.bullet.mail.ne1.yahoo.com [98.138.90.58]) by ietfa.amsl.com (Postfix) with SMTP id 8EA8821F8513 for ; Tue, 6 Mar 2012 11:32:50 -0800 (PST) Received: from [98.138.90.55] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 06 Mar 2012 19:32:46 -0000 Received: from [98.138.89.163] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 06 Mar 2012 19:32:46 -0000 Received: from [127.0.0.1] by omp1019.mail.ne1.yahoo.com with NNFMP; 06 Mar 2012 19:32:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 634025.87845.bm@omp1019.mail.ne1.yahoo.com Received: (qmail 5683 invoked by uid 60001); 6 Mar 2012 19:32:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1331062366; bh=3/RRfffDuEcVireozUDElcSiBF306rl8FVk3DVvBDwI=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=NsF/VSOgXWp4zA8EV6kA2yBe6CsEDGTY3Pc4IL+l03BL/CrbVjfkEY9AbNInB9+xBTozM8leW/PcmJIc3UVvLNexLMmzvF2m7TsW3QJGsztGUxIq60knCS0Xk4hBxxSeuP2OZ9UXQaIHzRJ1LFToGXhep4XM2p4obqJbAgfGs84= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=qMPqYF1VeV8dgdI6q9MKY4ZmhcA6FX9Ib23iEfh9yJqONytz1SEeFQeAvbf1oa1XT5fdmKzHv390qIx/M3AaomJcglSia11fTOtV40EFsIEdjvhNVuWKGMD3NmTTt/AkEYZ78I+3oxS/1aTRpm9Xe9mMyO+JUUX7eI8IuTagI0s=; X-YMail-OSG: H5SKt1EVM1mowWsGdmrxnCI4TQNe70SLOYtecgr6UHXcJqQ JEOxlH06Tk71c.zMpVWx_o6h9OxMPtbl6IbPvgiSt55r.nJ.UtA8mNA8PjWa Nw_ZChCW0VVJRM5IyGM_RDepcN90SFDGfsx1kDMpKEPM6l3dhgXHEZ0lHSMl EMeo1MJZU1HopClDWvK6XzxhRUFjMsf.OneinygNDAz2f4F0xZLB4d4XOJsI jC1MZhVRLfUM1X9Q_oVD9Hux8n2HGK1xF4p1RgoPLlMLXx1cXDNZGrvGnoGC 8WvYIo5wLSLOUoKe1GeQnodE01LcIlEifGTZnEY5D9q1mDHEgD5y_jXw6C3Q 6iYypV_4Vjul.RmywNId9IDCcDOrUyiQnpfr5r0_0xa40IFPVaP4MaGfvIle GIMpcs6M5QEw.d8jwLkYa5n5qTunV8SwGjCaOKqYKVzCZeJFJhwC5Wnax9hX 1YXRzkxcCwTlJ5cBW.D6fCaDf5xyS3eNXfhZ3cnj2oKry_ojomX79mLdMNTr 2rPhjN8SSVixXjVB2PPjYtwgWdrFang9qDqKfUjWh3Oq9slFL3ayhnZU- Received: from [71.61.133.134] by web125406.mail.ne1.yahoo.com via HTTP; Tue, 06 Mar 2012 11:32:46 PST X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1331062366.99632.YahooMailClassic@web125406.mail.ne1.yahoo.com> Date: Tue, 6 Mar 2012 11:32:46 -0800 (PST) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 06 Mar 2012 19:32:54 -0000 > Be warned that "It hasn't happened yet" may not be a sufficient > discussion. This is true, Doug Otis promoting this attack for many years and yet nothing has happened. This gives evidence that the threat of recursive nature of SPF evaluations causing the local recursive resolver to send too many queries to unrelated third parties may not be that useful. Indeed, I have analyzed Doug's reports in the past and I found they miss a huge amount of work that the attacker has to do, thus greatly reducing the real amplification factor. Recursion can be a problem, but notice that DNS uses recursive resolvers, and as William Leibzon pointed this out to this message to DNSOPS back in 2006: http://www.ietf.org/mail-archive/web/dnsop/current/msg04911.html As William explains, it is quite possible to generate larger amplification attacks using plain old DNS, in particular, the NS, MX, SRV, etc. records. Unlike RFC 4408, the DNS RFCs don't have any limits on the recursion depth. It is far easier for an attacker to trigger an NS lookup than it is to trigger an SPF evaluation. You would think that if such attacks were useful, that in the many years that the NS record has been around, the easy of which it is to trigger an NS lookup, and the larger amplification than SPF, that it would have shown up. Things like the "no data" limit are not complete fixes. Domains that have wildcard MX records, for example, will return data. Actually, someone being attacked can use this, by publishing wildcards, they can create a useful TTL time. Or, the party being attacked can update their SOA record with a longer nTTL time. This is a general problem with recursion and DNS. The solution is likely to be best made in the resolver itself, maybe with an API extension letting the resolver know what certain DNS lookups are related. I highly recommend going back an reading that thread from William to DNSOPS before charging off to find "solutions". From agthisell@yahoo.com Tue Mar 6 11:55:06 2012 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 3390321F869A for ; Tue, 6 Mar 2012 11:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.015 X-Spam-Level: X-Spam-Status: No, score=0.015 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_50=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 2WOuKyJhnIaf for ; Tue, 6 Mar 2012 11:55:05 -0800 (PST) Received: from nm40-vm4.bullet.mail.ne1.yahoo.com (nm40-vm4.bullet.mail.ne1.yahoo.com [98.138.229.180]) by ietfa.amsl.com (Postfix) with SMTP id 99D8321F867A for ; Tue, 6 Mar 2012 11:55:05 -0800 (PST) Received: from [98.138.90.56] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 06 Mar 2012 19:55:02 -0000 Received: from [98.138.226.163] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 06 Mar 2012 19:55:02 -0000 Received: from [127.0.0.1] by omp1064.mail.ne1.yahoo.com with NNFMP; 06 Mar 2012 19:55:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 622089.64525.bm@omp1064.mail.ne1.yahoo.com Received: (qmail 67055 invoked by uid 60001); 6 Mar 2012 19:55:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1331063702; bh=1P27AqN6u1+KlUujMh4S9Zlp9Y5xGb5rfgp+fxi/jpA=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=0aQJLfL3grx9WRlnqWcaaXiJlUd4pLac1NweRpOKYq3RieGRa9/4mbNuoZKO3uk3yEdMBYkBiaDnzZqPIWg5/fColg1Q7qiaQLC4wacn8/1ksRkEWHXU8KR594X8PbLKH3jSIaMquew21XMAufAsieHBdC29ziKYPMs2how2uvU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=C1hrqtVz08Bxjxpd9kVXrZ+Zs1rnfII93JP4vTjHfjr6gyR4614Ml0LOHIvdwA3jgIf8ZCRL6hpmh/6jl+9YLWnaTggEsz/iaHzrXp8PmSqmPp0tZhYbOHnEPWxX34QbO2NT1i5vElljnFfsdJGGxnNhNX2MQ9SjkMZCz3hsm9E=; X-YMail-OSG: PWicCBMVM1n_fM6lhtSAb7iKjp6dmHqKkeZrC7m1POUaid2 LisvfIZki Received: from [71.61.133.134] by web125404.mail.ne1.yahoo.com via HTTP; Tue, 06 Mar 2012 11:55:01 PST X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1331063701.64023.YahooMailClassic@web125404.mail.ne1.yahoo.com> Date: Tue, 6 Mar 2012 11:55:01 -0800 (PST) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 06 Mar 2012 19:55:06 -0000 > I suggest we consider "MAY" language here -- admitting that we can't > know how this issue might play out over the next decade. Instead of > trying for a maximum number of such queries, could we consider instead > what the _minimum_ might be to accomplish identified valid usage, and > specify MAY for any queries beyond that minimum? I don't much like this kind of thing since it would mean that two different SPF implementations/users could evaluate the same SPF record and give different results. The goal of keeping SPF evaluations consistent is also why all syntax errors MUST be detected, and why you don't have to implement the check_host() function exactly as laid out in RFC 4408, but the results MUST be the same. From spf2@kitterman.com Tue Mar 6 12:53:05 2012 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 9770C21E8024 for ; Tue, 6 Mar 2012 12:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 p5xmBJE6Q6mF for ; Tue, 6 Mar 2012 12:53:03 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1FC21E80BF for ; Tue, 6 Mar 2012 12:53:01 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5197F20E40C0; Tue, 6 Mar 2012 15:53:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331067181; bh=AzgxAiFr1nlRthe3h+g4tN9cIpCrVZWmnQr3zLPx7Kg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=QZYw5EWipkZvYoiVmPIfEZyzjfk7LrKL+9hTxUlmlH2NaLDRD04aTJElquzxx8qcc 83itPoUhif5jG6xlfQh8t7G00bF7fJFEmNnRu/LJu6MTJLAevHCIbDw94aH/g++MXQ loRg/wqZVNpiWP78/9U4SQ+BSfWoMuVjVaq8sb68= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 322C820E4099; Tue, 6 Mar 2012 15:53:00 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 06 Mar 2012 15:53 -0500 Message-ID: <19293386.D3cedfnU8u@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120306102738.0b9e4e10@elandnews.com> References: <1330458545.56033.YahooMailClassic@web125403.mail.ne1.yahoo.com> <20120306181857.GI77987@verdi> <6.2.5.6.2.20120306102738.0b9e4e10@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] #4: RFC 4408 Section 4.1 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, 06 Mar 2012 20:53:05 -0000 On Tuesday, March 06, 2012 11:11:04 AM S Moonesamy wrote: > At 10:18 06-03-2012, John Leslie wrote: > > This is a typo, right -- you mean Issue #4? > > > >http://trac.tools.ietf.org/wg/spfbis/trac/ticket/4 > > Sorry, that was a typo. I meant Issue #4. > > > However, let us not forget that some (hopefully brief) review of > > > >RFC 4405 in our "result-of-experiment" document is in-charter. > > I'll give a quick okay as long as it fits within the "conclusions" document. > At 10:10 06-03-2012, Murray S. Kucherawy wrote: > >I think your summary is accurate. I also suggest that the only two > >dissenting opinions (from the same person) conflated the SUBMITTER > >issue as being in scope for the WG but out of scope for the > >RFC4408bis document. It is possible for both to be true, as is the case > >now. > I haven't discussed about what is in scope in relation to Issue #4 > with Andrew. Arthur Thisell mentioned that SUBMITTER is not defined > or used in RFC 4408. There will be questions during the AD review if > it is added in the second deliverable (4408bis). I'd prefer we didn't do it because it was not a technical valid approach than that the AD woud look at us funny if we did it because of the charter. Scott K From msk@cloudmark.com Tue Mar 6 13:29:24 2012 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 8A62621F87F4 for ; Tue, 6 Mar 2012 13:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 mvUsQZLR+5bG for ; Tue, 6 Mar 2012 13:29:24 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 278D821F87F3 for ; Tue, 6 Mar 2012 13:29:24 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Tue, 6 Mar 2012 13:29:23 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: A suggestion about the experiment document Thread-Index: AQHM++Ayo8UtTDDDakGOtdvfYndHQg== Date: Tue, 6 Mar 2012 21:29:23 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.com> References: <20120305175124.GR76465@crankycanuck.ca> <4F552745.5020507@Commerco.Net> In-Reply-To: <4F552745.5020507@Commerco.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [spfbis] A suggestion about the experiment document 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, 06 Mar 2012 21:29:24 -0000 I've bounced this idea off a couple of people and so far it's been well-rec= eived, so here I am, going for broke. :-) Given our deliberations over the type 99 issue that spilled into the main I= ETF list talking about new RRtypes, provisioning systems, etc., I would lik= e to suggest that we tell SPF's story with respect to these issues in the e= xperiment document, as an appendix. I don't have any specific text to sugg= est yet, but I wanted to float the general idea here first. We might cover topics like: - we generally like the idea of doing dedicated RRtypes for specific work, = however... - SPF was first incubated outside the IETF, so it started off using TXT, an= d there it has mostly stayed - at the time, the road to getting a dedicated RRtype for experimentation w= as steep and prickly - DNS provisioning tools haven't kept up, and generally don't - the text of RFC4408 didn't exactly encourage migration - things might've gone "better" had these last four bullets not been true - etc. Comments? -MSK From tony@att.com Tue Mar 6 13:41:25 2012 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 2E28621E8025 for ; Tue, 6 Mar 2012 13:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 Pdd8LmPEXUeH for ; Tue, 6 Mar 2012 13:41:24 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFF221E8013 for ; Tue, 6 Mar 2012 13:41:23 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 384865f4.0.161803.00-474.403444.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 06 Mar 2012 21:41:24 +0000 (UTC) X-MXL-Hash: 4f56848476ff1813-b66d2431d2d2174fe2a0734c2546f54ddeb18698 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q26LfsvW009393 for ; Tue, 6 Mar 2012 16:41:54 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q26LfmsY009340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Mar 2012 16:41:48 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Tue, 6 Mar 2012 16:41:11 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q26LfBjV023250 for ; Tue, 6 Mar 2012 16:41:11 -0500 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q26Lf2Yd022701 for ; Tue, 6 Mar 2012 16:41:02 -0500 Received: from [130.10.36.6] (vpn-130-10-36-6.vpn.west.att.com[130.10.36.6]) by maillennium.att.com (mailgw1) with ESMTP id <20120306213831gw1004or42e> (Authid: tony); Tue, 6 Mar 2012 21:38:32 +0000 X-Originating-IP: [130.10.36.6] Message-ID: <4F56846B.6070002@att.com> Date: Tue, 06 Mar 2012 16:40:59 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "spfbis@ietf.org" References: <20120305175124.GR76465@crankycanuck.ca> <4F552745.5020507@Commerco.Net> <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=khJMWLpwAE8A:10 a=ra92YfU4GoUA:10 a=Dlqn0NaGXP] X-AnalysisOut: [wA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:1] X-AnalysisOut: [0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=w-2dGtdcWZEj3wyvai4A:9 a] X-AnalysisOut: [=W3BQTVHItqDm3FJKr_cA:7 a=wPNLvfGTeEIA:10] Subject: Re: [spfbis] A suggestion about the experiment document 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, 06 Mar 2012 21:41:25 -0000 As an adjunct to explaining the results of the spf experiment, I think it's valuable information. I'm ambivalent to whether it's in an appendix or just another section. Tony Hansen On 3/6/2012 4:29 PM, Murray S. Kucherawy wrote: > I've bounced this idea off a couple of people and so far it's been well-received, so here I am, going for broke. :-) > > Given our deliberations over the type 99 issue that spilled into the main IETF list talking about new RRtypes, provisioning systems, etc., I would like to suggest that we tell SPF's story with respect to these issues in the experiment document, as an appendix. I don't have any specific text to suggest yet, but I wanted to float the general idea here first. > > We might cover topics like: > > - we generally like the idea of doing dedicated RRtypes for specific work, however... > - SPF was first incubated outside the IETF, so it started off using TXT, and there it has mostly stayed > - at the time, the road to getting a dedicated RRtype for experimentation was steep and prickly > - DNS provisioning tools haven't kept up, and generally don't > - the text of RFC4408 didn't exactly encourage migration > - things might've gone "better" had these last four bullets not been true > - etc. > > Comments? > > -MSK From msk@cloudmark.com Tue Mar 6 13:44:13 2012 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 E453521E8025 for ; Tue, 6 Mar 2012 13:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 JuiK2BDZ4yZC for ; Tue, 6 Mar 2012 13:44:13 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 882CC21E8013 for ; Tue, 6 Mar 2012 13:44:13 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Tue, 6 Mar 2012 13:44:13 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] A suggestion about the experiment document Thread-Index: AQHM++Ayo8UtTDDDakGOtdvfYndHQpZeUf+A//96oTA= Date: Tue, 6 Mar 2012 21:44:12 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807D1D3@exch-mbx901.corp.cloudmark.com> References: <20120305175124.GR76465@crankycanuck.ca> <4F552745.5020507@Commerco.Net> <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.com> <4F56846B.6070002@att.com> In-Reply-To: <4F56846B.6070002@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] A suggestion about the experiment document 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, 06 Mar 2012 21:44:14 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Tony Hansen > Sent: Tuesday, March 06, 2012 1:41 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] A suggestion about the experiment document >=20 > As an adjunct to explaining the results of the spf experiment, I think > it's valuable information. I'm ambivalent to whether it's in an > appendix or just another section. I suggested an appendix because it's technically off-topic in terms of the = charter and the title of the document. But I don't feel strongly about it = either. -MSK From spf2@kitterman.com Tue Mar 6 13:51:12 2012 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 639A221E80D5 for ; Tue, 6 Mar 2012 13:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 lyyozBt5WLPB for ; Tue, 6 Mar 2012 13:51:11 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 76ED321E8089 for ; Tue, 6 Mar 2012 13:51:11 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D84BD20E40C0; Tue, 6 Mar 2012 16:51:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331070670; bh=NLbJ/XRL4yJVpnEMIdNZwUOZvjamqyVQcTbs7klybv4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=NNMTwE9nLjGNCTM0Dcz9irL78uf2IsFAK0dRX+bhfPqskTgKnW9RYwW8ROGHKz9oe SFCS71cQjZ51ajDkg8VLD/HE7kp5bkGdVW2CllA8O+4fHVvWgFRwG2MBs9/l4ozK0R Sr9vvKj6SSgCeGaSrJDZ43NipI8KugGBnh7nnWT8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BF4AE20E4099; Tue, 6 Mar 2012 16:51:10 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 06 Mar 2012 16:51:10 -0500 Message-ID: <7652389.KFjPuiOAp5@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E00392807D1D3@exch-mbx901.corp.cloudmark.com> References: <20120305175124.GR76465@crankycanuck.ca> <4F56846B.6070002@att.com> <9452079D1A51524AA5749AD23E00392807D1D3@exch-mbx901.corp.cloudmark.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] A suggestion about the experiment document 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, 06 Mar 2012 21:51:12 -0000 On Tuesday, March 06, 2012 09:44:12 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Tony Hansen Sent: Tuesday, March 06, 2012 1:41 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] A suggestion about the experiment document > > > > As an adjunct to explaining the results of the spf experiment, I think > > it's valuable information. I'm ambivalent to whether it's in an > > appendix or just another section. > > I suggested an appendix because it's technically off-topic in terms of the > charter and the title of the document. But I don't feel strongly about it > either. Since what was or was not the experiment was never clearly defined, I think it's whatever we reasonably want it to be. Scott K From lenm@ops.corpnet.sel.sony.com Tue Mar 6 13:43:01 2012 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 C0DC721E8025 for ; Tue, 6 Mar 2012 13:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 QMFnQYlFJV3p for ; Tue, 6 Mar 2012 13:43:01 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id B953721E8013 for ; Tue, 6 Mar 2012 13:43:00 -0800 (PST) Received: from mail103-am1-R.bigfish.com (10.3.201.246) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 6 Mar 2012 21:42:59 +0000 Received: from mail103-am1 (localhost [127.0.0.1]) by mail103-am1-R.bigfish.com (Postfix) with ESMTP id E512D1004A0; Tue, 6 Mar 2012 21:42:59 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zz98dKzz1202h1082kzzz2fh668h839h944h) X-Forefront-Antispam-Report: CIP:160.33.98.74; KIP:(null); UIP:(null); IPV:NLI; H:mail7.fw-bc.sony.com; RD:mail7.fw-bc.sony.com; EFVD:NLI Received-SPF: pass (mail103-am1: domain of ops.corpnet.sel.sony.com designates 160.33.98.74 as permitted sender) client-ip=160.33.98.74; envelope-from=lenm@ops.corpnet.sel.sony.com; helo=mail7.fw-bc.sony.com ; -bc.sony.com ; Received: from mail103-am1 (localhost.localdomain [127.0.0.1]) by mail103-am1 (MessageSwitch) id 1331070176877778_31711; Tue, 6 Mar 2012 21:42:56 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.248]) by mail103-am1.bigfish.com (Postfix) with ESMTP id D1A862C0045; Tue, 6 Mar 2012 21:42:56 +0000 (UTC) Received: from mail7.fw-bc.sony.com (160.33.98.74) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server id 14.1.225.23; Tue, 6 Mar 2012 21:42:56 +0000 Received: from mail1x.sgo.in.sel.sony.com (mailx.sgo.in.sel.sony.com [43.130.1.112]) by mail7.fw-bc.sony.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id q26LgsOH006824; Tue, 6 Mar 2012 21:42:55 GMT Received: from ops.corpnet.sel.sony.com (ops.corpnet.sel.sony.com [43.135.152.168]) by mail1x.sgo.in.sel.sony.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id q26Lgduq014212; Tue, 6 Mar 2012 21:42:39 GMT Received: from ops.corpnet.sel.sony.com (localhost.des-cntr.sca.sony.com [127.0.0.1]) by ops.corpnet.sel.sony.com (8.12.9/8.11.2) with ESMTP id q26LgSSZ007208; Tue, 6 Mar 2012 21:42:28 GMT From: Leonard Mills Received: from localhost (lenm@localhost) by ops.corpnet.sel.sony.com (8.12.9/8.12.9/Submit) with ESMTP id q26LgQ9T007205; Tue, 6 Mar 2012 21:42:27 GMT Date: Tue, 6 Mar 2012 21:42:26 +0000 To: "Murray S. Kucherawy" In-Reply-To: <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-OriginatorOrg: corpnet.sel.sony.com X-Mailman-Approved-At: Tue, 06 Mar 2012 13:54:58 -0800 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] A suggestion about the experiment document 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, 06 Mar 2012 21:48:37 -0000 On Tue, 6 Mar 2012, Murray S. Kucherawy wrote: > Given our deliberations over the type 99 issue that spilled into the main IETF list talking about new RRtypes, provisioning systems, etc., I would like to suggest that we tell SPF's story with respect to these issues in the experiment document, as an appendix. I don't have any specific text to suggest yet, but I wanted to float the general idea here first. Seems like a very good idea to me. Right now tge intent is probably more important than the particular items covered, but "what went before" can be important in fleshing out descriptions. Len From dhc@dcrocker.net Tue Mar 6 13:55:12 2012 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 2E7A021F85D9 for ; Tue, 6 Mar 2012 13:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.607 X-Spam-Level: X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 EcMy4xPyyWqN for ; Tue, 6 Mar 2012 13:55:11 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5679E21F858E for ; Tue, 6 Mar 2012 13:55:11 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q26Lt5JC013468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Mar 2012 13:55:10 -0800 Message-ID: <4F5687AF.80009@dcrocker.net> Date: Tue, 06 Mar 2012 13:54:55 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120305175124.GR76465@crankycanuck.ca> <4F552745.5020507@Commerco.Net> <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.com> <4F56846B.6070002@att.com> In-Reply-To: <4F56846B.6070002@att.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.17]); Tue, 06 Mar 2012 13:55:11 -0800 (PST) Subject: Re: [spfbis] A suggestion about the experiment document 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, 06 Mar 2012 21:55:12 -0000 On 3/6/2012 1:40 PM, Tony Hansen wrote: > As an adjunct to explaining the results of the spf experiment, I think it's > valuable information. I'm ambivalent to whether it's in an appendix or just > another section. The choice of DNS record type isn't mainstream to the SPF story, in my view. Using the DNS for /a/ record is, but which of the two isn't. In addition, the topic of DNS RR type has rather a lot of history in the community and it could distract the reader from what /is/ the SPF story. So I suggest appendix is better. (I think that means I +1'd having the text in the document...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Tue Mar 6 13:55:42 2012 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 4BD6521F8546 for ; Tue, 6 Mar 2012 13:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 ul+ITtCrrs3d for ; Tue, 6 Mar 2012 13:55:41 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9654D21F8569 for ; Tue, 6 Mar 2012 13:55:41 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3246120E40C0; Tue, 6 Mar 2012 16:55:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331070941; bh=wj8nWHaMQGwaX8l1zjSgqTcVRJzqLABJ4TTjBH9xQKc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ASW4xSQV1ao1Yxb9GbMYWH33F4QDWOcPTDJYnKzvcysIw6iQVNyPFq2I/DoHCM/Sz l1gMxx66nwFLoORY8JmUFxR3KatIk55YDcvWxWewE11gUIgBpLLwNgX5Acm30wEwTm ZC8U4Vs3owCs29ME0W/v4iRtSBlfWRdfBw6IowF0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 199FB20E4099; Tue, 6 Mar 2012 16:55:40 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 06 Mar 2012 16:55:40 -0500 Message-ID: <1722287.sA7CKq2DFd@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.com> References: <20120305175124.GR76465@crankycanuck.ca> <4F552745.5020507@Commerco.Net> <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.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] A suggestion about the experiment document 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, 06 Mar 2012 21:55:42 -0000 On Tuesday, March 06, 2012 09:29:23 PM Murray S. Kucherawy wrote: I think it's a good idea. I do have a quibble with this: > - the text of RFC4408 didn't exactly encourage migration Given the state of the art when RFC 4408 was published, the SHOULD publish Type SPF was advice in advance of the facts. I think in fact it was far more encouraging that was technically justified at the time (that's where the MUST publish at least one type without specifying which comes from). The major interoperability issue that's come up in this working group is precisely from RFC 4408 being too encouraging. Scott K From msk@cloudmark.com Tue Mar 6 14:05:52 2012 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 989E121F8625 for ; Tue, 6 Mar 2012 14:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 SDYKuqoR3JxT for ; Tue, 6 Mar 2012 14:05:51 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id C090A21F8624 for ; Tue, 6 Mar 2012 14:05:51 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Tue, 6 Mar 2012 14:05:51 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] A suggestion about the experiment document Thread-Index: AQHM++Ayo8UtTDDDakGOtdvfYndHQpZeVhkA//960AA= Date: Tue, 6 Mar 2012 22:05:50 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807D289@exch-mbx901.corp.cloudmark.com> References: <20120305175124.GR76465@crankycanuck.ca> <4F552745.5020507@Commerco.Net> <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.com> <1722287.sA7CKq2DFd@scott-latitude-e6320> In-Reply-To: <1722287.sA7CKq2DFd@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] A suggestion about the experiment document 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, 06 Mar 2012 22:05:52 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Tuesday, March 06, 2012 1:56 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] A suggestion about the experiment document >=20 > I think it's a good idea. I do have a quibble with this: >=20 > > - the text of RFC4408 didn't exactly encourage migration >=20 > Given the state of the art when RFC 4408 was published, the SHOULD > publish Type SPF was advice in advance of the facts. I think in fact > it was far more encouraging that was technically justified at the time > (that's where the MUST publish at least one type without specifying > which comes from). The major interoperability issue that's come up in > this working group is precisely from RFC 4408 being too encouraging. My fault for being imprecise. I was referring specifically to the interope= rability bug that's been identified, where neither side was guaranteed to p= ublish or query type 99, so they might never actually communicate. I think= the language thus ultimately encouraged both sides toward TXT, where the p= re-IETF work was already firmly rooted anyway. Regardless, I'm happy to just say something about this per WG consensus. W= e don't need to resolve this now, but it seems like we generally think this= is a good idea to include in the report, and that's good enough for the mo= ment. (I'm now observing in my DNS survey that there are also resolvers and/or fi= rewalls that simply drop queries for unknown types; the TXT reply comes bac= k right away, the SPF reply never comes. We might want to mention that too= .) -MSK From vesely@tana.it Wed Mar 7 00:50:30 2012 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 833EF21F869F for ; Wed, 7 Mar 2012 00:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.654 X-Spam-Level: X-Spam-Status: No, score=-4.654 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49l1facp4BLT for ; Wed, 7 Mar 2012 00:50:29 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9F43D21F869D for ; Wed, 7 Mar 2012 00:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1331110227; bh=BN226VYaO/4daQtYNbMR7s4nO6k0ZojEREd//bAfEMc=; l=1120; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ObSoyY/gZSCUwZUV4PlDnbCtFmf6NtfqSTPKdEz7h0oMwKw0tnh3Jy1OwRrwwVWPC 8maqPPhG7u/j3eqWFuloKgKgbLv//wNKfF/oZ831aeTY3i9a87r6HKiMgFJy04+gWq hWbbpHCma84oXlznVjUp7sBhBgbbfhs/ID/zD2bo= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 07 Mar 2012 09:50:27 +0100 id 00000000005DC039.000000004F572153.000062FC Message-ID: <4F572152.1080106@tana.it> Date: Wed, 07 Mar 2012 09:50:26 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <6.2.5.6.2.20120306091044.0b9a15b0@elandnews.com> <20120306180201.GH77987@verdi> <1503188.cxsYnuchm5@scott-latitude-e6320> In-Reply-To: <1503188.cxsYnuchm5@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 08:50:30 -0000 On 06/Mar/12 19:43, Scott Kitterman wrote: > > The basic theory is not new and a detailed assessment of it was done several > years ago: > > http://www.openspf.org/draft-otis-spf-dos-exploit_Analysis Section 5.4 of RFC 4408 says: To prevent Denial of Service (DoS) attacks, more than 10 MX names MUST NOT be looked up during the evaluation of an "mx" mechanism (see Section 10). Section 10 says: SPF implementations MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier. If this number is exceeded during a check, a PermError MUST be returned. The "include", "a", "mx", "ptr", and "exists" mechanisms as well as the "redirect" modifier do count against this limit. To me, "do count against this limit" means that for "v=spf1 +mx -all" one has already spent two lookups for the record itself and the mx, so the evaluation fails if the sending address belongs to the ninth eXchanger or further down. No 111 amplification. What am I missing? From vesely@tana.it Wed Mar 7 00:51:09 2012 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 9892F21F86A2 for ; Wed, 7 Mar 2012 00:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.655 X-Spam-Level: X-Spam-Status: No, score=-4.655 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwp5d1QVffke for ; Wed, 7 Mar 2012 00:51:09 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id CD9F221F86A0 for ; Wed, 7 Mar 2012 00:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1331110268; bh=6t2Lxnupcy5b86uyOROAOpSTmuRaAs34kPjA2DM1fkc=; l=755; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=TnbTuiO4ulNHaBOsvp2PDfWFOZQJZIScqjHFNof+ju7iC3MYPLt7GUEhv+cZzmVN6 +i9AYk9I/t6ccJ14IQHYdXuniEvA+O6igOpf9yvIb7cNyr6ltXSD6oQKM41cBbtk6X LsVTYoli0O6yvs9WC/H5OJqBVEMM4X3dW3DgUQV0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 07 Mar 2012 09:51:08 +0100 id 00000000005DC039.000000004F57217C.0000634C Message-ID: <4F57217C.1050402@tana.it> Date: Wed, 07 Mar 2012 09:51:08 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120305175124.GR76465@crankycanuck.ca> <4F56846B.6070002@att.com> <9452079D1A51524AA5749AD23E00392807D1D3@exch-mbx901.corp.cloudmark.com> <7652389.KFjPuiOAp5@scott-latitude-e6320> In-Reply-To: <7652389.KFjPuiOAp5@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A suggestion about the experiment document 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, 07 Mar 2012 08:51:09 -0000 On 06/Mar/12 22:51, Scott Kitterman wrote: > On Tuesday, March 06, 2012 09:44:12 PM Murray S. Kucherawy wrote: >>> From: ietf.org On Behalf Of Tony Hansen >> >>> As an adjunct to explaining the results of the spf experiment, I think >>> it's valuable information. I'm ambivalent to whether it's in an >>> appendix or just another section. >> >> I suggested an appendix because it's technically off-topic in terms of the >> charter and the title of the document. But I don't feel strongly about it >> either. > > Since what was or was not the experiment was never clearly defined, I think > it's whatever we reasonably want it to be. If spfbis is going to temporarily put type 99 aside, this topic deserves a top-class explanation, IMHO. From agthisell@yahoo.com Wed Mar 7 03:47:58 2012 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 6D98421F87D1 for ; Wed, 7 Mar 2012 03:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.013 X-Spam-Level: X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_50=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 77B2c4jIhwMj for ; Wed, 7 Mar 2012 03:47:58 -0800 (PST) Received: from nm40-vm7.bullet.mail.ne1.yahoo.com (nm40-vm7.bullet.mail.ne1.yahoo.com [98.138.229.183]) by ietfa.amsl.com (Postfix) with SMTP id DE74B21F8674 for ; Wed, 7 Mar 2012 03:47:57 -0800 (PST) Received: from [98.138.90.53] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 11:47:53 -0000 Received: from [98.138.88.232] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 11:47:53 -0000 Received: from [127.0.0.1] by omp1032.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 11:47:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 183688.50015.bm@omp1032.mail.ne1.yahoo.com Received: (qmail 24594 invoked by uid 60001); 7 Mar 2012 11:47:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1331120873; bh=C8nqxf2Bj8S+19QOo4zYOK6X0C7tuoqSIoYxldOXJzE=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=K9j5OMMOanKRAe1IApVT7MtG2b5odI8LD/4XWLJuACtpbFCGuG4BFkT/1c23ThTt7jmcSvY7OoHFy/Qxda/UsL5Ior9CD6ADNB34RFlA6Lg9s2E7a64nPz377ENUAtFM0/WUQxnzLIi9XCl6/V2doojQ9acXGwCqP4XoCUCQLYk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=6HyiXQGh3fXmNjAi5saLMdR7xJeUcHZn9DbSTIxHEtKLL92mX4ltcLPXsXqZ4I+ZVRN5sJOlTp6HqHVNZJSw5qdvYZL4CCbyfXVXsLdqb+mKDKbQlZ7SgJEhZt3qXFkI4dvEb9zPOQ/VZhh7rE1tme4apHfo0fIUMAj0WSwJXic=; X-YMail-OSG: pqrzojsVM1kYCKiNg3F7CilbyDsXlrkMj.mmrKiEwDnnbLZ 5S9ag.tyJGHBh6rpmwTo.653xH7EvKta614X9ZHH8scCYAvz5.37bLLXudKk waVFMpdnRNjgKKC0eFDinLmKwVeljA.LAaLrUoaRA9j2oDtDkArArq9YeaiH 37nc2ER3mPC5r5MGZAosc2gCURoKmykODzp1sFGgEmzhs6slWGC3XqNG9ywJ MObwpWOQLiXCNTu9iTo_Tyyv7KoUlJMNOu4hkQfIGbn9gRPVawXwANVbhDbh lGEWwQ48ou0c1ABtnBllOu9fi3Lzb05Cfl_DZyt1Dwjoc7NrQbDAYeheX70Q _2fzLlX7wIxxljvboGwdEx4S_6FqmY0QRX8ofWOACRdLYKKVYW3LszKBp0sk WXuHyY_uxStvpUji.iWiAqmGDsANd3_pQb.WtuRk6VZCHyChNNN5n6eR8pDy Xo4Y- Received: from [71.61.133.134] by web125406.mail.ne1.yahoo.com via HTTP; Wed, 07 Mar 2012 03:47:52 PST X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1331120872.80909.YahooMailClassic@web125406.mail.ne1.yahoo.com> Date: Wed, 7 Mar 2012 03:47:52 -0800 (PST) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 11:47:58 -0000 > Section 10 says: > > SPF implementations MUST limit the number of mechanisms and modifiers > that do DNS lookups to at most 10 per SPF check, including any > lookups caused by the use of the "include" mechanism or the > "redirect" modifier. Good catch, Aleessandro. That "lookups" should be "mechanisms or modifiers". Can anyone think of a shorter/better term for the unwieldy "mechanism and/or modifier"? From agthisell@yahoo.com Wed Mar 7 03:58:25 2012 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 2D5B021F87AA for ; Wed, 7 Mar 2012 03:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_50=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 vT5ZWEAszUM2 for ; Wed, 7 Mar 2012 03:58:23 -0800 (PST) Received: from nm13-vm0.bullet.mail.ne1.yahoo.com (nm13-vm0.bullet.mail.ne1.yahoo.com [98.138.91.48]) by ietfa.amsl.com (Postfix) with SMTP id 1681A21F87A9 for ; Wed, 7 Mar 2012 03:58:23 -0800 (PST) Received: from [98.138.90.56] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 11:58:20 -0000 Received: from [98.138.226.167] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 11:58:20 -0000 Received: from [127.0.0.1] by omp1068.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 11:58:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 54765.76278.bm@omp1068.mail.ne1.yahoo.com Received: (qmail 566 invoked by uid 60001); 7 Mar 2012 11:58:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1331121499; bh=LVAtdAuy2bFy+V8gRefCHNkwoRBX9UnBU4NwIZFgqy8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=qHW+tBn/9+bY9V7eP1qIfyxGErWnSrybm3q3J+SNKnRVr2CBA5o47sai0c84bwZPU4XP3jDTTSQL7nLqJ+V2ADyPl3XCVBgLwqQvw+zbZg9rqZofUENH9e/qwBiKOPIOJa82+YlUthNAUm+tNnXmlhwImnmhjX3QPk0NcmCcBxE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=lJnlFdqUAOsL3gcMSBAu0L47pmnZB7kQkAbN+i1PAXeJgOPeNEiXb4zYRaUTNRFU3udUT/ot1Ump5fMPdtdm0JfqXpRNfju49nU3RPThxzUp8rYvmop/wYKa4uf2FkbecJ5I5O+V9cc2diLRlJgYPJHfRxhti6XQVB6Qy7lvO1Y=; X-YMail-OSG: CSIFEzUVM1lLmYr3e7ZrCA6MiAtGA_TC25KRi1VlLOEE8Vf RfvgQC5jRwJZlQ02rqkgIJiC7luXqBxJly6tqoqp0qSRHvj4NEaq.4MaJtG_ hlRALPgHNWNPPzgd5CjcOBWNCmSMjtmSwI4lBvtrc9g62.y5bdlqGvRI4Uib mH0AP7_nxzM6VdK5txbgLhceVCOImsquEskgmP3uQtYQRYDj.B.lqshNp5cw LT9jCAkn8bcmioUBxvvmwdRJkqXbn9pqQwLVtDdibTAFAxn0bEb_4kxQT6f7 uUpyKQZjthsi0rQilNGpszfIN38wovKLzTijp5ji25b9dTjEVexpexSW0il8 4ab1IH1.m3Nb.124qFQypNfoHVkOo7jm1FcTHHbry0PktlEytsSSmeZHGlrK vut1ELVlOl1x0umPudHKshpgN1qEDARrJVxz7TNVtiD28Wfkxy_SNjnv_tVk ISw-- Received: from [71.61.133.134] by web125402.mail.ne1.yahoo.com via HTTP; Wed, 07 Mar 2012 03:58:19 PST X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1331121499.99326.YahooMailClassic@web125402.mail.ne1.yahoo.com> Date: Wed, 7 Mar 2012 03:58:19 -0800 (PST) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 11:58:25 -0000 > Can anyone think of a shorter/better term for the unwieldy "mechanism and/or modifier"? (sorry for the reply to myself, too early in the morning...) The ABNF uses "terms" to describe mechanisms/modifiers, but I never liked that either, even for the ABNF. I guess the term "terms" is used elsewhere in RFC 4408... From spf2@kitterman.com Wed Mar 7 04:06:48 2012 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 DBACB21F87B0 for ; Wed, 7 Mar 2012 04:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 spQ9Zd-51LzN for ; Wed, 7 Mar 2012 04:06:48 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0848C21F86F1 for ; Wed, 7 Mar 2012 04:06:48 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 19E5E20E40FA; Wed, 7 Mar 2012 07:06:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331122007; bh=HnCwYNF5VY8zLe6hOPaq0UzQSSl0SUSApkBlQBHwCyA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=jDWZwDm/0+RzMSNCyEiLRuTulT9BxYfApNa4faWzu6bwoFALlwZiCcdwqjCBXmGq0 fTQ2gERjMrpHmFTi5VROqGIRDBdmNbd2sl/vH8uiVq40flVOODZIl8vs9ylCNIO0Ut mbaYBAWRalmqdZ738WElfUSx8/LKwlfVQ5+leAm8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id EF6B520E40A3; Wed, 7 Mar 2012 07:06:46 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 07 Mar 2012 07:06:46 -0500 Message-ID: <2317537.fikNkrUavS@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F572152.1080106@tana.it> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <1503188.cxsYnuchm5@scott-latitude-e6320> <4F572152.1080106@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 12:06:49 -0000 On Wednesday, March 07, 2012 09:50:26 AM Alessandro Vesely wrote: > On 06/Mar/12 19:43, Scott Kitterman wrote: > > The basic theory is not new and a detailed assessment of it was done > > several years ago: > > > > http://www.openspf.org/draft-otis-spf-dos-exploit_Analysis > > Section 5.4 of RFC 4408 says: > > To prevent Denial of Service > (DoS) attacks, more than 10 MX names MUST NOT be looked up during the > evaluation of an "mx" mechanism (see Section 10). > > Section 10 says: > > SPF implementations MUST limit the number of mechanisms and modifiers > that do DNS lookups to at most 10 per SPF check, including any > lookups caused by the use of the "include" mechanism or the > "redirect" modifier. If this number is exceeded during a check, a > PermError MUST be returned. The "include", "a", "mx", "ptr", and > "exists" mechanisms as well as the "redirect" modifier do count > against this limit. > > To me, "do count against this limit" means that for "v=spf1 +mx -all" > one has already spent two lookups for the record itself and the mx, so > the evaluation fails if the sending address belongs to the ninth > eXchanger or further down. No 111 amplification. What am I missing? First, I don't think there's a lot of point in computing the maximum number of lookups possible. As has been said elsewhere in the thread there are other, simpler, ways of doing an attack like this, so I while I do think we need to address the concern, I'm not worried about the specifics in great detail. I do think we need to make sure the processing limits are worded in a way that is clear enough that everyone counts things the same way for a deterministic result. Your "v=spf1 +mx -all" example and your counting is a good example of how people can easily get things wrong. Look again at RFC 4408 10.1. "MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check" Your example only has one mechanism or modifier that does a DNS lookup (mx), so it counts as one, not two. The language in 4408 10.1 is technically unambiguous, but hard to parse. This is why I filed issue #6, RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization. We can figure out how to rewrite it when we get to that issue, but I thought it worth mentioning is this thread as an example of why we need clearer words. http://trac.tools.ietf.org/wg/spfbis/trac/ticket/6 Scott K From spf2@kitterman.com Wed Mar 7 04:11:07 2012 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 B523F21F8713 for ; Wed, 7 Mar 2012 04:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 pI294X1hRtTC for ; Wed, 7 Mar 2012 04:11:07 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id F180E21F870F for ; Wed, 7 Mar 2012 04:11:06 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8B24320E40FA; Wed, 7 Mar 2012 07:11:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331122266; bh=cigy4QNBl03CnxGCY2kRbiSwtmgAhUPH+pIl7vi4Xj8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=LHbOximZBqTyS3klCPLk+iS8JDJbtbbPmzhf8RW3OubeczWACta1nugW+8UXyRYP7 5iDh+zYhyg5oOF+7yq6tI7WATN0PYR3V7vygPdbhoWANjWFFjx2n5ODlSgoiAXgzId UaDmh3JUeJEpvs0q65iqA54v3+v37guEWZ6Hs/yA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7207A20E40A3; Wed, 7 Mar 2012 07:11:06 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 07 Mar 2012 07:11:05 -0500 Message-ID: <3297400.fQGg0oUriz@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <1331121499.99326.YahooMailClassic@web125402.mail.ne1.yahoo.com> References: <1331121499.99326.YahooMailClassic@web125402.mail.ne1.yahoo.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] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 12:11:07 -0000 On Wednesday, March 07, 2012 03:58:19 AM Arthur Thisell wrote: > > Can anyone think of a shorter/better term for the unwieldy "mechanism > > and/or modifier"? > (sorry for the reply to myself, too early in the morning...) > > The ABNF uses "terms" to describe mechanisms/modifiers, but I never liked > that either, even for the ABNF. I guess the term "terms" is used elsewhere > in RFC 4408... It's only used in one paragrah (4.6.1) outside the ABNF and I've never, ever heard anyone use it in discussing SPF (IIRC), so if there's a better 'term' to be using, it ought to be easy enough to replace. I think we're reasonably safe from confusing people. Scott K From spf2@kitterman.com Wed Mar 7 04:24:52 2012 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 AD20E21F8508 for ; Wed, 7 Mar 2012 04:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 Qhi7u0cQrE7P for ; Wed, 7 Mar 2012 04:24:52 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0E59D21F84D9 for ; Wed, 7 Mar 2012 04:24:52 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 98DE920E40FA; Wed, 7 Mar 2012 07:24:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331123091; bh=8ei5r7p9NuGBbKJs6xIHzVkzxlgp5AJZShz2s+4EmHo=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=mTvmJXtuW5Ex4TCreD6CrJ8WIbXcC8ynPLJKfPzFHLJE1STxXsADDjnCdMUyqdqob NfewH5e0/inkgDmV0FN1x83SWy/5+g+B0Glcs2B9tml720TggAvdKZdd+KQEgnZ3+F vMZtdJJWL/wUU/wNLtQAZvzjTlqJb2z0vegiMy18= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7A95320E40A3; Wed, 7 Mar 2012 07:24:51 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 07 Mar 2012 07:24:50 -0500 Message-ID: <2896288.llcdo1tP7C@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <1331120872.80909.YahooMailClassic@web125406.mail.ne1.yahoo.com> References: <1331120872.80909.YahooMailClassic@web125406.mail.ne1.yahoo.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] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 12:24:52 -0000 On Wednesday, March 07, 2012 03:47:52 AM Arthur Thisell wrote: > > Section 10 says: > > SPF implementations MUST limit the number of mechanisms and modifiers > > that do DNS lookups to at most 10 per SPF check, including any > > lookups caused by the use of the "include" mechanism or the > > "redirect" modifier. > > Good catch, Aleessandro. That "lookups" should be "mechanisms or > modifiers". Can anyone think of a shorter/better term for the unwieldy > "mechanism and/or modifier"? FWIW, I think mechanisms and modifiers is correct. You always have to count both, but sometimes the quantity of one of them is zero. and/or just makes it more uncertain. Scott K From vesely@tana.it Wed Mar 7 04:42:00 2012 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 BA0F021F87BC for ; Wed, 7 Mar 2012 04:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.655 X-Spam-Level: X-Spam-Status: No, score=-4.655 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H8UPGMi5CO2 for ; Wed, 7 Mar 2012 04:42:00 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E252A21F86DB for ; Wed, 7 Mar 2012 04:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1331124118; bh=Dv9yiMFFHA9scPIYSmQphJvI1hWkAE46YWiRi/Qp4DQ=; l=1159; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=li/zB4jkF5Vz4VlSLLysc7aFAZjXXAyq9iiI9gnHH2kxBZ7PmtFtsT1zlUlQfcqyJ A19WVmbagiz4zhX+vwf/SUyamroFcd/W9mPNm40PwCZfa0ZxpcKgNC5cU+nbd2lJee eCUPecw3zEDB1a63EjEd1CY7AMwLNDsq89vHrWpk= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 07 Mar 2012 13:41:58 +0100 id 00000000005DC039.000000004F575796.00001F20 Message-ID: <4F575795.7040506@tana.it> Date: Wed, 07 Mar 2012 13:41:57 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <1503188.cxsYnuchm5@scott-latitude-e6320> <4F572152.1080106@tana.it> <2317537.fikNkrUavS@scott-latitude-e6320> In-Reply-To: <2317537.fikNkrUavS@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 12:42:00 -0000 On 07/Mar/12 13:06, Scott Kitterman wrote: > On Wednesday, March 07, 2012 09:50:26 AM Alessandro Vesely wrote: >> >> To me, "do count against this limit" means that for "v=spf1 +mx -all" >> one has already spent two lookups for the record itself and the mx, so >> the evaluation fails if the sending address belongs to the ninth >> eXchanger or further down. No 111 amplification. What am I missing? > > First, I don't think there's a lot of point in computing the > maximum number of lookups possible. Why? It doesn't sound difficult to specify of implement. I mean, isn't it easier to say "you can do at most 111 lookups" than "you can evaluate at most 10 terms worth 10 lookups each plus an exists as a bonus"? > Look again at RFC 4408 10.1. > > "MUST limit the number of mechanisms and modifiers that do DNS lookups to at > most 10 per SPF check" It may be clearer as: MUST limit the number of terms that do DNS lookups to at most 10 /terms/ per SPF check BTW, I don't think "term" is a bad term. > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/6 Sorry for conflating #6 and #24. They really ought to be merged. From vesely@tana.it Wed Mar 7 04:42:45 2012 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 82F6421F87BE for ; Wed, 7 Mar 2012 04:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.656 X-Spam-Level: X-Spam-Status: No, score=-4.656 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oqm-K2IkV7B for ; Wed, 7 Mar 2012 04:42:45 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C018C21F87BC for ; Wed, 7 Mar 2012 04:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1331124163; bh=fS2mUKFsEy6JASbQmYiLHV6InAyu6zMScHOShGtj/yw=; l=347; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=B4St7sWThfTgjtVsKX9Npk/GKFWkroSiY/L6iNmOFeRQm4HACInhZji+hK0e7LJ+G 31d0HIe743qb98q6NjbMij+cjKJ4mH8xZ3xOsBEWbMaN47rowAz9eQkG0sXhOMRl97 TvO6+kdi0aNFXsH9M5Nvocx7O6qaDv5TzETe8OS8= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 07 Mar 2012 13:42:43 +0100 id 00000000005DC045.000000004F5757C3.00001F6C Message-ID: <4F5757C3.7060202@tana.it> Date: Wed, 07 Mar 2012 13:42:43 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120305175124.GR76465@crankycanuck.ca> <4F552745.5020507@Commerco.Net> <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.com> <1722287.sA7CKq2DFd@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807D289@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392807D289@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A suggestion about the experiment document 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, 07 Mar 2012 12:42:45 -0000 On 06/Mar/12 23:05, Murray S. Kucherawy wrote: > > (I'm now observing in my DNS survey that there are also resolvers > and/or firewalls that simply drop queries for unknown types; the > TXT reply comes back right away, the SPF reply never comes. We > might want to mention that too.) Yes, please. Do you measure how many servers do that? From spf2@kitterman.com Wed Mar 7 05:10:49 2012 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 915F721F86EC for ; Wed, 7 Mar 2012 05:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 Lz78ZJ9981NT for ; Wed, 7 Mar 2012 05:10:49 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E308821F867C for ; Wed, 7 Mar 2012 05:10:43 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 67FC120E40FA; Wed, 7 Mar 2012 08:10:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331125843; bh=cl28ycKu55DbbFr4SEqYyrAokhkTElw1lb/laf3TS4s=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=SeCRJLH8nVDJxcYt1fR81w9ZnoN+Ef9rUhX7TmAZfY0Q+jPDpyJWTLnV4m+m8DT2X Sekn90IkUfUQmDP49JIhKUamrjgZneTF3lG44MzsGgCb9BgZoxRP0FSdTMnzn2TY1T HI86yfIfnXJjgWlXrlAbA/7I9bQhfoYpP+EMCh/8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4F48D20E40A3; Wed, 7 Mar 2012 08:10:43 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 07 Mar 2012 08:10:42 -0500 Message-ID: <22187973.cpWMZthzO6@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F575795.7040506@tana.it> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <2317537.fikNkrUavS@scott-latitude-e6320> <4F575795.7040506@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 13:10:49 -0000 On Wednesday, March 07, 2012 01:41:57 PM Alessandro Vesely wrote: > On 07/Mar/12 13:06, Scott Kitterman wrote: > > On Wednesday, March 07, 2012 09:50:26 AM Alessandro Vesely wrote: > >> To me, "do count against this limit" means that for "v=spf1 +mx -all" > >> one has already spent two lookups for the record itself and the mx, so > >> the evaluation fails if the sending address belongs to the ninth > >> eXchanger or further down. No 111 amplification. What am I missing? > > > > First, I don't think there's a lot of point in computing the > > maximum number of lookups possible. > > Why? It doesn't sound difficult to specify of implement. I mean, > isn't it easier to say "you can do at most 111 lookups" than "you can > evaluate at most 10 terms worth 10 lookups each plus an exists as a > bonus"? The 111 is a corner case. Your reformulation makes it the standard case. I don't think it's a good idea. > > Look again at RFC 4408 10.1. > > > > "MUST limit the number of mechanisms and modifiers that do DNS lookups > > to at most 10 per SPF check" > > It may be clearer as: > > MUST limit the number of terms that do DNS lookups to at most 10 > /terms/ per SPF check > > BTW, I don't think "term" is a bad term. Could be, except then you have to go look up what a term is. I don't feel strongly either way. > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/6 > > Sorry for conflating #6 and #24. They really ought to be merged. I don't think so. They are related, but not the same. AIUI, #6 is about refactoring the way the existing processing limits and security considerations and this is about adding a new limit on no data lookups. scott K From agthisell@yahoo.com Wed Mar 7 06:19:38 2012 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 3B03421F880B for ; Wed, 7 Mar 2012 06:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.011 X-Spam-Level: X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_50=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 yJV5NY6k+yjx for ; Wed, 7 Mar 2012 06:19:37 -0800 (PST) Received: from nm13-vm6.bullet.mail.ne1.yahoo.com (nm13-vm6.bullet.mail.ne1.yahoo.com [98.138.91.106]) by ietfa.amsl.com (Postfix) with SMTP id 2F58621F87FB for ; Wed, 7 Mar 2012 06:19:37 -0800 (PST) Received: from [98.138.90.50] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 14:19:34 -0000 Received: from [98.138.226.164] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 14:19:34 -0000 Received: from [127.0.0.1] by omp1065.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 14:19:34 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 255005.63486.bm@omp1065.mail.ne1.yahoo.com Received: (qmail 40346 invoked by uid 60001); 7 Mar 2012 14:19:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1331129974; bh=KHGFeYPA7NWUrPq34xNjmMcXUOnwEcSdMnHFWF12mXU=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=AZT+YZjtn6s0FutyCCrCVIoISyeVC1Van0uvyumEHpMl1j+LcShkAXjz40+mk6plRXuojmVSDXRMJTGXjDktrK1oPudWvWYy4xnZskzF+ve41Z6+0MH1urjFTeXXAkFfMPIuphvrMtAUnn6HK9TSKGUr5RLrEIc7NMRpLQgh5j8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=wNB5GWcuIo2aUnKZPy7snjbsVJm8vBpu+PNvvD3pTKl1AxVUmtAZOrKSPorTnCUsnmP1ukaZz0zyy6FDT4hjC8gOc0J9S3Riv2UYWFXwTc46Wc5Od4jK0gC4TgFW6fWSBRFVHMIEF2jIknv7Ryfv/6aNVNVjEyeLO2GvYeqvD7A=; X-YMail-OSG: mngi4HsVM1lC2mB40rQjUfibbVvJY6fPHcKjgQQDtPaGpa9 P5JC0Q1GXMU3dy8K0WpxU38OJYhAe9P26GizRyHGclw.cLLH1WQApE_tuXwy bMeR01QoeCquHdP52UvI_cPVdjqvG_I1GxBu2a7Q5WWDtuMAQSKRAEwS.mm5 eC91evZUu19HTMtsYp1jVfEkbTOpWQiqvJpU7OFveAsFGaMGHhv2MdMCMUm. J1GEzhjMqwj8QwsTof6iSjdAr6Gnyi8Gb9XCcskd.4VGkxU419nv3c3esnqP qpEBjnB4K4LYknrV_fsa6_kDVqdYtOszqrh3tR6HenKpxAhoUEi3PcXfQi2S HGF8PuBYZydYcW32EgbEz2ou_je6cQ_xICfxpKNpeEBMVh4vmq9AJNndMsBF .PLydOEFyIaWJAEtP0NwPVfwYbB9G9xFmoFoEzSLhKbAoMc1uJt5oow3GuQv .UJAL7ijHlPKilpEpExflvN3loRNICyISAcVDC50td_BVY_USd8EJBrf2fhw j2HJAnEkF Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Wed, 07 Mar 2012 06:19:34 PST X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1331129974.15962.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Wed, 7 Mar 2012 06:19:34 -0800 (PST) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] Possible new issue: Be more liberal with the syntax? 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, 07 Mar 2012 14:19:38 -0000 I realize I'm very late in suggesting issues to be discussed, so I don't know if the ADs will even consider my two possible issues. Their ruling isn't that important to me because I don't think these are critical issues and I can live with them not being considered. I'm breaking up the two issues into two posts for ease of threading... The first issue: Should the syntax checking of SPF records be relaxed at all? The robustness principle says we should be conservative with what we send, but liberal with what we accept. During the design of the SPF spec, it was considered to be very important that all receivers interpret the domain owner's policy the same way, so choices were taken such as requiring all syntax errors to be detected in all cases. I'm not sure if that was the correct choice. One of the things that Caller-ID for Email did right is that Microsoft recognized that you can unambiguously tell a domain name from an IPv4 address from an IPv6 address, so they had one data field for all of them. With SPF, we have a: vs ip4: vs ip6:, and as a result, there used to be a lot of malformed SPF records with things like a:1.2.3.4, or ipv4:example.org. Since it usually is possible to unambiguously determine the intent of the publishers, should we relax the syntax of SPF records so that you can put any kind of addressing in any of the a/ip mechanisms? This would effectively make a:, ip4:, and ip6: aliases of each other, and the same processing would be done on all three. Throw in the new aliases of ip:, ipv4: and ipv6:, and I think you could cover a lot of the malformed SPF records out in the wild. Basically, I'm advocating that RFC4408bis say that domain owners MUST publish in the same format as specified in RFC4408, but implementations MAY choose to consider this extended syntax. Later on, another WG might consider relaxing the MUST publish to a SHOULD publish, or making the aliases officially blessed. Now, I haven't looked at an actual list of SPF records in several years, so I don't know if things have gotten better or worse. I don't know what percentage of SPF records have syntax errors, nor what percentage of those errors would be fixed by this change. I'm not even sure if relaxing the syntax would be a good thing, but it is something I think is worth at least considering. From agthisell@yahoo.com Wed Mar 7 06:39:40 2012 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 04A1021F880C for ; Wed, 7 Mar 2012 06:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.01 X-Spam-Level: X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_50=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 48x7DbHkk8Kl for ; Wed, 7 Mar 2012 06:39:39 -0800 (PST) Received: from nm2-vm5.bullet.mail.ne1.yahoo.com (nm2-vm5.bullet.mail.ne1.yahoo.com [98.138.91.224]) by ietfa.amsl.com (Postfix) with SMTP id DD02421F8805 for ; Wed, 7 Mar 2012 06:39:38 -0800 (PST) Received: from [98.138.90.57] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 14:39:38 -0000 Received: from [98.138.89.174] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 14:39:38 -0000 Received: from [127.0.0.1] by omp1030.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 14:39:38 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 455699.77470.bm@omp1030.mail.ne1.yahoo.com Received: (qmail 61810 invoked by uid 60001); 7 Mar 2012 14:39:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1331131178; bh=kH0NH0DFs22aOrDw0IXVaVkszA/fNKgYnF8/ZLv4J50=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=jEluXmn5K4Iw5DFXDoKqOVU/e1ddaF+3rYVSZV6QhsqTB0ztJAvElFs6bUEempoiDQnodHpc3RRgzzJoANsrOri+UzYALMj2RIsbOKSom3BADGkvF/WULaTIx3RyUXEIf0b+jmnubJNdNug8oHCk8HRMVjeUmszOevks4o1oS/E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=eHWZvpcaZzNAIy6M17a/ntQbQcVftGjqiBw6hj+/z12mBFu4246EMNLnvcC2evUy7VsSBTSI+tMh/BENxCSF5QYEriRR+zXQt83KiT7bmcAXoW3w5d/3Ea1vOJKzPNeCzSJGcSFqnBAF4DHMDyH6TNPl++ToJMLxjV3TLYNXe7s=; X-YMail-OSG: odYqJtMVM1lr79to.VgO33dO0WviVx704mtaoA0.7EOA7Y5 O5tElGKtUvgK3wxfh9yNl2YGATtz.KtcCZ1.7f2nSUan.vsCnal8klrOUcVE 8ha.ojX2TV6WvCUthq8n4nQElJNv1fbp4IjFbYGXgrXzwsernpPlOZJDaxuN 6Rnu2gEX3EQj_DmaJPBIjGyS2FdvIdjVMUGB.ZW5klqVVKHwHp447nhds2pp TivhoB02DKE6wqT2ct2ndXo_g579ayu1MEH1tFxpU.pGX5GNm4eNK3zO8z27 ukTWA5kxzlhpTz1W9S3WWQn7cSNbHQgAx45B9KuU3SEzVLWubTJU5ARZljwa Bu1.ILFVspePywjjOqO293uOaw2epSTH17PODaouZg9D9VNZBX8BlEMnzVdY j_fZPTQgJ6manRFiJMpXwi1kdon4Q88cvt6WpdbU5Gg4P5rvkl_6oi8xtu7q d2X4- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Wed, 07 Mar 2012 06:39:38 PST X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1331131178.44648.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Wed, 7 Mar 2012 06:39:38 -0800 (PST) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] Possible new issue: deprecate ptr/%{p} 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, 07 Mar 2012 14:39:40 -0000 I realize I'm very late in suggesting issues to be discussed, so I don't know if the ADs will even consider my two possible issues. Their ruling isn't that important to me because I don't think these are critical issues and I can live with them not being considered. I'm breaking up the two issues into two posts for ease of threading... Second issue: Should the ptr: mechanism and the %{p} macro be deprecated? Already in RFC 4408, it says: Note: Use of this mechanism is discouraged because it is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the arpa name servers. If used, proper PTR records must be in place for the domain's hosts and the "ptr" mechanism should be one of the last mechanisms checked. Microsoft wanted this to go away entirely, for these reasons. This note in the RFC is terse, so let me lay out the case against these more fully. Maybe things have changed dramatically while I've been asleep, but the in-addr.arpa namespace is a mess. It is poorly maintained, to the point where in some countries, even ISPs can't get delegations for their IP addresses. Queries to this name space often time out, and even when they give an answer, the answer is often bogus. Now, with all the other mechanisms/modifiers, the publisher usually has a great deal of control over the nameservers referenced and the content that gets returned. An mx: mechanism that isn't working right is likely going to cause a lot of other problems so it will be noticed and fixed. The ptr:/%{p} stuff, on the other hand, is under the loose control of the sender, not the publisher. If someone sends mail from a host within a bogus in-addr space, the receiver suffers with the timeouts. The SPF publisher can get inconsistent results when faced with temporary nameserver problems, since error handling is different for ptr/%{p} than other mechanisms/modifiers. I guess all I'm suggesting is that this note should be raised to a SHOULD NOT publish. I wouldn't object to having it removed entirely though. From spf2@kitterman.com Wed Mar 7 06:49:18 2012 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 AB05D21F869D for ; Wed, 7 Mar 2012 06:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 aYZllqgfWdpm for ; Wed, 7 Mar 2012 06:49:17 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4782121F862F for ; Wed, 7 Mar 2012 06:49:13 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AC64320E40FA; Wed, 7 Mar 2012 09:49:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331131752; bh=L0TP07rG5bgll81g/YWd4ZDmlJZ7uKAugetMujUesfk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=MhFw32pd3Ad0qtmoD2zLkwFdCYQ5/q6g526XDtScPhDx2fl146OTsW1AFeRrPlqSR kyTv4kL3w9A+99pq/u+5neUT3xgUXzPIlLfnghgfymwfknxC8sqPs5AQKolgo3w+9y MeVDLKgkj0qwdrXi1vM+bnshpwuqQu3DamMmDRZY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8DF6F20E40A3; Wed, 7 Mar 2012 09:49:12 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 07 Mar 2012 09:49:11 -0500 Message-ID: <2572295.QkTNcT9Kcz@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <1331129974.15962.YahooMailClassic@web125403.mail.ne1.yahoo.com> References: <1331129974.15962.YahooMailClassic@web125403.mail.ne1.yahoo.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] Possible new issue: Be more liberal with the syntax? 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, 07 Mar 2012 14:49:18 -0000 On Wednesday, March 07, 2012 06:19:34 AM Arthur Thisell wrote: > I realize I'm very late in suggesting issues to be discussed, so I don't > know if the ADs will even consider my two possible issues. Their ruling > isn't that important to me because I don't think these are critical issues > and I can live with them not being considered. I'm breaking up the two > issues into two posts for ease of threading... > > The first issue: Should the syntax checking of SPF records be relaxed at > all? > > The robustness principle says we should be conservative with what we send, > but liberal with what we accept. During the design of the SPF spec, it > was considered to be very important that all receivers interpret the domain > owner's policy the same way, so choices were taken such as requiring all > syntax errors to be detected in all cases. I'm not sure if that was the > correct choice. > > One of the things that Caller-ID for Email did right is that Microsoft > recognized that you can unambiguously tell a domain name from an IPv4 > address from an IPv6 address, so they had one data field for all of them. > With SPF, we have a: vs ip4: vs ip6:, and as a result, there used to be a > lot of malformed SPF records with things like a:1.2.3.4, or > ipv4:example.org. > > Since it usually is possible to unambiguously determine the intent of the > publishers, should we relax the syntax of SPF records so that you can put > any kind of addressing in any of the a/ip mechanisms? This would > effectively make a:, ip4:, and ip6: aliases of each other, and the same > processing would be done on all three. Throw in the new aliases of ip:, > ipv4: and ipv6:, and I think you could cover a lot of the malformed SPF > records out in the wild. > > Basically, I'm advocating that RFC4408bis say that domain owners MUST > publish in the same format as specified in RFC4408, but implementations MAY > choose to consider this extended syntax. Later on, another WG might > consider relaxing the MUST publish to a SHOULD publish, or making the > aliases officially blessed. > > Now, I haven't looked at an actual list of SPF records in several years, so > I don't know if things have gotten better or worse. I don't know what > percentage of SPF records have syntax errors, nor what percentage of those > errors would be fixed by this change. I'm not even sure if relaxing the > syntax would be a good thing, but it is something I think is worth at least > considering. My gut feel is that the frequency of these types of errors has been decreasing. Since I maintain the openspf.net/org email test reflector, I've got the recent logs. I checked the most recent just to get a sense of how frequent this is. There were 56 permanent errors in the log (many were duplicates as people often send more than one test message without fixing anything). Only one of them was in this catagory: SPF Permanent Error: Invalid IP4 address: ip4:smptout.secuereserver.net The vast majority of errors were including domains that didn't have SPF records or trivial recursion errors in include where they included themselves. While I agree that, in principle, a:, ip4:, ip6: could have been combined, I think it would be a mistake to do so in 4408bis. I think anything like such a change should be reserved for a future effort that does not have backwards compatibility as a goal. There are implementations that do this sort of thing for private use (pyspf has a "relaxed" mode) and I think that for people who know what they are doing it's OK, but it should not be standardized. Scott K From spf2@kitterman.com Wed Mar 7 06:54:36 2012 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 24F7F21F86EF for ; Wed, 7 Mar 2012 06:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 boPvueoFlZWY for ; Wed, 7 Mar 2012 06:54:35 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD3F21F86E0 for ; Wed, 7 Mar 2012 06:54:35 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D857D20E40FA; Wed, 7 Mar 2012 09:54:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331132074; bh=KTI+y8ks50vm2IjXaWxosl4dwBkKef/vyQYFPjT/Zzk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Bvlj74gojCz1IrRxPQjNoB+BJWylvHTdrzhlnEUwd0Oel1dtx6ivWEdbjoBXo/81H gAtp8UF+sFkvGALpxpCHSXvEnuvemH0o/UQrVscEhtjbQ3xbLjqZ82DoN/zc8XS5bo b/iBkQF2kNYVfgrJsW17XjxpX81WHFYBn+pNJuxY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B866220E40A3; Wed, 7 Mar 2012 09:54:34 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 07 Mar 2012 09:54:34 -0500 Message-ID: <1473407.eEIUMJUJ4l@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <1331131178.44648.YahooMailClassic@web125403.mail.ne1.yahoo.com> References: <1331131178.44648.YahooMailClassic@web125403.mail.ne1.yahoo.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] Possible new issue: deprecate ptr/%{p} 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, 07 Mar 2012 14:54:36 -0000 On Wednesday, March 07, 2012 06:39:38 AM Arthur Thisell wrote: > I realize I'm very late in suggesting issues to be discussed, so I don't > know if the ADs will even consider my two possible issues. Their ruling > isn't that important to me because I don't think these are critical issues > and I can live with them not being considered. I'm breaking up the two > issues into two posts for ease of threading... > > Second issue: Should the ptr: mechanism and the %{p} macro be deprecated? > > Already in RFC 4408, it says: > > Note: Use of this mechanism is discouraged because it is slow, it is > not as reliable as other mechanisms in cases of DNS errors, and it > places a large burden on the arpa name servers. If used, proper PTR > records must be in place for the domain's hosts and the "ptr" > mechanism should be one of the last mechanisms checked. > > Microsoft wanted this to go away entirely, for these reasons. > > This note in the RFC is terse, so let me lay out the case against these more > fully. > > Maybe things have changed dramatically while I've been asleep, but the > in-addr.arpa namespace is a mess. It is poorly maintained, to the point > where in some countries, even ISPs can't get delegations for their IP > addresses. Queries to this name space often time out, and even when they > give an answer, the answer is often bogus. > > Now, with all the other mechanisms/modifiers, the publisher usually has a > great deal of control over the nameservers referenced and the content that > gets returned. An mx: mechanism that isn't working right is likely going > to cause a lot of other problems so it will be noticed and fixed. The > ptr:/%{p} stuff, on the other hand, is under the loose control of the > sender, not the publisher. If someone sends mail from a host within a > bogus in-addr space, the receiver suffers with the timeouts. The SPF > publisher can get inconsistent results when faced with temporary nameserver > problems, since error handling is different for ptr/%{p} than other > mechanisms/modifiers. > > I guess all I'm suggesting is that this note should be raised to a SHOULD > NOT publish. I wouldn't object to having it removed entirely though. Given the backward compatibility requirements in the charter (this feature is used), I don't think removal is in scope. I think discussing making it a SHOULD NOT is a reasonable issue. For a long time (they've changed it now), the Cisco SPF record was v=spf1 ptr:cisco.com ~all. Presumably they know how to make such things work. There are certainly cases where it's just fine. If I were designing from scratch today, I wouldn't included ptr: or %{p}, but we aren't. Scott K From agthisell@yahoo.com Wed Mar 7 07:54:51 2012 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 5A7AB21F859E for ; Wed, 7 Mar 2012 07:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.009 X-Spam-Level: X-Spam-Status: No, score=0.009 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_50=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 46NHy7m-zwEH for ; Wed, 7 Mar 2012 07:54:50 -0800 (PST) Received: from nm5-vm4.bullet.mail.ne1.yahoo.com (nm5-vm4.bullet.mail.ne1.yahoo.com [98.138.91.165]) by ietfa.amsl.com (Postfix) with SMTP id B909521F85C0 for ; Wed, 7 Mar 2012 07:54:50 -0800 (PST) Received: from [98.138.90.53] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 15:54:50 -0000 Received: from [98.138.89.166] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 15:54:50 -0000 Received: from [127.0.0.1] by omp1022.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 15:54:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 309544.32943.bm@omp1022.mail.ne1.yahoo.com Received: (qmail 65951 invoked by uid 60001); 7 Mar 2012 15:54:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1331135690; bh=SDiutpyUoTJrO4VR90ZY4zt/PI4Tjr8qIgJnGrsDGvs=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=SSFU2dSt3OO7aD7LiKN9UiCfy8pgEJQrbbIAG4JmDd+tn4JqMpOyfMMQGn46MoSEDDXtgNrFsobUNDKARkCCivV6MBUDBwHt2djwoWH1UqxgyHf21lcWZBU99Pqw5RrnL1mSDTVXH7IfOHxLhR6MyeAbjX+FJu/c15mSHIf1LVQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=2l4iZTf5Dg2SdzqlbUMvmpz7uJd9uvnIt4EB/6hxwCNsEDBaPZArUUht6ulSh6A9QukGd9G6jpbEaYdnM/ZwJAip4h0BDtYFxH+9mkoXvc/wYhhy4JJgNtx7a+N6f4zghKezjaHB92toh1Ankpo44AzoknOIweawupzyto0jV1w=; X-YMail-OSG: 4NOrmmQVM1kHdaQtMxBhrzb_ZJ8qdKsgM13Pd5gIiONT03Q qxXKB7.j_8tTEqv8tQaE7tnC_k_sJu41fjq3RBbV87PKCy4WArQ0RDAZgMZR DUxwUDXRtXRL2PhuOQjK6ggAgjPBmzAvPlU7qoHhJdWNG6hYhNYCZb6DyRXM DI85n1fchsATDV_Se3AK115xki0epwFrHsU4beOGMtG6KV7wBZNgNR3GhaZ3 zYTYzonJ4bv8QBMChgk21kvbDQ8jRzmZ2C2fPN1bQfF9kNAuG8_9rF2XgAhS sbz2p4K7NdK0hixzMUWsICfzdlwFHvMOpEKjgl_uhHfg_dmDN8wTdVPUYhCF fT6fHmH_Iz4EG3RAAYmWCmBMSGZ3NNsyrZjgeDx3hYYM6evgptTo2y9UMjey PRPn1QxK06qJplX6CXJHv8GSVjPvDkXVJssH6Xu11sAr1o7qKnMs1uJUMtD. ytdg- Received: from [71.61.133.134] by web125405.mail.ne1.yahoo.com via HTTP; Wed, 07 Mar 2012 07:54:49 PST X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1331135689.65072.YahooMailClassic@web125405.mail.ne1.yahoo.com> Date: Wed, 7 Mar 2012 07:54:49 -0800 (PST) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] Possible new issue: deprecate ptr/%{p} 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, 07 Mar 2012 15:54:51 -0000 > Given the backward compatibility requirements in the charter (this feature is > used), I don't think removal is in scope. A backward compatible change would be for ptr:/%{p} to always act as if there were network problems causing all DNS queries for this evaluation to be dropped. This is a pretty common result anyway. In effect, ptr: would never match and %{p} would always evaluate to "unknown". I still lean toward moving the current note to the beginning of the ptr: description section and changing it to "SHOULD NOT publish", but I think we could effectively remove it if we wanted to. From ajs@anvilwalrusden.com Wed Mar 7 07:55:18 2012 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 970D521E80A0 for ; Wed, 7 Mar 2012 07:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 xR+RvrwGLZ1e for ; Wed, 7 Mar 2012 07:55:18 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0C59A21E80A2 for ; Wed, 7 Mar 2012 07:55:18 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C96721ECB41D for ; Wed, 7 Mar 2012 15:55:07 +0000 (UTC) Date: Wed, 7 Mar 2012 10:55:05 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120307155504.GF79276@mail.yitter.info> References: <1331129974.15962.YahooMailClassic@web125403.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1331129974.15962.YahooMailClassic@web125403.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Possible new issue: Be more liberal with the syntax? 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, 07 Mar 2012 15:55:18 -0000 Dear colleagues, On Wed, Mar 07, 2012 at 06:19:34AM -0800, Arthur Thisell wrote: > I realize I'm very late in suggesting issues to be discussed, so I > don't know if the ADs will even consider my two possible issues. I don't know what the ADs will say about it, but the chairs have been clear that we will not rule out of scope issues that come up and that meet the charter. A technical issue is a technical issue, and we'll deal with them as long as they're on-charter. There may, of course, also be issues that would not be on charter, but that could be the basis for future work. > One of the things that Caller-ID for Email did right is that > Microsoft recognized that you can unambiguously tell a domain name > from an IPv4 address from an IPv6 address No hat. It's funny you should say that; there's currently a great deal of gnashing of teeth over how you can do that. How can you unambiguously tell a domain name from an IPv4 address? What if the list of TLDs changes dramatically? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From agthisell@yahoo.com Wed Mar 7 08:35:51 2012 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 49F4721E8028 for ; Wed, 7 Mar 2012 08:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.008 X-Spam-Level: X-Spam-Status: No, score=0.008 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_50=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 pGeJ0gzb8D9Q for ; Wed, 7 Mar 2012 08:35:50 -0800 (PST) Received: from nm22-vm6.bullet.mail.ne1.yahoo.com (nm22-vm6.bullet.mail.ne1.yahoo.com [98.138.91.115]) by ietfa.amsl.com (Postfix) with SMTP id 8BA3221E8017 for ; Wed, 7 Mar 2012 08:35:50 -0800 (PST) Received: from [98.138.90.53] by nm22.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 16:35:45 -0000 Received: from [98.138.87.8] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 16:35:45 -0000 Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP; 07 Mar 2012 16:35:45 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 66704.51149.bm@omp1008.mail.ne1.yahoo.com Received: (qmail 71898 invoked by uid 60001); 7 Mar 2012 16:35:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1331138143; bh=c4Uq4v1yLgEwkpchKonnAAXExpHK51BPTLVbTB0g/qg=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=jQeKnlr589hjKuisOofjPLt+63uIuJkim8ljIGqSoAYuhMi51Q2SlAH2fCUcJI3lhuksO3T6oM4wyCmCQvt1CCt+14V1RMVOMkpX6vJMW13S/pDyUDij2dJyReViB4RT5VzeFXHd3JUg0u3sseFSCTp6pJ6UbSQkowhMQ2pQ8ak= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=Nqm1pvOT8qVxD7u/r7KY6Bgo9h3b2opT/EquWzk27jxAFfZC6lYRKpyeSxJEIVouj5+uAAFn8s1F6QnXKEOtqi89pjHnlQxH9P8mD78xLRhJIP+FBCrkBx/Ex98qBf6R32tWKuKIVWt/TxzpLKfMwUwtwvAdcd4ITQS5idy0ppY=; X-YMail-OSG: Z3JkK.YVM1mkKi60xA2eBgdX2tMHzY8cA5CqLco22L5x861 _aPe1nEkO_bGrMEmmxIqUdb2RsuY219JnLSMuuUIJn.gjW.TZvRTr4GkmAxI aGYHTTkYMYnEB5oJ8mVHsnNXDZFtGdWmsassDswF2FQ2jHXgxrssi8YhcLnK e3NgysdtbOP4WJzBDXI3.IWlcS6Wbtyfkg7nMXH8FFtk8qvFdXJQovP3KAky 8V8emPv265gqGJdGGIDFDkKtg4w.38MhzNef.yN0P1CDUwfNf7z63xWS09VX hEAtFqxSfmcG6T67zxowrU6n98NuTHzOZYTUSk1Endpp_Tqzwp0VcPRfOzaE 9vEqYisl6Yfty_F36y1QQuk7nt_Z05oKAwJrEdE4kYqBhcFwLil62OoFrjaz Wrv14MxHWzoxDcEVFb8Szw_s2s9P8OSzWlzmf6PnplokaxR0APXVn9YoBFY. pr3w- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Wed, 07 Mar 2012 08:35:43 PST X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1331138143.53594.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Wed, 7 Mar 2012 08:35:43 -0800 (PST) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] Possible new issue: Be more liberal with the syntax? 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, 07 Mar 2012 16:35:51 -0000 > I don't know what the ADs will say about it, *sigh* Clearly, I needed more coffee before posting this morning. > No hat. It's funny you should say that; there's currently a great > deal of gnashing of teeth over how you can do that. How can you > unambiguously tell a domain name from an IPv4 address? What if the > list of TLDs changes dramatically? A domain name must have at least one ALPHA character in each label, an IPv4 address must have all numeric labels (in the range of 0-255), and an IPv6 address basically must have a colon. This is all spelled out in the ABNF in RFC 4408 (see ip4-network, ip6-network and domain-spec). Somewhere in the MARID posts, here is a regular expression that matches all valid SPF records. The RFC 4408 ABNF is restricted enough that it can be run through ABNF->re converts. If there are real issues distinguishing these, then it is likely that the RFC 4408 ABNF is wrong and needs to be fixed/clarified. From johnl@iecc.com Wed Mar 7 09:14:12 2012 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 EF42C21F87AE for ; Wed, 7 Mar 2012 09:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.217 X-Spam-Level: X-Spam-Status: No, score=-110.217 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 9LzXezaYf0k4 for ; Wed, 7 Mar 2012 09:14:12 -0800 (PST) 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 F19DC21F87A9 for ; Wed, 7 Mar 2012 09:14:11 -0800 (PST) Received: (qmail 62289 invoked from network); 7 Mar 2012 17:14:10 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Mar 2012 17:14: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:vbr-info; s=4f579762.xn--hew.k1203; i=johnl@user.iecc.com; bh=n2dWusfkSp5SAJ4YIJuNe+1zPzfvpmNfWfqAORHOluw=; b=pAl5+iX22vpasJGHTkMdvbMYhIaesQ2Ot6JTLVb5iXXElZi0gMmqmQMOdhC4wbnUwHFn6CJu8cb/cMhV86GMKgowmxMWl6YBuqMzQc/UuOyJv91meUdKjSf2qCKJwt2LCA7Epq59aqgVEQhknNilk8s/rnXa/004CoRAw39dMUY= 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:vbr-info; s=4f579762.xn--hew.k1203; olt=johnl@user.iecc.com; bh=n2dWusfkSp5SAJ4YIJuNe+1zPzfvpmNfWfqAORHOluw=; b=ok7SfxiEzbCCgjpWFWB+Oue2HVNqxz3Vgo/v74AQJafY59wDUO94v/sxP70UIJlEVSFUW49oPUYG2N0/kIcjpg/cfvI4Eg5QoEa8MM/IOQTcGKZx5gKf4OC77qQoKp/M6iJsxyTgpIfifNiqrecaQd3W3Km3+kk4b9YFvF/jOSg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 7 Mar 2012 17:13:48 -0000 Message-ID: <20120307171348.68168.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1331129974.15962.YahooMailClassic@web125403.mail.ne1.yahoo.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: agthisell@yahoo.com Subject: Re: [spfbis] Possible new issue: Be more liberal with the syntax? 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, 07 Mar 2012 17:14:13 -0000 >The first issue: Should the syntax checking of SPF records be relaxed at all? Heck, no. Implementations are always allowed to work around bugs if they want to, but the best way to interoperate is to provide a clear spec and encourage people to implement it correctly. I suppose it would be mostly harmless to add an appendix noting common errors and how not to make them, but I fear that some people would insist on misreading it as if if's in the RFC it must be OK. R's, John From johnl@iecc.com Wed Mar 7 09:17:21 2012 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 DDC2721E80F7 for ; Wed, 7 Mar 2012 09:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.226 X-Spam-Level: X-Spam-Status: No, score=-110.226 tagged_above=-999 required=5 tests=[AWL=0.973, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 QXKVJya90wQ9 for ; Wed, 7 Mar 2012 09:17:21 -0800 (PST) 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 1844321E80F6 for ; Wed, 7 Mar 2012 09:17:20 -0800 (PST) Received: (qmail 62891 invoked from network); 7 Mar 2012 17:17:20 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Mar 2012 17:17:20 -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:vbr-info; s=4f579820.xn--btvx9d.k1203; i=johnl@user.iecc.com; bh=vIpYTFcUtPNmmoFNUlDn9PfnJoBK4sdk1+Of4jv3BqM=; b=gm9XCGR4loVkSABDsCP16mnTpZMH68uE+eBwiAnQxUT/xB8MqCwsZQUTtZfrpeGcewOAkmStCBIBrNlJrL3bmgA8kW5qFrT1UWXm+Q/4gvV226pkLSqvGqhT+o52JLenaQGOH7p70xx6Tpq05p0gLc0e4LgAMFEHHINwTWzliKA= 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:vbr-info; s=4f579820.xn--btvx9d.k1203; olt=johnl@user.iecc.com; bh=vIpYTFcUtPNmmoFNUlDn9PfnJoBK4sdk1+Of4jv3BqM=; b=Lo8sF4lZXhIhv74bEDVkQ4uqLKdeGhfQ4gXMrg3tH2Abe0m3+XoMw0I3a66A0qAMaZDH01XQtGuuTtDDF0k8rYu3+YKeSc0oqdKb3BEMkXBT+AUqlqZ6cFBEvpr1YQP0aLY/mqQ7c+TJVUowoyt08CnKSgt7ELgX3NBYq0BMs8k= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 7 Mar 2012 17:16:58 -0000 Message-ID: <20120307171658.68291.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1331135689.65072.YahooMailClassic@web125405.mail.ne1.yahoo.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: agthisell@yahoo.com Subject: Re: [spfbis] Possible new issue: deprecate ptr/%{p} 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, 07 Mar 2012 17:17:22 -0000 >A backward compatible change would be for ptr:/%{p} to always act as if there were network >problems causing all DNS queries for this evaluation to be dropped. No, it wouldn't. For people who use PTR and whose rDNS is set up correctly (there is plenty of rDNS that works correctly), it would break records that work now. SHOULD NOT is fine. R's, John From vesely@tana.it Wed Mar 7 09:43:19 2012 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 1D82521E801B for ; Wed, 7 Mar 2012 09:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.657 X-Spam-Level: X-Spam-Status: No, score=-4.657 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gt8q1N45DeRL for ; Wed, 7 Mar 2012 09:43:18 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3C52621E8017 for ; Wed, 7 Mar 2012 09:43:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1331142195; bh=NlpCC6G6LvNl1b6lyZkVMv6iak6x4ttfIn0Sid1n/YQ=; l=1785; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=OvgV2fsTsoF2c9kjIs0Ga/aHpeIDaJFmkXXGKeYixmymnVjcELNhgUAUza4fRcQ+F ouSpqeEvLdV+NPyZ3mkUh7BRkAVYcgsobndlE/xe065ITLqPjPhfhQ0kRZiBp6CTXc s5AlIf+BgJw2j3fMPApEbdg//FAtcWWyQKPFS81c= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 07 Mar 2012 18:43:15 +0100 id 00000000005DC03F.000000004F579E33.00006991 Message-ID: <4F579E33.4000102@tana.it> Date: Wed, 07 Mar 2012 18:43:15 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <2317537.fikNkrUavS@scott-latitude-e6320> <4F575795.7040506@tana.it> <22187973.cpWMZthzO6@scott-latitude-e6320> In-Reply-To: <22187973.cpWMZthzO6@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 17:43:19 -0000 On 07/Mar/12 14:10, Scott Kitterman wrote: > On Wednesday, March 07, 2012 01:41:57 PM Alessandro Vesely wrote: >> On 07/Mar/12 13:06, Scott Kitterman wrote: >>> >>> First, I don't think there's a lot of point in computing the >>> maximum number of lookups possible. >> >> Why? It doesn't sound difficult to specify of implement. I mean, >> isn't it easier to say "you can do at most 111 lookups" than "you can >> evaluate at most 10 terms worth 10 lookups each plus an exists as a >> bonus"? > > The 111 is a corner case. Your reformulation makes it the standard > case. I don't think it's a good idea. No, wait. I don't mean one /has/ to do all the lookups. The limit is meant to guard against an excessive number of lookups, whether malicious or buggy. As long as we believe that's not the norm, and only happens in corner cases, a non-partitioned amount of lookups may be more flexible and simpler than a structured limit devised to prevent a particular attack only. >> MUST limit the number of terms that do DNS lookups to at most 10 >> /terms/ per SPF check >> >> BTW, I don't think "term" is a bad term. > > Could be, except then you have to go look up what a term is. I don't feel > strongly either way. I'd be fine with a better term. The point is, as Arthur noted, that it has to be repeated twice in that sentence. >> Sorry for conflating #6 and #24. They really ought to be merged. > > I don't think so. They are related, but not the same. > > AIUI, #6 is about refactoring the way the existing processing limits and > security considerations and this is about adding a new limit on no data > lookups. Except in case we find out that a better refactoring of processing limits can cover the full threat space, making #24 moot. From ajs@anvilwalrusden.com Wed Mar 7 10:02:18 2012 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 6906221E8017 for ; Wed, 7 Mar 2012 10:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 oc9JcHDrI9ff for ; Wed, 7 Mar 2012 10:02:17 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id EC54E21F84CD for ; Wed, 7 Mar 2012 10:02:16 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 182C21ECB41D for ; Wed, 7 Mar 2012 18:02:16 +0000 (UTC) Date: Wed, 7 Mar 2012 13:02:14 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120307180213.GP79276@mail.yitter.info> References: <1331138143.53594.YahooMailClassic@web125403.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1331138143.53594.YahooMailClassic@web125403.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Possible new issue: Be more liberal with the syntax? 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, 07 Mar 2012 18:02:18 -0000 No hat. On Wed, Mar 07, 2012 at 08:35:43AM -0800, Arthur Thisell wrote: > > A domain name must have at least one ALPHA character in each label, > an IPv4 address must have all numeric labels (in the range of > 0-255), and an IPv6 address basically must have a colon. This is > all spelled out in the ABNF in RFC 4408 (see ip4-network, > ip6-network and domain-spec). This is interesting, and I hadn't put it together before. I think your argument isn't quite right, but I think you're nevertheless correct that under RFC 4408 rules you _can_ unambiguously differentiate these three different types of thing. Phew. For those who care about the argument: RFC 1123 has some rules about host names (not, actually, domain names; RFC 3696, which is the basis for section 8.1 in RFC 4408, is informational, but 1123 assuredly isn't. Confusion about host vs. domain names is rampant, and I'm going to glide over it for now). Depending on how you read it, RFC 1123 either makes a normative claim that top-level labels in host names must be "alphabetic" (which in the context means [a-zA-Z]) or else makes a statement about then-current root zone policy. There is an open dispute about which interpretation of 1123 is right. This turns out to be important because some time ago ICANN started delegating DNS names from the root using IDNA. Every one of those labels starts with "xn--", which means that at the very least there will be hyphens (non-alphabetic characters) in there; it works out that digits are also possible. This means that every one of those new TLDs will fail any strict SPF checker if they're really doing what section 8.1 of 4408 says. I may be misreading it, but I don't think 4408 requires an alphabetic character in every label. If it does, it's seriously broken. While RFC 952 required every label to start with an alphabetic character (thereby ensuring that every label had at least one alphabetic character), RFC 1123 explicitly relaxed this requirement, as the DISCUSSION in section 2.1 makes clear: If a dotted-decimal number can be entered without such identifying delimiters, then a full syntactic check must be made, because a segment of a host domain name is now allowed to begin with a digit and could legally be entirely numeric (see Section 6.1.2.4). However, a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic. (It's actually the "will be alphabetic" bit at the end of that DISCUSSION that is the source of controversy.) RFC 4408 does give us some reason for hope, however, and that it that it also has rules about IPv4 and IPv6 addresses, which allow us to distinguish even when, in general, we might not be able to. (The general problem is that IP addresses can appear in forms that are _not_ the usual forms, but since there is a restriction on what an IP address could be, we might be ok.) Unless I'm misreading it, RFC 4408 doesn't enforce the "must be alphabetic" rule, but instead just requires an alphabetic at the beginning of the label: toplabel = ( *alphanum ALPHA *alphanum ) / ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ; LDH rule plus additional TLD restrictions ; (see [RFC3696], Section 2) alphanum = ALPHA / DIGIT So RFC 4408 is actually more relaxed than RFC 1123 (on the "strict" reading), but that's a good thing because the actual root zone needs it to be more relaxed. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Wed Mar 7 10:05:00 2012 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 3460521F8508 for ; Wed, 7 Mar 2012 10:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 LtzlGBfvdOJg for ; Wed, 7 Mar 2012 10:04:59 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id D508521F84E1 for ; Wed, 7 Mar 2012 10:04:51 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 7 Mar 2012 10:04:51 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] A suggestion about the experiment document Thread-Index: AQHM++Ayo8UtTDDDakGOtdvfYndHQpZeVhkA//960ACAAX0HgP//05Qw Date: Wed, 7 Mar 2012 18:04:50 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807E554@exch-mbx901.corp.cloudmark.com> References: <20120305175124.GR76465@crankycanuck.ca> <4F552745.5020507@Commerco.Net> <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.com> <1722287.sA7CKq2DFd@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807D289@exch-mbx901.corp.cloudmark.com> <4F5757C3.7060202@tana.it> In-Reply-To: <4F5757C3.7060202@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] A suggestion about the experiment document 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, 07 Mar 2012 18:05:00 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Wednesday, March 07, 2012 4:43 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] A suggestion about the experiment document >=20 > On 06/Mar/12 23:05, Murray S. Kucherawy wrote: > > (I'm now observing in my DNS survey that there are also resolvers > > and/or firewalls that simply drop queries for unknown types; the TXT > > reply comes back right away, the SPF reply never comes. We might want > > to mention that too.) >=20 > Yes, please. Do you measure how many servers do that? The current survey does not, unfortunately. I only noticed the pattern onc= e it was well into its run. I can, of course, add that check and re-run it= . But I'm not sure it matters that much to get numbers; observing that it = happens at all is interesting by itself. -MSK From spf2@kitterman.com Wed Mar 7 10:05:47 2012 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 3475521F85B5 for ; Wed, 7 Mar 2012 10:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 SKzQ4MHq0fN7 for ; Wed, 7 Mar 2012 10:05:43 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D87E021F85A4 for ; Wed, 7 Mar 2012 10:05:37 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5476820E40FA; Wed, 7 Mar 2012 13:05:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331143537; bh=htyLZau2vjKAedgXgbHhajip/CadyAzlt3t2c64jYFo=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=m3e4GC2/W3cNqdCAVs+7GB/+rD/R1UzyWTKnoOm1DFGNyz+9zvwuYE46wP3WBJ2EN JLbmQ3pKFxqSRI0fQjO2I1pxeQT2YzF29hfka7wqK//px7LEJjYTVabSIXgWbwWy/m kHuXhJO5rs1Br2KrrlvEuwaC4Hz3qD6EgB05TaDA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 39C6B20E40A3; Wed, 7 Mar 2012 13:05:37 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 07 Mar 2012 13:05:36 -0500 Message-ID: <5370057.tXlR2v9Toq@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F579E33.4000102@tana.it> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <22187973.cpWMZthzO6@scott-latitude-e6320> <4F579E33.4000102@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 18:05:47 -0000 On Wednesday, March 07, 2012 06:43:15 PM Alessandro Vesely wrote: > On 07/Mar/12 14:10, Scott Kitterman wrote: > > On Wednesday, March 07, 2012 01:41:57 PM Alessandro Vesely wrote: > >> On 07/Mar/12 13:06, Scott Kitterman wrote: > >>> > >>> > >>> First, I don't think there's a lot of point in computing the > >>> maximum number of lookups possible. > >> > >> > >> > >> Why? It doesn't sound difficult to specify of implement. I mean, > >> isn't it easier to say "you can do at most 111 lookups" than "you can > >> evaluate at most 10 terms worth 10 lookups each plus an exists as a > >> bonus"? > > > > > > > > The 111 is a corner case. Your reformulation makes it the standard > > case. I don't think it's a good idea. > > No, wait. I don't mean one has to do all the lookups. The limit is > meant to guard against an excessive number of lookups, whether > malicious or buggy. As long as we believe that's not the norm, and > only happens in corner cases, a non-partitioned amount of lookups may > be more flexible and simpler than a structured limit devised to > prevent a particular attack only. The current rules are: No more than 10 terms that need DNS lookups No more than 10 a lookups from an mx mechanism No more than 10 a lookups from a PTR mechanism. So there is currently a primary limit of 10 and a secondary limit of 10 lookups per primary of a certain type. Is there any evidence that the primary limit of 10 is not adequate? I am not aware of any. Most of the largest email providers that exist have published records that fit within this limit. Why would we want to change it? Because we're changing the spec and it makes the spec clearer is not a good reason if it requires code to be re-written. Your proposal would. As has been mentioned, one of the primary design principles in SPF was to produce a deterministic output based on a defined input. If we change the current 1 + 10 + 10*10 limit to 111, then every SPF library that properly implements RFC 4408 10.1 would have to be changed. Based on that, I think the proposal is out of scope, but I also think it's a bad idea in any case. Scott K From ajs@anvilwalrusden.com Wed Mar 7 10:17:10 2012 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 AABF721F86B6 for ; Wed, 7 Mar 2012 10:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 un8c0BA9fL2I for ; Wed, 7 Mar 2012 10:17:09 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 70B6E21F86D0 for ; Wed, 7 Mar 2012 10:16:59 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9FB8D1ECB41D for ; Wed, 7 Mar 2012 18:16:58 +0000 (UTC) Date: Wed, 7 Mar 2012 13:16:57 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120307181656.GS79276@mail.yitter.info> References: <20120305175124.GR76465@crankycanuck.ca> <4F552745.5020507@Commerco.Net> <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.com> <1722287.sA7CKq2DFd@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807D289@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9452079D1A51524AA5749AD23E00392807D289@exch-mbx901.corp.cloudmark.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] A suggestion about the experiment document 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, 07 Mar 2012 18:17:10 -0000 No hat. On Tue, Mar 06, 2012 at 10:05:50PM +0000, Murray S. Kucherawy wrote: > > (I'm now observing in my DNS survey that there are also resolvers and/or firewalls that simply drop queries for unknown types; the TXT reply comes back right away, the SPF reply never comes. We might want to mention that too.) > This is a well-known problem, and was something people worried about with DNSSEC. See http://www.iis.se/docs/Routertester_en.pdf, http://www.icann.org/committees/security/sac035.pdf, and RFC 5625. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Wed Mar 7 10:51:02 2012 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 C4AB011E8072 for ; Wed, 7 Mar 2012 10:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 DcBgEbzzxh5i for ; Wed, 7 Mar 2012 10:51:00 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E211511E8079 for ; Wed, 7 Mar 2012 10:50:58 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.238.195]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q27IojlH016626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Mar 2012 10:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331146256; i=@elandsys.com; bh=FbN0Nny+bpIVngB8i8jE4fkJPmWiuScZpu/inSTTMoU=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=mYZCtmpN/1bwBmo6Cw/id3D/wNRizL5UgqqqTf27lb663ra34g5WmfAlHw10SbZ0P 9jhpz3TgO+w+S+UZMRIVTZw9Iyjwn2mX/Tue8xUrqZfVoLorWk7tH/wiojnAphXTlR QpuXIagJ5F2BpG3Ctw1DLzGqYdfDT8bRSKSAgnj0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331146256; i=@elandsys.com; bh=FbN0Nny+bpIVngB8i8jE4fkJPmWiuScZpu/inSTTMoU=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=AyhTSqtL9mlkSD/E2TVR5PupxEazYfS80OyRlXqj2hrIx0YbltW3Mb++NiGEr1qUy ETkY9oTizDAftWrwns4TROjLeM8VIlbQ5nYLhhDxtcvWnb04JnqLN4iaRVf642NHyZ wZYRaXbIZsv1yFnLQHk3DvYbH2xzOyPGfIsqoFbU= Message-Id: <6.2.5.6.2.20120307101107.0a9edd70@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 07 Mar 2012 10:21:11 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1331129974.15962.YahooMailClassic@web125403.mail.ne1.yahoo .com> References: <1331129974.15962.YahooMailClassic@web125403.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Possible new issue: Be more liberal with the syntax? 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, 07 Mar 2012 18:51:02 -0000 At 06:19 07-03-2012, Arthur Thisell wrote: >The first issue: Should the syntax checking of SPF records be >relaxed at all? This is being tracked as Issue #26. There is also a ticket for the second issue that was raised today. Could we defer the discussion on this issue until the thread is open? Regards, S. Moonesamy SPFBIS WG co-chair From msk@cloudmark.com Wed Mar 7 11:01:11 2012 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 5E82C11E8085 for ; Wed, 7 Mar 2012 11:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 8x+cxxqxIOPo for ; Wed, 7 Mar 2012 11:01:10 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id F0B3211E8086 for ; Wed, 7 Mar 2012 11:01:09 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Wed, 7 Mar 2012 11:01:09 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] A suggestion about the experiment document Thread-Index: AQHM++Ayo8UtTDDDakGOtdvfYndHQpZeVhkA//960ACAAdppgP//hbKQ Date: Wed, 7 Mar 2012 19:01:08 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807E75B@exch-mbx901.corp.cloudmark.com> References: <20120305175124.GR76465@crankycanuck.ca> <4F552745.5020507@Commerco.Net> <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.com> <1722287.sA7CKq2DFd@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807D289@exch-mbx901.corp.cloudmark.com> <20120307181656.GS79276@mail.yitter.info> In-Reply-To: <20120307181656.GS79276@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] A suggestion about the experiment document 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, 07 Mar 2012 19:01:11 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Andrew Sullivan > Sent: Wednesday, March 07, 2012 10:17 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] A suggestion about the experiment document >=20 > No hat. "Fifty Mission Cap" here. > > (I'm now observing in my DNS survey that there are also resolvers > > and/or firewalls that simply drop queries for unknown types; the TXT > > reply comes back right away, the SPF reply never comes. We might want > > to mention that too.) >=20 > This is a well-known problem, and was something people worried about > with DNSSEC. See http://www.iis.se/docs/Routertester_en.pdf, > http://www.icann.org/committees/security/sac035.pdf, and RFC 5625. Is that a suggestion that we shouldn't bother talking about it, or that we = should and this is potential reference material? I think this is interesti= ng data resulting from our surveys, but I don't want to beat a dead horse i= f we don't have anything new to contribute. -MSK From spf2@kitterman.com Wed Mar 7 11:15:44 2012 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 57A9D11E808F for ; Wed, 7 Mar 2012 11:15:44 -0800 (PST) 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 2VbPOLdVUGbd for ; Wed, 7 Mar 2012 11:15:43 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 845C111E808E for ; Wed, 7 Mar 2012 11:15:43 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 8D643D04066; Wed, 7 Mar 2012 13:15:42 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331147742; bh=Zr8ydfsJ/+xuPCiL0XVOfGRNW/cbUy5pfGs/kcuBqkc=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=oAi3BnIkWdNdtlOx4byO+MSDdU5jP6I27iwrqOPHIhd+ItI3L39h+2AqbYwR5zabG O/Tgw7Wd5w0HmwKbR5/t8jfebzf+lIaJ9oryMoFo2ieI+00OMpA3LUnaHxGxDcwIPE GvkR6ZHdJ2FgazvgJM3889gmNgiEEw5HL6JF0n/M= Received: from 67.sub-97-10-2.myvzw.com (67.sub-97-10-2.myvzw.com [97.10.2.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id BD9DFD04018; Wed, 7 Mar 2012 13:15:41 -0600 (CST) References: <20120305175124.GR76465@crankycanuck.ca> <4F552745.5020507@Commerco.Net> <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.com> <1722287.sA7CKq2DFd@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807D289@exch-mbx901.corp.cloudmark.com> <20120307181656.GS79276@mail.yitter.info> <9452079D1A51524AA5749AD23E00392807E75B@exch-mbx901.corp.cloudmark.com> User-Agent: K-9 Mail for Android In-Reply-To: <9452079D1A51524AA5749AD23E00392807E75B@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 07 Mar 2012 14:15:45 -0500 To: "spfbis@ietf.org" Message-ID: <3437eb48-bca1-43bc-961e-56664d9832d3@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A suggestion about the experiment document 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, 07 Mar 2012 19:15:44 -0000 "Murray S. Kucherawy" wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On >Behalf Of Andrew Sullivan >> Sent: Wednesday, March 07, 2012 10:17 AM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] A suggestion about the experiment document >> >> No hat. > >"Fifty Mission Cap" here. > >> > (I'm now observing in my DNS survey that there are also resolvers >> > and/or firewalls that simply drop queries for unknown types; the >TXT >> > reply comes back right away, the SPF reply never comes. We might >want >> > to mention that too.) >> >> This is a well-known problem, and was something people worried about >> with DNSSEC. See http://www.iis.se/docs/Routertester_en.pdf, >> http://www.icann.org/committees/security/sac035.pdf, and RFC 5625. > >Is that a suggestion that we shouldn't bother talking about it, or that >we should and this is potential reference material? I think this is >interesting data resulting from our surveys, but I don't want to beat a >dead horse if we don't have anything new to contribute. If I may stretch the metaphor... I'd suggest that since people are still claiming new RR types are useful (Type SPF is hardly new anymore, but that only amplifies the point), the horse isn't dead and you ought to reload the shotgun. Scott K From R.E.Sonneveld@sonnection.nl Wed Mar 7 11:19:08 2012 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 E85FE11E8095 for ; Wed, 7 Mar 2012 11:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 zJnBRCCoMBWT for ; Wed, 7 Mar 2012 11:19:08 -0800 (PST) Received: from mx11.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id D386211E8094 for ; Wed, 7 Mar 2012 11:19:07 -0800 (PST) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0M0J00B004BUUR00@hydrogen.mailtransaction.com>; Wed, 07 Mar 2012 20:19:06 +0100 (CET) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0M0J0024B4BTEL00@hydrogen.mailtransaction.com>; Wed, 07 Mar 2012 20:19:06 +0100 (CET) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0M0J008074BT2E00@lion.sonnection.nl> for spfbis@ietf.org; Wed, 07 Mar 2012 20:19:05 +0100 (CET) Message-id: <4F57B62E.9070307@sonnection.nl> Date: Wed, 07 Mar 2012 20:25:34 +0100 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Scott Kitterman References: <20120305175124.GR76465@crankycanuck.ca> <4F552745.5020507@Commerco.Net> <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.com> <1722287.sA7CKq2DFd@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807D289@exch-mbx901.corp.cloudmark.com> <20120307181656.GS79276@mail.yitter.info> <9452079D1A51524AA5749AD23E00392807E75B@exch-mbx901.corp.cloudmark.com> <3437eb48-bca1-43bc-961e-56664d9832d3@email.android.com> In-reply-to: <3437eb48-bca1-43bc-961e-56664d9832d3@email.android.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1331147946; bh=vqiOj3TlX0uA7SOHCg1yRDHaxTpoMveYIfNclgk9YQY=; h=MIME-version:Content-transfer-encoding:Content-type:Message-id: Date:From:To:Cc:Subject:References:In-reply-to; b=D5wQPaJ5obFQNWZSSduKqsB6zuyPrw+qVUuJE2pNruLU2x+n18esVixIEqli8/J0D f4WoFYg1/Ajk7uNPtK1EBE67ZODbkSh4fi+RwdgsGkARM6mxLDuiGzIVKBXtxp1ajD 5Ek32CMrKGzQA9Iq5lERvU6FMkRAcESCQrslqDn0= X-DKIM: OpenDKIM Filter v2.4.3 hydrogen.mailtransaction.com 0M0J00B004BUUR00 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] A suggestion about the experiment document 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, 07 Mar 2012 19:19:09 -0000 On 3/7/12 8:15 PM, Scott Kitterman wrote: > > "Murray S. Kucherawy" wrote: > >>> -----Original Message----- >>> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On >> Behalf Of Andrew Sullivan >>> Sent: Wednesday, March 07, 2012 10:17 AM >>> To: spfbis@ietf.org >>> Subject: Re: [spfbis] A suggestion about the experiment document >>> >>> No hat. >> "Fifty Mission Cap" here. >> >>>> (I'm now observing in my DNS survey that there are also resolvers >>>> and/or firewalls that simply drop queries for unknown types; the >> TXT >>>> reply comes back right away, the SPF reply never comes. We might >> want >>>> to mention that too.) >>> This is a well-known problem, and was something people worried about >>> with DNSSEC. See http://www.iis.se/docs/Routertester_en.pdf, >>> http://www.icann.org/committees/security/sac035.pdf, and RFC 5625. >> Is that a suggestion that we shouldn't bother talking about it, or that >> we should and this is potential reference material? I think this is >> interesting data resulting from our surveys, but I don't want to beat a >> dead horse if we don't have anything new to contribute. > If I may stretch the metaphor... > > I'd suggest that since people are still claiming new RR types are useful (Type SPF is hardly new anymore, but that only amplifies the point), the horse isn't dead and you ought to reload the shotgun. in other words: document it, either by describing the problem in a few lines or adding a reference to the documents Andrew mentioned (or both), /rolf From ajs@anvilwalrusden.com Wed Mar 7 11:19:50 2012 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 32C5711E8087 for ; Wed, 7 Mar 2012 11:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 pZqKwfV25JQo for ; Wed, 7 Mar 2012 11:19:48 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id AE7F311E8072 for ; Wed, 7 Mar 2012 11:19:48 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A186C1ECB41D for ; Wed, 7 Mar 2012 19:19:38 +0000 (UTC) Date: Wed, 7 Mar 2012 14:19:36 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120307191936.GT79276@mail.yitter.info> References: <20120305175124.GR76465@crankycanuck.ca> <4F552745.5020507@Commerco.Net> <9452079D1A51524AA5749AD23E00392807D174@exch-mbx901.corp.cloudmark.com> <1722287.sA7CKq2DFd@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807D289@exch-mbx901.corp.cloudmark.com> <20120307181656.GS79276@mail.yitter.info> <9452079D1A51524AA5749AD23E00392807E75B@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9452079D1A51524AA5749AD23E00392807E75B@exch-mbx901.corp.cloudmark.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] A suggestion about the experiment document 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, 07 Mar 2012 19:19:50 -0000 On Wed, Mar 07, 2012 at 07:01:08PM +0000, Murray S. Kucherawy wrote: > Is that a suggestion that we shouldn't bother talking about it, or > that we should and this is potential reference material? I think > this is interesting data resulting from our surveys, but I don't > want to beat a dead horse if we don't have anything new to > contribute. I guess with my hat on, it would be useful to point to it and say, "Here are some observations, possibly related to [references]." For the latter, I'd particularly encourage citing the proxy recommendations, since they seem to be part of what's giving you trouble. A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Wed Mar 7 12:08:16 2012 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 AFE8F11E80BE for ; Wed, 7 Mar 2012 12:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 e0yraZXcgvbe for ; Wed, 7 Mar 2012 12:08:15 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8585A11E80BB for ; Wed, 7 Mar 2012 12:08:15 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E509F20E40FA; Wed, 7 Mar 2012 15:08:14 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331150894; bh=eZQbd3uJ+/LJB0WC1S0nhhrfTTWDkPKEeza7N7FUSfc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=B8L6upymuztuP4E0TTl8EUh19D/N/d43dj2r5PU1/vVtkqq3nwsO9wVnjjSYUME2B Vev/ZxoeXKPha6r8aa3OqsKumU6AX6H/oaz4ADi3+ofFvIPXWCZZ70IrvTvOMVGfTy HKX38imUGAc+fmk1eQg3Y54dLVKF82bppW8VJkro= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C7F3820E40A3; Wed, 7 Mar 2012 15:08:14 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 07 Mar 2012 15:08:14 -0500 Message-ID: <1606339.7MxFi1WF8B@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F57B62E.9070307@sonnection.nl> References: <20120305175124.GR76465@crankycanuck.ca> <3437eb48-bca1-43bc-961e-56664d9832d3@email.android.com> <4F57B62E.9070307@sonnection.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A suggestion about the experiment document 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, 07 Mar 2012 20:08:16 -0000 On Wednesday, March 07, 2012 08:25:34 PM Rolf E. Sonneveld wrote: > On 3/7/12 8:15 PM, Scott Kitterman wrote: > > "Murray S. Kucherawy" wrote: > >>> -----Original Message----- > >>> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > >> > >> Behalf Of Andrew Sullivan > >> > >>> Sent: Wednesday, March 07, 2012 10:17 AM > >>> To: spfbis@ietf.org > >>> Subject: Re: [spfbis] A suggestion about the experiment document > >>> > >>> No hat. > >> > >> "Fifty Mission Cap" here. > >> > >>>> (I'm now observing in my DNS survey that there are also resolvers > >>>> and/or firewalls that simply drop queries for unknown types; the > >> > >> TXT > >> > >>>> reply comes back right away, the SPF reply never comes. We might > >> > >> want > >> > >>>> to mention that too.) > >>> > >>> This is a well-known problem, and was something people worried about > >>> with DNSSEC. See http://www.iis.se/docs/Routertester_en.pdf, > >>> http://www.icann.org/committees/security/sac035.pdf, and RFC 5625. > >> > >> Is that a suggestion that we shouldn't bother talking about it, or > >> that > >> we should and this is potential reference material? I think this is > >> interesting data resulting from our surveys, but I don't want to beat > >> a > >> dead horse if we don't have anything new to contribute. > > > > If I may stretch the metaphor... > > > > I'd suggest that since people are still claiming new RR types are useful > > (Type SPF is hardly new anymore, but that only amplifies the point), > > the horse isn't dead and you ought to reload the shotgun. > in other words: document it, either by describing the problem in a few > lines or adding a reference to the documents Andrew mentioned (or both), I think having some hard numbers to point to is incredibly valuable. Something like "one bazillion domains were surveyed for published DNS records of Type TXT and Type SPF. Of these, all but three successfully answered the request for Type TXT, and 12,427 did not answer the Type SPF request at all." A set of facts like that would give us a good basis for understanding the reliability and performance impacts of using Type SPF (and provide some more general lessons i think on the challanges with new RR deployment). Scott K From SRS0=O03q7=BO==stuart@gathman.org Wed Mar 7 12:17:56 2012 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 4426321F8684 for ; Wed, 7 Mar 2012 12:17:56 -0800 (PST) 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 b2tjIVtd-te1 for ; Wed, 7 Mar 2012 12:17:55 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF5021F8685 for ; Wed, 7 Mar 2012 12:17:55 -0800 (PST) Received: from sdg.bmsi.com (sdg.bmsi.com [192.168.9.34] (may be forged)) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q27KH3Cg022073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Mar 2012 15:17:03 -0500 Message-ID: <4F57C271.1060106@gathman.org> Date: Wed, 07 Mar 2012 15:17:53 -0500 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <22187973.cpWMZthzO6@scott-latitude-e6320> <4F579E33.4000102@tana.it> <5370057.tXlR2v9Toq@scott-latitude-e6320> In-Reply-To: <5370057.tXlR2v9Toq@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 20:18:35 -0000 Long ago, Nostradamus foresaw that on 03/07/2012 01:05 PM, Scott Kitterman would write: > The current rules are: > > No more than 10 terms that need DNS lookups > No more than 10 a lookups from an mx mechanism > No more than 10 a lookups from a PTR mechanism. > I would like to point out that 'MX' is the only problematic mechanism in a Doug Otis scenario. PTR only needs to get looked up once per connection (and is then cached). The MTA has probably already looked it up, so I don't think it should count at all (but I'm not recommending changing the rules for 4408bis). 'A' is a straightforward one lookup per mechanism. 'MX', on the other hand may require up to 10 additional 'A' lookups. From spf2@kitterman.com Wed Mar 7 12:30:48 2012 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 B4D4611E809C for ; Wed, 7 Mar 2012 12:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 lL+Y+XmSzwdJ for ; Wed, 7 Mar 2012 12:30:48 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 01E8911E809B for ; Wed, 7 Mar 2012 12:30:48 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8E13420E40FA; Wed, 7 Mar 2012 15:30:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331152247; bh=z8L72TKPEMef5zOSqdFdcQcqI1z8Kdq8KAGNNXOKbdw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=YdsYJ5LUShbQ6nm+tzpT9yB5slebxBeLiNtAqeZTqboor8DXRsTK6u2j0gadYe6Sg HioxhEM9l8coDWw7cuAEtxdPIrmdmjVaHrQum4Q3TTl1ZCDpB/brW71Mbr8TRCd0cS S02GjgXjgc8sBYKoMTgpUQjrduvwoqj6GHERFDY0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 823E020E40A3; Wed, 7 Mar 2012 15:30:47 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 07 Mar 2012 15:30:47 -0500 Message-ID: <1643914.vUaBv9VAvs@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F57C271.1060106@gathman.org> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <5370057.tXlR2v9Toq@scott-latitude-e6320> <4F57C271.1060106@gathman.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 20:30:48 -0000 On Wednesday, March 07, 2012 03:17:53 PM Stuart D Gathman wrote: > Long ago, Nostradamus foresaw that on 03/07/2012 01:05 PM, Scott > > Kitterman would write: > > The current rules are: > > > > No more than 10 terms that need DNS lookups > > No more than 10 a lookups from an mx mechanism > > No more than 10 a lookups from a PTR mechanism. > > I would like to point out that 'MX' is the only problematic mechanism in > a Doug Otis scenario. PTR only needs to get looked up once per > connection (and is then cached). The MTA has probably already looked it > up, so I don't think it should count at all (but I'm not recommending > changing the rules for 4408bis). 'A' is a straightforward one lookup > per mechanism. 'MX', on the other hand may require up to 10 additional > 'A' lookups. To the extent any of this is actually problematic, I agree. Scott K From sm@elandsys.com Wed Mar 7 13:26:54 2012 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 5B3E711E80A2 for ; Wed, 7 Mar 2012 13:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.187 X-Spam-Level: X-Spam-Status: No, score=-103.187 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599, GB_I_LETTER=-2, SARE_SUB_PCT_LETTER=0.784, 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 sKOHx0cDHCC0 for ; Wed, 7 Mar 2012 13:26:53 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D1F11E80A5 for ; Wed, 7 Mar 2012 13:26:53 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.237.72]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q27LQbT3020142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Mar 2012 13:26:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331155609; i=@elandsys.com; bh=jerDoKn04Mk3dIMJFFt9aAJIJCf1wqj9JZW6oCA+upg=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=GeCTJWRNgE8+nr2HGJrlOMofx8u4rbl7kMT5eqlwhRC9n8IGDdaGqKrnMBXc3YXGt zzyx/BmjTYaWl7icr7wbouRSGD9JxtBCJVK+xu2W8iSdmxlZjlVtdpjqnlYlktQ7/U mtUPxc99tFtMWjJ8R1VU/lkT7kUfsaufAWBsG1+E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331155609; i=@elandsys.com; bh=jerDoKn04Mk3dIMJFFt9aAJIJCf1wqj9JZW6oCA+upg=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=ugSL3TJEB9c7L8aWMXQaUvSwLlnmdq04u7yiDUOiwyYuJ0XwSoqX6Ul0SbsBYmhjb pcusFPvBzPBFv8QF5Yb9WTps7paVRR2Cluu6wsVIeX4EJ+6aK/xqqM9s78w0h3lP96 fLcGfIf0wRWIwbmmKRWR7/jlBrKu1KOqlBOSOM7I= Message-Id: <6.2.5.6.2.20120307000722.0e4798d8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 07 Mar 2012 12:05:58 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.f025e215c3de7379cf01e5e1dba0aa8e@tools.ietf.org> References: <061.f025e215c3de7379cf01e5e1dba0aa8e@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #16: RFC 4408: Section 8.1 Add %v macro to ABNF grammar 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, 07 Mar 2012 21:26:54 -0000 At 07:06 21-02-2012, spfbis issue tracker wrote: >#16: RFC 4408: Section 8.1 Add %v macro to ABNF grammar > > Add %v macro to ABNF grammar > > Suggested wording: > > The ABNF grammar in section 8.1 and appendix A are missing the letter "v". > The > macro-letter production should look like this: > > macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / > "c" / "r" / "t" / "v" > > Rationale: > > The %v macro is listed in the table of macros in section 8.1, and used in > the examples. [snip] >Ticket URL: I am going to classify Issue #16 as "hold for document update" (it is better to discuss it when there is a 4480bis WG draft) . If there are any objections, please post them to this mailing list. Regards S. Moonesamy SPFBIS WG co-chair From msk@cloudmark.com Wed Mar 7 13:36:13 2012 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 4151411E80B2 for ; Wed, 7 Mar 2012 13:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 tYbN2YaY5XKL for ; Wed, 7 Mar 2012 13:36:12 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id B72E511E80A3 for ; Wed, 7 Mar 2012 13:36:12 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 7 Mar 2012 13:36:11 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #24: RFC 4408: Reasonable DNS error limits Thread-Index: AQHM+7yYx93ZDimmwkGuor51xQ56+JZeFRiAgAALrQCAAOyMAIAANtoAgAAJ1YCAAAgIAIAATCeAgAAGPgCAACT2gIAAA5uA//+JLHA= Date: Wed, 7 Mar 2012 21:36:11 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807EC68@exch-mbx901.corp.cloudmark.com> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <5370057.tXlR2v9Toq@scott-latitude-e6320> <4F57C271.1060106@gathman.org> <1643914.vUaBv9VAvs@scott-latitude-e6320> In-Reply-To: <1643914.vUaBv9VAvs@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 21:36:13 -0000 Limiting the total number of DNS queries a single policy causes is a functi= on of the domain publishing the policy, and the policies to which it points= (which may or may not be the same). If for example I post a policy of "v=3Dspf1 mx -all", and then I advertise = "n" MXes, and each of those have "m" IP addresses, that gives me m x n IP a= ddresses to compare to the client address. If that's arbitrarily truncated= , by this specification, it can lead to false negatives and random message = rejections. I think there are two things to point out here in RFC4408bis (in the vein o= f "I have not read your document but I have an opinion on it"): 1) An ADMD that wants to publish an SPF policy but already has a matrix of = MX/A records that will be queried needs to understand the DNS load from SPF= verifiers that this will generate, and might want to consider some other a= rrangement. 2) The same ADMD that declines to make any adjustment risks SPF false negat= ives as described above. I'm also a little troubled that, since the order of RRs in a reply can be r= andomized, the place at which the set is truncated is not under the control= of the ADMD. I know it's out of scope, but if we can't come up with a way= to alleviate that concern (which seems likely), we might -- after re-chart= ering, of course -- consider a way to provide instruction to verifiers abou= t how to truncate the list; for example, consider only MXes whose precedenc= e is below/above/equal to some value. -MSK From spf2@kitterman.com Wed Mar 7 13:55:31 2012 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 0874211E80B7 for ; Wed, 7 Mar 2012 13:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 7fXLwqU0Z-CC for ; Wed, 7 Mar 2012 13:55:30 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFE111E80AE for ; Wed, 7 Mar 2012 13:55:30 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6FCE420E40FA; Wed, 7 Mar 2012 16:55:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331157329; bh=6CfZEORS3dT7NbR3hDUBCq/3YI1IFga33PokJro5FlU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=NXmT/69fwprycCW9YcS7gvaJ/QpnIz1TM38BIWCZ/Gq++tH3IZNCK1AaIL1nm0I2a l8siBpKf5INfcLvKCxrVfJMo51QRpN9nxXQk5WVTpoDW9xR7E2LcYYu664PlvCatDY Uy3da12ZQAA3Q4s7wRHRnX4OMQ9Yt9ulzox7XHhY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 56ED920E40A3; Wed, 7 Mar 2012 16:55:29 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 07 Mar 2012 16:55:28 -0500 Message-ID: <3679773.ridM3LemJv@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E00392807EC68@exch-mbx901.corp.cloudmark.com> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <1643914.vUaBv9VAvs@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807EC68@exch-mbx901.corp.cloudmark.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] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 21:55:31 -0000 On Wednesday, March 07, 2012 09:36:11 PM Murray S. Kucherawy wrote: > Limiting the total number of DNS queries a single policy causes is a > function of the domain publishing the policy, and the policies to which it > points (which may or may not be the same). > > If for example I post a policy of "v=spf1 mx -all", and then I advertise "n" > MXes, and each of those have "m" IP addresses, that gives me m x n IP > addresses to compare to the client address. If that's arbitrarily > truncated, by this specification, it can lead to false negatives and random > message rejections. > > I think there are two things to point out here in RFC4408bis (in the vein of > "I have not read your document but I have an opinion on it"): > > 1) An ADMD that wants to publish an SPF policy but already has a matrix of > MX/A records that will be queried needs to understand the DNS load from SPF > verifiers that this will generate, and might want to consider some other > arrangement. > > 2) The same ADMD that declines to make any adjustment risks SPF false > negatives as described above. > > I'm also a little troubled that, since the order of RRs in a reply can be > randomized, the place at which the set is truncated is not under the > control of the ADMD. I know it's out of scope, but if we can't come up > with a way to alleviate that concern (which seems likely), we might -- > after re-chartering, of course -- consider a way to provide instruction to > verifiers about how to truncate the list; for example, consider only MXes > whose precedence is below/above/equal to some value. What RFC 4408 doesn't say (it's left to the reader to infer from paragraph 10.1) is if you have more than 10 mx records, don't use an mx mechanism in your SPF record. We could be explicit about that. There are ways around this problem that don't require protocol changes. FWIW, I don't think anyone actually needs more than 10, they just haven't thought things through (Gmail only has 5, Yahoo has 3). I don't think that 4408bis has to accomodate every vaguery of ill considered design. On the off chance one actually has more than 10, you can do it like this: Imagine the following: $ dig mx example.com +short 10 mx00.example.com 10 mx01.example.com 10 mx02.example.com 10 mx03.example.com 10 mx04.example.com 20 mx05.example.com 20 mx06.example.com 20 mx07.example.com 20 mx08.example.com ... 40 mx20.example.com Instead of using mx in an SPF record, publish records for another unique hostname, e.g. mx.example.com, and a records from it pointint at all the various mx* IP addresses: $ dig a mx.example.com +short mx.example.com 120 IN A 192.0.2.2 mx.example.com 120 IN A 192.0.2.3 mx.example.com 120 IN A 192.0.2.4 mx.example.com 120 IN A 192.0.2.5 mx.example.com 120 IN A 192.0.2.6 mx.example.com 120 IN A 192.0.2.7 mx.example.com 120 IN A 192.0.2.8 ... mx.example.com 120 IN A 192.0.2.22 Then you can use that in an SPF record like: v=spf1 a:mx.example.com -all That covers all the same IP space as: v=spf1 mx -all (for example.com) But it's only one DNS lookup. There's really no reason to give any advice other than "If you have more than 10, don't use mx/ptr". Scott K From msk@cloudmark.com Wed Mar 7 14:11:08 2012 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 53A9611E80BC for ; Wed, 7 Mar 2012 14:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 VKEKZsifFT2b for ; Wed, 7 Mar 2012 14:11:07 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id DF0F911E80BB for ; Wed, 7 Mar 2012 14:11:07 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Wed, 7 Mar 2012 14:11:07 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #24: RFC 4408: Reasonable DNS error limits Thread-Index: AQHM+7yYx93ZDimmwkGuor51xQ56+JZeFRiAgAALrQCAAOyMAIAANtoAgAAJ1YCAAAgIAIAATCeAgAAGPgCAACT2gIAAA5uA//+JLHCAAI59AP//fT4w Date: Wed, 7 Mar 2012 22:11:06 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807ED03@exch-mbx901.corp.cloudmark.com> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <1643914.vUaBv9VAvs@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807EC68@exch-mbx901.corp.cloudmark.com> <3679773.ridM3LemJv@scott-latitude-e6320> In-Reply-To: <3679773.ridM3LemJv@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 22:11:08 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Wednesday, March 07, 2012 1:55 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits >=20 > [...] >=20 > There's really no reason to give any advice other than "If you have > more than 10, don't use mx/ptr". I'd be quite happy if we included that sort of material to guide people abo= ut the tradeoffs of various approaches. I don't think the protocol needs t= o be fixed to handle this stuff, but nuances like what we're talking about = need to be highlighted. There's still an attack that's at least worth calling out, but I don't part= icularly care about MX/A set truncations causing false negatives in that ca= se. -MSK From ajs@anvilwalrusden.com Wed Mar 7 14:41:11 2012 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 6B4E011E80CB for ; Wed, 7 Mar 2012 14:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 xKrhbsFPMs4x for ; Wed, 7 Mar 2012 14:41:11 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C743411E80C7 for ; Wed, 7 Mar 2012 14:41:10 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 292B11ECB41D for ; Wed, 7 Mar 2012 22:41:10 +0000 (UTC) Date: Wed, 7 Mar 2012 17:41:08 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120307224108.GX79276@mail.yitter.info> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <1643914.vUaBv9VAvs@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807EC68@exch-mbx901.corp.cloudmark.com> <3679773.ridM3LemJv@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807ED03@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9452079D1A51524AA5749AD23E00392807ED03@exch-mbx901.corp.cloudmark.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 22:41:11 -0000 On Wed, Mar 07, 2012 at 10:11:06PM +0000, Murray S. Kucherawy wrote: > I'd be quite happy if we included that sort of material to guide > people [. . .] I'm not sure whether my hat is on or off for this, but that sounds to me very much like deployment advice and not part of the protocol. If people want to produce such material, we ought to think very hard about whether it belongs in a protocol draft or somewhere else. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Wed Mar 7 14:46:34 2012 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 CC4DC21F85BB for ; Wed, 7 Mar 2012 14:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 q7xa0md2hZQH for ; Wed, 7 Mar 2012 14:46:34 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 61F6C21F8608 for ; Wed, 7 Mar 2012 14:46:34 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 7 Mar 2012 14:46:34 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #24: RFC 4408: Reasonable DNS error limits Thread-Index: AQHM+7yYx93ZDimmwkGuor51xQ56+JZeFRiAgAALrQCAAOyMAIAANtoAgAAJ1YCAAAgIAIAATCeAgAAGPgCAACT2gIAAA5uA//+JLHCAAI59AP//fT4wgACPhAD//3rtMA== Date: Wed, 7 Mar 2012 22:46:33 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807ED7A@exch-mbx901.corp.cloudmark.com> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <1643914.vUaBv9VAvs@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807EC68@exch-mbx901.corp.cloudmark.com> <3679773.ridM3LemJv@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807ED03@exch-mbx901.corp.cloudmark.com> <20120307224108.GX79276@mail.yitter.info> In-Reply-To: <20120307224108.GX79276@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 22:46:35 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Andrew Sullivan > Sent: Wednesday, March 07, 2012 2:41 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits >=20 > I'm not sure whether my hat is on or off for this, but that sounds to > me very much like deployment advice and not part of the protocol. If > people want to produce such material, we ought to think very hard about > whether it belongs in a protocol draft or somewhere else. True, that. If putting this stuff in appendices is something we don't really want to do= (I could go either way), an Applicability Statement is certainly a feasibl= e alternative. It's not among our current chartered deliverables, but I'd = be willing to argue for its addition. -MSK From spf2@kitterman.com Wed Mar 7 14:55:56 2012 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 5228711E808F for ; Wed, 7 Mar 2012 14:55:56 -0800 (PST) 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 NB51Azwr5mWt for ; Wed, 7 Mar 2012 14:55:55 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id A748D21F8618 for ; Wed, 7 Mar 2012 14:55:55 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 34817D04066; Wed, 7 Mar 2012 16:55:55 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331160955; bh=yQsWh6tRZlTzvaUQXMNrUCmOgmNcTN83GNDrwyt5nv0=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=W/XC9KoeyJ2WQfRfaBQza1qzpbtWDFUovNKJFGHytaHF234O8nj9p0n2Ag2UGuCVG fHyxjaOvHRLicGF3jI2r3FrxfzUy0SwX+/pQ/M5YlWO1SndRfzEydGo1KUhfUYIsYF N6tmd+i8vrQ1G0LPw+A29Gh49z0wOTwTmsQwa9FY= Received: from 242.sub-97-241-250.myvzw.com (242.sub-97-241-250.myvzw.com [97.241.250.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9A555D04018; Wed, 7 Mar 2012 16:55:54 -0600 (CST) References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <1643914.vUaBv9VAvs@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807EC68@exch-mbx901.corp.cloudmark.com> <3679773.ridM3LemJv@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807ED03@exch-mbx901.corp.cloudmark.com> <20120307224108.GX79276@mail.yitter.info> User-Agent: K-9 Mail for Android In-Reply-To: <20120307224108.GX79276@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 07 Mar 2012 17:56:01 -0500 To: spfbis@ietf.org Message-ID: <7f20dd49-8b25-4272-bb32-568f329d1765@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 22:55:56 -0000 Andrew Sullivan wrote: >On Wed, Mar 07, 2012 at 10:11:06PM +0000, Murray S. Kucherawy wrote: >> I'd be quite happy if we included that sort of material to guide >> people > >[. . .] > >I'm not sure whether my hat is on or off for this, but that sounds to >me very much like deployment advice and not part of the protocol. If >people want to produce such material, we ought to think very hard >about whether it belongs in a protocol draft or somewhere else. > Writing records that fit within the processing limits is an essential part of determinism of the protocol. Please let's not fork off part of what people need to know to do that into a separate document (that no one is chartered to write). Scott K From ajs@anvilwalrusden.com Wed Mar 7 15:05:13 2012 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 4649021F8576 for ; Wed, 7 Mar 2012 15:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 IfbEUGSNQc1d for ; Wed, 7 Mar 2012 15:05:12 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5395021F84F3 for ; Wed, 7 Mar 2012 15:05:11 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A797B1ECB41D for ; Wed, 7 Mar 2012 23:05:10 +0000 (UTC) Date: Wed, 7 Mar 2012 18:05:08 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120307230508.GB80123@mail.yitter.info> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <1643914.vUaBv9VAvs@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807EC68@exch-mbx901.corp.cloudmark.com> <3679773.ridM3LemJv@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807ED03@exch-mbx901.corp.cloudmark.com> <20120307224108.GX79276@mail.yitter.info> <7f20dd49-8b25-4272-bb32-568f329d1765@email.android.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7f20dd49-8b25-4272-bb32-568f329d1765@email.android.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 07 Mar 2012 23:05:13 -0000 On Wed, Mar 07, 2012 at 05:56:01PM -0500, Scott Kitterman wrote: > > > Writing records that fit within the processing limits is an > essential part of determinism of the protocol. Please let's not fork > off part of what people need to know to do that into a separate > document (that no one is chartered to write). Hat on for sure now. I agree with this. I'm just trying to distinguish between "parts of protocol" (which is definitely part of what we have to do) and "advice to users". "DNS response size limits" fits in the former. "How to set up your zone so it works reliably" does not. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Wed Mar 7 15:12:46 2012 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 C10BD21F85A7 for ; Wed, 7 Mar 2012 15:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 rWUWfvVrDLPV for ; Wed, 7 Mar 2012 15:12:46 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EAB21F8599 for ; Wed, 7 Mar 2012 15:12:45 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.238.179]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q27NCXIB009436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Mar 2012 15:12:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331161964; i=@elandsys.com; bh=qiqNhgrJmCYEt9Sm5V+UixW/n2uDOytLQs9ERmcIbTk=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=spfM78jSqwxxKsSiSK/ysIFfOL4Fj6PoDpdT9ZPs2MLTQCo1miZv98SJdKgUPrUyC PZ5eLDQZ1EFVC1uamXM3AgFTgayQz2SyWm20UmOW6c2C0Gz+eCKJmk1rpcfLjNAWnx 7xikuJFZxYXry7FvZoGiVjBHOZTy250EZVnfCE4U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331161964; i=@elandsys.com; bh=qiqNhgrJmCYEt9Sm5V+UixW/n2uDOytLQs9ERmcIbTk=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=GaCEzOOYp/J5Reglo8jQqmeC/eRAZrYBOJ03CWZ2A73WiJA5uGxHzXmkh9IJWLTdd F71Xtv/vlymlcL0QnxPAUrOT1X4B0qQOci1mF7zRBk7k3tu9Ac8GKpSBnmfBIUAWqK YgN1nDflc02H9zIM1laY2sC1L3ruLz2ujGRRCxCU= Message-Id: <6.2.5.6.2.20120307150701.0a0c7d28@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 07 Mar 2012 15:10:51 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.6bd7631aa74ff75bc011ac2769322b92@tools.ietf.org> References: <061.6bd7631aa74ff75bc011ac2769322b92@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #6: RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization 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, 07 Mar 2012 23:12:46 -0000 At 13:04 07-02-2012, spfbis issue tracker wrote: >#6: RFC 4408 Section 10.1 - Processing limits needs clarification and >reorganization > > Message from Scott Kitterman on 6 Feb 2012: > > As I understand it, security considerations aren't generally supposed to > give > normative protocol implementations constraints, but the processing limits > in > paragraph 10.1 of RFC 4408 does exactly this. > > While the technical limits themselves are appropriate, paragraph 10.1 > should > be split into two parts. The actual processing limits should find a home > in > the main body of the specification and then a revised security > consideration > should focus on a clearer discussion about why they are important and why > one > should design records the minimize DNS impact. > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00293.html [snip] >Ticket URL: I am opening Issue #6 in case it is related to the discussion of Issue #24. Please comment on this issue. Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Wed Mar 7 16:13:43 2012 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 BF4C411E8072 for ; Wed, 7 Mar 2012 16:13:43 -0800 (PST) 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 tWUhvod3WpRx for ; Wed, 7 Mar 2012 16:13:42 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CFC7C21F84EB for ; Wed, 7 Mar 2012 16:13:42 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DC40920E40FA; Wed, 7 Mar 2012 19:13:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331165621; bh=TS59/LV5dyTyxJq58/7nfSym3AsbhdMUotZ+48OJN54=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=pEQjtzOUOKBc9LmINclIQKR1kThylUiJhNIjkzGE/aNQ7k0SdM9IBk+vNanrfT5wr H774tRW+evvPIroRrZegxezJjS8uJ72VccHaS+O8xh3CVycEWtaP1eNYud15I0czUi zHzbLOgIoOGXIzZHT2b2jhsEKxezKLd9469pja0E= Received: from scott-latitude-e6320.localnet (218.sub-97-128-232.myvzw.com [97.128.232.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7B05920E40A3; Wed, 7 Mar 2012 19:13:41 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 07 Mar 2012 19:13:39 -0500 Message-ID: <20802005.zxzKu6fIYM@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120307150701.0a0c7d28@elandnews.com> References: <061.6bd7631aa74ff75bc011ac2769322b92@tools.ietf.org> <6.2.5.6.2.20120307150701.0a0c7d28@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] #6: RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization 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, 08 Mar 2012 00:13:43 -0000 On Wednesday, March 07, 2012 03:10:51 PM S Moonesamy wrote: > At 13:04 07-02-2012, spfbis issue tracker wrote: > >#6: RFC 4408 Section 10.1 - Processing limits needs clarification and > >reorganization > > > > Message from Scott Kitterman on 6 Feb 2012: ... > >Ticket URL: > > I am opening Issue #6 in case it is related to the discussion of > Issue #24. Please comment on this issue. Here's what I had envisioned when I submitted this issue. RFC 4408 paragraph 10.1 contains a mix of considerations and hard protocol requirements. The protocol requirements should be moved up into the main part of the document from security considerations. I would add the following facts (exact text there's no point in writing since we don't have a document to put it in - still) and whatever additional limits we determin are appropriate (irf any from the discussion of issue #24) into paragraph 4.6. Either as part of a the main body of 4.6 or a new 4.6.1 that's before the current 4.6.1. SPF implementations MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier. If this number is exceeded during a check, a PermError MUST be returned. The "include", "a", "mx", "ptr", and "exists" mechanisms as well as the "redirect" modifier do count against this limit. The "all", "ip4", and "ip6" mechanisms do not require DNS lookups and therefore do not count against this limit. The "exp" modifier does not count against this limit because the DNS lookup to fetch the explanation string occurs after the SPF record has been evaluated. When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there MUST be a limit of no more than 10 MX or PTR RRs looked up and checked. MTAs or other processors MAY also impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD allow at least 20 seconds. If such a limit is exceeded, the result of authorization SHOULD be "TempError". The balance of 10.1 I would leave in security considerations. Text and clarifications TBD until we have a draft. Scott K From msk@cloudmark.com Wed Mar 7 16:36:26 2012 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 CB74F11E8085 for ; Wed, 7 Mar 2012 16:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 evUa6ucZ9xT2 for ; Wed, 7 Mar 2012 16:36:26 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6458711E8094 for ; Wed, 7 Mar 2012 16:36:26 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 7 Mar 2012 16:36:25 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #6: RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization Thread-Index: AQHM/MBWuN5QNc14UEKuz8i8Gm+vs5Zfi1Hg Date: Thu, 8 Mar 2012 00:36:25 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807EFAD@exch-mbx901.corp.cloudmark.com> References: <061.6bd7631aa74ff75bc011ac2769322b92@tools.ietf.org> <6.2.5.6.2.20120307150701.0a0c7d28@elandnews.com> <20802005.zxzKu6fIYM@scott-latitude-e6320> In-Reply-To: <20802005.zxzKu6fIYM@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #6: RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization 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, 08 Mar 2012 00:36:26 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Wednesday, March 07, 2012 4:14 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] #6: RFC 4408 Section 10.1 - Processing limits needs= clarification and reorganization >=20 > [...] >=20 > The balance of 10.1 I would leave in security considerations. Text and > clarifications TBD until we have a draft. That all seems reasonable to me, but we need to haggle about wording. For = example, the first paragraph's wording says more than ten can't be done. T= hat could be read as "pick your favourite ten" rather than "throw an error = if there are more than ten". The second paragraph seems to shift to talkin= g about limiting the actual MX queries issued to the DNS, but isn't that th= e same as the number of MX mechanisms in the previous paragraph, where "mx"= is excluded from the count? But we can tackle later. -MSK From spf2@kitterman.com Wed Mar 7 16:49:54 2012 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 6EF3521F8566 for ; Wed, 7 Mar 2012 16:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, SARE_SUB_ENC_UTF8x2=0.246] 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 oSQlDg4XBalw for ; Wed, 7 Mar 2012 16:49:53 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id E142D21F84FC for ; Wed, 7 Mar 2012 16:49:50 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 4C3BAD04066; Wed, 7 Mar 2012 18:49:50 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331167790; bh=e49HIjSB+u8LCjynLhvAGxUF3XRPDFCa32kpvkQSOJY=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=NfAsg36j1bPmCXJUceCGHyz0za2z7zJTFqqxMA8cnPWdlPEy48i4/a1IRwoAyal6p HfuyCr/CInG3GcW10zKYezC9S/x5FsUHiwYJdwhNl9McRGoxarXOhiWbTg3h3riyTs NA45yEUim+dIWMIzQIloG4KhVBN9twX9kc28/vQk= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 02032D04018; Wed, 7 Mar 2012 18:49:49 -0600 (CST) References: <061.6bd7631aa74ff75bc011ac2769322b92@tools.ietf.org> <6.2.5.6.2.20120307150701.0a0c7d28@elandnews.com> <20802005.zxzKu6fIYM@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807EFAD@exch-mbx901.corp.cloudmark.com> User-Agent: K-9 Mail for Android In-Reply-To: <9452079D1A51524AA5749AD23E00392807EFAD@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 07 Mar 2012 19:49:24 -0500 To: "spfbis@ietf.org" Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] =?utf-8?q?=236=3A_RFC_4408_Section_10=2E1_-_Processing_l?= =?utf-8?q?imits=09needs=09clarification_and_reorganization?= 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, 08 Mar 2012 00:49:54 -0000 "Murray S. Kucherawy" wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On >Behalf Of Scott Kitterman >> Sent: Wednesday, March 07, 2012 4:14 PM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] #6: RFC 4408 Section 10.1 - Processing limits >needs clarification and reorganization >> >> [...] >> >> The balance of 10.1 I would leave in security considerations. Text >and >> clarifications TBD until we have a draft. > >That all seems reasonable to me, but we need to haggle about wording. >For example, the first paragraph's wording says more than ten can't be >done. That could be read as "pick your favourite ten" rather than >"throw an error if there are more than ten". The second paragraph >seems to shift to talking about limiting the actual MX queries issued >to the DNS, but isn't that the same as the number of MX mechanisms in >the previous paragraph, where "mx" is excluded from the count? > >But we can tackle later. Agreed. No point in it before there's a draft. Scott K From johnl@iecc.com Wed Mar 7 16:57:15 2012 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 3F4F521F859F for ; Wed, 7 Mar 2012 16:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.235 X-Spam-Level: X-Spam-Status: No, score=-110.235 tagged_above=-999 required=5 tests=[AWL=0.964, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 VLwD19JQVJsj for ; Wed, 7 Mar 2012 16:57:14 -0800 (PST) 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 55A7221F859E for ; Wed, 7 Mar 2012 16:57:14 -0800 (PST) Received: (qmail 69205 invoked from network); 8 Mar 2012 00:57:13 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 8 Mar 2012 00:57: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:vbr-info; s=4f5803e9.xn--hew.k1203; i=johnl@user.iecc.com; bh=/jRywSOVXMKss+uBAeTSLcyoaED4aJX9QA4tonraDXQ=; b=C1Yyi6ivTwCgegpxTfqJ/6wISQOBoy76vKCDlYH85AGgtJIGnEg0zV2rxCTKqn0NysHtM/ZGQx6EmYUaUkQJ0gzXVkuGGfuwfBQva+V5synJpncWoAp+/f6ThlY+32OKENqnDpyP4E59jdN0BeLKaG844Sw6s+3+zm/PmX5MvzY= 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:vbr-info; s=4f5803e9.xn--hew.k1203; olt=johnl@user.iecc.com; bh=/jRywSOVXMKss+uBAeTSLcyoaED4aJX9QA4tonraDXQ=; b=KRzofrxsvleRm/hGfIDYfMFTv8+ZOj/uYrwXlh042LFyr1iptf0EdTuVAcTyd6jlI1QIOzDcdCiPdgxAS7lOoKK5JtxOIDY/mLZ7v7zdsvoAHCvLxeGNBUyIgM0l1lmP4UtS46hSCMTL0SPRO0qnSMEUoJQlKc3PizPsrbhDR/g= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 8 Mar 2012 00:56:51 -0000 Message-ID: <20120308005651.83946.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <3679773.ridM3LemJv@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 08 Mar 2012 00:57:15 -0000 >FWIW, I don't think anyone actually needs more than 10, they just haven't >thought things through (Gmail only has 5, Yahoo has 3). Actually, gmail has considerably more than 5, but they only hand out five per DNS answer. Each of Yahoo's MXes has at least 8 A records. But, of course, neither publishes an SPF record with an MX clause. >There's really no reason to give any advice other than "If you have more than >10, don't use mx/ptr". Agreed. R's, John From johnl@iecc.com Wed Mar 7 16:58:50 2012 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 4D5A121E800C for ; Wed, 7 Mar 2012 16:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.244 X-Spam-Level: X-Spam-Status: No, score=-110.244 tagged_above=-999 required=5 tests=[AWL=0.955, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 RfurNS1DbGKE for ; Wed, 7 Mar 2012 16:58:50 -0800 (PST) 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 B3DDF11E8089 for ; Wed, 7 Mar 2012 16:58:49 -0800 (PST) Received: (qmail 69409 invoked from network); 8 Mar 2012 00:58:48 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 8 Mar 2012 00:58:48 -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:vbr-info; s=4f580448.xn--3zv.k1203; i=johnl@user.iecc.com; bh=+ANAPqZ9LMULioH19CnkAY6cZ5rG7lT7k2wNUWsEzhs=; b=njo23GJzN4cDwFcuneLGqNO3yti72jsN4zzkAVlXs2+mTvDWHr4zvaTA5VJq50W1E8vHNjANAKfwr561jQ977HVYekFA6JxoG2Rwt/jRmcU9ecDr9upuI1qSlo1uZmw/pQ8b/MXv1mcZiNpNF373NTrE8VLcN4wTQQPEkWqz6Wo= 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:vbr-info; s=4f580448.xn--3zv.k1203; olt=johnl@user.iecc.com; bh=+ANAPqZ9LMULioH19CnkAY6cZ5rG7lT7k2wNUWsEzhs=; b=p9b6m5AjOXcLq+F2gb3MBrRSMwzIRgRdJBaJuzpVN9YzCdq49ljJB+QXljRNDm3uuxesH3LJhycqZlon8QzaN+FCmo04Z7U9RxubrIBi28X4AN7TJDRWZNCQieUUiHVn8aVbClZcRkA4HhNjYmQxTPfH6Sh6NsPIy9lCp3qoj48= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 8 Mar 2012 00:58:26 -0000 Message-ID: <20120308005826.84024.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20120307224108.GX79276@mail.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: ajs@anvilwalrusden.com Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 08 Mar 2012 00:58:50 -0000 >I'm not sure whether my hat is on or off for this, but that sounds to >me very much like deployment advice and not part of the protocol. If >people want to produce such material, we ought to think very hard >about whether it belongs in a protocol draft or somewhere else. In this case, I think it belongs in the protocol document, since it's basically pointing out that something that you might think would work if you read one part of the document in fact doesn't if you read the rest of it. R's, John From msk@cloudmark.com Wed Mar 7 17:01:56 2012 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 DD67D21E8011 for ; Wed, 7 Mar 2012 17:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 hd12-snI2+h7 for ; Wed, 7 Mar 2012 17:01:56 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7386621E800C for ; Wed, 7 Mar 2012 17:01:56 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Wed, 7 Mar 2012 17:01:55 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #24: RFC 4408: Reasonable DNS error limits Thread-Index: AQHM+7yYx93ZDimmwkGuor51xQ56+JZeFRiAgAALrQCAAOyMAIAANtoAgAAJ1YCAAAgIAIAATCeAgAAGPgCAACT2gIAAA5uA//+JLHCAAI59AIAAMq2A//97ElA= Date: Thu, 8 Mar 2012 01:01:56 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807F0D6@exch-mbx901.corp.cloudmark.com> References: <3679773.ridM3LemJv@scott-latitude-e6320> <20120308005651.83946.qmail@joyce.lan> In-Reply-To: <20120308005651.83946.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 08 Mar 2012 01:01:57 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of John Levine > Sent: Wednesday, March 07, 2012 4:57 PM > To: spfbis@ietf.org > Cc: spf2@kitterman.com > Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits >=20 > >FWIW, I don't think anyone actually needs more than 10, they just > >haven't thought things through (Gmail only has 5, Yahoo has 3). >=20 > Actually, gmail has considerably more than 5, but they only hand out > five per DNS answer. Each of Yahoo's MXes has at least 8 A records. > But, of course, neither publishes an SPF record with an MX clause. Let's say they did: Is there no possibility then that a piece of email migh= t come from a server that's not in the five contained in the DNS answer? This is the kind of thing I'm on about. -MSK From johnl@iecc.com Wed Mar 7 18:15:45 2012 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 8484121E805E for ; Wed, 7 Mar 2012 18:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.252 X-Spam-Level: X-Spam-Status: No, score=-110.252 tagged_above=-999 required=5 tests=[AWL=0.947, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 es3zkksIWU9D for ; Wed, 7 Mar 2012 18:15:44 -0800 (PST) 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 0B6AF21E8054 for ; Wed, 7 Mar 2012 18:15:43 -0800 (PST) Received: (qmail 78900 invoked from network); 8 Mar 2012 01:49:01 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 8 Mar 2012 01:49:01 -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:vbr-info; s=4f58100d.xn--9vv.k1203; i=johnl@user.iecc.com; bh=wBrODKDSHvx7/hAK/a190AIWWFKdXMtfRliHQTbvUgM=; b=WkEQPeONUbU8OqgjnnOqoPQaE1mT3IJ0oaNg8RVKAjd6u6F1uFPONNzFyyl6yy8U4U5FwgE2QSgLDkXGV4ofSPCyM71BwMVLYJ7cLumDpFx/RDwVsFhp4reRb/2OIWHp8ao+AYL7XsPtsvYaR7aGiJgx5eqHmygcN9El0Mzn8iU= 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:vbr-info; s=4f58100d.xn--9vv.k1203; olt=johnl@user.iecc.com; bh=wBrODKDSHvx7/hAK/a190AIWWFKdXMtfRliHQTbvUgM=; b=Wk/PMokJ9OVviNUkAQS1ZAghHca7ln334XJcoEdLR2UNBAEZaiHy1W6E5Nzt1SlPBgdyukJ6u5tyylyv6BtFsZ5WgDUfCvkVB454wZdm36i53/EIFaUyQNIhRPLAWASTzXKqWqf5LBHUiWHPcd2PFiIiMX3BfYcCjJgKMrQopJY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 8 Mar 2012 01:48:39 -0000 Message-ID: <20120308014839.85687.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E00392807F0D6@exch-mbx901.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: msk@cloudmark.com Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 08 Mar 2012 02:15:45 -0000 >> Actually, gmail has considerably more than 5, but they only hand out >> five per DNS answer. Each of Yahoo's MXes has at least 8 A records. >> But, of course, neither publishes an SPF record with an MX clause. > >Let's say they did: Is there no possibility then that a piece of email might come from a >server that's not in the five contained in the DNS answer? In practice, anyone big enough to do rotating DNS for their mail servers is going to have separate inbound and outbound servers, but hypothetically assuming they got a really great deal on a warehouse full of bidirectional Sendmail boxes, of course mail would be likely to come from servers that don't show up in any particular DNS reply. The general advice is that if you're using any clause that uses the value of another DNS query, such as a, mx, include, ptr, exists, and redirect, the results of that query better be consistent. R's, John From sm@elandsys.com Thu Mar 8 08:11:28 2012 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 5CC7521F854C for ; Thu, 8 Mar 2012 08:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 n+JY41BblT2J for ; Thu, 8 Mar 2012 08:11:25 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBC721F8545 for ; Thu, 8 Mar 2012 08:11:25 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.238.178]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q28GBAIC007085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Mar 2012 08:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331223082; i=@elandsys.com; bh=iC9lWolumqeoP6TTIFJIOMbD8n3ktDRzLao7GG5mbsw=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=smCHrQmquZgp8hxZxnh4XMgkUj1KffobDxhXD2yC0MqaB1+k2WjfcMBmCZJkR2qu2 Gd0aOEx8Jkfp06/8+WuhnkkbaJu1QLPk01rOFx/RzfwILcGxPbx29RnSO59dwqRybn 9d4oyNgqy96MIKQVrR4lUlQloWEMmjfegcq6O8Zo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331223082; i=@elandsys.com; bh=iC9lWolumqeoP6TTIFJIOMbD8n3ktDRzLao7GG5mbsw=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=PCcBZIhuG9sDSNoAD+xa4xGx6yJtVns7g+zo9xDsQk5dg4+qLHG3zdhEndKRcjT0Q UQJHM6MTsjdJyoBJfIQpMLf6v75yaN5cy4hHfhJ37p2aMoYNKL3ZxEG4ciUAXWAv+c 3FRbmacrHiuKX8c/t74tFBNPTd8ZH0X6rtvLo2H8= Message-Id: <6.2.5.6.2.20120308074152.09ab1040@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 08 Mar 2012 07:54:35 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.2167e477978346c301a443db8231454d@tools.ietf.org> References: <061.2167e477978346c301a443db8231454d@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #25: RFC 4408: Section 4.4 Parallel Query 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, 08 Mar 2012 16:11:28 -0000 At 13:48 23-02-2012, spfbis issue tracker wrote: >#25: RFC 4408: Section 4.4 Parallel Query > > In question: > > 4.4. Record Lookup > > 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. If both SPF and TXT RRs are > looked up, the queries MAY be done in parallel. > > I have seen this before and was very curious about how literal is that in > term of the technical methods used to perform "parallel" queries. But with > the group postings today related to type SPF and TXT queries and terms > like "asynchronous" or "Same time" made me think this might an item to be > clarified. > > The statement "the queries MAY be done in parallel" should be expanded to > > - Explain what "Parallel"" means, > - The reasons whe on MAY wish to do this, and > - What are the possible issues and considerations with it. > > The term "Parallel" has a specific meaning (in terms of computers and > software) which correlates to time independent concurrency of different > thread, process, task, etc. To the SPF implementator, this may mean using > two different threads, fibers, task each doing a DNS query - SPF and TXT, > or in DNS parley, it can a batch of multiple query packets. This should > be perhaps be explained. > > The reasons is to lower overhead, I suppose, which may implies the > "Multiple Query Packets" method, to help avoid the need to do two separate > queries. > > The possible issues as I basically understand it: > > - Multiple Query Packets (MQP) is not a universally support feature and > in some reported - > broken and unreliable, and > > Now, the main issue starts with the idea that the end result of a parallel > or MQP query MUST be the same for the result of two sequential queries. > > In theory, the sequential order would be SPF type first, then TXT type as > a fall back. The current text offer a functional spec requirement. What is > needed is a technical specification description. That should be done as > if there as no parallelism or MQP capability, only sequential. The > parallel or MQP is essentially an DNS overhead optimization of the > sequential method. > > No question, the ideal query of two related types would be to batch it as > one call. But the reality is it is not an universal DNS server supported > feature and since it must be described using the lowest common denominator > method, this section should expand how the SPF and TXT queries should are > done sequentially with translations of results. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00580.html [snip] >Ticket URL: Please comment on Issue #25. As a reminder, please keep the subject line as it makes it easier to track discussions about each issue. Regards, S. Moonesamy SPFBIS WG co-chair From agthisell@yahoo.com Thu Mar 8 08:56:55 2012 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 6C50221F8649 for ; Thu, 8 Mar 2012 08:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.008 X-Spam-Level: X-Spam-Status: No, score=0.008 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_50=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 8F5wVcJOCYje for ; Thu, 8 Mar 2012 08:56:55 -0800 (PST) Received: from nm3-vm3.bullet.mail.ne1.yahoo.com (nm3-vm3.bullet.mail.ne1.yahoo.com [98.138.91.133]) by ietfa.amsl.com (Postfix) with SMTP id CCC4121F863B for ; Thu, 8 Mar 2012 08:56:54 -0800 (PST) Received: from [98.138.90.51] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 08 Mar 2012 16:56:46 -0000 Received: from [98.138.89.163] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 08 Mar 2012 16:56:46 -0000 Received: from [127.0.0.1] by omp1019.mail.ne1.yahoo.com with NNFMP; 08 Mar 2012 16:56:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 599170.35920.bm@omp1019.mail.ne1.yahoo.com Received: (qmail 25611 invoked by uid 60001); 8 Mar 2012 16:56:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1331225806; bh=l0fS5gEl0zftuZ6tvIAuZrRnXpbx6pmIDzm/if5f1eM=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=DH0k9YRGjmJPjzWv70e2CN+q/oRM9CVcvnsmv6pWNxkKZKmAI9Rox4mKCZOcc6mRTxOny64MpIsuUXWdIlAF6QS/ysN2jcG5JYmipt5IC5Zv/h3jEu936gbO+JJJuWwLyB8fFBihCG7/zpXZ2Ww+1bSTl03IEFhKnfnZlPOt2rk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=w2WWoWCt2qwDCrd/E4gqdDpX4zuXMw2IW4Jfs5m9QKUgnq6XVNvVY0DEGisT0Yx3DPVYfs0T78+McJUInAOfPrELjTShtShjCOCG+vXc+nVJWs+cb1Upiv3/TYP2liir+F3nziCmo0BJxdUtJ2DRc5eN7kRniyybQjJD2ov7GcE=; X-YMail-OSG: .NIka8cVM1nnQ1b2E3J_eNDM9m57dUiGxP6RETda9eqB4cL earacGKcdaARy38sanpac1EZCFbQgNi6k3NqYvTrX.PyILpVGYwrJZhIok85 oodTswDrJufsXQJBC5T.23l_ssgp6GigRssRS1Gac.QWL4tZHkGRfoGr2WaL mA.uimiuFMCypNfxmsdwEkgMS3Bul2PkV1WJH8E36Ko8iUiSpC9SaHWmqdmK aTEAOYMR7YdvIoMkVB38XksXOWAXi5gAwOKDlAJy5EcrxT1xwuLL9ot0Lizo HqP_Xfbu6SSlq4B6grir1QXn5W2EbpnDNm8SveLImZy05KmHwOMlOaqxxca_ mFonwTYAiw4Hswuo4BiM9_QO5IwXVvqxDT2qIf4X2UYQ5d6pAS4wP5QoRluR FHCHJbzBOsiU7PnQSeQVD9Mx5zQc95qx56yx898jcdct9IWh2mgbFVj8aR5Y SFA-- Received: from [71.61.133.134] by web125401.mail.ne1.yahoo.com via HTTP; Thu, 08 Mar 2012 08:56:46 PST X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1331225806.25301.YahooMailClassic@web125401.mail.ne1.yahoo.com> Date: Thu, 8 Mar 2012 08:56:46 -0800 (PST) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #25: RFC 4408: Section 4.4 Parallel Query 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, 08 Mar 2012 16:56:55 -0000 SPF clients SHOULD NOT query TXT and type 99 records in parallel because SPF clients SHOULD NOT query type 99 records. From sm@elandsys.com Thu Mar 8 09:25:37 2012 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 51A3D21F8592 for ; Thu, 8 Mar 2012 09:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 U2DNcKXjJSE9 for ; Thu, 8 Mar 2012 09:25:35 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2EE21F858E for ; Thu, 8 Mar 2012 09:25:35 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.238.178]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q28HPMPh012212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Mar 2012 09:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331227534; i=@elandsys.com; bh=GtnMKGf2y9pdvKGdR0F/YGQu3oFrsoGR2+UAjdLKM2o=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=G3wG3ezJw4pQidBEhzCf31abitzdVFJkpAsCEV/bAf36LGFN7mdwAfhaDQ/AMsgKv nsM8HWDoVyKiBLa5q2WeKLLzqUr7qX3xYTkvsZUnUBPOUCa9KhuHU2gt0BZUxR1HUP pWnIec5aEE3R6/Rv2tdofth7A1j1jsEpvVlgh0e8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331227534; i=@elandsys.com; bh=GtnMKGf2y9pdvKGdR0F/YGQu3oFrsoGR2+UAjdLKM2o=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=e2o2zdqOy7jEIG2oxnp7HQngB+RGibfuV+YTG3c/nlMhyZO7TpOFNrgXZ8jJsg3xg g0RMFv0buSw55MznVHBNcnKUL4WEK/LIAQK0oxSTPyrLT+4e8QnDHg7LaYe3ZrtUq6 bJqzcL0TTBb/RSFiVyqp95oooIb8dNNDHwQXmGBc= Message-Id: <6.2.5.6.2.20120308082243.0a8df518@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 08 Mar 2012 09:14:02 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20120308014839.85687.qmail@joyce.lan> References: <9452079D1A51524AA5749AD23E00392807F0D6@exch-mbx901.corp.cloudmark.com> <20120308014839.85687.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 08 Mar 2012 17:25:37 -0000 I'll attempt to summarize the discussion of Issue #24. If I misinterpreted or misunderstood your comments, please let me know. The issue was based on the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg00501.html Philip Gladstone commented that the number of "exists" mechanisms that can be invoked is small, so there doesn't appear to be a risk here [1]. Scott Kitterman pointed out the actionable part of the issue: this risk can be significantly mitigated by simply imposing reasonable No Data limits [2]. He also mentioned an implementation and suggested a survey of records to get a distribution of the number of void DNS lookups in SPF records. He agreed [3] on the points mentioned in Philip Gladstone's message. John Leslie mentioned that the issue is calling out a possible abuse situation, wherein an SPF record can call for more than one DNS lookup to a domain quite unrelated to the sending MTA and that it deserves discussion on one of our RFCs [4]. He also mentioned that the essential point is that any no-data response is a hint of abuse; thus action to impose a limit on the rate of such queries after a no-data response may be appropriate. Murray Kucherawy asked for a clarification about the issue [5]. Scott Kitterman pointed to draft-otis-spf-dos-exploit-01 [expired draft] and mentioned that there are easier ways to do an amplification attack [6]. Murray Kucherawy suggested NODATA cutoff limits in a security considerations section [7]. Arthur Thisell mentioned that it is quite possible to generate larger amplification attacks using plain old DNS, in particular, the NS, MX, SRV, etc. records. Unlike RFC 4408, the DNS RFCs don't have any limits on the recursion depth. It is far easier for an attacker to trigger an NS lookup than it is to trigger an SPF evaluation [8] and that things like the "no data" limit are not complete fixes. He also mentioned in response to a previous message about "MAY" language would mean that two different SPF implementations/users could evaluate the same SPF record and give different results [9]. Alessandro Vesely quoted Section 5.4 of RFC 4408 and Section 10, and commented that he did not see amplification [attack]. Stuart Gathman pointed out that 'MX' is the only problematic mechanism in a Doug Otis scenario [10] and Scott Kitterman agreed. There was a comment from Andrew Sullivan, as chair [11]. I read all the messages on this thread. I left some out in this message. It's difficult to come up with a rough summary of the discussion on Issue #24. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00768.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00769.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00771.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00773.html 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg00777.html 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg00781.html 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg00783.html 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg00786.html 9. http://www.ietf.org/mail-archive/web/spfbis/current/msg00787.html 10. http://www.ietf.org/mail-archive/web/spfbis/current/msg00827.html 11. http://www.ietf.org/mail-archive/web/spfbis/current/msg00836.html From johnl@iecc.com Thu Mar 8 09:33:47 2012 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 6DCC221F867D for ; Thu, 8 Mar 2012 09:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.261 X-Spam-Level: X-Spam-Status: No, score=-110.261 tagged_above=-999 required=5 tests=[AWL=0.938, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 ojHyFmCkwm5B for ; Thu, 8 Mar 2012 09:33:46 -0800 (PST) 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 4231021F8678 for ; Thu, 8 Mar 2012 09:33:45 -0800 (PST) Received: (qmail 97918 invoked from network); 8 Mar 2012 17:33:42 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 8 Mar 2012 17:33:42 -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:vbr-info; s=4f58ed76.xn--30v786c.k1203; i=johnl@user.iecc.com; bh=DgpgdojpyYgQXVbJDbZ0Qe71tI21FWa5uhPeWLl8tds=; b=HIJktBZ7FLmutSl7rGYbAFEpLHAkHQ7gTaJHc1dG/ama7g4PpzbqD1OanxGfCMM4sBjmwRrneSc4qAHrEEp3HoXXHuRNSFiLx+p7cWGiz3BEL6R5NuLY81CfZtYKG1B/DrB2v8beGkiTi0/on98EkYRL/0bzpVXBl5ZTDTvjxEU= 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:vbr-info; s=4f58ed76.xn--30v786c.k1203; olt=johnl@user.iecc.com; bh=DgpgdojpyYgQXVbJDbZ0Qe71tI21FWa5uhPeWLl8tds=; b=H65mnqdHp9h7pKm9NPrsc3A2KP5sOIMPWSB3kceaAlf06NDwt9I2/4S+bqdDrtDnt7kVvzDFFfqLYm+zrURftfc+O3qV5Py6qgZv87rlA4634xhakziPVDAbActafl4hLqA6tdINfIWjNFMc6V4N++mSwO6MxdnOymdHXkcFFaY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 8 Mar 2012 17:33:20 -0000 Message-ID: <20120308173320.19832.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20120308074152.09ab1040@elandnews.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [spfbis] #25: RFC 4408: Section 4.4 Parallel Query 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, 08 Mar 2012 17:33:47 -0000 >> 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. If both SPF and TXT RRs are >> looked up, the queries MAY be done in parallel. I don't see how this would be confusing for anyone who is familiar with the way that the DNS works. It means you send off the two queries, then wait and see what if anything comes back in response to both of them. It's a normal technique that's used in a lot of situations other than SPF, and does not require special client libraries, special servers, or special anything else. This sort of relates to the type 99 discussion, since there's only one query to be made, but we can fix that when we decide about type 99. On the third hand, if an SPF record refers to other records via a, mx, include, and so forth, it's entirely reasonable to make those queries in parallel, too. We don't need to say anything about it, it's a normal optimization. So my suggestion is to close this issue, keeping in mind that we may come back and remove the section if we deprecate type 99. R's, John From spf2@kitterman.com Thu Mar 8 10:01:55 2012 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 80C7121F860B for ; Thu, 8 Mar 2012 10:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 Zi4tad9pIZb6 for ; Thu, 8 Mar 2012 10:01:54 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2F921F84BD for ; Thu, 8 Mar 2012 10:01:54 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 69FC820E40FA; Thu, 8 Mar 2012 13:01:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331229713; bh=YInfT8cFWW7VJ8m3MJyKT9WkE3/9Dj8RjQkEA94Oeeo=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=CW0GYPtLUVBb9+ubuTQxvm2DLtDjG9UJocw7AZAJEynTtkflOKboaDFWdWQCHc+X8 QWPdSEYxsULXeaSTKKz7SS8YmsBSV/lj1+JYTNwxvrVm0Rbgtn4Cz1m/fhWVJdz0tU W+u8wbwnfmqe7hdcEMm9pW9FFhEbBmvKieKPVkJc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4D56A20E408F; Thu, 8 Mar 2012 13:01:53 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 08 Mar 2012 13:01:52 -0500 Message-ID: <1635014.q2pgS3jpuG@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120308173320.19832.qmail@joyce.lan> References: <20120308173320.19832.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] #25: RFC 4408: Section 4.4 Parallel Query 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, 08 Mar 2012 18:01:55 -0000 On Thursday, March 08, 2012 05:33:20 PM John Levine wrote: > >> 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. If both SPF and TXT RRs > >> are > >> looked up, the queries MAY be done in parallel. > > I don't see how this would be confusing for anyone who is familiar > with the way that the DNS works. It means you send off the two > queries, then wait and see what if anything comes back in response to > both of them. It's a normal technique that's used in a lot of > situations other than SPF, and does not require special client > libraries, special servers, or special anything else. > > This sort of relates to the type 99 discussion, since there's only one > query to be made, but we can fix that when we decide about type 99. > > On the third hand, if an SPF record refers to other records via a, mx, > include, and so forth, it's entirely reasonable to make those queries in > parallel, too. We don't need to say anything about it, it's a normal > optimization. > > So my suggestion is to close this issue, keeping in mind that we may come > back and remove the section if we deprecate type 99. +1. Scott K From spf2@kitterman.com Thu Mar 8 10:17:04 2012 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 8148321F86D9 for ; Thu, 8 Mar 2012 10:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 C1GII159o6jg for ; Thu, 8 Mar 2012 10:17:03 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id ABD7221F86DC for ; Thu, 8 Mar 2012 10:17:03 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 41F6020E40FA; Thu, 8 Mar 2012 13:17:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331230623; bh=xgpgJF16NtBEmn7fz1AeEjSCErT0Dy4KleHFf54p6Is=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=hrEDruJ9/TXl+KpGW2MVUC0ciNxGqicUYNbVnZlo3HZI89jOEPjUh4QT7Uuw89Bkg aAke8LLSyGvRz22cVTn+v6GyDd2cKcOtvMYCO6sBv52oJmszMAbPjmR2Yzm7i8Xjk9 YcRLe0am1ginTNkLHVJNyiLLgC9LAsYD1fgx28IU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 24B2220E408F; Thu, 8 Mar 2012 13:17:02 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 08 Mar 2012 13:17:02 -0500 Message-ID: <1941350.xkAskUePl6@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120308082243.0a8df518@resistor.net> References: <9452079D1A51524AA5749AD23E00392807F0D6@exch-mbx901.corp.cloudmark.com> <20120308014839.85687.qmail@joyce.lan> <6.2.5.6.2.20120308082243.0a8df518@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] #24: RFC 4408: Reasonable DNS error limits 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, 08 Mar 2012 18:17:04 -0000 On Thursday, March 08, 2012 09:14:02 AM S Moonesamy wrote: > I'll attempt to summarize the discussion of Issue #24. If I > misinterpreted or misunderstood your comments, please let me know. > The issue was based on the message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg00501.html > > Philip Gladstone commented that the number of "exists" mechanisms > that can be invoked is small, so there doesn't appear to be a risk > here [1]. Scott Kitterman pointed out the actionable part of the > issue: this risk can be significantly mitigated by simply imposing > reasonable No Data limits [2]. He also mentioned an implementation > and suggested a survey of records to get a distribution of the number > of void DNS lookups in SPF records. He agreed [3] on the points > mentioned in Philip Gladstone's message. > > John Leslie mentioned that the issue is calling out a possible abuse > situation, wherein an SPF record can call for more than one DNS > lookup to a domain quite unrelated to the sending MTA and that it > deserves discussion on one of our RFCs [4]. He also mentioned that > the essential point is that any no-data response is a hint of abuse; > thus action to impose a limit on the rate of such queries after a > no-data response may be appropriate. > > Murray Kucherawy asked for a clarification about the issue > [5]. Scott Kitterman pointed to draft-otis-spf-dos-exploit-01 > [expired draft] and mentioned that there are easier ways to do an > amplification attack [6]. Murray Kucherawy suggested NODATA cutoff > limits in a security considerations section [7]. > > Arthur Thisell mentioned that it is quite possible to generate larger > amplification attacks using plain old DNS, in particular, the NS, MX, > SRV, etc. records. Unlike RFC 4408, the DNS RFCs don't have any > limits on the recursion depth. It is far easier for an attacker to > trigger an NS lookup than it is to trigger an SPF evaluation [8] and > that things like the "no data" limit are not complete fixes. He also > mentioned in response to a previous message about "MAY" language > would mean that two different SPF implementations/users could > evaluate the same SPF record and give different results [9]. > > Alessandro Vesely quoted Section 5.4 of RFC 4408 and Section 10, and > commented that he did not see amplification [attack]. Stuart Gathman > pointed out that 'MX' is the only problematic mechanism in a Doug > Otis scenario [10] and Scott Kitterman agreed. > > There was a comment from Andrew Sullivan, as chair [11]. > > I read all the messages on this thread. I left some out in this > message. It's difficult to come up with a rough summary of the > discussion on Issue #24. I think it's a good summary and fairly captures my points. The only important point from the thread that I recall (I didn't go reread all the messages) that isn't mention is someone (I think John Leslie) suggesting that "it hasn't happened yet" is not a sufficient argument to consider this risk is necessarily mitigated. I think that absent data, we won't be able to come to a good decision on this issue. The SPF record survey that Murray Kucherawy has in progress now (to help inform the Type TXT/Type SPF discussion) will give us a list SPF records that could serve as an input to the survey I suggested. If, to pick an exemplary number, we determine that we could set the maximum number of void lookups to 5 and affect no currently deployed SPF records that we could find that are otherwise functional, then I think that adding this kind of limit is low risk and eminently sensible. OTOH, if you have to set it to 50 and it still affects some small percentage, it's pretty inconsistent with the backwards compatibility goals in the charter and of minimal value. The truth will likely be (of course) in the middle where we'll have a diversity of opinion about what the facts mean. I'd like to suggest we do the survey and then look at this again. My Perl skills are nil, but I'll be glad to help out to the extent I can. Scott K From spf2@kitterman.com Thu Mar 8 10:21:14 2012 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 B649121F8644 for ; Thu, 8 Mar 2012 10:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=1.011, BAYES_00=-2.599, GB_I_LETTER=-2] 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 NhH-xE-4xIdt for ; Thu, 8 Mar 2012 10:21:12 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C8BA521F861F for ; Thu, 8 Mar 2012 10:21:12 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6121B20E40FA; Thu, 8 Mar 2012 13:21:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331230872; bh=AVQ4NXK0Z7wET3Cu5cbw25KH+vtZpaYxYpnLbHINGyg=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=SY5JXYbQ3J7VVsxrkLFolHWzA9lOJYCqNytm973z0xqxXSDFbEzpJYRnyjULdveNr y4TCI8/S1lupYnBcz1VzoOixtR3ZWZzt8tlBCpqcWCkTQWiX/a7jivRA8bqJ03894G zYzi1zpzbV6cjL1zjs9tiS7AjUzmfcLRUbw8nf0I= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4836120E408F; Thu, 8 Mar 2012 13:21:12 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 08 Mar 2012 13:21:11 -0500 Message-ID: <2624139.lqkInL5mDL@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Fwd: [dmarc-discuss] Results of three-letter domain scan 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, 08 Mar 2012 18:21:14 -0000 I'm forwarding this here since I thought the survey results might be of interest. Scott K ---------- Forwarded Message ---------- Subject: [dmarc-discuss] Results of three-letter domain scan Date: Thursday, March 08, 2012, 07:10:10 AM From: Bryan Costales To: dmarc-discuss@dmarc.org I finished a three day scan of all one, two, and three letter domains in the .com, .org, and .net TLDs. In summary, my results are: 156,198 domains queried 128,833 domains actually exist and are queriable 28,618 had v=spf1 TXT records (22%) 0 had v=spf1 DNS type 99 records 78 had Spf2.0 records 6 had DMARC records The six DMARC records found were: _dmarc.hd.org: v=DMARC1; p=reject; rua=mailto:postmaster@hd.org; ruf=mailto:postmaster@hd.org; pct=100 _dmarc.nb.com: v=DMARC1;p=none;pct=100;ruf=d@ruf.agari.com;rua=mailto:d@rua.agari.com,mailto:dmarcadmin@nb.com _dmarc.bcx.com: v=DMARC1; p=reject; adkim=r; aspf=s; pct=100; rua=mailto:dmarc@bcx.com; ruf=mailto:arf@bcx.com _dmarc.bcx.org: v=DMARC1; p=reject; adkim=s; aspf=s; pct=100; rua=mailto:dmarc@bcx.com; ruf=mailto:arf@bcx.com _dmarc.sga.org: v=DMARC1; p=none; pct=100; rua=mailto:cs@sga.org _dmarc.1hr.net: v=DMARC1; p=reject; rua=mailto:andy@haveland.com; ruf=mailto:andy@haveland.com; pct=100 The list of SPF records can be downloaded from http://www.bcx.com/software/gmilt/spf.list.txt.gz Best regards, --Bryan Costales _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html) ----------------------------------------- From msk@cloudmark.com Thu Mar 8 11:05:27 2012 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 3300021F853C for ; Thu, 8 Mar 2012 11:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 DQ8xCttogspL for ; Thu, 8 Mar 2012 11:05:26 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 584A921F84E7 for ; Thu, 8 Mar 2012 11:05:26 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Thu, 8 Mar 2012 11:05:25 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #25: RFC 4408: Section 4.4 Parallel Query Thread-Index: AQHM/UYmovPAVsz/PkixPU1QwyoSvJZhLqsAgAAH+QD//4tfoA== Date: Thu, 8 Mar 2012 19:05:25 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928080BB9@exch-mbx901.corp.cloudmark.com> References: <20120308173320.19832.qmail@joyce.lan> <1635014.q2pgS3jpuG@scott-latitude-e6320> In-Reply-To: <1635014.q2pgS3jpuG@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #25: RFC 4408: Section 4.4 Parallel Query 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, 08 Mar 2012 19:05:27 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Thursday, March 08, 2012 10:02 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #25: RFC 4408: Section 4.4 Parallel Query >=20 > > So my suggestion is to close this issue, keeping in mind that we may > > come back and remove the section if we deprecate type 99. >=20 > +1. +1. I find the cited text neither misleading nor confusing. Anyone skille= d in the art of DNS or writing code understands what "parallel" means. -MSK From vesely@tana.it Sat Mar 10 04:12:13 2012 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 E02C921F8633 for ; Sat, 10 Mar 2012 04:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.657 X-Spam-Level: X-Spam-Status: No, score=-4.657 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIvbt+HCel1E for ; Sat, 10 Mar 2012 04:12:13 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E9B3621F8631 for ; Sat, 10 Mar 2012 04:12:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1331381530; bh=aSWpY0gagj/z2llktWQSRHqvjTS9cfCRMHHEs3CCc2Q=; l=2383; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Y58DUAPOyiP72zke3PjmmweDQCpxs7owGX72Zrm3bojmruLDYZk8w35TfwF4C7t7W awWGENH+Bs/HfIv2hiWf6w+xTim1k/dtxsWukKJj3QQPGpBkr6eroiyqjPznS05qgW Bxo9T5TkWhs9xpOwyX3IqVMpey0IsC0U7kidsmc8= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 10 Mar 2012 13:12:10 +0100 id 00000000005DC039.000000004F5B451A.00001E52 Message-ID: <4F5B4519.2090602@tana.it> Date: Sat, 10 Mar 2012 13:12:09 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <9452079D1A51524AA5749AD23E00392807F0D6@exch-mbx901.corp.cloudmark.com> <20120308014839.85687.qmail@joyce.lan> <6.2.5.6.2.20120308082243.0a8df518@resistor.net> In-Reply-To: <6.2.5.6.2.20120308082243.0a8df518@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 10 Mar 2012 12:12:14 -0000 On 08/Mar/12 18:14, S Moonesamy wrote: > I'll attempt to summarize the discussion of Issue #24. If I > misinterpreted or misunderstood your comments, please let me know. > [...] > > Alessandro Vesely quoted Section 5.4 of RFC 4408 and Section 10, and > commented that he did not see amplification [attack]. Sorry, I meant to say that if issue #6 were solved by comprehensively limiting lookups rather than guarding against known attack paths only, then there would be no possibility of amplification and this issue would be moot. On 07/Mar/12 19:05, Scott Kitterman wrote: > On Wednesday, March 07, 2012 06:43:15 PM Alessandro Vesely wrote: >> On 07/Mar/12 14:10, Scott Kitterman wrote: >>> >>> The 111 is a corner case. Your reformulation makes it the >>> standard case. I don't think it's a good idea. >> >> As long as we believe that's not the norm, and only happens in >> corner cases, a non-partitioned amount of lookups may be more >> flexible and simpler than a structured limit devised to prevent a >> particular attack only. > > The current rules are: > > No more than 10 terms that need DNS lookups > No more than 10 a lookups from an mx mechanism > No more than 10 a lookups from a PTR mechanism. > > So there is currently a primary limit of 10 and a secondary limit > of 10 lookups per primary of a certain type. I'm unable to see the advantages of such a complicated structure. I hope we are not going to mandate that. > Why would we want to change it? Because we're changing the spec > and it makes the spec clearer is not a good reason if it requires > code to be re-written. Your proposal would. If we wanted to change it, given that current processing limits need clarification and reorganization, we could do it so as to avoid invalidating existing code. > As has been mentioned, one of the primary design principles in SPF > was to produce a deterministic output based on a defined input. AIUI, the "beyond limits" result is meant to be achieved for malicious or buggy records only. It is not a production technique. A "good" SPF record getting PermError after some DNS maintenance, or a "bad" record making a successful attack, are not the kind of determinism we're after. Unless the 10-10-10 rule expresses an interoperable protocol feature, there should be no reason to require that exact behavior. From agthisell@yahoo.com Sat Mar 10 06:08:23 2012 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 4BE3921F860B for ; Sat, 10 Mar 2012 06:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.007 X-Spam-Level: X-Spam-Status: No, score=0.007 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_50=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 B3TqAXqS4aM6 for ; Sat, 10 Mar 2012 06:08:22 -0800 (PST) Received: from nm23-vm0.bullet.mail.ne1.yahoo.com (nm23-vm0.bullet.mail.ne1.yahoo.com [98.138.91.57]) by ietfa.amsl.com (Postfix) with SMTP id E92C321F8610 for ; Sat, 10 Mar 2012 06:08:21 -0800 (PST) Received: from [98.138.90.57] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 10 Mar 2012 14:08:17 -0000 Received: from [98.138.89.162] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 10 Mar 2012 14:08:17 -0000 Received: from [127.0.0.1] by omp1018.mail.ne1.yahoo.com with NNFMP; 10 Mar 2012 14:08:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 260420.70178.bm@omp1018.mail.ne1.yahoo.com Received: (qmail 35362 invoked by uid 60001); 10 Mar 2012 14:08:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1331388497; bh=uga80TRcuLK/gNOjOJSY353VFdSEDWMA6+h6U7dWc+4=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=UeXiQ7mbcVC0H8E+8/g9DaiaoE45vllN3nkHJNINd5m6Yksmo1wX6keRlF/ZM6KEy0i/JWyGl1a0bGHSSWaqgVVCb6mqmZVDwDhVWbqKHaDwZ1+VuFg8ZlyDp+m39FMHLrHrtDyL2Iafk39mw7Vl6CiJUguQg8nCCkQpBExGn4g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=UudQDHLzxQVwKUW3SYaB8paW/4v6bYaecrrTA4+dRUgCZQOaGUbN9o/W5C+kDB313B6yRGpX2WOgGIFQ/JiVXcYnSRW50bAruHZp6cAwevGbKlqLVnVRB4wXUHWN+7NKd15wRy2mf1CwHEZnLd8fCJ4HtiFBVRuzb6wmkh1/rK4=; X-YMail-OSG: e.M7.HwVM1kBlQ0tqd5HgJ8zm_89YdaHEqUqk6XhriLR2.1 D7XWQOKr5r9dFPcMJPnpg3QyXoIfLycGlGwaOzpYPAqsxRrEcDGTEEMJzBU1 u9SlhmDq85v_AE7tpMcw_VzqAxd.16rewyRZaLbKQ7o5ultf2J7G_dmy8i_k gvfwqU9PtxuWWLA2tJYMagqiXOcHP07OM4aB3IZk_zIO4Ah3n1WD6hOAAJj2 hutPLbJZOd6OI_x30bfZOOi_xZ5bv7PDR_MQVj7.yYycSkfZGiHWg7xrf5z5 c0mtXuvmPIUevZ2TYaI1WDNvSFlHEyrtb8fs5knVMqkXjun4oTtJG8uuis8g ja8oqHLkdeypzcuFS3Wl0GHgUjpkQkJRXV6lcErznUAWGkoH_IQHH.Dz84MS 0kl141srRhjcdLUe2h2JOquW82_Y7OBVHb194ZuibJvJqdIjhvB7zPnQLfxD djJ0- Received: from [71.61.133.134] by web125401.mail.ne1.yahoo.com via HTTP; Sat, 10 Mar 2012 06:08:17 PST X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1331388497.22690.YahooMailClassic@web125401.mail.ne1.yahoo.com> Date: Sat, 10 Mar 2012 06:08:17 -0800 (PST) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 10 Mar 2012 14:08:23 -0000 >> The current rules are: >> >> No more than 10 terms that need DNS lookups >> No more than 10 a lookups from an mx mechanism >> No more than 10 a lookups from a PTR mechanism. >> >> So there is currently a primary limit of 10 and a secondary limit >> of 10 lookups per primary of a certain type. > > I'm unable to see the advantages of such a complicated structure. I > hope we are not going to mandate that. The advantage, as I see it, is that it is easier for the publisher. It is easy to count by hand, the number of mechanisms/modifiers. It is easy to make sure (or verify) that your MX records don't have more than 10 hosts. Trying to correctly count the number of DNS looku From spf2@kitterman.com Sat Mar 10 08:55:49 2012 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 3760621F84EF for ; Sat, 10 Mar 2012 08:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 PXDYMwAhZvMw for ; Sat, 10 Mar 2012 08:55:48 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBD421F84EB for ; Sat, 10 Mar 2012 08:55:47 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D849E20E40BB; Sat, 10 Mar 2012 11:55:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331398546; bh=E+THOgfCcm0qkO1ANksjGMlWVIwFhJDvB8B+r/PCNrE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ACxZz2DkewMfuzQiIhC0n3psxLZN5z8YEF+DQf2avmH3ZaLN63A5vTlG3As4mfK16 kd61VovOgDD46Xj9MZyil2J+PVJqz4/DEsZifOdJJ8iwwLC9XG18Co2IOCv8i1wbzE 7m9NsY4F5VCxe9OqVev0RUy0wUpMpA7A7phIxylw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BE60620E4099; Sat, 10 Mar 2012 11:55:46 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 10 Mar 2012 11:55:46 -0500 Message-ID: <15132064.N3D2FkuYn5@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F5B4519.2090602@tana.it> References: <9452079D1A51524AA5749AD23E00392807F0D6@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120308082243.0a8df518@resistor.net> <4F5B4519.2090602@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 10 Mar 2012 16:55:49 -0000 On Saturday, March 10, 2012 01:12:09 PM Alessandro Vesely wrote: > On 08/Mar/12 18:14, S Moonesamy wrote: > > I'll attempt to summarize the discussion of Issue #24. If I > > misinterpreted or misunderstood your comments, please let me know. > > [...] > > > > Alessandro Vesely quoted Section 5.4 of RFC 4408 and Section 10, and > > commented that he did not see amplification [attack]. > > Sorry, I meant to say that if issue #6 were solved by comprehensively > limiting lookups rather than guarding against known attack paths only, > then there would be no possibility of amplification and this issue > would be moot. > > On 07/Mar/12 19:05, Scott Kitterman wrote: > > On Wednesday, March 07, 2012 06:43:15 PM Alessandro Vesely wrote: > >> On 07/Mar/12 14:10, Scott Kitterman wrote: > >>> The 111 is a corner case. Your reformulation makes it the > >>> standard case. I don't think it's a good idea. > >> > >> As long as we believe that's not the norm, and only happens in > >> corner cases, a non-partitioned amount of lookups may be more > >> flexible and simpler than a structured limit devised to prevent a > >> particular attack only. > > > > The current rules are: > > > > No more than 10 terms that need DNS lookups > > No more than 10 a lookups from an mx mechanism > > No more than 10 a lookups from a PTR mechanism. > > > > So there is currently a primary limit of 10 and a secondary limit > > of 10 lookups per primary of a certain type. > > I'm unable to see the advantages of such a complicated structure. I > hope we are not going to mandate that. > > > Why would we want to change it? Because we're changing the spec > > and it makes the spec clearer is not a good reason if it requires > > code to be re-written. Your proposal would. > > If we wanted to change it, given that current processing limits need > clarification and reorganization, we could do it so as to avoid > invalidating existing code. > > > As has been mentioned, one of the primary design principles in SPF > > was to produce a deterministic output based on a defined input. > > AIUI, the "beyond limits" result is meant to be achieved for malicious > or buggy records only. It is not a production technique. > A "good" SPF record getting PermError after some DNS maintenance, or a > "bad" record making a successful attack, are not the kind of > determinism we're after. Unless the 10-10-10 rule expresses an > interoperable protocol feature, there should be no reason to require > that exact behavior. It is. RFC 4408 allows 10 mechanisms that use DNS. If 4408bis allows (to pick an example) an overall limit of 50 DNS lookups without distinguishing as to their type, a sender could publish ann SPF record with (as an example) 15 DNS a: mechanisms that would be compliant with this hypothetical 4408bis requirement. Such a record would get a PermError from any software designed to RFC 4408 requirements. Unless we want to abandon backwards compatibility (we don't and we'd have to recharter for it anyway) the limit of no more than 10 a:, mx:, include:, ptr: or exists: is going to have to be carried forward into 4408bis. There is no backwards compatible way to change it. The other two limits are a bit different. The additional lookups that can be caused by mx: and ptr: mechanisms are lookup caps, not hard publishing limits. Sites can publish as many MX records as they want. It won't cause an error, it will just cause unreliable results because a compliant check_host() implementation will only look at the first ten and there's no guarantee of order in the responses. The current language of RFC 4408 paragraph 10.1 does comprehensively limit the total number of DNS lookups and there is no validated 'attack path'. Issue #6 is about potentially adding an additional constraint that might provide some reduced risk to DNS DoS (not that the current level is high) and offer some potential for performance improvement (since check_host() would be able to abandon processing buggy records earlier). 4408bis needs to clearly define what records will raise errors. SPF record publishers need to have confidence that their records will be processed reliably by both 4408 and 4408bis compliant check_host() implementations. I do not believe it's possible to rewrite the limits the way you have proposed without losing backward compatbility. So either I misunderstand your proposal or one of us is wrong about backward compatibility. Would you please propose some text that might be suitable for inclusion in a 4408bis draft (if we had one) that explains your proposal? Scott K From vesely@tana.it Sun Mar 11 07:21:08 2012 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 1F9EC21F8694 for ; Sun, 11 Mar 2012 07:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.658 X-Spam-Level: X-Spam-Status: No, score=-4.658 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk2hA6KE01+K for ; Sun, 11 Mar 2012 07:21:07 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 119E721F8690 for ; Sun, 11 Mar 2012 07:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1331475665; bh=VJqDR6w8FPvYz9RoLLqESsylT0svYg1jjBOLQKyyz0Y=; l=4260; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=cLI9j5KUOohVLQmqMpseFmip1Ok3lCI1oEOv9B+dlaLCD0m6fvxmQo96PodJOLcH7 tYOMgjMuedQINRnebMbGmpeock7rNeDfCN0wTKhyjgL+dQ6vn0rJMuZnKEzpk3P63w 1WAbxg3PZ590k5Pq9RdhKZ5J1mzop9X8Jz01Huy8= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 11 Mar 2012 15:21:05 +0100 id 00000000005DC039.000000004F5CB4D1.00007F09 Message-ID: <4F5CB4D1.8030602@tana.it> Date: Sun, 11 Mar 2012 15:21:05 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <9452079D1A51524AA5749AD23E00392807F0D6@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120308082243.0a8df518@resistor.net> <4F5B4519.2090602@tana.it> <15132064.N3D2FkuYn5@scott-latitude-e6320> In-Reply-To: <15132064.N3D2FkuYn5@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 11 Mar 2012 14:21:08 -0000 On 10/Mar/12 17:55, Scott Kitterman wrote: > On Saturday, March 10, 2012 01:12:09 PM Alessandro Vesely wrote: >> >> Unless the 10-10-10 rule expresses an interoperable protocol >> feature, there should be no reason to require that exact >> behavior. > > It is. The numbers "10" there have no semantically relevant meaning, though. > RFC 4408 allows 10 mechanisms that use DNS. If 4408bis allows (to > pick an example) an overall limit of 50 DNS lookups without > distinguishing as to their type, a sender could publish ann SPF > record with (as an example) 15 DNS a: mechanisms that would be > compliant with this hypothetical 4408bis requirement. Such a record > would get a PermError from any software designed to RFC 4408 > requirements. > > Unless we want to abandon backwards compatibility (we don't and > we'd have to recharter for it anyway) the limit of no more than 10 > a:, mx:, include:, ptr: or exists: is going to have to be carried > forward into 4408bis. There is no backwards compatible way to > change it. > > The other two limits are a bit different. The additional lookups > that can be caused by mx: and ptr: mechanisms are lookup caps, not > hard publishing limits. Sites can publish as many MX records as > they want. It won't cause an error, it will just cause unreliable > results because a compliant check_host() implementation will only > look at the first ten and there's no guarantee of order in the > responses. That's the semantics of DNS, and the traditional difficulties at maintaining DNS settings. To wit, SPF could be used to just tell what addresses are authorized, and it would be a real pain to maintain it. Therefore, SPF offers all the mechanisms quoted above, and redirect. Thus, publishers' convenience is paid with lookups. (That looks much like interpret/compile tradeoffs, and the situation could be amended using an "SPF compiler" that also monitors related DNS zones and autonomously re-compiles on change.) > The current language of RFC 4408 paragraph 10.1 does comprehensively > limit the total number of DNS lookups and there is no validated > 'attack path'. Attack paths can be considered definitely over-exaggerated liberties being taken by a publisher, in this context. The point is how do we tell when a publisher crosses the line, when it exaggerates, at what point the publisher's convenience isn't worth the price it puts. I see two choices: 1: The standard specifies exactly where the line lies. 2: The standard just says there has to be a line. #1 is apparently what you like and what RFC 4408 might be considered to be stating. #2 is somewhat softer. For a comparison with DKIM, consider the recommended signature content list: the result of a verification may depend on local verifier's settings. > 4408bis needs to clearly define what records will raise errors. > SPF record publishers need to have confidence that their records > will be processed reliably by both 4408 and 4408bis compliant > check_host() implementations. If the WG decides to go for choice #2 above, more latitude is left to verifiers. The 10-10-10 rule lives in security considerations, and we can leave it there, add more considerations aimed at avoiding to damage 3rd parties' DNS servers, and whatever, but make it clear that local verifier policies may determine error conditions arbitrarily. It is also possible to do both choices. That is, specify exactly where the most lenient line lies, while strongly recommending that stricter limits be implemented. In this case, I'd suggest that the mandated "hard" line be expressed in terms simpler than 10-10-10. > I do not believe it's possible to rewrite the limits the way you > have proposed without losing backward compatibility. It is possible, as it can be left to implementations to trace the line. The 10-10-10 behavior may still be suggested not normatively, as it currently stands. > Would you please propose some text that might be suitable for > inclusion in a 4408bis draft (if we had one) that explains your > proposal? That's probably useless. At this stage, it may be enough that the WG understands what that choice is and possibly makes a decision. From spf2@kitterman.com Sun Mar 11 14:16:15 2012 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 627D021F8608 for ; Sun, 11 Mar 2012 14:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 4hLcNhfO-xPM for ; Sun, 11 Mar 2012 14:16:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B662921F85A4 for ; Sun, 11 Mar 2012 14:16:14 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4E95720E40BD; Sun, 11 Mar 2012 17:16:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331500574; bh=2kF2d3Xae2ExKYWWbEAFYfKBh9vv+Odetgac0S6JpPc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=LrrRqc3CUKLNpHdPDbx5J9jg27qvdDXugebS/turaR3lXhstjlMX+dRpuWmZ2pNrH 5L0Q2p8W6hYga3ICsaKxsq3z4dUeIYCCR0GTta6IrtpW6MHR4sAIVkzFvNgjJmQHGK gPtPbFqko7Kv8NzlYwqHD6XpRk+EpFP2oxkuBNyA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3566720E4093; Sun, 11 Mar 2012 17:16:14 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 11 Mar 2012 17:16:13 -0400 Message-ID: <3742706.Jky7TKSgXu@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F5CB4D1.8030602@tana.it> References: <9452079D1A51524AA5749AD23E00392807F0D6@exch-mbx901.corp.cloudmark.com> <15132064.N3D2FkuYn5@scott-latitude-e6320> <4F5CB4D1.8030602@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 11 Mar 2012 21:16:15 -0000 On Sunday, March 11, 2012 03:21:05 PM Alessandro Vesely wrote: > That's probably useless. At this stage, it may be enough that the WG > understands what that choice is and possibly makes a decision. AIUI, the only choice you are offering is if we want to define an interoperable set of requirements for record publishers and processors. I seriously hope we care about interoperabliity. Scott K From msk@cloudmark.com Mon Mar 12 00:24:16 2012 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 BBC0E11E8073 for ; Mon, 12 Mar 2012 00:24:16 -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 pqBvsuUfrMH4 for ; Mon, 12 Mar 2012 00:24:16 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3E35B21F856A for ; Mon, 12 Mar 2012 00:24:16 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Mon, 12 Mar 2012 00:24:15 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #24: RFC 4408: Reasonable DNS error limits Thread-Index: AQHM+7yYx93ZDimmwkGuor51xQ56+JZeFRiAgAALrQCAAOyMAIAANtoAgAAJ1YCAAAgIAIAATCeAgAAGPgCAACT2gIAAA5uA//+JLHCAAI59AIAAMq2A//97ElCAAJNngIABAo0AgALQUYCAAE8+AIABVlmAgACnykA= Date: Mon, 12 Mar 2012 07:24:14 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928085635@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E00392807F0D6@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120308082243.0a8df518@resistor.net> <4F5B4519.2090602@tana.it> <15132064.N3D2FkuYn5@scott-latitude-e6320> <4F5CB4D1.8030602@tana.it> In-Reply-To: <4F5CB4D1.8030602@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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, 12 Mar 2012 07:24:16 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Sunday, March 11, 2012 7:21 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits >=20 > The point is how do we tell when a publisher crosses the line, when it > exaggerates, at what point the publisher's convenience isn't worth the > price it puts. I see two choices: >=20 > 1: The standard specifies exactly where the line lies. >=20 > 2: The standard just says there has to be a line. >=20 > #1 is apparently what you like and what RFC 4408 might be considered to > be stating. #2 is somewhat softer. For a comparison with DKIM, > consider the recommended signature content list: the result of a > verification may depend on local verifier's settings. My problem with #2 is that from one SPF verifier to the next, the results a= re inconsistent. (That's actually a problem with both of them given the random quality of or= dering in DNS replies, but it's even more fuzzy when you don't have any gui= dance on where the line should be.) As I think Scott mentioned elsewhere in the thread, there are ways to get a= round this even if the set of outbound IPs is known even if the set is some= what large. Maybe what we need to do is include a description of that mech= anism and when it might be used. -MSK From sm@elandsys.com Mon Mar 12 11:20:06 2012 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 0929F21F87FE for ; Mon, 12 Mar 2012 11:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 RNlqn6CeYs3U for ; Mon, 12 Mar 2012 11:20: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 53CB921F8848 for ; Mon, 12 Mar 2012 11:20:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.189]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2CIJcrt010150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Mar 2012 11:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331576401; i=@elandsys.com; bh=EPDPbcrB1m0m2el4QTUC8dte2btoEFt2zAVEnAwErw0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=JvAZerovHExbb5+ysvj+9ZZGS0Q7K5zdG4XQ3XSP2owj+6hhQY3E7JQ0+rJqXHjTd wsnBralhhS5by0l2by3FT0XUl4O0ipuWu1K0r6BDLJnvbmu1LxXq8LZe2BO21O0Rdp GLmUnQRdg3RBFnLR/d08Gz8acvrL4H4Ir0SDjh4g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331576401; i=@elandsys.com; bh=EPDPbcrB1m0m2el4QTUC8dte2btoEFt2zAVEnAwErw0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=IkmseVVb5o0iM4fwXX/xI5KFZkKEAzTrTJw9srbmZl4UG/yhlhKLOd+gC9hAxxjgR 2V/k7HbXlAZAK5xvt3+P54xDR5pCha5B0z2fzqlLDgEih6blMX9+r/+bteGC9/1og0 qZCvKI6ElpGRwoJeB8SBKzHjQuJWhT4sTT1tK72s= Message-Id: <6.2.5.6.2.20120312111654.0adb2610@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 12 Mar 2012 11:19:09 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 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, 12 Mar 2012 18:20:06 -0000 At 14:10 07-02-2012, spfbis issue tracker wrote: >#10: RFC 4408 rplace Received-SPF with RFC5451 > > Message from Murray Kucherawy on 6 Feb 2012: > > We should consider striking Section 7 and replacing it with a reference to > RFC5451 with some reasonable but brief associated text. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00330.html [snip] >Ticket URL: Please comment on Issue #10. As a reminder, please keep the subject line. Regards, S. Moonesamy SPFBIS WG co-chair From sm@elandsys.com Mon Mar 12 11:34:39 2012 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 03F0D21F88CB for ; Mon, 12 Mar 2012 11:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 rdMzA3scumRk for ; Mon, 12 Mar 2012 11:34: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 5CFF421F888E for ; Mon, 12 Mar 2012 11:34:34 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.189]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2CIY9JC007983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Mar 2012 11:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331577273; i=@elandsys.com; bh=dqfvqe/8p7c1CHsRKvqLgTRjOslbjmWMGFRZy0zDtzw=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=2yfqubvlIJW6Vkd/er5bldjxLv5fh6Da0+1ZdRSPHCoQlZgEMdH/r1oHLxC7zpKTG QTEq2rq23g5vO+HL2af2LIsP45FxfKXvb24B83KVVXxi90REk5Na/piE1sf90Z9dN2 B0Aysxe0lJgIjO52CI4uq+8YvpPBnOaj4AcmzEQE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331577273; i=@elandsys.com; bh=dqfvqe/8p7c1CHsRKvqLgTRjOslbjmWMGFRZy0zDtzw=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=u4WTqlQImZcc1QayD9kos/l6Ngj/mm/CUCP/FXKnG5+g5Yx1I6IS09sU0WsEzN3I7 S9bd+LdoXhDwK+fEizW2I/7dEIoab7478sVwBFOOGGkg2SAbs0QIMuQqC4zgs14Stl 1pPRhmNPs9AOOFJ/AFxjvOBZRurIizl1b2YDvT3Y= Message-Id: <6.2.5.6.2.20120312112159.0adb24c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 12 Mar 2012 11:30:04 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <9452079D1A51524AA5749AD23E00392807EFAD@exch-mbx901.corp.cl oudmark.com> References: <061.6bd7631aa74ff75bc011ac2769322b92@tools.ietf.org> <6.2.5.6.2.20120307150701.0a0c7d28@elandnews.com> <20802005.zxzKu6fIYM@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807EFAD@exch-mbx901.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #6: RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization 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, 12 Mar 2012 18:34:39 -0000 I'll attempt to summarize the discussion about Issue #6. As usual, if I misunderstood or misinterpreted what you said, please let me know. Issue #6 was raised by Scott Kitterman on February 6 [1]. In a message posted on March 8, he suggested that the protocol requirements should be moved up into the main part of the document from security considerations [2]. Murray Kucherawy agreed [3]. Regards S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00293.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00838.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00839.html From spf2@kitterman.com Mon Mar 12 11:57:26 2012 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 44CF721E8066 for ; Mon, 12 Mar 2012 11:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 N8ql7+65jNMJ for ; Mon, 12 Mar 2012 11:57:25 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A128521E8053 for ; Mon, 12 Mar 2012 11:57:23 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2C7B020E40BD; Mon, 12 Mar 2012 14:57:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331578643; bh=HuTb+f4Usd5KXZ7whnHOn6vB53XJQJcC9dqzVmKXbb0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=gO6YFfielc6n0wop61mcIULALQSD5is5GgvYERg+KBQPP5NC3fVyADNxi6uouqnqX UKj6U6LUg08rjG+qD/Todu9YXF070NiVf1bxmmX72lqZCKmsE9bzl5+geQxZB9gKRZ 0rwRRfeDNjoNQ6fxnsJDuHt13tLgJaxp/z8Lhw0M= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0E51F20E40A4; Mon, 12 Mar 2012 14:57:22 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 12 Mar 2012 14:57:22 -0400 Message-ID: <4916132.0TxoWXRv1F@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120312111654.0adb2610@elandnews.com> References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <6.2.5.6.2.20120312111654.0adb2610@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] #10: RFC 4408 replace Received-SPF with RFC5451 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, 12 Mar 2012 18:57:26 -0000 On Monday, March 12, 2012 11:19:09 AM S Moonesamy wrote: > At 14:10 07-02-2012, spfbis issue tracker wrote: > >#10: RFC 4408 rplace Received-SPF with RFC5451 > > > > Message from Murray Kucherawy on 6 Feb 2012: > > > > We should consider striking Section 7 and replacing it with a > > reference to RFC5451 with some reasonable but brief associated text. At the time RFC 4408 was written, there was no general framework for reporting authentication results, so the Received-SPF trace header was developed. It is still widely used. Now that Authentication-Results exists and is gaining deployment, I agree that it should eventually replace Received-SPF. I have reviewed the Authentication-Results header definition and implemented it as an optional alternative to Received-SPF. I also helped create a Python module for creating and parsing Authentication-Results headers (http://pypi.python.org/pypi/authres ). Based on that work, I believe that Authentication-Results is technically suitable to replace Received-SPF. I do not, however, think we can do it now. Received-SPF is a feature in widespread use and so it's too soon (charter or no charter I think it's premature). I would, however, support including information about both in 4408bis with an indication that Received-SPF is deprecated and support may be dropped in the future when the specification is revisited. Scott K From msk@cloudmark.com Mon Mar 12 12:15:04 2012 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 DDCCE21F8902 for ; Mon, 12 Mar 2012 12:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 zYDpYDCCao-M for ; Mon, 12 Mar 2012 12:15:04 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 67FC521F85AC for ; Mon, 12 Mar 2012 12:15:04 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 12 Mar 2012 12:15:03 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 Thread-Index: AQHNAHzCVedQGBvKIkWWdm+y3YjKp5ZneEgA//+OhiA= Date: Mon, 12 Mar 2012 19:15:03 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280866B5@exch-mbx901.corp.cloudmark.com> References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <6.2.5.6.2.20120312111654.0adb2610@elandnews.com> <4916132.0TxoWXRv1F@scott-latitude-e6320> In-Reply-To: <4916132.0TxoWXRv1F@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 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, 12 Mar 2012 19:15:05 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Monday, March 12, 2012 11:57 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 >=20 > I do not, however, think we can do it now. Received-SPF is a feature > in widespread use and so it's too soon (charter or no charter I think > it's premature). I would, however, support including information about > both in 4408bis with an indication that Received-SPF is deprecated and > support may be dropped in the future when the specification is > revisited. At the risk of harkening back to the type 99 debate, I have two points in r= esponse to this: 1) I'm concerned about endorsing two mechanisms. This may be the right way= forward, but I'm not sure yet. And if it is, I want to be very careful no= t to create another type 99 problem. 2) It's clear there are SPF verifiers that add Received-SPF, but it's not c= lear that anything other than humans actually consumes it. There are howev= er implementations of RFC5451 (at least one) that do parse them inbound in = order to conform to the "remove your own on inbound" requirement that speci= fication imposes, and I imagine there have to be more for that reason. If = we conclude there's no machine processing of Received-SPF inbound, then I s= uspect it's safe, and within charter, to switch. -MSK From spf2@kitterman.com Mon Mar 12 12:31:11 2012 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 DE7AF21E808C for ; Mon, 12 Mar 2012 12:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 ik9TCGGHkDy8 for ; Mon, 12 Mar 2012 12:31:03 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B827421E8086 for ; Mon, 12 Mar 2012 12:31:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 239AD20E40BD; Mon, 12 Mar 2012 15:31:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331580663; bh=H4RcuTULvhllwPJ9dbNlmDf1LFbt9NlnKu4DGv7IYCw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=j8tUh7dx2wmohkLF/2l3YXpKAe7R31V5XYwDoaFm5idGBriW4YCEUUGz5V4X3EwC/ f0hPUjq0xqybQVuDozR6eehOnTQoVBocx371IDaIiAQnPM64grmjXdyOMP8Ui66eQV QmDqeNZSwps+lBOay8rFN4SEXLzNWzLrUQuNHaRU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 09E2920E40A4; Mon, 12 Mar 2012 15:31:02 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 12 Mar 2012 15:31:02 -0400 Message-ID: <3907486.4FXkoHtM5U@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280866B5@exch-mbx901.corp.cloudmark.com> References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <4916132.0TxoWXRv1F@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280866B5@exch-mbx901.corp.cloudmark.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] #10: RFC 4408 replace Received-SPF with RFC5451 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, 12 Mar 2012 19:31:11 -0000 On Monday, March 12, 2012 07:15:03 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Scott Kitterman Sent: Monday, March 12, 2012 11:57 AM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 > > > > I do not, however, think we can do it now. Received-SPF is a feature > > in widespread use and so it's too soon (charter or no charter I think > > it's premature). I would, however, support including information about > > both in 4408bis with an indication that Received-SPF is deprecated and > > support may be dropped in the future when the specification is > > revisited. > > At the risk of harkening back to the type 99 debate, I have two points in > response to this: > > 1) I'm concerned about endorsing two mechanisms. This may be the right way > forward, but I'm not sure yet. And if it is, I want to be very careful not > to create another type 99 problem. > > 2) It's clear there are SPF verifiers that add Received-SPF, but it's not > clear that anything other than humans actually consumes it. There are > however implementations of RFC5451 (at least one) that do parse them > inbound in order to conform to the "remove your own on inbound" requirement > that specification imposes, and I imagine there have to be more for that > reason. If we conclude there's no machine processing of Received-SPF > inbound, then I suspect it's safe, and within charter, to switch. There are such. Spamassassin will consume Received-SPF. Recent versions will consume Auth-Results too. I'm also aware of a number of private implementations that do the remove your own on inbound processing. As an example of why I think it's too soon to switch, I only recently finished implementing Auth-Res support for the Python based SPF policy-server for Postfix that I develop/maintain. This is new enough that, AFAIK, it has yet to appear in any Linux distribution release. Because there is no automatice multi-ADMD interoperability requirement for either of these trace headers (to the extent they are processed, they only matter within an ADMD), there isn't an issue with getting stuck in a non- deployment don't loop like we have with Type SPF. In any case, given that the feature is widely used, I'm not sure how you can find it in the charter to be OK to remove? Scott K From msk@cloudmark.com Mon Mar 12 12:36:06 2012 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 6B07121E808F for ; Mon, 12 Mar 2012 12:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 GHwRwqRUBeIh for ; Mon, 12 Mar 2012 12:36:05 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id EB48821E8086 for ; Mon, 12 Mar 2012 12:36:05 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 12 Mar 2012 12:36:05 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 Thread-Index: AQHNAHzCVedQGBvKIkWWdm+y3YjKp5ZneEgA//+OhiCAAHriAP//i9yw Date: Mon, 12 Mar 2012 19:36:05 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928086762@exch-mbx901.corp.cloudmark.com> References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <4916132.0TxoWXRv1F@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280866B5@exch-mbx901.corp.cloudmark.com> <3907486.4FXkoHtM5U@scott-latitude-e6320> In-Reply-To: <3907486.4FXkoHtM5U@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 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, 12 Mar 2012 19:36:06 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Monday, March 12, 2012 12:31 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 >=20 > In any case, given that the feature is widely used, I'm not sure how > you can find it in the charter to be OK to remove? I did say "If we conclude...". If we don't, then it isn't. -MSK From ajs@anvilwalrusden.com Mon Mar 12 12:38:40 2012 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 78ECC21E809D for ; Mon, 12 Mar 2012 12:38: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 apmp7UB2xoDj for ; Mon, 12 Mar 2012 12:38:39 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 999DF21E809C for ; Mon, 12 Mar 2012 12:38:39 -0700 (PDT) Received: from mail.yitter.info (unknown [199.91.193.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 50BF71ECB41C for ; Mon, 12 Mar 2012 19:38:38 +0000 (UTC) Date: Mon, 12 Mar 2012 15:38:41 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120312193840.GC12833@mail.yitter.info> References: <20120305175124.GR76465@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120305175124.GR76465@crankycanuck.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 12 Mar 2012 19:38:40 -0000 Dear colleagues, On Mon, Mar 05, 2012 at 12:51:24PM -0500, Andrew Sullivan wrote: > If the WG adopts the draft, we expect to appoint Murray as editor > assuming that he is amenable and has time. So far as we are able to determine, there are no objections to this planned course of action. We commited (and remain commited) to undertaking this action in Paris (anyway, we can't publish a -00 until then). But in the absence of any controversy about either the draft or the planned editor, your chairs would not consider it a problem if some work happened on this draft before Paris. Best, Andrew (for the chairs) -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Mon Mar 12 12:40:50 2012 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 997B721E808F for ; Mon, 12 Mar 2012 12:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 4sXk2NeRTw8v for ; Mon, 12 Mar 2012 12:40:50 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D9BB421E805C for ; Mon, 12 Mar 2012 12:40:49 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 74A9D20E40BD; Mon, 12 Mar 2012 15:40:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331581249; bh=1WU8RJcQDZU6TYt5hdtNJKOiVE6VkhIrpH/LTCD+ogs=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=jOz0/awpyqHZpLtZW7dv3aeKSoUXVdyozXaTU0yeMKYzReKZIZ9pjlxgXgSPI3QUQ uK8NMwJtgh9u+I5QiYylr2w3oCTu7cfjjY/HI1Ecml9Btxted/pCQzxt2XfcJ51KsW JEDl5pVupHxxjxZ09AKhzMYljZ7HTMfXPwd5aEU8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5BF9A20E40A4; Mon, 12 Mar 2012 15:40:49 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 12 Mar 2012 15:40:48 -0400 Message-ID: <3774742.6ur9rGJG6v@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E003928086762@exch-mbx901.corp.cloudmark.com> References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <3907486.4FXkoHtM5U@scott-latitude-e6320> <9452079D1A51524AA5749AD23E003928086762@exch-mbx901.corp.cloudmark.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] #10: RFC 4408 replace Received-SPF with RFC5451 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, 12 Mar 2012 19:40:50 -0000 On Monday, March 12, 2012 07:36:05 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Scott Kitterman Sent: Monday, March 12, 2012 12:31 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 > > > > In any case, given that the feature is widely used, I'm not sure how > > you can find it in the charter to be OK to remove? > > I did say "If we conclude...". If we don't, then it isn't. I don't think that if it's machine processed or not is particularly germane to the charter requirements, but since it is used via machine processing, I think the argument is moot. I guess I'll save it for if we get there. Scott K From spf2@kitterman.com Mon Mar 12 12:43:08 2012 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 471F921E809C for ; Mon, 12 Mar 2012 12:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 OGCpwAVuLtUC for ; Mon, 12 Mar 2012 12:43:07 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A142921E805C for ; Mon, 12 Mar 2012 12:43:07 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 353FC20E40BD; Mon, 12 Mar 2012 15:43:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331581387; bh=gpKt8TCu6NxkDL8/XGXJVtww8w0xNBdTohHHUKu9qPI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=KT5osHzHYPr+RbcniBoqvIMBc0s7SRNzQCa6oeT+IrZMjwB8EfqNXRPPYf6fjzxYB DUNEoeTxN0dNgGOT6zu/Q3N9TCQOQ9OwR6SkR6Xb6DR3MbUruLR3ppGfC73RYIorX8 m8+qk/KJ7ESf4NvnNhXiQ2MH1qBDrhGuS7m2+wIU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 17E3620E40A4; Mon, 12 Mar 2012 15:43:06 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 12 Mar 2012 15:43:06 -0400 Message-ID: <8072748.7hBsB5UoZd@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120312193840.GC12833@mail.yitter.info> References: <20120305175124.GR76465@crankycanuck.ca> <20120312193840.GC12833@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 12 Mar 2012 19:43:08 -0000 On Monday, March 12, 2012 03:38:41 PM Andrew Sullivan wrote: > Dear colleagues, > > On Mon, Mar 05, 2012 at 12:51:24PM -0500, Andrew Sullivan wrote: > > If the WG adopts the draft, we expect to appoint Murray as editor > > assuming that he is amenable and has time. > > So far as we are able to determine, there are no objections to this > planned course of action. We commited (and remain commited) to > undertaking this action in Paris (anyway, we can't publish a -00 until > then). But in the absence of any controversy about either the draft > or the planned editor, your chairs would not consider it a problem if > some work happened on this draft before Paris. I have no objection to the document or the editor, but it's difficult to know, in the absence of an overall structure for the work of the group if I should or not. I still find the piecemeal, scattershot approach we are using inefficient and confusing. Scott K From msk@cloudmark.com Mon Mar 12 12:44:31 2012 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 5A31C21F88EE for ; Mon, 12 Mar 2012 12:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 NyU-pnieZRji for ; Mon, 12 Mar 2012 12:44:30 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E62E721F88EA for ; Mon, 12 Mar 2012 12:44:30 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Mon, 12 Mar 2012 12:44:30 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment Thread-Index: AQHM+viuh+ryOLgSzUaSlnd8lXLsyZZnjtyA//+MG0A= Date: Mon, 12 Mar 2012 19:44:30 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280867A4@exch-mbx901.corp.cloudmark.com> References: <20120305175124.GR76465@crankycanuck.ca> <20120312193840.GC12833@mail.yitter.info> In-Reply-To: <20120312193840.GC12833@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 12 Mar 2012 19:44:31 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Andrew Sullivan > Sent: Monday, March 12, 2012 12:39 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis- experim= ent >=20 > So far as we are able to determine, there are no objections to this > planned course of action. We commited (and remain commited) to > undertaking this action in Paris (anyway, we can't publish a -00 until > then). But in the absence of any controversy about either the draft or > the planned editor, your chairs would not consider it a problem if some > work happened on this draft before Paris. We could petition our AD to let the -00 in past the embargo if we really wa= nt to do so. But I'm fine either way. -MSK From dotzero@gmail.com Mon Mar 12 12:51:45 2012 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 6163C21F883C for ; Mon, 12 Mar 2012 12:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 7tH3xPmEEWni for ; Mon, 12 Mar 2012 12:51:43 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0F9221F8835 for ; Mon, 12 Mar 2012 12:51:43 -0700 (PDT) Received: by dakl33 with SMTP id l33so6011161dak.31 for ; Mon, 12 Mar 2012 12:51: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=sruUU58VKgULj2T+wuG5InDCWW/zme399T/bWRzy+aw=; b=vJTITYGZuosb1fZFQ/RkXF1YPSCH2RqsQp67dsY7KA6MNOdUfrcqnArOjSB90NGlfc 7Po3zIf10PkKplHf042JXcCdM8P4aCTefnhDOY1aGqrgQQwm1ySrcv8Ew83mCk2pJAz9 LPF4OxRS6i4rwBjhnqLgcmyTHv0zl6uDtkOfnNjCcQIoMStdeVkiX70J7b/imD7BUw5O CZdmtvHPfN4EbZNs3GBUI1g7QL/0hAXUfR4B3SVjwDRimi9pzSi1ntgmOFSYaptHFnLY prtGOxnYf3eWDnPNcHtNvYFLz6OEAc5CVf+fvheQmAtu4ceyQJTCD1H2i9MPbFygPqus D6/w== MIME-Version: 1.0 Received: by 10.68.129.195 with SMTP id ny3mr18196818pbb.88.1331581903563; Mon, 12 Mar 2012 12:51:43 -0700 (PDT) Received: by 10.68.231.129 with HTTP; Mon, 12 Mar 2012 12:51:43 -0700 (PDT) In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E2050BD50@TK5EX14MBXC204.redmond.corp.microsoft.com> References: <20120305175124.GR76465@crankycanuck.ca> <4F558307.10802@dcrocker.net> <4F563C4F.3050706@dcrocker.net> <1508272.ca9gNiCPaJ@scott-latitude-e6320> <4F563EAC.6030500@dcrocker.net> <7F7F36E50398F84DBAF25C9D51732F1E2050BD50@TK5EX14MBXC204.redmond.corp.microsoft.com> Date: Mon, 12 Mar 2012 15:51:43 -0400 Message-ID: From: Dotzero To: Paul Midgen Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 12 Mar 2012 19:51:45 -0000 On Tue, Mar 6, 2012 at 12:28 PM, Paul Midgen wrote: > discrete cumulative non-parliamentary concurrence > I was going to go with positive affirmation. From msk@cloudmark.com Mon Mar 12 12:51:59 2012 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 F1A2F21E80B4 for ; Mon, 12 Mar 2012 12:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 eiWXT0m18a6k for ; Mon, 12 Mar 2012 12:51:58 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 19B8A21F8835 for ; Mon, 12 Mar 2012 12:51:56 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Mon, 12 Mar 2012 12:51:55 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment Thread-Index: AQHM+viuh+ryOLgSzUaSlnd8lXLsyZZnjtyA//+N1HA= Date: Mon, 12 Mar 2012 19:51:55 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280867E0@exch-mbx901.corp.cloudmark.com> References: <20120305175124.GR76465@crankycanuck.ca> <20120312193840.GC12833@mail.yitter.info> In-Reply-To: <20120312193840.GC12833@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 12 Mar 2012 19:51:59 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Andrew Sullivan > Sent: Monday, March 12, 2012 12:39 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experime= nt >=20 > But in the absence of any controversy about either the draft or > the planned editor, your chairs would not consider it a problem if some > work happened on this draft before Paris. By way of an update, I've retooled the survey I was running to record both = the reply I got (or NXDOMAIN) as well as the time it took for the reply to = come. This will help to detect firewalls and DNS servers that discard unkn= own queries. Such isn't conclusive (recording SERVFAIL along with how long= it took for that reply to come is a heuristic to detect it), but it may lo= g an interesting pattern. -MSK From msk@cloudmark.com Mon Mar 12 13:23:14 2012 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 9D55421F89B2 for ; Mon, 12 Mar 2012 13:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 E+3nzMMIoPk4 for ; Mon, 12 Mar 2012 13:23:14 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1781B21F89B3 for ; Mon, 12 Mar 2012 13:23:13 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 12 Mar 2012 13:23:10 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment Thread-Index: AQHM+viuh+ryOLgSzUaSlnd8lXLsyZZnjtyA//+UY3A= Date: Mon, 12 Mar 2012 20:23:10 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280868D6@exch-mbx901.corp.cloudmark.com> References: <20120305175124.GR76465@crankycanuck.ca> <20120312193840.GC12833@mail.yitter.info> In-Reply-To: <20120312193840.GC12833@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 12 Mar 2012 20:23:14 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Andrew Sullivan > Sent: Monday, March 12, 2012 12:39 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis- experim= ent >=20 > So far as we are able to determine, there are no objections to this > planned course of action. We commited (and remain commited) to > undertaking this action in Paris (anyway, we can't publish a -00 until > then). But in the absence of any controversy about either the draft or > the planned editor, your chairs would not consider it a problem if some > work happened on this draft before Paris. And so in terms of getting work done on progressing it while we wait for th= e -00 embargo to lift, here are the work items as I see them: 1) Add Microsoft/Hotmail's DNS survey results when they're available (proba= bly late this month). 2) Add my own DNS survey results, which I've just restarted, when they're a= vailable (probably late this month). 3) Add any other data that might be contributed by others. 4) People whose data I've cited should be sure I've represented them correc= tly in the document. 5) What would we like to see in the Conclusions section based on the data w= e've collected? I think we could start on (5) at the same time as the others because the su= rveys running are very probably only going to reaffirm what earlier surveys= suggested. My intent is to have all the points in that section be of the = form "Based on X, we conclude Y, because Z.", where X appears in the data s= ections above that in the document, and Z might include references to other= materials to support the Ys. I have my own opinions about all the points this document has to cover, but= my job as editor is to reflect consensus, so it's important that people pa= rticipate so consensus can be determined and recorded. This WG has a lot o= f energy and so the content in here should be quite well-formed once we're = done. So, does anyone want to make a straw man conclusion set to get us started? -MSK From barryleiba.mailing.lists@gmail.com Mon Mar 12 13:41:33 2012 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 4860D21F89DE for ; Mon, 12 Mar 2012 13:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 P9W5SUios7sv for ; Mon, 12 Mar 2012 13:41:32 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4CD321F89DD for ; Mon, 12 Mar 2012 13:41:32 -0700 (PDT) Received: by ggmi1 with SMTP id i1so3461603ggm.31 for ; Mon, 12 Mar 2012 13:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=69Sn9maGz126wWUcsaz67O1yfd1skl0ebKHTLUwCtgU=; b=rLWUOiYKIl4bYhqLkrhS5rdrAyX+NsxZ8DTHLcyzTGBGgBd6tq5iX/E8GUmCdtu400 imgvO+okpy/v6QdgdVaPEYpk9pcIkTWeviBTsQavRk5scyzpa9DnFjHkwObbkjw3WTzC IQPeqZGfhWkI+DQGc0QIPFF0HTEA7+4kxbyT4vhcbZdznGygKpPF2cD7wF9Jpf4Oia/5 PVPH7HVsx3mATDNIPevqrKkgKzcvvew18r0K0YlvZDJOTn/SguE408avIN/OfgIXjdLJ 09tVOXbxoL6H8M2E5qK4SPHJtpV+9O2016TpNhr4WdGto5pUYmOYd4hwo0vVGiEJajjC SfYw== MIME-Version: 1.0 Received: by 10.236.195.37 with SMTP id o25mr14498301yhn.55.1331584892377; Mon, 12 Mar 2012 13:41:32 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.106.16 with HTTP; Mon, 12 Mar 2012 13:41:32 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E0039280866B5@exch-mbx901.corp.cloudmark.com> References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <6.2.5.6.2.20120312111654.0adb2610@elandnews.com> <4916132.0TxoWXRv1F@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280866B5@exch-mbx901.corp.cloudmark.com> Date: Mon, 12 Mar 2012 16:41:32 -0400 X-Google-Sender-Auth: jHyTuxHgVC85bwM7NrR7pN_6Lwc Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=20cf303f6aea7f9c5a04bb11c4a4 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 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, 12 Mar 2012 20:41:33 -0000 --20cf303f6aea7f9c5a04bb11c4a4 Content-Type: text/plain; charset=ISO-8859-1 >> I would, however, support including information about >> both in 4408bis with an indication that Received-SPF is deprecated and >> support may be dropped in the future when the specification is >> revisited. > > At the risk of harkening back to the type 99 debate, I have two points in response to this: > 1) I'm concerned about endorsing two mechanisms. This may be the right way forward, > but I'm not sure yet. Isn't that what Scott's "deprecated" suggestion says? Deprecating "Received-SPF" means saying that it's in current use, but new implementations are advised not to generate it (basically, SHOULD NOT). For something that has enough usage that we can't remove it (yes, the charter goes against that), noting that it's on the way out and new implementations shouldn't generate it seems to be the right way to go. Barry, participatorilly --20cf303f6aea7f9c5a04bb11c4a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> =A0I would, however, support including information about
>&g= t; both in 4408bis with an indication that Received-SPF is deprecated and>> support may be dropped in the future when the specification is >> revisited.
>
> At the risk of harkening back to the ty= pe 99 debate, I have two points in response to this:
> 1) I'm con= cerned about endorsing two mechanisms. =A0This may be the right way forward= ,
> but I'm not sure yet. =A0

Isn't that what Scott's &= quot;deprecated" suggestion says? =A0Deprecating "Received-SPF&qu= ot; means saying that it's in current use, but new implementations are = advised not to generate it (basically, SHOULD NOT). =A0For something that h= as enough usage that we can't remove it (yes, the charter goes against = that), noting that it's on the way out and new implementations shouldn&= #39;t generate it seems to be the right way to go.

Barry, participatorilly --20cf303f6aea7f9c5a04bb11c4a4-- From msk@cloudmark.com Mon Mar 12 13:47:02 2012 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 83E7F21F89BC for ; Mon, 12 Mar 2012 13:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HTML_MESSAGE=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 NwGPWyesXlbS for ; Mon, 12 Mar 2012 13:47:01 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 27B9021F897C for ; Mon, 12 Mar 2012 13:46:55 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 12 Mar 2012 13:46:54 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 Thread-Index: AQHNAHzCVedQGBvKIkWWdm+y3YjKp5ZneEgA//+OhiCAAI6VAP//i99g Date: Mon, 12 Mar 2012 20:46:54 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280869E7@exch-mbx901.corp.cloudmark.com> References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <6.2.5.6.2.20120312111654.0adb2610@elandnews.com> <4916132.0TxoWXRv1F@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280866B5@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280869E7exchmbx901corpclo_" MIME-Version: 1.0 Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 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, 12 Mar 2012 20:47:02 -0000 --_000_9452079D1A51524AA5749AD23E0039280869E7exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As long as that's made clear, sure. I'm just trying to avoid having two me= chanisms in use like we did with the RRTypes. From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@g= mail.com] On Behalf Of Barry Leiba Sent: Monday, March 12, 2012 1:42 PM To: Murray S. Kucherawy Cc: spfbis@ietf.org Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 >> I would, however, support including information about >> both in 4408bis with an indication that Received-SPF is deprecated and >> support may be dropped in the future when the specification is >> revisited. > > At the risk of harkening back to the type 99 debate, I have two points in= response to this: > 1) I'm concerned about endorsing two mechanisms. This may be the right w= ay forward, > but I'm not sure yet. Isn't that what Scott's "deprecated" suggestion says? Deprecating "Receive= d-SPF" means saying that it's in current use, but new implementations are a= dvised not to generate it (basically, SHOULD NOT). For something that has = enough usage that we can't remove it (yes, the charter goes against that), = noting that it's on the way out and new implementations shouldn't generate = it seems to be the right way to go. Barry, participatorilly --_000_9452079D1A51524AA5749AD23E0039280869E7exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As long as that’s m= ade clear, sure.  I’m just trying to avoid having two mechanisms= in use like we did with the RRTypes.

 <= /p>

From: barrylei= ba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@gmail.com] On Behalf Of Barry Leiba
Sent: Monday, March 12, 2012 1:42 PM
To: Murray S. Kucherawy
Cc: spfbis@ietf.org
Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC545= 1

 

>>  I would, however, support including i= nformation about
>> both in 4408bis with an indication that Received-SPF is deprecated= and
>> support may be dropped in the future when the specification is
>> revisited.
>
> At the risk of harkening back to the type 99 debate, I have two points= in response to this:
> 1) I'm concerned about endorsing two mechanisms.  This may be the= right way forward,
> but I'm not sure yet.  

Isn't that what Scott's "deprecated" suggestion says?  Depre= cating "Received-SPF" means saying that it's in current use, but = new implementations are advised not to generate it (basically, SHOULD NOT).=  For something that has enough usage that we can't remove it (yes, the charter goes against that), noting that it's on the way out a= nd new implementations shouldn't generate it seems to be the right way to g= o.

Barry, participatorilly

--_000_9452079D1A51524AA5749AD23E0039280869E7exchmbx901corpclo_-- From spf2@kitterman.com Mon Mar 12 13:52:42 2012 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 5869911E8117 for ; Mon, 12 Mar 2012 13:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 SKAK+ZaQ+bxI for ; Mon, 12 Mar 2012 13:52:41 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEEC11E8104 for ; Mon, 12 Mar 2012 13:52:41 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 94F8120E40BD; Mon, 12 Mar 2012 16:52:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331585560; bh=9ZpqgxFp+TZLrvCZAHJO8u5XXWTq4relnUqa4IK15aA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=eUqyjIIValPzbdh1XWv+l3sef0w07NtAzd6R74YY9BUNrcN8D6sdaPKg1Sd8nkhAB uUaCHy/QE6Q47ZL4YIj0L3wo1UWELTgMpcVa7gLpwK+TxcTGnJNMLQUUni3BCUx304 dDaMMehT77fNOGgYBLQGTXsWUF5wtrhJs7/cKFzY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 77FB820E40A4; Mon, 12 Mar 2012 16:52:40 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 12 Mar 2012 16:52:39 -0400 Message-ID: <3562947.qLpJhHJksn@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280869E7@exch-mbx901.corp.cloudmark.com> References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <9452079D1A51524AA5749AD23E0039280869E7@exch-mbx901.corp.cloudmark.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] #10: RFC 4408 replace Received-SPF with RFC5451 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, 12 Mar 2012 20:52:42 -0000 I think the transition issue is very different. For this one it's make sure you're generating the same thing at the border that you're consuming internally for each ADMD, not "Let's switch over everyone on the internet". Scott K On Monday, March 12, 2012 08:46:54 PM Murray S. Kucherawy wrote: > As long as that's made clear, sure. I'm just trying to avoid having two > mechanisms in use like we did with the RRTypes. > > From: barryleiba.mailing.lists@gmail.com > [mailto:barryleiba.mailing.lists@gmail.com] On Behalf Of Barry Leiba Sent: > Monday, March 12, 2012 1:42 PM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 > > >> I would, however, support including information about > >> > >> both in 4408bis with an indication that Received-SPF is deprecated and > >> support may be dropped in the future when the specification is > >> revisited. > > > > At the risk of harkening back to the type 99 debate, I have two points > > in response to this: 1) I'm concerned about endorsing two mechanisms. > > This may be the right way forward, but I'm not sure yet. > > Isn't that what Scott's "deprecated" suggestion says? Deprecating > "Received-SPF" means saying that it's in current use, but new > implementations are advised not to generate it (basically, SHOULD NOT). > For something that has enough usage that we can't remove it (yes, the > charter goes against that), noting that it's on the way out and new > implementations shouldn't generate it seems to be the right way to go. > > Barry, participatorilly From dhc@dcrocker.net Mon Mar 12 15:26:51 2012 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 5B7C021E808E for ; Mon, 12 Mar 2012 15:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 D1Z6+mPw1JYt for ; Mon, 12 Mar 2012 15:26:50 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B0E9E21E8085 for ; Mon, 12 Mar 2012 15:26:50 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2CMQh8u010951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Mar 2012 15:26:49 -0700 Message-ID: <4F5E780D.9090508@dcrocker.net> Date: Mon, 12 Mar 2012 15:26:21 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Dotzero References: <20120305175124.GR76465@crankycanuck.ca> <4F558307.10802@dcrocker.net> <4F563C4F.3050706@dcrocker.net> <1508272.ca9gNiCPaJ@scott-latitude-e6320> <4F563EAC.6030500@dcrocker.net> <7F7F36E50398F84DBAF25C9D51732F1E2050BD50@TK5EX14MBXC204.redmond.corp.microsoft.com> 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.17]); Mon, 12 Mar 2012 15:26:49 -0700 (PDT) Cc: "spfbis@ietf.org" , "dcrocker@bbiw.net" , Paul Midgen Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 12 Mar 2012 22:26:51 -0000 On 3/12/2012 12:51 PM, Dotzero wrote: > On Tue, Mar 6, 2012 at 12:28 PM, Paul Midgen wrote: >> discrete cumulative non-parliamentary concurrence > > I was going to go with positive affirmation. might be more interesting to have a negative affirmation. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Mon Mar 12 15:27:27 2012 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 D0AEA21E808E for ; Mon, 12 Mar 2012 15:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 R+mOlbUZP4T8 for ; Mon, 12 Mar 2012 15:27:24 -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 141E221E8092 for ; Mon, 12 Mar 2012 15:27:24 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.189]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2CMR8t8027793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Mar 2012 15:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331591239; i=@elandsys.com; bh=jbbYbHfF/sryLRr56p0Jhbpes1yl9XfGF2k015/Btlc=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=g0S05jvNrpHv4PYo7K7q3xQwEN818px2/9VKxVv9cPauCKZVwTTfeZZX716S10/VI Tuyl8igMnCm5bG7K8RSWCCaycimIUbmGkx/viedjj1If3udo6MBTTJvpr/0P+YGRd1 N7ic19jJ4P/ZGaJiayNCk+RZz1XG/OQtj6hT3I0U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331591239; i=@elandsys.com; bh=jbbYbHfF/sryLRr56p0Jhbpes1yl9XfGF2k015/Btlc=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=ZEes2PXUrmxiOjzQzRmN0EgOclHw9jQ820aGecfD2h2fIjokmhQPXBoOhuKGsIJ0f wg0PMgqaJiis0GtiuobuAHoI+VHY9cjxUoK1DdZqNb2KqqV+BX5RfTPPtIemWavs2P Hbgpw2hYoqpu3hxeJXUUfv8pF90DYj8jh5nR6IRI= Message-Id: <6.2.5.6.2.20120312140847.09fa4e10@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 12 Mar 2012 14:27:52 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <9452079D1A51524AA5749AD23E003928080BB9@exch-mbx901.corp.cl oudmark.com> References: <20120308173320.19832.qmail@joyce.lan> <1635014.q2pgS3jpuG@scott-latitude-e6320> <9452079D1A51524AA5749AD23E003928080BB9@exch-mbx901.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #25: RFC 4408: Section 4.4 Parallel Query 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, 12 Mar 2012 22:27:27 -0000 I'll summarize Issue #25. If I misinterpreted or misunderstood your comments, please let me know. Issue #25 was opened based on a message posted on February 23 [1]. John Levine mentioned that the issue sort of relates to the type 99 discussion, since there's only one query to be made, but we can fix that when we decide about type 99 [2]. He also commented on keeping in mind that we may come back and remove the section if we deprecate type 99 and Scott Kitterman agreed [3]. Murray Kucherawy also agreed and added that he does not find the cited text misleading nor confusing [4]. In an off-list contribution, a person agreed that if type 99 is removed, issue #25 is now moot. The person does not think that the "Parallel method is a given and the basic sequential method needs to be described". Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00580.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00848.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00849.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00852.html From dotzero@gmail.com Mon Mar 12 19:44:26 2012 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 2A88E21F88F8 for ; Mon, 12 Mar 2012 19:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 wFCu2aVAEYXT for ; Mon, 12 Mar 2012 19:44:25 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40AEC21F8805 for ; Mon, 12 Mar 2012 19:44:25 -0700 (PDT) Received: by dakl33 with SMTP id l33so112812dak.31 for ; Mon, 12 Mar 2012 19:44: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:content-transfer-encoding; bh=OWopdeXADYmZhOPcG4mtvd5WRZ3rNDRSiNeSiKDN8Eo=; b=zRJL1VxW2dU7ICwJgIEFHiGdTuebfmcG5ew2MwGq42C6wD4VuCf8YReJEzdaxqIcJ0 rIAjjBRsa30dlFwtYXhr5rv5BalJX97zI5V8nOfIiEgAHvIxu8k/jx9JgTdFZ8E30lkl 6Fvtqn9YvRRnARlh6CL9YGJHl/ANi4UCHkz80H2zoOOUpzJbhyhkyjf8KY07+V/4ch6n usL/qmBLK4nKeunJUv7yKJdyHOMsxxR8g9uzYHznkeFiUOvfvDZgrbIDAshyiVJshkBR I3wsH17wT7CSem2yv9vkWOGXQbR+JuomUiKJ/05s2NcQUgvMheLzw8MzIzCLMRP1qz4a AmVg== MIME-Version: 1.0 Received: by 10.68.132.9 with SMTP id oq9mr2072319pbb.130.1331606664960; Mon, 12 Mar 2012 19:44:24 -0700 (PDT) Received: by 10.68.231.129 with HTTP; Mon, 12 Mar 2012 19:44:24 -0700 (PDT) In-Reply-To: <4F5E780D.9090508@dcrocker.net> References: <20120305175124.GR76465@crankycanuck.ca> <4F558307.10802@dcrocker.net> <4F563C4F.3050706@dcrocker.net> <1508272.ca9gNiCPaJ@scott-latitude-e6320> <4F563EAC.6030500@dcrocker.net> <7F7F36E50398F84DBAF25C9D51732F1E2050BD50@TK5EX14MBXC204.redmond.corp.microsoft.com> <4F5E780D.9090508@dcrocker.net> Date: Mon, 12 Mar 2012 22:44:24 -0400 Message-ID: From: Dotzero To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" , Paul Midgen Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 13 Mar 2012 02:44:26 -0000 On Mon, Mar 12, 2012 at 6:26 PM, Dave Crocker wrote: > > > On 3/12/2012 12:51 PM, Dotzero wrote: >> >> On Tue, Mar 6, 2012 at 12:28 PM, Paul Midgen =A0wr= ote: >>> >>> discrete cumulative non-parliamentary concurrence >> >> >> I was going to go with positive affirmation. > > > > might be more interesting to have a negative affirmation. > > d/ I'm still trying to figure out how DKIM got dragged into the thread. From sm@elandsys.com Tue Mar 13 01:31:26 2012 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 56AEE21F889E for ; Tue, 13 Mar 2012 01:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 72m42H09XML6 for ; Tue, 13 Mar 2012 01:31:24 -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 1EF7421F889A for ; Tue, 13 Mar 2012 01:31:24 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.26]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2D8V81F024570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Mar 2012 01:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331627479; i=@elandsys.com; bh=TyDp4ZOo4298t/s9KEXhCb3CNtOi9kWq8m1jJjAHvg8=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=ARIzq6QYkXKFHdZFPAxR/66oY8hF4QagrLIHy2oRO6ecPww6pSvLK7kF+WFGqkgoE cMbnKpSUWkAOSODwhHwsRmOpwt7Sbrs169ZqKQkuVfwoPvIBQXwjDkv6bQMEXlp2GZ LjI/DcWqGv6Vr7TjXIkFcweX5Qmvgbvsrgyrlvkg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331627479; i=@elandsys.com; bh=TyDp4ZOo4298t/s9KEXhCb3CNtOi9kWq8m1jJjAHvg8=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=TPKLeIk6WCqx9bWS39+K5sK1tg6BMiY/26zOhj/CTuN5mMpo52aixYjzhiaQMKbhj VjsAhH4uIgVyoKZupA2UYVSbHVbAFMz2La328Fo1783JUhOTDL+4S7GclXa1dGNdVj Vf9+ldBm4NnGFs3vWrKu3961DSeav8Z+HZJ4MZmM= Message-Id: <6.2.5.6.2.20120313012810.0a31fe60@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Mar 2012 01:30:21 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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, 13 Mar 2012 08:31:26 -0000 At 05:27 10-02-2012, spfbis issue tracker wrote: >#12: RFC 4408 Section 9 - Forwarding and helo identities > > Message from Alessandro Vesely on 10 Feb 2012: > > The advice given in the non-normative Section 9 is misleading. On the > one hand, it provides overly cumbersome techniques based on macros > that are not universally considered safe. On the other hand, it fails > to state the obvious point that a return-path is only needed if > someone is going to care about delivery failures. > > When an email alias refers to an external domain, the forwarder must > change it. This has to be normative, and update Section 3.9.1 of > [RFC5321] --not one of the best written sections of that paper. > > Forwarding =C3=83 la MAIL FROM:<> should be mentioned as the default, > easiest way to re-inject messages. The implied interoperability is > that the owner of the target mailbox must be aware of a given > "forwarding recipe", and be able to modify or delete it. The > variation MAIL FROM: is necessary when a > postmaster's action is needed for modifying/deleting a given recipe. > SRS should be mentioned as a general purpose variation for extended > forwarding needs. > > The spec should say that an SPF record must be defined for every A or= AAAA > record, irrespectively of whether its host label also appears in some MX > RRs. We should encourage the use of _spf labels and redirect=3D for > designing sound and maintainable SPF compliance. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00374.html [snip] >Ticket URL: Please comment on Issue #12. As a reminder, please keep the subject line. Regards, S. Moonesamy SPFBIS WG co-chair=20 From vesely@tana.it Tue Mar 13 05:18:01 2012 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 2137F21F8780 for ; Tue, 13 Mar 2012 05:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.659 X-Spam-Level: X-Spam-Status: No, score=-4.659 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf7JsZ31hEiN for ; Tue, 13 Mar 2012 05:18:00 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 42C5221F877D for ; Tue, 13 Mar 2012 05:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1331641078; bh=CG+PMvGvaMs0PnfMpxXg8vRESCrPITdPhN0yFiJj9gw=; l=1208; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=JhB+Kmpw/Xw3ZBfyGEKRihY2La+61hIcd7L1kVVEHCsBZaqetyzeMTTwDqR6rj7Hq 4PukzOvvDHlKgy/o+FgOYUzd/pCesrHYaFYiShJP7wL0j/PRWnL3GwhgWu6Uwd34mp h80Ejj/OOnzfOksTelhPNeox7NVr1wXpbL9Syb60= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 13 Mar 2012 13:17:58 +0100 id 00000000005DC033.000000004F5F3AF6.00001F4E Message-ID: <4F5F3AF5.4000406@tana.it> Date: Tue, 13 Mar 2012 13:17:57 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <6.2.5.6.2.20120312111654.0adb2610@elandnews.com> <4916132.0TxoWXRv1F@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280866B5@exch-mbx901.corp.cloudmark.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 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, 13 Mar 2012 12:18:01 -0000 On 12/Mar/12 21:41, Barry Leiba wrote: >>> I would, however, support including information about both in >>> 4408bis with an indication that Received-SPF is deprecated and >>> support may be dropped in the future when the specification is >>> revisited. >> >> At the risk of harkening back to the type 99 debate, I have two >> points in response to this: >> 1) I'm concerned about endorsing two mechanisms. This may be the >> right way forward, but I'm not sure yet. > > Isn't that what Scott's "deprecated" suggestion says? Deprecating > "Received-SPF" means saying that it's in current use, but new > implementations are advised not to generate it (basically, SHOULD > NOT). For something that has enough usage that we can't remove it > (yes, the charter goes against that), noting that it's on the way out > and new implementations shouldn't generate it seems to be the right > way to go. Hm... a SHOULD NOT seems quite stronger than needed here. There are implementations that use both, and it is not much disturbing (except for bandwidth/storage, that is.) I'd let it at MAY, noting that the evolution is toward the more homogeneous A-R, but allowing plenty of time to migrate. From spf2@kitterman.com Tue Mar 13 08:11:19 2012 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 A806F21F8897 for ; Tue, 13 Mar 2012 08:11:19 -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 xQx2-HwTPUHb for ; Tue, 13 Mar 2012 08:11:19 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCBC21F888B for ; Tue, 13 Mar 2012 08:11:18 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 1C193D04064; Tue, 13 Mar 2012 10:11:18 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331651478; bh=oowFYc1R4bnvklLZB2BR/oi8WZbm7dMEFABwlccD1No=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=PuGnMCfGAf3SdGLMbOT+2x56Ju1luw6HWaQpdgibwyweEY0delBiSkvGj4e2RfH+U mplGoFk4vzETzas+Dk0TBwmkCC+CqHsgUUkSywre1zGA37rc5mRxlYZhtOATnOfddU KLtC77s8RmR3qxBrabEX289Sd/k7e40Jbfd5lHh4= Received: from 68.sub-97-129-240.myvzw.com (68.sub-97-129-240.myvzw.com [97.129.240.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 98210D04005; Tue, 13 Mar 2012 10:11:17 -0500 (CDT) References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <6.2.5.6.2.20120312111654.0adb2610@elandnews.com> <4916132.0TxoWXRv1F@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280866B5@exch-mbx901.corp.cloudmark.com> <4F5F3AF5.4000406@tana.it> <90491c3c-748f-49d9-9f64-d96f6d2edb69@email.android.com> User-Agent: K-9 Mail for Android In-Reply-To: <90491c3c-748f-49d9-9f64-d96f6d2edb69@email.android.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 13 Mar 2012 11:10:55 -0400 To: spfbis@ietf.org Message-ID: <2cdc6262-63b4-4743-affb-4d2352fdd298@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 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, 13 Mar 2012 15:11:19 -0000 Scott Kitterman wrote: >Alessandro Vesely wrote: > >On 12/Mar/12 21:41, Barry Leiba wrote: >>>> I would, however, support including information about both in >>>> 4408bis with an indication that Received-SPF is deprecated and >>>> support may be dropped in the future when the specification is >>>> revisited. >>> >>> At the risk of harkening back to the type 99 debate, I have two >>> points in response to this: >>> 1) I'm concerned about endorsing two mechanisms. This may be the >>> right way forward, but I'm not sure yet. >> >> Isn't that what Scott's "deprecated" suggestion says? Deprecating >> "Received-SPF" means saying that it's in current use, but new >> implementations are advised not to generate it (basically, SHOULD >> NOT). For something that has enough usage that we can't remove it >> (yes, the charter goes against that), noting that it's on the way out >> and new implementations shouldn't generate it seems to be the right >> way to go. > >Hm... a SHOULD NOT seems quite stronger than needed here. There are >implementations that use both, and it is not much disturbing (except >for bandwidth/storage, that is.) I'd let it at MAY, noting that the >evolution is toward the more homogeneous A-R, but allowing plenty of >time to migrate. I think the term deprecated is a sufficiently standard software development term to make the point that needs making. Since automatic processing generally takes place within an ADMD, switching isn't something that has global interoperability impacts. I don't think any kind of 2119 MUSTard is appropriate here. Scott K From msk@cloudmark.com Tue Mar 13 09:31:58 2012 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 804C121E802C for ; Tue, 13 Mar 2012 09:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 Wv-vyhGWp-zK for ; Tue, 13 Mar 2012 09:31:57 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E404421F8792 for ; Tue, 13 Mar 2012 09:31:57 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Tue, 13 Mar 2012 09:31:57 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment Thread-Index: AQHM+viuh+ryOLgSzUaSlnd8lXLsyZZb/eLwgAEjFoCAANzggIAAAGmAgAACaACAAAy3gIAJhSCAgAArNICAAEgZAIAAcY6A Date: Tue, 13 Mar 2012 16:31:56 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928087ED3@exch-mbx901.corp.cloudmark.com> References: <20120305175124.GR76465@crankycanuck.ca> <4F558307.10802@dcrocker.net> <4F563C4F.3050706@dcrocker.net> <1508272.ca9gNiCPaJ@scott-latitude-e6320> <4F563EAC.6030500@dcrocker.net> <7F7F36E50398F84DBAF25C9D51732F1E2050BD50@TK5EX14MBXC204.redmond.corp.microsoft.com> <4F5E780D.9090508@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 13 Mar 2012 16:31:58 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dotzero > Sent: Monday, March 12, 2012 7:44 PM > To: dcrocker@bbiw.net > Cc: spfbis@ietf.org; Paul Midgen > Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experime= nt >=20 > I'm still trying to figure out how DKIM got dragged into the thread. My best guess is that the document says SPF is part of a small group of dom= ain-level email authentication technologies, and offers DKIM as another exa= mple. But that's it. -MSK From spf2@kitterman.com Tue Mar 13 11:22:57 2012 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 C12C521E804E for ; Tue, 13 Mar 2012 11:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 kBO22zO9DBwF for ; Tue, 13 Mar 2012 11:22:55 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BD08621E8018 for ; Tue, 13 Mar 2012 11:22:55 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BFEFE20E40BD; Tue, 13 Mar 2012 14:22:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331662974; bh=9XFtm1XUwG0RW0/z2OtzEQ59aat1BPYDJ4607zYPvt4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=KqdFrotlwOAWaNym6CyLM87jiI3stpplQp+OD8q0U8ghFb6pAX9bcFF4eswyIQK5T pmkTIkWMtSEEPO9ukMPSdwqJaIJI6YXCa70xqWNrvBWAPKBlSXVpEbwFLQ/VyXEDfz YDDY0xSAkiTsR6RDxvHSuF+XsW9BrLInqLnNMvNQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A15B020E4064; Tue, 13 Mar 2012 14:22:54 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 13 Mar 2012 14:22:54 -0400 Message-ID: <2372065.C4Li7o8hMb@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120313012810.0a31fe60@elandnews.com> References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <6.2.5.6.2.20120313012810.0a31fe60@elandnews.com> 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] #12: RFC 4408 Section 9 - Forwarding and helo identities 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, 13 Mar 2012 18:22:57 -0000 On Tuesday, March 13, 2012 01:30:21 AM S Moonesamy wrote: > At 05:27 10-02-2012, spfbis issue tracker wrote: > >#12: RFC 4408 Section 9 - Forwarding and helo identities > > > > Message from Alessandro Vesely on 10 Feb 2012: > > =20 > > The advice given in the non-normative Section 9 is misleading. On= the > > one hand, it provides overly cumbersome techniques based on macros= > > that are not universally considered safe. On the other hand, it f= ails > > to state the obvious point that a return-path is only needed if > > someone is going to care about delivery failures. It is a given that one only need care about return-path being accurate = if one=20 cares about delivery failures, but also irrelevant. Random dropping of= email=20 (either original messages or bounces) interferes with the overall relia= bility=20 of email on the internet. I don't think the group should add anything=20= indicating that discarding bounces or directing mail from to a non-exis= tant=20 mailbox because the sender doesn't care is a good idea. -1 on the con= cept. More detailed comments below. > > When an email alias refers to an external domain, the forwarder mu= st > > change it. This has to be normative, and update Section 3.9.1 of > > [RFC5321] --not one of the best written sections of that paper. > > =20 > > Forwarding =C3=83 la MAIL FROM:<> should be mentioned as the defa= ult, > > easiest way to re-inject messages. The implied interoperability i= s > > that the owner of the target mailbox must be aware of a given > > "forwarding recipe", and be able to modify or delete it. The > > variation MAIL FROM: is necessary when a > > postmaster's action is needed for modifying/deleting a given recip= e. > > SRS should be mentioned as a general purpose variation for extende= d > > forwarding needs. > > =20 > > The spec should say that an SPF record must be defined for every A= or > > AAAA record, irrespectively of whether its host label also appears= in > > some MX RRs. We should encourage the use of _spf labels and > > redirect=3D for designing sound and maintainable SPF compliance. This issue encompasses a number of disparate recommendations and Alessa= ndro=20 has a number of comments that relate to different parts of the section.= I=20 think it's useful to talk about each part in turn: 9. Implications 9.1. Sending Domains > > The advice given in the non-normative Section 9 is misleading. On= the > > one hand, it provides overly cumbersome techniques based on macros= > > that are not universally considered safe. =20 This appears to refer to 9.1. =20 Nothing is "universally considered safe". It's a known fact that drink= ing too=20 much water can kill you. That doesn't make drinking water a bad idea. = It is=20 true that the type of record suggested in 9.1 is uncachable, so domains= that=20 use it should be prepared for more DNS traffic than is usual for an SPF= record=20 that doens't use uncachable macros. I think it would be reasonable to = mention=20 this. Additionally, there are mechanisms that exist today that did not exist = when=20 RFC 4408 was drafted that provide alternative mechanisms to collect the= =20 relevant data. draft-ietf-marf-spf-reporting, currently in IETF wide l= ast=20 call, is one mechanism that can support exactly this use case. Outside= the=20 IETF, DMARC (dmarc.org) is another approach. =20 References to at least draft-ietf-marf-spf-reporting should be added to= 9.1,=20 but the current text about a special SPF record should remain. The adv= antage=20 of the special SPF record/DNS log approach is that it requires no coope= ration=20 from receivers beyond doing normal SPF checks. 9.2. Mailing Lists It does not appear that any of the comments address 9.2. I think it wo= uld be=20 useful (and a good preamble to the forwarding discussion) to update thi= s text=20 to make use of the email architecture terminology that didn't exist whe= n RFC=20 4408 was written. The references should be updated as well. I don't t= hink=20 any functional changes to 9.2 are needed. 9.3. Forwarding Services and Aliases=20 This comment appears to relate to 9.3: > > When an email alias refers to an external domain, the forwarder mu= st > > change it. This has to be normative, and update Section 3.9.1 of > > [RFC5321] --not one of the best written sections of that paper. As does: > > Forwarding =C3=83 la MAIL FROM:<> should be mentioned as the defa= ult, > > easiest way to re-inject messages. The implied interoperability i= s > > that the owner of the target mailbox must be aware of a given > > "forwarding recipe", and be able to modify or delete it. The > > variation MAIL FROM: is necessary when a > > postmaster's action is needed for modifying/deleting a given recip= e. > > SRS should be mentioned as a general purpose variation for extende= d > > forwarding needs. I disagree with the comments. First, I think 3.6.2 of RFC 5321 is more= =20 relevant (it even mentions SPF by name). I don't think 4408bis should = update=20 5321. I think it would make consensus substantially harder to achieve = and=20 there is no technical need for it. In email architecture terms, a forwarder ("relay SMTP server" in RFC 53= 21=20 terms, not an alias expander) is part of the receiving ADMD. Forwardin= g is=20 configured by the receiver for the receiver's convenience (unlike maili= ng lists=20 where there is a joint participation model). It would be useful to explicitly say in this section that THE place to = do SPF=20 checks is at the transition point between the sending ADMD and the rece= iving=20 ADMD. When a message is relayed within the recieving ADMD, SPF checks,= per se=20 are not appropriate, all that can be done is to use the results of chec= ks done=20 on the ADMD border if they can be trasmitted in a reasonably trustworth= y=20 manner. There are lots of ways problems in this area can be addreesed, a couple= are: 1. Check at the border and internal relays whitelist border relays fro= m SPF=20 checks 2. Rewrite Mail From (e.g. SRS) when mail is transmitted between exter= nal and=20 internal parts of the ADMD so the check can validate that the mail=20 legitimately came a trusted part of their ADMD. Doing wild tricks like null mail from forwarding are not appropriate he= re. =20 They will result in mail loss and there's no need. In the terms that 9.3 is written, I think this is mostly a middle/end p= roblem,=20 but the methods listed for beginning/middle/end that are listed are all= =20 potentially useful. This could use some cleanup to use email arch term= s and=20 such, but it's a pretty decent list of options to use. 9.4. Mail Services=20 9.5. MTA Relays=20 It doesn't appear that there are parts if this issue related to the las= t two=20 sub-sections. > > The spec should say that an SPF record must be defined for every A= or > > AAAA record, irrespectively of whether its host label also appears= in > > some MX RRs. We should encourage the use of _spf labels and > > redirect=3D for designing sound and maintainable SPF compliance. I think it would be useful to add something in this section that addres= ses=20 domains that send no mail. For hosts that really send no mail, "v=3Dsp= f1 -all"=20 is a great record to be publishing as it's got a zero percent chance of= false=20 positive. I think SHOULD publish for all domains is plenty. I don't s= ee a=20 MUST. redirect/include and _spf are nice tools for domains that need them. T= hey are=20 not, however, a general solution or requirement. I think 5.2 already g= ive=20 adequate coverage to the use of include:. I think it would be useful (= as part=20 of the processing limits discussion) to include an indication that SPF = records=20 SHOULD NOT require TCP fallback to retrieve (and this includes the answ= ers for=20 other TXT records published for that domain) and offer the _spf example= of how=20 to work around packet size limitations. Scott K From msk@cloudmark.com Tue Mar 13 13:41:53 2012 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 CCEA821F86B0 for ; Tue, 13 Mar 2012 13:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 yMLXHuoPqNvR for ; Tue, 13 Mar 2012 13:41:53 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 44F6821F86AF for ; Tue, 13 Mar 2012 13:41:53 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Tue, 13 Mar 2012 13:41:52 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities Thread-Index: AQHNAPOvjPj4aXh6qkacTdX4tosjPJZorirQ Date: Tue, 13 Mar 2012 20:41:51 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928088468@exch-mbx901.corp.cloudmark.com> References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <6.2.5.6.2.20120313012810.0a31fe60@elandnews.com> In-Reply-To: <6.2.5.6.2.20120313012810.0a31fe60@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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, 13 Mar 2012 20:41:53 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzcGZiaXMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnNwZmJpcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUyBNb29u ZXNhbXkNCj4gU2VudDogVHVlc2RheSwgTWFyY2ggMTMsIDIwMTIgMTozMCBBTQ0KPiBUbzogc3Bm YmlzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc3BmYmlzXSAjMTI6IFJGQyA0NDA4IFNlY3Rp b24gOSAtIEZvcndhcmRpbmcgYW5kIGhlbG8gaWRlbnRpdGllcw0KPiANCj4gPiAgVGhlIGFkdmlj ZSBnaXZlbiBpbiB0aGUgbm9uLW5vcm1hdGl2ZSBTZWN0aW9uIDkgaXMgbWlzbGVhZGluZy4gIE9u DQo+ID4gdGhlICBvbmUgaGFuZCwgaXQgcHJvdmlkZXMgb3Zlcmx5IGN1bWJlcnNvbWUgdGVjaG5p cXVlcyBiYXNlZCBvbg0KPiA+IG1hY3JvcyAgdGhhdCBhcmUgbm90IHVuaXZlcnNhbGx5IGNvbnNp ZGVyZWQgc2FmZS4gIE9uIHRoZSBvdGhlciBoYW5kLA0KPiA+IGl0IGZhaWxzICB0byBzdGF0ZSB0 aGUgb2J2aW91cyBwb2ludCB0aGF0IGEgcmV0dXJuLXBhdGggaXMgb25seSBuZWVkZWQNCj4gPiBp ZiAgc29tZW9uZSBpcyBnb2luZyB0byBjYXJlIGFib3V0IGRlbGl2ZXJ5IGZhaWx1cmVzLg0KDQpJ ZiB3ZSBoYXZlIHNvbWV0aGluZyB0byBzYXkgYWJvdXQgdGhlIHNhZmV0eSBvZiB1c2Ugb2YgbWFj cm9zLCBkb2luZyBzbyBpbiBTZWN0aW9uIDggb3IgYWRkaW5nIGEgc2VjdGlvbiBhYm92ZSA5LjEg d291bGQgYmUgdGhlIHBsYWNlIHRvIGRvIGl0LiAgQnV0IEkgZG9uJ3QgdGhpbmsgSSBhZ3JlZSB0 aGF0IHdoYXQncyBpbiA5LjEgaXMgb3Zlcmx5IGN1bWJlcnNvbWUuICBJdCBtYXkgbm90IGJlIHN5 bnRhY3RpYyBiZWF1dHksIGJ1dCBpZiB5b3UncmUgd2lsbGluZyB0byBhY2NlcHQgd2hhdCdzIGRl ZmluZWQgaW4gU2VjdGlvbiA4LCB0aGVuIFNlY3Rpb24gOS4xIHNlZW1zIG9rYXkgdG8gbWUuDQoN Cj4gPiBXaGVuIGFuIGVtYWlsIGFsaWFzIHJlZmVycyB0byBhbiBleHRlcm5hbCBkb21haW4sIHRo ZSBmb3J3YXJkZXIgbXVzdA0KPiA+IGNoYW5nZSBpdC4gIFRoaXMgaGFzIHRvIGJlIG5vcm1hdGl2 ZSwgYW5kIHVwZGF0ZSBTZWN0aW9uIDMuOS4xIG9mDQo+ID4gW1JGQzUzMjFdIC0tbm90IG9uZSBv ZiB0aGUgYmVzdCB3cml0dGVuIHNlY3Rpb25zIG9mIHRoYXQgcGFwZXIuDQoNCiJpdCIgYmVpbmcg dGhlIFJGQzUzMjEuTWFpbEZyb20/DQoNCkkgZG9uJ3QgYWdyZWUgdGhhdCB0aGlzIGRvY3VtZW50 IGlzIHRoZSByaWdodCBwbGFjZSB0byBtYWtlIGEgY29ycmVjdGlvbiB0byBSRkM1MzIxIFNlY3Rp b24gMy45LjEgb3V0cmlnaHQuICBJZiB3ZSB3YW50IHRvIHNheSBzb21ldGhpbmcgbGlrZSAiU1BG LXNlbnNpdGl2ZSBpbXBsZW1lbnRhdGlvbnMgbWlnaHQgd2FudCB0byAuLi4iLCB0aGVuIEkgbWln aHQgZ28gZm9yIHRoZSBpZGVhIG9mIHNheWluZyAiVXBkYXRlcyBSRkM1MzIxIiwgYnV0IEkgZG9u J3QgdGhpbmsgd2UnbGwgZ2V0IGF3YXkgd2l0aCAoYW5kIGRvbid0IGFncmVlIHdpdGgpIGEgYmxh bmtldCBzdGF0ZW1lbnQuDQoNCj4gPiAgRm9yd2FyZGluZyDDg8aSICBsYSBNQUlMIEZST006PD4g c2hvdWxkIGJlIG1lbnRpb25lZCBhcyB0aGUgZGVmYXVsdCwNCj4gPiBlYXNpZXN0IHdheSB0byBy ZS1pbmplY3QgbWVzc2FnZXMuICBUaGUgaW1wbGllZCBpbnRlcm9wZXJhYmlsaXR5IGlzDQo+ID4g dGhhdCB0aGUgb3duZXIgb2YgdGhlIHRhcmdldCBtYWlsYm94IG11c3QgYmUgYXdhcmUgb2YgYSBn aXZlbg0KPiA+ICJmb3J3YXJkaW5nIHJlY2lwZSIsIGFuZCBiZSBhYmxlIHRvIG1vZGlmeSBvciBk ZWxldGUgaXQuICBUaGUNCj4gPiB2YXJpYXRpb24gTUFJTCBGUk9NOjxwb3N0bWFzdGVyQGV4YW1w bGUuY29tPiBpcyBuZWNlc3Nhcnkgd2hlbiBhDQo+ID4gcG9zdG1hc3RlcidzIGFjdGlvbiBpcyBu ZWVkZWQgZm9yIG1vZGlmeWluZy9kZWxldGluZyBhIGdpdmVuIHJlY2lwZS4NCj4gPiAgU1JTIHNo b3VsZCBiZSBtZW50aW9uZWQgYXMgYSBnZW5lcmFsIHB1cnBvc2UgdmFyaWF0aW9uIGZvciBleHRl bmRlZA0KPiA+IGZvcndhcmRpbmcgbmVlZHMuDQoNClNvIHRoZSBlbXB0eSBzdHJpbmcgU0hPVUxE IGJlIHRoZSBlbnZlbG9wZSBzZW5kZXIgdXNlZCBmb3IgZm9yd2FyZGVkIG1haWw/ICBUaGF0IGVm ZmVjdGl2ZWx5IGRpc2FibGVzIFNQRiwgbWFraW5nIGZvcndhcmRpbmcgaW50byBhbiBhdHRhY2sg dmVjdG9yLg0KDQpJIGNhbid0IGVudmlzaW9uIHRoZSBpbmZyYXN0cnVjdHVyZSB5b3UncmUgdGFs a2luZyBhYm91dCBoZXJlLiAgV2hhdGV2ZXIgaXQgbWlnaHQgYmUsIEknbSBjb25maWRlbnQgZ3Vl c3NpbmcgYWhlYWQgb2YgdGltZSB0aGF0IGl0IHdvdWxkIGV4Y2VlZCB0aGUgY29uc3RyYWludHMg b2YgdGhlIGNoYXJ0ZXIsIGJ1dCBJJ2Qgc3RpbGwgbGlrZSB0byBoZWFyIHdoYXQgeW91IGhhdmUg aW4gbWluZC4NCg0KU1BGIHN0YW5kcyBvbiBpdHMgb3duIHdpdGhvdXQgU1JTLCBidXQgaXQgaGFz IHNlZW4gb25seSB2ZXJ5IGxpdHRsZSBhZG9wdGlvbiBhcyBmYXIgYXMgSSBrbm93LCBzbyBJIHRo aW5rIGF0IGJlc3Qgd2UgY291bGQgbWVudGlvbiBTUlMgaW4gYW4gYXBwZW5kaXguDQoNCj4gPiAg VGhlIHNwZWMgc2hvdWxkIHNheSB0aGF0IGFuIFNQRiByZWNvcmQgbXVzdCBiZSBkZWZpbmVkIGZv ciBldmVyeSBBIG9yDQo+ID4gQUFBQSAgcmVjb3JkLCBpcnJlc3BlY3RpdmVseSBvZiB3aGV0aGVy IGl0cyBob3N0IGxhYmVsIGFsc28gYXBwZWFycyBpbg0KPiA+IHNvbWUgTVggIFJScy4gIFdlIHNo b3VsZCBlbmNvdXJhZ2UgdGhlIHVzZSBvZiBfc3BmIGxhYmVscyBhbmQNCj4gPiByZWRpcmVjdD0g Zm9yICBkZXNpZ25pbmcgc291bmQgYW5kIG1haW50YWluYWJsZSBTUEYgY29tcGxpYW5jZS4NCg0K SSBkb24ndCB0aGluayB3ZSBjYW4gZW5jb3VyYWdlIHVzZSBvZiBfc3BmIGluIHRoaXMgZG9jdW1l bnQgYXMgaXQncyBhIHN1YnN0YW50aWFsIGRlcGFydHVyZSBmcm9tIHRoZSBkZXBsb3llZCBiYXNl LCBhbmQgd2UncmUgdGh1cyBjaGFydGVyLWNvbnN0cmFpbmVkIGFnYWluc3QgZG9pbmcgc28uICBJ bmZvcm1hdGl2ZSB0ZXh0IGFib3V0IGVuY291cmFnaW5nIHVzZSBvZiByZWRpcmVjdD0gaXMgZmlu ZSBpZiB3ZSBjYW4gY29tZSB0byBzb21lIGNvbnNlbnN1cyBvbiBpdCwgZXNwZWNpYWxseSBpZiBp dCdzIGJhc2VkIG9uIGRhdGEgdGhhdCBzaG93cyBpdCdzIHdpc2UuDQoNCi1NU0sNCg== From msk@cloudmark.com Tue Mar 13 13:55:16 2012 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 D5C4021F84B5 for ; Tue, 13 Mar 2012 13:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 cu2uqUVoy43b for ; Tue, 13 Mar 2012 13:55:16 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 87BA221F853A for ; Tue, 13 Mar 2012 13:55:15 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Tue, 13 Mar 2012 13:55:15 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities Thread-Index: AQHNAUZS1zQ5UGus8k+dRPuGMu8eIpZoswuw Date: Tue, 13 Mar 2012 20:55:14 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280884FA@exch-mbx901.corp.cloudmark.com> References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <6.2.5.6.2.20120313012810.0a31fe60@elandnews.com> <2372065.C4Li7o8hMb@scott-latitude-e6320> In-Reply-To: <2372065.C4Li7o8hMb@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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, 13 Mar 2012 20:55:17 -0000 Scott did all the work, but... > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Tuesday, March 13, 2012 11:23 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident= ities >=20 An informative reference to that draft might be a good idea, though I don't= have strong feelings either way. > References to at least draft-ietf-marf-spf-reporting should be added to > 9.1, but the current text about a special SPF record should remain. +1 > It does not appear that any of the comments address 9.2. I think it > would be useful (and a good preamble to the forwarding discussion) to > update this text to make use of the email architecture terminology that > didn't exist when RFC > 4408 was written. The references should be updated as well. I don't > think any functional changes to 9.2 are needed. +1 > I disagree with the comments. First, I think 3.6.2 of RFC 5321 is more > relevant (it even mentions SPF by name). I don't think 4408bis should > update 5321. I think it would make consensus substantially harder to > achieve and there is no technical need for it. +1 (I need a +1 button) > It would be useful to explicitly say in this section that THE place to > do SPF checks is at the transition point between the sending ADMD and > the receiving ADMD. When a message is relayed within the recieving > ADMD, SPF checks, per se are not appropriate, all that can be done is > to use the results of checks done on the ADMD border if they can be > trasmitted in a reasonably trustworthy manner. We can make liberal use of or reference to Appendix C of RFC5451 to back th= is up. > redirect/include and _spf are nice tools for domains that need them. > They are not, however, a general solution or requirement. I think 5.2 > already give adequate coverage to the use of include:. I think it > would be useful (as part of the processing limits discussion) to > include an indication that SPF records SHOULD NOT require TCP fallback > to retrieve (and this includes the answers for other TXT records > published for that domain) and offer the _spf example of how to work > around packet size limitations. Sounds reasonable. -MSK From sm@elandsys.com Tue Mar 13 17:49:54 2012 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 BBE7D21E8036 for ; Tue, 13 Mar 2012 17:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 F7p4AjjAmju1 for ; Tue, 13 Mar 2012 17:49:53 -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 A2D7D21E800F for ; Tue, 13 Mar 2012 17:49:53 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.203]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2E0nfDP013845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Mar 2012 17:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331686192; i=@elandsys.com; bh=o/nwq9LyjkF4yxWt4DWTKSGq2u6oubl1QqAFuMqDpQ0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=ptbVzbtHY0NXNsERiDI10sUtWS60eC/EQlQh/02lLz/W54C6/l6EaMRj0kqVjx+EY Gud5f6RSljD8OSo8ClTTCQ7xHbPLbzlSDDffxejfYXAEXRGxNAxSf7+TJ6QYbLLU62 +luBw+BHsN0y4jZn6ft9YWlyfM/8r0lWB9YiLESk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331686192; i=@elandsys.com; bh=o/nwq9LyjkF4yxWt4DWTKSGq2u6oubl1QqAFuMqDpQ0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=j2T64L/4/fp2KVl9QKrud5S3mK/AL+kNNVJoQFEVnjn6CjgJ3Ay38d7N1gysXZV5O uziDbu1PCoI+B/LcK+9xhxa7ytEE6ehJmDw4mQnC/4XR6XoHhY+q+K7Tw2OKpW8Bct zpq6w/frhXMhH+0ylPwAsWvWal8DmgQ1no6soC7w= Message-Id: <6.2.5.6.2.20120313164854.0ac1f800@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Mar 2012 17:46:37 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <2372065.C4Li7o8hMb@scott-latitude-e6320> References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <6.2.5.6.2.20120313012810.0a31fe60@elandnews.com> <2372065.C4Li7o8hMb@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 00:49:54 -0000 Hello, There has been comments about changes which should go in 4408bis. It is up to the WG to reach agreement on whether it wants to document problems in the "conclusion" draft and address them in the 4408bis draft. There isn't any mention of SRS in RFC 4408. Currently, it is not possible to tell whether SRS will go into 4408bis or not. I'll highlight a paragraph from the SPFBIS charter: "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." A narrow interpretation of that might come out as: if there isn't an error, there isn't any ground for making a correction. If the someone argues for adding an enhancement, the person has to show that the enhancement has _already_ gained widespread support. There is an IETF meeting coming up in a few weeks. Is "forwarding" a problem which should be on the agenda? Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Tue Mar 13 18:17:25 2012 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 C962111E8073 for ; Tue, 13 Mar 2012 18:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 zHOPdouPJvh4 for ; Tue, 13 Mar 2012 18:17:25 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 117DB21F855D for ; Tue, 13 Mar 2012 18:17:25 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 43EBA20E40BD; Tue, 13 Mar 2012 21:17:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331687844; bh=HDN//93sgCBGGXXrHH7Z/5wqF3ljl0qJQ8fh1e9rCo8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=fR4ZP1xRIzE2fX3ooVXW8RXpvznzadKkdsq95viK4NMLvuAnfm406MrqtuFHibDCM AUqNZXvvl0NEBJkWlNC7df5kZVJi+GmXJf2uphya7X+Gng5fn4ar7p721pf8gNRjns UEqJUa/52j9l0MvI/aYZLN04i20EdbwYiBEngxlA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 260EC20E4064; Tue, 13 Mar 2012 21:17:23 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 13 Mar 2012 21:17:23 -0400 Message-ID: <1349057.HC0y8X2qev@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120313164854.0ac1f800@resistor.net> References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <2372065.C4Li7o8hMb@scott-latitude-e6320> <6.2.5.6.2.20120313164854.0ac1f800@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] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 01:17:25 -0000 On Tuesday, March 13, 2012 05:46:37 PM S Moonesamy wrote: > Hello, > > There has been comments about changes which should go in 4408bis. It > is up to the WG to reach agreement on whether it wants to document > problems in the "conclusion" draft and address them in the 4408bis > draft. There isn't any mention of SRS in RFC 4408. Currently, it is > not possible to tell whether SRS will go into 4408bis or not. I'll > highlight a paragraph from the SPFBIS charter: > > "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." > > A narrow interpretation of that might come out as: if there isn't an > error, there isn't any ground for making a correction. If the > someone argues for adding an enhancement, the person has to show that > the enhancement has _already_ gained widespread support. > > There is an IETF meeting coming up in a few weeks. Is "forwarding" a > problem which should be on the agenda? Forwarding (I think relaying is a better term as it's used in 5321) is not a problem, per se. It is a case that SPF that it takes some care in an SPF deployment at accomodate. Using SRS is one of many ways to do so, but since SRS has never been standardized, I don't think 4408bis should refer to it specifically. It is a specific method of rewriting "Mail From" in order to support downstream SPF queries. RFC 4408 9.3.2.1 describes this in general terms. It is useful to have that in there, but I don't think defining a specific method is needed. There is no interoperability benefit for doing so. I'm quite confused about this mail as it seems to be concerned about reusing existing concepts from RFC 4408. SRS is a shorthand (as one specific method) for doing what's described in 9.3.2.1. There's no news here as far as I can tell. Am I missing something? Scott K From sm@elandsys.com Tue Mar 13 18:43:26 2012 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 304FA21F8569 for ; Tue, 13 Mar 2012 18:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 kBQ45+kXR-rj for ; Tue, 13 Mar 2012 18:43: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 81ED021F8568 for ; Tue, 13 Mar 2012 18:43:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.203]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2E1hBPQ023859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Mar 2012 18:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331689402; i=@elandsys.com; bh=TYmiKI3jZlUdczdMQWN/oidIqFVIcF45SFu1aPZ9DPU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=kVTwGj2FS7xr1ITof74RehEYiKoE4l66KFo8AuYRkyaTsvmC986vLwrlU3buS/CMU WVTIVzOVjbPU4OTVQpTxVWSegKzmCcxR0KP+FkaCgXFnQ/l2b+boZMSk6XPHReil4d K60XezexgJtcbceW0ZwOdxeuHXCl+RYM6OENEjOg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331689402; i=@elandsys.com; bh=TYmiKI3jZlUdczdMQWN/oidIqFVIcF45SFu1aPZ9DPU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=jxbIOlB5wKiIUaXXwX1yxpx45OVntq8KuM4v64A0CvyAHRp4Qj2/dtvMYjdNCMuvb ExsqEbMhHraCwxXwDNpuxxhGEvyR1FV/gg+puG5ZNF7osPaFW+0biz7MITmXrGwQzo EZbqfLfqdt3vXtdjiVi3u5n5KU7A8stWu3VUFO5E= Message-Id: <6.2.5.6.2.20120313183121.0a5542f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Mar 2012 18:41:13 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1349057.HC0y8X2qev@scott-latitude-e6320> References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <2372065.C4Li7o8hMb@scott-latitude-e6320> <6.2.5.6.2.20120313164854.0ac1f800@resistor.net> <1349057.HC0y8X2qev@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 01:43:26 -0000 Hi Scott, At 18:17 13-03-2012, Scott Kitterman wrote: >I'm quite confused about this mail as it seems to be concerned about reusing >existing concepts from RFC 4408. SRS is a shorthand (as one specific method) >for doing what's described in 9.3.2.1. There's no news here as far as I can >tell. Am I missing something? The message is about whether there is an issue which requires face to face discussion. If so, time would have to be allocated to it in the agenda for the forthcoming WG session. Regards, S. Moonesamy From spf2@kitterman.com Tue Mar 13 18:58:15 2012 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 D2EB121F84BD for ; Tue, 13 Mar 2012 18:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 M3qUT0+XMCTh for ; Tue, 13 Mar 2012 18:58:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D10FD21F84B6 for ; Tue, 13 Mar 2012 18:58:14 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 586B820E40BD; Tue, 13 Mar 2012 21:58:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331690294; bh=JjKwCXstCqXCedmrVg5gseePw0e8YStf7yIkrQFBw+Y=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=FzNxR+l3kxavbqnOfzdov2ZDX/v+uo3C9SUNINVktHTBiMcEewlPpQjCZ21TkFjrN WQJssBv8RNUCXyUINRJSCotE26KLs1rpDZ9hH9NCKf0o2fInEy7DAFxk8jkKopWrvG xywjifbHZ0m+tArpwM2j2utI+UzgvjcMvuWWwERo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2488E20E4064; Tue, 13 Mar 2012 21:58:13 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 13 Mar 2012 21:58:13 -0400 Message-ID: <5894992.S2ySQ6Xl3m@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120313183121.0a5542f8@resistor.net> References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <1349057.HC0y8X2qev@scott-latitude-e6320> <6.2.5.6.2.20120313183121.0a5542f8@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] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 01:58:16 -0000 On Tuesday, March 13, 2012 06:41:13 PM S Moonesamy wrote: > Hi Scott, > > At 18:17 13-03-2012, Scott Kitterman wrote: > >I'm quite confused about this mail as it seems to be concerned about > >reusing existing concepts from RFC 4408. SRS is a shorthand (as one > >specific method) for doing what's described in 9.3.2.1. There's no news > >here as far as I can tell. Am I missing something? > > The message is about whether there is an issue which requires face to > face discussion. If so, time would have to be allocated to it in the > agenda for the forthcoming WG session. What issue? Scott K From spf2@kitterman.com Tue Mar 13 19:41:15 2012 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 60FE821E8017 for ; Tue, 13 Mar 2012 19:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 p9ORN+j12pdZ for ; Tue, 13 Mar 2012 19:41:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6F94921E800F for ; Tue, 13 Mar 2012 19:41:14 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D844920E40BD; Tue, 13 Mar 2012 22:41:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331692873; bh=GxT4/Iuzqow/irG/vYeFuKeVyyjL0EFFSw/LdFnro30=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=LTYuyzaWyldmCP6xu2zTyVYTF57WE+fCOcmq6kLE1medpsqEp3KBQw5DbByRNKgL/ B7D4ZQRh53D3TMRmz93NqL2wrqz7pEGEUHEKEi3QVjjK4MlC7J2fSlv5o1HVrwW8Tk TojRaH/7gc2nkOzjWe5nHmyPmgEEypU1llOAqn3o= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BD40720E4064; Tue, 13 Mar 2012 22:41:13 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 13 Mar 2012 22:41:13 -0400 Message-ID: <1802142.Q6lvvUk8k4@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <5894992.S2ySQ6Xl3m@scott-latitude-e6320> References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <6.2.5.6.2.20120313183121.0a5542f8@resistor.net> <5894992.S2ySQ6Xl3m@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 02:41:15 -0000 On Tuesday, March 13, 2012 09:58:13 PM Scott Kitterman wrote: > On Tuesday, March 13, 2012 06:41:13 PM S Moonesamy wrote: > > Hi Scott, > > > > At 18:17 13-03-2012, Scott Kitterman wrote: > > >I'm quite confused about this mail as it seems to be concerned about > > >reusing existing concepts from RFC 4408. SRS is a shorthand (as one > > >specific method) for doing what's described in 9.3.2.1. There's no > > >news > > >here as far as I can tell. Am I missing something? > > > > The message is about whether there is an issue which requires face to > > face discussion. If so, time would have to be allocated to it in the > > agenda for the forthcoming WG session. > > What issue? > > Scott K OK. I wet back and read the original message again. I gather this is your potential issue: > There is an IETF meeting coming up in a few weeks. Is "forwarding" a > problem which should be on the agenda? I don't see the benefit. RFC 4408 covers the range of possibilities reasonably well in terms of how senders and receivers can accommodate this attribute of the email architecture. All we need to do is update the current text a bit to take into account the email arch document and it's terminology. I don't think there's a real issue that needs to take up meeting time. Scott K From johnl@iecc.com Tue Mar 13 20:59:09 2012 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 CE41D21E8050 for ; Tue, 13 Mar 2012 20:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.306 X-Spam-Level: X-Spam-Status: No, score=-110.306 tagged_above=-999 required=5 tests=[AWL=0.893, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 vif48wfp+pV0 for ; Tue, 13 Mar 2012 20:59:09 -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 D827021E8017 for ; Tue, 13 Mar 2012 20:59:08 -0700 (PDT) Received: (qmail 39140 invoked from network); 14 Mar 2012 03:59:07 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Mar 2012 03:59:07 -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:vbr-info; s=4f60178b.xn--30v786c.k1203; i=johnl@user.iecc.com; bh=xJdvtKD7WVYnJvG0C+Gdcprn5GfxYRuZ/G7biB/In3s=; b=oSqbgveZrA43yJMYADOeaWiXca8y0RwtmNMYpUj4DYSCmHzDGtSBH9Z5rkORSpN8/DOwNZso6XKvPqqpeJP6q36ZXfwGF9XlUrSMDrWggpApdQbMlfLg8SXyeeHTqCFv5u/1jvoFd8s8RnH4wim06KccFC+pjPwQW3OhkjomMUg= 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:vbr-info; s=4f60178b.xn--30v786c.k1203; olt=johnl@user.iecc.com; bh=xJdvtKD7WVYnJvG0C+Gdcprn5GfxYRuZ/G7biB/In3s=; b=kD39Eu1e3LubMvZcMQM1P9yZYM0oeKf4EVPQVJgTmVe2Yiz2HhTx0brBJB061DGOaxzUqDA3ojJ0mceXCw9toYn91GCmpdDrH2ZDJEmvlIku2eqQwoaXrllDAr4A2n8Zu6LVO+i86UZ7pnxteDZt+wzbpF7rA82mPHQREeMqJwQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Mar 2012 03:58:45 -0000 Message-ID: <20120314035845.2234.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20120313164854.0ac1f800@resistor.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: sm+ietf@elandsys.com Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 03:59:09 -0000 >There is an IETF meeting coming up in a few weeks. Is "forwarding" a >problem which should be on the agenda? NO, Capital N, Capital O. SPF is path authentication, it's well understood that it's not designed to deal with forwarding. People have been trying to invent ways to shoehorn forwarded mail into SPF since long before RFC 4408, and I think it's safe to say that nothing new in that regard has happened since 4408. There may still be some people who think that all SMTP mail should change to match what SPF does. (Not Scott, certainly.) They are wrong. R's, John From sm@elandsys.com Tue Mar 13 22:20:34 2012 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 973F421F85D8 for ; Tue, 13 Mar 2012 22:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 4n3onSrMz9Az for ; Tue, 13 Mar 2012 22:20:32 -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 4F06121F85D3 for ; Tue, 13 Mar 2012 22:20:32 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.203]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2E5KJ9F017021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Mar 2012 22:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331702430; i=@elandsys.com; bh=hrNI80bbhD9Quf79z/1qydFa0pAE4k8eAnqlD/KZgn4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=RW22lqoL0QAvD/3h9qN6P2wUQBCE+ZgeWXCizMtPjd+b3ek7X/8O/OizjgT+7EJtp 85PXacMSMdhaS76zgaACPQo+8XO6NWSRaCwgHpbgVIArVLkO42SLyC/KFdtu7bBaDJ CfKYfg4KgpDDFyrsKVurYuKn7vVMry21P9FadLUY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331702430; i=@elandsys.com; bh=hrNI80bbhD9Quf79z/1qydFa0pAE4k8eAnqlD/KZgn4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=ApBQvtOL7kyHMVlv4WDzZmlQSDRpQIKmtCh/xeiNLgLRN3KIrxK/tUWHl2d+IdGKU JEXNC0ZuhxEQsplN3/OLvA36xhVsiK/PbpCu6earVaRZzn1RjuBb+o2AO65Znke0ll fdf6QkXl0ZQfamQ3aT6TnZJy1stFqNxmidsr1ON4= Message-Id: <6.2.5.6.2.20120313221606.0aeaadf0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Mar 2012 22:17:22 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for 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: Wed, 14 Mar 2012 05:20:34 -0000 At 17:53 17-02-2012, spfbis issue tracker wrote: >#14: RFC 4408: local-part macro prep for deprecation > > Message from Doug Otis on 17 Feb 2012: > > Use of local-part macros in SPF record sets necessitates repeating all > invoked DNS transactions. DNS caching only limits DNS overhead when no > local-part macros are used within SPF record sets. It is not uncommon for > the use of random local-part names in messages to be sent by malefactors. > Such use significantly impacts the utility of SPF without burdening the > authoritative servers employed by malefactors. Not only will local-part > macros increase the gain of a reflected attack, it also prevents resolving > addresses of a set of servers for a specific domain. > Permitting local-part assessments will return results based upon entire > email addresses and not just the email-address domain. It is common to > use SPF to resolve the outbound addresses used by a domain to check > reputation listings against these addresses. This use assumes a specific > domain has not defined local-part macros in their record set or that it > defaults to "postmaster". > > SPF local-part macros should not be used as a method to vet valid local- > part names, as this would permit the use of high speed dictionary attacks > to discover which are valid. A domain better protects confidentiality of > valid local-parts by postponing acceptance or refusal to the Data command. > A reasonable practice for recipients to use to ensure effective caching > and to retain the desired utility is to supplant any local-part with that > of "postmaster". Otherwise, when SPF processing follows other types of > vetting, expansion of the local-part would leak its status via DNS > requests. > > Add: > > A method for mitigating a reduction in utility or risks associated with > local-part macros would be to replace any local-part with that of > "postmaster". > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00412.html [snip] >Ticket URL: Please comment on the Issue #14. As a reminder, please keep the subject line. Regards, S. Moonesamy SPFBIS WG co-chair From sm@elandsys.com Tue Mar 13 23:03:54 2012 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 6BF0C21F84D0 for ; Tue, 13 Mar 2012 23:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 wFsbMn0X7nfr for ; Tue, 13 Mar 2012 23:03:50 -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 74EAF21F84C4 for ; Tue, 13 Mar 2012 23:03:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.203]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2E63bJm009139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Mar 2012 23:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331705028; i=@elandsys.com; bh=yPz2koVfCT3RVXd0IacINUhWDm0Jwn34n4WHJ7BVpDA=; h=Date:To:From:Subject:Cc; b=omSjAdwpf0gNs9eJkKKnRe4xHuvwjtcYxWA2B12Yiv9E8r80H35OEnth4OwHbSK7J IGQeS1tvW8kh+ZlFr19KOmVMAFN7GY21HL2wJjTDrzhGc+My9YUMi33uwhmkoUPUBw GADWl3bF73Ap8bVObDUnGYxcmCHczrUXXrAgyllA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331705028; i=@elandsys.com; bh=yPz2koVfCT3RVXd0IacINUhWDm0Jwn34n4WHJ7BVpDA=; h=Date:To:From:Subject:Cc; b=DpoRllEea3Sl7E+UaE5KAyQghpTHQirN+Am1rUD2kRjC9MBKGxh5IePYI98S/wUh6 KycH9xQwbfwjt4rdnFVkxmP7XpG+U2Lelm4rghUZ4E6A+091bbX4cdbWN8IFGb5YZ9 7SXRqCKWiXrsx77Pgft3WSCvruRNi1aYifabb7mo= Message-Id: <6.2.5.6.2.20120313222350.08f06a08@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Mar 2012 22:42:59 -0700 To: spfbis@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] RFC 4408 issue list 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 Mar 2012 06:03:54 -0000 Hello, The following issues have been opened for discussion. I'll list the links to the summary of the discussions. #1 http://www.ietf.org/mail-archive/web/spfbis/current/msg00719.html #2 http://www.ietf.org/mail-archive/web/spfbis/current/msg00441.html #3 http://www.ietf.org/mail-archive/web/spfbis/current/msg00439.html #4 http://www.ietf.org/mail-archive/web/spfbis/current/msg00772.html #6 http://www.ietf.org/mail-archive/web/spfbis/current/msg00860.html #8 http://www.ietf.org/mail-archive/web/spfbis/current/msg00442.html #9 - no summary available #10 - no summary available #12 - no summary available #13 http://www.ietf.org/mail-archive/web/spfbis/current/msg00715.html #14 - no summary available #16 http://www.ietf.org/mail-archive/web/spfbis/current/msg00829.html #17 http://www.ietf.org/mail-archive/web/spfbis/current/msg00718.html #23 http://www.ietf.org/mail-archive/web/spfbis/current/msg00717.html #24 http://www.ietf.org/mail-archive/web/spfbis/current/msg00847.html #25 http://www.ietf.org/mail-archive/web/spfbis/current/msg00876.html If an issue has not been opened yet and you would like to see it discussed at IETF 83, please send a request to spfbis-chairs@tools.ietf.org together with an explanation. Regards, S. Moonesamy SPFBIS WG co-chair From vesely@tana.it Wed Mar 14 03:17:12 2012 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 E08DE21F8732 for ; Wed, 14 Mar 2012 03:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.659 X-Spam-Level: X-Spam-Status: No, score=-4.659 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6vROkKLFMxh for ; Wed, 14 Mar 2012 03:17:12 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D33B421F872A for ; Wed, 14 Mar 2012 03:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1331720230; bh=E3dlgUxKGyQGzeJbJpSVpaB2v/GYW9fsaN5IS2R6B1k=; l=2873; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=k6tYW6gmlkZS1zCcGmutBxB025bZr9AVb0DOTwYIh9GupoCfYy6Wf9Cso8ay95LaS njkU2Q8/F2AyQXfvUGL7tGNHLKrcd4FoADheoO6cWLf9afGdXCqFMXigwb/14chTEX ee55M27bGz2LNhll2MS1Il+TAgq9Q6rzwMoeivS8= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 14 Mar 2012 11:17:10 +0100 id 00000000005DC047.000000004F607026.00006042 Message-ID: <4F607025.6060704@tana.it> Date: Wed, 14 Mar 2012 11:17:09 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <6.2.5.6.2.20120313012810.0a31fe60@elandnews.com> <9452079D1A51524AA5749AD23E003928088468@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928088468@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 10:17:13 -0000 On 13/Mar/12 21:41, Murray S. Kucherawy wrote: > >>> When an email alias refers to an external domain, the forwarder must >>> change it. This has to be normative, and update Section 3.9.1 of >>> [RFC5321] --not one of the best written sections of that paper. > > "it" being the RFC5321.MailFrom? Yep. > I don't agree that this document is the right place to make a > correction to RFC5321 Section 3.9.1 outright. If we want to say > something like "SPF-sensitive implementations might want to ...", > then I might go for the idea of saying "Updates RFC5321" There are implementations that violate 3.9.1 by not leaving "the rest of the envelope" (that is, RFC5321.MailFrom) unchanged. As that change was triggered by SPF, it should be up to SPF to spell the text that 5321bis will hopefully adopt, whenever "the celestial omens align correctly". Scott correctly notes that RFC 5321 evades defining methods to verify MailFrom, when it mentions SPF and relaying. Forwarding (in the 821 sense of relaying while changing the envelope recipient) is not done well in RFC 5321 because some sentences there are ambiguous (see also http://trac.tools.ietf.org/wg/yam/trac/ticket/9). In particular, the term "alias" doesn't look like a synonym of intra-ADMD redirection/ expansion. >>> Forwarding à la MAIL FROM:<> should be mentioned as the default, >>> easiest way to re-inject messages. > > So the empty string SHOULD be the envelope sender used for > forwarded mail? That effectively disables SPF, making forwarding > into an attack vector. SPF verification is limited to the helo identity in such cases. In the worst case that should deliver a neutral result, whereas keeping RFC5321.MailFrom unchanged would deserve a fail. The impasse whereby most domains cannot afford -all is rooted in exactly this point. > I can't envision the infrastructure you're talking about here. > Whatever it might be, I'm confident guessing ahead of time that it > would exceed the constraints of the charter, but I'd still like to > hear what you have in mind. I don't know how many MTAs changed their default forwarding behavior in violation of Section 3.9.1 of RFC5321 in order to support SPF. Is that a widespread support? I think it is an error that Section 3.9 does not circumscribe the use of alias expansion rules. Should spfbis correct that, or at least add clarifying language? Forwarding has other shortcomings that ought to be fixed, but they are not related to SPF. See http://fixforwarding.org/. > I don't think we can encourage use of _spf in this document as it's > a substantial departure from the deployed base, and we're thus > charter-constrained against doing so. I though _spf was quite popular (_spf.microsoft.com, _spf.google.com, _spf.yahoo.com, ...) but I'm willing to correct myself when I'm wrong. From spf2@kitterman.com Wed Mar 14 04:11:14 2012 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 5E2AC21F8790 for ; Wed, 14 Mar 2012 04:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 3J3UMbsfLJ9v for ; Wed, 14 Mar 2012 04:11:13 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5992A21F878E for ; Wed, 14 Mar 2012 04:11:13 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7A86920E40D0; Wed, 14 Mar 2012 07:11:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331723472; bh=sshytNwuzRiMeOcYWEBsBzlGYxdEqtLUUht8OH/7UdY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=JKpX1fKeIn410lOjW5ZJeN/LWV/MM80AFk0OPEmt/P5UbK3o8w3B1m9jwxqJFD7QG CeZS7loEDi7wQmDM7PWijal1hVGzV5bR15OusrdQUQ4LEJP2PjotTdkIn87vu47bmR OQ6AyhMlc1MYGlBONeI7Sp8WC4neKBItp+PLeHys= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6109B20E40A3; Wed, 14 Mar 2012 07:11:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 14 Mar 2012 07:11:11 -0400 Message-ID: <2446087.zUs73KZpp2@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120313221606.0aeaadf0@elandnews.com> References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <6.2.5.6.2.20120313221606.0aeaadf0@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] #14: RFC 4408: local-part macro prep for 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: Wed, 14 Mar 2012 11:11:14 -0000 On Tuesday, March 13, 2012 10:17:22 PM S Moonesamy wrote: > At 17:53 17-02-2012, spfbis issue tracker wrote: > >#14: RFC 4408: local-part macro prep for deprecation > > > > Message from Doug Otis on 17 Feb 2012: > > > > Use of local-part macros in SPF record sets necessitates repeating all > > invoked DNS transactions. DNS caching only limits DNS overhead when > > no > > local-part macros are used within SPF record sets. It is not uncommon > > for the use of random local-part names in messages to be sent by > > malefactors. Such use significantly impacts the utility of SPF > > without burdening the authoritative servers employed by malefactors. > > Not only will local-part macros increase the gain of a reflected > > attack, it also prevents resolving addresses of a set of servers for > > a specific domain. > > Permitting local-part assessments will return results based upon > > entire > > email addresses and not just the email-address domain. It is common > > to > > use SPF to resolve the outbound addresses used by a domain to check > > reputation listings against these addresses. This use assumes a > > specific domain has not defined local-part macros in their record set > > or that it defaults to "postmaster". > > > > SPF local-part macros should not be used as a method to vet valid > > local- > > part names, as this would permit the use of high speed dictionary > > attacks to discover which are valid. A domain better protects > > confidentiality of valid local-parts by postponing acceptance or > > refusal to the Data command. A reasonable practice for recipients to > > use to ensure effective caching and to retain the desired utility is > > to supplant any local-part with that of "postmaster". Otherwise, > > when SPF processing follows other types of vetting, expansion of the > > local-part would leak its status via DNS requests. > > > > Add: > > > > A method for mitigating a reduction in utility or risks associated > > with > > local-part macros would be to replace any local-part with that of > > "postmaster". > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00412.html > > [snip] > > >Ticket URL: > > Please comment on the Issue #14. As a reminder, please keep the subject > line. This is a used, but uncommonly used feature of the protocol. It is uncommonly used as most domains will not need per-user policies. Removing it would break backward compatiblity. Arbitrarily replacing the actual localpart with postmaster would do the same. The fact that localpart macros affect cachabilty is not news. 4408 8.1 includes: Note: Domains should avoid using the "s", "l", "o", or "h" macros in conjunction with any mechanism directive. Although these macros are powerful and allow per-user records to be published, they severely limit the ability of implementations to cache results of check_host() and they reduce the effectiveness of DNS caches. There's no evidence provided that these macros are, or ever have been, used by "malefactors" to attempt to cause harm and even less evidence that such attempts have ever succeeded. The point about outbound checks is odd, since that's within an ADMD's control how to manage such things and so it's a simple case of "if it hurts, don't do that". It's been a best practice for the better part of a decade for MTAs not to accept mail for invalid recipients, so there are other ways of accomplishing the exact idea of extracting valid localpart names. There is no news about this. Fundamentally the changes requested in this issue are outside the charter and there's no valid rationale for pursuing them in any case. Scott K From spf2@kitterman.com Wed Mar 14 04:22:03 2012 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 7E90A21F8797 for ; Wed, 14 Mar 2012 04:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 X9gGP8sbTlGR for ; Wed, 14 Mar 2012 04:22:02 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6166521F8754 for ; Wed, 14 Mar 2012 04:22:02 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EDD2F20E40D0; Wed, 14 Mar 2012 07:22:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331724122; bh=dqmI1wqKTj/71etLW4XYwyf5K/AA/hJCho7p3RDljTc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=BSad/BNo4lBHLx1GEBkiOtyX4O2MVugJqKc80df1Eq+W5b9G9cIhwVM21W9S9ytfL wG+t01CQ01gHvsqO3a6J2XEKOT8n3D46fWoeGaMNH8a70diQIJfRYuNDxi2LH0Cwdu LS41pks4YloHG1ObEf0yUUb8YmwHNAAcJTU27Xe0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id CC75920E40A3; Wed, 14 Mar 2012 07:22:01 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 14 Mar 2012 07:22:01 -0400 Message-ID: <42961400.o77ARy3XGq@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F607025.6060704@tana.it> References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <9452079D1A51524AA5749AD23E003928088468@exch-mbx901.corp.cloudmark.com> <4F607025.6060704@tana.it> 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] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 11:22:03 -0000 On Wednesday, March 14, 2012 11:17:09 AM Alessandro Vesely wrote: > On 13/Mar/12 21:41, Murray S. Kucherawy wrote: > >>> When an email alias refers to an external domain, the forwarder m= ust > >>> change it. This has to be normative, and update Section 3.9.1 of= > >>> [RFC5321] --not one of the best written sections of that paper. > >=20 > > "it" being the RFC5321.MailFrom? >=20 > Yep. >=20 > > I don't agree that this document is the right place to make a > > correction to RFC5321 Section 3.9.1 outright. If we want to say > > something like "SPF-sensitive implementations might want to ...", > > then I might go for the idea of saying "Updates RFC5321" >=20 > There are implementations that violate 3.9.1 by not leaving "the rest= > of the envelope" (that is, RFC5321.MailFrom) unchanged. As that > change was triggered by SPF, it should be up to SPF to spell the text= > that 5321bis will hopefully adopt, whenever "the celestial omens alig= n > correctly". >=20 > Scott correctly notes that RFC 5321 evades defining methods to verify= > MailFrom, when it mentions SPF and relaying. Forwarding (in the 821 > sense of relaying while changing the envelope recipient) is not done > well in RFC 5321 because some sentences there are ambiguous (see also= > http://trac.tools.ietf.org/wg/yam/trac/ticket/9). In particular, the= > term "alias" doesn't look like a synonym of intra-ADMD redirection/ > expansion. What is being discussed here isn't a (5321) 3.9.1 alias expansion, it's= a=20 3.6.1 relay SMTP server. As such, your notion that Mail From must be c= hanged=20 is just incorrect. 5321 is silent on the issue and this isn't the plac= e to fix=20 it if it needs fixing. > >>> Forwarding =E0 la MAIL FROM:<> should be mentioned as the default= , > >>> easiest way to re-inject messages. > >=20 > > So the empty string SHOULD be the envelope sender used for > > forwarded mail? That effectively disables SPF, making forwarding > > into an attack vector. >=20 > SPF verification is limited to the helo identity in such cases. In > the worst case that should deliver a neutral result, whereas keeping > RFC5321.MailFrom unchanged would deserve a fail. The impasse whereby= > most domains cannot afford -all is rooted in exactly this point. >=20 > > I can't envision the infrastructure you're talking about here. > > Whatever it might be, I'm confident guessing ahead of time that it > > would exceed the constraints of the charter, but I'd still like to > > hear what you have in mind. >=20 > I don't know how many MTAs changed their default forwarding behavior > in violation of Section 3.9.1 of RFC5321 in order to support SPF. Is= > that a widespread support? I think it is an error that Section 3.9 > does not circumscribe the use of alias expansion rules. Should spfbi= s > correct that, or at least add clarifying language? No. Section 9 of 4408 already beats the topic to death. =20 > Forwarding has other shortcomings that ought to be fixed, but they ar= e > not related to SPF. See http://fixforwarding.org/. >=20 > > I don't think we can encourage use of _spf in this document as it's= > > a substantial departure from the deployed base, and we're thus > > charter-constrained against doing so. >=20 > I though _spf was quite popular (_spf.microsoft.com, _spf.google.com,= > _spf.yahoo.com, ...) but I'm willing to correct myself when I'm wrong= . It is common use, but it's an arbitrary convention, not a feature of th= e=20 protocol. Such addresses are only used in SPF processing if they are p= ointed=20 to by a redirect or include from elsewhere. If you want to encourage t= his as=20 a method to contrain DNS reply size in the initial query, I think it's = fine,=20 although using _bob.example.com would work just the same. =20 BTW, not all those actually exist. Scott K From msk@cloudmark.com Wed Mar 14 10:41:44 2012 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 7F14521F8776 for ; Wed, 14 Mar 2012 10:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 uaNIhlBf9rfH for ; Wed, 14 Mar 2012 10:41:44 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id EE63021F86A7 for ; Wed, 14 Mar 2012 10:41:43 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 10:41:38 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities Thread-Index: AQHNAXxgcvNWCv52skGjXWyyVu1V/JZqDy3w Date: Wed, 14 Mar 2012 17:41:38 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928089EC3@exch-mbx901.corp.cloudmark.com> References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <6.2.5.6.2.20120313012810.0a31fe60@elandnews.com> <2372065.C4Li7o8hMb@scott-latitude-e6320> <6.2.5.6.2.20120313164854.0ac1f800@resistor.net> In-Reply-To: <6.2.5.6.2.20120313164854.0ac1f800@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 17:41:44 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of S Moonesamy > Sent: Tuesday, March 13, 2012 5:47 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident= ities >=20 > There has been comments about changes which should go in 4408bis. It > is up to the WG to reach agreement on whether it wants to document > problems in the "conclusion" draft and address them in the 4408bis > draft. I would say that the conclusion document is not a place to document problem= s except those that are germane to the resolution of the experiment. > There isn't any mention of SRS in RFC 4408. Currently, it is > not possible to tell whether SRS will go into 4408bis or not. I'll > highlight a paragraph from the SPFBIS charter: >=20 > "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." I don't advocate adding SRS as any normative part of SPFbis. I would, howe= ver, suggest in some informative section of the document that the WG consid= er including a reference to it as we describe the known limitations of SPF,= assuming there's a stable definition for SRS somewhere out there we could = use. I also think SPF stands just fine on its own without SRS or a similar mecha= nism, so I'd be just fine leaving it out altogether. I may need coffee to jar my memory, but I don't think I've seen anything in= our deliberations so far that warrants more discussion of the forwarding p= roblem than we already have in RFC4408. We should definitely review it aga= in though as we move forward. -MSK From sm@elandsys.com Wed Mar 14 10:44:18 2012 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 376D121F8740 for ; Wed, 14 Mar 2012 10:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 3duchM6IC7Nq for ; Wed, 14 Mar 2012 10:44:16 -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 1080421F86DB for ; Wed, 14 Mar 2012 10:44:16 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.218]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2EHi2lV010851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Mar 2012 10:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331747054; i=@elandsys.com; bh=X4sz3k4Osb+DVymIF0P6UKxJiE501YnLYNp4YlmeSxs=; h=Date:To:From:Subject:Cc; b=vrovZPEDo06wnhe+U2QdTnK3VlKWYbimGn+AqYF+QVYvepQLW3sf06qCtfFVUXWin 8yRJKvoUi9pLdQ1ZzOGzHiw4FDTB3BUovPG/aa0I1O1c3no2Dz/EK7la4RIL4rhnfm szs9X5+vgcxN4Hk7OTz91K/TmK7I+EutDsXY/9S0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331747054; i=@elandsys.com; bh=X4sz3k4Osb+DVymIF0P6UKxJiE501YnLYNp4YlmeSxs=; h=Date:To:From:Subject:Cc; b=vwrbwdMCjYSGxAWROvYNCGU63+yGxFzPk8NMihgJbVku9uH2hDrjOa4tdE6wWiHPt a7R2z7do1EAS3TmtrY3DkrXnR4uq0pC54DNKs0lzDVCTydW2nVeAs9pRHzIpBsCjsW o21nD8Jndsvwe8fDhT19vjeDURBUwwj4sPQe247M= Message-Id: <6.2.5.6.2.20120314103632.0a451d08@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Mar 2012 10:40:38 -0700 To: spfbis@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Draft agenda for IETF83 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 Mar 2012 17:44:18 -0000 Hello, This is a tentative agenda for the IETF83 session: SPF Update Working Group Agenda March 30, 2012 09:00 - 11:00 120 minutes Note well 1 minute Agenda bashing 4 minutes RFC 4408 issues 35 minutes SPF RR Type and TXT RR (issue #9) 20 minutes DNS amplification attacks 20 minutes Adoption of draft describing the 30 minutes SPF/Sender-ID experiment and discussion Any Other Business 10 minutes http://www.ietf.org/proceedings/83/agenda/agenda-83-spfbis.txt Regards, S. Moonesamy SPFBIS WG co-chair From msk@cloudmark.com Wed Mar 14 10:58:48 2012 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 45ACB21F8528 for ; Wed, 14 Mar 2012 10:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 EoSEqqqRYxYp for ; Wed, 14 Mar 2012 10:58:47 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4B221F8527 for ; Wed, 14 Mar 2012 10:58:47 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 10:58:46 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities Thread-Index: AQHNAcukKLAHKNVlD0KkeRiQqRl/r5ZqELkg Date: Wed, 14 Mar 2012 17:58:45 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928089F06@exch-mbx901.corp.cloudmark.com> References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <6.2.5.6.2.20120313012810.0a31fe60@elandnews.com> <9452079D1A51524AA5749AD23E003928088468@exch-mbx901.corp.cloudmark.com> <4F607025.6060704@tana.it> In-Reply-To: <4F607025.6060704@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 17:58:48 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzcGZiaXMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnNwZmJpcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxlc3Nh bmRybyBWZXNlbHkNCj4gU2VudDogV2VkbmVzZGF5LCBNYXJjaCAxNCwgMjAxMiAzOjE3IEFNDQo+ IFRvOiBzcGZiaXNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzcGZiaXNdICMxMjogUkZDIDQ0 MDggU2VjdGlvbiA5IC0gRm9yd2FyZGluZyBhbmQgaGVsbyBpZGVudGl0aWVzDQo+IA0KPiA+IEkg ZG9uJ3QgYWdyZWUgdGhhdCB0aGlzIGRvY3VtZW50IGlzIHRoZSByaWdodCBwbGFjZSB0byBtYWtl IGENCj4gPiBjb3JyZWN0aW9uIHRvIFJGQzUzMjEgU2VjdGlvbiAzLjkuMSBvdXRyaWdodC4gIElm IHdlIHdhbnQgdG8gc2F5DQo+ID4gc29tZXRoaW5nIGxpa2UgIlNQRi1zZW5zaXRpdmUgaW1wbGVt ZW50YXRpb25zIG1pZ2h0IHdhbnQgdG8gLi4uIiwgdGhlbg0KPiA+IEkgbWlnaHQgZ28gZm9yIHRo ZSBpZGVhIG9mIHNheWluZyAiVXBkYXRlcyBSRkM1MzIxIg0KPiANCj4gVGhlcmUgYXJlIGltcGxl bWVudGF0aW9ucyB0aGF0IHZpb2xhdGUgMy45LjEgYnkgbm90IGxlYXZpbmcgInRoZSByZXN0DQo+ IG9mIHRoZSBlbnZlbG9wZSIgKHRoYXQgaXMsIFJGQzUzMjEuTWFpbEZyb20pIHVuY2hhbmdlZC4g IEFzIHRoYXQgY2hhbmdlDQo+IHdhcyB0cmlnZ2VyZWQgYnkgU1BGLCBpdCBzaG91bGQgYmUgdXAg dG8gU1BGIHRvIHNwZWxsIHRoZSB0ZXh0IHRoYXQNCj4gNTMyMWJpcyB3aWxsIGhvcGVmdWxseSBh ZG9wdCwgd2hlbmV2ZXIgInRoZSBjZWxlc3RpYWwgb21lbnMgYWxpZ24NCj4gY29ycmVjdGx5Ii4N Cg0KQWxsdWRpbmcgdG8gSm9obiBMZXZpbmUncyBwb3N0LCBJIGRvbid0IHRoaW5rIFNQRiBpcyBz dWZmaWNpZW50bHkgaGVhdnl3ZWlnaHQgdG8gc2F5IHRoYXQgUkZDNTMyMSAzLjkuMSBnb3QgaXQg d3JvbmcuICBTUEYgaXMgZWZmZWN0aXZlbHkgYSBsYXllciBvbiB0b3Agb2YgU01UUC4gIEVudmly b25tZW50cyB0aGF0IGRvbid0IHVzZSBTUEYgbWlnaHQgcmVseSBvbiB0aGUgb3Bwb3NpdGUgYmVo YXZpb3IuDQoNCj4gU2NvdHQgY29ycmVjdGx5IG5vdGVzIHRoYXQgUkZDIDUzMjEgZXZhZGVzIGRl ZmluaW5nIG1ldGhvZHMgdG8gdmVyaWZ5DQo+IE1haWxGcm9tLCB3aGVuIGl0IG1lbnRpb25zIFNQ RiBhbmQgcmVsYXlpbmcuICBGb3J3YXJkaW5nIChpbiB0aGUgODIxDQo+IHNlbnNlIG9mIHJlbGF5 aW5nIHdoaWxlIGNoYW5naW5nIHRoZSBlbnZlbG9wZSByZWNpcGllbnQpIGlzIG5vdCBkb25lDQo+ IHdlbGwgaW4gUkZDIDUzMjEgYmVjYXVzZSBzb21lIHNlbnRlbmNlcyB0aGVyZSBhcmUgYW1iaWd1 b3VzIChzZWUgYWxzbw0KPiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy95YW0vdHJhYy90 aWNrZXQvOSkuICBJbiBwYXJ0aWN1bGFyLCB0aGUNCj4gdGVybSAiYWxpYXMiIGRvZXNuJ3QgbG9v ayBsaWtlIGEgc3lub255bSBvZiBpbnRyYS1BRE1EIHJlZGlyZWN0aW9uLw0KPiBleHBhbnNpb24u DQoNCkkgZGlzYWdyZWUsIHRoZSBkZWZpbml0aW9uIHRoZXJlIHJlZmxlY3RzIGV4YWN0bHkgbXkg dW5kZXJzdGFuZGluZyBvZiBob3cgYWxpYXNlcyB3b3JrIGluIHRoYXQgb3IgYW55IGNvbnRleHQu ICBTZWUgYWxzbyBSRkM1NTk4LCBTZWN0aW9uIDUuMS4NCg0KPiA+IFNvIHRoZSBlbXB0eSBzdHJp bmcgU0hPVUxEIGJlIHRoZSBlbnZlbG9wZSBzZW5kZXIgdXNlZCBmb3IgZm9yd2FyZGVkDQo+ID4g bWFpbD8gIFRoYXQgZWZmZWN0aXZlbHkgZGlzYWJsZXMgU1BGLCBtYWtpbmcgZm9yd2FyZGluZyBp bnRvIGFuIGF0dGFjaw0KPiA+IHZlY3Rvci4NCj4gDQo+IFNQRiB2ZXJpZmljYXRpb24gaXMgbGlt aXRlZCB0byB0aGUgaGVsbyBpZGVudGl0eSBpbiBzdWNoIGNhc2VzLiAgSW4gdGhlDQo+IHdvcnN0 IGNhc2UgdGhhdCBzaG91bGQgZGVsaXZlciBhIG5ldXRyYWwgcmVzdWx0LCB3aGVyZWFzIGtlZXBp bmcNCj4gUkZDNTMyMS5NYWlsRnJvbSB1bmNoYW5nZWQgd291bGQgZGVzZXJ2ZSBhIGZhaWwuICBU aGUgaW1wYXNzZSB3aGVyZWJ5DQo+IG1vc3QgZG9tYWlucyBjYW5ub3QgYWZmb3JkIC1hbGwgaXMg cm9vdGVkIGluIGV4YWN0bHkgdGhpcyBwb2ludC4NCg0KVGhlcmUgYXJlIHNvbWUgU1BGIGltcGxl bWVudGF0aW9ucyB0aGF0IGRvbid0IGNoZWNrIEhFTE8sIGFuZCB0aGV5IGFyZSBjb21wbGlhbnQg d2l0aCBSRkM0NDA4Lg0KDQo+ID4gSSBjYW4ndCBlbnZpc2lvbiB0aGUgaW5mcmFzdHJ1Y3R1cmUg eW91J3JlIHRhbGtpbmcgYWJvdXQgaGVyZS4NCj4gPiBXaGF0ZXZlciBpdCBtaWdodCBiZSwgSSdt IGNvbmZpZGVudCBndWVzc2luZyBhaGVhZCBvZiB0aW1lIHRoYXQgaXQNCj4gPiB3b3VsZCBleGNl ZWQgdGhlIGNvbnN0cmFpbnRzIG9mIHRoZSBjaGFydGVyLCBidXQgSSdkIHN0aWxsIGxpa2UgdG8N Cj4gPiBoZWFyIHdoYXQgeW91IGhhdmUgaW4gbWluZC4NCj4gDQo+IEkgZG9uJ3Qga25vdyBob3cg bWFueSBNVEFzIGNoYW5nZWQgdGhlaXIgZGVmYXVsdCBmb3J3YXJkaW5nIGJlaGF2aW9yIGluDQo+ IHZpb2xhdGlvbiBvZiBTZWN0aW9uIDMuOS4xIG9mIFJGQzUzMjEgaW4gb3JkZXIgdG8gc3VwcG9y dCBTUEYuICBJcyB0aGF0DQo+IGEgd2lkZXNwcmVhZCBzdXBwb3J0PyAgSSB0aGluayBpdCBpcyBh biBlcnJvciB0aGF0IFNlY3Rpb24gMy45IGRvZXMgbm90DQo+IGNpcmN1bXNjcmliZSB0aGUgdXNl IG9mIGFsaWFzIGV4cGFuc2lvbiBydWxlcy4gIFNob3VsZCBzcGZiaXMgY29ycmVjdA0KPiB0aGF0 LCBvciBhdCBsZWFzdCBhZGQgY2xhcmlmeWluZyBsYW5ndWFnZT8NCg0KQWxpYXMgZXhwYW5zaW9u IGRvZXNuJ3QgY2hhbmdlIHRoZSBlbnZlbG9wZSBzZW5kZXIuICBXaGVuIHlvdSBzYXkgImZvcndh cmRpbmciLCB0aGF0J3Mgd2hhdCBJIHRoaW5rIHlvdSBtZWFuLiAgQW5kIEkgY2FuJ3Qgc2VlIHRo YXQgU1BGIGxheWVyZWQgb24gdG9wIG9mIFNNVFAgYW5kIGNyZWF0aW5nIHRoYXQgbmVlZCBhdXRv bWF0aWNhbGx5IG1lYW5zIFNNVFAgZ290IGl0IHdyb25nIGFuZCB0aGVyZSdzIHNvbWV0aGluZyB3 ZSBuZWVkIHRvIGZpeC4NCg0KLU1TSw0K From dotzero@gmail.com Wed Mar 14 11:34:14 2012 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 D2BAF21F8767 for ; Wed, 14 Mar 2012 11:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 J3MxjHzX6QTT for ; Wed, 14 Mar 2012 11:34:14 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id E5DB821F8766 for ; Wed, 14 Mar 2012 11:34:13 -0700 (PDT) Received: by dald2 with SMTP id d2so4420592dal.27 for ; Wed, 14 Mar 2012 11:34: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:content-transfer-encoding; bh=BtLLtNcMr8ViiExGGQtDP+46vcvq7SOrQUordxzpj4I=; b=OKjiDK4aK5/DgOg0pX+kIgN99rJEMAJb0zm0k1M2eq8q7aakY4PUs8mMLI6IumjpGB RM0+o43Hfz7g/xv+G2J+uvjfLixEatDjQM0t5bCuAuicjXeftX4r9vDVeX5Ns+XMjT2V nRw1O4WI6+9VoLEFNrw8KdwRJrXGB9J8PFK3Kph5Tr/biY7PJ2qy5b/uUgA3sI28MVU+ amoXdNvnA+OCMhKBlzyq596wh0IFRQBMD83j9fc3XKw20Q3qN0cvuwnmKCvCEqA4Seyg JDroVDcz6M4Vv+9fPUC+SLDQgYQKYdmk2BjsjT1a4FSO6bO4S8zFp8lc2hJvTxY3AQHa A6AA== MIME-Version: 1.0 Received: by 10.68.129.195 with SMTP id ny3mr4200320pbb.88.1331750053669; Wed, 14 Mar 2012 11:34:13 -0700 (PDT) Received: by 10.68.231.129 with HTTP; Wed, 14 Mar 2012 11:34:13 -0700 (PDT) In-Reply-To: <20120314035845.2234.qmail@joyce.lan> References: <6.2.5.6.2.20120313164854.0ac1f800@resistor.net> <20120314035845.2234.qmail@joyce.lan> Date: Wed, 14 Mar 2012 14:34:13 -0400 Message-ID: From: Dotzero To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org, sm+ietf@elandsys.com Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 18:34:14 -0000 On Tue, Mar 13, 2012 at 11:58 PM, John Levine wrote: >>There is an IETF meeting coming up in a few weeks. =A0Is "forwarding" a >>problem which should be on the agenda? > > NO, Capital N, Capital O. > > SPF is path authentication, it's well understood that it's not > designed to deal with forwarding. =A0People have been trying to invent > ways to shoehorn forwarded mail into SPF since long before RFC 4408, > and I think it's safe to say that nothing new in that regard has > happened since 4408. > > There may still be some people who think that all SMTP mail should > change to match what SPF does. =A0(Not Scott, certainly.) =A0They are > wrong. > > R's, > John > +1 From spf2@kitterman.com Wed Mar 14 11:38:50 2012 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 96ECE21F8573 for ; Wed, 14 Mar 2012 11:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 iVkfCMpVsSE6 for ; Wed, 14 Mar 2012 11:38:50 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EB6C321F8540 for ; Wed, 14 Mar 2012 11:38:49 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3062120E40D0; Wed, 14 Mar 2012 14:38:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331750329; bh=4NX/mP9QNLyYE6HP4dLnP7R08Y37rxcuV8UowH1TGaA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=eYjOaxcIwS8ewup8YEtI/zIyLeJccfsG8qpPCXkNEch9fFuKsf3ttGOpJFZTtN5t1 53hXpRr5j5BmQ09RIPQ869+6hWk9KJq65pLTPqmLKz1b981tXNfl6XebpnP2j2ssBz npo1i6H54qDnuKulvPLC+kw/61MlTY6SKN7ZgmB4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 135C720E40A3; Wed, 14 Mar 2012 14:38:48 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 14 Mar 2012 14:38:48 -0400 Message-ID: <1582246.ifGuAyB4YY@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120314103632.0a451d08@elandnews.com> References: <6.2.5.6.2.20120314103632.0a451d08@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Draft agenda for IETF83 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 Mar 2012 18:38:50 -0000 On Wednesday, March 14, 2012 10:40:38 AM SM wrote: ... > DNS amplification attacks 20 minutes ... I think this would be a waste of the group's time. Scott K From sm@elandsys.com Wed Mar 14 12:05:39 2012 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 470DA21F8821 for ; Wed, 14 Mar 2012 12:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 PlKZrp-2wNHZ for ; Wed, 14 Mar 2012 12:05:38 -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 6499C21F882F for ; Wed, 14 Mar 2012 12:05:38 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.80]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2EJ5PMX003700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Mar 2012 12:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331751936; i=@elandsys.com; bh=t+Yh9qFOPmCNqXLk76gdKDkj2TYrql8hSoOkTFenN+w=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=wBoKvUVBqrt4vOgPtoYwaXPzqCYJjBjzgzoAB+DI/bBsqpmE1fQugtlQUD5nD/btY HiscinwFqN1CgsvAIy8b3TPvPkO9GC8vRZOD4/QNNjKw3xM9tjPgFSm5yg7wYQtXfa S8afsY9yDAedjlRLc6EZ5bGZy5O3Wk3MIintoKMk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331751936; i=@elandsys.com; bh=t+Yh9qFOPmCNqXLk76gdKDkj2TYrql8hSoOkTFenN+w=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=FNoL50+DLeGuUxtdTWU2TGCecXdlU89gHyZF/eqDML8IRHd4YVCfS7EVIvzHaZamI ENjSfO0u+d/vLWgahnkiSMHxTU8RZDy1FFTV5x9kljrHF3ymbrMrOJRIfjkyxDKyBf ihdoyB2wjSnDEofiE962daDjzfcH0zoJNVLkgpo8= Message-Id: <6.2.5.6.2.20120314113845.09b3b920@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Mar 2012 11:52:58 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <2cdc6262-63b4-4743-affb-4d2352fdd298@email.android.com> References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <6.2.5.6.2.20120312111654.0adb2610@elandnews.com> <4916132.0TxoWXRv1F@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280866B5@exch-mbx901.corp.cloudmark.com> <4F5F3AF5.4000406@tana.it> <90491c3c-748f-49d9-9f64-d96f6d2edb69@email.android.com> <2cdc6262-63b4-4743-affb-4d2352fdd298@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 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 Mar 2012 19:05:39 -0000 This is a summary of the comments on Issue #10. As usual, if I misinterpreted or misunderstood your comments, please let me know. Issue #10 was opened based on the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg00330.html Scott Kitterman believes that Authentication-Results is technically suitable to replace Received-SPF but he does not think that it can be done now [1]. Murray Kucherawy mentioned that it clear there are SPF verifiers that add Received-SPF, but it's not clear that anything other than humans actually consumes it. He mentioned that there are however implementations of RFC5451 (at least one) that do parse them inbound in order to conform to the "remove your own on inbound" requirement that specification imposes [2]. He concluded that it is safe and within the charter to switch. Scott Kitterman pointed out that there is an implementation that consumes the Received-SPF header and mentioned that the feature is widely used [3]. Barry Leiba, as a participant, pointed out that deprecating "Received-SPF" means saying that it's in current use, but new implementations are advised not to generate it (basically, SHOULD NOT). For something that has enough usage that we can't remove it (yes, the charter goes against that), noting that it's on the way out and new implementations shouldn't generate it seems to be the right way to go [4]. Alessandro Vesely suggested a MAY, noting that the evolution is toward the more homogeneous A-R, but allowing plenty of time to migrate [5]. Scott Kitterman mentioned that since automatic processing generally takes place within an ADMD, switching isn't something that has global interoperability impacts [6]. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00861.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00862.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00863.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00872.html 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg00879.html 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg00880.html From johnl@iecc.com Wed Mar 14 12:28:28 2012 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 27A4C21F86F5 for ; Wed, 14 Mar 2012 12:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.313 X-Spam-Level: X-Spam-Status: No, score=-110.313 tagged_above=-999 required=5 tests=[AWL=0.886, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 7DqHc0Y9xPio for ; Wed, 14 Mar 2012 12:28:27 -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 0D65D21F87FC for ; Wed, 14 Mar 2012 12:28:26 -0700 (PDT) Received: (qmail 80431 invoked from network); 14 Mar 2012 19:28:24 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Mar 2012 19:28:24 -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:vbr-info; s=4f60f158.xn--yuvv84g.k1203; i=johnl@user.iecc.com; bh=+Sw/fnoeHkfGa+6otOF/UzD/M3BFA+fZ3O6XUHkQRqc=; b=lBXWwErKcWZrOhR8b08DW3B1yZPJGkXGF9u0WHr8Qwz+YwoeOlMEtRhskb6R0zZOZPOpzoEvRU3UGnZY3GK7S2T9CzmJWsIY5/ulljcSeaEGPfhznXUYcQmnRK5ilGPWqy33Vr0Iuz4v9uFUZotaoX1d8wrdo28WOdbH0BKuSjs= 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:vbr-info; s=4f60f158.xn--yuvv84g.k1203; olt=johnl@user.iecc.com; bh=+Sw/fnoeHkfGa+6otOF/UzD/M3BFA+fZ3O6XUHkQRqc=; b=hVonnGVZhNnoG0UPAWRU5dnXFZ6KeqnLNQmmhKPQQGFy4la4kWlgMQSe6TUGmbPdlmnWg1I0QHXmBKMSeE8oXbkWIAwd0Wcz25uZMvxLjevrbEeDejGfuE0/a6JBgRUu/rV++vD8bW0ZyEZ0XgbULX7y07ezjYQtPK8KYbb/3iw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Mar 2012 19:28:02 -0000 Message-ID: <20120314192802.7410.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E003928089EC3@exch-mbx901.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: msk@cloudmark.com Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 19:28:28 -0000 >I don't advocate adding SRS as any normative part of SPFbis. I would, however, >suggest in some informative section of the document that the WG consider >including a reference to it as we describe the known limitations of SPF, >assuming there's a stable definition for SRS somewhere out there we could use. There isn't really anything to standardize in SRS. It's basically a single user recipient of VERP, encoding stuff in the bounce address to provide hints about what bounced. Like VERP and BATV, the limit on mailbox length gives it has fairly severe interop problems if you want it work reliably as opposed to being a heuristic. The only way I can think of to avoid that problem is for forwarding systems to keep a database of bounce addresses from forwarded mail and use a database key rather than the address, but I don't know anyone who does that. (Nor would I suggest anyone use it just to work around SPF.) >I may need coffee to jar my memory, but I don't think I've seen anything in our >deliberations so far that warrants more discussion of the forwarding problem >than we already have in RFC4408. Yes. > We should definitely review it again though as we move forward. No. It's a fact, not a problem. R's, John From msk@cloudmark.com Wed Mar 14 12:41:48 2012 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 E249621F8690 for ; Wed, 14 Mar 2012 12:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 Q205s+vAGct4 for ; Wed, 14 Mar 2012 12:41:48 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 56E2921F8633 for ; Wed, 14 Mar 2012 12:41:48 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 12:41:47 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities Thread-Index: AQHNAhijr4WG/AzzUEqUMIXDGGKPkJZqMJVA Date: Wed, 14 Mar 2012 19:41:47 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392808B2A6@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E003928089EC3@exch-mbx901.corp.cloudmark.com> <20120314192802.7410.qmail@joyce.lan> In-Reply-To: <20120314192802.7410.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 19:41:49 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of John Levine > Sent: Wednesday, March 14, 2012 12:28 PM > To: spfbis@ietf.org > Cc: Murray S. Kucherawy > Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident= ities >=20 > > We should definitely review it again though as we move forward. >=20 > No. It's a fact, not a problem. I mean we should review the text we're providing as information to make sur= e it's right, not we should try to fix forwarding vis a vis SPF. -MSK From SRS0=hXLc1=BV==stuart@gathman.org Wed Mar 14 14:33:34 2012 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 36A1211E8081 for ; Wed, 14 Mar 2012 14:33:34 -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 ucTdq61daNUz for ; Wed, 14 Mar 2012 14:33:33 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 368E911E807F for ; Wed, 14 Mar 2012 14:33:33 -0700 (PDT) Received: from sdg.bmsi.com (sdg.bmsi.com [192.168.9.34] (may be forged)) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q2ELWbPD017256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Mar 2012 17:32:38 -0400 Message-ID: <4F610EA9.7040402@gathman.org> Date: Wed, 14 Mar 2012 17:33:29 -0400 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <6.2.5.6.2.20120313012810.0a31fe60@elandnews.com> <2372065.C4Li7o8hMb@scott-latitude-e6320> <6.2.5.6.2.20120313164854.0ac1f800@resistor.net> <9452079D1A51524AA5749AD23E003928089EC3@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928089EC3@exch-mbx901.corp.cloudmark.com> Content-Type: multipart/alternative; boundary="------------030502000907020001060400" Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 21:33:59 -0000 This is a multi-part message in MIME format. --------------030502000907020001060400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Long ago, Nostradamus foresaw that on 03/14/2012 01:41 PM, Murray S. Kucherawy would write: > I don't advocate adding SRS as any normative part of SPFbis. I would, > however, suggest in some informative section of the document that the > WG consider including a reference to it as we describe the known > limitations of SPF, assuming there's a stable definition for SRS > somewhere out there we could use. I also think SPF stands just fine on > its own without SRS or a similar mechanism, so I'd be just fine > leaving it out altogether. I may need coffee to jar my memory, but I > don't think I've seen anything in our deliberations so far that > warrants more discussion of the forwarding problem than we already > have in RFC4408. We should definitely review it again though as we > move forward. The RFC should address one of the most common receiver mistakes: http://www.openspf.org/FAQ/Common_receiver_mistakes Checking SPF On Forwarded Mail Mail forwarding is set up by the receiver and so for forwarded mail, the border mail server (at which SPF should be checked) is the forwarder's mail server. If you check SPF on your mail server it is coming from your forwarder and not from a mail server authorized by the sending domain. Technically this is similar to checking SPF against mail relayed from your secondary MX like discussed in the previous item. Authorized forwarders should be whitelisted against SPF checks to avoid this problem. In particular, if a receiver is unable to treat an authorized forwarder as an internal MX, and the forwarder does not rewrite MAIL FROM (via SRS or similar scheme), then you MUST NOT treat any alleged SPF result as a real SPF result. It is only a guess, and not a very good one at that. Nevertheless, way too many shops do this. --------------030502000907020001060400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Long ago, Nostradamus foresaw that on 03/14/2012 01:41 PM, Murray S. Kucherawy would write:
I don't advocate adding SRS as any normative part of SPFbis. I would, however, suggest in some informative section of the document that the WG consider including a reference to it as we describe the known limitations of SPF, assuming there's a stable definition for SRS somewhere out there we could use. I also think SPF stands just fine on its own without SRS or a similar mechanism, so I'd be just fine leaving it out altogether. I may need coffee to jar my memory, but I don't think I've seen anything in our deliberations so far that warrants more discussion of the forwarding problem than we already have in RFC4408. We should definitely review it again though as we move forward.

The RFC should address one of the most common receiver mistakes: http://www.openspf.org/FAQ/Common_receiver_mistakes

Checking SPF On Forwarded Mail

Mail forwarding is set up by the receiver and so for forwarded mail, the border mail server (at which SPF should be checked) is the forwarder's mail server. If you check SPF on your mail server it is coming from your forwarder and not from a mail server authorized by the sending domain. Technically this is similar to checking SPF against mail relayed from your secondary MX like discussed in the previous item. Authorized forwarders should be whitelisted against SPF checks to avoid this problem.

In particular, if a receiver is unable to treat an authorized forwarder as an internal MX, and the forwarder does not rewrite MAIL FROM (via SRS or similar scheme), then you MUST NOT treat any alleged SPF result as a real SPF result.  It is only a guess, and not a very good one at that.  Nevertheless, way too many shops do this.

--------------030502000907020001060400-- From spf2@kitterman.com Wed Mar 14 14:38:15 2012 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 8709E11E808A for ; Wed, 14 Mar 2012 14:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 7Vil0RXWzb7Q for ; Wed, 14 Mar 2012 14:38:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B637811E8089 for ; Wed, 14 Mar 2012 14:38:14 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E9F0420E40D0; Wed, 14 Mar 2012 17:38:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331761094; bh=5fGSwWFICKd5qKxzFXPjU2ySXK2VLRyejCwSWdurJtw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=cwro8K5YN5/FJ/4NYdiD46NAesAlsN9XRJ+GA4+5nPkz8/Ik0G410tHmTBsbyKd9g qLP7jZWRHMU8lRK8N0clafquL5a/4xRVGgKqQDJthNPsYufqNy8f5q5bmFvRfYJe4w RP39U+OEKimx+udVCrnbUVsCrr6vNyJS19xbfRRo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id CB81320E40A3; Wed, 14 Mar 2012 17:38:13 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 14 Mar 2012 17:38:13 -0400 Message-ID: <6694737.57JkfGf6xl@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F610EA9.7040402@gathman.org> References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <9452079D1A51524AA5749AD23E003928089EC3@exch-mbx901.corp.cloudmark.com> <4F610EA9.7040402@gathman.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 21:38:15 -0000 On Wednesday, March 14, 2012 05:33:29 PM Stuart D Gathman wrote: > Long ago, Nostradamus foresaw that on 03/14/2012 01:41 PM, Murray S. > > Kucherawy would write: > > I don't advocate adding SRS as any normative part of SPFbis. I would, > > however, suggest in some informative section of the document that the > > WG consider including a reference to it as we describe the known > > limitations of SPF, assuming there's a stable definition for SRS > > somewhere out there we could use. I also think SPF stands just fine on > > its own without SRS or a similar mechanism, so I'd be just fine > > leaving it out altogether. I may need coffee to jar my memory, but I > > don't think I've seen anything in our deliberations so far that > > warrants more discussion of the forwarding problem than we already > > have in RFC4408. We should definitely review it again though as we > > move forward. > > The RFC should address one of the most common receiver mistakes: > http://www.openspf.org/FAQ/Common_receiver_mistakes > > > Checking SPF On Forwarded Mail > > Mail forwarding is set up by the receiver and so for forwarded mail, > the border mail server (at which SPF should be checked) is the > forwarder's mail server. If you check SPF on your mail server it is > coming from your forwarder and not from a mail server authorized by > the sending domain. Technically this is similar to checking SPF > against mail relayed from your secondary MX like discussed in the > previous item. Authorized forwarders should be whitelisted against > SPF checks to avoid this problem. > > In particular, if a receiver is unable to treat an authorized forwarder > as an internal MX, and the forwarder does not rewrite MAIL FROM (via SRS > or similar scheme), then you MUST NOT treat any alleged SPF result as a > real SPF result. It is only a guess, and not a very good one at that. > Nevertheless, way too many shops do this. I think that RFC 4408 9.3.3.1 describes this, but it could be better written. Scott K From dotis@mail-abuse.org Wed Mar 14 15:07:40 2012 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 05C0721F8866 for ; Wed, 14 Mar 2012 15:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=0.198, 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 jKdHMHIONuV8 for ; Wed, 14 Mar 2012 15:07:39 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7D88321F8863 for ; Wed, 14 Mar 2012 15:07:39 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 43BAC174052F for ; Wed, 14 Mar 2012 22:07:35 +0000 (UTC) Message-ID: <4F6116A6.2090307@mail-abuse.org> Date: Wed, 14 Mar 2012 15:07:34 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <22187973.cpWMZthzO6@scott-latitude-e6320> <4F579E33.4000102@tana.it> <5370057.tXlR2v9Toq@scott-latitude-e6320> In-Reply-To: <5370057.tXlR2v9Toq@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits 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 Mar 2012 22:07:40 -0000 Dear SPFbis wg, Conversations related to spf/txt records and general assumptions about potential DDoS concerns have been reviewed. It seems limits for name and no data errors represent a compatible solution for resolving concerns related with the distributed nature of email, but it is not clear what conclusions have been reached. Email remains heavily abused. The initial impetus behind SPF was to deal with problems created when recipient validation followed message acceptance. Since then such acceptance has become an unsustainable practice with increased network consumption from additional abuse that this invites, even when invalid recipients are silently dropped. It would also be illogical to assume MTAs would be primary targets of abuse being the vehicle of distribution. SPF leverages resources of the recipient to instantiate multiples of DNS transactions that might be measured in the hundreds. The actual number depends upon whether spf/txt are done in parallel and whether EHLO and MFROM identities are also checked. It should also be noted negative caching compliance is one of DNS's shortcomings. A limit of 10 no data and name errors should not impact legitimate SPF records. Any problems related to NS record referrals can be addressed with changes to the DNS protocol. As such, SPF is different. Those that could be affected by SPF may not offer any spf/txt resource records and universally use DNS that imposes strict limits on NS referrals. It seems more productive to wait for proposed text to assess the situation, rather than arguing specific points in isolation. Regards, Douglas Otis From SRS0=hXLc1=BV==stuart@gathman.org Wed Mar 14 16:41:25 2012 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 63B4F11E8075 for ; Wed, 14 Mar 2012 16:41: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=[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 brlFs0jaRtMP for ; Wed, 14 Mar 2012 16:41:24 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id B1F2321F876C for ; Wed, 14 Mar 2012 16:41:24 -0700 (PDT) Received: from fairfax.gathman.org (gathman [192.168.10.1]) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q2ENeTV0019215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Mar 2012 19:40:30 -0400 Date: Wed, 14 Mar 2012 19:41:20 -0400 (EDT) From: "Stuart D. Gathman" To: Scott Kitterman In-Reply-To: <6694737.57JkfGf6xl@scott-latitude-e6320> Message-ID: References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <9452079D1A51524AA5749AD23E003928089EC3@exch-mbx901.corp.cloudmark.com> <4F610EA9.7040402@gathman.org> <6694737.57JkfGf6xl@scott-latitude-e6320> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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 Mar 2012 23:41:25 -0000 On Wed, 14 Mar 2012, Scott Kitterman wrote: >> In particular, if a receiver is unable to treat an authorized forwarder >> as an internal MX, and the forwarder does not rewrite MAIL FROM (via SRS >> or similar scheme), then you MUST NOT treat any alleged SPF result as a >> real SPF result. It is only a guess, and not a very good one at that. >> Nevertheless, way too many shops do this. > > I think that RFC 4408 9.3.3.1 describes this, but it could be better written. It describes several options, but the MUST NOT for the receiver end is missing. There is a strong implication that if you can't handle your own forwarding, then SPF results are invalid. But that doesn't seem to be enough for many email operators. I also don't like the suggestion that senders should try to work around forwarding controlled by the receiver. You might do that to get mail through to a particular recipient in a pinch, but the recipient is wrong, not the sender. -- Stuart D. Gathman "Confutatis maledictis, flamis acribus addictis" - background song for a Microsoft sponsored "Where do you want to go from here?" commercial. From johnl@iecc.com Wed Mar 14 17:15:18 2012 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 2372211E809A for ; Wed, 14 Mar 2012 17:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.32 X-Spam-Level: X-Spam-Status: No, score=-110.32 tagged_above=-999 required=5 tests=[AWL=0.879, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 u8uUEL5zDHBI for ; Wed, 14 Mar 2012 17:15: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 490F111E8075 for ; Wed, 14 Mar 2012 17:15:17 -0700 (PDT) Received: (qmail 66913 invoked from network); 15 Mar 2012 00:15:16 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Mar 2012 00:15: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:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f613494.xn--9vv.k1203; i=johnl@user.iecc.com; bh=HC5f8mW2EAPicjpRosVlJIkD+9kLz9EoXErh50SdbmY=; b=dak8zQTYRdj/sjXxbJ/RXtE7tWaYf8Cyfe4cdL6gj1hTG2NkJ/kMVfcoJT/a2pqhdoc5uaFa5HC464QxUyuhvTbRwD2VJPnTqes6kxA0sK+PWwEvaCbTS9OIPypcshmigFSaaU31nRYr/A58vhNkLT7kM9EZx97xKRnWFW50Ve0= 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:vbr-info; s=4f613494.xn--9vv.k1203; olt=johnl@user.iecc.com; bh=HC5f8mW2EAPicjpRosVlJIkD+9kLz9EoXErh50SdbmY=; b=r6kt6AFXWUIfgSNNim4Kbh0TwctmEPnGMgLYCcR3uELEZm6pDENwR3PNP3XMLmRsKaQBk/TTH8XPGym41sy3lklJrdNOkF8bJMG1r/P48cfT0q2rQFG4higgbkE84EIPmNJO4lbkfFN4do8TvOKTvxUdgLxBDSgJZmJx8pc+jX4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 15 Mar 2012 00:14:53 -0000 Message-ID: <20120315001453.10962.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1582246.ifGuAyB4YY@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] Draft agenda for IETF83 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, 15 Mar 2012 00:15:18 -0000 >> DNS amplification attacks 20 minutes >... > >I think this would be a waste of the group's time. Agreed. I'm only aware of one person who thinks that this is an important issue, and although he is very persistent, after years of effort he has attracted no support for his position. R's, John From sm@elandsys.com Wed Mar 14 22:49:24 2012 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 8C24B21F8705 for ; Wed, 14 Mar 2012 22:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 bThTEMqPwVD6 for ; Wed, 14 Mar 2012 22:49:22 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D9521F8703 for ; Wed, 14 Mar 2012 22:49:22 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.241]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2F5n85N001859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Mar 2012 22:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331790560; i=@elandsys.com; bh=Epmj1WvN2rt2y2gPIvXfEzcWdKLpzZLXZNZJ08m3DCg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=L6TheN110v6ypiQKpJzxVKVuMf9A4NIx8VUbxYEoC/qONmLJ/K8Gx7j5XuVHbbE7r fc+9VI9PddfSWirPcwpM3H/4tCuJrq2hodZAjsuOzUChHEHHI7RrtyOkIDDfm2smHN f282DwC5S5BM+757zx4stDv+Tmk2+LoYFpcKg5KQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331790560; i=@elandsys.com; bh=Epmj1WvN2rt2y2gPIvXfEzcWdKLpzZLXZNZJ08m3DCg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=PfjVRG2EkUYCovh8KIzMKldIqHMcIe081BHDjtWKqroEn6O+8DSvN7+t5E2Wck7QQ b1daQYJQev4nitqy0cGtgyDSMsY91aPsX0g2VF/aY08wxmnbyOLy+4WHvK6g0U6BSC ABcK4b++Fzf3u81BC5RErSw4W2L6EFOKEoJOS5Lo= Message-Id: <6.2.5.6.2.20120314220625.0a9c0718@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Mar 2012 22:46:23 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <9452079D1A51524AA5749AD23E0039280868D6@exch-mbx901.corp.cl oudmark.com> References: <20120305175124.GR76465@crankycanuck.ca> <20120312193840.GC12833@mail.yitter.info> <9452079D1A51524AA5749AD23E0039280868D6@exch-mbx901.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Request adoption of draft-kucherawy-spfbis-experiment 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, 15 Mar 2012 05:49:24 -0000 At 13:23 12-03-2012, Murray S. Kucherawy wrote: >And so in terms of getting work done on progressing it while we wait >for the -00 embargo to lift, here are the work items as I see them: There hasn't been any alternative proposal for the "conclusion" draft. The following people committed to work on draft-kucherawy-spfbis-experiment ( http://tools.ietf.org/html/draft-kucherawy-spfbis-experiment-03 ): Commerco WebMaster Alessandro Vesely Paul Midgen John Levine Dave Crocker John Leslie Dotzero >5) What would we like to see in the Conclusions section based on the >data we've collected? > >I think we could start on (5) at the same time as the others because >the surveys running are very probably only going to reaffirm what >earlier surveys suggested. My intent is to have all the points in >that section be of the form "Based on X, we conclude Y, because Z.", >where X appears in the data sections above that in the document, and >Z might include references to other materials to support the Ys. The chairs already mentioned that it is not a problem if some work happened on this draft before Paris. There hasn't been any reply to the above question. What would the people mentioned above and other WG participants like to see in the Conclusions section? Regards, S. Moonesamy From pgladstone@cisco.com Thu Mar 15 06:34:06 2012 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 E973421F858F for ; Thu, 15 Mar 2012 06:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.689 X-Spam-Level: X-Spam-Status: No, score=-7.689 tagged_above=-999 required=5 tests=[AWL=2.309, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] 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 iFnfjeaDG-3m for ; Thu, 15 Mar 2012 06:34:06 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1748321F8585 for ; Thu, 15 Mar 2012 06:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=4619; q=dns/txt; s=iport; t=1331818446; x=1333028046; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=GCIHqgYkAyuvZ8nD658Zzg2aACwV8v7LDf699LtfZsA=; b=VRRVC0cMq3H+jAmlnbEdpxWEuSlPIpb4CzJesAborbyu46Fnj5u9C/Tm mKj2QyehvU13ki7ivkBml33TUtf8bjoucdMqtKGGMKa0QTMgQPUvOLmlU wAn2RplfbkyQ9/0jXu0c/ggn1eZECzYXwPIXLdM5WN1mOL28AVxb77+aK Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKXvYU+rRDoG/2dsb2JhbABAA4U8sGmBB4IJAQEBBBIBEGQCCwQUCQwVAgIPAgo8EwYCAQEeh2cBmyyNBJIiBIo9gxgHghGBFgSVYYVsiFOBaIMCgUA X-IronPort-AV: E=Sophos;i="4.73,591,1325462400"; d="scan'208,217";a="36258484" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 15 Mar 2012 13:34:05 +0000 Received: from [161.44.106.143] (dhcp-161-44-106-143.cisco.com [161.44.106.143]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2FDY59A012866 for ; Thu, 15 Mar 2012 13:34:05 GMT Message-ID: <4F61EFCC.306@cisco.com> Date: Thu, 15 Mar 2012 09:34:04 -0400 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <9452079D1A51524AA5749AD23E003928089EC3@exch-mbx901.corp.cloudmark.com> <4F610EA9.7040402@gathman.org> <6694737.57JkfGf6xl@scott-latitude-e6320> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050102060003010604030307" Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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, 15 Mar 2012 13:34:07 -0000 This is a multi-part message in MIME format. --------------050102060003010604030307 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 3/14/2012 7:41 PM, Stuart D. Gathman wrote: >> I think that RFC 4408 9.3.3.1 describes this, but it could be better=20 >> written. > > > It describes several options, but the MUST NOT for the receiver end is = > missing. > There is a strong implication that if you can't handle your own=20 > forwarding, > then SPF results are invalid. But that doesn't seem to be enough for > many email operators. > > I also don't like the suggestion that senders should try to work around= > forwarding controlled by the receiver. You might do that to get mail=20 > through > to a particular recipient in a pinch, but the recipient is wrong, not > the sender. The trouble (in my view) is that users set up forwarding at alumni=20 associations, professional associations etc. They do not control=20 anything about these systems except the forwarding tables. The final destination of the email is some other mail server (gmail,=20 hotmail, aol etc). The users do not control anything about those systems = either except for their own email account. What *exactly* is being suggested? That the recipient go to gmail and=20 say 'please whitelist alumni.someuniversity.edu.somecountry for spf'?=20 This doesn't seem workable to me. It also doesn't seem workable to have=20 per-user SPF whitelisting rules on big mail receivers -- it would=20 certainly make handling multi-recipient messages rather complex unless=20 they all had the same set of SPF preferences. This problem is, after all, what SRS was designed to solve. Philip --=20 Philip Gladstone Distinguished Engineer Product Development pgladstone@cisco.com Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Google: +1 978 800 1010 Ham radio: N1DQ --------------050102060003010604030307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 3/14/2012 7:41 PM, Stuart D. Gathman wrote:
I think that RFC 4408 9.3.3.1 describes this, but it could be better written.


It describes several options, but the MUST NOT for the receiver end is missing.
There is a strong implication that if you can't handle your own forwarding,
then SPF results are invalid.  But that doesn't seem to be enough for
many email operators.

I also don't like the suggestion that senders should try to work around
forwarding controlled by the receiver.  You might do that to get mail through
to a particular recipient in a pinch, but the recipient is wrong, not
the sender.

The trouble (in my view) is that users set up forwarding at alumni associations, professional associations etc. They do not control anything about these systems except the forwarding tables.

The final destination of the email is some other mail server (gmail, hotmail, aol etc). The users do not control anything about those systems either except for their own email account.

What *exactly* is being suggested? That the recipient go to gmail and say 'please whitelist alumni.someuniversity.edu.somecountry for spf'? This doesn't seem workable to me. It also doesn't seem workable to have per-user SPF whitelisting rules on big mail receivers -- it would certainly make handling multi-recipient messages rather complex unless they all had the same set of SPF preferences.

This problem is, after all, what SRS was designed to solve.

Philip

-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ
--------------050102060003010604030307-- From pgladstone@cisco.com Thu Mar 15 09:18:28 2012 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 D745F21F879A for ; Thu, 15 Mar 2012 09:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.882 X-Spam-Level: X-Spam-Status: No, score=-7.882 tagged_above=-999 required=5 tests=[AWL=2.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] 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 VSwlXPZ8725j for ; Thu, 15 Mar 2012 09:18:28 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BF7DD21F8780 for ; Thu, 15 Mar 2012 09:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8966; q=dns/txt; s=iport; t=1331828307; x=1333037907; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=076N4JDXQimcTOBm2DFDvlzH07YLP63jiHZuNbpE70I=; b=F98R2+ntkPxiu5Dh07AtiU0SR1FlcLxRoFvaG+hbGO49LuEHLAiGvNNH j8pICgmqfjFAlZhGjga2so4uQTx4k1V7TRb4CI2GCyxC7NU93tkbK51jg H4l5ZT0AzhjjybTRVY+luMNr7le58tNHilRGI8ko2ct9hL+KSDXT5HhgO 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJoVYk+tJV2Z/2dsb2JhbABAA4U8sGuBB4IJAQEBBBIBEEkKAg8CCxgJFgsCAgkDAgECAQk8EwYCAQEeh2iafY0Ekg4Eij2DH4IRgRYElWGFbIhTgWiDAoE6BhE X-IronPort-AV: E=Sophos;i="4.73,591,1325462400"; d="scan'208,217";a="63735019" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 15 Mar 2012 16:18:27 +0000 Received: from [161.44.112.17] ([161.44.112.17]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2FGIQDs015585 for ; Thu, 15 Mar 2012 16:18:27 GMT Message-ID: <4F621651.2020000@cisco.com> Date: Thu, 15 Mar 2012 12:18:25 -0400 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <6.2.5.6.2.20120313221606.0aeaadf0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120313221606.0aeaadf0@elandnews.com> Content-Type: multipart/alternative; boundary="------------040108010501010405080300" Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for 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: Thu, 15 Mar 2012 16:18:29 -0000 This is a multi-part message in MIME format. --------------040108010501010405080300 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/14/2012 1:17 AM, S Moonesamy wrote: > At 17:53 17-02-2012, spfbis issue tracker wrote: >> #14: RFC 4408: local-part macro prep for deprecation >> >> Message from Doug Otis on 17 Feb 2012: >> >> Use of local-part macros in SPF record sets necessitates repeating all >> invoked DNS transactions. DNS caching only limits DNS overhead when no >> local-part macros are used within SPF record sets. It is not >> uncommon for >> the use of random local-part names in messages to be sent by >> malefactors. >> Such use significantly impacts the utility of SPF without burdening the >> authoritative servers employed by malefactors. Not only will >> local-part >> macros increase the gain of a reflected attack, it also prevents >> resolving >> addresses of a set of servers for a specific domain. >> Permitting local-part assessments will return results based upon entire >> email addresses and not just the email-address domain. It is common to >> use SPF to resolve the outbound addresses used by a domain to check >> reputation listings against these addresses. This use assumes a >> specific >> domain has not defined local-part macros in their record set or that it >> defaults to "postmaster". >> >> SPF local-part macros should not be used as a method to vet valid >> local- >> part names, as this would permit the use of high speed dictionary >> attacks >> to discover which are valid. A domain better protects >> confidentiality of >> valid local-parts by postponing acceptance or refusal to the Data >> command. >> A reasonable practice for recipients to use to ensure effective caching >> and to retain the desired utility is to supplant any local-part with >> that >> of "postmaster". Otherwise, when SPF processing follows other types of >> vetting, expansion of the local-part would leak its status via DNS >> requests. I don't understand this paragraph. The local part macro is used to validate the *sender* of the email. This cannot be done by postponing acceptance or refusal to the Data command. I suspect that there is some confusion between sender local part and recipient local-part. >> >> Add: >> >> A method for mitigating a reduction in utility or risks associated with >> local-part macros would be to replace any local-part with that of >> "postmaster". >> This would break backward compatibility. There is no reason that the string "postmaster" would pass validation. Note that an MTA may serve several domains, and it may arrange that all outgoing mail from postmaster comes from a specific domain. In this case, if it was doing local-part verification, then the use of postmaster could easily cause SPF failures. In conjunction with issue #12 and forwarders that do not do SRS, the forwarder will be sending mail *from* the original local-part, but from the *wrong* MTA. At least checking the local part allows this to be validated. [I could see systems which tried to distinguish between valid forwarders and spammers by using a set of heuristics based on the local-part and the timing of SPF checks] In other words, I do not support the deprecation of the local-part macro. Philip -- Philip Gladstone Distinguished Engineer Product Development pgladstone@cisco.com Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Google: +1 978 800 1010 Ham radio: N1DQ -- Philip Gladstone Distinguished Engineer Product Development pgladstone@cisco.com Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Google: +1 978 800 1010 Ham radio: N1DQ --------------040108010501010405080300 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 3/14/2012 1:17 AM, S Moonesamy wrote:
At 17:53 17-02-2012, spfbis issue tracker wrote:
#14: RFC 4408: local-part macro prep for deprecation

 Message from Doug Otis on 17 Feb 2012:

 Use of local-part macros in SPF record sets necessitates repeating all
 invoked DNS transactions.  DNS caching only limits DNS overhead when no
 local-part macros are used within SPF record sets.  It is not uncommon for
 the use of random local-part names in messages to be sent by malefactors.
 Such use significantly impacts the utility of SPF without burdening the
 authoritative servers employed by malefactors.  Not only will local-part
 macros increase the gain of a reflected attack, it also prevents resolving
 addresses of a set of servers for a specific domain.
 Permitting local-part assessments will return results based upon entire
 email addresses and not just the email-address domain.  It is common to
 use SPF to resolve the outbound addresses used by a domain to check
 reputation listings against these addresses.  This use assumes a specific
 domain has not defined local-part macros in their record set or that it
 defaults to "postmaster".

 SPF local-part macros should not be used as a method to vet valid local-
 part names, as this would permit the use of high speed dictionary attacks
 to discover which are valid.  A domain better protects confidentiality of
 valid local-parts by postponing acceptance or refusal to the Data command.
 A reasonable practice for recipients to use to ensure effective caching
 and to retain the desired utility is to supplant any local-part with that
 of "postmaster".  Otherwise, when SPF processing follows other types of
 vetting, expansion of the local-part would leak its status via DNS
 requests.
I don't understand this paragraph. The local part macro is used to validate the *sender* of the email. This cannot be done by postponing acceptance or refusal to the Data command. I suspect that there is some confusion between sender local part and recipient local-part.

 Add:

 A method for mitigating a reduction in utility or risks associated with
 local-part macros would be to replace any local-part with that of
 "postmaster".

This would break backward compatibility. There is no reason that the string "postmaster" would pass validation. Note that an MTA may serve several domains, and it may arrange that all outgoing mail from postmaster comes from a specific domain. In this case, if it was doing local-part verification, then the use of postmaster could easily cause SPF failures.

In conjunction with issue #12 and forwarders that do not do SRS, the forwarder will be sending mail *from* the original local-part, but from the *wrong* MTA. At least checking the local part allows this to be validated. [I could see systems which tried to distinguish between valid forwarders and spammers by using a set of heuristics based on the local-part and the timing of SPF checks]

In other words, I do not support the deprecation of the local-part macro.

Philip

-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ


-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ
--------------040108010501010405080300-- From johnl@iecc.com Thu Mar 15 10:58:16 2012 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 8BC7821F86A5 for ; Thu, 15 Mar 2012 10:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.328 X-Spam-Level: X-Spam-Status: No, score=-110.328 tagged_above=-999 required=5 tests=[AWL=0.871, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 6ZSc3ereCwdw for ; Thu, 15 Mar 2012 10:58:16 -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 ACE2C21F8623 for ; Thu, 15 Mar 2012 10:58:15 -0700 (PDT) Received: (qmail 59151 invoked from network); 15 Mar 2012 17:58:14 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Mar 2012 17:58:14 -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:vbr-info; s=4f622db7.xn--yuvv84g.k1203; i=johnl@user.iecc.com; bh=C6K+J1btwBbi6qpln2gyPnrVKSmigx5SWxkGLG4DpxY=; b=ZMLixsljuOcEfx1S0HS7qv5ukPSNfi/oP1LiVCdJAh/2TX6YXM011+8D2qTT/EZ2KgfbddI9YycN3ABrWPQiPHcK1NCtz5gKycM/dATg2Jm8eyLSKW3D+BXYr3F0QjQrD0GAOTsP17z0UaFH2tJ6ysuBdaoYJBTnNJIDo9yYVus= 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:vbr-info; s=4f622db7.xn--yuvv84g.k1203; olt=johnl@user.iecc.com; bh=C6K+J1btwBbi6qpln2gyPnrVKSmigx5SWxkGLG4DpxY=; b=RfCgqmlXdZ749xfMsdZu0ntPVxM97IFnWoEhkpDZ1D+SQxZKVoDGmtcaYp/WWWKZkiLk3ciE3O4zPE3mng7Eoz/kjvyGCe1t8N0Ioo6kk33hb5FRm6C5GIEaoRGGbzufv3dtJYguWg9/BGHlHxqVZk2k0kCZz8xdRjh8e/OXh4I= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 15 Mar 2012 17:57:53 -0000 Message-ID: <20120315175753.21172.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: stuart@gathman.org Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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, 15 Mar 2012 17:58:16 -0000 >> I think that RFC 4408 9.3.3.1 describes this, but it could be better written. > >It describes several options, but the MUST NOT for the receiver end is missing. >There is a strong implication that if you can't handle your own forwarding, >then SPF results are invalid. But that doesn't seem to be enough for >many email operators. I agree with Scott, the writing could be clearer, but the general discussion in 9.3 is fine. Unless your name is Paypal, a -ALL in your SPF record will screw up a thousand innocent mail transactions for every random spoof it catches. Mail forwarding has been around almost as long as mail has, it's not broken, it's not going to change to deal with the well-known limitations of SPF, and that's not a problem. R's, John From WebMaster@Commerco.Net Thu Mar 15 12:08:37 2012 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 35C6C21E8064 for ; Thu, 15 Mar 2012 12:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.244 X-Spam-Level: X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 aCq1rtV6F8za for ; Thu, 15 Mar 2012 12:08:36 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id AFEF721E8047 for ; Thu, 15 Mar 2012 12:08:36 -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:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=aXgnNwNo4QEH+L52FUMhBpMzecJBmbfX2WU9/d+eu8YqGxemZju61eeG385xe9/Vvs0r1TOFau90cz4YtPnusLXVDV4VMyspwa0jImeGH32Gig4BwOtkWtDrB6yPd01lplWK1Trf/oCak3/c8aj9sRxvtHeFKIsXHZL3cQwd4PY= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Thu, 15 Mar 2012 19:08:35 +0000 Message-ID: <4F623E2D.3070100@Commerco.Net> Date: Thu, 15 Mar 2012 13:08:29 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120315175753.21172.qmail@joyce.lan> In-Reply-To: <20120315175753.21172.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 Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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, 15 Mar 2012 19:08:37 -0000 On 3/15/2012 11:57 AM, John Levine wrote: >>> I think that RFC 4408 9.3.3.1 describes this, but it could be better written. >> >> It describes several options, but the MUST NOT for the receiver end is missing. >> There is a strong implication that if you can't handle your own forwarding, >> then SPF results are invalid. But that doesn't seem to be enough for >> many email operators. > > I agree with Scott, the writing could be clearer, but the general discussion > in 9.3 is fine. > > Unless your name is Paypal, a -ALL in your SPF record will screw up a > thousand innocent mail transactions for every random spoof it catches. > Mail forwarding has been around almost as long as mail has, it's not > broken, it's not going to change to deal with the well-known > limitations of SPF, and that's not a problem. > > R's, > John > _______________________________________________ We are hardly PayPal, yet we have had no real issues with SPF and forwarding (using -all) over the many years it has been in use here. As to RFC 4408 9.3 it seems adequate. Alan M. From pgladstone@cisco.com Thu Mar 15 14:47:18 2012 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 1441221E8037 for ; Thu, 15 Mar 2012 14:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.895 X-Spam-Level: X-Spam-Status: No, score=-6.895 tagged_above=-999 required=5 tests=[AWL=0.803, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MANGLED_EMAIL=2.3, RCVD_IN_DNSWL_HI=-8] 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 MgxCVZWZJuNC for ; Thu, 15 Mar 2012 14:47:16 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB9621E801E for ; Thu, 15 Mar 2012 14:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14602; q=dns/txt; s=iport; t=1331848036; x=1333057636; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=RUDU7Al79T3KRKAFvor8nk2zth2LmusZixcmhjbEBhE=; b=BjTXz/7u1CQOURrBnbtOmdQaDZ3Jh4x8j5oxMnIqFIzZfFFvbrI5p4mI KcfeKQfoH4OmZPQQV5sm0uvGo5eJhjedLLSZ4AcBJlDOC5tYqYBOe09df pRzWC5fAkmf1ycSyXSP01UTgPranftqWodmmTMypFzO9+5T30f/75KAKz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8HAItiYk+tJXHA/2dsb2JhbABAA4U7nyWRSYEHggkBAQEEEgEQRAcKDwIJAhgJFgsCAgkDAgECAQkqEhMGAgEBHodoC5ptjQSSAQSKPYMfghGBFgSVYYVsiFOBaIMCgUA X-IronPort-AV: E=Sophos;i="4.73,592,1325462400"; d="scan'208,217";a="63833133" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 15 Mar 2012 21:47:15 +0000 Received: from [161.44.106.214] (dhcp-161-44-106-214.cisco.com [161.44.106.214]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2FLlFso007671 for ; Thu, 15 Mar 2012 21:47:15 GMT Message-ID: <4F626362.7060405@cisco.com> Date: Thu, 15 Mar 2012 17:47:14 -0400 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120315175753.21172.qmail@joyce.lan> <4F623E2D.3070100@Commerco.Net> In-Reply-To: <4F623E2D.3070100@Commerco.Net> Content-Type: multipart/alternative; boundary="------------030304030108020404090705" Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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, 15 Mar 2012 21:47:18 -0000 This is a multi-part message in MIME format. --------------030304030108020404090705 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/15/2012 3:08 PM, Commerco WebMaster wrote: > On 3/15/2012 11:57 AM, John Levine wrote: >>>> I think that RFC 4408 9.3.3.1 describes this, but it could be >>>> better written. >>> >>> It describes several options, but the MUST NOT for the receiver end >>> is missing. >>> There is a strong implication that if you can't handle your own >>> forwarding, >>> then SPF results are invalid. But that doesn't seem to be enough for >>> many email operators. >> >> I agree with Scott, the writing could be clearer, but the general >> discussion >> in 9.3 is fine. >> >> Unless your name is Paypal, a -ALL in your SPF record will screw up a >> thousand innocent mail transactions for every random spoof it catches. >> Mail forwarding has been around almost as long as mail has, it's not >> broken, it's not going to change to deal with the well-known >> limitations of SPF, and that's not a problem. >> >> R's, >> John >> _______________________________________________ > > We are hardly PayPal, yet we have had no real issues with SPF and > forwarding (using -all) over the many years it has been in use here. > > This surprises me. Over the last week or so, these are my stats on which sites forward email from me without doing SRS and which would get dropped if I used a -all. This is just my home email server (and yes, I do run a reasonably active mailing list with maybe a thousand subscribers). I will agree that a lot of people use -all: +all 2145 -all 54271 ?all 54532 ~all 166763 These are the counts from my record database. Philip The first column is the number of messages, then the IP address and then the reverse lookup if one exists. 5: 10.51.0.5 1: 128.103.229.181 postmail-s03.cadm.harvard.edu 5: 128.186.98.3 mail.met.fsu.edu 1: 128.59.28.172 sapodilla.cc.columbia.edu 2: 129.170.6.23 mailhub23.Dartmouth.EDU 3: 131.252.111.42 tomlinson.oit.pdx.edu 5: 131.252.111.43 sluizer.oit.pdx.edu 7: 131.252.111.44 postel.oit.pdx.edu 1: 173.203.2.22 gate.forward.smtp.ord1a.emailsrvr.com 12: 173.225.51.56 ganymede.interbridge.net 2: 173.247.254.120 biz104.inmotionhosting.com 2: 18.7.68.21 ALUM-MAILSEC-RELAY-1.MIT.EDU 3: 18.7.68.28 ALUM-MAILSEC-RELAY-8.MIT.EDU 2: 18.7.68.30 ALUM-MAILSEC-RELAY-10.MIT.EDU 1: 180.151.57.187 16: 198.82.165.108 rollins.bev.net 2: 199.81.10.48 1: 199.81.10.49 prh00393.prod.fedex.com 1: 199.81.10.50 prh00394.prod.fedex.com 1: 207.115.20.131 flpd121.sbcis.sbc.com 7: 207.55.16.112 zmail-mta02.peak.org 5: 209.68.2.48 shema.pair.com 2: 216.139.86.1 mail01.mx.maxen.net 4: 216.139.86.2 mail02.mx.maxen.net 4: 216.139.86.3 mail03.mx.maxen.net 3: 216.139.86.4 mail04.mx.maxen.net 4: 216.40.42.17 forward.a.hostedemail.com 14: 38.126.103.58 callisto.interbridge.net 7: 64.14.73.19 s459.sureserver.com 3: 64.18.0.119 exprod5mx233.postini.com 2: 64.18.0.169 exprod5mx249.postini.com 2: 64.18.0.35 exprod5mx189.postini.com 1: 64.18.0.43 exprod5mx197.postini.com 2: 64.18.0.54 exprod5mx258.postini.com 6: 64.18.0.73 exprod5mx214.postini.com 5: 64.40.145.244 mail2.websitesource.net 18: 64.55.116.20 vhawiniis-002.wbi.mycspot.net 1: 66.175.56.152 mail122c38.carrierzone.com 2: 66.175.56.163 mail133c38.carrierzone.com 5: 66.175.56.189 mail115c38.carrierzone.com 1: 66.231.182.48 mx1-relay1.dnsmadeeasy.com 3: 66.94.237.209 nm8.access.bullet.mail.mud.yahoo.com 35: 74.208.4.194 mout.perfora.net 5: 74.208.4.195 mout.perfora.net 1: 76.96.27.228 qmta15.emeryville.ca.mail.comcast.net 2: 76.96.59.228 qmta15.westchester.pa.mail.comcast.net 1: 76.96.62.24 qmta02.westchester.pa.mail.comcast.net 1: 76.96.62.56 qmta06.westchester.pa.mail.comcast.net 3: 98.138.90.59 nm27-vm1.bullet.mail.ne1.yahoo.com 3: 98.139.212.182 nm23.bullet.mail.bf1.yahoo.com 3: 98.139.212.189 nm30.bullet.mail.bf1.yahoo.com 6: 98.139.212.252 nm28-vm1.bullet.mail.bf1.yahoo.com 3: 98.139.213.137 nm21-vm0.bullet.mail.bf1.yahoo.com 6: 98.139.213.151 nm7-vm0.bullet.mail.bf1.yahoo.com 2: 98.139.44.192 nm29-vm0.access.bullet.mail.sp2.yahoo.com 1: 98.139.52.204 nm7.bullet.mail.ac4.yahoo.com 6: 98.139.52.223 nm26.bullet.mail.ac4.yahoo.com 1: 98.139.52.235 nm14-vm1.bullet.mail.ac4.yahoo.com 3: 98.139.52.236 nm15-vm0.bullet.mail.ac4.yahoo.com 6: 98.139.53.211 nm18-vm1.bullet.mail.ac4.yahoo.com 6: 98.139.91.198 nm10-vm0.bullet.mail.sp2.yahoo.com 3: 98.139.91.222 nm22-vm0.bullet.mail.sp2.yahoo.com 1: 98.139.91.230 nm26-vm0.bullet.mail.sp2.yahoo.com 6: 98.139.91.232 nm27-vm0.bullet.mail.sp2.yahoo.com 6: 98.139.91.249 nm2-vm1.bullet.mail.sp2.yahoo.com > -- > Philip Gladstone > Distinguished Engineer > Product Development > pgladstone@cisco.com > Phone: +1 978-ZEN-TOAD (+1 978 936 8623) > Google: +1 978 800 1010 > Ham radio: N1DQ --------------030304030108020404090705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 3/15/2012 3:08 PM, Commerco WebMaster wrote:
On 3/15/2012 11:57 AM, John Levine wrote:
I think that RFC 4408 9.3.3.1 describes this, but it could be better written.

It describes several options, but the MUST NOT for the receiver end is missing.
There is a strong implication that if you can't handle your own forwarding,
then SPF results are invalid.  But that doesn't seem to be enough for
many email operators.

I agree with Scott, the writing could be clearer, but the general discussion
in 9.3 is fine.

Unless your name is Paypal, a -ALL in your SPF record will screw up a
thousand innocent mail transactions for every random spoof it catches.
Mail forwarding has been around almost as long as mail has, it's not
broken, it's not going to change to deal with the well-known
limitations of SPF, and that's not a problem.

R's,
John
_______________________________________________

We are hardly PayPal, yet we have had no real issues with SPF and forwarding (using -all) over the many years it has been in use here.


This surprises me. Over the last week or so, these are my stats on which sites forward email from me without doing SRS and which would get dropped if I used a -all. This is just my home email server (and yes, I do run a reasonably active mailing list with maybe a thousand subscribers). I will agree that a lot of people use -all:

        +all   2145
        -all  54271
        ?all  54532
        ~all 166763

These are the counts from my record database.

Philip

The first column is the number of messages, then the IP address and then the reverse lookup if one exists.


    5:              10.51.0.5 
    1:        128.103.229.181  postmail-s03.cadm.harvard.edu
    5:           128.186.98.3  mail.met.fsu.edu
    1:          128.59.28.172  sapodilla.cc.columbia.edu
    2:           129.170.6.23  mailhub23.Dartmouth.EDU
    3:         131.252.111.42  tomlinson.oit.pdx.edu
    5:         131.252.111.43  sluizer.oit.pdx.edu
    7:         131.252.111.44  postel.oit.pdx.edu
    1:           173.203.2.22  gate.forward.smtp.ord1a.emailsrvr.com
   12:          173.225.51.56  ganymede.interbridge.net
    2:        173.247.254.120  biz104.inmotionhosting.com
    2:             18.7.68.21  ALUM-MAILSEC-RELAY-1.MIT.EDU
    3:             18.7.68.28  ALUM-MAILSEC-RELAY-8.MIT.EDU
    2:             18.7.68.30  ALUM-MAILSEC-RELAY-10.MIT.EDU
    1:         180.151.57.187 
   16:         198.82.165.108  rollins.bev.net
    2:           199.81.10.48 
    1:           199.81.10.49  prh00393.prod.fedex.com
    1:           199.81.10.50  prh00394.prod.fedex.com
    1:         207.115.20.131  flpd121.sbcis.sbc.com
    7:          207.55.16.112  zmail-mta02.peak.org
    5:            209.68.2.48  shema.pair.com
    2:           216.139.86.1  mail01.mx.maxen.net
    4:           216.139.86.2  mail02.mx.maxen.net
    4:           216.139.86.3  mail03.mx.maxen.net
    3:           216.139.86.4  mail04.mx.maxen.net
    4:           216.40.42.17  forward.a.hostedemail.com
   14:          38.126.103.58  callisto.interbridge.net
    7:            64.14.73.19  s459.sureserver.com
    3:            64.18.0.119  exprod5mx233.postini.com
    2:            64.18.0.169  exprod5mx249.postini.com
    2:             64.18.0.35  exprod5mx189.postini.com
    1:             64.18.0.43  exprod5mx197.postini.com
    2:             64.18.0.54  exprod5mx258.postini.com
    6:             64.18.0.73  exprod5mx214.postini.com
    5:          64.40.145.244  mail2.websitesource.net
   18:           64.55.116.20  vhawiniis-002.wbi.mycspot.net
    1:          66.175.56.152  mail122c38.carrierzone.com
    2:          66.175.56.163  mail133c38.carrierzone.com
    5:          66.175.56.189  mail115c38.carrierzone.com
    1:          66.231.182.48  mx1-relay1.dnsmadeeasy.com
    3:          66.94.237.209  nm8.access.bullet.mail.mud.yahoo.com
   35:           74.208.4.194  mout.perfora.net
    5:           74.208.4.195  mout.perfora.net
    1:           76.96.27.228  qmta15.emeryville.ca.mail.comcast.net
    2:           76.96.59.228  qmta15.westchester.pa.mail.comcast.net
    1:            76.96.62.24  qmta02.westchester.pa.mail.comcast.net
    1:            76.96.62.56  qmta06.westchester.pa.mail.comcast.net
    3:           98.138.90.59  nm27-vm1.bullet.mail.ne1.yahoo.com
    3:         98.139.212.182  nm23.bullet.mail.bf1.yahoo.com
    3:         98.139.212.189  nm30.bullet.mail.bf1.yahoo.com
    6:         98.139.212.252  nm28-vm1.bullet.mail.bf1.yahoo.com
    3:         98.139.213.137  nm21-vm0.bullet.mail.bf1.yahoo.com
    6:         98.139.213.151  nm7-vm0.bullet.mail.bf1.yahoo.com
    2:          98.139.44.192  nm29-vm0.access.bullet.mail.sp2.yahoo.com
    1:          98.139.52.204  nm7.bullet.mail.ac4.yahoo.com
    6:          98.139.52.223  nm26.bullet.mail.ac4.yahoo.com
    1:          98.139.52.235  nm14-vm1.bullet.mail.ac4.yahoo.com
    3:          98.139.52.236  nm15-vm0.bullet.mail.ac4.yahoo.com
    6:          98.139.53.211  nm18-vm1.bullet.mail.ac4.yahoo.com
    6:          98.139.91.198  nm10-vm0.bullet.mail.sp2.yahoo.com
    3:          98.139.91.222  nm22-vm0.bullet.mail.sp2.yahoo.com
    1:          98.139.91.230  nm26-vm0.bullet.mail.sp2.yahoo.com
    6:          98.139.91.232  nm27-vm0.bullet.mail.sp2.yahoo.com
    6:          98.139.91.249  nm2-vm1.bullet.mail.sp2.yahoo.com

-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ
--------------030304030108020404090705-- From SRS0=LBxGw=BX==stuart@gathman.org Thu Mar 15 17:40:53 2012 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 8885A21E8026 for ; Thu, 15 Mar 2012 17:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 AAADX3wRsju8 for ; Thu, 15 Mar 2012 17:40:53 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id EA2B721E800F for ; Thu, 15 Mar 2012 17:40:52 -0700 (PDT) Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q2G0dq7Z012427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Mar 2012 20:39:57 -0400 Message-ID: <4F628C0C.4030803@gathman.org> Date: Thu, 15 Mar 2012 20:40:44 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120315175753.21172.qmail@joyce.lan> <4F623E2D.3070100@Commerco.Net> <4F626362.7060405@cisco.com> In-Reply-To: <4F626362.7060405@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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, 16 Mar 2012 00:52:12 -0000 Long ago, Nostradamus foresaw that on 03/15/2012 05:47 PM, Philip Gladstone would write: >> We are hardly PayPal, yet we have had no real issues with SPF and >> forwarding (using -all) over the many years it has been in use here. >> > This surprises me. Over the last week or so, these are my stats on > which sites forward email from me without doing SRS and which would > get dropped if I used a -all. This is just my home email server (and > yes, I do run a reasonably active mailing list with maybe a thousand > subscribers). I will agree that a lot of people use -all: This is exactly what needs to be clearer. You as the sender have no control. It is the *recipient* that sets up the forward, and is responsible for handling it properly IF they want to check SPF. That does imply that gmail.com, aol.com, etc can't check SPF (except perhaps on a per user basis as requested) because of exactly what you described: people set up forwards from random locations to their gmail account and expect it to work. Their expectation is reasonable if they don't expect SPF to screen forgeries. But gmail MUST NOT consider SPF results official (and probably shouldn't reject on an alleged SPF FAIL), unless their terms of use forbid forwarding to a gmail account from random locations, or they have some magic way of handling such forwards. I suspect gmail actually has an internal list of trusted forwarders - but I can't really tell. If the random forwarder does SRS, then it all just works. If the random forwarder does 551 with a forwarding address, it all just works (appropriate for alumni, etc) For recipients with a small private or company wide email domain, requiring whitelisting of non-SRS forwarders is good policy. Big email providers like aol and gmail generally don't need to reject on SPF. They have effective IP blacklists based on feedback from millions of users. Small email domains *do* need to reject on SPF, and it is a simple matter of policy to either forbid random non-SRS forwards, or provide a procedure to tell the company MTAs about the new semi-trusted MX. From dotis@mail-abuse.org Thu Mar 15 18:23:38 2012 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 0402021F85F0 for ; Thu, 15 Mar 2012 18:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 9msEiTR1ipnj for ; Thu, 15 Mar 2012 18:23:37 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 56AA321F85EC for ; Thu, 15 Mar 2012 18:23:37 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 1744A174058F for ; Fri, 16 Mar 2012 01:23:37 +0000 (UTC) Message-ID: <4F629618.7000108@mail-abuse.org> Date: Thu, 15 Mar 2012 18:23:36 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <6.2.5.6.2.20120313221606.0aeaadf0@elandnews.com> <4F621651.2020000@cisco.com> In-Reply-To: <4F621651.2020000@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for 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: Fri, 16 Mar 2012 01:23:38 -0000 On 3/15/12 9:18 AM, Philip Gladstone wrote: > On 3/14/2012 1:17 AM, S Moonesamy wrote: >> At 17:53 17-02-2012, spfbis issue tracker wrote: >>> #14: RFC 4408: local-part macro prep for deprecation >>> >>> Message from Doug Otis on 17 Feb 2012: >>> >>> Use of local-part macros in SPF record sets necessitates repeating all >>> invoked DNS transactions. DNS caching only limits DNS overhead >>> when no >>> local-part macros are used within SPF record sets. It is not >>> uncommon for >>> the use of random local-part names in messages to be sent by >>> malefactors. >>> Such use significantly impacts the utility of SPF without burdening >>> the >>> authoritative servers employed by malefactors. Not only will >>> local-part >>> macros increase the gain of a reflected attack, it also prevents >>> resolving >>> addresses of a set of servers for a specific domain. >>> Permitting local-part assessments will return results based upon >>> entire >>> email addresses and not just the email-address domain. It is >>> common to >>> use SPF to resolve the outbound addresses used by a domain to check >>> reputation listings against these addresses. This use assumes a >>> specific >>> domain has not defined local-part macros in their record set or >>> that it >>> defaults to "postmaster". >>> >>> SPF local-part macros should not be used as a method to vet valid >>> local- >>> part names, as this would permit the use of high speed dictionary >>> attacks >>> to discover which are valid. A domain better protects >>> confidentiality of >>> valid local-parts by postponing acceptance or refusal to the Data >>> command. >>> A reasonable practice for recipients to use to ensure effective >>> caching >>> and to retain the desired utility is to supplant any local-part >>> with that >>> of "postmaster". Otherwise, when SPF processing follows other >>> types of >>> vetting, expansion of the local-part would leak its status via DNS >>> requests. > I don't understand this paragraph. The local part macro is used to > validate the *sender* of the email. This cannot be done by postponing > acceptance or refusal to the Data command. I suspect that there is > some confusion between sender local part and recipient local-part. Dear Philip, Thank you for the question. Valid local-parts are exposed with immediate rejections of individual recipients for inbound messages, and at anytime when resource records in DNS determine sender validity when SPF records contain local-part macros. Exposing valid local-parts in this manner asks for additional abuse and should be considered a bad practice on that basis alone, but there is more... >>> Add: >>> >>> A method for mitigating a reduction in utility or risks associated >>> with >>> local-part macros would be to replace any local-part with that of >>> "postmaster". >>> > This would break backward compatibility. There is no reason that the > string "postmaster" would pass validation. Note that an MTA may serve > several domains, and it may arrange that all outgoing mail from > postmaster comes from a specific domain. In this case, if it was doing > local-part verification, then the use of postmaster could easily cause > SPF failures. Host checks default to "postmaster" when local-parts are not included for various reasons such as with NDNs or EHLO checks. Use of local-part macros relinquishes sender's control over authorized sources. Substituting "postmaster" protects against possible abuse of the recipient's resources, which should be considered a good practice. > In conjunction with issue #12 and forwarders that do not do SRS, the > forwarder will be sending mail *from* the original local-part, but > from the *wrong* MTA. At least checking the local part allows this to > be validated. [I could see systems which tried to distinguish between > valid forwarders and spammers by using a set of heuristics based on > the local-part and the timing of SPF checks] It seems safe to conclude SRS has not reached a level of adoption offering benefit. The The Authorized Third-Party Signatures (ATPS) draft, http://tools.ietf.org/html/rfc6541 should impose fewer obstacles, especially when supported by various service providers. Basing acceptance on local-part macros allows undetectable spoofing of senders. Again, this asks for abuse and places recipients at risk which should be considered an extremely bad practice. > In other words, I do not support the deprecation of the local-part macro. It should be mentioned, support of local-part macro vetting by recipients allows any malefactor the ability to hammer victims using recipient's resources, and lacking limits on no-data, still have messages accepted based upon SPF results. Would you advocate for MFROM and EHLO checks? Would you advocate for spf/txt being done in parallel? Lacking no-data limits can result in hundreds of needless queries aimed at any victim that only needs to support DNS, and not even email. It is also very likely no one will notice except victims who may lack any relationship with email services. It should also be mentioned, these victims will be unable to play any role in mitigating the attacks. Regards, Douglas Otis From spf2@kitterman.com Thu Mar 15 20:51:06 2012 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 A479421E8056 for ; Thu, 15 Mar 2012 20:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 0ztMDSNG5zzi for ; Thu, 15 Mar 2012 20:51:06 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1A021E801B for ; Thu, 15 Mar 2012 20:51:06 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1AD2720E40D7; Thu, 15 Mar 2012 23:51:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331869865; bh=G6JYKOHu9GSxlnZVv0arXLFkoBW5fLtA6hfEIGfSG6M=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Tjcd0RPiSt1bHGhenMaa5Gi0zQ7GjGYhSYHWmNBNglTZgYDJA6juJywEOjVZ5uIgM p83qcQT5IZ8JpqQpe4+Vy2CjJwgXZB59nVx0MMyPIfb8p7HZTlQR3ObExd97xWhU9J +aUNd2BZ/rErF4tsR79/YMsh4SHY37NaUk+kldfM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 00F6620E408F; Thu, 15 Mar 2012 23:51:04 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 15 Mar 2012 23:39:03 -0400 Message-ID: <1611031.Oj2UJhZdgh@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F629618.7000108@mail-abuse.org> References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <4F621651.2020000@cisco.com> <4F629618.7000108@mail-abuse.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for 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: Fri, 16 Mar 2012 03:51:06 -0000 On Thursday, March 15, 2012 06:23:36 PM Douglas Otis wrote: ... > Host checks default to "postmaster" when local-parts are not included > for various reasons such as with NDNs or EHLO checks. Use of local-part > macros relinquishes sender's control over authorized sources. > Substituting "postmaster" protects against possible abuse of the > recipient's resources, which should be considered a good practice. ... After the first sentence, this is incorrect. The use of local-part macros does exactly the opposite of that. It enables the sender to set per-user SPF policies. There's no abuse of recipient resources here. Yes, SPF records that use local-part macros can't be globally cached, so there might be some increased DNS usage, but there's no abuse. Should this ever prove to be a problem in practice, receivers are free to skip SPF checks on such messages. Limiting local-part macros to always use postmaster is functionally equivalent to removing the macro. This would break backwards compatibility with a feature that's in use and there's no reason to go there. Scott K From spf2@kitterman.com Thu Mar 15 20:54:12 2012 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 5D1F921E8064 for ; Thu, 15 Mar 2012 20:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 wkXUYt7y3LXX for ; Thu, 15 Mar 2012 20:54:11 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9536321E8062 for ; Thu, 15 Mar 2012 20:54:11 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2E69620E40D0; Thu, 15 Mar 2012 23:54:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331870051; bh=cav6C9n+C02s4KUGHKIzRw3cfxOI9xdkqSdxQilCUVs=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=AOSEC5yVUkzlxc2GZ87XrGxU/HdZRDdBLuYbir/1KKb1wTWS0yfrBwe3aA7T9odXT ue+98TJh87FLmsQZTaznVaFBbrb4y+ObO1IMhipLtd8PqcRJRFM+H1Uw3zj+XN+fsi /kJT+mLpVieU6TGfgf+0q1mOLIjGu7fxeaG3Pu1c= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 11A2A20E408F; Thu, 15 Mar 2012 23:54:10 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 15 Mar 2012 23:54:10 -0400 Message-ID: <5718697.q5mpy510na@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F628C0C.4030803@gathman.org> References: <20120315175753.21172.qmail@joyce.lan> <4F626362.7060405@cisco.com> <4F628C0C.4030803@gathman.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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, 16 Mar 2012 03:54:12 -0000 On Thursday, March 15, 2012 08:40:44 PM Stuart Gathman wrote: > I suspect gmail actually has an internal list of trusted forwarders - > but I can't really tell. I'm not sure how they manage it, but if you publish a DMARC record (see dmarc.org) the feedback you get from Google has forwarded messages marked as such. They definitely have something. Scott K From vesely@tana.it Fri Mar 16 04:33:09 2012 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 6C4C721F85EC for ; Fri, 16 Mar 2012 04:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.656 X-Spam-Level: X-Spam-Status: No, score=-4.656 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRKnZ-601QeV for ; Fri, 16 Mar 2012 04:33:08 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB0E21F85FB for ; Fri, 16 Mar 2012 04:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1331897546; bh=7wqCsf6A6cHpfBnWzLtdXsrVbdnz3wpMvd0gdhrZebY=; l=1121; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=JoEBeiIpHNVMwnS86n4X96DZwJtq4bQ18Z3/EtBBuCRBxnXY8SIkjxh0lveCvQ6xO xFmKNjaE7WssOJzKtE7VXAdX4VOcjqQALjuW8TPn6DL7JfMnqadmJbxi0U+GrscBJq TGgSihtNK5GMWxr0UMXbcYKx2dUemIqtwjg4blWM= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 16 Mar 2012 12:32:26 +0100 id 00000000005DC035.000000004F6324CA.00002FBB Message-ID: <4F6324C9.20101@tana.it> Date: Fri, 16 Mar 2012 12:32:25 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120315175753.21172.qmail@joyce.lan> <4F626362.7060405@cisco.com> <4F628C0C.4030803@gathman.org> <5718697.q5mpy510na@scott-latitude-e6320> In-Reply-To: <5718697.q5mpy510na@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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, 16 Mar 2012 11:33:09 -0000 On 16/Mar/12 04:54, Scott Kitterman wrote: > On Thursday, March 15, 2012 08:40:44 PM Stuart Gathman wrote: >> I suspect gmail actually has an internal list of trusted forwarders - >> but I can't really tell. > > I'm not sure how they manage it, but if you publish a DMARC record (see > dmarc.org) the feedback you get from Google has forwarded messages marked as > such. They definitely have something. Yes, a number of failed SPF checks for forwarded mail! >> people set up forwards from random locations to their gmail >> account and expect it to work. Their expectation is reasonable >> if they don't expect SPF to screen forgeries. But gmail MUST NOT >> consider SPF results official (and probably shouldn't reject on >> an alleged SPF FAIL), unless their terms of use forbid forwarding >> to a gmail account from random locations, or they have some magic >> way of handling such forwards. It seems that one of the following must be true: 1: gmail, or any other receiver, don't consider SPF results official, 2: senders never publish -all, or 3: users don't expect forwarding to work. From spf2@kitterman.com Fri Mar 16 05:34:31 2012 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 CA4C321F85A8 for ; Fri, 16 Mar 2012 05:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 Hl1jPI0sJMPv for ; Fri, 16 Mar 2012 05:34:30 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9A52E21F865D for ; Fri, 16 Mar 2012 05:34:30 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A787420E40D0; Fri, 16 Mar 2012 08:34:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331901267; bh=S4wFggtozyy7El/YMZ+dFMJZFZusWxwAQiTNBqtHHLg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Tly/I2M3WHiZxgH2TiQwJgEEkqRSzh6E6U6Q5U0/zAYRPuLrKu1mSeZvYuBPafjfG wQql5OOFOVeGInZQ6bzKKEvwJRNWDsbj4AhuynFJSeeNWnid8+nw39D6pIbdAK4RNC SFtN3L3dmN2q4Wlh8d4W5OPBcV1zEi2YAvQ+us9w= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8924520E4089; Fri, 16 Mar 2012 08:34:27 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 16 Mar 2012 08:34:26 -0400 Message-ID: <2368238.z2f9qZKL6b@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F6324C9.20101@tana.it> References: <20120315175753.21172.qmail@joyce.lan> <5718697.q5mpy510na@scott-latitude-e6320> <4F6324C9.20101@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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, 16 Mar 2012 12:34:31 -0000 On Friday, March 16, 2012 12:32:25 PM Alessandro Vesely wrote: > On 16/Mar/12 04:54, Scott Kitterman wrote: > > On Thursday, March 15, 2012 08:40:44 PM Stuart Gathman wrote: > >> I suspect gmail actually has an internal list of trusted forwarders - > >> but I can't really tell. > > > > I'm not sure how they manage it, but if you publish a DMARC record (see > > dmarc.org) the feedback you get from Google has forwarded messages > > marked as such. They definitely have something. > > Yes, a number of failed SPF checks for forwarded mail! > > >> people set up forwards from random locations to their gmail > >> account and expect it to work. Their expectation is reasonable > >> if they don't expect SPF to screen forgeries. But gmail MUST NOT > >> consider SPF results official (and probably shouldn't reject on > >> an alleged SPF FAIL), unless their terms of use forbid forwarding > >> to a gmail account from random locations, or they have some magic > >> way of handling such forwards. > > It seems that one of the following must be true: > > 1: gmail, or any other receiver, don't consider SPF results official, > > 2: senders never publish -all, or > > 3: users don't expect forwarding to work. 4. Gmail is a very large, sophisticated mail operator run by a company with lots of expertise in assessing and correlating large volumes of data and uses both the data and the capability to determine likely forwarding paths and doesn't reject forwarded mail (independent of SPF) in order to avoid causing backscatter. Scott K From pgladstone@cisco.com Fri Mar 16 07:03:29 2012 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 EB01521F86A1 for ; Fri, 16 Mar 2012 07:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.102 X-Spam-Level: X-Spam-Status: No, score=-8.102 tagged_above=-999 required=5 tests=[AWL=1.896, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] 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 GIOaWkBul+-t for ; Fri, 16 Mar 2012 07:03:28 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5344D21F841C for ; Fri, 16 Mar 2012 07:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=2729; q=dns/txt; s=iport; t=1331906607; x=1333116207; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=7WqrY1ouq203y2Kl1QEo+D8J5CHrAZKkdo+iazeRC+A=; b=aeYkOVwIrs4+T+Tldt4fk9eLvOIs4osd8QFOuRIASFgpPCx6DippVZvs 7b1Hde0/6qr1zPzUIBR8ZzH+dkdDcw1hHzFRd8CCkK2oROOgEWGBQCsNw SzBTPLJoosbRNJzcKlou18zURrF4iIApDQxU1H8nwt5sON7Obxfn7WVPl E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADpHY0+tJXG8/2dsb2JhbAA/A4VHsHiBB4IJAQEBBBIBEFUPAgsEARMJFgsCAgkDAgECAQk8EwYCAQEeh2ief40EijMEjVIFggyBFgSVZoVsiFOBaIMC X-IronPort-AV: E=Sophos;i="4.73,598,1325462400"; d="scan'208,217";a="67007107" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 16 Mar 2012 14:03:27 +0000 Received: from [161.44.106.143] (dhcp-161-44-106-143.cisco.com [161.44.106.143]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2GE3Qxw016732 for ; Fri, 16 Mar 2012 14:03:26 GMT Message-ID: <4F63482D.8060105@cisco.com> Date: Fri, 16 Mar 2012 10:03:25 -0400 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120315175753.21172.qmail@joyce.lan> <4F626362.7060405@cisco.com> <4F628C0C.4030803@gathman.org> <5718697.q5mpy510na@scott-latitude-e6320> <4F6324C9.20101@tana.it> In-Reply-To: <4F6324C9.20101@tana.it> Content-Type: multipart/alternative; boundary="------------000604040708040902020309" Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities 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, 16 Mar 2012 14:03:29 -0000 This is a multi-part message in MIME format. --------------000604040708040902020309 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/16/2012 7:32 AM, Alessandro Vesely wrote: > It seems that one of the following must be true: > > 1: gmail, or any other receiver, don't consider SPF results official, > > 2: senders never publish -all, or > > 3: users don't expect forwarding to work. These options are *very* worrying for the future of SPF. If the big players ignore SPF, then this reduces the effective adoption of SPF dramatically. Why publish an SPF record if the results of evaluation are ignored? People do publish -all Users do expect forwarding to work. [In my case, I have an SPF record that rates limits the forwarding rate by any particular MTA] Philip > > -- > Philip Gladstone > Distinguished Engineer > Product Development > pgladstone@cisco.com > Phone: +1 978-ZEN-TOAD (+1 978 936 8623) > Google: +1 978 800 1010 > Ham radio: N1DQ --------------000604040708040902020309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

On 3/16/2012 7:32 AM, Alessandro Vesely wrote: 

      
It seems that one of the following must be true:

1: gmail, or any other receiver, don't consider SPF results official,

2: senders never publish -all, or

3: users don't expect forwarding to work.


    

    

    These options are *very* worrying for the future of SPF.

    

    If the big players ignore SPF, then this reduces the effective
    adoption of SPF dramatically. Why publish an SPF record if the
    results of evaluation are ignored?

    

    People do publish -all

    

    Users do expect forwarding to work.

    

    [In my case, I have an SPF record that rates limits the forwarding
    rate by any particular MTA]

    

    Philip

    

    

      

      

      
-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ


    

  


--------------000604040708040902020309--

From john@jlc.net  Fri Mar 16 07:29:03 2012
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 32D4721F85F4 for ; Fri, 16 Mar 2012 07:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.352
X-Spam-Level: 
X-Spam-Status: No, score=-106.352 tagged_above=-999 required=5 tests=[AWL=0.247, 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 MA1XPhIP0wFz for ; Fri, 16 Mar 2012 07:29:02 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 92B4021F85A4 for ; Fri, 16 Mar 2012 07:29:02 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 65A5333C85; Fri, 16 Mar 2012 10:29:02 -0400 (EDT)
Date: Fri, 16 Mar 2012 10:29:02 -0400
From: John Leslie 
To: Philip Gladstone 
Message-ID: <20120316142902.GF64669@verdi>
References: <20120315175753.21172.qmail@joyce.lan> <4F626362.7060405@cisco.com> <4F628C0C.4030803@gathman.org> <5718697.q5mpy510na@scott-latitude-e6320> <4F6324C9.20101@tana.it> <4F63482D.8060105@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4F63482D.8060105@cisco.com>
User-Agent: Mutt/1.4.1i
Cc: spfbis@ietf.org
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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, 16 Mar 2012 14:29:03 -0000

Philip Gladstone  wrote:
> On 3/16/2012 7:32 AM, Alessandro Vesely wrote:
> 
>> It seems that one of the following must be true:
>> 
>> 1: gmail, or any other receiver, don't consider SPF results official,
>> 
>> 2: senders never publish -all, or
>> 
>> 3: users don't expect forwarding to work.
> 
> These options are *very* worrying for the future of SPF.
> 
> If the big players ignore SPF, then this reduces the effective adoption 
> of SPF dramatically. Why publish an SPF record if the results of 
> evaluation are ignored?

   Philip is correct to talk of "effective adoption" in the eyes of the
beholder; but that's certainly not the whole picture.

   Some domains avoid publishing -all, specifically because of uncertainty
over possible forwarding.

   Some MTA managers _check_ SPF, but don't respect -all -- instead
recording the SPF results in a header.

   These and other workarounds are perfectly reasonable, so far as they
go...

> People do publish -all
> 
> Users do expect forwarding to work.

   Let's be sure we're clear here: some sender domains do publish -all
when they know their email will never _originate_ from a different MTA;
some receivers enable forwarding and do not want emails discarded
because of an SPF -all.

   RFC 4408 has nothing to _resolve_ this tussle.

   I doubt we can _resolve_ it in 4408bis either; but I hope we can
explain it a bit better.

> [In my case, I have an SPF record that rates limits the forwarding rate 
> by any particular MTA]

   Sounds like one possible approach (though I don't fully understand it).
I can think of a half-dozen different approaches...

   I suggest we collect different approaches, and try to craft an
Appendix discussing their strengths and weaknesses.

--
John Leslie 

From dotzero@gmail.com  Fri Mar 16 07:39:38 2012
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 A1FC821F872E for ; Fri, 16 Mar 2012 07:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 f6p5RsIe7FHQ for ; Fri, 16 Mar 2012 07:39:38 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 191EF21F871B for ; Fri, 16 Mar 2012 07:39:38 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so1799818yhk.31 for ; Fri, 16 Mar 2012 07:39:37 -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=5q7hmOxY6TQajJtOe+kkyVLF5+a8uiXdDrFUr0JJ+/Q=; b=kyvcUAMIdUrAmWbhhRuXdKVJ4pnbDuypfs5wy4MwgEtvhbLI9Zicn9DSSw7ctqKaiJ ya0tqAQp+PakgEfqD4B1cEh0kUdfibjhQyxMfH4sJ3YPu1YuOVVa2/pCHaslOzXs34rZ kuNM2vG1IJU4n51QE8zmS0ZtzOu0gBulIjNPVCIzQuy69g3UUdsdWMClmkvXREDLdBh/ 21msLRv8kfb6pXowmlESVAUwvs0nNVFy3Qc3DZtIC6nU1DQ1K6HI7aoZ7z4Qa4qu/B6h 4zvbvobnI5/+cv9m92joboOJun4srI7kkOvJlMdjwdliO/KGf+AkEo+quukZvxkzvXbO D5cQ==
MIME-Version: 1.0
Received: by 10.68.129.100 with SMTP id nv4mr15470274pbb.109.1331908777018; Fri, 16 Mar 2012 07:39:37 -0700 (PDT)
Received: by 10.68.231.129 with HTTP; Fri, 16 Mar 2012 07:39:36 -0700 (PDT)
In-Reply-To: <4F63482D.8060105@cisco.com>
References: <20120315175753.21172.qmail@joyce.lan> <4F626362.7060405@cisco.com> <4F628C0C.4030803@gathman.org> <5718697.q5mpy510na@scott-latitude-e6320> <4F6324C9.20101@tana.it> <4F63482D.8060105@cisco.com>
Date: Fri, 16 Mar 2012 10:39:36 -0400
Message-ID: 
From: Dotzero 
To: Philip Gladstone 
Content-Type: text/plain; charset=ISO-8859-1
Cc: spfbis@ietf.org
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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, 16 Mar 2012 14:39:38 -0000

On Fri, Mar 16, 2012 at 10:03 AM, Philip Gladstone  wrote:
>
>
> On 3/16/2012 7:32 AM, Alessandro Vesely wrote:
>
> It seems that one of the following must be true:
> 1: gmail, or any other receiver, don't consider SPF results official,
> 2: senders never publish -all, or
> 3: users don't expect forwarding to work.
>
>
> These options are *very* worrying for the future of SPF.
>
> If the big players ignore SPF, then this reduces the effective adoption of
> SPF dramatically. Why publish an SPF record if the results of evaluation are
> ignored?
>
> People do publish -all
>
> Users do expect forwarding to work.
>
> [In my case, I have an SPF record that rates limits the forwarding rate by
> any particular MTA]
>
> Philip
>
>
>

Philip,

I'm not sure I understand your complaint. If I understand you
correctly, your complaint is that Gmail is not compiant with SPF
because it accepts mail coming through a maillist (which fails SPF
validation) when the original domain publishes a "-all".

I suggest you reread section 2.5.4 of RFC4408 more carefully. There is
no requirement to reject... and Gmail DOES mark the mail (adding a
header) as having failed SPF. As far as I can tell they are doing what
is required.

Mike

From spf2@kitterman.com  Fri Mar 16 09:17:25 2012
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 E498321F86E3 for ; Fri, 16 Mar 2012 09:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002,  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 CLknjYzHYFfX for ; Fri, 16 Mar 2012 09:17:24 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0470121F86B2 for ; Fri, 16 Mar 2012 09:17:24 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6BEDC20E40D0; Fri, 16 Mar 2012 12:17:23 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331914643; bh=cgmpYrgh+Ln9ImrYU9Hfq9Jn2UmIGogAnDiFpiyuqOw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=kYipgWnhgryYbehr6MuYmOzoSyGOv7cNB88aPiZA9wcedXMzL4fgpPVg5XM5SH/aI 58P/kL7PgIh3JRmpiF8cUZu+uzcuCnd5BCk7Ar0EE19+yp0SWEu+eKv5GcfIrgAlZk 5nBoWG4n+S7Dau2cmOjbH8F56Xq1I1f0GbqF/dCA=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4E2D320E4089;  Fri, 16 Mar 2012 12:17:23 -0400 (EDT)
From: Scott Kitterman 
To: spfbis@ietf.org
Date: Fri, 16 Mar 2012 12:17:22 -0400
Message-ID: <4472029.oVkT6GqL45@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <4F63482D.8060105@cisco.com>
References: <20120315175753.21172.qmail@joyce.lan> <4F6324C9.20101@tana.it> <4F63482D.8060105@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] #12: RFC 4408 Section 9 - Forwarding and helo identities
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, 16 Mar 2012 16:17:25 -0000

On Friday, March 16, 2012 10:03:25 AM Philip Gladstone wrote:
> On 3/16/2012 7:32 AM, Alessandro Vesely wrote:
> > It seems that one of the following must be true:
> > 
> > 1: gmail, or any other receiver, don't consider SPF results official,
> > 
> > 2: senders never publish -all, or
> > 
> > 3: users don't expect forwarding to work.
> 
> These options are *very* worrying for the future of SPF.
> 
> If the big players ignore SPF, then this reduces the effective adoption
> of SPF dramatically. Why publish an SPF record if the results of
> evaluation are ignored?
> 
> People do publish -all
> 
> Users do expect forwarding to work.

I've published a -all SPF record since (IIRC) sometime in 2005.  There is very 
little forwarding in the set of people I send to.  In a few cases, I've gotten 
bounce messages due to post-forwarding rejections.  So far, they've always 
contained the target address of the forward and I just resent the message.

Forwarding does happen, but I think that it's rare enough that mail losses due 
to a combination of forwarding and SPF based rejection is a noise level issue 
in the scheme of the overall unreliability of email.  I'm, personally, a lot 
more worried about providers that break the reject or deliver paradigm and 
just drop email into a black hole for reasons that no doubt make sense to 
them.

Scott K

From WebMaster@Commerco.Net  Fri Mar 16 09:43:25 2012
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 14DEE21E8012 for ; Fri, 16 Mar 2012 09:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.641
X-Spam-Level: 
X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=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 fEUbkLgRYqDN for ; Fri, 16 Mar 2012 09:43:24 -0700 (PDT)
Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5A44521F875B for ; Fri, 16 Mar 2012 09:43:24 -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:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=UXyGSDyXpE1lnz/DldrL+CW8hC3PSYV1NVJ00IZTM3RZF1lz1aYmjhY4w4Gwgg/G/il+HS3gowJ/6+ZbswzgcoV7Vnb3L6iUIZmKeVy2s6SmQatA9cGe6Y0eecFiFlQnaveenBPBNpB7Leyj8rygN10vj0zlH2Bf1AxxHPeU6fU=
Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Fri, 16 Mar 2012 16:43:21 +0000
Message-ID: <4F636DA3.4000702@Commerco.Net>
Date: Fri, 16 Mar 2012 10:43:15 -0600
From: Commerco WebMaster 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120315175753.21172.qmail@joyce.lan> <4F626362.7060405@cisco.com> <4F628C0C.4030803@gathman.org> <5718697.q5mpy510na@scott-latitude-e6320> <4F6324C9.20101@tana.it> <4F63482D.8060105@cisco.com>
In-Reply-To: <4F63482D.8060105@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-FromIP: 71.216.84.59
X-FromCountry: US
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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, 16 Mar 2012 16:43:25 -0000

On 3/16/2012 8:03 AM, Philip Gladstone wrote:
>
>
> On 3/16/2012 7:32 AM, Alessandro Vesely wrote:
>> It seems that one of the following must be true:
>>
>> 1: gmail, or any other receiver, don't consider SPF results official,
>>
>> 2: senders never publish -all, or
>>
>> 3: users don't expect forwarding to work.
>
> These options are *very* worrying for the future of SPF.
>
> If the big players ignore SPF, then this reduces the effective adoption
> of SPF dramatically. Why publish an SPF record if the results of
> evaluation are ignored?
>
> People do publish -all
>
> Users do expect forwarding to work.
>
> [In my case, I have an SPF record that rates limits the forwarding rate
> by any particular MTA]
>
> Philip
>
>>
>> --
>> Philip Gladstone
>> Distinguished Engineer
>> Product Development
>> pgladstone@cisco.com
>> Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
>> Google: +1 978 800 1010
>> Ham radio: N1DQ

In the early mid 2000s, when SPF was gaining momentum, its immediate 
appeal to me was that there was a defacto standard vehicle as a place to 
point others to when one of the company domains were abused by an email 
spammer.

Back then, very few systems supported SPF in the TXT RR (never mind the 
type 99 SPF RR, which was not even on the table at the time).  The issue 
was to have an authoritative place someone could see clearly where the 
domains we hold and control were allowed to send mail from.  I have 
always implemented the -all parameter and it has always worked for us.

So retrospect, it is really just a matter of perspective and 
expectations as to what SPF historically was really all about.  In our 
case that being, domain name reputation protection.

Alan M.


From msk@cloudmark.com  Fri Mar 16 09:47:35 2012
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 99D6821F877C for ; Fri, 16 Mar 2012 09:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.603
X-Spam-Level: 
X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 9xGuCp05kM1Q for ; Fri, 16 Mar 2012 09:47:35 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1801A21F8760 for ; Fri, 16 Mar 2012 09:47:35 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Fri, 16 Mar 2012 09:47:34 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
Thread-Index: AQHNAtU0v6G/xTBM2kufoZqHd8wpc5ZsLbGAgAAsWwCAADB5AIAANgwAgACACICAABFUAP//0RCQ
Date: Fri, 16 Mar 2012 16:47:34 +0000
Message-ID: <9452079D1A51524AA5749AD23E00392808EE42@exch-mbx901.corp.cloudmark.com>
References: <20120315175753.21172.qmail@joyce.lan> <5718697.q5mpy510na@scott-latitude-e6320> <4F6324C9.20101@tana.it> <2368238.z2f9qZKL6b@scott-latitude-e6320>
In-Reply-To: <2368238.z2f9qZKL6b@scott-latitude-e6320>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.20.2.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo	identities
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, 16 Mar 2012 16:47:35 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of Scott Kitterman
> Sent: Friday, March 16, 2012 5:34 AM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident=
ities
>=20
> > It seems that one of the following must be true:
> >
> > 1: gmail, or any other receiver, don't consider SPF results official,

It could be that they do, but only use it as input to a larger evaluation a=
lgorithm.

> 4.  Gmail is a very large, sophisticated mail operator run by a company
> with lots of expertise in assessing and correlating large volumes of
> data and uses both the data and the capability to determine likely
> forwarding paths and doesn't reject forwarded mail (independent of
> SPF) in order to avoid causing backscatter.

That's kind of the same thing, I think.

-MSK

From msk@cloudmark.com  Fri Mar 16 09:48:59 2012
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 A578E21F85ED for ; Fri, 16 Mar 2012 09:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.603
X-Spam-Level: 
X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 BMdj2WLr7h6E for ; Fri, 16 Mar 2012 09:48:59 -0700 (PDT)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4704A21F85DA for ; Fri, 16 Mar 2012 09:48:59 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Fri, 16 Mar 2012 09:48:58 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
Thread-Index: AQHNAtU0v6G/xTBM2kufoZqHd8wpc5ZsLbGAgAAsWwCAADB5AIAANgwAgACACICAACoxgIAABygA//+xkLA=
Date: Fri, 16 Mar 2012 16:48:58 +0000
Message-ID: <9452079D1A51524AA5749AD23E00392808EE5F@exch-mbx901.corp.cloudmark.com>
References: <20120315175753.21172.qmail@joyce.lan> <4F626362.7060405@cisco.com> <4F628C0C.4030803@gathman.org> <5718697.q5mpy510na@scott-latitude-e6320>	<4F6324C9.20101@tana.it> <4F63482D.8060105@cisco.com> <20120316142902.GF64669@verdi>
In-Reply-To: <20120316142902.GF64669@verdi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.20.2.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo	identities
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, 16 Mar 2012 16:48:59 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of John Leslie
> Sent: Friday, March 16, 2012 7:29 AM
> To: Philip Gladstone
> Cc: spfbis@ietf.org
> Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident=
ities
>=20
>    RFC 4408 has nothing to _resolve_ this tussle.
>=20
>    I doubt we can _resolve_ it in 4408bis either; but I hope we can
> explain it a bit better.

+1.

-MSK

From john@jlc.net  Fri Mar 16 09:49:36 2012
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 B71D421E8012 for ; Fri, 16 Mar 2012 09:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.356
X-Spam-Level: 
X-Spam-Status: No, score=-106.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 tgJl93HWL6LN for ; Fri, 16 Mar 2012 09:49:36 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 25C8A21E8035 for ; Fri, 16 Mar 2012 09:49:36 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 1FCED33C74; Fri, 16 Mar 2012 12:49:36 -0400 (EDT)
Date: Fri, 16 Mar 2012 12:49:36 -0400
From: John Leslie 
To: Scott Kitterman 
Message-ID: <20120316164936.GH64669@verdi>
References: <20120315175753.21172.qmail@joyce.lan> <4F6324C9.20101@tana.it> <4F63482D.8060105@cisco.com> <4472029.oVkT6GqL45@scott-latitude-e6320>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4472029.oVkT6GqL45@scott-latitude-e6320>
User-Agent: Mutt/1.4.1i
Cc: spfbis@ietf.org
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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, 16 Mar 2012 16:49:36 -0000

Scott Kitterman  wrote:
> 
> Forwarding does happen, but I think that it's rare enough that mail
> losses due to a combination of forwarding and SPF based rejection is
> a noise level issue in the scheme of the overall unreliability of email.

   Is that damning with faint praise??

   Seriously, I don't know how to put bounds on such losses. It may be
"noise-level". Even at "noise-level" I think it deserves some discussion
in 4408bis (though I doubt we'll come up with any mandatory protocol
changes).

> I'm, personally, a lot more worried about providers that break the
> reject or deliver paradigm and just drop email into a black hole for
> reasons that no doubt make sense to them.

   It is rather hard to delimit such reasons...

   Nonetheless, backscatter is a real problem; and I have seen threats
of blacklisting due to backscatter -- that's arguably a sufficient
reason. :^(

   I'd like to believe that SPF can help the backscatter problem. Some
discussion of this in 4408bis seems like a good idea...

--
John Leslie 

From spf2@kitterman.com  Fri Mar 16 10:23:58 2012
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 B004C21E8043 for ; Fri, 16 Mar 2012 10:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002,  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 FFW4szP3Or3q for ; Fri, 16 Mar 2012 10:23:58 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9C63421E8027 for ; Fri, 16 Mar 2012 10:23:53 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E9ECF20E40D0; Fri, 16 Mar 2012 13:23:52 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331918633; bh=eenSNC30I9hfzD2hjd03j+nvURbGkv0FJG2KFjRN99o=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=WeEGLWlnrw8q6dUh5L4u9TVfQcsYmd+2EJbwmyl00LqT4+WaxjD8VrjeL6uzDATGU ncdfA4xYSen7G+7F1zaIKGqjVjiK55zq2N70qZwwq3mOn5fBG0xP7GXjJcJlcmS94w MpxEjxP1BsvEe35RUkvVkmKNz578zIn5tQJx8KG4=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C9F0820E4089;  Fri, 16 Mar 2012 13:23:52 -0400 (EDT)
From: Scott Kitterman 
To: spfbis@ietf.org
Date: Fri, 16 Mar 2012 13:23:52 -0400
Message-ID: <6903649.1Kk6b2HWnu@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <20120316164936.GH64669@verdi>
References: <20120315175753.21172.qmail@joyce.lan> <4472029.oVkT6GqL45@scott-latitude-e6320> <20120316164936.GH64669@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] #12: RFC 4408 Section 9 - Forwarding and helo identities
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, 16 Mar 2012 17:23:58 -0000

On Friday, March 16, 2012 12:49:36 PM John Leslie wrote:
> Scott Kitterman  wrote:
> > Forwarding does happen, but I think that it's rare enough that mail
> > losses due to a combination of forwarding and SPF based rejection is
> > a noise level issue in the scheme of the overall unreliability of email.
> 
>    Is that damning with faint praise??
> 
>    Seriously, I don't know how to put bounds on such losses. It may be
> "noise-level". Even at "noise-level" I think it deserves some discussion
> in 4408bis (though I doubt we'll come up with any mandatory protocol
> changes).

I agree it's an issue, it just doesn't seem to be a major one.  It's covered 
in 4408 section 9 which, I think, has the right information, it just needs to 
be written a bit better and updated.

> > I'm, personally, a lot more worried about providers that break the
> > reject or deliver paradigm and just drop email into a black hole for
> > reasons that no doubt make sense to them.
> 
>    It is rather hard to delimit such reasons...
> 
>    Nonetheless, backscatter is a real problem; and I have seen threats
> of blacklisting due to backscatter -- that's arguably a sufficient
> reason. :^(
> 
>    I'd like to believe that SPF can help the backscatter problem. Some
> discussion of this in 4408bis seems like a good idea...

The term backscatter does not appear in 4408.  It should probably come up in 
4408bis.

Scott K

From vesely@tana.it  Fri Mar 16 11:09:17 2012
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 E89E521F8630 for ; Fri, 16 Mar 2012 11:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.657
X-Spam-Level: 
X-Spam-Status: No, score=-4.657 tagged_above=-999 required=5 tests=[AWL=0.062,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OETiOaqa7aPl for ; Fri, 16 Mar 2012 11:09:16 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id CD28821F85F6 for ; Fri, 16 Mar 2012 11:09:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1331921351; bh=R45ARmOeAna5SCtpd0syiLvSrPllqf+lLw15+hGAOwc=; l=1247; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=d8Jcgdu0SpgSTS9FleBdFL+dPcBHvhou8ezn7YOYleqJzFsXXVtk7vy1X75cZvYyj E2cQVJdhnQB3UprUcmk9pWoCkR4zg214lB3FQafcK1b37tYpYJPWMVh+DM7t5+RRZ7 gGuFLFDTfRQVl9dh9VLGSoiaryD/cDzCY0RSsFp4=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 16 Mar 2012 19:09:11 +0100 id 00000000005DC039.000000004F6381C7.00001312
Message-ID: <4F6381C7.1050001@tana.it>
Date: Fri, 16 Mar 2012 19:09:11 +0100
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120315175753.21172.qmail@joyce.lan> <4472029.oVkT6GqL45@scott-latitude-e6320> <20120316164936.GH64669@verdi> <6903649.1Kk6b2HWnu@scott-latitude-e6320>
In-Reply-To: <6903649.1Kk6b2HWnu@scott-latitude-e6320>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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, 16 Mar 2012 18:09:17 -0000

On 16/Mar/12 18:23, Scott Kitterman wrote:
> On Friday, March 16, 2012 12:49:36 PM John Leslie wrote:
>> Scott Kitterman  wrote:
>>> Forwarding does happen, but I think that it's rare enough that mail
>>> losses due to a combination of forwarding and SPF based rejection is
>>> a noise level issue in the scheme of the overall unreliability of email.
>> 
>>    Is that damning with faint praise??
>> 
>>    Seriously, I don't know how to put bounds on such losses. It may be
>> "noise-level". Even at "noise-level" I think it deserves some discussion
>> in 4408bis (though I doubt we'll come up with any mandatory protocol
>> changes).
> 
> I agree it's an issue, it just doesn't seem to be a major one.

It implies that either SPF stays at limited use, or that forwarding
gets deprecated, so that their combination can be ignored and will
eventually vanish.

> It's covered in 4408 section 9 which, I think, has the right
> information, it just needs to be written a bit better and updated.

Section 9 explains it very well, but doesn't solve it.  Are we
standardizing SPF in the hope that people will spontaneously fix
forwarding, and at that point, maybe, dare say that they fixed it
because it was broken?

From spf2@kitterman.com  Fri Mar 16 11:25:45 2012
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 8580021E806D for ; Fri, 16 Mar 2012 11:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002,  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 fiINghONDsXB for ; Fri, 16 Mar 2012 11:25:41 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3794521E8059 for ; Fri, 16 Mar 2012 11:25:41 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CF7D720E40D0; Fri, 16 Mar 2012 14:25:38 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331922338; bh=6c1IWGKYZcDVI2x8gvv7uFldiemCr5gqlnptfyi4YQA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=fKL7b6ddMkGmrXMs3ypfdEuvC9oNMtBNT77+jlsF3cHxM9O+KLzPa7XJJGyvbbuI3 yq8ZsfbZ1D6RubyDdzPJ2Yxuvk2l0S2ecC66G4jEVo1UA0nu8NYpG67Ge+gEiBC7Xl aa93uas5kYuezdEIEOB18yt16x6lHCO7u/BHwxqo=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B57BB20E4089;  Fri, 16 Mar 2012 14:25:38 -0400 (EDT)
From: Scott Kitterman 
To: spfbis@ietf.org
Date: Fri, 16 Mar 2012 14:25:38 -0400
Message-ID: <1961226.eMbsOy0Kc2@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <4F6381C7.1050001@tana.it>
References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320> <4F6381C7.1050001@tana.it>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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, 16 Mar 2012 18:25:45 -0000

On Friday, March 16, 2012 07:09:11 PM Alessandro Vesely wrote:
> On 16/Mar/12 18:23, Scott Kitterman wrote:
> > On Friday, March 16, 2012 12:49:36 PM John Leslie wrote:
> >> Scott Kitterman  wrote:
> >>> Forwarding does happen, but I think that it's rare enough that mail
> >>> losses due to a combination of forwarding and SPF based rejection is
> >>> a noise level issue in the scheme of the overall unreliability of
> >>> email.
> >>    Is that damning with faint praise??
> >>    
> >>    Seriously, I don't know how to put bounds on such losses. It may be
> >> "noise-level". Even at "noise-level" I think it deserves some
> >> discussion
> >> in 4408bis (though I doubt we'll come up with any mandatory protocol
> >> changes).
> > 
> > I agree it's an issue, it just doesn't seem to be a major one.
> 
> It implies that either SPF stays at limited use, or that forwarding
> gets deprecated, so that their combination can be ignored and will
> eventually vanish.

Forwarding is already a small niche.  From an SPF protocol design perspective 
I think it can be ignored.  As was said already somewhere in this thread, it's 
an attribute of SMTP that people who deploy SPF (both as record publishers and 
as checkers) will have to consider how to deal with.  Section 9 gives some 
advice on this.  We should improve that advice, but that's really all was can 
do.

> > It's covered in 4408 section 9 which, I think, has the right
> > information, it just needs to be written a bit better and updated.
> 
> Section 9 explains it very well, but doesn't solve it.  Are we
> standardizing SPF in the hope that people will spontaneously fix
> forwarding, and at that point, maybe, dare say that they fixed it
> because it was broken?

It is quite possible to check SPF at SMTP time and reject on SPF Fail without 
rejecting mail due to forwarding.  I've written software that gives 
administrators the tools to do it (tools are the easy part - knowing what data 
to put in the tools is harder), but mostly it doesn't scale for large 
operators.

At the other end of the scale, you have massive operators like Gmail who can 
use SPF and other inputs to figure out who the forwarders are and not reject 
based on SPF for such hosts.

None of it's easy, but it's fundamentally doable if the receiver cares to.  No 
matter what we write in an RFC, we can't make them care.

There are other possibilities that are clearly out of scope for SPFbis.  DMARC 
proposed to use SPF and DKIM in combination.  Their protocol 'handles' 
forwarding.

Perhaps, someday, someone will understand the situation well enough to write 
an applicability statement that explains all about how to integrate SMTP 
forwarding and SPF, but I don't think there's anything much beyone a better 
written section 9 we can do in 4408bus.

Scott K

From dhc@dcrocker.net  Fri Mar 16 13:08:51 2012
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 573CA21F85F9 for ; Fri, 16 Mar 2012 13:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.606
X-Spam-Level: 
X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 U42Y3WXZ+Mbx for ; Fri, 16 Mar 2012 13:08:50 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9403F21F85F1 for ; Fri, 16 Mar 2012 13:08:50 -0700 (PDT)
Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2GK8he0010788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Mar 2012 13:08:50 -0700
Message-ID: <4F638A10.2070304@dcrocker.net>
Date: Fri, 16 Mar 2012 11:44:32 -0700
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <6.2.5.6.2.20120306091044.0b9a15b0@elandnews.com> <3321896.9R8WsgF0d8@scott-latitude-e6320>
In-Reply-To: <3321896.9R8WsgF0d8@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.17]); Fri, 16 Mar 2012 13:08:50 -0700 (PDT)
Subject: [spfbis] Scope of effects for a change
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: Fri, 16 Mar 2012 20:08:51 -0000

On 3/6/2012 9:27 AM, Scott Kitterman wrote:
> This proposal may affect currently published and RFC 4408 compliant records as
> it is silent on this type of limitation.

I don't recall seeing the general issue raised, but I easily could have missed it:

In talking about possible changes to the specifications and the degree to which 
there is installed base that uses the existing text, it's worth distinguishing 
between:

      1.  Changes to the syntax or semantics of the SPF DNS records.  These 
affect what the owner of the associated domain intends or has to do;

      2.  Changes to the use of DNS records at the SMTP server side.

It is possible to have no changes in either the bits in the DNS record or the 
formal interpretion of them, but still have the consumer of the bits -- 
processing at the SMTP-server's side -- be different.

The scope of effect for #1 is quite broad.

The scope of effect for #2 is less broad.  Of course there is still a big 
difference between changes of this type that are entirely incompatible with 
whatever installed base in using the existing spec, versus changes that permit 
the old behavior continue.

I thought it worth highlighting this issue, for our considerations of changes 
that have greater or lesser effects on the installed base.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From johnl@iecc.com  Fri Mar 16 15:12:52 2012
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 3D08121E808E for ; Fri, 16 Mar 2012 15:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.335
X-Spam-Level: 
X-Spam-Status: No, score=-110.335 tagged_above=-999 required=5 tests=[AWL=0.864, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 DDu1OcWZxErg for ; Fri, 16 Mar 2012 15:12:51 -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 5C7C321E801A for ; Fri, 16 Mar 2012 15:12:51 -0700 (PDT)
Received: (qmail 74039 invoked from network); 16 Mar 2012 22:12:49 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 16 Mar 2012 22:12:49 -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:vbr-info; s=4f63bae1.xn--hew.k1203; i=johnl@user.iecc.com; bh=6vdzLgn8Cup/N86/Wx3j08G1KcoGrn3a+A7gabqBw54=; b=jRhoVSmI6J7tXNOkNqMAEnJ5Iye/depMb8zHwyhWbpx5R4VepZgPeeZD+Ykhpo8364hmWZw9Qwd4jnmxbo+CkqxCbwBaai5Q4ErlArzvwoib5s+DQleKKTuCvI5zby1+Tift//bAmOknyZ9glD6F2xyCclmc8Bt02+xmd7rwonY=
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:vbr-info; s=4f63bae1.xn--hew.k1203; olt=johnl@user.iecc.com; bh=6vdzLgn8Cup/N86/Wx3j08G1KcoGrn3a+A7gabqBw54=; b=lN4BnLQSw9qbPmbyhCHnaGdI9il//c+bHM0P5XPfKs6EsGUXeJ6bWXyotOGbroVXzuSWS4nVNLDe39FVIol8UDExle538Pcd607W5WgU245Ce/j+3Rb0Fk6xgr/cBHrEVOljvdeqy0C56DdI0KCGUAvVpaC70f6avnf+7OzZqlg=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 16 Mar 2012 22:12:27 -0000
Message-ID: <20120316221227.14457.qmail@joyce.lan>
From: "John Levine" 
To: spfbis@ietf.org
In-Reply-To: <1961226.eMbsOy0Kc2@scott-latitude-e6320>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Cc: spf2@kitterman.com
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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, 16 Mar 2012 22:12:52 -0000

>Forwarding is already a small niche.

Forwarding is a small niche, but people collecting and sending mail at sites separate
from their home domain (typically doing so at Gmail or Yahoo) is a growing niche.
It has all the same issues as forwarding, it's not going away, SPF does what it does.

R's,
John

From dotis@mail-abuse.org  Fri Mar 16 17:46:59 2012
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 0FB7B21E8014 for ; Fri, 16 Mar 2012 17:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.411
X-Spam-Level: 
X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 XzcvC7V+qD0Y for ; Fri, 16 Mar 2012 17:46:58 -0700 (PDT)
Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7574921E807B for ; Fri, 16 Mar 2012 17:46:58 -0700 (PDT)
Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id DC62C1740165 for ; Sat, 17 Mar 2012 00:46:57 +0000 (UTC)
Message-ID: <4F63DF01.8090208@mail-abuse.org>
Date: Fri, 16 Mar 2012 17:46:57 -0700
From: Douglas Otis 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <4F621651.2020000@cisco.com> <4F629618.7000108@mail-abuse.org> <1611031.Oj2UJhZdgh@scott-latitude-e6320>
In-Reply-To: <1611031.Oj2UJhZdgh@scott-latitude-e6320>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Sat, 17 Mar 2012 00:46:59 -0000

On 3/15/12 8:39 PM, Scott Kitterman wrote:
> On Thursday, March 15, 2012 06:23:36 PM Douglas Otis wrote:
> ...
>> Host checks default to "postmaster" when local-parts are not included
>> for various reasons such as with NDNs or EHLO checks.  Use of local-part
>> macros relinquishes sender's control over authorized sources.
>> Substituting "postmaster" protects against possible abuse of the
>> recipient's resources, which should be considered a good practice.
> ...
>
> After the first sentence, this is incorrect.
>
> The use of local-part macros does exactly the opposite of that.  It enables
> the sender to set per-user SPF policies.
Dear Scott,

Senders should internally assert their per-user policies before sending 
and not place this burden on recipients.

The SPF left to right process concludes when a mechanism matches and 
qualifiers are returned.  To constrain possible sources in combination 
with possible local-parts, merged resource record references must be 
used.  This expects recipients to query unique resource records for 
every source address prefix, times the number of local-parts handled.

Local-part macros used in this fashion will place a large burden on 
recipient resources.  A domain sourcing 15 million local-parts from N 
number of unique prefixes represents a _significant_ increase in the 
consumption of recipient resources.  The level of this consumption is 
further exacerbated by the SPF process being unable to cache results 
based on domains since results may include local-part macros.

So even when exactly the same identifier is checked, the full set of DNS 
transactions must occur where a reduction of repeated transactions 
against authoritative servers relies fully upon prior transactions 
remaining in the recipient's cache.  But when transactions return 
no-data, caching durations may be fairly short and not comply with the 
authoritative domains expectations.  Malefactors are able to send 
messages continuously from different sources and domains while still 
exploiting the same evil MX resource records having non-existent targets 
within the victim's domain.  While the MX record itself gets cached, the 
contained targets may have already expired from the cache.  SPF's lack 
of no-data errors makes such strategies extremely easy to configure.
> There's no abuse of recipient resources here.  Yes, SPF records that use
> local-part macros can't be globally cached, so there might be some increased
> DNS usage, but there's no abuse.  Should this ever prove to be a problem in
> practice, receivers are free to skip SPF checks on such messages.
There is no reasonable justification for continuing both a dangerous and 
unnecessary practice.  Those running MTAs are extremely unlikely to know 
whether they are participating in a distributed denial of service 
attack.  Victims of such attacks will likely see thousands of legitimate 
sources for an attack while being unsure whether sources have been 
spoofed.  All thanks to SPF local-part macros.
> Limiting local-part macros to always use postmaster is functionally equivalent
> to removing the macro.  This would break backwards compatibility with a
> feature that's in use and there's no reason to go there.
Substituting postmaster will not break compatibility.  This simply 
requires restrictions on local-parts be done by senders prior to sending.

In the few cases I have seen this mechanism used, it was to allow users 
to send from _any_ source.   When used in this fashion, SPF 
confirmations place recipients at risk of being deceived.  There is no 
reasonable justification for continuing support for this seldom used and 
poorly considered "feature".

Regards,
Douglas Otis


From pgladstone@cisco.com  Fri Mar 16 21:22:06 2012
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 70E5421F8656 for ; Fri, 16 Mar 2012 21:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.319
X-Spam-Level: 
X-Spam-Status: No, score=-9.319 tagged_above=-999 required=5 tests=[AWL=0.679,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8]
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 pkesRqVtLp5D for ; Fri, 16 Mar 2012 21:22:05 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 07D7721F864A for ; Fri, 16 Mar 2012 21:22:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=9178; q=dns/txt; s=iport; t=1331958125; x=1333167725; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=24SwBR+Z1jE+LdrmBBbFrkw18Do8ObLsn33EyNs2GqU=; b=Oa4TRvFKsSgVBfPN8+KhlUJ4uNfB1OC6i8QoOu/ThoGRj3SRZnnIUuDI Vk8HNuzl8oyuZUnUJvNZ6dmJ3sHjNnCkuKpmoe87e+Qqnl1QWbm1uqGHd cc/NOjJGIJWE0z03bKroJBE6UgVonVgdgsgO0ddtjB6VtDgYuUBhgxANF E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AssGAOIQZE+tJXG9/2dsb2JhbAA/A4MNgjGxAYEHggkBAQEEEgEQZAIJAhgJIQICDwIKPBMGAgEBHodomluNBJIdBIpCgwyCEYEWBJVmhWyIU4FogwKBQA
X-IronPort-AV: E=Sophos;i="4.73,602,1325462400"; d="scan'208,217";a="67223281"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 17 Mar 2012 04:21:58 +0000
Received: from [10.117.107.25] (rtp-pgladsto-8918.cisco.com [10.117.107.25]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2H4LveE021512 for ; Sat, 17 Mar 2012 04:21:57 GMT
Message-ID: <4F641164.10602@cisco.com>
Date: Sat, 17 Mar 2012 00:21:56 -0400
From: Philip Gladstone 
Organization: Cisco Systems, Inc
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <4F621651.2020000@cisco.com> <4F629618.7000108@mail-abuse.org> <1611031.Oj2UJhZdgh@scott-latitude-e6320> <4F63DF01.8090208@mail-abuse.org>
In-Reply-To: <4F63DF01.8090208@mail-abuse.org>
Content-Type: multipart/alternative; boundary="------------080300060307040904000906"
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Sat, 17 Mar 2012 04:22:06 -0000

This is a multi-part message in MIME format.
--------------080300060307040904000906
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable



On 3/16/2012 8:46 PM, Douglas Otis wrote:
> Dear Scott,
>
> Senders should internally assert their per-user policies before=20
> sending and not place this burden on recipients.
This makes no sense. The *purpose* of SPF is to allow the origin domain=20
to express policies about which MTAs are authorized to send mail=20
purporting to come from the origin domain. Can you please explain=20
exactly why an unauthorized sender (aka spammer) should assert my (the=20
purported origin domain) per-user policies before sending? If the=20
spammers obeyed my policies, then we wouldn't have spam any more!
> Local-part macros used in this fashion will place a large burden on=20
> recipient resources.  A domain sourcing 15 million local-parts from N=20
> number of unique prefixes represents a _significant_ increase in the=20
> consumption of recipient resources.

I also don't understand what 'resources' you are referring to when you=20
claim a _significant_ increase in resources. Are you referring to CPU=20
time, Disk bandwidth, Memory consumption, Network bandwidth, electricity =

use or what? My feeling is that the use of local-part macros increases=20
the number of DNS lookups by (probably) 1 per mechanism that uses a=20
local part macro. Is this increase significant in terms of CPU? I doubt=20
it as spam filtering is computationally very expensive. Disk bandwidth=20
-- I doubt that the DNS lookup by the receiving MTA involves any disk=20
IO. For memory, there may be an increase of the order of 1K in a DNS=20
cache. Sensible policies on the TTL of the record will mean that this=20
record only remains cached for a short period of time. In terms of=20
network bandwidth, the consumption is probably under 1K travelling from=20
receiving MTA to authoritative DNS server managed by the origin domain.
> The level of this consumption is further exacerbated by the SPF=20
> process being unable to cache results based on domains since results=20
> may include local-part macros.
SPF can still cache domain results in exactly the same way. All that the =

use of local part macros does is to reduce the hit rate of the cache=20
somewhat. In the records that appear to be in use that use local-part=20
macros, there are three groups:

1) Those which appear to use it as a fallback after a/mx/ptr records.=20
Presumably, most valid mail gets through the first checks and the local=20
part macro is only tested for forged mail

2) Those which do all the checks using one big macro record. E.g.=20
'v=3Dspf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all'

3) Those which have rather different policies for each local-part. These =

records use redirect or include to fetch a per-local-part policy.

Having said all that, there are very few records that use macros at all:

     45: %{d}
     30: %{h}
     28: %{ir}
   1386: %{i}
    126: %{l1r+}
      1: %{l1r-}
     41: %{l}
     19: %{o}
     11: %{r}
     40: %{s}
      2: %{v}

The first column is the count, and the second is the macro. This is from =

my 280k SPF record dump. I.e. less than 1% use macros, but the=20
local-part macro is second only to the source IP in usage.

Is there an increase in consumption if I add an=20
exists:%{l1r-}.user.spf.%{d) clause. Yes. Is it significant. No. [Note=20
that I can cause *exactly* the same increase in consumption if I add=20
a:mumble.spf.%{d} and always return a record with a TTL of 0]

I just don't see that the resource increase is noticeable by comparison=20
with the cost of handling the email. I don't know about you, but my=20
email feed runs at around 95% spam and most of the resource is spent=20
discarding it.

Philip

--=20
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ


--------------080300060307040904000906
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    

    On 3/16/2012 8:46 PM, Douglas Otis wrote:
    
Dear
      Scott,
      

      

      Senders should internally assert their per-user policies before
      sending and not place this burden on recipients.
      

    

    This makes no sense. The *purpose* of SPF is to allow the origin
    domain to express policies about which MTAs are authorized to send
    mail purporting to come from the origin domain. Can you please
    explain exactly why an unauthorized sender (aka spammer) should
    assert my (the purported origin domain) per-user policies before
    sending? If the spammers obeyed my policies, then we wouldn't have
    spam any more!

    
Local-part macros used in this fashion will
      place a large burden on recipient resources.  A domain sourcing 15
      million local-parts from N number of unique prefixes represents a
      _significant_ increase in the
      consumption of recipient resources. 

    

    

    I also don't understand what 'resources' you are referring to when
    you claim a _significant_ increase in resources. Are you referring
    to CPU time, Disk bandwidth, Memory consumption, Network bandwidth,
    electricity use or what? My feeling is that the use of local-part
    macros increases the number of DNS lookups by (probably) 1 per
    mechanism that uses a local part macro. Is this increase significant
    in terms of CPU? I doubt it as spam filtering is computationally
    very expensive. Disk bandwidth -- I doubt that the DNS lookup by the
    receiving MTA involves any disk IO. For memory, there may be an
    increase of the order of 1K in a DNS cache. Sensible policies on the
    TTL of the record will mean that this record only remains cached for
    a short period of time. In terms of network bandwidth, the
    consumption is probably under 1K travelling from receiving MTA to
    authoritative DNS server managed by the origin domain.

    
 The level of this consumption is further
      exacerbated by the SPF process being unable to cache results based
      on domains since results may include local-part macros. 

    

    SPF can still cache domain results in exactly the same way. All that
    the use of local part macros does is to reduce the hit rate of the
    cache somewhat. In the records that appear to be in use that use
    local-part macros, there are three groups:

    

    1) Those which appear to use it as a fallback after a/mx/ptr
    records. Presumably, most valid mail gets through the first checks
    and the local part macro is only tested for forged mail

    

    2) Those which do all the checks using one big macro record. E.g.
    'v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all'

    

    3) Those which have rather different policies for each local-part.
    These records use redirect or include to fetch a per-local-part
    policy.

    

    Having said all that, there are very few records that use macros at
    all:

    

        45: %{d}

        30: %{h}

        28: %{ir}

      1386: %{i}

       126: %{l1r+}

         1: %{l1r-}

        41: %{l}

        19: %{o}

        11: %{r}

        40: %{s}

         2: %{v}

    

    The first column is the count, and the second is the macro. This is
    from my 280k SPF record dump. I.e. less than 1% use macros, but the
    local-part macro is second only to the source IP in usage.

    

    Is there an increase in consumption if I add an
    exists:%{l1r-}.user.spf.%{d) clause. Yes. Is it significant. No.
    [Note that I can cause *exactly* the same increase in consumption if
    I add a:mumble.spf.%{d} and always return a record with a TTL of 0]

    

    I just don't see that the resource increase is noticeable by
    comparison with the cost of handling the email. I don't know about
    you, but my email feed runs at around 95% spam and most of the
    resource is spent discarding it.

    

    Philip

    

    
-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ


  


--------------080300060307040904000906--

From dotis@mail-abuse.org  Sun Mar 18 23:30:59 2012
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 9C8A121F8596 for ; Sun, 18 Mar 2012 23:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.259
X-Spam-Level: 
X-Spam-Status: No, score=-102.259 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, 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 sAkJFmpMlS6T for ; Sun, 18 Mar 2012 23:30:59 -0700 (PDT)
Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id F01C321F853D for ; Sun, 18 Mar 2012 23:30:58 -0700 (PDT)
Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id C82F21740171 for ; Mon, 19 Mar 2012 06:30:57 +0000 (UTC)
Message-ID: <4F66D2A1.30304@mail-abuse.org>
Date: Sun, 18 Mar 2012 23:30:57 -0700
From: Douglas Otis 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <4F621651.2020000@cisco.com> <4F629618.7000108@mail-abuse.org> <1611031.Oj2UJhZdgh@scott-latitude-e6320> <4F63DF01.8090208@mail-abuse.org> <4F641164.10602@cisco.com>
In-Reply-To: <4F641164.10602@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Mon, 19 Mar 2012 06:30:59 -0000

On 3/16/12 9:21 PM, Philip Gladstone wrote:
> On 3/16/2012 8:46 PM, Douglas Otis wrote:
>> Dear Scott,
>>
>> Senders should internally assert their per-user policies before 
>> sending and not place this burden on recipients.
> This makes no sense. The *purpose* of SPF is to allow the origin 
> domain to express policies about which MTAs are authorized to send 
> mail purporting to come from the origin domain. Can you please explain 
> exactly why an unauthorized sender (aka spammer) should assert my (the 
> purported origin domain) per-user policies before sending? If the 
> spammers obeyed my policies, then we wouldn't have spam any more! 
Dear Philip,

SPF authorized sources should allow recipients to assume user level 
controls have already been applied!  Processing local-part macros 
entails additional DNS transactions requiring a substantial increase in 
DNS caching and SMTP session durations.  This expects a local-part macro 
process will be applied against sub-domains illustrated by your example 
whenever a different user is seen from the SPF domain.

Fortunately few use this method so there is no good record supporting 
the utility or scalability of local-part macros.  The use of local-part 
or i macros also prevents use of SPF to identify the range of IP 
addresses used by the domain, which represents SPF's greatest utility.
>> Local-part macros used in this fashion will place a large burden on 
>> recipient resources.  A domain sourcing 15 million local-parts from N 
>> number of unique prefixes represents a _significant_ increase in the 
>> consumption of recipient resources.
> I also don't understand what 'resources' you are referring to when you 
> claim a _significant_ increase in resources. Are you referring to CPU 
> time, Disk bandwidth, Memory consumption, Network bandwidth, 
> electricity use or what? 
All of the above, in addition to increasing the potential amplification 
for reflected attacks off of recipients resolving local-part macros.  
This represents a significant concern since the exists and every other 
mechanism supporting local-part macros are assumed to potentially occur 
against non-existent resources any number of times without necessarily 
affecting the results returned.
> My feeling is that the use of local-part macros increases the number 
> of DNS lookups by (probably) 1 per mechanism that uses a local part 
> macro. Is this increase significant in terms of CPU? I doubt it as 
> spam filtering is computationally very expensive. Disk bandwidth -- I 
> doubt that the DNS lookup by the receiving MTA involves any disk IO. 
> For memory, there may be an increase of the order of 1K in a DNS 
> cache. Sensible policies on the TTL of the record will mean that this 
> record only remains cached for a short period of time. In terms of 
> network bandwidth, the consumption is probably under 1K travelling 
> from receiving MTA to authoritative DNS server managed by the origin 
> domain.
http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01

Ignore the text and just review the log.  Assuming only the Mail From 
identity is checked, the log shows 34.8K bytes from victim's name 
servers responding to 28.8K bytes of requests by recipients for every 
message containing a different local-part.  A different local-part for 
every message is not unusual in spam campaigns.  Spammers may minimize 
their traffic by waiting to repeat local-parts after typical negative 
cache durations.  Once their evil MX record sets supporting their 
campaign have been cached, nearly the entire follow-on DNS traffic will 
be carried almost exclusively by recipients.  These durations normally 
override any requested negative cache duration and are also likely to be 
flushed anyway.

You would need to assume local-part macros are not used abusively to 
arrive at perhaps a 1K byte/user increase in the DNS traffic.  This 
issue must still consider there are millions of local-parts used per 
domain non-abusively.  Once the number of users per domain are 
considered this quickly becomes a problem without there being any 
malicious use of this feature.
>> The level of this consumption is further exacerbated by the SPF 
>> process being unable to cache results based on domains since results 
>> may include local-part macros.
> SPF can still cache domain results in exactly the same way. All that 
> the use of local part macros does is to reduce the hit rate of the 
> cache somewhat. In the records that appear to be in use that use 
> local-part macros, there are three groups:
>
> 1) Those which appear to use it as a fallback after a/mx/ptr records. 
> Presumably, most valid mail gets through the first checks and the 
> local part macro is only tested for forged mail
>
> 2) Those which do all the checks using one big macro record. E.g. 
> 'v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all'
>
> 3) Those which have rather different policies for each local-part. 
> These records use redirect or include to fetch a per-local-part policy.
>
> Having said all that, there are very few records that use macros at all:
>
>     45: %{d}
>     30: %{h}
>     28: %{ir}
>   1386: %{i}
>    126: %{l1r+}
>      1: %{l1r-}
>     41: %{l}
>     19: %{o}
>     11: %{r}
>     40: %{s}
>      2: %{v}
>
> The first column is the count, and the second is the macro. This is 
> from my 280k SPF record dump. I.e. less than 1% use macros, but the 
> local-part macro is second only to the source IP in usage.
>
> Is there an increase in consumption if I add an 
> exists:%{l1r-}.user.spf.%{d) clause. Yes. Is it significant. No. [Note 
> that I can cause *exactly* the same increase in consumption if I add 
> a:mumble.spf.%{d} and always return a record with a TTL of 0]
An SPF record such as this would allow anyone to spoof messages from the 
domain.  It would need to include some form of the i macro as well.
> I just don't see that the resource increase is noticeable by 
> comparison with the cost of handling the email. I don't know about 
> you, but my email feed runs at around 95% spam and most of the 
> resource is spent discarding it.
When you know 95% of SPF records processed are on behalf of malefactors, 
every transaction that might be directed against any domain, especially 
those allowed to return no data,  creates an unnecessary risk especially 
for worthless overhead supporting local-part macros.   A safe and 
pragmatic solution would be to swap all local-parts with "postmaster".

Regards,
Douglas Otis



From pgladstone@cisco.com  Mon Mar 19 06:22:05 2012
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 6D77421F867B for ; Mon, 19 Mar 2012 06:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.228
X-Spam-Level: 
X-Spam-Status: No, score=-8.228 tagged_above=-999 required=5 tests=[AWL=1.770,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8]
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 PpGJ8p0TpgAd for ; Mon, 19 Mar 2012 06:22:04 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6160221F8582 for ; Mon, 19 Mar 2012 06:22:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=2061; q=dns/txt; s=iport; t=1332163323; x=1333372923; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=dVRTvgyxRic2eb6IXBbaSJ6CvVcN6p024klT0Lk0Kco=; b=ZOIyapwlqD5gtAXeKsjvJGe+sdfQ0V34UAx1kF434uVfRfSc/8GIunah LGAQD/x4qzJqN6IHhoGtJ8VQo+exGYeTHvBNUH+rqkxD/2w18PyVXkeAp vn0oLzqWivKPFjID40Y1QWSXB2u8S7i6BgAUkVDrg0KuYSu6MIH9asa2E Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAKAxZ0+tJXG+/2dsb2JhbAA/A4VHsQyBB4IJAQEBBBIBEGQCCwQBEwkhAgIPAgo8EwYCAQEeh2ifG40EiXAEjVEFggyBFgSVaIVtiFOBaIMC
X-IronPort-AV: E=Sophos;i="4.73,611,1325462400"; d="scan'208,217";a="67347300"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 19 Mar 2012 13:22:03 +0000
Received: from [161.44.106.143] (dhcp-161-44-106-143.cisco.com [161.44.106.143]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2JDM2bY010323 for ; Mon, 19 Mar 2012 13:22:02 GMT
Message-ID: <4F6732F7.30105@cisco.com>
Date: Mon, 19 Mar 2012 09:21:59 -0400
From: Philip Gladstone 
Organization: Cisco Systems, Inc
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <4F621651.2020000@cisco.com> <4F629618.7000108@mail-abuse.org> <1611031.Oj2UJhZdgh@scott-latitude-e6320> <4F63DF01.8090208@mail-abuse.org> <4F641164.10602@cisco.com> <4F66D2A1.30304@mail-abuse.org>
In-Reply-To: <4F66D2A1.30304@mail-abuse.org>
Content-Type: multipart/alternative; boundary="------------060404050908030002030505"
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Mon, 19 Mar 2012 13:22:05 -0000

This is a multi-part message in MIME format.
--------------060404050908030002030505
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 3/19/2012 2:30 AM, Douglas Otis wrote:
>
> SPF authorized sources should allow recipients to assume user level 
> controls have already been applied!

One question:   What entity is supposed to have applied these user level 
controls? Note that in the case that it is not the authorized domain 
sending traffic, then the authorized domain does not have any chance to 
apply user level controls.

What am I missing?

Philip

-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ


--------------060404050908030002030505
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    

    On 3/19/2012 2:30 AM, Douglas Otis wrote:

    

      

      SPF authorized sources should allow recipients to assume user
      level controls have already been applied!  

    

    

    One question:   What entity is supposed to have applied these user
    level controls? Note that in the case that it is not the authorized
    domain sending traffic, then the authorized domain does not have any
    chance to apply user level controls.

    

    What am I missing?

    

    Philip

    
-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ


  


--------------060404050908030002030505--

From spf2@kitterman.com  Mon Mar 19 06:32:08 2012
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 36B6321F853D for ; Mon, 19 Mar 2012 06:32:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002,  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 PZ2PuPg-sgAX for ; Mon, 19 Mar 2012 06:32:07 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEA721F850C for ; Mon, 19 Mar 2012 06:32:07 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0567220E40BD; Mon, 19 Mar 2012 09:32:06 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332163926; bh=1qDrBTSe5K+1BYSTQssN5H9sfiIUP7eNMvIwdopdG5Q=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=L6pqfDmmWjBDtanIjVstd7kkO1YJd5yCH1WOe02yQ2J/e2BqlY5ZTsoxgrHIySCPR a/HtKCf/OX/k8G9HT66aveRbZNUfhfy/BHKTaJWFGcp75TKqCaZZOtCdNFhkCbPB3x FPr9kpH9MI95LFWe51gcApWwJ2badOPfF3oJ6M24=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DC4F420E40A4;  Mon, 19 Mar 2012 09:32:05 -0400 (EDT)
From: Scott Kitterman 
To: spfbis@ietf.org
Date: Mon, 19 Mar 2012 09:32:05 -0400
Message-ID: <1464793.ZEWILd8cXx@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <4F66D2A1.30304@mail-abuse.org>
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <4F641164.10602@cisco.com> <4F66D2A1.30304@mail-abuse.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Mon, 19 Mar 2012 13:32:08 -0000

On Sunday, March 18, 2012 11:30:57 PM Douglas Otis wrote:
> SPF authorized sources should allow recipients to assume user level 
> controls have already been applied!  

This doesn't make any sense.  The point of per-user policies is that they are, 
in fact, per user.

All you are saying in this thread is you don't think SPF should have per-user 
policies.  I get that, but the fact is it does and the feature is in use.

Scott L

From dotis@mail-abuse.org  Mon Mar 19 11:01:44 2012
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 7ED4421F8811 for ; Mon, 19 Mar 2012 11:01:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.417
X-Spam-Level: 
X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 nYlz09WFwDEC for ; Mon, 19 Mar 2012 11:01:43 -0700 (PDT)
Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6CD21F880D for ; Mon, 19 Mar 2012 11:01:43 -0700 (PDT)
Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 1B5BF1740425 for ; Mon, 19 Mar 2012 18:01:43 +0000 (UTC)
Message-ID: <4F677486.9080001@mail-abuse.org>
Date: Mon, 19 Mar 2012 11:01:42 -0700
From: Douglas Otis 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <4F641164.10602@cisco.com> <4F66D2A1.30304@mail-abuse.org> <1464793.ZEWILd8cXx@scott-latitude-e6320>
In-Reply-To: <1464793.ZEWILd8cXx@scott-latitude-e6320>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Mon, 19 Mar 2012 18:01:44 -0000

On 3/19/12 6:32 AM, Scott Kitterman wrote:
> On Sunday, March 18, 2012 11:30:57 PM Douglas Otis wrote:
>> SPF authorized sources should allow recipients to assume user level
>> controls have already been applied!
> This doesn't make any sense.  The point of per-user policies is that they are,
> in fact, per user.
Dear Scott,

SPF offers authorizations for outbound domains ensuring return of NDNs 
or to declare the IP addresses used by domain's outbound servers.  These 
addresses can then construct white-lists or resolve reputation services 
blocking the domain.  This utility represents easily more than 99% of 
current uses for SPF not compatible with User level control without a 
general agreement "postmaster" as a local-part always enumerates these 
addresses.

Expecting recipients to impose user level controls on behalf of senders 
is highly ill considered nor has such use been widely implemented except 
in rare cases.  The current macro processing structure ignores the 
100/200/400 transactions that ignore the occurrences of no-data errors 
(depending upon use of spf/txt resource records and Mail From/EHLO 
identity options).

The EHLO processing is still able to exploit the 10 x gain offered by 
the 10 MX mechanisms simply by spoofing EHLO sub-domains.  Based upon 
current SPF specification, the use of macros and insensitivity to 
no-data errors permits a 1 KB message to generate (34.8KB +28.8 KB) x 4 
or 254KB of victim traffic against any domain that simply supports DNS.  
The victim domain does not even need to offer MX/TXT/spf resource records.
> All you are saying in this thread is you don't think SPF should have per-user
> policies.  I get that, but the fact is it does and the feature is in use.
This is a poorly considered and rarely used feature nor does User level 
control based upon local-part macros serve a valid purpose.  SPF should 
not authorize untrusted outbound servers!  DKIM provides a safer and 
more practical means to ensure control of email header fields.  SPF was 
never intended to ensure an identity used in email header fields nor can 
this mechanism be expected to scale for such use even when extended by 
another protocol that attempts to restrict these fields based upon the 
unseen Mail From parameter.

Regards,
Douglas Otis






From ajs@anvilwalrusden.com  Mon Mar 19 11:16:05 2012
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 44CE221F8851 for ; Mon, 19 Mar 2012 11:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.483
X-Spam-Level: 
X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116,  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 D0U8Ua05ili1 for ; Mon, 19 Mar 2012 11:16:04 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD3121F87F7 for ; Mon, 19 Mar 2012 11:16:04 -0700 (PDT)
Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 41A211ECB41D for ; Mon, 19 Mar 2012 18:15:54 +0000 (UTC)
Date: Mon, 19 Mar 2012 14:15:44 -0400
From: Andrew Sullivan 
To: spfbis@ietf.org
Message-ID: <20120319181543.GC45974@mail.yitter.info>
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <4F641164.10602@cisco.com> <4F66D2A1.30304@mail-abuse.org> <1464793.ZEWILd8cXx@scott-latitude-e6320> <4F677486.9080001@mail-abuse.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4F677486.9080001@mail-abuse.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Mon, 19 Mar 2012 18:16:05 -0000

Hi Doug,

On Mon, Mar 19, 2012 at 11:01:42AM -0700, Douglas Otis wrote:

> senders is highly ill considered nor has such use been widely
> implemented except in rare cases. 

Just as a point of information: is that a positivice claim that it has
been implemented (though rarely); or are you really saying that as far
as you know it's unimplemented, but you're not willing to say "never"?

> SPF should not authorize untrusted outbound servers!  DKIM provides
> a safer and more practical means to ensure control of email header
> fields.

Please check our charter; we have some pretty strict limits on what we
are allowed to do:

      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.

Are you claiming that the feature is unused, or that it is an error?

Best,

A


-- 
Andrew Sullivan
ajs@anvilwalrusden.com

From ajs@anvilwalrusden.com  Mon Mar 19 11:17:25 2012
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 6179021F88C2 for ; Mon, 19 Mar 2012 11:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.484
X-Spam-Level: 
X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115,  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 aN285LgHUJnu for ; Mon, 19 Mar 2012 11:17:25 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id DD9C021F88C1 for ; Mon, 19 Mar 2012 11:17:24 -0700 (PDT)
Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4A3F81ECB41D for ; Mon, 19 Mar 2012 18:17:24 +0000 (UTC)
Date: Mon, 19 Mar 2012 14:17:22 -0400
From: Andrew Sullivan 
To: spfbis@ietf.org
Message-ID: <20120319181722.GD45974@mail.yitter.info>
References: <6.2.5.6.2.20120314103632.0a451d08@elandnews.com> <1582246.ifGuAyB4YY@scott-latitude-e6320>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1582246.ifGuAyB4YY@scott-latitude-e6320>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [spfbis] Draft agenda for IETF83
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 Mar 2012 18:17:25 -0000

Dear colleagues,

On Wed, Mar 14, 2012 at 02:38:48PM -0400, Scott Kitterman wrote:
> 
> I think this would be a waste of the group's time.

John Levine sent a similar remark.

Do people have other things they want on the agenda?  There was little
feedback apart from these two suggestions.  We plan to alter the
agenda, and if there are other changes people want I'd like to hear
them.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

From dotzero@gmail.com  Mon Mar 19 11:23:26 2012
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 1501221F886C for ; Mon, 19 Mar 2012 11:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 yVdeT4EgJNpm for ; Mon, 19 Mar 2012 11:23:25 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB0221F8869 for ; Mon, 19 Mar 2012 11:23:25 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so1339442pbb.31 for ; Mon, 19 Mar 2012 11:23: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:content-transfer-encoding; bh=y0Eanh02FHGnqcneVnAvE6XuvwMNfes63BWqN5pngS8=; b=q3WbdggYislfegoWs1H2gKym7ufmA/4UvMwCmpppaGEdPyx8sCLa2WjBOLEGKlM+cm NeUgyuelktxYpq4iy33oayi0aRHGn6atyKoxHS90d4j7HYQ+RJCmMsdp8ns6JWtKUF65 cdGZryG3BSaZMtl2NbbjM4rgrAhzASxetB496aJNdNAK+9KRMwAbClhdfDP6jVjYJdrt lopbXY5IRKXiOk9SX9UMSZNHf/tQijgkq+TW6koo1e0gdXyE4AbugmBIXf5VPjBJiJKt +oubOwaBRYpzHgBVcpWq2d/4Uw5Ud2Ep50Hs+FdzXf1CDeAdSAlD8d5NDliiipu8QXIq U6ew==
MIME-Version: 1.0
Received: by 10.68.125.135 with SMTP id mq7mr33352844pbb.155.1332181405026; Mon, 19 Mar 2012 11:23:25 -0700 (PDT)
Received: by 10.68.40.10 with HTTP; Mon, 19 Mar 2012 11:23:24 -0700 (PDT)
In-Reply-To: <20120319181722.GD45974@mail.yitter.info>
References: <6.2.5.6.2.20120314103632.0a451d08@elandnews.com> <1582246.ifGuAyB4YY@scott-latitude-e6320> <20120319181722.GD45974@mail.yitter.info>
Date: Mon, 19 Mar 2012 14:23:24 -0400
Message-ID: 
From: Dotzero 
To: Andrew Sullivan 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: spfbis@ietf.org
Subject: Re: [spfbis] Draft agenda for IETF83
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 Mar 2012 18:23:26 -0000

On Mon, Mar 19, 2012 at 2:17 PM, Andrew Sullivan  w=
rote:
> Dear colleagues,
>
> On Wed, Mar 14, 2012 at 02:38:48PM -0400, Scott Kitterman wrote:
>>
>> I think this would be a waste of the group's time.
>
> John Levine sent a similar remark.
>
> Do people have other things they want on the agenda? =A0There was little
> feedback apart from these two suggestions. =A0We plan to alter the
> agenda, and if there are other changes people want I'd like to hear
> them.
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com
>

Andrew, I will not be able to make it in person but I would like to
concur with Scott and Jown with regard to DNS amplification attacks.
his was first raised by Doug 7-8 years ago and we have not seen any
instances of this hypothetical abuse in the wild. As John pointed out,
despite Doug vocally asserting this as a significant issue, he has not
attracted significant (I was going to say any) support within the
community of folks actively working in this space.

Mike

From msk@cloudmark.com  Mon Mar 19 11:29:31 2012
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 BA04521F8895 for ; Mon, 19 Mar 2012 11:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.601
X-Spam-Level: 
X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 NDX7Te93gyiz for ; Mon, 19 Mar 2012 11:29:31 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4DF21F8894 for ; Mon, 19 Mar 2012 11:29:31 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Mon, 19 Mar 2012 11:29:30 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] Draft agenda for IETF83
Thread-Index: AQHNAgogy9YvT0v0vUy9GRvfGZXDjpZqlKcAgAfVqwD//42V8A==
Date: Mon, 19 Mar 2012 18:29:30 +0000
Message-ID: <9452079D1A51524AA5749AD23E00392809317B@exch-mbx901.corp.cloudmark.com>
References: <6.2.5.6.2.20120314103632.0a451d08@elandnews.com> <1582246.ifGuAyB4YY@scott-latitude-e6320> <20120319181722.GD45974@mail.yitter.info>
In-Reply-To: <20120319181722.GD45974@mail.yitter.info>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.20.2.121]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] Draft agenda for IETF83
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 Mar 2012 18:29:31 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of Andrew Sullivan
> Sent: Monday, March 19, 2012 11:17 AM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] Draft agenda for IETF83
>=20
> > I think this would be a waste of the group's time.
>=20
> John Levine sent a similar remark.
>=20
> Do people have other things they want on the agenda?  There was little
> feedback apart from these two suggestions.  We plan to alter the
> agenda, and if there are other changes people want I'd like to hear
> them.

I can't think of any other topics that need face-to-face time except maybe =
a quick summary of where we are on each of the tickets in the tracker (quic=
k, I said!).  The remaining time allocated to DNS attacks could be split be=
tween talking about what to put in the experiment document and the type 99 =
discussion/debate/d=E9tente/fiasco.

-MSK

From ajs@anvilwalrusden.com  Mon Mar 19 11:51:24 2012
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 7CF5221E8013 for ; Mon, 19 Mar 2012 11:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level: 
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114,  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 QykQT6CUo-i7 for ; Mon, 19 Mar 2012 11:51:23 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B629521E800C for ; Mon, 19 Mar 2012 11:51:23 -0700 (PDT)
Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3264A1ECB41D for ; Mon, 19 Mar 2012 18:51:23 +0000 (UTC)
Date: Mon, 19 Mar 2012 14:51:21 -0400
From: Andrew Sullivan 
To: spfbis@ietf.org
Message-ID: <20120319185120.GF45974@mail.yitter.info>
References: <6.2.5.6.2.20120314103632.0a451d08@elandnews.com> <1582246.ifGuAyB4YY@scott-latitude-e6320> <20120319181722.GD45974@mail.yitter.info> 
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: [spfbis] on theoretical attacks (was:  Draft agenda for IETF83)
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 Mar 2012 18:51:24 -0000

No hat.

Dear colleagues,

On Mon, Mar 19, 2012 at 02:23:24PM -0400, Dotzero wrote:

> concur with Scott and Jown with regard to DNS amplification attacks.
> his was first raised by Doug 7-8 years ago and we have not seen any
> instances of this hypothetical abuse in the wild.

I suggest to be very careful with this line of argument.  Dan
Bernstein identified outbound port predictability of DNS queries as a
vulnerability nearly 10 years before Kaminsky's much-discussed attack.
DJB's complaint was also dismissed as mostly theoretical.

It might be a stronger argument that other vectors of attack are
easier and more effective, however.  (I refuse to have an opinion on
the matter, though I have thought about it.)



Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

From dotzero@gmail.com  Mon Mar 19 12:01:28 2012
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 041F021E801E for ; Mon, 19 Mar 2012 12:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 xoAvQ8Iu26qq for ; Mon, 19 Mar 2012 12:01:27 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 693F521E8024 for ; Mon, 19 Mar 2012 12:01:27 -0700 (PDT)
Received: by dakl33 with SMTP id l33so11452064dak.31 for ; Mon, 19 Mar 2012 12:01:27 -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=6/a+7iOVYT6dw96q7KDkB/06z7Fb7rndF7SnvtPWKFY=; b=hePaIDxvzL9xXCJE9WKmW9XgIz6Jfjh8vhUfHAAQ4FNKHYzJkq1lS6R9+Er7VhM4XP tvFTKWqc+n1GFqawOjpLO0RMAtWuh0zqcdOK4Hu7OppVLFhRZ3LGLNkWwwjrZJYSiom+ joB1DBhfBBFhyVyZWHin5EosoVrMEfmChwfiWvh1+mBCBrmzNPeIcQdvJfRagYO1tPZW vYV/50W6NL0appP/hdfei22i3yMAxKG6jKBph1+K+Uci5/0IyQjFbS+6/57TMjUEXXP9 lnAxFOhkHJzI41oL9eadjcfbacz55ckrnFfMbPJPmyIvg6bBhmAL6sSTFXSisLlxvPnJ Z7MQ==
MIME-Version: 1.0
Received: by 10.68.222.7 with SMTP id qi7mr8901693pbc.50.1332183687204; Mon, 19 Mar 2012 12:01:27 -0700 (PDT)
Received: by 10.68.40.10 with HTTP; Mon, 19 Mar 2012 12:01:27 -0700 (PDT)
In-Reply-To: <20120319185120.GF45974@mail.yitter.info>
References: <6.2.5.6.2.20120314103632.0a451d08@elandnews.com> <1582246.ifGuAyB4YY@scott-latitude-e6320> <20120319181722.GD45974@mail.yitter.info>  <20120319185120.GF45974@mail.yitter.info>
Date: Mon, 19 Mar 2012 15:01:27 -0400
Message-ID: 
From: Dotzero 
To: Andrew Sullivan 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: spfbis@ietf.org
Subject: Re: [spfbis] on theoretical attacks (was: Draft agenda for IETF83)
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 Mar 2012 19:01:28 -0000

On Mon, Mar 19, 2012 at 2:51 PM, Andrew Sullivan  w=
rote:
> No hat.
>
> Dear colleagues,
>
> On Mon, Mar 19, 2012 at 02:23:24PM -0400, Dotzero wrote:
>
>> concur with Scott and Jown with regard to DNS amplification attacks.
>> his was first raised by Doug 7-8 years ago and we have not seen any
>> instances of this hypothetical abuse in the wild.
>
> I suggest to be very careful with this line of argument. =A0Dan
> Bernstein identified outbound port predictability of DNS queries as a
> vulnerability nearly 10 years before Kaminsky's much-discussed attack.
> DJB's complaint was also dismissed as mostly theoretical.
>
> It might be a stronger argument that other vectors of attack are
> easier and more effective, however. =A0(I refuse to have an opinion on
> the matter, though I have thought about it.)
>
>

This has actually been a significant part of the response/discussion.
I plead guilty to knowing the history of the discussion and assuming
(a bad thing to do) that most others are also familiar (or have taken
the time to review the MARID and spf-discuss archives.

Mike

>
> Best,
>
> A
>
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com
> _______________________________________________
> spfbis mailing list
> spfbis@ietf.org
> https://www.ietf.org/mailman/listinfo/spfbis

From spf2@kitterman.com  Mon Mar 19 12:06:33 2012
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 69B2D21F88C1 for ; Mon, 19 Mar 2012 12:06:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002,  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 jqYBJmnXCx6k for ; Mon, 19 Mar 2012 12:06:32 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A132321F88C0 for ; Mon, 19 Mar 2012 12:06:32 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id F0BA420E40BD; Mon, 19 Mar 2012 15:06:31 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332183992; bh=gBN2sQRFgPiVuGGftUuhpiRhnFSKEsA3w905zoKd3uw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=UHBJFaAA67BltzDb0aaAFUvrNLhHZRpQKn2+Z39eHlyf03tEmk25dGtPq20JdqGwh QKgklWxl8zf5jh0c3mD3KRIR+yleupEHB54LPT2/ZoheSst9bba/BGpRU6Y6N9YLyX B2ALvbfMMaR7mkklz8VVrENWXjv4zlQDBo5kHYt8=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D78C520E40A4;  Mon, 19 Mar 2012 15:06:31 -0400 (EDT)
From: Scott Kitterman 
To: spfbis@ietf.org
Date: Mon, 19 Mar 2012 15:06:31 -0400
Message-ID: <10579619.84ng6M2pcE@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <20120319185120.GF45974@mail.yitter.info>
References: <6.2.5.6.2.20120314103632.0a451d08@elandnews.com>  <20120319185120.GF45974@mail.yitter.info>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] on theoretical attacks (was: Draft agenda for IETF83)
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 Mar 2012 19:06:33 -0000

On Monday, March 19, 2012 02:51:21 PM Andrew Sullivan wrote:
> No hat.
> 
> Dear colleagues,
> 
> On Mon, Mar 19, 2012 at 02:23:24PM -0400, Dotzero wrote:
> > concur with Scott and Jown with regard to DNS amplification attacks.
> > his was first raised by Doug 7-8 years ago and we have not seen any
> > instances of this hypothetical abuse in the wild.
> 
> I suggest to be very careful with this line of argument.  Dan
> Bernstein identified outbound port predictability of DNS queries as a
> vulnerability nearly 10 years before Kaminsky's much-discussed attack.
> DJB's complaint was also dismissed as mostly theoretical.
> 
> It might be a stronger argument that other vectors of attack are
> easier and more effective, however.  (I refuse to have an opinion on
> the matter, though I have thought about it.)

Despite a large degree of skepticism about this type of attack, the SPF 
community did a serious analysis of the question several years ago:

http://www.openspf.org/draft-otis-spf-dos-exploit_Analysis

The conclusion (which I've seen no reason to step away from) is that the 
attack vector that Doug raises is extremely unlikely to ever materialize and 
in the event an attacker chose to do an attack similar to this one, there are 
significantly easier ways to do it.

If we can bolt on the void lookups limit (I've forgotten which issue # that 
one was) without affecting interoperability of current records (we'll need some 
survey results that we won't have for awhile, so no need to argue the point 
further now) then we should add it as an insurance policy/efficiency measure (it 
would give compliant receivers a way to stop processing bogus records sooner), 
but we should by no means regard it or removing per user policies as needed to 
make the protocol secure.

Scott K

From dotis@mail-abuse.org  Mon Mar 19 12:47:47 2012
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 EEC5C21E8028 for ; Mon, 19 Mar 2012 12:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.422
X-Spam-Level: 
X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 3CSo1Ck9V8cG for ; Mon, 19 Mar 2012 12:47:47 -0700 (PDT)
Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6988B21E8015 for ; Mon, 19 Mar 2012 12:47:47 -0700 (PDT)
Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 542E917400CD for ; Mon, 19 Mar 2012 19:47:47 +0000 (UTC)
Message-ID: <4F678D63.4070705@mail-abuse.org>
Date: Mon, 19 Mar 2012 12:47:47 -0700
From: Douglas Otis 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <4F641164.10602@cisco.com> <4F66D2A1.30304@mail-abuse.org> <1464793.ZEWILd8cXx@scott-latitude-e6320> <4F677486.9080001@mail-abuse.org> <20120319181543.GC45974@mail.yitter.info>
In-Reply-To: <20120319181543.GC45974@mail.yitter.info>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Mon, 19 Mar 2012 19:47:48 -0000

On 3/19/12 11:15 AM, Andrew Sullivan wrote:
> Hi Doug,
>
> On Mon, Mar 19, 2012 at 11:01:42AM -0700, Douglas Otis wrote:
>
>> senders is highly ill considered nor has such use been widely
>> implemented except in rare cases.
> Just as a point of information: is that a positivice claim that it has
> been implemented (though rarely); or are you really saying that as far
> as you know it's unimplemented, but you're not willing to say "never"?
Dear Andrew,

The local-part feature is used by a fraction of a percent of exchanges 
supported by SPF.  Even so, in these rare cases, it serves no valid 
purpose and conflicts with the majority of SPF uses.  This mechanism 
expects recipients to impose restrictions on Mail From parameters used 
by a domain's authorized servers.  A parameter not seen by recipients 
and no protocol imposes local-part restriction on other email header 
fields that might be visible.  This is a feature that clearly should be 
removed as not being used, or at least not gainfully used while imposing 
additional resource risks.

To ensure compatibility in those few instances where SPF records contain 
local-part macros, the specification should indicate use of "postmaster" 
can be alternatively applied to enumerate a domain's outbound servers.  
This would ensure SPF's general utility and compatibility, while also 
guarding against unscalable abuse of recipient resources.
>> SPF should not authorize untrusted outbound servers!  DKIM provides
>> a safer and more practical means to ensure control of email header
>> fields.
> Please check our charter; we have some pretty strict limits on what we
> are allowed to do:
>
>        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 specification is in error by not ensuring a local-part mechanism 
will not interfere with the vast majority of utilities normally offered 
by SPF.  In that sense, it would be an error to not ensure against such 
compatibility related interference.  This interference is corrected by 
supplanting local-part with "postmaster" when assessing a domain's 
outbound server address set.

The specification is also in error by ignoring accumulations of no-data 
errors that may occur during processing of SPF related macros.  This is 
a different error that must also be resolved.

Likely due to its overhead and unreliable results, few large domains 
dynamically employ SPF as a basis for rejecting messages.  As such, it 
presents fewer exploit opportunities.  It would be naive to assume that 
no evidence being published of SPF macro mechanisms being exploited in 
attacks against some victim domain offers assurances against current or 
future exploits or that SPF will continue to be generally ignored as a 
basis for acceptance.  It is likely exploitation of a recipient's 
resources will go unnoticed by email recipients.  Since email is able to 
make a distributed attack extremely easy to instrument, it is important 
recipient resources not fall into the wrong hands.
> Are you claiming that the feature is unused, or that it is an error?

Both.  To ensure compatibility in those few instances where SPF records 
contain local-part macros, the specification should indicate use of 
"postmaster" can be alternatively applied to enumerate a domain's 
outbound servers.  This would ensure SPF's general utility and 
compatibility, while also guarding against unscalable abuse of recipient 
resources.

Regards,
Douglas Otis

From SRS0=nJSb6=B3==stuart@gathman.org  Mon Mar 19 20:03:28 2012
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 5B97321F8772 for ; Mon, 19 Mar 2012 20:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.51
X-Spam-Level: 
X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089,  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 bHKCGbwxWmM2 for ; Mon, 19 Mar 2012 20:03:27 -0700 (PDT)
Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id B5B3521F8760 for ; Mon, 19 Mar 2012 20:03:27 -0700 (PDT)
Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q2K32UM4028169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Mar 2012 23:02:31 -0400
Message-ID: <4F67F37A.20100@gathman.org>
Date: Mon, 19 Mar 2012 23:03:22 -0400
From: Stuart Gathman 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: spfbis@ietf.org
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <6.2.5.6.2.20120313221606.0aeaadf0@elandnews.com>
In-Reply-To: <6.2.5.6.2.20120313221606.0aeaadf0@elandnews.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Tue, 20 Mar 2012 03:06:01 -0000

Long ago, Nostradamus foresaw that on 03/14/2012 01:17 AM, S Moonesamy
would write:
>>  Use of local-part macros in SPF record sets necessitates repeating all
>>  invoked DNS transactions.  DNS caching only limits DNS overhead when no
>>  local-part macros are used within SPF record sets.  It is not
>> uncommon for
>>  the use of random local-part names in messages to be sent by
>> malefactors. 
While Doug is correct that the localpart macro defeats DNS caching in
the hands of a malefactor (and rfc4408 mentions this), so does an IP6
connection with PTR (or ip address macro) (sender has a 64 bit address
space to randomize for a unique IP on each connection).  Should we
remove IP6 support?

The postmaster idea is not backward compatible.  But I have a better
suggestion: if a receiver finds their DNS cache thrashing from localpart
macros (or ip6), or is concerned that that *might* happen, then they
should simply *ignore* SPF records with localpart macros.  Even better,
the libspf2 library has a "cache able" test that determines whether a
policy can be cached.  A receiver concerned about the attacks Doug is
talking about can simply ignore uncache able SPF records. 

We could even be helpful and include the algorithm for cacheability
testing in the security section, and suggest that receivers MAY ignore
uncache able policies if they suspect or wish to prevent a Doug style
attack (although there are easier ways to get the same amplification, so
I don't see the motivation for a bad guy to use such an attack).  This
avoids breaking policies,  and provides an effective mitigation when needed.


From agthisell@yahoo.com  Mon Mar 19 20:06:38 2012
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 58B7621E8043 for ; Mon, 19 Mar 2012 20:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.007
X-Spam-Level: 
X-Spam-Status: No, score=0.007 tagged_above=-999 required=5 tests=[AWL=0.006,  BAYES_50=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 PvquELIkA8UT for ; Mon, 19 Mar 2012 20:06:37 -0700 (PDT)
Received: from nm30-vm0.bullet.mail.ne1.yahoo.com (nm30-vm0.bullet.mail.ne1.yahoo.com [98.138.91.69]) by ietfa.amsl.com (Postfix) with SMTP id AAD3F21E8027 for ; Mon, 19 Mar 2012 20:06:37 -0700 (PDT)
Received: from [98.138.90.55] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 20 Mar 2012 03:06:34 -0000
Received: from [98.138.226.168] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 20 Mar 2012 03:06:34 -0000
Received: from [127.0.0.1] by omp1069.mail.ne1.yahoo.com with NNFMP; 20 Mar 2012 03:06:34 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 537050.49061.bm@omp1069.mail.ne1.yahoo.com
Received: (qmail 18442 invoked by uid 60001); 20 Mar 2012 03:06:34 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1332212794; bh=fXHnU9yfRfiE5SPzXTr59SvyJ+BMYQOZKXMcIy7WBxE=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=dSeO5BgF3Mrn/ptf+5fBwpOe5NRw/XRmBcbJ17U/l4mLWe5SQ32Q9E3g79za11yLvg2nLuAGB6qNqMp7KDFeFMFiwUQvAwcWR+rhpXpA38YLrN1N53o7WsuUacEf8ay6g5/LstPz8M/5+9axYtxOcQPcnvhU+QRs3+x9gE0Ieos=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=hAsj0Df/nv0Nu+m3UsqccPQ49R5mTTrl7eWMKZFSZtAX6tcH1/m2ydTYKwi2bU5WkjdLzDzoI74qrdp00PPbZrrSZEkjGvz+rIgLVqYGznD1phaN5HQf/RCgT09KIn+aO1niOC+fumQEL+u4xo6rhQgVb1eFjoOCLmjrlrdqMas=;
X-YMail-OSG: _R19WvoVM1luqjiNeHO1fmnxIChRv7rvKeY_o1G9axtSWcu IRolQDm1RViNAp8o_rUct3rIJWh1a3zDn8b1s4j0QnkxTSJHjMix_qaVDfeS ar..QMfXjbwGWyr9R_bdAgMStvu7h_aPLlBMG4NuUuZfcc1BUeLwJThDfeTq KiUQIRZB54vD2Qlc2Ugcykaqoy8TzltcuvHN.C_dGy0ZdsTQt3nY35tTdGG. Quwoi3UA3OReJOYWA16jS1XWd.Li2z3nB_Z0QyHB1Al7YzdhzWV1Ft5kjRQv M8IXNps9YjQhh2TVgvrA1f.m98EQSFlt5xldANMO13wYzHeH7O8MmY7ry4B3 Xv1wipIMqmOp5QpfovL1Q6f6Qh0FbuGTjiys2s7tBNrRo1v6e8y_p9WBTPpR K7gTT5WTOiplxycJHR40cdXvaJI1nKvL7gHIgv4JMhlOf_S3YPK_tr_SYb8m WL4s-
Received: from [71.61.133.134] by web125404.mail.ne1.yahoo.com via HTTP; Mon, 19 Mar 2012 20:06:34 PDT
X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427
Message-ID: <1332212794.1494.YahooMailClassic@web125404.mail.ne1.yahoo.com>
Date: Mon, 19 Mar 2012 20:06:34 -0700 (PDT)
From: Arthur Thisell 
To: spfbis@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [spfbis]  on theoretical attacks (was: Draft agenda for IETF83)
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 Mar 2012 03:06:38 -0000

Based on what I've read, I too feel that putting up a 20min session on the amplification factor would not be productive.

> As John pointed out,
> despite Doug vocally asserting this as a significant issue, he has not
> attracted significant (I was going to say any) support within the
> community of folks actively working in this space.

It isn't that the subject of a DDOS attack and the amplification factor hasn't gotten any support, it is Doug's presentation that hasn't.   Doug wasn't the first to raise the subject of SPF's amplification.  Indeed, the vastly more restrictive processing limits in libspf2 were added before Doug made his first post on the subject.

The problem is that Doug has done nothing new and is still presenting his old ID as if it hasn't been read, analyzed and rejected.   Indeed, he recently wrote:

> the use of macros and insensitivity to no-data errors permits a 1 KB message to generate (34.8KB +28.8 KB) x 4 or 254KB of victim traffic against any domain that simply supports DNS.

There is the problem.   A scary 254k number, but ignores the flaw that it isn't 1KB of traffic that the attacker needs to be able to generate in order to create that attack, it is far larger.

I have read Doug's paper, and I reject the conclusions due to false premises.   I have spelled out these problems years ago, and I do not think it would be productive to continue to rehash old arguments. This draft has been presented at at least one previous IETF meeting, isn't like it hasn't been given a fair hearing.  Obviously, nothing anyone says is going to change Doug's mind, and Doug hasn't changed anyone else's mind.

From msk@cloudmark.com  Mon Mar 19 20:50:00 2012
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 3363A21F878E for ; Mon, 19 Mar 2012 20:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.557
X-Spam-Level: 
X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 bLOi4Zy2gXgQ for ; Mon, 19 Mar 2012 20:49:59 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B3CBD21F8789 for ; Mon, 19 Mar 2012 20:49:59 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Mon, 19 Mar 2012 20:49:59 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] #14: RFC 4408: local-part macro prep for  deprecation
Thread-Index: AQHNAaIwfZPmwXaIkEyZDPzx1lwYu5Zy/hkA//+WddA=
Date: Tue, 20 Mar 2012 03:49:58 +0000
Message-ID: <9452079D1A51524AA5749AD23E003928093B28@exch-mbx901.corp.cloudmark.com>
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <6.2.5.6.2.20120313221606.0aeaadf0@elandnews.com> <4F67F37A.20100@gathman.org>
In-Reply-To: <4F67F37A.20100@gathman.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [67.160.203.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Tue, 20 Mar 2012 03:50:00 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of Stuart Gathman
> Sent: Monday, March 19, 2012 8:03 PM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for deprecatio=
n
>=20
> The postmaster idea is not backward compatible.  But I have a better
> suggestion: if a receiver finds their DNS cache thrashing from
> localpart macros (or ip6), or is concerned that that *might* happen,
> then they should simply *ignore* SPF records with localpart macros.
> Even better, the libspf2 library has a "cache able" test that
> determines whether a policy can be cached.  A receiver concerned about
> the attacks Doug is talking about can simply ignore uncache able SPF
> records.
>=20
> We could even be helpful and include the algorithm for cacheability
> testing in the security section, and suggest that receivers MAY ignore
> uncache able policies if they suspect or wish to prevent a Doug style
> attack (although there are easier ways to get the same amplification,
> so I don't see the motivation for a bad guy to use such an attack).
> This avoids breaking policies,  and provides an effective mitigation
> when needed.

Assuming we decide we want to say anything at all about the perceived probl=
em, this seems like a reasonable compromise versus Doug's preference of rem=
oving or disabling the local part macros outright.

-MSK

From vesely@tana.it  Tue Mar 20 01:46:21 2012
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 220A121F87B5 for ; Tue, 20 Mar 2012 01:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.657
X-Spam-Level: 
X-Spam-Status: No, score=-4.657 tagged_above=-999 required=5 tests=[AWL=0.062,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-KH-L2xLYSV for ; Tue, 20 Mar 2012 01:46:20 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3165C21F87B0 for ; Tue, 20 Mar 2012 01:46:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332233177; bh=lffcjOrhX6v7oAS53KJt1teKe43R2+wZqkcFcAUvAqk=; l=1136; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=hdx+MUaQ+KQcJRncQ5vUsvaZWS1VUfjSPZCorYRt8/MB2ZrXoeZ7hM+yEnV2LSv9X tXap1XiThimETNxW/ZO93umjw8O21EMfOQptm4X48lPVeFYfNWS7+RGit+JJebEShG OxPyp9DCxsg0IaNrsyjaSFBQT1BIDWhN/aFCj6T4=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 20 Mar 2012 09:46:17 +0100 id 00000000005DC035.000000004F6843D9.000029F8
Message-ID: <4F6843D8.10906@tana.it>
Date: Tue, 20 Mar 2012 09:46:16 +0100
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <6.2.5.6.2.20120313221606.0aeaadf0@elandnews.com> <4F67F37A.20100@gathman.org> <9452079D1A51524AA5749AD23E003928093B28@exch-mbx901.corp.cloudmark.com>
In-Reply-To: <9452079D1A51524AA5749AD23E003928093B28@exch-mbx901.corp.cloudmark.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Tue, 20 Mar 2012 08:46:21 -0000

On 20/Mar/12 04:49, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Stuart Gathman
>
>> We could even be helpful and include the algorithm for cacheability
>> testing in the security section, and suggest that receivers MAY ignore
>> uncache able policies if they suspect or wish to prevent a Doug style
>> attack (although there are easier ways to get the same amplification,
>> so I don't see the motivation for a bad guy to use such an attack).
>> This avoids breaking policies,  and provides an effective mitigation
>> when needed.
> 
> Assuming we decide we want to say anything at all about the
> perceived problem, this seems like a reasonable compromise versus
> Doug's preference of removing or disabling the local part macros
> outright.

That variation looks similar to the best-guess case.  That is, for
domains having no or unacceptable SPF record receivers can synthesize
a policy and evaluate that.  (There are similar approaches for ADSP.)

IIRC, we decided that the reporting header fields
(Authentication-Results and Received-SPF) should not conflate such
surrogate results with true ones.

From spf2@kitterman.com  Tue Mar 20 03:53:34 2012
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 504D021F86EB for ; Tue, 20 Mar 2012 03:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002,  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 Xx+-igz9sK4l for ; Tue, 20 Mar 2012 03:53:33 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id C51E921F86E0 for ; Tue, 20 Mar 2012 03:53:26 -0700 (PDT)
Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id ACAA4D0407E; Tue, 20 Mar 2012 05:53:25 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332240805; bh=jB4FGEtJNaPn1mJkVqKTMbH0OWHMy8UFm7sdqPNJmpc=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=dOtDckVLzcb0LxSV3r6pj8Ozf03vTkjSjV7VQeY6d2chsnSABhHelxUXxkafthQeC Buk6p37y8L7/J42LeCxyn0IAxWbi4d53oglHOOpKO80stl3zeA1rRWDL2VgVz4Hiso XAJczHWLs1D/vHvZDMkvvMQgG7Xgm61asejBGaic=
Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 3B0BBD04049;  Tue, 20 Mar 2012 05:53:24 -0500 (CDT)
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <6.2.5.6.2.20120313221606.0aeaadf0@elandnews.com> <4F67F37A.20100@gathman.org> <9452079D1A51524AA5749AD23E003928093B28@exch-mbx901.corp.cloudmark.com> <4F6843D8.10906@tana.it>
User-Agent: K-9 Mail for Android
In-Reply-To: <4F6843D8.10906@tana.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Scott Kitterman 
Date: Tue, 20 Mar 2012 06:53:31 -0400
To: spfbis@ietf.org
Message-ID: <98405225-3ea3-471e-98a7-df079fcd3731@email.android.com>
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Tue, 20 Mar 2012 10:53:34 -0000

Alessandro Vesely  wrote:

>On 20/Mar/12 04:49, Murray S. Kucherawy wrote:
>>> From: ietf.org On Behalf Of Stuart Gathman
>>
>>> We could even be helpful and include the algorithm for cacheability
>>> testing in the security section, and suggest that receivers MAY
>ignore
>>> uncache able policies if they suspect or wish to prevent a Doug
>style
>>> attack (although there are easier ways to get the same
>amplification,
>>> so I don't see the motivation for a bad guy to use such an attack).
>>> This avoids breaking policies,  and provides an effective mitigation
>>> when needed.
>> 
>> Assuming we decide we want to say anything at all about the
>> perceived problem, this seems like a reasonable compromise versus
>> Doug's preference of removing or disabling the local part macros
>> outright.
>
>That variation looks similar to the best-guess case.  That is, for
>domains having no or unacceptable SPF record receivers can synthesize
>a policy and evaluate that.  (There are similar approaches for ADSP.)
>
>IIRC, we decided that the reporting header fields
>(Authentication-Results and Received-SPF) should not conflate such
>surrogate results with true ones.

No. It's rather the opposite.

In that case a receiver is making up a record and applying it.  Inventing records and applying them is not SPF.

In this case, it's a matter of not doing SPF processing if resources are not available. Nothing forces a receiver to check SPF for a particular message.

To further clarify, (thinking in terms of an RFC 5451 Authentication Results header field) I suspect you are thinking the result reported would be SPF none. What we're discussing is reporting no authentication check done.

Scott K

From vesely@tana.it  Tue Mar 20 05:16:18 2012
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 43F3B21F8648 for ; Tue, 20 Mar 2012 05:16:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.358
X-Spam-Level: 
X-Spam-Status: No, score=-4.358 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=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 YZgvyAvqJihm for ; Tue, 20 Mar 2012 05:16:17 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 63D1A21F863C for ; Tue, 20 Mar 2012 05:16:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332245775; bh=WuXH/5E54jfcwEArKQz4Ut4rpggI45xekOXetTfHLmw=; l=816; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=MyS/33xq99+B1P/j+mZ3JNX7CpJNiBYAXr0pVhbyUSfhnd5Z/qH8IoU9ozIl4j16e 3MFt4eIxRzml6oSEaB9uhM0ezlyotp9Yp4I9F58LKcP1Yd8bFNMtjMgDbZQLK/DXsg ruUFrpFyygqdrw84f4uTnM/pyZYPgejKxEFefe+M=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 20 Mar 2012 13:16:15 +0100 id 00000000005DC035.000000004F68750F.00005D5D
Message-ID: <4F68750F.6060104@tana.it>
Date: Tue, 20 Mar 2012 13:16:15 +0100
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <6.2.5.6.2.20120313221606.0aeaadf0@elandnews.com> <4F67F37A.20100@gathman.org> <9452079D1A51524AA5749AD23E003928093B28@exch-mbx901.corp.cloudmark.com> <4F6843D8.10906@tana.it> <98405225-3ea3-471e-98a7-df079fcd3731@email.android.com>
In-Reply-To: <98405225-3ea3-471e-98a7-df079fcd3731@email.android.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Tue, 20 Mar 2012 12:16:18 -0000

On 20/Mar/12 11:53, Scott Kitterman wrote:
> 
> To further clarify, (thinking in terms of an RFC 5451
> Authentication Results header field) I suspect you are thinking the
> result reported would be SPF none. What we're discussing is
> reporting no authentication check done.

Any check done may be worth being reported.  Personally, I don't see
much added value in reporting that a check was skipped, but if there
is a (valid) reason to skip it and if alternative checks have been
carried out, it might still make sense to report that.  Consider:

Authentication-Results: somehost.example;
  spf=skip reason=uncacheable;
  spf-best-guess=pass smtp.mailfrom=sender.example;
  spf-quirk=neutral (using postmaster@sender.example)
     smtp.mailfrom=sender.example;

Would any part of such a result be useful?

From spf2@kitterman.com  Tue Mar 20 05:53:47 2012
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 0E1F221F858E for ; Tue, 20 Mar 2012 05:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.297
X-Spam-Level: 
X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, J_CHICKENPOX_34=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 HgubmKJAataL for ; Tue, 20 Mar 2012 05:53:45 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AB97921F858D for ; Tue, 20 Mar 2012 05:53:45 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CBA3820E40BD; Tue, 20 Mar 2012 08:53:44 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332248024; bh=Zb+nWJky3cOCOBQPBDCTq7HyqtzhlhGzeH4RzFm8YCM=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=C7KnHY+mo4t5mZ3A5KmSoDNvOYzDISZgacgtCT3EWrKJJtkGlIgrnXgzh83S/7wvB vzRkPVM3NbhkV5e1Fsknkm2CCU8PAy/kGOnYAQ2InPhUEcph/zPL4czaCn7DSWrojg W+aztGv6+jNHskKj+aNxPBopewqaGvJSaotk+pmc=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id ADB9820E4064;  Tue, 20 Mar 2012 08:53:44 -0400 (EDT)
From: Scott Kitterman 
To: spfbis@ietf.org
Date: Tue, 20 Mar 2012 08:53:44 -0400
Message-ID: <2215525.feDxLYxsSs@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <4F68750F.6060104@tana.it>
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <98405225-3ea3-471e-98a7-df079fcd3731@email.android.com> <4F68750F.6060104@tana.it>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Tue, 20 Mar 2012 12:53:47 -0000

On Tuesday, March 20, 2012 01:16:15 PM Alessandro Vesely wrote:
> On 20/Mar/12 11:53, Scott Kitterman wrote:
> > To further clarify, (thinking in terms of an RFC 5451
> > Authentication Results header field) I suspect you are thinking the
> > result reported would be SPF none. What we're discussing is
> > reporting no authentication check done.
> 
> Any check done may be worth being reported.  Personally, I don't see
> much added value in reporting that a check was skipped, but if there
> is a (valid) reason to skip it and if alternative checks have been
> carried out, it might still make sense to report that.  Consider:
> 
> Authentication-Results: somehost.example;
>   spf=skip reason=uncacheable;
>   spf-best-guess=pass smtp.mailfrom=sender.example;
>   spf-quirk=neutral (using postmaster@sender.example)
>      smtp.mailfrom=sender.example;
> 
> Would any part of such a result be useful?

I was thinking the case under discussions would be more like:

Authentication-Results: test.example.org; none (SPF skipped due to non-
cacheable record)

Someone might (I question the value, but someone might) define spf-best-guess 
as a new email authentication method, in which case spf-best-guess=pass 
smtp.mailfrom=sender.example; would be reasonable.  If I were the one defining 
it, I would only permit pass and none for results as the other possibilities 
are at best meaningless and at worst actively dangerous.

I've no idea what spf-quirk would be?

In one open source implementation where I've implemented RFC 5451, I've also 
done things like:

Authentication-Results: test.example.org; none (SPF skipped for whitelisted 
relay domain - client-ip=%s; helo=%s; envelope-from=%s; receiver=%s)

I think that recording that no authentication test was done and why for post-
delivery analysis is an important thing, so in general, I think it's useful to 
report both what's done and not done and why.  It's not going to be a lot of 
help for automatic downstream processing, but it can be invaluable for 
troubleshooting.

Scott K

From msk@cloudmark.com  Tue Mar 20 06:40:51 2012
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 D1A8F21F8732 for ; Tue, 20 Mar 2012 06:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.558
X-Spam-Level: 
X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 YDcBoiYPWX7j for ; Tue, 20 Mar 2012 06:40:51 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6959921F872F for ; Tue, 20 Mar 2012 06:40:51 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 06:40:50 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] #14: RFC 4408: local-part macro prep for  deprecation
Thread-Index: AQHNAaIwfZPmwXaIkEyZDPzx1lwYu5Zy/hkA//+WddCAAMlZAP//3JGQ
Date: Tue, 20 Mar 2012 13:40:49 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039280940A0@exch-mbx901.corp.cloudmark.com>
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <6.2.5.6.2.20120313221606.0aeaadf0@elandnews.com> <4F67F37A.20100@gathman.org> <9452079D1A51524AA5749AD23E003928093B28@exch-mbx901.corp.cloudmark.com> <4F6843D8.10906@tana.it>
In-Reply-To: <4F6843D8.10906@tana.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [67.160.203.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Tue, 20 Mar 2012 13:40:51 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of Alessandro Vesely
> Sent: Tuesday, March 20, 2012 1:46 AM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for deprecatio=
n
>=20
> That variation looks similar to the best-guess case.  That is, for
> domains having no or unacceptable SPF record receivers can synthesize a
> policy and evaluate that.  (There are similar approaches for ADSP.)
>=20
> IIRC, we decided that the reporting header fields (Authentication-
> Results and Received-SPF) should not conflate such surrogate results
> with true ones.

The difference is that Best-Guess SPF imposes a record where there is none,=
 which is a complete policy fabrication.  In this case we're ignoring all o=
r part of a record that (in theory) causes an operational hardship, which r=
eceivers are always free to do anyway.

-MSK

From msk@cloudmark.com  Tue Mar 20 06:42:40 2012
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 C600D21F8734 for ; Tue, 20 Mar 2012 06:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Level: 
X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 6IRkWuDR6CZU for ; Tue, 20 Mar 2012 06:42:39 -0700 (PDT)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id D971821F871A for ; Tue, 20 Mar 2012 06:42:39 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 06:42:39 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] #14: RFC 4408: local-part macro prep for  deprecation
Thread-Index: AQHNAaIwfZPmwXaIkEyZDPzx1lwYu5Zy/hkA//+WddCAAMlZAIAAI42AgAAXHoCAAAp5AP//mDhQ
Date: Tue, 20 Mar 2012 13:42:38 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039280940B8@exch-mbx901.corp.cloudmark.com>
References: <061.6bb02ffb883fb6947aec11bfa6544ac4@tools.ietf.org> <98405225-3ea3-471e-98a7-df079fcd3731@email.android.com> <4F68750F.6060104@tana.it> <2215525.feDxLYxsSs@scott-latitude-e6320>
In-Reply-To: <2215525.feDxLYxsSs@scott-latitude-e6320>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [67.160.203.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Tue, 20 Mar 2012 13:42:40 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of Scott Kitterman
> Sent: Tuesday, March 20, 2012 5:54 AM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for deprecatio=
n
>=20
> I was thinking the case under discussions would be more like:
>=20
> Authentication-Results: test.example.org; none (SPF skipped due to non-
> cacheable record)
> [...]

+1 to all of this.

-MSK


From agthisell@yahoo.com  Tue Mar 20 07:57:15 2012
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 85F9521F8531 for ; Tue, 20 Mar 2012 07:57:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.006
X-Spam-Level: 
X-Spam-Status: No, score=0.006 tagged_above=-999 required=5 tests=[AWL=0.005,  BAYES_50=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 7BKqVc4By2Ss for ; Tue, 20 Mar 2012 07:57:14 -0700 (PDT)
Received: from nm35.bullet.mail.ne1.yahoo.com (nm35.bullet.mail.ne1.yahoo.com [98.138.229.28]) by ietfa.amsl.com (Postfix) with SMTP id 2B27921F84FE for ; Tue, 20 Mar 2012 07:57:09 -0700 (PDT)
Received: from [98.138.90.53] by nm35.bullet.mail.ne1.yahoo.com with NNFMP; 20 Mar 2012 14:57:05 -0000
Received: from [98.138.87.11] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 20 Mar 2012 14:57:05 -0000
Received: from [127.0.0.1] by omp1011.mail.ne1.yahoo.com with NNFMP; 20 Mar 2012 14:57:05 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 832971.79717.bm@omp1011.mail.ne1.yahoo.com
Received: (qmail 25973 invoked by uid 60001); 20 Mar 2012 14:57:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1332255425; bh=QwHwaS6UzLRL5bzzTk4CNyrkYi3E2hYjwKiEPZ21aiM=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=6X12M63rDIcHzHNMG8cBP1Ugh5OoTTfokyRRx1vzzcwNGSWquknH8glcVIMyJbPoBjaa4r7x/7H2MFu0PtNid+nPSsOBYShUnyDlPECIMSYy+MfI9tym2l2pvOeWVbsSCWRqONW+jFV8mV/YqAzUMJVq3onamyhJSH6ElvlxoHM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=lebfe4+HKehDtUtIIGzLsqrH5LbORhBiz3BsmJfJlyCisF+TaHORrKh7t2dO3xtMhCWOQ63etLW6cYAxiQGcKLBHFYatzG1rhrvpgiePw4bFM7akG7xZlwP71rp+kjtNGuVhpXqdOpYTeM9tnU/gcS+k8UPwLeJtrrxjyj6RTOQ=;
X-YMail-OSG: Y2UOjKUVM1l9nEK.Dq1ND03C_8Co7pdh7Z9pAIpi1D7E.Aq aWV3M6wwMfSpGvoMszz0UBxQ2V3NUuYcD3G9na_7x6g0MMOMcba3RTlNMzai OlL2osNPgBR7aIXBnKRFgHw9vSJzmDIQnsq0cSOMdv1CoR2dCcBdvb7wn51Y 9fFkngIp8nSN4yncZhBtIQDi8TW98Wp4vRhdky.xAV0GCjlLpJkrIvnYK.Ed V78f8flAVsIcHmnXL_mry31mWlJOCY4i.d2G4Hy8VsFvJDm686i0T8qO31dm 50yqWgoYvX.LEzGcTaZgW65k.rHU7OB45siKijk6ccKyOW0pNbLAMlP1i2h7 NehWON3GbHMeQagD_7cjusdnuhaWJBEcMydT24kUXSKgck9WfPBQI.kW__lw TpC5dNRo0zLZBWw7uBJCqwutX0xUMC2Oz5UOy0qVe0EjZaNL4ovfq7wFC53s MJbE-
Received: from [71.61.133.134] by web125402.mail.ne1.yahoo.com via HTTP; Tue, 20 Mar 2012 07:57:05 PDT
X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427
Message-ID: <1332255425.8736.YahooMailClassic@web125402.mail.ne1.yahoo.com>
Date: Tue, 20 Mar 2012 07:57:05 -0700 (PDT)
From: Arthur Thisell 
To: spfbis@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [spfbis] Policies (was: 14: RFC 4408: local-part macro prep for 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: Tue, 20 Mar 2012 14:57:15 -0000

> The difference is that Best-Guess SPF imposes a record where there is none, > which is a complete policy fabrication.

There is some easy confusion here.

SPF stands for Sender Policy Framework, but it isn't really a sender policy, rather it is a domain owner's policy.  Its use has never really been extended into other policy areas the way Meng and Micrsoft (a la positional keywords in senderid) envisioned, so the name is somewhat misleading.

The SPF "best guess", isn't really a fabrication of a domain owner's policy, it is an email receiver policy.  It is perfectly ok for a receiver to implement any policy they want, including requiring IP addresses to be prime numbers or requiring at least one vowel in the sender's domain name.  I suppose that "best guess", like FCrDNS, does vaguely authenticate stuff, but if we put it in the Authentication-Results header, it needs to be clear that it is a receiver's policy.   In any case, I don't think "best guess" usage is really a subject that belongs here.

From SRS0=nJSb6=B3==stuart@gathman.org  Tue Mar 20 08:38:39 2012
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 6A06D21F85C4 for ; Tue, 20 Mar 2012 08:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level: 
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086,  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 4sPSBJxPOFz3 for ; Tue, 20 Mar 2012 08:38:39 -0700 (PDT)
Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id C0A0921F856D for ; Tue, 20 Mar 2012 08:38:38 -0700 (PDT)
Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q2KFbek9005302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Mar 2012 11:37:42 -0400
Message-ID: <4F68A478.7080906@gathman.org>
Date: Tue, 20 Mar 2012 11:38:32 -0400
From: Stuart Gathman 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: spfbis@ietf.org
References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <6.2.5.6.2.20120312111654.0adb2610@elandnews.com> <4916132.0TxoWXRv1F@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280866B5@exch-mbx901.corp.cloudmark.com>
In-Reply-To: <9452079D1A51524AA5749AD23E0039280866B5@exch-mbx901.corp.cloudmark.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451
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 Mar 2012 15:38:39 -0000

Long ago, Nostradamus foresaw that on 03/12/2012 03:15 PM, Murray S.
Kucherawy would write:
> 2) It's clear there are SPF verifiers that add Received-SPF, but it's
> not clear that anything other than humans actually consumes it. There
> are however implementations of RFC5451 (at least one) that do parse
> them inbound in order to conform
My MTAs parse Received-SPF from trusted forwarders, and accrue
reputation to the domain:spf-result therein.  Sure, I will eventually
handle A-R also, but it isn't done yet.  It is too soon to drop
Received-SPF.  Unlike type99, there is no penalty to having both headers
- other than a few bytes per message.  So mentioning the new header is
good.  But don't drop the old one.  Yet.

From johnl@iecc.com  Tue Mar 20 15:48:06 2012
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 3BB1921F85E5 for ; Tue, 20 Mar 2012 15:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.342
X-Spam-Level: 
X-Spam-Status: No, score=-110.342 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 TxcrTMV-6Ejk for ; Tue, 20 Mar 2012 15:48: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 6C0BC21F85D9 for ; Tue, 20 Mar 2012 15:48:05 -0700 (PDT)
Received: (qmail 11134 invoked from network); 20 Mar 2012 22:48:04 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Mar 2012 22:48: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:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f690924.xn--btvx9d.k1203; i=johnl@user.iecc.com; bh=ItiIyGINj2u+Bfebry3q7U4gzi9wk117q9hWnOY3hnQ=; b=uR3YfovlaqBv9OT4ht/vujHcIuy+QtXLrVezAwL2aaRgphGcSz+3pLtZhWQdW6kOCgJ8OuAJYjWhNrBH3jmj8C+wjTdmHINnsBP8PHgb6gQYkDU/cGZ74DF07L7rM/IDSOLMvTFKJbPOkxchHRMLaUqsQ2wI0MvLb/eVOxp2aVM=
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:vbr-info; s=4f690924.xn--btvx9d.k1203; olt=johnl@user.iecc.com; bh=ItiIyGINj2u+Bfebry3q7U4gzi9wk117q9hWnOY3hnQ=; b=IdoOEYG+u9qwODr9UbC+gIhD++x7bsd42+Vl846b40LAWNBi19MqHZkqCisTjryZ/FxPvR46SS3k5T3dz6cr+HCbTvqPw5jzj7HBPtmjx+XYFvtuxdFiX1m2sg5EUuLF9hrocMKluM5b376NdIOMvmFvvXuodIVLiXuvBBKe/js=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 20 Mar 2012 22:47:42 -0000
Message-ID: <20120320224742.68669.qmail@joyce.lan>
From: "John Levine" 
To: spfbis@ietf.org
In-Reply-To: <9452079D1A51524AA5749AD23E003928093B28@exch-mbx901.corp.cloudmark.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Cc: msk@cloudmark.com
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Tue, 20 Mar 2012 22:48:06 -0000

>Assuming we decide we want to say anything at all about the perceived problem, this seems like a reasonable
>compromise versus Doug's preference of removing or disabling the local part macros outright.

Based on the limited data I've seen, there seems to be remarkably
little cacheing of any of the DNS records typically looked up for
e-mail, such as rDNS, DNSBLs, and SPF.

As far as I know, nobody's ever seen cache thrashing due to SPF, so
nobody's ever tried to deal with it, and we have no idea how well
various solutions would work.  I would strongly discourage us from
recommending untried solutions to hypothetical problems in a standards
track document.

R's,
John

From dotis@mail-abuse.org  Tue Mar 20 17:09:21 2012
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 4716821F84E4 for ; Tue, 20 Mar 2012 17:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.426
X-Spam-Level: 
X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 ezcCi98-0+py for ; Tue, 20 Mar 2012 17:09:20 -0700 (PDT)
Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id B902021F84DF for ; Tue, 20 Mar 2012 17:09:20 -0700 (PDT)
Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 2415617404C3 for ; Wed, 21 Mar 2012 00:09:20 +0000 (UTC)
Message-ID: <4F691C2F.1000703@mail-abuse.org>
Date: Tue, 20 Mar 2012 17:09:19 -0700
From: Douglas Otis 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <1332212794.1494.YahooMailClassic@web125404.mail.ne1.yahoo.com>
In-Reply-To: <1332212794.1494.YahooMailClassic@web125404.mail.ne1.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] on theoretical attacks (was: Draft agenda for IETF83)
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 Mar 2012 00:09:21 -0000

On 3/19/12 8:06 PM, Arthur Thisell wrote:
>  Based on what I've read, I too feel that putting up a 20min session
>  on the amplification factor would not be productive.
>
> > As John pointed out, despite Doug vocally asserting this as a
> > significant issue, he has not attracted significant (I was going to
> > say any) support within the community of folks actively working in
> > this space.
>
>  It isn't that the subject of a DDOS attack and the amplification
>  factor hasn't gotten any support, it is Doug's presentation that
>  hasn't. Doug wasn't the first to raise the subject of SPF's
>  amplification. Indeed, the vastly more restrictive processing limits
>  in libspf2 were added before Doug made his first post on the
>  subject.

Dear Arthur,

This concern has continued from when SPF advocated 20 deep recursions as 
a method to constrain the DNS transactions that SPF generated from one 
message.

>  The problem is that Doug has done nothing new and is still presenting
>  his old ID as if it hasn't been read, analyzed and rejected. Indeed,
>  he recently wrote:
>
> > the use of macros and insensitivity to no-data errors permits a 1
> > KB message to generate (34.8KB +28.8 KB) x 4 or 254KB of victim
> > traffic against any domain that simply supports DNS.
>
>  There is the problem. A scary 254k number, but ignores the flaw
>  that it isn't 1KB of traffic that the attacker needs to be able to
>  generate in order to create that attack, it is far larger.

The number of resource records an attacker needs to publish in order to 
enable this reflected attack will not reduce the traffic experienced by 
victims.  This assertion also ignores different treatments for negative 
responses versus an attacker's positive responses.

The attacker has a significant advantage when requested negative 
durations by victim's domains are often shortened to avoid dealing with 
"disruption" induced support calls.  Once their campaign exceeds 
negative caching durations used by recipients and the attack sequence 
repeats, an attacker's resources will be locally cached with 
transactions repeated against their victims.  At this point, no new 
responses are required by the attacker!  There is nothing that prevents 
the same resources from being shared between an attacker's various Mail 
 From domains to leverage these hot and evil cached resources.

Regards,
Douglas Otis



From dotis@mail-abuse.org  Tue Mar 20 20:16:54 2012
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 1CC9621F84D8 for ; Tue, 20 Mar 2012 20:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.43
X-Spam-Level: 
X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 cm5V2Obu9h0y for ; Tue, 20 Mar 2012 20:16:53 -0700 (PDT)
Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id A704721F84D3 for ; Tue, 20 Mar 2012 20:16:53 -0700 (PDT)
Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 80372174015B for ; Wed, 21 Mar 2012 03:16:53 +0000 (UTC)
Message-ID: <4F694825.2080609@mail-abuse.org>
Date: Tue, 20 Mar 2012 20:16:53 -0700
From: Douglas Otis 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120320224742.68669.qmail@joyce.lan>
In-Reply-To: <20120320224742.68669.qmail@joyce.lan>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Wed, 21 Mar 2012 03:16:54 -0000

On 3/20/12 3:47 PM, John Levine wrote:
>> Assuming we decide we want to say anything at all about the perceived problem, this seems like a reasonable
>> compromise versus Doug's preference of removing or disabling the local part macros outright.
> Based on the limited data I've seen, there seems to be remarkably
> little cacheing of any of the DNS records typically looked up for
> e-mail, such as rDNS, DNSBLs, and SPF.
Dear John,

Those processing SPF records while running an MTA are unlikely to notice 
their participation in a DDoS attack orchestrated with SPF.  Those 
impacted by SPF will be unable to implement a remedy.
> As far as I know, nobody's ever seen cache thrashing due to SPF, so
> nobody's ever tried to deal with it, and we have no idea how well
> various solutions would work.  I would strongly discourage us from
> recommending untried solutions to hypothetical problems in a standards
> track document.
The goal is not to make changes in how SPF is normally used.  The goal 
is to ensure SPF retains its widely used utility for enumerating 
addresses of a domain's outbound servers.  SPF has never been widely 
used as intended.  There is no way to predict what revival of this 
flawed specification may have on its use.  It is prudent to consider 
what increased processing of SPF may have with its related security 
concerns.  Security concerns that extend beyond those that may 
inadvertently abuse DNS with hundreds of transactions ignoring no-data 
errors initiated with recipient resources by unknown entities.

Regards,
Douglas Otis


From vesely@tana.it  Wed Mar 21 02:27:17 2012
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 2077821F8569 for ; Wed, 21 Mar 2012 02:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.657
X-Spam-Level: 
X-Spam-Status: No, score=-4.657 tagged_above=-999 required=5 tests=[AWL=0.062,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdnrRqXeRM2l for ; Wed, 21 Mar 2012 02:27:16 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 44D9F21F8567 for ; Wed, 21 Mar 2012 02:27:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332322026; bh=Noy3xcz56AcSHbP9r0nvH0xa393qiZ9EPRycYxSlRRo=; l=1349; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=bmNhkNcYUzzJSaohHw0qTiS9Td2BocPtLXe+YTMB/gQ5IkonXqjs9jAVV14yS0L8h GucNwNNteYn9FjTMXvwLltoHsnPhQ1ns7PZO9OnfEZhRiU7cgptcTYRzaNgd0LjQp9 vliH4HE7mEccoNWTLRupNNZO9CJ7zfxUiF0xyhWE=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 21 Mar 2012 10:27:06 +0100 id 00000000005DC039.000000004F699EEA.00000814
Message-ID: <4F699EEA.9050908@tana.it>
Date: Wed, 21 Mar 2012 10:27:06 +0100
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120320224742.68669.qmail@joyce.lan> <4F694825.2080609@mail-abuse.org>
In-Reply-To: <4F694825.2080609@mail-abuse.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Wed, 21 Mar 2012 09:27:17 -0000

On 21/Mar/12 04:16, Douglas Otis wrote:
> On 3/20/12 3:47 PM, John Levine wrote:
>
>> Based on the limited data I've seen, there seems to be remarkably
>> little cacheing of any of the DNS records typically looked up for
>> e-mail, such as rDNS, DNSBLs, and SPF.

At least, responses originating from the same message should get
cached during the message processing, in case various tools running at
the same MTA are unable to reuse one another's results.

>> As far as I know, nobody's ever seen cache thrashing due to SPF, so
>> nobody's ever tried to deal with it, and we have no idea how well
>> various solutions would work.  I would strongly discourage us from
>> recommending untried solutions to hypothetical problems in a standards
>> track document.
>
> The goal is not to make changes in how SPF is normally used.  The goal
> is to ensure SPF retains its widely used utility for enumerating
> addresses of a domain's outbound servers.

Do we have utilities for counting how many IPv4/6 addresses does an
SPF record mean to "pass"?  Comparing the number of (connected
components of) good addresses to the number of queries required to
determine it should measure the efficacy of SPF records.  IMHO, the
boundary between poor efficacy and malicious attack is subjective, but
such is any measure of domain reputation.


From dotis@mail-abuse.org  Wed Mar 21 17:31:34 2012
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 A3FC121E805A for ; Wed, 21 Mar 2012 17:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.434
X-Spam-Level: 
X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 a8NvgGm1HxtR for ; Wed, 21 Mar 2012 17:31:34 -0700 (PDT)
Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE1321E8015 for ; Wed, 21 Mar 2012 17:31:34 -0700 (PDT)
Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 07EBB17403B0 for ; Thu, 22 Mar 2012 00:31:34 +0000 (UTC)
Message-ID: <4F6A72E5.8090509@mail-abuse.org>
Date: Wed, 21 Mar 2012 17:31:33 -0700
From: Douglas Otis 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120320224742.68669.qmail@joyce.lan> <4F694825.2080609@mail-abuse.org> <4F699EEA.9050908@tana.it>
In-Reply-To: <4F699EEA.9050908@tana.it>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #14: RFC 4408: local-part macro prep for  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: Thu, 22 Mar 2012 00:31:34 -0000

On 3/21/12 2:27 AM, Alessandro Vesely wrote:
> On 21/Mar/12 04:16, Douglas Otis wrote:
> At least, responses originating from the same message should get 
> cached during the message processing, in case various tools running at 
> the same MTA are unable to reuse one another's results.
Dear Alessandro,

Agreed, several messages may exist within an SMTP session.  When just 
the right-hand-side of email-addresses are used for SPF record checks, a 
single check would apply for all messages of a domain.  Precluding 
"postmaster" local-parts from authorizing the server could impair NDN 
acceptance and degrade interchange compatibility.

Reusing checks for messages of the same domain would be ideal.  Users 
should be authenticated prior to messages being sent anyway.  After all, 
left-hand-side restrictions were recently deprecated in DKIM where it 
did not cause the additional overhead seen with SPF.  Expecting 
recipients to confirm local-parts has serious scaling issues.  
Fortunately this rarely attempted mechanism can be "nipped in the bud" 
before it becomes a serious problem.
>> The goal is not to make changes in how SPF is normally used.  The goal
>> is to ensure SPF retains its widely used utility for enumerating
>> addresses of a domain's outbound servers.
> Do we have utilities for counting how many IPv4/6 addresses does an
> SPF record mean to "pass"?  Comparing the number of (connected
> components of) good addresses to the number of queries required to
> determine it should measure the efficacy of SPF records.  IMHO, the
> boundary between poor efficacy and malicious attack is subjective, but
> such is any measure of domain reputation.
Such measurements will be difficult when SPF records contain "i" or "l" 
macros.  Domain reputations for SPF will also immediately confront 
latency issues.  Reputation checks are normally based upon source IP 
addresses used by TCP connections.  This occurs well before SPF domains 
can be verified as authorized.  Often these checks only occur prior to 
sending NDNs.   With latency being a problem, reputation checks are 
unlikely able to preclude problematic SPF record domains.   However, 
problematic macro elements can be proactively precluded instead.  With 
use of problematic macros being rare, careful preclusion should not 
prove disruptive especially when specifications offer guidance for both 
senders and receivers.

Regards,
Douglas Otis

From pmidge@microsoft.com  Thu Mar 22 13:03:39 2012
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 5141221F8566 for ; Thu, 22 Mar 2012 13:03:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.249
X-Spam-Level: 
X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 3wAtTJbbr+59 for ; Thu, 22 Mar 2012 13:03:38 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 832B021F855B for ; Thu, 22 Mar 2012 13:03:38 -0700 (PDT)
Received: from mail193-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Thu, 22 Mar 2012 20:03:29 +0000
Received: from mail193-ch1 (localhost [127.0.0.1])	by mail193-ch1-R.bigfish.com (Postfix) with ESMTP id 9CCC7260235; Thu, 22 Mar 2012 20:03:29 +0000 (UTC)
X-SpamScore: -26
X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail193-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail193-ch1 (localhost.localdomain [127.0.0.1]) by mail193-ch1 (MessageSwitch) id 1332446607838431_18187; Thu, 22 Mar 2012 20:03:27 +0000 (UTC)
Received: from CH1EHSMHS019.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229])	by mail193-ch1.bigfish.com (Postfix) with ESMTP id C354B1C0065;	Thu, 22 Mar 2012 20:03:27 +0000 (UTC)
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 22 Mar 2012 20:03:27 +0000
Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.137]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Thu, 22 Mar 2012 20:03:30 +0000
From: Paul Midgen 
To: S Moonesamy , "spfbis@ietf.org" 
Thread-Topic: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451
Thread-Index: AQHNASt8riiDXAOHs0WFsEmeapwSlJZqJQEAgAylY/A=
Date: Thu, 22 Mar 2012 20:03:29 +0000
Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E20F65CEA@TK5EX14MBXC292.redmond.corp.microsoft.com>
References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <6.2.5.6.2.20120312111654.0adb2610@elandnews.com> <4916132.0TxoWXRv1F@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280866B5@exch-mbx901.corp.cloudmark.com>  <4F5F3AF5.4000406@tana.it> <90491c3c-748f-49d9-9f64-d96f6d2edb69@email.android.com> <2cdc6262-63b4-4743-affb-4d2352fdd298@email.android.com> <6.2.5.6.2.20120314113845.09b3b920@resistor.net>
In-Reply-To: <6.2.5.6.2.20120314113845.09b3b920@resistor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.35]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451
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 Mar 2012 20:03:39 -0000

After reading through all this, and being a new implementer of SPF that alr=
eady implements RFC5451, if given the choice I will not stamp Received-SPF.

I'd prefer not to because (believe it or not, every byte counts) this reduc=
es mail storage cost. RFC5451 already provides the opportunity to remove a =
bunch of other x- headers Hotmail inflicted on itself, so I don't see the p=
oint in adding redundancy.

Since I'm not removing Received-SPF from an existing implementation, this s=
eems in-line with current sentiment.

-p

-----Original Message-----
From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of=
 S Moonesamy
Sent: Wednesday, March 14, 2012 11:53 AM
To: spfbis@ietf.org
Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451

This is a summary of the comments on Issue #10.  As usual, if I misinterpre=
ted or misunderstood your comments, please let me know.

Issue #10 was opened based on the message at http://www.ietf.org/mail-archi=
ve/web/spfbis/current/msg00330.html

Scott Kitterman believes that Authentication-Results is technically suitabl=
e to replace Received-SPF but he does not think that it can be done now [1]=
.  Murray Kucherawy mentioned that it clear there are SPF verifiers that ad=
d Received-SPF, but it's not clear that anything other than humans actually=
 consumes it.  He mentioned that there are however implementations of RFC54=
51 (at least one) that do parse them inbound in order to conform to the "re=
move your own on inbound"=20
requirement that specification imposes [2].  He concluded that it is safe a=
nd within the charter to switch.  Scott Kitterman pointed out that there is=
 an implementation that consumes the Received-SPF header and mentioned that=
 the feature is widely used [3].

Barry Leiba, as a participant, pointed out that deprecating "Received-SPF" =
means saying that it's in current use, but new implementations are advised =
not to generate it (basically, SHOULD NOT).  For something that has enough =
usage that we can't remove it (yes, the charter goes against that), noting =
that it's on the way out and new implementations shouldn't generate it seem=
s to be the right way to go [4].  Alessandro Vesely suggested a MAY, noting=
 that the evolution is toward the more homogeneous A-R, but allowing plenty=
 of time to migrate [5].

Scott Kitterman mentioned that since automatic processing generally takes p=
lace within an ADMD, switching isn't something that has global interoperabi=
lity impacts [6].

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00861.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00862.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00863.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00872.html
5. http://www.ietf.org/mail-archive/web/spfbis/current/msg00879.html
6. http://www.ietf.org/mail-archive/web/spfbis/current/msg00880.html

_______________________________________________
spfbis mailing list
spfbis@ietf.org
https://www.ietf.org/mailman/listinfo/spfbis



From spf2@kitterman.com  Thu Mar 22 14:01:23 2012
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 E77DE21E802D for ; Thu, 22 Mar 2012 14:01:22 -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.004,  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 uB9ti0k6w4Fm for ; Thu, 22 Mar 2012 14:01:21 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CACC621E802B for ; Thu, 22 Mar 2012 14:01:21 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A770F20E40BD; Thu, 22 Mar 2012 17:01:20 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332450080; bh=dxcB9gwHqN7zkoWn8/vxINgPyzys1ZEkBkuxbbF14mU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=S/UJhUN9a/SpsxO3rZlz0TZIIFMQC0JNgU2caqYzpVxBWrkeI5x0tiF4u/UeqIN3W c4QlwKo3XTyho7pr3Jw9XyYQrMUfCojNNyHADeSt/MFB77lQUO8J+KWeEhvwzqNhMd /fScoa57SqiWnox+z4hLMVR/NBdV/mqX1Cm92pgw=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8C87920E408F;  Thu, 22 Mar 2012 17:01:20 -0400 (EDT)
From: Scott Kitterman 
To: spfbis@ietf.org
Date: Thu, 22 Mar 2012 17:01:19 -0400
Message-ID: <1788008.TexYV2zLNy@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E20F65CEA@TK5EX14MBXC292.redmond.corp.microsoft.com>
References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <6.2.5.6.2.20120314113845.09b3b920@resistor.net> <7F7F36E50398F84DBAF25C9D51732F1E20F65CEA@TK5EX14MBXC292.redmond.corp.microsoft.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] #10: RFC 4408 replace Received-SPF with RFC5451
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 Mar 2012 21:01:23 -0000

On Thursday, March 22, 2012 08:03:29 PM Paul Midgen wrote:
> After reading through all this, and being a new implementer of SPF that
> already implements RFC5451, if given the choice I will not stamp
> Received-SPF.
> 
> I'd prefer not to because (believe it or not, every byte counts) this
> reduces mail storage cost. RFC5451 already provides the opportunity to
> remove a bunch of other x- headers Hotmail inflicted on itself, so I don't
> see the point in adding redundancy.
> 
> Since I'm not removing Received-SPF from an existing implementation, this
> seems in-line with current sentiment.

Agreed.  By definition, no one is depending on your implementation providing 
Received-SPF and which you provide is primarily a matter for how you chose to 
do things within your overall ADMD.  There are people that relay out of 
Hotmail to other providers for final delivery that might prefer to see both, 
but it's not like they are getting anything now.

Scott K

From vesely@tana.it  Fri Mar 23 01:07:16 2012
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 0F85E21F84CD for ; Fri, 23 Mar 2012 01:07:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.659
X-Spam-Level: 
X-Spam-Status: No, score=-4.659 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3DYwBrwRwPr for ; Fri, 23 Mar 2012 01:07:11 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 807D721F843C for ; Fri, 23 Mar 2012 01:07:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332490029; bh=rG++4LtaUAYQ9jcWH8YE+7iKW1D1x5D5uhBIGnf+qUM=; l=1343; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Afs7HUTNO89rgdJxSlap6OnxUcTwAk+eRGSoQGYrBfNQvWGmGreI7yD+9/iQUCw/l K8mgPvnzEU1j2iP6eoHt8G1Lawqe1+vFebXNLrt9HbZ4WhEBufOw3HLgP4ArT6NDoU rUmWo7xASwNkDT88owwyVaWbLdNb2FQp6LFyMCw0=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 23 Mar 2012 09:07:09 +0100 id 00000000005DC03F.000000004F6C2F2D.00001FE0
Message-ID: <4F6C2F2C.8020405@tana.it>
Date: Fri, 23 Mar 2012 09:07:08 +0100
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <6.2.5.6.2.20120314113845.09b3b920@resistor.net> <7F7F36E50398F84DBAF25C9D51732F1E20F65CEA@TK5EX14MBXC292.redmond.corp.microsoft.com> <1788008.TexYV2zLNy@scott-latitude-e6320>
In-Reply-To: <1788008.TexYV2zLNy@scott-latitude-e6320>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451
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 Mar 2012 08:07:16 -0000

On 22/Mar/12 22:01, Scott Kitterman wrote:
> On Thursday, March 22, 2012 08:03:29 PM Paul Midgen wrote:
>> After reading through all this, and being a new implementer of SPF that
>> already implements RFC5451, if given the choice I will not stamp
>> Received-SPF.
>> 
>> I'd prefer not to because (believe it or not, every byte counts) this
>> reduces mail storage cost. RFC5451 already provides the opportunity to
>> remove a bunch of other x- headers Hotmail inflicted on itself, so I don't
>> see the point in adding redundancy.
>> 
>> Since I'm not removing Received-SPF from an existing implementation, this
>> seems in-line with current sentiment.
> 
> Agreed.  By definition, no one is depending on your implementation providing 
> Received-SPF and which you provide is primarily a matter for how you chose to 
> do things within your overall ADMD.

+1, it makes sense to encourage new implementations to use A-R (only).

> There are people that relay out of Hotmail to other providers for
> final delivery that might prefer to see both, but it's not like
> they are getting anything now.

Hm... some implementations rename that to Original-Received-SPF.  The
old header field was not designed for forwarding.  (Actually, SPF
itself was not designed for forwarding, but this mumbling belongs to
the other thread...)

From sm@elandsys.com  Fri Mar 23 02:11:23 2012
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 53FD421F854D for ; Fri, 23 Mar 2012 02:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.594
X-Spam-Level: 
X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 FPEfLGdBClOG for ; Fri, 23 Mar 2012 02:11:18 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD6B21F854A for ; Fri, 23 Mar 2012 02:11:18 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.237.94]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2N9B0w4008239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Mar 2012 02:11:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1332493872; i=@elandsys.com; bh=DQaJ+Zzm/H1ObVQWcvLXoiKP7JEPic0WF758tavouBs=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=jSWEr2Yb53XmjDQ5oLOmrA7S+tKvzb5q1D2O8EMvTAXuGLhqfSu61eaTAvrnBHZJf R6mM1i2EzSVGpy/0X2zTqUSNzpMtKovpFX9wUitVz4LfIGbmKui6ebmwiKghAW9NQh L14KQOUzlC/1NcmtyBjtv3kG9hB6RHob9iJiai7o=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1332493872; i=@elandsys.com; bh=DQaJ+Zzm/H1ObVQWcvLXoiKP7JEPic0WF758tavouBs=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=Rtl4w0gPSY0y7LZ5ff8KLQlZ1tBc4OZmCRw6nRRrA/lDKSFLTvhhWaa7EwUiQOW2U JW3ydYGZb5mWHkmshV7tOtj8GFTsYuvG+5ojGThfooybJdzJxxpWDtZ3kxIsyVWuOP vq3AQ5w0gX95SP5EghzyNWc8ikzkYzak1vBLystM=
Message-Id: <6.2.5.6.2.20120323015120.09d62710@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 23 Mar 2012 01:59:20 -0700
To: spfbis@ietf.org
From: S Moonesamy 
In-Reply-To: <061.7b579813c6f1a0e79af162f7d410113b@tools.ietf.org>
References: <061.7b579813c6f1a0e79af162f7d410113b@tools.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [spfbis] #11: RFC 4408 Section 4 check_host() function
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 Mar 2012 09:11:23 -0000

At 03:44 08-02-2012, spfbis issue tracker wrote:
>#11: RFC 4408 Section 4 check_host() function
>
>  Message from Murray Kucherawy on 7 Feb 2012:
>
>  The use of a "check_host()"=9D in a standards track RFC smacks of us=
 defining
>  an API, which I think the IETF tries to avoid.  (The greybeards in here
>  can correct me if I'm wrong.)  After staring at the RFC4408 text for a
>  while, it seems to me it could be rewritten to avoid this construct
>  without losing any detail.
>
>  I realize that's a little bit hypocritical coming from one of the co-
>  editors of RFC6376, which defined a set of inputs, some outputs (one
>  required, others optional), and some end states, but RFC4408 is a lot=
 more
>  blatant about it, for example by going so far as naming the function;
>  somehow in my head it crosses a line that RFC6376 avoided.  I think it
>  comes down to the difference between specifying a function and describing
>  an algorithm.
>
>  http://www.ietf.org/mail-archive/web/spfbis/current/msg00359.html

[snip]

>Ticket URL: 

Please comment on Issue #11.  I am opening it so=20
that it can also be discussed during the IETF meeting.

Regards,
S. Moonesamy
SPFBIS WG co-chair  =20


From spf2@kitterman.com  Fri Mar 23 02:39:13 2012
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 7AEBF21F84B6 for ; Fri, 23 Mar 2012 02:39:13 -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.004,  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 YzVYzxg7aTMH for ; Fri, 23 Mar 2012 02:39:09 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0CD21F84B2 for ; Fri, 23 Mar 2012 02:39:09 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7E7BD20E40BD; Fri, 23 Mar 2012 05:39:07 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332495547; bh=7r+jt9xw0SjpL2fidw2JZa83EJfjwjEXIIA6sYQ5vJk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Raf4xQZPYzBEEP2xZ/TF5IbmQt36ucjuAjyX/Q0n2kRUaZigwfffRDDiTk6NNYOA9 r4CzC8N/YMkhLP6XDbEZNLndj0KeKVMhpTbB+h69DpXigCB9ETMf/dTulOz4Yfj6K6 IKrTQiOW8lzGJ4NWlTmiz90a2FAbhynP+enTVOic=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 61C8320E408F;  Fri, 23 Mar 2012 05:39:07 -0400 (EDT)
From: Scott Kitterman 
To: spfbis@ietf.org
Date: Fri, 23 Mar 2012 05:39:06 -0400
Message-ID: <6142523.ruCe9BVMMC@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <6.2.5.6.2.20120323015120.09d62710@elandnews.com>
References: <061.7b579813c6f1a0e79af162f7d410113b@tools.ietf.org> <6.2.5.6.2.20120323015120.09d62710@elandnews.com>
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] #11: RFC 4408 Section 4 check_host() function
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 Mar 2012 09:39:13 -0000

On Friday, March 23, 2012 01:59:20 AM S Moonesamy wrote:
> At 03:44 08-02-2012, spfbis issue tracker wrote:
> >#11: RFC 4408 Section 4 check_host() function
> >
> >  Message from Murray Kucherawy on 7 Feb 2012:
> > =20
> >  The use of a "check_host()"=9D in a standards track RFC smacks of =
us
> >  defining an API, which I think the IETF tries to avoid.  (The
> >  greybeards in here can correct me if I'm wrong.)  After staring at=

> >  the RFC4408 text for a while, it seems to me it could be rewritten=
 to
> >  avoid this construct without losing any detail.
> > =20
> >  I realize that's a little bit hypocritical coming from one of the =
co-
> >  editors of RFC6376, which defined a set of inputs, some outputs (o=
ne
> >  required, others optional), and some end states, but RFC4408 is a =
lot
> >  more blatant about it, for example by going so far as naming the
> >  function; somehow in my head it crosses a line that RFC6376 avoide=
d.=20
> >  I think it comes down to the difference between specifying a funct=
ion
> >  and describing an algorithm.
> > =20
> >  http://www.ietf.org/mail-archive/web/spfbis/current/msg00359.html
>=20
> [snip]
>=20
> >Ticket URL: 
>=20
> Please comment on Issue #11.  I am opening it so
> that it can also be discussed during the IETF meeting.

-1 on this proposal.

Maintaining backwards compatiblity is a very high priority in the chart=
er. =20
When we re-write text, and particularly re-writing entire sections, we =
risk=20
introdcuing inadvertent functional changes.  We don't have the benefit =
of=20
assuming future readers of 4408bis will know we meant to be compatible =
with=20
4408 and understand from that intent how to interpret new text.

The best way to maintain backward compatibility is not to change things=
.  For=20
an issue like this, where there's no technical issue, just a stylist on=
e,=20
taking the risk of inadvertently changing some aspect of the technical=20=

functionality is not worth whatever modest benefit might be associated =
with a=20
different style of writing the document.

Scott K

From vesely@tana.it  Fri Mar 23 02:57:29 2012
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 D1A3721F8545 for ; Fri, 23 Mar 2012 02:57:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.359
X-Spam-Level: 
X-Spam-Status: No, score=-4.359 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_48=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 gMHbJ3nlUV0h for ; Fri, 23 Mar 2012 02:57:25 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 10DBB21F8543 for ; Fri, 23 Mar 2012 02:57:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332496643; bh=wzLYuble6ndJY8cxJ0zRh0OH1e6dr7FjlqtdehlQf74=; l=3268; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=jQFYD2kvI9/pCK7JBHN/938n5asjMVuZfpYrDEaKaGgzoLPDsK13DQNQifKnlFQ9d +i4keZZerkppLF3g4oXphvGbgi9iVLBAAJjgNdHteM+ZBRQGplHcxuXKfmbPaVZMJM IQuh/BzOlRzTsOBEPSCWg15hAFcjmO6PuXG5kSrs=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 23 Mar 2012 10:57:23 +0100 id 00000000005DC039.000000004F6C4903.000039D2
Message-ID: <4F6C4903.8090901@tana.it>
Date: Fri, 23 Mar 2012 10:57:23 +0100
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320> <4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320>
In-Reply-To: <1961226.eMbsOy0Kc2@scott-latitude-e6320>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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 Mar 2012 09:57:30 -0000

On 16/Mar/12 19:25, Scott Kitterman wrote:
> On Friday, March 16, 2012 07:09:11 PM Alessandro Vesely wrote:
>> 
>> Section 9 explains it very well, but doesn't solve it.  Are we
>> standardizing SPF in the hope that people will spontaneously fix
>> forwarding, and at that point, maybe, dare say that they fixed it
>> because it was broken?
> 
> It is quite possible to check SPF at SMTP time and reject on SPF
> Fail without rejecting mail due to forwarding.  I've written
> software that gives administrators the tools to do it (tools are
> the easy part - knowing what data to put in the tools is harder),
> but mostly it doesn't scale for large operators.
> 
> At the other end of the scale, you have massive operators like
> Gmail who can use SPF and other inputs to figure out who the
> forwarders are and not reject based on SPF for such hosts.
> 
> None of it's easy, but it's fundamentally doable if the receiver
> cares to.  No matter what we write in an RFC, we can't make them
> care.

RFC 4408 repeatedly mentions the possibility to reject messages that
fail SPF.  Indeed, that was the original idea of the protocol, IIRC.

John confirms that forwarding is "not going away, SPF does what it
does."  Nevertheless, I think it is a moral obligation for a standard
writer to figure out and describe how to make things work.  Operators
who know better will do their way, under their responsibility.  But it
is insane to air a possibility --reject on fail-- which we know does
not work.

> There are other possibilities that are clearly out of scope for
> SPFbis.  DMARC proposed to use SPF and DKIM in combination.  Their
> protocol 'handles' forwarding.

They seem to be asking "Did you mean 'reject' when you said '-all'?"

> Perhaps, someday, someone will understand the situation well enough
> to write an applicability statement that explains all about how to
> integrate SMTP forwarding and SPF, but I don't think there's
> anything much beyond a better written section 9 we can do in
> 4408bis.

Shall we stay experimental until then?  Or will 4408bis be such an
irresponsible specification as to result in an SDO being unable to
comply with its own standards:  I see DMARC reporting messages failing
SPF with smtp.mailfrom=ietf.org because they are forwarded to Google
without changing smtp.mailfrom.  I see bounces from IETF's role
addresses (I-D@tools.ietf.org) due to the same reason.  (The
postmaster said:
  Yes.  Sight.  I've run into this particular problem before, it's
  been discussed on the tools-discuss list and on the wgchairs list,
  and I've asked if there's a clearcut recommendation I can follow,
  and the response has been such that I conclude that any changes I
  can make also has equally serious (different) consequences.  It's
  apparently (not that I know enough about SPF to be able to
  adjudicate this, but that's the way I've understood the responses
  I've received) an inherent problem with SPF....
)

The possible solutions I see are as follows:

* Recklessly pretend that the problem doesn't exist,
* prohibit rejection on SPF fail,
* specify under what conditions it is safe to reject on SPF fail,
* update SMTP to make forwarding SPF-compatible, or
* deprecate SPF altogether.

From vesely@tana.it  Fri Mar 23 03:03:36 2012
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 A8E8B21F854C for ; Fri, 23 Mar 2012 03:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.657
X-Spam-Level: 
X-Spam-Status: No, score=-4.657 tagged_above=-999 required=5 tests=[AWL=0.062,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIYZq8MRtzzt for ; Fri, 23 Mar 2012 03:03:32 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 376C221F8545 for ; Fri, 23 Mar 2012 03:03:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332497011; bh=KLSbFMQPNImmlC3oggpYC8AYVv8NHVQQtnCJTJqaWLI=; l=1491; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=KarbSgh1/6lN1djRU3UorzYTLf6WoOEixdEc4gIeGtd4Ta4SsBF+a37qES8V9qF2y Xz2xlzfYo0yI0LBT+Mh60YtwcEU8qkA4VGlEhSEGN3mw7IUo+4dPCw5Wx7Xg5qtY6L 4OqiSSOusvbfBtSHd8ttLebkaXo/A3v8C1CUMLP4=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 23 Mar 2012 11:03:31 +0100 id 00000000005DC039.000000004F6C4A73.00003B34
Message-ID: <4F6C4A73.9010009@tana.it>
Date: Fri, 23 Mar 2012 11:03:31 +0100
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <061.7b579813c6f1a0e79af162f7d410113b@tools.ietf.org> <6.2.5.6.2.20120323015120.09d62710@elandnews.com> <6142523.ruCe9BVMMC@scott-latitude-e6320>
In-Reply-To: <6142523.ruCe9BVMMC@scott-latitude-e6320>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #11: RFC 4408 Section 4 check_host() function
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 Mar 2012 10:03:36 -0000

On 23/Mar/12 10:39, Scott Kitterman wrote:
> On Friday, March 23, 2012 01:59:20 AM S Moonesamy wrote:
>
>>> RFC4408 is a lot more blatant about it, for example by going so
>>> far as naming the function; somehow in my head it crosses a
>>> line that RFC6376 avoided. I think it comes down to the
>>> difference between specifying a function and describing an
>>> algorithm.
>> 
>> Please comment on Issue #11.  I am opening it so that it can also
>> be discussed during the IETF meeting.
> 
> -1 on this proposal.
> 
> Maintaining backwards compatiblity is a very high priority in the
> charter. When we re-write text, and particularly re-writing entire
> sections, we risk introdcuing inadvertent functional changes.  We
> don't have the benefit of assuming future readers of 4408bis will
> know we meant to be compatible with 4408 and understand from that
> intent how to interpret new text.
> 
> The best way to maintain backward compatibility is not to change
> things.  For an issue like this, where there's no technical issue,
> just a stylist one, taking the risk of inadvertently changing some
> aspect of the technical functionality is not worth whatever modest
> benefit might be associated with a different style of writing the
> document.

Although I basically agree with Scott, it could be added (e.g. in
Section 1.2) that the function name being used is not an API entry
point and that such terminology is used for clarity and historical
reasons only.

From sm@elandsys.com  Fri Mar 23 03:21:39 2012
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 F0F1F21F854D for ; Fri, 23 Mar 2012 03:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.594
X-Spam-Level: 
X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 2Q7l3IBjXDrL for ; Fri, 23 Mar 2012 03:21: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 C7B7221F8549 for ; Fri, 23 Mar 2012 03:21:34 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.237.94]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2NALHCd006821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Mar 2012 03:21:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1332498089; i=@elandsys.com; bh=rLEgJvtbEeMeeijIH/+z5RmrJ+IWVXzBFnugMxb1GZg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=3LtcLXTiupzPT7ipHDD1idtiktKpeoVLYc7TZPsaBIzsbRRMJ9fsis9nGV9APKrm6 Q7X4pRIT1riWNPvD7ES5fQ6OlngfOytbWpyyMe48MHOE++QoIvnXJqfLnK49NLRPbu sFYq7njZXoQDCVMH0wP8tEulWJskF6I+7mtIXCCw=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1332498089; i=@elandsys.com; bh=rLEgJvtbEeMeeijIH/+z5RmrJ+IWVXzBFnugMxb1GZg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=2S8dXzi1HS8IiRxDeIgiDKQrY1uQJps2l2X+nLb78Euw6swXOxhrgv8WcRxec4Ljm CMHzhiIuDcLKT/FCFXUkDYWHT1YV4ki37xb0OPbeuMIcKFY3ol68LzX68Q7zuklB5v OV86PTxtCoPZX6GXGXvywEAhAhL9Y1G1huDDNPVU=
Message-Id: <6.2.5.6.2.20120323020007.0968fd88@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 23 Mar 2012 02:35:22 -0700
To: spfbis@ietf.org
From: S Moonesamy 
In-Reply-To: <20120316221227.14457.qmail@joyce.lan>
References: <1961226.eMbsOy0Kc2@scott-latitude-e6320> <20120316221227.14457.qmail@joyce.lan>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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 Mar 2012 10:21:40 -0000

This is a rough summary of the discussion about Issue #12.  As usual, 
if you are misquoted or misunderstood, please let me know.

Issue #12 is based on a message posted on February 10 [1].  Murray 
Kucherawy does not agree about making a correction to Section 3.9.1 
of RFC 5332 in 4408bis [2].  He also mentioned that the empty string 
effectively disables SPF, making forwarding into an attack 
vector.  He also pointed out that SPF stands on its own without SRS 
and there is very little adoption of the later.  He mentioned that 
encouraging the use of _spf is a substantial departure from the deployed base.

Alessandro Vesely pointed out that there are implementations that 
violate 3.9.1 by not leaving "the rest of the envelope" (that is, 
RFC5321.MailFrom) unchanged.  As that change was triggered by SPF, it 
should be up to SPF to spell the text that 5321bis will hopefully 
adopt [3].  He also mentioned that Forwarding has other shortcomings 
that ought to be fixed, but they are not related to SPF.

Scott Kitterman does not think that any functional changes to 9.2 are 
needed [4] or that 5321 should be updated by 4408bis.  He also 
mentioned in another message that _spf is in common use but it is an 
arbitrary convention, not a feature of the protocol [5].

Murray Kucherawy alluded to a message from John Levine and commented 
that SPF not is sufficiently heavyweight to say that RFC5321 3.9.1 
got it wrong.  SPF is effectively a layer on top of 
SMTP.  Environments that don't use SPF might rely on the opposite behavior.

John Levine mentioned that there isn't anything to standardize in 
SRS.  It's basically a single user recipient of VERP, encoding stuff 
in the bounce address to provide hints about what bounced.  Like VERP 
and BATV, the limit on mailbox length gives it has fairly severe 
interop problems if you want it work reliably as opposed to being a 
heuristic [6].

Stuart Gathman pointed out that the RFC should address one of the 
common receiver mistakes; checking SPF on forwarded mail [7].  He 
also mentioned that RFC 4408 9.3.3.1 describes several options but 
the MUST NOT for the receiver end is missing.
There is a strong implication that if you can't handle your own forwarding,
then SPF results are invalid [8].  Philip Gladstone pointed out that 
users do not control anything about these systems except the 
forwarding tables [9].

John Levine mentioned that the general discussion in 9.3 is fine 
[10].  Commerco WebMaster  reported not having any real issues with 
SPF and forwarding (using -all) [11].  Philip Gladstone  posted some 
statistics and pointed out that sites forward email from me without 
doing SRS and which would get dropped if I used a -all [12].  John 
Leslie mentioned that
some domains avoid publishing -all, specifically because of 
uncertainty over possible forwarding [13] and that some MTA managers 
_check_ SPF, but don't respect -all -- instead recording the SPF 
results in a header.

Scott Kitterman mentioned that Forwarding is already a small niche 
and from an SPF protocol design perspective he think it can be 
ignored [14].  John Levine pointed out that people collecting and 
sending mail at sites separate
from their home domain [15].

Alessandro Vesely suggested some possible solutions [16].

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00374.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00883.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00893.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00882.html
5. http://www.ietf.org/mail-archive/web/spfbis/current/msg00895.html
6. http://www.ietf.org/mail-archive/web/spfbis/current/msg00902.html
7. http://www.ietf.org/mail-archive/web/spfbis/current/msg00904.html
8. http://www.ietf.org/mail-archive/web/spfbis/current/msg00907.html
9. http://www.ietf.org/mail-archive/web/spfbis/current/msg00910.html
10. http://www.ietf.org/mail-archive/web/spfbis/current/msg00912.html
11. http://www.ietf.org/mail-archive/web/spfbis/current/msg00913.html
12. http://www.ietf.org/mail-archive/web/spfbis/current/msg00914.html
13. http://www.ietf.org/mail-archive/web/spfbis/current/msg00922.html
14. http://www.ietf.org/mail-archive/web/spfbis/current/msg00931.html
15. http://www.ietf.org/mail-archive/web/spfbis/current/msg00933.html
16. http://www.ietf.org/mail-archive/web/spfbis/current/msg00969.html


From spf2@kitterman.com  Fri Mar 23 04:00:38 2012
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 44E2821F8527 for ; Fri, 23 Mar 2012 04:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level: 
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, SARE_SUB_ENC_UTF8x2=0.246]
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 UZiLlaU8sq4e for ; Fri, 23 Mar 2012 04:00:34 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id CE0E021F852E for ; Fri, 23 Mar 2012 04:00:33 -0700 (PDT)
Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id B85B8D0407E; Fri, 23 Mar 2012 06:00:32 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332500432; bh=2aT7hED3gGk0RNhVhW8VzLF2jmiezHR+MzLRuCT2fxM=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=nu4sPzfucXd4gHbAaCTYZ/eEhnawTXoOnxKIyvcSVSsrB3WRTJQc8H/djZvbJMe9L puH6YMEzx1C87oUNH9dDup3rmdjEbAjNhrIuyJ2AKz0biEFN/XJXMcGjTr8i1As4yK r3rI+m8Act7MEIj/Sfm5uCaFM8DQ4WMQBlyIAcQc=
Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 433E2D04060;  Fri, 23 Mar 2012 06:00:31 -0500 (CDT)
References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320> <4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320> <4F6C4903.8090901@tana.it>
User-Agent: K-9 Mail for Android
In-Reply-To: <4F6C4903.8090901@tana.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Scott Kitterman 
Date: Fri, 23 Mar 2012 07:00:32 -0400
To: spfbis@ietf.org
Message-ID: <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com>
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] =?utf-8?q?=2312=3A_RFC_4408_Section_9_-_Forwarding_and_h?= =?utf-8?q?elo=09identities?=
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 Mar 2012 11:00:38 -0000

Alessandro Vesely  wrote:

>On 16/Mar/12 19:25, Scott Kitterman wrote:
>> On Friday, March 16, 2012 07:09:11 PM Alessandro Vesely wrote:
>>> 
>>> Section 9 explains it very well, but doesn't solve it.  Are we
>>> standardizing SPF in the hope that people will spontaneously fix
>>> forwarding, and at that point, maybe, dare say that they fixed it
>>> because it was broken?
>> 
>> It is quite possible to check SPF at SMTP time and reject on SPF
>> Fail without rejecting mail due to forwarding.  I've written
>> software that gives administrators the tools to do it (tools are
>> the easy part - knowing what data to put in the tools is harder),
>> but mostly it doesn't scale for large operators.
>> 
>> At the other end of the scale, you have massive operators like
>> Gmail who can use SPF and other inputs to figure out who the
>> forwarders are and not reject based on SPF for such hosts.
>> 
>> None of it's easy, but it's fundamentally doable if the receiver
>> cares to.  No matter what we write in an RFC, we can't make them
>> care.
>
>RFC 4408 repeatedly mentions the possibility to reject messages that
>fail SPF.  Indeed, that was the original idea of the protocol, IIRC.

Yes, but no where is it mandated. With one specific exception, RFC 4408 is silent on receiver policy. That is not an accident. 

>John confirms that forwarding is "not going away, SPF does what it
>does."  Nevertheless, I think it is a moral obligation for a standard
>writer to figure out and describe how to make things work.  Operators
>who know better will do their way, under their responsibility.  But it
>is insane to air a possibility --reject on fail-- which we know does
>not work.

Sure it does.  I've published a -all SPF record since before RFC 4408 was published and I know some receivers reject on fail because every now and then I get bounces due to forwarding (in these few cases, I just resend the message).

I've published software that has some reasonably wide use that defaults to reject on fail. No one has ever suggested this default was problematic. FWIW, defer on temperror (which used to be the default) did cause problems, did generate complaints, and I did change it.

>> There are other possibilities that are clearly out of scope for
>> SPFbis.  DMARC proposed to use SPF and DKIM in combination.  Their
>> protocol 'handles' forwarding.
>
>They seem to be asking "Did you mean 'reject' when you said '-all'?"
>
Among other things, yes.

>> Perhaps, someday, someone will understand the situation well enough
>> to write an applicability statement that explains all about how to
>> integrate SMTP forwarding and SPF, but I don't think there's
>> anything much beyond a better written section 9 we can do in
>> 4408bis.
>
>Shall we stay experimental until then?  Or will 4408bis be such an
>irresponsible specification as to result in an SDO being unable to
>comply with its own standards:  I see DMARC reporting messages failing
>SPF with smtp.mailfrom=ietf.org because they are forwarded to Google
>without changing smtp.mailfrom.  I see bounces from IETF's role
>addresses (I-D@tools.ietf.org) due to the same reason.  (The
>postmaster said:
>  Yes.  Sight.  I've run into this particular problem before, it's
>  been discussed on the tools-discuss list and on the wgchairs list,
>  and I've asked if there's a clearcut recommendation I can follow,
>  and the response has been such that I conclude that any changes I
>  can make also has equally serious (different) consequences.  It's
>  apparently (not that I know enough about SPF to be able to
>  adjudicate this, but that's the way I've understood the responses
>  I've received) an inherent problem with SPF....
>)
>
>The possible solutions I see are as follows:
>
>* Recklessly pretend that the problem doesn't exist,
>* prohibit rejection on SPF fail,
>* specify under what conditions it is safe to reject on SPF fail,
>* update SMTP to make forwarding SPF-compatible, or
>* deprecate SPF altogether.

Section 9 of RFC 4408 contains a veritable compendium of things that can be done at the beginning, middle, and end of the transit of a message. I don't see a lot more to be done.

I think the real issue here is you want receiver policy specified and RFC 4408 generally avoids that. Rather than argue about forwarding and receiver policy (which is only one aspect of it), perhaps it would be more useful for you to open a new issue on that more general topic.

Scott K


From spf2@kitterman.com  Fri Mar 23 04:11:10 2012
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 B71E821F8568 for ; Fri, 23 Mar 2012 04:11:10 -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.007,  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 tTMmEYxHEbpg for ; Fri, 23 Mar 2012 04:11:06 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2995B21F8535 for ; Fri, 23 Mar 2012 04:11:06 -0700 (PDT)
Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id C504AD0407E; Fri, 23 Mar 2012 06:11:05 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332501065; bh=2Yo0tJYjr37I8V9kfgzSMZIihVLYuegyj1HNHi2p79U=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=mlf8JBHAS7Ywln1bc32nXxQye8+xZOuDP9BPARNO2m5pbTwF3u+75WD/ksF9hYr1O 3HgYWJ10uzVi+4/PTtGHVVnPnMQQQ54AMcjYMFy+mUHpr6QQmXbASj/Eo+NSZUsRTf EiUDMZnQ0lKVNxbflKCjgcagGxBbgxzr8IAWZAe0=
Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9313CD04060;  Fri, 23 Mar 2012 06:11:05 -0500 (CDT)
References: <1961226.eMbsOy0Kc2@scott-latitude-e6320> <20120316221227.14457.qmail@joyce.lan> <6.2.5.6.2.20120323020007.0968fd88@resistor.net>
User-Agent: K-9 Mail for Android
In-Reply-To: <6.2.5.6.2.20120323020007.0968fd88@resistor.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Scott Kitterman 
Date: Fri, 23 Mar 2012 07:11:17 -0400
To: spfbis@ietf.org
Message-ID: 
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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 Mar 2012 11:11:10 -0000

S Moonesamy  wrote:

>This is a rough summary of the discussion about Issue #12.  As usual, 
>if you are misquoted or misunderstood, please let me know.
>
>Issue #12 is based on a message posted on February 10 [1].  Murray 
>Kucherawy does not agree about making a correction to Section 3.9.1 
>of RFC 5332 in 4408bis [2].  He also mentioned that the empty string 
>effectively disables SPF, making forwarding into an attack 
>vector.  He also pointed out that SPF stands on its own without SRS 
>and there is very little adoption of the later.  He mentioned that 
>encouraging the use of _spf is a substantial departure from the
>deployed base.
>
>Alessandro Vesely pointed out that there are implementations that 
>violate 3.9.1 by not leaving "the rest of the envelope" (that is, 
>RFC5321.MailFrom) unchanged.  As that change was triggered by SPF, it 
>should be up to SPF to spell the text that 5321bis will hopefully 
>adopt [3].  He also mentioned that Forwarding has other shortcomings 
>that ought to be fixed, but they are not related to SPF.
>
>Scott Kitterman does not think that any functional changes to 9.2 are 
>needed [4] or that 5321 should be updated by 4408bis.  He also 
>mentioned in another message that _spf is in common use but it is an 
>arbitrary convention, not a feature of the protocol [5].
>
>Murray Kucherawy alluded to a message from John Levine and commented 
>that SPF not is sufficiently heavyweight to say that RFC5321 3.9.1 
>got it wrong.  SPF is effectively a layer on top of 
>SMTP.  Environments that don't use SPF might rely on the opposite
>behavior.
>
>John Levine mentioned that there isn't anything to standardize in 
>SRS.  It's basically a single user recipient of VERP, encoding stuff 
>in the bounce address to provide hints about what bounced.  Like VERP 
>and BATV, the limit on mailbox length gives it has fairly severe 
>interop problems if you want it work reliably as opposed to being a 
>heuristic [6].
>
>Stuart Gathman pointed out that the RFC should address one of the 
>common receiver mistakes; checking SPF on forwarded mail [7].  He 
>also mentioned that RFC 4408 9.3.3.1 describes several options but 
>the MUST NOT for the receiver end is missing.
>There is a strong implication that if you can't handle your own
>forwarding,
>then SPF results are invalid [8].  Philip Gladstone pointed out that 
>users do not control anything about these systems except the 
>forwarding tables [9].
>
>John Levine mentioned that the general discussion in 9.3 is fine 
>[10].  Commerco WebMaster  reported not having any real issues with 
>SPF and forwarding (using -all) [11].  Philip Gladstone  posted some 
>statistics and pointed out that sites forward email from me without 
>doing SRS and which would get dropped if I used a -all [12].  John 
>Leslie mentioned that
>some domains avoid publishing -all, specifically because of 
>uncertainty over possible forwarding [13] and that some MTA managers 
>_check_ SPF, but don't respect -all -- instead recording the SPF 
>results in a header.
>
>Scott Kitterman mentioned that Forwarding is already a small niche 
>and from an SPF protocol design perspective he think it can be 
>ignored [14].  John Levine pointed out that people collecting and 
>sending mail at sites separate
>from their home domain [15].
>
>Alessandro Vesely suggested some possible solutions [16].
>
>Regards,
>S. Moonesamy
>
>1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00374.html
>2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00883.html
>3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00893.html
>4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00882.html
>5. http://www.ietf.org/mail-archive/web/spfbis/current/msg00895.html
>6. http://www.ietf.org/mail-archive/web/spfbis/current/msg00902.html
>7. http://www.ietf.org/mail-archive/web/spfbis/current/msg00904.html
>8. http://www.ietf.org/mail-archive/web/spfbis/current/msg00907.html
>9. http://www.ietf.org/mail-archive/web/spfbis/current/msg00910.html
>10. http://www.ietf.org/mail-archive/web/spfbis/current/msg00912.html
>11. http://www.ietf.org/mail-archive/web/spfbis/current/msg00913.html
>12. http://www.ietf.org/mail-archive/web/spfbis/current/msg00914.html
>13. http://www.ietf.org/mail-archive/web/spfbis/current/msg00922.html
>14. http://www.ietf.org/mail-archive/web/spfbis/current/msg00931.html
>15. http://www.ietf.org/mail-archive/web/spfbis/current/msg00933.html
>16. http://www.ietf.org/mail-archive/web/spfbis/current/msg00969.html
>
I also mentioned not having problems with -all and forwarding. I disagree with the characterization of what Alessandro suggested in [16] as solutions.

Scott K

From spf2@kitterman.com  Fri Mar 23 05:31:39 2012
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 F168321F84EB for ; Fri, 23 Mar 2012 05:31:38 -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.007,  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 dB44d41EjCY3 for ; Fri, 23 Mar 2012 05:31:34 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B6F6421F851D for ; Fri, 23 Mar 2012 05:31:34 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2C68620E40BD; Fri, 23 Mar 2012 08:31:34 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332505894; bh=dAEbGNnykCsjZL20i5Ct6z4S+QvKAiD36gNmS1JJ/S0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=czApIIjRkwma4VLP1oObZg8U9ojlinTSDN0ZS15udpLq4wVk15fVTnoaZCdFQNAYr sAyiJ1DqTcxrOvzI/s59Ifw7WG3iAJroTFGbMGOlN6LJwB42NaYq9qUalAuPysMMiI tNnD/kA0/tkx6kq2ItwlfiWhJWPG5qLoN3FACiPM=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 12B9220E4083;  Fri, 23 Mar 2012 08:31:33 -0400 (EDT)
From: Scott Kitterman 
To: spfbis@ietf.org
Date: Fri, 23 Mar 2012 08:31:33 -0400
Message-ID: <10049000.JnkWhYZNpC@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <4F6C4A73.9010009@tana.it>
References: <061.7b579813c6f1a0e79af162f7d410113b@tools.ietf.org> <6142523.ruCe9BVMMC@scott-latitude-e6320> <4F6C4A73.9010009@tana.it>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] #11: RFC 4408 Section 4 check_host() function
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 Mar 2012 12:31:39 -0000

On Friday, March 23, 2012 11:03:31 AM Alessandro Vesely wrote:
> On 23/Mar/12 10:39, Scott Kitterman wrote:
> > On Friday, March 23, 2012 01:59:20 AM S Moonesamy wrote:
> >>> RFC4408 is a lot more blatant about it, for example by going so
> >>> far as naming the function; somehow in my head it crosses a
> >>> line that RFC6376 avoided. I think it comes down to the
> >>> difference between specifying a function and describing an
> >>> algorithm.
> >> 
> >> Please comment on Issue #11.  I am opening it so that it can also
> >> be discussed during the IETF meeting.
> > 
> > -1 on this proposal.
> > 
> > Maintaining backwards compatiblity is a very high priority in the
> > charter. When we re-write text, and particularly re-writing entire
> > sections, we risk introdcuing inadvertent functional changes.  We
> > don't have the benefit of assuming future readers of 4408bis will
> > know we meant to be compatible with 4408 and understand from that
> > intent how to interpret new text.
> > 
> > The best way to maintain backward compatibility is not to change
> > things.  For an issue like this, where there's no technical issue,
> > just a stylist one, taking the risk of inadvertently changing some
> > aspect of the technical functionality is not worth whatever modest
> > benefit might be associated with a different style of writing the
> > document.
> 
> Although I basically agree with Scott, it could be added (e.g. in
> Section 1.2) that the function name being used is not an API entry
> point and that such terminology is used for clarity and historical
> reasons only.

I think something like this is reasonable.

Scott K

From vesely@tana.it  Fri Mar 23 10:07:46 2012
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 5F14621F85EC for ; Fri, 23 Mar 2012 10:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.659
X-Spam-Level: 
X-Spam-Status: No, score=-4.659 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vscWNy41Wvrz for ; Fri, 23 Mar 2012 10:07:42 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id BF29921F85E3 for ; Fri, 23 Mar 2012 10:07:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332522460; bh=PnBzo6SdE4cJ2tdjWPSc4tolwwec3Cgjho7m+4MxLm4=; l=2106; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=LEeQJkg64k3Wn1LTHIN3iPylSp5+NPx6ejBfM4RW1YWaQ7BhtdOq3W5rR6PPFTk50 TAiO8FI4L1uESkqubIfKiW/kStA6S3+cmm7buySquOlDnTuoAW75B1nFCs4va61a6d tkBlWYyq0adpexZ6D3rVGFaR4+rLKvIIU/CKotN4=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 23 Mar 2012 18:07:40 +0100 id 00000000005DC039.000000004F6CADDC.00002893
Message-ID: <4F6CADDC.1000005@tana.it>
Date: Fri, 23 Mar 2012 18:07:40 +0100
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320> <4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320> <4F6C4903.8090901@tana.it> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com>
In-Reply-To: <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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 Mar 2012 17:07:46 -0000

On 23/Mar/12 12:00, Scott Kitterman wrote:
> Alessandro Vesely  wrote:
> 
>>The possible solutions I see are as follows:
>>
>>* Recklessly pretend that the problem doesn't exist,
>>* prohibit rejection on SPF fail,
>>* specify under what conditions it is safe to reject on SPF fail,
>>* update SMTP to make forwarding SPF-compatible, or
>>* deprecate SPF altogether.
> 
> Section 9 of RFC 4408 contains a veritable compendium of things
> that can be done at the beginning, middle, and end of the transit
> of a message. I don't see a lot more to be done.

I'd leave aside possible amendments to that text, for the time being.

> I think the real issue here is you want receiver policy specified
> and RFC 4408 generally avoids that.

>From a formal POV, it does so.  However, reject-on-fail is mentioned
in prominent passages of the spec, and not by mistake.  Many people,
including myself, have been advocating an even stronger position on
receiver policy.  As a result, reject-on-fail is widespread enough to
cause problems.

Of course, we can pretend there is no problem, 1st bullet above, but
that's not a useful answer to tools.ietf.org's postmaster and many
others like him.  It's a conceptual decision that I'm after, a
strategic resolution on what we /think/ is the best use of SPF.  I
think we'll work better, as a WG, if we share the same determination.
I'm open to any logical settlement, anything such that three hosts
implementing the spirit of the spec interoperate as expected.

> Rather than argue about forwarding and receiver policy (which is
> only one aspect of it), perhaps it would be more useful for you to
> open a new issue on that more general topic.

What more general topic?  This ticket is already too wide to be
practical for wordsmithing purposes, but I think it is just enough to
cover the issue at hand.  For example, we could plan, according to the
middle bullet, to trust the helo identity for forwarded messages, if
there were more than a few domains who cared to define an SPF record
for each helo identity they use...

From msk@cloudmark.com  Fri Mar 23 10:20:24 2012
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 8739621F85A1 for ; Fri, 23 Mar 2012 10:20:24 -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=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJbhgkFUAFFR for ; Fri, 23 Mar 2012 10:20:24 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id ED5CE21F85A0 for ; Fri, 23 Mar 2012 10:20:23 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 10:20:23 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] #11: RFC 4408 Section 4 check_host() function
Thread-Index: AQHNCNTsuGze43OZA0CdRV3SG3SoxpZ4FUMAgAAG0oCAAClcgP//199g
Date: Fri, 23 Mar 2012 17:20:22 +0000
Message-ID: <9452079D1A51524AA5749AD23E003928098E32@exch-mbx901.corp.cloudmark.com>
References: <061.7b579813c6f1a0e79af162f7d410113b@tools.ietf.org> <6142523.ruCe9BVMMC@scott-latitude-e6320>	<4F6C4A73.9010009@tana.it> <10049000.JnkWhYZNpC@scott-latitude-e6320>
In-Reply-To: <10049000.JnkWhYZNpC@scott-latitude-e6320>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.20.2.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] #11: RFC 4408 Section 4 check_host() function
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 Mar 2012 17:20:24 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of Scott Kitterman
> Sent: Friday, March 23, 2012 5:32 AM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] #11: RFC 4408 Section 4 check_host() function
>=20
> > > Maintaining backwards compatiblity is a very high priority in the
> > > charter. When we re-write text, and particularly re-writing entire
> > > sections, we risk introdcuing inadvertent functional changes.  We
> > > don't have the benefit of assuming future readers of 4408bis will
> > > know we meant to be compatible with 4408 and understand from that
> > > intent how to interpret new text.

By the same token, I don't agree that the change I'm proposing makes any th=
reat to backward compatibility.  The algorithm itself is certainly unchange=
d; it's the presentation of the algorithm in the form of a (loose) API defi=
nition that I think we should avoid.

We went through a similar exercise with the promotion of DKIM to Draft Stan=
dard and it was successful, so I'm looking to provide SPF with the benefits=
.

> > > The best way to maintain backward compatibility is not to change
> > > things.  For an issue like this, where there's no technical issue,
> > > just a stylist one, taking the risk of inadvertently changing some
> > > aspect of the technical functionality is not worth whatever modest
> > > benefit might be associated with a different style of writing the
> > > document.

I think it's more than a stylistic point.  For Experimental documents the b=
ar is pretty low in terms of what gets through to publication, but for Stan=
dards Track documents the evaluation is more rigorous.  In that sense, the =
"We shouldn't specify APIs" mantra that pops its head up now and then in th=
e IETF is more likely to strike us this time around.  We need to be careful=
 to avoid it or we'll be forced to deal with it at a less convenient point =
in the document's evolution.

> > Although I basically agree with Scott, it could be added (e.g. in
> > Section 1.2) that the function name being used is not an API entry
> > point and that such terminology is used for clarity and historical
> > reasons only.
>=20
> I think something like this is reasonable.

Adding text to say the "check_host()" thing is an illustration point only a=
nd not an API definition is probably a reasonable compromise.  We could ask=
 our ADs to be sure.

-MSK

From spf2@kitterman.com  Fri Mar 23 10:20:50 2012
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 C4B2721F8604 for ; Fri, 23 Mar 2012 10:20:50 -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.007,  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 5jnMS1--nnck for ; Fri, 23 Mar 2012 10:20:46 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 87E8021F8595 for ; Fri, 23 Mar 2012 10:20:46 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C8A8720E40BD; Fri, 23 Mar 2012 13:20:45 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332523245; bh=lD74r9InWKCN49qMB6vohk2jPFStQpJDlD9zuQoHccI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=V4iwBgTR6Q5ehhaNgdA4TOJ+SHkBQUF9ElRYVzmFf3jEvOffupG51fn54vZ46c7Zi r63IwT4isYj9fFIK6KHIcSSz/gLSD03E6TlJYIFrKM8JsxW4/40vyVKAoMqalj2Oko YWhOoM6tzV3vpsc/taddR8qrkysCcuLLbcozsojM=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id AEEC620E4083;  Fri, 23 Mar 2012 13:20:45 -0400 (EDT)
From: Scott Kitterman 
To: spfbis@ietf.org
Date: Fri, 23 Mar 2012 13:20:45 -0400
Message-ID: <16658996.WWsWQrny8L@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <4F6CADDC.1000005@tana.it>
References: <20120315175753.21172.qmail@joyce.lan> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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 Mar 2012 17:20:50 -0000

On Friday, March 23, 2012 06:07:40 PM Alessandro Vesely wrote:
> > Rather than argue about forwarding and receiver policy (which is
> > only one aspect of it), perhaps it would be more useful for you to
> > open a new issue on that more general topic.
> 
> What more general topic?  This ticket is already too wide to be
> practical for wordsmithing purposes, but I think it is just enough to
> cover the issue at hand.  For example, we could plan, according to the
> middle bullet, to trust the helo identity for forwarded messages, if
> there were more than a few domains who cared to define an SPF record
> for each helo identity they use...

The more general topic is "Should 4408bis be more prescriptive about receiver 
policy?"  With the exception of MUST treat Neutral and None the same there are 
no hard receiver policy requirements 4408.  All of the others are in the vain 
of "If you ... then ...".  

Getting beyond that to try and specify receiver policy would, IMO, be a 
mistake, but I think it should be generally discussed by the group rather than 
bolted onto this issue.  If we're going to specify it, we should broadly 
specify it, not just for dealing with forwarding.  If we're not going to 
generally specify receiver policy, then (obviously) we shouldn't.

Depending on how this discussion comes out, that will affect what it is 
reasonable to try and specify for forwarding.

Scott K

From msk@cloudmark.com  Fri Mar 23 10:32:13 2012
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 DE32421F860F for ; Fri, 23 Mar 2012 10:32:12 -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=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YekO02e+1Gax for ; Fri, 23 Mar 2012 10:32:12 -0700 (PDT)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id C942F21F860B for ; Fri, 23 Mar 2012 10:32:11 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 10:32:11 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
Thread-Index: AQHNCRd5di1lS/R2VEyGB3ryw8yxn5Z4IIBQ
Date: Fri, 23 Mar 2012 17:32:10 +0000
Message-ID: <9452079D1A51524AA5749AD23E003928098E77@exch-mbx901.corp.cloudmark.com>
References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320>	<4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320>	<4F6C4903.8090901@tana.it> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it>
In-Reply-To: <4F6CADDC.1000005@tana.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.20.2.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo	identities
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 Mar 2012 17:32:13 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of Alessandro Vesely
> Sent: Friday, March 23, 2012 10:08 AM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident=
ities
>=20
> From a formal POV, it does so.  However, reject-on-fail is mentioned in
> prominent passages of the spec, and not by mistake.  Many people,
> including myself, have been advocating an even stronger position on
> receiver policy.  As a result, reject-on-fail is widespread enough to
> cause problems.

I'm quite sure at least Scott will tire of me holding up DKIM as an example=
 of a better way to do things, but I'm talking here about the document, not=
 the protocol.  :-)

As has been said, SPF tried at least in part to present a mechanism that wa=
s "safe" for reject-on-fail.  There's also common advice that says one shou=
ldn't do this even when asked to so because of SPF's failure modes.  Indeed=
, this sentiment has even spilled over into the nascent DMARC work.

DKIM, on the other hand, retreated from that position some time ago and act=
ually says that people shouldn't reject mail on failure specifically becaus=
e of legitimate failure modes.  It should simply be input into a larger eva=
luation mechanism.

So I obviously don't advocate for "recklessly pretend the problem doesn't e=
xist", but I do think we can only go so far in terms of giving people rope.=
  Being more assertive in our description of the problem and recommendation=
s is probably quite appropriate.

We can't prohibit rejection on SPF fail, in the same way that we can't dema=
nd people discard on ADSP failures.

The last two options (update SMTP, deprecate SPF) sound like non-starters.

> Of course, we can pretend there is no problem, 1st bullet above, but
> that's not a useful answer to tools.ietf.org's postmaster and many
> others like him.  It's a conceptual decision that I'm after, a
> strategic resolution on what we /think/ is the best use of SPF.  I
> think we'll work better, as a WG, if we share the same determination.
> I'm open to any logical settlement, anything such that three hosts
> implementing the spirit of the spec interoperate as expected.

Interoperability for SPF, in my view, only goes as far as the evaluation fu=
nction produces the same result for everyone given the same inputs.  The ac=
tual action taken by the receiver is not our concern, just like with DKIM, =
although we can provide strong advice and explain why we think it's the rig=
ht advice.

-MSK

From msk@cloudmark.com  Fri Mar 23 10:33:55 2012
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 C41F121F84BF for ; Fri, 23 Mar 2012 10:33:55 -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=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Okn1oaDrqq+i for ; Fri, 23 Mar 2012 10:33:55 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0C65721F8499 for ; Fri, 23 Mar 2012 10:33:55 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 10:33:54 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451
Thread-Index: AQHNASt8VedQGBvKIkWWdm+y3YjKp5ZqmloAgAymWoCAABApgIAAugYAgAAo05A=
Date: Fri, 23 Mar 2012 17:33:53 +0000
Message-ID: <9452079D1A51524AA5749AD23E003928098ED8@exch-mbx901.corp.cloudmark.com>
References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <6.2.5.6.2.20120314113845.09b3b920@resistor.net> <7F7F36E50398F84DBAF25C9D51732F1E20F65CEA@TK5EX14MBXC292.redmond.corp.microsoft.com> <1788008.TexYV2zLNy@scott-latitude-e6320> <4F6C2F2C.8020405@tana.it>
In-Reply-To: <4F6C2F2C.8020405@tana.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.20.2.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451
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 Mar 2012 17:33:55 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of Alessandro Vesely
> Sent: Friday, March 23, 2012 1:07 AM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451
>=20
> > There are people that relay out of Hotmail to other providers for
> > final delivery that might prefer to see both, but it's not like they
> > are getting anything now.
>=20
> Hm... some implementations rename that to Original-Received-SPF.  The
> old header field was not designed for forwarding.  (Actually, SPF
> itself was not designed for forwarding, but this mumbling belongs to
> the other thread...)

Why would they do that?  As I recall, Received-SPF includes an indication o=
f who added it, so this shouldn't strictly be necessary.

Worth documenting in any case.

-MSK

From spf2@kitterman.com  Fri Mar 23 10:48:10 2012
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 6E57F21F8631 for ; Fri, 23 Mar 2012 10:48:10 -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.007,  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 9j2Vi6H8h0O5 for ; Fri, 23 Mar 2012 10:48:06 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 08C4921F8629 for ; Fri, 23 Mar 2012 10:48:06 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9402820E40BD; Fri, 23 Mar 2012 13:48:05 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332524885; bh=p/RpwdMjuwhxZK6HQLO7jfivpJkngjGYkv7nZ2KoI9U=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=n5mVUbp8OM31WTwvqPwGsSJib1pWG4AwGzHXVXmnGOgGERBpNNf8fLDKgPgrHX9Ws D9GFUPyG61xh01+Z1WtIjZhVaQTycAsF8IW8vW6bFU8XiQNs6wXreEfo5JtvETkY5O JtnPCSxX/6GiNh7cOFgXZ5DHutwnUCS/rNtYr0n4=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 76A2020E4083;  Fri, 23 Mar 2012 13:48:05 -0400 (EDT)
From: Scott Kitterman 
To: spfbis@ietf.org
Date: Fri, 23 Mar 2012 13:48:04 -0400
Message-ID: <2511919.PKh0OllOnr@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <9452079D1A51524AA5749AD23E003928098E77@exch-mbx901.corp.cloudmark.com>
References: <20120315175753.21172.qmail@joyce.lan> <4F6CADDC.1000005@tana.it> <9452079D1A51524AA5749AD23E003928098E77@exch-mbx901.corp.cloudmark.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] #12: RFC 4408 Section 9 - Forwarding and helo	identities
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 Mar 2012 17:48:10 -0000

On Friday, March 23, 2012 05:32:10 PM Murray S. Kucherawy wrote:
> > -----Original Message-----
> > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf
> > Of Alessandro Vesely Sent: Friday, March 23, 2012 10:08 AM
> > To: spfbis@ietf.org
> > Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo
> > identities
> > 
> > From a formal POV, it does so.  However, reject-on-fail is mentioned in
> > prominent passages of the spec, and not by mistake.  Many people,
> > including myself, have been advocating an even stronger position on
> > receiver policy.  As a result, reject-on-fail is widespread enough to
> > cause problems.
> 
> I'm quite sure at least Scott will tire of me holding up DKIM as an example
> of a better way to do things, but I'm talking here about the document, not
> the protocol.  :-)
> 
> As has been said, SPF tried at least in part to present a mechanism that was
> "safe" for reject-on-fail.  There's also common advice that says one
> shouldn't do this even when asked to so because of SPF's failure modes. 
> Indeed, this sentiment has even spilled over into the nascent DMARC work.
> 
> DKIM, on the other hand, retreated from that position some time ago and
> actually says that people shouldn't reject mail on failure specifically
> because of legitimate failure modes.  It should simply be input into a
> larger evaluation mechanism.

I'm happy to learn lessons for improvement from wherever they come.  I'm not 
sure this is a good parallel, however.  You are correct that DKIM avoids any 
policy proscriptions, but I don't think that's a fair comparison because the 
scope of SPF is more like DKIM + ADSP than just DKIM.  It would be very odd to 
have something with policy as it's middle name that avoided policy.

I don't think that DKIM + ADSP is very generally useful.  It is far less 
useful than SPF with -all IMO.  It may be inherent or it may be because the 
DKIM working group ignored policy considerations when DKIM was being developed 
and only tried to bolt it on at the end.  There's really no way to know for 
sure (this isn't just looking in the rear view mirror - I argued when the DKIM 
working group was formed not to do it that way, but I lost out).

I think that the answer to the question of "Is reject on fail safe" and the 
question of "Is publishing a -all record safe" is very firmly "It depends".  
Sometimes it is and sometimes it isn't (in answer to both questions), so I 
think if we try to come up with a one size fits all for 4408bis we'll get one 
size fits approximately none.

I'm quite comfortable with the idea of a range of options for what receivers 
might do (and have written code that supports pretty much all of them I can 
think of) and only providing guidance in terms of "If you ..., then you 
SHOULD/MUST ...".

Scott K

From vesely@tana.it  Fri Mar 23 10:59:32 2012
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 E342E21F850C for ; Fri, 23 Mar 2012 10:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.659
X-Spam-Level: 
X-Spam-Status: No, score=-4.659 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia2SoHD7m1-T for ; Fri, 23 Mar 2012 10:59:28 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5706721F8567 for ; Fri, 23 Mar 2012 10:59:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332525567; bh=zswzJNXXLY+f1vgZ0VWpOFfBnHprkF8LWxK7bey+9P4=; l=1242; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=AyhH8tsLoVTiHDhx9KYB0dYPEOIjnMvhVOFY8fnU83+F2ZZbq58xfZRK+HPYHuAD8 vc/dtC0U71sOhRK7nNS8B/GspC64Do5j3ZuQzy6xuIDLSurHcRyE5KIv+1Jk4x1+k0 ZpG5HFqq4iyUv3beGql8cxiF16+KMtp2uSwe/sVM=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 23 Mar 2012 18:59:27 +0100 id 00000000005DC042.000000004F6CB9FF.000035C7
Message-ID: <4F6CB9FF.5090506@tana.it>
Date: Fri, 23 Mar 2012 18:59:27 +0100
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120315175753.21172.qmail@joyce.lan> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it> <16658996.WWsWQrny8L@scott-latitude-e6320>
In-Reply-To: <16658996.WWsWQrny8L@scott-latitude-e6320>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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 Mar 2012 17:59:33 -0000

On 23/Mar/12 18:20, Scott Kitterman wrote:
> 
> The more general topic is "Should 4408bis be more prescriptive
> about receiver policy?"  With the exception of MUST treat Neutral
> and None the same there are no hard receiver policy requirements
> 4408.  All of the others are in the vain of "If you ... then ...".

Yes.  It is weakly expressed also due to standardization reasons that
I keep forgetting.  However, phrases like "local policy can take
stronger action against such E-Mail, such as rejecting it" are pretty
understandable even without MUSTard.

> Getting beyond that to try and specify receiver policy would, IMO,
> be a mistake, but I think it should be generally discussed by the
> group rather than bolted onto this issue.  If we're going to
> specify it, we should broadly specify it, not just for dealing with
> forwarding.  If we're not going to generally specify receiver
> policy, then (obviously) we shouldn't.

OTOH, predictable behavior makes for better interoperability.

> Depending on how this discussion comes out, that will affect what it is 
> reasonable to try and specify for forwarding.

I agree forwarding is the ugliest case to discuss, but recipient
behavior is all downhill from there.

From spf2@kitterman.com  Fri Mar 23 11:01:48 2012
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 04BCC21F865E for ; Fri, 23 Mar 2012 11:01:48 -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.007,  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 WWJPX5y7lzzS for ; Fri, 23 Mar 2012 11:01:43 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4D521F865B for ; Fri, 23 Mar 2012 11:01:43 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 268ED20E40BD; Fri, 23 Mar 2012 14:01:43 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332525703; bh=4YFdprcc30kzPCsNAzGuIEJ/qMdo6eqWsTZjtHwCmWw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=WdGl8lJJ8DcTija/a+ZbLLD0Dwsg45pf+kQTm/s64DY/Cadb9R1qLG1yJLCrTK3qp 0z9leSXclgo8iYqgaR4Mk9TVzCyAsMrDQjEdHy/I5G4ksKa2jl6xtZ/69bLhmfdwhu aWDA9M3trpYkeE1sS1UUtjmzXO0Axi+x4zYMxAvc=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0D7BE20E4083;  Fri, 23 Mar 2012 14:01:42 -0400 (EDT)
From: Scott Kitterman 
To: spfbis@ietf.org
Date: Fri, 23 Mar 2012 14:01:42 -0400
Message-ID: <6439778.SLGWHG47E6@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <4F6CB9FF.5090506@tana.it>
References: <20120315175753.21172.qmail@joyce.lan> <16658996.WWsWQrny8L@scott-latitude-e6320> <4F6CB9FF.5090506@tana.it>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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 Mar 2012 18:01:48 -0000

On Friday, March 23, 2012 06:59:27 PM Alessandro Vesely wrote:
> On 23/Mar/12 18:20, Scott Kitterman wrote:
> > The more general topic is "Should 4408bis be more prescriptive
> > about receiver policy?"  With the exception of MUST treat Neutral
> > and None the same there are no hard receiver policy requirements
> > 4408.  All of the others are in the vain of "If you ... then ...".
> 
> Yes.  It is weakly expressed also due to standardization reasons that
> I keep forgetting.  However, phrases like "local policy can take
> stronger action against such E-Mail, such as rejecting it" are pretty
> understandable even without MUSTard.
> 
> > Getting beyond that to try and specify receiver policy would, IMO,
> > be a mistake, but I think it should be generally discussed by the
> > group rather than bolted onto this issue.  If we're going to
> > specify it, we should broadly specify it, not just for dealing with
> > forwarding.  If we're not going to generally specify receiver
> > policy, then (obviously) we shouldn't.
> 
> OTOH, predictable behavior makes for better interoperability.
> 
> > Depending on how this discussion comes out, that will affect what it is
> > reasonable to try and specify for forwarding.
> 
> I agree forwarding is the ugliest case to discuss, but recipient
> behavior is all downhill from there.

I'm of the opinion that receivers will do what they want and so it's pointless 
to try and tell them what to do.  What we should focus on is how to do the 
things they might choose in a reasonably standardized way (e.g. specify what 
result codes to use).

Scott K

From johnl@iecc.com  Fri Mar 23 11:44:41 2012
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 0A8CC21E801C for ; Fri, 23 Mar 2012 11:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.362
X-Spam-Level: 
X-Spam-Status: No, score=-110.362 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 IZ1mSvSERaeX for ; Fri, 23 Mar 2012 11:44:36 -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 CC61221E800E for ; Fri, 23 Mar 2012 11:44:35 -0700 (PDT)
Received: (qmail 60455 invoked from network); 23 Mar 2012 18:44:34 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Mar 2012 18:44:34 -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:vbr-info; s=4f6cc491.xn--yuvv84g.k1203; i=johnl@user.iecc.com; bh=2vHkYibnqpVJFeeQuT1FedZQawvS7LvfNVUBIBuugbY=; b=dGVAfFggDWz32rjxsnl+8Xr6vvsXFicsSY76dQmo1BgOS0ovdHADaUvcn0c8qBqhr5523nCzk5jzF1LlxdwB/MvZmcwSShNcCr55YYKV8rXB/qWu/v0dJsnW05GgZ4fY/28dyeJ8l34DLKPz/20/LdPqJFFtpEUzjzKVtj11puc=
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:vbr-info; s=4f6cc491.xn--yuvv84g.k1203; olt=johnl@user.iecc.com; bh=2vHkYibnqpVJFeeQuT1FedZQawvS7LvfNVUBIBuugbY=; b=cqtaLwYaZK7hitV2iT5WvCi+5rCFdAb0LHoSR8Uh0xPjUZA4voniJniThj8q76oNclPvhdALgDUGxqBsMCzSZYi0Id3fkLcwcQ3tHCx0dteWZ5VjUz69h8KgPAmIuRhzm9tEC8WrAEZp9oY9PxzWsKvunOWBQzyXvIkNBkNYO3g=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 23 Mar 2012 18:44:11 -0000
Message-ID: <20120323184411.57292.qmail@joyce.lan>
From: "John Levine" 
To: spfbis@ietf.org
In-Reply-To: <16658996.WWsWQrny8L@scott-latitude-e6320>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Cc: spf2@kitterman.com
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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 Mar 2012 18:44:41 -0000

>The more general topic is "Should 4408bis be more prescriptive about receiver 
>policy?"

Since it's unenforcable, heck no.

R's,
John

From vesely@tana.it  Fri Mar 23 12:57:18 2012
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 BB7FB21F85F6 for ; Fri, 23 Mar 2012 12:57:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.66
X-Spam-Level: 
X-Spam-Status: No, score=-4.66 tagged_above=-999 required=5 tests=[AWL=0.059,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSqmfO0Tc0ON for ; Fri, 23 Mar 2012 12:57:14 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 96C1821F85FF for ; Fri, 23 Mar 2012 12:57:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332532629; bh=HnundahHlIYbcHlOBxagMbGXveQnspnOJGQjECBmqjQ=; l=3306; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=VPw8KOAVUrRRIvJIiVX87wLlEG4ep57nq3eWnE5A15bL0adyORUDN9bxswFmSuZse O494aSlhI8zGaTZ2P7Dm6eRp0oiyxUA9Ghs9E+F5pwjpYO9R83kN26UWDyKiZqSRPO 3uBqpK8kuWLFEIseKV5B7ffQcOpRIVam9GilRlts=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 23 Mar 2012 20:57:09 +0100 id 00000000005DC039.000000004F6CD595.00005039
Message-ID: <4F6CD594.1090909@tana.it>
Date: Fri, 23 Mar 2012 20:57:08 +0100
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320>	<4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320>	<4F6C4903.8090901@tana.it> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it> <9452079D1A51524AA5749AD23E003928098E77@exch-mbx901.corp.cloudmark.com>
In-Reply-To: <9452079D1A51524AA5749AD23E003928098E77@exch-mbx901.corp.cloudmark.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo	identities
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 Mar 2012 19:57:18 -0000

On 23/Mar/12 18:32, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>
>> reject-on-fail is widespread enough to cause problems.
> 
> I'm quite sure at least Scott will tire of me holding up DKIM as an
> example of a better way to do things, but I'm talking here about
> the document, not the protocol.  :-)
> 
> As has been said, SPF tried at least in part to present a mechanism
> that was "safe" for reject-on-fail.  There's also common advice
> that says one shouldn't do this even when asked to so because of
> SPF's failure modes.  Indeed, this sentiment has even spilled over
> into the nascent DMARC work.
> 
> DKIM, on the other hand, retreated from that position some time ago
> and actually says that people shouldn't reject mail on failure
> specifically because of legitimate failure modes.  It should simply
> be input into a larger evaluation mechanism.

This looks logical and safe, except that that larger evaluation
mechanism currently consists mostly of black magic and undisclosed
esoteric techniques.  We cannot say to accept messages failing SPF
without indicating some more or less equivalent protection against
domain-name spoofing.

> So I obviously don't advocate for "recklessly pretend the problem
> doesn't exist", but I do think we can only go so far in terms of
> giving people rope.  Being more assertive in our description of the
> problem and recommendations is probably quite appropriate.

+1, we should agree what to recommend, then assert it strongly enough.

> We can't prohibit rejection on SPF fail, in the same way that we
> can't demand people discard on ADSP failures.

That must be because of those standardization reasons that I'm unable
to get straight.  (ADSP did it so well that people have difficulties
even understanding what "discardable" means.)

> The last two options (update SMTP, deprecate SPF) sound like
> non-starters.

Yeah; really, none of those bullets sound attractive.  Would it be
possible to check the feasibility of updating just a little bit of
SMTP?  For example, that one MUST NOT use alias mode to external
servers unless its address passes an SPF record with its label.  I
mean as a possibility, without committing ourselves to actually do so.
(Yes, I can imagine how would, say, John Klensin react if I hounded
him for such a question, but maybe there is a better way of asking...)

Deprecating SPF, to me, is not much more or less attractive than
recklessly ignoring the problem, since hurtful and deprecated are
nearly synonyms.  I hope the WG is good enough to avoid both.

>> I'm open to any logical settlement, anything such that three hosts
>> implementing the spirit of the spec interoperate as expected.
> 
> Interoperability for SPF, in my view, only goes as far as the
> evaluation function produces the same result for everyone given the
> same inputs.  The actual action taken by the receiver is not our
> concern, just like with DKIM, although we can provide strong advice
> and explain why we think it's the right advice.

One way or the other, we must say how recipients are supposed to
behave to make the protocol work.  The clearer the better.  It has to
be our concern, although it might be impermissible for us to
explicitly mandate it.

From SRS0=Yas8d=B6==stuart@gathman.org  Fri Mar 23 13:25:27 2012
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 89ADE21F85C0 for ; Fri, 23 Mar 2012 13:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.141
X-Spam-Level: 
X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, SARE_MILLIONSOF=0.315]
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 FZIxOqGcZFWW for ; Fri, 23 Mar 2012 13:25:27 -0700 (PDT)
Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 03CB021F85B8 for ; Fri, 23 Mar 2012 13:25:26 -0700 (PDT)
Received: from sdg.bmsi.com (sdg.bmsi.com [192.168.9.34] (may be forged)) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q2NKOVEt021425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Mar 2012 16:24:32 -0400
Message-ID: <4F6CDC34.8030608@gathman.org>
Date: Fri, 23 Mar 2012 16:25:24 -0400
From: Stuart D Gathman 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320> <4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320> <4F6C4903.8090901@tana.it>
In-Reply-To: <4F6C4903.8090901@tana.it>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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 Mar 2012 20:27:22 -0000

Long ago, Nostradamus foresaw that on 03/23/2012 05:57 AM, Alessandro 
Vesely would write:
> John confirms that forwarding is "not going away, SPF does what it 
> does." Nevertheless, I think it is a moral obligation for a standard 
> writer to figure out and describe how to make things work. Operators 
> who know better will do their way, under their responsibility. But it 
> is insane to air a possibility --reject on fail-- which we know does 
> not work.
Reject on FAIL works perfectly well - WITH the constraint that receivers 
must not treat results from (alias/non-SRS) forwarders as SPF results.  
This is ridiculously simple for a small operator (configure a small list 
of authorized forwarders), doable for a very large operator like gmail 
or aol (using SPF results over millions of messages to figure out who 
the forwarders are), and very difficult for a medium operator (no, end 
users are *not* going to helpfully tell you when they set up a forward 
on some random MTA).  This probably means medium operators can't 
realistically reject on SPF.

spfbis should simply explain the constraint for correctly rejecting on 
SPF.  Rfc4408 already does, but not very explicity.  I think we should 
say that any SPF result MUST NOT be considered official (and therefore 
rejecting on FAIL is not recommended) when the client MTA is a non-SRS 
forwarder.  Note that for small operators, it is much more common in my 
experience for them to reject on FAIL from their own secondary MX, than 
to have forwarding problems.

SPF does not break forwarding.  It simply has the limitation that 
policies can't be (correctly) checked for alias/non-SRS forwarders.

Idea: instead of trying to detect alias forwarders, detect 
non-forwarders instead.  Start by assuming *all* MTAs are alias 
forwarders.  Whenever you get an SPF PASS, add the domain,IP tuple (MTA 
could send both forwarded an unforwarded emails) to a database of 
non-forwarders, for which you can reject on FAIL.  The database could 
get very large, however.

From SRS0=Yas8d=B6==stuart@gathman.org  Fri Mar 23 14:11:10 2012
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 3141E21F8629 for ; Fri, 23 Mar 2012 14:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.184
X-Spam-Level: 
X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, J_CHICKENPOX_62=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 Iv7x1a16y9Wo for ; Fri, 23 Mar 2012 14:11:09 -0700 (PDT)
Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id A0DBF21F8627 for ; Fri, 23 Mar 2012 14:11:09 -0700 (PDT)
Received: from sdg.bmsi.com (sdg.bmsi.com [192.168.9.34] (may be forged)) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q2NLAEAf022399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Mar 2012 17:10:15 -0400
Message-ID: <4F6CE6EC.1060501@gathman.org>
Date: Fri, 23 Mar 2012 17:11:08 -0400
From: Stuart D Gathman 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320> <4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320> <4F6C4903.8090901@tana.it> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it>
In-Reply-To: <4F6CADDC.1000005@tana.it>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
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 Mar 2012 21:11:10 -0000

Long ago, Nostradamus foresaw that on 03/23/2012 01:07 PM, Alessandro 
Vesely would write:
> Of course, we can pretend there is no problem,
There is, in fact, no problem.

The result of running the SPF algorithm on an alias forwarder is NOT an 
actual SPF result.  Rejecting on an actual SPF result does not cause 
problems.  The fact that connections from alias forwarders are invalid 
input to the SPF algorithm is a limitation of the protocol.  But it does 
not break forwarding.  Forwarding is only broken when receivers confuse 
pseudo-SPF results from an alias forwarder with real SPF results, and 
then reject on FAIL.

We should continue to encourage reject on *SPF* (vs pseudo-SPF) FAIL.  
We need to define valid inputs to SPF in a way that people won't confuse 
the two as easily.

There are a variety of ways to distinguish alias forwarders from direct 
MTAs, from the very simple "configure authorized forwarders in your SPF 
software", to webapps to allow users to enable reject on FAIL and enter 
authorized forwarders for a larger MTA, to methods that detect 
forwarders from a large set of connections.  If a receiver can't 
distinguish alias forwarders in some practical way, then SPF is not as 
useful to them.

Note that configuring authorized forwarders does not need to involve 
entering IP addresses if the forwarder publishes SPF for some domain 
that covers the MTAs used for alias forwarding.

As I mentioned in a previous message, I believe that if the SPF result 
is pass, we can assume that the MTA is *not* an alias forwarder for that 
domain, and this can be used to build a list of domain,ip where an SPF 
fail result is valid.  But this is a new idea (for me anyway), and needs 
to be vetted.

From sm@elandsys.com  Fri Mar 23 14:51:46 2012
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 D5EC521F8681 for ; Fri, 23 Mar 2012 14:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.595
X-Spam-Level: 
X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 uPdUmni6d8Ue for ; Fri, 23 Mar 2012 14: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 81E4021F867F for ; Fri, 23 Mar 2012 14:51:42 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.239.247]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2NLpMlC015671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Mar 2012 14:51:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1332539495; i=@elandsys.com; bh=d0pQ1rya+K6RE715AD30DB35q1WUGc3wlUvOQm5dbdw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=yEkiIYBMSTobf+F22ZakdliPzh/XXFm056HDHtUfD/qLM49pyhRTtlsLnezovVC9d qmHR/TR1D8BhenCD/4ah7p6b3Fiqa0UYd2I1hlsTcTX2gner+9FOe1lqTAHGdJh1mh j+UJVAHz97/KZZkaYREVtlrrC6SI9dYhFKSE3/K0=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1332539495; i=@elandsys.com; bh=d0pQ1rya+K6RE715AD30DB35q1WUGc3wlUvOQm5dbdw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qPqW7ZZ4OLfVsxVwfQG9MnRb7IdSTpS2W2bhjnE7k2KpLlgD5V/8Hczw/FRLnqSl9 yLgbmSJ16zr9jBalUEuTSrmVd81MKXlbundrBmHwuFcLuis4U7ofmsHZTVeDdtHoLO jSIxzNQyIxJDuS9QmfeiP4kXN+btAEhuPyfVQfVU=
Message-Id: <6.2.5.6.2.20120323135052.0afab650@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 23 Mar 2012 14:45:40 -0700
To: Alessandro Vesely 
From: S Moonesamy 
In-Reply-To: <4F6CD594.1090909@tana.it>
References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320> <4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320> <4F6C4903.8090901@tana.it> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it> <9452079D1A51524AA5749AD23E003928098E77@exch-mbx901.corp.cloudmark.com> <4F6CD594.1090909@tana.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: spfbis@ietf.org
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo	identities
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 Mar 2012 21:51:46 -0000

Hi Alessandro,
At 12:57 23-03-2012, Alessandro Vesely wrote:
>Yeah; really, none of those bullets sound attractive.  Would it be
>possible to check the feasibility of updating just a little bit of
>SMTP?  For example, that one MUST NOT use alias mode to external
>servers unless its address passes an SPF record with its label.  I
>mean as a possibility, without committing ourselves to actually do so.

I don't see any justification at the moment for asking whether it is 
feasible to make such an update.  You could raise the question during 
the WG session next Friday if you wish.

Regards,
S. Moonesamy
SPFBIS WG co-chair 


From msk@cloudmark.com  Fri Mar 23 21:52:13 2012
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 6C2BE21F8512 for ; Fri, 23 Mar 2012 21:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.561
X-Spam-Level: 
X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 CvIzXmsQnwCI for ; Fri, 23 Mar 2012 21:52:12 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id C5AAE21F851C for ; Fri, 23 Mar 2012 21:52:12 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 21:52:09 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
Thread-Index: AQHNCRd5di1lS/R2VEyGB3ryw8yxn5Z41hgAgAAJR3A=
Date: Sat, 24 Mar 2012 04:52:08 +0000
Message-ID: <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com>
References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320>	<4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320>	<4F6C4903.8090901@tana.it> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it> <4F6CE6EC.1060501@gathman.org>
In-Reply-To: <4F6CE6EC.1060501@gathman.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [67.160.203.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo	identities
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 Mar 2012 04:52:13 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of Stuart D Gathman
> Sent: Friday, March 23, 2012 2:11 PM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident=
ities
>=20
> The result of running the SPF algorithm on an alias forwarder is NOT an
> actual SPF result.  Rejecting on an actual SPF result does not cause
> problems.  The fact that connections from alias forwarders are invalid
> input to the SPF algorithm is a limitation of the protocol.  But it
> does not break forwarding.  Forwarding is only broken when receivers
> confuse pseudo-SPF results from an alias forwarder with real SPF
> results, and then reject on FAIL.
> [...]

This an interesting tack, but I don't think I agree.  SPF takes as input a =
domain name and an IP address, does some crunching, and returns a result.  =
That result is deterministic.  At the level of that interface, the IP addre=
ss of a forwarder is indistinguishable from any other, so to say one class =
of IP address is valid while another is not seems a non-sequitur to me.

Any result produced by taking those two pieces of input and following the S=
PF algorithm is an SPF result.  If two different systems have differing out=
puts given the same inputs, then we have an interoperability problem and/or=
 a broken specification.

Requiring different treatment of forwarders based on a heuristic would not =
be an SPF result, in the same way that several have asserted that Best Gues=
s SPF is not an SPF result.

> We should continue to encourage reject on *SPF* (vs pseudo-SPF) FAIL.
> We need to define valid inputs to SPF in a way that people won't
> confuse the two as easily.

That might be a useful exercise, but I don't think it fits with the current=
 protocol.

-MSK


From msk@cloudmark.com  Fri Mar 23 21:57:10 2012
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 A0A5121F8594 for ; Fri, 23 Mar 2012 21:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.562
X-Spam-Level: 
X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 0oUhVfHguN7F for ; Fri, 23 Mar 2012 21:57:09 -0700 (PDT)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2B221F8593 for ; Fri, 23 Mar 2012 21:57:09 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 21:57:08 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and	helo identities
Thread-Index: AQHNCS8o+kRgYNdEuEiJV/Rw7Z8exJZ44cUQ
Date: Sat, 24 Mar 2012 04:57:08 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039280995A3@exch-mbx901.corp.cloudmark.com>
References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320>	<4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320>	<4F6C4903.8090901@tana.it> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it> <9452079D1A51524AA5749AD23E003928098E77@exch-mbx901.corp.cloudmark.com> <4F6CD594.1090909@tana.it>
In-Reply-To: <4F6CD594.1090909@tana.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [67.160.203.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and	helo	identities
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 Mar 2012 04:57:10 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of Alessandro Vesely
> Sent: Friday, March 23, 2012 12:57 PM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident=
ities
>=20
> Yeah; really, none of those bullets sound attractive.  Would it be
> possible to check the feasibility of updating just a little bit of
> SMTP?  For example, that one MUST NOT use alias mode to external
> servers unless its address passes an SPF record with its label.  I mean
> as a possibility, without committing ourselves to actually do so.

I would bet real money that this is a non-starter.  By doing so, you would =
declare a big piece of the deployed email infrastructure non-compliant.  If=
 I may paraphrase John Levine about MLMs: Forwarders have been doing what t=
hey do for decades without complaints, so who are we to suddenly tell them =
that they're wrong?

> (Yes, I can imagine how would, say, John Klensin react if I hounded him
> for such a question, but maybe there is a better way of asking...)

Such as trying to get one of us to do it for you?  :-)

> One way or the other, we must say how recipients are supposed to behave
> to make the protocol work.  The clearer the better.  It has to be our
> concern, although it might be impermissible for us to explicitly
> mandate it.

When it comes time to crack open RFC4408bis itself, I imagine you should ha=
ve clarifying text ready to propose so we can discuss it.  I haven't looked=
 lately, but I believe Scott when he says it's already there.

-MSK

From johnl@iecc.com  Sat Mar 24 02:04:14 2012
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 11EFA21F86A5 for ; Sat, 24 Mar 2012 02:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.368
X-Spam-Level: 
X-Spam-Status: No, score=-110.368 tagged_above=-999 required=5 tests=[AWL=0.831, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 B5sJwpHu-3+5 for ; Sat, 24 Mar 2012 02:04:13 -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 053D021F8698 for ; Sat, 24 Mar 2012 02:04:12 -0700 (PDT)
Received: (qmail 54334 invoked from network); 24 Mar 2012 09:04:11 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Mar 2012 09:04:11 -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:vbr-info; s=4f6d8e0b.xn--btvx9d.k1203; i=johnl@user.iecc.com; bh=4x7V4222ADyPicGjmSo23ew0tpcWv2NJA9maLRWw3Zg=; b=ATH4CN95RJgfAluBGZQOYhU/sYseUjReC61aFlhMuCsnXZNKzFD1o1dYcM2hak7yCR7ivVk4V96RX7vG0lHEdSz3VsJ3NAYxjyXxKBF8QnCBk3+xC3rzVfIuNRbQAgNSQ8l4t9J8NJ55xPjxBONn3Lwf5ETPkm4I8fKtcLWGVxo=
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:vbr-info; s=4f6d8e0b.xn--btvx9d.k1203; olt=johnl@user.iecc.com; bh=4x7V4222ADyPicGjmSo23ew0tpcWv2NJA9maLRWw3Zg=; b=QATV1NEjhbMPNtwIQYE2W9UbfnlNRgIwHIMC5tEaJAY+FI4AR4nNfZBq0g2lsD8+48qLiOWnvSu46gQrlMBlZ0OhW12gSrNYHZbdX4OQFGTnwmQ7Mq/kmZh+A9uSAgqbgoSeLutCUtueKcB+7+a/s6xQQBOrrGPkN10hpQukuc8=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 24 Mar 2012 09:03:49 -0000
Message-ID: <20120324090349.15462.qmail@joyce.lan>
From: "John Levine" 
To: spfbis@ietf.org
In-Reply-To: <9452079D1A51524AA5749AD23E0039280995A3@exch-mbx901.corp.cloudmark.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Cc: msk@cloudmark.com
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and	helo	identities
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 Mar 2012 09:04:14 -0000

>> Yeah; really, none of those bullets sound attractive.  Would it be
>> possible to check the feasibility of updating just a little bit of SMTP?

I think I know Klensin well enough to channel his answer to that
question.  To summarize three pages of detailed response: absolutely
none.

It is a specific design feature of SMTP that the contents of a message
are independent of the path it takes.  That isn't going to change.

The only reason SPF works at all is that a large fraction of mail
happens to take a predictable path.  But not all of it does, and the
part that doesn't can't be wished away.

R's,
John



From vesely@tana.it  Sat Mar 24 08:50:00 2012
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 0ACCD21F863C for ; Sat, 24 Mar 2012 08:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level: 
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEBDr8nnex9B for ; Sat, 24 Mar 2012 08:49:59 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 01EBD21F863B for ; Sat, 24 Mar 2012 08:49:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332604197; bh=4d5DqTlPrBi+aqjOc2DOY2FX/uQsgjiIZ8eNrp/04Wc=; l=593; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=NJv3n6OGt/6dEt7KMYukIBwB7y+omwOohGSQC0/VHTrIqsBZtWD/a0MDocYMWxmam 5zy/vcYw0gUKKsg4yJqYprVGawNp7pVvmJ34MKIN96aMtJTufJDhFbsjCXvXw13Zke GkStUh5DixJTC+anNxNqf0fOHWWRLHRJiJBVzYuk=
Received: from [10.216.6.61] ([93.158.42.29]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 24 Mar 2012 16:49:52 +0100 id 00000000005DC039.000000004F6DED23.00005B79
Message-ID: <4F6DED16.4060705@tana.it>
Date: Sat, 24 Mar 2012 16:49:42 +0100
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: spfbis@ietf.org
References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <6.2.5.6.2.20120314113845.09b3b920@resistor.net> <7F7F36E50398F84DBAF25C9D51732F1E20F65CEA@TK5EX14MBXC292.redmond.corp.microsoft.com> <1788008.TexYV2zLNy@scott-latitude-e6320> <4F6C2F2C.8020405@tana.it> <9452079D1A51524AA5749AD23E003928098ED8@exch-mbx901.corp.cloudmark.com>
In-Reply-To: <9452079D1A51524AA5749AD23E003928098ED8@exch-mbx901.corp.cloudmark.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451
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 Mar 2012 15:50:00 -0000

On 23.03.2012 18:33, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>
>> Hm... some implementations rename that to Original-Received-SPF.
> 
> Why would they do that?

To ease checking, IIRC.  I'm unable to find that discussion right now, I'll
confirm (or retract) this point next week.

> As I recall, Received-SPF includes an indication of who added it, so this
> shouldn't strictly be necessary.

Correct.  However, the "receiver" field is not mandatory, and there is no
discussion about removing spoofed fields.

> Worth documenting in any case.

From spf2@kitterman.com  Sat Mar 24 09:01:12 2012
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 3517D21F858D for ; Sat, 24 Mar 2012 09:01:12 -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.007,  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 IIUhV-Q4PcSM for ; Sat, 24 Mar 2012 09:01:11 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A034921F852D for ; Sat, 24 Mar 2012 09:01:01 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B61C220E40BD; Sat, 24 Mar 2012 12:01:00 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332604860; bh=XpTrireTHF25pGMmK8XNbE03Fr7CTdbhhI0qQXdvgUI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Bdk2hT92+yPYWsH+V161Ao7CpcbOCxhmsW+e65cU3vNo7SYHEA/DHxK1BiW1g8cxm /tu8uOH/19rHi3mb0LMA6i/ed69LnWLRqmF2hRYX3H/1bTaDaRXnMI7bxSrHrK0b7P DQwdERfIA1cLR/5BvErtnf5XgkEHNt55p7yTtLOY=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9CD8620E40BB;  Sat, 24 Mar 2012 12:01:00 -0400 (EDT)
From: Scott Kitterman 
To: spfbis@ietf.org
Date: Sat, 24 Mar 2012 12:00:59 -0400
Message-ID: <7405816.UVz7f3xFDu@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <4F6DED16.4060705@tana.it>
References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <9452079D1A51524AA5749AD23E003928098ED8@exch-mbx901.corp.cloudmark.com> <4F6DED16.4060705@tana.it>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451
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 Mar 2012 16:01:12 -0000

On Saturday, March 24, 2012 04:49:42 PM Alessandro Vesely wrote:
> On 23.03.2012 18:33, Murray S. Kucherawy wrote:
> >> From: ietf.org On Behalf Of Alessandro Vesely
> >> 
> >> Hm... some implementations rename that to Original-Received-SPF.
> > 
> > Why would they do that?
> 
> To ease checking, IIRC.  I'm unable to find that discussion right now, I'll
> confirm (or retract) this point next week.
> 
> > As I recall, Received-SPF includes an indication of who added it, so
> > this
> > shouldn't strictly be necessary.
> 
> Correct.  However, the "receiver" field is not mandatory, and there is no
> discussion about removing spoofed fields.

The implementations I've seen use a combination of Received: and Received-SPF: 
to determine which ones were added by a trusted MTA.  There's an assumption 
that anything added before the first trusted MTA will be ignored, so there's no 
need to remove them (they are untrustworthy, but not necessarily spoofed).

This is not completely reliable, but better than trying to extract the correct 
source IP address out of a Received: field and apply SPF against that after the 
SMTP transaction is finished (which I have also seen).

Scott K

From vesely@tana.it  Sat Mar 24 09:18:33 2012
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 2BD6921F8656 for ; Sat, 24 Mar 2012 09:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level: 
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKaKubCFdtKa for ; Sat, 24 Mar 2012 09:18:31 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7489221F864F for ; Sat, 24 Mar 2012 09:18:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332605910; bh=zoUhCsE0vFYlfSbdCS+bdKdN8y9Pj8aLVZ1qL8yvte4=; l=2332; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=h1fmcREa5sr9q1SFW7kB2ULonF3lNuMEdm6oqhzJi3yxNXEzpNI4FLKJ33zVo0Vs8 43lYPkYXLlTftDiBjzonD0yNMSXz4AFokjOmXCIpw0SnwvG9tjkHOFXL/4KN1tM3dy pRPzgjI/OPjy0+nN2+7g7BrIxKCq5a3kh0CRHU7M=
Received: from [10.216.6.61] ([93.158.42.29]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 24 Mar 2012 17:18:29 +0100 id 00000000005DC039.000000004F6DF3D5.00006202
Message-ID: <4F6DF3D1.3070209@tana.it>
Date: Sat, 24 Mar 2012 17:18:25 +0100
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320>	<4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320>	<4F6C4903.8090901@tana.it> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com>
In-Reply-To: <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo	identities
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 Mar 2012 16:18:33 -0000

On 24.03.2012 05:52, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Stuart D Gathman
>
>> The result of running the SPF algorithm on an alias forwarder is NOT an
>> actual SPF result.  Rejecting on an actual SPF result does not cause
>> problems.  The fact that connections from alias forwarders are invalid
>> input to the SPF algorithm is a limitation of the protocol.  But it
>> does not break forwarding.  Forwarding is only broken when receivers
>> confuse pseudo-SPF results from an alias forwarder with real SPF
>> results, and then reject on FAIL.
>> [...]
> 
> This an interesting tack, but I don't think I agree.  SPF takes as input a
> domain name and an IP address, does some crunching, and returns a result.
> That result is deterministic.  At the level of that interface, the IP
> address of a forwarder is indistinguishable from any other, so to say one
> class of IP address is valid while another is not seems a non-sequitur to
> me.

I didn't fully grasp Stuart's method.  If it works reliably, it is a
possibility.  It is true that it seems to add a complex IP database
maintenance to a simple algorithm, but I wouldn't consider it out of scope if
it enables us to spell under what condition it is safe to reject.

> Any result produced by taking those two pieces of input and following the
> SPF algorithm is an SPF result.  If two different systems have differing
> outputs given the same inputs, then we have an interoperability problem
> and/or a broken specification.

We can distinguish the algorithm from the conditions that enable reject on
fail.  Two systems may get the same results but different ability to reject
based on that.  I'm quite dubious about defining different behaviors for
small, medium, and very large systems, but, heck, whatever works!

> Requiring different treatment of forwarders based on a heuristic would not
> be an SPF result, in the same way that several have asserted that Best
> Guess SPF is not an SPF result.

Yes.

>> We should continue to encourage reject on *SPF* (vs pseudo-SPF) FAIL.
>> We need to define valid inputs to SPF in a way that people won't
>> confuse the two as easily.
> 
> That might be a useful exercise, but I don't think it fits with the
> current protocol.

Yes, strictly speaking, it is not part of it.

From vesely@tana.it  Sat Mar 24 09:30:18 2012
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 A094B21F85F0 for ; Sat, 24 Mar 2012 09:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level: 
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBpbiMC1JlAF for ; Sat, 24 Mar 2012 09:30:18 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C0FB121F85EA for ; Sat, 24 Mar 2012 09:30:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332606616; bh=Cnv7eEnulUT+ziXjdGn2vnqWYPhBEO1JO+8se+19ht0=; l=1146; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ckuUgwxi0YtvO+46c/UwUOmVud7ZyL8rH/1A5Acy3bV50UsuEYZSdyomtjQmeBFx7 9gQ8TCoT8Ulh8e2eBXzEAwayn1WXcHNClHmFSn+XH6bu1ldhKr4cQ58sBMAF8ZFjFM Oazyvfcx5A1AVD9kRPwvqCCkMqj+7bX/853bIpCY=
Received: from [10.216.6.61] ([93.158.42.29]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 24 Mar 2012 17:30:16 +0100 id 00000000005DC039.000000004F6DF698.00006501
Message-ID: <4F6DF691.8080205@tana.it>
Date: Sat, 24 Mar 2012 17:30:09 +0100
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320>	<4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320>	<4F6C4903.8090901@tana.it> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it> <9452079D1A51524AA5749AD23E003928098E77@exch-mbx901.corp.cloudmark.com> <4F6CD594.1090909@tana.it> <9452079D1A51524AA5749AD23E0039280995A3@exch-mbx901.corp.cloudmark.com>
In-Reply-To: <9452079D1A51524AA5749AD23E0039280995A3@exch-mbx901.corp.cloudmark.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and	helo	identities
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 Mar 2012 16:30:18 -0000

On 24.03.2012 05:57, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>
>> Yeah; really, none of those bullets sound attractive.  Would it be
>> possible to check the feasibility of updating just a little bit of
>> SMTP?  For example, that one MUST NOT use alias mode to external
>> servers unless its address passes an SPF record with its label.
> 
> I would bet real money that this is a non-starter.  By doing so, you would
> declare a big piece of the deployed email infrastructure non-compliant.

Isn't it a small piece?

> If I may paraphrase John Levine about MLMs: Forwarders have been doing
> what they do for decades without complaints, so who are we to suddenly
> tell them that they're wrong?

Not suddenly, every user and operator found out that email is too easily
abused.  IMHO, it is the smallest change that is compatible with plain reject
on fail.

>> (Yes, I can imagine how would, say, John Klensin react if I hounded him
>> for such a question, but maybe there is a better way of asking...)
> 
> Such as trying to get one of us to do it for you?  :-)

Are you volunteering? :-)

From spf2@kitterman.com  Sat Mar 24 09:31:39 2012
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 A7E1C21F8622 for ; Sat, 24 Mar 2012 09:31:39 -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.007,  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 z-q6NvUPpkCt for ; Sat, 24 Mar 2012 09:31:38 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 68C4721F8615 for ; Sat, 24 Mar 2012 09:31:38 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D944820E40BD; Sat, 24 Mar 2012 12:31:37 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332606697; bh=ZqajeZpE75OUaKA1c/QALg5Gb+x3zYXNxktN5nDb2+U=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type:Content-Transfer-Encoding; b=O9gvCYkytP08TtSy3FYEXMN+d6Y55FTG/mMhRfDGir/3U9RPy3A6Z4L4xG7HdNk6v 0QUuO7XH1Or6WyIkgAwxfq92+6YiU0YGMs++oMLVYsfKRlKYXLZDSZgkwPBIw8/2hZ GbdvzSbk/xLQPta+u4LGZ0l2HqUknMvIy5jLEyto=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BBF5720E40BB;  Sat, 24 Mar 2012 12:31:37 -0400 (EDT)
From: Scott Kitterman 
To: spfbis@ietf.org
Date: Sat, 24 Mar 2012 12:31:37 -0400
Message-ID: <2744445.3m1Dyi5C5m@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com>
References: <20120315175753.21172.qmail@joyce.lan> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nextPart1340414.4ZtAWlEGmJ"
Content-Transfer-Encoding: 7Bit
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo	identities
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 Mar 2012 16:31:39 -0000

--nextPart1340414.4ZtAWlEGmJ
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Saturday, March 24, 2012 04:52:08 AM Murray S. Kucherawy wrote:
> > -----Original Message-----
> > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf
> > Of Stuart D Gathman Sent: Friday, March 23, 2012 2:11 PM
> > To: spfbis@ietf.org
> > Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo
> > identities
> > 
> > The result of running the SPF algorithm on an alias forwarder is NOT an
> > actual SPF result.  Rejecting on an actual SPF result does not cause
> > problems.  The fact that connections from alias forwarders are invalid
> > input to the SPF algorithm is a limitation of the protocol.  But it
> > does not break forwarding.  Forwarding is only broken when receivers
> > confuse pseudo-SPF results from an alias forwarder with real SPF
> > results, and then reject on FAIL.
> > [...]
> 
> This an interesting tack, but I don't think I agree.  SPF takes as input a
> domain name and an IP address, does some crunching, and returns a result. 
> That result is deterministic.  At the level of that interface, the IP
> address of a forwarder is indistinguishable from any other, so to say one
> class of IP address is valid while another is not seems a non-sequitur to
> me.
> 
> Any result produced by taking those two pieces of input and following the
> SPF algorithm is an SPF result.  If two different systems have differing
> outputs given the same inputs, then we have an interoperability problem
> and/or a broken specification.
> 
> Requiring different treatment of forwarders based on a heuristic would not
> be an SPF result, in the same way that several have asserted that Best
> Guess SPF is not an SPF result.
> > We should continue to encourage reject on *SPF* (vs pseudo-SPF) FAIL.
> > We need to define valid inputs to SPF in a way that people won't
> > confuse the two as easily.
> 
> That might be a useful exercise, but I don't think it fits with the current
> protocol.

I think it's more useful to make recommendations about where SPF checks should 
be done.  My ascii art skills are minimal, so I made a PDF (attached - no 
comments on those skills please) to describe what I think are the different 
architectural cases and where SPF checks should be done in each.

The first one is the most common case of direct transfer from the sending ADMD 
to the receiving ADMD.  The check should be done on the border between the two 
ADMDs (that doesn't mean the results of those checks can't be used elsewhere 
if that's the design of the receiving ADMD, but that's where the measurement 
should be taken).

The second one is the traditional forwarder case.  In this case, the forwarder 
is an agent for the receiver (the sender has no idea their mail will be 
forwarded, it's the receiver that determines this).  The forwarder is 
effectively part of the receiver's ADMD.  The case is generically the same 
though.  SPF should be checked when it passes from the sender's ADMD to the 
receiver's.  The reason this case is so hard is that many receivers don't 
understand the boundaries of their ADMD to include this and argue they 
shouldn't have to.

The third one is the case of a rewriting forwarder (this could be SRS or some 
other method, that is an implementation detail).  In this case the forwarder 
proxies for the sender so that they are acting as both an agent for the sender 
and for the receiver.  The receiver is inside both ADMDs to some degree.

Finally, in the mailing list case, it's really very easy as normal mailing 
lists treat a submission as a completed delivery and then make a new message 
to the list.  In the first transaction they are the receiving ADMD and in the 
second they are the sending.  Lists are also different in that, unlike 
forwarding, both the sender and the receiver are party to the list (assuming 
appropriate controls to avoid random posts are in place) and so the list 
manager is an agent for both.

When I say section 9 needs to be re-written in modern email architecture 
terms, this is the kind of thing I had in mind.  I wouldn't go so far as 
Stuart does to declare that measurements taken in the wrong place are not SPF 
results.  That binds the protocol to architecture in a way that I think is 
problematic.  I do think we need to give advice on where/how to do it.

Scott K
--nextPart1340414.4ZtAWlEGmJ
Content-Disposition: attachment; filename="SPF_arch.pdf"
Content-Transfer-Encoding: base64
Content-Type: application/pdf; name="SPF_arch.pdf"

JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nNVZS4/bNhC+61fwXMAKhw+JBBYGkng3QG7pGuih6MltEgRxi6SH/P3O
ixJtS7bs7MHFYq0Za16aGXI+0bYF86P5ZqyxrTcxx9aZPvu2M9//an77xfzdgKG/758aizeC2TdF
KJivqkCqX9UEXeXe5+bjL2S5BQexo6vNiS8xJTL4Ztu43CYTE7rb/mlePaGnYLYfHyyst1+ax23z
4bKBDgM4a8G2CaAn/cyKyOdkPRlw4Npo+pBaejAXe7wK5zK0veldwvwobQGd7JTr+mhEvosBn0Es
Cb1roOtRVjjwHtNC8kIVO8qxB5FXz1VMu+Zzo3IaY81RijUa9NTTE1ScFsC20UKmpz+8/vqOq/4D
/99jfb/8L3LxLA1RRX0+O6fy5/P1fLnhoM8Uno3ogjvOGUjYcb9jy1ln/bp7sMHGdXyw3nbrP7bv
F/UxJOrjLtFyOjLbk61k8xoAr6PFM33te6AlqlkJ0GFehQvRUl0500prDYSj2oi8VEwslVp611H9
pMrZSeXxOvaDU9siKT7raKiKLFX6bKAp/xRDHKpTc9d2831nYKov53JyKns+Swt62Hto83QPv6Zm
c/aNddTI0b7Ff+7p5a3sQ0Dr060sfdwd9PGllYFrFGsXM36qORfEXKJg4xqXxWa9Chj32j1g6I/r
FX71xJ9C822wdNvjBwA4/N6JMnLACxY8C/tqidFQo+YaN4o0bhvJYsm/mmcVo3kiN7IVscR7Yp9Q
yOGgzAM9Si0ck64nbQ9lzA0phQCRyoMlg84+WdwRIK1X+M0TRCniBi9LNg3ZbGPv0EkZAMJJwDE6
bGilXaTloFzIme6wRuizbttEle2faNmcRVboYkU5ti/y6reKaByFJcKaG0chedpX9G1j8J6zMDcE
5/IyNwSnMrV4AEaXT3rxBQZgtBmf9ecHYIA85A+3yEz7nXAx9OSHs6y05l84qYxoUFbEklTRiwTV
NhdJosY+KJZFUjzWsZTxN/TXQFP242B/X9HXdvA9P/v04JvOxqnsfH6WDL3EbzhTffsSQy/zopts
31uGHgOGmPw4oXXoQV77yYn2mi5Wxp1MQroxDkOcb2+IBv5a9N+uV06tbGygi9N5OTcC600j2sAT
7GQARojD+MMhxG+FMgBHrshdMwBDJBs/OQCxkzjUb+bV47vnaD79a15tvwez+cd8uGJMyAN4h6hk
yEfnsGjeJn6nJfhDQMsrvTM+epKSO72ldIiG0GwLF5pw1qk8ZVzs8EJU+7IQpQrO1NHsbtvyD7Gz
Rrmv6IXLzLbWQh/Q0AoTrYz3PP4yPcV23wzle8BS4Wv6GR1qGHek4y/pwIkOdvQlnXTi5+0lHU8I
7lDHXtIJFnN/ZWyhO9EJZ3UIppzquEs63anOZskxCi45EyyhFGwunwn/MCeN5tOImDyu4H5ATB43
Y2xe1qC2RnSEloRCzGRpEgjHb2YiLqTaEYYdiLg4HgOiocNCJb6KGUGjONkfcNeO3TtPwsQ0PZOW
uQ1kLlFLcKOnFebjNG6kfdpjV/P8vQo3Bnrx9Zy+JYP3ImgsGVEYxJyADUmx0iX3wnFRREOSIrZK
FQUSCUcgR2ueXdULxb4CLfZbR1Sg49BjAz1Cx1KemrsNPt5zFqZB5HRe5kDkXKYWA8nJRn4xILm8
ny++VtGqC0BGj05PXtPBCQFFgYF6hsIvbo8EF+VkRcMfTlQugsiVWq1B5CJ05xK9SbwouusV3XU3
oLtofE58wuYdnbsIR4dbSCe+LzSfTO0K5zv6FA3Iuv9HpXeN64A2a7mDO2JUDaXVlnLsRTXYex3X
zEoQTY285mawnmyfkPnkseYWrgYXCQR5fPM7qV0CbzfYHo7ag3uDKzn1cuGhJys28nugD8Cbizt+
vfCBWsR3jEx9x8tQVroPnnadIE86ypXdb3iLQYwTBkcu+Ck3mjZ24wKvdjXsAnVqcTrKDZvsPEbC
1NIPGgmt7RvIBLiEIyuIxzCzSvVU5F3hAk5ylgZHxRE7Qu8aPhsVhic4SQuhRoRB2ywpDutQBnxU
IqsYxkf8iOJhf8BdjY/uNwEz2GgmJXOLbi5JS7ARAAO2OO7SB2dqNwEj4F/T4tJj+HPAKNB795gO
GibCyfik9CpVsi4cF4OkJRtip5TOpzFPsnmSvFJqRzm0L9LitY6H6idSJb6aG6FRqU7NXQ2N7jwP
09v7fGbmwNFcrhZ0crAdhz3RyS8AjgQJLu/pS7PLMwB1+Rga5fXKK6ThX4g2hIQUDjkK2BU0NNwB
QNR0HeABCyenhbcAHhgBT1bAk24CPA6CwACGL8KVzut5CkpP8k+hhcNZGBTwgI+tU5AidAE8ekd2
RtZQWm0px15EQ7zXcZ0DPCXymjsHeCgeGACPcEsBT99zEtIJ/IdHbuzrOqGjxEBMC8+NjxATWlbg
RogJunT8i6QgIeh7QbKMmUjMDZgJOklWLTmNmoozQk0TrkpFxZXgpmJccFNxXEuqqw/mP8fJWLIK
ZW5kc3RyZWFtCmVuZG9iagoKMyAwIG9iagoxODY2CmVuZG9iagoKNCAwIG9iago8PC9UeXBlL1hP
YmplY3QKL1N1YnR5cGUvRm9ybQovQkJveFsgMjkxLjcgNDc5IDM3MSA1ODUuMyBdCi9Hcm91cDw8
L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9LIHRydWU+PgovTGVuZ3RoIDEwNwovRmlsdGVy
L0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nE2OsQ6AMAhE934FswMpINJ+D4lxsP+/KhaTbu9yx3Hc
CQ1UGAlG4akORgapDRto02AhlGQHUYnUdKxi/y8mf11eUlXO/G49e4I8+4Pz65vkZY3DlXsiMxa+
X0eMcsFYOBw4t/IAKy4pRgplbmRzdHJlYW0KZW5kb2JqCgo1IDAgb2JqCjw8L0NBIDAuNQogICAv
Y2EgMC41Cj4+CmVuZG9iagoKNiAwIG9iago8PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9ybQov
QkJveFsgMjM4LjUgMzE5LjQgMzQ0LjcgMzk4LjggXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9D
Uy9EZXZpY2VSR0IvSyB0cnVlPj4KL0xlbmd0aCAxMTAKL0ZpbHRlci9GbGF0ZURlY29kZQo+Pgpz
dHJlYW0KeJxNTzkOwDAI23kFcwckIOd7IlUZ2v+vLYRIWZAtY2ykM2XU3qjiCypMJZimZLi5vnDu
xDg202JzObj/W7JuOR4ghSltRZsp7ggct4J5Sjg8XY5eAybEXvQ82YMTrFH1rGRfHMxUvC/4ADeD
LMQKZW5kc3RyZWFtCmVuZG9iagoKNyAwIG9iago8PC9DQSAwLjUKICAgL2NhIDAuNQo+PgplbmRv
YmoKCjggMCBvYmoKPDwvVHlwZS9YT2JqZWN0Ci9TdWJ0eXBlL0Zvcm0KL0JCb3hbIDIzOC41IDEz
NS4xIDM0NC43IDIxNC41IF0KL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0sg
dHJ1ZT4+Ci9MZW5ndGggMTEyCi9GaWx0ZXIvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnicTU85DsAw
CNt5BXMHJI4cfU+kqkP7/7WFECmbLdvYyMlUUNjI8AUVpppMzX7MZyNduBl1HIsVcVckWAsJStya
eIBU/vVUtLsSicR5K1m0zMRsl23XgBumb+3c2YM3+KIWXexfbMxVvA74AP4ULD8KZW5kc3RyZWFt
CmVuZG9iagoKOSAwIG9iago8PC9DQSAwLjUKICAgL2NhIDAuNQo+PgplbmRvYmoKCjExIDAgb2Jq
Cjw8L0xlbmd0aCAxMiAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgMTk5MTY+PgpzdHJl
YW0KeJztfHt8VNW1/9pnzyMPhjx4BQLMSYZAIE8CCMRUJiQTwPAIEDCh3iYnMyfJwCQzziMxFgte
a7VBi7eltvYh2Ba1RctkojagLdRf23u1D7Ctre3PCv607xe1attbzdzv3udMHoDW3t/94/f5/JiT
tffaa6+99tprrb32OXMYouGYTlNoP3Fye3u00HTGCJ/vELFcb19UffC5plzg54ns3+gMdfXc9bmb
XyBK/wKRNdIVGOj8xcfff4QoKw9j+rp1zffIquypaN+N9lXdIKwfHbCj/R9oL+juid44l61OQ/t3
aKcFgl7taroaaNZrKGw92o2h7dkLrWi/ibbaq/Xo730m64dE2XOJymOhYCTqowVJomsOif5QWA/9
ZVHn62g/aurASKqPFRGzyfb/5x/rRwAbyQmYyw9RPlHyJcArgF+NXpt807qHXKO7k+f5NDA/YgJR
Ed1Dh2kBXWBL6Sk6TdfSA1RLTXSI1tEZOk5TaYB9myzkonp6iIqYkxRqoFnMSvfST+h6CtPP6TwV
UyO9yHIhx0Mhmkmrk79G2Uh3JE+AK4Pq6Mt0kgXYdqoAvl4pZSWY+WDyNM2i4uR3k8+j9Vn6OVuQ
HKL1wH5BObSI9tG/US7tpmeSIkoWUAc9yPayX1MBtdMBy3LLYHIPguoxeo41AttEA9bn0x+jAEZ9
ns1ip5Pnkr+kr1kY6ZD0r3QHNE7QaaWc11mPkEoL6T20mTT0vp9+wqaxpdydXJRcm7wX1AfpVaVE
+Ra3Q48S2kBtdBfdD2v8iF6h11kmW8E+y47hepb9wfo8dGukGN2EvfVZWO9BephOsKVsqTJLmQVr
zaLFtAN9B+ko5h+ms6yRtbLT7Ov8qLVydE1yenJG8pfJJC2hFmh4mL6OOV5jleDBDLyQRy3zLVFr
1Vu3YIU++gydpWehx4uw++v0V7YE10vKB5R9yeuSDyV/Dl3SyEmraCvtoiD1UT99Dl59ir5Bf2J/
V9LBecbyTetN1gvJj8K2C2ktdN8C7u2QfQBeStAIrh9hlTlMxSpWsc1sG+tiB9k9bIT9hP1EsSkF
yg3Kb3icf5u/YLnKak1WQ9JMmo95XXQddcMDH4C1P4r1PkTfpKfZDLaQlWFFP8L4N5SrlXpcn1fO
KC/y2/hBy5vWD42eH/3t6N+Tg2RHlK2DHWL0JVjhj2wmdFjMdrMIexma3608yqfybO7iK3gtb+at
/A5+iP8H/54lbDlm+al1g1WzHrNro72jzyYbkx8kkRVs0GsRldJyWon46UQ07YF+IVxh2ku30CB9
BPHyUTpCx7DuU/Q0PUc/o9/BA8QKoLMfs/cg6m5jH8F1L3uYfZ19kz3NXmJviEspxFWsXKWsUeqU
BqVLuQ3XIeWs8iPlV3wu9/J9fD+u+/jj/CcWslgsSWsVrvXWA9YHbd+2F9vX2zvSvvPm799a8lbr
Wy+O0uic0feO3jP69dFfJncmB6B/EZVROTS9HVreixg8iutLiMTH6VvI3T+Wur7KFGZFxOcxF6Kh
FF5bw9axDbg2sa24duC6ju3CpbEO1o1rH9vP/pXdyj7I7mIfl9cnsbaj7IvscVxfYSdxPcfOsV+w
37BXFQSxwhHNRcoipUJZjZXWKeuULco2XF1KEFdICSt98NCDyrByQvkRn8aLeBnX+A38Xv5l/hT/
If+bRbGUWiosNZadli7LrZYzlmctz1v+bnVaPdZu633Wp2z5tuW2Hbbdtk/ajtt+ZXvTbrM32Tvs
e+0/tCfTipCt/h3rfmxSyquwnWER63TLjco57Is8HrLeznbAYjalmQf4R/j3rZ3sAlfZT9kg9/M9
yc/zBuWvPMh2KqdYIXdaq3kn3UlJdkx5SXlN+aVlBmtWfs2KLf/GvqIEeZ1ik3n1B5YZllutvyJS
fkzVys3stPJNfiu/NflVqrbex85Z71OeJdVyXplG57Crb1c+gUHfU/zKAWqxLLf+nfyw+xetN8Le
1yh3sCX8h5b76OfcpfyZXWD3IGt8l11rWaC8T1nNjiHjvsXm0+/ZDRRiHyc3e4L9jI0QYw/xB9lG
ZQq8FVccbCUOu+/yAvZDnkGtQke2UJnBmpQLyg7+pO0sX4Gj/Sx9n25inFUidlKfUerFDjikLEJO
8yCb/IBVUR59Avn+tdEnRca2Pm89gDi7n5fSNqqkf1G+TdXYGz/H1UIfoio6iRi8gyqVT9Le5H7m
Q97fhPyp0AjbTRUsE9lyFnTbh/NiplKIXNiGWf+K/P8Msn4j+wP1MxU76zQVW0TPnRYPMlM78u8B
XD76F7Q+Qx+1PWb9AW1hs4gs6uh9iPIX6H04c17G/HOoBvrtovstpdBaRWa+ASM+M7qe3Lg+RN9m
Ct0Mna/BPm+yrEfmvSe5Gyv044zaiDPxafInP0F18N225K3JA9SWvD95PXXR9uRDyL99yQRdRbdb
W5Wd1hLLcuTYp9k3cB79b3YAeXs9/RT5qIjl0W9wfRkaXWN9ggYtP0buXJO8M/kczYA9CmGhDpyi
r1AP/QF2W89P07LRzcpQsoGHcEKdo63JB5NOlkHdyQAy75N01G5F7tlP861H3W73mmveU3N19epV
K69asXxZ1dLKivKy0pIli4sXLSxa4CosUJ3z583NnzM7b9bM6dNyc7KzpjqmZGakp9ltVgtXGJV6
XA3tanxhe9yy0LV+fZlouzQQtAmE9rgKUsNknrjaLtnUyZxucHZexOk2ON1jnCxbraGaslLV41Lj
3613qSNs19YW4HfVu1rV+O8lvknid0vcAbygAANUT153vRpn7aon3tDXPehpr4e4ocyMOlednlFW
SkMZmUAzgcVnuUJDbNY1TCLKLE/1kEJpDigVn+Oq98Rnu+qFBnFe5NF88aatLZ76/IKC1rLSOKvz
ujri5FobzyqRLFQnp4nb6uJ2OY3qF6uhA+pQ6enBO0eyqaO9ZIrP5dOub4lzrVXMkVOCeevjs256
JW+8CeG5dS23T+zN54OePL8qmoODt6vxI1tbJvYWiLK1FTLiSlFD+2ADJr4TJmzcrmIu5bbWlji7
DROqYh1iTcbqdJdHUNp3q/F011pX9+DudjhmzmCctg0UJObMcZ9Inqc5HnWwucVVEF+T72rV6ucO
TafBbQPDs93q7Mk9ZaVD2TmGWYemZpnIFMdERB/rk5hkF1jjtjG7MqGRawPCIa56VWjS4sKaVolC
X0WD3lVgw6eVYVTcB3/44+l17YPZ1aBni/Fxa1G2Sx18neB/1+9/N5mimRRbUfbrJFARJWOBhv4U
Hi8piS9ZIgLEXgePQsdrZHtFWWnfiBJ3hbJVVDAfNcG2Wmt1BYxfUCDce2DETR1oxPdvbTHaKnXk
J8hdUdIaV9pFz+lUz4wdomd/qmdseLsLcfyofP6YEU9bOPaXlT1zmqe7Os5mvkO3bvQ3bnc1bt3V
onoG203bNjZPahn9q8b6TIwZHTB43FIES21wIfS27WoRBPxZixpcHn/7emw16BifVtfC85VWA1Py
uRSF+L1+TLJotEwRsixFNhn/vhF7GgJYUpjaEM9uX2+UrRkFBe9y0Ejyghglq/Fh5pri1SWT21dP
ak9Sb8ogh8KWhUpj867BwYxJfQ1IVoODDS61YbB9UBtJ7u9wqdmuwRO8hbcMhjztKfePJE8eyI83
3NmKRXSz6jIc68I3Vlx4MrbTpiGFPaF8DfeNduVUgqyWEeVrj3LKsAvkMUaz02zWU+hXiLPFlM72
sPdRXkn2GzVv1WzOfq1m01s1tAZ49psollYW5BTkFKFgOBHfVPnpN91W+jvuFk6T8cSqPPu75z79
TGtbVs3rabPT5CH9uZfnPTXpuU5ohgfxsSdc1PaCUQ/utGmcMumj2FazuYqBG4/dci48GRhEhbLx
HFYL2d/FszSX1HV8FwkLGPcJZOIMd8+jJq7QVDbXxDmF2RITt9B89hkTt1IeO2niNipk3zdxOz3P
XjPxNFqofMfE0+lDyqsmnmHdyW808UwKp33PxKdQZ7rbxB22R9MfMPGpdH32rrG178t+3MQZZeWs
MHGF7Dn1Js5pdU6jiVvA80ETt9KUnI+ZuI1ycg6buJ0COXETT6NpuXNNPJ3qcitMPEM5lhs28Uxa
PWPe2LcSy2bsNHEH3zXjwyY+lcrzXoYmzCKsPmV2jsStwiOz50ncJullErdL+mqJp0l8g8TThY9m
t5o4fDTnOhOHj+bETBw+mnOricNHc143cfgof5qJw0f5JSYOH+VvMnH4aG6RicNHcxtNHD6a+6yJ
w0eFi0wcPiq818Tho8KkicNHi4clniHWtSRL4pliLUvyJT5F0g0dpkp8pcSzxVqW1El8GvDcJVsl
Pl3yeCU+Q8oJSnympO+T+Gw59oDE8yWPods8yfNFiTsl/pjEF0j+r0t8icTPSLxM4j8TeJqh/28l
bsz1F4FPkfQSLnG5lhK5xiwRP1SST800gGdNHffdGnlRq/RFQDOekgW+Cc/ovYCoyaXiPjmIJ9OQ
LDXQ/ZJDBSWA8eXA6iVd+7+UVDGmmYr71yBosTGeiLyz7jXnW0qrcVXiOdTAqiS1FiMCqLdhTBd0
iMpR2yAvAghTH0of5vDjPliXfZtR90ueIGga5AvuLswbQCt8yQqq/8Fo9aLx1bRTzhwZW6nQdBVK
VT6n+LGeMHoigE7MsvgfyH87aeOjjDHjI5pgyU3of2e5X5ZeEz7xoa9H6r4HNKHVf9+fKqjCGn7M
GpWaC/uraAueqCl1BzRUoacYL74BE/NtQrkFc3dKvwoNxTgdUiNS925TWvlldDJiKIh5hU4h8A68
LZcuY1fw9Uutusbm9Zs7o0zGYlTqEABlwLRDWK5KSC0FZafkj0q6iqc6YT9hyV65JhGjy6SXuuUo
wy4pK2t4NgvIuaKX7EuhR1haT5VrEb3aRXZMSU+1U96a6HHDjxulvj7TR73SkhHI1KTcsFxJp7mG
fqmrF6WQG5UUTcrySZlih/VKPYSHxN4UPN0mTwQ7oEP66gZghh0C0nYdaHll3OlSr16z7pwQEf1S
hwBkC1k9cn9ETaleaZkIrk65y9QJPvVKy2gTcoahW8oihte6pJ00OdY3yfcRObcRWar0j09iMWk1
XdrlnWNhkWkhv5ThnbAjOiT3O8eJsQMu9d9ECxs26jU17R2jiSwSk1lPNTORTjfKXdcrvdUnZfrN
fWjYyKCF5NiUVY0o6pPZt29sTwhbh825w2Me2jMWcxfvL8MO726PGatbKyPHiOvgmP5GXBp26DXz
+WSLGzHnk943ojsmLWxIism1G3M2SVlCYhR0bUJeaZLZulfaxNjP/knRbOTIAalZQI6IyJUGzKjr
ln7UzHnDZr4Tq4tIz8cm7R+hrdhxKR1FNKgyKg1/iHV7Za4LjHk4YObRDkBAajdgrjgmc60hqV/2
dEtpQVxGzvSavunBGMPW14HPJ2cYMG00MZ90yLF7TF0NCwkLdAFukjwiUibmChHrxhkQNXuCk3Ko
T8ZXbJIXU5I1mdODE6T5pP1C0icDkzh90kJhaduUX8vlOR8FfzXuHypgA3GVy6wxMSLLzaxTIfl7
IL0CZVRmAqGXaEWoTco2dp2RH8NjZ2T52Mj/2Rn7pSdSOXF8ls3YJc3Y9Q2AOtzbCHwLqGL3NMjs
IegeULajFHc/63Cie+S3qILaTA7KkDB+7lx6wqTo3RNyQci08sBYZn53p+y4r/yml43YSmW/ARmv
qTm98l3Q+F3BxCyb0sfYTz0TzjBN7gYjsnpN6ZrUQpdnqhFhIs5bzdnE7uwz83+HzN5+8+Qy5nk7
y6TuyfrNE1fsJf+EHDgxyxs7qdOMlsvZK2iuS1hMn5RJU3v20vl8ZiYJy50fG8sYHaZnJp6dl8/A
ky1lnCWXRsWlM/vNParCcpq8Dx+/S9HkOaHLvHT5uYX1d5hnpHGmDFziC8NPk+8JjUyoSY1C0rJ+
M4u8G5+rZiym8njXhHlF7vBJSxvnsXH6hyc8J5SOcYcnxO34fck7Wyogs4b/opw+Li91XkZk/I3f
FaRy3jhnELzGHXRMWlzI7x5bj6HXxOjuMbOkYX9jV4XM+BjPppNj6J1WNB4fG+TaL/Vc6iw07uwi
E1ZjnDRe6dXei3wQvsje45LF+oLyXs5nniXivsN4QknlgXfj/ZQ8Y0/q5nk6+VxMybvUj4a1jBVE
zbP8cvs45THtIlt3/lPajlv50hm85v1bh9maqJFunoRRnD0pCeL5Sbx3Ek8qxXgaFG+VFwNfiSeD
VaBWglKJS3xrsoMaTc5K9C5Fz3ITX4lniJVy1FW0Ak8UAoT0f+6s+++fjKm+iousN3YeNg+E9E7N
q6tfVJu7dXVTsDcYBUmtC4ZDwbAW9Qd71VDAW67Wa1HtHzBVCGHq9mAgJigRdUMvxi1dvbqyDEVV
uVobCKjb/F3d0Yi6TY/o4T7d1+zv0SPqZr1f3Rbs0Xq36V2xgBZOTVB9Ubdq9lfv1MMRMWlV+aoq
tXiT3xsORoKd0cUX8U9kk13okR1N2zc1X8T7kNoc1nx6jxbeowY733Gdaljv8keielj3qf5eNQrW
HdvVJi2qLlSbN6lbOjvLVa3Xp+qBiN7fDbbyMUmwULArrIW6ByaSdLU+rPX7e7vEWD+cUaZuj2q9
AX0AOoT9kWBvqbrT740Gw+pGLezTe6Mw67Kq5m5/BLoIlbWOgK5GU77s9IcjUVULhXTN1FGwi1os
y1g41rgx2OvDinr1/khIC+nhUrUTM/R3+73dqj+q9msR1adH/F29uq9cVTdE1W5QIrGOiH5DDDoE
BtQO3Rvs0dVgry7kCUP0B8MBX0TtCUKBSMzr1SORzlhAqqZ6w7q0YQTShCJYWpe/VwuoPmP1EbUf
xlJ74AY11uvTwxdbYREU8od1r3REx8DFNoEDxtZnKAyNeiG0V2DhYKyrG35R9Rujem/E36djkbrw
KrBQOChUhYn6goE+4YnOWBijw2JBe4TlUv6CDpfxGKZbq0Vg66CQD1tCh17Euak4LOdTvTB3zBsF
UywiRjbp4ZAejWkyVpoCWm/UDz/7DTMjIgfUYMCnRqIDcK23WwtrGAtpUb83onbEDP9oPi0kJEaD
apdYh36jVw8ExIIDiNEOf8AfHcDEsVAATP3+aLfaFQwiMqFLsGcAWl/n9+lwZCxixElHMLgnIhXq
0bq0m/y9esSIirCOHRBFI2hEqC/ojRlLFMxaIBKUbD5/JBTQBgyir08PR/1ireXd0WiouqKiv7+/
vMc0ZDlCp6I72hOo6ImKfxVY0RNpiwrXIR7DYkeWi853ObBfD4hIlEM2b2ne0LChrrZ5w5bN6pYG
deOGOs/m7R61dt02j2eTZ3OzI8ORIffO2IYReLeMArgOFkMwX2bLylX5sWRYS4TfQDAmRnqDfTIV
GCEr5MBPPXKHaWoAxuoFu9YV1nVhsHK1FcO6NTgr2BHVYGF4b5IyIpP1Y+Oqul9GoBHycFInzDKu
F6wdDXbpRpAKz46NgxOiYT9CBKKhprk7JwSwqRR2yZgpxgYD19Q+LRCTKUWLRPToxNHl6g7sSOyU
gdQqsCYzEyIINTUS0r1+hMilK1dhRRHjXXKs5vP5xT7G9g/LM6FUkMPStjKXXKRUwN/jNyNd8ol9
GYkaOVlEniQG+5GgYx0Bf6RbzANZhrl7EJLQH64KDahGmJoWmjyRtMeGzvHFiV2IZBeR02DTePVw
r7mCsKm3ZI50B2PYrGG9z48DRcTApcsXfPCkjn1q7kXBN7ZGqIUJotjl4z4WC9NMrTsvL1aqPDbA
i/zWoacEYR4tWi0YdmyvxaFSvGr5ysXqyqWryiqXV1amp+9oBLFy6dLly1GuXLZSXXnVitUrVjsy
3mbXveNmFK0KUz25D/GwHJSPmeKxQDwkDjAHbj124xbk1/LGJdWX+vLPZ3xxxz/Fh/hX+SnACX6S
P3zlxcqVFytXXqxcebFCV16sXHmxcuXFypUXK1derFx5sXLlxcqVFytXXqxcebFy5cXKlRcr/0++
WJn07cc4rkn+y/W9dNEYfdL3Isad9+VlBmSET2hb5luWWhot6yzvQbl60gwiB7+dlM1yz4jcY6y+
m8XZ/ZzkvqgFV1ieeUKnt5dweXzs35tTsgDiL/M5kTzNXxr2eKrcI6hLymWdKF5cJTsSc+ZWfZW/
pDyMc8IJwrnEzHzZ82Ji7VoTuWqVgQwvKas6V5vBX6Q/AhT+Ij+HOJOjhovLqy7UOkBg/AOUxRg5
6Qj/GcUBCrn5T4cXLKw6fIp/B/3P8KehqRj2dMKRUwWB/86/Qrnk5I/zx8yex4an5lRRbYTfRYxO
ozwLOA+4ALBQkD9I+wAHAccBFspC6QRUALYICj/Gj0HPo+KfsqOsAAQBBwEWauZfAn2PKPlDfDcV
Yuyd/BDNQH2Af0zWX0A9B/XnQJ+P+n60RX3YbH8atej/lEm/F+2ZqD9p1p8APR/1PfKH5E7+cbPd
x2NyXNSsj/BIYr4zu3Y++lVAJYADOwTsEEx3SDgYJeO38oCcaQh1Feoeo4a5bk4UuKSPbh6eNbvq
CEx6M0x/Myx3Myx3M1nQtTfFs9fgKeN7wbMXPHvBsxdWqeQRzBcRP2VAmQ1QARx2j8Dugh5HeRpw
VtI/iPJuwBHR4v2w42Jo9WG+O1HsRJB1Da92V615gnfC1G7eOTx7XtXB8VZ6hghE1FPNOkvw6rJX
H06fIqj68Jx5Rg2uPbVTuZfeD1BoOsoFgOWAeoCFexMLKpwn+WbqSSP3VOc+ZR/fZ9lntVTWs9xT
vIqa0gghmcvLqAYMi51tNWxle3oofX86z05X0yvT3elN6dYg38cPcu7kFXwN38LbuHUkeTphr16G
yr3OVr3s7swjmfHM05lnM61x22nbWdt52wWbVbVV2ty2Jlu7LWTbb7vbdsSWfrftbrvSnhnK3J/J
szPVzMpMd2ZTptVpZ0dqb+Md4qcMKLMBIcDdAAts3Aa6yt8HaIM32mCK94FOKAmtbMBZ4OdRW9HK
Al8W+LJAzQI1S/7+Jkv2NAHaASGz1zbWkxoj+C+IHsAi9E4FVfx44DzKCwIDXIuWAy0HWg5wnVXe
hIbZKFVAE4BL2nkAogZlqq/S7G8H2GT/BcmT6nOLscqbbm3R6cUsvpgdWczuXszcNWtqq9yFKHJz
c9tcbUVtxW1HLUFXsChYHDxq2eLaUrSleMtRyxrXmqI1xWuOWipcFUUVxRVHLU6Xs8hZ7DxqObjx
+MZTG89stLRtDG7ct5GvhOuGEyWVVbIuLBL1Y4nZc6pWZtW+RzmO5bShPAw4B+CUhdIJqACsAQQB
VuW4pD4C6iOgPkJbAG0AK0Y9IlIMSqfZJ+iHZZ/ARL8yqZ9j8Q8nqpdtqd2ItNsGOAzgkP0w+h+W
3AZ2XNLjKM9L+haT/4ikCy4nIDVOJMFdMt3twjbcRWsAbYAQwEpn+HV0DgDpKJ2AEOA4wMJ34bqO
X6c8guth5WFe6nYsneGkmTNxfOTmpGXXZitTEAsO9pAsPynLD8tyjSwXuKde63jjWsfXrnV86FrH
IiBKMQ42BzskywJ3Zq3j0VrHllrH4loHpM2iAnIoM2RpEyX7rSw3y7LUPb3A8bcCx58LHH8qcHy2
wHFDgeM9BWLcXOxhhzJdlpmiZPfI8lpZLnRnOh3fcjquczpWOh21DnYfw+y0VpbzZZkvSvbqo1n1
WZT+BHuV6iGJJWoWO0cUkhVLJmpqUY0mataheitRcx+q/0zUfMz5JPsbk0cbeyOx4BVn7Qz2Gttg
Ee0/m/Wf2AY6hvoC6i7UD1ANK0L9hUTNLYL/8xj/KbQ/R4Vpgv9+apLjDrMNkv5Zc9xnEqUdmPXT
idIBzPopKpWzfiJR+gqoH0uUfhjVRxOlAVQHE0VCwd2JmiXO2hzWRQsUweulIkVostGccT0kB1Cv
MwZ7EqViVL2YYITVJVxLUS0SWj7JXNQkp3MmXHKR88glRcwll1Q6n4pkPZVlSeUdVCjrtITrFkix
PVr0ivMvNU+IhdPrLCtxn/PlJ7G+nWj+H7Yhccz57AlhroTzTOkIK3rc+T3XE85vLhhhOxPO06Uj
aeg4VTqisMecQzByHLwKe9x5vLTL+YhL9h51oReuPlxT5vy0a5fz3iK0E85bSp8UalAPVrwT3a2l
1zg31hxzNhSNMHS7azCZO8NZ7Qo7V4O8aoRtGD7mXLpgRKhSCRnHHncuwYwLXVKVHStPKivIzmLu
UnvU3mHfad9qv9q+zF5mV+3z7HPt09Ny07LTpqZNSctIS0uzpVnSlDRKmz6SPO8uEb+fm27Llv91
hkWUFolnK6JUjJ8SKixNwd6JT+ONSuP2tSye20iNzWvjK0saR+zJbfFVJY3xtKb3tgwx9pFWtOLK
HSOMmlsQoIJ0W7740fQJYqzitrvyRb33trtaW1lj/LSXGjvU+BvbsY6MrbviVtfaPJrZtyZvTe41
Oasb6i9TtJtlyfgnr2TiJ29e/J7G7S3xL81rjVcJJDmvtTG+Tvzc+oRygxL01J9QQqJqbTnBblJu
8GwTdHZTfesYGxUqIbBRjagE2zAVCjYqZMOSbaNkQ5gWeuqHCgsNpqfYBsGE8HlKMnUZshZgCshq
EhXYlPm0QMpaoMwXbIgHQ1jWRGFTiGVJYVlTSAqbK5iGiorAUlokWIZWFoFhqGil7D423u0qMtRp
pSI5TxFrlfMwNs5TbPAgCkweJQ08Jf+TH33tP8HMhrUXfF7xo/d2l0cHtMcP9HXnxfd3qOqQ7wXz
1/AL2zu83aLW9PgLLr0+7nPVq0Oa9zLdXtGtueqHyOtpbhnyuvX6hObWPC6tvnX4gX11jZPm+vDY
XHX7LiNsnxBWJ+Z6oPEy3Y2i+wExV6OYq1HM9YD7ATlX47a1rLGpZSiN1rbWXW/Uw0pmBvZDe35B
69qZ2aFr5Oa4uiDvA/knLYRjK7OkNT7FtTbuAIiustqyWtGF3Sm6por/1sDsyvvA1QX5J9lDZlc2
yDmutVRCeR5//dhfJBKJCojFSlBGY3mSFsWmLdjeGG8QP8Kuidd44u72+lYm3BEzP3Ut7uxTNWdq
lGDNvpqDNYdrjtdYY7FWkHNPFZ4pVNoKg4X7Cg8WHi48XmgTHde3PO6uOVz4x0IeQzSxKD6eejln
DDX+RDMai4gPYYIIwJiuJFZS11JbSF7c9TLcoZfRNIALsAywHWCl/4XyB4CXAX8GWOhWlB8DfB4w
LCi8jJd58vz1YsbWEpF08njVcOWKqlUjqLVOo96+y6g9m426prYqD3VizbKM2izcgDM6ifIZwE8B
vwH8J8DKq3iVFB4zorY1QpESBvUJjagoIiVRVgKECXNHIyUlJEAEODwA1hI2Oe6JRWIEU8AhqMAk
qRExLCbq1Oe/AHOAPh4KZW5kc3RyZWFtCmVuZG9iagoKMTIgMCBvYmoKODUwNAplbmRvYmoKCjEz
IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQkFBQUFBK1RpbWVzTmV3Um9t
YW5QU01UCi9GbGFncyA0Ci9Gb250QkJveFstNTY4IC0zMDYgMjAyNyAxMDA2XS9JdGFsaWNBbmds
ZSAwCi9Bc2NlbnQgODkxCi9EZXNjZW50IC0yMTYKL0NhcEhlaWdodCAxMDA2Ci9TdGVtViA4MAov
Rm9udEZpbGUyIDExIDAgUgo+PgplbmRvYmoKCjE0IDAgb2JqCjw8L0xlbmd0aCAyMjEvRmlsdGVy
L0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicXZBBT8QgEIXv/Io57h420J6bJmbNJj3oGqs/gMK0ktiB
TOmh/94pVk08QPJ474M36Gv32FHI+oWj6zHDGMgzLnFlhzDgFEhVNfjg8qHK7mablBa235aMc0dj
bBqlX8VbMm9wevBxwLPSd/bIgSY4vV970f2a0ifOSBmMalvwOMo9TzY92xl1oS6dFzvk7SLIX+Bt
Swh10dV3FRc9Lsk6ZEsTqsaYFprbrVVI/p93EMPoPixLspKkMbUp2eN0p/axftqAW5mlSZm9VNgf
D4S/35Ni2qmyvgB9WW11CmVuZHN0cmVhbQplbmRvYmoKCjE1IDAgb2JqCjw8L1R5cGUvRm9udC9T
dWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0JBQUFBQStUaW1lc05ld1JvbWFuUFNNVAovRmlyc3RD
aGFyIDAKL0xhc3RDaGFyIDEKL1dpZHRoc1s3NzcgMjUwIF0KL0ZvbnREZXNjcmlwdG9yIDEzIDAg
UgovVG9Vbmljb2RlIDE0IDAgUgo+PgplbmRvYmoKCjE2IDAgb2JqCjw8L0xlbmd0aCAxNyAwIFIv
RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgMjcwODA+PgpzdHJlYW0KeJztvHt8VMX5MD4z55w9
Z+9nN5u9JJvs2Wx2E7IhgSQQEiJZIAExcr9IMJEsyUIWct8NAa+hiiDe0Fa8VkStota6hIsB7Veq
1lovhVZrv9oqWLFqWyrf1tIqJvs+M3tyQW3fvu/v98fv8/u4Z2fmmZlnZp55nmeeeWb2Eu/pjSAD
6kccCjW3h7tu7F7fjxB6DSFsbd4YV+74XfwdgE8ipJm0tmtd+yUPFlgQkmSEhMS6ts1rX84uW46Q
8ShCvt+1RsItlTOnmhCafB/0MbUVCjqGvyNC/k3I57a2xzdlmwJXQP6fkL+yrbM5vO6OadchVBKH
fKg9vKmrVXctD/kDkFc6wu2RRT97/QbIQ/vgL7s6Y/FdqCCJ0GV7aX1XT6Tr+5vvz4D8ywjphqAM
w0NfBgA1NE84XtCIklanNxhNZtliTbOl2x1OV0amOysb/f//JRxBLggZwqPIxQeQE6HkRxA+pulw
NPkxracp+SMgD6oBob3oSRxFT6Ln0PP4DLR6Ch1GB9DLyIFq0H3oSvQ9tA1p0CoouQEtgUeA8u9h
V/IAKkZ7QJf2oNcB9xJ0NTqC7NiZ/ARdg7Zyb0CrrciIctBMtAh1opvxxcle1IBO8NeicnQx6kBd
uD+5MnlL8vbkw+gH6DD3cnII6VEGaobn9eRfhP9O/g5NhBZ3oLvRCXy79iAKwSj9gPl91IPu4Rp5
nFyX/AIo8KI+oIFH89Hr+CgJQu8R9BF24iu52dDLQ8lE8kXAcqNG1IruQUfwFDyXeIWG5Pzk68gO
Y2yCXu9GA+gQPIPox+gdbBDOJB9OnkEuVIjmwXwOoF/go9zw0Jbhaspo4NIEVAE1nei/0M/QcezD
PyGdgkEoEULC5ck3kQ1NRsuB2keh5R/wP8jV8FzDvcTPSc5CJuDLbZTb6KfofZyBi/FCvIJMIJ3k
fq4HSTDiZHhaUBT4fRf0/h4O4kPEQI5xD/FP8Oc0WcMnkyaQSADdi76PfoKNMFMFx/B38Fv4AzKb
rCb3kt9z3+Mf438lhmHWl6F2dDN6Av0DW/E0vBhfilvxlXgbvg3fjV/Hx/HHZCZZRjaQT7lWrpv7
MT8LnqV8jL9WuF64UfPx8MrhF4d/OfyPZEnyerQY9GELUH8Huh9mdhgdQ2/DcwL9HgtYj03wKNiL
l+Mr4Lka34wfxHvxY/gAjHIc/x5/gv+K/47PEQSPhmQSL8mBx0d6SB/5HrmPHIPnOPkz+ZxzcDlc
kJvCVXH1XCdQtY3bCc9B7n0+gz/GJ4HPJcIuYbewV3hCeF44ozGI35GQ9NqXDw0VDL03jIa3D+8a
Hhg+kHwfpYMMM4ALHlQF1IfhWQ/y3gUa9xR6AxuAdxm4AM/AFwNnVuP1uBtvAk5eh+/BP2C0/wg/
C1z6Df4UaDYSN6O5iEwhs8hCeC4jEdJNdpLbyQHyFvmCEzk9Z+bSuQJuLtfIRbg4t5nbxSW417h3
ud9zZ7kv4UnyOt7D5/ABPsjP5Vfzvfz9/Ef8R0KD8KrwoUanaddcrxnU/I84VZwhLhIXi43ireIh
8U2pCbTzBXQQPT1+zeOT3BauljuIbiGlvIv8gvwC9Hk1auHmE9BUshdvJ1fhAyRX2KSZTqbjBegM
HwBev0R2k7NkOjcf1+GlaD2ZnOpNY+Mfh6SKfwGd5p+Fuf0Cet6kMeCryacaAxrAiFTAmD/lJvFB
7lX0DncCi/we9Ftehx34NHmUWwRa8GN+hrASebn70I+4bnwVOkhqwWKfk24CPV6AHwe7sAyX4H9y
ScSRBaBF5dwH6Fq0gfw3Og3reDu6E7fw69AtqBRfiT5Cj8CqmCB0aAo06fjnJMrvIGn4ACL8YzC7
CpyLOcGGrsON3D2aT8nbqBcd43XoPe6HQP0x8iNuPn9GWIJbYQVcha5H3cktaLOwkv8VXoc4vAL5
+ZNg3a7kSngvpNeAVWkAm3YIVvcRsAMzuflQ4gTNuRj0YjlYiHvguQvsBA8aFIU1fglYsV+gA5pl
ZBCtE0wYrA5C/KvDS9Cq5CPo7uQ61JG8HU0Ee7AteSX0uBd9iG5Fe/HW4StQF8qGlfMevliYQ44J
c5ITyQ7yNllKdp0vX+C2HzvRH+H5EZqDZgjPoB38b9BSVJ28Kflr0O58sLB3ozXoInQKZvkXGOFC
7igqHV5A9iXncF0w3xNocfLRpAfrUGuyDS1Ez6IfiAIKi8HQzJmh6hkXVE2vrJhWPqWstGTypOKi
iYXBggn5eQF/ri/Hq3iys9yZGS6nw55uS7NaZLPJaNDrtJKoEXiOYFRY65vTpCQCTQk+4Lvwwok0
7wtDQXhcQVNCgaI55+MklCaGppyPGQLMtV/BDKUwQ6OYWFaqUNXEQqXWpyRer/Epg3jV4pUA31zj
q1cSpxk8n8E7GWwE2OuFBkqts7VGSeAmpTYxZ2PrjtqmGuhun1432zc7optYiPbp9ADqAUo4fF37
sGMGZgBx1FbuI0gyAlGJDF9NbcLlq6EUJDh/bbglsWjxytqaTK+3fmJhAs9u9q1JIN+shDnIUNBs
NkxCMzshsmGUKJ0NulHZV3h0x02DMlrTFDS0+FrCDSsTXLiejmEJwrg1Ccflp5xjWejcOnvltvG1
mdyOWmdUodkdO7YpiQcWrxxf66VxfT30AW2Jf07Tjjkw9E3AxLqlCoxGttavTOCtMKRCZ0JnlZpf
xFdLS5rWKwmtb5avdcf6JhBNxo4EWrLZO5CRETqcPIkyapUdy1b6vInqTF99uMa9z4Z2LNm83xVS
XOfXTCzcJ1tSjN1nMquAwTgeiIzWMYihU6huyShnMaXINw8UIqE0K0DJSh/MaRqNItPQjuZpgAav
egytEi0gkWhCO7tph1xJy2n7hOCXfcqOvyPQAN/pP59fElZLNH7574iCVE9GVQ3qR+BEMJgoKKAq
Is4GmQKNM1h+ysTCjYPE5+uSFUiAfWgR8DZcX1kM7Pd6qYBvHAyhNZBJ9C9emcoraE3mAAoVB+sT
pInWHB2pSV9Oa/pHakabN/lAkw8w5zc9IQVG32bZnlbbWpnA9n9THUnV1y311S1etVKp3dGk8rZu
2Xm5VP200ToVSqTNXsllEhUimRyrBaVsGEWmmZWGBO+Ht4YpdcugKIFWshKszEnITRem4nqd1/sf
NhpMnqGtWDLWTCUzURk8Pz/9vPx55Bl2cEAwbIJ1y1bt2KE7rw5ULTXgPDUBjUfLVnqV2Qm0HFam
H96DyaPTaKjPTISAZbMpAuhfqkjNnoeYqcL18KLaObFwDhi6HTvm+JQ5O5p2hAeT/Wt8iuzbcZg8
T57f0VXbNKI4g8kjN2Ym5txUD7xqxZUTEcHM+RQQeLMimnWA4FMacZDcHUpDAn+KQzqRP4WRS9II
pwj3LGzqWnDxipAzKJ+tGqpaIH9WNX+oClUDLH8J0eRJXovX4ocIw5b2pcId/TIkoHNI4Y/S01VD
8iP+T8IbaBIaDt3XzDXzMS7O8/68KVyFezY3T7w4q9ZTkzsnbylXLzZkXZJ/Q5op3xjIJblcnn+q
ucxX468tXqWs8C33t+nXGzeY1toizs36y42Xm6+Se3Nj/uu5HfobjDvMN8tbc6/1327cZd6Vnu3P
NRn1ghcObJmwycAeo8H+3Bwo0wjZmRNvzcAZp8Fjl8HNXASLswvvxBo8iBMh/8TsbDsnZE/UZgYy
LtIG0AQ8IaPEG7DigHWZArNxTW6+1BkEHjTOP3VaPr1APts4//Rnp1H16erT8lDjKQifWayOCgu8
rRUVGMDJk1BjN27sTivPJqUlU6dOKQvkBXLzAoEpZVOnlpbY7Q4xEPDlaNJtDjvvsMMWqdH4cnID
DU8bV798VefjSxc1TB9uWxxdd/Vfv/fQ59cLR8xPPpbYUzENv72y//Lrz33/Z8N/uxv/Ru64+ZJZ
sZradT5HOFj+UKTzJy3R17aYbrxly6ULS0s35E8/uLH3WCz+CTjNdcmP+Wx+Buz6Wei9UIsHudPJ
cq5RaNQu10e4DUKnNqKH47qMZZJnfVv4wnY2Q5xsrXRNds+0zs+Y6V5sbXAtcYet7Rlh9ybNpvSz
5KxThjOb2ehwLLI32bvsnN1t3ik/IBNZ5jPdOhENksdDWnxHmpvXO0JG0OOQNq+gLGHExgwP5Pb7
A2U0DWVl+8omebDHXirniqHcgjKPWC0uFDnRlV1WnuJ7cP7QqQVydzB4tjs4nzJ+6FT1aWtFcWPV
UHcVpky3AstxI2rE3T3YQXmJLDIqLUEWm+i120EE2AsSAI5zlx0p/MvhT4Y/xbbf/RoOHV9+rBvY
2nzT0DtksWHaihuufAyvcDx0AHswBx5+/vB7w5/LylNHWvEd189ufYTq9jZYQn8ATtrRa6E0gdOk
kb3yoPwB91HaGe5smoYHOxOarDeWbZbxXfJx50ln0skrks1ks1vdgog1dqPOaDKYcvWh0qllST2G
t36BkzIio2xqWcJ5xkm6nA84E86jTt7JkdJ0ux8jWm0F/DPUOCvoODoJy26BAzSxOwjL8bMqGQCa
OV0l02VaXX3aAooITJm9OWTXWLQ6SSfqOI0csGhMmdiss2ZiFMTBYMEW0FIUbOwutZSmpzTTnm7x
WcpS6mnZ9mDvu017Fsm6AwUbLow9ygfufKq2a37JVUMxcn1H+8zbXxt6FrRrTvJj7oRwBFlAu94K
PaEjvNFvLDPWGIUptinuS8gy3RLbUvc60iJEtM22JvdRz5vCr9PedX2Y9qHtU8efXB9mnfQkPXaP
J5hRZa/KqMvo8uz0iEUk11hkryRTjHWk1jjHNs99iW6FcZ3xQ81H9i/wZyYZp3MmvWxGmW69aEG6
dDend5Zi5LeY/bJ83IJlS8jSZOm38Ja4Nfc58Zh4QkyK/Dj1WpRSr+75p4cau6tkWM1Vp+iyrqLB
QlczXci4uxF1e6eAUtH1a6VcclhKLdhG9QpWNtWqaZEXr/l17/o3r23aVbx/SPlh78Yf7L1i057r
77/p3EO7Mbdj8Uxi+mIOsb72yk9eeue1F4Fn20GZqoBn1B5fFWpcqN2pfUCb0B7VntCe0YpI69F2
afu1u9Wik9qkVufRYgSnJsJpNdzVGGkEDa/TiH4B8bv5B/gEf5Q/yWuO8md4gniFPw45nl8gzV1E
rXhjd08VteB0bmzF0EDXTE932pTSdA4mtP3AgQP8n44dO5fOB869A4ckNGt4MfdH0PVsVIDOhJr0
esFWqPfbLtbX2jTaLFdWoT5gK/RV6KfaLtLPsa0QV+pb9V/o/p5uKvIV5s3wzci7OG9n4QOF4lTv
1AnVhXP0c7y1E5Z5l02Iis3e5glNhf2F7+R97P2L79M8i8OuSR8k+w7ku9NETE2HrMD20QSHnX50
FBSe2pOrQjMFt9usq81xG3T29FJ/qc7vdB53YNkRcjQ5+h28I27GfpTjyX3OfMx8wpw08x5ztXmh
mTO7goVxLxV4cAET+GfUdIPMh06dBa6cBnsClpymVZQp3WC+HQ5YCyDh8ql5IHqSkrxjSqmF2epA
2jjxr31KXzI7ftV2pwlvTPz2TMcvb3728kciv33gv/549yNXXbn3ycs37V2Zsdhf0rKqPHEjrnr3
Loxvuqv/y/X/PLbpCa7gl0efe+2Fl15AJDkEe3Q96ISITDg71FwsT5LXSa3aJnk7t1P+ufCS5qh8
RtZLQj1eQRbJrfqE/DfD34x/M2l5A2/kTRycrwSeNxhNkkYUDQBLGoNILYZosEEB4TiFN9gAQ5st
CFK2htMMkq6QFkmGT0IEE3IE6xHG+pDVoKCIyC1ZxB/jT/DcTh7zgxiH9IsMR8UTBm6nARtoXjbD
miLXiP0iEb9rfus3oGfAWxcEeDthq8xwyadPI2d1Vcbp6lOwvuC9TSgKXiW/uK3ISZOUJlZUbJNf
fNH04ovbhFQKIqhL6JfWJbLBJTvAmzlJPJI8g1Dyn9PgVY97uht9uBT7OC+X5uUCeRoRDOUvycp3
nxi6d8/b+H/unpPjLhWOfDEHPztcQ1bhXYf7br4R9Pl+4O8q4K8Z7NR1oYDiwbMl8Bdg6hY524wk
R0DRYm2GJ0tWMN35G7OnN7DFQ/2es42nmQNUzfwfsKtTuUxR0kiCxEu8xuXMcBKNXmfQGcHOpttt
9jQ7p8nkHF5sNUHklNxebNdZvCjI7C68wPSWWrwlVM2s6TZiIj6/l6pbylvwee/Hnz+x6ur6eGzB
5be9vnV4H6647QeTa+ff2bbgyeHXhCPpWRevGT724qPDw4+FS56cOrn2k0f+8I+CbLpH3YWQxgzz
lHFv6BpEzJKNZEr8RsP1hpcNnNYwzzDPzE3g/cZC00ruUn6jcZNpm1HSE0GqME41LSR1XI0YkuYb
Z5l0d5G7uV3iLmkv96iosRKzyTRJIDZBIJLBaJwkSABKhiXmJTgE6iPRC3S90WgyyUjSkiZrv5VY
j5C9yIgnDwiKNIgnh3QGrU4JGa6BXe8IWQF6rocaMghKpzVjpJi7wAUZJCueVoQmoV/ghEGyd79l
er0z6ALd+qyxygmSYHoFcMZo5lQjaFl1FWx+Y08G6B7Vtm1XMW2DBIz5mFr9GBmS55CUfAvW3VtM
q+oSBqjLh7rDyJj85z6TjpbC6YJm3zzkrTAVeivAkXnzUHmFqaScgQcnQunEiiB71ffQnaKRiRXb
HVPLsRe2UuzDlrtwLr50kt01Ba/GwjPDK54aXikcOffX2y5cdC/35Rdz+FfPTeFPnlOozd0DOvok
yM6JcvDFIbNVb8LWqe5VnrVSu4e3DiZ/v9+aUQbpmf05eWUWms/KK5PV1KymUP/f+7MCqXrAl9WU
1odiAPhNF7kvUpbqG9zt7h7tJtNm81bddvOdxsfMg+aPTR+ZZZPBoFjMNovFbDEbtNZM4s2w6zRW
i2w0CE6t1u7IcGU7HMibQ1cPcjrNZpOUHTDdp2lUcrty+3O53Bynuoh80/em9ll6hpAbz7pOOelK
ojKiawn8OCiuqigGvxmDD73NVBQUwDZQOxwceaFGkENIJ4XMFWa50mKtpOzG3Uw4puR7oQxXhSXH
VWGFYAq5K+QcGwQPhHRVNsF6utaYpy3CgnOk+bgiAqvMZ4FituR83j1kx4uvXf7KG/Pzl1+c/Oz5
5R2XTPTWvY/3bN214M6HhicJRxa+vPm+t7L8uQt6h7vx5OtumqYXh3q50vLNc1uvp+tuEfhBp2G/
zECvh+ZqDdjjnp0227E0bamjKa3JcS+5l7vH+LD8cIZBMrp060mUWy/0GrqM/cZHDAe1h3QHDQY7
rNEPCGfKWW3uNF8D+xbbC+dNQiG0iO2GO9ED4PydQVpkNusR4q3g+zjBxXabsTnXlJMJVOTqgx4M
ngLG89zpucdETD0eIk7OLHsx5QmchqhHPfAeRpieME/3fHa6h51oQByWimIZjjWNp0aOMSMuter8
jJxd6AbIVe3L+vRH7wz/o+eTG578necp1zWrtj/+8HXrb8FbHU8fw1lY90NMtjy1J3ND2wtvvPX8
d4C+DPCgP+YDSIcve3qKgFGOpUI3CDI0Wiq04CSXSTQig8k/7ocUqylg/HdIm+0tQ/kQQe7jkDbH
X4bsEEHundDB/KIypEBkNkxA+dqArgJN0V2I5upWwGZZL63UrsVrSVSKajehPtxHNkubtH26bXgb
uZ67Qdwu7dB+H92lvU33Q/Sg7sfoaXGf7ufop7p30K91f0Yf6M6hz3SFOiTonMiuy0cBXbluIQrB
bhuy2suEELj7OlGS/FqdTavVIY4Q8NltIANBp0M6rSQRgjWiTsshLBTD5pkjhUIh8O6IdhBnHgyB
oSMCQCGtQkI4R//HX1E5gWEbahxqzHCCdUsdcSpGV42l4muWDbaV7rH1wpaMF5emUTOUVorxj4bb
/uuU3+MM/vnwcAcfGLpuXeeyjWQ79fMw2gqG5yXQWwu6NjS9OA3LPPbxZfxsfim/lo/zGq1F0kpa
Y5pFa0SchPVuDRxkYGL5OyUs5ShpOI3kWNRjSvrXjinWuarewVEFtOqzHvCx2QGF7vzMA0Dyz7eZ
2Cwae6j1hKMI9bVEqmYinEK2PjgjWn3pZTNmzZp+mS2bD+zpvrDy0by51U09Q29S+nOTfyUFwt3I
gfoPIx2cLX2BMi0lZiYA/S5YCwajDnPILmuDZp3GDgcFs5wDBtZo9RtwUpRqtbVNYhc4MjtFHomK
+ICYEI+Kx0WNeISsR048dd/a1BQ+OwVeDJirU59VsYPCEIjCWmEpLZV/nrJXfkfqnGDxgadYDjPx
WWz0AErkjIur1rQVXnfd/oMH04L52Xt2yzMiD5Lmm7DYNnzzTUPfnV+YQe3/RXBSd4Ms8lE5zgrd
ojVqC1zGjIIJxoIC2J3TyzMrC+YVNBobC9YbowVNk3YYr59wj/3ejMeM6Y+4Hs8/5Hom/0XXsfxf
pb+bL9XYsccBIi8sKKvgKwrn8RcWrpDqg2ulaHCjYZvh54bPjZ8HLeVlJszLxblljhKvzbl6QucE
MsFdbKo23WrabUqahN2mp0yfmjiTyc05qDGyO++wud0iqs3TlQAjJ4TlMPJ7cwfJpSE5L4QCckAJ
TAo8FRACkyuoDDz0fF9xtII8UIErHH5nTnHuc5pjGuLRVGuIZvI0ZpHAHWcn2NOfVQ19+CFlLfXI
T1noIb/7dDek7GrFot6tsCOZn/nh9EalnD1TytgJX8ybQdSDLJgohy/AaUQTSVkrQOKqWg6vf+rZ
ubELp2x4Zx0urd1+zeashLPj+A3bH18kax05z7oda17sbChpj7Y+GMi6dvmcJ7Yu2LLAZjJm5Pp1
HRMvqO92dt9YFwpfVLTpzLmtF0zD7+a75fz5xRc2Xbrwgj7QxmrYBfaBBCfht0NX8Dm2nErtRdqa
3BU5kZwrtbdor8t9JO2Jwuc5o9aR4XRMqit8yyFkkuWEyCVY52yQGrQNugZ9g6HBuF5ar12vW69f
b1hvPBA4kGemd0i5E6bmrtLV61sCLflxXxy22u/q7jPcnn9n4R2THtY9Zngo7+H8/YGfBuxZ1KZa
sytWSXl+g47PUALpvL4oK4PK0O1xVbsWula7nnIdc2nMLo+r03XCxXtct7qI6xmyHKWDKsIZTKZ+
nYyPwxaPZUwwvbex2alRPhrKNlnKMC5qyGrLIlnudJF3F+k9GTgj1xVKc5a5QB8GxNwCwHzaXXG8
ABdklNBWgbyCsqaSoyWkuqS/hJTIsEvlIiXXnHMC4Wq0EBaAa/LItU/3fFCL0z0LmGrQm5/Pguom
1Q16EQzCmZZevkGc0g9VPcA1D+VNzPbBYTVgka1ymsxpcoxKJtLmi5lYmAhRtg2yXpMvE+X4jAZp
gi4T5+dpdZogn4k8cha9HAlSS5uKMDWnBcEtW7bQmxJ6ZG5MK7enjn95gbwiOBtSt/0r93rwZJPU
xV6gesB8wxVXbpri/+5Ldy+cOa3gtqVX/XiVJWGIRa9cb7cXZ1733J0roi9ddextfIF7Q0+k5gKf
018yb8uCuZvzPcELr1jnXNKwpNznzkrT5ZbOvLJh1e5LfqjeRWkCoGk+9NJhpIUNcibsRH7+FH9K
+77jQ0X4tXBWIQ5J8WmdmYqW43zZbk26W6+n5tsHfrPuuB/v9D/gJ36HI8Pk32nBlkHceNDp35mJ
MwEKuRAp9fnxcYSp30E8iIqIQ65c/yDetN87d+Q83QOu3SmQGHjlQwtqIzV/6AY5VVVVgU8+XwYZ
WhzM0KsXUiaDLS1gM1gysdWYrl5EbaG3d8ER0w+7FkTjL6IoBAC9ktpT8sj6jXd6rn7l/sf3+xpm
dH3vwMqWi7dU8oE7Fqxes/LIU4eG8sj321ZX3vHw0J1kYNOmRffcNvQ2KFYNWNY84JYRudBPQo1W
UecyzNVcKK3Q1EvrNFFJKpMrrZX2Kc5auc5aZ691NggN2iVyo7XRvsTZLrRrW+R2a7u9xdmH07Ua
wXgpt0xYprvU0MZFhIiuzaBzuHnRAuy15YpU1dNy/WWT4PgtyrCjcOLkE5SpUO6iBhFgUy4KAQpl
KkGTM6jWgy0Mnpa7g41nGwFgqg7bCjV21P3VLhWWatcIa7Q8bqxPk8uBRyilYGj8bUTNwzf89LfY
fsWfbjwxfPrwwLbrB/Zv3TZA0nDeLRuH3x96/U/fwdnY+Nqrr/3yp6++Alq0NvmRsFF4A87Eg6Gm
ZrI+iyioxNgMzmY8qx9dl7UT3SM8wf3AeJg7YPyZ8Tg6lfW3LIvJmmXJyuIKNPmWArfimWtcYbsk
fYWrVdiQdYX1Rus93N2me9x78cNkr+XXpjRkQxmyTc7gwa17byC/ghmQvPwK2Ywwn5mWbeAys3mt
HDBfhAIKmIQMDxzFwbdwZTc3qFfv59+7W+hCB7VppFc1mN758r6cXHpJk1tawqurEFaflbKFP/D8
BcMvfHh6+Df3PoVnP/87XDj9udLnv/vYBw3tf7j+od8TMvnTcz/BHb/6EC/fd/LViQ/c/uDwp7c9
M/zJjmfV+176/Scb2ncY2YFsY7oD1tgUrpY7YuS5weTJUK7DVeaQLAaLjQN31uwWRJteZ/Br2Q2v
Fh/VYu0CO52xg97w2s/YSZf9AXvCnrTzdmL7l35T+sjNHb3ipTbwM3rBi9jtpKVi7H7XpDGJfpPG
kImNknlkOYGlwnQ5WZhZOm/9HLj66MYf1R3o3bDo5irhyNBfb298+L6h1WTPtiuW3nLV0DNAw3aY
8z9hznr8WihD1KzQrNJyZuPfhLMabjnXpyNWjZLmLZPoIdSaRz2tMwcgtQqswMsKQtdBiYbnBV5T
rp3LC37NRN1KXR/Xq3uH+0AjPqLBPk1A9EsVmmnaauNCYz1fr1kp1muv4jcLd2tf0vyKf0tzSvOJ
+A/N51K6VacTOI4nGo2o1UqQAZfaL2psoqjheN4v6GwCeNpayEiwU7Gv8kl6PdLxg9g8IORIkIR8
CjsFZew0YqPej8BDB5s2suUYjO97565VjVnKZC2Qu0f0TXW6we12ML+bpxdYAnjeJgBEWaqSqjgW
g0qyY6q2MKtCK2VlVWmoumdVQPLmgMKSfd7UgbSe3RR0wz7DzrCa5NEBbwVo09EBO03eG5ArNKmE
5Qws2acfuWmgWxIdyvoujyWbHUaz2apYBK3ODjhp4z/vy0yhg7WARcLu+C0YzgI+LFq2H8CPfzK8
Hj/33vCea4QjXz6LE8Mbh1qI5/LhS1M3ZfwQaIAROdEloSkRywYbqZPrbJfKl9p4vSHbbDIhh5Od
/SVrQMpQMjC8M5xG9czvGrs4A0Y2nqWf2qiHfXZ9Rq09u/yiWyTxetkpfOTei0y4fX7b7fV/Gf75
8HZ8xbP3N148+brhG4QjJmvkUPszw0NDP+TwTdc0XJtuhKH2AqVbgVItqgsVaIRsSbpVxKKIOD5F
nXifQhQ9IRl6XqsSp5veMHYhwczKqVHqGqtkSh/Qlu5lYS/37pcfksTQIuHIk8OVTw6thR4mwZhH
2D3twpBRINk8RwfSCLx2kMT2K6nr0qc1CibFHOYAPojZyLRWOnR3ijN0fHnoVOMfZPaZTfXIx6pT
6KgkbTiL3zGcKRiffPKLv9FzwbbhKO+F3cuKstGx0A8M8kT5ArlO5quVhEI8ygSDL6skvSRrVlaX
slORKh2VmRc5Lsqsly41NDgaMtdLGwxRud2xIfOo8obtXee7GW9kn7Kdyj6pJBW7jw/KwfQpfKU8
h79IXiV/qP9T1rCst5g4u5sd9exukx6ZXLnHdVjWhXRNun4dr4vjtFJSavUjdBSWEn4AJ/AZzHtw
NV6IOezyzC134pQbB96BPPQZc9WoGpxmhz/1sxWoRd1pI9u+HZSB+kt5Fm7chrbt4crbW7cfX997
4opVtxZZHtm46YlH47F9w1HhxzsWL74peddDw+duvLhy6Bz38OsvvvrrV1/5DfA6DZjWD7uaA+0P
Zdu02Owqdk1yhVxdrnsN9xkfM0oZxnxjwnXUxbuo+c3P8JRlSUbOYHbrcDoJ2tJ4Do64u23YlkwL
8Q4/D8f62zGz1fsnTytjNlvn9pSBEUEPOV3P4iPIi85iHQIrArt4EOQLcgVDcrqRCreK3hyfBqvN
TLZNtmi0okaCA5CstWYiiwYMN9jtgi1bcBC2+55Sen6cUlY+dg5OT6dnyYHdu9Myrt14cUPmtJIl
NceOcffc1L2hbM4l1u/r5jStuelLqp0ahISn+QCykn0h2WzDBfwEHbnIcqnlFgtnoaZZ6/GWye6s
lOUOPenJLeM1Bm2aJlPrsgo84jV6rd4kWWWUxtlEt5SpzwJXxS8WSEFTGZoiVkrTTTXcXE1InC/V
6Web51ousl5qXmLdILZI66ybNZeLcemw5oj5kPXvmnPafL0lH+Ub80z55jxrsW0aKrf2SddLd3F3
Gh7Fe8le/SOGg+iQ5ojpZbD4b2s/5j82f2T9TPOF1m3lBIFoRFHQ6nSS3mDQyRaLeTBZt19AVmUw
OS+0Vmc2KS9YREkRLVZrELZdQRBNOoPBbzTZjEaTZDGbgzrJBs2RMHongwgWrbxkthhMRp1Fx3NW
o8EgSaJIL2msZmrZdLazshE3GenVHGccxI+GdMpCHe7UXaMjukGyPKRdaMGdlmssxEJzelnATUJX
6r4aP3oQn007u5ZZGNf8zxobnaD38KbXOY3OP4xuJyP31NaUb1yR+iQE4m3zx1/tnJ+ANd9mgk3H
JFfRQGEa6hKepSsPGBWDQp5NnkQYgil5/ACaZFas4KHgaeqrvi5RthS2Gyl5fJ84CbMC79K6RCm7
CZSSJ/eJSqrUql6T0+vV44fMCu0bNvzjA+Ik2uMAmkaOpEYa7Xy0nYO1syRP7tcpvIJoRWpnpJ29
echagQoh0M0wrYJthd099L6K3pzTKyt2Y5XmoNdWPi6Pw3XDzxx5rJovfezw7ikXHHpq+MAzj034
DR8YuveU5RXSMXTXq6+TtefeIVce/PIYaP+1cDAqZ5+r3nQYCbBYy6eVCXTRlk1JpZMmp9IcP0tD
fvDnzIJH2C2cEPiFEJ0ROA+TZlLgQV10hEu5aLQntuwzYGXuRvgoOgN2ecxf40c/aQ0GU5+1so8S
e9geTPfeaw/Qz6SAxl2wfxQAjQIqDRkw4blsAUls2yCPhkwi4dSNSjPu46c/NKY+faJ7E92ddj1P
fgXd/e1J9n0t8ss//yiz+9rV5qq/S5kS+/bngx/kFYx8EzQ5NLxYEwBriGCfxCNfD0VInDG8AM0e
+8LoV34W4NFAkbACNfAxVAdhG4Q5+GdoO6SzhBXJIeFn6H7N4+guSPfwCC2CkEEeR1tJBcql3/cF
vIugrBpwaNsawFvL+kFoO/R7P/8B2gthEi0D/DSo10D/10IeeISmoiScIIrIy1wG9yv+O/xZ4U3N
gFgrmaQO6U3pTe1B3R/1WwxGsOd2k8PUZnrEdNK8yfx3S9zykuUvbDYeNI3KiHIIyagYzQKaDLoh
0A5aOodbgOg3ouhrmMUc44KO5TjWyoQlFebQZdiuwjzS4bgKC8iJr1ZhDeDvUmERvYgfVmEJBUir
CmvRDnKLCuv45zmnCuvRGvEdFTagtVKVChs1B6QHVdiEGswrRuV0jXlAhUFM8mQVJnDinKrCHCqW
L1BhHnDaVFhABrlbhTWAf5UKi2iNfJ0KSyhN/oMKa1Gt/LkK60jYMkOF9Why2u7RX9OUph1XYSO3
ysapsAkVORqBEsxTrhscNzJYoBJx3MlgDSt/lMEiK9/PYInBLzBYS2XkeEOFQUbOX6owyMj5WxUG
GTk/UWGQkWuuCoOMXItVGGTkiqowyMjVp8Igo4zpKgwyygirMMgo408qDDLyPKnCICPFrMIgI6VX
hUFGeRMYrKPzytvKYD2dS95tDDaw8j0MNjE41adM55J3mMFpAFvzfsZgG8N5m8HprJ8PGWxn5X9n
sIu2zccMzqQ4+SnasihOvofBHgYHGZzL8MsZXMDgWgZPpCsjfymFJUa/CrOx8ldT2JAq38BgNpf8
PrQMbUZdKILWojBqhlRBj0FYhloZPB91og4IcRVLAavTiXoApnEYyqMMQ4GSNmhfBFANKw//P+yp
eJQyBS2FmjbUO4oTg7J5kKbGm4wq4JmEJqpQCSudCS3aIF0CbdYBDXHWagn0F4PQgzZC3AJYPVAf
Bkxasw7GaINcz9eorRyHqXwFtxKtYD3GRmdAKZgGsYLyoaco0NkDNTEIa6HHCeP6+lctxzDmAx/G
cj9iHKX8aoGW7Wz8DVBGe/6/57UCpXRGUaAkziiivFEgT3Hiaq/LQQ4KWsTaKyjAxpsP8UIYey3j
eRjwabsI9Eq53Mda0t6KvoGmlHw7YVxKUxfgbv6XWBGmVxSvj1G1bnTcqKq1E5lcOtEaleoFrKaV
aU4YqCkcpb2H1USZhi6FuJdRnZJDSpuoBGYzSuKMyyN86wFaFMAKqzqY0qQo430L0yyqax1srPH6
0qz2FWa00ZbtrEdKdyuM3856THFfYVSH2XjNqjRSNZTqmCqPMJtjqt3mUflHVS3vUiUYYbyJMc1L
zW5EQmGV/l42msJGGE/ViOQpb2i+j/XdOk4bKG4n6ys19kh5ittxlSPNqqbGvoYXhz4jjCtRSFN9
N6slvYzTVKPGdLqTrdgextE21p5SSuXZrrYaGaGZtd+ojhpVZ5pae7SHMS6sZWu4TS0d42tU5W6n
OpMow+9luTGpxpiWtjHqvlknRmxqbHQutK6d9TfWB7UNG1Rqwyr/m5m1U9RVOsKzFjb2Olaaak9X
WFSVYStbd12qjnRCTFf0RpXbqR7GrHyYySqlHQrjYbM6/yiTWhvD6WJrL6WNHaxlaibjtTs6qll0
5W9SJdPOqKG6uVFdWym70zZKRzvLjWlv/Cs7Uewr82tWx1jDeuhlnG45TzcjqBvKRzjby35XOjLD
tUy3FaYDmxhvY0zv4qP2JCV1SntqvcdVq5FaTTFVy8asZ6q2nUkkjC5n7VNU036bWe2YpqVGb2Hc
6mKrZPPoLEbG7mA2k9aHGSd61DHoGkpxMc7aj1A80nsX06F2ZjdHaCtie14c6iphLy2GfulTxLDG
W9giZp3aAaOVraU2gNoB6mASirBcDK1mOpCSeNEo5v+7I/QxjUnhRsaNsgAs/TLY7+dAmA2aR+GF
UEp3gDkQX8zKa6FkKcRUN+fCTlALz3xWugwZ4WRAwzKmTbFv0DVltDy1TlIc7VJ5Pqaj/9kuNiaZ
EYs8Iuc1rHYz4PeOjtk8attS+jy2H423linLMWZHU+s3qtrMmLqm17FeIqM2ka7WenU0uro3qrZ0
zehulBoz/m84M2I7+0atU0RdcZFRne5h9iOurue1qj5+E79GViHlWGRcL2Or+Ovjtag7INXANcwy
pqheo0qmQ+35mySUx2Z1PqdSFvnrWvH1kUdsG7ViYeaDhmHUNpXbMdWG/KuxKfeXQ8mYnd38NVlE
VC9jvM+Vst5hRlEX42xU9XT+E5krqi52jLNtI+NSS9LCOB0dt4v0jPORC0exe8bp7dje/e85Ralr
Z/2P6FXnef31MflvYNIc74eO2McxzE7ATXmovYzjtP/W0fmk6Bqv3e2qRU3xP7WqulT9GLO85+vQ
v5vRmH7MY3P/uuRGfC+650RUDy01m5S/18yk2vEVGfR8hd9jPceYt0o9khZ1H9rIfKM+NN67+t9L
f6S/HtX/i6pnnW/y4r4uxxS3xjzWZtbn19fxiMTCX+H12v8jase4/PURzt/vz6coonqxcdh7Rnqg
55OZKHUSyAcfvgyVw1lLgXgy5CbCCbEMwiREbwmWozoVcxL774UyeFJwOSqFQFtNRVPgLEAD7f3/
bK/7v98ZR+qKv8K90f1w2eauyNpwc0R5TFnWGlHmd3Z0xqFImd3Z09XZE45HOzuUrrbmIqUmHA//
b5CKaWfK0s62XloSU+Z1QLvJFRWTJkJUUqTMbGtTlkTXtcZjypJILNKzMdIysycablsSWdfbFu4Z
6baSFSpqaeWKSE+MDlBSNK1EyZ8fbe7pjHWujU9gWOMrWcH8ZSzZqyzrCbdE2sM9G5TOtf+WaqUn
si4ai0d6Ii1KtEOJA+rypcqicFwJKMvmKwvXri1Swh0tSqQtFulrBbSi0Z5gvp3resJdrZvHF0WU
mp5wX7RjHW0bBdZOVJZ0roGuF0SbWzvbwrFC2ntPtDkaVpaGeztaYA7Apmklszs74pF2SlvPZiUW
Bg4Ck6JrlZZILLquo1BJ8aUZsMJRqGzv7Ikorb3t4Q4gX2luDfeEm2EakIk2x2Ae4Q4F6jbT+UeB
5V0wwUhzJBbrhOHohMLQf29zqxJVu6KT7+2IKH3ReCtjQ3tnZwttTWEgOw6ENANTYyNl8b5IRzwa
AexmAHp7NhcpjNOdGyM9YZB1vCcSjrdDFW3Q3AvyjtHBqPQiPYyEtb1tbQAyWmH49k4YJNrR0huL
s6nG4pvbIuM5QTU1RkeJ9LRHOxhGT+cG6DYM9Df3wkApAbZEw+s6aX1fK/BcaY20dQFHOpV10Y0R
hsBUPqy0ATuU9gjwriPaDOjhrq4IsLGjOQKDpNgdpcxSIptgMu2Rts0KzC0GutNG+2iPtjH2xtVF
FFPHa4YWayJKbwxUinEz0t1Lie1tpvxX1nbClKFHmFQ8TvUEpt4TAbnHQTVATDFgGVNPyLaH14Uv
j3ZA15F4c2GKadC8JRrragtvpkPQ1h2RvlhXuAtIA5QWIDEejdGOKXpXT2d7J+utqDUe76osLu7r
6ytqVxW2qLmzvbg13t5W3B6n/6FU3B5bHaYTL6KF/2GDvkgblEZYkwULl82bM2/2zGXzFi5QFs5R
Lp43u3bB0lpl5twltbXzaxcsM+qMumWtwNYRrlEWU5kAoTCDOOPoNywxNhmqyHTOazYrmzt7actm
qm3AZ7aOUmoJysF0FOQLy68D0MPreiIRqolFSj00aw2DGnSuocsIWsbPI4ZqZx9VpwgILkI53RNp
joOc1wIfx+iiIuxcF2EoTMSj7UA0oL1reuPQNZDZCStq3ITyYiNEgSKPsmK0MdU2ZWO4rTe8BjQs
HAMNGd+6SFnewXR288gsYE6q5QL1DiuxrkhzFIzO12euABc7mLbRtuGWlijVCdDKHmaRC2lxD+Mt
W91fIaot2h6lE4JBGF5fZ8+GWEpJmT6yws4+MKi9a9qisVY6DvSVYnc7KCrQD6Lq2qyklFfl0PkD
MX7MWzs2OWq9unsjMTYM2L3mSE+HOoMelW6GHGvt7G1rgTW0MRrpS5mrr02f4oEkI2ABWsZM3Ogc
gSxmWJvjYzKmEwurVK/95m4ZyaMN1HWvdgTjhOOVFGH50pmwCeRPKyufoJRPnjZxUtmkSVrt8joo
nDR5clkZxOWl5Ur51CkVUyqMun+x6v7tYqS5YpU8tg7hqNrJDnnUKadHtM3YCBv/enAAPmFuw0jd
UuYG0UMiddpauHu4fdyPuecgHOaOcD/89kr/2yt99O2V/rdX+t9e6X97pf/tlf63V/rfXul/e6X/
7ZX+t1f6317pf3ul/+2V/v8Hr/TPO/mPwWGG/01173+lTeS8OwF2K/Av+mxjGj4uz2fzk/k6fi5/
AcQV541AbfC/6mUBWzPU9qRm34oTeA+H2Lr4122+GR79Li9K5rHvD3/tNdOHzJwDfQohCYFDHoiL
ISyEsBrCrRB2Q9AwPFrSCeEaCM9BOMNqQpxj4PbS0CAkN7Jk//q2EpYNp7INjSy7/5L6VDp/cSqt
mZdCq0yhTS5LFRfNSqV5hanU6i/pp6nOWHJ0pp2zo+Mc/fJlF8SYvIjMGCMPeoBLRwkIhNOoJSHO
uj83ULL7OY5HmCMcBp56kkc5PGC0lMzUkST5FFmRh/yFnE7VkNP7TZaS3TMvIr9HT0F4DgJHfg/P
++R9dA05iTAyQ1wNYTeE5yAcg/ApBA05Cc8JeN4j7wHWu6gYQjWE1RB2Q3gOwqcQRPIuxDL5Hf02
MIspXA2BkN9BLJPfwrR+C7GZvAPQO+QdIO2NgfKKksMMCBargMevAo5MFbDaSwbJrwY+n+AZJB/s
V4KeB2ZOIm+iBAQCg70Jnb+JFAiLIDRB6IKgAegtgN5C/RB2QngAQgKCBtq8BW3egjavQHgNwlto
EoQQhEUQJHJ8AIYZJMcGArM8M+3kF+RnyAFMfZ28zNLXyEssfZX8lKU/hzQb0lfISwPZHjRTD/UI
2siQypAWQ71AfrI/1+pJzrSQ54A9HoiLIVRDWAhhNYRbIWjIcyRnoMVjhU6eQa9ICDAH0CcsfQQ9
KKHQek8oMBt0TKFRoPICgCDarewOkFBg192QpVHgltsBolHgupsAolHg8i0A0SjQthEgGgVa1gNE
o8Cq1QDRKLBwGUAQDZL7n87N85Qv3ICVmWbSB1zqAy71AZf6EE/66IM+5ylt9w4UFADH7gkFJxR4
+o/g/mdx/xLc/yDuj+D+q3H/Ftxfhfsvw/1B3O/G/dm4P4T7n8HTgBX9OHTgvGxFyIn7X8H9T+L+
GO4P4H4/7s/F/QouDw0S78C8UpbUsmT/TLquIL1gRokZaPQCR72g1l5Y9s9BfAxCkuVCgKTkpJBd
2TTN2V9QncoXVZZ0zryQvAANXwAxvIBOQOBBQC+AGr0AndBvp5shroawGsJRCJ9CSELQAHYOEH4r
i80QF0OohrAawjUQPoWgYeR8CoGgTpXEpxhhxSrRC2mOvAAP/dd7L/GGsmS3HJQv5G51Y3M2Xpid
zCblyE5/nWC1SJZBbDz0D+M//2FE2placgu5FWWBIHaq6a0Dn2d5BvFdA4FnPDPT8Z0omwetwxUo
gP2QTkMxlp+C3BJNy5CbPAFpyYB7hYf+oDZQ6DmCTbTVIc/n7lOeT9yDBMCP3c94fqMM8njA82so
eeKQ5033DZ6fFw9KUPJsYBBDckRhqIfd0zxPvsJQt0DFPQOeq2lyyHOVe65ng5tVRFIVl8UgFzJ7
lgRWeS6E/mrcazyhGPR5yFPtvsxTlcKaQtsc8kwCEoIpsACIneBmg/qyWYfLywdxa6hQ3CWuFBeK
U8USsVD0ih4xS8wUbZJVkiWTZJB0kiRpJF4iEpJs9MfdQfrjCptGpomGpzHPYJnQmKR+NUOwRNBF
KJHG1ZG6pbNwXeJoM6pboyTOLvUNYt3iVQnBNwsnrHWobtmsxLRg3aCYXJIoD9YlxEWXrtyH8S31
UJog2wcxWrZyECdp0dZM+pfdhxHGlq03Z9I0f+vN9fXIad9Y7ay2zrBUzKn5hqhJjcf9FZDzPDgr
satu6crE41n1iRIKJLPq6xLfpf/pfRj/FZ+prTmM/4cm9SsPczPwX2uX0HJuRk19fd0gXsHwkIL/
B/BAY/6H4UnZSKF4SJGyU3j3pPD80B7wcmkCeFot8jM8v1bL8HhM8fbFcmtr9uXmMhwHuJ4MJ+ZQ
xuO84gccv5/h2PvRKwznFXs/xUnMYChuN6BkuxkKzkBuhuLGGQxlxRhKsYpywyjKDWwkDo/huFM4
xpMjOMaTgBP8T1+RWcEg3j+9vrmB/h96k682AqEpcePGVmeif42i7GuuV/8oPdC0prmVpuFIot4X
qUk0+2qUfdMbvqG6gVZP99XsQw21y1buawhFagamh6bX+sI19fvnLiorP2+sG0bHKlv0DZ0top2V
0bHmln9DdTmtnkvHKqdjldOx5obmsrEQ0/FFK/dJaFb97IZUup/odaCvTZne+ll2uWsGU97pXufV
mUfAIdmL9MH6hME3K2GEQKsmzpw4k1bBmqJVJvqn92qV8+rp3swjeK9aJUOxxTcLBeO9sV7krI3W
pN4xeEFRvJcyPBUHY//qBXW1iVC4JhZHqC5RsLQuUb141cp9ogilTXRKicqRMr2+djB5NFVYBIWV
tJDjRhFpWRUt02pVxK/Lv1dN2a8e+8kz+3EoG8Ohrp5LZNctI2AKlqn/Ln4E3CW6PcTqYYIxHMSx
kT4Y2Uj9Ny8635EQ71UhlQ9xNU21giaxEXaMvqANmKr/BdCkIMkKZW5kc3RyZWFtCmVuZG9iagoK
MTcgMCBvYmoKMTQ5MzAKZW5kb2JqCgoxOCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0Zv
bnROYW1lL0NBQUFBQStBcmlhbE1UCi9GbGFncyA0Ci9Gb250QkJveFstNjY0IC0zMjQgMjAyNyAx
MDM3XS9JdGFsaWNBbmdsZSAwCi9Bc2NlbnQgOTA1Ci9EZXNjZW50IC0yMTEKL0NhcEhlaWdodCAx
MDM3Ci9TdGVtViA4MAovRm9udEZpbGUyIDE2IDAgUgo+PgplbmRvYmoKCjE5IDAgb2JqCjw8L0xl
bmd0aCAzNTQvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicXZLLboMwEEX3fIWX6SLCJjwa
CSElJEgs+lDTfgCBIUUqxjJkwd/XM+O2UhegY/nO+MjjsKxPtR6W8NVO7QUW0Q+6szBPd9uCuMJt
0IGKRDe0i1/Rvx0bE4Su9rLOC4y17qc8D8I3tzcvdhWbQzdd4SEIX2wHdtA3sfkoL259uRvzBSPo
RcigKEQHvevz1JjnZoSQqrZ157aHZd26kr/A+2pARLRWrNJOHcymacE2+gZBLmUh8qoqAtDdv72d
5JJr33421kWVi0qZ7ArHEXGaIO+Yz8gxc4ycMO+RU+YMOSOOFfIjM+X3zCfkA58VIR+5ls4tibMU
+cRMmTMz9amII+lYSa7FsxT7Z9hHeX88S3n/Cpn9Y8p4/0dk739EZv+E+nt/9FHsn6CDYv+MMt6f
Mt4f70Gxf1ois39c0iD8jeNI8M38jFq0d2vdmOlh0XxxsoOG37dnJoNV9H0DFtaxcAplbmRzdHJl
YW0KZW5kb2JqCgoyMCAwIG9iago8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9CYXNlRm9u
dC9DQUFBQUErQXJpYWxNVAovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDMwCi9XaWR0aHNbNzUwIDY2
NiA1NTYgNTU2IDU1NiAyMjIgNTU2IDY2NiA3MjIgODMzIDcyMiA1MDAgNTAwIDMzMyAyNzcgMjc3
CjU1NiA1MDAgODMzIDU1NiA3MjIgNTU2IDUwMCA2NjYgNjEwIDYxMCA1NTYgMjc3IDcyMiAyMjIg
NTU2IF0KL0ZvbnREZXNjcmlwdG9yIDE4IDAgUgovVG9Vbmljb2RlIDE5IDAgUgo+PgplbmRvYmoK
CjIxIDAgb2JqCjw8L0YxIDE1IDAgUi9GMiAyMCAwIFIKPj4KZW5kb2JqCgoyMiAwIG9iago8PC9G
b250IDIxIDAgUgovWE9iamVjdDw8L1RyNCA0IDAgUi9UcjYgNiAwIFIvVHI4IDggMCBSPj4KL0V4
dEdTdGF0ZTw8L0VHUzUgNSAwIFIvRUdTNyA3IDAgUi9FR1M5IDkgMCBSPj4KL1Byb2NTZXRbL1BE
Ri9UZXh0L0ltYWdlQy9JbWFnZUkvSW1hZ2VCXQo+PgplbmRvYmoKCjEgMCBvYmoKPDwvVHlwZS9Q
YWdlL1BhcmVudCAxMCAwIFIvUmVzb3VyY2VzIDIyIDAgUi9NZWRpYUJveFswIDAgNTk1IDc5NF0v
R3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMiAw
IFI+PgplbmRvYmoKCjEwIDAgb2JqCjw8L1R5cGUvUGFnZXMKL1Jlc291cmNlcyAyMiAwIFIKL01l
ZGlhQm94WyAwIDAgNTk1IDc5NCBdCi9LaWRzWyAxIDAgUiBdCi9Db3VudCAxPj4KZW5kb2JqCgoy
MyAwIG9iago8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMTAgMCBSCi9PcGVuQWN0aW9uWzEgMCBSIC9Y
WVogbnVsbCBudWxsIDBdCj4+CmVuZG9iagoKMjQgMCBvYmoKPDwvQXV0aG9yPEZFRkYwMDUzMDA2
MzAwNkYwMDc0MDA3NDAwMjAwMDRCMDA2OTAwNzQwMDc0MDA2NTAwNzIwMDZEMDA2MTAwNkU+Ci9D
cmVhdG9yPEZFRkYwMDQ5MDA2RDAwNzAwMDcyMDA2NTAwNzMwMDczPgovUHJvZHVjZXI8RkVGRjAw
NEMwMDY5MDA2MjAwNzIwMDY1MDA0RjAwNjYwMDY2MDA2OTAwNjMwMDY1MDAyMDAwMzMwMDJFMDAz
ND4KL0NyZWF0aW9uRGF0ZShEOjIwMTIwMzI0MTIxNzUzLTA0JzAwJyk+PgplbmRvYmoKCnhyZWYK
MCAyNQowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMjgzNjkgMDAwMDAgbiAKMDAwMDAwMDAxOSAw
MDAwMCBuIAowMDAwMDAxOTU2IDAwMDAwIG4gCjAwMDAwMDE5NzcgMDAwMDAgbiAKMDAwMDAwMjI1
OCAwMDAwMCBuIAowMDAwMDAyMjk4IDAwMDAwIG4gCjAwMDAwMDI1ODYgMDAwMDAgbiAKMDAwMDAw
MjYyNiAwMDAwMCBuIAowMDAwMDAyOTE2IDAwMDAwIG4gCjAwMDAwMjg1MTMgMDAwMDAgbiAKMDAw
MDAwMjk1NiAwMDAwMCBuIAowMDAwMDExNTQ3IDAwMDAwIG4gCjAwMDAwMTE1NjkgMDAwMDAgbiAK
MDAwMDAxMTc3MCAwMDAwMCBuIAowMDAwMDEyMDYxIDAwMDAwIG4gCjAwMDAwMTIyMjkgMDAwMDAg
biAKMDAwMDAyNzI0NiAwMDAwMCBuIAowMDAwMDI3MjY5IDAwMDAwIG4gCjAwMDAwMjc0NjAgMDAw
MDAgbiAKMDAwMDAyNzg4NCAwMDAwMCBuIAowMDAwMDI4MTU5IDAwMDAwIG4gCjAwMDAwMjgyMDIg
MDAwMDAgbiAKMDAwMDAyODYxMyAwMDAwMCBuIAowMDAwMDI4Njk4IDAwMDAwIG4gCnRyYWlsZXIK
PDwvU2l6ZSAyNS9Sb290IDIzIDAgUgovSW5mbyAyNCAwIFIKL0lEIFsgPEM3ODI4NUVEQUQwM0E3
RkQwQjY0RDQ4RDYzMTU2ODcxPgo8Qzc4Mjg1RURBRDAzQTdGRDBCNjRENDhENjMxNTY4NzE+IF0K
L0RvY0NoZWNrc3VtIC9DRDlEM0VEM0Q0N0RFRjYzRkYzREZBQTQ3NTEwODhENQo+PgpzdGFydHhy
ZWYKMjg5NTEKJSVFT0YK

--nextPart1340414.4ZtAWlEGmJ--


From vesely@tana.it  Sat Mar 24 09:43:25 2012
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 C3CBC21F85C9 for ; Sat, 24 Mar 2012 09:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level: 
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9OGZA0F8kyl for ; Sat, 24 Mar 2012 09:43:24 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 13D8721F8572 for ; Sat, 24 Mar 2012 09:43:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332607403; bh=zYesHaVnB2cBpQCo2IQhCCweFXOdGxE6u91eX7UcZdM=; l=975; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=LVOUitrHdku0QGAdMnYoucrbou4bykjRqqFmsP13Ik5DVQPFPeSzKzwFdEK5jvSr4 N4rajz9xu8+cCO85AV4y77Bzb6F3Ae7RVslmxBeo6XTc01Hswt+C52V+neCcTjGZuO 754/0saO8SvVTY4/kTK8kck347bLD2IFNf/237bA=
Received: from [10.216.6.61] ([93.158.42.29]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 24 Mar 2012 17:43:22 +0100 id 00000000005DC042.000000004F6DF9AA.00006846
Message-ID: <4F6DF992.10605@tana.it>
Date: Sat, 24 Mar 2012 17:42:58 +0100
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120324090349.15462.qmail@joyce.lan>
In-Reply-To: <20120324090349.15462.qmail@joyce.lan>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and	helo	identities
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 Mar 2012 16:43:25 -0000

On 24.03.2012 10:03, John Levine wrote:
>>> Yeah; really, none of those bullets sound attractive.  Would it be
>>> possible to check the feasibility of updating just a little bit of SMTP?
> 
> I think I know Klensin well enough to channel his answer to that
> question.  To summarize three pages of detailed response: absolutely
> none.

Probably yes.  Yet, those three pages may come handy if the WG needs to
justify a decision like banning reject on fail.

> It is a specific design feature of SMTP that the contents of a message
> are independent of the path it takes.

Not the content, just a piece of the envelope.  A varying return-path is not
such a novelty, after all.

> The only reason SPF works at all is that a large fraction of mail
> happens to take a predictable path.  But not all of it does, and the
> part that doesn't can't be wished away.

Thus, with SPF being a standard part of mail, we can say mail works in a
large fraction of cases.

From dotis@mail-abuse.org  Sat Mar 24 16:21:28 2012
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 9A1A421F84DF for ; Sat, 24 Mar 2012 16:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.438
X-Spam-Level: 
X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 HkfbLenZqdAW for ; Sat, 24 Mar 2012 16:21:27 -0700 (PDT)
Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFA621F84B6 for ; Sat, 24 Mar 2012 16:21:26 -0700 (PDT)
Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 18F6217402F4 for ; Sat, 24 Mar 2012 23:21:26 +0000 (UTC)
Message-ID: <4F6E56F5.5090209@mail-abuse.org>
Date: Sat, 24 Mar 2012 16:21:25 -0700
From: Douglas Otis 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it>
In-Reply-To: <4F6DF992.10605@tana.it>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and	helo	identities
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 Mar 2012 23:21:28 -0000

On 3/24/12 9:42 AM, Alessandro Vesely wrote:
> > The only reason SPF works at all is that a large fraction of mail
> > happens to take a predictable path. But not all of it does, and
> > the part that doesn't can't be wished away.
>
>  Thus, with SPF being a standard part of mail, we can say mail works
>  in a large fraction of cases.

Dear Alessandro,

A piece missing in SMTP is a method to authenticate outbound and 
incoming servers, but email operations work well and likely better 
without SPF.  Dropping NDNs without an SPF pass lowers intended delivery 
integrity in a way not compliant with SMTP.

Dealing with NDNs containing spoofed return paths can be (and largely 
have been) supplanted by vetting prior to acceptance.  Domains that 
don't may find email not working as desired and their MTA's increasingly 
flooded with abuse.  DKIM provides more reliable defenses against 
phishing, where a return path is seldom visible anyway.

SPF may help facilitate the determination of IP address's reputation 
interference.  SPF may help facilitate white-listing of problematic 
domains that require too much support otherwise, but only when "i" and 
"l" macros have not been used.  Responding to problems created for even 
a small fraction of email is why SPF as a basis for acceptance or 
rejection is not practical for large operations who provide services for 
the majority of email.

Unfortunately, SPF remains problematic even for the EHLO such as what 
can be done for email coming from 10.64.0.0/10?

Regards,
Douglas Otis



From dotis@mail-abuse.org  Sat Mar 24 16:24:14 2012
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 5C2C421E802B for ; Sat, 24 Mar 2012 16:24:14 -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 aMlHIzSaAfV4 for ; Sat, 24 Mar 2012 16:24:14 -0700 (PDT)
Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id F08DA21E8028 for ; Sat, 24 Mar 2012 16:24:13 -0700 (PDT)
Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id D9FF817402B6 for ; Sat, 24 Mar 2012 23:24:13 +0000 (UTC)
Message-ID: <4F6E579D.70001@mail-abuse.org>
Date: Sat, 24 Mar 2012 16:24:13 -0700
From: Douglas Otis 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <4F6E56F5.5090209@mail-abuse.org>
In-Reply-To: <4F6E56F5.5090209@mail-abuse.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and	helo	identities
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 Mar 2012 23:24:14 -0000

On 3/24/12 4:21 PM, Douglas Otis wrote:
> Unfortunately, SPF remains problematic even for the EHLO such as what 
> can be done for email coming from 10.64.0.0/10? 
Correction: 100.64.0.0/10

Regards,
Douglas Otis

From vesely@tana.it  Sun Mar 25 00:56:38 2012
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 557F321F8581 for ; Sun, 25 Mar 2012 00:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level: 
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJH0XyYVh4-Z for ; Sun, 25 Mar 2012 00:56:37 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFE021F8573 for ; Sun, 25 Mar 2012 00:56:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332662194; bh=Geivj9vot2xg4oLgBi0qTx5pnrx0iEaOWRevjGNYNUQ=; l=1333; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=CHaQKH7iJk1OynKAHxhDsvmKk4RkvUYQKQVdiqvU2u/ZVtut+Pr51VDbpTnO3B4yd vVqmLC7AnT8dTuHdAqn7hNZbu33THCSCWo3DNVzBX9KpuVIi7k3Hrr1IidjuAu8YX3 c/NN52f14LpaNIcDc5SdNQZO7cT0ulTg+kRc4/FQ=
Received: from [10.216.7.9] ([93.158.46.61]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 25 Mar 2012 09:56:33 +0200 id 00000000005DC039.000000004F6ECFB1.0000343B
Message-ID: <4F6ECFA4.2030707@tana.it>
Date: Sun, 25 Mar 2012 09:56:20 +0200
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120315175753.21172.qmail@joyce.lan> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> <2744445.3m1Dyi5C5m@scott-latitude-e6320>
In-Reply-To: <2744445.3m1Dyi5C5m@scott-latitude-e6320>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo	identities
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 Mar 2012 07:56:38 -0000

On 24.03.2012 17:31, Scott Kitterman wrote:
> The second one is the traditional forwarder case.  In this case, the forwarder 
> is an agent for the receiver (the sender has no idea their mail will be 
> forwarded, it's the receiver that determines this).  The forwarder is 
> effectively part of the receiver's ADMD.  The case is generically the same 
> though.  SPF should be checked when it passes from the sender's ADMD to the 
> receiver's.  The reason this case is so hard is that many receivers don't 
> understand the boundaries of their ADMD to include this and argue they 
> shouldn't have to.

To include them, receivers should at least know.

There is no protocol whereby a forwarder can tell to a receiver that it is
going to forward mail.  (We may call it "consent-exchange protocol", as it
implies that the owners of the target addresses grant their consent for such
use; this is a legal requirement in some countries.)  Thus, operators on the
receiving side have to collect the relevant data by unspecified means; that
is to say, manual and fallible methods, irrespectively of the system size.

Of course, pretending to be a legitimate forwarder is a common attack path...

It would be illuminating to be able to estimate what fraction of legitimate
mail is (or fails to be) transferred that way.  Any report?

From msk@cloudmark.com  Sun Mar 25 01:16:16 2012
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 E8EF621F85CD for ; Sun, 25 Mar 2012 01:16:15 -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 2UQCiuXWJ7lB for ; Sun, 25 Mar 2012 01:16:14 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 899C521F85C3 for ; Sun, 25 Mar 2012 01:16:14 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Sun, 25 Mar 2012 01:16:13 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding	and	helo identities
Thread-Index: AQHNCdtnqIMs1vadLE2PffDRfHoLgpZ59eqw
Date: Sun, 25 Mar 2012 08:16:13 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039280B7ABD@exch-mbx901.corp.cloudmark.com>
References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320>	<4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320>	<4F6C4903.8090901@tana.it> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it> <9452079D1A51524AA5749AD23E003928098E77@exch-mbx901.corp.cloudmark.com> <4F6CD594.1090909@tana.it> <9452079D1A51524AA5749AD23E0039280995A3@exch-mbx901.corp.cloudmark.com> <4F6DF691.8080205@tana.it>
In-Reply-To: <4F6DF691.8080205@tana.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.129.23.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding	and	helo	identities
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 Mar 2012 08:16:16 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of Alessandro Vesely
> Sent: Saturday, March 24, 2012 9:30 AM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident=
ities
>=20
> > I would bet real money that this is a non-starter.  By doing so, you
> > would declare a big piece of the deployed email infrastructure non-
> > compliant.
>=20
> Isn't it a small piece?

I don't have such measurements.  Do they even exist?

> > If I may paraphrase John Levine about MLMs: Forwarders have been doing
> > what they do for decades without complaints, so who are we to suddenly
> > tell them that they're wrong?
>=20
> Not suddenly, every user and operator found out that email is too
> easily abused.  IMHO, it is the smallest change that is compatible with
> plain reject on fail.

Still, you're proposing adding a new requirement onto the entirety of a dec=
ades-old infrastructure.  I imagine for that trick to work, the benefit wou=
ld have to be pretty enormous, and a huge majority would have to be on boar=
d with adopting it.

-MSK

From msk@cloudmark.com  Sun Mar 25 01:16:16 2012
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 302EA21F85C3 for ; Sun, 25 Mar 2012 01:16:16 -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 wYsFRk8UAmdf for ; Sun, 25 Mar 2012 01:16:15 -0700 (PDT)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF0121F85C9 for ; Sun, 25 Mar 2012 01:16:15 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Sun, 25 Mar 2012 01:16:14 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding	and	helo identities
Thread-Index: AQHNCd08azdwq0k3Q0qc13vRnug09pZ59ogQ
Date: Sun, 25 Mar 2012 08:16:14 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com>
References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it>
In-Reply-To: <4F6DF992.10605@tana.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.129.23.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding	and	helo	identities
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 Mar 2012 08:16:16 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of Alessandro Vesely
> Sent: Saturday, March 24, 2012 9:43 AM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident=
ities
>=20
> > The only reason SPF works at all is that a large fraction of mail
> > happens to take a predictable path.  But not all of it does, and the
> > part that doesn't can't be wished away.
>=20
> Thus, with SPF being a standard part of mail, we can say mail works in
> a large fraction of cases.

SPF isn't a standard part of mail.  It's an optional add-on.

-MSK

From vesely@tana.it  Sun Mar 25 03:14:27 2012
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 4B13521F854E for ; Sun, 25 Mar 2012 03:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level: 
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ed2a0D6XASYO for ; Sun, 25 Mar 2012 03:14:26 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id BBD2B21F852B for ; Sun, 25 Mar 2012 03:14:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332670464; bh=eExKdhk6xM+lnBXY3lRL2Ibzj4Zv6koOMw00cWx3PWg=; l=1062; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=QMUCEIDKvz98FcpC6djGG9Urt0GuClpnKN16BT2zoX/E8kAZITicxLA4Dbsroo4G9 R7Yzrt9HBMpaUYqm0+Iz/R5JcDfjFwLgzNWhAw0T6+jEmsmjmIYuCttdjnmqjuhcyY B7by008PY5GzBSKjLPaXmAH+wbfzjhatN0jEuy90=
Received: from [130.129.16.89] (dhcp-1059.meeting.ietf.org [130.129.16.89]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 25 Mar 2012 12:14:24 +0200 id 00000000005DC039.000000004F6EF000.00005212
Message-ID: <4F6EEFF5.3070306@tana.it>
Date: Sun, 25 Mar 2012 12:14:13 +0200
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com>
In-Reply-To: <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding	and	helo	identities
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 Mar 2012 10:14:27 -0000

On 25.03.2012 10:16, Murray S. Kucherawy wrote:
>
>>> The only reason SPF works at all is that a large fraction of mail
>>> happens to take a predictable path.  But not all of it does, and the
>>> part that doesn't can't be wished away.
>>
>> Thus, with SPF being a standard part of mail, we can say mail works in
>> a large fraction of cases.
> 
> SPF isn't a standard part of mail.  It's an optional add-on.

Until we hold that reject-on-fail is valid, SPF is less optional than it
would seem at a first glance, because it affects a mail operation that used
to be possible without it.  A sender who does not opt for SPF can have its
forwarded messages bounced because both the originator and the target opted
to implement SPF in such a way to break that operation.  In this respect, SPF
has changed SMTP already, whether we're gonna document that as an update or not.

What's worse is that there's no guidance on how to avoid such incidents.  A
protocol worth its salt should allow to determine what parties are at fault
in case of malfunction.

From msk@cloudmark.com  Sun Mar 25 22:59:42 2012
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 336E721E8082 for ; Sun, 25 Mar 2012 22:59:42 -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=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH-pv5C87FPP for ; Sun, 25 Mar 2012 22:59:41 -0700 (PDT)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 63F2D21E8064 for ; Sun, 25 Mar 2012 22:59:38 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Sun, 25 Mar 2012 22:59:37 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: Deployment document?
Thread-Index: AQHNCxWfWPz9zvDtzkafJsdTdh/Aew==
Date: Mon, 26 Mar 2012 05:59:36 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039280B8A8A@exch-mbx901.corp.cloudmark.com>
References: <20120315175753.21172.qmail@joyce.lan> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> <2744445.3m1Dyi5C5m@scott-latitude-e6320>
In-Reply-To: <2744445.3m1Dyi5C5m@scott-latitude-e6320>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.22.1.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [spfbis] Deployment document?
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 Mar 2012 05:59:42 -0000

Given Scott's last message, I think there's been enough discussion about de=
ployment advice, caveats, etc., that we should decide whether there's enoug=
h material to warrant its own document.  If the volume of such pedagogy is =
significant, then packing it all into a really big appendix of RFC4408bis m=
ight be considered poor form.

It's obviously not one of our deliverables in the current charter, but I su=
spect it wouldn't be a big deal to add it since it doesn't affect the const=
raints on protocol changes.

Co-chairs, your thoughts?

-MSK

From msk@cloudmark.com  Sun Mar 25 23:04:37 2012
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 EB67D21F848E for ; Sun, 25 Mar 2012 23:04:37 -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=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qANQo4uiqNPT for ; Sun, 25 Mar 2012 23:04:37 -0700 (PDT)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 82E2E21F848C for ; Sun, 25 Mar 2012 23:04:37 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Sun, 25 Mar 2012 23:04:37 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and	helo identities
Thread-Index: AQHNCdulhj3gxUJwYUuSDjFQ0mDkSJZ8GIxw
Date: Mon, 26 Mar 2012 06:04:35 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039280B8AAD@exch-mbx901.corp.cloudmark.com>
References: <20120315175753.21172.qmail@joyce.lan> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> <2744445.3m1Dyi5C5m@scott-latitude-e6320>
In-Reply-To: <2744445.3m1Dyi5C5m@scott-latitude-e6320>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.22.1.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and	helo	identities
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 Mar 2012 06:04:38 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of Scott Kitterman
> Sent: Saturday, March 24, 2012 9:32 AM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident=
ities
>=20
> Finally, in the mailing list case, it's really very easy as normal
> mailing lists treat a submission as a completed delivery and then make
> a new message to the list.  In the first transaction they are the
> receiving ADMD and in the second they are the sending.  Lists are also
> different in that, unlike forwarding, both the sender and the receiver
> are party to the list (assuming appropriate controls to avoid random
> posts are in place) and so the list manager is an agent for both.

Do most list servers these days replace the envelope sender?  I can't remem=
ber.

Perhaps predictably, I want to avoid us telling MLMs what they have to star=
t doing in terms of what they need to do to accommodate SPF.

From WebMaster@Commerco.Net  Sun Mar 25 23:10:29 2012
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 2B35F21E8064 for ; Sun, 25 Mar 2012 23:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.927
X-Spam-Level: 
X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.061,  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 zlPihp4-YXKp for ; Sun, 25 Mar 2012 23:10:28 -0700 (PDT)
Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7D96C21E8063 for ; Sun, 25 Mar 2012 23:10:28 -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:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=mMS24CCdnXNvCVfbgC1LEeOG/hMc3cr3tbXiFMrhGgZOV/xfG04wwZhusTxbM6bjVS+fq0QjqreteoBGxOqMdeAueBohGQONDtqo+SG33YJ/dhiZ2nHn+N4mFKaCDws01qP1JCvfXp9Bpwv3QU2KUxjZwIZRX0n9vJy+rkIvFdc=
Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Mon, 26 Mar 2012 06:10:26 +0000
Message-ID: <4F70084C.5020304@Commerco.Net>
Date: Mon, 26 Mar 2012 00:10:20 -0600
From: Commerco WebMaster 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120315175753.21172.qmail@joyce.lan> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> <2744445.3m1Dyi5C5m@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280B8A8A@exch-mbx901.corp.cloudmark.com>
In-Reply-To: <9452079D1A51524AA5749AD23E0039280B8A8A@exch-mbx901.corp.cloudmark.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-FromIP: 71.216.84.59
X-FromCountry: US
Subject: Re: [spfbis] Deployment document?
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 Mar 2012 06:10:29 -0000

On 3/25/2012 11:59 PM, Murray S. Kucherawy wrote:
> Given Scott's last message, I think there's been enough discussion about deployment advice, caveats, etc., that we should decide whether there's enough material to warrant its own document.  If the volume of such pedagogy is significant, then packing it all into a really big appendix of RFC4408bis might be considered poor form.
>
> It's obviously not one of our deliverables in the current charter, but I suspect it wouldn't be a big deal to add it since it doesn't affect the constraints on protocol changes.
>
> Co-chairs, your thoughts?
>
> -MSK
> _______________________________________________

+1

Despite my not being a co-chair, I think the idea seems sound.  Where do 
you suggest that this kind of information reside?  Is there a precedent 
for doing this from other RFCs?  If so, then it seems a template for 
creating such an adjunct document exists.

I would submit that such a collection of deployment, caveats, etc., 
information discussed so far could logically rest somewhere within 
OpenSPF.Org

Alan M.


From spf2@kitterman.com  Sun Mar 25 23:27:11 2012
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 EBE6721F845E for ; Sun, 25 Mar 2012 23:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.469
X-Spam-Level: 
X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, SARE_SUB_ENC_UTF8x2=0.246]
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 k28Ua-rWer2U for ; Sun, 25 Mar 2012 23:27:11 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE7321F8458 for ; Sun, 25 Mar 2012 23:27:11 -0700 (PDT)
Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 4FE55D04063; Mon, 26 Mar 2012 01:27:10 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332743230; bh=Kw6wOloChbx5cvRWhDJSOoci3uK2Rn6Dxc80XmTCNOs=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=XVPBxA6W5oY5nLUA4pectaC1TcBcmKqOWx2ZtnxOKRK3Adx/+r2so6K90z9Sxt/Rl 0UZ6/TfzCqFSLt0vrfTFRDRt3eXzxYHISL4LiwBe2Q5oFVphMZbXn0/dcT49rysHcx +ot9IhtNY0n734BpcezvSgY1dXmwU01fh3KGpNpM=
Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 7D187D0403E;  Mon, 26 Mar 2012 01:27:06 -0500 (CDT)
References: <20120315175753.21172.qmail@joyce.lan> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> <2744445.3m1Dyi5C5m@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280B8AAD@exch-mbx901.corp.cloudmark.com>
User-Agent: K-9 Mail for Android
In-Reply-To: <9452079D1A51524AA5749AD23E0039280B8AAD@exch-mbx901.corp.cloudmark.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Scott Kitterman 
Date: Mon, 26 Mar 2012 02:27:05 -0400
To: "spfbis@ietf.org" 
Message-ID: <8a0794df-8659-4f39-b340-1517ee2bd416@email.android.com>
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] =?utf-8?q?=2312=3A_RFC_4408_Section_9_-_Forwarding=09and?= =?utf-8?q?=09helo=09identities?=
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 Mar 2012 06:27:12 -0000

"Murray S. Kucherawy"  wrote:

>> -----Original Message-----
>> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On
>Behalf Of Scott Kitterman
>> Sent: Saturday, March 24, 2012 9:32 AM
>> To: spfbis@ietf.org
>> Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo
>identities
>> 
>> Finally, in the mailing list case, it's really very easy as normal
>> mailing lists treat a submission as a completed delivery and then
>make
>> a new message to the list.  In the first transaction they are the
>> receiving ADMD and in the second they are the sending.  Lists are
>also
>> different in that, unlike forwarding, both the sender and the
>receiver
>> are party to the list (assuming appropriate controls to avoid random
>> posts are in place) and so the list manager is an agent for both.
>
>Do most list servers these days replace the envelope sender?  I can't
>remember.

AFAIK, they do.

Scott K


From johnl@iecc.com  Mon Mar 26 01:23:04 2012
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 E397721F8478 for ; Mon, 26 Mar 2012 01:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.394
X-Spam-Level: 
X-Spam-Status: No, score=-110.394 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 TjwSR6Lz3LSi for ; Mon, 26 Mar 2012 01:23:02 -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 E844E21F855A for ; Mon, 26 Mar 2012 01:23:00 -0700 (PDT)
Received: (qmail 10706 invoked from network); 26 Mar 2012 08:23:00 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Mar 2012 08:23:00 -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:vbr-info; s=4f702764.xn--btvx9d.k1203; i=johnl@user.iecc.com; bh=q3szNjsSzBnYEO2EsMB6/sMfLGyAsMa9qoFl5FOJQxo=; b=JlNLhXw/qkd8OtgkUIq8JGdOsNhCzoU386JUToXinHEKRlaDMkfRTgR2rXxU3FOUgUIkUCGvCFablIOCG/FgjwkW274TuThevh4PXYE4SFKssefJCyudRoKkuB+cfDM6lB+aYAgyhBbiaCESpr95Z9aetrr8Ulwq9O55J4Loo18=
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:vbr-info; s=4f702764.xn--btvx9d.k1203; olt=johnl@user.iecc.com; bh=q3szNjsSzBnYEO2EsMB6/sMfLGyAsMa9qoFl5FOJQxo=; b=rnGlI0wmgwPPpKc7UVQbuqPsNCJ0CE0LslLo+ZoNLfWCTy/rUfKkkjz6f80/Nk47aRWwEdJrMoAE6SJznFr0hm9MNj/X8VkDR0trj4XJaL34hNrv7lxaXOUEkOgi9dCt2+5yjwHvY0+edB2HmbDJQCTDdbd1mTyADAeegVetd7I=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 26 Mar 2012 08:22:37 -0000
Message-ID: <20120326082237.24546.qmail@joyce.lan>
From: "John Levine" 
To: spfbis@ietf.org
In-Reply-To: <9452079D1A51524AA5749AD23E0039280B8AAD@exch-mbx901.corp.cloudmark.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Cc: msk@cloudmark.com
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and	helo	identities
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 Mar 2012 08:23:04 -0000

>Do most list servers these days replace the envelope sender?  I can't remember.

They all do.  They have to, if they're going to do bounce management.

MLM's haven't had any trouble with SPF other than in faulty client
implementations that attempt to correlate some bit of the message
headers with the bounce address.

R's,
John

From sm@elandsys.com  Mon Mar 26 01:32:05 2012
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 6495521F8532 for ; Mon, 26 Mar 2012 01:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.595
X-Spam-Level: 
X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 YZNAr5pHzThS for ; Mon, 26 Mar 2012 01:32:03 -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 3732C21F8523 for ; Mon, 26 Mar 2012 01:32:03 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.235.181]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2Q8VmPQ014528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2012 01:31:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1332750720; i=@elandsys.com; bh=2bV16T09I83bU3h00PRGptNaLliV7L7dpRNX1F8fvEM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4quivMWYXFpETLm5WFwTvu/TanyAg20fgVymyDArS1rbxIjEPM1v1xX7wPeXhqocg 11U10ap+3insqdVd8TdIgJDHyGswuCeAsO/EAAIIUzof/nLScSP3GIZPuLOV8AARWK XvpuBAC7AE9fJd9aaN+lwvcZm3g7cCGieGSVeDYA=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1332750720; i=@elandsys.com; bh=2bV16T09I83bU3h00PRGptNaLliV7L7dpRNX1F8fvEM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pBC3rVsWVPMzePZFxWxYWeNP9DjWaGUI4yyVTj/lf7aZ8Na4YglTyEqLKfW0beQ8S bgBzSxoB2Cg2NO3Gfi3nnqK02wOSWtCtm51lreJxHXN3O8jr2vBUNCxZjgbqD1rXjl OJMy67beDg3b+CTU7bh5svpnHxqWJyCtOcnA8e8Q=
Message-Id: <6.2.5.6.2.20120326012359.099d33e0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 26 Mar 2012 01:29:22 -0700
To: "Murray S. Kucherawy" 
From: S Moonesamy 
In-Reply-To: <9452079D1A51524AA5749AD23E0039280B8A8A@exch-mbx901.corp.cl oudmark.com>
References: <20120315175753.21172.qmail@joyce.lan> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> <2744445.3m1Dyi5C5m@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280B8A8A@exch-mbx901.corp.cloudmark.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: spfbis@ietf.org
Subject: Re: [spfbis] Deployment document?
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 Mar 2012 08:32:05 -0000

Hi Murray,
At 22:59 25-03-2012, Murray S. Kucherawy wrote:
>Given Scott's last message, I think there's been enough discussion 
>about deployment advice, caveats, etc., that we should decide 
>whether there's enough material to warrant its own document.  If the 
>volume of such pedagogy is significant, then packing it all into a 
>really big appendix of RFC4408bis might be considered poor form.
>
>It's obviously not one of our deliverables in the current charter, 
>but I suspect it wouldn't be a big deal to add it since it doesn't 
>affect the constraints on protocol changes.

Could you please bring this up during the WG session on Friday?  As 
the Responsible AD will be in the room, it should be easy to resolve 
the deliverable angle.

Could the WG please provide feedback about this so that we don't get 
into a long discussion on Friday?

Regards,
S. Moonesamy
SPFBIS WG co-chair 


From spf2@kitterman.com  Mon Mar 26 03:53:26 2012
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 4867E21F859F for ; Mon, 26 Mar 2012 03:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.591
X-Spam-Level: 
X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008,  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 5fo8HstDv5Ou for ; Mon, 26 Mar 2012 03:53:25 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 032A421F859B for ; Mon, 26 Mar 2012 03:53:24 -0700 (PDT)
Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 40456D04063; Mon, 26 Mar 2012 05:53:24 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332759204; bh=xIDVm/GWMBTCszAJlKCfH2pXw3AIuCfzzIIvJl82Y6g=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=DYIQlJKkcKjoA3ih7W3f54/6/mb5DlDAFxQAXv9UD7fvh0E+bJtUSYpyWeHk8MKCi dN7MyKbcDQXlfC7MB3TY2WF7OfZwzPWpnHRu/+6uZZDGeanVtkVDEqaUXLnOqG7jSp nbIkaiEj+aMJ/9/51lUvBW8V+1krRxjkBJD1yqmg=
Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id F3A24D0403E;  Mon, 26 Mar 2012 05:53:23 -0500 (CDT)
References: <20120315175753.21172.qmail@joyce.lan> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> <2744445.3m1Dyi5C5m@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280B8A8A@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120326012359.099d33e0@resistor.net>
User-Agent: K-9 Mail for Android
In-Reply-To: <6.2.5.6.2.20120326012359.099d33e0@resistor.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Scott Kitterman 
Date: Mon, 26 Mar 2012 06:53:16 -0400
To: spfbis@ietf.org
Message-ID: <2a193857-dd68-4354-867b-5cc4f57e1fbe@email.android.com>
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] Deployment document?
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 Mar 2012 10:53:26 -0000

S Moonesamy  wrote:

>Hi Murray,
>At 22:59 25-03-2012, Murray S. Kucherawy wrote:
>>Given Scott's last message, I think there's been enough discussion 
>>about deployment advice, caveats, etc., that we should decide 
>>whether there's enough material to warrant its own document.  If the 
>>volume of such pedagogy is significant, then packing it all into a 
>>really big appendix of RFC4408bis might be considered poor form.
>>
>>It's obviously not one of our deliverables in the current charter, 
>>but I suspect it wouldn't be a big deal to add it since it doesn't 
>>affect the constraints on protocol changes.
>
>Could you please bring this up during the WG session on Friday?  As 
>the Responsible AD will be in the room, it should be easy to resolve 
>the deliverable angle.
>
>Could the WG please provide feedback about this so that we don't get 
>into a long discussion on Friday?

I am not convinced of the need. I think it's generally better to keep it in one document.

Scott K

From msk@cloudmark.com  Mon Mar 26 04:22:52 2012
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 25F5121F85EA for ; Mon, 26 Mar 2012 04:22:52 -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=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EjYJYiw4F59 for ; Mon, 26 Mar 2012 04:22:51 -0700 (PDT)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5D021F85A4 for ; Mon, 26 Mar 2012 04:22:51 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 04:22:50 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] Deployment document?
Thread-Index: AQHNCxWfWPz9zvDtzkafJsdTdh/Ae5Z8jWsA///hXSA=
Date: Mon, 26 Mar 2012 11:22:50 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039280B8FD6@exch-mbx901.corp.cloudmark.com>
References: <20120315175753.21172.qmail@joyce.lan> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> <2744445.3m1Dyi5C5m@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280B8A8A@exch-mbx901.corp.cloudmark.com> <4F70084C.5020304@Commerco.Net>
In-Reply-To: <4F70084C.5020304@Commerco.Net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.22.1.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] Deployment document?
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 Mar 2012 11:22:52 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of Commerco WebMaster
> Sent: Sunday, March 25, 2012 11:10 PM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] Deployment document?
>=20
> Despite my not being a co-chair, I think the idea seems sound.  Where
> do you suggest that this kind of information reside?  Is there a
> precedent for doing this from other RFCs?  If so, then it seems a
> template for creating such an adjunct document exists.

DKIM has a deployment document that's separate from the protocol specificat=
ion, for example.  They also did an overview document.

I'm sensitive to Scott's concern that it all be in one document.  There's s=
ome question about whether anyone reading RFC4408bis would even think to lo=
ok for separate documents.  We could, of course, do them as a cluster, thou=
gh that will have the side effect of delaying publication until both are re=
ady.

I'd be fine with doing this in RFC4408bis itself unless the volume of it ge=
ts too big to fit practically in an appendix.  At that point I think it sho=
uld be in its own Informational.

As SM requested, I'll bring it up Friday.

-MSK

From msk@cloudmark.com  Mon Mar 26 04:56:34 2012
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 E8ABA21F8670 for ; Mon, 26 Mar 2012 04:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.3
X-Spam-Level: 
X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, J_CHICKENPOX_93=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 9U86F2yRUN0n for ; Mon, 26 Mar 2012 04:56:34 -0700 (PDT)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7775121F860E for ; Mon, 26 Mar 2012 04:56:34 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 04:56:34 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: RFC 6577 on Authentication-Results Registration Update for Sender	Policy Framework (SPF) Results
Thread-Index: AQHNC0YoFUciMvuAFUyZ/S8T5wgeSJZ8eElA
Date: Mon, 26 Mar 2012 11:56:33 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039280B950C@exch-mbx901.corp.cloudmark.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [172.22.1.150]
Content-Type: multipart/mixed; boundary="_002_9452079D1A51524AA5749AD23E0039280B950Cexchmbx901corpclo_"
MIME-Version: 1.0
Subject: [spfbis] FW: RFC 6577 on Authentication-Results Registration Update for Sender	Policy Framework (SPF) Results
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 Mar 2012 11:56:35 -0000

--_002_9452079D1A51524AA5749AD23E0039280B950Cexchmbx901corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

FYI, this fixes the "hardfail" bug in Authentication-Results to match what =
RFC4408 said.

-MSK

--_002_9452079D1A51524AA5749AD23E0039280B950Cexchmbx901corpclo_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Mon, 26 Mar 2012 11:56:31 GMT";
	modification-date="Mon, 26 Mar 2012 11:56:31 GMT"

Received: from mail.cloudmark.com (208.83.136.59) by ht1.cloudmark.com
 (172.22.10.80) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 26 Mar
 2012 04:47:00 -0700
Received: from cmgw1.cloudmark.com ?(cmgw1.cloudmark.com [208.83.136.25])
        by mail.cloudmark.com (8.14.3/8.14.3) with ESMTP id q2QBkTLl027234
        for ; Mon, 26 Mar 2012 04:47:00 -0700
        (envelope-from ietf-announce-bounces@ietf.org)
Received: from mail.ietf.org ([12.22.58.30])	by mail.cloudmark.com with
 bizsmtp	id qBn61i0010f7nZY01Bn6Sh; Mon, 26 Mar 2012 04:47:06 -0700
Received: from ietfa.amsl.com (localhost [127.0.0.1])	by ietfa.amsl.com
 (Postfix) with ESMTP id C473B21F8688;	Mon, 26 Mar 2012 04:40:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])	by ietfa.amsl.com (Postfix)
 with ESMTP id 2187D21F8690	for ;	Mon, 26 Mar
 2012 04:40:10 -0700 (PDT)
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 eyb2YmSPFN4u for
 ;	Mon, 26 Mar 2012 04:40:09 -0700 (PDT)
Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47])	by ietfa.amsl.com
 (Postfix) with ESMTP id 8FB7021F8688	for ; Mon, 26
 Mar 2012 04:40:09 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30)	id A3586B1E01C; Mon, 26
 Mar 2012 04:38:52 -0700 (PDT)
From: "rfc-editor@rfc-editor.org" 
To: "ietf-announce@ietf.org" ,
	"rfc-dist@rfc-editor.org" 
CC: "rfc-editor@rfc-editor.org" 
Subject: RFC 6577 on Authentication-Results Registration Update for Sender
	Policy Framework (SPF) Results
Thread-Topic: RFC 6577 on Authentication-Results Registration Update for
 Sender	Policy Framework (SPF) Results
Thread-Index: AQHNC0YoFUciMvuAFUyZ/S8T5wgeSA==
Sender: "ietf-announce-bounces@ietf.org" 
Date: Mon, 26 Mar 2012 11:38:52 +0000
Message-ID: <20120326113852.A3586B1E01C@rfc-editor.org>
List-Help: 
List-Subscribe: ,
	
List-Unsubscribe: ,
	
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: EXCH-HTCAS901.corp.cloudmark.com
X-MS-Has-Attach: 
X-Auto-Response-Suppress: All
X-MS-Exchange-Organization-SenderIdResult: Pass
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-PRD: ietf.org
X-MS-TNEF-Correlator: 
received-spf: Pass (EXCH-HTCAS901.corp.cloudmark.com: domain of
 ietf-announce-bounces@ietf.org designates 12.22.58.30 as permitted sender)
 receiver=EXCH-HTCAS901.corp.cloudmark.com; client-ip=12.22.58.30;
 helo=mail.cloudmark.com;
dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com;
	s=default; t=1332762426;	bh=XKebLtJj42xFZNjO9tVQRnpwqGD4cJjKUr8gJ81Puvw=;
	h=To:Subject:From:Message-Id:Date:Cc:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:Sender;
	b=pqSDLB6RuNAKeeBQ4P4BzTUJMCOuf/4k3STtN/Dm+v8//xXQNO9Dej4Mi+qgrjxoB
	 h2uoRrnle8jiqC+k7vN01mssCjUZM2NBVcSdQJPCknJHx306mfa5G7n8QziRd5Ewsw
	 BKzE8pZumyq3e8rsQtS9v7mAuYLYMMqZIAhj0jPo=
list-id: "IETF announcement list. No discussions." 
x-mailman-version: 2.1.12
x-beenthere: ietf-announce@ietf.org
errors-to: ietf-announce-bounces@ietf.org
list-post: 
list-archive: 
x-spam-status: No, score=-104.319 tagged_above=-999 required=5
	tests=[AWL=0.758, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611,
	HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4,
	USER_IN_WHITELIST=-100]
x-spam-score: -104.319
x-virus-scanned: amavisd-new at amsl.com
x-spam-level: 
x-original-to: ietf-announce@ietfa.amsl.com
delivered-to: ietf-announce@ietfa.amsl.com
x-spam-flag: NO
authentication-results: mail.cloudmark.com;	dkim=pass header.d=ietf.org
 header.b=mNf2VLo+
x-cmae-score: 0.00
x-cmae-analysis: v=2.0 cv=AK3EY2DH c=1 sm=1 a=GU4rwa5YvsQnE15YQEkOQw==:17
 a=cg79xCmPx4oA:10 a=jqLZRQbfNSIA:10 a=wPDyFdB5xvgA:10 a=b6nfwRhkAAAA:8
 a=BqEg4_3jAAAA:8 a=48vgC7mUAAAA:8 a=B4mWk3cx2F_6KPDLD4gA:9
 a=Dq-P6Rcb9_XcKHaj9SIA:7 a=ehZt0hOliUgA:10 a=4YeqJvKdtvQA:10
 a=RjwTPiaSbNEA:10 a=1eQkaoUQ5BgA:10 a=GU4rwa5YvsQnE15YQEkOQw==:117
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


A new Request for Comments is now available in online RFC libraries.

       =20
        RFC 6577

        Title:      Authentication-Results Registration Update for Sender=20
                    Policy Framework (SPF) Results=20
        Author:     M. Kucherawy
        Status:     Standards Track
        Stream:     IETF
        Date:       March 2012
        Mailbox:    msk@cloudmark.com
        Pages:      5
        Characters: 8173
        Updates:    RFC5451

        I-D Tag:    draft-kucherawy-authres-spf-erratum-02.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6577.txt

This memo updates the registry of authentication method results in
Authentication-Results: message header fields, correcting a
discontinuity between the original registry creation and the Sender
Policy Framework (SPF) specification.  [STANDARDS-TRACK]

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



--_002_9452079D1A51524AA5749AD23E0039280B950Cexchmbx901corpclo_--

From vesely@tana.it  Mon Mar 26 06:16:07 2012
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 8A08721F8628 for ; Mon, 26 Mar 2012 06:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level: 
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtnquahFcHog for ; Mon, 26 Mar 2012 06:16:06 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6278921F861B for ; Mon, 26 Mar 2012 06:16:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332767763; bh=hzk6gH0rBbNGDpBpwwOiECs/1gvt/lGmGFLQ5UQyGm8=; l=1474; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Cxd8SJtj7i6FYULgRKeXe5X4vYhdpwCzOPpE88NV1omBYMyPAMh7uD994I+3ztXVe eNQUyBEqyh3fE6QTZmgBGfzUGu8myV92bTOZQE5FlOkEmklR4qcTUb17Eh7hJjyGHv LfdGBRKmNcx0cdEqo7IYeNr9MXWelnProbNuH4y0=
Received: from [130.129.23.88] (dhcp-1758.meeting.ietf.org [130.129.23.88]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 26 Mar 2012 15:15:58 +0200 id 00000000005DC033.000000004F706C0F.0000469D
Message-ID: <4F706C03.4000101@tana.it>
Date: Mon, 26 Mar 2012 15:15:47 +0200
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120315175753.21172.qmail@joyce.lan> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> <2744445.3m1Dyi5C5m@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280B8A8A@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120326012359.099d33e0@resistor.net>
In-Reply-To: <6.2.5.6.2.20120326012359.099d33e0@resistor.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] Deployment document?
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 Mar 2012 13:16:07 -0000

On Mon 26/Mar/2012 15:00:29 +0200 S Moonesamy wrote:
> At 22:59 25-03-2012, Murray S. Kucherawy wrote:
>> Given Scott's last message,

Was it the one about Received-SPF?

>> I think there's been enough discussion about deployment advice, caveats,
>> etc., that we should decide whether there's enough material to warrant
>> its own document.  If the volume of such pedagogy is significant, then
>> packing it all into a really big appendix of RFC4408bis might be
>> considered poor form.
>>
>> It's obviously not one of our deliverables in the current charter, but I
>> suspect it wouldn't be a big deal to add it since it doesn't affect the
>> constraints on protocol changes.
> 
> Could you please bring this up during the WG session on Friday?  As the
> Responsible AD will be in the room, it should be easy to resolve the
> deliverable angle.
> 
> Could the WG please provide feedback about this so that we don't get into a
> long discussion on Friday?

It's not very clear what should go to the separate document.  Differently
than DKIM, SPF is a self contained protocol, or at least used to.  Some
difficulties originate from unclear logic (e.g. break forwarding being
predicated true and false at the same time) but if we are able to get them
straight, we might actually happen to shorten the original text.  That is to
say, I'd defer deciding about an overflow document to when we see that we
need to be verbose.  I hope it won't be necessary.

From msk@cloudmark.com  Mon Mar 26 06:19:51 2012
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 84A8821F866C for ; Mon, 26 Mar 2012 06:19:51 -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=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFCz3L1pTd0l for ; Mon, 26 Mar 2012 06:19:51 -0700 (PDT)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id E654C21E80A9 for ; Mon, 26 Mar 2012 06:19:50 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 06:19:50 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: [spfbis] Deployment document?
Thread-Index: AQHNCxWfWPz9zvDtzkafJsdTdh/Ae5Z8P7E5gADEmYD//4tG4A==
Date: Mon, 26 Mar 2012 13:19:49 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039280B96FD@exch-mbx901.corp.cloudmark.com>
References: <20120315175753.21172.qmail@joyce.lan> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> <2744445.3m1Dyi5C5m@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280B8A8A@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120326012359.099d33e0@resistor.net> <4F706C03.4000101@tana.it>
In-Reply-To: <4F706C03.4000101@tana.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.22.1.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] Deployment document?
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 Mar 2012 13:19:51 -0000

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf =
Of Alessandro Vesely
> Sent: Monday, March 26, 2012 6:16 AM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] Deployment document?
>=20
> On Mon 26/Mar/2012 15:00:29 +0200 S Moonesamy wrote:
> > At 22:59 25-03-2012, Murray S. Kucherawy wrote:
> >> Given Scott's last message,
>=20
> Was it the one about Received-SPF?

I was referring to Scott's message that included a PDF which showed possibl=
e places in the handling chain where SPF evaluation makes sense.  That by i=
tself could be developed into its own informational document, along with ot=
her things we've talked about including as operational and/or deployment ad=
vice.

> It's not very clear what should go to the separate document.
> Differently than DKIM, SPF is a self contained protocol, or at least
> used to.  Some difficulties originate from unclear logic (e.g. break
> forwarding being predicated true and false at the same time) but if we
> are able to get them straight, we might actually happen to shorten the
> original text.  That is to say, I'd defer deciding about an overflow
> document to when we see that we need to be verbose.  I hope it won't be
> necessary.

We certainly should inventory what we want to put into such a document befo=
re starting.  But it feels to me as though there's quite a bit to write alr=
eady.

From vesely@tana.it  Mon Mar 26 06:41:01 2012
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 8855221E809A for ; Mon, 26 Mar 2012 06:41:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level: 
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHQVAsgBcY-3 for ; Mon, 26 Mar 2012 06:41:01 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7F121E8097 for ; Mon, 26 Mar 2012 06:40:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332769251; bh=gDEbrmW4GjPGCrr/JoptVMS5Q0dOImLk6a9/4VHBJlw=; l=619; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=WAUvK8YBoicqyCty7Lvkh1ELXzGEmX10bECo5Eimy46mqjEwDlJx92yj+WBmoFGLP F6OHhndUJrpP9yJcKbDztR/EJ18Q0uOdjs1glE2gBiKYAl0j6D8/H90pKgGLECgKYS 499Yzh5lIvCgYVD7R6wRa9l4uXu8RRXwNzwgiVv0=
Received: from [130.129.23.88] (dhcp-1758.meeting.ietf.org [130.129.23.88]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 26 Mar 2012 15:40:43 +0200 id 00000000005DC033.000000004F7071DE.00004C32
Message-ID: <4F7071CA.1020401@tana.it>
Date: Mon, 26 Mar 2012 15:40:26 +0200
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120315175753.21172.qmail@joyce.lan> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> <2744445.3m1Dyi5C5m@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280B8A8A@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120326012359.099d33e0@resistor.net> <4F706C03.4000101@tana.it> <9452079D1A51524AA5749AD23E0039280B96FD@exch-mbx901.corp.cloudmark.com>
In-Reply-To: <9452079D1A51524AA5749AD23E0039280B96FD@exch-mbx901.corp.cloudmark.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] Deployment document?
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 Mar 2012 13:41:01 -0000

On Mon 26/Mar/2012 15:25:54 +0200 Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>>
>> Was it the one about Received-SPF?
> 
> I was referring to Scott's message that included a PDF which showed
> possible places in the handling chain where SPF evaluation makes sense.

I see.  Those figures will have to be manually converted to ascii-art, but
aren't they part of the main protocol?  I'm not an artist, but I volunteer to
do that conversion, if nobody else wants to.  The description of those
figures might be short and clear or lengthy and fuzzy, that's up to how
clever we are.

From vesely@tana.it  Tue Mar 27 01:17:46 2012
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 D6FCA21F8865 for ; Tue, 27 Mar 2012 01:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level: 
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpO7iGpkDzbJ for ; Tue, 27 Mar 2012 01:17:44 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E669921F884C for ; Tue, 27 Mar 2012 01:17:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332836253; bh=o7sC4u3pwh4UN9JTu9KWM48n67tfnBBuDuV1IsAEb0c=; l=849; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=K5da9X/D40S2YeeT3bYkSBrjDw0mdXEHqXSASJKkVHxFtyHl0Rh3XpyRQ9uocuJSK lu1M8sDot3NCCUw+1iN54wkdKpvenbn73jzEgTapWr1sD90F6wihaWjdkgvAIK20PD oFpEArSsR5gL2AbXvt6YhYBXP27mC8h8XueBF9Ng=
Received: from [130.129.17.62] (dhcp-113e.meeting.ietf.org [130.129.17.62]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 27 Mar 2012 10:17:25 +0200 id 00000000005DC04B.000000004F717799.0000510B
Message-ID: <4F717781.7030606@tana.it>
Date: Tue, 27 Mar 2012 10:17:05 +0200
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320>	<4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320>	<4F6C4903.8090901@tana.it> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it> <9452079D1A51524AA5749AD23E003928098E77@exch-mbx901.corp.cloudmark.com> <4F6CD594.1090909@tana.it> <9452079D1A51524AA5749AD23E0039280995A3@exch-mbx901.corp.cloudmark.com> <4F6DF691.8080205@tana.it> <9452079D1A51524AA5749AD23E0039280B7ABD@exch-mbx901.corp.cloudmark.com>
In-Reply-To: <9452079D1A51524AA5749AD23E0039280B7ABD@exch-mbx901.corp.cloudmark.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding	and	helo	identities
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 Mar 2012 08:17:47 -0000

On Tue 27/Mar/2012 09:51:51 +0200 Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>
>> IMHO, it is the smallest change that is compatible with plain reject on
>> fail.
> 
> Still, you're proposing adding a new requirement onto the entirety of a
> decades-old infrastructure.  I imagine for that trick to work, the benefit
> would have to be pretty enormous, and a huge majority would have to be on
> board with adopting it.

I'd rather ask the opposite question.  That is, what functionality requires
to preserve the envelope unaltered?  Severe changes for avoiding backscatter
have been carried out on almost every system, in recent years.  Dropping the
envelope sender on external "alias expansion" would probably pass unnoticed,
except for an unprecedented simplification of the SPF receiver-behavior spec.

From sm@elandsys.com  Tue Mar 27 05:48:42 2012
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 B5C6321E81CD for ; Tue, 27 Mar 2012 05:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.595
X-Spam-Level: 
X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 AvGQZtVWeAAv for ; Tue, 27 Mar 2012 05:48:38 -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 B19EC21F87CA for ; Tue, 27 Mar 2012 05:48:38 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.236.147]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2RCmQb7022330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Mar 2012 05:48:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1332852517; i=@elandsys.com; bh=hp8Oh0hnV+h0gCvPhScimbrQvlvPkni7bWd2EPWlrR0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=zngFJjwyT6TUiggsFdo71zkRt94JEtR+ddnF2GyOU/cuvNBzPJ6BWINRY200kaEQ2 gs/7GSFylX3tBr6uKNVbNoSMMfP7Jnnt8aI1QXJ376beTXzn3l8AZomDCO+txFciOG 5Gspi93JQysIYyo4MGJrbFBml8A7oQTNMfdITRvE=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1332852517; i=@elandsys.com; bh=hp8Oh0hnV+h0gCvPhScimbrQvlvPkni7bWd2EPWlrR0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=gtvoCgh5IDXIg1chv31/Gq+Afo5RW1NXETq2OjQL67deIkTzeKo2fKBY0N96hypeL wgDNT6Vo2XOhrODHSXcB705FZgJriCtxpisIdjmFdohxNI3XdecPb5FNxcnu/O2xQY 0d3eH4TxHsQ0WA/YAyOkfkpMOZg+9ENKR7Az92a8=
Message-Id: <6.2.5.6.2.20120327053653.0c048a20@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 27 Mar 2012 05:45:37 -0700
To: spfbis@ietf.org
From: S Moonesamy 
In-Reply-To: <10049000.JnkWhYZNpC@scott-latitude-e6320>
References: <061.7b579813c6f1a0e79af162f7d410113b@tools.ietf.org> <6142523.ruCe9BVMMC@scott-latitude-e6320> <4F6C4A73.9010009@tana.it> <10049000.JnkWhYZNpC@scott-latitude-e6320>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [spfbis] #11: RFC 4408 Section 4 check_host() function
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 Mar 2012 12:48:42 -0000

This is a quick summary of Issue #11.  The issue is based on a 
message posted on February 7 [1].

Scott Kitterman mentioned that maintaining backwards compatiblity is 
a very high priority in the charter [2].  When we re-write text, and 
particularly re-writing entire sections, there is a risk of 
inadvertent functional changes.  He is of the view that it is a 
stylistic issue.  Alessandro Vesely agreed [3].  He also suggested 
adding text (e.g. in Section 1.2) that the function name being used 
is not an API entry point and that such terminology is used for 
clarity and historical reasons only, to which Scott Kitterman agreed.

Murray Kucherawy did not agree that the change threatens backward 
compatibility.  He thinks that it is more than a stylistic point [4] 
and mentioned that adding text to say the "check_host()" thing is an 
illustration point only and not an API definition is probably a 
reasonable compromise.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00359.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00968.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00970.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00976.html


From sm@elandsys.com  Wed Mar 28 05:57:33 2012
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 0194921E81F5 for ; Wed, 28 Mar 2012 05:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.595
X-Spam-Level: 
X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 oSa9KZU+aaGi for ; Wed, 28 Mar 2012 05:57:32 -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 290AF21E81DE for ; Wed, 28 Mar 2012 05:57:32 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.235.57]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2SCvKXF000753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Mar 2012 05:57:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1332939451; i=@elandsys.com; bh=mU6bBP6xdwzdIMG2N6fc89vNEIlBlIfl/qYj13OzLMU=; h=Date:To:From:Subject:Cc; b=Q9aUQgJKGLWIts9kAAgl6CS5B5sTadiYDy1wPGn+mwulZKJ2CjlkOzclUggh158FI XPCJafrByMrV5ZQ5luKKFN97IEv2bJnM+IMzJNPv/CIxBjdl+qtsYqhvtR5NjaAOjb /iNg7VHIFo+dHsxduW5S74XOQ/0X4xeSzb1BoAc4=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1332939451; i=@elandsys.com; bh=mU6bBP6xdwzdIMG2N6fc89vNEIlBlIfl/qYj13OzLMU=; h=Date:To:From:Subject:Cc; b=0+wDAobLurVqjQHabGsOOK0Yy0fLbjgoOzqAf9ia+hWupEZITW+cIFznBKi5xfKm6 dmnmEW1l5FM9XXiAgf5GaaGrQibPtMtFZN7yKy4nDBBBZ4InmTOjufoKiV54ltDWP9 nGfNQGLdj8EgYtyYHm6DbEvteKhXf7ccnTvfAAC0=
Message-Id: <6.2.5.6.2.20120328055039.0dfc5d80@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 28 Mar 2012 05:56:37 -0700
To: spfbis@ietf.org
From: S Moonesamy 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [spfbis] Agenda for IETF83
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 Mar 2012 12:57:33 -0000

Hello,

This is the agenda for the IETF83 session:

SPF Update Working Group Agenda

March 30, 2012, 09:00 - 11:00 CET              120 minutes

     Note well                                    1 minute

     Agenda bashing                               4 minutes

     RFC 4408 issues                             35 minutes

     SPF RR Type and TXT RR (issue #9)           20 minutes

     DNS amplification attacks                   10 minutes

     Path authorization/updating SMTP             5 minutes

     Is a deployment document needed              5 minutes

     Adoption of                                 30 minutes
       draft-kucherawy-spfbis-experiment-03
       describing the SPF/Sender-ID experiment
       and discussion

     Any Other Business                          10 minutes

Regards,
Andrew Sullivan & S. Moonesamy, SPFBIS WG chairs


From sm@elandsys.com  Wed Mar 28 07:08:56 2012
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 1F2F821E8190 for ; Wed, 28 Mar 2012 07:08:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.595
X-Spam-Level: 
X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 5B2ETtWFfvM3 for ; Wed, 28 Mar 2012 07:08:55 -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 5860421E825B for ; Wed, 28 Mar 2012 07:08:52 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.235.57]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2SE8ehQ011291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Mar 2012 07:08:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1332943731; i=@elandsys.com; bh=jYFSHtL6ZDBCr+NCsHIxJZDZVJq+X7CI0179poENz/w=; h=Date:To:From:Subject:Cc; b=Fs7kJBVTLMN3fg0+lBIw6g08oKwxkIy6MmgWHRbBrOoH/A//MEI+X4X1px04dDfec AnGhgWZ0flI72v6yoOZAvbGdP8QEsn5clcISMRuVqngctDYfpCYKliQQL3fnfcGPI3 fO54rj1dUHoDIP4q7IojbkUn2XuP1ruQhZjqOMiQ=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1332943731; i=@elandsys.com; bh=jYFSHtL6ZDBCr+NCsHIxJZDZVJq+X7CI0179poENz/w=; h=Date:To:From:Subject:Cc; b=JNIKgsNgBxHGT/hzV4cyiLP+Y8o7kcTYT/zPqIUZdEWMS6Trj4mGAg+nwJ1rQr+6n ZeT6b7AbO96PyQTV2sVTCZAy3GAPja7GdKxwPin2g3zNTYNJIhKRc7pDo1hLFogYgG PN/NiJfObbaSydowNajIQ69HAw0eBgEfmm0zKPeY=
Message-Id: <6.2.5.6.2.20120328055906.0dff3a60@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 28 Mar 2012 06:16:00 -0700
To: spfbis@ietf.org
From: S Moonesamy 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [spfbis] Remote participation for IETF 83
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 Mar 2012 14:08:56 -0000

Hello,

The SPFBIS WG will be meeting in room 252A on Friday between 09:00 an 
11:00 CET (07:00 - 09:00 UTC).

The agenda for the SPFBIS session is at 
http://www.ietf.org/proceedings/83/agenda/agenda-83-spfbis.txt  The 
meeting materials (slides, etc.) can be downloaded from 
https://datatracker.ietf.org/meeting/83/materials.html

The audio stream will be accessible at 
http://ietf83streaming.dnsalias.net/ietf/ietf835.m3u  You can join 
the spfbis@jabber.ietf.org Jabber room to participate remotely or use 
Meetecho ( http://www.meetecho.com/ietf83/spfbis ).

We need a minute taker and a Jabber scribe for the session.  Please 
volunteer by sending an email to spfbis-chairs@tools.ietf.org.

Regards,
S. Moonesamy
SPFBIS WG co-chair


From spf2@kitterman.com  Wed Mar 28 15:41:05 2012
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 E2D0B21E8117 for ; Wed, 28 Mar 2012 15:41:05 -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.007,  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 cyqHRan8vnJx for ; Wed, 28 Mar 2012 15:41:04 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7A68A21E80AD for ; Wed, 28 Mar 2012 15:41:04 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8C1DD20E40DA; Wed, 28 Mar 2012 18:41:03 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1332974463; bh=JM8qucGyovgNxUvhtk8GL9gjMSxoICMSnmEgwrvjjws=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=mhkugzKUHir2Arf0U27dCkSLWioC5B+fW8MtVCvX/vonDV79GHWIDTBuG2LzhYtEL hOeb5rUiU7FMJOiKEX9AeW4FWwb/8x+BUOoRrTK1FA5IuXgenkEr54XvF1KuSAPDNK szhvottW3t1aITvWU6Fb8aNB6if6pv8fYzoueOqg=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 736B020E40A3;  Wed, 28 Mar 2012 18:41:03 -0400 (EDT)
From: Scott Kitterman 
To: spfbis@ietf.org
Date: Wed, 28 Mar 2012 18:41:02 -0400
Message-ID: <1731357.f8lSbc92ri@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <6.2.5.6.2.20120328055039.0dfc5d80@elandnews.com>
References: <6.2.5.6.2.20120328055039.0dfc5d80@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] Agenda for IETF83
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 Mar 2012 22:41:06 -0000

On Wednesday, March 28, 2012 05:56:37 AM S Moonesamy wrote:
...
>      DNS amplification attacks                   10 minutes
...

Didn't roughly everyone who commented on this agenda item suggest we shouldn't 
do it?  I think it would be more productive to end the session 10 minutes 
early and give people more time for informal discussion.

Scott K

From johnl@iecc.com  Wed Mar 28 15:51:11 2012
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 EEFDB21E80AD for ; Wed, 28 Mar 2012 15:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.4
X-Spam-Level: 
X-Spam-Status: No, score=-110.4 tagged_above=-999 required=5 tests=[AWL=0.799,  BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 LkiOtgoYbOWh for ; Wed, 28 Mar 2012 15:51: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 045BE21E810F for ; Wed, 28 Mar 2012 15:51:10 -0700 (PDT)
Received: (qmail 16650 invoked from network); 28 Mar 2012 22:51:10 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Mar 2012 22:51: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:vbr-info; s=4f7395dc.xn--hew.k1203; i=johnl@user.iecc.com; bh=7mJx/ZBmpIqRyUXHkQLTlLuQkppMKjG38MNq6NDVWtk=; b=GrdbpPYSlCTpwhnREMnH+NL/YwitWC/aJIzOgLNRnVJ/NNfrWqBuNMJD8/9Hi051qFHGbdPytNsjwZl1zt/1FgPRQxEbyBQGQVHU8P2rHtBgDUCZFPwr9DMOf26e8Hg4WQiVxv6nH4visaWVwYjCDYwb+J928RobBC03Kbty25g=
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:vbr-info; s=4f7395dc.xn--hew.k1203; olt=johnl@user.iecc.com; bh=7mJx/ZBmpIqRyUXHkQLTlLuQkppMKjG38MNq6NDVWtk=; b=hSfVRaW6ngdtYimfbHHsvgU1fIMBlygVfAfO89OiaIM5dBREJxdwR7mlsWl/YfSkmQa2smqYUBiK6ep4nqTt6s5PIo+0v2VdS0zOy1xwsWB9hTrMxJZKCSYh0mHeAK1oISr9hP4akJLWlIv9J1sh6TWOtjfE0XkvVTnmmNgs/iw=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 28 Mar 2012 22:50:46 -0000
Message-ID: <20120328225046.16893.qmail@joyce.lan>
From: "John Levine" 
To: spfbis@ietf.org
In-Reply-To: <1731357.f8lSbc92ri@scott-latitude-e6320>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Cc: spf2@kitterman.com
Subject: Re: [spfbis] Agenda for IETF83
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 Mar 2012 22:51:12 -0000

>>      DNS amplification attacks                   10 minutes
>...
>
>Didn't roughly everyone who commented on this agenda item suggest we shouldn't 
>do it? 

That's my recollection.  I'll try to bash it off the agenda.

R's,
John

From dotis@mail-abuse.org  Wed Mar 28 16:25:30 2012
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 E7B9A21E8178 for ; Wed, 28 Mar 2012 16:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.445
X-Spam-Level: 
X-Spam-Status: No, score=-102.445 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 bnWy7tiLJGVv for ; Wed, 28 Mar 2012 16:25:30 -0700 (PDT)
Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1098A21E8175 for ; Wed, 28 Mar 2012 16:25:29 -0700 (PDT)
Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 86D5E1740471 for ; Wed, 28 Mar 2012 23:25:29 +0000 (UTC)
Message-ID: <4F739DE9.8010202@mail-abuse.org>
Date: Wed, 28 Mar 2012 16:25:29 -0700
From: Douglas Otis 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120328225046.16893.qmail@joyce.lan>
In-Reply-To: <20120328225046.16893.qmail@joyce.lan>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] Agenda for IETF83
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 Mar 2012 23:25:31 -0000

On 3/28/12 3:50 PM, John Levine wrote:
>>>       DNS amplification attacks                   10 minutes
>> ...
>>
>> Didn't roughly everyone who commented on this agenda item suggest we shouldn't
>> do it?
> That's my recollection.  I'll try to bash it off the agenda.
Dear John,

There were less vocal participants who voiced concerns about ignoring 
this issue.  I'll admit those running MTAs are unlikely to become DDoS 
targets, or notice when they facilitate distributed attacks through 
abuse of SPF macros.  Depending upon implementations, SPF processing 
could permit 400 DNS transactions against victim domains that return 
no-data and still result in message acceptance.  It is also incorrect to 
suggest instantiating supporting records for this type of attack is 
difficult, or requires extensive amounts of malefactor's resources.

A few minor changes could impose reasonable error limits for name an 
no-data errors and thus mitigate this potential threat.

Regards,
Douglas Otis

From ajs@anvilwalrusden.com  Wed Mar 28 16:27:56 2012
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 7FAC321E8183 for ; Wed, 28 Mar 2012 16:27:56 -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 w1cemOJIgpmL for ; Wed, 28 Mar 2012 16:27:56 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C584B21E812B for ; Wed, 28 Mar 2012 16:27:55 -0700 (PDT)
Received: from mail.yitter.info (unknown [83.145.64.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E69B11ECB420 for ; Wed, 28 Mar 2012 23:27:54 +0000 (UTC)
Date: Wed, 28 Mar 2012 19:27:53 -0400
From: Andrew Sullivan 
To: spfbis@ietf.org
Message-ID: <20120328232752.GC13790@mail.yitter.info>
References: <6.2.5.6.2.20120328055039.0dfc5d80@elandnews.com> <1731357.f8lSbc92ri@scott-latitude-e6320>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1731357.f8lSbc92ri@scott-latitude-e6320>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [spfbis] Agenda for IETF83
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 Mar 2012 23:27:56 -0000

On Wed, Mar 28, 2012 at 06:41:02PM -0400, Scott Kitterman wrote:

> Didn't roughly everyone who commented on this agenda item suggest we shouldn't 
> do it?

Some did, yes.  The time was cut considerably since the earlier
agenda, and there is of course no rule that we have to fill every
moment of allotted time.

Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

From ietf@meetecho.com  Thu Mar 29 15:51:49 2012
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 B534821E8086 for ; Thu, 29 Mar 2012 15:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 vweFT8psxev2 for ; Thu, 29 Mar 2012 15:51:49 -0700 (PDT)
Received: from smtplq04.aruba.it (smtplqs-out26.aruba.it [62.149.158.66]) by ietfa.amsl.com (Postfix) with SMTP id C3B3821E8054 for ; Thu, 29 Mar 2012 15:51:48 -0700 (PDT)
Received: (qmail 26225 invoked by uid 89); 29 Mar 2012 22:51:47 -0000
Received: from unknown (HELO smtp3.aruba.it) (62.149.158.223) by smtplq04.aruba.it with SMTP; 29 Mar 2012 22:51:47 -0000
Received: (qmail 23228 invoked by uid 89); 29 Mar 2012 22:51:47 -0000
Received: from unknown (HELO ?192.168.0.40?) (alex@meetecho.com@78.192.151.119) by smtp3.ad.aruba.it with ESMTPA; 29 Mar 2012 22:51:47 -0000
Message-ID: <4F74E77A.3040503@meetecho.com>
Date: Fri, 30 Mar 2012 00:51:38 +0200
From: Meetecho IETF support 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: spfbis@ietf.org
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N
Cc: Team Meetecho 
Subject: [spfbis] Meetecho support for SPFBIS WG meeting session
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 Mar 2012 22:51:49 -0000

Hi all,

a virtual room has been reserved on the Meetecho system for Friday's 
SPFBIS WG meeting session.

Access to the on-line session (including audio and video streams) will 
be available at:
http://www.meetecho.com/ietf83/spfbis

The Meetecho session automatically logs you into the standard IETF 
jabber room. So, from there, you can have an integrated experience 
involving all media and allowing you to interact with the room.
Remote participants might also send their own voice to the room, if they 
want to, by either calling a landline phone number, or using our 
embedded VoIP applet (in this last case they are *strongly* advised to 
use a headset).

A tutorial of interactivity features of the tool can be found at:
http://www.meetecho.com/ietf83/tutorials

Cheers,
the Meetecho team

-- 
Meetecho s.r.l.
Web Conferencing and Collaboration Tools
www.meetecho.com

From msk@cloudmark.com  Fri Mar 30 03:24:46 2012
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 584BD21F86A0 for ; Fri, 30 Mar 2012 03:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.548
X-Spam-Level: 
X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=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 hSVHQm6vGgcs for ; Fri, 30 Mar 2012 03:24:44 -0700 (PDT)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id BFC0B21F86A2 for ; Fri, 30 Mar 2012 03:24:44 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Fri, 30 Mar 2012 03:24:44 -0700
From: "Murray S. Kucherawy" 
To: "spfbis@ietf.org" 
Thread-Topic: Experiment document
Thread-Index: Ac0OX1JElkOuVjEpSX+EejibzakHPA==
Date: Fri, 30 Mar 2012 10:24:43 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039280C2AF5@exch-mbx901.corp.cloudmark.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.129.23.154]
Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280C2AF5exchmbx901corpclo_"
MIME-Version: 1.0
Subject: [spfbis] Experiment document
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, 30 Mar 2012 10:24:46 -0000

--_000_9452079D1A51524AA5749AD23E0039280C2AF5exchmbx901corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

While we wait for the tools team to sort out the datatracker problem, I'm g=
oing to continue revising the draft as an individual submission.

I'm going to add/update the results from my SPF survey first.  And I'll arr=
ange for Scott to get access to my survey data so he can complete his secon=
dary survey.

Dave proposed talking about which questions we'd like to see answered in th=
e experiment document to send to the IESG.  From this, we can figure out if=
 we can already answer those questions or if we need to design and run more=
 surveys.  I propose we start coming up with those questions now.  I'll sta=
rt by tossing these out, and people should alter/chop/augment these entries=
:


-          What is the relative deployment of SPF vs TXT records?

-          How many clients appear to be querying each record type?

-          What are counts on records that are specific to Sender-ID (i.e.,=
 spf2.0/pra) versus others?

-          How much do the Sender-ID results deviate from the SPF results i=
n terms of pass/fail?

-          How often do the validated identifiers differ between SPF and Se=
nder-ID?

-          How many implementations of each of the four RFCs are known to e=
xist?  (This is anecdotal, not survey-based.)

And the following appendix topics:


-          What operational considerations were observed (e.g., firewalls, =
dropped packets for unknown types)?

-          The whole SPF vs. TXT evolution discussion

-          How often were non-SPF records found in TXT queries?

Please bash the list now.

I also need to add a paragraph that describes the surveys we've done.  I'll=
 add that for mine; Philip, please send me a description of yours, on-list =
or off.

Thanks,
-MSK

--_000_9452079D1A51524AA5749AD23E0039280C2AF5exchmbx901corpclo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











While we wait for the tools team to sort out the dat=
atracker problem, I’m going to continue revising the draft as an indi=
vidual submission.


 


I’m going to add/update the results from my SP=
F survey first.  And I’ll arrange for Scott to get access to my =
survey data so he can complete his secondary survey.


 


Dave proposed talking about which questions we’=
;d like to see answered in the experiment document to send to the IESG.&nbs=
p; From this, we can figure out if we can already answer those questions or=
 if we need to design and run more surveys. 
 I propose we start coming up with those questions now.  I’ll st=
art by tossing these out, and people should alter/chop/augment these entrie=
s:


 


-     &=
nbsp;   
What is the relative deployment of SPF vs TXT recor=
ds?


-     &=
nbsp;   
How many clients appear to be querying each record =
type?


-     &=
nbsp;   
What are counts on records that are specific to Sen=
der-ID (i.e., spf2.0/pra) versus others?


-     &=
nbsp;   
How much do the Sender-ID results deviate from the =
SPF results in terms of pass/fail?


-     &=
nbsp;   
How often do the validated identifiers differ betwe=
en SPF and Sender-ID?


-     &=
nbsp;   
How many implementations of each of the four RFCs a=
re known to exist?  (This is anecdotal, not survey-based.)<=
/p>

 


And the following appendix topics:


 


-     &=
nbsp;   
What operational considerations were observed (e.g.=
, firewalls, dropped packets for unknown types)?


-     &=
nbsp;   
The whole SPF vs. TXT evolution discussion


-     &=
nbsp;   
How often were non-SPF records found in TXT queries=
?


 


Please bash the list now.


 


I also need to add a paragraph that describes the su=
rveys we’ve done.  I’ll add that for mine; Philip, please =
send me a description of yours, on-list or off.


 


Thanks,


-MSK






--_000_9452079D1A51524AA5749AD23E0039280C2AF5exchmbx901corpclo_--

From sm@elandsys.com  Fri Mar 30 06:16:16 2012
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 35B9721F8677; Fri, 30 Mar 2012 06:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.595
X-Spam-Level: 
X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 tdV51LQN1sa7; Fri, 30 Mar 2012 06:16:15 -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 EFF6721F84F3; Fri, 30 Mar 2012 06:16:14 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.239.240]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2UDFxep023824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Mar 2012 06:16:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1333113372; i=@elandsys.com; bh=S+QfRaCKA3jI1GPkxfKHRRUqYVeFabzcuQTgoB/IRok=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=r6pV5Axfaq06iq8vBjM6n++cx9Sn40mIkAVUUiKeG/zaIkSgHAL+28J9vcTmRmjUY gn/irr1VSRShYnLi951YJPXg0vMF5eyEarZn81dKEkfxNJJAtQYw4Zw10tlMiQTjPQ YFpcEEgte5rlJJHBBPQJ2DSnsMUewJi1wMcuW+CY=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1333113372; i=@elandsys.com; bh=S+QfRaCKA3jI1GPkxfKHRRUqYVeFabzcuQTgoB/IRok=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Mx66U/STNlQVVqc3ruDUJzK+IUIrFSDhkW/hLJAM83PU8og29BsIPtclLe/xOjxhK AHWpnilWg829qhrdOG0UK1ABtUApdOA6QaF7u+lMKJgwHZcAWnaXdvUfCmjm7Gr6Ks AU0hPREXBHI+Kh9+kzo0VSi3QFWTx1YL4duas844=
Message-Id: <6.2.5.6.2.20120330043944.0dd1cf40@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 30 Mar 2012 06:13:35 -0700
To: vmeet@ietf.org
From: S Moonesamy 
In-Reply-To: <4F74E77A.3040503@meetecho.com>
References: <4F74E77A.3040503@meetecho.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailman-Approved-At: Fri, 30 Mar 2012 06:17:22 -0700
Cc: Team Meetecho 
Subject: Re: [spfbis] Meetecho support for SPFBIS WG meeting session
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, 30 Mar 2012 13:16:16 -0000

Hello

[Bcc to spfbis@; please follow up on vmeet@ietf.org]

The purpose of this email is two-fold; provide feedback to the 
Meetecho team and to get feedback about remote participation.

At 15:51 29-03-2012, Meetecho IETF support wrote:
>a virtual room has been reserved on the Meetecho system for Friday's 
>SPFBIS WG meeting session.

First of all, thanks to the Meetecho team for providing the service 
and for responding to the support issues in real-time.  Thanks to 
Murray Kucherawy for being Jabber scribe and Tony Hansen for stepping 
in when Murray presented; and the minute-taker, John Levine (not 
using Etherpad).

Due to the low audio quality, I was not able to tell who was speaking 
at times.  With the video feed, I could see chair (body language 
during the session) and follow the slides.  Meetecho also provides 
the slide number and title over XMPP.

There were around 20 people in the room and over 10 people and the 
Responsible Area Director in the Jabber room.  There was no 
Jabber/chair interaction as there was only one chair in the room.

It's difficult to rate the experience between Meetecho and the legacy 
remote service.  The weak point for Meetecho is audio quality whereas 
the legacy audio has about a 15 second delay.  In this case, my 
trade-off was the desire to follow this session without significant 
audio delay.

The slides used by Meetecho was from the IETF materials web 
page.  The chair called for one or more hums during the meeting.  If 
new text is projected on the screen (questions to hum on, for 
example), that would not be displayed through Meetecho.  As I could 
not see the microphone line, it was not possible to evaluate the 
importance of each issue in real-time.

There are some user interface and user issues when using Meetecho  (I 
mistakenly broadcasted video).  I used a standalone XMPP client 
instead of following the Meetecho (XMPP) chat window.

Could other remote participants for this session please provide feedback on:

  (a) What worked for you?

  (b) What did not work for you?

  (c) Could you follow the WG session?

  (d) Do you feel that you were able to participate adequately in the
      discussions?

  (e) Do you feel that you were able to participate adequately in the
      decision-making?

  (f) Do you have a better understanding of how WG issues can be
      resolved after following this session?

Regards,
S. Moonesamy

P.S. Did the Meetecho team volunteer to sponsor some T-Shirts for 
AppsDir? :-)   


From R.E.Sonneveld@sonnection.nl  Fri Mar 30 14:25:55 2012
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 7759721F8621 for ; Fri, 30 Mar 2012 14:25:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.618
X-Spam-Level: 
X-Spam-Status: No, score=-3.618 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 5jqPjAmFKiaq for ; Fri, 30 Mar 2012 14:25:53 -0700 (PDT)
Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 1415921F8618 for ; Fri, 30 Mar 2012 14:25:53 -0700 (PDT)
Received: from process-dkim-sign-daemon.helium.mailtransaction.com by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0M1P00I00VJ3Z800@helium.mailtransaction.com>; Fri, 30 Mar 2012 23:25:52 +0200 (CEST)
Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0M1P00G17VJ1IM00@helium.mailtransaction.com>; Fri, 30 Mar 2012 23:25:51 +0200 (CEST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_WRXvW22UO3VEi5uU4B70QQ)"
Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0M1P0080NVIXKT00@lion.sonnection.nl> for spfbis@ietf.org; Fri, 30 Mar 2012 23:25:46 +0200 (CEST)
Message-id: <4F762676.7030906@sonnection.nl>
Date: Fri, 30 Mar 2012 23:32:38 +0200
From: "Rolf E. Sonneveld" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: "Murray S. Kucherawy" 
References: <9452079D1A51524AA5749AD23E0039280C2AF5@exch-mbx901.corp.cloudmark.com>
In-reply-to: <9452079D1A51524AA5749AD23E0039280C2AF5@exch-mbx901.corp.cloudmark.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009;  t=1333142751; bh=UB6krwqcaYR9xZL6Ak6yjiDflF28EtbVJMOIRHCdk0M=;  h=MIME-version:Content-type:Message-id:Date:From:To:Cc:Subject: References:In-reply-to; b=CtVB4lFf6hs6Bc69D/A/GyXHyVBw/yVBoiXgzgNCaLM7b1+3t7ejPqPrssQOy0QAq fc4xf52s3wWxpmmPPNlR8bV0zvV1VVYJXpCTP3kmWWFpuWyzQ6+B+fG24t0JhJ4IoD 4A7/oODpzQGp18HwLs6mCIEPSwNa3lt0JTchKA5g=
X-DKIM: OpenDKIM Filter v2.4.3 helium.mailtransaction.com 0M1P00I00VJ3Z800
Cc: "spfbis@ietf.org" 
Subject: Re: [spfbis] Experiment document
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, 30 Mar 2012 21:25:55 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_WRXvW22UO3VEi5uU4B70QQ)
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT

Hi, Murray,

thanks for the excellent work to gather these data.

On 3/30/12 12:24 PM, Murray S. Kucherawy wrote:
>
> While we wait for the tools team to sort out the datatracker problem, 
> I'm going to continue revising the draft as an individual submission.
>
> I'm going to add/update the results from my SPF survey first.  And 
> I'll arrange for Scott to get access to my survey data so he can 
> complete his secondary survey.
>
> Dave proposed talking about which questions we'd like to see answered 
> in the experiment document to send to the IESG.  From this, we can 
> figure out if we can already answer those questions or if we need to 
> design and run more surveys.  I propose we start coming up with those 
> questions now.  I'll start by tossing these out, and people should 
> alter/chop/augment these entries:
>
> -What is the relative deployment of SPF vs TXT records?
>
> -How many clients appear to be querying each record type?
>
> -What are counts on records that are specific to Sender-ID (i.e., 
> spf2.0/pra) versus others?
>
> -How much do the Sender-ID results deviate from the SPF results in 
> terms of pass/fail?
>

Not sure I understand this correctly: the output of questions 1 and 3 
can be derived easily by some database queries, but am I correct that 
question 4 requires processing of IP addresses/ranges to see what the 
results are? If so, what is the test set to test with? How do you create 
test sets when include:, redirect: or macro's are used?

> -How often do the validated identifiers differ between SPF and Sender-ID?
>
> -How many implementations of each of the four RFCs are known to 
> exist?  (This is anecdotal, not survey-based.)
>

Add this one:

- distribution of number of DNS queries required to parse the SPF record.

> And the following appendix topics:
>
> -What operational considerations were observed (e.g., firewalls, 
> dropped packets for unknown types)?
>
> -The whole SPF vs. TXT evolution discussion
>
> -How often were non-SPF records found in TXT queries?
>
> Please bash the list now.
>
> I also need to add a paragraph that describes the surveys we've done.  
> I'll add that for mine; Philip, please send me a description of yours, 
> on-list or off.
>

/rolf


--Boundary_(ID_WRXvW22UO3VEi5uU4B70QQ)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT


  
    
  
  
    Hi, Murray,

    

    thanks for the excellent work to gather these data.

    

    On 3/30/12 12:24 PM, Murray S. Kucherawy wrote:
    

      
      
      
      

        
While we wait for the tools team to sort
          out the datatracker problem, I’m going to continue revising
          the draft as an individual submission.

        
 

        
I’m going to add/update the results from my
          SPF survey first.  And I’ll arrange for Scott to get access to
          my survey data so he can complete his secondary survey.

        
 

        
Dave proposed talking about which questions
          we’d like to see answered in the experiment document to send
          to the IESG.  From this, we can figure out if we can already
          answer those questions or if we need to design and run more
          surveys.  I propose we start coming up with those questions
          now.  I’ll start by tossing these out, and people should
          alter/chop/augment these entries:

        
 

        
-         
            What is the relative deployment
          of SPF vs TXT records?

        
-         
            How many clients appear to be
          querying each record type?

        
-         
            What are counts on records that
          are specific to Sender-ID (i.e., spf2.0/pra) versus others?

        
-         
            How much do the Sender-ID
          results deviate from the SPF results in terms of pass/fail?

      

    

    

    Not sure I understand this correctly: the output of questions 1 and
    3 can be derived easily by some database queries, but am I correct
    that question 4 requires processing of IP addresses/ranges to see
    what the results are? If so, what is the test set to test with? How
    do you create test sets when include:, redirect: or macro's are
    used?

     

    

      

        

        
-         
            How often do the validated
          identifiers differ between SPF and Sender-ID?

        
-         
            How many implementations of each
          of the four RFCs are known to exist?  (This is anecdotal, not
          survey-based.)

      

    

    

    Add this one:

    

    - distribution of number of DNS queries required to parse the SPF
    record.

    

    

      

        
 

        
And the following appendix topics:

        
 

        
-         
            What operational considerations
          were observed (e.g., firewalls, dropped packets for unknown
          types)?

        
-         
            The whole SPF vs. TXT evolution
          discussion

        
-         
            How often were non-SPF records
          found in TXT queries?

        
 

        
Please bash the list now.

        
 

        
I also need to add a paragraph that
          describes the surveys we’ve done.  I’ll add that for mine;
          Philip, please send me a description of yours, on-list or off.

      

    

    

    /rolf

    

  


--Boundary_(ID_WRXvW22UO3VEi5uU4B70QQ)--