From vesely@tana.it Fri Mar 1 10:30:53 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAA221F9368 for ; Fri, 1 Mar 2013 10:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.583 X-Spam-Level: X-Spam-Status: No, score=-4.583 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhXDqbTqt4hf for ; Fri, 1 Mar 2013 10:30:53 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D026021F9366 for ; Fri, 1 Mar 2013 10:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1362162651; bh=WBxA51y5LFMZCL/9whACI84PhReb4PGIWZDb3t3gijY=; l=854; h=Date:From:To:References:In-Reply-To; b=T9TvBOljHCbBL4H6Yd5pRxxPnWi2M/XJZLazh6s7otAQZQl5r+zR/67yXuC/R6+ze XBIWA9VQFb4H9Po2FWSh/gVVD3LyuaA/edwKqNyHg50AFGAr4khOmWyZgc/FdhKT5z R3ANP5lr1XPz6ZBMQjS+6miywBQAIxsPCkLQT3ms= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Fri, 01 Mar 2013 19:30:50 +0100 id 00000000005DC044.000000005130F3DA.00003A41 Message-ID: <5130F3DA.7020406@tana.it> Date: Fri, 01 Mar 2013 19:30:50 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <9664703.HH00DzRRtU@scott-latitude-e6320> <512BDA7A.8060005@dcrocker.net> <1813725.CSqLJFfySO@scott-latitude-e6320> <6.2.5.6.2.20130228225826.0a799db8@resistor.net> In-Reply-To: <6.2.5.6.2.20130228225826.0a799db8@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Mar 2013 18:30:53 -0000 On Fri 01/Mar/2013 08:00:21 +0100 S Moonesamy wrote: > At 13:53 25-02-2013, Scott Kitterman wrote: >> What if we redo this section in terms of mediators that change >> mail from to something local to the mediator and mediators that >> leave it unchanged? I think that is the key point and while one >> can make generalizations about which types of mediators do what, >> it may work better to write about this topic primarily in terms >> of how mediators behave relative to mail from than what type of >> mediator they are. > > Are you ok with the above-mentioned approach? I'm not sure what Scott is planning to come out with. Some 5598 terms are not very widespread, and would need to be replaced in contexts such as, say, a wikipedia article on SPF. Their extreme use might lower the comprehensibility/accessibility of the spec, IMHO. From dhc@dcrocker.net Fri Mar 1 18:38:04 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA84321E80CA for ; Fri, 1 Mar 2013 18:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyzpmKjgxRmL for ; Fri, 1 Mar 2013 18:38:01 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C8C9C21E8037 for ; Fri, 1 Mar 2013 18:38:01 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r222c0oe007433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Mar 2013 18:38:01 -0800 Message-ID: <513165FF.1060806@dcrocker.net> Date: Fri, 01 Mar 2013 18:37:51 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Scott Kitterman References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <9664703.HH00DzRRtU@scott-latitude-e6320> <512BDA7A.8060005@dcrocker.net> <1813725.CSqLJFfySO@scott-latitude-e6320> In-Reply-To: <1813725.CSqLJFfySO@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, 01 Mar 2013 18:38:01 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases 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: Sat, 02 Mar 2013 02:38:04 -0000 On 2/25/2013 1:53 PM, Scott Kitterman wrote: >> My core point is that mailing lists are not required to create a new >> >rfc5321.mailfrom address, but it they don't, SPF breaks (absent >> >registration of the mediator in the SPF record. > What if we redo this section in terms of mediators that change mail from to > something local to the mediator and mediators that leave it unchanged? I > think that is the key point and while one can make generalizations about which > types of mediators do what, it may work better to write about this topic > primarily in terms of how mediators behave relative to mail from than what > type of mediator they are. Sounds like a good approach. Describe a known issue, in terms of the behaviors and their effects, without attempting to make normative declarations or even recommendations. In terms of 5598, the label Mediator is defined distinctly as "A Mediator forwards a message through a re-posting process." This includes "RFC5321.RcptTo: Set by - Mediator Author". That sets the stage for the problematic interaction with SPF, if the Mediator chooses to set the RcptTo to be the address from the original posting. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Sat Mar 2 00:25:47 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8755921F8FD8 for ; Sat, 2 Mar 2013 00:25:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHApcbLMCeZQ for ; Sat, 2 Mar 2013 00:25:47 -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 E8ACA21F8FD7 for ; Sat, 2 Mar 2013 00:25:46 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.143.43]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r228PZxr021431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 2 Mar 2013 00:25:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362212745; bh=bdu5iD6wWbeEP27/cZVDqyRfJqA1yvGu6egU26/fIbE=; h=Date:To:From:Subject:In-Reply-To:References; b=dp7FzkFq9SAS12MO5JYaKaDelO2W82eWAZedLfM6b7RCcmQiahTgHjgMVFTwChs5I YDzC4+xBlLeODl9/0XRDe2hPNpQGF3XHmbKi7qC7m44e+YnUYamNtDrIAiw9hCaWLu HqyV2d4f2+wXDc5UQ2vdkc7fL/XJoA3sdwLnXZjY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1362212745; i=@elandsys.com; bh=bdu5iD6wWbeEP27/cZVDqyRfJqA1yvGu6egU26/fIbE=; h=Date:To:From:Subject:In-Reply-To:References; b=m0FzxSZskSQbtoRMMa+ICRineQptqcqC6vWYxQumZ0xmMIc0m0byb5b172uPO9o+b j5f1eqps2q1M3EKbjbZuCmAqRZJjIgM9/yI8QmPrEasPS1ORB6SuO5CqjtvOOVTmHE Db7qmX9gGNmgfJeNAXYIKCclfomTWV5c+wT6BX84= Message-Id: <6.2.5.6.2.20130302002357.0b77b930@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 02 Mar 2013 00:25:24 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <5130F3DA.7020406@tana.it> References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <9664703.HH00DzRRtU@scott-latitude-e6320> <512BDA7A.8060005@dcrocker.net> <1813725.CSqLJFfySO@scott-latitude-e6320> <6.2.5.6.2.20130228225826.0a799db8@resistor.net> <5130F3DA.7020406@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Mar 2013 08:25:47 -0000 Hi Scott, At 10:30 01-03-2013, Alessandro Vesely wrote: >I'm not sure what Scott is planning to come out with. Some 5598 terms >are not very widespread, and would need to be replaced in contexts >such as, say, a wikipedia article on SPF. Their extreme use might >lower the comprehensibility/accessibility of the spec, IMHO. Could you comment on the above? Thanks, S. Moonesamy From spf2@kitterman.com Sat Mar 2 06:11:59 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AE121F8554 for ; Sat, 2 Mar 2013 06:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vA4exzff9ue1 for ; Sat, 2 Mar 2013 06:11:58 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8602621F8551 for ; Sat, 2 Mar 2013 06:11:58 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 82C8BD04087; Sat, 2 Mar 2013 08:11:57 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1362233517; bh=Q9fZWDf39yO2kFBDkdB8T37SZTteJTWORk7mPCMHUmo=; h=In-Reply-To:References:Subject:From:Date:To:From; b=ZbNBDLzv1PHGcxahildCkqS9BEzs3tVFIeC7bctvSjwjiziA3npvYDPNM+gTJoQTH edS9c7QPllUgZL4cMu8udUT0iwtbEoqSXew5BbFePGW5Y/JniOcPJROrOsBGujg8j0 z8VkVcaQqshhUEiiLo/IDrRdHRDkaD3dLdJfXJK4= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 06B70D0405B; Sat, 2 Mar 2013 08:11:56 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130302002357.0b77b930@resistor.net> References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <9664703.HH00DzRRtU@scott-latitude-e6320> <512BDA7A.8060005@dcrocker.net> <1813725.CSqLJFfySO@scott-latitude-e6320> <6.2.5.6.2.20130228225826.0a799db8@resistor.net> <5130F3DA.7020406@tana.it> <6.2.5.6.2.20130302002357.0b77b930@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sat, 02 Mar 2013 09:11:49 -0500 To: spfbis@ietf.org Message-ID: <4d0a367e-aee3-4763-8bae-f8bb13887069@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Mar 2013 14:12:00 -0000 S Moonesamy wrote: >Hi Scott, >At 10:30 01-03-2013, Alessandro Vesely wrote: >>I'm not sure what Scott is planning to come out with. Some 5598 terms >>are not very widespread, and would need to be replaced in contexts >>such as, say, a wikipedia article on SPF. Their extreme use might >>lower the comprehensibility/accessibility of the spec, IMHO. > >Could you comment on the above? I'm not sure either. I didn't writeit yet. Scott K From dhc@dcrocker.net Sat Mar 2 07:57:59 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C7B21F84C9 for ; Sat, 2 Mar 2013 07:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O-WgJIvjoyh for ; Sat, 2 Mar 2013 07:57:59 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E2ACE21F84C8 for ; Sat, 2 Mar 2013 07:57:58 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r22FvwxW031977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 2 Mar 2013 07:57:58 -0800 Message-ID: <5132217E.5060402@dcrocker.net> Date: Sat, 02 Mar 2013 07:57:50 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <9664703.HH00DzRRtU@scott-latitude-e6320> <512BDA7A.8060005@dcrocker.net> <1813725.CSqLJFfySO@scott-latitude-e6320> <6.2.5.6.2.20130228225826.0a799db8@resistor.net> <5130F3DA.7020406@tana.it> <6.2.5.6.2.20130302002357.0b77b930@resistor.net> <4d0a367e-aee3-4763-8bae-f8bb13887069@email.android.com> In-Reply-To: <4d0a367e-aee3-4763-8bae-f8bb13887069@email.android.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]); Sat, 02 Mar 2013 07:57:58 -0800 (PST) Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases 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: Sat, 02 Mar 2013 15:57:59 -0000 >> At 10:30 01-03-2013, Alessandro Vesely wrote: >>> I'm not sure what Scott is planning to come out with. Some 5598 terms >>> are not very widespread, and would need to be replaced in contexts >>> such as, say, a wikipedia article on SPF. Their extreme use might >>> lower the comprehensibility/accessibility of the spec, IMHO. >> >> Could you comment on the above? > > I'm not sure either. I didn't writeit yet. If Alessandro wishes to make specific suggestions for specific changes, the rest of us will be able to comment. Absent that, we'd just be guessing. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From vesely@tana.it Sat Mar 2 22:59:01 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7081121F8626 for ; Sat, 2 Mar 2013 22:59:01 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqS-ZVHT2-dn for ; Sat, 2 Mar 2013 22:59:00 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 788CC21F861A for ; Sat, 2 Mar 2013 22:59:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1362293938; bh=u/U4CA6Hs++O7Ctu70K5LPQZjuI2fDC8coto4VxWy7w=; l=2079; h=Date:From:To:References:In-Reply-To; b=RnrEhpGBsUt9UJbnHr1otLfn5GM8IF7vXhXlCiOVkEqQjhh+tormIius3+NQTezMX cvLI8KO8fKc8ivZY9RC30NSqnSbpD7XGR9MdW+hFKg+9Ahre6DwME6vIedtc4t9VeE t1UcfibAJYEBgTSj9/v+pyr5Z9LfCZTloh2UnLp8= Received: from [10.57.167.221] (93-32-182-24.ip34.fastwebnet.it [93.32.182.24]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Sun, 03 Mar 2013 07:58:57 +0100 id 00000000005DC039.000000005132F4B1.000032A8 Message-ID: <5132F4A8.3040606@tana.it> Date: Sun, 03 Mar 2013 07:58:48 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <9664703.HH00DzRRtU@scott-latitude-e6320> <512BDA7A.8060005@dcrocker.net> <1813725.CSqLJFfySO@scott-latitude-e6320> <6.2.5.6.2.20130228225826.0a799db8@resistor.net> <5130F3DA.7020406@tana.it> <6.2.5.6.2.20130302002357.0b77b930@resistor.net> <4d0a367e-aee3-4763-8bae-f8bb13887069@email.android.com> <5132217E.5060402@dcrocker.net> In-Reply-To: <5132217E.5060402@dcrocker.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Mar 2013 06:59:01 -0000 On Sat 02/Mar/2013 16:57:50 +0100 Dave Crocker wrote: > >>> At 10:30 01-03-2013, Alessandro Vesely wrote: >>>> I'm not sure what Scott is planning to come out with. Some 5598 terms >>>> are not very widespread, and would need to be replaced in contexts >>>> such as, say, a wikipedia article on SPF. Their extreme use might >>>> lower the comprehensibility/accessibility of the spec, IMHO. >>> >>> Could you comment on the above? >> >> I'm not sure either. I didn't writeit yet. > > If Alessandro wishes to make specific suggestions for specific changes, > the rest of us will be able to comment. That section, currently 10.3.2, looks rather good to me. If we need to make it even better, I'd suggest the following changes to the first paragraph: * clarify that "email forwarder" is used as a synonym of "forwarding service" in this document. * Drop "Alias" from the section's title. * Drop citation of RFC 1123, and the term "List", copy and paste Dave's explanation instead. * Separate definition from SPF effect. Update that "near-universal", which was true at the time of writing 4408. None of those points is essential. Applying them all might produce an outcome more or less like so: 10.3.2. Forwarding Services Forwarding services, which we also call email forwarders, take mail that is received at a mailbox and direct it to some external mailbox. [RFC5321] describes this action as an alias expansion. In terms of [RFC5598], the label Mediator is defined distinctly as "A Mediator forwards a message through a re-posting process." This includes "RFC5321.RcptTo: Set by - Mediator Author". At the time of this writing, a large number of such services follow the only practice described by [RFC5321], which is to use the original "MAIL FROM" of a message when re-injecting it for delivery to the external mailbox. This means the external mailbox's MTA sees all such mail in a connection from a host of the forwarding service, and so the "MAIL FROM" identity will not, in general, pass authorization. From superuser@gmail.com Mon Mar 4 23:56:30 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6C921F86F7 for ; Mon, 4 Mar 2013 23:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 w1zvRTwmTZqd for ; Mon, 4 Mar 2013 23:56:29 -0800 (PST) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5FB21F8653 for ; Mon, 4 Mar 2013 23:56:28 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id es5so5093942wgb.17 for ; Mon, 04 Mar 2013 23:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wQTY2/exjz37Rff2KKvhUrGNyCwNMNI4dS+E7m/Q8jw=; b=Sr2DkXUb5jQXG4th8ZBZIpKsC39rcRYHobPWqojWqX4clCGTbRWFqW0R2tzryr9FaM qzTXmJGDZCiIcgPELpQHxMoNemSUgr6ZbAgVU2Kgh7PbHayn5MhKiEdp3APaUvEBjlNO aznGq8fX/RzEEQIr8/o0PJrZiyLYftuJ0/y4uz/cID5knGFv6TeX9/WOsor6QPHkASCf 2Imy0tbemjPdBqdtf1gRHBLGhOX+AYWLG/eeGJZxZTuUlAorBgFs7wtziQS4qWPR9gr3 hm3yjUfaDnck0sw9JFcdu9CZtiNKf360J0q0w/Xz3h6IuOMXNgtGwUChskEYoGJhTDs9 GXpA== MIME-Version: 1.0 X-Received: by 10.194.59.100 with SMTP id y4mr37049591wjq.51.1362470187754; Mon, 04 Mar 2013 23:56:27 -0800 (PST) Received: by 10.180.189.6 with HTTP; Mon, 4 Mar 2013 23:56:27 -0800 (PST) In-Reply-To: <1991186.y8zxGRhPli@scott-latitude-e6320> References: <13841705.Ry8OH4Cp8v@scott-latitude-e6320> <1991186.y8zxGRhPli@scott-latitude-e6320> Date: Mon, 4 Mar 2013 23:56:27 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7b86cea48ef9ca04d728cfbc Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Mar 2013 07:56:30 -0000 --047d7b86cea48ef9ca04d728cfbc Content-Type: text/plain; charset=ISO-8859-1 It looks like the vast majority of this stuff has been resolved in the latest version. I'll touch on the few that still remain open. Other than these, we only have three open tickets (two closely related). Does that mean we're almost done? On Mon, Jul 16, 2012 at 7:30 AM, Scott Kitterman wrote: > > The chatter in Paris suggested simply adding a paragraph before the > > definition of check_host() that says emphatically that this is not an API > > definition, but rather the mechanism is used to illustrate the > algorithm; a > > compliant SPF implementation MUST do something semantically equivalent to > > what we describe for check_host(). Pete said this was probably > > acceptable. It's probably less work than all the s// I did here as well. > > We should probably try that approach, in retrospect. > > OK. I'll take a shot at that in the next revision. Thanks. > I see you've done so at the top of Section 4. However, there are six references to check_host() prior to that point. It might be good to include a short intro paragraph as a new subsection of Section 1 so that those references aren't dangling. Something like: 1.2. check_host() Section 4 introduces an algorithm to evaluate an SPF policy against an arriving email transaction. In an early implementation, this algorithm was encoded in a function called check_host(). That name is used in this document as symbolic of the SPF evaluation algorithm, but of course implementers are not required to use this name. > > > 2.5.6. TempError > > > > > > > > A "temperror" result means that the SPF client encountered a > > > > transient error while performing the check. Checking software can > > > > choose to accept or temporarily reject the message. If the > message > > > > is rejected during the SMTP transaction for this reason, the > software > > > > SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 > > > > enhanced status code. > > > > > > > > [MSK: Do we really need to spell out SMTP reply codes and enhanced > > > > status > > > > codes? Isn't it enough to say those codes are defined in RFC5321 and > > > > RFC3463, and leave it at that?] > > > > > > I think we should. There was an erratum about one of them being > missing > > > and > > > it would be odd to resolve that erratum by removing them all. > > > > > > Additionally, > > > > > > I'm not sure it's 100% obvious. When we were reviewing that erratum, > we > > > discovered RFC 4408 got one of them wrong. I think there is an > > > interoperability point here about consistency that it's worth not > removing > > > text for. > > > > What do others think? I always prefer to refer to other protocols (or > > specific parts of them) rather than copying details from them. > > This always seemed to me like adding specificity, not mere copying. > I'm still partial to omitting these, but I appear to be solo on that one, so I'll let it drop. > > > > For several mechanisms, the is optional. If it is > not > > > > provided, the is used as the . > > > > > > > > [MSK: How are and different? Do we need them > > > both?] > > > > > > Domain-spec is a defined ABNF term. Domain isn't. It's one of the > input > > > arguments to check_host()/CheckHost defined in section 4.1. In the > case > > > of an > > > SPF record like: > > > > > > example.com In TXT "v=spf1 a:mail.example.com -all" > > > > > > the domain is example.com, an input value applicable to the entire > > > evaluation > > > (see redirect= for a limited exception to this) while domain-spec is a > > > property associated with a particular mechanism or modifer. > > > > > > I think they are distinct enough that we ought not try and combine > them. > > > > OK, then I think the right thing would be to say that they are > > syntactically identical, but used in different parts of the evaluation > > process. In ABNF, something like this would do: > > > > domain = > > > > domain-spec = domain > > ; syntactically identical to "domain", but used differently in the > > evaluation > > > > Dave, do you have any other insight here? > > The current ABNF says: > > domain-spec = macro-string domain-end > > So you're proposing changing this to: > > domain-spec = macro-string domain-end / domain > ; syntactically identical to "domain", > but > ; used differently in the evaluation > > This doesn't read quite right to me. I think it's actually the other way > around: > > domain-spec = macro-string domain-end / domain > domain = domain-spec / "input value" > ; either provided as an input for the > ; evaluation process or a domain-spec > used > ; as an input for recursive evaluation > > As I've said before though ABNF is not my thing, so that might be totally > wrong. > Barry, could you comment on this? > > > ip4-network = qnum "." qnum "." qnum "." qnum > > > > qnum = DIGIT ; 0-9 > > > > > > > > / %x31-39 DIGIT ; 10-99 > > > > / "1" 2DIGIT ; 100-199 > > > > / "2" %x30-34 DIGIT ; 200-249 > > > > / "25" %x30-35 ; 250-255 > > > > > > > > ; as per conventional dotted quad notation. e.g., > 192.0.2.0 > > > > > > > > [MSK: Is there really not a reference for this syntax?] > > > > > > There probably is, but we didn't find it in 2005. If someone can dig > it > > > up, I'll add it. > > > > I actually can't find one either. Pete or Dave, perhaps? > > OK. Standing by. > > > > > key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) > > > > > > > > key = "client-ip" / "envelope-from" / "helo" / > > > > > > > > "problem" / "receiver" / "identity" / > > > > > > > > mechanism / name > > > > > > > > identity = "mailfrom" ; for the "MAIL FROM" identity > > > > > > > > / "helo" ; for the "HELO" identity > > > > / name ; other identities > > > > > > > > [MSK: Should "identity" be quoted in the "key" list?] > > I think it should not. > I agree, but it still is in the current version. > > > > > [MSK: There are two paths to "key" generating "name": one direct, one > > > > through "identity"]> > > > > > > Is this a problem? > > > > I thought it was considered an ambiguous grammar in that case, and thus > > "improper". > > > > You should run this through a BNF checker too just to see if any bugs are > > found. There's one on tools.ietf.org someplace. > > I did already. The previous round of ABNF discussion we had we engendered > by > just such a trip to Bill's ABNF checker. > Barry, another ABNF question for you. > > > > > macro-expand = ( "%{" macro-letter transformers *delimiter > "}" ) > > > > > > > > / "%%" / "%_" / "%-" > > > > > > > > [MSK: The "*delimiter" allows this: %{s.-+,/_=.+,..+.} What would > that > > > > mean?]> > > > > > > Good question. It's almost 1AM, so I'm not even going to try and > figure > > > that > > > one out right now. What does it mean? > > > > My point is that the grammar allows it, and I'm not certain we want that. > > What's the point of allowing lots of delimiters? How would one apply > more > > than one? > > One could publish an SPF record that would match multiple sequential > delimiters. That would be odd, and not very useful, but I don't think > it's a > problem. I don't think there's an interoperability benefit to modifying > the > ABNF to prohibit it. > > > > > By default, strings are split on "." (dots). Note that no special > > > > treatment is given to leading, trailing, or consecutive > delimiters, > > > > > > > > [MSK: In input strings, right?] > > > > > > Yes. > > > > So if the "delimiter" part of the ABNF is "+.", what does a parser do? > > Break on +, then within those break on .? Break on either (like strtok() > > does)? > > OK. Now I'm not sure about my previous comment. Let's hold this until the > overall macro discussion is resolved. > What do you think now? :-) -MSK --047d7b86cea48ef9ca04d728cfbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It looks like the vast majority of this stuff has been res= olved in the latest version.=A0 I'll touch on the few that still remain= open.=A0 Other than these, we only have three open tickets (two closely re= lated).=A0 Does that mean we're almost done?

On Mon, Jul 16, 2= 012 at 7:30 AM, Scott Kitterman <spf2@kitterman.com> wrote:=
> The chatter in Paris suggested simply adding a paragraph before the
> definition of check_host() that says emphatically that this is not an = API
> definition, but rather the mechanism is used to illustrate the algorit= hm; a
> compliant SPF implementation MUST do something semantically equivalent= to
> what we describe for check_host(). =A0Pete said this was probably
> acceptable. =A0It's probably less work than all the s// I did here= as well.
> We should probably try that approach, in retrospect.

OK. =A0I'll take a shot at that in the next revision. =A0Th= anks.

I see you've done so at the t= op of Section 4.=A0 However, there are six references to check_host() prior= to that point.=A0 It might be good to include a short intro paragraph as a= new subsection of Section 1 so that those references aren't dangling.= =A0 Something like:

1.2.=A0 check_host()

Section 4 introduces = an algorithm to evaluate an SPF policy against an arriving email transactio= n.=A0 In an early implementation, this algorithm was encoded in a function = called check_host().=A0 That name is used in this document as symbolic of t= he SPF evaluation algorithm, but of course implementers are not required to= use this name.


> > > 2.5.6. =A0TempError
> > >
> > > =A0 =A0A "temperror" result means that the SPF cli= ent encountered a
> > > =A0 =A0transient error while performing the check. =A0Checki= ng software can
> > > =A0 =A0choose to accept or temporarily reject the message. = =A0If the message
> > > =A0 =A0is rejected during the SMTP transaction for this reas= on, the software
> > > =A0 =A0SHOULD use an SMTP reply code of 451 and, if supporte= d, the 4.4.3
> > > =A0 =A0enhanced status code.
> > >
> > > [MSK: Do we really need to spell out SMTP reply codes and en= hanced
> > > status
> > > codes? =A0Isn't it enough to say those codes are defined= in RFC5321 and
> > > RFC3463, and leave it at that?]
> >
> > I think we should. =A0There was an erratum about one of them bein= g missing
> > and
> > it would be odd to resolve that erratum by removing them all.
> >
> > =A0Additionally,
> >
> > I'm not sure it's 100% obvious. =A0When we were reviewing= that erratum, we
> > discovered RFC 4408 got one of them wrong. =A0I think there is an=
> > interoperability point here about consistency that it's worth= not removing
> > text for.
>
> What do others think? =A0I always prefer to refer to other protocols (= or
> specific parts of them) rather than copying details from them.

This always seemed to me like adding specificity, not mere copying.

I'm still partial to omitting = these, but I appear to be solo on that one, so I'll let it drop.
=A0
<= div>> > > =A0 =A0For several mechanisms, the <domain-spec> i= s optional. =A0If it is not
> > > =A0 =A0provided, the <domain> is used as the <targe= t-name>.
> > >
> > > [MSK: How are <domain-spec> and <domain> differe= nt? =A0Do we need them
> > both?]
> >
> > Domain-spec is a defined ABNF term. =A0Domain isn't. =A0It= 9;s one of the input
> > arguments to check_host()/CheckHost defined in section 4.1. =A0In= the case
> > of an
> > SPF record like:
> >
> > example.com = In TXT "v=3Dspf1 a:mail.example.com -all"
> >
> > the domain is ex= ample.com, an input value applicable to the entire
> > evaluation
> > (see redirect=3D for a limited exception to this) while domain-sp= ec is a
> > property associated with a particular mechanism or modifer.
> >
> > I think they are distinct enough that we ought not try and combin= e them.
>
> OK, then I think the right thing would be to say that they are
> syntactically identical, but used in different parts of the evaluation=
> process. =A0In ABNF, something like this would do:
>
> domain =3D <whatever the definition we want to use is>
>
> domain-spec =3D domain
> =A0 ; syntactically identical to "domain", but used differen= tly in the
> evaluation
>
> Dave, do you have any other insight here?

The current ABNF says:

=A0 =A0domain-spec =A0 =A0 =A0=3D macro-string domain-end

So you're proposing changing this to:

=A0 =A0domain-spec =A0 =A0 =A0=3D macro-string domain-end / domain
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 ; syntactically identical to "domain", but
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; u= sed differently in the evaluation

This doesn't read quite right to me. =A0I think it's actually= the other way
around:

=A0 =A0domain-spec =A0 =A0 =A0=3D macro-string domain-end / domain
=A0 =A0domain =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D domain-spec / "input= value"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; e= ither provided as an input for the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; e= valuation process or a domain-spec used
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; a= s an input for recursive evaluation

As I've said before though ABNF is not my thing, so that might be total= ly
wrong.

Barry, could you comment o= n this?

> > > =A0 =A0ip4-network =A0 =A0 =A0=3D qnum= "." qnum "." qnum "." qnum
> > > =A0 =A0qnum =A0 =A0 =A0 =A0 =A0 =A0 =3D DIGIT =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 ; 0-9
> > >
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / %x31-39 DIGIT = =A0 =A0 =A0 ; 10-99
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / "1" = 2DIGIT =A0 =A0 =A0 =A0 =A0; 100-199
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / "2" = %x30-34 DIGIT =A0 ; 200-249
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / "25"= %x30-35 =A0 =A0 =A0 =A0; 250-255
> > >
> > > =A0 =A0 =A0 =A0 =A0 =A0 ; as per conventional dotted quad no= tation. =A0e.g., 192.0.2.0
> > >
> > > [MSK: Is there really not a reference for this syntax?]
> >
> > There probably is, but we didn't find it in 2005. =A0If someo= ne can dig it
> > up, I'll add it.
>
> I actually can't find one either. =A0Pete or Dave, perhaps?

OK. =A0Standing by.

> > > =A0 =A0key-value-pair =A0 =3D key [CFWS] "=3D" ( d= ot-atom / quoted-string )
> > >
> > > =A0 =A0key =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D "client-ip&qu= ot; / "envelope-from" / "helo" /
> > >
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "problem&qu= ot; / "receiver" / "identity" /
> > >
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mechanism / n= ame
> > >
> > > =A0 =A0identity =A0 =A0 =A0 =A0 =3D "mailfrom" =A0= ; for the "MAIL FROM" identity
> > >
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / "helo&quo= t; =A0 =A0 ; for the "HELO" identity
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / name =A0 =A0 = =A0 ; other identities
> > >
> > > [MSK: Should "identity" be quoted in the "key= " list?]

I think it should not.

I ag= ree, but it still is in the current version.
=A0

> > > [MSK: There are two paths to "key" generating &quo= t;name": one direct, one
> > > through "identity"]>
> >
> > Is this a problem?
>
> I thought it was considered an ambiguous grammar in that case, and thu= s
> "improper".
>
> You should run this through a BNF checker too just to see if any bugs = are
> found. =A0There's one on tools.ietf.org someplace.

I did already. =A0The previous round of ABNF discussion we had we eng= endered by
just such a trip to Bill's ABNF checker.
Barry, another ABNF question for you.
=A0

> > > =A0 =A0macro-expand =A0 =A0 =3D ( "%{" macro-lette= r transformers *delimiter "}" )
> > >
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / "%%"= / "%_" / "%-"
> > >
> > > [MSK: The "*delimiter" allows this: %{s.-+,/_=3D.+= ,..+.} =A0What would that
> > > mean?]>
> >
> > Good question. =A0It's almost 1AM, so I'm not even going = to try and figure
> > that
> > one out right now. =A0What does it mean?
>
> My point is that the grammar allows it, and I'm not certain we wan= t that.
> What's the point of allowing lots of delimiters? =A0How would one = apply more
> than one?

One could publish an SPF record that would match multiple sequential<= br> delimiters. =A0That would be odd, and not very useful, but I don't thin= k it's a
problem. =A0I don't think there's an interoperability benefit to mo= difying the
ABNF to prohibit it.

> > > =A0 =A0By default, strings are split on "." (dots)= . =A0Note that no special
> > > =A0 =A0treatment is given to leading, trailing, or consecuti= ve delimiters,
> > >
> > > [MSK: In input strings, right?]
> >
> > Yes.
>
> So if the "delimiter" part of the ABNF is "+.", wh= at does a parser do?
> Break on +, then within those break on .? =A0Break on either (like str= tok()
> does)?

OK. =A0Now I'm not sure about my previous comment. =A0Let's h= old this until the
overall macro discussion is resolved.

=
What do you think now?=A0 :-)

=A0-MSK
--047d7b86cea48ef9ca04d728cfbc-- From barryleiba.mailing.lists@gmail.com Tue Mar 5 07:06:47 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E3621F89A4 for ; Tue, 5 Mar 2013 07:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAmKah68lISx for ; Tue, 5 Mar 2013 07:06:47 -0800 (PST) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id DC38221F89B2 for ; Tue, 5 Mar 2013 07:06:46 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id s24so1305768vbi.36 for ; Tue, 05 Mar 2013 07:06:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=sF7Qop4JLCpO4TqdYuLtASiqKWXhvI+8bm/FRqFxWP8=; b=EVRb9GDPsmT5LDXX7WdP5QtQVcM9at60uw6H/U9dY8QTio/sjkzH8X+KlQ+eXHzxeT 25h+O5VwYoksnxbtO7nThl6EnqkSxxaU5iNHXMYJ68eFTF87fZIQDlJ0dkWA0B5fWbNA JGY/p08FMBanqLk6htdS3MOY/fNrXSZ/+9XKkNwsu34UkpJao6Qka3THSg9zAyC/3bOF OhA46oiDBCnMXuXg0C7SemXkNetA5823Jefkp2pDLxcp0ST9gqpKFWjio8PMHEV2BuG5 lRih8clY6mSEPBecDpB6LXydprhgtbs7GyPHSF8Q3mpk3cjJeMyJO6l/A5VnLNUi04Fi Kz2g== MIME-Version: 1.0 X-Received: by 10.58.106.161 with SMTP id gv1mr9925694veb.35.1362496006115; Tue, 05 Mar 2013 07:06:46 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Tue, 5 Mar 2013 07:06:45 -0800 (PST) In-Reply-To: References: <13841705.Ry8OH4Cp8v@scott-latitude-e6320> <1991186.y8zxGRhPli@scott-latitude-e6320> Date: Tue, 5 Mar 2013 10:06:45 -0500 X-Google-Sender-Auth: gjdsyikFi8dSR6vrWDQPYOyJzB8 Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Mar 2013 15:06:48 -0000 >> > > > For several mechanisms, the is optional. If it is >> > > > not >> > > > provided, the is used as the . >> > > > >> > > > [MSK: How are and different? Do we need them >> > > both?] >> > > >> > > Domain-spec is a defined ABNF term. Domain isn't. It's one of the >> > > input >> > > arguments to check_host()/CheckHost defined in section 4.1. In the >> > > case >> > > of an >> > > SPF record like: >> > > >> > > example.com In TXT "v=spf1 a:mail.example.com -all" >> > > >> > > the domain is example.com, an input value applicable to the entire >> > > evaluation >> > > (see redirect= for a limited exception to this) while domain-spec is a >> > > property associated with a particular mechanism or modifer. >> > > >> > > I think they are distinct enough that we ought not try and combine >> > > them. >> > >> > OK, then I think the right thing would be to say that they are >> > syntactically identical, but used in different parts of the evaluation >> > process. In ABNF, something like this would do: >> > >> > domain = >> > >> > domain-spec = domain >> > ; syntactically identical to "domain", but used differently in the >> > evaluation >> > >> > Dave, do you have any other insight here? >> >> The current ABNF says: >> >> domain-spec = macro-string domain-end >> >> So you're proposing changing this to: >> >> domain-spec = macro-string domain-end / domain >> ; syntactically identical to "domain", >> but >> ; used differently in the evaluation >> >> This doesn't read quite right to me. I think it's actually the other way >> around: >> >> domain-spec = macro-string domain-end / domain >> domain = domain-spec / "input value" >> ; either provided as an input for the >> ; evaluation process or a domain-spec >> used >> ; as an input for recursive evaluation >> >> As I've said before though ABNF is not my thing, so that might be totally >> wrong. > > > Barry, could you comment on this? I think this is confusing because you're mixing syntactic elements with values used in the protocol. We do this often, and it's not usually a problem, but here it can be: if "domain-spec" might be the thing that's in the domain-spec spot in the ABNF, but sometimes might come from the argument to check_host(). Happily, there's already an answer built in, right there in Section 4.8: This domain is called the in the rest of this document. ... For several mechanisms, the is optional. If it is not provided, the is used as the . When you're talking about the syntactic element, use "domain-spec" (without angle-brackets) consistently. When you're talking about the value that's used in an algorithm, which might have come from the domain-spec element or might have come from the argument, use "" consistently. Also happily, you're already mostly doing that, so there's almost no change needed. Any change to the ABNF for this seems quite wrong; please don't do that. I see that "" is used three times with angle-brackets. The first (quoted above), in Section 4.8, should simply lose the brackets. The other two, in Section 5.5, look wrong. I think they should be "", but someone more familiar with the algorithm should check that. (Even though it's in a "do not use" section, we should get it right.) All the uses of "domain-spec" without the angle-brackets look correct to me, as do all the uses of "". The last line of Section 4.8 has "target-name" without angle-brackets, and should be changed. There's also one of those in Section 6.1. So that's it: change the three occurrences of "" and two occurrences of "target-name", and I think everything is clear. If you want to address Murray's confusion, you could say that Murray's being Martian and there's no change needed, or you could just do something like this: OLD For several mechanisms, the is optional. If it is not provided, the is used as the . NEW For several mechanisms, the domain-spec is optional. If it is not provided, the from the check_host() arguments (see Section 4.1) is used as the . END Barry From sm@elandsys.com Tue Mar 5 08:20:05 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C951421F89A4 for ; Tue, 5 Mar 2013 08:20:05 -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 7kgUaL+3yGy5 for ; Tue, 5 Mar 2013 08:20:05 -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 3A3C721F8917 for ; Tue, 5 Mar 2013 08:20:05 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.130.90]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r25GJpet013830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Mar 2013 08:20:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362500404; bh=07vsofsmpfECft/OgAiB+HrR0pIKljHGq2spX9OJskI=; h=Date:To:From:Subject:Cc; b=k5NJk8fpntRkfefwFdhrswaJKkVEXdi1L/zW1vok9LvC2+N7nUScqNXHZHyzNjQ/J FMHCu4VTw0gQSk0jfptnFXyW2yNdo40N3ZXFQNTxMfDtwn6aOAGkyFIjc2B2dZDwO/ RcGouZTaKdYA+RE5hNHZvsaKoVK4hF0cDYEOVEV0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1362500404; i=@elandsys.com; bh=07vsofsmpfECft/OgAiB+HrR0pIKljHGq2spX9OJskI=; h=Date:To:From:Subject:Cc; b=NRxQVyUi6Iy5L9mvHeUMzHM4iQFgv4ngB39pC2ss+gRLLwwD209blSl+FuIJ0gLxQ o6bXoVJT6yHV+yXtO1TSNmTjkqdi622pBD6Gqbcm1910+9QzO3V0KoyjmHPnUhHvb3 J2mCHnoq4+sR/0Su/0Fp3KXmaorBWaEpUfpQCfkk= Message-Id: <6.2.5.6.2.20130305081300.0a0b5b98@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Mar 2013 08:17:47 -0800 To: spfbis@ietf.org, Scott Kitterman From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org Subject: [spfbis] Target date for draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Mar 2013 16:20:05 -0000 The target date for the SPFBIS working group to deliver draft-ietf-spfbis-4408bis to the IESG was December 2012. draft-ietf-spfbis-4408bis is two months late. We would like to set May 2013 as the target date. Please suggest a date if you consider the proposed target date as unrealistic. Note that, in order to meet a date in May, now is an excellent time to start doing comprehensive reviews. Andrew Sullivan & S. Moonesamy, SPFBIS WG co-chairs From superuser@gmail.com Tue Mar 5 11:08:38 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FDB11E812B for ; Tue, 5 Mar 2013 11:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxlTzkJwIXVz for ; Tue, 5 Mar 2013 11:08:37 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 69CD211E812A for ; Tue, 5 Mar 2013 11:08:37 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id d7so6680139wer.8 for ; Tue, 05 Mar 2013 11:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=grUyaNLUxYMHiEJWvMQQVsMLiBdX8YVxznSvqALiYe0=; b=I5aeNHXamvLIT3JBvrvx/m8lO1oyeWrFx1W4ZwygVhzbwPLcXtYSjfY+20h+SLHWBW YUXHwNtheEyjOozNg5jAp37at3XH/ssL2bbv52KD+xq1L2BDeR7EYac/6XhbXCtPZfVt 4lYrS1tE4tkSx3T6hNSg+2a41Hj8HHF26ayrmxtRjtiB/VcIKgBsQeZTZQEwrcUwGLix rpRSssFfi3bbYdHpPCYHqF1p123Vh0S+zFbJjBQc/+X1fWXk7ASjUCS99DoT5qdbw8Ji iqQXoESXYUr7rSHCB+seeBdficHRuAVV4pt+t13d+wgk+eEgswXuHsNTfuNFSIPV1cWn EfGA== MIME-Version: 1.0 X-Received: by 10.194.59.100 with SMTP id y4mr41745632wjq.51.1362510516623; Tue, 05 Mar 2013 11:08:36 -0800 (PST) Received: by 10.180.189.6 with HTTP; Tue, 5 Mar 2013 11:08:36 -0800 (PST) In-Reply-To: <6.2.5.6.2.20130305081300.0a0b5b98@elandnews.com> References: <6.2.5.6.2.20130305081300.0a0b5b98@elandnews.com> Date: Tue, 5 Mar 2013 11:08:36 -0800 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7b86cea458a4b604d73233fe Cc: "spfbis@ietf.org" , spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Target date for draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Mar 2013 19:08:38 -0000 --047d7b86cea458a4b604d73233fe Content-Type: text/plain; charset=ISO-8859-1 Assuming there are no outside reviews that identify major problems, I think May 2013 should be plenty of time to wrap up what appears to be left. On Tue, Mar 5, 2013 at 8:17 AM, S Moonesamy wrote: > The target date for the SPFBIS working group to deliver > draft-ietf-spfbis-4408bis to the IESG was December 2012. > draft-ietf-spfbis-4408bis is two months late. We would like to set May > 2013 as the target date. > > Please suggest a date if you consider the proposed target date as > unrealistic. > > Note that, in order to meet a date in May, now is an excellent time to > start doing comprehensive reviews. > > Andrew Sullivan & S. Moonesamy, SPFBIS WG co-chairs > > ______________________________**_________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/**listinfo/spfbis > --047d7b86cea458a4b604d73233fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Assuming there are no outside reviews that identify major = problems, I think May 2013 should be plenty of time to wrap up what appears= to be left.


On Tue, Mar 5, 2013 at 8:17 AM, S Moonesamy <sm+ietf@elandsys.com= > wrote:
The target date for the SPFBIS working group to deliver draft-ietf-spfbis-4= 408bis to the IESG was December 2012. =A0draft-ietf-spfbis-4408bis is two m= onths late. =A0We would like to set May 2013 as the target date.

Please suggest a date if you consider the proposed target date as unrealist= ic.

Note that, in order to meet a date in May, now is an excellent time to star= t doing comprehensive reviews.

Andrew Sullivan & S. Moonesamy, SPFBIS WG co-chairs

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

--047d7b86cea458a4b604d73233fe-- From dotzero@gmail.com Tue Mar 5 11:14:21 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6209C21F8570 for ; Tue, 5 Mar 2013 11:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tcqn76dxTbvK for ; Tue, 5 Mar 2013 11:14:20 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 94B6621F857A for ; Tue, 5 Mar 2013 11:14:20 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id eb20so6590082lab.31 for ; Tue, 05 Mar 2013 11:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lNX/8cQcQ4Tt2WM7W8g+XiIizBZtIRzGk0cusT7rgJU=; b=VF6ZuhhHB1sYw4wO5+wJThi7MFEs7iakr87Ok+YMUqlpP74UqB5uBsYyqXqvfXpc2L A4xqNAwyZ1+iqQeFnA996an3mrary+nxi06HJ217LXJOyNT4w85Zo6SR6xdoesOrZ7L8 udvO0NmlGU9NWuCLbuq13ofgcF9DHy4/i8MJcpLlXbKCXVT8Wa9PRPZJL0TOhxQxwBvB WSMJeXntgHr21+WUDCUBaAi+pD09fHDrlar01P8pShlex0pgE25kvOKAhRqgv4dixgDA XBjwd17UTUEjp/aYMzrSmQ7jT9DOCctuoorUcoKnTHLKXzSF554aT3+rQdqBne7giNeQ iAGA== MIME-Version: 1.0 X-Received: by 10.152.144.202 with SMTP id so10mr22792753lab.9.1362510859477; Tue, 05 Mar 2013 11:14:19 -0800 (PST) Received: by 10.112.48.133 with HTTP; Tue, 5 Mar 2013 11:14:19 -0800 (PST) In-Reply-To: References: <6.2.5.6.2.20130305081300.0a0b5b98@elandnews.com> Date: Tue, 5 Mar 2013 14:14:19 -0500 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" , spfbis-chairs@tools.ietf.org, S Moonesamy Subject: Re: [spfbis] Target date for draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Mar 2013 19:14:21 -0000 I would agree with Murray. I have been pretty quiet throughout the SPFBIS process but have more time to spend on it. Mike On Tue, Mar 5, 2013 at 2:08 PM, Murray S. Kucherawy wrote: > Assuming there are no outside reviews that identify major problems, I think > May 2013 should be plenty of time to wrap up what appears to be left. > > > On Tue, Mar 5, 2013 at 8:17 AM, S Moonesamy wrote: >> >> The target date for the SPFBIS working group to deliver >> draft-ietf-spfbis-4408bis to the IESG was December 2012. >> draft-ietf-spfbis-4408bis is two months late. We would like to set May 2013 >> as the target date. >> >> Please suggest a date if you consider the proposed target date as >> unrealistic. >> >> Note that, in order to meet a date in May, now is an excellent time to >> start doing comprehensive reviews. >> >> Andrew Sullivan & S. Moonesamy, SPFBIS WG co-chairs >> >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis > > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From spf2@kitterman.com Tue Mar 5 15:24:22 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1286911E8122 for ; Tue, 5 Mar 2013 15:24:22 -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 YumpWqd4X3-b for ; Tue, 5 Mar 2013 15:24:21 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6E20211E809C for ; Tue, 5 Mar 2013 15:24:21 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 80AC620E4167; Tue, 5 Mar 2013 18:24:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1362525860; bh=o5RpxLX4ZbJgYnreUcP3P/kiwYkI5nLYF84ZFMZUszc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FuKfxCYiSXNm52rdUnIJyPZFczkK/sOUjOgFZ6TAak6+b0CluDwJwepZezrYallGT usrg9Ht/zvWDa3U22rf4miEzCToNHi4WMKZMxL0fzK0EtK/xkdPYudK+wfVsZVj80b II7RQ0EAJEx0+pNPdPPleL91tJQuQRwGUjoqLDTw= Received: from scott-latitude-e6320.localnet (153.sub-70-192-207.myvzw.com [70.192.207.153]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5473220E40F9; Tue, 5 Mar 2013 18:24:19 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Date: Tue, 05 Mar 2013 18:24:18 -0500 Message-ID: <8793345.v9WZyjdpps@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-25-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130305081300.0a0b5b98@elandnews.com> References: <6.2.5.6.2.20130305081300.0a0b5b98@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: S Moonesamy Subject: Re: [spfbis] Target date for draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Mar 2013 23:24:22 -0000 On Tuesday, March 05, 2013 08:17:47 AM S Moonesamy wrote: > The target date for the SPFBIS working group to deliver > draft-ietf-spfbis-4408bis to the IESG was December > 2012. draft-ietf-spfbis-4408bis is two months late. We would like > to set May 2013 as the target date. > > Please suggest a date if you consider the proposed target date as > unrealistic. > > Note that, in order to meet a date in May, now is an excellent time > to start doing comprehensive reviews. > > Andrew Sullivan & S. Moonesamy, SPFBIS WG co-chairs I suspect that the last few issues are going to take a bit of time to get right (and get something resembling rough consensus), it seems slightly ambitious to me, but I wouldn't call it unrealistic. I think it's a bit sporting, but not unrealistic. Scott K From sm@elandsys.com Wed Mar 6 11:02:42 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58B021F88BC for ; Wed, 6 Mar 2013 11:02:42 -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 ZvGs1nLrX0tq for ; Wed, 6 Mar 2013 11:02:37 -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 C471B21F8910 for ; Wed, 6 Mar 2013 11:02:34 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.159.92]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r26J2GJW002763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 Mar 2013 11:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362596547; bh=15JIjuLxK9RXNVQqWUzwYuKCQ/fzY3chs3JTZopc14Y=; h=Date:To:From:Subject:In-Reply-To:References; b=R/eLQYEKzNcO5M+m1RTxSDEdFHVRZYwls0LwclnbATlMYcSPLnPYsiinrAX4V67NI nBU+eQFBf45hgIOem/gABz/dpfBvo8o9HEeyXHTIxD0ZntS3iJrtCUOp2Pb+0WNSuM 9Ha4CLVfddFRrIaJkryD251MMD/dli9CmKucv2gE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1362596547; i=@elandsys.com; bh=15JIjuLxK9RXNVQqWUzwYuKCQ/fzY3chs3JTZopc14Y=; h=Date:To:From:Subject:In-Reply-To:References; b=gzRDvFWGAbu4kJC56ax1yoT2VPNW09IYpH8mHAdOzTSSII3jU+Q70DyQzvWWmucfg oA3PFagKTQtRViBl71LpJHKi/nJ0xo4Bbc0jjnEHBhAbMXE71RZ+B3wEf1qU7fAuaj B1Zqq+xeMtcJpOMVfw/Qw+r6NgJDw3eQuKfSjKR4= Message-Id: <6.2.5.6.2.20130306105548.0c8c7208@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Mar 2013 11:00:37 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4d0a367e-aee3-4763-8bae-f8bb13887069@email.android.com> References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <9664703.HH00DzRRtU@scott-latitude-e6320> <512BDA7A.8060005@dcrocker.net> <1813725.CSqLJFfySO@scott-latitude-e6320> <6.2.5.6.2.20130228225826.0a799db8@resistor.net> <5130F3DA.7020406@tana.it> <6.2.5.6.2.20130302002357.0b77b930@resistor.net> <4d0a367e-aee3-4763-8bae-f8bb13887069@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Mar 2013 19:02:43 -0000 Hi Scott, At 06:11 02-03-2013, Scott Kitterman wrote: >I'm not sure either. I didn't writeit yet. Alessandro Vesely suggested some text at http://www.ietf.org/mail-archive/web/spfbis/current/msg03295.html Can that text be used or would you like to suggest text? Regards, S. Moonesamy From spf2@kitterman.com Wed Mar 6 11:06:03 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AFC21F85DC for ; Wed, 6 Mar 2013 11:06:03 -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 lzuVJrmqwn6c for ; Wed, 6 Mar 2013 11:05:59 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id DBBA921F852B for ; Wed, 6 Mar 2013 11:05:54 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3E3E120E411E; Wed, 6 Mar 2013 14:05:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1362596754; bh=rdK8uslEeEkDjzN/d8gY7DU7AkCd9rJxSybIsQycH2M=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WGrTDW95Ka/M4nXpoNY/rMHMYFCdWVxcN+EtSHhJCtxVvyLqjflij4ZWXhJEMOv6x evv7+xSDwmivO82hw3veDxh12sk33JPp/qLnZ6ONO5B/r85QtJHnzsShr0fHlCPt6M +ZUV70w/lECh5fsMO0Mk9/r/NGMy+JT2h13wn098= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2144220E40BB; Wed, 6 Mar 2013 14:05:53 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 06 Mar 2013 14:05:50 -0500 Message-ID: <8862382.mu1ZUkx3Jf@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-25-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130306105548.0c8c7208@resistor.net> References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <4d0a367e-aee3-4763-8bae-f8bb13887069@email.android.com> <6.2.5.6.2.20130306105548.0c8c7208@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] #56: Section 9.2.2 Forwarding Services and Aliases X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Mar 2013 19:06:03 -0000 On Wednesday, March 06, 2013 11:00:37 AM S Moonesamy wrote: > Hi Scott, > > At 06:11 02-03-2013, Scott Kitterman wrote: > >I'm not sure either. I didn't writeit yet. > > Alessandro Vesely suggested some text at > http://www.ietf.org/mail-archive/web/spfbis/current/msg03295.html > Can that text be used or would you like to suggest text? I don't think that suggestion really addresses the issue. I do plan on tackling it, possibly this weekend. Scott K From superuser@gmail.com Thu Mar 14 12:40:36 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FA211E8217 for ; Thu, 14 Mar 2013 12:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 EGBn56qvEBLK for ; Thu, 14 Mar 2013 12:40:35 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3445211E820F for ; Thu, 14 Mar 2013 12:40:35 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id fm10so2344260wgb.33 for ; Thu, 14 Mar 2013 12:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Y1sJrAW9wJCOw12G2dxaW/skeV0vLhxhe9Y9gl3dOdI=; b=vdDGohvCdK11X8YsFXvPQ3woo9LTlJC/VlzqpGUV8xW2lbHtEwSXGouCjWRmSbjNZ0 B7JlZqNaBFp4MEOhHFqxbqdmHVktcBgWZNylsmBSjSd2jEP4YykBkIK3bm3NyvU8K6im 8MzVnCVyQsLA0gE8T6POWiv/79/mT5eipGu1Nkh2VTPD9PQa1xNQm1KhW0fOCPhzYjUb Eej4iSzYKLM+0aOlW2zrFLQQARKIFoleKvlmkkKEnIO/j+1VqMhb+KjxQFmQLOhMpZuS 90p1Qs3ZGz3wKg7KrCpjFEg2M9JWU9g5If0P55Z3JmeYE8Pa+oSvrqVJ6RscMRgTTxE2 XPAA== MIME-Version: 1.0 X-Received: by 10.194.59.100 with SMTP id y4mr6571041wjq.51.1363290034419; Thu, 14 Mar 2013 12:40:34 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Thu, 14 Mar 2013 12:40:34 -0700 (PDT) Date: Thu, 14 Mar 2013 15:40:34 -0400 Message-ID: From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=047d7b86cea43a3dd604d7e7b2cf Subject: [spfbis] draft-kucherawy-rfc5451bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Mar 2013 19:40:36 -0000 --047d7b86cea43a3dd604d7e7b2cf Content-Type: text/plain; charset=ISO-8859-1 [also posted to apps-discuss] I've uploaded an update to draft-kucherawy-rfc5451bis for review. It incorporates the feedback I've received over the last few months since the last version. https://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis/ To recap: RFC5451 defines a standard message header field for recording the results of things like DKIM and SPF by border MTAs so internal things like MUAs don't have to repeat those checks. This is an update draft based on operational experience since the proposed standard was originally published in 2009. So, two things: 1) Reviewers, please! I think this is pretty much ready to go as it's been around since last June with some reviews, but nothing lately. A final glance by some of the apps community (especially mail people) would be grand. 2) I'd like to process this through APPSAWG. Salvatore would have to shepherd it since I can't shepherd my own document. Is that a reasonable path for this work? There isn't an active working group doing SMTP things, and we know our ADs would prefer to avoid sponsoring things if possible. Thanks, -MSK --047d7b86cea43a3dd604d7e7b2cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[also posted to apps-discuss]

I= 've uploaded an update to=20 draft-kucherawy-rfc5451bis for review.=A0 It incorporates the feedback=20 I've received over the last few months since the last version.

<= a href=3D"https://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis/">htt= ps://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis/

To recap: RFC5451 defines a standard message header field for recording=20 the results of things like DKIM and SPF by border MTAs so internal=20 things like MUAs don't have to repeat those checks.=A0 This is an updat= e draft based on operational experience since the proposed standard was ori= ginally published in 2009.

So, two things:

1) Reviewers, please!=A0 I think this is pretty much ready to go as it's= =20 been around since last June with some reviews, but nothing lately.=A0 A=20 final glance by some of the apps community (especially mail people)=20 would be grand.

2) I'd like to process this through=20 APPSAWG.=A0 Salvatore would have to shepherd it since I can't shepherd = my=20 own document.=A0 Is that a reasonable path for this work?=A0 There isn'= t an=20 active working group doing SMTP things, and we know our ADs would prefer to avoid sponsoring things if possible.

Thanks,
-MSK
--047d7b86cea43a3dd604d7e7b2cf-- From spf2@kitterman.com Sat Mar 16 10:40:42 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E8A21F8858 for ; Sat, 16 Mar 2013 10:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 nqRAN8nr6dVo for ; Sat, 16 Mar 2013 10:40:41 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A48D621F8610 for ; Sat, 16 Mar 2013 10:40:41 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6C26A20E4113; Sat, 16 Mar 2013 13:40:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1363455640; bh=2eNdyeO6r9F5H8QQg/LCtt0Idm5K+2+ueweHc81kycs=; h=From:To:Subject:Date:From; b=nK0Bj+lVulHpKnJgz2QabQe0wJgvFqh0vWqkKCzxzG3amL/ogKDXdCvbLgBOqlYhf Sr+SJSYjPyuRaooFO2vPoFzMzFMFm1Rb/gfOQbyxK6oV3WJpClicl7atp6oQczZMPe iS1mAJXpV2tI/9HsT6Avj7HjdixYcNFyVHrKe37M= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1E39F20E4062; Sat, 16 Mar 2013 13:40:39 -0400 (EDT) From: Scott Kitterman To: "spfbis@ietf.org" Date: Sat, 16 Mar 2013 13:40:39 -0400 Message-ID: <45461426.5BMDfefsaY@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-25-generic; KDE/4.9.5; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Reasonable DNS error limits #24 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Mar 2013 17:40:42 -0000 This is one of the few open issues we have remaining: http://trac.tools.ietf.org/wg/spfbis/trac/ticket/24 > 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. This "No Data limit" is already widely deployed as part of the modern Perl SPF implementation, Mail::SPF. This is documented at: http://search.cpan.org/~jmehnle/Mail-SPF-v2.8.0/lib/Mail/SPF/Server.pm > max_void_dns_lookups > > An integer 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 (NXDOMAIN) before processing is aborted with a > permerror result. If undef is specified, there is no stricter limit on > the number of void DNS look-ups beyond the usual processing limits. > Defaults to 2. > > Specifically, the DNS look-ups that are subject to this limit are those > caused by the a, mx, ptr, and exists mechanisms and the p macro. > > A value of 2 is likely to prevent effective DoS attacks against > third-party victim domains. However, a definite limit may cause > permerror results even with certain (overly complex) innocent sender > policies where useful results would normally be returned. The default of 2 has been in place since version 2.006, released on 2008-08-17. I had hoped to have time (or find someone else who had time) to use the results of Murray's previous SPF record survey to quantify the impact this might have on existing records, but have not succeeded. Given that this has been in place, by default, for over 4 years on a very popular (using the Debian GNU/Linux distribution popcon (popularity contest) data, I would estimate that Mail::SPF is installed in almost 10% of Debian systems - it is by far the most popular SPF implementation in the distribution) implementation, I think it is, however, reasonable to assume that if it caused significant problems, they would have come up by now. I did check with the primary developer (Julian Mehnle) and he is not aware of people having problems with it. The only places a no data result will occur that are not due to a problem in the record are for exists which do not match the given criteria and for ptr (and p macro) if the connect IP has no reverse DNS. The Mail::SPF limit of two allows for both these issues to occur in a record without raising an error. My proposal is that we add this as a new limit in section 4.6.4, DNS Lookup Limits, to resolve this issue. I think it's a useful limit, unlikely to cause backward compatibility issues, and in scope for consideration due to long term, wide spread deployment. If there is some consensus around the concept, then we can come up with specific text for 4.6.4, but I think it's useful to discuss the concept first. Scott K From spf2@kitterman.com Sat Mar 16 11:17:10 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1378A21F8845 for ; Sat, 16 Mar 2013 11:17:10 -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=1.000, 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 WGd1IKpaQePi for ; Sat, 16 Mar 2013 11:17:09 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C3EF721F883E for ; Sat, 16 Mar 2013 11:17:08 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D3AAE20E4113; Sat, 16 Mar 2013 14:17:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1363457825; bh=C2mlbbrIyNYEeA7d/YyPHLraTkCQml67LpfPoJ0Ix4Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mnx2iEQLHYMmXw6dC3DOCF3Nn6PQQKnzFZH6VWrBZr9M0NgPDQlbZXx7x87IrTN6J kvmyHOQd+rlXASWldTtEK2zWn/rKsVIWU+GV+WLH9QLOE5saPXoJoti8+DV4N9u8LS vJPbpe0iPIDEDoo2QHVZu4tmm+gvUkxCXD4buBNc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B5E3B20E4062; Sat, 16 Mar 2013 14:17:05 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 16 Mar 2013 14:17:01 -0400 Message-ID: <3005266.bpAoHDOQkP@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-25-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <1991186.y8zxGRhPli@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] Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Mar 2013 18:17:10 -0000 On Monday, March 04, 2013 11:56:27 PM Murray S. Kucherawy wrote: > It looks like the vast majority of this stuff has been resolved in the > latest version. I'll touch on the few that still remain open. Other than > these, we only have three open tickets (two closely related). Does that > mean we're almost done? > > On Mon, Jul 16, 2012 at 7:30 AM, Scott Kitterman wrote: > > > The chatter in Paris suggested simply adding a paragraph before the > > > definition of check_host() that says emphatically that this is not an > > > API > > > definition, but rather the mechanism is used to illustrate the > > > > algorithm; a > > > > > compliant SPF implementation MUST do something semantically equivalent > > > to > > > what we describe for check_host(). Pete said this was probably > > > acceptable. It's probably less work than all the s// I did here as > > > well. > > > We should probably try that approach, in retrospect. > > > > OK. I'll take a shot at that in the next revision. Thanks. > > I see you've done so at the top of Section 4. However, there are six > references to check_host() prior to that point. It might be good to > include a short intro paragraph as a new subsection of Section 1 so that > those references aren't dangling. Something like: > > 1.2. check_host() > > Section 4 introduces an algorithm to evaluate an SPF policy against an > arriving email transaction. In an early implementation, this algorithm was > encoded in a function called check_host(). That name is used in this > document as symbolic of the SPF evaluation algorithm, but of course > implementers are not required to use this name. Done. > > > > 2.5.6. TempError > > > > > > > > > A "temperror" result means that the SPF client encountered a > > > > > transient error while performing the check. Checking software > > > > > can > > > > > choose to accept or temporarily reject the message. If the > > > > message > > > > > > > is rejected during the SMTP transaction for this reason, the > > > > software > > > > > > > SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 > > > > > enhanced status code. > > > > > > > > > > [MSK: Do we really need to spell out SMTP reply codes and enhanced > > > > > status > > > > > codes? Isn't it enough to say those codes are defined in RFC5321 > > > > > and > > > > > RFC3463, and leave it at that?] > > > > > > > > I think we should. There was an erratum about one of them being > > missing and > > > > it would be odd to resolve that erratum by removing them all. > > > > Additionally, > > > > I'm not sure it's 100% obvious. When we were reviewing that erratum, > > we discovered RFC 4408 got one of them wrong. I think there is an > > > > interoperability point here about consistency that it's worth not > > removing text for. > > > > > > What do others think? I always prefer to refer to other protocols (or > > > specific parts of them) rather than copying details from them. > > > > This always seemed to me like adding specificity, not mere copying. > > I'm still partial to omitting these, but I appear to be solo on that one, > so I'll let it drop. Thanks. > > > > > For several mechanisms, the is optional. If it is > > not provided, the is used as the . > > > > > [MSK: How are and different? Do we need them > > > > both?] > > > > Domain-spec is a defined ABNF term. Domain isn't. It's one of the > > inputarguments to check_host()/CheckHost defined in section 4.1. In the > > caseof an SPF record like: > > > > > > > > example.com In TXT "v=spf1 a:mail.example.com -all" > > > > > > > > the domain is example.com, an input value applicable to the entire > > > > evaluation > > > > (see redirect= for a limited exception to this) while domain-spec is a > > > > property associated with a particular mechanism or modifer. > > > > > > > > I think they are distinct enough that we ought not try and combine > > them. > > > > > OK, then I think the right thing would be to say that they are > > > syntactically identical, but used in different parts of the evaluation > > > process. In ABNF, something like this would do: > > > > > > domain = > > > > > > domain-spec = domain > > > > > > ; syntactically identical to "domain", but used differently in the > > > > > > evaluation > > > > > > Dave, do you have any other insight here? > > > > The current ABNF says: > > domain-spec = macro-string domain-end > > > > So you're proposing changing this to: > > domain-spec = macro-string domain-end / domain > > > > ; syntactically identical to "domain", > > > > but > > > > ; used differently in the evaluation > > > > This doesn't read quite right to me. I think it's actually the other way > > > > around: > > domain-spec = macro-string domain-end / domain > > domain = domain-spec / "input value" > > > > ; either provided as an input for the > > ; evaluation process or a domain-spec > > > > used > > > > ; as an input for recursive evaluation > > > > As I've said before though ABNF is not my thing, so that might be totally > > wrong. > > Barry, could you comment on this? Barry did comment. Will follow up to his reply. > > > > ip4-network = qnum "." qnum "." qnum "." qnum > > > > > > > > > qnum = DIGIT ; 0-9 > > > > > > > > > > / %x31-39 DIGIT ; 10-99 > > > > > / "1" 2DIGIT ; 100-199 > > > > > / "2" %x30-34 DIGIT ; 200-249 > > > > > / "25" %x30-35 ; 250-255 > > > > > > > > > > ; as per conventional dotted quad notation. e.g., > > 192.0.2.0 > > > > > > > [MSK: Is there really not a reference for this syntax?] > > > > > > > > There probably is, but we didn't find it in 2005. If someone can dig > > it up, I'll add it. > > > > > > I actually can't find one either. Pete or Dave, perhaps? > > > > OK. Standing by. > > > > > > > key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) > > > > > > > > > > key = "client-ip" / "envelope-from" / "helo" / > > > > > > > > > > "problem" / "receiver" / "identity" / > > > > > > > > > > mechanism / name > > > > > > > > > > identity = "mailfrom" ; for the "MAIL FROM" identity > > > > > > > > > > / "helo" ; for the "HELO" identity > > > > > / name ; other identities > > > > > > > > > > [MSK: Should "identity" be quoted in the "key" list?] > > > > I think it should not. > > I agree, but it still is in the current version. Via a separate discussion, we resolved this the other way around. identity and mechanism are now both quoted. The 4408 ABNF was wrong, but backwards from what I originally thought. > > > > > [MSK: There are two paths to "key" generating "name": one direct, > > > > > one > > > > > through "identity"]> > > > > > > > > Is this a problem? > > > > > > I thought it was considered an ambiguous grammar in that case, and thus > > > "improper". > > > > > > You should run this through a BNF checker too just to see if any bugs > > > are > > > found. There's one on tools.ietf.org someplace. > > > > I did already. The previous round of ABNF discussion we had we engendered > > by just such a trip to Bill's ABNF checker. > > Barry, another ABNF question for you. I think we've resolved this one in -11. > > > > > macro-expand = ( "%{" macro-letter transformers *delimiter > > > > "}" ) > > > > > > > / "%%" / "%_" / "%-" > > > > > > > > > > [MSK: The "*delimiter" allows this: %{s.-+,/_=.+,..+.} What would > > that mean?]> > > > > > > > > Good question. It's almost 1AM, so I'm not even going to try and > > > > figure that one out right now. What does it mean? > > > > > > My point is that the grammar allows it, and I'm not certain we want > > > that. > > > What's the point of allowing lots of delimiters? How would one apply > > > more than one? > > > > One could publish an SPF record that would match multiple sequential > > delimiters. That would be odd, and not very useful, but I don't think > > it's a > > problem. I don't think there's an interoperability benefit to modifying > > the > > ABNF to prohibit it. > > > > > > > By default, strings are split on "." (dots). Note that no special > > > > > treatment is given to leading, trailing, or consecutive > > delimiters, > > > > > > > [MSK: In input strings, right?] > > > > > > > > Yes. > > > > > > So if the "delimiter" part of the ABNF is "+.", what does a parser do? > > > Break on +, then within those break on .? Break on either (like > > > strtok() > > > does)? > > > > OK. Now I'm not sure about my previous comment. Let's hold this until > > the > > overall macro discussion is resolved. > > What do you think now? :-) I think it's not causing problems, we ought not to mess with it. Scott K From spf2@kitterman.com Sat Mar 16 12:14:27 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16F521F8780 for ; Sat, 16 Mar 2013 12:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 XJTC7A+aP6A6 for ; Sat, 16 Mar 2013 12:14:26 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFF521F8444 for ; Sat, 16 Mar 2013 12:14:26 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E24E120E4113; Sat, 16 Mar 2013 15:14:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1363461265; bh=JpBmS0seUzE8xPHL6IYd4zQ08gSfM+qTAsUrSUW0aYU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kQ/DSYoZkhiMm42bjqUoeWDL171NWGro1+/fBZHUrVQyx31PSG88F/FPo1PChTlof D+DxAPNVUV+OWSNnOb+MydwuLoygxzR8w2fQ1lfrpelbn9buiD7CQs6CeuLDAJ/2Ow w/DBCoR/Mkg0JmZQ/ZZ+XWFjBDqCKfbVwHFQbr1g= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 91DFB20E4062; Sat, 16 Mar 2013 15:14:25 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 16 Mar 2013 15:14:24 -0400 Message-ID: <21650898.kGunOTsKji@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-25-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Mar 2013 19:14:27 -0000 On Tuesday, March 05, 2013 10:06:45 AM Barry Leiba wrote: > >> > > > For several mechanisms, the is optional. If it is > >> > > > > >> > > > not > >> > > > > >> > > > provided, the is used as the . > >> > > > > >> > > > [MSK: How are and different? Do we need > >> > > > them > >> > > > >> > > both?] > >> > > > >> > > Domain-spec is a defined ABNF term. Domain isn't. It's one of the > >> > > input > >> > > arguments to check_host()/CheckHost defined in section 4.1. In the > >> > > case > >> > > of an > >> > > SPF record like: > >> > > > >> > > example.com In TXT "v=spf1 a:mail.example.com -all" > >> > > > >> > > the domain is example.com, an input value applicable to the entire > >> > > evaluation > >> > > (see redirect= for a limited exception to this) while domain-spec is > >> > > a property associated with a particular mechanism or modifer. > >> > > > >> > > I think they are distinct enough that we ought not try and combine > >> > > them. > >> > > >> > OK, then I think the right thing would be to say that they are > >> > syntactically identical, but used in different parts of the evaluation > >> > process. In ABNF, something like this would do: > >> > > >> > domain = > >> > > >> > domain-spec = domain > >> > ; syntactically identical to "domain", but used differently in the > >> > evaluation > >> > > >> > Dave, do you have any other insight here? > >> > >> The current ABNF says: > >> domain-spec = macro-string domain-end > >> > >> So you're proposing changing this to: > >> domain-spec = macro-string domain-end / domain > >> > >> ; syntactically identical to > >> "domain", > >> > >> but > >> > >> ; used differently in the evaluation > >> > >> This doesn't read quite right to me. I think it's actually the other way > >> > >> around: > >> domain-spec = macro-string domain-end / domain > >> domain = domain-spec / "input value" > >> > >> ; either provided as an input for the > >> ; evaluation process or a domain-spec > >> > >> used > >> > >> ; as an input for recursive > >> evaluation > >> > >> As I've said before though ABNF is not my thing, so that might be totally > >> wrong. > > > > Barry, could you comment on this? > > I think this is confusing because you're mixing syntactic elements > with values used in the protocol. We do this often, and it's not > usually a problem, but here it can be: if "domain-spec" might be the > thing that's in the domain-spec spot in the ABNF, but sometimes might > come from the argument to check_host(). > > Happily, there's already an answer built in, right there in Section 4.8: > > This > domain is called the in the rest of this document. > ... > For several mechanisms, the is optional. If it is not > provided, the is used as the . > > When you're talking about the syntactic element, use "domain-spec" > (without angle-brackets) consistently. When you're talking about the > value that's used in an algorithm, which might have come from the > domain-spec element or might have come from the argument, use > "" consistently. > > Also happily, you're already mostly doing that, so there's almost no > change needed. Any change to the ABNF for this seems quite wrong; > please don't do that. > > I see that "" is used three times with angle-brackets. > The first (quoted above), in Section 4.8, should simply lose the > brackets. The other two, in Section 5.5, look wrong. I think they > should be "", but someone more familiar with the > algorithm should check that. (Even though it's in a "do not use" > section, we should get it right.) Done and I agree the ones in 5.5 should be changed to target-name. > All the uses of "domain-spec" without the angle-brackets look correct > to me, as do all the uses of "". The last line of > Section 4.8 has "target-name" without angle-brackets, and should be > changed. There's also one of those in Section 6.1. Done. > So that's it: change the three occurrences of "" and two > occurrences of "target-name", and I think everything is clear. If you > want to address Murray's confusion, you could say that Murray's being > Martian and there's no change needed, or you could just do something > like this: > > OLD > For several mechanisms, the is optional. If it is not > provided, the is used as the . > > NEW > For several mechanisms, the domain-spec is optional. If it is not > provided, the from the check_host() arguments (see > Section 4.1) is used as the . > > END Done also. Thank you for the detailed analysis and recommendations. Scott K From spf2@kitterman.com Sat Mar 16 13:01:34 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2172021F8628 for ; Sat, 16 Mar 2013 13:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 4LxBnzx0+tPp for ; Sat, 16 Mar 2013 13:01:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1268421F855C for ; Sat, 16 Mar 2013 13:01:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 829EE20E4113; Sat, 16 Mar 2013 16:01:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1363464092; bh=OLSiTwsf7xNnthjrD3NegkVc0321oE3P1N31H/ktc7g=; h=From:To:Subject:Date:In-Reply-To:References:From; b=W2v1WoYKAbLHWWc8Xjd7fBdonKwBDhJ9qReI3zGueEYbA+SaM3x25gePQ8TGIHFgh i5nev4Mk93xMUDVuLftJz+EMASPOA0FbcXqsz9OoDOSDTTBl46Nsu5TRMbktUgLqWM kVbZ635UGbKQ4nrbzyl405zd3I0byDCSeWLbODds= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 64C9A20E4062; Sat, 16 Mar 2013 16:01:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 16 Mar 2013 16:01:31 -0400 Message-ID: <2462034.aoBIrkDmzC@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-25-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <5132F4A8.3040606@tana.it> References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <5132217E.5060402@dcrocker.net> <5132F4A8.3040606@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] #56: Section 9.2.2 Forwarding Services and Aliases X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Mar 2013 20:01:34 -0000 On Sunday, March 03, 2013 07:58:48 AM Alessandro Vesely wrote: > On Sat 02/Mar/2013 16:57:50 +0100 Dave Crocker wrote: > >>> At 10:30 01-03-2013, Alessandro Vesely wrote: > >>>> I'm not sure what Scott is planning to come out with. Some 5598 terms > >>>> are not very widespread, and would need to be replaced in contexts > >>>> such as, say, a wikipedia article on SPF. Their extreme use might > >>>> lower the comprehensibility/accessibility of the spec, IMHO. > >>> > >>> Could you comment on the above? > >> > >> I'm not sure either. I didn't writeit yet. > > > > If Alessandro wishes to make specific suggestions for specific changes, > > the rest of us will be able to comment. > > That section, currently 10.3.2, looks rather good to me. If we need to > make it even better, I'd suggest the following changes to the first > paragraph: > > * clarify that "email forwarder" is used as a synonym of "forwarding > service" in this document. > > * Drop "Alias" from the section's title. > > * Drop citation of RFC 1123, and the term "List", copy and paste Dave's > explanation instead. > > * Separate definition from SPF effect. Update that "near-universal", > which was true at the time of writing 4408. > > None of those points is essential. Applying them all might produce an > outcome more or less like so: > > > 10.3.2. Forwarding Services > > Forwarding services, which we also call email forwarders, take mail > that is received at a mailbox and direct it to some external mailbox. > [RFC5321] describes this action as an alias expansion. In terms of > [RFC5598], the label Mediator is defined distinctly as "A Mediator > forwards a message through a re-posting process." This includes > "RFC5321.RcptTo: Set by - Mediator Author". At the time of this > writing, a large number of such services follow the only practice > described by [RFC5321], which is to use the original "MAIL FROM" of > a message when re-injecting it for delivery to the external mailbox. > This means the external mailbox's MTA sees all such mail in a > connection from a host of the forwarding service, and so the "MAIL > FROM" identity will not, in general, pass authorization. I think this is now OBE based on me reworking 10.3 with some offlist help from Dave. The text is now much simplified. I'm also going to fix up Appendix D to refer to mediators and not just forwarders. Here's what I have locally now: > 10.3. Mediators > > Mediators are a type of User actor.[RFC5598]. That is, a mediator > takes 'delivery' of a message and posts a 'submission' of a new > message. The mediator can make the newly-posted message be as > similar or as different from the original message as they wish. > Examples include mailing lists (see [RFC5598] Section 5.3) and > ReSenders ([RFC5598] Section 5.2). This is discussed in [RFC5321], > Section 3.9. For the operation of SPF, the essential concern is the > email address in the 5321.MailFrom command for the new message. > > Because SPF evaluation is based on the IP Address of the "last" > sending SMTP server, the address of the mediator will be used, rather > than the address of the SMTP server that sent the message to the > mediator. Some mediators retain the email address from the original > message, while some use a new address. > > If the address is the same as for the original message, and the > original message had an associated SPF record, then the SPF > evaluation will fail unless mitigations such as those described in > Appendix D are used. Scott K From internet-drafts@ietf.org Sat Mar 16 13:14:52 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E5721F87D1; Sat, 16 Mar 2013 13:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTNRKWgkx8N1; Sat, 16 Mar 2013 13:14:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E53F21F87D2; Sat, 16 Mar 2013 13:14:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130316201451.1643.97469.idtracker@ietfa.amsl.com> Date: Sat, 16 Mar 2013 13:14:51 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-12.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 20:14:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Sender Policy Framework (SPF) for Authorizing Use of Dom= ains in Email, Version 1 Author(s) : Scott Kitterman Filename : draft-ietf-spfbis-4408bis-12.txt Pages : 73 Date : 2013-03-16 Abstract: Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby an ADMD can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. This document obsoletes RFC4408. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Sat Mar 16 13:16:19 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E5421F882A for ; Sat, 16 Mar 2013 13:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 yxxUafWJbZKI for ; Sat, 16 Mar 2013 13:16:18 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5176621F8814 for ; Sat, 16 Mar 2013 13:16:18 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AC96D20E4113; Sat, 16 Mar 2013 16:16:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1363464977; bh=6jAeUz/WFwnqFQ+j8ljkWfyPryRMbWoyPenS1Q28+N4=; h=From:To:Subject:Date:From; b=a3z2KFevhy/5+5E26kPO5WQibbXqttfioW1aRwzae2VG7H98G2eaS9rrCywkOsmP3 mP0rqXVB0aL7D1HfnsSyN0pQk9jg+uO9/hvTJlCgfylzWhN5DBvGaydEW2IFu/z201 g3xn7q+BulOTzlUPy8OhD2KuwRZcy8wAZ5ldJ1tg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 85E3920E4062; Sat, 16 Mar 2013 16:16:17 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 16 Mar 2013 16:16:16 -0400 Message-ID: <2553538.aRr1bxuI3j@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-25-generic; KDE/4.9.5; 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: New Version Notification for draft-ietf-spfbis-4408bis-12.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 20:16:19 -0000 A new version of I-D, draft-ietf-spfbis-4408bis-12.txt has been successfully submitted by Scott Kitterman and posted to the IETF repository. Filename: draft-ietf-spfbis-4408bis Revision: 12 Title: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 Creation date: 2013-03-16 Group: spfbis Number of pages: 73 URL: http://www.ietf.org/internet-drafts/draft-ietf- spfbis-4408bis-12.txt Status: http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis Htmlized: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-12 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-12 With the exception of http://trac.tools.ietf.org/wg/spfbis/trac/ticket/24 this draft at least attempts to address all the open issues of which I'm aware. I'll stop and wait for comments now ... Scott K From dotzero@gmail.com Sat Mar 16 14:19:13 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0811221F8667 for ; Sat, 16 Mar 2013 14:19:13 -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 VWCB9ZopVPdJ for ; Sat, 16 Mar 2013 14:19:12 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id D981221F8630 for ; Sat, 16 Mar 2013 14:19:11 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id ge1so3711230lbb.1 for ; Sat, 16 Mar 2013 14:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GMB0zYTOSGIKbey0c+sugA+UOahC4MVXMRY8S8YTdCs=; b=ecgFV/RIaG9qVKx7H0V1iFKOvm0rymmq/cXFa7zpCsrFR4LXnFGZplOfP+YACPeGmt 5TBmaYNYKegoG0N6RklV5Uqv9MtUgA6u6+yjkyq55j8btvz8OzoZqtxPqTH1ys1zuFrE ydEKwyyYFKBXiwK7VQXM0IeRYIVw8SfHi1nVusbAYC0y4QEOxb/r7Qj6KwirQsTqYUBe 1D4y+3KTCYJSS7r+2N38HOH3loMpO34w9tlKjpn0X+FjfF38CmrihLC3DDDQp8srFEYV 4Gn2+Zh0WLtc0bs5ruxEoJMKYruLxm0fddxKOs5XmgcKKxiiOWvAdp+/dm0fmTJJ9gog Z03g== MIME-Version: 1.0 X-Received: by 10.112.28.4 with SMTP id x4mr4386479lbg.33.1363468750731; Sat, 16 Mar 2013 14:19:10 -0700 (PDT) Received: by 10.112.48.133 with HTTP; Sat, 16 Mar 2013 14:19:10 -0700 (PDT) In-Reply-To: <45461426.5BMDfefsaY@scott-latitude-e6320> References: <45461426.5BMDfefsaY@scott-latitude-e6320> Date: Sat, 16 Mar 2013 17:19:10 -0400 Message-ID: From: Dotzero To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Reasonable DNS error limits #24 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Mar 2013 21:19:13 -0000 Scott, Your analysis and recommendation sound reasonable. +1 On Sat, Mar 16, 2013 at 1:40 PM, Scott Kitterman wrote: > This is one of the few open issues we have remaining: > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/24 > >> 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. > > This "No Data limit" is already widely deployed as part of the modern Perl SPF > implementation, Mail::SPF. This is documented at: > > http://search.cpan.org/~jmehnle/Mail-SPF-v2.8.0/lib/Mail/SPF/Server.pm > >> max_void_dns_lookups >> >> An integer 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 (NXDOMAIN) before processing is aborted with a >> permerror result. If undef is specified, there is no stricter limit on >> the number of void DNS look-ups beyond the usual processing limits. >> Defaults to 2. >> >> Specifically, the DNS look-ups that are subject to this limit are those >> caused by the a, mx, ptr, and exists mechanisms and the p macro. >> >> A value of 2 is likely to prevent effective DoS attacks against >> third-party victim domains. However, a definite limit may cause >> permerror results even with certain (overly complex) innocent sender >> policies where useful results would normally be returned. > > The default of 2 has been in place since version 2.006, released on > 2008-08-17. > > I had hoped to have time (or find someone else who had time) to use the results > of Murray's previous SPF record survey to quantify the impact this might have > on existing records, but have not succeeded. Given that this has been in > place, by default, for over 4 years on a very popular (using the Debian > GNU/Linux distribution popcon (popularity contest) data, I would estimate that > Mail::SPF is installed in almost 10% of Debian systems - it is by far the most > popular SPF implementation in the distribution) implementation, I think it is, > however, reasonable to assume that if it caused significant problems, they > would have come up by now. I did check with the primary developer (Julian > Mehnle) and he is not aware of people having problems with it. > > The only places a no data result will occur that are not due to a problem in > the record are for exists which do not match the given criteria and for ptr > (and p macro) if the connect IP has no reverse DNS. The Mail::SPF limit of > two allows for both these issues to occur in a record without raising an > error. > > My proposal is that we add this as a new limit in section 4.6.4, DNS Lookup > Limits, to resolve this issue. I think it's a useful limit, unlikely to cause > backward compatibility issues, and in scope for consideration due to long > term, wide spread deployment. > > If there is some consensus around the concept, then we can come up with > specific text for 4.6.4, but I think it's useful to discuss the concept first. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From superuser@gmail.com Mon Mar 18 20:32:05 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948C121F8BEF for ; Mon, 18 Mar 2013 20:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqSVtdi2zOxG for ; Mon, 18 Mar 2013 20:32:04 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id EC06921F8BE7 for ; Mon, 18 Mar 2013 20:31:58 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id hi18so14894wib.15 for ; Mon, 18 Mar 2013 20:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=scDRysZh2psjs/7cpi9KTym0639QLlCn9/q/KYUdRtw=; b=HEDLkqp0OHCr7XzQQqp8W2zw/Cwnbx8ZSAhgKzAOPeB9pWraN/pWHXYRnjctknakeY ccVdYtrUOjsQSSJd179UYKYkJS4G0gWQHcq190mG5SeEdweytXv9eAZnLUWcd5v7CwEm dr1IdYhthbbemudVSVxJx8LsC1DAdt4aO8XUB58KU55HHGD6w1TIsz3qqzverPN/hJa1 PWF2v9xdfA9gowXQ1Wp76v0zCxIZRKi9QBa2BiPBzEmUvnknVa6EAFVTS6RCyoSXIouJ /Tk/jAja7fkmW+A0krzfc2laJvUhTAdNtmBa7UVDa443KxS0DzdHPt3ezAZigUpGKp+D YH6w== MIME-Version: 1.0 X-Received: by 10.180.83.10 with SMTP id m10mr2129938wiy.5.1363663918083; Mon, 18 Mar 2013 20:31:58 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Mon, 18 Mar 2013 20:31:58 -0700 (PDT) In-Reply-To: References: <45461426.5BMDfefsaY@scott-latitude-e6320> Date: Mon, 18 Mar 2013 20:31:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dotzero Content-Type: multipart/alternative; boundary=f46d04428eb66e328d04d83ebfb2 Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] Reasonable DNS error limits #24 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Mar 2013 03:32:05 -0000 --f46d04428eb66e328d04d83ebfb2 Content-Type: text/plain; charset=ISO-8859-1 I don't much care for the term "void lookup" (and Scott and I have discussed this), but apart from that I'm in agreement with Mike that the description and recommendation are reasonable additions. If I can come up with a better term, I will. At a minimum, I would put a sentence or two defining the term up front in the section where this is being added. Something like this, perhaps (with corrections as appropriate): Concerns have been addressed that SPF verifiers can be used as amplification agents for a denial-of-service attack. In this scenario, the attacker publishes an SPF record in its own DNS that uses "a" and "mx" mechanisms directed toward the intended victim, e.g. "a:example.com a: foo.example.com a:bar.example.com ..." and then distributes mail with a MAIL FROM value including its own domain in large volume to a wide variety of destinations. Any such destination operating an SPF verifier will begin querying all of the names associated with the "a" mechanisms in that record. The names used in the record needn't exist for the attack to be effective. A DNS query that returns either a positive answer (RCODE 0) with an answer count of 0, or a no such record (RCODE 3) answer, is sometimes called a "void lookup". Operational experience since publication of RFC4408 suggests that mitigation of this class of attack can be accomplished with minimal impact on the deployed base by having the verifier abort processing and return "permerror" (Section x.x.x) once two void lookups have been encountered. While an implementation may choose to make such a limit configurable, such a limit SHOULD exist and the default of two is RECOMMENDED. -MSK On Sat, Mar 16, 2013 at 2:19 PM, Dotzero wrote: > Scott, > > Your analysis and recommendation sound reasonable. > > > +1 > > On Sat, Mar 16, 2013 at 1:40 PM, Scott Kitterman > wrote: > > This is one of the few open issues we have remaining: > > > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/24 > > > >> 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. > > > > This "No Data limit" is already widely deployed as part of the modern > Perl SPF > > implementation, Mail::SPF. This is documented at: > > > > http://search.cpan.org/~jmehnle/Mail-SPF-v2.8.0/lib/Mail/SPF/Server.pm > > > >> max_void_dns_lookups > >> > >> An integer 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 (NXDOMAIN) before processing is aborted with a > >> permerror result. If undef is specified, there is no stricter limit > on > >> the number of void DNS look-ups beyond the usual processing limits. > >> Defaults to 2. > >> > >> Specifically, the DNS look-ups that are subject to this limit are > those > >> caused by the a, mx, ptr, and exists mechanisms and the p macro. > >> > >> A value of 2 is likely to prevent effective DoS attacks against > >> third-party victim domains. However, a definite limit may cause > >> permerror results even with certain (overly complex) innocent sender > >> policies where useful results would normally be returned. > > > > The default of 2 has been in place since version 2.006, released on > > 2008-08-17. > > > > I had hoped to have time (or find someone else who had time) to use the > results > > of Murray's previous SPF record survey to quantify the impact this might > have > > on existing records, but have not succeeded. Given that this has been in > > place, by default, for over 4 years on a very popular (using the Debian > > GNU/Linux distribution popcon (popularity contest) data, I would > estimate that > > Mail::SPF is installed in almost 10% of Debian systems - it is by far > the most > > popular SPF implementation in the distribution) implementation, I think > it is, > > however, reasonable to assume that if it caused significant problems, > they > > would have come up by now. I did check with the primary developer > (Julian > > Mehnle) and he is not aware of people having problems with it. > > > > The only places a no data result will occur that are not due to a > problem in > > the record are for exists which do not match the given criteria and for > ptr > > (and p macro) if the connect IP has no reverse DNS. The Mail::SPF limit > of > > two allows for both these issues to occur in a record without raising an > > error. > > > > My proposal is that we add this as a new limit in section 4.6.4, DNS > Lookup > > Limits, to resolve this issue. I think it's a useful limit, unlikely to > cause > > backward compatibility issues, and in scope for consideration due to long > > term, wide spread deployment. > > > > If there is some consensus around the concept, then we can come up with > > specific text for 4.6.4, but I think it's useful to discuss the concept > first. > > > > Scott K > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d04428eb66e328d04d83ebfb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't much care for the term "void lo= okup" (and Scott and I have discussed this), but apart from that I'= ;m in agreement with Mike that the description and recommendation are reaso= nable additions.=A0 If I can come up with a better term, I will.=A0 At a mi= nimum, I would put a sentence or two defining the term up front in the sect= ion where this is being added.=A0 Something like this, perhaps (with correc= tions as appropriate):

Concerns have been addressed that SPF verifiers can be used = as amplification agents for a denial-of-service attack.=A0 In this scenario= , the attacker publishes an SPF record in its own DNS that uses "a&quo= t; and "mx" mechanisms directed toward the intended victim, e.g. = "a:example.com a:foo.example.com a:b= ar.example.com ..." and then distributes mail with a MAIL FROM val= ue including its own domain in large volume to a wide variety of destinatio= ns.=A0 Any such destination operating an SPF verifier will begin querying a= ll of the names associated with the "a" mechanisms in that record= .=A0 The names used in the record needn't exist for the attack to be ef= fective.

A DNS query that returns either a positive answer (RCODE 0) with an ans= wer count of 0, or a no such record (RCODE 3) answer, is sometimes called a= "void lookup".=A0 Operational experience since publication of RF= C4408 suggests that mitigation of this class of attack can be accomplished = with minimal impact on the deployed base by having the verifier abort proce= ssing and return "permerror" (Section x.x.x) once two void lookup= s have been encountered.=A0 While an implementation may choose to make such= a limit configurable, such a limit SHOULD exist and the default of two is = RECOMMENDED.

-MSK


On Sat, Mar 16, 2013 at 2:19 PM, Dotzero <= dotzero@gmail.com> wrote:
Scott,

Your analysis and recommendation sound reasonable.


+1

On Sat, Mar 16, 2013 at 1:40 PM, Scott Kitterman <spf2@kitterman.com> wrote:
> This is one of the few open issues we have remaining:
>
> http://trac.tools.ietf.org/wg/spfbis/trac/ticket/24
>
>> Each of 10 SPF mechanisms may require 10 separate reflected DNS re= solutions
>> where SPF is insensitive to the number of No Data responses in mul= tiples of
>> 100 DNS transactions. There is no limit for the number of No Data = results,
>> which represents a likely method malefactors might use in conjunct= ion 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 a= re made
>> for each message. Network amplification that could result is subst= antial.
>> This risk can be significantly mitigated by simply imposing reason= able No
>> Data limits.
>
> This "No Data limit" is already widely deployed as part of t= he modern Perl SPF
> implementation, Mail::SPF. =A0This is documented at:
>
> http://search.cpan.org/~jmehnle/Mail-SPF-v2.= 8.0/lib/Mail/SPF/Server.pm
>
>> max_void_dns_lookups
>>
>> =A0 =A0 An integer denoting the maximum number of "void"= DNS look-ups per SPF
>> =A0 =A0 check, i.e. the number of DNS look-ups that were caused by=
>> =A0 =A0 DNS-interactive terms and macros (as defined in RFC 4408, = 10.1,
>> =A0 =A0 paragraphs 6 and 7) and that are allowed to return an empt= y answer with
>> =A0 =A0 RCODE 0 or RCODE 3 (NXDOMAIN) before processing is aborted= with a
>> =A0 =A0 permerror result. If undef is specified, there is no stric= ter limit on
>> =A0 =A0 the number of void DNS look-ups beyond the usual processin= g limits.
>> =A0 =A0 Defaults to 2.
>>
>> =A0 =A0 Specifically, the DNS look-ups that are subject to this li= mit are those
>> =A0 =A0 caused by the a, mx, ptr, and exists mechanisms and the p = macro.
>>
>> =A0 =A0 A value of 2 is likely to prevent effective DoS attacks ag= ainst
>> =A0 =A0 third-party victim domains. However, a definite limit may = cause
>> =A0 =A0 permerror results even with certain (overly complex) innoc= ent sender
>> =A0 =A0 policies where useful results would normally be returned.<= br> >
> The default of 2 has been in place since version 2.006, released on > 2008-08-17.
>
> I had hoped to have time (or find someone else who had time) to use th= e results
> of Murray's previous SPF record survey to quantify the impact this= might have
> on existing records, but have not succeeded. =A0Given that this has be= en in
> place, by default, for over 4 years on a very popular (using the Debia= n
> GNU/Linux distribution popcon (popularity contest) data, I would estim= ate that
> Mail::SPF is installed in almost 10% of Debian systems - it is by far = the most
> popular SPF implementation in the distribution) implementation, I thin= k it is,
> however, reasonable to assume that if it caused significant problems, = they
> would have come up by now. =A0I did check with the primary developer (= Julian
> Mehnle) and he is not aware of people having problems with it.
>
> The only places a no data result will occur that are not due to a prob= lem in
> the record are for exists which do not match the given criteria and fo= r ptr
> (and p macro) if the connect IP has no reverse DNS. =A0The Mail::SPF l= imit of
> two allows for both these issues to occur in a record without raising = an
> error.
>
> My proposal is that we add this as a new limit in =A0section 4.6.4, DN= S Lookup
> Limits, to resolve this issue. =A0I think it's a useful limit, unl= ikely to cause
> backward compatibility issues, and in scope for consideration due to l= ong
> term, wide spread deployment.
>
> If there is some consensus around the concept, then we can come up wit= h
> specific text for 4.6.4, but I think it's useful to discuss the co= ncept first.
>
> Scott K
> _______________________________________________
> spfbis mailing list
> spfbis@ietf.org
> https://www.ietf.org/mailman/listinfo/spfbis
_______________________________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--f46d04428eb66e328d04d83ebfb2-- From vesely@tana.it Tue Mar 19 05:33:03 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4B021F8922 for ; Tue, 19 Mar 2013 05:33:03 -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 YLnl2ZC9SkI6 for ; Tue, 19 Mar 2013 05:33:02 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9567421F88F7 for ; Tue, 19 Mar 2013 05:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1363696379; bh=7lb49urew120S9p4nJCeQvjYT/FczdpVgnN6j7xMzkE=; l=1194; h=Date:From:To:References:In-Reply-To; b=ZQFv1rQnLDGCKxrF38jtMmeuhDpniF53NceE0tQEJ39HhVSQgI9kfWPLIJoeD0gH9 1JyJOLh+TcJtBmNw+CwgYkLD5xmRdPJwZ1lFtGfbLM71xPRqiB2KFiMcLmWQAIyCsU zLyU4cBAVYLqrbWnaxefl3M0jvBqDiyyoFM6kk+M= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 19 Mar 2013 13:32:59 +0100 id 00000000005DC02B.0000000051485AFB.00002CC3 Message-ID: <51485AFB.7010204@tana.it> Date: Tue, 19 Mar 2013 13:32:59 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <5132217E.5060402@dcrocker.net> <5132F4A8.3040606@tana.it> <2462034.aoBIrkDmzC@scott-latitude-e6320> In-Reply-To: <2462034.aoBIrkDmzC@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Mar 2013 12:33:03 -0000 On Sat 16/Mar/2013 21:01:31 +0100 Scott Kitterman wrote: > On Sunday, March 03, 2013 07:58:48 AM Alessandro Vesely wrote: >> >> That section, currently 10.3.2, looks rather good to me. [...] > > I think this is now OBE based on me reworking 10.3 with some > offlist help from Dave. The text is now much simplified. Yes. Keeping an "also known as forwarders" wouldn't hurt, though. > I'm also going to fix up Appendix D to refer to mediators and not > just forwarders. If I may propose a change to appendix D, that would be to promote its top-level bullets to proper subsections, and use titles such as *mitigation that can be operated by the sender*. The introductory paragraph could then be reworded like so: OLD There are three places that techniques can be used to ameliorate unintended SPF failures with mediators. NEW Each actor can deploy various techniques to ameliorate unintended SPF failures when messages are mediated. Or some such. Mentioning some valid reasons why an actor cannot do what the others would expect might refrain people from prompting in vain. In particular, SRS deserves both a better presentation and an argument against it. From vesely@tana.it Tue Mar 19 08:05:13 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC7921F8C3E for ; Tue, 19 Mar 2013 08:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjupEqx56npX for ; Tue, 19 Mar 2013 08:05:12 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6F09621F8BE7 for ; Tue, 19 Mar 2013 08:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1363705511; bh=0/J0nSdEUYSc8Y1RwSgKHnTgQlftjSNco+BdV2aaK2w=; l=2376; h=Date:From:To:References:In-Reply-To; b=cwVOnAvFuSHDxsBkry5xZu9aEl8BiIm+NoOhhxNzCcI3yUrmb6OeyLok4rBLDaZhD zLdcvcFOkbJa3MiS2EwMwMHjHw7o2F7aFujJnn6YadnNUTM9h/urCIaAT9HiuektjW YeMf16xmuxcVcvcTDQcAZAVDbglqibdKVkzNrEJA= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 19 Mar 2013 16:05:11 +0100 id 00000000005DC045.0000000051487EA7.00006F8D Message-ID: <51487EA7.70306@tana.it> Date: Tue, 19 Mar 2013 16:05:11 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <45461426.5BMDfefsaY@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Reasonable DNS error limits #24 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Mar 2013 15:05:13 -0000 On Tue 19/Mar/2013 04:31:58 +0100 Murray S. Kucherawy wrote: > I don't much care for the term "void lookup" (and Scott and I have > discussed this), but apart from that I'm in agreement with Mike that > the description and recommendation are reasonable additions. If I can > come up with a better term, I will. At a minimum, I would put a > sentence or two defining the term up front in the section where this > is being added. Something like this, perhaps (with corrections as > appropriate): > > Concerns have been addressed that SPF verifiers can be used as > amplification agents for a denial-of-service attack. In this > scenario, the attacker publishes an SPF record in its own DNS that > uses "a" and "mx" mechanisms directed toward the intended victim, > e.g. "a:example.com a:foo.example.com a:bar.example.com ..." and > then distributes mail with a MAIL FROM value including its own > domain in large volume to a wide variety of destinations. Any such > destination operating an SPF verifier will begin querying all of > the names associated with the "a" mechanisms in that record. The > names used in the record needn't exist for the attack to be > effective. Besides, can't we mention somewhere, e.g. Section 4.8, that the domain owners consent is required to specify domains in SPF records? Just as ammo for those LEAs out there... > A DNS query that returns either a positive answer (RCODE 0) with an > answer count of 0, or a no such record (RCODE 3) answer, is sometimes > called a "void lookup". Operational experience since publication of > RFC4408 suggests that mitigation of this class of attack can be > accomplished with minimal impact on the deployed base by having the > verifier abort processing and return "permerror" (Section x.x.x) once > two void lookups have been encountered. While an implementation may > choose to make such a limit configurable, such a limit SHOULD exist > and the default of two is RECOMMENDED. I like that text, but the last sentence. I don't think that kind of attacks justify such a low limit. If the victim's DNS and the mail servers' caching DNSes work properly, the amplification gain seems to be low. IMHO, the last sentence should be: An implementation MAY choose to make such a limit configurable and default to a value lower than the recommended limit of 10. jm2c From superuser@gmail.com Tue Mar 19 09:55:50 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551D021F8D8B for ; Tue, 19 Mar 2013 09:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.257 X-Spam-Level: X-Spam-Status: No, score=-1.257 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQPziCloEuXG for ; Tue, 19 Mar 2013 09:55:49 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADBB21F86D3 for ; Tue, 19 Mar 2013 09:55:44 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi8so765129wib.7 for ; Tue, 19 Mar 2013 09:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=x7th/7ZnMc2MGMuEdhycPlNlfyBdNYKg/+YVC+4RbmI=; b=d8CDKSf5MHl0KPBMFC6ubCRa+mShItHR9CNITUmRaHnjg2dveqMryFgCPNyDdPTDf8 kO2P1wzDjs6bo47IV5em2RgPqYiG1Tc1N1gu47wh0Dyucex2jReePU76UIQmoUmP/ZWl o4KuDTJw86OVUwCdBxlH6FK1CKJ/nNOX/lwcZjnhCnw9E108NRbYaU1h5fPbCJjt8saI 6DFmblVddUECWz5vaLlqcH5D2q6vjq8FAMxk8AHav0z6Q5aFBOf/qQjqTGtk4rdH8ngF snUNh0NqtRr1r/nzzQfhwCAWyYukR+oOj6aH2KlJpmZthg7B5Jcb7IS8V7wZA6jr7Uqp q2bQ== MIME-Version: 1.0 X-Received: by 10.194.178.9 with SMTP id cu9mr4801403wjc.39.1363712128717; Tue, 19 Mar 2013 09:55:28 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Tue, 19 Mar 2013 09:55:28 -0700 (PDT) In-Reply-To: <51487EA7.70306@tana.it> References: <45461426.5BMDfefsaY@scott-latitude-e6320> <51487EA7.70306@tana.it> Date: Tue, 19 Mar 2013 09:55:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=089e013d1f28021d2d04d849f9df Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Reasonable DNS error limits #24 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Mar 2013 16:55:50 -0000 --089e013d1f28021d2d04d849f9df Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 19, 2013 at 8:05 AM, Alessandro Vesely wrote: > Besides, can't we mention somewhere, e.g. Section 4.8, that the domain > owners consent is required to specify domains in SPF records? Just as > ammo for those LEAs out there... > How are we supposed to make such an assertion in a protocol document? > > > A DNS query that returns either a positive answer (RCODE 0) with an > > answer count of 0, or a no such record (RCODE 3) answer, is sometimes > > called a "void lookup". Operational experience since publication of > > RFC4408 suggests that mitigation of this class of attack can be > > accomplished with minimal impact on the deployed base by having the > > verifier abort processing and return "permerror" (Section x.x.x) once > > two void lookups have been encountered. While an implementation may > > choose to make such a limit configurable, such a limit SHOULD exist > > and the default of two is RECOMMENDED. > > I like that text, but the last sentence. I don't think that kind of > attacks justify such a low limit. If the victim's DNS and the mail > servers' caching DNSes work properly, the amplification gain seems to > be low. IMHO, the last sentence should be: > > An implementation MAY choose to make such a limit configurable and > default to a value lower than the recommended limit of 10. > > But the limit in the module Scott referenced is 2, not 10. What's the > justification for changing it now? > --089e013d1f28021d2d04d849f9df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 19, 2013 at 8:05 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
Besides, can't we mention somewhere, e.g= . Section 4.8, that the domain
owners consent is required to specify domains in SPF records? =A0Just as ammo for those LEAs out there...

How ar= e we supposed to make such an assertion in a protocol document?

> A DNS query that returns either a positive answer (RCODE 0) with an > answer count of 0, or a no such record (RCODE 3) answer, is sometimes<= br> > called a "void lookup". =A0Operational experience since publ= ication of
> RFC4408 suggests that mitigation of this class of attack can be
> accomplished with minimal impact on the deployed base by having the > verifier abort processing and return "permerror" (Section x.= x.x) once
> two void lookups have been encountered. =A0While an implementation may=
> choose to make such a limit configurable, such a limit SHOULD exist > and the default of two is RECOMMENDED.

I like that text, but the last sentence. =A0I don't think that ki= nd of
attacks justify such a low limit. =A0If the victim's DNS and the mail servers' caching DNSes work properly, the amplification gain seems to be low. =A0IMHO, the last sentence should be:

=A0 =A0An implementation MAY choose to make such a limit configurable and =A0 =A0default to a value lower than the recommended limit of 10.

But the limit in the module Scott referenced is 2, not 10.=A0 Wha= t's the justification for changing it now?

--089e013d1f28021d2d04d849f9df-- From superuser@gmail.com Fri Mar 22 09:54:57 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F8221F8928 for ; Fri, 22 Mar 2013 09:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.130, 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 Y813pAE1HmLb for ; Fri, 22 Mar 2013 09:54:56 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 467F421F8DF0 for ; Fri, 22 Mar 2013 09:54:48 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id fm10so423369wgb.21 for ; Fri, 22 Mar 2013 09:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=73OG/7HKxIjUzwDGtZM91+496LSoPUu0V+OGBoCY2p8=; b=mXK2ZB1sjmPl5yijvaYnvmv/5RWdmP5unFLkymHVwO3Yd6vL/bX6T/ElC6Prdzd03Y bvHeeOC3AVuEtvIOlBf10YCz6/3z8XSWjqQJFkCI31V419F26ga5Rvgw3zJw485wa4Il 5ya8QAhnpK8Ikv4ileMmuTqR4bQDaSkGZvWcykZnB28iC5bNQfsmsNaZKjqqagH9clp6 A++Laz6TFEHQ2OUQA1iTGRsDs3yrkqZ2P8ySZ7pRDoJIyu7UlidRZmET/bSadUnD3emN 3+JfogF6Swd+OMFMgT5aeMvDDa34KFZtBbk31vv7FIb4Cvx2Mlyr/w6Di76SjGYWX2co +Vzg== MIME-Version: 1.0 X-Received: by 10.194.59.100 with SMTP id y4mr4406094wjq.51.1363971287486; Fri, 22 Mar 2013 09:54:47 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Fri, 22 Mar 2013 09:54:47 -0700 (PDT) Date: Fri, 22 Mar 2013 09:54:47 -0700 Message-ID: From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=047d7b86cea4131aab04d88650ec Subject: [spfbis] Authentication-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: Fri, 22 Mar 2013 16:54:57 -0000 --047d7b86cea4131aab04d88650ec Content-Type: text/plain; charset=ISO-8859-1 Colleagues, (with apologies for the cross-posting if you get more than one copy of this) As you may have seen already, I'm working on a revision to RFC5451. A Proposed Standard "bis" effort always benefits from describing extant implementations. I know about the ones I've written, and about some very public uses of it (Gmail, Yahoo, for example). If there's anyone in this audience that knows of others, I'd love to hear about it. Reviews of the update are also welcome: https://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis/ Thanks, -MSK --047d7b86cea4131aab04d88650ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

(with ap= ologies for the cross-posting if you get more than one copy of this)
As you may have seen already, I'm working on a revision to RFC5451.

A=20 Proposed Standard "bis" effort always benefits from describing ex= tant=20 implementations.=A0 I know about the ones I've written, and about some= =20 very public uses of it (Gmail, Yahoo, for example).=A0 If there's anyon= e=20 in this audience that knows of others, I'd love to hear about it.

Reviews of the update are also welcome:

https://datatracker.ie= tf.org/doc/draft-kucherawy-rfc5451bis/

Thanks,
-MSK
--047d7b86cea4131aab04d88650ec-- From SRS0=eA7m5=NL==stuart@gathman.org Fri Mar 22 18:44:34 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014B721F8A7E for ; Fri, 22 Mar 2013 18:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZjr4GwqH3uq for ; Fri, 22 Mar 2013 18:44:33 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 6642C21F8CAA for ; Fri, 22 Mar 2013 18:44:33 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (PLAIN sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1364003085; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=bfXtaBbFyrlVMb5CHo+ZM6Rp2emjd2hGSNZqaCbjeu0=; b=EB43P6Ml5uOwbHfHSY744nFF1MAOmCHdQjjsjTQ0esQ99mR2dweVaIqOvubUTKFjA7zoap Oay3jgnCUFCw3OOYa9o0HVDLNIfCCDNHf14CKfy9h0POLn8CkHFrVVVEcQnhBJUCKctO8MM8 GKtp2619etyRthRYY5cwv17QWgopg= Received: from silver.gathman.org ([IPv6:2001:470:8:809:4575:284e:b724:ae98]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r2N1ieAG022836 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 22 Mar 2013 21:44:45 -0400 Message-ID: <514D08FB.40006@gathman.org> Date: Fri, 22 Mar 2013 21:44:27 -0400 From: Stuart Gathman Organization: BWI Corporation User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <1991186.y8zxGRhPli@scott-latitude-e6320> <3005266.bpAoHDOQkP@scott-latitude-e6320> In-Reply-To: <3005266.bpAoHDOQkP@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Mar 2013 04:21:15 -0000 On 03/16/2013 02:17 PM, Scott Kitterman wrote: > On Monday, March 04, 2013 11:56:27 PM Murray S. Kucherawy wrote: >> It looks like the vast majority of this stuff has been resolved in the >> latest version. I'll touch on the few that still remain open. Other than >> these, we only have three open tickets (two closely related). Does that >> mean we're almost done? >> In reading through http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-11, I had a problem with section 4.6.4. While putting on my implementer/test suite hat, it was not at all clear whether SPF implementations MUST limit the number of mechanisms and modifiers ("terms") that cause any DNS query to at most 10 during SPF evaluation. means that the *total* number of mechanisms and modifiers is limited to 10, or that each type of mechanism/modifier is limited to 10. Looking at the current test suite, I see the answer is "total number of all types", but it was not clear from reading it while pretending I forgot all that stuff. From underspell@gmail.com Mon Mar 25 07:59:23 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BEE11E80DF for ; Mon, 25 Mar 2013 07:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVQWBNRvGj1e for ; Mon, 25 Mar 2013 07:59:23 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id B283C11E80DE for ; Mon, 25 Mar 2013 07:59:19 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id fo12so11619306lab.0 for ; Mon, 25 Mar 2013 07:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=rYZSOkFJvU/6VtFDNbI3PEmfjkopToAIj8vk2j3sVf0=; b=uOi33ch0+qEIyzcXTGcil/cUcIILbz+LxwKZ0vLj6Y9jvnfB8WDaaDwF0JXWRIxt0a AkfQcb87qC7q8dzuvvYX4JeIathzhnyK93T4ecgxgjeQA5SE/tgzBPHswesrzEr3UBmX q9rKgvVUa6hWRtsigld0YubXch6gWiGWrFPHzUZMY5/VVTCssVkDE7J0fJYTjtMi7xPC ixVKm0Jw8cnqB2i6c9k2Gjmqirwa76CIevwWAFDX4IlYNh80djIv/xxOzfM6lqFPYogE 2Nmh4HxM5Ai7/K8qxyaOFKxsd6xhtDujNyw8i5z5ZQil8k2QZVcLSLxnKEViZ1K2EfJY Z2bg== MIME-Version: 1.0 X-Received: by 10.112.155.67 with SMTP id vu3mr1897150lbb.109.1364223558598; Mon, 25 Mar 2013 07:59:18 -0700 (PDT) Received: by 10.114.19.176 with HTTP; Mon, 25 Mar 2013 07:59:18 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Mar 2013 14:59:18 +0000 Message-ID: From: Jose Borges Ferreira To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 25 Mar 2013 08:13:34 -0700 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Authentication-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, 25 Mar 2013 14:59:23 -0000 Hi! I've noted that Courrier MTA logs DNSWL results on an Authentication-Results header. I looked at the source and documentation and apparently it's only for whitelists. Don't know if it qualifies as existing implementation because it's only available on the svn version... Configuration snippet: # BLACKLISTS=3D'-block=3Dzen.spamhaus.org,BLOCK2 -block=3Dcbl.abuseat.org,B= LOCK2' # # The BLACKLISTS setting can also contain -allow options to implement # DNS-based whitelists. See the couriertcpd(1) man page for more informatio= n. # The -block and -allow options from this setting are passed directly to # couriertcpd(1). BLACKLISTS=3D"" ##NAME: ALLOW_EXCLUSIVE:0 # # The -allow option adds an Authentication-Results: header to a received # message, if the sender's IP was found in the -allow lookup. And according to the code, adds something like: Authentication-Results: " + cme_name + ";\n dnswl=3Dpass dns.zone=3D" +"\n policy.ip=3D" + ip; And eventually a policy.txt with rfc2047_encode_str of the TXT record. Jos=E9 Borges Ferreira On Fri, Mar 22, 2013 at 4:54 PM, Murray S. Kucherawy wrote: > Colleagues, > > (with apologies for the cross-posting if you get more than one copy of th= is) > > As you may have seen already, I'm working on a revision to RFC5451. > > A Proposed Standard "bis" effort always benefits from describing extant > implementations. I know about the ones I've written, and about some very > public uses of it (Gmail, Yahoo, for example). If there's anyone in this > audience that knows of others, I'd love to hear about it. > > Reviews of the update are also welcome: > > https://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis/ > > Thanks, > -MSK > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From johnl@iecc.com Mon Mar 25 11:46:38 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2E221F90E2 for ; Mon, 25 Mar 2013 11:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[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 fcs2s6C-cLax for ; Mon, 25 Mar 2013 11:46:37 -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 F2DC521F9125 for ; Mon, 25 Mar 2013 11:46:36 -0700 (PDT) Received: (qmail 60853 invoked from network); 25 Mar 2013 18:46:35 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Mar 2013 18:46:35 -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=51509b8a.xn--yuvv84g.k1303; i=johnl@user.iecc.com; bh=8mJZzJHBStbOrciXBDdV4u97zKSIII7tSe4Ew67Z5JE=; b=fo1nzRF1PUbWNbKU6Jo7VslFc7ov31K6MwapowQNTr1AxErT9i0zoQrc2DFrXKHFK7tECsv4O8Tyxy4/VnpHPi0Vd4OjgMXlyBM8cCuMu8Jwa4vvkFvtdXtzYS+EDXfRcn1IHtTg7j9x6gYENRewvoTwwPGVIUkyjBTnFXc+5kc= 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=51509b8a.xn--yuvv84g.k1303; olt=johnl@user.iecc.com; bh=8mJZzJHBStbOrciXBDdV4u97zKSIII7tSe4Ew67Z5JE=; b=nsK7mjbKO2KdbskvN6QZvdRV2DoUgEcZh7SzJBsBU4xXFgwuBjp/i/zja6PVVszKMG+6oPvXtcp5MP5CXgl3ZnaGVWrbgGWC6b6uzT4GqxI3h7yeICliEvAo3lY48G+Q+LPlNeDZQZEJveCapeh/ruWHGSlrl1rSWEdOceIzi9E= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Mar 2013 18:46:12 -0000 Message-ID: <20130325184612.21466.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: superuser@gmail.com Subject: Re: [spfbis] Authentication-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, 25 Mar 2013 18:46:38 -0000 >A Proposed Standard "bis" effort always benefits from describing extant >implementations. I know about the ones I've written, and about some very >public uses of it (Gmail, Yahoo, for example). If there's anyone in this >audience that knows of others, I'd love to hear about it. I'm authentication-results headers in a plugin into the mailfront SMTP daemon. It does SPF and DKIM, matches the syntax in Murray's draft. From spf2@kitterman.com Mon Mar 25 12:27:15 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237C721F9529 for ; Mon, 25 Mar 2013 12:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ov0KLN8ySfC for ; Mon, 25 Mar 2013 12:27:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6383721F951A for ; Mon, 25 Mar 2013 12:27:14 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A6A4D20E40CD; Mon, 25 Mar 2013 15:27:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364239633; bh=D+W0/fyXnOxaoeQYmcc47H62pDlKuTiEKDTs7pc4Tu8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=a2C7dijiTK4uFdXURQRiUM5q6mVcdNSpRrhIykhXFdNg3xtJXJSQy1dLGSCh+jNGx rr6IzQ01JGjiLBPHS+8DPyJ07nJlq5Fw1c6fNQ6/DtAvPyn7lrov8OL47VEGzWyETM QswlD7y0MJMl0gIxme80lgnUz1TE0P3xZjrSeDNI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8240120E4062; Mon, 25 Mar 2013 15:27:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Mar 2013 15:27:12 -0400 Message-ID: <3027540.GXWi4kjD1K@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <51485AFB.7010204@tana.it> References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <2462034.aoBIrkDmzC@scott-latitude-e6320> <51485AFB.7010204@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] #56: Section 9.2.2 Forwarding Services and Aliases X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Mar 2013 19:27:15 -0000 On Tuesday, March 19, 2013 01:32:59 PM Alessandro Vesely wrote: > On Sat 16/Mar/2013 21:01:31 +0100 Scott Kitterman wrote: > > On Sunday, March 03, 2013 07:58:48 AM Alessandro Vesely wrote: > >> That section, currently 10.3.2, looks rather good to me. [...] > > > > I think this is now OBE based on me reworking 10.3 with some > > offlist help from Dave. The text is now much simplified. > > Yes. Keeping an "also known as forwarders" wouldn't hurt, though. > > > I'm also going to fix up Appendix D to refer to mediators and not > > just forwarders. > > If I may propose a change to appendix D, that would be to promote its > top-level bullets to proper subsections, and use titles such as > *mitigation that can be operated by the sender*. The introductory > paragraph could then be reworded like so: > > OLD > There are three places that techniques can be used to ameliorate > unintended SPF failures with mediators. > > NEW > Each actor can deploy various techniques to ameliorate unintended > SPF failures when messages are mediated. > > Or some such. Mentioning some valid reasons why an actor cannot do > what the others would expect might refrain people from prompting in > vain. In particular, SRS deserves both a better presentation and an > argument against it. I find adding the subsections makes it clearer, so I've committed that locally for -13. Scott K From spf2@kitterman.com Mon Mar 25 12:30:44 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5446A21F956A for ; Mon, 25 Mar 2013 12:30:44 -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 o87RCaxhwG9Q for ; Mon, 25 Mar 2013 12:30:43 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6D021F9567 for ; Mon, 25 Mar 2013 12:30:43 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0580920E40CD; Mon, 25 Mar 2013 15:30:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364239843; bh=ORRwKKEhteXKOit/8w+RyhhAs8ZJepMOEamRQvezc2Y=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jjSijM6xDkr3V/7/NEjrJOy14hr318AZYZi2i6DsePvJPMZpHXG1doPkc6v7lzpoO WlewTdpw7rVS2BdeGsorNd3PWzvVEMNlZSJrm69LtaZxoEqrDTp0iXmjyGcRGj5GYq 5caFmJdulnNd1pEMunm6KafDuDKGiUcSfDU7CMFM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DFE4A20E4062; Mon, 25 Mar 2013 15:30:42 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Mar 2013 15:30:41 -0400 Message-ID: <3509662.rYkuaFbkhu@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <514D08FB.40006@gathman.org> References: <3005266.bpAoHDOQkP@scott-latitude-e6320> <514D08FB.40006@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] Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Mar 2013 19:30:44 -0000 On Friday, March 22, 2013 09:44:27 PM Stuart Gathman wrote: > On 03/16/2013 02:17 PM, Scott Kitterman wrote: > > On Monday, March 04, 2013 11:56:27 PM Murray S. Kucherawy wrote: > >> It looks like the vast majority of this stuff has been resolved in the > >> latest version. I'll touch on the few that still remain open. Other > >> than > >> these, we only have three open tickets (two closely related). Does that > >> mean we're almost done? > > In reading through > http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-11, I had a problem > with section 4.6.4. While putting on my implementer/test suite hat, it > was not at all clear whether > > SPF implementations MUST limit the number of mechanisms and modifiers > ("terms") that cause any DNS query to at most 10 during SPF > evaluation. > > means that the *total* number of mechanisms and modifiers is limited to > 10, or that each type of mechanism/modifier is limited to 10. Looking at > the current test suite, I see the answer is "total number of all types", > but it was not clear from reading it while pretending I forgot all that > stuff. OK. I guess you're better at pretending than I am. Here's what I'll try on the group for the next revision: > SPF implementations MUST limit the total number of mechanisms and > modifiers ("terms") that cause any DNS query to at most 10 during SPF > evaluation. Specifically, the "include", "a", "mx", "ptr", and > "exists" mechanisms as well as the "redirect" modifier count against > this collective limit. Scott K From internet-drafts@ietf.org Mon Mar 25 13:31:06 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4684921F90BD; Mon, 25 Mar 2013 13:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiZenXSKPESI; Mon, 25 Mar 2013 13:31:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6CD21F9113; Mon, 25 Mar 2013 13:31:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130325203105.13841.3813.idtracker@ietfa.amsl.com> Date: Mon, 25 Mar 2013 13:31:05 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-13.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 20:31:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Sender Policy Framework (SPF) for Authorizing Use of Dom= ains in Email, Version 1 Author(s) : Scott Kitterman Filename : draft-ietf-spfbis-4408bis-13.txt Pages : 73 Date : 2013-03-25 Abstract: Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby an ADMD can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. This document obsoletes RFC4408. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Mon Mar 25 13:34:58 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D2821F93CE for ; Mon, 25 Mar 2013 13:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_AVOID=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKG3aZ6o0f11 for ; Mon, 25 Mar 2013 13:34:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CAFE321F92BA for ; Mon, 25 Mar 2013 13:34:56 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0C52E20E40CD; Mon, 25 Mar 2013 16:34:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364243696; bh=i9HCOY8MqC8iF6AeYp25gZLOSZMwRUS/4XW5rkBTuqo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Pi7iRXh5z7B3lmH9znJgFARa/hcPtQmzjWnjCNw2WYvk84Yx+T8caq3xBcwYI3C5U TEDhI1+0OZ3QluzRX8cRWWChknb8ffC9jm8GJVoCIb6tON6E6ycbVzkQxINK2qaMPg AGsTiJzpkn0vsL1KiSOHpWGVJqFh+doeWS0zCVik= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E0F0020E4062; Mon, 25 Mar 2013 16:34:55 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Mar 2013 16:34:55 -0400 Message-ID: <2257567.nS2ZGm5AVz@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <45461426.5BMDfefsaY@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] Reasonable DNS error limits #24 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Mar 2013 20:34:58 -0000 I worked this around a bit into a new security consideration (the why) and an addition the the DNS processing limit section (the what). Thanks. Scott K On Monday, March 18, 2013 08:31:58 PM Murray S. Kucherawy wrote: > I don't much care for the term "void lookup" (and Scott and I have > discussed this), but apart from that I'm in agreement with Mike that the > description and recommendation are reasonable additions. If I can come up > with a better term, I will. At a minimum, I would put a sentence or two > defining the term up front in the section where this is being added. > Something like this, perhaps (with corrections as appropriate): > > Concerns have been addressed that SPF verifiers can be used as > amplification agents for a denial-of-service attack. In this scenario, the > attacker publishes an SPF record in its own DNS that uses "a" and "mx" > mechanisms directed toward the intended victim, e.g. "a:example.com a: > foo.example.com a:bar.example.com ..." and then distributes mail with a > MAIL FROM value including its own domain in large volume to a wide variety > of destinations. Any such destination operating an SPF verifier will begin > querying all of the names associated with the "a" mechanisms in that > record. The names used in the record needn't exist for the attack to be > effective. > > A DNS query that returns either a positive answer (RCODE 0) with an answer > count of 0, or a no such record (RCODE 3) answer, is sometimes called a > "void lookup". Operational experience since publication of RFC4408 > suggests that mitigation of this class of attack can be accomplished with > minimal impact on the deployed base by having the verifier abort processing > and return "permerror" (Section x.x.x) once two void lookups have been > encountered. While an implementation may choose to make such a limit > configurable, such a limit SHOULD exist and the default of two is > RECOMMENDED. > > -MSK > > On Sat, Mar 16, 2013 at 2:19 PM, Dotzero wrote: > > Scott, > > > > Your analysis and recommendation sound reasonable. > > > > > > +1 > > > > On Sat, Mar 16, 2013 at 1:40 PM, Scott Kitterman > > > > wrote: > > > This is one of the few open issues we have remaining: > > > > > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/24 > > > > > >> 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. > > > > > > This "No Data limit" is already widely deployed as part of the modern > > > > Perl SPF > > > > > implementation, Mail::SPF. This is documented at: > > > > > > http://search.cpan.org/~jmehnle/Mail-SPF-v2.8.0/lib/Mail/SPF/Server.pm > > > > > >> max_void_dns_lookups > > >> > > >> An integer 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 (NXDOMAIN) before processing is aborted with a > > >> permerror result. If undef is specified, there is no stricter limit > > > > on > > > > >> the number of void DNS look-ups beyond the usual processing limits. > > >> Defaults to 2. > > >> > > >> Specifically, the DNS look-ups that are subject to this limit are > > > > those > > > > >> caused by the a, mx, ptr, and exists mechanisms and the p macro. > > >> > > >> A value of 2 is likely to prevent effective DoS attacks against > > >> third-party victim domains. However, a definite limit may cause > > >> permerror results even with certain (overly complex) innocent > > >> sender > > >> policies where useful results would normally be returned. > > > > > > The default of 2 has been in place since version 2.006, released on > > > 2008-08-17. > > > > > > I had hoped to have time (or find someone else who had time) to use the > > > > results > > > > > of Murray's previous SPF record survey to quantify the impact this might > > > > have > > > > > on existing records, but have not succeeded. Given that this has been > > > in > > > place, by default, for over 4 years on a very popular (using the Debian > > > GNU/Linux distribution popcon (popularity contest) data, I would > > > > estimate that > > > > > Mail::SPF is installed in almost 10% of Debian systems - it is by far > > > > the most > > > > > popular SPF implementation in the distribution) implementation, I think > > > > it is, > > > > > however, reasonable to assume that if it caused significant problems, > > > > they > > > > > would have come up by now. I did check with the primary developer > > > > (Julian > > > > > Mehnle) and he is not aware of people having problems with it. > > > > > > The only places a no data result will occur that are not due to a > > > > problem in > > > > > the record are for exists which do not match the given criteria and for > > > > ptr > > > > > (and p macro) if the connect IP has no reverse DNS. The Mail::SPF limit > > > > of > > > > > two allows for both these issues to occur in a record without raising an > > > error. > > > > > > My proposal is that we add this as a new limit in section 4.6.4, DNS > > > > Lookup > > > > > Limits, to resolve this issue. I think it's a useful limit, unlikely to > > > > cause > > > > > backward compatibility issues, and in scope for consideration due to > > > long > > > term, wide spread deployment. > > > > > > If there is some consensus around the concept, then we can come up with > > > specific text for 4.6.4, but I think it's useful to discuss the concept > > > > first. > > > > > Scott K > > > _______________________________________________ > > > spfbis mailing list > > > spfbis@ietf.org > > > https://www.ietf.org/mailman/listinfo/spfbis > > > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Mon Mar 25 13:36:35 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5A521F93D1 for ; Mon, 25 Mar 2013 13:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 eAa+Y4SNJDkr for ; Mon, 25 Mar 2013 13:36:35 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E06FE21F93D0 for ; Mon, 25 Mar 2013 13:36:34 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6ECFB20E40CD; Mon, 25 Mar 2013 16:36:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364243794; bh=7rUZzYVR+GxZXJVbAXFyzp5acVGP6VidlygI+tuOCkE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=i5pAC90obN2NOqQbbY5AuflX2Jxi2YqRvqyZaDY4OqkOB5P6Dz3ou82PRnEB2/KHV LOetnNHkVaGgo6xW5txaQc2StvD2/FzzVcMU5AVkm4DKS+iGoj2yYAzr7xao6yJVQ0 ydhxG36FKxVrbK8FeD1XJzCHeF4Vwlujl+XjRk+0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5F63120E4062; Mon, 25 Mar 2013 16:36:34 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Mar 2013 16:36:33 -0400 Message-ID: <1804790.RLFSdufdM7@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <20130325203105.13841.3813.idtracker@ietfa.amsl.com> References: <20130325203105.13841.3813.idtracker@ietfa.amsl.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] I-D Action: draft-ietf-spfbis-4408bis-13.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 20:36:35 -0000 On Monday, March 25, 2013 01:31:05 PM internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the SPF Update Working Group of > the IETF. > > Title : Sender Policy Framework (SPF) for Authorizing Use of > Domains in Email, Version 1 Author(s) : Scott Kitterman > Filename : draft-ietf-spfbis-4408bis-13.txt > Pages : 73 > Date : 2013-03-25 This draft incorporates some minor clarifications and reformatting as suggested by Stuart and Alessandro. It also includes the new DNS "void lookup" processing limit from Mail::SPF that we previously discussed. More significantly, this reduces the number of open issues in the tracker and the number of unread SPFbis mails I have sitting waiting for action both to zero. Scott K From sm@elandsys.com Mon Mar 25 13:44:19 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E59121F9165 for ; Mon, 25 Mar 2013 13:44:19 -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 INi+5Vkfaxba for ; Mon, 25 Mar 2013 13:44:17 -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 764BC21F9138 for ; Mon, 25 Mar 2013 13:44:17 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.156.25]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2PKi48o009738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Mar 2013 13:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364244256; bh=+y6p3u2tQ8IYnqL6bWu6RPN0J3JG8KvntDfBL8N9FMc=; h=Date:To:From:Subject:In-Reply-To:References; b=Ma5tPOsTGkdJj52rC8I9whMxt4Gvh/XQBueHdsdVyOIWNzbPqzhVshCCYArIXXT0s PzM5EMtkIzbsCI7rkMw7jcS+wNPws9/pzfd7yTW81epyePYV+N/mNvORz7NkyO5jry LKxtHmfqotMJsGZ+VkqLOEABzMB8RwniJBT1rQlE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1364244256; i=@elandsys.com; bh=+y6p3u2tQ8IYnqL6bWu6RPN0J3JG8KvntDfBL8N9FMc=; h=Date:To:From:Subject:In-Reply-To:References; b=bSPgU+WPUP8W+f8qXX4e3X2G2dxC5A3mRYYIJFX+LAzHPUA04U7BAL1cVuR13O2hs eF0a08wPrM3/jm7ixg6kVOy1WSideKXz10F0NL+5smzc1wTi3hjgwFKKoue1jyCzrl 9vtIIRqgoxziez+XQHTgvvJqWbj2dBpOOFSfvbNQ= Message-Id: <6.2.5.6.2.20130325134108.0dece4c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Mar 2013 13:43:56 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1804790.RLFSdufdM7@scott-latitude-e6320> References: <20130325203105.13841.3813.idtracker@ietfa.amsl.com> <1804790.RLFSdufdM7@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-13.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 20:44:19 -0000 At 13:36 25-03-2013, Scott Kitterman wrote: >More significantly, this reduces the number of open issues in the tracker and >the number of unread SPFbis mails I have sitting waiting for action both to >zero. Thanks for moving the work forward. Please send a message to spfbis-chairs@tools.ietf.org when draft-ietf-spfbis-4408bis is ready for WGLC. Regards, S. Moonesamy From spf2@kitterman.com Mon Mar 25 15:43:37 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D1C21F854F for ; Mon, 25 Mar 2013 15:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5O7gIrecppCt for ; Mon, 25 Mar 2013 15:43:37 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 493AB21F84A9 for ; Mon, 25 Mar 2013 15:43:37 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0487B20E40CD; Mon, 25 Mar 2013 18:43:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364251414; bh=91lAUHdq2LDsr9oy3f3qOH5/8v3uSM3ECHwv8dfIBN8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=dy8tU7x7+DzjGnQKkBsP2IKuzpOm47dQdaSlApVZPDidYNmUPq/AA2Gi5GT1QmAQc ZMJ/J8eq5vHzVcunfl4DrRZIgUwI7/W4T0da11z1L4LRlkdMq4Qe8nGE61JlB3cACS WSmpyodL9AVahSWikwlpT2h4uEbNN6bLp6PB6T88= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DE66320E4062; Mon, 25 Mar 2013 18:43:33 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Mar 2013 18:43:33 -0400 Message-ID: <2005925.n4O2vObA2K@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130325134108.0dece4c0@resistor.net> References: <20130325203105.13841.3813.idtracker@ietfa.amsl.com> <1804790.RLFSdufdM7@scott-latitude-e6320> <6.2.5.6.2.20130325134108.0dece4c0@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] I-D Action: draft-ietf-spfbis-4408bis-13.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 22:43:38 -0000 On Monday, March 25, 2013 01:43:56 PM S Moonesamy wrote: > At 13:36 25-03-2013, Scott Kitterman wrote: > >More significantly, this reduces the number of open issues in the tracker > >and the number of unread SPFbis mails I have sitting waiting for action > >both to zero. > > Thanks for moving the work forward. > > Please send a message to spfbis-chairs@tools.ietf.org when > draft-ietf-spfbis-4408bis is ready for WGLC. OK. I'll give it a few days for these changes to incubate, but otherwise, I think we're there. Scott K From vesely@tana.it Tue Mar 26 11:46:34 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD15B21F8C4C for ; Tue, 26 Mar 2013 11:46:34 -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 VFnOQI9tplQe for ; Tue, 26 Mar 2013 11:46:34 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D32A221F8820 for ; Tue, 26 Mar 2013 11:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1364323590; bh=T95dYRQF64OMBBTJLHzzrtKF0Cvho92O9h4ktah1LQU=; l=952; h=Date:From:To:References:In-Reply-To; b=SVXV85AniKLrk5xzY/tXIyCS5nzGwwoxHOvs6kW/pL6eCAi8W1SJE1jKL2jKbHy75 OZjPJeCmkXw5mx1rCGXjluJv6pMS5oTH8f9xXuBTVj++UbINvmiRCtbQQD+33h1zIU m1L+rfTMW4UDQ0mg5r8jO3os7TA5McoRh2cQPO90= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 26 Mar 2013 19:46:30 +0100 id 00000000005DC039.000000005151ED06.00007D37 Message-ID: <5151ED06.8050208@tana.it> Date: Tue, 26 Mar 2013 19:46:30 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <45461426.5BMDfefsaY@scott-latitude-e6320> <2257567.nS2ZGm5AVz@scott-latitude-e6320> In-Reply-To: <2257567.nS2ZGm5AVz@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Reasonable DNS error limits #24 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Mar 2013 18:46:34 -0000 On Mon 25/Mar/2013 21:34:55 +0100 Scott Kitterman wrote: > I worked this around a bit into a new security consideration (the why) and an > addition the the DNS processing limit section (the what). Thanks. I think it may be clearer if 11.1 *Processing Limits* refers back to Section 4.6.4 *DNS Lookup Limits* where "void lookups" is defined, rather than talking about "lookups of non-existent domains". The examples in 11.1 only mention "a" and "mx", while your original message mentioned also "ptr", "exists" and the p macro. Are implementers supposed to derive that on their own? Counting void lookups against "exists", as Mail::SPF::Server does, implies that at most one "exists" mechanism can be defined in a record and its descendants: A second "exists" must never fail (and hence it's futile) because its failure would trigger permerror, thereby requiring manual intervention on the record. Advice for publishers is deserved. From tim@eudaemon.net Tue Mar 26 18:15:28 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1513321F86A8 for ; Tue, 26 Mar 2013 18:15:28 -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 ck9N7SoDMqz4 for ; Tue, 26 Mar 2013 18:15:27 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 86BE921F84BD for ; Tue, 26 Mar 2013 18:15:13 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 8D580CB46 for ; Tue, 26 Mar 2013 21:15:49 -0400 (EDT) From: Tim Draegen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 26 Mar 2013 21:15:14 -0400 To: "spfbis@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [spfbis] clarification on when to lookup IPv6 addresses X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Mar 2013 01:15:28 -0000 Hi, I recently became confused about when IPv6 addresses should be = looked up. I naively thought that the "a" mechanism meant "perform A = record lookup and match using any returned addresses". However, I've = come to learn that Section 5 of RFC 4408 mentions this: When any mechanism fetches host addresses to compare with , when is an IPv4 address, A records are fetched, when is an IPv6 address, AAAA records are fetched. Even if the SMTP connection is via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section 2.5.5) MUST still be considered an IPv4 address. So, if the incoming connection is over IPv6, the "a:" mechanism should = perform AAAA queries. Neat! But obfuscated. I don't exactly understand where else the A vs AAAA consideration should = be applied. Since I wrote a diagnostic tool for doing SPF checking, = there is no "incoming connection", hence my oversight. I'll comb = through various reference libraries to find my answer, but I thought I'd = bring this up. How IPv6 fits into SPF can be made clearer. HTH, =3D- Tim From sm@elandsys.com Tue Mar 26 18:31:54 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D3E21F8629 for ; Tue, 26 Mar 2013 18:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhYn8SBmogvj for ; Tue, 26 Mar 2013 18:31: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 B075621F8600 for ; Tue, 26 Mar 2013 18:31:53 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.56]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2R1Vbr8003536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Mar 2013 18:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364347909; bh=jCQcQDobj3nfha7+vWIKjhbtDVNqhen8Km7wHkweA5c=; h=Date:To:From:Subject:In-Reply-To:References; b=yDZRulcSRV353toy138GvGj9omKYVhIkquvFElft6YV+kg5uESDGQ9PQ0jDUyKQSi gc8jYrEb3BvW2r5Fs0MeFH8qFE7mYcc4gpsRaAHFmEoDrLW2Mv/7WdDfcXTtVOV+S2 xox2VfKMPWZHYbNG/P64RKPf2EamclabOg7OQEzg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1364347909; i=@elandsys.com; bh=jCQcQDobj3nfha7+vWIKjhbtDVNqhen8Km7wHkweA5c=; h=Date:To:From:Subject:In-Reply-To:References; b=Niy3Czy/xi4bmG8onYJIIIoL4NNfU0mqIN4Xr32Dp0sGrbI1c9vdoCHWl7WIv/U/m qqiMlmDsFDIrozRUoRo/cdQRavE4kX2oHjJCmI45IX72rPaXSAWF49eIfQm8/Ypcyt gcaNXR2BERIOLKh8riffdpPeo+J4CPylq30YG+ZQ= Message-Id: <6.2.5.6.2.20130326182117.0d0e69f0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 26 Mar 2013 18:30:09 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <8793345.v9WZyjdpps@scott-latitude-e6320> References: <6.2.5.6.2.20130305081300.0a0b5b98@elandnews.com> <8793345.v9WZyjdpps@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Target date for draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Mar 2013 01:31:54 -0000 Hello, Thanks to Murray Kucherawy, Mike and Scott Kitterman for their feedback. The target date for draft-ietf-spfbis-4408bis is May 2013. The plan is to have a Working Group Last Call and an IETF Last Call before that date. Regards, S. Moonesamy SPFBIS WG co-chair From sm@resistor.net Tue Mar 26 18:38:57 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F6521F875A for ; Tue, 26 Mar 2013 18:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 Bf8ncefa+Is1 for ; Tue, 26 Mar 2013 18:38:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3415921F874E for ; Tue, 26 Mar 2013 18:38:57 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2R1cbfA001140; Tue, 26 Mar 2013 18:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364348322; bh=i/dtuoNXgNE5dtC8cUcwnN//aYegqFNvnDuVFmchDcg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=diXhCMHRlMTe0J+/Y9ynMOZfZns4IuxjVAVmJadBREtwEfv0zYYCyP30QQvRPW33o 3NQnjDx5JSBB9YxAz68Tz4Q7Z9e/8ji3/iECjY+aOp2WXIb57v9bJHfXcfOT2dEbMJ DDqqEp0t1ifr1Mtv+iyW0ot5JW7jPwTmDCULUz/I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1364348322; i=@resistor.net; bh=i/dtuoNXgNE5dtC8cUcwnN//aYegqFNvnDuVFmchDcg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LgyCNnA3UJJSkRtUafFVd/P1KBDDGSAbwJRRWg0xg082LgkuFRcx6Y4/K6X+Ip7GB 3ULEem395LvJBRc/bPi56rIEMp37f1xWAGgbPwdDu9Xa6PG7rm3+a6L7fm1ZSgy7WH kjXpv5jQ0GWHtqbnuaQoDS+ZpRo2hiTXFQK93exg= Message-Id: <6.2.5.6.2.20130326183242.0d17ea50@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 26 Mar 2013 18:38:26 -0700 To: Tim Draegen From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] clarification on when to lookup IPv6 addresses X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Mar 2013 01:38:57 -0000 Hi Tim, At 18:15 26-03-2013, Tim Draegen wrote: >Hi, I recently became confused about when IPv6 addresses should be >looked up. I naively thought that the "a" mechanism meant "perform >A record lookup and match using any returned addresses". However, >I've come to learn that Section 5 of RFC 4408 mentions this: > > When any mechanism fetches host addresses to compare with , when > is an IPv4 address, A records are fetched, when is an IPv6 > address, AAAA records are fetched. Even if the SMTP connection is > via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section > 2.5.5) MUST still be considered an IPv4 address. >So, if the incoming connection is over IPv6, the "a:" mechanism >should perform AAAA queries. Neat! But obfuscated. > >I don't exactly understand where else the A vs AAAA consideration >should be applied. Since I wrote a diagnostic tool for doing SPF >checking, there is no "incoming connection", hence my >oversight. I'll comb through various reference libraries to find my >answer, but I thought I'd bring this up. There is a thread at http://www.ietf.org/mail-archive/web/spfbis/current/msg03217.html about the text. Regards, -sm From spf2@kitterman.com Tue Mar 26 19:52:38 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650D321F86B1 for ; Tue, 26 Mar 2013 19:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rAgqf4vQivc for ; Tue, 26 Mar 2013 19:52:37 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAF421F8691 for ; Tue, 26 Mar 2013 19:52:37 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3A36820E40D2; Tue, 26 Mar 2013 22:52:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364352756; bh=35sJKP0S8oG6qDZzyTZOaVMwEoQF4moq1TlPw4QjQpQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=moXHs8ODT4jRMBdSSfaXri1cu5Jp00nyjkdfPsSVWztfSByDSAOAZQNOJg6M0pgJb G4dfeCqIxRoqgrWqSRS75yADS1PoL/Buyk3NOad+ucuTI1ZGNtOy+wBt3WrGZmG13Q zz7pGkY0jujMxpWK+cet24h2QdZ1oD9ERKGErsq0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1F5E820E40BE; Tue, 26 Mar 2013 22:52:35 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 26 Mar 2013 22:52:35 -0400 Message-ID: <1623038.9vy8POQLHT@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130326183242.0d17ea50@resistor.net> References: <6.2.5.6.2.20130326183242.0d17ea50@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] clarification on when to lookup IPv6 addresses X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Mar 2013 02:52:38 -0000 On Tuesday, March 26, 2013 06:38:26 PM SM wrote: > Hi Tim, > > At 18:15 26-03-2013, Tim Draegen wrote: > >Hi, I recently became confused about when IPv6 addresses should be > >looked up. I naively thought that the "a" mechanism meant "perform > >A record lookup and match using any returned addresses". However, > > > >I've come to learn that Section 5 of RFC 4408 mentions this: > > When any mechanism fetches host addresses to compare with , when > > is an IPv4 address, A records are fetched, when is an IPv6 > > address, AAAA records are fetched. Even if the SMTP connection is > > via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section > > 2.5.5) MUST still be considered an IPv4 address. > > > >So, if the incoming connection is over IPv6, the "a:" mechanism > >should perform AAAA queries. Neat! But obfuscated. > > > >I don't exactly understand where else the A vs AAAA consideration > >should be applied. Since I wrote a diagnostic tool for doing SPF > >checking, there is no "incoming connection", hence my > >oversight. I'll comb through various reference libraries to find my > >answer, but I thought I'd bring this up. > > There is a thread at > http://www.ietf.org/mail-archive/web/spfbis/current/msg03217.html > about the text. What we have now, from that thread in -13 is: > When any mechanism fetches host addresses to compare with , when > is an IPv4, "A" records are fetched; when is an IPv6 > address, "AAAA" records are fetched. SPF implementations on IPv6 > servers need to handle both "AAAA" and "A" secords, for clients on > IPv4 mapped IPv6 addresses [RFC4291]. IPv4 addresses are only > listed in an SPF record using the "ip4" mechanism. Tim: Is that clearer than RFC 4408 was? Would that have solved your problem? Scott K From spf2@kitterman.com Tue Mar 26 20:02:12 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5D021E803F for ; Tue, 26 Mar 2013 20:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 iyMfrDnH6WIa for ; Tue, 26 Mar 2013 20:02:11 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6624921E803D for ; Tue, 26 Mar 2013 20:02:11 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E625D20E40D2; Tue, 26 Mar 2013 23:02:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364353330; bh=KZHbF5bFkU1swFY966cedTG1VsUrgqWD42/hDkQJpAA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JR9IHnX8scah8fUXGa6bIbZnErPhPNI5pF/Upjf9Zsn3L1Geej+dcXSHMkFLdIC94 iGNkMFnBtpDmNcgToP+/g3APaZinQoRzs/WCF+ij+Czr366SiLK8HE5FippDfF0m9h 7tiTEiXMmj3Uqex27OUWVSGbVCmUfIIGtg+EMBJQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C6AB920E40BE; Tue, 26 Mar 2013 23:02:10 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 26 Mar 2013 23:02:10 -0400 Message-ID: <2307317.GyhSenpC3r@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <5151ED06.8050208@tana.it> References: <45461426.5BMDfefsaY@scott-latitude-e6320> <2257567.nS2ZGm5AVz@scott-latitude-e6320> <5151ED06.8050208@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] Reasonable DNS error limits #24 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Mar 2013 03:02:12 -0000 On Tuesday, March 26, 2013 07:46:30 PM Alessandro Vesely wrote: > On Mon 25/Mar/2013 21:34:55 +0100 Scott Kitterman wrote: > > I worked this around a bit into a new security consideration (the why) and > > an addition the the DNS processing limit section (the what). Thanks. > I think it may be clearer if 11.1 *Processing Limits* refers back to > Section 4.6.4 *DNS Lookup Limits* where "void lookups" is defined, > rather than talking about "lookups of non-existent domains". Fixed locally. > The examples in 11.1 only mention "a" and "mx", while your original > message mentioned also "ptr", "exists" and the p macro. Are > implementers supposed to derive that on their own? The list of DNS using terms is earlier in section 4.6.4. Since that's where the implementation guidance is, I think that's the right place to me exhaustive. > Counting void lookups against "exists", as Mail::SPF::Server does, > implies that at most one "exists" mechanism can be defined in a record > and its descendants: A second "exists" must never fail (and hence > it's futile) because its failure would trigger permerror, thereby > requiring manual intervention on the record. Advice for publishers is > deserved. The limit is two, so it's an error if there are three. The text in 11.1 was wrong (and inconsistent with 4.6.4). Fixed locally. Thanks for the feedback. Scott K From spf2@kitterman.com Tue Mar 26 21:01:46 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7126C21F8E55 for ; Tue, 26 Mar 2013 21:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoQ3ho6IqlwB for ; Tue, 26 Mar 2013 21:01:45 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 845CD21F8E51 for ; Tue, 26 Mar 2013 21:01:45 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CDACE20E40D2; Wed, 27 Mar 2013 00:01:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364356904; bh=7LTk0CfKcVK1dlkQH6jTZDvZHeRjhNrFsVIY6pjqOUI=; h=From:To:Subject:Date:From; b=iZJ6n3X2xdBtOffq5NYEmEiEtrPuPKbCtXCtwljC/gCIXQ6QDPNsUwBHgfVjfJetj URLP5KRwSughwQlXBlC9BlXTTvHxLYKGmBkvIde7xVB2WtTayht4fzCasPkS1/C/FI EXs/k3xFDDuRGNT7lBivul1Il8uaORR0hlyi2myM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B15C320E40BE; Wed, 27 Mar 2013 00:01:44 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 27 Mar 2013 00:01:42 -0400 Message-ID: <2171755.unhtkAshy1@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Summary for upgrades from RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Mar 2013 04:01:46 -0000 After I uploaded the last revision, I remembered that we said we would include a short section on technical changes from RFC 4408 when we were deciding on the document reorganization. Here's a first cut at it. I expect this will be another appendix. I was thinking right after the examples (this would then become Appendix C). Please suggest a better title. Appendix C. Changes in implementation requirements from RFC 4408 - Use of DNS RR type SPF (99) has been removed from the protocol [RFC 6686]. - A new DNS related processing limit based on "void lookups" has been added [section 4.6.4]. - A new option for converting repeated DNS SERVFAIL responses from temperror to permerror as been added [section 2.6.6]. - Use of the ptr mechanism and the %p macro have been strongly discouraged [section 5.5] and [section 7.2]. They remain part of the protocol, but records ought to be updated to avoid them. - Use of the Authentication Results header field [RFC 5451] as a possible alternative to use of the Received-SPF header field is discussed [section 9.2]. - There have been a number of minor corrections to the ABNF to make it more clear and correct [Appendix A]. SPF library implementers should give the revised ABNF a careful review to determine if implementation changes are needed. - Use of X- fields in the ABNF has been removed [RFC 6648]. - Ambiguity about how to deal invalid domain-spec after macro expansion has been documented. Depending on one specific behavior has to be avoided [section 4.8]. - General operational information has been updated and expanded based on 8 years of post [RFC 4408] operations experience [section 10] and Appendices D - H. - Security considerations have been reviewed and updated [section 11]. What did I miss? What should be worded better? Scott K From tim@eudaemon.net Wed Mar 27 06:27:00 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE2D21F8B18 for ; Wed, 27 Mar 2013 06:26:58 -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 ykSECb3GTiXu for ; Wed, 27 Mar 2013 06:26:58 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id ABD4021F8AE8 for ; Wed, 27 Mar 2013 06:26:57 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 9D820CB46 for ; Wed, 27 Mar 2013 09:27:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tim Draegen In-Reply-To: <1623038.9vy8POQLHT@scott-latitude-e6320> Date: Wed, 27 Mar 2013 09:26:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6FC85761-81F7-427C-AB1C-226D0F1953C1@eudaemon.net> References: <6.2.5.6.2.20130326183242.0d17ea50@resistor.net> <1623038.9vy8POQLHT@scott-latitude-e6320> To: "spfbis@ietf.org" X-Mailer: Apple Mail (2.1503) Subject: Re: [spfbis] clarification on when to lookup IPv6 addresses X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Mar 2013 13:27:00 -0000 On Mar 26, 2013, at 10:52 PM, Scott Kitterman = wrote: >=20 > What we have now, from that thread in -13 is: >=20 >> When any mechanism fetches host addresses to compare with , = when >> is an IPv4, "A" records are fetched; when is an IPv6 >> address, "AAAA" records are fetched. SPF implementations on IPv6 >> servers need to handle both "AAAA" and "A" secords, for clients on >> IPv4 mapped IPv6 addresses [RFC4291]. IPv4 addresses are only >> listed in an SPF record using the "ip4" mechanism. >=20 > Tim: >=20 > Is that clearer than RFC 4408 was? Would that have solved your = problem? It is a bit clearer, but my problem came from not connecting the dots = between the "a:" mechanism and doing AAAA lookups. It would be nice to = have (but not necessary) a link in the "a:" mechanism description about = this. =3D- Tim From SRS0=DqMFF=NP==stuart@gathman.org Wed Mar 27 07:01:14 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095F221F910B for ; Wed, 27 Mar 2013 07:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 u1zu9BLJxdAB for ; Wed, 27 Mar 2013 07:01:12 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 31CEA21F8528 for ; Wed, 27 Mar 2013 07:01:12 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1364392873; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Date : From : Subject; bh=3zaBwJaOOtQJ4AbvZq9+MdvBJL6selVvK+2X3Fmu+sE=; b=jsVdEuk7fyyczSYrQyQ7qcEGdcMTskYGlEYwUxcXBV6PfZyAvgz6wCAiyoxY+g9dUik+7F c/Bd/homB63W05RMFCXyyIhjeUsqRSPNSH9DtVZ/xjMtrxlTcxS1v/hZ2kWQXH7MQexm2r1R gaZLdTe0PdKNuNnLE9qvM/TVzURYQ= Received: from melissa.gathman.org (ip72-205-26-231.dc.dc.cox.net [72.205.26.231]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r2RE1CNa021977 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 27 Mar 2013 10:01:13 -0400 Message-ID: <5152FBA6.5050201@gathman.org> Date: Wed, 27 Mar 2013 10:01:10 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal><5015F1A7.50000@gathman.org><501B2180.9090304@gathman.org><0D2A0D5F64179F4F9556D3DEDE39F9AF010D3CFD@XCHANGE.rvl.internal> <0D2A0D5F64179F4F9556D3DEDE39F9AF010D3D13@XCHANGE.rvl.internal> In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF010D3D13@XCHANGE.rvl.internal> Content-Type: multipart/alternative; boundary="------------090507030600020801080505" Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Mar 2013 15:22:53 -0000 This is a multi-part message in MIME format. --------------090507030600020801080505 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Long ago, Nostradamus foresaw that on 08/03/2012 02:51 AM, Wayne Doust would write: > > This is OT: But I temp-fail on SPF Fail with the reason why and a > phone number to ring. This gives the sender a chance to call us and > have them placed in our white-list. I also auto white-list all > outgoing email addresses. The users know that if someone can't email > them, then sending the SENDER an email usually "fixes" that. > > > > As the adoption of SPF moves forward, I will probably start using an > initial temp-fail on SPF SoftFail. > I apply heuristics to attempt to "fix" the syntax error (e.g. a:1.2.3.4 -> ip4:1.2.3.4) and re-evaluate to result to give a rather more that usually informed "best guess". If the heuristic result is Pass, a DSN with a diagnostic for the syntax error is sent to the sender, and the message is accepted. The Received-SPF header still says PermError. Back to the RFC, it should be very clear that any Received-SPF or Authentication-Results header should show the *actual* SPF result, and not any such heuristics. Example: Received-SPF: PermError (mail.example.com: permanent error in processing domain of example.com.br: Use the ip4 mechanism for ip4 addresses) client-ip=192.0.2.14; envelope-from="6F1ED9F@example.com.br"; helo="[198.51.100.207]"; receiver=mail.example.com; problem="a:203.0.113.73"; mechanism=?all; x-bestguess=neutral; x-helo-spf=none; identity=mailfrom --------------090507030600020801080505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Long ago, Nostradamus foresaw that on 08/03/2012 02:51 AM, Wayne Doust would write:

This is OT: But I temp-fail on SPF Fail with the reason why and a phone number to ring. This gives the sender a chance to call us and have them placed in our white-list. I also auto white-list all outgoing email addresses. The users know that if someone can’t email them, then sending the SENDER an email usually “fixes” that.

 

As the adoption of SPF moves forward, I will probably start using an initial temp-fail on SPF SoftFail.

I apply heuristics to attempt to "fix" the syntax error (e.g. a:1.2.3.4 -> ip4:1.2.3.4) and re-evaluate to result to give a rather more that usually informed "best guess".  If the heuristic result is Pass, a DSN with a diagnostic for the syntax error is sent to the sender, and the message is accepted.  The Received-SPF header still says PermError.

Back to the RFC, it should be very clear that any Received-SPF or Authentication-Results header should show the *actual* SPF result, and not any such heuristics.   Example:

Received-SPF: PermError (mail.example.com: permanent error in processing domain of example.com.br: Use the ip4 mechanism for ip4 addresses) client-ip=192.0.2.14; envelope-from="6F1ED9F@example.com.br"; helo="[198.51.100.207]"; receiver=mail.example.com; problem="a:203.0.113.73"; mechanism=?all; x-bestguess=neutral; x-helo-spf=none; identity=mailfrom
--------------090507030600020801080505-- From spf2@kitterman.com Sun Mar 31 12:42:52 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B17021F86C1 for ; Sun, 31 Mar 2013 12:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEs7lv9Y4xOO for ; Sun, 31 Mar 2013 12:42:51 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3E51021F8696 for ; Sun, 31 Mar 2013 12:42:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2B9A520E40DE; Sun, 31 Mar 2013 15:42:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364758963; bh=xZ9Djc4El+cYs3hSnKXPmOiDGN+FyVWPngbLGlcDdAc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ahRyFMSGIn4TFM5Edwxij9cPR+gqf5Q/0B//5Z85I8Qs9bQ3pLS8eEvi9oICeTvTc 0awfKul1jccmttibKSRvVdW09qM0fnE/WCZhxk4et4D61n4UyPJ8QXzjDeYvP3oPW3 l3xeGx4/PHJxL/6smfdf/dNdMIK/FjjYcyjhgvVE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 10FE620E40C6; Sun, 31 Mar 2013 15:42:42 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 31 Mar 2013 15:42:41 -0400 Message-ID: <2726884.1PfuDJCn6J@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <6FC85761-81F7-427C-AB1C-226D0F1953C1@eudaemon.net> References: <1623038.9vy8POQLHT@scott-latitude-e6320> <6FC85761-81F7-427C-AB1C-226D0F1953C1@eudaemon.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] clarification on when to lookup IPv6 addresses X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Mar 2013 19:42:52 -0000 On Wednesday, March 27, 2013 09:26:56 AM Tim Draegen wrote: > On Mar 26, 2013, at 10:52 PM, Scott Kitterman wrote: > > What we have now, from that thread in -13 is: > >> When any mechanism fetches host addresses to compare with , when > >> is an IPv4, "A" records are fetched; when is an IPv6 > >> address, "AAAA" records are fetched. SPF implementations on IPv6 > >> servers need to handle both "AAAA" and "A" secords, for clients on > >> IPv4 mapped IPv6 addresses [RFC4291]. IPv4 addresses are only > >> listed in an SPF record using the "ip4" mechanism. > > > > Tim: > > > > Is that clearer than RFC 4408 was? Would that have solved your problem? > > It is a bit clearer, but my problem came from not connecting the dots > between the "a:" mechanism and doing AAAA lookups. It would be nice to > have (but not necessary) a link in the "a:" mechanism description about > this. OK. How about this (just committed locally for the next update): a = "a" [ ":" domain-spec ] [ dual-cidr-length ] - An address lookup is done on the . The is compared - to the returned address(es). If any address matches, the mechanism - matches. + An address lookup is done on the using the type of + lookup (A or AAAA) appropriate for the connection type. The is + compared to the returned address(es). If any address matches, the + mechanism matches. Scott K From WebMaster@Commerco.Net Sun Mar 31 13:29:23 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA3921F853A for ; Sun, 31 Mar 2013 13:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.611 X-Spam-Level: X-Spam-Status: No, score=0.611 tagged_above=-999 required=5 tests=[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 ogCSntCNXFrp for ; Sun, 31 Mar 2013 13:29:22 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8677C21F84F1 for ; Sun, 31 Mar 2013 13:29:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=QGRDnhwZ9MksK/S08J5MLBxxaRawhjRTJvto9yde+R4UdRJN6nC/unz5ZbMQnrkmgVR/h5WJxkm6KbRkV1Aw2g67UUO9K0U8VeqI1+0Eeq0hGxauZufH9JDvUSxmLn/5S0kx65G7U2gjRZ/DoefV37vy6NTf4wNYYq+6YFgpqqQ= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.6) with ESMTP (EHLO [10.240.241.49]); Sun, 31 Mar 2013 20:29:22 +0000 Message-ID: <51589C9B.7050001@Commerco.Net> Date: Sun, 31 Mar 2013 14:29:15 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: spfbis@ietf.org References: <1623038.9vy8POQLHT@scott-latitude-e6320> <6FC85761-81F7-427C-AB1C-226D0F1953C1@eudaemon.net> <2726884.1PfuDJCn6J@scott-latitude-e6320> In-Reply-To: <2726884.1PfuDJCn6J@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: Scott Kitterman Subject: Re: [spfbis] clarification on when to lookup IPv6 addresses X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Mar 2013 20:29:23 -0000 On 3/31/2013 1:42 PM, Scott Kitterman wrote: > On Wednesday, March 27, 2013 09:26:56 AM Tim Draegen wrote: >> On Mar 26, 2013, at 10:52 PM, Scott Kitterman wrote: >>> What we have now, from that thread in -13 is: >>>> When any mechanism fetches host addresses to compare with , when >>>> is an IPv4, "A" records are fetched; when is an IPv6 >>>> address, "AAAA" records are fetched. SPF implementations on IPv6 >>>> servers need to handle both "AAAA" and "A" secords, for clients on >>>> IPv4 mapped IPv6 addresses [RFC4291]. IPv4 addresses are only >>>> listed in an SPF record using the "ip4" mechanism. >>> >>> Tim: >>> >>> Is that clearer than RFC 4408 was? Would that have solved your problem? >> >> It is a bit clearer, but my problem came from not connecting the dots >> between the "a:" mechanism and doing AAAA lookups. It would be nice to >> have (but not necessary) a link in the "a:" mechanism description about >> this. > > OK. How about this (just committed locally for the next update): > > a = "a" [ ":" domain-spec ] [ dual-cidr-length ] > > - An address lookup is done on the . The is compared > - to the returned address(es). If any address matches, the mechanism > - matches. > + An address lookup is done on the using the type of > + lookup (A or AAAA) appropriate for the connection type. The is > + compared to the returned address(es). If any address matches, the > + mechanism matches. > > Scott K +1 Perhaps you might also consider adding parenthetically "(e.g., IPv4 or IPv6)" or just "(IPv4 or IPv6)" after "connection type" for explanatory emphasis and balance to the parenthetical "(A or AAAA)" after "type of lookup". Alan M. From spf2@kitterman.com Sun Mar 31 14:00:33 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B4821F8606 for ; Sun, 31 Mar 2013 14:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+R6EbkpRiWw for ; Sun, 31 Mar 2013 14:00:32 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3876221F850F for ; Sun, 31 Mar 2013 14:00:32 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3F24020E40DE; Sun, 31 Mar 2013 17:00:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364763631; bh=hMihXDhLV7F/UV9imzAT4gAe36voGwE5qZy267a9k80=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PdT9ZL4pF36WBrKDddhUAA2kcPVB2KEVdSbeyzRPdVKTzCJVVCMHDzolniSz3DeDD JDfo7A6x69FSbF4MIufdUOKuGBcY5oPonyAXAhZosQ1RtL5+UR2mxLVTJf+L2oz2kO 2yH3KYSRbf/vdwplmYKH2fb648cAobmeosmfnYwE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2697C20E40C6; Sun, 31 Mar 2013 17:00:30 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 31 Mar 2013 17:00:30 -0400 Message-ID: <1593470.339JcrkDSB@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <51589C9B.7050001@Commerco.Net> References: <2726884.1PfuDJCn6J@scott-latitude-e6320> <51589C9B.7050001@Commerco.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] clarification on when to lookup IPv6 addresses X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Mar 2013 21:00:33 -0000 On Sunday, March 31, 2013 02:29:15 PM Commerco WebMaster wrote: > On 3/31/2013 1:42 PM, Scott Kitterman wrote: > > On Wednesday, March 27, 2013 09:26:56 AM Tim Draegen wrote: > >> On Mar 26, 2013, at 10:52 PM, Scott Kitterman wrote: > >>> What we have now, from that thread in -13 is: > >>>> When any mechanism fetches host addresses to compare with , when > >>>> is an IPv4, "A" records are fetched; when is an IPv6 > >>>> address, "AAAA" records are fetched. SPF implementations on IPv6 > >>>> servers need to handle both "AAAA" and "A" secords, for clients on > >>>> IPv4 mapped IPv6 addresses [RFC4291]. IPv4 addresses are only > >>>> listed in an SPF record using the "ip4" mechanism. > >>> > >>> Tim: > >>> > >>> Is that clearer than RFC 4408 was? Would that have solved your problem? > >> > >> It is a bit clearer, but my problem came from not connecting the dots > >> between the "a:" mechanism and doing AAAA lookups. It would be nice to > >> have (but not necessary) a link in the "a:" mechanism description about > >> this. > > > > OK. How about this (just committed locally for the next update): > > a = "a" [ ":" domain-spec ] [ dual-cidr-length ] > > > > - An address lookup is done on the . The is compared > > - to the returned address(es). If any address matches, the mechanism > > - matches. > > + An address lookup is done on the using the type of > > + lookup (A or AAAA) appropriate for the connection type. The is > > + compared to the returned address(es). If any address matches, the > > + mechanism matches. > > > > Scott K > > +1 > > Perhaps you might also consider adding parenthetically "(e.g., IPv4 or > IPv6)" or just "(IPv4 or IPv6)" after "connection type" for explanatory > emphasis and balance to the parenthetical "(A or AAAA)" after "type of > lookup". Done. Thanks. Scott K From spf2@kitterman.com Sun Mar 31 14:30:27 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C497B21F8659 for ; Sun, 31 Mar 2013 14:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmjNeEPpK1+K for ; Sun, 31 Mar 2013 14:30:27 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0983121F863B for ; Sun, 31 Mar 2013 14:30:27 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 885D920E40DE; Sun, 31 Mar 2013 17:30:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364765426; bh=80qDE74qRqByZBG7B3ytrr1nHHJsUja6NnUr0iKPEfw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=C1IqUrI1LIkELaSvmHYxDI5QRL0zFsbWZHg7T9JjClsqJqJKe7Oml7vGYuMFLBTi7 GeB1bUQE33nhnOjQ12OjeYtpbJFSO2q0xBMdKx20IaIn536Dm25iBqUVSspc7g413K KelPxG0sHMTaHnz3wxgkdMQVgwTbL+76770n+UeU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 70BE620E40C6; Sun, 31 Mar 2013 17:30:26 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 31 Mar 2013 17:30:25 -0400 Message-ID: <2312084.dQrlQ2JCVg@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <2171755.unhtkAshy1@scott-latitude-e6320> References: <2171755.unhtkAshy1@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] Summary for upgrades from RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Mar 2013 21:30:27 -0000 On Wednesday, March 27, 2013 12:01:42 AM Scott Kitterman wrote: > After I uploaded the last revision, I remembered that we said we would > include a short section on technical changes from RFC 4408 when we were > deciding on the document reorganization. Here's a first cut at it. I > expect this will be another appendix. I was thinking right after the > examples (this would then become Appendix C). Please suggest a better > title. > > Appendix C. Changes in implementation requirements from RFC 4408 > > - Use of DNS RR type SPF (99) has been removed from the protocol [RFC > 6686]. > > - A new DNS related processing limit based on "void lookups" has been added > [section 4.6.4]. > > - A new option for converting repeated DNS SERVFAIL responses from > temperror to permerror as been added [section 2.6.6]. > > - Use of the ptr mechanism and the %p macro have been strongly discouraged > [section 5.5] and [section 7.2]. They remain part of the protocol, but > records ought to be updated to avoid them. > > - Use of the Authentication Results header field [RFC 5451] as a possible > alternative to use of the Received-SPF header field is discussed [section > 9.2]. > > - There have been a number of minor corrections to the ABNF to make it more > clear and correct [Appendix A]. SPF library implementers should give the > revised ABNF a careful review to determine if implementation changes are > needed. > > - Use of X- fields in the ABNF has been removed [RFC 6648]. > > - Ambiguity about how to deal invalid domain-spec after macro expansion has > been documented. Depending on one specific behavior has to be avoided > [section 4.8]. > > - General operational information has been updated and expanded based on 8 > years of post [RFC 4408] operations experience [section 10] and Appendices D > - H. > > - Security considerations have been reviewed and updated [section 11]. > > What did I miss? What should be worded better? I have not gotten much in the way of feedback on this and I think it's important to get right. I'd appreciate if anyone else has reviewed the proposed text and finds it OK, they say so. I'm somewhat reluctant to commit it to 4408bis without that. This is all I'm waiting on before publishing -14 and telling the chairs I think we're ready for WGLC. Scott K From superuser@gmail.com Sun Mar 31 15:40:11 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9444421F86D3 for ; Sun, 31 Mar 2013 15:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ewU9KwBUuAm for ; Sun, 31 Mar 2013 15:40:10 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA2621F875D for ; Sun, 31 Mar 2013 15:40:09 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so1712216wgg.2 for ; Sun, 31 Mar 2013 15:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=V5XqEbIO8PW5ybeT8CD7XK2n4KRzO01vgh4kiOoVhnw=; b=ra0Ih/v+OaCoKES0bfP338ZWwRv7ntj8m5E58R2gb+iOn8HxXyyiPFcHJD3Ywwp5U6 9m0G+3k704nwdyA0XAAnDs3ngJZti9+ALM9Cg4W8a7agPt+ub3gcIZqF3tHn38SlAT28 sAZklWcHYes4t2bPXiE3lZRjGDt/pVgbSOltw5yEWe5S9Uu99+o2Dl0cTXiokX/DIjge NWMef+FOEqhoyO/bvJ7q4nyzF/CyQ8LRHofOr0asqWDbw8HQP1lAUeUZMEL1vb2tQEFY 0f+91cnkFR+s0nkJTJXq92J8IB7HZk0Qjt7eX0y58W2OHsasXxAz8BmdT8j4zspATZLg Rtrw== MIME-Version: 1.0 X-Received: by 10.180.94.133 with SMTP id dc5mr7447282wib.1.1364769608109; Sun, 31 Mar 2013 15:40:08 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Sun, 31 Mar 2013 15:40:07 -0700 (PDT) In-Reply-To: <2312084.dQrlQ2JCVg@scott-latitude-e6320> References: <2171755.unhtkAshy1@scott-latitude-e6320> <2312084.dQrlQ2JCVg@scott-latitude-e6320> Date: Sun, 31 Mar 2013 15:40:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d04462e66b1162904d9402f66 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Summary for upgrades from RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Mar 2013 22:40:11 -0000 --f46d04462e66b1162904d9402f66 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 31, 2013 at 2:30 PM, Scott Kitterman wrote: > > Appendix C. Changes in implementation requirements from RFC 4408 > I would add a note at the top of the section that indicates the changes are all either (a) corrections to errors in 4408, or (b) additional documentation based on consensus of operational experience acquired since publication of 4408. Otherwise, a reviewer might wonder what the basis of some or all of these might be. > - Use of DNS RR type SPF (99) has been removed from the protocol [RFC > > 6686]. > > > > - A new DNS related processing limit based on "void lookups" has been > added > > [section 4.6.4]. > > > > - A new option for converting repeated DNS SERVFAIL responses from > > temperror to permerror as been added [section 2.6.6]. > > > > - Use of the ptr mechanism and the %p macro have been strongly > discouraged > > [section 5.5] and [section 7.2]. They remain part of the protocol, but > > records ought to be updated to avoid them. > "...because they were found to still be in use..." > > - Use of the Authentication Results header field [RFC 5451] as a > possible > > alternative to use of the Received-SPF header field is discussed [section > > 9.2] > "Authentication-Results" > > - There have been a number of minor corrections to the ABNF to make it > more > > clear and correct [Appendix A]. SPF library implementers should give the > > revised ABNF a careful review to determine if implementation changes are > > needed. > > > > - Use of X- fields in the ABNF has been removed [RFC 6648]. > > > > - Ambiguity about how to deal invalid domain-spec after macro expansion > has > > been documented. Depending on one specific behavior has to be avoided > > [section 4.8]. > "...deal with..." -MSK --f46d04462e66b1162904d9402f66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Mar 31, 2013 at 2:30 PM, Scott Kitterman <spf2@k= itterman.com> wrote:
>= Appendix C. =A0Changes in implementation requirements from RFC 4408

I would add a note at the top of the secti= on that indicates the changes are all either (a) corrections to errors in 4= 408, or (b) additional documentation based on consensus of operational expe= rience acquired since publication of 4408.=A0 Otherwise, a reviewer might w= onder what the basis of some or all of these might be.

> =A0- Use of DNS RR type SPF (99) has been removed from the protocol [R= FC
> 6686].
>
> =A0- A new DNS related processing limit based on "void lookups&qu= ot; has been added
> [section 4.6.4].
>
> =A0- A new option for converting repeated DNS SERVFAIL responses from<= br> > temperror to permerror as been added [section 2.6.6].
>
> =A0- Use of the ptr mechanism and the %p macro have been strongly disc= ouraged
> [section 5.5] and [section 7.2]. =A0They remain part of the protocol, = but
> records ought to be updated to avoid them.

"...because they were found to still be in use...= "
=A0
> =A0- Use of the Authentication Results header field [RFC 5451] as a po= ssible
> alternative to use of the Received-SPF header field is discussed [sect= ion
> 9.2]

"Authenticat= ion-Results"
=A0
> =A0- There have been a number of minor corrections to the ABNF to make= it more
> clear and correct [Appendix A]. =A0SPF library implementers should giv= e the
> revised ABNF a careful review to determine if implementation changes a= re
> needed.
>
> =A0- Use of X- fields in the ABNF has been removed [RFC 6648].
>
> =A0- Ambiguity about how to deal invalid domain-spec after macro expan= sion has
> been documented. =A0Depending on one specific behavior has to be avoid= ed
> [section 4.8].

".= ..deal with..."
=A0
-MSK
--f46d04462e66b1162904d9402f66-- From superuser@gmail.com Sun Mar 31 22:26:20 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6BC21F867D for ; Sun, 31 Mar 2013 22:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8cPWPY4bhII for ; Sun, 31 Mar 2013 22:26:19 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 35EF021F84D5 for ; Sun, 31 Mar 2013 22:26:18 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so1845350wgg.0 for ; Sun, 31 Mar 2013 22:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=vFizRufYq5O/+Y4+PKEZqIOQDZdPDQVaEZO0c8PEoDM=; b=PovbTq4EJG9FF9uMKfkaD+pIjQVXYmBLrRwBMJ1hVUwM7AMe03PyRoE111d3Ry6EYG sGK8CMZINMZBKrt24YUzuftIUohje3MK7rysD/mKtQfr1ewXJ+/DwvFaO9R6OrWsPoCe H5GUrSIxuZ8t85Np+PCbbNB8UVPDrbY2h+/Ck0HRzkSdRFtNUB+jwRwTjjooE7GBuXLs 6MjX/dztuZYL3YhJQSqfPURNPTC+y+NRHdr/7hm7ialb4zX3XhkvAx9nlPZLKHcBNPF2 r7JD6q2KmCRSkqV8I71PelDkltZZUfDwOrpxAM1T3PVgfGazvlqax8I/3Vo/Ik9RG29R 82DA== MIME-Version: 1.0 X-Received: by 10.180.77.226 with SMTP id v2mr8055367wiw.33.1364793978315; Sun, 31 Mar 2013 22:26:18 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Sun, 31 Mar 2013 22:26:18 -0700 (PDT) Date: Sun, 31 Mar 2013 22:26:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7f1a44eb3104d945dce5 Subject: [spfbis] DMARC working group charter proposal X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Apr 2013 05:26:20 -0000 --f46d043c7f1a44eb3104d945dce5 Content-Type: text/plain; charset=ISO-8859-1 At the IETF meeting in Atlanta, Tim Draegen presented a proposal for DMARC, which is an email authentication and reporting layer atop SPF and DKIM. The externally-developed proposal is now in widespread deployment by a number of large-scale providers. The group that developed it is seeking to bring it to the IETF for further development and broad review, and development of operational guidance. A first draft of a charter can be found linked from http://wiki.tools.ietf.org/wg/appsawg/trac/wiki. There is a dmarc@ietf.org list available for discussing the technical contents of the work and also this draft charter. Please follow up there with any charter contents so we don't innundate this list with that discussion. To subscribe to that list: https://www.ietf.org/mailman/listinfo/dmarc -MSK --f46d043c7f1a44eb3104d945dce5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
At the IETF meeting in Atlanta, Tim Draegen= presented a=20 proposal for DMARC, which is an email authentication and reporting layer atop SPF and DKIM.=A0 The externally-developed proposal is now in=20 widespread deployment by a number of large-scale providers.=A0 The group=20 that developed it is seeking to bring it to the IETF for further=20 development and broad review, and development of operational guidance.
<= br>
A first draft of a charter can be found linked from http://wiki.tools.ietf.org/wg= /appsawg/trac/wiki.

There is a dmarc@ietf.org list available f= or discussing the technical=20 contents of the work and also this draft charter.=A0 Please follow up=20 there with any charter contents so we don't innundate this list with=20 that discussion.=A0 To subscribe to that list:

https://www.ietf.org/mailman/listinfo/dm= arc

-MSK
--f46d043c7f1a44eb3104d945dce5--