From vesely@tana.it Wed Feb 1 03:37:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD65C21F85AF for ; Wed, 1 Feb 2012 03:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.63 X-Spam-Level: X-Spam-Status: No, score=-4.63 tagged_above=-999 required=5 tests=[AWL=0.089, 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 go3UmsCzOy01 for ; Wed, 1 Feb 2012 03:37:26 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id DE32C21F85A5 for ; Wed, 1 Feb 2012 03:37:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328096245; bh=Pb88rnxM3vQ6lP66ybDkTd1sv2co3+BTqdFWfCDqJIQ=; l=217; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=fcCyyiCreLbKFDJCtr5P2F7tYsR94YOBrpYhlgMFtUlTmtwGDihqm34YXNdMxZHqr t4nAMFl5u1IvKd8wJK5o0UtOFrpkFIHzvyFalglp0Ud8UEE9yH17Lt/22gwu+q6t2l Lx8DB6tB5MNa84okcCdkzURBwHHQn8QDqk5Mnnm4= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 01 Feb 2012 12:37:24 +0100 id 00000000005DC039.000000004F2923F4.00002C61 Message-ID: <4F2923F4.2080309@tana.it> Date: Wed, 01 Feb 2012 12:37:24 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F28DBB7.5070101@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Feb 2012 11:37:26 -0000 On 01/Feb/12 07:50, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Pete Resnick > >> Please review the below and see if there is anything that makes your >> head explode. > > Looks okay to me. +1 From dhc2@dcrocker.net Wed Feb 1 03:52:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DFA21F8629 for ; Wed, 1 Feb 2012 03:52:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMX9HQ--6M5c for ; Wed, 1 Feb 2012 03:52:51 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5943121F8621 for ; Wed, 1 Feb 2012 03:52:51 -0800 (PST) Received: from [10.0.0.73] (wsip-68-101-40-225.dc.dc.cox.net [68.101.40.225]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q11Bqf8b006406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Feb 2012 03:52:49 -0800 Message-ID: <4F292787.5040109@dcrocker.net> Date: Wed, 01 Feb 2012 06:52:39 -0500 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Pete Resnick References: <4F28DBB7.5070101@qualcomm.com> In-Reply-To: <4F28DBB7.5070101@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 01 Feb 2012 03:52:50 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 11:52:53 -0000 On 2/1/2012 1:29 AM, Pete Resnick wrote: > addition of any enhancements > that have already gained widespread support, What additions are being proposed and considered? This clause broadens the scope significantly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Wed Feb 1 04:08:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C59B21F8513 for ; Wed, 1 Feb 2012 04:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuYsOyrHQrNa for ; Wed, 1 Feb 2012 04:08:00 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD7C21F84E2 for ; Wed, 1 Feb 2012 04:07:59 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id E75FAD0408B; Wed, 1 Feb 2012 06:07:58 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328098079; bh=MyL+oGCEFfqhIN82gZzC18QHcW5+jsQog/XJwE4K7+w=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=fQdgV1ctG11D1Ttx3zRNcLdv8IsvQ89uy1VGhHyNB4Hh5ynmeZX8A3sUz8aKBAkKE fqjJkSo1pvR1UpvYhUowVTzMwAP9xT10sHsJ/B+dGq86LjASSDhdBxzX0gQCglN9xX oHCzUk/KrNea9brBgOPHYYZrWX5Pw4oNUQbjcXSY= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A70E1D0400D; Wed, 1 Feb 2012 06:07:58 -0600 (CST) References: <4F28DBB7.5070101@qualcomm.com> <4F292787.5040109@dcrocker.net> User-Agent: K-9 Mail for Android In-Reply-To: <4F292787.5040109@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 01 Feb 2012 07:08:08 -0500 To: spfbis@ietf.org Message-ID: <18eefd51-d3d1-4db6-92bb-5ebf37cbe516@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Feb 2012 12:08:00 -0000 Dave CROCKER wrote: > > >On 2/1/2012 1:29 AM, Pete Resnick wrote: >> addition of any enhancements >> that have already gained widespread support, > > >What additions are being proposed and considered? > >This clause broadens the scope significantly. FWIW, I'm not aware of anything that would currently meet that criteria and the only thing that might in the time frame we're discussing is the SPF failure feedback report going on in MARF. If this language lets us transition the SPF modifier registry into 4408bis, then it's probably useful. Scott K From presnick@qualcomm.com Wed Feb 1 07:39:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4542B11E80B2 for ; Wed, 1 Feb 2012 07:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gs9Cf9dzanms for ; Wed, 1 Feb 2012 07:39:25 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 8422711E8071 for ; Wed, 1 Feb 2012 07:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1328110765; x=1359646765; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F295CA2.7030902@qualcomm.com>|Date:=20We d,=201=20Feb=202012=2009:39:14=20-0600|From:=20Pete=20Res nick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20|CC:=20Dave =20CROCKER=20,=20 |Subject:=20Re:=20[spfbis]=20Updated=20charter=20-=20fina l=20review|References:=20<4F28DBB7.5070101@qualcomm.com> =20<4F292787.5040109@dcrocker.net>|In-Reply-To:=20<4F2927 87.5040109@dcrocker.net>|Content-Type:=20text/plain=3B=20 charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=sf4sK3TxbZTv+KcMBBXVCGD9Mvv7u9geaZkxkmoozaM=; b=Z/X/r0t4rk1VU7QtLLFk9yCBGcQy0GLSAx1rAw5EvhZWIBmzmOOC96Uq 9Mc7RJQzTRdadUAtsid6nHWV4+WshNop/X9Ui415hFquVSgSIpWst9cJ2 WzzJB54VMhWX8t0ag65LatA4ynWmoLjFbkaZD/nn2xQxPx1ZBLhvtPr0N I=; X-IronPort-AV: E=McAfee;i="5400,1158,6606"; a="159659916" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 01 Feb 2012 07:39:21 -0800 X-IronPort-AV: E=Sophos;i="4.71,602,1320652800"; d="scan'208";a="158014893" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 01 Feb 2012 07:39:20 -0800 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 1 Feb 2012 07:39:16 -0800 Message-ID: <4F295CA2.7030902@qualcomm.com> Date: Wed, 1 Feb 2012 09:39:14 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <4F28DBB7.5070101@qualcomm.com> <4F292787.5040109@dcrocker.net> In-Reply-To: <4F292787.5040109@dcrocker.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: spfbis@ietf.org, Dave CROCKER Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Feb 2012 15:39:26 -0000 On 2/1/12 5:52 AM, Dave CROCKER wrote: > On 2/1/2012 1:29 AM, Pete Resnick wrote: >> addition of any enhancements >> that have already gained widespread support, > > What additions are being proposed and considered? > > This clause broadens the scope significantly. This line has been in the charter since it went to the IESG and for IETF review. My read of the line has always been that there is a burden on the proposer to show that any particular enhancement already has implementation and that the community has already (past tense) given the feature widespread support. I am willing to leave to the judgment of the chairs (and myself) whether the WG has clear consensus on the "widespread support" of such an enhancement should one come forward. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From spf2@kitterman.com Wed Feb 1 07:45:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B2111E80F7 for ; Wed, 1 Feb 2012 07:45:48 -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 Cm4zYNhbcoa2 for ; Wed, 1 Feb 2012 07:45:47 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 78FC511E8071 for ; Wed, 1 Feb 2012 07:45:47 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8F63F20E40D0; Wed, 1 Feb 2012 10:45:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328111146; bh=owlPvG9BOwUtGPd7YwzMK1xjM350VVbiYBze6Y+CgXM=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=VZ51iZLQa9EIOpgtB1aGcrZbwyppkjBPdmDZ4kWd4l6uHq8LWQb1ohdXj/SbQagQT 1wjHQHjWxNMSJ7J/nv6luHJ5BdQgw5olN0y15TDXEtpqblwxSs28YxBN3fG0zNnWUW omHwKFbEkt05QJPkCl2hg8lwPfmSz6eW52MdYK/E= Received: from scott-latitude-e6320.localnet (unknown [208.255.163.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6FF6920E4064; Wed, 1 Feb 2012 10:45:46 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 01 Feb 2012 10:45:45 -0500 Message-ID: <1357237.nPVXCpdn4W@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F28DBB7.5070101@qualcomm.com> References: <4F28DBB7.5070101@qualcomm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Feb 2012 15:45:48 -0000 On Wednesday, February 01, 2012 12:29:11 AM Pete Resnick wrote: > All, > > I have made some updates to the charter based on feedback during IESG > review. If I can sneak it onto the Thursday telechat this week, I might, > but the IESG might be none too pleased for me to put it on so late, so > it may wait two more weeks. We'll see. > > Please review the below and see if there is anything that makes your > head explode. Looks good to me. Let's get started. Scott K From dhc2@dcrocker.net Wed Feb 1 07:49:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E30B11E80C2 for ; Wed, 1 Feb 2012 07:49:05 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtJam5As+c5R for ; Wed, 1 Feb 2012 07:49:04 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E2FB911E80B2 for ; Wed, 1 Feb 2012 07:49:04 -0800 (PST) Received: from [10.0.0.26] (mail.pir.org [72.44.190.134]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q11FmvRj020055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Feb 2012 07:49:04 -0800 Message-ID: <4F295EE5.1000502@dcrocker.net> Date: Wed, 01 Feb 2012 10:48:53 -0500 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Pete Resnick References: <4F28DBB7.5070101@qualcomm.com> <4F292787.5040109@dcrocker.net> <4F295CA2.7030902@qualcomm.com> In-Reply-To: <4F295CA2.7030902@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 01 Feb 2012 07:49:04 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 15:49:05 -0000 On 2/1/2012 10:39 AM, Pete Resnick wrote: > My read of the line has always been that there is a burden on the proposer to > show that any particular enhancement already has implementation and that the > community has already (past tense) given the feature widespread support. I am > willing to leave to the judgment of the chairs (and myself) whether the WG has > clear consensus on the "widespread support" of such an enhancement should one > come forward. mumble(*) d/ (*) that's a synonym for 'grumble'. -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Wed Feb 1 08:29:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4180121F8C15 for ; Wed, 1 Feb 2012 08:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.476, 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 2Iy1tBieP2Gw for ; Wed, 1 Feb 2012 08:29:04 -0800 (PST) Received: from listserv.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0A02421F88E3 for ; Wed, 1 Feb 2012 08:29:03 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4967; t=1328113736; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=gUqAm3ALzEYRFCyVe45MxCmEIDQ=; b=TvEEDlBwc1KE+5qnjIMU wo/wRc1QB8JjNcnlfrlJJGq9Yq6/FI5ij9micdOY1tgCdCxV/FJJpuW1qeVxgNCI BCnSR4dBquOPCWIbqnK1+uqB8Oby6qVw0oZ4J+JSZecjgKSDIiK/zUYS7LzRy5To swnGqLjVZ8dkSU6YUlXvZmM= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 01 Feb 2012 11:28:56 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1315601955.62943.2496; Wed, 01 Feb 2012 11:28:56 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4967; t=1328113528; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=noPS4ND C39YD81MEAqZzFZkK/b3uXuVBzIRiyt2iMJ0=; b=F7DtxgdxCROyLTJGn9zO4np Va0xiS4fYvqcPs41ylphZxl3EDx/Rpnps61macleot8KIge1axBb+URRqE9DfBja VU11Y/7mNZPuOKbwLAVcpG0K1nIyNvIKSz7OzglIKCrzITsmT82n62Tc5j13LjT0 ryWxsd4/ALGUNhH2UAzA= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 01 Feb 2012 11:25:28 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1914551704.11315.7476; Wed, 01 Feb 2012 11:25:28 -0500 Message-ID: <4F29682D.305@isdg.net> Date: Wed, 01 Feb 2012 11:28:29 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4F28DBB7.5070101@qualcomm.com> In-Reply-To: <4F28DBB7.5070101@qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Feb 2012 16:29:05 -0000 +1, looks good to me. -- HLS Pete Resnick wrote: > All, > > I have made some updates to the charter based on feedback during IESG > review. If I can sneak it onto the Thursday telechat this week, I might, > but the IESG might be none too pleased for me to put it on so late, so > it may wait two more weeks. We'll see. > > Please review the below and see if there is anything that makes your > head explode. > > pr > > --- > > Working Group Name: > SPF Update (SPFBIS) > > IETF Area: > Applications Area > > Chair(s): > TBD > > Applications Area Director(s): > Pete Resnick > Peter Saint-Andre > > Applications Area Advisor: > Pete Resnick > > Mailing Lists: > General Discussion:spfbis@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/spfbis > Archive: http://www.ietf.org/mail-archive/web/spfbis/ > > Description of Working Group: > The Sender Policy Framework (SPF, RFC4408) specifies the publication > of a DNS record which states that a listed IP address is authorized > to send mail on behalf of the listing domain name's owner. SMTP > servers extract the domain name in the SMTP "MAIL FROM" or "HELO" > command for confirming this authorization. The protocol has had > Experimental status for some years and has become widely deployed. > This working group will summarize the result of the experiment and > revise the specification, based on deployment experience and listed > errata, and will seek Standards Track status for the protocol. > > The MARID working group considered two specifications for > publication of email-sending authorization: Sender-ID, which > eventually became RFC4405, RFC4406 and RFC4407, and SPF, which > eventually became RFC4408, all in the end published under > Experimental status. By using IP addresses, both protocols specify > authorization in terms of path, though unlike SPF, Sender-ID uses > domain names found in the header of the message rather than the > envelope. > > The two protocols rely on the same policy publication mechanism, > namely a specific TXT resource record in the DNS. This creates a > basic ambiguity about the interpretation of any specific instance of > the TXT record. Because of this, there were concerns about > conflicts between the two in concurrent operation. The IESG note > prepended to RFC 4405 through RFC 4408 defined an experiment with > SPF and Sender-ID, and invited an expression of community consensus > in the period following the publication of those specifications. > > Both technologies initially enjoyed widespread deployment. Since > that time, broad SPF use has continued, whereas use of Sender-ID has > slackened. Furthermore, SPF's linkage to the envelope (as opposed > to Sender-ID's linkage to identifiers in the message content) has > proven sufficient among operators. > > Formation of the SPF Update Working Group is predicated on three > assumptions: > > 1. The SPF/Sender-ID experiment has concluded. > > 2. SPF has been a qualified success, warranting further development. > > 3. Sender-ID has had less success, and no further development is > justified. > > The working group will produce a document describing the course of > the SPF/Sender-ID experiment, thus bringing that experiment to a > formal conclusion. The group will complete additional work on SPF > (described below), but will not complete additional work on the > Sender-ID specification. > > Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any enhancements > that have already gained widespread support, and addition of > clarifying language. > > Specifically out-of-scope for this working group: > > * Revisiting past technical arguments where consensus was reached in > the MARID working group, except where review is reasonably > warranted based on operational experience. > > * Discussion of the merits of SPF. > > * Discussion of the merits of Sender-ID in preference to SPF. > > * Extensions to the SPF protocols. > > * Removal of existing features that are in current use. > > Discussion of extensions to the SPF protocols or removal of > existing features shall only be discussed after completion of > current charter items in anticipation of rechartering the working > group. > > An initial draft of an updated SPF specification document is > draft-kitterman-4408bis. The working group may choose to use this > document as a basis for their specification. > > Goals and Milestones: > Aug 2012: A document describing the SPF/Sender-ID experiment > and its conclusions to the IESG for publication. > > Dec 2012: A standards track document defining SPF, > based on RFC4408 and as amended above, > to the IESG for publication. > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From SRS0=SmceD=AL==stuart@gathman.org Wed Feb 1 09:45:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A99411E814E for ; Wed, 1 Feb 2012 09:45:57 -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 D+egCAa1dS-D for ; Wed, 1 Feb 2012 09:45:57 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4AF11E811D for ; Wed, 1 Feb 2012 09:45:56 -0800 (PST) Received: from sdg.bmsi.com (sdg.bmsi.com [192.168.9.34] (may be forged)) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q11Hj888008183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Feb 2012 12:45:09 -0500 Message-ID: <4F297A50.1000708@gathman.org> Date: Wed, 01 Feb 2012 12:45:52 -0500 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F28DBB7.5070101@qualcomm.com> <4F292787.5040109@dcrocker.net> <18eefd51-d3d1-4db6-92bb-5ebf37cbe516@email.android.com> In-Reply-To: <18eefd51-d3d1-4db6-92bb-5ebf37cbe516@email.android.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Feb 2012 17:46:47 -0000 Long ago, Nostradamus foresaw that on 02/01/2012 07:08 AM, Scott Kitterman would write: > > What additions are being proposed and considered? > > This clause broadens the scope significantly. > FWIW, I'm not aware of anything that would currently meet that criteria and the only thing that might in the time frame we're discussing is the SPF failure feedback report going on in MARF. > > If this language lets us transition the SPF modifier registry into 4408bis, then it's probably useful. > Since 4408 already reserves unknown modifiers for extensions, there is no need to mention specific extensions, except perhaps to reference the IANA registry for such extensions. From dotis@mail-abuse.org Wed Feb 1 17:15:09 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E8911E80AB for ; Wed, 1 Feb 2012 17:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.312 X-Spam-Level: X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 IktZs2lb3w2I for ; Wed, 1 Feb 2012 17:15:08 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB5F11E8087 for ; Wed, 1 Feb 2012 17:15:08 -0800 (PST) Received: from US-DOUGO-MAC.local (SJDCLUXGATEWAY1.sdi.trendnet.org [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 6F48717402E4 for ; Thu, 2 Feb 2012 01:15:02 +0000 (UTC) Message-ID: <4F29E395.3020100@mail-abuse.org> Date: Wed, 01 Feb 2012 17:15:01 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F28DBB7.5070101@qualcomm.com> In-Reply-To: <4F28DBB7.5070101@qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Feb 2012 01:15:09 -0000 On 1/31/12 10:29 PM, Pete Resnick wrote: > All, > > I have made some updates to the charter based on feedback during IESG > review. If I can sneak it onto the Thursday telechat this week, I > might, but the IESG might be none too pleased for me to put it on so > late, so it may wait two more weeks. We'll see. > > Please review the below and see if there is anything that makes your > head explode. Dear Pete, At any inbound SMTP server, there may be attempts to resolve an extensive list of IPv4 and IPv6 addresses associated with SPF records whether referenced from insecure SMTP Mail From or HELO/EHLO parameters. SMTP services must cope with an extensive amount of unwanted traffic and will therefore have extensive provisioning. SMTP distributed attacks will be extremely difficult for any single SMTP recipient to detect. Nor will victims of an attack be aware of the triggering messages. Victims of this type of attack may not even exchange SMTP traffic. Most sources of unwanted SMTP traffic originate from insecure hosts. Resulting SPF related DNS transactions performed by receiving SMTP servers will obfuscate their source. In addition, Authentication-Results header fields, that may be added to forwarded messages, exclude source IP addresses. Even when victims of targeted attacks are known, proactive protection at either SMTP or DNS services can be thwarted by SPF’s macro capabilities. SPF’s macros makes it impractical to identify records or messages involved in an attack which may also lead to extensive traffic amplification. DDoS vulnerabilities may result from the distributed nature of SMTP messages and receipt of DNS traffic related to SPF validation which may consume all of a victim's available resources. Whether an attack leverages HELO/EHLO subdomains or more significantly an email-address local-part, the overall number of transactions involved can be extensive while demanding little of the sender’s resources. An SPF ‘mx’ or ‘ptr’ mechanism limit corresponds to a ten times greater number of DNS resource record resolutions. SPF deployment would be significantly safer where recipients employ reasonable limits for the permitted number of resulting DNS failures. Determining reasonable DNS error limits for SPF should be part of the WG charter. Potential victims of SPF amplifications will not represent those needing to change the SPF process. Regards, Douglas Otis From spf2@kitterman.com Wed Feb 1 17:54:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BA011E80F8 for ; Wed, 1 Feb 2012 17:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqPavMc1sQm9 for ; Wed, 1 Feb 2012 17:54:22 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id A839911E8087 for ; Wed, 1 Feb 2012 17:54:22 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 1E31BD0408B; Wed, 1 Feb 2012 19:54:22 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328147662; bh=lUJUPdv2kAuRqQQFl2B/jeVLLZK7j5cqRON/YJxRAg4=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=ARYpcTekxvsXOSq/R7QlFn7cJfY1BnplP01IzcV9+dfz17vqbCkBFIDPc2heb0wXu kWazUe+GD85jhRcy9JFelSkQmmKGJT6nyZKTDSWqTtwUgQfXhHI5hAZc/P5MeKfhtU 63MZZzoFYWPLilam5W7hVTjvzxlryHbE6kHe1tNE= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CE2D2D04025; Wed, 1 Feb 2012 19:54:21 -0600 (CST) References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> User-Agent: K-9 Mail for Android In-Reply-To: <4F29E395.3020100@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 01 Feb 2012 20:53:42 -0500 To: spfbis@ietf.org Message-ID: <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Feb 2012 01:54:23 -0000 Douglas Otis wrote: >On 1/31/12 10:29 PM, Pete Resnick wrote: >> All, >> >> I have made some updates to the charter based on feedback during IESG > >> review. If I can sneak it onto the Thursday telechat this week, I >> might, but the IESG might be none too pleased for me to put it on so >> late, so it may wait two more weeks. We'll see. >> >> Please review the below and see if there is anything that makes your >> head explode. >Dear Pete, > >At any inbound SMTP server, there may be attempts to resolve an >extensive list of IPv4 and IPv6 addresses associated with SPF records >whether referenced from insecure SMTP Mail From or HELO/EHLO >parameters. >SMTP services must cope with an extensive amount of unwanted traffic >and >will therefore have extensive provisioning. SMTP distributed attacks >will be extremely difficult for any single SMTP recipient to detect. >Nor >will victims of an attack be aware of the triggering messages. Victims >of this type of attack may not even exchange SMTP traffic. > >Most sources of unwanted SMTP traffic originate from insecure hosts. >Resulting SPF related DNS transactions performed by receiving SMTP >servers will obfuscate their source. In addition, >Authentication-Results >header fields, that may be added to forwarded messages, exclude source >IP addresses. Even when victims of targeted attacks are known, >proactive >protection at either SMTP or DNS services can be thwarted by SPF’s >macro >capabilities. SPF’s macros makes it impractical to identify records or >messages involved in an attack which may also lead to extensive traffic > >amplification. > >DDoS vulnerabilities may result from the distributed nature of SMTP >messages and receipt of DNS traffic related to SPF validation which may > >consume all of a victim's available resources. Whether an attack >leverages HELO/EHLO subdomains or more significantly an email-address >local-part, the overall number of transactions involved can be >extensive >while demanding little of the sender’s resources. An SPF ‘mx’ or ‘ptr’ >mechanism limit corresponds to a ten times greater number of DNS >resource record resolutions. SPF deployment would be significantly >safer >where recipients employ reasonable limits for the permitted number of >resulting DNS failures. > >Determining reasonable DNS error limits for SPF should be part of the >WG >charter. Potential victims of SPF amplifications will not represent >those needing to change the SPF process. The charter already covers this. If there are operational problems with the current design, it's in scope to address them. Scott K From dotis@mail-abuse.org Wed Feb 1 20:32:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B68911E80BF for ; Wed, 1 Feb 2012 20:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.325 X-Spam-Level: X-Spam-Status: No, score=-102.325 tagged_above=-999 required=5 tests=[AWL=0.274, 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 hgqmozJ5c3Hr for ; Wed, 1 Feb 2012 20:32:40 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 18DCE11E807F for ; Wed, 1 Feb 2012 20:32:40 -0800 (PST) Received: from US-DOUGO-MAC.local (SJDCLUXGATEWAY1.sdi.trendnet.org [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id EB3A6174010F for ; Thu, 2 Feb 2012 04:32:39 +0000 (UTC) Message-ID: <4F2A11E7.10409@mail-abuse.org> Date: Wed, 01 Feb 2012 20:32:39 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> In-Reply-To: <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Feb 2012 04:32:40 -0000 On 2/1/12 5:53 PM, Scott Kitterman wrote: > Douglas Otis wrote: > > On 1/31/12 10:29 PM, Pete Resnick wrote: > >> All, > >> > >> I have made some updates to the charter based on feedback during > >> IESG review. If I can sneak it onto the Thursday telechat this > >> week, I might, but the IESG might be none too pleased for me to > >> put it on so late, so it may wait two more weeks. We'll see. > >> > >> Please review the below and see if there is anything that makes > >> your head explode. > > Dear Pete, > > > > At any inbound SMTP server, there may be attempts to resolve an > > extensive list of IPv4 and IPv6 addresses associated with SPF > > records whether referenced from insecure SMTP Mail From or > > HELO/EHLO parameters. SMTP services must cope with an extensive > > amount of unwanted traffic and will therefore have extensive > > provisioning. SMTP distributed attacks will be extremely difficult > > for any single SMTP recipient to detect. Nor will victims of an > > attack be aware of the triggering messages. Victims of this type > > of attack may not even exchange SMTP traffic. > > > > Most sources of unwanted SMTP traffic originate from insecure > > hosts. Resulting SPF related DNS transactions performed by > > receiving SMTP servers will obfuscate their source. In addition, > > Authentication-Results header fields, that may be added to > > forwarded messages, exclude source IP addresses. Even when victims > > of targeted attacks are known, proactive protection at either SMTP > > or DNS services can be thwarted by SPF’s macro capabilities. SPF’s > > macros makes it impractical to identify records or messages > > involved in an attack which may also lead to extensive traffic > > amplification. > > > > DDoS vulnerabilities may result from the distributed nature of > > SMTP messages and receipt of DNS traffic related to SPF validation > > which may consume all of a victim's available resources. Whether an > > attack leverages HELO/EHLO subdomains or more significantly an > > email-address local-part, the overall number of transactions > > involved can be extensive while demanding little of the sender’s > > resources. An SPF ‘mx’ or ‘ptr’ mechanism limit corresponds to a > > ten times greater number of DNS resource record resolutions. SPF > > deployment would be significantly safer where recipients employ > > reasonable limits for the permitted number of resulting DNS > > failures. > > > > Determining reasonable DNS error limits for SPF should be part of > > the WG charter. Potential victims of SPF amplifications will not > > represent those needing to change the SPF process. > > The charter already covers this. If there are operational problems > with the current design, it's in scope to address them. Dear Scott, Perhaps express this as requirement to establish a realistic Security Consideration section. It seems unlikely email providers will notice their role in what might be devastating DDoS attacks impossible for victims to mitigate. Depending on email provider's perspectives of "operational problems" unfortunately overlooks these broader Internet concerns. Regards, Douglas Otis From spf2@kitterman.com Thu Feb 2 03:32:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBD921F8A57 for ; Thu, 2 Feb 2012 03:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 gqlXbKjbjs2S for ; Thu, 2 Feb 2012 03:32:53 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC8421F8A56 for ; Thu, 2 Feb 2012 03:32:53 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 8094FD0408B; Thu, 2 Feb 2012 05:32:52 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328182372; bh=v3ypuiT+iIOxmgOJAebWOVSUlbR1/maDvyXgMpijTYA=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=VMttew4KXmYuTomGDx5v79Ecqa+uO10k2feBfxpxKAGgzUaH0YYJ6FyC7Jr8gT4Ul GmCBWV6O1jBl7ysm+p6SLC5+V+Z0j020gUQ2LrQzLFLxxCP6XrQUiJX5VG5ueps8Wa j7gLU08SII3vt1EWO2AOah+91rEoSd3EB8oaM3Rg= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 49067D0400D; Thu, 2 Feb 2012 05:32:52 -0600 (CST) References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> <4F2A11E7.10409@mail-abuse.org> User-Agent: K-9 Mail for Android In-Reply-To: <4F2A11E7.10409@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 02 Feb 2012 06:33:01 -0500 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Feb 2012 11:32:54 -0000 Douglas Otis wrote: >On 2/1/12 5:53 PM, Scott Kitterman wrote: >> Douglas Otis wrote: >> > On 1/31/12 10:29 PM, Pete Resnick wrote: >> >> All, >> >> >> >> I have made some updates to the charter based on feedback during >> >> IESG review. If I can sneak it onto the Thursday telechat this >> >> week, I might, but the IESG might be none too pleased for me to >> >> put it on so late, so it may wait two more weeks. We'll see. >> >> >> >> Please review the below and see if there is anything that makes >> >> your head explode. >> > Dear Pete, >> > >> > At any inbound SMTP server, there may be attempts to resolve an >> > extensive list of IPv4 and IPv6 addresses associated with SPF >> > records whether referenced from insecure SMTP Mail From or >> > HELO/EHLO parameters. SMTP services must cope with an extensive >> > amount of unwanted traffic and will therefore have extensive >> > provisioning. SMTP distributed attacks will be extremely difficult >> > for any single SMTP recipient to detect. Nor will victims of an >> > attack be aware of the triggering messages. Victims of this type >> > of attack may not even exchange SMTP traffic. >> > >> > Most sources of unwanted SMTP traffic originate from insecure >> > hosts. Resulting SPF related DNS transactions performed by >> > receiving SMTP servers will obfuscate their source. In addition, >> > Authentication-Results header fields, that may be added to >> > forwarded messages, exclude source IP addresses. Even when victims >> > of targeted attacks are known, proactive protection at either SMTP >> > or DNS services can be thwarted by SPF’s macro capabilities. SPF’s >> > macros makes it impractical to identify records or messages >> > involved in an attack which may also lead to extensive traffic >> > amplification. >> > >> > DDoS vulnerabilities may result from the distributed nature of >> > SMTP messages and receipt of DNS traffic related to SPF validation >> > which may consume all of a victim's available resources. Whether an >> > attack leverages HELO/EHLO subdomains or more significantly an >> > email-address local-part, the overall number of transactions >> > involved can be extensive while demanding little of the sender’s >> > resources. An SPF ‘mx’ or ‘ptr’ mechanism limit corresponds to a >> > ten times greater number of DNS resource record resolutions. SPF >> > deployment would be significantly safer where recipients employ >> > reasonable limits for the permitted number of resulting DNS >> > failures. >> > >> > Determining reasonable DNS error limits for SPF should be part of >> > the WG charter. Potential victims of SPF amplifications will not >> > represent those needing to change the SPF process. >> >> The charter already covers this. If there are operational problems >> with the current design, it's in scope to address them. > >Dear Scott, > >Perhaps express this as requirement to establish a realistic Security >Consideration section. It seems unlikely email providers will notice >their role in what might be devastating DDoS attacks impossible for >victims to mitigate. Depending on email provider's perspectives of >"operational problems" unfortunately overlooks these broader Internet >concerns. Your wording assumes a problem. That's not appropriate. Either these attacks you claim are devastating someone exist and there will be evidence somewhere or they aren't a problem. Redesigning protocols for invisible attacks that no one can find is nonsense. The work of this group needs to be about engineering facts and not flights of fancy. Scott K From dhc2@dcrocker.net Thu Feb 2 04:00:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B6821F8A00 for ; Thu, 2 Feb 2012 04:00:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnPSjnHIhvJ4 for ; Thu, 2 Feb 2012 04:00:10 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1196521F89FF for ; Thu, 2 Feb 2012 04:00:10 -0800 (PST) Received: from [10.71.1.117] (static-70-108-248-155.res.east.verizon.net [70.108.248.155]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q12C01WZ009177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2012 04:00:09 -0800 Message-ID: <4F2A7ABD.5090201@dcrocker.net> Date: Thu, 02 Feb 2012 06:59:57 -0500 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Scott Kitterman References: <4F28DBB7.5070101@qualcomm.com> <4F292787.5040109@dcrocker.net> <18eefd51-d3d1-4db6-92bb-5ebf37cbe516@email.android.com> In-Reply-To: <18eefd51-d3d1-4db6-92bb-5ebf37cbe516@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]); Thu, 02 Feb 2012 04:00:09 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 12:00:10 -0000 On 2/1/2012 7:08 AM, Scott Kitterman wrote: > Dave CROCKER wrote: >> This clause broadens the scope significantly. > > FWIW, I'm not aware of anything that would currently meet that criteria and > the only thing that might in the time frame we're discussing is the SPF > failure feedback report going on in MARF. That's a useful observation, since it should help to bias the group against spending very much time considering "additions", absent extremely compelling deployment experience. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From barryleiba.mailing.lists@gmail.com Thu Feb 2 06:18:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE9E21F841E for ; Thu, 2 Feb 2012 06:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fawXFlpygMS for ; Thu, 2 Feb 2012 06:18:36 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0E721F84CE for ; Thu, 2 Feb 2012 06:18:36 -0800 (PST) Received: by yenm3 with SMTP id m3so1235163yen.31 for ; Thu, 02 Feb 2012 06:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=bjnjCzPmoBRhTiO0WvAi5tNRansi/ktNtFGaHfPC+F4=; b=Zvow8GQblae+XTAQ3s4aoygnI3ljVM2twzl6QsgCfyW6BXhVpFGQGhV80Ay1VNK+aA 1fICsyW66CCQeWNJ9tQL2i4v92biwruFQsbVUxbrJ9NSGtiA9gFBsVHJauZgWUsiiHl4 ustk7sV/AHK7kro1e+fY1bwmNzmuJCMygWVvo= MIME-Version: 1.0 Received: by 10.236.124.69 with SMTP id w45mr4427357yhh.57.1328192315968; Thu, 02 Feb 2012 06:18:35 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Thu, 2 Feb 2012 06:18:35 -0800 (PST) In-Reply-To: <4F2A11E7.10409@mail-abuse.org> References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> <4F2A11E7.10409@mail-abuse.org> Date: Thu, 2 Feb 2012 09:18:35 -0500 X-Google-Sender-Auth: ulgyfb5g4JT9SY6PWJyy1VXK0uw Message-ID: From: Barry Leiba To: spfbis@ietf.org Content-Type: multipart/alternative; boundary=20cf300e54152fce8a04b7fbdfdd Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Feb 2012 14:18:36 -0000 --20cf300e54152fce8a04b7fbdfdd Content-Type: text/plain; charset=ISO-8859-1 > Perhaps express this as requirement to establish a realistic Security Consideration section. Regardless of what we put in the charter, reviewing the security considerations and considering revising them appropriately is clearly an in-scope -- I might even say *required* -- activity. It will be up to the chairs to ensure that happens and to manage the discussion. It will be one responsibility of the participants to come to consensus on it, and to accept when the consensus is against them, and move on. Barry --20cf300e54152fce8a04b7fbdfdd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Perhaps express this as requirement to establish a realistic Security = Consideration section.

Regardless of what we put in the charter, rev= iewing the security considerations and considering revising them appropriat= ely is clearly an in-scope -- I might even say *required* -- activity. =A0I= t will be up to the chairs to ensure that happens and to manage the discuss= ion. =A0It will be one responsibility of the participants to come to consen= sus on it, and to accept when the consensus is against them, and move on.
Barry
--20cf300e54152fce8a04b7fbdfdd-- From ajs@anvilwalrusden.com Thu Feb 2 07:08:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAD921F8551 for ; Thu, 2 Feb 2012 07:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.053, 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 ZOr2MgS5lvnK for ; Thu, 2 Feb 2012 07:08:25 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7F84121F8547 for ; Thu, 2 Feb 2012 07:08:25 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7933C1ECB41C for ; Thu, 2 Feb 2012 15:08:23 +0000 (UTC) Date: Thu, 2 Feb 2012 10:08:20 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120202150820.GB388@crankycanuck.ca> References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> <4F2A11E7.10409@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F2A11E7.10409@mail-abuse.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Feb 2012 15:08:26 -0000 Hi Doug, On Wed, Feb 01, 2012 at 08:32:39PM -0800, Douglas Otis wrote: > Perhaps express this as requirement to establish a realistic > Security Consideration section. If we're going to do that, we ought to list all the other standard things that published WG documents are supposed to do, like reflect WG consensus, have correct boilerplate, have correct references -- indeed, the charter would end up having all the PROTO instructions, the instructions to genart and secdir, and so on. And, indeed, every charter ought to contain this. I think it's an unreasonable request. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From john@jlc.net Thu Feb 2 07:12:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989E721F8527 for ; Thu, 2 Feb 2012 07:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.302 X-Spam-Level: X-Spam-Status: No, score=-106.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3ex01qGFy4U for ; Thu, 2 Feb 2012 07:12:36 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id E827D21F851A for ; Thu, 2 Feb 2012 07:12:34 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3CC6333C27; Thu, 2 Feb 2012 10:12:34 -0500 (EST) Date: Thu, 2 Feb 2012 10:12:34 -0500 From: John Leslie To: spfbis@ietf.org Message-ID: <20120202151234.GD46701@verdi> References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> <4F2A11E7.10409@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Feb 2012 15:12:36 -0000 Barry Leiba wrote: > > Regardless of what we put in the charter, reviewing the security > considerations and considering revising them appropriately is clearly > an in-scope -- I might even say *required* -- activity. It will be > up to the chairs to ensure that happens and to manage the discussion. > It will be one responsibility of the participants to come to consensus > on it, and to accept when the consensus is against them, and move on. I was thinking of posting the same thing: there's no reason to put a Security Considerations item in the charter. FYI, this charter is on today's IESG agenda. Hopefully Pete will advise us of any action taken. (Barry will be trying on his brand-new-AD hat in about an hour. :^) -- John Leslie From barryleiba.mailing.lists@gmail.com Thu Feb 2 08:13:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9E021F85D2 for ; Thu, 2 Feb 2012 08:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.948 X-Spam-Level: X-Spam-Status: No, score=-102.948 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lgp57PKrpW2o for ; Thu, 2 Feb 2012 08:13:17 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAEA21F84F5 for ; Thu, 2 Feb 2012 08:13:17 -0800 (PST) Received: by yenm3 with SMTP id m3so1321165yen.31 for ; Thu, 02 Feb 2012 08:13:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QqUMjAcrMtWSx9setr1DObFjP2z2v8RQM+fv3bA9xLg=; b=v4ZaZXwLFU16NDlTT3dwtsdJqHqyAluWFye4+HnGijO//VEeXvwKjvSyJrjXnuF9ZQ QS5ihroMh5wwfQbVsgKrsb77VYZV0ULr6Qf+VAC5doG9dUpdW4DNNi88qMOBgzkid8IM NGHs8NqOreefoo3a06L3q1plC0pBtWIQ9LdTY= MIME-Version: 1.0 Received: by 10.236.124.69 with SMTP id w45mr5228512yhh.57.1328199197067; Thu, 02 Feb 2012 08:13:17 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Thu, 2 Feb 2012 08:13:16 -0800 (PST) In-Reply-To: <20120202151234.GD46701@verdi> References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> <4F2A11E7.10409@mail-abuse.org> <20120202151234.GD46701@verdi> Date: Thu, 2 Feb 2012 11:13:16 -0500 X-Google-Sender-Auth: rXTsRq0pOGipFJkKdtRdsG908co Message-ID: From: Barry Leiba To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Feb 2012 16:13:18 -0000 > =A0 (Barry will be trying on his brand-new-AD hat in about an hour. :^) It's still just a propeller-beanie right now. It becomes a proper hat in Paris (so I suppose it should be a beret). Barry From hsantos@isdg.net Thu Feb 2 09:55:34 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A4621F860B for ; Thu, 2 Feb 2012 09:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjJK5WwMvSbM for ; Thu, 2 Feb 2012 09:55:33 -0800 (PST) Received: from ftp.catinthebox.net (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 526DB21F8601 for ; Thu, 2 Feb 2012 09:55:33 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4111; t=1328205324; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=pMk8mGaggNzIMrZfG5+lHUvTcto=; b=k08ekBXpvIVjnwGt2IH3 M7pPXYo+Ke1416JWkqCyWXr+c3OQMtrFmLFzjA79WoMyiaU54OcI+d47T2xoLn7b +OeqEZRuMPCf+fp0F2lyZBIo8r84O3Z6RLGvKRjfPN/knBWQDv15ANDqP+WdSgZa q3dV9PTVXSsqEeiGh4hfEs8= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 02 Feb 2012 12:55:24 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1407187833.63904.788; Thu, 02 Feb 2012 12:55:22 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4111; t=1328205115; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2rLQBda /XisOe/5mp9WbWUJq2gVuBNnWNL3DvMLQl0U=; b=puPHO2/ZPYykH8ky8eZm9sG IKNf3HIpuQQOyvxQnhK5osn1qrICqpbx3Krh9JWL1bhghTM2SZXlAd9Wck08MDIH IGbVW3It9v2ZCgZnC3IovTUaQSuZAs60PDcPFxWJat6yiV/Gtg7hnpPfZ2Swhlv+ W7ZIXA4TSnrjrc8dGG9w= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 02 Feb 2012 12:51:55 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2006137408.11467.5284; Thu, 02 Feb 2012 12:51:54 -0500 Message-ID: <4F2ACE11.30202@isdg.net> Date: Thu, 02 Feb 2012 12:55:29 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> <4F2A11E7.10409@mail-abuse.org> In-Reply-To: <4F2A11E7.10409@mail-abuse.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Feb 2012 17:55:34 -0000 The problem is that from your POV there is only one solution - STOP USING SPF. In short, the ultimate conclusion when your security concerns is seriously considered, is to stop using SPF. That's not a solution - a non-starter. You keep talking about IPV6 and I don't know about others, thats still really very far for MOST people. I have yet to encounter one person that is only talking IPV6 and we can't deal with him. I can't even recall one company even inquiring about IPV6 support for any our internet servers. == HLS Douglas Otis wrote: > On 2/1/12 5:53 PM, Scott Kitterman wrote: >> Douglas Otis wrote: >> > On 1/31/12 10:29 PM, Pete Resnick wrote: >> >> All, >> >> >> >> I have made some updates to the charter based on feedback during >> >> IESG review. If I can sneak it onto the Thursday telechat this >> >> week, I might, but the IESG might be none too pleased for me to >> >> put it on so late, so it may wait two more weeks. We'll see. >> >> >> >> Please review the below and see if there is anything that makes >> >> your head explode. >> > Dear Pete, >> > >> > At any inbound SMTP server, there may be attempts to resolve an >> > extensive list of IPv4 and IPv6 addresses associated with SPF >> > records whether referenced from insecure SMTP Mail From or >> > HELO/EHLO parameters. SMTP services must cope with an extensive >> > amount of unwanted traffic and will therefore have extensive >> > provisioning. SMTP distributed attacks will be extremely difficult >> > for any single SMTP recipient to detect. Nor will victims of an >> > attack be aware of the triggering messages. Victims of this type >> > of attack may not even exchange SMTP traffic. >> > >> > Most sources of unwanted SMTP traffic originate from insecure >> > hosts. Resulting SPF related DNS transactions performed by >> > receiving SMTP servers will obfuscate their source. In addition, >> > Authentication-Results header fields, that may be added to >> > forwarded messages, exclude source IP addresses. Even when victims >> > of targeted attacks are known, proactive protection at either SMTP >> > or DNS services can be thwarted by SPF’s macro capabilities. SPF’s >> > macros makes it impractical to identify records or messages >> > involved in an attack which may also lead to extensive traffic >> > amplification. >> > >> > DDoS vulnerabilities may result from the distributed nature of >> > SMTP messages and receipt of DNS traffic related to SPF validation >> > which may consume all of a victim's available resources. Whether an >> > attack leverages HELO/EHLO subdomains or more significantly an >> > email-address local-part, the overall number of transactions >> > involved can be extensive while demanding little of the sender’s >> > resources. An SPF ‘mx’ or ‘ptr’ mechanism limit corresponds to a >> > ten times greater number of DNS resource record resolutions. SPF >> > deployment would be significantly safer where recipients employ >> > reasonable limits for the permitted number of resulting DNS >> > failures. >> > >> > Determining reasonable DNS error limits for SPF should be part of >> > the WG charter. Potential victims of SPF amplifications will not >> > represent those needing to change the SPF process. >> >> The charter already covers this. If there are operational problems >> with the current design, it's in scope to address them. > > Dear Scott, > > Perhaps express this as requirement to establish a realistic Security > Consideration section. It seems unlikely email providers will notice > their role in what might be devastating DDoS attacks impossible for > victims to mitigate. Depending on email provider's perspectives of > "operational problems" unfortunately overlooks these broader Internet > concerns. > > Regards, > Douglas Otis > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From dotis@mail-abuse.org Thu Feb 2 12:08:11 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3892E21F8635 for ; Thu, 2 Feb 2012 12:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 6cG+Lev-6vp1 for ; Thu, 2 Feb 2012 12:08:10 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB8221F85BB for ; Thu, 2 Feb 2012 12:08:10 -0800 (PST) Received: from US-DOUGO-MAC.local (SJDCLUXGATEWAY2.sdi.trendnet.org [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 95FD2174031A for ; Thu, 2 Feb 2012 20:08:09 +0000 (UTC) Message-ID: <4F2AED29.3010902@mail-abuse.org> Date: Thu, 02 Feb 2012 12:08:09 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> <4F2A11E7.10409@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Feb 2012 20:08:11 -0000 On 2/2/12 3:33 AM, Scott Kitterman wrote: Douglas Otis wrote: >> On 2/1/12 5:53 PM, Scott Kitterman wrote: >>> Douglas Otis wrote: >>>> On 1/31/12 10:29 PM, Pete Resnick wrote: >>>>> All, >>>>> >>>>> I have made some updates to the charter based on feedback during >>>>> IESG review. If I can sneak it onto the Thursday telechat this >>>>> week, I might, but the IESG might be none too pleased for me to >>>>> put it on so late, so it may wait two more weeks. We'll see. >>>>> >>>>> Please review the below and see if there is anything that makes >>>>> your head explode. >>>> Dear Pete, >>>> >>>> At any inbound SMTP server, there may be attempts to resolve an >>>> extensive list of IPv4 and IPv6 addresses associated with SPF >>>> records whether referenced from insecure SMTP Mail From or >>>> HELO/EHLO parameters. SMTP services must cope with an extensive >>>> amount of unwanted traffic and will therefore have extensive >>>> provisioning. SMTP distributed attacks will be extremely difficult >>>> for any single SMTP recipient to detect. Nor will victims of an >>>> attack be aware of the triggering messages. Victims of this type >>>> of attack may not even exchange SMTP traffic. >>>> >>>> Most sources of unwanted SMTP traffic originate from insecure >>>> hosts. Resulting SPF related DNS transactions performed by >>>> receiving SMTP servers will obfuscate their source. In addition, >>>> Authentication-Results header fields, that may be added to >>>> forwarded messages, exclude source IP addresses. Even when victims >>>> of targeted attacks are known, proactive protection at either SMTP >>>> or DNS services can be thwarted by SPF’s macro capabilities. SPF’s >>>> macros makes it impractical to identify records or messages >>>> involved in an attack which may also lead to extensive traffic >>>> amplification. >>>> >>>> DDoS vulnerabilities may result from the distributed nature of >>>> SMTP messages and receipt of DNS traffic related to SPF validation >>>> which may consume all of a victim's available resources. Whether an >>>> attack leverages HELO/EHLO subdomains or more significantly an >>>> email-address local-part, the overall number of transactions >>>> involved can be extensive while demanding little of the sender’s >>>> resources. An SPF ‘mx’ or ‘ptr’ mechanism limit corresponds to a >>>> ten times greater number of DNS resource record resolutions. SPF >>>> deployment would be significantly safer where recipients employ >>>> reasonable limits for the permitted number of resulting DNS >>>> failures. >>>> >>>> Determining reasonable DNS error limits for SPF should be part of >>>> the WG charter. Potential victims of SPF amplifications will not >>>> represent those needing to change the SPF process. >>> The charter already covers this. If there are operational problems >>> with the current design, it's in scope to address them. >> Dear Scott, >> >> Perhaps express this as requirement to establish a realistic Security >> Consideration section. It seems unlikely email providers will notice >> their role in what might be devastating DDoS attacks impossible for >> victims to mitigate. Depending on email provider's perspectives of >> "operational problems" unfortunately overlooks these broader Internet >> concerns. > Your wording assumes a problem. That's not appropriate. Either these attacks you claim are devastating someone exist and there will be evidence somewhere or they aren't a problem. Redesigning protocols for invisible attacks that no one can find is nonsense. > > The work of this group needs to be about engineering facts and not flights of fancy. Dear Scott, When dealing with security "whatever can happen will happen" could be termed "Murphy's law" and this provides a good basis for assessing security. Architectural flaws within Internet infrastructure become pernicious when those impacted are unable to take corrective action. Draft-otis-spf-dos-exploit-01 demonstrates the possible. Fortunately, a majority of large providers do not use SPF for message acceptance because they do not wish to deal with complaints arising from assumptions the SMTP Mail From parameter fully describes the path of a message in conjunction with SPF records ending in "-all". Including a limit in the SPF validation process for the number of name errors or no data errors permitted would make the SPF process significantly safer. IMHO, a large factor contributing to undesired SMTP traffic is the lack of domain authentication of outbound servers, which should be possible within a few transactions. Unfortunately, SPF recommends resolving SPF records for both HELO/EHLO and Mail From SMTP parameters obtained from otherwise unknown sources using as many as 200 DNS transactions that can be directed against non-existent resources! We have a large number of customers within the pacific region, and are currently seeing a greater amount of traffic against absolute IPv6 addresses than those against our own servers across a range of services. Email providers deciding to not accept IPv6 traffic will likely be receiving it through Large Scale NATs. At which point, no number of SPF transactions will be sufficient. SPF currently provides a useful utility in determining which reputation service has listed an IP address authorized by the domain, or to white-list their authorized addresses. Use of local-part macros would defeat the value of this utility and should be deprecated. Regards, Douglas Otis From hsantos@isdg.net Thu Feb 2 13:31:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1533421F85EF for ; Thu, 2 Feb 2012 13:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIfOFUoKVINp for ; Thu, 2 Feb 2012 13:31:35 -0800 (PST) Received: from ntbbs.santronics.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D71F821F85EE for ; Thu, 2 Feb 2012 13:31:34 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2079; t=1328218289; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=pQWSJV4YBTpx/XAm/K3TbvbSyik=; b=DjFf8gCMDi0+SR2bYZBL LeKAPPjDdAz9xO3e6wapqYXDaKfAyOkv/mef4/iD89t36psOHZrbOET4ww8fQHdc hnQQkNySoTpWyNVkTA287jwn/qUy0eoA4cUFfIYrSJVF66nMCVnmx4VnGh0EWR1d P3+skDGfjDGuOx9mbMZZRIg= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 02 Feb 2012 16:31:29 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1420152967.63904.3180; Thu, 02 Feb 2012 16:31:28 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2079; t=1328218081; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=tcrIU8O mU5z9oUGCB7KiwIZ08rcfOLL87nqIaxH91LM=; b=oA6PqRRtkUjbflYyd8bMfLV 5c64an6Xi3GDKwtlpUOKBeyxyt1LN6xLnfLtKqcnR+ArXhXoMfTwd1ahS9IBSY86 NA7Q33BZoFLBKjL0APt3GRZcMbGP2mmQ4cruAn2FzJqj8jRUnOfn8Xc/xSRTfcFt UD4KA1tU+4+xnesOFhTU= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 02 Feb 2012 16:28:01 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2019103626.11521.4576; Thu, 02 Feb 2012 16:28:00 -0500 Message-ID: <4F2B00B6.7030009@isdg.net> Date: Thu, 02 Feb 2012 16:31:34 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> <4F2A11E7.10409@mail-abuse.org> <4F2AED29.3010902@mail-abuse.org> In-Reply-To: <4F2AED29.3010902@mail-abuse.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Feb 2012 21:31:36 -0000 Douglas Otis wrote: > Fortunately, a > majority of large providers do not use SPF for message acceptance > because they do not wish to deal with complaints arising from > assumptions the SMTP Mail From parameter fully describes the path of a > message in conjunction with SPF records ending in "-all". Did you ever consider they were not candidates to use SPF? I always viewed SPF benefited private user domains, companies, of any size, institutions, etc, where there is less to no unknown variables in their networking. But I think that is all depends on your definition for "Large Providers." FaceBook.com and gmail.com can be viewed as "very large" Email Providers. Facebook.com, I presume has a very large pool of outbound senders and it has a well defined network with a -ALL final result. On the other hand, gmail.com with its ?ALL is a major overhead and resource "waster" - its completely useless for gmail.com to use UNKNOWN condition. Nothing good comes from it: MATCH - IP is on the GMAIL Network - Whoopie! NO MATCH - IP is not on the GMAIL NETWORK In both cases, abuse can and still occurs but with the latter, its where major abuse would be with bad guys using gmail.com with a wasteful record, and worse, it is always two lookups for what is most likely a wasteful yield. At least with Facebook.com, there is a measurable yield. Its protecting itself from any foreign abuse. Recently, I got a smile when I saw my old employer Mobil Oil (now as Exxon Mobil) corporate domain has a HARD FAIL SPF Record! Processes with hard failure detection mechanism is where the maximum benefit is found. A PASS or anything else still generally requires even more filter checks and even if you couple it with reputation or scoring, it is still not deterministic unlike a hard fail. Any system operation, large or small, that can not establish a well defined network was never really a candidate for SPF - I think we always knew that. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From dotis@mail-abuse.org Thu Feb 2 16:31:30 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF0321F869F for ; Thu, 2 Feb 2012 16:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.347 X-Spam-Level: X-Spam-Status: No, score=-102.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 XJV27L+8rl2T for ; Thu, 2 Feb 2012 16:31:29 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8F521F869D for ; Thu, 2 Feb 2012 16:31:29 -0800 (PST) Received: from US-DOUGO-MAC.local (SJDCLUXGATEWAY2.sdi.trendnet.org [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 0A973174019F for ; Fri, 3 Feb 2012 00:31:29 +0000 (UTC) Message-ID: <4F2B2AE0.7050905@mail-abuse.org> Date: Thu, 02 Feb 2012 16:31:28 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> <4F2A11E7.10409@mail-abuse.org> <4F2AED29.3010902@mail-abuse.org> <4F2B00B6.7030009@isdg.net> In-Reply-To: <4F2B00B6.7030009@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Feb 2012 00:31:30 -0000 On 2/2/12 1:31 PM, Hector Santos wrote: > Douglas Otis wrote: > > Fortunately, a majority of large providers do not use SPF for > > message acceptance because they do not wish to deal with complaints > > arising from assumptions the SMTP Mail From parameter fully > > describes the path of a message in conjunction with SPF records > > ending in "-all". > > Did you ever consider they were not candidates to use SPF? > > I always viewed SPF benefited private user domains, companies, of any > size, institutions, etc, where there is less to no unknown variables > in their networking. > > But I think that is all depends on your definition for "Large > Providers." FaceBook.com and gmail.com can be viewed as "very large" > Email Providers. Facebook.com, I presume has a very large pool of > outbound senders and it has a well defined network with a -ALL final > result. > > On the other hand, gmail.com with its ?ALL is a major overhead and > resource "waster" - its completely useless for gmail.com to use > UNKNOWN condition. Nothing good comes from it: > > MATCH - IP is on the GMAIL Network - Whoopie! NO MATCH - IP is not > on the GMAIL NETWORK > > In both cases, abuse can and still occurs but with the latter, its > where major abuse would be with bad guys using gmail.com with a > wasteful record, and worse, it is always two lookups for what is most > likely a wasteful yield. > > At least with Facebook.com, there is a measurable yield. Its > protecting itself from any foreign abuse. > > Recently, I got a smile when I saw my old employer Mobil Oil (now as > Exxon Mobil) corporate domain has a HARD FAIL SPF Record! > > Processes with hard failure detection mechanism is where the maximum > benefit is found. A PASS or anything else still generally requires > even more filter checks and even if you couple it with reputation or > scoring, it is still not deterministic unlike a hard fail. > > Any system operation, large or small, that can not establish a well > defined network was never really a candidate for SPF - I think we > always knew that. Dear Hector, Many providers of email services run on thin margins threatened by answering support calls caused by erroneous assumptions, such as whether an email alias is used to arrive at a recipient's mailbox. The Mail From parameter indicates where Delivery Status Notifications are to be sent, and nothing more can be assumed. At most, SPF Pass indicates the last hop was authorized, however authorization does not authenticate the originating domain. Refusing messages based upon SPF HARD FAIL is also likely to demand expensive exceptions for these refusals. Regards, Douglas Otis From dhc2@dcrocker.net Fri Feb 3 09:40:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A25521F8528 for ; Fri, 3 Feb 2012 09:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.193 X-Spam-Level: X-Spam-Status: No, score=-3.193 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DATE_IN_PAST_12_24=0.992, 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 ArU+G-Kemh+f for ; Fri, 3 Feb 2012 09:40:26 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D3F9921F8526 for ; Fri, 3 Feb 2012 09:40:26 -0800 (PST) Received: from [10.22.16.112] ([68.65.169.138]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q13HeGtI023971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Feb 2012 09:40:21 -0800 Message-ID: <4F2ACD02.40700@dcrocker.net> Date: Thu, 02 Feb 2012 12:50:58 -0500 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Barry Leiba References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> <4F2A11E7.10409@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 03 Feb 2012 09:40:22 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 17:40:27 -0000 On 2/2/2012 9:18 AM, Barry Leiba wrote: > > Perhaps express this as requirement to establish a realistic Security > Consideration section. > > Regardless of what we put in the charter, reviewing the security considerations > and considering revising them appropriately is clearly an in-scope -- I might > even say *required* -- activity. Still, it might be worth adding the suggested extra text to the charter. Personally, I was planning on trying to establish an UNrealistic Security Considerations section, but would not pursue it if the charter prohibited it... Perhaps the charter should also contain a proscription against meaningless charter content? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Fri Feb 3 10:15:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF62C21F8597 for ; Fri, 3 Feb 2012 10:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 wPNoj9KP+ZCA for ; Fri, 3 Feb 2012 10:15:46 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 90B9F21F8595 for ; Fri, 3 Feb 2012 10:15:46 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Feb 2012 10:15:46 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 3 Feb 2012 10:15:45 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Fri, 3 Feb 2012 10:15:44 -0800 Thread-Topic: [spfbis] Updated charter - final review Thread-Index: Aczimu1e4+21xnSoSS2QTfcd6SnfCQABN/+Q Message-ID: References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> <4F2A11E7.10409@mail-abuse.org> <4F2ACD02.40700@dcrocker.net> In-Reply-To: <4F2ACD02.40700@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Feb 2012 18:15:47 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dave CROCKER > Sent: Thursday, February 02, 2012 9:51 AM > To: Barry Leiba > Cc: spfbis@ietf.org > Subject: Re: [spfbis] Updated charter - final review >=20 > Perhaps the charter should also contain a proscription against > meaningless charter content? We need a BCP for that. From presnick@qualcomm.com Fri Feb 3 11:08:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC0021F85C3 for ; Fri, 3 Feb 2012 11:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.827 X-Spam-Level: X-Spam-Status: No, score=-105.827 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+aQ3noH84AX for ; Fri, 3 Feb 2012 11:08:41 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 8E46621F85B6 for ; Fri, 3 Feb 2012 11:08:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1328296121; x=1359832121; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F2C30B4.8020200@qualcomm.com>|Date:=20Fr i,=203=20Feb=202012=2013:08:36=20-0600|From:=20Pete=20Res nick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20"spfbis@ietf.org"=20|Subject:=20Chartered|Content-Type:=20text/plain =3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.39.5]; bh=IVE0ASHiesiRkF/MrKk7lWHhbriBX1YT9fxKrg3NBsc=; b=XFFQes2aVQGbqq+8tK86GkJctQT9QhDAXM1c9hMALFUNEJGxTUC18u66 ey39IFYJu148ffa+Cwx+BhdLcb2sr9JzH4jwijQP7jXfO5wuaZAa5EM7t zl/ZY46GrYjtQy3geXB7+7esPVd+7bgutDeUHKs3oCTQmdI2gZN6CO/4l 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6609"; a="160385372" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 03 Feb 2012 11:08:39 -0800 X-IronPort-AV: E=Sophos;i="4.73,352,1325491200"; d="scan'208";a="157299939" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 03 Feb 2012 11:08:39 -0800 Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 3 Feb 2012 11:08:38 -0800 Message-ID: <4F2C30B4.8020200@qualcomm.com> Date: Fri, 3 Feb 2012 13:08:36 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "spfbis@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Subject: [spfbis] Chartered X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Feb 2012 19:08:47 -0000 Folks, The spfbis group charter was approved yesterday by the IESG. You should see the announcement soon. The charter as you saw it is what we went with. A couple of notes from your AD: I've assigned Andrew Sullivan and Subramanian Moonesamy (aka SM) as your intrepid chairs. Andrew has been chairing DNSEXT for quite some time, and SM has chaired YAM, is the fearless leader of the Apps Area Directorate (nee Review Team), and is WG secretary for HYBI, so I think both are well suited to keeping everybody inside the lines of an extremely tightly scoped charter. Please welcome them, and let's get some good work done together by staying focused on the work at hand. We all understand that there is some history of contentiousness in this area, so remaining professional and calm will be very helpful. If there are problems, don't yell about them on the list; take them to the chairs or, exceptionally, to me. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From dhc2@dcrocker.net Fri Feb 3 11:21:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19F421F8505 for ; Fri, 3 Feb 2012 11:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[AWL=1.703, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKtQVWcHCz+e for ; Fri, 3 Feb 2012 11:21:51 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id AB92521F851E for ; Fri, 3 Feb 2012 11:21:50 -0800 (PST) Received: from [10.22.16.112] ([68.65.169.138]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q13JLh5t027181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Feb 2012 11:21:49 -0800 Message-ID: <4F2C33C1.50807@dcrocker.net> Date: Fri, 03 Feb 2012 11:21:37 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> <4F2A11E7.10409@mail-abuse.org> <4F2ACD02.40700@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 03 Feb 2012 11:21:49 -0800 (PST) Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 19:21:51 -0000 On 2/3/2012 10:15 AM, Murray S. Kucherawy wrote: >> Perhaps the charter should also contain a proscription against >> meaningless charter content? > > We need a BCP for that. Perhaps an analysis of the ecological impact of additions to charters and specification of material that is redundant, obvious or otherwise useless? Extra words mean extra paper. They also reduce the information salience of the document. That is, it makes it harder to find the parts that /are/ imporant. No doubt there are other implications. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs@anvilwalrusden.com Fri Feb 3 13:07:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8ADD21F8526 for ; Fri, 3 Feb 2012 13:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[AWL=-1.343, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hs9EA-Z8oPiG for ; Fri, 3 Feb 2012 13:07:05 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B80BC21F855A for ; Fri, 3 Feb 2012 13:07:04 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7FB501ECB41C for ; Fri, 3 Feb 2012 21:07:03 +0000 (UTC) Date: Fri, 3 Feb 2012 16:07:05 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120203210705.GN4322@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] WG management X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Feb 2012 21:07:06 -0000 Dear colleagues, Our AD (Pete), SM and I had a chat about ensuring that this Working Group stays focussed and on-charter. I'm summarizing for the list. I'm sure they'll correct me if I fail to make anything clear. This WG has, to its great advantage, a tightly-scoped charter and clear tasks. I know that we, all of us, are keen to bring the work to a speedy and satisfactory conclusion. At the same time, we are all aware that we are discussing a contentious topic, that there were some very strong passions about the topic in the past, and that there remain both strong arguments and strong feelings about topic. The IETF has open processes and an open culture. Moreover, decisions are supposed to be taken (or at least explicitly ratified) on the mailing list. This all means that anyone can participate just by joining the list; they often do, and otherwise have little interaction with the IETF or the people who participate in it frequently. That brings the great benefit of ensuring that every relevant perspective and talent may be brought to bear on a hard problem. It also brings a cost, because participants must discipline themselves to be measured in what they say, to be even-handed and fair, and not to drift off-topic. Sometimes people don't do one (or all) of these things, and behaviour on the list (or even in a face to face meeting) becomes boorish or hostile. There is, of course, more than one way to exhibit that behaviour, but whether it is outright maliciousness or snide condescension, it is not acceptable in this WG. As Chris Lewis said on another list recently, "Anyone can have a bad day and fail in one way or the other." I'd hate to count how many times I have had such a day. But as Chris equally noted, consistent patterns of bad behaviour are not to be tolerated from any WG participant. SM and I are determined to ensure that this WG conduct itself in a civilized, though no less rigorous, way. We intend to use the available issue tracker as much as possible in order to keep discussion on a given issue as tightly focussed as possible. We encourage participants to govern themselves as much as possible, and particularly suggest that if you feel strongly when composing a mail you might want to wait a few minutes and re-read your remarks before sending them. Put yourself in the other person's shoes, and try to understand another's point of view before dismissing it rudely. Remember, also, that your interlocutor might not be a long-time participant in the IETF and might not recognize that you're merely having a bad day; or equally that your interlocutor might not be familiar with something you know, and that it therefore is your responsibility to present your evidence clearly, concisely, completely, and once. Finally, it's important to remember that sometimes others just disagree with you; "rough consensus" means that your views might be rejected by everyone else, and in that case you need to accede gracefully. This is all just a reminder of things we all already know. At the same time, SM and I draw to your attention RFC 2418 (particularly section 3.3) and RFC 3834 (particularly section 2). We'd hate to be in the position of having to exercise any of the more draconian procedures, and we thank you in advance for not causing that to happen. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From dotis@mail-abuse.org Fri Feb 3 13:27:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2685E21F84B3 for ; Fri, 3 Feb 2012 13:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 l7L0J70CfBQX for ; Fri, 3 Feb 2012 13:27:43 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id ACC2E21F84AE for ; Fri, 3 Feb 2012 13:27:43 -0800 (PST) Received: from US-DOUGO-MAC.local (SJDCLUXGATEWAY1.sdi.trendnet.org [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id DA53C17400A8 for ; Fri, 3 Feb 2012 21:27:42 +0000 (UTC) Message-ID: <4F2C514E.4010902@mail-abuse.org> Date: Fri, 03 Feb 2012 13:27:42 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com> <4F2A11E7.10409@mail-abuse.org> <4F2ACD02.40700@dcrocker.net> In-Reply-To: <4F2ACD02.40700@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Feb 2012 21:27:44 -0000 On 2/2/12 9:50 AM, Dave CROCKER wrote: > On 2/2/2012 9:18 AM, Barry Leiba wrote: > >> Perhaps express this as requirement to establish a realistic > >> Security Consideration section. > > > > Regardless of what we put in the charter, reviewing the security > > considerations and considering revising them appropriately is > > clearly an in-scope -- I might even say *required* -- activity. > > > Still, it might be worth adding the suggested extra text to the > charter. Personally, I was planning on trying to establish an > UNrealistic Security Considerations section, but would not pursue it > if the charter prohibited it... > > Perhaps the charter should also contain a proscription against > meaningless charter content? Dear Dave, No one denies email confronts significant levels of abuse, however other services respond by establishing safe and efficient cryptographic authentications compliant with Today's Internet. SPF path authorizations employ recipient resources processing macros defined in a draft that never reached consensus within an IETF Marid WG prior to closure. Initial drafts proposed XML encoded 2KB resource records without limit, modified to tag/value text with 20 deep recursion limits, and modified again to limits of 10 macro mechanisms with each allowing 10 subsequent DNS transactions just prior to the closure. Although some progress being made, the closure seemed related to a lack of consensus about whether SMTP Mail From parameter rewriting or PRA algorithm would facilitate unauthorized path refusal. The concern expressed was to ensure the WG charter was not seen as endorsing the current scheme that allows 200 directed DNS transactions reflected against non-existent resources. Comments about the charter were to highlight potential concerns admittedly unlikely to directly impact SMTP, but were about the granting of unknown entities poorly constrained access to recipient resources. A WG outcome based upon realistic assessment of SPF's current utility and related risks is welcome. Introducing limits on the number of DNS Name or No Data errors will not impact how SPF might be used, only how it might be abused. Regards, Douglas Otis From ajs@anvilwalrusden.com Fri Feb 3 13:30:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B8721F8603 for ; Fri, 3 Feb 2012 13:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtlFErcS01PV for ; Fri, 3 Feb 2012 13:30:51 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 71F5321F8601 for ; Fri, 3 Feb 2012 13:30:51 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A4A0C1ECB41C for ; Fri, 3 Feb 2012 21:30:50 +0000 (UTC) Date: Fri, 3 Feb 2012 16:30:52 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120203213052.GP4322@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Request for reviews of 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: Fri, 03 Feb 2012 21:30:52 -0000 Dear colleagues, Because we are the SPFBIS Working Group, SM and I believe that our first order of business is to collect the issues with RFC 4408. We believe we have a way to collect them. (Credit where it's due: this was SM's idea. I just think it's a great one and wholeheartedly support it. He's on vacation, so I'm posting the mail.) We request that WG participants each perform a review of RFC 4408. This review may be of the document alone, or if you like also with reference to experience with it. Please post your review to the mailing list. We ask that nobody debate the merits of anyone's review, and indeed that nobody respond in any way to anyone else's review. Just review the document without reference to the rest of the WG. This is important as a procedural matter: discussions of the various reviews is out of bounds. Please don't give into the temptation. SM and I will collect the reviews, and pull out every issue we see. We will then create one issue ticket in the tracker, once it is available, for every issue we identify. At this point, of course, debate will be necessary because it's entirely likely that SM and I will miss something or get our categorization wrong. But this approach will ensure that we are always talking about specific issues when we have that debate, and that we'll all be working from the collected reviews that have been posted. We'd like to set a deadline for the reviews of two weeks; so we will close the queue for reviews at 00:00 on 18 February. We understand that, with the WG just having been chartered, that may be too optimistic. If this is too soon for you, please let SM and me know, and we'll adjust the deadline. We'd like to use the results of this, however, as the basis for further work and for a meeting session in Paris, so we request that you try not to let it linger too long. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From dhc2@dcrocker.net Fri Feb 3 13:37:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7232921F8552 for ; Fri, 3 Feb 2012 13:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.748 X-Spam-Level: X-Spam-Status: No, score=-5.748 tagged_above=-999 required=5 tests=[AWL=0.852, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5LDbLTzIU64 for ; Fri, 3 Feb 2012 13:37:19 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4F421F8512 for ; Fri, 3 Feb 2012 13:37:19 -0800 (PST) Received: from [10.22.17.178] ([68.65.169.231]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q13LbCmG029476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Feb 2012 13:37:18 -0800 Message-ID: <4F2C5381.7010403@dcrocker.net> Date: Fri, 03 Feb 2012 13:37:05 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120203210705.GN4322@mail.yitter.info> In-Reply-To: <20120203210705.GN4322@mail.yitter.info> 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, 03 Feb 2012 13:37:18 -0800 (PST) Subject: Re: [spfbis] WG management X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 21:37:20 -0000 On 2/3/2012 1:07 PM, Andrew Sullivan wrote: > As Chris Lewis said on another list recently, "Anyone can have a bad > day and fail in one way or the other." I'd hate to count how many Andrew, Welcome and good luck. Glad to see the substance of your message. Chris' postings was a formal notification to the Repute working grooup. I put it up on the wiki for that working group: It might be worth considering development of standard language for working groups to use. (The draft we wrote for Repute had that goal, but I've no doubt it needs modification.) We have a "Note Well" system with respect to policies, procedures and notification of IPR issues. We probably ought to develop the same thing for participation rules. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs@anvilwalrusden.com Fri Feb 3 13:51:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A381F0C3C for ; Fri, 3 Feb 2012 13:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 3lLLSgmMrLYW for ; Fri, 3 Feb 2012 13:51:57 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id CC0C11F0C36 for ; Fri, 3 Feb 2012 13:51:57 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 135C71ECB41C for ; Fri, 3 Feb 2012 21:51:57 +0000 (UTC) Date: Fri, 3 Feb 2012 16:51:59 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120203215158.GQ4322@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Feb 2012 21:51:58 -0000 Dear colleagues, One of our tasks as a WG is to bring to an end the experiment started by RFC 4408 and other documents published at the same time. To that end, your chairs would like evidence about the results of the experiment. Note that we are asking specifically for evidence; evidence of effectiveness and, particularly, evidence in respect of relative effectiveness between SPF and Sender-ID would be extremely helpful. This would all be evidence gleaned from operational experience with one or more of the published RFCs. This is _not_ a request for an analysis of that evidence, or any sort of meta-commentary on it. It is especially not a request for any analysis of the differences nor any architecural commentary on how one or the other would work under this or that condition. It's just straight actual from-the-field evidence: this is an empirical experiment, and therefore we want empirical data. Please post anything you have to the list. We ask that participants not discuss the different observations that are posted; if you have different evidence to offer, please just post it without regard to others' postings. Thank you. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Fri Feb 3 13:58:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6A81F0C42 for ; Fri, 3 Feb 2012 13:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 hCACozuqqnvg for ; Fri, 3 Feb 2012 13:58:46 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id D44A21F0C43 for ; Fri, 3 Feb 2012 13:58:45 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 30ACF1ECB41C; Fri, 3 Feb 2012 21:58:45 +0000 (UTC) Date: Fri, 3 Feb 2012 16:58:47 -0500 From: Andrew Sullivan To: dcrocker@bbiw.net Message-ID: <20120203215847.GS4322@mail.yitter.info> References: <20120203210705.GN4322@mail.yitter.info> <4F2C5381.7010403@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F2C5381.7010403@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: spfbis@ietf.org Subject: Re: [spfbis] WG management X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Feb 2012 21:58:47 -0000 Hi Dave, On Fri, Feb 03, 2012 at 01:37:05PM -0800, Dave CROCKER wrote: > > > It might be worth considering development of standard language for > working groups to use. It might be, yes, and I think it would be an excellent idea to pursue. I'm not sure what list to use for it, although I am sure that it's not this one :-) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Fri Feb 3 14:06:33 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0990D1F0C42 for ; Fri, 3 Feb 2012 14:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 bk879Ro3rqCh for ; Fri, 3 Feb 2012 14:06:32 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 82BC11F0C3F for ; Fri, 3 Feb 2012 14:06:32 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CBBBD1ECB420 for ; Fri, 3 Feb 2012 22:06:31 +0000 (UTC) Date: Fri, 3 Feb 2012 17:06:33 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120203220633.GU4322@mail.yitter.info> References: <20120203213052.GP4322@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120203213052.GP4322@mail.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Request for reviews of 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: Fri, 03 Feb 2012 22:06:33 -0000 Dear colleagues, On Fri, Feb 03, 2012 at 04:30:52PM -0500, Andrew Sullivan wrote: > We request that WG participants each perform a review of RFC 4408. I should have been clear: I didn't mean to exclude the errata from this review. Please take it into consideration (and thanks to Scott Kitterman for reminding me to be clear about it). Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Fri Feb 3 14:27:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAED21F8510 for ; Fri, 3 Feb 2012 14:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFi1A20LEUsr for ; Fri, 3 Feb 2012 14:27:21 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 08F3221F850F for ; Fri, 3 Feb 2012 14:27:20 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7AF1E20E40D0; Fri, 3 Feb 2012 17:27:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328308040; bh=Kx5mfsNZRYxQruuA2uG5toN5NrGTCz2/hfIUhLHlalg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=T9n8u8M27I0TY6nleKArslAk7kZXSLT4a9hvjlZBS7AMknmAg2aPWrBilHp/WyS53 WkbvfaUMppOw9kxNjGizHTgLqz/USX8Sp5Q9C+zSqzPHL6xTWFHj4/f4wb2Iprc35R SCL8NWEQeJLqBbr7REQ327TL0tPbLkW40fBByIEM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5E4BF20E4043; Fri, 3 Feb 2012 17:27:20 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 03 Feb 2012 17:27:19 -0500 Message-ID: <40255162.ysvdAIjBC2@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120203215158.GQ4322@mail.yitter.info> References: <20120203215158.GQ4322@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Feb 2012 22:27:21 -0000 On Friday, February 03, 2012 04:51:59 PM Andrew Sullivan wrote: > Dear colleagues, > > One of our tasks as a WG is to bring to an end the experiment started > by RFC 4408 and other documents published at the same time. It was never clear to me what the experiment was supposed to be, so I've no idea what evidence would be appropriate. Ultimately, I think Sender ID has been replaced by DKIM and that SPF and DKIM are complementary technolgies, so I'm not sure how to reply. Can we get away with: The SPF/Sender ID experiment was overtaken by the development of DK/DKIM and so Sender ID is obsoleted by those other technologies? Scott K From spf2@kitterman.com Fri Feb 3 14:47:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1139A21F8620 for ; Fri, 3 Feb 2012 14:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 E+EwnecsSW6i for ; Fri, 3 Feb 2012 14:47:01 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 48D5821F861F for ; Fri, 3 Feb 2012 14:47:01 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C529A20E40D0; Fri, 3 Feb 2012 17:47:00 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328309220; bh=16wtXmp1V2EyY08jui3UKlNPL5xwhQFxY/lWqrG3dxo=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=GK4KVvQF2K/iWaQwGdAZpayKMwDTYanZ+nWPdcte6eugHUI+k/P3S4gB0spszCCGI KanD5ngJB0tM5tcux6f5TlT/AaSUvu8Mnbd2IMZ9V+eVF3T2Fsi9VA1njNqk3ODSOE hdkAX7xV8UrMw2Q8zYSMHQ7E5WrdJHE2HUr3azhU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A6EF020E4043; Fri, 3 Feb 2012 17:47:00 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 03 Feb 2012 17:47 -0500 Message-ID: <7863221.PHTaGIf0LX@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Issue: "Permanent" Temporary errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Feb 2012 22:47:02 -0000 TempError is defined in RFC 4408 as: 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 DSN code. This is further specified in the check_host() definition: 4.4. Record Lookup In accordance with how the records are published (see Section 3.1 above), a DNS query needs to be made for the name, querying for either RR type TXT, SPF, or both. If both SPF and TXT RRs are looked up, the queries MAY be done in parallel. If all DNS lookups that are made return a server failure (RCODE 2), or other error (RCODE other than 0 or 3), or time out, then check_host() exits immediately with the result "TempError". Particularly when querying for SPF records of type SPF, persistent 2 ServFail results are not rare. It is my impression that ServFail is a condition that generally will require operator intervention to correct. The definition of PermError is (partly): 2.5.7. PermError A "PermError" result means that the domain's published records could not be correctly interpreted. This signals an error condition that requires manual intervention to be resolved, as opposed to the TempError result. I think that RCODE 2 replies should be considered PermError instead of TempError. The operational impact of this is that messages are deferred (4xx) instead of rejected (5xx) so they sit in a deferral queue and are retried for however long the sending MTA is configured to attempt it. The user of the message isn't notified of the non-delivery until it expires out of the queue, generally after several days. In the SPF policy server for Postfix that I maintain, I changed the default action on TempError from defer as a result of this issue. Scott K From WebMaster@Commerco.Net Fri Feb 3 14:54:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1341E11E8088 for ; Fri, 3 Feb 2012 14:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZN3jxjPJTuC for ; Fri, 3 Feb 2012 14:54:44 -0800 (PST) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 691AE21F8620 for ; Fri, 3 Feb 2012 14:54:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=tWHbDK/O7sNfhV8c4+wi5K04B+B/DElZeFVO08EI2OYUnJ4LdUj2lwBQuh3QQDL9Sgy9Ko+bWbSJH5DvyAYUVzs9/OiBY1FqFFKcqMwyTSM0TknzfH7dagFZoem2UjcMvQJOKKs3pGIT2/LioiBgSMgnFeT+imew2TFEScsZ8hQ= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Fri, 03 Feb 2012 22:54:41 +0000 Message-ID: <4F2C65AC.7010105@Commerco.Net> Date: Fri, 03 Feb 2012 15:54:36 -0700 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> In-Reply-To: <40255162.ysvdAIjBC2@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 Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Feb 2012 22:54:45 -0000 On 2/3/2012 3:27 PM, Scott Kitterman wrote: > On Friday, February 03, 2012 04:51:59 PM Andrew Sullivan wrote: >> Dear colleagues, >> >> One of our tasks as a WG is to bring to an end the experiment started >> by RFC 4408 and other documents published at the same time. > > It was never clear to me what the experiment was supposed to be, so I've no > idea what evidence would be appropriate. Ultimately, I think Sender ID has > been replaced by DKIM and that SPF and DKIM are complementary technolgies, so > I'm not sure how to reply. > > Can we get away with: > > The SPF/Sender ID experiment was overtaken by the development of DK/DKIM and > so Sender ID is obsoleted by those other technologies? > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > +1 I would also add that I see the overall experiment process as being defined by its purpose, its ability to meet its purpose and finally its success in adoption by the Internet community. In the case of purpose, perhaps simply domain name reputation protection through a process which defines simply how domain name holders can explicitly declare from what MTAs that email represented as being sent from their domain may be sent. In the case of meeting its purpose, does SPF adequately address its purpose? In most cases, yes. In our own experience, absolutely yes. Finally, adoption by the community. Arguably, SPF is one of the more widely adopted facilities for achieving its stated purpose. Arguably, the SPF experiment has gone well for its implementers. I also agree with Scott's assertion that SPF and DKIM are complementary technologies. Alan M From dhc2@dcrocker.net Fri Feb 3 14:58:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E34211E809B for ; Fri, 3 Feb 2012 14:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.031 X-Spam-Level: X-Spam-Status: No, score=-6.031 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMEMx0m1THB6 for ; Fri, 3 Feb 2012 14:58:25 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D60EB11E809A for ; Fri, 3 Feb 2012 14:58:25 -0800 (PST) Received: from [10.22.16.112] ([68.65.169.138]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q13MwI4o030776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Feb 2012 14:58:25 -0800 Message-ID: <4F2C6684.9030408@dcrocker.net> Date: Fri, 03 Feb 2012 14:58:12 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Scott Kitterman References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> In-Reply-To: <40255162.ysvdAIjBC2@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, 03 Feb 2012 14:58:25 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 22:58:26 -0000 On 2/3/2012 2:27 PM, Scott Kitterman wrote: > On Friday, February 03, 2012 04:51:59 PM Andrew Sullivan wrote: >> Dear colleagues, >> >> One of our tasks as a WG is to bring to an end the experiment started >> by RFC 4408 and other documents published at the same time. > > It was never clear to me what the experiment was supposed to be, so I've no > idea what evidence would be appropriate. Ultimately, I think Sender ID has > been replaced by DKIM and that SPF and DKIM are complementary technolgies, so > I'm not sure how to reply. > > Can we get away with: > > The SPF/Sender ID experiment was overtaken by the development of DK/DKIM and > so Sender ID is obsoleted by those other technologies? The simplest form of experimental question could be: 1. Has the world essentially dropped one of these (or both). Clearly spf is still heavily used, so this translates into whether there remains significant support for Sender-ID. I believe the answer is no, but I don't any empirical basis for this. A more elaborate question could be: 2. Are there features from one that gained support and would be worth merging into the other? Given my own answer to #1, above, that translates into "Are there parts of Sender-ID worth salvaging?" Given the narrow scope, it is likely that any items deems reasonable to merge into SPF will have to wait for a later SPFbisbis effort, but it could be worth documenting. Of general interest would be: 3. Document the deployment experiences of using SPF and/or Sender-ID. This would be a plusses and minuses history. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs@anvilwalrusden.com Fri Feb 3 15:56:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5336321F8534 for ; Fri, 3 Feb 2012 15:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 LYZyspoOndok for ; Fri, 3 Feb 2012 15:56:16 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id D56C821F851A for ; Fri, 3 Feb 2012 15:56:16 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 219A31ECB41C for ; Fri, 3 Feb 2012 23:56:16 +0000 (UTC) Date: Fri, 3 Feb 2012 18:56:18 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120203235617.GA4322@crankycanuck.ca> References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40255162.ysvdAIjBC2@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] "The question is wrong" thread (was: Request for experimental evidence) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Feb 2012 23:56:17 -0000 Dear colleagues, On Fri, Feb 03, 2012 at 05:27:19PM -0500, Scott Kitterman wrote: > It was never clear to me what the experiment was supposed to be, so > I've no idea what evidence would be appropriate. While I explicitly asked that the experiment evidence not include meta-analysis, commentary, and so on, and that it only have empirical evidence of whatever kind, I think Scott Kitterman's point is a reasonable one: "The question is wrong." Therefore, this subthread is for "The question is wrong" responses. If you just want to say "+1" that's ok with me. If you want to outline the ways in which you think the question is wrong or the experiment was flawed, that's ok with me too. Please do not add commentary about others' remarks, however, just as I originally asked. We're _collecting_ right now, not analyzing. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Fri Feb 3 15:57:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF94221F8534 for ; Fri, 3 Feb 2012 15:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 mO1lseuwQMVO for ; Fri, 3 Feb 2012 15:57:01 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3029021F851A for ; Fri, 3 Feb 2012 15:57:01 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9D45C1ECB41C for ; Fri, 3 Feb 2012 23:57:00 +0000 (UTC) Date: Fri, 3 Feb 2012 18:57:02 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120203235702.GB4322@crankycanuck.ca> References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <4F2C6684.9030408@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F2C6684.9030408@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Feb 2012 23:57:01 -0000 Dear colleagues, For the purposes of this collection exercise, any of the questions Dave outlines below, or indeed any other question you think has been answered by the experiment, is a fine one. The constraint is that you have to have empirical evidence of some kind. Note the distinction Dave usefully makes in his (1): "I believe the answer is no, but I don't any empirical basis for this." (Thank you for making the distinction, Dave.) We will have opportunities later to discuss beliefs, conclusions, and so on. But right now, it's important that we collect whatever empirical evidence we have, however sketchy, and do it with as little bias as we can. I am sometimes willing to discuss experimental metholology to the point that your ears bleed. It was once one of my areas of specialization. But for right now, we need to focus on such empirical evidence as we can scare up. Thanks, A On Fri, Feb 03, 2012 at 02:58:12PM -0800, Dave CROCKER wrote: > > On 2/3/2012 2:27 PM, Scott Kitterman wrote: > >On Friday, February 03, 2012 04:51:59 PM Andrew Sullivan wrote: > >>Dear colleagues, > >> > >>One of our tasks as a WG is to bring to an end the experiment started > >>by RFC 4408 and other documents published at the same time. > > > >It was never clear to me what the experiment was supposed to be, so I've no > >idea what evidence would be appropriate. Ultimately, I think Sender ID has > >been replaced by DKIM and that SPF and DKIM are complementary technolgies, so > >I'm not sure how to reply. > > > >Can we get away with: > > > >The SPF/Sender ID experiment was overtaken by the development of DK/DKIM and > >so Sender ID is obsoleted by those other technologies? > > > The simplest form of experimental question could be: > > 1. Has the world essentially dropped one of these (or both). > > Clearly spf is still heavily used, so this translates into whether > there remains significant support for Sender-ID. I believe the > answer is no, but I don't any empirical basis for this. > > > A more elaborate question could be: > > 2. Are there features from one that gained support and would be > worth merging into the other? > > Given my own answer to #1, above, that translates into "Are there > parts of Sender-ID worth salvaging?" > > Given the narrow scope, it is likely that any items deems reasonable > to merge into SPF will have to wait for a later SPFbisbis effort, > but it could be worth documenting. > > > Of general interest would be: > > 3. Document the deployment experiences of using SPF and/or Sender-ID. > > This would be a plusses and minuses history. > > d/ > -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Fri Feb 3 16:04:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647EC21F85F4 for ; Fri, 3 Feb 2012 16:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 6gSimNLkoAWJ for ; Fri, 3 Feb 2012 16:04:21 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id D80B321F85E9 for ; Fri, 3 Feb 2012 16:04:20 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 189FC1ECB41C for ; Sat, 4 Feb 2012 00:04:20 +0000 (UTC) Date: Fri, 3 Feb 2012 19:04:22 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120204000421.GC4322@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Meeting in Paris X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Feb 2012 00:04:21 -0000 Dear colleagues, We were chartered after the meeting slot request deadline, but I have since asked for a slot anyway. Here's what I asked for (pasted directly from the mail I sent to the agenda people): 2 hours (± 30 mins is ok, but this is a first meeting and a contentious topic.) 50 people (we're guessing. Probably REPUTE in Taipei would be a reasonable comparison.) conflicts1: appsawg, dane, dnsext, dnsop, eai, marf, precis, repute, sieve, hybi conflicts2: alto, behave, homenet, iri, mif, oauth, pkix If you have objections or, in particular, if I've missed something really obvious in the conflicts (I'd be astonished if I hadn't), please let me know as soon as possible. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From SRS0=/6jdS=AO==stuart@gathman.org Fri Feb 3 16:31:59 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9924311E8093 for ; Fri, 3 Feb 2012 16:31:59 -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 nbyovoZWBR8t for ; Fri, 3 Feb 2012 16:31:59 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA5D11E8091 for ; Fri, 3 Feb 2012 16:31:58 -0800 (PST) Received: from sdg.bmsi.com (sdg.bmsi.com [192.168.9.34] (may be forged)) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q140VCfI028479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Feb 2012 19:31:13 -0500 Message-ID: <4F2C7C7C.3020407@gathman.org> Date: Fri, 03 Feb 2012 19:31:56 -0500 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <7863221.PHTaGIf0LX@scott-latitude-e6320> In-Reply-To: <7863221.PHTaGIf0LX@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Issue: "Permanent" Temporary errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Feb 2012 00:33:10 -0000 Long ago, Nostradamus foresaw that on 02/03/2012 05:47 PM, Scott Kitterman would write: > I think that RCODE 2 replies should be considered PermError instead of > TempError. > > The operational impact of this is that messages are deferred (4xx) instead of > rejected (5xx) so they sit in a deferral queue and are retried for however > long the sending MTA is configured to attempt it. The user of the message > isn't notified of the non-delivery until it expires out of the queue, generally > after several days. > > In the SPF policy server for Postfix that I maintain, I changed the default > action on TempError from defer as a result of this issue. > +1 From presnick@qualcomm.com Fri Feb 3 19:36:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC6A21F8636 for ; Fri, 3 Feb 2012 19:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgBiogZJVgG2 for ; Fri, 3 Feb 2012 19:36:27 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id C37CF21F8602 for ; Fri, 3 Feb 2012 19:36:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1328326586; x=1359862586; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F2CA7B6.5040500@qualcomm.com>|Date:=20Fr i,=203=20Feb=202012=2021:36:22=20-0600|From:=20Pete=20Res nick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20|CC:=20Dave =20CROCKER=20,=20Scott=20Kitterman=20< spf2@kitterman.com>,=0D=0A=09|Subject: =20Re:=20[spfbis]=20Request=20for=20experimental=20eviden ce|References:=20<20120203215158.GQ4322@mail.yitter.info> =09<40255162.ysvdAIjBC2@scott-latitude-e6320>=20<4F2C6684 .9030408@dcrocker.net>|In-Reply-To:=20<4F2C6684.9030408@d crocker.net>|Content-Type:=20text/plain=3B=20charset=3D"I SO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=G+nOTIjpWyXcQCeFPGha0NO+L4nOExXtHXCJI/aL6/M=; b=M29Oc794Hk8Hwh10/9c4eixqYqG0Y2N3BnMPLJit2vi91ZwynL5bGVMo P8Ok6fEbzTrQO8/eyw7v2yDtffUbCB1GXgr7euenpBU1i5YpNaK7tRrRj NsbpYyosRkK1cIUTdMW5Nvk6e2Z+k4zRZegsToHpU6VErD2mmFyJgw+mF 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6609"; a="158197369" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 03 Feb 2012 19:36:26 -0800 X-IronPort-AV: E=Sophos;i="4.73,355,1325491200"; d="scan'208";a="179849956" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 03 Feb 2012 19:36:26 -0800 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 3 Feb 2012 19:36:25 -0800 Message-ID: <4F2CA7B6.5040500@qualcomm.com> Date: Fri, 3 Feb 2012 21:36:22 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <4F2C6684.9030408@dcrocker.net> In-Reply-To: <4F2C6684.9030408@dcrocker.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: spfbis@ietf.org, Dave CROCKER , Scott Kitterman Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Feb 2012 03:36:28 -0000 On 2/3/12 4:58 PM, Dave CROCKER wrote: > On 2/3/2012 2:27 PM, Scott Kitterman wrote: >> On Friday, February 03, 2012 04:51:59 PM Andrew Sullivan wrote: >>> Dear colleagues, >>> >>> One of our tasks as a WG is to bring to an end the experiment started >>> by RFC 4408 and other documents published at the same time. >> >> It was never clear to me what the experiment was supposed to be, so >> I've no >> idea what evidence would be appropriate. Ultimately, I think Sender >> ID has >> been replaced by DKIM and that SPF and DKIM are complementary >> technolgies, so >> I'm not sure how to reply. >> >> Can we get away with: >> >> The SPF/Sender ID experiment was overtaken by the development of >> DK/DKIM and >> so Sender ID is obsoleted by those other technologies? > > The simplest form of experimental question could be: > > 1. Has the world essentially dropped one of these (or both). > > Clearly spf is still heavily used, so this translates into whether > there remains significant support for Sender-ID. I believe the answer > is no, but I don't any empirical basis for this. [Speaking without hats] Point of clarification: In addition to wanting some "empirical basis" for whether there remains significant support for Sender-ID, I think we also want some specifics (i.e., empirical basis) for how "clearly spf is still heavily used". That is, I think we want the result-of-the-experiment document to actually say how much deployment there is of each technology, and what kind of deployments. It doesn't have to be extensive, but I think we do want the document to have some numbers. > A more elaborate question could be: > > 2. Are there features from one that gained support and would be worth > merging into the other? > > Given my own answer to #1, above, that translates into "Are there > parts of Sender-ID worth salvaging?" > > Given the narrow scope, it is likely that any items deems reasonable > to merge into SPF will have to wait for a later SPFbisbis effort, but > it could be worth documenting. > > > Of general interest would be: > > 3. Document the deployment experiences of using SPF and/or Sender-ID. > > This would be a plusses and minuses history. Agreed on these. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From msk@cloudmark.com Fri Feb 3 19:40:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4215621F85C9 for ; Fri, 3 Feb 2012 19:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.288 X-Spam-Level: X-Spam-Status: No, score=-102.288 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0CFBbTSIhqp for ; Fri, 3 Feb 2012 19:40:14 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D66E221F85C7 for ; Fri, 3 Feb 2012 19:40:14 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Feb 2012 19:40:14 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 3 Feb 2012 19:40:14 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Fri, 3 Feb 2012 19:40:19 -0800 Thread-Topic: [spfbis] Meeting in Paris Thread-Index: Aczi0Izhm01VoWqyQNOUyWJ66A0diAAHhOaQ Message-ID: References: <20120204000421.GC4322@mail.yitter.info> In-Reply-To: <20120204000421.GC4322@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [spfbis] Meeting in Paris X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Feb 2012 03:40:15 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzcGZiaXMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnNwZmJpcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5kcmV3 IFN1bGxpdmFuDQo+IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDMsIDIwMTIgNDowNCBQTQ0KPiBU bzogc3BmYmlzQGlldGYub3JnDQo+IFN1YmplY3Q6IFtzcGZiaXNdIE1lZXRpbmcgaW4gUGFyaXMN Cj4gDQo+ICAgICBjb25mbGljdHMxOiBhcHBzYXdnLCBkYW5lLCBkbnNleHQsIGRuc29wLCBlYWks IG1hcmYsIHByZWNpcywgcmVwdXRlLA0KPiAgICAgc2lldmUsIGh5YmkNCj4gDQo+ICAgICBjb25m bGljdHMyOiBhbHRvLCBiZWhhdmUsIGhvbWVuZXQsIGlyaSwgbWlmLCBvYXV0aCwgcGtpeA0KDQpJ ZiBJIGNhbiBiZSBzZWxmaXNoLCBwbGVhc2UgYWRkIHY2b3BzIHRvIGNvbmZsaWN0czIuDQoNClRo YW5rcywNCi1NU0sNCg0K From msk@cloudmark.com Fri Feb 3 19:51:24 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EE111E808D for ; Fri, 3 Feb 2012 19:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PyYz0CtT86Z for ; Fri, 3 Feb 2012 19:51:23 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id DCD9911E8071 for ; Fri, 3 Feb 2012 19:51:23 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Feb 2012 19:51:23 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 3 Feb 2012 19:51:23 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Fri, 3 Feb 2012 19:51:28 -0800 Thread-Topic: [spfbis] "The question is wrong" thread (was: Request for experimental evidence) Thread-Index: Acziz2zasXSWsu4qT9aA8fHEIRxELwAH1sMg Message-ID: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> In-Reply-To: <20120203235617.GA4322@crankycanuck.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] "The question is wrong" thread (was: Request for experimental evidence) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Feb 2012 03:51:24 -0000 I imagine to the IESG at the time, the "experiment" was the simultaneous de= ployment of the two technologies (or perhaps more accurately, their simulta= neous release into the wild as experimental RFCs) and an observation of the= impacts of doing so. The issue they had, as I recall, was that the two te= chnologies acted based on the same signal from the purported sender (the SP= F record), but could (often, in theory) reach different conclusions. It wa= s this collision that caused them not to release either as Proposed Standar= d, and add the IESG Note to all four documents. Thus to my mind, resolving the "experiment" itself involves questions such = as these: 1) Was this simultaneous deployment harmful, as the IESG feared? 2) Do SPF and Sender-ID actually come to similar or equal conclusions most = of the time? Or perhaps more generally, how often do they disagree? ...and then one of: 3a) If they are essentially or even approximately the same, which one is si= mpler and thus merits advancement? =09 3b) If they are essentially or even approximately the same, which one is mo= re widely deployed and thus worth standardization? I have opinions about all of these except (2), which requires a lot of coll= ected data to answer. I'll know sometime this weekend if my own data colle= cted about DKIM happens to include SPF and Sender-ID data so that I could o= ffer an answer (hopefully one of several such data sets). -MSK From msk@cloudmark.com Fri Feb 3 20:10:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C09F21F8547 for ; Fri, 3 Feb 2012 20:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGml+I79so47 for ; Fri, 3 Feb 2012 20:10:35 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A57FA21F8542 for ; Fri, 3 Feb 2012 20:10:35 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Feb 2012 20:10:32 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 3 Feb 2012 20:10:32 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Fri, 3 Feb 2012 20:10:37 -0800 Thread-Topic: [spfbis] "The question is wrong" thread (was: Request for experimental evidence) Thread-Index: Acziz2zasXSWsu4qT9aA8fHEIRxELwAH1sMgAADcCtA= Message-ID: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] "The question is wrong" thread (was: Request for experimental evidence) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Feb 2012 04:10:36 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Murray S. Kucherawy > Sent: Friday, February 03, 2012 7:51 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] "The question is wrong" thread (was: Request for ex= perimental evidence) >=20 > I have opinions about all of these except (2), which requires a lot of > collected data to answer. I'll know sometime this weekend if my own > data collected about DKIM happens to include SPF and Sender-ID data so > that I could offer an answer (hopefully one of several such data sets). The report came back earlier than I expected. In 95.51% of the cases for which I have both SPF and Sender-ID data (only a= bout 125k messages), the two agreed (i.e., both passed or neither passed). I'm quite sure there are far larger data sets than the one I have, but I ho= pe that gets us started. -MSK From msk@cloudmark.com Fri Feb 3 20:14:25 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2481C21F8574 for ; Fri, 3 Feb 2012 20:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao1zNP3Lw5lX for ; Fri, 3 Feb 2012 20:14:24 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B785321F856A for ; Fri, 3 Feb 2012 20:14:24 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Feb 2012 20:14:24 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 3 Feb 2012 20:14:24 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Fri, 3 Feb 2012 20:14:29 -0800 Thread-Topic: [spfbis] Request for experimental evidence Thread-Index: Aczi7jBzUym6ynOBRWKET6AuvbZplQABQeKQ Message-ID: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <4F2C6684.9030408@dcrocker.net> <4F2CA7B6.5040500@qualcomm.com> In-Reply-To: <4F2CA7B6.5040500@qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Feb 2012 04:14:25 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Pete Resnick > Sent: Friday, February 03, 2012 7:36 PM > To: dcrocker@bbiw.net > Cc: spfbis@ietf.org; Dave CROCKER; Scott Kitterman > Subject: Re: [spfbis] Request for experimental evidence >=20 > Point of clarification: In addition to wanting some "empirical basis" > for whether there remains significant support for Sender-ID, I think we > also want some specifics (i.e., empirical basis) for how "clearly spf > is still heavily used". That is, I think we want the result-of-the- > experiment document to actually say how much deployment there is of > each technology, and what kind of deployments. It doesn't have to be > extensive, but I think we do want the document to have some numbers. I think this is a difficult task to complete given the fact that it's impos= sible to tell from random polling whether a given site, sending or receivin= g, has deployed either technology. We'd have to rely on a survey of some k= ind, which necessarily makes some guesses about the masses that don't submi= t answers. -MSK From pmidge@microsoft.com Sat Feb 4 03:57:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EF321F8577 for ; Sat, 4 Feb 2012 03:57:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+rjolQ2kneI for ; Sat, 4 Feb 2012 03:57:23 -0800 (PST) Received: from TX2EHSOBE005.bigfish.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id E371C21F8528 for ; Sat, 4 Feb 2012 03:57:22 -0800 (PST) Received: from mail153-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Sat, 4 Feb 2012 11:57:22 +0000 Received: from mail153-tx2 (localhost [127.0.0.1]) by mail153-tx2-R.bigfish.com (Postfix) with ESMTP id 0F0CC4403E5; Sat, 4 Feb 2012 11:57:22 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371I542M1432Nzz1202hzz8275ch1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail153-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail153-tx2 (localhost.localdomain [127.0.0.1]) by mail153-tx2 (MessageSwitch) id 1328356640494550_14481; Sat, 4 Feb 2012 11:57:20 +0000 (UTC) Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.246]) by mail153-tx2.bigfish.com (Postfix) with ESMTP id 693F0240049; Sat, 4 Feb 2012 11:57:20 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 4 Feb 2012 11:57:20 +0000 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.110]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0247.005; Sat, 4 Feb 2012 03:57:10 -0800 From: Paul Midgen To: "Murray S. Kucherawy" , "spfbis@ietf.org" Thread-Topic: [spfbis] Request for experimental evidence Thread-Index: AQHM4r4SQLOijVDXPUucGKGbKkyib5YsRpqAgAAIoQCAAE24AIAACqeA///sNRA= Date: Sat, 4 Feb 2012 11:57:09 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204A6B29@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <4F2C6684.9030408@dcrocker.net> <4F2CA7B6.5040500@qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Feb 2012 11:57:23 -0000 I have a data collection effort underway at Hotmail that should wrap up aro= und late March and will share the data with this list. I agree with Murray that deployment will be hard to gauge, but it will be e= asy to compare the results of both methods against the same message, for a = huge volume of mail with a very large number of unique sending domains over= a reasonably long period of time. In my opinion the true purpose of the experiment was to determine which met= hod produced a measurable advantage in robust determination of path authori= zation. When it is shown that both ended up doing pretty much the same thin= g, there should be little reasonable resistance to taking the simplest most= expedient path forward. Hopefully others will share data as well. -p -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: Friday, February 03, 2012 8:14 PM To: spfbis@ietf.org Subject: Re: [spfbis] Request for experimental evidence > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On=20 > Behalf Of Pete Resnick > Sent: Friday, February 03, 2012 7:36 PM > To: dcrocker@bbiw.net > Cc: spfbis@ietf.org; Dave CROCKER; Scott Kitterman > Subject: Re: [spfbis] Request for experimental evidence >=20 > Point of clarification: In addition to wanting some "empirical basis" > for whether there remains significant support for Sender-ID, I think=20 > we also want some specifics (i.e., empirical basis) for how "clearly=20 > spf is still heavily used". That is, I think we want the=20 > result-of-the- experiment document to actually say how much deployment=20 > there is of each technology, and what kind of deployments. It doesn't=20 > have to be extensive, but I think we do want the document to have some nu= mbers. I think this is a difficult task to complete given the fact that it's impos= sible to tell from random polling whether a given site, sending or receivin= g, has deployed either technology. We'd have to rely on a survey of some k= ind, which necessarily makes some guesses about the masses that don't submi= t answers. -MSK _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From pmidge@microsoft.com Sat Feb 4 04:03:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1DD21F85A7 for ; Sat, 4 Feb 2012 04:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 lzNkgIjaF+YS for ; Sat, 4 Feb 2012 04:03:45 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3855021F84CF for ; Sat, 4 Feb 2012 04:03:45 -0800 (PST) Received: from mail146-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Sat, 4 Feb 2012 12:03:44 +0000 Received: from mail146-ch1 (localhost [127.0.0.1]) by mail146-ch1-R.bigfish.com (Postfix) with ESMTP id 7270A2015D; Sat, 4 Feb 2012 12:03:44 +0000 (UTC) X-SpamScore: -37 X-BigFish: VS-37(zz9371I11fbM542M1432Nzz1202hzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail146-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail146-ch1 (localhost.localdomain [127.0.0.1]) by mail146-ch1 (MessageSwitch) id 1328357012278019_20099; Sat, 4 Feb 2012 12:03:32 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248]) by mail146-ch1.bigfish.com (Postfix) with ESMTP id 770C23C0046; Sat, 4 Feb 2012 12:03:22 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 4 Feb 2012 12:03:22 +0000 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.110]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0247.005; Sat, 4 Feb 2012 04:03:14 -0800 From: Paul Midgen To: "Murray S. Kucherawy" , "spfbis@ietf.org" Thread-Topic: [spfbis] "The question is wrong" thread (was: Request for experimental evidence) Thread-Index: AQHM4s9tgPqZdpwtPkeRneX6wbGqPJYsoQkAgAAFWYD///05cA== Date: Sat, 4 Feb 2012 12:03:13 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204A6B5F@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] "The question is wrong" thread (was: Request for experimental evidence) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Feb 2012 12:03:45 -0000 I mention a rather large set of data being accumulated in another message t= o the list. Analysis of smaller data sets supports Murray's ~95% value. I've just taken= to saying >95% of the time SPF and SenderID do the same thing. I'll add a = few other bits of information to the analysis but that'll just be additiona= l color (e.g. PRA breakdowns, comparison to MailFrom, etc.) -p -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: Friday, February 03, 2012 8:11 PM To: spfbis@ietf.org Subject: Re: [spfbis] "The question is wrong" thread (was: Request for expe= rimental evidence) > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On=20 > Behalf Of Murray S. Kucherawy > Sent: Friday, February 03, 2012 7:51 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] "The question is wrong" thread (was: Request for=20 > experimental evidence) >=20 > I have opinions about all of these except (2), which requires a lot of=20 > collected data to answer. I'll know sometime this weekend if my own=20 > data collected about DKIM happens to include SPF and Sender-ID data so=20 > that I could offer an answer (hopefully one of several such data sets). The report came back earlier than I expected. In 95.51% of the cases for which I have both SPF and Sender-ID data (only a= bout 125k messages), the two agreed (i.e., both passed or neither passed). I'm quite sure there are far larger data sets than the one I have, but I ho= pe that gets us started. -MSK _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From vesely@tana.it Sat Feb 4 04:15:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DCB21F8532 for ; Sat, 4 Feb 2012 04:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.644 X-Spam-Level: X-Spam-Status: No, score=-4.644 tagged_above=-999 required=5 tests=[AWL=0.075, 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 0mS+0wt+rB-0 for ; Sat, 4 Feb 2012 04:15:02 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5427921F856C for ; Sat, 4 Feb 2012 04:15:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328357700; bh=3yYuw8BjmBYbWxND6n8i5XrWbv/fMDWZupxz6g5UFPo=; l=1373; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=B7XgA2+G6ivj/rStcTkC6ghQvVWh0yoY6dE344GipjK4S5fP0rs3+ershQoOHduvd FDm8SxMfzRsBiSmuF/MHLa+7rZA7nmr2ycJArgmJxzQrzZBTlytNpczD6yDwccHAEI Ix9MLsoe31k9sZKZo296NCM6PtLay5KAgAtNYXaE= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 04 Feb 2012 13:15:00 +0100 id 00000000005DC035.000000004F2D2144.00001C45 Message-ID: <4F2D2143.5080003@tana.it> Date: Sat, 04 Feb 2012 13:14:59 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <4F2C6684.9030408@dcrocker.net> <4F2CA7B6.5040500@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Feb 2012 12:15:03 -0000 On 04/Feb/12 05:14, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Pete Resnick > >> I think we want the result-of-the-experiment document to actually >> say how much deployment there is of each technology, and what >> kind of deployments. It doesn't have to be extensive, but I think >> we do want the document to have some numbers. > > I think this is a difficult task to complete given the fact that > it's impossible to tell from random polling whether a given site, > sending or receiving, has deployed either technology. We'd have to > rely on a survey of some kind, which necessarily makes some guesses > about the masses that don't submit answers. Yes, it is much easier to sample the published policies base. http://eggert.org/meter/spf.html and http://spf-all.com/ come to mind. For checking, besides Murray's collected data for DKIM, there is Google's DMARC reporting. It allows, among other things, to count failing spf checks for messages naively forwarded to gmail accounts, e.g., presumably for messages I sent to this or similar list, I got: ietf.org hardfail Another way to get numbers on checking results is to extract them from our own log files, where we know how we check SPF on incoming messages. That is obviously skewed, but can provide a trend. Worth? From spf2@kitterman.com Sat Feb 4 07:12:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8542721F8497 for ; Sat, 4 Feb 2012 07:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 4KtcC4nKcF78 for ; Sat, 4 Feb 2012 07:12:18 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BF93321F8478 for ; Sat, 4 Feb 2012 07:12:18 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B29C020E40B7; Sat, 4 Feb 2012 10:12:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328368337; bh=ni+Ja5S0EHyXm1znnKjH6RQhcA6z+fXY/UR8Dpg/V+w=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=D7wcpRRmWKTDSsl3Uxetjs3pavmoptEzVQliHlYy837Us+jl/4T3oMOcHoopdeUn1 w01iNKb7yIm/YqTcxpVdTt3ZLUHeCUIBzmbhJhu9yJhx7svfr+vwfQiKN/FiZginfG mzXWZU8FHo3+G+4aLvOiWPkvLNQAmbH1WrndsoMk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9282220E409F; Sat, 4 Feb 2012 10:12:17 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 04 Feb 2012 10:12:16 -0500 Message-ID: <2209995.9R6ESzKXuW@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Issue: RFC 4408 Errata X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Feb 2012 15:12:19 -0000 Errata exist and should be addresses in RFC 4408bis. http://www.rfc-editor.org/errata_search.php?rfc=4408 http://www.openspf.net/RFC_4408/Errata All of these, except one, are addressed in my draft that was the input draft for this working group: https://datatracker.ietf.org/doc/draft-kitterman-4408bis/ One didn't seem to have an obvious resolution, so I brought it up for review on the spf-discuss list late last year: http://www.listbox.com/member/archive/735/2011/10/sort/time_rev/page/1/entry/19:26/20111024163756:0CD3E470- FE80-11E0-89F0-A0E3D75F85EF/ You can look through the list archives and judge for yourself, but I think the rough consensus there favored option 1. I think this is the right resolution. Scott K From spf2@kitterman.com Sat Feb 4 08:43:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C627B21F84FA for ; Sat, 4 Feb 2012 08:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 dA917IQ72gQF for ; Sat, 4 Feb 2012 08:43:36 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 27B5221F84EF for ; Sat, 4 Feb 2012 08:43:36 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7513320E40B7; Sat, 4 Feb 2012 11:43:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328373815; bh=O1dNEfkaG02ZMEujv1wmHlAjdoC1SJlH1tm9c0K9qEs=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=RyZU3wb8c3khvliNS0TvYTcp8HDCqOWCrfEcwQTvIdD4AnN0eWkOxfpuAkuqQTe4g V4h00mGg63/zBFKUG/lSXrmC7KcFBVu8np0bko3IgVhxIjrWDlRiSxYX/SXAdQEt3+ euPdHYKSHEWeHnnL8Pe1rCwT+vBNUbKJqYBpVlmQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 56E7820E409F; Sat, 4 Feb 2012 11:43:35 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 04 Feb 2012 11:43:34 -0500 Message-ID: <5492551.llHetrvIID@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Issue: RFC 4408 ambiguities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Feb 2012 16:43:36 -0000 Shortly after RFC 4408 was released several SPF implementers collaborated on a test suite to validate RFC 4408 conformance. Through this effort, a number of ambiguities were identified in RFC 4408. These ambiguities are documented as comments in the test suite. Those that were consdidered important for interoperability were documented as errata. Others were not. The SPF test suite comments should be reviewed for non-errata comments and the ambiguity should be resolved or at least documented, since these don't seem to have an affect on interoperability, resolution is not essential. http://www.openspf.net/auth/Test_Suite As you can see from http://www.openspf.net/Implementations this test suite has been used by at least 4 different implementations. Additionally, the test suite documents common understanding if defined inputs and outputs, so it's a useful resource for the group to resolve any new concerns about uncertainty in the spec. Scott K From SRS0=G71eN=AP==stuart@gathman.org Sat Feb 4 18:19:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C657C21F84C4 for ; Sat, 4 Feb 2012 18:19:26 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7n-D3Yj94eEe for ; Sat, 4 Feb 2012 18:19:17 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id BCDBB21F84C3 for ; Sat, 4 Feb 2012 18:19:17 -0800 (PST) Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q152IQDm013569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 4 Feb 2012 21:18:31 -0500 Message-ID: <4F2DE713.2060209@gathman.org> Date: Sat, 04 Feb 2012 21:18:59 -0500 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> In-Reply-To: <4F29E395.3020100@mail-abuse.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Feb 2012 02:21:52 -0000 Long ago, Nostradamus foresaw that on 02/01/2012 08:15 PM, Douglas Otis would write: > An SPF ‘mx’ or ‘ptr’ mechanism limit corresponds to a ten times > greater number of DNS resource record resolutions. Actually, the PTR mechanism is essentially "free" for SPF DoS concerns in that it has already been resolved and cached by the MTA. Doug has several valid points: 1. Each uncached MX query served by an attacker's DNS can result in 10 uncached A record queries by a 3rd party triggered via SMTP. RFC4408 limits each SMTP transaction to 10 DNS oriented mechanisms, so with one SMTP MAIL FROM (or HELO) transaction and 10 uncached MX queries served, an attacker can trigger 100 uncached A queries by a 3rd party (the MTA). 2. The macro features allow an attacker to vary the domains with each SMTP MAIL FROM or HELO transaction to prevent caching. (By "transaction" I mean sending the TCP packet with the MAIL FROM or HELO command, and receiving the response so as to enable the next transaction.) 3. The victim of the A record queries will only see the IPs of legitimate MTAs, obscuring the perpetrator. The MX mechanism is not going away for 4408bis. Neither are the macro features. The next working group (for spf3 or whatever) can consider such surgery: for example removing the MX mechanism, or simply counting each MX record as an A mechanism for processing limit purposes. And again, SMTP enabled DoS does not require SPF. For example, with IP6 - just connect from random IP6 ips, and serve a big list of PTR records with names in your targets DNS when the MTA tries to identify the connect IP, none of which match your random IP. In my opinion, replacing SMTP would be a better use of energy than trying to stop deployment of IP6 or SPF (replacing SMTP gets rid of SPF as a bonus!). From dhc2@dcrocker.net Sat Feb 4 19:03:04 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D8621F84D5 for ; Sat, 4 Feb 2012 19:03: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQIIetVKSv4Y for ; Sat, 4 Feb 2012 19:03:03 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8965B21F84D4 for ; Sat, 4 Feb 2012 19:03:03 -0800 (PST) Received: from [192.168.1.9] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1532udc000716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Feb 2012 19:03:02 -0800 Message-ID: <4F2DF159.8050304@dcrocker.net> Date: Sat, 04 Feb 2012 19:02:49 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Pete Resnick References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <4F2C6684.9030408@dcrocker.net> <4F2CA7B6.5040500@qualcomm.com> In-Reply-To: <4F2CA7B6.5040500@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 04 Feb 2012 19:03:03 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 03:03:04 -0000 On 2/3/2012 7:36 PM, Pete Resnick wrote: >> The simplest form of experimental question could be: >> >> 1. Has the world essentially dropped one of these (or both). ... > Point of clarification: In addition to wanting some "empirical basis" for > whether there remains significant support for Sender-ID, I think we also want > some specifics (i.e., empirical basis) for how "clearly spf is still heavily > used". That is, I think we want the result-of-the-experiment document to I believe Lars had nothing to do with SPF development or any of the related technologies. That is, I believe he qualifies as an independent source. The URL has more detail, but he cites 65% global deployment. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Sat Feb 4 22:31:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235D421F852D for ; Sat, 4 Feb 2012 22:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 xXB-yVIbBksP for ; Sat, 4 Feb 2012 22:31:24 -0800 (PST) Received: from mail.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 738E521F852B for ; Sat, 4 Feb 2012 22:31:23 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=7141; t=1328423472; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Pk+pJM7JkrZdUjv80Ndsj4jo8nQ=; b=EMLG9GpAgh52CiDQXU3q XAjVW03Cy84UyR4NAZzZifp8l069s5FCwztyn4snsoSrlKrVErLiD5Jp4MsNFffD XTW4jkw6qCbNdCfx1yEeY/mvskyz1jikAg60WYYl/x/ng1Npvv7bx24m6KlEAEKo Sy37hnPYTjdY6jpdyleUg/s= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 05 Feb 2012 01:31:12 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1625334717.65977.388; Sun, 05 Feb 2012 01:31:12 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7141; t=1328423260; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=saWciKV TGM0hSkluMiL0TaCHgzpn46ETF5FiUJjMCxg=; b=lJZhb3eqGcN14veg0Hi43My TFYUE7qUzTHt3TvPYrSffUWnEgZmzeBq8S7STiTrtP5JYMEcZSciHcmO7uB284My HydWJfC+DgUAJG3LynQ34LOThtgycuY5wzBzLaZSb3CoemnOhKoavHr3HTqR6bSa Txg+biA/VrCBJNclia14= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 05 Feb 2012 01:27:40 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2224282408.11775.6368; Sun, 05 Feb 2012 01:27:39 -0500 Message-ID: <4F2E21F9.2060704@isdg.net> Date: Sun, 05 Feb 2012 01:30:17 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4F28DBB7.5070101@qualcomm.com> <4F29682D.305@isdg.net> In-Reply-To: <4F29682D.305@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Feb 2012 06:31:26 -0000 Pete, Now that I have a better change (more time) to review the charter, there is one item that I think may be important related to SENDER-ID from the standpoint of RFC 4405 SUBMITTER SMTP Extension. To begin the WG spec discussions, I was going to propose the following to modify section 4.1: 4.1. Arguments The check_host() function takes these arguments: - the IP address of the SMTP client that is emitting the mail, either IPv4 or IPv6. - the domain that provides the sought-after authorization information; initially, the domain portion of the "MAIL FROM" or "HELO" identity. [submitter] - RFC 4409, SUBMITTER keyword passed to the "MAIL FROM" but then I though it may not fit the charter with the way SENDER-ID is discussed. Background: In our implementation, if the SUBMITTER keyword is provided to the MAIL FROM, it is passed to our SPF implementation check_host() function: result = check_host(ip, domain [, submitter]) The tie-in, even for the SPF implementator who may not directly support SENDER-ID, it could be supporting RFC 4405 because it is a SMTP level protocol and it allows SMTP systems the NON-PAYLOAD affordability to support SENDER-ID indirectly. In my opinion, I think it has technical and operational merit to consider how implementations has supported SENDER-ID via the SUBMITTER keyword. However, the charter does ring with the idea that the industry are no longer interested in SENDER-ID. I don't think we can make that decision for anyone. Perhaps a statement should be added to the charter or revised it to clarify the lack of WG consideration for SENDER-ID does not imply it is no longer supported and that RFC4405 MAY be supported via SPF-BIS. If anything, the check_host() arguments SHOULD be changed to be flexible with optional parameters and not locked in and using RFC4405 is a valid technical rational as an example optional parameter without having to introduce SENDER-ID discussions. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Hector Santos wrote: > +1, looks good to me. > > -- > HLS > > Pete Resnick wrote: >> All, >> >> I have made some updates to the charter based on feedback during IESG >> review. If I can sneak it onto the Thursday telechat this week, I >> might, but the IESG might be none too pleased for me to put it on so >> late, so it may wait two more weeks. We'll see. >> >> Please review the below and see if there is anything that makes your >> head explode. >> >> pr >> >> --- >> >> Working Group Name: >> SPF Update (SPFBIS) >> >> IETF Area: >> Applications Area >> >> Chair(s): >> TBD >> >> Applications Area Director(s): > Pete Resnick >> Peter Saint-Andre >> >> Applications Area Advisor: >> Pete Resnick >> >> Mailing Lists: >> General Discussion:spfbis@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/spfbis >> Archive: http://www.ietf.org/mail-archive/web/spfbis/ >> >> Description of Working Group: >> The Sender Policy Framework (SPF, RFC4408) specifies the publication >> of a DNS record which states that a listed IP address is authorized >> to send mail on behalf of the listing domain name's owner. SMTP >> servers extract the domain name in the SMTP "MAIL FROM" or "HELO" >> command for confirming this authorization. The protocol has had >> Experimental status for some years and has become widely deployed. >> This working group will summarize the result of the experiment and >> revise the specification, based on deployment experience and listed >> errata, and will seek Standards Track status for the protocol. >> >> The MARID working group considered two specifications for >> publication of email-sending authorization: Sender-ID, which >> eventually became RFC4405, RFC4406 and RFC4407, and SPF, which >> eventually became RFC4408, all in the end published under >> Experimental status. By using IP addresses, both protocols specify >> authorization in terms of path, though unlike SPF, Sender-ID uses >> domain names found in the header of the message rather than the >> envelope. >> >> The two protocols rely on the same policy publication mechanism, >> namely a specific TXT resource record in the DNS. This creates a >> basic ambiguity about the interpretation of any specific instance of >> the TXT record. Because of this, there were concerns about >> conflicts between the two in concurrent operation. The IESG note >> prepended to RFC 4405 through RFC 4408 defined an experiment with >> SPF and Sender-ID, and invited an expression of community consensus >> in the period following the publication of those specifications. >> >> Both technologies initially enjoyed widespread deployment. Since >> that time, broad SPF use has continued, whereas use of Sender-ID has >> slackened. Furthermore, SPF's linkage to the envelope (as opposed >> to Sender-ID's linkage to identifiers in the message content) has >> proven sufficient among operators. >> >> Formation of the SPF Update Working Group is predicated on three >> assumptions: >> >> 1. The SPF/Sender-ID experiment has concluded. >> >> 2. SPF has been a qualified success, warranting further development. >> >> 3. Sender-ID has had less success, and no further development is >> justified. >> >> The working group will produce a document describing the course of >> the SPF/Sender-ID experiment, thus bringing that experiment to a >> formal conclusion. The group will complete additional work on SPF >> (described below), but will not complete additional work on the >> Sender-ID specification. >> >> Changes to the SPF specification will be limited to the correction >> of errors, removal of unused features, addition of any enhancements >> that have already gained widespread support, and addition of >> clarifying language. >> >> Specifically out-of-scope for this working group: >> >> * Revisiting past technical arguments where consensus was reached in >> the MARID working group, except where review is reasonably >> warranted based on operational experience. >> >> * Discussion of the merits of SPF. >> >> * Discussion of the merits of Sender-ID in preference to SPF. >> >> * Extensions to the SPF protocols. >> >> * Removal of existing features that are in current use. >> >> Discussion of extensions to the SPF protocols or removal of >> existing features shall only be discussed after completion of >> current charter items in anticipation of rechartering the working >> group. >> >> An initial draft of an updated SPF specification document is >> draft-kitterman-4408bis. The working group may choose to use this >> document as a basis for their specification. >> >> Goals and Milestones: >> Aug 2012: A document describing the SPF/Sender-ID experiment >> and its conclusions to the IESG for publication. >> >> Dec 2012: A standards track document defining SPF, >> based on RFC4408 and as amended above, >> to the IESG for publication. >> > From hsantos@isdg.net Sat Feb 4 22:53:25 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F7521F853D for ; Sat, 4 Feb 2012 22:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.474, 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 iHjuw-HCG0GF for ; Sat, 4 Feb 2012 22:53:25 -0800 (PST) Received: from mail.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E8D6921F853A for ; Sat, 4 Feb 2012 22:53:24 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1242; t=1328424803; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=NPYQsDQ4IMeGgI/BlyEvnEdc7ic=; b=kC52Bg2Cv/fIrx6Hz1oz xHPStaLn1bDvm2WKD95OVjXX7UaHnfECSRPkIlmnZJ0GS8BO9u5PrvWoz9N74o7X fUGH0MMeYj4te11lj3hWIlUIkvLq8VtS9nwrsfiS3xSC7BKlyp7C5Kq9i56KZ9xf nBz0TzzUbjF6k0zzh0msXnQ= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 05 Feb 2012 01:53:23 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1626664876.65977.2232; Sun, 05 Feb 2012 01:53:22 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1242; t=1328424590; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=1XK4jn4 e4eShqeqANn31zP+u4OHLIAj0TtV+RZSB5Pw=; b=E74hraHvHHFXDdpv/s1YAPp 0DQSZ1aQuM/2kJS5XkB0QklPogYuqNwADTL+f2M9gyA61Ft7+895C21s0pUoZg0B I8EMKEsu68ad0JfDO7Rbca291YZkiNa3DzuiZCfFLgbuy9OCEijh//BdaoCaweGd zEbfEm5jKQx19IcfK6No= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 05 Feb 2012 01:49:50 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2225613236.11777.1960; Sun, 05 Feb 2012 01:49:49 -0500 Message-ID: <4F2E272C.7020303@isdg.net> Date: Sun, 05 Feb 2012 01:52:28 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] Issue: Section 4.1 Check_Host() Arguments - adding RFC4405 Support X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 06:53:26 -0000 This may need a charter change/adjustment, but I would like to proposed section 4.1 be updated to support RFC 4405 by adding an optional [submitter] argument to the check_host() function model: 4.1. Arguments The check_host() function takes these arguments: - the IP address of the SMTP client that is emitting the mail, either IPv4 or IPv6. - the domain that provides the sought-after authorization information; initially, the domain portion of the "MAIL FROM" or "HELO" identity. | [submitter] - RFC4409, SUBMITTER keyword passed to the "MAIL FROM" Our SMTP server does not directly support SENDER-ID. However, our SPF implementation indirectly supports SENDER-ID via the RFC4405 SUBMITTER keyword, if any. Our SPF check_host() process model is: result = check_host(ip, domain [, submitter]) IMO, while we may not to get into SENDER-ID discussions for SPFBIS, the WG should not exclude the possibility for any industry support for SUBMITTER and it should be discussed as as realistic possibility to be part of the check_host() arguments. If you agree, it should be included in updating SPF-BIF. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From ajs@anvilwalrusden.com Mon Feb 6 04:19:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7676A21F8600 for ; Mon, 6 Feb 2012 04:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 ia1B4HrX5hxi for ; Mon, 6 Feb 2012 04:19:28 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id ED74821F85FF for ; Mon, 6 Feb 2012 04:19:27 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0E8271ECB41D for ; Mon, 6 Feb 2012 12:19:26 +0000 (UTC) Date: Mon, 6 Feb 2012 07:19:28 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120206121928.GA7609@crankycanuck.ca> References: <4F28DBB7.5070101@qualcomm.com> <4F29682D.305@isdg.net> <4F2E21F9.2060704@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F2E21F9.2060704@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 12:19:28 -0000 Dear Hector, colleagues, On Sun, Feb 05, 2012 at 01:30:17AM -0500, Hector Santos wrote: > Now that I have a better change (more time) to review the charter, > there is one item that I think may be important related to SENDER-ID > from the standpoint of RFC 4405 SUBMITTER SMTP Extension. Unfortunately, it is now too late to make changes to the charter without undertaking a WG rechartering exercise. I'd like to ask everyone to close this thread, please. > To begin the WG spec discussions, I was going to propose the > following to modify section 4.1: We've decided to begin the WG discssions a different way. Please see the threads about this I kicked off on Friday. Perhaps your suggestions could be made as part of a review, or else perhaps you have some evidence about the experiment you wish to share. > In my opinion, I think it has technical and operational merit to > consider how implementations has supported SENDER-ID via the > SUBMITTER keyword. > > However, the charter does ring with the idea that the industry are > no longer interested in SENDER-ID. I don't think we can make that > decision for anyone. Please see the thread asking for evidence about the experiment. Thanks and best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From pgladstone@cisco.com Mon Feb 6 05:46:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B5421F8630 for ; Mon, 6 Feb 2012 05:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fzNMa4cxXJF for ; Mon, 6 Feb 2012 05:46:14 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E8AF121F862F for ; Mon, 6 Feb 2012 05:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=800; q=dns/txt; s=iport; t=1328535974; x=1329745574; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=aUYoocmENriip4+GSG9wOX8Axsd3t+HGwlhLnW1JYh0=; b=VbeVzal76KIO/SUDIQPHHAzdjK/jF/3GPleyMi4zOAgVa3KzOxEs5Up7 K1Rjl5gDUj0zjF9JWBE5utIGdPqWTNpdXkviYpBmfc1v1S0exa+qQNepj zc/+LSGegESOZKx+t4RpITAB1AkA2wxcj2C6Rxpqul72xjtNVYzG8rnGs E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkHAMrYL0+tJV2Z/2dsb2JhbABDgw2BfqougQWBcgEBAQQSARAVQBELGAICBRYLAgIJAwIBAgFFEwgBAR6iGwGMZZF9gS+KNQEHAgIJBQ0DEwEIBQMDCRwDgnIZBAMMAxQFV1GCBoEWBIhEjGSFWI0h X-IronPort-AV: E=Sophos;i="4.73,370,1325462400"; d="scan'208";a="54022515" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 06 Feb 2012 13:46:13 +0000 Received: from [10.117.107.19] (rtp-pgladsto-8912.cisco.com [10.117.107.19]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q16DkDD5027623 for ; Mon, 6 Feb 2012 13:46:13 GMT Message-ID: <4F2FD9A4.1040108@cisco.com> Date: Mon, 06 Feb 2012 08:46:12 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120203215158.GQ4322@mail.yitter.info> In-Reply-To: <20120203215158.GQ4322@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 13:46:18 -0000 On 2/3/2012 4:51 PM, Andrew Sullivan wrote: > Dear colleagues, > > One of our tasks as a WG is to bring to an end the experiment started > by RFC 4408 and other documents published at the same time. > > To that end, your chairs would like evidence about the results of the > experiment. > > The problem that was widespread at the time of the introduction of SPF -- the joe-job has ceased to be an issue (as far as I am concerned). I feel that SPF has contributed to the ending of that particular scourge. However, the scarcity of deployed SRS (Sender Rewriting Scheme) implementations remains a barrier today to more widespread use of hardfail in SPF. This also extends to some (social) websites which send email to your 'friends' and forge it to come from you. Philip From sm@elandsys.com Mon Feb 6 06:11:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906BD21F8639 for ; Mon, 6 Feb 2012 06:11:37 -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=[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 6uvmSo0Fh5nl for ; Mon, 6 Feb 2012 06:11:32 -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 A3E5721F8617 for ; Mon, 6 Feb 2012 06:11:31 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q16EB9fj007318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 6 Feb 2012 06:11:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328537474; i=@elandsys.com; bh=Zj5x33Bf54Cj7G5YCxgMelCcY3WVsUzfnFr3sEb4YOY=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=k73t1EVZEY9evNCLlwfGKY1oqn9V9hWOxsjFGcHQZE+zjJoRwIBikNQGzX2FNn0BU WBVK9odEUgK54IyyvbenPrhQR2xJs86Z1W4hECcNZtGgeM2FjOfM+MyWQqtjwyCA6I sYYoeRJrJff6pkd4wlG9ab4LMkJVxk8V68+1j6Bc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328537474; i=@elandsys.com; bh=Zj5x33Bf54Cj7G5YCxgMelCcY3WVsUzfnFr3sEb4YOY=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=cDnuqkMCKV1jFenUdkdl6fCr6I4GYMT0Cv1lxgdCWgv7Cne/lJHh0XPGWTOIfDYCp IkOy3jlmuzLgJIUqDdkN60BxF0xACHlLV+0UUgBiWZvRhU65ikF7ekTc77ULeK1UaZ gCm4n1l3Io0NHrLaqP8D5OhZz/o2SEXaQFefDhnU= Message-Id: <6.2.5.6.2.20120206051254.08f58900@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 06 Feb 2012 05:43:00 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <5492551.llHetrvIID@scott-latitude-e6320> References: <5492551.llHetrvIID@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Issue: RFC 4408 ambiguities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 14:11:37 -0000 At 08:43 AM 2/4/2012, Scott Kitterman wrote: >The SPF test suite comments should be reviewed for non-errata >comments and the >ambiguity should be resolved or at least documented, since these >don't seem to >have an affect on interoperability, resolution is not essential. I suggest that WG participants include comments about the above as part of their review of RFC 4408 if they believe that it is relevant. >http://www.openspf.net/auth/Test_Suite The above link is not publicly accessible. As the content of the message was labelled as a RFC 4408 issue, it will be tracked as an issue. I will be opening an issue for each erratum ( http://www.rfc-editor.org/errata_search.php?rfc=4408 ). Regards, S. Moonesamy SPFBIS WG co-chair From sm@elandsys.com Mon Feb 6 06:11:38 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A3B21F8633 for ; Mon, 6 Feb 2012 06:11:38 -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 BdUDrPxqIlfq for ; Mon, 6 Feb 2012 06:11:33 -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 AD74E21F861A for ; Mon, 6 Feb 2012 06:11:32 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q16EB9fl007318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2012 06:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328537478; i=@elandsys.com; bh=Nf7wXHNBfaa+W8vfM1GRl84rwAWmv8tZlbWhie9FX28=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=j63tIvEuaYSUvI5/VHmKP+ypsc1HsoVdvE9Kmtav1CqiICo6g9ToumNguFN6d1TvU 9G60WO3oAOXlAgOaFbOfOY24PUv8EcDinb15RteqOkOnnKyAjaQv5HEohZ31qY+Vd2 WCkQ4VnT5Iu5nJT7eGtqAWoX2j4Tj60Zauf7gsk4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328537478; i=@elandsys.com; bh=Nf7wXHNBfaa+W8vfM1GRl84rwAWmv8tZlbWhie9FX28=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=uye23lkz/9sXcxxMTID5YiFsdphxhv3/8/dW2u1dLqxSqQJEy90JMQuQmri/rsUC/ 1We2PdkmtNitOwAu+JB7VdUFOeHRZl1UTQh2loIAccIC/2QTw8qI6KJRXaT6LZf3H0 bLtUQrTRld2sFkBwVePBKlmrUZgyit26PUliKRD8= Message-Id: <6.2.5.6.2.20120206054305.08f60cf8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 06 Feb 2012 06:09:05 -0800 To: Stuart Gathman From: SM In-Reply-To: <4F2DE713.2060209@gathman.org> References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <4F2DE713.2060209@gathman.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 14:11:38 -0000 Hi Stuart, Andrew Sullivan posted a message, as WG co-chair, about changes to the WG charter ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00280.html ). I suggest opening a new thread for your review of RFC 4408. At 06:18 PM 2/4/2012, Stuart Gathman wrote: >Doug has several valid points: I suggest that Doug posts the points as part of a review of RFC 4408 so that they can be tracked as issues. >The next working group (for spf3 or whatever) can consider such surgery: >for example removing the MX mechanism, or simply counting each MX record >as an A mechanism for processing limit purposes. As the WG is working on RFC 4408, this is the time to request changes to the SPF specification. Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Mon Feb 6 06:16:29 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC8D21F8600 for ; Mon, 6 Feb 2012 06:16:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8D863KAWDc06 for ; Mon, 6 Feb 2012 06:16:26 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0745C21F85E9 for ; Mon, 6 Feb 2012 06:16:26 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8A80A20E4126; Mon, 6 Feb 2012 09:16:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328537785; bh=H7L+3Cwjc6VAnmvYZip0jcZj6/+ZJ8XIsCzqaE95p4A=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=O7sssxJXCnPCqqT+6LpG2gIfIavCdjuxqtIx/g2pU1mILBsQsRTMlj7LWrM0kw4ue yczjpXwBXoj0Bkg9OPz4wGCa8ZYNv48wSUs1BNtEfI0deKABlBVhGjluEhYKeFubVq ACglp6SOMd42qnkQrcbtlMsYjuZc+Y8z7IVuhlug= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 70DF020E408E; Mon, 6 Feb 2012 09:16:25 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 06 Feb 2012 09:16:24 -0500 Message-ID: <1828318.tn8WGusqBE@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120206051254.08f58900@resistor.net> References: <5492551.llHetrvIID@scott-latitude-e6320> <6.2.5.6.2.20120206051254.08f58900@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] Issue: RFC 4408 ambiguities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 14:16:29 -0000 On Monday, February 06, 2012 05:43:00 AM S Moonesamy wrote: > At 08:43 AM 2/4/2012, Scott Kitterman wrote: > >The SPF test suite comments should be reviewed for non-errata > >comments and the > >ambiguity should be resolved or at least documented, since these > >don't seem to > >have an affect on interoperability, resolution is not essential. > > I suggest that WG participants include comments about the above as > part of their review of RFC 4408 if they believe that it is relevant. > > >http://www.openspf.net/auth/Test_Suite > > The above link is not publicly accessible. > > As the content of the message was labelled as a RFC 4408 issue, it > will be tracked as an issue. > > I will be opening an issue for each erratum ( > http://www.rfc-editor.org/errata_search.php?rfc=4408 ). Sorry for using the wrong URL. It's: http://www.openspf.net/Test_Suite Scott K From ajs@anvilwalrusden.com Mon Feb 6 07:29:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F6D21F8613 for ; Mon, 6 Feb 2012 07:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 qaPA0HwOBIZA for ; Mon, 6 Feb 2012 07:29:50 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id AEF4721F8611 for ; Mon, 6 Feb 2012 07:29:50 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 66F981ECB41D for ; Mon, 6 Feb 2012 15:29:43 +0000 (UTC) Date: Mon, 6 Feb 2012 10:29:30 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120206152926.GF7609@mail.yitter.info> References: <20120203215158.GQ4322@mail.yitter.info> <4F2FD9A4.1040108@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F2FD9A4.1040108@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 15:29:51 -0000 Dear colleagues, On Mon, Feb 06, 2012 at 08:46:12AM -0500, Philip Gladstone wrote: > The problem that was widespread at the time of the introduction of > SPF -- the joe-job has ceased to be an issue (as far as I am > concerned). I feel that SPF has contributed to the ending of that > particular scourge. > > However, the scarcity of deployed SRS (Sender Rewriting Scheme) > implementations remains a barrier today to more widespread use of > hardfail in SPF. This also extends to some (social) websites which > send email to your 'friends' and forge it to come from you. This is not to pick on Philip Gladstone, but to remind everyone that what we're looking for is empirical evidence. What we need are actual observations of SPF deployment. The first paragraph above gives an evaluation of what SPF did, and the second paragraph has a claim about an SPF dependency. How unused is hardfail in SPF? (Whether that is because of the reason offered or another one is a separate question, and not a matter of evidence.) Please restrict your postings in this thread to empirical evidence. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Mon Feb 6 08:19:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A9B21F863B for ; Mon, 6 Feb 2012 08:19:26 -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=[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 Ghqc-fXiww4Z for ; Mon, 6 Feb 2012 08:19:21 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B463721F85EE for ; Mon, 6 Feb 2012 08:19:21 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q16GJC8w001528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2012 08:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328545158; i=@elandsys.com; bh=an9FGnhCvHJkknvGnYipOXgyqRQtzXWwNPxUpCNMPvo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=a7t9Ylbee4pY6m3rXJXInYag8+E8Wftavh4IJRWAYrfbpp5x4hEjQfuzjt2uh9zZo CZPX2Oq/QrHyINAE/B63VEGSGoY6WB5tw1deSkHsCa/7zKPuN4il4sgDkyvCMlYJd2 ysvZeMQzdtdWp2bK2Wv/cVuC4M18hruzF8qHSi/M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328545158; i=@elandsys.com; bh=an9FGnhCvHJkknvGnYipOXgyqRQtzXWwNPxUpCNMPvo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=pHHEmQXkfihF2lqIiNGdhW2CjabqMezk/d2M8tnavIuWXYEY5tVHQERrRPZNe8YRo gvz2OmpDeJ1xEz/HJyoS5/xmJrNBASvxX3jPNbA5uDWHi3EE5NnMlDpVtorkanI56A lwXH5G2DHHIOfb6b8xo0UVOsuj0JljQiERncZrtE= Message-Id: <6.2.5.6.2.20120206062507.08f22c00@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 06 Feb 2012 08:17:21 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4F2FD9A4.1040108@cisco.com> References: <20120203215158.GQ4322@mail.yitter.info> <4F2FD9A4.1040108@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 16:19:26 -0000 At 05:46 AM 2/6/2012, Philip Gladstone wrote: >The problem that was widespread at the time of the introduction of >SPF -- the joe-job has ceased to be an issue (as far as I am >concerned). I feel that SPF has contributed to the ending of that >particular scourge. Paul Midgen mentioned that he can share some data with the working group ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00271.html ). Such information is useful for the work on the document which concludes the Sender-ID and SPF experiments. I'll quote part of Andrew's message ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00255.html ): "This is _not_ a request for an analysis of that evidence, or any sort of meta-commentary on it. It is especially not a request for any analysis of the differences nor any architecural commentary on how one or the other would work under this or that condition. It's just straight actual from-the-field evidence: this is an empirical experiment, and therefore we want empirical data." Saying that SPF or Sender-ID has contributed to solve X is not empirical data. Scott Kitterman posted the following comment ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00258.html ): "It was never clear to me what the experiment was supposed to be, so I've no idea what evidence would be appropriate." There are different ways to assess the experiments. The working group can consider the number of implementations, it can consider deployment, e.g. DNS records for Sender-ID and SPF, or the problems the experiments sought to address. There will be ample opportunity to discuss about which metric to use. For now, if you think that you have data which is relevant, post it to the list. Regards, S. Moonesamy SPFBIS WG co-chair From pgladsto@cisco.com Mon Feb 6 08:44:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89DF21F8645 for ; Mon, 6 Feb 2012 08:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCfXFe5+JEyS for ; Mon, 6 Feb 2012 08:44:23 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB2921F85FC for ; Mon, 6 Feb 2012 08:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladsto@cisco.com; l=1224; q=dns/txt; s=iport; t=1328546663; x=1329756263; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=KgwG25irNDJCjnIOA2WZXUpnPLeDpU6IsDYJIPi/gj8=; b=FiBwAZxPWwWfFGo3VUuukF6bpYl5CB0RqgpgE9iyu0rzYsmI9gvJ7ye/ p+q0mem50jgHcvIoGs4DIM7/QAHLyywpDSrg7RnltT7ZSQPgYv0ndSbbA KAHSGPbtkPD94TMRZWxH9uZ4pPjV/bU8d/NGos6fWC6SMdDXMwffIM6G6 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADkDME+rRDoG/2dsb2JhbABAA4ULqjmBBYFyAQEBBBIBEBVADwILGAICBRYLAgIJAwIBAgEJPBMGAgEBHqISAYxlkgUEgSuJfgkCAgkFDQMTAQgFAwMJHAOCchkEAwwDFAVXDQEEBDYFggaBFgSIRIxkhViNIQ X-IronPort-AV: E=Sophos;i="4.73,371,1325462400"; d="scan'208";a="27264792" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 06 Feb 2012 16:44:04 +0000 Received: from [161.44.106.141] (dhcp-161-44-106-141.cisco.com [161.44.106.141]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q16Gi4kn010633 for ; Mon, 6 Feb 2012 16:44:04 GMT Message-ID: <4F300350.2070500@cisco.com> Date: Mon, 06 Feb 2012 11:44:00 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120203215158.GQ4322@mail.yitter.info> <4F2FD9A4.1040108@cisco.com> <20120206152926.GF7609@mail.yitter.info> In-Reply-To: <20120206152926.GF7609@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 06 Feb 2012 08:50:45 -0800 Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 16:44:24 -0000 On 2/6/2012 10:29 AM, Andrew Sullivan wrote: > Please restrict your postings in this thread to empirical evidence.=20 > Thanks, A=20 OK! I have an archive of ~280,000 SPF records from the Alexa top 1M web=20 hosts. Not exactly the list of people that send email, but representative= =2E Qualifiers used: +a 223030 +all 2117 +aspmx 25 +exists 1415 +ip 507 +ip4 331927 +ip6 833 +ipv4 640 +mail 44 +mx 215065 +p4 27 +ptr 36507 +spf 43 -a 33 -all 52810 -ip4 43 ?all 53887 ?exists 66 ~a 31 ~al 29 ~all 164812 Note that the vast majority of '+' is implicit. Also, I have eliminated=20 the infrequent checks -- there is a fair amount of garbage in these=20 records (and maybe that is indicative of a problem). There is some=20 garbage in the table above. Philip --=20 Philip Gladstone Distinguished Engineer Product Development pgladstone@cisco.com Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Google: +1 978 800 1010 Ham radio: N1DQ From spf2@kitterman.com Mon Feb 6 09:05:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B837921F86A3 for ; Mon, 6 Feb 2012 09:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 0XLovwU0e+Aj for ; Mon, 6 Feb 2012 09:05:01 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1052621F86CE for ; Mon, 6 Feb 2012 09:05:01 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 83B8E20E4126; Mon, 6 Feb 2012 12:05:00 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328547900; bh=I94qUdO+2Lsry+EFHwp0Pqf/UgyJYSNLF76IAmMgiFs=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=AGkv8qf1C2WaXIxecUqRiFFyr8Q91DhLMjHl6QMAGs0hQ7ojShPm/npM4P5Nq0yIe 6QqcCmTHcmbJVdTBcZShktbBIy47gHBzOWebKnUWufZC4nfUJ3aE4jehUWz1YrxN3H eSMNYCyFeV+w+aDlL1cnhXmxKXgs8nO58cPdoUHM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6459020E408E; Mon, 6 Feb 2012 12:05:00 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 06 Feb 2012 12:04:59 -0500 Message-ID: <4461618.x9P3vB2UHx@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120206062507.08f22c00@resistor.net> References: <20120203215158.GQ4322@mail.yitter.info> <4F2FD9A4.1040108@cisco.com> <6.2.5.6.2.20120206062507.08f22c00@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] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 17:05:01 -0000 On Monday, February 06, 2012 08:17:21 AM S Moonesamy wrote: > Saying that SPF or Sender-ID has contributed to solve X is not empirical > data. If I put it in terms of: Before I deployed an SPF record ending in -all (fail), on my personal domains I used to get dozens to hundreds of bounce back emails from joe job attempts on and almost daily bases. Within a few months of deploying this record the level of traffic dropped to essentially nothing and it's been years since I recall getting a single such message. Is that empirical data (that was my experience as a small domain owner and I suspect similar to Phil's)? Scott K From spf2@kitterman.com Mon Feb 6 09:23:30 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0788321F86A6 for ; Mon, 6 Feb 2012 09:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 FSgAGzRBs263 for ; Mon, 6 Feb 2012 09:23:29 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6838121F86A3 for ; Mon, 6 Feb 2012 09:23:29 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 01D7320E4126; Mon, 6 Feb 2012 12:23:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328549009; bh=NfWMGjcl7IVDd7HPXIBxCuDQQbuja77NbvznVA/DjD4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=JUlBGtQmXpGJTWa1GM0MgnFaeZThaX585ZYDiS4pfVaHd9laq+GAQkxT5wGdFMBl+ 1qr7vInlIaDxQjWpok1U5Liy9A0GMggMXc1BA2MfcKDq4lzcZPq1QlbdZvKgxDlI1x B7grCy4OENtU+w3dnthyNIPnE9kGdlpC8gv9YRQM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D8BE220E408E; Mon, 6 Feb 2012 12:23:28 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 06 Feb 2012 12:23:28 -0500 Message-ID: <2108869.NqbhDt9bXh@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120206152926.GF7609@mail.yitter.info> References: <20120203215158.GQ4322@mail.yitter.info> <4F2FD9A4.1040108@cisco.com> <20120206152926.GF7609@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 17:23:30 -0000 On Monday, February 06, 2012 10:29:30 AM Andrew Sullivan wrote: > How unused is hardfail in SPF? It's not used at all, since there's no such thing as hardfail in SPF. I think being careful and precise about language in this discussion is important. Scott K From msk@cloudmark.com Mon Feb 6 09:37:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5885D21F847A for ; Mon, 6 Feb 2012 09:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 CWurvGRHncNS for ; Mon, 6 Feb 2012 09:37:43 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1C82421F847D for ; Mon, 6 Feb 2012 09:37:34 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 09:37:34 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 6 Feb 2012 09:37:34 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 6 Feb 2012 09:37:32 -0800 Thread-Topic: [spfbis] Request for experimental evidence Thread-Index: Aczk8Xq4BURAr1PKTkeuZ4aoLnyS2QABEZNQ Message-ID: References: <20120203215158.GQ4322@mail.yitter.info> <4F2FD9A4.1040108@cisco.com> <6.2.5.6.2.20120206062507.08f22c00@resistor.net> <4461618.x9P3vB2UHx@scott-latitude-e6320> In-Reply-To: <4461618.x9P3vB2UHx@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 17:37:44 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Monday, February 06, 2012 9:05 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] Request for experimental evidence >=20 > If I put it in terms of: >=20 > Before I deployed an SPF record ending in -all (fail), on my personal > domains I used to get dozens to hundreds of bounce back emails from joe > job attempts on and almost daily bases. >=20 > Within a few months of deploying this record the level of traffic > dropped to essentially nothing and it's been years since I recall > getting a single such message. >=20 > Is that empirical data (that was my experience as a small domain owner > and I suspect similar to Phil's)? I think such anecdotal evidence answers a question as to SPF's efficacy, bu= t not the question of resolution of the experiment declared by the IESG (or= , at least, not directly). In particular, it makes no statement about whet= her or not Sender-ID had or would have had the same or similar impact. From spf2@kitterman.com Mon Feb 6 09:42:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66B421F8460 for ; Mon, 6 Feb 2012 09:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 Wqy3IXFNp4Ey for ; Mon, 6 Feb 2012 09:42:21 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 24FCA21F8462 for ; Mon, 6 Feb 2012 09:42:20 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7AF2420E414F; Mon, 6 Feb 2012 12:42:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328550140; bh=dNtAqYQj7Yxg4A71Numw7N/8Mq+aZWLiLOmD8e5CMDE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Z4gfgdl1QRSag8dVSUhF9Bx6RWcoquWSrHiBNx/a3JIJO5G6Rgq21gxhb9Riyp1pc ryaT7UZlrYqsiMpe1OtHj5pq+Vm0WkCqFYc4iPBsrlPBXgV/E99uu/y8EnewykViEI 39UcaHs/V9ovbdK9U439xmwPndoL5iGRylcWnoFU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5D83B20E408E; Mon, 6 Feb 2012 12:42:20 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 06 Feb 2012 12:42:19 -0500 Message-ID: <1502896.8P9jSTJ1xr@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120203215158.GQ4322@mail.yitter.info> <4461618.x9P3vB2UHx@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] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 17:42:21 -0000 On Monday, February 06, 2012 09:37:32 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Scott Kitterman Sent: Monday, February 06, 2012 9:05 AM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] Request for experimental evidence > > > > If I put it in terms of: > > > > Before I deployed an SPF record ending in -all (fail), on my personal > > domains I used to get dozens to hundreds of bounce back emails from joe > > job attempts on and almost daily bases. > > > > Within a few months of deploying this record the level of traffic > > dropped to essentially nothing and it's been years since I recall > > getting a single such message. > > > > Is that empirical data (that was my experience as a small domain owner > > and I suspect similar to Phil's)? > > I think such anecdotal evidence answers a question as to SPF's efficacy, but > not the question of resolution of the experiment declared by the IESG (or, > at least, not directly). In particular, it makes no statement about > whether or not Sender-ID had or would have had the same or similar impact. That's true, but there's no way to go back and tell. I think it is useful on the basis of the idea that got suggested here somewhere that if they both work, we should just use the simpler one (SPF). That thought can be extended to, if SPF works, we should just use it. Unless there's a showing of superior efficacy of some kind, there's no reason to take on the inherent technical and IPR complexities of Sender-ID. Scott K From pgladstone@cisco.com Mon Feb 6 09:46:53 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D09921F86EF for ; Mon, 6 Feb 2012 09:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jjf+AmzTCo43 for ; Mon, 6 Feb 2012 09:46:52 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2D43721F86E5 for ; Mon, 6 Feb 2012 09:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=1530; q=dns/txt; s=iport; t=1328550412; x=1329760012; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=uv1tUnXG9nELS6TIPDhqiUpJf1B8NDs9hUI5lRouFUI=; b=heK7AttCOtOxCnDhsD6IFE06HY37Bo9/h5Lrxa59rEdBshT3cKkrYd8h X1i1n1inRUW8UilVUfEYV/eFDIY6db3eutCtosQmGtbgsPgsP1v9N9mEr KR2WZFObW+mFyXDfB6dUQd1frKr244HH/qzpbAN8h0MPe3LXyo/eTd5Lz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEADARME9Io8UY/2dsb2JhbABDhQuoEIMugXIBAQEEEgEQFUARCxgCAgUWCwICCQMCAQIBRRMIAQEeoWIBjGWSCIEviX8BBwICCQUNAxMBCAUDAwkfgnIZBAMMAxQFVw0BBAQ7ggaBFgSIRIxkhViNIQ X-IronPort-AV: E=Sophos;i="4.73,372,1325462400"; d="scan'208";a="4940151" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 06 Feb 2012 17:46:50 +0000 Received: from [161.44.106.141] (dhcp-161-44-106-141.cisco.com [161.44.106.141]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q16Hkndv015337 for ; Mon, 6 Feb 2012 17:46:50 GMT Message-ID: <4F301208.3090800@cisco.com> Date: Mon, 06 Feb 2012 12:46:48 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120203215158.GQ4322@mail.yitter.info> <4F2FD9A4.1040108@cisco.com> <6.2.5.6.2.20120206062507.08f22c00@resistor.net> <4461618.x9P3vB2UHx@scott-latitude-e6320> In-Reply-To: <4461618.x9P3vB2UHx@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 17:46:53 -0000 On 2/6/2012 12:04 PM, Scott Kitterman wrote: > Before I deployed an SPF record ending in -all (fail), on my personal domains > I used to get dozens to hundreds of bounce back emails from joe job attempts > on and almost daily bases. > > Within a few months of deploying this record the level of traffic dropped to > essentially nothing and it's been years since I recall getting a single such > message. > > Is that empirical data (that was my experience as a small domain owner and I > suspect similar to Phil's)? > > Over the last 4 days, I see 57 IP addresses forwarding emails that were originated from my domain. I *think* that all of these are actually valid forwards (but not doing the appropriate SRS rewriting), though I suspect that there are implementation problems in certain SPF implementations. For example, 98.136.219.60: ostmaster 98.138.215.201: ostmaster 98.138.91.117: postmaster 98.138.91.60: postmaster 98.139.165.31: ostmaster 98.139.165.55: ostmaster This says that the addresses forwarded mail from postmaster@mydomain and ostmaster@mydomain. I suspect that the 'ostmaster' is a bug in the evaluation of the %{l1r-} macro. I also see 209.68.2.48: bounces.wxqc This indicates that (probably) wxqc-bounces was the originator and the %{l1r-} did not get evaluated correctly (two components were returned) 128.186.98.3: ouncces.wxqc This is weirdest -- it looks like another bug. (I see this particular error from two other IPs as well. Philip From spf2@kitterman.com Mon Feb 6 09:52:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144C221F8604 for ; Mon, 6 Feb 2012 09:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 6xsJuV0AvLdT for ; Mon, 6 Feb 2012 09:52:07 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 22EFA21F8633 for ; Mon, 6 Feb 2012 09:52:06 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 88A2120E4126; Mon, 6 Feb 2012 12:52:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328550726; bh=4nzSETyUyZMtrnOG0DoGzFFJImx+mYYSqWbqu+OmndA=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=jhuyVx5y0J6goSNVGnjHr+yJOQAGR3c8Ltcm9tIXMHD6HfphnK95gXIWB2asNU9oP 6Jh9d/2o8P4607heN0Em73LQIZRf54f92qqwN0Xq0EX0bM3rRslvbh/RG5W0c+hjqX S/EqYyv6csSnTJAZZbyl9NUHVk1TeESQQgy2C7+M= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6BBE720E408E; Mon, 6 Feb 2012 12:52:06 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 06 Feb 2012 12:52:05 -0500 Message-ID: <1789090.uGqYcqLmHb@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Issue: Processing limits needs clarification and reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 17:52:08 -0000 As I understand it, security considerations aren't generally supposed to give normative protocol implementations constraints, but the processing limits in paragraph 10.1 of RFC 4408 does exactly this. While the technical limits themselves are appropriate, paragraph 10.1 should be split into two parts. The actual processing limits should find a home in the main body of the specification and then a revised security consideration should focus on a clearer discussion about why they are important and why one should design records the minimize DNS impact. Scott K From dhc2@dcrocker.net Mon Feb 6 10:22:13 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4742F21F8726 for ; Mon, 6 Feb 2012 10:22:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5w8f9dqbfiQ for ; Mon, 6 Feb 2012 10:22:12 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3C66121F870B for ; Mon, 6 Feb 2012 10:22:12 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q16IM6Tp017953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2012 10:22:11 -0800 Message-ID: <4F301A4C.704@dcrocker.net> Date: Mon, 06 Feb 2012 10:22:04 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Scott Kitterman References: <1789090.uGqYcqLmHb@scott-latitude-e6320> In-Reply-To: <1789090.uGqYcqLmHb@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]); Mon, 06 Feb 2012 10:22:12 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] Issue: Processing limits needs clarification and reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 18:22:13 -0000 On 2/6/2012 9:52 AM, Scott Kitterman wrote: > As I understand it, security considerations aren't generally supposed to give > normative protocol implementations constraints, but the processing limits in > paragraph 10.1 of RFC 4408 does exactly this. > > While the technical limits themselves are appropriate, paragraph 10.1 should > be split into two parts. The actual processing limits should find a home in > the main body of the specification and then a revised security consideration > should focus on a clearer discussion about why they are important and why one > should design records the minimize DNS impact. +1 There are some (security and other) folks who believe that it is entirely acceptable to have normative statements in the security considerations section. I'm not one of them. I think that a Considerations section is an adjunct to the actual specification and that format, protocol, configuration and operations normative statements should be in "specification" sections, distinct from analysis and 'considerations' section. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Mon Feb 6 10:28:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DC321F86A3 for ; Mon, 6 Feb 2012 10:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 VIcZKRRQDqoG for ; Mon, 6 Feb 2012 10:28:40 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 56C6421F84F3 for ; Mon, 6 Feb 2012 10:28:38 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 10:28:38 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 6 Feb 2012 10:28:38 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 6 Feb 2012 10:28:36 -0800 Thread-Topic: [spfbis] Issue: Processing limits needs clarification and reorganization Thread-Index: Aczk/EGMqgTYsj9hSiemNSvk3AYfIQAAM6fA Message-ID: References: <1789090.uGqYcqLmHb@scott-latitude-e6320> <4F301A4C.704@dcrocker.net> In-Reply-To: <4F301A4C.704@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Issue: Processing limits needs clarification and reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 18:28:41 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dave CROCKER > Sent: Monday, February 06, 2012 10:22 AM > To: Scott Kitterman > Cc: spfbis@ietf.org > Subject: Re: [spfbis] Issue: Processing limits needs clarification and re= organization >=20 > +1 >=20 > There are some (security and other) folks who believe that it is > entirely acceptable to have normative statements in the security > considerations section. +1 as well, both to the procedural point and to the specific issue that nee= ds clarification. From dhc2@dcrocker.net Mon Feb 6 10:29:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74AF21F86CE for ; Mon, 6 Feb 2012 10:29:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf5n26Q2DE8p for ; Mon, 6 Feb 2012 10:29:08 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F32D221F869E for ; Mon, 6 Feb 2012 10:28:57 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q16ISqiA018135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 6 Feb 2012 10:28:57 -0800 Message-ID: <4F301BE2.8050603@dcrocker.net> Date: Mon, 06 Feb 2012 10:28:50 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120203215158.GQ4322@mail.yitter.info> <4F2FD9A4.1040108@cisco.com> <20120206152926.GF7609@mail.yitter.info> <4F300350.2070500@cisco.com> In-Reply-To: <4F300350.2070500@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 06 Feb 2012 10:28:57 -0800 (PST) Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 18:29:08 -0000 > I have an archive of ~280,000 SPF records This prompts a question worth considering: Do we care about adoption via publication of SPF records, versus adoption via evaluation of SPF records? It's trivial to publish a record, but it does still take the decision and some effort. So knowledge of publication percentages is helpful. In contrast, it is rather expensive to start paying attention to SPF records on the receive side, since it requires extra software AND requires additional policy decisions. That is, how should the additional information be /used/? Adoption by publication is important, of course, but it only represents an inexpensive hope of utility. Adoption by evaluation is, IMO, the critical information. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Mon Feb 6 10:31:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0459921F86A3 for ; Mon, 6 Feb 2012 10:31:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXxSL0k5DYrp for ; Mon, 6 Feb 2012 10:31:47 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1362F21F86D9 for ; Mon, 6 Feb 2012 10:31:47 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q16IVfWF018202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2012 10:31:46 -0800 Message-ID: <4F301C8B.70107@dcrocker.net> Date: Mon, 06 Feb 2012 10:31:39 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 06 Feb 2012 10:31:46 -0800 (PST) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 18:31:48 -0000 On 2/3/2012 7:51 PM, Murray S. Kucherawy wrote: > I imagine to the IESG at the time, the "experiment" was the simultaneous deployment of the two technologies (or perhaps more accurately, their simultaneous release into the wild as experimental RFCs) and an observation of the impacts of doing so. This highlights a very basic and very serious problem we are faced with: guessing what the IESG wanted. Absent a clear statement, how can we know we are satisfying the requirement to comment on the 'experiment'? We do not even know what it was or was supposed to be. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs@anvilwalrusden.com Mon Feb 6 10:39:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D501021F86EE for ; Mon, 6 Feb 2012 10:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 CA6ycCwSpRud for ; Mon, 6 Feb 2012 10:39:27 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 59B1421F86D9 for ; Mon, 6 Feb 2012 10:39:27 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2EC411ECB41D for ; Mon, 6 Feb 2012 18:39:26 +0000 (UTC) Date: Mon, 6 Feb 2012 13:39:24 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120206183924.GN7609@mail.yitter.info> References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F301C8B.70107@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 18:39:28 -0000 Dear colleagues, On Mon, Feb 06, 2012 at 10:31:39AM -0800, Dave CROCKER wrote: > This highlights a very basic and very serious problem we are faced > with: guessing what the IESG wanted. > > Absent a clear statement, how can we know we are satisfying the > requirement to comment on the 'experiment'? We do not even know > what it was or was supposed to be. All of that is true, but it is also futile: "the IESG" is not the same body it was then, and anyway asking people about what their intentions were in the past is not likley to yield a proposition amenable to verification. Speaking only for myself for a moment, this is actually why I think we want anything that resembles empirical evidence about any of this experiment. If we are to go to the rest of the IETF and say, "We believe this experiment is over," people will be right to ask what basis we have for that assertion. We don't know what the experimental terms are, but we can point to such evidence as we have and say that it seems to demonstrate [insert our conclusions here]. Speaking as chair again, I strongly discourage us to attempt to work out what the experimental purpose was. It's too bad nobody wrote it down at the time. But they didn't, and we have to live with that fact of the world. The lack of experimental goals, however, is indeed why we have a thread for complaints that we cannot tell what would qualify as evidence about the experiment. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From dotzero@gmail.com Mon Feb 6 11:03:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940FC21F8609 for ; Mon, 6 Feb 2012 11:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yAtpAZPOMTa for ; Mon, 6 Feb 2012 11:03:20 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB07521F8603 for ; Mon, 6 Feb 2012 11:03:19 -0800 (PST) Received: by dakl33 with SMTP id l33so5888869dak.31 for ; Mon, 06 Feb 2012 11:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QypOo58FRjwkVTDU2WHelLc1cT5qxloecyklIfOyKZo=; b=uQDAPA80V+17xtntFgiG57HFKK2bfMHLfia/5yrbRmRGTpCOK0yImMRodeW2LpiBK9 nugKjrta162uYVK9biAt3rT3/thUyeT5hQdE4vUklUc+BTarsfbGxio+IQ0ulAM+55JX s7tRf4ftBUulpscwBTXqRtGy0XbTs5Y88Nd1Q= MIME-Version: 1.0 Received: by 10.68.233.74 with SMTP id tu10mr25362675pbc.98.1328554993582; Mon, 06 Feb 2012 11:03:13 -0800 (PST) Received: by 10.142.102.3 with HTTP; Mon, 6 Feb 2012 11:03:13 -0800 (PST) In-Reply-To: <20120206183924.GN7609@mail.yitter.info> References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> Date: Mon, 6 Feb 2012 14:03:13 -0500 Message-ID: From: Dotzero To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 19:03:21 -0000 On Mon, Feb 6, 2012 at 1:39 PM, Andrew Sullivan wr= ote: > Dear colleagues, > > On Mon, Feb 06, 2012 at 10:31:39AM -0800, Dave CROCKER wrote: > >> This highlights a very basic and very serious problem we are faced >> with: guessing what the IESG wanted. >> >> Absent a clear statement, how can we know we are satisfying the >> requirement to comment on the 'experiment'? =A0We do not even know >> what it was or was supposed to be. > > All of that is true, but it is also futile: "the IESG" is not the same > body it was then, and anyway asking people about what their intentions > were in the past is not likley to yield a proposition amenable to > verification. > > Speaking only for myself for a moment, this is actually why I think we > want anything that resembles empirical evidence about any of this > experiment. =A0If we are to go to the rest of the IETF and say, "We > believe this experiment is over," people will be right to ask what > basis we have for that assertion. =A0We don't know what the experimental > terms are, but we can point to such evidence as we have and say that > it seems to demonstrate [insert our conclusions here]. > > Speaking as chair again, I strongly discourage us to attempt to work > out what the experimental purpose was. =A0It's too bad nobody wrote it > down at the time. =A0But they didn't, and we have to live with that fact > of the world. =A0The lack of experimental goals, however, is indeed why > we have a thread for complaints that we cannot tell what would qualify > as evidence about the experiment. > > Best, > > A > In light of Andrews comments, I would recommend that we not spend any time considering SenderID. Based on the results we cans imply say that it failed to gain traction in the wild (particularly from a receiver evaluation side) and leave it at that. The working group charter is focused on SPF and NOT SenderID. Mike From msk@cloudmark.com Mon Feb 6 11:09:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317DD21F8730 for ; Mon, 6 Feb 2012 11:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 tV4lJn-uOQ0q for ; Mon, 6 Feb 2012 11:09:19 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAA321F872D for ; Mon, 6 Feb 2012 11:09:16 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 11:09:16 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 6 Feb 2012 11:09:15 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 6 Feb 2012 11:09:14 -0800 Thread-Topic: [spfbis] "The question is wrong" thread Thread-Index: AczlAgDOl0nFM/YZSJqdSq8n8Y+29AAALNUA Message-ID: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 19:09:20 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dotzero > Sent: Monday, February 06, 2012 11:03 AM > To: Andrew Sullivan > Cc: spfbis@ietf.org > Subject: Re: [spfbis] "The question is wrong" thread >=20 > In light of Andrews comments, I would recommend that we not spend any > time considering SenderID. Based on the results we cans imply say that > it failed to gain traction in the wild (particularly from a receiver > evaluation side) and leave it at that. The working group charter is > focused on SPF and NOT SenderID. What evidence would you present to support that claim? We need to do better than anecdotal, I believe. From dotzero@gmail.com Mon Feb 6 11:17:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AC021F8733 for ; Mon, 6 Feb 2012 11:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yt9A7j9L-ErV for ; Mon, 6 Feb 2012 11:17:05 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C11F21F872D for ; Mon, 6 Feb 2012 11:17:05 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so2348760pbc.31 for ; Mon, 06 Feb 2012 11:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yMXrPZwAu0kMgCoALN9JFPN33MPsnCTZ1aQQ5QctSWM=; b=dMDOUK6oCqEy5OyiJ8Nq6cVtt4Pl3TTGukAhQujrENtvcemt44uXSlCYS0cihxOLTx xtLhgvTWhLKGzDrX/Ox2emnNaQmhBHIbNBqqIx3hIm7IGrqKY0GC9N9uM9IQ821GDkor dhUyuO+Ikx1vSRQFoq9X05+u/GjJmLPR4FuSo= MIME-Version: 1.0 Received: by 10.68.208.228 with SMTP id mh4mr49763370pbc.13.1328555825212; Mon, 06 Feb 2012 11:17:05 -0800 (PST) Received: by 10.142.102.3 with HTTP; Mon, 6 Feb 2012 11:17:05 -0800 (PST) In-Reply-To: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> Date: Mon, 6 Feb 2012 14:17:05 -0500 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 19:17:06 -0000 On Mon, Feb 6, 2012 at 2:09 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Dotzero >> Sent: Monday, February 06, 2012 11:03 AM >> To: Andrew Sullivan >> Cc: spfbis@ietf.org >> Subject: Re: [spfbis] "The question is wrong" thread >> >> In light of Andrews comments, I would recommend that we not spend any >> time considering SenderID. Based on the results we cans imply say that >> it failed to gain traction in the wild (particularly from a receiver >> evaluation side) and leave it at that. The working group charter is >> focused on SPF and NOT SenderID. > > What evidence would you present to support that claim? > The only significant receiver that I am aware of that validates SenderID is Microsoft and they are supportive of SPF as part of DMARC looking forward. I'll flip it around. if someone or someones want to come forward and argue that SenderID has a thriving implementer base then I'd love to see the list. > We need to do better than anecdotal, I believe. > You missed the (implied) point in my first statement. SenderID is out of scope for the charter of the SPFbis working group. If others wish to then they can seek to form a SenderIDbis working group. I am not recommending this, just pointing out that this group does not have an obligation to speak to that experiement. My comment about SenderID adoption should really be considered as an aside. Mike From msk@cloudmark.com Mon Feb 6 11:23:09 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4512B21F86C9 for ; Mon, 6 Feb 2012 11:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 t-6Xh+AusjbV for ; Mon, 6 Feb 2012 11:23:08 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id C85EF21F86A7 for ; Mon, 6 Feb 2012 11:23:08 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 11:23:08 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 6 Feb 2012 11:23:07 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 6 Feb 2012 11:23:06 -0800 Thread-Topic: [spfbis] "The question is wrong" thread Thread-Index: AczlA+o+9tl1dt+ESJGXV1hqBv1vxgAAFXGQ Message-ID: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 19:23:09 -0000 > -----Original Message----- > From: Dotzero [mailto:dotzero@gmail.com] > Sent: Monday, February 06, 2012 11:17 AM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] "The question is wrong" thread >=20 > > What evidence would you present to support that claim? >=20 > The only significant receiver that I am aware of that validates > SenderID is Microsoft and they are supportive of SPF as part of DMARC > looking forward. I'll flip it around. if someone or someones want to > come forward and argue that SenderID has a thriving implementer base > then I'd love to see the list. I don't think it's reasonable to ask anyone to prove a negative. > > We need to do better than anecdotal, I believe. >=20 > You missed the (implied) point in my first statement. SenderID is out > of scope for the charter of the SPFbis working group. If others wish to > then they can seek to form a SenderIDbis working group. I am not > recommending this, just pointing out that this group does not have an > obligation to speak to that experiement. My comment about SenderID > adoption should really be considered as an aside. I disagree. The IESG Note attached to both Sender ID and SPF indicates tha= t the two are in direct conflict, which is why both were relegated to Exper= imental status. If I were on the IESG that will receive this working group= 's documents and that issue had been completely ignored or only marginally = addressed, I would object to the documents' advancement. I don't think this is a way out. We need to answer the question one way or= another. It's in our charter. -MSK From ajs@anvilwalrusden.com Mon Feb 6 11:52:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7690721F863B for ; Mon, 6 Feb 2012 11:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 Y-sGmgCD8R+f for ; Mon, 6 Feb 2012 11:52:52 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 42B4421F8699 for ; Mon, 6 Feb 2012 11:52:51 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 48E0E1ECB41D for ; Mon, 6 Feb 2012 19:52:50 +0000 (UTC) Date: Mon, 6 Feb 2012 14:52:48 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120206195248.GS7609@mail.yitter.info> References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 19:52:52 -0000 On Mon, Feb 06, 2012 at 02:03:13PM -0500, Dotzero wrote: > time considering SenderID. Based on the results we cans imply say that ^^^^^^^^^^^^^^^^^^^^ Let me try again. We are attempting to determine, in the present stage, _what those results are_ and not what they mean. We need to collect the data before we can analyze it. We cannot throw away one pile of evidence on the basis that we already know what the answer is. > evaluation side) and leave it at that. The working group charter is > focused on SPF and NOT SenderID. This is certainly true, but given that they were both released at the same time using the same facilities on the Internet, it is going to be hard to move ahead without making a determination about the way these things interacted with one another. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From dhc2@dcrocker.net Mon Feb 6 11:58:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2273921F8723 for ; Mon, 6 Feb 2012 11:58:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ru2cI2IshICB for ; Mon, 6 Feb 2012 11:58:20 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD0921F872D for ; Mon, 6 Feb 2012 11:58:20 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q16JwDX1019859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2012 11:58:18 -0800 Message-ID: <4F3030D3.9090900@dcrocker.net> Date: Mon, 06 Feb 2012 11:58:11 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Andrew Sullivan References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> In-Reply-To: <20120206183924.GN7609@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 06 Feb 2012 11:58:19 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 19:58:21 -0000 On 2/6/2012 10:39 AM, Andrew Sullivan wrote: > All of that is true, but it is also futile: "the IESG" is not the same > body it was then, and anyway asking people about what their intentions > were in the past is not likley to yield a proposition amenable to > verification. I concur, and in fact was mostly interested in highlighting that casting any of this in terms of what "the IESG" wants or wanted will not be productive. However some of the discussion has attempted to presume what was being requested by the IESG. The history of this activity is an 'experiment' only in the sense of test-marketing. Seeing whether something will be a success in the market. Of course, there can be many interesting questions about what it means to be a success, including comparative worth between competing solutions. So, really, my core point is that we need to agree on what questions we need to answer. Any empirical data could be helpful, but without specific questions that we agree need to be answered the degree of utility will be accidental. I originally posted some suggested questions for us to answer. You and others have posted additional questions. All look interesting, but we probably should prune the set to a few basic issues that could help with strategic choices. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs@anvilwalrusden.com Mon Feb 6 12:22:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B944F21F8613 for ; Mon, 6 Feb 2012 12:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 uvJpELG5Nijl for ; Mon, 6 Feb 2012 12:22:52 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 40AC821F8606 for ; Mon, 6 Feb 2012 12:22:52 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7C8E11ECB41D for ; Mon, 6 Feb 2012 20:22:51 +0000 (UTC) Date: Mon, 6 Feb 2012 15:22:45 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120206202244.GA8370@mail.yitter.info> References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3030D3.9090900@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 20:22:52 -0000 On Mon, Feb 06, 2012 at 11:58:11AM -0800, Dave CROCKER wrote: > > I originally posted some suggested questions for us to answer. You > and others have posted additional questions. All look interesting, > but we probably should prune the set to a few basic issues that > could help with strategic choices. I'm clearly having a bad chair day, because I'm having a devil of a time getting this point across. While I agree that it would be considerably easier to prune the questions we think we're trying to answer, I believe that we might face hard questions later if we exclude some classes of evidence from consideration or if we decide too early to rule some question out of consideration. That is why (despite it going against everything in my personal make-up) I have been resisting trying to shape the question too much in this initial round. I know that there are many people who may find this approach frustrating or annoying, or who might think that this is simply a waste of time. It seems to me, however, that we are less likely to overlook something during our evaluation if we have collected as much as possible from the beginning. Had the "experiment" actually contained any sort of statement about what propositions were under test, I would likely urge a different evaluation methodology. But it didn't, so I didn't. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From dotzero@gmail.com Mon Feb 6 12:29:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C964E21F86C9 for ; Mon, 6 Feb 2012 12:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTJzL0DpSUya for ; Mon, 6 Feb 2012 12:29:32 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id EC7A121F86EE for ; Mon, 6 Feb 2012 12:29:31 -0800 (PST) Received: by dakl33 with SMTP id l33so5954382dak.31 for ; Mon, 06 Feb 2012 12:29:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QYHpV+Q/qQF67t09ftYEzjjb79cz+59i5BYcqzUrTo4=; b=Of6AxK+gEC1Kk7NuvLL7faIebsBR4UFkqTQEno6A5iY2pQBqpI4CQ/wvMWh9uVVOua n+QbOLmoAaAH3tG3nKKTWuGx+0mHKMReKWdkjYYhxdKWSHQzebpz2znIVY19sic06Gt/ Csd7KdK9hc3QGgY9k46d7HqN2HsrlwmhNT21w= MIME-Version: 1.0 Received: by 10.68.222.169 with SMTP id qn9mr22595147pbc.30.1328560171780; Mon, 06 Feb 2012 12:29:31 -0800 (PST) Received: by 10.142.102.3 with HTTP; Mon, 6 Feb 2012 12:29:31 -0800 (PST) In-Reply-To: <20120206195248.GS7609@mail.yitter.info> References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <20120206195248.GS7609@mail.yitter.info> Date: Mon, 6 Feb 2012 15:29:31 -0500 Message-ID: From: Dotzero To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 20:29:32 -0000 On Mon, Feb 6, 2012 at 2:52 PM, Andrew Sullivan wr= ote: > On Mon, Feb 06, 2012 at 02:03:13PM -0500, Dotzero wrote: > >> time considering SenderID. Based on the results we cans imply say that > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^^^^^^^^^= ^^^ > > Let me try again. =A0We are attempting to determine, in the present > stage, _what those results are_ and not what they mean. =A0We need to > collect the data before we can analyze it. =A0We cannot throw away one > pile of evidence on the basis that we already know what the answer is. > >> evaluation side) and leave it at that. The working group charter is >> focused on SPF and NOT SenderID. > > This is certainly true, but given that they were both released at the > same time using the same facilities on the Internet, it is going to be > hard to move ahead without making a determination about the way these > things interacted with one another. > I leave it to others then to provide data on SenderID. I'm not saying throw away a pile of evidence on the basis that we already know what the answer is. I'm saying that data regarding SenderID and the success or failure of THAT experiment is generally orthogonal to the SPF experiment and it's success or failure in the wild. SenderID data should only be of interest regarding the SPF experiment to the extent that such data directly impacts discussion of the success or failure (empirically) of the SPF experiment. At the close of the MARID working group there were basically two competing camps - each supporting one of the specs. I was lukewarm towards SenderID but found it unacceptable because a flaw in the PRA algorithm (related to use of the Sender field) allowed malicious emails to consistently get a neutral even for domains publishing a -all. Mike From sm@elandsys.com Mon Feb 6 13:52:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C0211E8080 for ; Mon, 6 Feb 2012 13:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 neZE1+59bbo3 for ; Mon, 6 Feb 2012 13:52:50 -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 5A74521F856F for ; Mon, 6 Feb 2012 13:52:34 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q16LqOw3012729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2012 13:52:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328565150; i=@elandsys.com; bh=P7e/wrwoYUZeTHryFG/orX6eFPBU4eXgRRH6XPrLtrE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=sj5mmjz24PELkJMoZhVMagDwVg3o4pwM9aKc61T87FJ86dR2YINgyBy3USALjkpsy zLl0TtLBc5wA6JwZ3vsQoR5C1BvNpXNuwB1YxWuN1cmydZspUO4vWW+BdVDuozr8/o Jqfu1THxPhh/I0gMYJq04IjKNmdVNzenCSzny+zA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328565150; i=@elandsys.com; bh=P7e/wrwoYUZeTHryFG/orX6eFPBU4eXgRRH6XPrLtrE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=3bOwu+Iz8XQ2RRmShfA5gI4kdIl4E75ehHwNvx3rsmet9yF1gsxP5uqNEjnAVDrp3 +466VZdey7LMNMN2HrPgzr3UXVzaVakKMojUNl+bHjWMeG/gvsXzplA9UY+m/Exwl6 zGs0q3z/qCWQLX8A1a51g/Qrr9blKaA/EwNxjhfY= Message-Id: <6.2.5.6.2.20120206131514.06d91d30@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 06 Feb 2012 13:52:12 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <20120206195248.GS7609@mail.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 21:52:52 -0000 Dear SPFBIS Working Group, If WG participants believe that there are or there will be two competing camps here, I suggest that they give the matter some more thought. We have a charter which spells out the working group deliverables. My WG co-chair has already explained that we are asking for: (i) Reviews of RFC 4408 (ii) Experimental evidence I would like to see some focus here instead of discussions about issues, how to conclude the experiments or what the IESG wants. Some of you may view the questions as fuzzy. I would like to be able to say: The Working Group has carefully considered this matter and took the following decision. It will take us longer to get to that point if we start with open-ended discussions. I understand that some WG participants might not be familiar with the IETF process. We are also here to explain the non-technical details. Please post your questions to this mailing list or to either of the WG co-chairs. Regards, S. Moonesamy SPFBIS WG co-chair From msk@cloudmark.com Mon Feb 6 14:07:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B879F21F85AC for ; Mon, 6 Feb 2012 14:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 GvkQe8b5TmcN for ; Mon, 6 Feb 2012 14:07:15 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E3DE511E8096 for ; Mon, 6 Feb 2012 14:07:15 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 14:07:15 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 6 Feb 2012 14:07:14 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 6 Feb 2012 14:07:14 -0800 Thread-Topic: [spfbis] "The question is wrong" thread Thread-Index: AczlDSCJVOLEn2QFQBm8Xkavee796gADkh6g Message-ID: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> In-Reply-To: <20120206202244.GA8370@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 22:07:16 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Andrew Sullivan > Sent: Monday, February 06, 2012 12:23 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] "The question is wrong" thread >=20 > Had the "experiment" actually contained any sort of statement about > what propositions were under test, I would likely urge a different > evaluation methodology. But it didn't, so I didn't. As has been pointed out, the IESG that added the Note Well to those other d= ocuments isn't the IESG we have today. But really, all that matters is the= IESG we have today (or, at least, the one that will review the output of t= his working group). Thus, would it be beneficial to ask the current IESG what it thinks the exp= eriment is or was, or what they'd like to see from us in terms of a resolut= ion? Since they're the ones that get to decide, maybe they're the ones we = should ask. -MSK From msk@cloudmark.com Mon Feb 6 14:10:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809BD11E8096 for ; Mon, 6 Feb 2012 14:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 8lsZTV26ZoDb for ; Mon, 6 Feb 2012 14:10:57 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 86A4911E8086 for ; Mon, 6 Feb 2012 14:10:41 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 14:10:40 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 6 Feb 2012 14:10:40 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 6 Feb 2012 14:10:38 -0800 Thread-Topic: [spfbis] "The question is wrong" thread Thread-Index: AczlGa6FqeL5iav0S5ubBl70sJSwEQAAjyiA Message-ID: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <20120206195248.GS7609@mail.yitter.info> <6.2.5.6.2.20120206131514.06d91d30@resistor.net> In-Reply-To: <6.2.5.6.2.20120206131514.06d91d30@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 22:10:58 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of S Moonesamy > Sent: Monday, February 06, 2012 1:52 PM > To: spfbis@ietf.org > Cc: Andrew Sullivan > Subject: Re: [spfbis] "The question is wrong" thread >=20 > I would like to see some focus here instead of discussions about > issues, how to conclude the experiments or what the IESG wants. Some > of you may view the questions as fuzzy. I would like to be able to > say: >=20 > The Working Group has carefully considered this matter and took the > following decision. I think we are going in that direction, though it's very early in that proc= ess. The request for RFC4408 reviews is quite clear, but the request for e= vidence of the results of the experiment isn't answerable without understan= ding exactly what we think the experiment was, and that currently seems to = be an open-ended question. Otherwise, I think we need some pretty specific= guidance about what data you're after. -MSK From dotzero@gmail.com Mon Feb 6 14:32:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FEA11E8075 for ; Mon, 6 Feb 2012 14:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHSaX6MXgdVh for ; Mon, 6 Feb 2012 14:32:17 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3509311E8096 for ; Mon, 6 Feb 2012 14:32:17 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so2487116pbc.31 for ; Mon, 06 Feb 2012 14:32:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tPVS7shv0GqbToUcL053pUg7Uh9tK9Ns+nhaIaWbPUU=; b=Q1EEc3DMeaDIR18M8Y/AD1dg71I7TlAdOGZvAGgAPxz2gG9sorpQDQ9s4DBbLGjhEr B2g1P+LctO6XzTObNUvmQyqU/CIIIfdDfd4EzhTSxzqKcBjBqR8WCFp7B4//Z1NwS2hy CeNajA9wJqVAP41lrPtozeaGeTqF1dlyfPnLo= MIME-Version: 1.0 Received: by 10.68.73.103 with SMTP id k7mr50404394pbv.132.1328567537015; Mon, 06 Feb 2012 14:32:17 -0800 (PST) Received: by 10.142.102.3 with HTTP; Mon, 6 Feb 2012 14:32:16 -0800 (PST) In-Reply-To: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <20120206195248.GS7609@mail.yitter.info> <6.2.5.6.2.20120206131514.06d91d30@resistor.net> Date: Mon, 6 Feb 2012 17:32:16 -0500 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 22:32:17 -0000 On Mon, Feb 6, 2012 at 5:10 PM, Murray S. Kucherawy wro= te: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf= Of S Moonesamy >> Sent: Monday, February 06, 2012 1:52 PM >> To: spfbis@ietf.org >> Cc: Andrew Sullivan >> Subject: Re: [spfbis] "The question is wrong" thread >> >> I would like to see some focus here instead of discussions about >> issues, how to conclude the experiments or what the IESG wants. =A0Some >> of you may view the questions as fuzzy. =A0I would like to be able to >> say: >> >> =A0 =A0The Working Group has carefully considered this matter and took t= he >> =A0 =A0following decision. > > I think we are going in that direction, though it's very early in that pr= ocess. =A0The request for RFC4408 reviews is quite clear, but the request f= or evidence of the results of the experiment isn't answerable without under= standing exactly what we think the experiment was, and that currently seems= to be an open-ended question. =A0Otherwise, I think we need some pretty sp= ecific guidance about what data you're after. > This is why I am asking for a consensus or a call by the chairs that the item (ii) Experimental evidence presented should be constrained by item (i) Reviews of RFC 4408 and the fact that RFC 4408 is the focus of this working group. There were in fact two concurrent experiments. The charter of the group does not include RFC 4406 or RFC 4407. Mike From sm@resistor.net Mon Feb 6 14:33:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B2111E8075 for ; Mon, 6 Feb 2012 14:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 YKz8ooZcKBy0 for ; Mon, 6 Feb 2012 14:33:48 -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 6AD5821F86DB for ; Mon, 6 Feb 2012 14:33:36 -0800 (PST) Received: from sm-THINK.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 q16MXWsc014026 for ; Mon, 6 Feb 2012 14:33:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328567615; i=@resistor.net; bh=L3pLGKVatRDLbb3OVgPGb1yk9lc48APb0N01gRjDkeU=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=PV5rwMgdC7Xu15AMxUC5MJ7YUsqh7tMknJCKLoF92adMpFOs7jLyoQapLIEYkntQV wvawo18Msln+BBxsTiSGkbNsFn/8wKu2z9Utf7BC8WRwho8o+xRm2i8EnJMhQ9BBxq 5TNZhgjuO3Kwmxw6PFn6m09MQviWoZdllo7hM75k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1328567615; i=@resistor.net; bh=L3pLGKVatRDLbb3OVgPGb1yk9lc48APb0N01gRjDkeU=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=iebmyvivtUp7gIsMj+sgzijqLSWsGAR9OppxPFxNLtMEKqJNSLYr9BKg5HNcEW1YR CQiETsZdwzurptlNlJk3uv8DfsU8S4+vbVmPV88ROQVf7iza0/6g01uNTc/7nquVAX gnJBIk1FrwO0Pq+JWOI9wjDb3AKShNv1ieAA0Cbo= Message-Id: <6.2.5.6.2.20120206141650.096cd600@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 06 Feb 2012 14:20:16 -0800 To: spfbis@ietf.org From: SM In-Reply-To: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 22:33:50 -0000 Hi Murray, At 02:07 PM 2/6/2012, Murray S. Kucherawy wrote: >As has been pointed out, the IESG that added the Note Well to those >other documents isn't the IESG we have today. But really, all that >matters is the IESG we have today (or, at least, the one that will >review the output of this working group). It's an IESG Note. The Note Well is about IETF Contributions. >Thus, would it be beneficial to ask the current IESG what it thinks >the experiment is or was, or what they'd like to see from us in >terms of a resolution? Since they're the ones that get to decide, >maybe they're the ones we should ask. I don't think you'll get the answer you are waiting for. :-) Regards, -sm From msk@cloudmark.com Mon Feb 6 14:35:14 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146C811E80A6 for ; Mon, 6 Feb 2012 14:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 DZGUMmjlens6 for ; Mon, 6 Feb 2012 14:35:13 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id AABE511E8075 for ; Mon, 6 Feb 2012 14:35:13 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 14:35:13 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 6 Feb 2012 14:35:13 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 6 Feb 2012 14:35:12 -0800 Thread-Topic: [spfbis] "The question is wrong" thread Thread-Index: AczlH2gT6L1TaRSjTLKC9COX6hJamQAAAzDw Message-ID: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> <6.2.5.6.2.20120206141650.096cd600@resistor.net> In-Reply-To: <6.2.5.6.2.20120206141650.096cd600@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 22:35:14 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of SM > Sent: Monday, February 06, 2012 2:20 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] "The question is wrong" thread >=20 > It's an IESG Note. The Note Well is about IETF Contributions. Sorry, yes, the IESG Note. > >Thus, would it be beneficial to ask the current IESG what it thinks the > >experiment is or was, or what they'd like to see from us in terms of a > >resolution? Since they're the ones that get to decide, maybe they're > >the ones we should ask. >=20 > I don't think you'll get the answer you are waiting for. :-) What answer do you think I'm waiting for? It's clear that any answer is better than guessing, and that my guess is di= fferent than those of others. -MSK From msk@cloudmark.com Mon Feb 6 14:37:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34CD11E80AB for ; Mon, 6 Feb 2012 14:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 qUoA1weTZy6N for ; Mon, 6 Feb 2012 14:37:16 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E197511E80A6 for ; Mon, 6 Feb 2012 14:37:15 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 14:37:15 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 6 Feb 2012 14:37:15 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 6 Feb 2012 14:37:13 -0800 Thread-Topic: [spfbis] "The question is wrong" thread Thread-Index: AczlHzBIV1l0GsHRQrOzCDPHsbSdIgAAGeTQ Message-ID: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <20120206195248.GS7609@mail.yitter.info> <6.2.5.6.2.20120206131514.06d91d30@resistor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 22:37:17 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dotzero > Sent: Monday, February 06, 2012 2:32 PM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] "The question is wrong" thread >=20 > This is why I am asking for a consensus or a call by the chairs that > the item (ii) Experimental evidence presented should be constrained by > item (i) Reviews of RFC 4408 and the fact that RFC 4408 is the focus > of this working group. There were in fact two concurrent experiments. > The charter of the group does not include RFC 4406 or RFC 4407. On the contrary, the charter lists as our first milestone: Aug 2012: A document describing the SPF/Sender-ID experiment and its conclusions to the IESG for publication. That clearly involves RFCs 4406 and 4407, because they defined Sender-ID, a= nd all three of them included the IESG Note, which created the experiment (= and without clearly defining it, as Andrew pointed out). -MSK From WebMaster@Commerco.Net Mon Feb 6 14:39:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712BE11E80AE for ; Mon, 6 Feb 2012 14:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwnlFrd8d52X for ; Mon, 6 Feb 2012 14:39:47 -0800 (PST) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id A7BBF11E80AB for ; Mon, 6 Feb 2012 14:39:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=YjrcdSW4kpNDWuRhmVcxNRtNUSzripMmiNGImYMpeBLLhiElZ2wOekpl9x47pFDUc4usvIrqx2acJC6QBSaIIZGU/ghoygFKjWVJNZXN7UtXFZi//eRi331Wg2lGWyc1kAxzlXGiP8Nh5rSsZg9o46UnOFM/QnLYUEx0ZoZ+0Pk= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Mon, 06 Feb 2012 22:39:46 +0000 Message-ID: <4F3056AC.5020807@Commerco.Net> Date: Mon, 06 Feb 2012 15:39:40 -0700 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> In-Reply-To: <20120206202244.GA8370@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 22:39:48 -0000 On 2/6/2012 1:22 PM, Andrew Sullivan wrote: > On Mon, Feb 06, 2012 at 11:58:11AM -0800, Dave CROCKER wrote: >> >> I originally posted some suggested questions for us to answer. You >> and others have posted additional questions. All look interesting, >> but we probably should prune the set to a few basic issues that >> could help with strategic choices. > > I'm clearly having a bad chair day, because I'm having a devil of a > time getting this point across. While I agree that it would be > considerably easier to prune the questions we think we're trying to > answer, I believe that we might face hard questions later if we > exclude some classes of evidence from consideration or if we decide > too early to rule some question out of consideration. That is why > (despite it going against everything in my personal make-up) I have > been resisting trying to shape the question too much in this initial > round. > > I know that there are many people who may find this approach > frustrating or annoying, or who might think that this is simply a > waste of time. It seems to me, however, that we are less likely to > overlook something during our evaluation if we have collected as much > as possible from the beginning. > > Had the "experiment" actually contained any sort of statement about > what propositions were under test, I would likely urge a different > evaluation methodology. But it didn't, so I didn't. > > Best regards, > > A > How about this - can we look at the "experiment" from an MTA adoption standpoint. There are a number of well known SMTP/POP server applications that exist on various OS platforms out there. Can we easily determine how many of these (both Open Source and Commercially paid for products) actually support SPF vs SenderID as a measure of success of one vs the other? It would at least offer an answer as to the success of the experiment from an MTA implementer standpoint in software which seemingly most benefits from SPF or SenderID. From an adopter point of view, I could offer yet another anecdotal story regarding SPF, but I'm guessing our Chair might be unhappy, so for these, probably the only thing we can do is reach out to those who have done some independent research from DNS servers as to the adoption of SPF RR and TXT RRs which contain the SPF v1 marker. In a strange sense, I suppose the support for and implementation of the SPF RR in DNS itself might be considered something of a win for the SPF experiment. Best, Alan M From sm@elandsys.com Mon Feb 6 14:59:14 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2627E11E809F for ; Mon, 6 Feb 2012 14:59:14 -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 B0ACk+GWI+Ns for ; Mon, 6 Feb 2012 14:59:11 -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 152CF11E8096 for ; Mon, 6 Feb 2012 14:59:11 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q16Mx2MJ016089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2012 14:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328569148; i=@elandsys.com; bh=XZ99OwVmZEwJyuE9+VzniCVmYBscA6rTdjkcR/f5vwo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=MAVKj8YW+Nq8mZYH4ZuiVzJKVW8Pj/yRGj0w9+aXSq8EmXwOGDOiBFPWwFVcnJ8pa fBQdPrVPZu3xpPjAjlJfBt4MJcx1174N00KBzXPvskdmcdy7wsoMHlKhKKqfkjH5dP Y5bbYZWDyjPwp0sdOd0TJVVT8VZCRKnSV/tLEWW8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328569148; i=@elandsys.com; bh=XZ99OwVmZEwJyuE9+VzniCVmYBscA6rTdjkcR/f5vwo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=fVOBGx0NriHdWjJB80dS43ERRX80xk0ntAIdhtu0UpjB30XlDDiggSS1TkynYYvL/ cYWZotOVCa4TtlJGBauFItLid2BGsatwMMOoeF5ZPNmbhdkE4ETxjV2Ji61+gaDpMb RHe65eHAqN2Rhc3cginnCvGLqxnKFwg0ihQHhFvM= Message-Id: <6.2.5.6.2.20120206143951.07685df0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 06 Feb 2012 14:48:49 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <20120206195248.GS7609@mail.yitter.info> <6.2.5.6.2.20120206131514.06d91d30@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 22:59:14 -0000 At 02:32 PM 2/6/2012, Dotzero wrote: >This is why I am asking for a consensus or a call by the chairs that >the item (ii) Experimental evidence presented should be constrained by >item (i) Reviews of RFC 4408 and the fact that RFC 4408 is the focus >of this working group. There were in fact two concurrent experiments. >The charter of the group does not include RFC 4406 or RFC 4407. I'll discuss the matter with my WG co-chair. Regards, S. Moonesamy SPFBIS WG co-chair From john@jlc.net Mon Feb 6 15:11:13 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05ED011E8095 for ; Mon, 6 Feb 2012 15:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.323 X-Spam-Level: X-Spam-Status: No, score=-105.323 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_05=-1.11, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5qnXJnVEU1X for ; Mon, 6 Feb 2012 15:11:12 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 111A311E8075 for ; Mon, 6 Feb 2012 15:11:12 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3CEE233C21; Mon, 6 Feb 2012 18:11:12 -0500 (EST) Date: Mon, 6 Feb 2012 18:11:12 -0500 From: John Leslie To: SM Message-ID: <20120206231112.GG61963@verdi> References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> <6.2.5.6.2.20120206141650.096cd600@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120206141650.096cd600@resistor.net> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 23:11:13 -0000 SM wrote: > At 02:07 PM 2/6/2012, Murray S. Kucherawy wrote: > >> Thus, would it be beneficial to ask the current IESG what it thinks >> the experiment is or was, or what they'd like to see from us in >> terms of a resolution? Since they're the ones that get to decide, >> maybe they're the ones we should ask. > > I don't think you'll get the answer you are waiting for. :-) More exactly, it's doubtful he'd get _any_ timely answer. Any AD can add a Management Item for such a request. Depending on how full a particular IESG agenda is, it may or may not get discussion. Either way, they look for one AD to take an action item to draft a reply. In this case, that pretty much means Pete Resnick or Barry Leiba. I don't think either of them would volunteer. If some AD does volunteer, it's a seemingly random variable how long it will take. Sometimes it's only two weeks; two months is closer to the norm; both Barry and I have seen these items drag on longer. Once a reply _is_ drafted, there's _always_ some AD that thinks it needs changes. Lather, rinse, repeat. I suggest a different paradigm: assume the IESG would simply like to see the Sender-ID experiment wrapped up, and they don't really care all that much whether Sender-ID ever gets advanced to Proposed Standard. Thus, they're likely to be happy with any justification we give for declaring the Sender-ID experiment to be complete. Our problem lies elsewhere: if we annoy the pro-Sender-ID folks too much, they'll raise issues during LastCall of our document declaring Sender-ID to have finished experimental stage. This could slow things considerably. All we really need out of this is to declare the Sender-ID use of v=spf obsolete. To justify that, we need only prove that SPF use of v=spf greatly exceeds Sender-ID use of it. I suggest we concentrate on gathering such evidence. -- John Leslie From sm@resistor.net Mon Feb 6 15:27:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA20B11E8075 for ; Mon, 6 Feb 2012 15:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IgrbFRKfB0h for ; Mon, 6 Feb 2012 15:27: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 D680221F84C5 for ; Mon, 6 Feb 2012 15:27:37 -0800 (PST) Received: from sm-THINK.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 q16NRUUr004220; Mon, 6 Feb 2012 15:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328570857; i=@resistor.net; bh=TPGko8L8nrg3NBlJfmuLVe5zTqhPM2Q2VC7KzdGibI8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=YWFs4/0sJNrtdPVB19Y2ES5qKE3r79iEi57F1rP6KyPewuatRShchi+Nqx69z06Sn A7G6k3xy3az3S+VVQI312F9CLGf7tLVaxwGD52vQFzipUvq86YJLZJFsRYq06jyEqn fuvtqR9snt1iwcS7wD0SQ4/7XVA94CHeUXhlmj4Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1328570857; i=@resistor.net; bh=TPGko8L8nrg3NBlJfmuLVe5zTqhPM2Q2VC7KzdGibI8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=zWrxW4rPazdIdg9JodDktNfzEzwvsBYLA06c9ye+3s6Z3sj+H9OAfuZNNzXb52PK+ gWUhP9ApiLYB7U8VKkE1iucy8Qfj8OiV7AUy7B6s4drXwsSHw8GBQNoBgxDr2VLI5v 1s66TKvcfK+C7zFlmXwYz1l7oo+MPiLLl5y57big= Message-Id: <6.2.5.6.2.20120206151807.07694868@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 06 Feb 2012 15:27:17 -0800 To: John Leslie From: SM In-Reply-To: <20120206231112.GG61963@verdi> References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> <6.2.5.6.2.20120206141650.096cd600@resistor.net> <20120206231112.GG61963@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 23:27:39 -0000 Hi John, At 03:11 PM 2/6/2012, John Leslie wrote: > More exactly, it's doubtful he'd get _any_ timely answer. I hope that your answer answers Murray's question. As for the rest of your message, insert smiley. :-) Regards, -sm From msk@cloudmark.com Mon Feb 6 15:31:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB4B11E80B8 for ; Mon, 6 Feb 2012 15:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 FEyV0qikJYou for ; Mon, 6 Feb 2012 15:31:06 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id BE3A011E80B4 for ; Mon, 6 Feb 2012 15:31:06 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 15:31:06 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 6 Feb 2012 15:31:06 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 6 Feb 2012 15:31:05 -0800 Thread-Topic: [spfbis] "The question is wrong" thread Thread-Index: AczlJuxKZDa4T4SYSm2CpPpkIOU/0QAAEPkg Message-ID: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> <6.2.5.6.2.20120206141650.096cd600@resistor.net> <20120206231112.GG61963@verdi> <6.2.5.6.2.20120206151807.07694868@resistor.net> In-Reply-To: <6.2.5.6.2.20120206151807.07694868@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Feb 2012 23:31:07 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of SM > Sent: Monday, February 06, 2012 3:27 PM > To: John Leslie > Cc: spfbis@ietf.org > Subject: Re: [spfbis] "The question is wrong" thread >=20 > Hi John, > At 03:11 PM 2/6/2012, John Leslie wrote: > > More exactly, it's doubtful he'd get _any_ timely answer. >=20 > I hope that your answer answers Murray's question. It tells me that may not exactly be a timely path to get some direction abo= ut what will satisfy our deliverable, but apart from that, I still feel lik= e we're taking at best an educated guess about the question we're supposed = to answer. -MSK From sm@resistor.net Mon Feb 6 16:32:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F5711E80B3 for ; Mon, 6 Feb 2012 16:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM104D6hUuMu for ; Mon, 6 Feb 2012 16:32:16 -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 CEF7A11E80C7 for ; Mon, 6 Feb 2012 16:32:11 -0800 (PST) Received: from sm-THINK.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 q170W7AN025483 for ; Mon, 6 Feb 2012 16:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328574730; i=@resistor.net; bh=KRRucaBIt4iGXP8SmSPdfI3GU+7kMvu35EDCMruTbts=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=MBVer6d4/jpBTgIvPUyppKLAY/gZFDE5MydDY6uOvTEnQ4agfaulHjbIFE9Qj1D+G LjiDDX41epC0Rv91BSCkOxcsK5Bv7aY5wk70ybGfKY7hImvNujlwuyJes924dlpvHD SLT5ozQ1hRerOl9ykDS0mz9G0e7QazwUNddR19C8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1328574730; i=@resistor.net; bh=KRRucaBIt4iGXP8SmSPdfI3GU+7kMvu35EDCMruTbts=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Hw6funKP+mpaH2sk6Nj4z27MmjRbUgpUY0Al+jfI0j1j0ElV38y3cqcYOYM7uG2Cg k+p1FXYfIImiTRQ0nMO8hcdmGPOIEZlVLXOoCoXnVHhWufr0fTTpV7Dt74339B7WwD 4b148o1YNRogbpml9GmDE7b2HOOIem1jdPXnLaqc= Message-Id: <6.2.5.6.2.20120206160922.078e2ab0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 06 Feb 2012 16:31:56 -0800 To: spfbis@ietf.org From: SM In-Reply-To: References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> <6.2.5.6.2.20120206141650.096cd600@resistor.net> <20120206231112.GG61963@verdi> <6.2.5.6.2.20120206151807.07694868@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 00:32:16 -0000 Hi Murray, At 03:31 PM 2/6/2012, Murray S. Kucherawy wrote: >satisfy our deliverable, but apart from that, I still feel like >we're taking at best an educated guess about the question we're >supposed to answer. Yes. BTW, I understand your point. Give me some time to think about it. Regards, -sm From scott@kitterman.com Mon Feb 6 18:10:25 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940BE21F86D3 for ; Mon, 6 Feb 2012 18:10:24 -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 iklvkvcQBSCa for ; Mon, 6 Feb 2012 18:10:23 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BA68421F8642 for ; Mon, 6 Feb 2012 18:10:23 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A0F9020E414F; Mon, 6 Feb 2012 21:10:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328580622; bh=XaZ3vzkGw/Rg2fwQYfHegvQhJ7dZ6dk6xmYZeIW3m0I=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=CShtFWes5vZZ/33QgKNPFbIljsNdBEcjq4XyGUNB6bxRb1TMlaonlnrBTXxGmtNbk VH1ejaiv3W7+GPCVJr7YxYn9d7BblFnLZtUO9UHnUC0gTjKszMOmxiWmYXtl2u98wP wfDwGru4E5j7xx1Gc66lO2w6tR+GC3n0DxS8nobo= Received: from scott-latitude-e6320.localnet (unknown [12.130.117.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4F14520E408E; Mon, 6 Feb 2012 21:10:22 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 06 Feb 2012 21:10:18 -0500 Message-ID: <2146275.WoS1xon1ug@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Mon, 06 Feb 2012 18:13:58 -0800 Subject: [spfbis] Issue: Downcase result names in spec text and ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 02:10:25 -0000 Having result names all lower case is all the rage these days, so we should probably downcase our result names. This doesn't affect interoperability since the names are already case insensitive in the ABNF. It's just a cosmetic update. Scott K From spf2@kitterman.com Mon Feb 6 18:24:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CD221F8726 for ; Mon, 6 Feb 2012 18:24:36 -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 n9x6DpX0ZEaN for ; Mon, 6 Feb 2012 18:24:36 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E606C21F871C for ; Mon, 6 Feb 2012 18:24:28 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7ED4020E414F; Mon, 6 Feb 2012 21:24:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328581468; bh=XaZ3vzkGw/Rg2fwQYfHegvQhJ7dZ6dk6xmYZeIW3m0I=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=XkbTw/ZKbLhN+x7eD0wOeBg8pRP2p2GPEGavbSbOrGPmrMEfxaFfq3YU+OvpWj2c4 J3oBuJN7erAs2GaeR0n4CVX8YCdlFRe8GPY9+5kSQZj5qiEFmvk7/5kiiPc2qCKvXm VtQcEN73m2cPtxU/a+xE/bIaSbirapdBW1je4ARA= Received: from scott-latitude-e6320.localnet (unknown [12.130.117.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 351AE20E408E; Mon, 6 Feb 2012 21:24:28 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 06 Feb 2012 21:24:18 -0500 Message-ID: <5882083.HJsRpRN8Su@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Issue: Downcase result names in spec text and ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 02:24:36 -0000 Having result names all lower case is all the rage these days, so we should probably downcase our result names. This doesn't affect interoperability since the names are already case insensitive in the ABNF. It's just a cosmetic update. Scott K From msk@cloudmark.com Mon Feb 6 19:13:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E658D11E80BB for ; Mon, 6 Feb 2012 19:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RtiURlzxQaW for ; Mon, 6 Feb 2012 19:13:46 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7266611E80C9 for ; Mon, 6 Feb 2012 19:13:22 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 19:13:21 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 6 Feb 2012 19:13:22 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 6 Feb 2012 19:13:27 -0800 Thread-Topic: [spfbis] Issue: Downcase result names in spec text and ABNF Thread-Index: AczlP6ejOi/pKCNARymFaOKQuU6PwgABr7zg Message-ID: References: <5882083.HJsRpRN8Su@scott-latitude-e6320> In-Reply-To: <5882083.HJsRpRN8Su@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Issue: Downcase result names in spec text and ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 03:13:47 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Monday, February 06, 2012 6:24 PM > To: spfbis@ietf.org > Subject: [spfbis] Issue: Downcase result names in spec text and ABNF >=20 > Having result names all lower case is all the rage these days, so we > should probably downcase our result names. This doesn't affect > interoperability since the names are already case insensitive in the > ABNF. It's just a cosmetic update. I agree, and that would make SPFbis and RFC5451 line up nicely. From dhc2@dcrocker.net Mon Feb 6 19:22:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912EA21F8573 for ; Mon, 6 Feb 2012 19:22:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtnvdZ9lEA7Z for ; Mon, 6 Feb 2012 19:22:55 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id ED71021F8570 for ; Mon, 6 Feb 2012 19:22:55 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q173MmH5015922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2012 19:22:53 -0800 Message-ID: <4F309906.1080407@dcrocker.net> Date: Mon, 06 Feb 2012 19:22:46 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Andrew Sullivan References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> In-Reply-To: <20120206202244.GA8370@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 06 Feb 2012 19:22:54 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 03:22:56 -0000 On 2/6/2012 12:22 PM, Andrew Sullivan wrote: > On Mon, Feb 06, 2012 at 11:58:11AM -0800, Dave CROCKER wrote: >> >> I originally posted some suggested questions for us to answer. You >> and others have posted additional questions. All look interesting, >> but we probably should prune the set to a few basic issues that >> could help with strategic choices. > > I'm clearly having a bad chair day, because I'm having a devil of a > time getting this point across. There was a TV station in Chicago, many years ago, that would post a sign on the screen when it was having technical difficulties. It showed a carton figure of a guy on a balcony, looking and pointing "away". The caption read "It's not you. It's not us. It's THEM!". Which is to say that, I think you're doing fine. You've pressed for resolution of an important point. It just happens to be one that is difficult, IMO. I think the underlying problem here is our having to answer questions without our being told what they are. Hence, we need to find out > While I agree that it would be > considerably easier to prune the questions we think we're trying to > answer, I believe that we might face hard questions later if we > exclude some classes of evidence from consideration or if we decide > too early to rule some question out of consideration. And indeed, that ought to inform our pruning process. But I suspect we can't do that without getting some interim review from the IESG. My suggestion is that we try to formulate the questions that we think make sense to answer and then cycle them to the IESG for comment, before actually formulating answers. s/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Mon Feb 6 20:21:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CAE11E80DC for ; Mon, 6 Feb 2012 20:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.464, 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 XemuJ2GI9Prz for ; Mon, 6 Feb 2012 20:21:15 -0800 (PST) Received: from news.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD2411E8086 for ; Mon, 6 Feb 2012 20:21:15 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=921; t=1328588471; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=3E9YCWRLVte3lb82dhai48AQo5k=; b=IDBPbAYp9SiHDiDdhGE2 wNZNX2HdkjhK7KxNZf6NbN0C6H9RQk+pLTkzk7KX5dqbvoQSRbL9AqBOR1S0mKPj AFpFQrjrq3SurBHjLkP2g9a/M36+I4KnaBTfacBM5Gd/6p0k9GW3LC6FpbzNdO2y GoA4XhDtOgIr5oGRbv5clLc= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 06 Feb 2012 23:21:11 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1790331437.67513.2368; Mon, 06 Feb 2012 23:21:10 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=921; t=1328588254; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=vbme8SD N+1FR3hqv1Z/TWUD4bd7H/XQseh5OdaQJ5xw=; b=YgxtUhHwXfRxYvnjyWjPSiP QCmeuc+7eR074AfPABtMy66XQ8GGOkC2CoQMUFPm+Hnjiw3ykdkkgBAKzMf2Zph5 i8GVV+Db/e36By7gw/EwOjeARCLJkYTV+MchREBDVWdiGn7E6tHE+4mFH2HYtzp4 wGMmza3BjjKQHvuvPTXc= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 06 Feb 2012 23:17:34 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2389277439.12013.6880; Mon, 06 Feb 2012 23:17:34 -0500 Message-ID: <4F30A6A9.1000104@isdg.net> Date: Mon, 06 Feb 2012 23:20:57 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <5882083.HJsRpRN8Su@scott-latitude-e6320> In-Reply-To: <5882083.HJsRpRN8Su@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Issue: Downcase result names in spec text and ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 04:21:16 -0000 Scott Kitterman wrote: > Having result names all lower case is all the rage these days, so we should > probably downcase our result names. This doesn't affect interoperability since > the names are already case insensitive in the ABNF. It's just a cosmetic > update. > So what are you are suggesting is "follow" what we wrote because I think its "prettier?" or maybe its bothering my "eyes" or its the "unix wienie" way? Generally, there are strong ergonomics design principles between designers and thinks like "results" are highlighted, and since you can't make describe as BOLD or ITALIC or UNDERLINE or colorize it in the spec, one good way is to UPPERCASE it. So perhaps what is better is to write up something that suggest result names are designed to be highlighted in some form. -1, keep it uppercase. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Mon Feb 6 20:35:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E2D11E80E0 for ; Mon, 6 Feb 2012 20:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.456, 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 G-TebjJho9q2 for ; Mon, 6 Feb 2012 20:35:47 -0800 (PST) Received: from news.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BCEE111E80DC for ; Mon, 6 Feb 2012 20:35:46 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1352; t=1328589337; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=mwDlYTsVjXWhDYOzcEZFcJap4uc=; b=T5ENce8KNKm/r+/Yz4gQ TR0Jiz+G2poHomx0rHLA18jYUVETfQv3Qy9SG4S/+Cgxp5YDlnaqBxgKK0xdFxor bOYwxViJfKNPcSOzMODcXODdlKGB4SSgEDYj5e/oP3kqz8xgrPUDP1Bd56J2za27 iC8J2SeGidkdKeiivjtb5/o= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 06 Feb 2012 23:35:37 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1791196665.67513.2148; Mon, 06 Feb 2012 23:35:36 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1352; t=1328589121; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=F6t9g3V T3njrWXyjaM/Z6XhLIyH0nHXDU5ObUaOLq2s=; b=hyETxiTpOjHdE0RQHVaUX1E 1rVVyiJC2mad9LaOOt0jNcOLRkNsQHAQmJ+tGZ9E4IIjjyiaMLHVeTBLbomoCpnL YLWcUGpDgk9O9To3+bZc3JH9WZHpBgGu5FxuRD5Pt7Zceh/AQ8LuMK4hACht3UV9 KVrWtXBSb+wm61oY536w= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 06 Feb 2012 23:32:01 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2390144470.12014.5272; Mon, 06 Feb 2012 23:32:01 -0500 Message-ID: <4F30AA0C.7010701@isdg.net> Date: Mon, 06 Feb 2012 23:35:24 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <1789090.uGqYcqLmHb@scott-latitude-e6320> In-Reply-To: <1789090.uGqYcqLmHb@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Issue: Processing limits needs clarification and reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 04:35:48 -0000 Scott Kitterman wrote: > As I understand it, security considerations aren't generally supposed to give > normative protocol implementations constraints, but the processing limits in > paragraph 10.1 of RFC 4408 does exactly this. > > While the technical limits themselves are appropriate, paragraph 10.1 should > be split into two parts. The actual processing limits should find a home in > the main body of the specification and then a revised security consideration > should focus on a clearer discussion about why they are important and why one > should design records the minimize DNS impact. Sounds like material for a BCP. There is also the difference between security concerns and optimization concerns. However, if anything, there is a generalize guideline for DNS operators to define optimal SPF records where the intent is minimize any overhead. For example, a classic example is one like gmail.com which is currently prepared for at least two (2) lookups since the first query result is an instruction to perform a redirect: v=spf1 redirect=_spf.google.com With the volume of inbound gmail.com out there, can you imagine the immediate 1/2 reduction of DNS query overhead if the gmail folks changed it to a direct/single call? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From msk@cloudmark.com Mon Feb 6 22:05:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C3821F877C for ; Mon, 6 Feb 2012 22:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raQzQG3IBUiB for ; Mon, 6 Feb 2012 22:05:27 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 66FE921F877A for ; Mon, 6 Feb 2012 22:05:27 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 22:05:26 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 6 Feb 2012 22:05:26 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 6 Feb 2012 22:05:33 -0800 Thread-Topic: Issue: Mixed use of RFC2119 words Thread-Index: AczlXoC5LkGqa8FQTt+1Y553rOkT0Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C9A7DC2EEXCHC2corpclo_" MIME-Version: 1.0 Subject: [spfbis] Issue: Mixed use of RFC2119 words X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 06:05:28 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC2EEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In scanning RFC4408, I see a number of places where "may" is used, but in a= ll-lowercase, presumably to avoid invoking its RFC2119 meaning. We have ot= her words like "can", "might", "could" that do a better job of avoiding amb= iguity. I suggest this be revisited in production of the -bis version. --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC2EEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In scanning RFC4= 408, I see a number of places where “may” is used, but in all-l= owercase, presumably to avoid invoking its RFC2119 meaning.  We have o= ther words like “can”, “might”, “could”= that do a better job of avoiding ambiguity.  I suggest this be revisi= ted in production of the –bis version.

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC2EEXCHC2corpclo_-- From msk@cloudmark.com Mon Feb 6 22:10:09 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B09E21F879B for ; Mon, 6 Feb 2012 22:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uC4clRcbuHqR for ; Mon, 6 Feb 2012 22:10:08 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5084521F86A0 for ; Mon, 6 Feb 2012 22:10:08 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 22:10:07 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 6 Feb 2012 22:10:07 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 6 Feb 2012 22:10:14 -0800 Thread-Topic: Issue: Editorial pass through references Thread-Index: AczlXyhJLvF5eK69RZuh9LIfW0A67w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C9A7DC2FEXCHC2corpclo_" MIME-Version: 1.0 Subject: [spfbis] Issue: Editorial pass through references X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 06:10:09 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC2FEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We need to update RFC2821 to RFC5321, etc. --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC2FEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We need to updat= e RFC2821 to RFC5321, etc.

 

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC2FEXCHC2corpclo_-- From msk@cloudmark.com Mon Feb 6 22:11:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF95F21F879B for ; Mon, 6 Feb 2012 22:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCiafJfq-BE1 for ; Mon, 6 Feb 2012 22:11:27 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 553FF21F879A for ; Mon, 6 Feb 2012 22:11:27 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 22:11:26 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 6 Feb 2012 22:11:26 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 6 Feb 2012 22:11:33 -0800 Thread-Topic: Issue: Consider changing some definitions to reference RFC5598 Thread-Index: AczlX1d/nSxnKJ3TQ2CIbyegHUK9SQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C9A7DC30EXCHC2corpclo_" MIME-Version: 1.0 Subject: [spfbis] Issue: Consider changing some definitions to reference RFC5598 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 06:11:28 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC30EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In particular, the second paragraph of Section 1.2 can probably be simplifi= ed somewhat by such a reference, and thereafter simply referring to those f= ields of interest as RFC5321.MailFrom or RFC5321.Helo. --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC30EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In particular, t= he second paragraph of Section 1.2 can probably be simplified somewhat by s= uch a reference, and thereafter simply referring to those fields of interes= t as RFC5321.MailFrom or RFC5321.Helo.

<= o:p> 

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC30EXCHC2corpclo_-- From msk@cloudmark.com Mon Feb 6 22:19:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D6921F876E for ; Mon, 6 Feb 2012 22:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ww5CATjqZ06Q for ; Mon, 6 Feb 2012 22:19:34 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 47C4921F872E for ; Mon, 6 Feb 2012 22:19:34 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 22:19:33 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 6 Feb 2012 22:19:33 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 6 Feb 2012 22:19:40 -0800 Thread-Topic: Issue: SPF RR type Thread-Index: AczlYHmpYw2dd5LRRvOqsXb6HNNzdA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C9A7DC31EXCHC2corpclo_" MIME-Version: 1.0 Subject: [spfbis] Issue: SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 06:19:35 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC31EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This may be a can of worms, but since we're chartered to tidy up where app= ropriate, I wonder if this might be such a spot. RFC4408 registered a new DNS RRtype, SPF, code 99. Are we able to tell how much deployment it's received? If only little (whi= ch is what I suspect, but I've no data to back that up), would it be approp= riate to relegate its discussion to an appendix and call it "historic"? --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC31EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This may be a ca= n of worms,  but since we’re chartered to tidy up where appropri= ate, I wonder if this might be such a spot.


RFC4408 registered a new DNS RRtype, SPF, code 99.

 

Are we able to= tell how much deployment it’s received?  If only little (which = is what I suspect, but I’ve no data to back that up), would it be app= ropriate to relegate its discussion to an appendix and call it “histo= ric”?

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC31EXCHC2corpclo_-- From msk@cloudmark.com Mon Feb 6 22:24:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C39821F87AF for ; Mon, 6 Feb 2012 22:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6uKTxdGrcDM for ; Mon, 6 Feb 2012 22:24:49 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id BA2CC21F87A9 for ; Mon, 6 Feb 2012 22:24:49 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 22:24:46 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 6 Feb 2012 22:24:46 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 6 Feb 2012 22:24:53 -0800 Thread-Topic: Issue: Replace Received-SPF with RFC5451? Thread-Index: AczlYTPT53XWpyeRSWeRiJdFyb4ScA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C9A7DC32EXCHC2corpclo_" MIME-Version: 1.0 Subject: [spfbis] Issue: Replace Received-SPF with RFC5451? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 06:24:51 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC32EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We should consider striking Section 7 and replacing it with a reference to = RFC5451 with some reasonable but brief associated text. --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC32EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We should consid= er striking Section 7 and replacing it with a reference to RFC5451 with som= e reasonable but brief associated text.

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC32EXCHC2corpclo_-- From presnick@qualcomm.com Mon Feb 6 23:00:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD3711E80B7 for ; Mon, 6 Feb 2012 23:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.266 X-Spam-Level: X-Spam-Status: No, score=-106.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ybc8Q0n3gc8J for ; Mon, 6 Feb 2012 23:00:26 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id DAD4111E80AF for ; Mon, 6 Feb 2012 23:00:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1328598025; x=1360134025; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F30CC06.4080301@qualcomm.com>|Date:=20Tu e,=207=20Feb=202012=2001:00:22=20-0600|From:=20Pete=20Res nick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20John=20Leslie=20 |CC:=20SM=20,=20 |Subject:=20Re:=20[spfbis]=20"The=20question=20is=20wrong "=20thread|References:=20<20120203215158.GQ4322@mail.yitt er.info>=09<40255162.ysvdAIjBC2@scott-latitude-e6320>=09< 20120203235617.GA4322@crankycanuck.ca>=09 =09<4F301C8B.70107@dcrocker.net>=09<20120206183924.GN7609 @mail.yitter.info>=09<4F3030D3.9090900@dcrocker.net>=09<2 0120206202244.GA8370@mail.yitter.info>=09 =09<6.2.5.6.2.20120206141650.096cd600@resistor.net>=20<20 120206231112.GG61963@verdi>|In-Reply-To:=20<2012020623111 2.GG61963@verdi>|Content-Type:=20text/plain=3B=20charset =3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.39.5]; bh=ktDm4/b4+oo7gsU2egR1T2IbGrNFuO4K7Hmym4L+Rfk=; b=fkVcrd//423UQvdQqlbmkECEhjNaRcSRMXNIrv+raZKSPPCuR476Kzo9 Rpv8gQPejWmXFAe1reN1Pk/XeiGcUkMWEt8LcCgLhZQhqKrwwBXTcfWGW OfRuCqIp9dBxePCGP9ZHoB0gBEdELNaEW91Ak1o+9hvEqYsuWc356HSV4 Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6612"; a="161091776" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 06 Feb 2012 23:00:24 -0800 X-IronPort-AV: E=Sophos;i="4.73,374,1325491200"; d="scan'208";a="193614372" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 06 Feb 2012 23:00:24 -0800 Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 6 Feb 2012 23:00:23 -0800 Message-ID: <4F30CC06.4080301@qualcomm.com> Date: Tue, 7 Feb 2012 01:00:22 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: John Leslie References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> <6.2.5.6.2.20120206141650.096cd600@resistor.net> <20120206231112.GG61963@verdi> In-Reply-To: <20120206231112.GG61963@verdi> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org, SM Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 07:00:26 -0000 With AD hat on. Let me put a slightly happier spin on John's message, which I think is essentially correct. On 2/6/12 5:11 PM, John Leslie wrote: > SM wrote: > >> At 02:07 PM 2/6/2012, Murray S. Kucherawy wrote: >> >> >>> Thus, would it be beneficial to ask the current IESG what it thinks >>> the experiment is or was, or what they'd like to see from us in >>> terms of a resolution? Since they're the ones that get to decide, >>> maybe they're the ones we should ask. >>> >> I don't think you'll get the answer you are waiting for. :-) >> > More exactly, it's doubtful he'd get _any_ timely answer. > > Any AD can add a Management Item for such a request. Depending on > how full a particular IESG agenda is, it may or may not get discussion. > Either way, they look for one AD to take an action item to draft a > reply. In this case, that pretty much means Pete Resnick or Barry > Leiba. I don't think either of them would volunteer. > So, let me say up front that I would immediately volunteer for this if asked. However, I don't think it's necessary. > If some AD does volunteer, it's a seemingly random variable how > long it will take. Sometimes it's only two weeks; two months is > closer to the norm; both Barry and I have seen these items drag on > longer. Once a reply _is_ drafted, there's _always_ some AD that > thinks it needs changes. > > Lather, rinse, repeat. > I think if you ask for a *formal* answer, something like the above is likely to happen. Or worse, they'll say, "Pete, you obviously didn't scope the charter well enough. Go back to the group and recharter that section." If simply asked the question without pomp and circumstance, I think it slightly more likely that the IESG will come to me (probably not Barry; we spare the new guys crap until they ask for it ;-) ) and say, "We said what we wanted in the charter. It's your WG to manage; go give them an answer." But really, the fact of the matter is that if you all come up with an interpretation of this sentence: The working group will produce a document describing the course of the SPF/Sender-ID experiment, thus bringing that experiment to a formal conclusion. and that interpretation sounds reasonable to me (which we can determine now), when it comes time for Last Call/IESG Evaluation, I will make it quite clear to the IESG that the WG has fulfilled it's charter obligation. Yes, we can wring our hands about some AD coming out of the woodwork and disagreeing, but (a) I think the likelihood of that is exceedingly low, and (b) if we're going to worry about that, I can provide a much longer list to worry about too. The fact is that the IESG thought the above sentence was sufficient to explain the deliverable. If we come up with a reasonable interpretation of that deliverable, we'll be fine and I will defend it to the hilt. > I suggest a different paradigm: assume the IESG would simply like > to see the Sender-ID experiment wrapped up, and they don't really > care all that much whether Sender-ID ever gets advanced to Proposed > Standard. > I think that's pretty much true, adding only, "the IESG would simply like to see the SPF *and* Sender-ID experiments wrapped up, and presumes that the charter is correct and the outcome of the experiment leads one to conclude that SPF should get advanced to Proposed Standard and Sender-ID should not". > Thus, they're likely to be happy with any justification we give > for declaring the Sender-ID experiment to be complete. Sure, with the caveat that the shepherd and/or I will be doing a document writeup, and (like the rest of the WG and the chairs, I hope) we will want to be able to document that the WG did its due diligence to come up with a justification for the conclusion of the experiment. > Our problem > lies elsewhere: if we annoy the pro-Sender-ID folks too much, they'll > raise issues during LastCall of our document declaring Sender-ID to > have finished experimental stage. This could slow things considerably. > Similarly, due diligence should address the above as well. > All we really need out of this is to declare the Sender-ID use > of v=spf obsolete. To justify that, we need only prove that SPF use > of v=spf greatly exceeds Sender-ID use of it. > > I suggest we concentrate on gathering such evidence. > This is why I like Andrew and SM's approach to this question: The WG was chartered on the assumption (see 1, 2, and 3 in the charter) that there exists community consensus that SPF has been more successfully deployed than Sender-ID and that therefore SPF should move forward and that no further work need be done on Sender-ID. The first order of business is to document that SPF *was* more successfully deployed than Sender-ID (by enumerating the amount of deployment of each and the "relative effectiveness" of each), and that's what I take Andrew to mean by providing "experimental evidence". It would be exceedingly amusing were we to discover that there is *more* deployment of Sender-ID or that it has *more* relative effectiveness. We might decide to re-charter in that horrifyingly unlikely event. :-) Assuming none of these very low likelihood events occurs, gathering data on how much and how effectively (relative to each other) SPF and Sender-ID got deployed seems like the right thing to be doing. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From sm@elandsys.com Tue Feb 7 03:32:24 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F56921F859A for ; Tue, 7 Feb 2012 03:32:24 -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 91jZeN6TFbwf for ; Tue, 7 Feb 2012 03:32:22 -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 6C97C21F846E for ; Tue, 7 Feb 2012 03:32:22 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q17BWAoa001178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2012 03:32:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328614339; i=@elandsys.com; bh=WRnQ+XIBSDWLRGM6Joj5n7h9gtoEO/X160Rkr8iIPGQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=PR3D2E6JzH9nUcfrXhRKNdjMbLOoJ49tDe9vVAD73ph+Edtk534FKvJd09eOXtREb RXUFxn/LscRP6SwRVfAAKZFm6PkDKzNT/At7HKquerEMcqXwuZsZSRKCma0XlhEa5D 580F/uowlIiaTCQVb8Ur3JS1KpA/B0Y13cVjqmJE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328614339; i=@elandsys.com; bh=WRnQ+XIBSDWLRGM6Joj5n7h9gtoEO/X160Rkr8iIPGQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=3D0fX7gUzm6wzKXfEd/kouAAIiCKePR39lJak8aToiI0PAiTetqTZSCcbsTPi89a4 6u0Y0O7JPQqjLI6IJj2nmGVOCf3G41HvlxiYO19iCzUmKDPOd9rng79dH3cp0uG0/8 oHdJR1C9bHrPNjIPOwy2kgoeceKuOjGgS6fyodtM= Message-Id: <6.2.5.6.2.20120207030843.08dd2408@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Feb 2012 03:21:35 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <5882083.HJsRpRN8Su@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] Issue: Downcase result names in spec text and ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 11:32:24 -0000 At 07:13 PM 2/6/2012, Murray S. Kucherawy wrote: >I agree, and that would make SPFbis and RFC5451 line up nicely. I don't see anything wrong with the above comment. I would like to remind this working group that the WG Chairs have asked for reviews of RFC 4408. Discussions or comments about the issues should be deferred for now. The WG Chair will solicit comments about each issue in a couple of weeks. Please be patient. Regards, S. Moonesamy SPFBIS WG co-chair From sm@elandsys.com Tue Feb 7 03:32:24 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A035421F846E for ; Tue, 7 Feb 2012 03:32:24 -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=[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 rzyH2C1kUyBP for ; Tue, 7 Feb 2012 03:32:22 -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 B69E521F8471 for ; Tue, 7 Feb 2012 03:32:22 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q17BWAoc001178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Feb 2012 03:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328614342; i=@elandsys.com; bh=AOEfBf/6vQ4+tGnwYCfRl0fMuJwc/EZa+EA4gonTy3c=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=0ATz/upQN24wYqRAHgoLobHd2lHXWpECvqbywFbUaUTcKVlffOHwEyuMKcwEQZm81 rUDLfivwujwKo+Mnsqy+h1uh6/uoFwR/5tk0tmAzfxi+2vZcbseiBFTGQ7yqnVuDan 9JcqDWyPbt5o4QCnaU2AXPkWkUGpE/uSr9magFvs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328614342; i=@elandsys.com; bh=AOEfBf/6vQ4+tGnwYCfRl0fMuJwc/EZa+EA4gonTy3c=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=l3+ylGFjyz0jEyNY+cGyZN1b9yfwxEeRKSQUC9ftmsoie4CPBCVvrF89rREEchuu0 A0LK29p8bvFdtfOTr/iu9dn1i7A3wgyF+OD2lCG9R02U62WI1SZ48r2LtwVuMKVu4G iNu6GICP8hCYmc7D0kevc+nByp157R5x9Kt6MWxg= Message-Id: <6.2.5.6.2.20120207032207.08dd2178@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Feb 2012 03:28:22 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4F30AA0C.7010701@isdg.net> References: <1789090.uGqYcqLmHb@scott-latitude-e6320> <4F30AA0C.7010701@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Issue: Processing limits needs clarification and reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 11:32:24 -0000 At 08:35 PM 2/6/2012, Hector Santos wrote: >Sounds like material for a BCP. There is also the difference >between security concerns and optimization concerns. I'll say it again. I don't see anything wrong about the comment. Please do not comment on issues. There will be ample opportunity for comments in a couple of weeks. Regards, S. Moonesamy SPFBIS WG co-chair From hsantos@isdg.net Tue Feb 7 07:00:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D590C21F880E for ; Tue, 7 Feb 2012 07:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DT9WLyUfRbS for ; Tue, 7 Feb 2012 07:00:46 -0800 (PST) Received: from pop3.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8263421F8809 for ; Tue, 7 Feb 2012 07:00:45 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=652; t=1328626843; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=9L8pj7gHWrWNprXQwOH1ojhuLlo=; b=DcD/Z2RPLD1UhEXV3Qt/ r1KAYpjAnhWnjAMQOJ98h+S6ILc2aQWbeJD5XGhHkhqIJFVnLEW5dwhfHGuGY50I AdUf8qItZzFwgxz31+0qGVG3iAS3PBaf5GRh/R4QhVZttZFgiFkW7r72d2hbcGvR E/hIIk2Nne7MF2edTBod4ds= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 07 Feb 2012 10:00:43 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1828702020.68227.3484; Tue, 07 Feb 2012 10:00:41 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=652; t=1328626627; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=v/mYqsm wCS5ppK8xEdrAxThqavMFoKQmsiuxIvkuLtA=; b=d3jqxEMY/jQSMWSAoOeZlq1 6LZPuyk24l/KxuiJ11U2kNMChGitJPaC1WYpkslJrpHGp1ey08cv/Q7qFl7aQi1K 8Kz73xduPf7oHN3S4y9kRRelUCSYVmmI1caK8BqQyGJXkboJSmF9b41vTkSw7+fV vh7SjiuLZkBc+BuYGvXo= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 07 Feb 2012 09:57:07 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2427649642.12076.7916; Tue, 07 Feb 2012 09:57:06 -0500 Message-ID: <4F313CA5.9090708@isdg.net> Date: Tue, 07 Feb 2012 10:00:53 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <1789090.uGqYcqLmHb@scott-latitude-e6320> <4F30AA0C.7010701@isdg.net> <6.2.5.6.2.20120207032207.08dd2178@resistor.net> In-Reply-To: <6.2.5.6.2.20120207032207.08dd2178@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Issue: Processing limits needs clarification and reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 15:00:47 -0000 S Moonesamy wrote: > At 08:35 PM 2/6/2012, Hector Santos wrote: >> Sounds like material for a BCP. There is also the difference between >> security concerns and optimization concerns. > > I'll say it again. I don't see anything wrong about the comment. > > Please do not comment on issues. There will be ample opportunity for > comments in a couple of weeks. Not quite following. Including with your previous similar post, you seem to be providing the idea (all) posted "Issue" comments are being cataloged and will posted again later (by you) for RFC? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From dhc2@dcrocker.net Tue Feb 7 08:03:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5274821F8851 for ; Tue, 7 Feb 2012 08:03:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crmn51H4-nbT for ; Tue, 7 Feb 2012 08:03:54 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id AFB2121F8627 for ; Tue, 7 Feb 2012 08:03:54 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q17G3hhF001575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2012 08:03:49 -0800 Message-ID: <4F314B5D.5000204@dcrocker.net> Date: Tue, 07 Feb 2012 08:03:41 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 07 Feb 2012 08:03:49 -0800 (PST) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Issue: Mixed use of RFC2119 words X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:03:55 -0000 On 2/6/2012 10:05 PM, Murray S. Kucherawy wrote: > In scanning RFC4408, I see a number of places where “may” is used, but in > all-lowercase, presumably to avoid invoking its RFC2119 meaning. We have other > words like “can”, “might”, “could” that do a better job of avoiding ambiguity. I > suggest this be revisited in production of the –bis version. In case folks missed this, this is a general RFC-style issue that finally prompted a draft set of suggestions: d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Tue Feb 7 08:07:09 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB4421F885F for ; Tue, 7 Feb 2012 08:07:09 -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=[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 AfGryin46MTJ for ; Tue, 7 Feb 2012 08:07:07 -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 3B98F21F8852 for ; Tue, 7 Feb 2012 08:07:07 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q17G6wgK002567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2012 08:07:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328630824; i=@elandsys.com; bh=GyNyp2d8yVqI0B7MUln76XQeuI95uTyilxIQliUbJD8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=KWM2tRzz8gEyCtFv2MVPszhj2Gdy4j51kCqwq3KjshDn0W6kxsL724UR4lF20kytZ Rb+2DHkjemANm9ivwo2XC9Nc0o+394tNYpQwWQygUztDRdF+zFdGSTouzL53EYWLNh XNqAeEC4lrAnplBLVPPnWY61/L9YpPAwzfxAJ0Uk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328630824; i=@elandsys.com; bh=GyNyp2d8yVqI0B7MUln76XQeuI95uTyilxIQliUbJD8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=MEl2MpyWEeUM6DjMcwvnJZjKv0XGWgI8G931s99ETG9AvabV8tJZkHEAuCJpTGghq ixMgw5Wju/gtMQ/Zs5IVMsOys98W8RQXr35F0kOTa0gy+Ik/vpquDj0X+gq/qqhAjM LPl0m4yxWtygcPN8zZHkPYilxEHvW7t2TYrM0qUo= Message-Id: <6.2.5.6.2.20120207070336.08bc6990@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Feb 2012 08:05:37 -0800 To: Hector Santos From: S Moonesamy In-Reply-To: <4F313CA5.9090708@isdg.net> References: <1789090.uGqYcqLmHb@scott-latitude-e6320> <4F30AA0C.7010701@isdg.net> <6.2.5.6.2.20120207032207.08dd2178@resistor.net> <4F313CA5.9090708@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] Issue: Processing limits needs clarification and reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:07:09 -0000 Hi Hector, At 07:00 AM 2/7/2012, Hector Santos wrote: >Not quite following. Including with your previous similar post, you >seem to be providing the idea (all) posted "Issue" comments are >being cataloged and will posted again later (by you) for RFC? The WG Chairs asked for reviews of RFC 4408. The issues identified in the reviews will be listed in the issue tracker. We will then request the working group to comment on each issue. Please note that the WG Chairs have not made any determination about whether an issue is valid or not valid or what is in scope. If you have any questions above the above, feel free to send them to the list or to the WG co-chairs. Regards, S. Moonesamy SPFBIS WG co-chair From ajs@anvilwalrusden.com Tue Feb 7 08:19:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE27A21F8848 for ; Tue, 7 Feb 2012 08:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 GhuTyy+toyhG for ; Tue, 7 Feb 2012 08:19:18 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 482BF21F8844 for ; Tue, 7 Feb 2012 08:19:18 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 465441ECB41D for ; Tue, 7 Feb 2012 16:19:17 +0000 (UTC) Date: Tue, 7 Feb 2012 11:19:15 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120207161915.GG9478@mail.yitter.info> References: <1789090.uGqYcqLmHb@scott-latitude-e6320> <4F30AA0C.7010701@isdg.net> <6.2.5.6.2.20120207032207.08dd2178@resistor.net> <4F313CA5.9090708@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F313CA5.9090708@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Issue: Processing limits needs clarification and reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:19:18 -0000 On Tue, Feb 07, 2012 at 10:00:53AM -0500, Hector Santos wrote: > Not quite following. Including with your previous similar post, you > seem to be providing the idea (all) posted "Issue" comments are > being cataloged and will posted again later (by you) for RFC? Yes. We're treating the "Issue" comments as part of the reviews I asked for last Friday. When I posted that, I explicitly asked that people not debate or discuss the reviews, but simply post their own reviews. SM and I will collate things into issues in the WG's issue tracker, once that's up. We're trying to break down the effort here into minimal steps, and avoid going over the same ground repeatedly in the WG. We thought a good way to do this would be to get all the issues identified, and then we could put together the full list of issues to be tackled by the WG. By isolating issues this way, we can concentrate our attention on one or two controversies at a time, instead of trying to argue about everything at once. The goal is to make progress on our nicely (and strictly) limited charter. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From hsantos@isdg.net Tue Feb 7 08:29:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EB321F8818 for ; Tue, 7 Feb 2012 08:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.447, 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 75oUg8wn5h5o for ; Tue, 7 Feb 2012 08:29:54 -0800 (PST) Received: from ntbbs.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E65B621F8813 for ; Tue, 7 Feb 2012 08:29:53 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1557; t=1328632188; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=1AvwRT4omRm978As3TOaYCOcqnI=; b=SUtrUXOrNBnZsLU+q9Gr Q1MYITKOfNhZ0RRjsQBjtpEgpxZ8m2Q8ISP67P6NqqwDG0KPuzdHgnEJSmbN6vzu f+88b101wvHpn1Y4nz8S0Oz1u1sm/61fVwy7TA5C0+lNtatGpxwht4NvH/tevXaL 45mf8coBU/v3opBYeOj/G68= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 07 Feb 2012 11:29:48 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1834047301.68227.3328; Tue, 07 Feb 2012 11:29:47 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1557; t=1328631972; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=GteYeFu /ysx5M/HeRnJWQTf4S4ZChM1meuNg6amSl3Y=; b=b27z+UKL6Mr2Z4Co+lOVAuP 3taU+x+puPoiKRddaS6ma7IxdP9G65HnPB2nse4uA9cI3PqFmRwZvEf/px0uK6Bv kStRxJ76oWg3YpXNHE0MidFs/1ncAmcQzWTk/0509NaO8L/0oaVgkuwNFTf8vdi9 eSIDaLpTGRCHeOULvafo= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 07 Feb 2012 11:26:12 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2432995204.12085.7924; Tue, 07 Feb 2012 11:26:11 -0500 Message-ID: <4F315185.5080602@isdg.net> Date: Tue, 07 Feb 2012 11:29:57 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <1789090.uGqYcqLmHb@scott-latitude-e6320> <4F30AA0C.7010701@isdg.net> <6.2.5.6.2.20120207032207.08dd2178@resistor.net> <4F313CA5.9090708@isdg.net> <6.2.5.6.2.20120207070336.08bc6990@resistor.net> In-Reply-To: <6.2.5.6.2.20120207070336.08bc6990@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Sullivan , SPFBIF Subject: Re: [spfbis] Issue: Processing limits needs clarification and reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:29:57 -0000 S Moonesamy wrote: > Hi Hector, > At 07:00 AM 2/7/2012, Hector Santos wrote: >> Not quite following. Including with your previous similar post, you >> seem to be providing the idea (all) posted "Issue" comments are being >> cataloged and will posted again later (by you) for RFC? > > The WG Chairs asked for reviews of RFC 4408. The issues identified in > the reviews will be listed in the issue tracker. We will then request > the working group to comment on each issue. Please note that the WG > Chairs have not made any determination about whether an issue is valid > or not valid or what is in scope. > > If you have any questions above the above, feel free to send them to the > list or to the WG co-chairs. The concern was whether the preponderance of ignorance has already starting or the issues posted were automatically added to the tracker (wasn't even aware this was going to be done now) without the WG chair(s) judgment to catalog it or not. I see you made a statement that its your call what gets on the table. It would be nice to get an early notification that a issue is cataloged or will not for XYZ reason. I just don't want to wasting time to posting issues believing it will be cataloged and in the end, find out, a) issues weren't cataloged and/or b) ignored and never comes up again (in two weeks) and I feel there is a need to create more noise by reposting it again. If noise reduction is desired, feedback is useful. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From sm@elandsys.com Tue Feb 7 08:37:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FC121F87E1 for ; Tue, 7 Feb 2012 08:37:54 -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=[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 fe7EvU-X9Ly2 for ; Tue, 7 Feb 2012 08:37:52 -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 2387A21F8762 for ; Tue, 7 Feb 2012 08:37:52 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q17GbiQE006458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2012 08:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328632670; i=@elandsys.com; bh=O16EXcEcscLq/tSyiRrHaRsG1Bu2ntI65uGMky28i0M=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=nbXWnAFLtdC7hz++QPZJFWftZPFyCHDYNDHqsha3O5bLhihb6Jn+wiP6tbDa2lo1O fmcn2qBDekIjwq/rIa+21Q6t8YLRz59IqgP3m2d2xLZrQR85qM7Km1U2BW53VBYL0y LrtlpUoNN/CexoET3ohaLIkrqnKbJMeYi39za5qw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328632670; i=@elandsys.com; bh=O16EXcEcscLq/tSyiRrHaRsG1Bu2ntI65uGMky28i0M=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=c/t/ggRwZVeHT5ee8IS+uKTVSqMjbjSnY2Lxg6IGd2uZk4WVOM1dJECZ8P40mfvT8 MwSyPiUPmhLGFEzSanY6A77WrU28YmMXkhQVVO0JpxuMBHQLysw8OSyFNDMcUf4xqT pOWIqt2IecjVrTuSHNGsMS2l9vz7tac6P/2xhQLI= Message-Id: <6.2.5.6.2.20120207081931.07e30b20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Feb 2012 08:36:47 -0800 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Issue: SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 16:37:54 -0000 Hi Murray, At 10:19 PM 2/6/2012, Murray S. Kucherawy wrote: >This may be a can of worms, but since we're chartered to tidy up >where appropriate, I wonder if this might be such a spot. > >RFC4408 registered a new DNS RRtype, SPF, code 99. > >Are we able to tell how much deployment it's received? If only >little (which is what I suspect, but I've no data to back that up), >would it be appropriate to relegate its discussion to an appendix >and call it "historic"? It would help if WG participants could provide data about the deployment of the DNS RR as part of the request for empirical data. Regards, S. Moonesamy SPFBIS WG co-chair From dhc2@dcrocker.net Tue Feb 7 08:41:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468C721F8851 for ; Tue, 7 Feb 2012 08:41:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPUo5FO7rJe6 for ; Tue, 7 Feb 2012 08:41:18 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 713D021F8860 for ; Tue, 7 Feb 2012 08:41:18 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q17Gf9vw002338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2012 08:41:15 -0800 Message-ID: <4F315423.6040300@dcrocker.net> Date: Tue, 07 Feb 2012 08:41:07 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Pete Resnick References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> <6.2.5.6.2.20120206141650.096cd600@resistor.net> <20120206231112.GG61963@verdi> <4F30CC06.4080301@qualcomm.com> In-Reply-To: <4F30CC06.4080301@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 07 Feb 2012 08:41:15 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:41:19 -0000 On 2/6/2012 11:00 PM, Pete Resnick wrote: > The fact is that the IESG thought the above sentence was sufficient to explain > the deliverable. If we come up with a reasonable interpretation of that > deliverable, we'll be fine and I will defend it to the hilt. Pete, You could well be right, of course. However there's enough history with late-stage surprises with the IESG to make it worth considering a relatively modest exercise. It will help /us/ to settle on the list of basic questions we decide to answer, in satisfaction of this charter requirement. It will likely help the process to run that presumably short list past the IESG for comment. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From WebMaster@Commerco.Net Tue Feb 7 08:46:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0B621F8821 for ; Tue, 7 Feb 2012 08:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jKIEG40mTHG for ; Tue, 7 Feb 2012 08:46:20 -0800 (PST) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9570721F87F7 for ; Tue, 7 Feb 2012 08:46:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=xAskrv1wh/c+RP69g9a0jZc2jxtn9w6tvOiGo5J7u3y0Jz+KK9tjJm8LG71tBy22ORTFjTAy3ta0LhkbgYX6xMGxkEA9RVcW49jTiYOdK5OLmkRV8b8lzm/p2mJ/mECJR+FfelgkL7+ZTdoEYcoOY4g/1fmbHGMkBobeG03mVmo= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Tue, 07 Feb 2012 16:46:19 +0000 Message-ID: <4F315555.9040206@Commerco.Net> Date: Tue, 07 Feb 2012 09:46:13 -0700 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] Issue: SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 16:46:21 -0000 Murray, I would prefer to avoid seeing RRtype 99 being seen as historic. Rather, the RRtype should be seen as the preferred RRtype of choice for SPF implementations. This may indeed be even more the case for future revs of SPF not addressed in this spfbis process. There was significant discussion as I recall on the SPF list regarding the treatment of RRtype 99 at the time it was approved because of the huge levels of adoption of the TXT RRtype for SPF (the only way to implement the experiment prior to the issuance of RRtype99). During those discussions I recall the future V3 version of SPF as perhaps implementing the notion that RRtype 99 was indeed to become the preferred mechanism for describing SPF in DNS. As such, I would tend to vote against the relegation of RRtype 99 as "historic". Best, Alan M. On 2/6/2012 11:19 PM, Murray S. Kucherawy wrote: > This may be a can of worms, but since we’re chartered to tidy up where > appropriate, I wonder if this might be such a spot. > > > RFC4408 registered a new DNS RRtype, SPF, code 99. > > Are we able to tell how much deployment it’s received? If only little > (which is what I suspect, but I’ve no data to back that up), would it be > appropriate to relegate its discussion to an appendix and call it > “historic”? > > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From john@jlc.net Tue Feb 7 09:05:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B179421F881E for ; Tue, 7 Feb 2012 09:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.347 X-Spam-Level: X-Spam-Status: No, score=-106.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtmSpnIqNHXI for ; Tue, 7 Feb 2012 09:05:51 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id AB94821F8834 for ; Tue, 7 Feb 2012 09:05:51 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id D730433C22; Tue, 7 Feb 2012 12:05:50 -0500 (EST) Date: Tue, 7 Feb 2012 12:05:50 -0500 From: John Leslie To: dcrocker@bbiw.net Message-ID: <20120207170550.GI61963@verdi> References: <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> <6.2.5.6.2.20120206141650.096cd600@resistor.net> <20120206231112.GG61963@verdi> <4F30CC06.4080301@qualcomm.com> <4F315423.6040300@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F315423.6040300@dcrocker.net> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 17:05:52 -0000 Dave CROCKER wrote: > On 2/6/2012 11:00 PM, Pete Resnick wrote: > >> The fact is that the IESG thought the above sentence was sufficient to >> explain the deliverable. If we come up with a reasonable interpretation >> of that deliverable, we'll be fine and I will defend it to the hilt. (I don't understand how such a nice guy as Pete survives in the arena of being an AD.) I thoroghly agree with Pete here. > You could well be right, of course. However there's enough history with > late-stage surprises with the IESG to make it worth considering a > relatively modest exercise. I disagree with Dave, at least partly wearing my NarrativeScribe hat. Such exercises are _not_ modest to the IESG. > It will help /us/ to settle on the list of basic questions we decide to > answer, in satisfaction of this charter requirement. It will likely help > the process to run that presumably short list past the IESG for comment. Pete has made us an offer we _really_should_not_ refuse. He has offered to initiate this discussion wearing his ResponsibleAD hat. It would be an abuse of process to escalate that to the full IESG unless and until we have a problem with our ResponsibleAD's interpretation of the charter item (which Pete has already said he'll mostly defer to us to write). No, Dave, it would not help to escalate this to the IESG now. -- John Leslie From vesely@tana.it Tue Feb 7 09:14:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6082421F885B for ; Tue, 7 Feb 2012 09:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.353 X-Spam-Level: X-Spam-Status: No, score=-4.353 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BKGykQJ3Gnv for ; Tue, 7 Feb 2012 09:14:22 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3091C21F8800 for ; Tue, 7 Feb 2012 09:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328634859; bh=w1OboR4P2kGsv+t98abrvf1T18kDDjl9OTk8mnVaeiY=; l=1952; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Vssl4H5CYIi8Bxu1XgwOGG5hhcw0ISnRNhMvQfXbj0xmYJ1OwWVdrMvCXj22M7JyK f27SM+jlTPbOzNiCQzjzisvkJe7HyMgHlzHQK9Q7eihdLuS5oeqoRHeogU2SkVtNLe 14Pl2R18F/0zHiwKqgrnfvNZLe4Id19gwPprklio= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 07 Feb 2012 18:14:19 +0100 id 00000000005DC035.000000004F315BEB.00003C99 Message-ID: <4F315BEB.9050009@tana.it> Date: Tue, 07 Feb 2012 18:14:19 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> <6.2.5.6.2.20120206141650.096cd600@resistor.net> <20120206231112.GG61963@verdi> <4F30CC06.4080301@qualcomm.com> In-Reply-To: <4F30CC06.4080301@qualcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 17:14:23 -0000 On 07/Feb/12 08:00, Pete Resnick wrote: > With AD hat on. > > On 2/6/12 5:11 PM, John Leslie wrote: > >> All we really need out of this is to declare the Sender-ID use >> of v=spf obsolete. To justify that, we need only prove that SPF use >> of v=spf greatly exceeds Sender-ID use of it. To clarify this point, let me quote the results of Microsoft's wizard http://www.anti-spamtools.org/ varying the "Scope" radio button: The Purported Responsible Address (PRA) only spf2.0/pra [mechanisms omitted] -all The MAIL FROM (or reverse-path) address only (2 records) v=spf1 [mechanisms omitted] -all spf2.0/pra ?all Both <-- this was the wizard's initial setting v=spf1 [mechanisms omitted] -all It doesn't seem to make sense to analyze the published records. Thus we can only analyze what's deployed on the checking side. However, we cannot assume that mail domains choose their MTA software based on Sender-ID/SPF support only. Moreover, some MTA software licenses are not compatible with OSP or RANDZ. Therefore, counting existing software developments, or deployments thereof, will not result in a true representation of the corresponding effectiveness. > Assuming [no] low likelihood events occur, gathering data on how > much and how effectively (relative to each other) SPF and Sender-ID > got deployed seems like the right thing to be doing. I'd randomly select some Sender-ID-compliant MTAs that are able to log "mfrom" and "pra" separately. We may consider SPF equivalent to Sender-ID with just "mfrom". That is to say, let's evaluate how relevant is the contribution of "pra" relative to "pra" + "mfrom", for such MTAs. In effect, it's that "pra" part that we are going to tear down. It is reasonable to evaluate it as we go. The problem is, the last time I checked hotmail, I obtained an ehlo response with no 250-SUBMITTER line. Are there any fully compliant Sender-ID deployments out there? From sm@elandsys.com Tue Feb 7 09:43:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970B621F88BC for ; Tue, 7 Feb 2012 09:43:07 -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=[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 F3iNpBg5Yx7X for ; Tue, 7 Feb 2012 09:43:04 -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 508DB21F8873 for ; Tue, 7 Feb 2012 09:43:03 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q17HgsJt013372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2012 09:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328636581; i=@elandsys.com; bh=4NWGUla7JreWsL2HEK0P8ydHqyJ+t4btnDrUXgsddPg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=L9LuX4ZfGXrE6lOkRsi78io/ZhuNpFF5by/SgGVfpa4Kn33SsJN26GloKBNISrWp2 o1ukCQE3wCIoEXt8zUdk0n4xA6Ja22eC8q+sqapz68WkuarWFQDYVuuMA1L959y8Dr g5AUPyXJ3Kc7984RLPPHVoa6nuH5oZZx8vIoEUBI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328636581; i=@elandsys.com; bh=4NWGUla7JreWsL2HEK0P8ydHqyJ+t4btnDrUXgsddPg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=1qzWQyaEOXomU2fAkU6dk4vsOMeYMsYUxgo7Ia5kC6VzbP0WhVI5YaessrbPZS6Ly RecY/71ck5zttYB6qFWVCXw1gL5nS/Sh9TwTBirHvZtydejhLfHaYxCfaeDRe+IDMe nVmhlHDtstqPImAOQvvDw8wLgVYMB5GbmUhJW4LU= Message-Id: <6.2.5.6.2.20120207083927.06706cd0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Feb 2012 09:24:26 -0800 To: Hector Santos From: S Moonesamy In-Reply-To: <4F315185.5080602@isdg.net> References: <1789090.uGqYcqLmHb@scott-latitude-e6320> <4F30AA0C.7010701@isdg.net> <6.2.5.6.2.20120207032207.08dd2178@resistor.net> <4F313CA5.9090708@isdg.net> <6.2.5.6.2.20120207070336.08bc6990@resistor.net> <4F315185.5080602@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan , spfbis@ietf.org Subject: Re: [spfbis] Issue: Processing limits needs clarification and reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:43:07 -0000 Hi Hector, At 08:29 AM 2/7/2012, Hector Santos wrote: >The concern was whether the preponderance of ignorance has already >starting or the issues posted were automatically added to the >tracker (wasn't even aware this was going to be done now) without >the WG chair(s) judgment to catalog it or not. I see you made a >statement that its your call what gets on the table. It would be >nice to get an early notification that a issue is cataloged or will >not for XYZ reason. I just don't want to wasting time to posting >issues believing it will be cataloged and in the end, find out, a) >issues weren't cataloged and/or b) ignored and never comes up again >(in two weeks) and I feel there is a need to create more noise by >reposting it again. As I mentioned previously, the WG Chairs have not made any determination about whether an issue is valid or not valid or what is in scope ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00336.html ). Someone will have to make the call. That someone is generally the WG Chairs. I am waiting for the issue tracker to be accessible to "catalog" the issues. May I humbly suggest that you wait a little before determining whether the WG Chairs have provided ample opportunity for discussion about every issue which have been posted? Regards, S. Moonesamy SPFBIS WG co-chair From sm@elandsys.com Tue Feb 7 09:43:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B0E21F8873 for ; Tue, 7 Feb 2012 09:43:08 -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=[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 bOXqJ4tH0bvV for ; Tue, 7 Feb 2012 09:43:07 -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 5146021F8891 for ; Tue, 7 Feb 2012 09:43:06 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q17HgsJv013372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2012 09:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328636585; i=@elandsys.com; bh=rcvIEcfdj3/gwjmjFRiLUTjagthOu4+tqIoRD8UVAk0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=ud/VrFHTmXggHaWC4rrZArVfixj/QEkC7xyopJsrBdx5Txf8pMHIABabDNwHSR/+I vOr7yPcKGjZ/Tuddu7fi8IikPOdzml38gG9yVTXs02BCf7+GiIVenBDSfReQH17/Or cgR4dHDGI4v2CxMCPoUtqledpbuRPLRdJeBOW+MM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328636585; i=@elandsys.com; bh=rcvIEcfdj3/gwjmjFRiLUTjagthOu4+tqIoRD8UVAk0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=SMAE7KitNhH31t2xOfYuO76clOoJM4Nz9ctF1PNSetC/NFxkdwqjOZHoBGc7aVaBG rFqaG/aNKu49pWIkZMwvCsVISEMvlbLFWHkxZ1AvKLWPb6lkkIaT0t4Z1PiWfDURpq +vP/Gmi3jiwGkpQapYM+vVIlzWckVPSEB9CcTKEo= Message-Id: <6.2.5.6.2.20120207092449.06706f60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Feb 2012 09:42:35 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4F315555.9040206@Commerco.Net> References: <4F315555.9040206@Commerco.Net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] Issue: SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 17:43:08 -0000 At 08:46 AM 2/7/2012, Commerco WebMaster wrote: >I would prefer to avoid seeing RRtype 99 being seen as historic. >Rather, the RRtype I prefer not to see any discussion about the issues or reviews that have been or will be posted to this mailing list. As WG Chairs, we rely on WG participants to help in making progress nicely. We would like to handle one o two controversies at a time instead of having a full-blown discussion about everything. Let me say it clearly. When I label a message as coming from the WG co-chair and I say "no discussions now", I mean no discussions now. Could WG participants please show some self-restrain by not getting into discussions about issues? Regards, S. Moonesamy SPFBIS WG co-chair From ajs@anvilwalrusden.com Tue Feb 7 09:49:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B976621F88EB for ; Tue, 7 Feb 2012 09:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Wzd6DwTpNzG for ; Tue, 7 Feb 2012 09:49:17 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDBF21F88E9 for ; Tue, 7 Feb 2012 09:49:17 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 42E3C1ECB41D for ; Tue, 7 Feb 2012 17:49:16 +0000 (UTC) Date: Tue, 7 Feb 2012 12:49:11 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120207174833.GA10000@crankycanuck.ca> References: <4F315555.9040206@Commerco.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F315555.9040206@Commerco.Net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Issue: SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 17:49:17 -0000 Chair hat on. On Tue, Feb 07, 2012 at 09:46:13AM -0700, Commerco WebMaster wrote: > > I would prefer to avoid seeing RRtype 99 being seen as historic. Please, no, stop. Now is _not_ the time, as we have asked repeatedly, to discuss the merits of the various issues. There will be an opportunity to discuss them later. Now, we are collecting issues, and not debating them. If we try to debate every issue at once, we will never manage to make any progress. Thanks and best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From wwwrun@ietfa.amsl.com Tue Feb 7 09:52:46 2012 Return-Path: X-Original-To: spfbis@ietf.org Delivered-To: spfbis@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 9F9EF21F85A1; Tue, 7 Feb 2012 09:52:46 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120207175246.9F9EF21F85A1@ietfa.amsl.com> Date: Tue, 7 Feb 2012 09:52:46 -0800 (PST) Cc: spfbis@ietf.org, sm+ietf@elandsys.com, ajs@anvilwalrusden.com Subject: [spfbis] WG Action: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 17:52:46 -0000 A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the WG Chairs. SPF Update (spfbis) ----------------------------------------- Last Updated: 2012-02-01 Chair(s): Andrew Sullivan S Moonesamy Applications Area Director(s): Pete Resnick Peter Saint-Andre Applications Area Advisor: Pete Resnick Mailing Lists: General Discussion: spfbis@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/spfbis Archive: http://www.ietf.org/mail-archive/web/spfbis/ Description of Working Group: The Sender Policy Framework (SPF, RFC4408) specifies the publication of a DNS record which states that a listed IP address is authorized to send mail on behalf of the listing domain name's owner. SMTP servers extract the domain name in the SMTP "MAIL FROM" or "HELO" command for confirming this authorization. The protocol has had Experimental status for some years and has become widely deployed. This working group will summarize the result of the experiment and revise the specification, based on deployment experience and listed errata, and will seek Standards Track status for the protocol. The MARID working group considered two specifications for publication of email-sending authorization: Sender-ID, which eventually became RFC4405, RFC4406 and RFC4407, and SPF, which eventually became RFC4408, all in the end published under Experimental status. By using IP addresses, both protocols specify authorization in terms of path, though unlike SPF, Sender-ID uses domain names found in the header of the message rather than the envelope. The two protocols rely on the same policy publication mechanism, namely a specific TXT resource record in the DNS. This creates a basic ambiguity about the interpretation of any specific instance of the TXT record. Because of this, there were concerns about conflicts between the two in concurrent operation. The IESG note prepended to RFC 4405 through RFC 4408 defined an experiment with SPF and Sender-ID, and invited an expression of community consensus in the period following the publication of those specifications. Both technologies initially enjoyed widespread deployment. Since that time, broad SPF use has continued, whereas use of Sender-ID has slackened. Furthermore, SPF's linkage to the envelope (as opposed to Sender-ID's linkage to identifiers in the message content) has proven sufficient among operators. Formation of the SPF Update Working Group is predicated on three assumptions: 1. The SPF/Sender-ID experiment has concluded. 2. SPF has been a qualified success, warranting further development. 3. Sender-ID has had less success, and no further development is justified. The working group will produce a document describing the course of the SPF/Sender-ID experiment, thus bringing that experiment to a formal conclusion. The group will complete additional work on SPF (described below), but will not complete additional work on the Sender-ID specification. Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language. Specifically out-of-scope for this working group: * Revisiting past technical arguments where consensus was reached in the MARID working group, except where review is reasonably warranted based on operational experience. * Discussion of the merits of SPF. * Discussion of the merits of Sender-ID in preference to SPF. * Extensions to the SPF protocols. * Removal of existing features that are in current use. Discussion of extensions to the SPF protocols or removal of existing features shall only be discussed after completion of current charter items in anticipation of rechartering the working group. An initial draft of an updated SPF specification document is draft-kitterman-4408bis. The working group may choose to use this document as a basis for their specification. Goals and Milestones: Aug 2012: A document describing the SPF/Sender-ID experiment and its conclusions to the IESG for publication. Dec 2012: A standards track document defining SPF, based on RFC4408 and as amended above, to the IESG for publication. From sm@elandsys.com Tue Feb 7 10:07:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6DC21F8569 for ; Tue, 7 Feb 2012 10:07:35 -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 b-TOtoI2jvRf for ; Tue, 7 Feb 2012 10:07:34 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEFF21F84B8 for ; Tue, 7 Feb 2012 10:07:25 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q17I7JgT009172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Feb 2012 10:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328638044; i=@elandsys.com; bh=yU7YdZR8IPI72/gjBV7mLvZakAW8My2K0Ihl4PGESbo=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=JSQcgo6DiGfrcUsqciMaDCJx+a8iED3BWlLKiTjiUmBzvLkls51uPSCJd3PsFn9XN WoCYNPoo0Sl4AysWPurnhH/R6/kkPHecrlTzhKKCMhikp4O4rcVd+8zn36aOvA5Yp7 qtQlx2YOxsgQhC/hRDj6j5RCtr15i00NQpW6q13g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328638044; i=@elandsys.com; bh=yU7YdZR8IPI72/gjBV7mLvZakAW8My2K0Ihl4PGESbo=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=ViEiAT9qLCndGnqWiBePFVrWN9QyaJVs05GH+WpuDzLI+jkQ8AqYZZ+FIkGPseliZ Ejp4c2Doznfw7xPUaDDSCc9ayvho0OypMXz3TibVOVGYV/ugepaHXnuvsofP8da+Z5 I3ytZszt/r205MdnztUJo+EY6joqvHX8kUUnPyp0= Message-Id: <6.2.5.6.2.20120207095112.06582ab0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Feb 2012 10:07:04 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4F315BEB.9050009@tana.it> References: <20120203215158.GQ4322@mail.yitter.info> <40255162.ysvdAIjBC2@scott-latitude-e6320> <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> <6.2.5.6.2.20120206141650.096cd600@resistor.net> <20120206231112.GG61963@verdi> <4F30CC06.4080301@qualcomm.com> <4F315BEB.9050009@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 18:07:35 -0000 At 09:14 AM 2/7/2012, Alessandro Vesely wrote: >To clarify this point, let me quote the results of Microsoft's wizard I could quote what the WG Chairs have been saying but it might be futile as it seems that nobody is listening. If WG participants ignore the requests from the WG Chairs, I take it that it is would not be unfair for the WG Chairs not to listen to what the WG participants say on this thread. Regards, S. Moonesamy SPFBIS WG co-chair From WebMaster@Commerco.Net Tue Feb 7 10:34:09 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DD921F88D4 for ; Tue, 7 Feb 2012 10:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9offhe82VEh for ; Tue, 7 Feb 2012 10:34:09 -0800 (PST) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id D55A821F88BC for ; Tue, 7 Feb 2012 10:34:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=4Bv+WFXuhj6ha7k8dv0uQoJZzC4uCHgLxF0KujoIyJpe+DB1lMQX0M0SG9pQIWvh/QqapaVU4c6j46F3Thlb626SQ9fY4fgtVh9B7RrXDDJqX3uDPkIobu0tGp+2ZyJ3tBOB5ACHHu4rjbf6KkYoM7pAZm+7SR6qenIyL9uc8uU= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Tue, 07 Feb 2012 18:34:06 +0000 Message-ID: <4F316E98.3090905@Commerco.Net> Date: Tue, 07 Feb 2012 11:34:00 -0700 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F315555.9040206@Commerco.Net> <6.2.5.6.2.20120207092449.06706f60@resistor.net> In-Reply-To: <6.2.5.6.2.20120207092449.06706f60@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] Issue: SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 18:34:09 -0000 I was simply responding to the question originally started by Murray S. Kucharawy regarding the topic. Perhaps this is a process issue as regards how the bis process operates. My most recent understanding of the process was that Murray was originally leading up the effort to get spfbis on track prior to the introduction of the co-chairs. He had introduced the original question on this list designed to get spfbis to standards. He has been here serving in that capacity prior to the introduction of chairs to this process and apparently continues to make good contributions to the spfbis effort. I worked on the belief that with specific questions being posed to the list by facilitators, there was an implicit request for answers by list members. To the spfbis co-chairs: if questions are brought up on the list by those generally understood to be process facilitators, how are they to be best addressed by list members in future? Thank you in advance for your guidance in this matter. Alan M. On 2/7/2012 10:42 AM, S Moonesamy wrote: > At 08:46 AM 2/7/2012, Commerco WebMaster wrote: >> I would prefer to avoid seeing RRtype 99 being seen as historic. >> Rather, the RRtype > > I prefer not to see any discussion about the issues or reviews that have > been or will be posted to this mailing list. As WG Chairs, we rely on WG > participants to help in making progress nicely. We would like to handle > one o two controversies at a time instead of having a full-blown > discussion about everything. > > Let me say it clearly. When I label a message as coming from the WG > co-chair and I say "no discussions now", I mean no discussions now. > Could WG participants please show some self-restrain by not getting into > discussions about issues? > > Regards, > S. Moonesamy > SPFBIS WG co-chair > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From sm@elandsys.com Tue Feb 7 11:01:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6308021F88D6 for ; Tue, 7 Feb 2012 11:01:51 -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=[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 I3DcpQ9XXw1z for ; Tue, 7 Feb 2012 11:01:50 -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 B428721F88BC for ; Tue, 7 Feb 2012 11:01:50 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q17J1Vp4018041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2012 11:01:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328641300; i=@elandsys.com; bh=JoVqn5oI1roFmR7hYLPRS7Ty08A1IYl1tutJ+ENd0iM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=tmVsxdz2IJxpDSqtUH0kxObAfZMYp5IiTBr3C5/ddynIgYgrH9cqz9E6XMjDP+CtS geEgOwBwfRUlWJHOlFmaI6agp5FkcTllIytywWxzLl4I9JKfVp7ir97n4W2alhi5FJ 32EXJt/acJhD/ae/xj0g1nrfv8iEFDpOlYo4uvF0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328641300; i=@elandsys.com; bh=JoVqn5oI1roFmR7hYLPRS7Ty08A1IYl1tutJ+ENd0iM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=4aDLITze+7PP+gtq5rWX9uo5ysXNZTyhOz1tOL5qtdI/kEMr+pQVYtXYeY3nPJt24 eVLHDp8GYwHrpStXB81Gvkq2JWGh8u7HmRiEq2ld0/N2s+5Q0Xao/QuqFLu2US241N Ou2GqOew4sdHFoiaPG/O+C3jKXmV8WAZm/RCU09A= Message-Id: <6.2.5.6.2.20120207103653.0820b450@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Feb 2012 11:00:41 -0800 To: Commerco WebMaster From: S Moonesamy In-Reply-To: <4F316E98.3090905@Commerco.Net> References: <4F315555.9040206@Commerco.Net> <6.2.5.6.2.20120207092449.06706f60@resistor.net> <4F316E98.3090905@Commerco.Net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] Issue: SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 19:01:51 -0000 Hi Alan, At 10:34 AM 2/7/2012, Commerco WebMaster wrote: >Perhaps this is a process issue as regards how the bis process >operates. My most recent understanding of the process was that >Murray was originally leading up the effort to get spfbis on track >prior to the introduction of the co-chairs. He had introduced the Murray spearheaded the effort in getting the SPFBIS WG chartered. He has put in a lot of effort in getting the working group on track. >To the spfbis co-chairs: if questions are brought up on the list by >those generally understood to be process facilitators, how are they >to be best addressed by list members in future? What Andrew and I have been trying to say is: please review RFC 4408 and post the issues you find to the mailing list. We will compile a list of issues and then start the discussion on them. We would like to tackle one of two controversies at a time as it would be easier for us to make progress nicely. Please do not discuss any question until the WG Chairs send out the request for comments. The SPFBIS WG Charter is at http://www.ietf.org/dyn/wg/charter/spfbis-charter IETF participants should also read and understand the Note Well ( http://www.ietf.org/about/note-well.html ). Regards, S. Moonesamy SPFBIS WG co-chair From ajs@anvilwalrusden.com Tue Feb 7 11:05:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4858E21F8902 for ; Tue, 7 Feb 2012 11:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSSur9iDLfhO for ; Tue, 7 Feb 2012 11:05:54 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 49C4221F8901 for ; Tue, 7 Feb 2012 11:05:49 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 014331ECB41D for ; Tue, 7 Feb 2012 19:05:42 +0000 (UTC) Date: Tue, 7 Feb 2012 14:05:26 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120207190522.GF10000@mail.yitter.info> References: <4F315555.9040206@Commerco.Net> <6.2.5.6.2.20120207092449.06706f60@resistor.net> <4F316E98.3090905@Commerco.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F316E98.3090905@Commerco.Net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Issue: SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 19:05:55 -0000 Hi, On Tue, Feb 07, 2012 at 11:34:00AM -0700, Commerco WebMaster wrote: > To the spfbis co-chairs: if questions are brought up on the list by > those generally understood to be process facilitators, how are they > to be best addressed by list members in future? In the IETF, I don't know what "generally understood to be process facilitators" means. If you are not familiar with the way the IETF works, I encourage you to read RFC 4667, which can be found at http://www.rfc-editor.org/rfc/rfc4677.txt. In this particular case, however, the WG chairs have been asking to follow one particular methodology: put your issues to the list, but please don't discuss them yet. That's what I requested last Friday, and I think we've tried to be consistent with it. The "yet" there is important. We will have an opportunity to discuss each issue at a later date, but we don't want to discuss them all now. As we've now said several times, the goal here is to break the issues down into manageable chunks, so that we're not struggling with all the issues at once. In general, we believe that progress is most likely to come if we can make progess on individual issues one or two at a time. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From WebMaster@Commerco.Net Tue Feb 7 11:25:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434CB21F87EF for ; Tue, 7 Feb 2012 11:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZccGrF8bt9X for ; Tue, 7 Feb 2012 11:25:11 -0800 (PST) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 90EAF21F87F2 for ; Tue, 7 Feb 2012 11:25:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=qru0a3tnm84MYGuJIghfWrq8gBb6+Zo//5Xkxd36K4bfhkkJfR2KqfvaHGNZha192Ad42OddjARa0MUnyvl816sEauF5zSz/fpcNAFIP+2EMiJK6DX1CKkBPl8hnCVZcPO/HnJG9348uwA+H1VMGRbCKWsBBId+RU5zY3pmTin0= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Tue, 07 Feb 2012 19:25:09 +0000 Message-ID: <4F317A85.6070308@Commerco.Net> Date: Tue, 07 Feb 2012 12:24:53 -0700 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F315555.9040206@Commerco.Net> <6.2.5.6.2.20120207092449.06706f60@resistor.net> <4F316E98.3090905@Commerco.Net> <20120207190522.GF10000@mail.yitter.info> In-Reply-To: <20120207190522.GF10000@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] Issue: SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 19:25:12 -0000 To our co-chairs, Thank you both for the clarification and I apologize for not entirely understanding current the process. To that end, perhaps we can have a single thread which lists all of the issues to be discussed once the list is assembled. In this way, we will have one spot we can all look to for an understanding of the next phase in the process, where comments would be more appropriate. @Andrew - thank you for the link to RFC 4667. Best, Alan M. On 2/7/2012 12:05 PM, Andrew Sullivan wrote: > Hi, > > On Tue, Feb 07, 2012 at 11:34:00AM -0700, Commerco WebMaster wrote: >> To the spfbis co-chairs: if questions are brought up on the list by >> those generally understood to be process facilitators, how are they >> to be best addressed by list members in future? > > In the IETF, I don't know what "generally understood to be process > facilitators" means. If you are not familiar with the way the IETF > works, I encourage you to read RFC 4667, which can be found at > http://www.rfc-editor.org/rfc/rfc4677.txt. > > In this particular case, however, the WG chairs have been asking to > follow one particular methodology: put your issues to the list, but > please don't discuss them yet. That's what I requested last Friday, > and I think we've tried to be consistent with it. The "yet" there is > important. We will have an opportunity to discuss each issue at a > later date, but we don't want to discuss them all now. > > As we've now said several times, the goal here is to break the issues > down into manageable chunks, so that we're not struggling with all the > issues at once. In general, we believe that progress is most likely > to come if we can make progess on individual issues one or two at a > time. > > Best regards, > > Andrew > From ajs@anvilwalrusden.com Tue Feb 7 11:51:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABF321F877F for ; Tue, 7 Feb 2012 11:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seS7mNxe2BOJ for ; Tue, 7 Feb 2012 11:51:02 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 03B8821F8638 for ; Tue, 7 Feb 2012 11:51:01 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1E9AE1ECB41D for ; Tue, 7 Feb 2012 19:51:01 +0000 (UTC) Date: Tue, 7 Feb 2012 14:50:57 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120207195056.GH10000@mail.yitter.info> References: <4F315555.9040206@Commerco.Net> <6.2.5.6.2.20120207092449.06706f60@resistor.net> <4F316E98.3090905@Commerco.Net> <20120207190522.GF10000@mail.yitter.info> <4F317A85.6070308@Commerco.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F317A85.6070308@Commerco.Net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] meta: this process (was: Issue: SPF RR type) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 19:51:03 -0000 Hi all, This is just a (re-re-)re-iteration of how we're trying to run this process. This particular part of the process is about capturing issues with RFC 4408. I'm not talking here about resolving the experiment; we'll deal with that in another thread. On Tue, Feb 07, 2012 at 12:24:53PM -0700, Commerco WebMaster wrote: > To that end, perhaps we can have a single thread which lists all of > the issues to be discussed once the list is assembled. In the first stage, we are collecting issues. I'd originally imagined people would post whole reviews of RFC 4408, but instead people seem to be identifying particular issues they have with it in separate messages. That's grand. Whatever way we collect them is good. We asked that people get their issues together by 18 Feb. Nobody has objected to that deadline yet. The plan is that, once we have stopped collecting, we can collate the issues into a big list. That big list will go into the tracker (if you don't know about the issue tracker, visit http://tools.ietf.org/wg/spfbis. To use the tracker you need a tools login. If you don't know about this, poke me offline and I'll explain), and we'll post a summary here. We'll ask for anything we missed or any distinctions people think we haven't made. Again, that will be an opportunity to _identify_ cases, and not to debate their merits. Once we have this in hand, then we can pick one or two of the identified issues _at a time_, and work to resolve them. This way, we control the rate at which we have to discuss complicated and contentious issues, and we can move forward. All of this was intended to be implicit in the note I sent to the list last Friday, but I recognize that perhaps it wasn't clear enough. Hence this note. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From pgladstone@cisco.com Tue Feb 7 12:09:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D9111E80CA for ; Tue, 7 Feb 2012 12:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF3q1jvRGXzb for ; Tue, 7 Feb 2012 12:09:15 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 44CD711E80BD for ; Tue, 7 Feb 2012 12:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=1351; q=dns/txt; s=iport; t=1328645355; x=1329854955; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=fZiRW0rXXUgXCDmYg13T2WKnv4lSVQOmb5i+baW7OjA=; b=GUTPK1W+xqwPxU3adbe7+YCqvssNQvvssw97IjMf+iInszwuQTB5yp73 fntwiVZbAZePxUJwT0MM2Y9+rMDoQhXM1I+1tIvZZO6cSJvRHfFeweni7 N75udxSbtOqow1WtuVpxlXwWZCI4HXhKTytDE9ONzaayg2L2alyQoTxBn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAMODMU9Io8UY/2dsb2JhbABDhQurUoFyAQEBBBIBEBVAEQsYAgIFFgsCAgkDAgECAUUTCAEBHqJ4AYxlkg+BL4oHAQcCAgkFDQMTAQgFAwMJH4JyGQQDDAMUBVcNAQQEO4IHgRYEiEaMZoVYjSM X-IronPort-AV: E=Sophos;i="4.73,379,1325462400"; d="scan'208";a="5025270" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 07 Feb 2012 20:09:13 +0000 Received: from [161.44.106.141] (dhcp-161-44-106-141.cisco.com [161.44.106.141]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q17K9C6H001471 for ; Tue, 7 Feb 2012 20:09:13 GMT Message-ID: <4F3184E7.4000600@cisco.com> Date: Tue, 07 Feb 2012 15:09:11 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120207081931.07e30b20@resistor.net> In-Reply-To: <6.2.5.6.2.20120207081931.07e30b20@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Issue: SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 20:09:17 -0000 On 2/7/2012 11:36 AM, S Moonesamy wrote: > It would help if WG participants could provide data about the > deployment of the DNS RR as part of the request for empirical data. > > I fetched the SPF RR from each of the 287,000 DNS names (in my database) that had an SPF record. Only 4,613 entries returned SPF (type 99) records. There were many timeouts (but I didn't count them) as it seems that some servers do not respond: azbus.net, kupai.me, togocom.com etc. Of the 4613 SPF RRs, ~800 do not match the TXT version for the same domain. In some cases it is just a whitespace difference or ordering difference. kvsupply.com TXT: v=spf1 a mx include:kvvet.com ~all SPF: v=spf1 a mx include:kvvet.com include:kvpetsupply.com ~all lps.org TXT: v=spf1 mx ptr ?all SPF: v=spf1 a:zmta1.lps.org a:zmta2.lps.org ptr ?all pizza.be TXT: v=spf1 a mx ip4:82.94.230.23 ip4:213.34.65.131 ip4:213.34.65.132 ip4:213.34.65.133 ip4:82.94.249.230 ~all SPF: v=spf1 a mx ip4:82.94.230.23 ip4:213.34.65.131 ip4:213.34.65.132 ip4:213.34.65.133 ip4:82.94.249.230 include:trustpilot.com ~all harvardbusiness.org TXT: v=spf1 ptr a:mail.hbsp.harvard.edu ip4:67.202.196.80/28 include:hbsp.harvard.edu ?all SPF: v=spf1 ptr a:mail.hbsp.harvard.edu ip4:67.202.196.80/28 ip4:74.125.148.0/22 include:hbsp.harvard.edu ?all Philip From ajs@anvilwalrusden.com Tue Feb 7 12:38:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4735621F8878 for ; Tue, 7 Feb 2012 12:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWTpg3eUfEEG for ; Tue, 7 Feb 2012 12:38:51 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id AFF5221F8877 for ; Tue, 7 Feb 2012 12:38:51 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EF1AB1ECB41D for ; Tue, 7 Feb 2012 20:38:50 +0000 (UTC) Date: Tue, 7 Feb 2012 15:38:48 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120207203848.GI10000@mail.yitter.info> References: <20120203235617.GA4322@crankycanuck.ca> <4F301C8B.70107@dcrocker.net> <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> <6.2.5.6.2.20120206141650.096cd600@resistor.net> <20120206231112.GG61963@verdi> <4F30CC06.4080301@qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F30CC06.4080301@qualcomm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] On what evidence is needed (was: "The question is wrong" thread) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 20:38:52 -0000 Dear colleagues, On Tue, Feb 07, 2012 at 01:00:22AM -0600, Pete Resnick wrote: > The WG was chartered on the assumption (see 1, 2, and 3 in the > charter) that there exists community consensus that SPF has been > more successfully deployed than Sender-ID and that therefore SPF > should move forward and that no further work need be done on > Sender-ID. The first order of business is to document that SPF *was* > more successfully deployed than Sender-ID (by enumerating the amount > of deployment of each and the "relative effectiveness" of each), and > that's what I take Andrew to mean by providing "experimental > evidence". That's right, it was, but SM and I can say something more formally: We have been avoiding trying to interpret what would qualify as empirical evidence of the end of the experiment, partly in an attempt to draw out participants' views about the experiment, and partly because the experimental design did not include a clear statement of the proposition being tested. Nevertheless, participants want a clearer statement of what evidence is desired. Our AD has offered to take seriously the WG's good-faith efforts to understand the experiment, and therefore that's what we will do. We understand the experiment to have consisted of the simultaneous deployment of two protocols using the same data from the DNS. We interpret the experiment to have been an effort to see which protocol would be more widely deployed, or more effective, or both. Therefore, any evidence about relative deployment, or relative efficacy, would be welcome. Evidence of migration from one technology to another would also be important evidence (really, evidence about relative deployment). Note that this is still _not_ a request for evaluations of the trade-off. For instance, if we discovered that the two technologies were approximately equal in efficacy, then one might make an argument that one or the other ought to be preferred because it is simpler and just as effective. That, however, is a _conclusion_, and not evidence as such. Let's please hold off on the conclusions until we have gathered such evidence as we have. Best regards, Andrew and SM -- Andrew Sullivan ajs@anvilwalrusden.com From john@jlc.net Tue Feb 7 13:12:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABBA21F8616 for ; Tue, 7 Feb 2012 13:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.356 X-Spam-Level: X-Spam-Status: No, score=-106.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lL9oTvN6eeV for ; Tue, 7 Feb 2012 13:12:00 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE5321F8615 for ; Tue, 7 Feb 2012 13:12:00 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 09D8933C22; Tue, 7 Feb 2012 16:12:00 -0500 (EST) Date: Tue, 7 Feb 2012 16:12:00 -0500 From: John Leslie To: Dave CROCKER Message-ID: <20120207211159.GJ61963@verdi> References: <20120206183924.GN7609@mail.yitter.info> <4F3030D3.9090900@dcrocker.net> <20120206202244.GA8370@mail.yitter.info> <6.2.5.6.2.20120206141650.096cd600@resistor.net> <20120206231112.GG61963@verdi> <4F30CC06.4080301@qualcomm.com> <4F315423.6040300@dcrocker.net> <20120207170550.GI61963@verdi> <4F315C0B.3020102@bbiw.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F315C0B.3020102@bbiw.net> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] "The question is wrong" thread X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 21:12:01 -0000 NB: although our WGCs are asking us not to discuss/analyze data, I think this one thread deserves just a bit more discussion. (But I will not respond to Dave much longer.) Dave CROCKER wrote: > > > Just to clarify, having Pete be the one to bring the list of questions > to the IESG and -- to make the distinction that Pete raised in his note > -- to cast it as an informal query and response, are fine. Should Pete want to do that, I wouldn't object (but I might send him private email about what he's getting into). > My concern is with waiting until the end of our work to get this issue > reviewed at all by the IESG. Reporting on Sender-ID is hardly "the end of our work". Check the charter milestones... > For anyone who misunderstand the basis of the concern I am raising, > or who thinks that an individual AD can make assurances about the > IESG, I encourage them to review the history of the YAM working group. I think Dave and I will have to agree to disagree here. I was scribing those IESG telechats; and I think my Narrative Minutes support my belief the IESG of that time was determined to not repeat a YAM-style charter. Regardless, today's IESG is different; and I agree with Pete's belief that his strong support of our "document decribing the SPF/Sender-ID experiment" will be sufficient to convince other ADs. (Where we may get "late surprises" is at IETF-wide LastCall; and no prior IESG statement can stop those.) -- John Leslie From sm@elandsys.com Tue Feb 7 13:12:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E4D21F8693 for ; Tue, 7 Feb 2012 13:12:39 -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 UnbaJRQ7ZR2H for ; Tue, 7 Feb 2012 13:12: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 04FE121F861F for ; Tue, 7 Feb 2012 13:12:36 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q17LCTo7029480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2012 13:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328649154; i=@elandsys.com; bh=dICEoJYXazR3UxbMS0T/nlMZaVq6rLD+s2dTv+D26Ms=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=4odQT13vx3vZNvFKYL//jrwrwX4ttaKfoi5sgk0NGrJ2e0ISkYN8yVkRNxgoTqPfk MzGFU7/Aq9GRZKwQ+QMTRPu9BYy3HfDddH7L0li865l/ReUhkZJ+StES7IQNeWAnof vPYeIHqgiL/6bKmo5kJ1nNxXwT03RFE240SI7z0U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328649154; i=@elandsys.com; bh=dICEoJYXazR3UxbMS0T/nlMZaVq6rLD+s2dTv+D26Ms=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=epuPM66B74gmt4FsRlELX0fmAJK6vg4wiCgKONlit/cUNKTTb69puktQonPpKPEba kvQtJZNmCtvTOHF21tOWY13vkAzKcipc5SY551rMh3nG18SXIxpE/WpEMMdM6OlwOb qnd5y969z455AGFj44ZGaiKdbEQ0QlYCOVfuG2ho= Message-Id: <6.2.5.6.2.20120207122754.083eb4e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Feb 2012 12:29:35 -0800 To: Philip Gladstone From: S Moonesamy In-Reply-To: <4F3184E7.4000600@cisco.com> References: <6.2.5.6.2.20120207081931.07e30b20@resistor.net> <4F3184E7.4000600@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Issue: SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Feb 2012 21:12:39 -0000 Hi Philip, At 12:09 PM 2/7/2012, Philip Gladstone wrote: >I fetched the SPF RR from each of the 287,000 DNS names (in my >database) that had an SPF record. Only 4,613 entries returned SPF >(type 99) records. There were many timeouts (but I didn't count >them) as it seems that some servers do not respond: azbus.net, >kupai.me, togocom.com etc. > >Of the 4613 SPF RRs, ~800 do not match the TXT version for the same >domain. In some cases it is just a whitespace difference or ordering >difference. Thanks for providing the data. Regards, S. Moonesamy From spf2@kitterman.com Tue Feb 7 17:29:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7B411E8080 for ; Tue, 7 Feb 2012 17:29:05 -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 jNtyqWDGexvu for ; Tue, 7 Feb 2012 17:29:04 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC4321F875C for ; Tue, 7 Feb 2012 17:29:04 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 608EA20E4126; Tue, 7 Feb 2012 20:29:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328664543; bh=QB63i7YqmpUNvyoKImuI/FMDc0VrcCNH9GEl2a3L1sU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=fFhapt7j0kdNFcY4E/6UIxKPBji+2dt+m73ON5DRKiU1mRNxB+wUvD+XUias/wmYc 9/a0z4d6oJJ0LyurSFtQG+rQxYqEc+j3vf3IBeMB0ym0MRu7gZeNi4HRE6H2i8N6/Q 2GhhRqK1vWJmVB9N5SyyymiHfmOMGpONaDjmk1oM= Received: from scott-latitude-e6320.localnet (unknown [97.67.196.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1987220E4099; Tue, 7 Feb 2012 20:29:02 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 07 Feb 2012 20:29 -0500 Message-ID: <2082691.X55C7MzGmd@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120207081931.07e30b20@resistor.net> References: <6.2.5.6.2.20120207081931.07e30b20@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] Issue: SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 08 Feb 2012 01:29:05 -0000 On Tuesday, February 07, 2012 08:36:47 AM S Moonesamy wrote: > Hi Murray, > > At 10:19 PM 2/6/2012, Murray S. Kucherawy wrote: > >This may be a can of worms, but since we're chartered to tidy up > >where appropriate, I wonder if this might be such a spot. > > > >RFC4408 registered a new DNS RRtype, SPF, code 99. > > > >Are we able to tell how much deployment it's received? If only > >little (which is what I suspect, but I've no data to back that up), > >would it be appropriate to relegate its discussion to an appendix > >and call it "historic"? > > It would help if WG participants could provide data about the > deployment of the DNS RR as part of the request for empirical data. I'm not sure if this qualifies as data or not, but ... I'm one of the upstream maintainers of the Python SPF library (pyspf). Pyspf has supported Type 99 since a few days after the type was allocated to SPF. Due to complaints about issues with badly acting DNS servers we disabled type 99/SPF support by default after a short period. There have been zero complaints about it not being enabled by default. I have reviewed the source of the open source users of pyspf and none of them over-ride this setting. As far as I can tell it's been off for half a decade and no one cared. I also help maintain a Postfix policy server in Perl that uses the Mail::SPF library. It did, for several years, have even the option to turn off type SPF queries. The Mail::SPF developer added the switch after multiple complaints. Based on interactions with multiple open source projects, including large Linux distributions like Debian and Ubuntu, all of the feedback from users I've heard is that type SPF is a problem and it should not be used. Scott K From msk@cloudmark.com Tue Feb 7 23:07:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798C021F85D2 for ; Tue, 7 Feb 2012 23:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHV6Olt2YSxI for ; Tue, 7 Feb 2012 23:07:34 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 72FF721F85C9 for ; Tue, 7 Feb 2012 23:07:34 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Feb 2012 23:07:34 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 7 Feb 2012 23:07:33 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Tue, 7 Feb 2012 23:07:41 -0800 Thread-Topic: Issue: Revisit use of "check_host()" Thread-Index: AczmMFjnZQRIz4cNSEyzRgwp0vQE6A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C9A7DC6AEXCHC2corpclo_" MIME-Version: 1.0 Subject: [spfbis] Issue: Revisit use of "check_host()" X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 08 Feb 2012 07:07:35 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC6AEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm sure some or all of you will be unthrilled that I brought this up, but = nevertheless... The use of "check_host()" in a standards track RFC smacks of us defining an= API, which I think the IETF tries to avoid. (The greybeards in here can c= orrect me if I'm wrong.) After staring at the RFC4408 text for a while, it= seems to me it could be rewritten to avoid this construct without losing a= ny detail. I realize that's a little bit hypocritical coming from one of the co-editor= s of RFC6376, which defined a set of inputs, some outputs (one required, ot= hers optional), and some end states, but RFC4408 is a lot more blatant abou= t it, for example by going so far as naming the function; somehow in my hea= d it crosses a line that RFC6376 avoided. I think it comes down to the dif= ference between specifying a function and describing an algorithm. I'd like us to consider this, even if said consideration in the end lasts o= nly about 90 seconds and consists of solid consensus telling me it's fine t= he way it is. :) -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC6AEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m sure s= ome or all of you will be unthrilled that I brought this up, but neverthele= ss…

 

The use of “check_host()” in a standards track RFC= smacks of us defining an API, which I think the IETF tries to avoid. = (The greybeards in here can correct me if I’m wrong.)  After st= aring at the RFC4408 text for a while, it seems to me it could be rewritten= to avoid this construct without losing any detail.

 

I realize that’= ;s a little bit hypocritical coming from one of the co-editors of RFC6376, = which defined a set of inputs, some outputs (one required, others optional)= , and some end states, but RFC4408 is a lot more blatant about it, for exam= ple by going so far as naming the function; somehow in my head it crosses a= line that RFC6376 avoided.  I think it comes down to the difference b= etween specifying a function and describing an algorithm.

 

I’d like = us to consider this, even if said consideration in the end lasts only about= 90 seconds and consists of solid consensus telling me it’s fine the = way it is.  J<= /p>

 

-MSK=

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC6AEXCHC2corpclo_-- From msk@cloudmark.com Tue Feb 7 23:38:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F035F21F859F for ; Tue, 7 Feb 2012 23:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=1.010, BAYES_00=-2.599, GB_I_LETTER=-2, 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 0NQnX3ybHOVN for ; Tue, 7 Feb 2012 23:38:50 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 87CAC21F859B for ; Tue, 7 Feb 2012 23:38:50 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Feb 2012 23:38:50 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 7 Feb 2012 23:38:49 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Tue, 7 Feb 2012 23:38:57 -0800 Thread-Topic: Issue: ABNF corrections Thread-Index: AczmNLdpnrmcnLa3QN+hY3dQdesk4g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [spfbis] Issue: ABNF corrections X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 08 Feb 2012 07:38:51 -0000 RFC5234 (Section 2.3 in particular) says string literals in ABNFs are actua= lly case-insensitive. That means this: macro-letter =3D "s" / "l" / "o" / "d" / "i" / "p" / "h" / "c" / "r" / "t" ...actually permits all the uppercase versions too. It doesn't seem as tho= ugh that's what we want here given that I don't see in the examples and hav= e never seen in the wild an uppercase macro. I suspect we need to review all the ABNF, but this stood out in my review. From sm@elandsys.com Wed Feb 8 02:43:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B626B21F85ED for ; Wed, 8 Feb 2012 02:43:15 -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 sl0inDGMUe+0 for ; Wed, 8 Feb 2012 02:43:13 -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 69E1A21F85E1 for ; Wed, 8 Feb 2012 02:43:13 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q18Ah1qp029119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2012 02:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328697791; i=@elandsys.com; bh=2As0Bd92FDFLRWVNHwF/rkCpJxMtRwnbtMx1DJ3EpOQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=DDb2h50WVdQjvkZGBu0tX1WjTR6PO62ECdMDrbgOtSDw7nIuSUpE6iZJfZn4b5Iu6 7fE0+IdLWdJ2da5ayY0Ua2kK8reQRSesCkCOoe8MoSdpOBEpjhiZAqQkO1ge87aQHC t78w0fMmesgGjDnViyqIrYWVdfXA2YAyqjstI164= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328697791; i=@elandsys.com; bh=2As0Bd92FDFLRWVNHwF/rkCpJxMtRwnbtMx1DJ3EpOQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=SSmkHJbAPBTUexwWq4/ujpPdLQHLcjyqvbvQZDOTTO5zlt5XkDfNBM+UiUMjIW7FC ocDZfVcR4yPgCcV5Z3aCRENlUrciE7kfxqGSxaXOPBKe/QrriQ23MD5xKYbkiWsS0d 0GQSZdMnKPF0Z9mDGb9zMQdKrDmt+fiKPPXH9X8w= Message-Id: <6.2.5.6.2.20120208023742.04c25ac0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 08 Feb 2012 02:40:37 -0800 To: Scott Kitterman From: S Moonesamy In-Reply-To: <2082691.X55C7MzGmd@scott-latitude-e6320> References: <6.2.5.6.2.20120207081931.07e30b20@resistor.net> <2082691.X55C7MzGmd@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Issue: SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 08 Feb 2012 10:43:15 -0000 Hi Scott, At 05:29 PM 2/7/2012, Scott Kitterman wrote: >I'm not sure if this qualifies as data or not, but ... > >I'm one of the upstream maintainers of the Python SPF library (pyspf). Pyspf >has supported Type 99 since a few days after the type was allocated to SPF. >Due to complaints about issues with badly acting DNS servers we disabled type >99/SPF support by default after a short period. There have been zero >complaints about it not being enabled by default. I have reviewed the source >of the open source users of pyspf and none of them over-ride this setting. I added this to Issue #9 ( http://trac.tools.ietf.org/wg/spfbis/trac/ticket/9 ). Regards, S. Moonesamy From sm@elandsys.com Wed Feb 8 02:51:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D322C21F86DB for ; Wed, 8 Feb 2012 02:51:00 -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=[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 sh6J3NrJkgKb for ; Wed, 8 Feb 2012 02:50:56 -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 D32FF21F86B3 for ; Wed, 8 Feb 2012 02:50:50 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q18AoY4m025873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2012 02:50:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328698240; i=@elandsys.com; bh=6CRorXNm4hsBqaaLk3W8Xpepky9Q3KElkhbDX6X6okM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=eml3e/Rr/UZ+xvU8tOumZRtbXBsa/486rMzQjxVJZjE0yu9jDupGMn1gG7uRygcrv Kxjks0Ude5X8FwFnbxjcGHLCVp/Yy47Nrxz8xmN239Q89GZkNBr1W+CFJF8kiTI3zN ub5DWshMxzklFOaDl0pWG3AhlzThEwr4OLE2iGfA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328698240; i=@elandsys.com; bh=6CRorXNm4hsBqaaLk3W8Xpepky9Q3KElkhbDX6X6okM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=mfCqNKFBsO0W75DwlldCVH+Bf8gPx7RS4T79jFKKPRMnaPUstAthMogGnyE4WST3c /Vn5hz3qKjSu36rIk6jMxygsHpBRL8tYrUJzAbISt0Msf6s1eQe8CZqmpMvLH2uo+o uUO9QD/7zx8mcNlglTXiK0c9vK0ZuS9P6vdfu5cs= Message-Id: <6.2.5.6.2.20120208024500.08e36a88@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 08 Feb 2012 02:47:40 -0800 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Issue: Revisit use of "check_host()" X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 08 Feb 2012 10:51:00 -0000 Hi Murray, At 11:07 PM 2/7/2012, Murray S. Kucherawy wrote: >The use of "check_host()" in a standards track RFC smacks of us >defining an API, which I think the IETF tries to avoid. (The >greybeards in here can correct me if I'm wrong.) After staring at >the RFC4408 text for a while, it seems to me it could be rewritten >to avoid this construct without losing any detail. This is being tracked as Issue #11 ( http://trac.tools.ietf.org/wg/spfbis/trac/ticket/11 ). >I'd like us to consider this, even if said consideration in the end >lasts only about 90 seconds and consists of solid consensus telling >me it's fine the way it is. J All issues raised will be considered by the WG. Regards, S. Moonesamy From hsantos@isdg.net Wed Feb 8 05:00:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C894C21F864F for ; Wed, 8 Feb 2012 05:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cc+My7ZgcHkB for ; Wed, 8 Feb 2012 05:00:20 -0800 (PST) Received: from catinthebox.net (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BB2E821F8606 for ; Wed, 8 Feb 2012 05:00:19 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1716; t=1328706014; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Mp/n2sB35l1kLwXucXTbVFwh0xw=; b=qoa5b5nRbfbof0KPjEDl h45XY0tMLOmwDjIR4FgA/YIy4TBY758Xx0xcE2IqQtyLfNNcJYysT2afLZfDzOzM FdJu09C1kCfm2kfs/yNe3p9rgxkH8dsSHRLAHd52azQ1Us1/C7Vmc06zlDblq+vt d/y7gZ8uE5HFUhvEXUD+xhM= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 08 Feb 2012 08:00:14 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1907872980.69364.2232; Wed, 08 Feb 2012 08:00:13 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1716; t=1328705796; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=pp6oxZT gk9F/c9Q6gviwXntnfibNlXjCFLtzSz2CYJA=; b=iHGwkrmdmuCH/d2FwOJ3qrc g1jOUmsVjSjwXPFeIKvd8yjKG6d/kPAWkv45upvld257dwUaYp6F2x7CvYmM2GL1 +Np4roPyN/ilmX2S8X/24OIOrOtQUbmkpJseugsnUIxKmkBG/piBY+3a0peyl7pZ YbdqXcf3LsBsFVrZL4sU= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 08 Feb 2012 07:56:36 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2506818579.12163.4588; Wed, 08 Feb 2012 07:56:35 -0500 Message-ID: <4F32720F.3080706@isdg.net> Date: Wed, 08 Feb 2012 08:01:03 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120208024500.08e36a88@resistor.net> In-Reply-To: <6.2.5.6.2.20120208024500.08e36a88@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Sullivan , SM Subject: Re: [spfbis] Issue: Revisit use of "check_host()" X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 08 Feb 2012 13:00:20 -0000 Ok, this is starting to concern me. Everyone's issue posted but my own were not added to the issued tracker when I believe my issue is fundamentally realistic about indirectly dealing SENDER-ID with a real RFC that exist and is supported by both senders and receivers. You didn't even give it a chance for discussion and yet added stuff with potentials to get IETF Appeals (Issue #10 shoved down our throats). The fact you choose not to add my issue, tells me this WG is going to be another DKIM with isolation and selective input ending up with up with a terrible Consensus By Osmosis process. Are you deliberately trying to create chaos with this in-your-face ignorance? -- This S Moonesamy wrote: > Hi Murray, > At 11:07 PM 2/7/2012, Murray S. Kucherawy wrote: >> The use of "check_host()" in a standards track RFC smacks of us >> defining an API, which I think the IETF tries to avoid. (The >> greybeards in here can correct me if I'm wrong.) After staring at the >> RFC4408 text for a while, it seems to me it could be rewritten to >> avoid this construct without losing any detail. > > This is being tracked as Issue #11 ( > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/11 ). > >> I'd like us to consider this, even if said consideration in the end >> lasts only about 90 seconds and consists of solid consensus telling me >> it's fine the way it is. J > > All issues raised will be considered by the WG. > > Regards, > S. Moonesamy > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From sm@elandsys.com Wed Feb 8 05:15:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3745421F85F4 for ; Wed, 8 Feb 2012 05:15:50 -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 iWFXRb8b151X for ; Wed, 8 Feb 2012 05:15:48 -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 271C221F8698 for ; Wed, 8 Feb 2012 05:15:48 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q18DFePA001226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2012 05:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328706945; i=@elandsys.com; bh=9/w8cKCW8R5oqC8/onpfQc+5qmrAnyummkDWKwgx+d8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=xEQYNoMDxyRFuFhfJjTKlWhkRAOhL5eaDlZ8XqiGBqrKgtFu8fUoLSMIwwVg1mUbS JYpQ8rgKaxa+2Z99r2srNkyIb58Pt+sJj1GYFsuGgDkfC5FqSPbhNQcS31bjD1CJ1c uwWmKpcsc86xGmDCpO/S7ISrf5EJGoN0N+So/hQ0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328706945; i=@elandsys.com; bh=9/w8cKCW8R5oqC8/onpfQc+5qmrAnyummkDWKwgx+d8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=bOyj3fi9swnZG5jX8tFA+m4i8z0LFqeYhQG2FY0YAoYEC+8FM8yXT6FUOSDRXtEkQ j5mP4s5jmW7OPGvR2Qzmr2AhWmT0JGGtCe4T5XOzP+qR8V4chb+1ed1HuSVMsZgA9S ZrHDswwyvkb4xYpkJr4AFKkMy6eJVBzlXDjGw13o= Message-Id: <6.2.5.6.2.20120208050649.08728830@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 08 Feb 2012 05:13:50 -0800 To: Hector Santos From: S Moonesamy In-Reply-To: <4F32720F.3080706@isdg.net> References: <6.2.5.6.2.20120208024500.08e36a88@resistor.net> <4F32720F.3080706@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan , spfbis@ietf.org Subject: Re: [spfbis] Issue: Revisit use of "check_host()" X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 08 Feb 2012 13:15:50 -0000 Hi Hector, At 05:01 AM 2/8/2012, Hector Santos wrote: >Ok, this is starting to concern me. Everyone's issue posted but my >own were not added to the issued tracker when I believe my issue is >fundamentally realistic about indirectly Would that be Issue #4 ( http://trac.tools.ietf.org/wg/spfbis/trac/ticket/4 )? > dealing SENDER-ID with a real RFC that exist and is supported by > both senders and receivers. You didn't even give it a chance for > discussion and yet added stuff with potentials to get IETF Appeals > (Issue #10 shoved down our throats). Issue #10 was raised in a message to the SPFBIS mailing list. It was added to the tracker like any other issue posted to the mailing list. >The fact you choose not to add my issue, tells me this WG is going >to be another DKIM with isolation and selective input ending up with >up with a terrible Consensus By Osmosis process. See Issue #4. >Are you deliberately trying to create chaos with this in-your-face ignorance? No. Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Wed Feb 8 05:29:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BC321F8585 for ; Wed, 8 Feb 2012 05:29:02 -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 7L+GYvJfBWuF for ; Wed, 8 Feb 2012 05:29:01 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id DCAAC21F8542 for ; Wed, 8 Feb 2012 05:29:01 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id D2DD6D0407F; Wed, 8 Feb 2012 07:29:00 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328707740; bh=TStztpJSU+mPXSHkS/eMm7DQVy9AKWeO3ZPHD4qzb7A=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=V6EumQEvOOOMOIPd8DSUFnVj7oQn92CfsOfali4AD3WcktsmMKKQjLGfkLR3kJNgI cac+9EJmBDWiINwZWSx+i7xiLlYVSRT9M8ThebJcAVGdNRQ77G5yWrLTZZUayrdRrP ZTpKDbsvM53SuM0zSN+p/DCnIM07dNLvEQcM45ks= Received: from 37.sub-97-217-220.myvzw.com (37.sub-97-217-220.myvzw.com [97.217.220.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 1B4AED0400D; Wed, 8 Feb 2012 07:28:59 -0600 (CST) References: <6.2.5.6.2.20120208024500.08e36a88@resistor.net> <4F32720F.3080706@isdg.net> User-Agent: K-9 Mail for Android In-Reply-To: <4F32720F.3080706@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 08 Feb 2012 07:29:09 -0600 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Issue: Revisit use of "check_host()" X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 08 Feb 2012 13:29:02 -0000 Hector Santos wrote: >Ok, this is starting to concern me. Everyone's issue posted but my >own were not added to the issued tracker when I believe my issue is >fundamentally realistic about indirectly dealing SENDER-ID with a real >RFC that exist and is supported by both senders and receivers. You >didn't even give it a chance for discussion and yet added stuff with >potentials to get IETF Appeals (Issue #10 shoved down our throats). > >The fact you choose not to add my issue, tells me this WG is going to >be another DKIM with isolation and selective input ending up with up >with a terrible Consensus By Osmosis process. > >Are you deliberately trying to create chaos with this in-your-face >ignorance? Hector, I wonder if yours might not be left aside because it's outside the scope of the charter? No need for accusations. Scott K From hsantos@isdg.net Wed Feb 8 05:51:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EAE21F85F3 for ; Wed, 8 Feb 2012 05:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.439, 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 jybMl6pD1q75 for ; Wed, 8 Feb 2012 05:50:45 -0800 (PST) Received: from catinthebox.net (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7E03521F85C3 for ; Wed, 8 Feb 2012 05:50:44 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1604; t=1328709034; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=iP2qVPVM5pyUVO4W/JO9gkTvFF0=; b=h7KGReQBBHS1QzCHyuxo Zet93Hk05PpiwFlgWeDNbxw3sthkdKZZYWW8zUVDjfgmflUqIIS887hBZCcs9K0i BaB0zhlSYQlq4wx/k5FX/ThsF76rK7loNleT/mP1PWmf/TkX7yvMjfChnSi/9N8v zbZKuCRwDOGmIIGlZwW7s9o= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 08 Feb 2012 08:50:34 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1910893393.69364.536; Wed, 08 Feb 2012 08:50:34 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1604; t=1328708818; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=qi0O+T8 HBvaJvuvF22z5gQkQ0L++qxv4k3/HMjSkCZ4=; b=Uc+EhtYdwRcNKYhL6txV8Z7 NtxkGQt30THFF/lxYD6FhNu31bKImiFb8i1wJl/v0GVhTmc+d11w9jphq/q3RM5D l5F4Uqe34CKP1EUEpiau68+jvU0YtjwDJ/1z+P1kUJoEKr9Yx6N5q6QHY2XydHEw HXVpG7ZUlT0PBEUp9pYA= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 08 Feb 2012 08:46:58 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2509840626.12170.4116; Wed, 08 Feb 2012 08:46:57 -0500 Message-ID: <4F327DDD.5020208@isdg.net> Date: Wed, 08 Feb 2012 08:51:25 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20120208024500.08e36a88@resistor.net> <4F32720F.3080706@isdg.net> <6.2.5.6.2.20120208050649.08728830@resistor.net> In-Reply-To: <6.2.5.6.2.20120208050649.08728830@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Sullivan , spfbis@ietf.org Subject: Re: [spfbis] Issue: Revisit use of "check_host()" X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 08 Feb 2012 13:51:03 -0000 S Moonesamy wrote: > Hi Hector, > At 05:01 AM 2/8/2012, Hector Santos wrote: >> Ok, this is starting to concern me. Everyone's issue posted but my >> own were not added to the issued tracker when I believe my issue is >> fundamentally realistic about indirectly > > Would that be Issue #4 ( > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/4 )? My sincere apology for not focusing on the all the items listed. I thought I clicked and open all of them. I apparently didn't. My apology. > Issue #10 was raised in a message to the SPFBIS mailing > list. It was added to the tracker like any other issue posted to > the mailing list. Yes, and probably the question is whether allowing a "small thread" to see what may be the "obvious" immediate concerns before adding something to the tracker is warranted. Even my own. For example, in this issue #10, proposed as a replacement as it was stated, IMO, is guaranteed to be controversial and will not be realistically supported by long time established SPF operations and product vendors. Proposed as an alternative is more realistic. So perhaps a small thread to correct the proposal would save time when ISSUE #10 is discussed. IOW, it will be what I will state on this issue. Received-SPF MUST NOT be eliminated in SPF-BIF not because I may or not believe using AUTH-RES is better, but rather because the proposal presumes the 3rd party filters will be in sync with changes and not broken when the SMTP receiver drops support for it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From ajs@crankycanuck.ca Wed Feb 8 06:01:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCB621F86FE for ; Wed, 8 Feb 2012 06:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.373, 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 veD1QnkjWDwN for ; Wed, 8 Feb 2012 06:01:40 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B25F221F86FD for ; Wed, 8 Feb 2012 06:01:40 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B09691ECB41D for ; Wed, 8 Feb 2012 14:01:39 +0000 (UTC) Date: Wed, 8 Feb 2012 09:01:37 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120208140137.GC11204@crankycanuck.ca> References: <6.2.5.6.2.20120208024500.08e36a88@resistor.net> <4F32720F.3080706@isdg.net> <6.2.5.6.2.20120208050649.08728830@resistor.net> <4F327DDD.5020208@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F327DDD.5020208@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 08 Feb 2012 06:05:58 -0800 Subject: Re: [spfbis] Issue: Revisit use of "check_host()" X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 08 Feb 2012 14:01:41 -0000 On Wed, Feb 08, 2012 at 08:51:25AM -0500, Hector Santos wrote: > Yes, and probably the question is whether allowing a "small thread" > to see what may be the "obvious" immediate concerns before adding > something to the tracker is warranted. Sorry, no, it is not, for the reasons we've already outlined more than once. We want to get all the issues out first. If we attempt to have a "small" thread to discuss whether each issue really is an issue, then we will in effect debate all issues twice. We'll never get anything done that way. I ask your indulgence in trying the approach we have asked the WG to use. Thanks, A -- Andrew Sullivan ajs@crankycanuck.ca From hsantos@isdg.net Wed Feb 8 06:10:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F81E21F865F for ; Wed, 8 Feb 2012 06:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.432, 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 8xlWGf1aLPPr for ; Wed, 8 Feb 2012 06:10:27 -0800 (PST) Received: from secure.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA1A21F85F0 for ; Wed, 8 Feb 2012 06:10:26 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1664; t=1328710225; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=fW5L0nT6GT6+usezA2Jlv/9G1oI=; b=bpmY91uDs5t5NPbwVThi PiG0sD/rUSnMWySN7Ri7x0fbaIsOoHtal2hJ7Vou8jtvAZOrBT/D50g0OO+MMlrD Di2x4xzfJjjASFIabjDjtL/ZOc/+cvBfpiHMt5S0zwRTvk5U8LPQuKGsRdt224kN 7D/Z02ZMm0rI+E4cuBb7qHo= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 08 Feb 2012 09:10:25 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1912083634.69364.3352; Wed, 08 Feb 2012 09:10:24 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1664; t=1328710006; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=ZVcFB5e rqFtPFt8wM3cjQvGgmjNbgCXtLCk1iLp+uiw=; b=rr4MKauwRBqxDg10vNtkmLI BkO8E1IDlS2k4Ysf8d7Zc9BtILOV2R6k09gnAOTbyYuUvN1XhbCTsPJOIdnObp9l Q3UsCAIrmMokM8lNGVyA18DBjL9H82g8+28NW1ZR1GSbwtdev1NYtZ0I/QsCDwC6 4tJUY+52vMQ73yrTiXdw= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 08 Feb 2012 09:06:46 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2511029814.12174.6668; Wed, 08 Feb 2012 09:06:46 -0500 Message-ID: <4F328282.60104@isdg.net> Date: Wed, 08 Feb 2012 09:11:14 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <6.2.5.6.2.20120208024500.08e36a88@resistor.net> <4F32720F.3080706@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] Issue: Revisit use of "check_host()" X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 08 Feb 2012 14:10:28 -0000 Scott Kitterman wrote: > > I wonder if yours might not be left aside because it's outside the scope of the charter? I was wrong. It was added. Faulty eyes. :( I don't believe it is out of scope nor should be. The facts are: - RFC 4405 is a SMTP protocol related to SPF non-payload outcomes, - There is large support for it by senders, - I can only speak for our package, but we support (SMTP receiver/forwarder) it. I don't want to see what happen to DKIM with its rigid, unpopular decision to limit the input to the DKIM evaluators when in fact, the reality was there are more parameters, like Author Domain. To me, we should think about the purity of the protocol model for SPF and that does include the possibility of seeing additional input, currently the RFC4405 SMTP extension for the SUBMITTER keyword: 5321.MAIL FROM: [SUBMITTER=PRA] It also relates to issue #11 (check_host) process model description as an algorithm. Although I feel the issuer seems to be describing a different view in issue #11 than what was done in DKIM-BIF. Issuer clarification is needed. Anyway, I feel Issue #4 and Issue #11 are related. The SPF "evaluator" or Check_Host() as it is defined, SHOULD NOT be locked in to just two parameters. It needs to be open ended and in the same way some did not want add specifically AUTHOR-DOMAIN as part of the input (an unrealistic mistake to ignore what was already done), we should not ignore the fact that SUBMITTER may be already realistically part of a SPF implementation for check_host(). -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From sm@elandsys.com Wed Feb 8 08:05:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3A221F8735 for ; Wed, 8 Feb 2012 08:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 orwFQN72jHwJ for ; Wed, 8 Feb 2012 08:05:31 -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 5BADC21F8601 for ; Wed, 8 Feb 2012 08:05:31 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q18G5OaB027395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2012 08:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328717130; i=@elandsys.com; bh=kfojufzJeJ4shi5PL9PjviovfzGXBgeYlIzD3oX6uBY=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=knKy5vxayMRftGso8N1H3O+0WaDmkmL6dw0wNlX49wjC3kDZra3VsdG7VCFbehxJ5 pAhbV9PIqe0D5PVCnm/JU3KRHOUOIdhCeoKUV1ENLN658fX8ANblU1ux6nzxX0Y9bt kdW1gOu82G+MobLK3MD1aWXOwb1Z5mlv6kcD7iTs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328717130; i=@elandsys.com; bh=kfojufzJeJ4shi5PL9PjviovfzGXBgeYlIzD3oX6uBY=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=WYUU1lAQRG/PY3nxUbOG9tOHtjuJu+gINKACZ3xEgkEfXF9dhBjnst2Qd1/w8cXQa zN1n3QXc9y85CaTwh+aJRczOtes4fgYrz+l1nRRNETi9wmKX3pOOx6/srtH0/np1Y1 VwEIk3EY4ZjuPWW4Dd5wl4mgVpaREeAdTMxtPYC8= Message-Id: <6.2.5.6.2.20120208063110.04b7c498@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 08 Feb 2012 06:58:44 -0800 To: Hector Santos From: S Moonesamy In-Reply-To: <4F327DDD.5020208@isdg.net> References: <6.2.5.6.2.20120208024500.08e36a88@resistor.net> <4F32720F.3080706@isdg.net> <6.2.5.6.2.20120208050649.08728830@resistor.net> <4F327DDD.5020208@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Issue: Revisit use of "check_host()" X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 08 Feb 2012 16:05:32 -0000 Hi Hector, At 05:51 AM 2/8/2012, Hector Santos wrote: >My sincere apology for not focusing on the all the items listed. I >thought I clicked and open all of them. I apparently didn't. My apology. It's alright. >Yes, and probably the question is whether allowing a "small thread" >to see what may be the "obvious" immediate concerns before adding >something to the tracker is warranted. Even my own. What may be obvious to me might not be obvious to other WG participants. As an individual, it is easier for me not to have to figure out which questions will generate a "small thread". It's less work for me to add the "questions" into the tracker ( http://trac.tools.ietf.org/wg/spfbis/trac/report/1 ). If I missed an issue or if I misunderstood the issue, WG participants can point it out. Disagreements will happen. We can either talk about them and find an acceptable resolution or we can follow the IETF process to the letter. I have a preference for the first alternative as it is snowing. :-) >For example, in this issue #10, proposed as a replacement as it was >stated, IMO, is guaranteed to be controversial and will not be >realistically supported by long time established SPF operations and >product vendors. Proposed as an alternative is more realistic. So >perhaps a small thread to correct the proposal would save time when >ISSUE #10 is discussed. IOW, it will be what I will state on this >issue. Received-SPF MUST NOT be eliminated in SPF-BIF not because >I may or not believe using AUTH-RES is better, but rather because >the proposal presumes the 3rd party filters will be in sync with >changes and not broken when the SMTP receiver drops support for it. I wonder which issue won't be controversial. :-) Issue #10 is mentioned in a thread about Issue #4. It is more work for me to follow the discussions about the issues when that happens. The work of this working group will span over several months. There is ample time to consider each issue calmly and work towards a resolution based on WG Consensus. Regards, S. Moonesamy From sm@resistor.net Wed Feb 8 08:58:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A278621F8623 for ; Wed, 8 Feb 2012 08:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE-zqUuRZaaD for ; Wed, 8 Feb 2012 08:57:59 -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 AB27E21F851C for ; Wed, 8 Feb 2012 08:57:59 -0800 (PST) Received: from sm-THINK.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 q18GvqVp001205 for ; Wed, 8 Feb 2012 08:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328720276; i=@resistor.net; bh=xu0K5o3aUm8NMkpyQooQEnowR429e3vOap+HxjZ2HJI=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=OKZp+r7sl7KxzUsqwsoPCPXrJJhxsfTUo2WW+TAFGlTwVtiSNUv8abYObf2OEBNbT fEK2JX0kbhC5IYSZMCrgg3T0MVaYhzDo62Kcwx91U+r8pNMz37cEmPidlHh6xZ0G0V L+e4728tchHFy08hjQpb47Hjcj8Yb30DnjlNfddw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1328720276; i=@resistor.net; bh=xu0K5o3aUm8NMkpyQooQEnowR429e3vOap+HxjZ2HJI=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=oKdSScF9Op7z5mRfD0ZoUptPH051U1NmuYcRD7wnNgdMDtcWTNqMTmpm/5vBYyd+W +TkdZxB7ksnRnmArtY2GMPpwevOofPkR7hK4b0p6qsMj8RxkGOO5b+x/fUMM00dSWB USuFAX4jW2AmT18m8TKNf7vSAUQz2tu1pkUNnY/4= Message-Id: <6.2.5.6.2.20120208030852.08a4d988@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 08 Feb 2012 08:24:17 -0800 To: spfbis@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Comments on 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, 08 Feb 2012 16:58:00 -0000 Hello, The following comments are on RFC 4408. Some of them may be out of scope. I avoided getting into editorial comments as far as possible. The RFC 2119 key words should be reviewed. The IESG Note mentions that "Sender ID experiment may use DNS records that may have been created for the current SPF experiment or earlier versions in this set of experiments. Depending on the content of the record, this may mean that Sender-ID heuristics would be applied incorrectly to a message. Depending on the actions associated by the recipient with those heuristics, the message may not be delivered or may be discarded on receipt". I suggest that the WG considers the above. The IESG Note also mentions that "Participants publishing SPF experiment DNS records should consider the advice given in section 3.4 of RFC 4406 and may wish to publish both v=spf1 and spf2.0 records to avoid the conflict". I suggest using data gathered to determine whether the advice was followed. "Participants in the Sender-ID experiment need to be aware that the way Resent-* header fields are used will result in failure to receive legitimate email when interacting with standards-compliant systems (specifically automatic forwarders which comply with the standards by not adding Resent-* headers, and systems which comply with RFC 822 but have not yet implemented RFC 2822 Resent-* semantics)". I suggest taking the above into consideration for the "conclusion" document. In Section 2.4: "When a mail receiver decides to perform an SPF check, it MUST use a correctly-implemented check_host() function (Section 4) evaluated with the correct parameters". RFC 2119 key words should be used for interoperability. A requirement to use a correctly-implemented function with correct parameters comes out as stating the obvious. In Section 2.5: "The authorization check SHOULD be performed during the processing of the SMTP transaction that sends the mail." The "that sends the mail" is superfluous in the above. In Section 2.5.4: "If the information does not originate with the checking software, it should be made clear that the text is provided by the sender's domain. For example: 550-5.7.1 SPF MAIL FROM check failed: 550-5.7.1 The domain example.com explains: 550 5.7.1 Please see http://www.example.com/mailpolicy.html" It is better not to document the multiline response as it comes out as a recommendation. In Section 2.5.5: 'The domain owner wants to discourage the use of this host and thus desires limited feedback when a "SoftFail" result occurs.' I suggest avoiding terms such as "domain owner". 'For example, the recipient's Mail User Agent (MUA) could highlight the "SoftFail" status, or the receiving MTA could give the sender a message using a technique called "greylisting" whereby the MTA can issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the first time the message is received, but accept it the second time.' It is better not to encourage a "greylisting" technique in this specification as it is more of an "antispam" technique than one about "sender policy". In Section 2.5.6: "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 DSN code." The "4.4.3" is an extended status code. It is not a "DNS code". The extended status code used is incorrect. In Section 3.1.1: "It is recognized that the current practice (using a TXT record) is not optimal, but it is necessary because there are a number of DNS server and resolver implementations in common use that cannot handle the new RR type. The two-record-type scheme provides a forward path to the better solution of using an RR type reserved for this purpose. An SPF-compliant domain name SHOULD have SPF records of both RR types." This "SHOULD" is not being followed. In Section 3.1.4: "The published SPF record for a given domain name SHOULD remain small enough that the results of a query for it will fit within 512 octets." "Records that are too long to fit in a single UDP packet MAY be silently ignored by SPF clients." I suggest either setting a maximum size for the record or reconsidering the text about ignoring a SPF record. BTW, some implementation encountered issues with DNS TXT record parsing. The example in Section 3.1.5 about wildcard records should be rewritten. In Section 5.4: 'Note regarding implicit MXs: If the has no MX records, check_host() MUST NOT pretend the target is its single MX, and MUST NOT default to an A lookup on the directly. This behavior breaks with the legacy "implicit MX" rule. See [RFC2821], Section 5. If such behavior is desired, the publisher should specify an "a" directive.' This paragraph should be updated to cover IPv6. In Section 5.5: "If a DNS error occurs while doing an A RR lookup, then that domain name is skipped and the search continues." AAAA RRs should also be taken into account. In Section 7: 'Other keys may be defined by SPF clients. Until a new key name becomes widely accepted, new key names should start with "x-".' "x-" is being deprecated. "SPF clients MUST make sure that the Received-SPF header field does not contain invalid characters, is not excessively long, and does not contain malicious data that has been provided by the sender." The above requirement is subject to interpretation. In Section 9.3: '[RFC1123] and [RFC2821] describe this action as an "alias" rather than a "mail list".' The mail transport material in RFC 1123 has been replaced in RFC 5321. In Section 10.4: "Another means to verify the identity of individual users is message cryptography such as PGP ([RFC2440]) or S/MIME ([RFC3851])." The term generally used is "digital signatures". The normative references should be updated to RFC 5321, RFC 5322 and RFC 5234. The informative reference for SUBMIT should be updated to RFC 6409. The references for RMX, DMP, Vixie and Green should be removed if there aren't stable references to the material. Regards, -sm From pgladstone@cisco.com Wed Feb 8 09:27:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FB921F876C for ; Wed, 8 Feb 2012 09:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.966 X-Spam-Level: X-Spam-Status: No, score=-4.966 tagged_above=-999 required=5 tests=[AWL=1.633, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-dZARj1OpVX for ; Wed, 8 Feb 2012 09:27:10 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADEA21F8693 for ; Wed, 8 Feb 2012 09:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=652; q=dns/txt; s=iport; t=1328722023; x=1329931623; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=nZW0iOnLBQQuAWTT8xe5sgugCFV4hZJ5CV8cLc11xIM=; b=bOkD7boM0TR9DoXibng4lcC5OGltNuS6Yd8QHwB1bPjkuRy7k4xtYGwP 4z4o++rBr/ja+aBqLVZCH70drbpN2wIBDqCE3DJnls2pspG1JPL7KHibz sP6KGxCfbCH6r0KmPHj/OH2AhMdevAdKWsLSmus4A4BOcn7TcLKbQ9Py9 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANivMk+rRDoG/2dsb2JhbABDhQ2nToIrgQeBcgEBAQQSARAVQBELGAICBRYLAgIJAwIBAgFFEwgBAR6iQAGMZZIAgS+KHAEHAgIJBQ0DEwEIBQMDCRwDAYJxGQQDDAMUBVcNAQQEO4IHgRYEiEaMZ4VYjSM X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="29406961" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 08 Feb 2012 17:27:03 +0000 Received: from [161.44.106.141] (dhcp-161-44-106-141.cisco.com [161.44.106.141]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q18HR2LE031098 for ; Wed, 8 Feb 2012 17:27:03 GMT Message-ID: <4F32B066.5080908@cisco.com> Date: Wed, 08 Feb 2012 12:27:02 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120208030852.08a4d988@elandnews.com> In-Reply-To: <6.2.5.6.2.20120208030852.08a4d988@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Comments on 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, 08 Feb 2012 17:27:10 -0000 On 2/8/2012 11:24 AM, SM wrote: > > The IESG Note also mentions that "Participants publishing SPF > experiment DNS records should consider the advice given in section 3.4 > of RFC 4406 and may wish to publish both v=spf1 and spf2.0 records to > avoid the conflict". In my list of collected records, I have 578 v=spf2 records. This is an underestimate as it turns out that I only saved the *first* spf record if there were multiple (Yes, my bad). However, if we assume that the ordering of TXT RRs is random, then this would indicate that maybe 1200 domains have both records (out of 278,000 which have at least one). Philip From spf2@kitterman.com Wed Feb 8 19:09:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1AF21F8589 for ; Wed, 8 Feb 2012 19:09:36 -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 H69kOjXfpOvo for ; Wed, 8 Feb 2012 19:09:35 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 61F4B21F84F3 for ; Wed, 8 Feb 2012 19:09:35 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 26F4220E4126; Wed, 8 Feb 2012 22:09:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328756974; bh=MzO1xf1vpuD+8Mp1IVI2q/z4DyLPJSwhdBdL6LnWAQA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=fFBhtO7NxgRplI6CFtvG0QrQ+fAhugT2cSJ0xz+zujq8vmKZZru19FMZsQ1IlYDVj rmAG8tAvoC+V/oWCm/zgQmXMqWOkFmZYUnZjicDIRYCS0gwy+nYiJ9ecb2cqj0B9L/ dF0yEqqDNHLGGB+9kFNRWU4/Wd1+eDiWMZBQQmNA= Received: from scott-latitude-e6320.localnet (unknown [97.67.196.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DDC9520E4064; Wed, 8 Feb 2012 22:09:33 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 08 Feb 2012 22:09:30 -0500 Message-ID: <1896220.Oye2VyZlgz@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120208030852.08a4d988@elandnews.com> References: <6.2.5.6.2.20120208030852.08a4d988@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Comments on 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: Thu, 09 Feb 2012 03:09:36 -0000 On Wednesday, February 08, 2012 08:24:17 AM SM wrote: ... > The example in Section 3.1.5 about wildcard records should be rewritten. ... This is a proposed solution to an issue, not an issue. I think while we are collecting issues, it's important to have a clear statement of what problem in RFC 4408 has been found that needs to be solved. Scott K From pgladstone@cisco.com Thu Feb 9 06:57:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B4F21F84EF for ; Thu, 9 Feb 2012 06:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lymmFmo4aB-f for ; Thu, 9 Feb 2012 06:57:23 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id B0D8521F84D1 for ; Thu, 9 Feb 2012 06:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=1452; q=dns/txt; s=iport; t=1328799443; x=1330009043; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=LMVwMVr2OvBsZo3oxeq8lPH4D2vC0KF7IUcsPmdOhRw=; b=NeH3vaVwvptpKVE2UQs021nu7OWZnkXM0rMBSAb9epdTNM+Ma9ftHYpg fKpN9Vm+G+PNKFTw0ajKRk4ZqrMd9HYT0vEixd70gtX+/8zspbXE25wj4 VfrR65nKf5hok1B4DmUlPxB5qIrAJIDiMgnjhsKwVSwBi0DyWiREUZkJz Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsEABzeM09Io8UY/2dsb2JhbABEhQ+nbYMzgXIBAQEEEgEQFUARCxgCAgUWCwICCQMCAQIBRRMIAQEeolgBjGWSLYEvihIHCgkdBREBBQQDBAsCBwUGAQMCFAESBoNgAwZ2ggeBFgSISIxohVqNJg X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="5192266" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 09 Feb 2012 14:57:21 +0000 Received: from [161.44.106.141] (dhcp-161-44-106-141.cisco.com [161.44.106.141]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q19EvJWl025482 for ; Thu, 9 Feb 2012 14:57:20 GMT Message-ID: <4F33DECC.8080504@cisco.com> Date: Thu, 09 Feb 2012 09:57:16 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120203215158.GQ4322@mail.yitter.info> <4F2FD9A4.1040108@cisco.com> <6.2.5.6.2.20120206062507.08f22c00@resistor.net> <4461618.x9P3vB2UHx@scott-latitude-e6320> <4F301208.3090800@cisco.com> In-Reply-To: <4F301208.3090800@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Request for experimental evidence X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 09 Feb 2012 14:57:23 -0000 On 2/6/2012 12:46 PM, Philip Gladstone wrote: >> > Over the last 4 days, I see 57 IP addresses forwarding emails that > were originated from my domain. I *think* that all of these are > actually valid forwards (but not doing the appropriate SRS rewriting), > though I suspect that there are implementation problems in certain SPF > implementations. > > For example, > > 98.136.219.60: ostmaster > 98.138.215.201: ostmaster > 98.138.91.117: postmaster > 98.138.91.60: postmaster > 98.139.165.31: ostmaster > 98.139.165.55: ostmaster > > This says that the addresses forwarded mail from postmaster@mydomain > and ostmaster@mydomain. I suspect that the 'ostmaster' is a bug in the > evaluation of the %{l1r-} macro. > > I also see > > 209.68.2.48: bounces.wxqc > > This indicates that (probably) wxqc-bounces was the originator and the > %{l1r-} did not get evaluated correctly (two components were returned) > > 128.186.98.3: ouncces.wxqc > > This is weirdest -- it looks like another bug. (I see this particular > error from two other IPs as well. > > Philip > I think that this points out a potential issue: * It is not easy/generally possible to find where a broken implementation of SPF is. While I can see where the bad DNS request comes from, this doesn't help as the address belongs to an DNS recursive name server. I don't know how to solve it, but it is an operational issue. Philip From vesely@tana.it Fri Feb 10 04:04:14 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5926721F863D for ; Fri, 10 Feb 2012 04:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.643 X-Spam-Level: X-Spam-Status: No, score=-4.643 tagged_above=-999 required=5 tests=[AWL=0.076, 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 zYVyX7DDg2Xy for ; Fri, 10 Feb 2012 04:04:08 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2806F21F861E for ; Fri, 10 Feb 2012 04:04:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328875447; bh=7qhBV4JbRWZUXTcPvdOXIjz6ZnVSfW3RFDY5al9rGiE=; l=1284; h=Message-ID:Date:From:MIME-Version:To:Content-Transfer-Encoding; b=bM8KN+q+jMqQFcU1lvuOs9Ck+axR86Ysm3+Ify5I2W//hgZVyPjJe4jqxsrdmBKaB Har4zsMAlJsp3hLBNxTeBJC16t9AJG4IYlRi9fsdsTHN36sE9xgYRKt2wNu41+opfs RoFoW9dM7LgvCl7ewB9nNs6/v/bhVx4kUrFWmtHM= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 10 Feb 2012 13:04:07 +0100 id 00000000005DC042.000000004F3507B7.000025E8 Message-ID: <4F3507B6.3040702@tana.it> Date: Fri, 10 Feb 2012 13:04:06 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [spfbis] Issue: forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 12:04:14 -0000 The advice given in the non-normative Section 9 is misleading. On the one hand, it provides overly cumbersome techniques based on macros that are not universally considered safe. On the other hand, it fails to state the obvious point that a return-path is only needed if someone is going to care about delivery failures. When an email alias refers to an external domain, the forwarder must change it. This has to be normative, and update Section 3.9.1 of [RFC5321] --not one of the best written sections of that paper. Forwarding à la MAIL FROM:<> should be mentioned as the default, easiest way to re-inject messages. The implied interoperability is that the owner of the target mailbox must be aware of a given "forwarding recipe", and be able to modify or delete it. The variation MAIL FROM: is necessary when a postmaster's action is needed for modifying/deleting a given recipe. SRS should be mentioned as a general purpose variation for extended forwarding needs. The spec should say that an SPF record must be defined for every A or AAAA record, irrespectively of whether its host label also appears in some MX RRs. We should encourage the use of _spf labels and redirect= for designing sound and maintainable SPF compliance. From sm@elandsys.com Tue Feb 14 10:12:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B45621E807E for ; Tue, 14 Feb 2012 10:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5T12Y+M9wHD for ; Tue, 14 Feb 2012 10:12:13 -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 BADB321F86F9 for ; Tue, 14 Feb 2012 10:11:42 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.233.105]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1EIBTGF006854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Feb 2012 10:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329243101; i=@elandsys.com; bh=BptqV7JL5wh3P/PpLLDXnVIuYRCoho3qL+TE189ayyY=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=u8DBKUiG++/rV8/zFSPvJtuYlsz0EHiDupvPZOB2iqr6NA66CyvuB4YxS8g0WHG3s GjCyUMZLuT/4FI4UIYKsUvHAoAGLP5mS3aAziRbX43rp0Ikkw9Y54WxE4kasSik8wt /A7e+Vf41CUNZYZ/CTa/PLKpoA+sVbxWCOkH251w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329243101; i=@elandsys.com; bh=BptqV7JL5wh3P/PpLLDXnVIuYRCoho3qL+TE189ayyY=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=2S6Qzv2dYlUM9ynBXs99HcGaAk8k3wF4monOd3r1VbrGR25LSxeUTi5bLNZsjDYNf PuPvByRIWJjehAcSSqZgVBTagJ8bdfJIfvWHryjIwaNgiDJlNGe6t4Z2IQbh1nmFBr Mr8kFW9OnYkI1Nyo4vd5aMivrSC20mTERa1niXdw= Message-Id: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 14 Feb 2012 10:10:51 -0800 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 18:12:18 -0000 Hello, We asked that people get their issues together by 18 February. The following issues have been posted to the tracker ( http://trac.tools.ietf.org/wg/spfbis/trac/report/1 ): 1. RFC 4408 Section 2.5.6 - Temporary errors 2. RFC 4408 Section B.3 - Errata #2250 3. RFC 4408 - Errata #99 4. RFC 4408 Section 4.1 5. RFC 4408 ambiguities 6. RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization 7. RFC 4408 Downcase result names in spec text and ABNF 8. RFC 4408 Mixed use of RFC2119 words 9. RFC 4408 SPF RR type 10. RFC 4408 replace Received-SPF with RFC5451 11. RFC 4408 Section 4 check_host() function 12. RFC 4408 Section 9 - Forwarding and helo identities Can working group participants please review RFC 4408 and post issues by Saturday? Thank you Andrew Sillivan & S. Moonesamy, SPFBIS WG co-chairs From spf2@kitterman.com Tue Feb 14 10:32:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4B821E8092 for ; Tue, 14 Feb 2012 10:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 4WZvDfO5az6y for ; Tue, 14 Feb 2012 10:32:19 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1063A21F86E1 for ; Tue, 14 Feb 2012 10:32:12 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 30B7A20E40BB; Tue, 14 Feb 2012 13:32:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329244331; bh=nbUG15r0b5jiL9b1voCBjjjItlpF6sk1aJSIUEEl4Nc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=o+QReCRqAg+MVW9QOVQhINTZ+vRIp22oa3ejtZnIGVUab4AqSax/2ZlMg2HZSrx/F 20eqlm7Va9Sjy3AHMaB2VHNOB0Sm7J+j3g0irq07xemopBN6cPpDdFviacXsn+3zlj 1myQk1bUVAakx2HEpvAhcBIQ3G7XurXgq7jBZKeo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 13DFC20E4099; Tue, 14 Feb 2012 13:32:10 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 14 Feb 2012 13:32:10 -0500 Message-ID: <2496430.O56CJKdbli@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 18:32:19 -0000 On Tuesday, February 14, 2012 10:10:51 AM S Moonesamy wrote: > Hello, > > We asked that people get their issues together by 18 February. The > following issues have been posted to the tracker ( > http://trac.tools.ietf.org/wg/spfbis/trac/report/1 ): > > 1. RFC 4408 Section 2.5.6 - Temporary errors > 2. RFC 4408 Section B.3 - Errata #2250 > 3. RFC 4408 - Errata #99 > 4. RFC 4408 Section 4.1 > 5. RFC 4408 ambiguities > 6. RFC 4408 Section 10.1 - Processing limits needs clarification > and reorganization > 7. RFC 4408 Downcase result names in spec text and ABNF > 8. RFC 4408 Mixed use of RFC2119 words > 9. RFC 4408 SPF RR type > 10. RFC 4408 replace Received-SPF with RFC5451 > 11. RFC 4408 Section 4 check_host() function > 12. RFC 4408 Section 9 - Forwarding and helo identities > > Can working group participants please review RFC 4408 and post issues > by Saturday? I'm probably just being a bit thick today, but what are you asking us to do that's different than what we just did? Confused, Scott K From sm@elandsys.com Tue Feb 14 10:52:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2967821E80B7 for ; Tue, 14 Feb 2012 10:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeY-KyCUR6NN for ; Tue, 14 Feb 2012 10:52:12 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5347C21E8087 for ; Tue, 14 Feb 2012 10:52:08 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.233.105]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1EIpsJN006863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 10:52:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329245527; i=@elandsys.com; bh=geHy3xk7nWz6sEmDr+Un7ylPuAntAwBa105B/xSJcQo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=aUDFNuO+FO+h7yw0EoLcbNsa6jbSNJfAbU4iAvAcm2qHM+eWQbbhQPHhN+JT2cvBG RgMeCzC2x2t8vz9xJ7GL8hlS73pQ/H6sLSfIXusiom8S6BgEb3AA7nIxRTlH3fMwN+ Iat9x1dyDwSvav0V3b9659BwSzzBy4LxG5B8aUmE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329245527; i=@elandsys.com; bh=geHy3xk7nWz6sEmDr+Un7ylPuAntAwBa105B/xSJcQo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=hjXp936MDt9/MTCVQjP3/wm5fpBonWQ+MaZfiDwQmAgi1RVWTHfNnQQI4uIdz6amI 28f3KdzXFaOyx3QKL73RqsLrinGcI6MHSuew0M7fjPRxKertHdj5dA6kY+FEEAvD75 Uy3LzUDHOzmsZ3gokfS+ldvrs8oqSmyIJ1nfB8ow= Message-Id: <6.2.5.6.2.20120214104201.09d15500@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 14 Feb 2012 10:50:37 -0800 To: Scott Kitterman From: S Moonesamy In-Reply-To: <2496430.O56CJKdbli@scott-latitude-e6320> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <2496430.O56CJKdbli@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 18:52:18 -0000 Hi Scott, At 10:32 14-02-2012, Scott Kitterman wrote: >I'm probably just being a bit thick today, but what are you asking us to do >that's different than what we just did? It's a reminder. If you have not posted your issue yet, it would be help to the WG chairs if you could post them by Saturday. If you have already posted issues, they should be in the tracker. Regards, S. Moonesamy SPFBIS WG co-chair From hsantos@isdg.net Tue Feb 14 13:27:59 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBE921F8661 for ; Tue, 14 Feb 2012 13:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvVyTNqGEx8G for ; Tue, 14 Feb 2012 13:27:58 -0800 (PST) Received: from ntbbs.santronics.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C1B9021F859B for ; Tue, 14 Feb 2012 13:27:54 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1418; t=1329254870; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=gdeq5fvoP+JBsxK2VAiGT0cFH58=; b=UcFGyCHItdOJBtSAI+wr 6FVH4jKIIM5Umxe4nl5koJ7j7LsYBrm6rjo9uKNC4Qv7PssWHLIgZN1xNIKmOHWL q62ji29eQMOpUtFmimqoasvUbBGvOp/EfQ10j2Stb82zZo240jyw1scUV8ybf62i qcwh6fxGV35yrQ8m9PrABYI= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 14 Feb 2012 16:27:50 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2456723279.78135.5368; Tue, 14 Feb 2012 16:27:50 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1418; t=1329254644; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=J1rdvgK mxGqBcD1UBbfWhSDxte9t7fymW9dBnyC1syg=; b=KCKehRh68qeBIh5fL8vk/Gq /BttUmtOr9JmA7HtNPwHqpaTh5HX+4BGhceWtr27vDK7IPei7lmoLVFuX8Sz+Kjv iCK3MJ636o5j3+OqGuYYcaDm/Z4MBJ0FinICI/1LPvg3LWctfS3r31hvUVUVhTMG 5t67SutCWHUoYsbMk5t4= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 14 Feb 2012 16:24:04 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3055666673.16406.5408; Tue, 14 Feb 2012 16:24:03 -0500 Message-ID: <4F3AD1E2.8090305@isdg.net> Date: Tue, 14 Feb 2012 16:28:02 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> In-Reply-To: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 21:27:59 -0000 Sorry, Saturday is too short for (for me, time wise). SM, SPF-BIS is too important for such an aggressive schedule. With the lack of discussion on the issues already cataloged, I sense there is going to a very heavy burden with quick decisions made. S Moonesamy wrote: > Hello, > > We asked that people get their issues together by 18 February. The > following issues have been posted to the tracker ( > http://trac.tools.ietf.org/wg/spfbis/trac/report/1 ): > > 1. RFC 4408 Section 2.5.6 - Temporary errors > 2. RFC 4408 Section B.3 - Errata #2250 > 3. RFC 4408 - Errata #99 > 4. RFC 4408 Section 4.1 > 5. RFC 4408 ambiguities > 6. RFC 4408 Section 10.1 - Processing limits needs clarification and > reorganization > 7. RFC 4408 Downcase result names in spec text and ABNF > 8. RFC 4408 Mixed use of RFC2119 words > 9. RFC 4408 SPF RR type > 10. RFC 4408 replace Received-SPF with RFC5451 > 11. RFC 4408 Section 4 check_host() function > 12. RFC 4408 Section 9 - Forwarding and helo identities > > Can working group participants please review RFC 4408 and post issues by > Saturday? > > Thank you > Andrew Sillivan & S. Moonesamy, SPFBIS WG co-chairs > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From sm@elandsys.com Tue Feb 14 14:14:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2D821F85A4 for ; Tue, 14 Feb 2012 14:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IwVQRgwvpzV for ; Tue, 14 Feb 2012 14:14:22 -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 D6BDF21E80ED for ; Tue, 14 Feb 2012 14:14:20 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.233.105]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1EME4hY010543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 14:14:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329257657; i=@elandsys.com; bh=ce6/hCUifGzL7Kxep1ST+EfSWrsr2I0cXLsLeFk07h8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=UKLVn5A2KSWrpa5ovuED8RJzA2qd3oHgvcI76S3oXIwEtvfEBrjRdsrO3x/pY8cYl LBFmQvHdVm3f5+OkNJI38IKPLjX3dGfAnVRGJGh62MGU7vD9vlMoCW6ERHYDz11DZt EuGMOsXkpIXj6wXtkHLnIbCKyOBaeaIgBxzCI/pc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329257657; i=@elandsys.com; bh=ce6/hCUifGzL7Kxep1ST+EfSWrsr2I0cXLsLeFk07h8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=fsXqniGsv/MAnFSm6We3Snig1BVdivs5mkfHc8TPG01jyUDoTYLvZZjFCDhPFS+jT gMNghf2MMBUnRdC2yx4OlfeWmLdiROLqjrY5DxLQbItwBF5v/zUWdjGDGJfDUfZ6VW G2+2OIAFF+Oqbb02SIWi8XUXdRVaLI2FiD5KNFdA= Message-Id: <6.2.5.6.2.20120214135907.074e8870@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 14 Feb 2012 14:13:36 -0800 To: Hector Santos From: S Moonesamy In-Reply-To: <4F3AD1E2.8090305@isdg.net> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3AD1E2.8090305@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 22:14:23 -0000 Hi Hector, At 13:28 14-02-2012, Hector Santos wrote: >Sorry, Saturday is too short for (for me, time wise). SM, SPF-BIS is >too important for such an aggressive schedule. With the lack of >discussion on the issues already cataloged, I sense there is going >to a very heavy burden with quick decisions made. Andrew, as SPFBIS WG co-chair, posted a message on February 7 about nobody objecting to the deadline ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00353.html ). From the above, I gather that you need more time. What date would be convenient for you? Regards, S. Moonesamy SPFBIS WG co-chair From ajs@anvilwalrusden.com Tue Feb 14 14:45:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7183A21E8028 for ; Tue, 14 Feb 2012 14:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 hRv+y91A27fR for ; Tue, 14 Feb 2012 14:45:42 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2D77021E8016 for ; Tue, 14 Feb 2012 14:45:41 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 964541ECB41C for ; Tue, 14 Feb 2012 22:45:33 +0000 (UTC) Date: Tue, 14 Feb 2012 17:44:57 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120214224450.GE22144@mail.yitter.info> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3AD1E2.8090305@isdg.net> <6.2.5.6.2.20120214135907.074e8870@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6.2.5.6.2.20120214135907.074e8870@resistor.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 22:45:43 -0000 On Tue, Feb 14, 2012 at 02:13:36PM -0800, S Moonesamy wrote: > Hi Hector, > At 13:28 14-02-2012, Hector Santos wrote: > >Sorry, Saturday is too short for (for me, time wise). […] > From the above, I gather that you need more time. What date would > be convenient for you? Perhaps we could take another approach. Hector, as you note, there are already several issues catalogued. I'd like to suggest that we begin discussions of some of the already-enumerated issues while you are still working on your list of issues. It seems to me that we can make progress on some issues while others find new issues. After all, it's not as though we're closing the list of issues forever before we start discussing issues: if a new issue emerges from the discussion, we're not going to rule it out of order. Similarly, the point here is to take only a few issues at a time, so there will still be some in the queue after the 18th. The point of the artificial deadline of the 18th was to collect as many issues as we could in order to prioritize items in discussion. If every issue hasn't been exposed by then, it's not the end of the world; we certainly have some things to chew on already. So in the absence of a really compelling reason to hold off, SM and I will pick some issues to start discussion on later this week. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Wed Feb 15 16:05:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A9D21E80CD for ; Wed, 15 Feb 2012 16:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CP7H4HnJDYMw for ; Wed, 15 Feb 2012 16:05:16 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4305C21E80D0 for ; Wed, 15 Feb 2012 16:05:16 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Feb 2012 16:05:15 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 15 Feb 2012 16:04:37 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Wed, 15 Feb 2012 16:04:20 -0800 Thread-Topic: [spfbis] RFC 4408 issues list Thread-Index: AczrRDGPlZyRPG9jSOeWIYvs57Xg2QA+hlSg Message-ID: References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> In-Reply-To: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 00:05:16 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of S Moonesamy > Sent: Tuesday, February 14, 2012 10:11 AM > To: spfbis@ietf.org > Subject: [spfbis] RFC 4408 issues list >=20 > Can working group participants please review RFC 4408 and post issues > by Saturday? I've posted my issues from my review already, but I'd like to point out tha= t I'll be mentioning this work at the MAAWG conference next week, and we mi= ght collect some new participants and/or feedback from that since SPF is ne= ar and dear to many that will be attending. I will forward what I get from= that and encourage them to get involved directly, but that may mean some i= ssues are raised after your deadline. I hope that's okay, or if not would = we consider pushing the deadline out a week or two? -MSK From spf2@kitterman.com Wed Feb 15 16:11:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE58321F849A for ; Wed, 15 Feb 2012 16:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 ISmkM5HHpNZ6 for ; Wed, 15 Feb 2012 16:11:17 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E4AE921F843E for ; Wed, 15 Feb 2012 16:11:10 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7BDF220E40BB; Wed, 15 Feb 2012 19:11:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329351070; bh=pOU1aHzKKl2+0n/YizPxmQIBgR90DxMZxZrq/25di0A=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ZPFUXEyLcfzg+xMfeFXr0IMwnBGDZWKzCAMVdbWE4Y+iFA/c5K5/0o5IFdqezD/wq xC9CXxikkBvol+PaYO5do+tEvboZZlXNljV5GV/1LyTFA4twmc7fTV0ky5BXZCeDZs 5ITMKhUl/BKWZHMk2XLXIokEP+7TAVcM9P3EzKqw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 61E4920E4064; Wed, 15 Feb 2012 19:11:10 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 15 Feb 2012 19:11:09 -0500 Message-ID: <2563909.ciMj4PbRPU@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 00:11:26 -0000 On Wednesday, February 15, 2012 04:04:20 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of S Moonesamy Sent: Tuesday, February 14, 2012 10:11 AM > > To: spfbis@ietf.org > > Subject: [spfbis] RFC 4408 issues list > > > > Can working group participants please review RFC 4408 and post issues > > by Saturday? > > I've posted my issues from my review already, but I'd like to point out that > I'll be mentioning this work at the MAAWG conference next week, and we > might collect some new participants and/or feedback from that since SPF is > near and dear to many that will be attending. I will forward what I get > from that and encourage them to get involved directly, but that may mean > some issues are raised after your deadline. I hope that's okay, or if not > would we consider pushing the deadline out a week or two? As Andrew Sullivan already said in another message in this thread, it's not like new issues can't be considered later. RFC 4408 is approaching it's sixth birthday. I think there's been lots of time for people to consider it. I'd prefer for us to get started and look at new issues later if any emerge. Scott K From msk@cloudmark.com Wed Feb 15 16:18:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0EF21E80AC for ; Wed, 15 Feb 2012 16:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACzPLL4WZc+7 for ; Wed, 15 Feb 2012 16:18:30 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 22B3021E801D for ; Wed, 15 Feb 2012 16:18:30 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Feb 2012 16:18:29 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 15 Feb 2012 16:18:23 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Wed, 15 Feb 2012 16:15:01 -0800 Thread-Topic: [spfbis] RFC 4408 issues list Thread-Index: AczsP5rlCTpYn+RJQvSo/KwRoUoengAAE+TA Message-ID: References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <2563909.ciMj4PbRPU@scott-latitude-e6320> In-Reply-To: <2563909.ciMj4PbRPU@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 00:18:31 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Wednesday, February 15, 2012 4:11 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] RFC 4408 issues list >=20 > As Andrew Sullivan already said in another message in this thread, it's > not like new issues can't be considered later. Fair enough; then I guess I'm just mentioning that I might have a bunch of = other feedback after next week. No reason to hold us up. -MSK From hsantos@isdg.net Thu Feb 16 07:44:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C265321F87EA for ; Thu, 16 Feb 2012 07:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.784 X-Spam-Level: X-Spam-Status: No, score=-0.784 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLL6LUgBrotg for ; Thu, 16 Feb 2012 07:44:11 -0800 (PST) Received: from catinthebox.net (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 83A0821F85DA for ; Thu, 16 Feb 2012 07:44:11 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2285; t=1329407043; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=dmQPlbAFHWI9WTPEaA1sdj6J770=; b=KnFvHSCufWs5I5g+zVPL EvHoXw2QTC2Ee020VPdY2MKuXTW+HQnntslNus6QqlXP74nKD9qxFB3D0ydS2Nfz pW0lTn1mMeDaorO0qOLX1ay5E7uSmPfYZxAS7eUIYOKLYBbU2foIPjubZuN9NdUC o0nWsFI0bo5uBwRoRAw3rRE= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 16 Feb 2012 10:44:03 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2608894719.81277.5664; Thu, 16 Feb 2012 10:44:03 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2285; t=1329406815; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0pF2/1D HyreaAVK0LvAWZ/AfSBtEX7q9CZsOASTp4sg=; b=kWbcIHKWkcvXK5trFQDD5l6 +S521xRMbPUy9xeBrEkr41hYo/nLbuQ44nu5PEkdnOrpWcYeENND9BUn/m3JaaPf YwtfRz7eQZcUp2fJtpalS2PJEAPpFb6Tb8jLVx5OfcGmjvy165qsFGhUQBjlp9f+ 0WgT5//KGvK7eFzaP9LM= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 16 Feb 2012 10:40:14 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3207837033.16721.4784; Thu, 16 Feb 2012 10:40:13 -0500 Message-ID: <4F3D2465.4060301@isdg.net> Date: Thu, 16 Feb 2012 10:44:37 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andrew Sullivan References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3AD1E2.8090305@isdg.net> <6.2.5.6.2.20120214135907.074e8870@resistor.net> <20120214224450.GE22144@mail.yitter.info> In-Reply-To: <20120214224450.GE22144@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:44:17 -0000 +1. My thoughts: - Mixed discipline environment, can't expect the same level of detail reviews across the board in the agenda sought. We have IETF level review disciplines vs functional, technical interest, - Need to separate issues into technical important levels, integration related. Which ones are discussed first, is a judgment call, but I lean towards the ones that deal with what we learned the last 9 years of vendor implementations, and that includes: - Senderid (RFC5222 related) vs Submitter (RFC5321 related that allows indirect support for SenderId), - Addressing the check_host() input and open-ended options, - Emphasis on security and (DNS) optimization, overhead minimization, - Reporting methods, directions. Thanks -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Andrew Sullivan wrote: > On Tue, Feb 14, 2012 at 02:13:36PM -0800, S Moonesamy wrote: >> Hi Hector, >> At 13:28 14-02-2012, Hector Santos wrote: >>> Sorry, Saturday is too short for (for me, time wise). > […] >> From the above, I gather that you need more time. What date would >> be convenient for you? > > Perhaps we could take another approach. > > Hector, as you note, there are already several issues catalogued. I'd > like to suggest that we begin discussions of some of the > already-enumerated issues while you are still working on your list of > issues. It seems to me that we can make progress on some issues while > others find new issues. After all, it's not as though we're closing > the list of issues forever before we start discussing issues: if a new > issue emerges from the discussion, we're not going to rule it out of > order. Similarly, the point here is to take only a few issues at a > time, so there will still be some in the queue after the 18th. The > point of the artificial deadline of the 18th was to collect as many > issues as we could in order to prioritize items in discussion. If > every issue hasn't been exposed by then, it's not the end of the > world; we certainly have some things to chew on already. > > So in the absence of a really compelling reason to hold off, SM and I > will pick some issues to start discussion on later this week. > > Thanks, > > A > From hsantos@isdg.net Thu Feb 16 07:53:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E541E21F864D for ; Thu, 16 Feb 2012 07:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=-1.321, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJGSyOE3fPSu for ; Thu, 16 Feb 2012 07:53:32 -0800 (PST) Received: from catinthebox.net (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D0BB721F85C4 for ; Thu, 16 Feb 2012 07:53:31 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1711; t=1329407609; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=nrS3BZaOTE5hEP8iwrDnmPd0EAw=; b=ggvZdY0LkYromAMMlP2P VBRrkZwb7BA7j34O+K9h10FBru45uGOhXSN+pmU6PeZlpm862Jm6D9ZRE3PlxZ77 tkOl0yNokZnINi3fWIUIvExtTiay9PCgdobh2EZG1x9xYcVhwTYCuyZOw25xBo/B H3+Z1VgEh4xQlTqyk2cVNJE= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 16 Feb 2012 10:53:29 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2609459817.81277.5240; Thu, 16 Feb 2012 10:53:28 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1711; t=1329407377; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=BaUDAoK PTZM78wI7bkvlUeuVjZeOr/b2+h2gWL9voHo=; b=cmLqk0NIc4rrdptcrCUG5Bi Ri03UswY+YVhRbOFZYknQRc6aMlzPUJCTukcqOJjXtOvf4VJCgo7G8Sr6C1jJNKJ 8ZlY1Y1kBhhMW0nCHlf0rRl9Mm4VgJ3+NcFZvVIrdemSRH3JITIaQNRcjphbQvVP BC3QeVtN3/IyiEmpI16I= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 16 Feb 2012 10:49:37 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3208400251.16723.5460; Thu, 16 Feb 2012 10:49:36 -0500 Message-ID: <4F3D269A.1010001@isdg.net> Date: Thu, 16 Feb 2012 10:54:02 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andrew Sullivan References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3AD1E2.8090305@isdg.net> <6.2.5.6.2.20120214135907.074e8870@resistor.net> <20120214224450.GE22144@mail.yitter.info> <4F3D2465.4060301@isdg.net> In-Reply-To: <4F3D2465.4060301@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:53:37 -0000 Small followup, and also nipping the bud on obvious issues that have a high potential for dispute. Honestly and I'm record that I do not like the IETF Rough Consensus (RC) concept. It was applicable in an era where we journeying into the unknown in years past to help with decision making. Its a terrible method in today's environment where we have untold IETF-MAN-YEARS in technology and how its will most likely work. I can not accept any RC today where there is obvious contention and quite often an osmosis element comes into play - ignore other input or others just step out thus automatically creating a untrue position. Tough call, understood, but at the end of the day its about fundamental engineering sense that MUST be followed. Thats me. Thats how I am. No bending. Hector Santos wrote: > +1. > > My thoughts: > > - Mixed discipline environment, can't expect the same level of detail > reviews across the board in the agenda sought. We have IETF level review > disciplines vs functional, technical interest, > > - Need to separate issues into technical important levels, integration > related. Which ones are discussed first, is a judgment call, but I lean > towards the ones that deal with what we learned the last 9 years of > vendor implementations, and that includes: > > - Senderid (RFC5222 related) vs Submitter (RFC5321 related that allows > indirect support for SenderId), > > - Addressing the check_host() input and open-ended options, > > - Emphasis on security and (DNS) optimization, overhead minimization, > > - Reporting methods, directions. > > Thanks > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From ajs@anvilwalrusden.com Thu Feb 16 08:57:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E03421F880E for ; Thu, 16 Feb 2012 08:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.084 X-Spam-Level: X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[AWL=-1.484, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.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 EKj4Cgg-wcAl for ; Thu, 16 Feb 2012 08:57:20 -0800 (PST) Received: from pdx-1.yitter.info (unknown [174.140.166.76]) by ietfa.amsl.com (Postfix) with ESMTP id B9A8821F8813 for ; Thu, 16 Feb 2012 08:57:15 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ajs@anvilwalrusden.com) by pdx-1.yitter.info (Postfix) with ESMTPSA id 72EDAA35809F for ; Thu, 16 Feb 2012 08:57:14 -0800 (PST) Date: Thu, 16 Feb 2012 11:57:06 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120216165706.GA29243@mail.yitter.info> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3AD1E2.8090305@isdg.net> <6.2.5.6.2.20120214135907.074e8870@resistor.net> <20120214224450.GE22144@mail.yitter.info> <4F3D2465.4060301@isdg.net> <4F3D269A.1010001@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F3D269A.1010001@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:57:20 -0000 Hi Hector, My chair hat is firmly on. I haven't consulted with SM on what I say below, but I'd be astonished if he disagreed with me. On Thu, Feb 16, 2012 at 10:54:02AM -0500, Hector Santos wrote: > Honestly and I'm record that I do not like > the IETF Rough Consensus (RC) concept. […] > followed. Thats me. Thats how I am. No bending. I don't mind if you don't like the approach that the IETF uses, but neither this WG nor this list shall be turned into a platform for discussion of the IETF process. There are _plenty_ of places around the IETF to discuss process. This WG isn't one of them, and we're going to use the established IETF processes for the operation of this WG. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Thu Feb 16 09:00:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD02321E801E for ; Thu, 16 Feb 2012 09:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=-1.471, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.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 hsB+-vUs7FID for ; Thu, 16 Feb 2012 09:00:05 -0800 (PST) Received: from pdx-1.yitter.info (unknown [174.140.166.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE1121E8015 for ; Thu, 16 Feb 2012 09:00:05 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ajs@anvilwalrusden.com) by pdx-1.yitter.info (Postfix) with ESMTPSA id D3249A35809F for ; Thu, 16 Feb 2012 09:00:03 -0800 (PST) Date: Thu, 16 Feb 2012 12:00:01 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120216170001.GB29243@mail.yitter.info> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:00:06 -0000 On Wed, Feb 15, 2012 at 04:04:20PM -0800, Murray S. Kucherawy wrote: > I've posted my issues from my review already, but I'd like to point > out that I'll be mentioning this work at the MAAWG conference next > week, and we might collect some new participants and/or feedback > from that since SPF is near and dear to many that will be attending. > I will forward what I get from that and encourage them to get > involved directly, but that may mean some issues are raised after > your deadline. I hope that's okay, or if not would we consider > pushing the deadline out a week or two? Please do draw this work to the attention of MAAWG participants. We of course welcome additional participation. We are going to start working on particular issues, though, starting next week. The point of the deadline was really just an administrative trick: we wanted to get a bunch of issues listed first so we had some things to prioritize. I cannot believe we won't see more issues coming up, and we of course encourage people to raise those as they think of them. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Thu Feb 16 10:24:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79D721F85DD for ; Thu, 16 Feb 2012 10:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9huKF1lz0iv for ; Thu, 16 Feb 2012 10:24: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 D828A11E8091 for ; Thu, 16 Feb 2012 10:24:47 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.236.65]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1GIORue014037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 10:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329416680; i=@elandsys.com; bh=5VkKRaNaamu26nzPlcgHj4u971FxNGLpgvCM0iQb6+c=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=fo2NpPJtdxgrjemrYg7R7++SYIdUkAbF4XdRYehVcF5Kix4oksQG/2+xkV+/L6Emp K1eYEzYO+eCIeInQGp7iUPxlo9uNyiyJlJkJsOrwYkvmAJqQFf27Uf44Pd4CwzC46m hi5S0bkigdRH0BO52uMhAaGl/cCP+TwY03CDuAiM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329416680; i=@elandsys.com; bh=5VkKRaNaamu26nzPlcgHj4u971FxNGLpgvCM0iQb6+c=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=DipxGcbywVDT/ygwQOwDpePa5VVTt/2oz+a4nKeilKylbxs8Zn1IoHBDbDKHZSCSG UfdnasJrvsVQoTMf8r56fCTFFRhKJW6j+UmKdy/Wl65T3W4cpe5k6mFFka+l7+gTkP J0N4uKdPK1RGAv5/7IXFcUYnqManhY7CvnxN+fes= Message-Id: <6.2.5.6.2.20120216095241.08f95ad0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Feb 2012 10:24:03 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20120216165706.GA29243@mail.yitter.info> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3AD1E2.8090305@isdg.net> <6.2.5.6.2.20120214135907.074e8870@resistor.net> <20120214224450.GE22144@mail.yitter.info> <4F3D2465.4060301@isdg.net> <4F3D269A.1010001@isdg.net> <20120216165706.GA29243@mail.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: [spfbis] Note Well (was: RFC 4408 issues list) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:24:53 -0000 At 08:57 16-02-2012, Andrew Sullivan wrote: >My chair hat is firmly on. I haven't consulted with SM on what I say >below, but I'd be astonished if he disagreed with me. I agree with what my co-chair said ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00386.html ). I would like to remind all working group participants to read the Note Well ( http://www.ietf.org/about/note-well.html ), which I quote: "A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements." Please note that that all IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). If you need more information, please ask the Working Group chairs. Regards, S. Moonesamy SPFBIS WG co-chair From dotis@mail-abuse.org Thu Feb 16 14:42:11 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5C421E8088 for ; Thu, 16 Feb 2012 14:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.257, 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 6rFWP0c366vj for ; Thu, 16 Feb 2012 14:42:10 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8AE21E808A for ; Thu, 16 Feb 2012 14:42:10 -0800 (PST) Received: from us-sherryl-e64k.us.trendnet.org (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 149A5174043B for ; Thu, 16 Feb 2012 22:42:10 +0000 (UTC) Message-ID: <4F3D8640.9090300@mail-abuse.org> Date: Thu, 16 Feb 2012 14:42:08 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> In-Reply-To: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] RFC 4408 issue Reasonable DNS error limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:42:11 -0000 Dear S Moonesamy, RFC4408 needs to set reasonable limits for the number of DNS transactions resulting in Name Errors or No Data results. This constrains potential reflected DNS amplification caused by the 111 (or 222 TXT/SPF RR) possible DNS transactions that might be attempted to resolve a complete SPF record set. 1 + 10 + 100 or 2 + 20 + 200 depending upon use of SPF/TXT resource records in parallel. The potential level of DDoS gain is also affected by whether other identities are to be resolved beyond the typical SMTP Mail From parameter, such as those used to resolve Sender-ID or HELO/EHLO identities. 1 for initial SPF records. 1 for each of the 10 mechanisms. 10 for each of the possible host address or PTR resolutions by each mechanism. Section 4.4 Record Lookup Was: If all DNS lookups that are made return a server failure (RCODE 2), or other error (RCODE other than 0 or 3), or time out, then check_host() exits immediately with the result "TempError". Change to: When more than 10 DNS transactions return a server failure (RCODE 2), time out or provide No Data (ANCOUNT of zero), subsequent DNS transactions SHOULD be avoided and conclude with a resolution of "TempError". When 10 DNS transactions return a Name Error (RCODE 3), subsequent DNS transactions SHOULD be avoided and conclude with a resolution of "None". When one of the optional resource record types (TXT or SPF) for a specific domain provide No DATA (ANCOUNT of zero) but data is returned by the other, DNS transactions for this domain SHOULD avoid subsequent transactions using the resource record type resulting in No Data. Regards, Douglas Otis From spf2@kitterman.com Thu Feb 16 15:00:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB5A21F8755 for ; Thu, 16 Feb 2012 15:00:17 -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 S99h2bYdL8FV for ; Thu, 16 Feb 2012 15:00:12 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 800D921F8750 for ; Thu, 16 Feb 2012 15:00:12 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id ED22F20E40BB; Thu, 16 Feb 2012 18:00:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329433212; bh=rvT9p/mtjIy6nB5a7o+9YbXp8twH0sW7h6zHd97ulcg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ZZJ5CtnM2GMApt1jS5CdBWpO0f68UKhr6tRUOjlyaXp0DdixSrbCc4CCZFk4FFkLP 0u3P+rmnk89fvWq7P6OgHsk0JGHovam8cb4BXrhOROGm5MoycDaVppaN+FW+H8NnAp OvF2+Pe4FPfo9FRNWGyS0r5SinZSKFLvO+i3FpfI= Received: from scott-latitude-e6320.localnet (140.239.105.162.ptr.us.xo.net [140.239.105.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id CDAE920E406C; Thu, 16 Feb 2012 18:00:11 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 16 Feb 2012 18:00:10 -0500 Message-ID: <3547736.yDvp77vJhl@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F3D8640.9090300@mail-abuse.org> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3D8640.9090300@mail-abuse.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] RFC 4408 issue Reasonable DNS error limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 23:00:17 -0000 I think this is one part of a possible solution to the existing issue on refactoring the processing limits in paragraph 10.1 of RFC 4408 and should be added to that issue rather than as a new separate issue. Scott K On Thursday, February 16, 2012 02:42:08 PM Douglas Otis wrote: > Dear S Moonesamy, > > RFC4408 needs to set reasonable limits for the number of DNS > transactions resulting in Name Errors or No Data results. This > constrains potential reflected DNS amplification caused by the 111 (or > 222 TXT/SPF RR) possible DNS transactions that might be attempted to > resolve a complete SPF record set. 1 + 10 + 100 or 2 + 20 + 200 > depending upon use of SPF/TXT resource records in parallel. > > The potential level of DDoS gain is also affected by whether other > identities are to be resolved beyond the typical SMTP Mail From > parameter, such as those used to resolve Sender-ID or HELO/EHLO > identities. 1 for initial SPF records. 1 for each of the 10 > mechanisms. 10 for each of the possible host address or PTR resolutions > by each mechanism. > > Section 4.4 Record Lookup > > Was: > If all DNS lookups that are made return a server failure (RCODE 2), or > other error (RCODE other than 0 or 3), or time out, then check_host() > exits immediately with the result "TempError". > > Change to: > When more than 10 DNS transactions return a server failure (RCODE 2), > time out or provide No Data (ANCOUNT of zero), subsequent DNS > transactions SHOULD be avoided and conclude with a resolution of > "TempError". When 10 DNS transactions return a Name Error (RCODE 3), > subsequent DNS transactions SHOULD be avoided and conclude with a > resolution of "None". > > When one of the optional resource record types (TXT or SPF) for a > specific domain provide No DATA (ANCOUNT of zero) but data is returned > by the other, DNS transactions for this domain SHOULD avoid subsequent > transactions using the resource record type resulting in No Data. > > Regards, > Douglas Otis > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From ajs@anvilwalrusden.com Thu Feb 16 15:16:14 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6F321E807B for ; Thu, 16 Feb 2012 15:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.982 X-Spam-Level: X-Spam-Status: No, score=-0.982 tagged_above=-999 required=5 tests=[AWL=-1.382, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.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 IenTh6I-ZMM1 for ; Thu, 16 Feb 2012 15:16:10 -0800 (PST) Received: from pdx-1.yitter.info (unknown [174.140.166.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1322621F87AF for ; Thu, 16 Feb 2012 15:16:09 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ajs@anvilwalrusden.com) by pdx-1.yitter.info (Postfix) with ESMTPSA id 973CAA35809F for ; Thu, 16 Feb 2012 15:16:08 -0800 (PST) Date: Thu, 16 Feb 2012 18:16:05 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120216231603.GV29243@mail.yitter.info> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3D8640.9090300@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3D8640.9090300@mail-abuse.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] RFC 4408 issue Reasonable DNS error limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 23:16:14 -0000 Hi Doug, Could we split this in two: (1) issue of "possible large number of DNS queries that could result" and (2) possible mitigations? That is, I'd like the issue to be (1) and your suggested answers to be part of the discussion of how to address the issue. Ok? A On Thu, Feb 16, 2012 at 02:42:08PM -0800, Douglas Otis wrote: > Dear S Moonesamy, > > RFC4408 needs to set reasonable limits for the number of DNS > transactions resulting in Name Errors or No Data results. This > constrains potential reflected DNS amplification caused by the 111 > (or 222 TXT/SPF RR) possible DNS transactions that might be > attempted to resolve a complete SPF record set. 1 + 10 + 100 or 2 + > 20 + 200 depending upon use of SPF/TXT resource records in parallel. > > The potential level of DDoS gain is also affected by whether other > identities are to be resolved beyond the typical SMTP Mail From > parameter, such as those used to resolve Sender-ID or HELO/EHLO > identities. 1 for initial SPF records. 1 for each of the 10 > mechanisms. 10 for each of the possible host address or PTR > resolutions by each mechanism. > > Section 4.4 Record Lookup > > Was: > If all DNS lookups that are made return a server failure (RCODE 2), > or other error (RCODE other than 0 or 3), or time out, then > check_host() exits immediately with the result "TempError". > > Change to: > When more than 10 DNS transactions return a server failure (RCODE > 2), time out or provide No Data (ANCOUNT of zero), subsequent DNS > transactions SHOULD be avoided and conclude with a resolution of > "TempError". When 10 DNS transactions return a Name Error (RCODE > 3), subsequent DNS transactions SHOULD be avoided and conclude with > a resolution of "None". > > When one of the optional resource record types (TXT or SPF) for a > specific domain provide No DATA (ANCOUNT of zero) but data is > returned by the other, DNS transactions for this domain SHOULD avoid > subsequent transactions using the resource record type resulting in > No Data. > > Regards, > Douglas Otis > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Andrew Sullivan ajs@anvilwalrusden.com From hsantos@isdg.net Thu Feb 16 15:53:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB9F21F8798 for ; Thu, 16 Feb 2012 15:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl7b+iwD5+Y3 for ; Thu, 16 Feb 2012 15:53:50 -0800 (PST) Received: from mail.santronics.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C77E521F8664 for ; Thu, 16 Feb 2012 15:53:49 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1197; t=1329436424; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=BqvflSFRcCyAlCqZcc8P7rDLH68=; b=q3Eoz+ncRqLOLAdxKief TANQX6GHkHYL8tlQqcBmfyEPpGEsTrrhQQghZke8p/EuAHIVRCq8k6WbR0sgQsNo iCKY9Jo18TNMHxZUirO7wUqti0ZZNfmj4v5/n69zc5S/uFuD11JOuSOaU5GSvFUl VKIckZ6SrLzbp4Rtn1GQLPw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 16 Feb 2012 18:53:44 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2638275277.81277.4144; Thu, 16 Feb 2012 18:53:44 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1197; t=1329436192; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=TLkkf0S bmTPsIigCo8dp9Qq8uKQLDvVs8LCdQMGSckI=; b=sziZ3z/6VJ5o7KpZRuVv20x Z7Af6aHmAN6F6MAMIrNkowaqWtr/qaa9TjyucOQs8r9mMl0YAwxcSRn1yNJv4QJR MP6GN66q5+vIrdqCX32yj2OKalWbt7iFkxVAsKXG4e8u/6/jA/5igXq3VFkW+pEh ux/l6bTbb4qRgn+S+hAg= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 16 Feb 2012 18:49:52 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3237214470.16971.7160; Thu, 16 Feb 2012 18:49:51 -0500 Message-ID: <4F3D9703.4000504@isdg.net> Date: Thu, 16 Feb 2012 18:53:39 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3AD1E2.8090305@isdg.net> <6.2.5.6.2.20120214135907.074e8870@resistor.net> <20120214224450.GE22144@mail.yitter.info> <4F3D2465.4060301@isdg.net> <4F3D269A.1010001@isdg.net> <20120216165706.GA29243@mail.yitter.info> In-Reply-To: <20120216165706.GA29243@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 23:53:55 -0000 I did not advocate a referendum on the RC process. But I am hoping that the WG will recognize using it an instrument to win controversial suggestions when they shouldn't be one in the first place will be problematic. Especially when you already been told upfront that those issue might be. Thats a MANAGEMENT problem. Andrew Sullivan wrote: > Hi Hector, > > My chair hat is firmly on. I haven't consulted with SM on what I say > below, but I'd be astonished if he disagreed with me. > > On Thu, Feb 16, 2012 at 10:54:02AM -0500, Hector Santos wrote: > >> Honestly and I'm record that I do not like >> the IETF Rough Consensus (RC) concept. > […] >> followed. Thats me. Thats how I am. No bending. > > I don't mind if you don't like the approach that the IETF uses, but > neither this WG nor this list shall be turned into a platform for > discussion of the IETF process. There are _plenty_ of places around > the IETF to discuss process. This WG isn't one of them, and we're > going to use the established IETF processes for the operation of this > WG. > > Best regards, > > A > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Thu Feb 16 16:13:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F210221E8061 for ; Thu, 16 Feb 2012 16:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.475, 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 pNb0m2KCSR1S for ; Thu, 16 Feb 2012 16:13:31 -0800 (PST) Received: from mail.santronics.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 15D2321E804B for ; Thu, 16 Feb 2012 16:13:30 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1803; t=1329437605; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=a+/tLnuQkGwUrpKFNk19Kw2bfvc=; b=mbjNHEM377CCs+Aa9tg+ jTPcWbrSt0EAKxNArlMvXHjbjG52K7hmDLqddMU8KqSR0JQufIShRiKQCCDfl0g2 /Q9TaUiRIXTV5e7YzMwoLOpBeq2Aylqqlc0ftG6uIQf60HJAtb4aOeLmQoATZZCO ZIEoXEVRIb8C+GOpf+tlHKk= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 16 Feb 2012 19:13:25 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2639455362.81277.2516; Thu, 16 Feb 2012 19:13:24 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1803; t=1329437373; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=qdqB8pQ VKhmCt8OZUA1hd7vFC1k+zHGQnpfO4otPGuE=; b=wtH+w1Apd4YW23/sNtdsFlc 3qAjOlXd428+KwYZe+q258UDg8HYYlYZP1gImXpt4fwhYfOXA+qZuzOvUpEkZwdf LintOJet8eNsvj/qeljho2hWwhckyP40kRpl8JurleklgjI8nPB482D/dZ41Q/ks CH0nAOAb64kCujV5uA0M= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 16 Feb 2012 19:09:33 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3238395783.16973.4672; Thu, 16 Feb 2012 19:09:32 -0500 Message-ID: <4F3D9BA0.8090608@isdg.net> Date: Thu, 16 Feb 2012 19:13:20 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3AD1E2.8090305@isdg.net> <6.2.5.6.2.20120214135907.074e8870@resistor.net> <20120214224450.GE22144@mail.yitter.info> <4F3D2465.4060301@isdg.net> <4F3D269A.1010001@isdg.net> <20120216165706.GA29243@mail.yitter.info> <6.2.5.6.2.20120216095241.08f95ad0@resistor.net> In-Reply-To: <6.2.5.6.2.20120216095241.08f95ad0@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Note Well X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Feb 2012 00:13:37 -0000 SM, AS: My point is simple. I have a concern with apparent WG Chairs plans to allow controversial issues be introduced and debated that perhaps SHOULD NOT have been even allowed to be introduced in the first place. I've seen it used incorrectly in the past to interject and change the framework of the protocol and I fear it will used again here for SPF using SPFBIF as a vehicle to institute the change. I'm seen it with DKIM and I don't wish to to see it with SPF. Anything that changes SPF in a non-compatible manner should not be an issue to be discussed and working purely on RC is not going to resolve the inherent problem it shouldn't have been one the first place. -- S Moonesamy wrote: > At 08:57 16-02-2012, Andrew Sullivan wrote: >> My chair hat is firmly on. I haven't consulted with SM on what I say >> below, but I'd be astonished if he disagreed with me. > > I agree with what my co-chair said ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg00386.html ). > > I would like to remind all working group participants to read the Note > Well ( http://www.ietf.org/about/note-well.html ), which I quote: > > "A participant in any IETF activity is deemed to accept all IETF rules of > process, as documented in Best Current Practices RFCs and IESG > Statements." > > Please note that that all IETF Contributions are subject to the rules of > RFC 5378 and RFC 3979 (updated by RFC 4879). > > If you need more information, please ask the Working Group chairs. > > Regards, > S. Moonesamy > SPFBIS WG co-chair > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From sm@elandsys.com Thu Feb 16 16:21:38 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BEA21F85B4 for ; Thu, 16 Feb 2012 16:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPswo0xJO-MA for ; Thu, 16 Feb 2012 16:21:33 -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 14CC521F85AE for ; Thu, 16 Feb 2012 16:21:32 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.236.65]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1H0LEul021561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 16:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329438086; i=@elandsys.com; bh=h2fEgZf/KSVINdYU22rtxZMvQpdw88uZd0fzcSp/pCQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=MAI+sluFq4nbNC/jo5NpEzRGmv5valryMHZHthqi2LNmLKAonV1++rJ38wSw9osVX Vvp5H5GZFPJoiAlIR93K42LsVPut8ztMpr9+a457QHy8NsceMxP5R46XucjBMForWG a0Sv8AKFTElzNUMOW1n/dN9n80ZcqSnEEZ42hkuI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329438086; i=@elandsys.com; bh=h2fEgZf/KSVINdYU22rtxZMvQpdw88uZd0fzcSp/pCQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=P213GODbb4c0rU+eFVC2lXsFH5uE6webxSOkm7X6CZVANcGXIovJE0446xVz/LAbf m02NlJSkwO8KA4z4a4DASq7inNIEd5ZJBoMlPf/11CR277A7AwJDIR0Uwg5ouqdyNj 2NODNXrAYr44z3TxI9o4ZIGN6MkipiD5i4bgkteY= Message-Id: <6.2.5.6.2.20120216161115.09cb7e70@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Feb 2012 16:21:02 -0800 To: Hector Santos From: S Moonesamy In-Reply-To: <4F3D9703.4000504@isdg.net> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3AD1E2.8090305@isdg.net> <6.2.5.6.2.20120214135907.074e8870@resistor.net> <20120214224450.GE22144@mail.yitter.info> <4F3D2465.4060301@isdg.net> <4F3D269A.1010001@isdg.net> <20120216165706.GA29243@mail.yitter.info> <4F3D9703.4000504@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 00:21:38 -0000 Hi Hector, At 15:53 16-02-2012, Hector Santos wrote: >I did not advocate a referendum on the RC process. But I am hoping >that the WG will recognize using it an instrument to win >controversial suggestions when they shouldn't be one in the first >place will be problematic. Especially when you already been told >upfront that those issue might be. Thats a MANAGEMENT problem. May I humbly suggest that we wait for the issues to be discussed before drawing any conclusion? It's only a matter of a few more days before the start of the discussions on the issues listed in the tracker. Thanks, S. Moonesamy From sm@elandsys.com Thu Feb 16 16:55:14 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E498C21F86B3 for ; Thu, 16 Feb 2012 16:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gWNMS9GFvIH for ; Thu, 16 Feb 2012 16:55:09 -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 A023621F85AD for ; Thu, 16 Feb 2012 16:55:09 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.236.65]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1H0sl0d015734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 16:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329440101; i=@elandsys.com; bh=57mefFCLZId9bKXUQ1oPj/cqvrwaEGHaGpxOnSuHIQ0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=jTJLEkvfLcdCbvU33E8VIYr/d7PDDsk7zkVU5n8Glgx1jQ9HDSJtzrR3TyV/er+Y/ Z7vBIFEp55BiQp7XA95vT5wPNdXk/pBpeMpg7Qgkcik/FjhYri9tLtUY5Mu4Ds8ONv 3cZ1euAC/xd0+zRZPbucM2qt6fmpsoLwcnSDFsfs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329440101; i=@elandsys.com; bh=57mefFCLZId9bKXUQ1oPj/cqvrwaEGHaGpxOnSuHIQ0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=APWdMjt298pKZbrOWk0zWWLPgXX/6lJHttAKo/fPirspoctRmWWmHwDsxRhJ5cU2W abLCP+JWnXL6jGOydcVyQ0DOmE04uRoMNu+DGA1IUnmjCmkPYFOtQ5WWv++9vqHHBY aq+XEUXpFycFG/lifppPxkiQyY+lmWBX6GmGqzx8= Message-Id: <6.2.5.6.2.20120216162305.09017d68@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Feb 2012 16:53:44 -0800 To: Hector Santos From: S Moonesamy In-Reply-To: <4F3D9BA0.8090608@isdg.net> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3AD1E2.8090305@isdg.net> <6.2.5.6.2.20120214135907.074e8870@resistor.net> <20120214224450.GE22144@mail.yitter.info> <4F3D2465.4060301@isdg.net> <4F3D269A.1010001@isdg.net> <20120216165706.GA29243@mail.yitter.info> <6.2.5.6.2.20120216095241.08f95ad0@resistor.net> <4F3D9BA0.8090608@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] Note Well X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Feb 2012 00:55:15 -0000 Hi Hector, At 16:13 16-02-2012, Hector Santos wrote: >My point is simple. I have a concern with apparent WG Chairs plans >to allow controversial issues be introduced and debated that perhaps >SHOULD NOT have been even allowed to be introduced in the first >place. I've seen it used incorrectly in the past to interject The WG Chairs asked everyone to review RFC 4408 and post their comments to this mailing list. The comments were listed in the tracker as issues. > and change the framework of the protocol and I fear it will used > again here for SPF using SPFBIF as a vehicle to institute the > change. I'm seen it with DKIM and I don't wish to to see it with SPF. This is the SPFBIS working group. >Anything that changes SPF in a non-compatible manner should not be >an issue to be discussed and working purely on RC is not going to >resolve the inherent problem it shouldn't have been one the first place. BCP 25 defines IETF working group procedures and guidelines. I would prefer not to see IETF rules exercised unless there is no other alternative. I suggest that we wait until tomorrow. If you still have a concern, you can email the WG Chairs privately, or post to the mailing list, if you wish. Regards, S. Moonesamy SPFBIS WG co-chair From dotis@mail-abuse.org Thu Feb 16 18:32:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB91E21E804B for ; Thu, 16 Feb 2012 18:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 Mt5rQ3Hnbl3X for ; Thu, 16 Feb 2012 18:32:16 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id B4CE121E8040 for ; Thu, 16 Feb 2012 18:32:16 -0800 (PST) Received: from us-sherryl-e64k.us.trendnet.org (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 4F99317404A8 for ; Fri, 17 Feb 2012 02:32:16 +0000 (UTC) Message-ID: <4F3DBC2F.7080004@mail-abuse.org> Date: Thu, 16 Feb 2012 18:32:15 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3D8640.9090300@mail-abuse.org> <20120216231603.GV29243@mail.yitter.info> In-Reply-To: <20120216231603.GV29243@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] RFC 4408 issue Reasonable DNS error limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 02:32:20 -0000 On 2/16/12 3:16 PM, Andrew Sullivan wrote: > Hi Doug, > > Could we split this in two: (1) issue of "possible large number of DNS > queries that could result" and (2) possible mitigations? That is, I'd > like the issue to be (1) and your suggested answers to be part of the > discussion of how to address the issue. Ok? Dear Andrew, I assume you want me to resubmit this as two separate messages. I'll have that first thing tomorrow. I am still recovering from an Inchon flight. I am also tempted to write something similar regarding the local-part macro. This feature is seldom used, but prevents domain level caching. This necessitates repeating the same process simply because it might be effected by a local-part macro. This feature also conflicts with using SPF as a utility to define the domain's outbound servers and to assess reputations based upon a domain name. Regards, Douglas Otis > > A > > On Thu, Feb 16, 2012 at 02:42:08PM -0800, Douglas Otis wrote: >> Dear S Moonesamy, >> >> RFC4408 needs to set reasonable limits for the number of DNS >> transactions resulting in Name Errors or No Data results. This >> constrains potential reflected DNS amplification caused by the 111 >> (or 222 TXT/SPF RR) possible DNS transactions that might be >> attempted to resolve a complete SPF record set. 1 + 10 + 100 or 2 + >> 20 + 200 depending upon use of SPF/TXT resource records in parallel. >> >> The potential level of DDoS gain is also affected by whether other >> identities are to be resolved beyond the typical SMTP Mail From >> parameter, such as those used to resolve Sender-ID or HELO/EHLO >> identities. 1 for initial SPF records. 1 for each of the 10 >> mechanisms. 10 for each of the possible host address or PTR >> resolutions by each mechanism. >> >> Section 4.4 Record Lookup >> >> Was: >> If all DNS lookups that are made return a server failure (RCODE 2), >> or other error (RCODE other than 0 or 3), or time out, then >> check_host() exits immediately with the result "TempError". >> >> Change to: >> When more than 10 DNS transactions return a server failure (RCODE >> 2), time out or provide No Data (ANCOUNT of zero), subsequent DNS >> transactions SHOULD be avoided and conclude with a resolution of >> "TempError". When 10 DNS transactions return a Name Error (RCODE >> 3), subsequent DNS transactions SHOULD be avoided and conclude with >> a resolution of "None". >> >> When one of the optional resource record types (TXT or SPF) for a >> specific domain provide No DATA (ANCOUNT of zero) but data is >> returned by the other, DNS transactions for this domain SHOULD avoid >> subsequent transactions using the resource record type resulting in >> No Data. >> >> Regards, >> Douglas Otis >> >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis From ajs@anvilwalrusden.com Thu Feb 16 18:44:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9190E21E801C for ; Thu, 16 Feb 2012 18:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[AWL=-2.069, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.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 w4dEA1h-UjGS for ; Thu, 16 Feb 2012 18:44:52 -0800 (PST) Received: from pdx-1.yitter.info (unknown [174.140.166.76]) by ietfa.amsl.com (Postfix) with ESMTP id A06B021E8022 for ; Thu, 16 Feb 2012 18:44:52 -0800 (PST) Received: from [172.16.34.108] (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ajs@anvilwalrusden.com) by pdx-1.yitter.info (Postfix) with ESMTPSA id 92810A35809F; Thu, 16 Feb 2012 18:44:51 -0800 (PST) References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3D8640.9090300@mail-abuse.org> <20120216231603.GV29243@mail.yitter.info> <4F3DBC2F.7080004@mail-abuse.org> In-Reply-To: <4F3DBC2F.7080004@mail-abuse.org> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <0FA62C5E-9C62-45C2-B206-3EDA175FD9F5@anvilwalrusden.com> Content-Transfer-Encoding: quoted-printable From: Andrew Sullivan Date: Thu, 16 Feb 2012 21:41:50 -0500 To: Douglas Otis X-Mailer: iPhone Mail (9A405) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] RFC 4408 issue Reasonable DNS error limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 02:44:56 -0000 No, no need for different mails. I'll take this as agreement.=20 --=20 Andrew Sullivan=20 Please excuse my clumsy thumbs.=20 On 2012-02-16, at 21:32, Douglas Otis wrote: > On 2/16/12 3:16 PM, Andrew Sullivan wrote: >> Hi Doug, >>=20 >> Could we split this in two: (1) issue of "possible large number of DNS >> queries that could result" and (2) possible mitigations? That is, I'd >> like the issue to be (1) and your suggested answers to be part of the >> discussion of how to address the issue. Ok? > Dear Andrew, >=20 > I assume you want me to resubmit this as two separate messages. I'll have= that first thing tomorrow. I am still recovering from an Inchon flight. >=20 > I am also tempted to write something similar regarding the local-part macr= o. This feature is seldom used, but prevents domain level caching. This ne= cessitates repeating the same process simply because it might be effected by= a local-part macro. This feature also conflicts with using SPF as a utilit= y to define the domain's outbound servers and to assess reputations based up= on a domain name. >=20 > Regards, > Douglas Otis >=20 >=20 >=20 >>=20 >> A >>=20 >> On Thu, Feb 16, 2012 at 02:42:08PM -0800, Douglas Otis wrote: >>> Dear S Moonesamy, >>>=20 >>> RFC4408 needs to set reasonable limits for the number of DNS >>> transactions resulting in Name Errors or No Data results. This >>> constrains potential reflected DNS amplification caused by the 111 >>> (or 222 TXT/SPF RR) possible DNS transactions that might be >>> attempted to resolve a complete SPF record set. 1 + 10 + 100 or 2 + >>> 20 + 200 depending upon use of SPF/TXT resource records in parallel. >>>=20 >>> The potential level of DDoS gain is also affected by whether other >>> identities are to be resolved beyond the typical SMTP Mail From >>> parameter, such as those used to resolve Sender-ID or HELO/EHLO >>> identities. 1 for initial SPF records. 1 for each of the 10 >>> mechanisms. 10 for each of the possible host address or PTR >>> resolutions by each mechanism. >>>=20 >>> Section 4.4 Record Lookup >>>=20 >>> Was: >>> If all DNS lookups that are made return a server failure (RCODE 2), >>> or other error (RCODE other than 0 or 3), or time out, then >>> check_host() exits immediately with the result "TempError". >>>=20 >>> Change to: >>> When more than 10 DNS transactions return a server failure (RCODE >>> 2), time out or provide No Data (ANCOUNT of zero), subsequent DNS >>> transactions SHOULD be avoided and conclude with a resolution of >>> "TempError". When 10 DNS transactions return a Name Error (RCODE >>> 3), subsequent DNS transactions SHOULD be avoided and conclude with >>> a resolution of "None". >>>=20 >>> When one of the optional resource record types (TXT or SPF) for a >>> specific domain provide No DATA (ANCOUNT of zero) but data is >>> returned by the other, DNS transactions for this domain SHOULD avoid >>> subsequent transactions using the resource record type resulting in >>> No Data. >>>=20 >>> Regards, >>> Douglas Otis >>>=20 >>> _______________________________________________ >>> spfbis mailing list >>> spfbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/spfbis >=20 > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From msk@cloudmark.com Thu Feb 16 19:48:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6166F21E807B for ; Thu, 16 Feb 2012 19:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf0PJ2g8A9oh for ; Thu, 16 Feb 2012 19:48:56 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id DB23521E806E for ; Thu, 16 Feb 2012 19:48:56 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 16 Feb 2012 19:48:56 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 16 Feb 2012 19:48:56 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Thu, 16 Feb 2012 19:48:55 -0800 Thread-Topic: Issue: Best-Guess SPF Thread-Index: AcztJxKv2IkGjfHoTLyYlmcyh23QLg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C9A7DDDAEXCHC2corpclo_" MIME-Version: 1.0 Subject: [spfbis] Issue: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 03:48:57 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDDAEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to have a section, or at least an appendix, that talks about best-= guess SPF: What it is, why/when it is or isn't a good idea, etc. --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDDAEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d like t= o have a section, or at least an appendix, that talks about best-guess SPF:= What it is, why/when it is or isn’t a good idea, etc.

=

 

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDDAEXCHC2corpclo_-- From sm@elandsys.com Thu Feb 16 20:03:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6549521E80A1 for ; Thu, 16 Feb 2012 20:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y-UHLyd2lCz for ; Thu, 16 Feb 2012 20:03:21 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DA721E8021 for ; Thu, 16 Feb 2012 20:03:20 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.236.65]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1H433Fr010798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Feb 2012 20:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329451395; i=@elandsys.com; bh=60zM20qFy5sLaRYd5IPfkUyIk20i3Inf0XlQ8II7130=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=ov9QMYifE+RJ5j5SEPHecpHwP610uYy+ee/kCaGJLh07czvPgHtvMu5ec1X3kXbZD /glXGAojoiud5T2BAa5Y0of+Ox1D0bAUeobApEHGepK7EdvMzCUPr/3CUEAlmn4NWC azagsua827QkkNna92QhGJ0fsJaFXJJQgkxad0Z4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329451395; i=@elandsys.com; bh=60zM20qFy5sLaRYd5IPfkUyIk20i3Inf0XlQ8II7130=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=Bqr+vQKo9MsBGBSk7IodbOspck9nXgqv6k9I66yOelm/4O68whgHdL8uIDQEJ7bbG f1NKOWtJ+C8Mp/MAPID/rkw2DHInPMN8Hit8axYzgKic3+bTEthPG9GkfGvOeVvTOw liQjB2Bb0pQ4eLG79TEcdVH1BgIFoi9QJTpya6wA= Message-Id: <6.2.5.6.2.20120216195026.094eb8f8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Feb 2012 19:59:55 -0800 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Message rejection from mail.isdg.net X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Feb 2012 04:03:26 -0000 Hi Hector, For your information, I sent you two messages today with a copy to the SPFBIS mailing list ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00394.html and http://www.ietf.org/mail-archive/web/spfbis/current/msg00395.html ). The messages were rejected by mail.isdg.net. See transcript below: ----- The following addresses had permanent fatal errors ----- (reason: 554 Message Not Accepted by filter.) ----- Transcript of session follows ----- ... while talking to mail.isdg.net.: >>> DATA <<< 554 Message Not Accepted by filter. 554 5.0.0 Service unavailable Regards, S. Moonesamy From hsantos@isdg.net Thu Feb 16 21:05:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2772421E800E for ; Thu, 16 Feb 2012 21:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAjkwBDY3zot for ; Thu, 16 Feb 2012 21:05:27 -0800 (PST) Received: from groups.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id DBD6A21E8026 for ; Thu, 16 Feb 2012 21:05:26 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2128; t=1329455120; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=x4Oka8B4ix9f3K5sJGwjzH3pFxE=; b=a7Sj5VS3upuFA8JScxlz Yvv4HoXZXHtL0MwR2DRvxeBu0aUC3q8HWq4/MhL43G4heAG9PJvBvWil2OTMXvFv tLEHQ8mwDA8EwV8xcD9tuzBCkgki7u2OZs9xpPbn2gk0ZgJzaHl6m9ZVW9mwmkUL au+UcrLXYX1oiL7iY2+O/vs= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 17 Feb 2012 00:05:20 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2656970608.82094.2152; Fri, 17 Feb 2012 00:05:19 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2128; t=1329454886; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2B5ZM9T XQ/CusC67vkJG9PC/Pppmjd0g2/BzVh178xw=; b=shqCFj0ScAesY6qX9LnGXO7 cqFuqfcBDk9k0gfuBwOxYQaI/VLmyk2kPfc315/lV/sYyq5UrNJFaeCIOW/L2tNH DpGsxMGbBKNH/brDqbPw+udmZlUCXJ8j1HB/hcZ01JVCy3Esn0OOaXdpSKJlev4e /gNt4qslXVQ03DAwEbQ4= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 17 Feb 2012 00:01:26 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3255909111.16997.4976; Fri, 17 Feb 2012 00:01:25 -0500 Message-ID: <4F3DE00A.8040402@isdg.net> Date: Fri, 17 Feb 2012 00:05:14 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20120216195026.094eb8f8@elandnews.com> In-Reply-To: <6.2.5.6.2.20120216195026.094eb8f8@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Message rejection from mail.isdg.net X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Feb 2012 05:05:32 -0000 S Moonesamy wrote: > Hi Hector, > > For your information, I sent you two messages today with a copy to the > SPFBIS mailing list ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg00394.html and > http://www.ietf.org/mail-archive/web/spfbis/current/msg00395.html ). > The messages were rejected by mail.isdg.net. See transcript below: > > ----- The following addresses had permanent fatal errors ----- > > (reason: 554 Message Not Accepted by filter.) > > ----- Transcript of session follows ----- > ... while talking to mail.isdg.net.: >> >> DATA > <<< 554 Message Not Accepted by filter. > 554 5.0.0 Service unavailable > > Regards, > S. Moonesamy > Ok, checking it out... Too aggressive filtering rules apply to you. Sorry. I just white listed your new elandsys.com address. I should note that back on Feb 7, a direct off-list email attempt to you was rejected using your new sm+ietf@elandsys.com address: ----------- Original Message ----------------- Subject: Undeliverable mail Date: Tue, 07 Feb 2012 11:30:07 -0500 From: postmaster@winserver.com To: This is an automatic generated Delivery Status Notification. The message can not be sent to recipient: sm+ietf@elandsys.com Reason: A transaction failure was reported by remote server: "550 5.7.0 Message violates site policy Please read http://www.qubic.net/scam/ to see how to resend your message" ----------- end of original message ------------- Switching to your traditional address sm@resistor.net went thru. I was going to say something to you, I decided not to believing (perhaps erroneously) it was intention given the circumstances. With this reply, I am sending a CC to your elandsys.com address to see if the above rejection occurs again. You shouldn't have a problem again, but i you feel you need to contact me directly and privately, you can use my gmail account, sant9442@gmail.com, Also, I'm almost always available via jabber: hector@jabber.isdg.net -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From sm@elandsys.com Fri Feb 17 00:04:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AC421E801C for ; Fri, 17 Feb 2012 00:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8sirpFilAZI for ; Fri, 17 Feb 2012 00:04:08 -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 3FC6321E8015 for ; Fri, 17 Feb 2012 00:04:08 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.236.65]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1H83gfG011336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 00:03:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329465835; i=@elandsys.com; bh=p21R+WAIkToDIKbUMbMk+jn3D/s+JHbT1KRvK0YB6Xk=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Rzo10MavIG39NZtZ1tETIctizLXJyK66fJyB2ih9YLzn4M/dtXSLRlLafqsGhiusS U6lbL0gm2H2T673TLUa3N4c2Pp3aeCRRNl5G6wQN3w2LWIVpPxoVc8kIPL6MEwAQCo KWI+/+7hXGJ1qLjG7buQTnsd45P6iY+Bz7WiQp8M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329465835; i=@elandsys.com; bh=p21R+WAIkToDIKbUMbMk+jn3D/s+JHbT1KRvK0YB6Xk=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=ROnGlvcSXc0qrQg6O5omJlYMTUw++5cu4ctdccm3cYu5IUCNAeskplklXJowQfpip R4oMtLcV4YDKHfeWPLy6tmAx4G9MOivewitNj+I2IVauJCCTUxrLehxutCRREZIpqh LTtcbQN7LhkZq+hdgCR/gCIPgFanrFCmrkiFeXEE= Message-Id: <6.2.5.6.2.20120216211336.08583998@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Feb 2012 21:30:55 -0800 To: Hector Santos From: S Moonesamy In-Reply-To: <4F3DE00A.8040402@isdg.net> References: <6.2.5.6.2.20120216195026.094eb8f8@elandnews.com> <4F3DE00A.8040402@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Message rejection from mail.isdg.net X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Feb 2012 08:04:10 -0000 Hi Hector, At 21:05 16-02-2012, Hector Santos wrote: >Ok, checking it out... Too aggressive filtering rules apply to you. >Sorry. I just white listed your new elandsys.com address. The email address isn't new. >I should note that back on Feb 7, a direct off-list email attempt to >you was rejected using your new sm+ietf@elandsys.com address: Sorry about that. >Switching to your traditional address sm@resistor.net went thru. I >was going to say something to you, I decided not to believing >(perhaps erroneously) it was intention given the circumstances. I don't block any IETF participant. If anyone gets a rejection, please let me know so that I can fix my broken stuff. >With this reply, I am sending a CC to your elandsys.com address to >see if the above rejection occurs again. I got your email. >You shouldn't have a problem again, but i you feel you need to >contact me directly and privately, you can use my gmail account, >sant9442@gmail.com, Also, I'm almost always available via jabber: >hector@jabber.isdg.net Thanks. I'll use them if I cannot get through to your primary email address. I added you to Jabber. Regards, S. Moonesamy From msk@cloudmark.com Fri Feb 17 10:48:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EAD21F8655 for ; Fri, 17 Feb 2012 10:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmJ8fG-5avvK for ; Fri, 17 Feb 2012 10:48:05 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 738CC21F864E for ; Fri, 17 Feb 2012 10:48:05 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Feb 2012 10:48:05 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 17 Feb 2012 10:48:04 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Fri, 17 Feb 2012 10:48:04 -0800 Thread-Topic: A general cleanup strategy Thread-Index: AcztpK6En9zx3QfUTlOax95x5bPRqA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C9A7DDEFEXCHC2corpclo_" MIME-Version: 1.0 Subject: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 18:48:06 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDEFEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is just a procedural suggestion. I'm fine if we throw it away. The charter has a lot of things in common with the general characteristics = of the steps one would take if a working group wanted to advance something = along the standards track. That is, clarify and tidy up the specification,= and toss out parts that are not known to be in use. Would it be helpful to prepare an interoperability report, or at least go t= hrough the exercise of doing so, even if we don't actually ask the IESG to = publish it? -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDEFEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is just a p= rocedural suggestion.  I’m fine if we throw it away.<= /p>

 

The chart= er has a lot of things in common with the general characteristics of the st= eps one would take if a working group wanted to advance something along the= standards track.  That is, clarify and tidy up the specification, and= toss out parts that are not known to be in use.

 

Would it be helpful to p= repare an interoperability report, or at least go through the exercise of d= oing so, even if we don’t actually ask the IESG to publish it?

 

-MSK=

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDEFEXCHC2corpclo_-- From ajs@anvilwalrusden.com Fri Feb 17 10:56:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4EF21E80BC for ; Fri, 17 Feb 2012 10:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.943 X-Spam-Level: X-Spam-Status: No, score=-0.943 tagged_above=-999 required=5 tests=[AWL=-1.343, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.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 f7K1e30MD8UF for ; Fri, 17 Feb 2012 10:56:26 -0800 (PST) Received: from pdx-1.yitter.info (unknown [174.140.166.76]) by ietfa.amsl.com (Postfix) with ESMTP id B782021E80BB for ; Fri, 17 Feb 2012 10:56:20 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ajs@anvilwalrusden.com) by pdx-1.yitter.info (Postfix) with ESMTPSA id A78D2A35809F for ; Fri, 17 Feb 2012 10:56:19 -0800 (PST) Date: Fri, 17 Feb 2012 13:56:17 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120217185617.GG31662@mail.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 18:56:26 -0000 On Fri, Feb 17, 2012 at 10:48:04AM -0800, Murray S. Kucherawy wrote: > > Would it be helpful to prepare an interoperability report, or at > least go through the exercise of doing so, even if we don't actually > ask the IESG to publish it? This is an excellent suggestion, and I think it would be a wonderful thing to do. Do we need to organize any formal testing, or do we have the data we need? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Fri Feb 17 11:01:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D4C21E80BF for ; Fri, 17 Feb 2012 11:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uADmFuVLE2Sn for ; Fri, 17 Feb 2012 11:01:05 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id BDAFE21E80BB for ; Fri, 17 Feb 2012 11:01:05 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Feb 2012 11:01:05 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 17 Feb 2012 11:01:05 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Fri, 17 Feb 2012 11:01:03 -0800 Thread-Topic: [spfbis] A general cleanup strategy Thread-Index: AcztpdscjgYN13cBQDK9vxgNZZUFLwAABzig Message-ID: References: <20120217185617.GG31662@mail.yitter.info> In-Reply-To: <20120217185617.GG31662@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 19:01:06 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Andrew Sullivan > Sent: Friday, February 17, 2012 10:56 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] A general cleanup strategy >=20 > On Fri, Feb 17, 2012 at 10:48:04AM -0800, Murray S. Kucherawy wrote: > > Would it be helpful to prepare an interoperability report, or at least > > go through the exercise of doing so, even if we don't actually ask the > > IESG to publish it? >=20 > This is an excellent suggestion, and I think it would be a wonderful > thing to do. Do we need to organize any formal testing, or do we have > the data we need? The data Philip Gladstone has provided to date are a terrific start. Anyon= e else with comparable data sets should be encouraged to provide them. Pau= l tells me offline that the Microsoft database that collects such informati= on was recently reset but will be back online soon, so he could provide us = with that report at that time. The trick, of course, is that we can't tell who's checking SPF or Sender-ID= inbound, so it's very hard to gauge (other than anecdotally) how many peop= le are using which ones and in which modes. I'll poll some off-list resources and get them to give us what they can. The interoperability report for DKIM was done with data from only a few sou= rces (though a couple were quite large, fortunately), so I don't think any = formal organization is necessary at this stage. -MSK From msk@cloudmark.com Fri Feb 17 11:42:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1396B21F8692 for ; Fri, 17 Feb 2012 11:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7h4sbnyHHdbr for ; Fri, 17 Feb 2012 11:42:34 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7494621F8688 for ; Fri, 17 Feb 2012 11:42:34 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Feb 2012 11:42:34 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 17 Feb 2012 11:42:34 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Fri, 17 Feb 2012 11:42:32 -0800 Thread-Topic: New Version Notification for draft-kucherawy-spfbis-experiment-00.txt Thread-Index: Acztq8b1xuUn3CjBSI+Rc0tx3/aHMgAAAa+Q Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [spfbis] FW: New Version Notification for draft-kucherawy-spfbis-experiment-00.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: Fri, 17 Feb 2012 19:42:35 -0000 QXMgYSBzdHJhdyBtYW4gZG9jdW1lbnQgZm9yIGRlc2NyaWJpbmcgdGhlIGV4cGVyaW1lbnQgYW5k IGl0cyBjb25jbHVzaW9ucywgSSBvZmZlciB0aGlzIHRvIHRoZSBXRyBhbmQgdm9sdW50ZWVyIHRv IGFjdCBhcyBlZGl0b3IuICBJdCBjb250YWlucyB0aGUgZGF0YSB3ZSd2ZSBzZWVuIG9uIHRoZSBs aXN0IHNvIGZhciAodGhhbmtzLCBQYXVsIGFuZCBQaGlsbGlwISksIGFuZCBJIGJlbGlldmUgaXMg YW4gYXBwcm9wcmlhdGUgdGhpbmcgdG8gc3VibWl0IGdpdmVuIHRoZSBwb3N0dXJlIHdlJ3ZlIHNl ZW4gZnJvbSBQZXRlIGFib3V0IHdoYXQgdGhlIElFU0cgd291bGQgYWNjZXB0IGFzIHJlc29sdXRp b24gdG8gdGhlIGV4cGVyaW1lbnQuDQoNCkkgaGF2ZSBkZWxpYmVyYXRlbHkgYXZvaWRlZCBwb3B1 bGF0aW5nIHRoZSBDb25jbHVzaW9ucyBzZWN0aW9uIG9uIG15IG93bi4gIFRoYXQncyBmb3IgdGhl IFdvcmtpbmcgR3JvdXAgdG8gZG8gYnkgY29uc2Vuc3VzLg0KDQpJJ3ZlIHBvbGxlZCBhIG51bWJl ciBvZiBzb3VyY2VzIGJvdGggb24gdGhpcyBsaXN0IGFuZCBvZmYgZm9yIGRhdGEgdG8gaW5jbHVk ZSBpbiB0aGlzIG1lbW8sIG9yIHdoYXRldmVyIG90aGVyIG1lbW8gd2UgZGVjaWRlIHRvIGFkdmFu Y2UuICBJJ2xsIGVuY291cmFnZSB0aGVtIHRvIHBvc3QgdG8gdGhpcyBsaXN0LCBvciBJJ2xsIGZv cndhcmQgd2hhdCB0aGV5IGdpdmUgbWUuDQoNCkFzIGZvciBteSBwcmV2aW91cyBtZXNzYWdlLCBJ IGRpZCB0aGUgaW50ZXJvcGVyYWJpbGl0eSByZXBvcnQgZm9yIERLSU0gc28gSSdtIGhhcHB5IHRv IGRvIG9uZSBmb3IgU1BGIGFzIHdlbGwsIGFsdGhvdWdoIEknZCBhbHNvIGJlIGhhcHB5IHRvIGhh dmUgYW5vdGhlciB2b2x1bnRlZXIuICA6LSkNCg0KLU1TSw0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTcsIDIwMTIgMTE6Mzkg QU0NClRvOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQpDYzogTXVycmF5IFMuIEt1Y2hlcmF3eQ0KU3Vi amVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rdWNoZXJhd3ktc3BmYmlz LWV4cGVyaW1lbnQtMDAudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1rdWNoZXJh d3ktc3BmYmlzLWV4cGVyaW1lbnQtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgTS4gS3VjaGVyYXd5IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K RmlsZW5hbWU6CSBkcmFmdC1rdWNoZXJhd3ktc3BmYmlzLWV4cGVyaW1lbnQNClJldmlzaW9uOgkg MDANClRpdGxlOgkJIFRoZSBTUEYvU2VuZGVyLUlEIEV4cGVyaW1lbnQNCkNyZWF0aW9uIGRhdGU6 CSAyMDEyLTAyLTE3DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBw YWdlczogNg0KDQpBYnN0cmFjdDoNCiAgIEluIDIwMDYgdGhlIElFVEYgcHVibGlzaGVkIGEgc3Vp dGUgb2YgcHJvdG9jb2wgZG9jdW1lbnRzIGNvbXByaXNpbmcNCiAgIFNQRiBhbmQgU2VuZGVyLUlE LCB0d28gcHJvcG9zZWQgZW1haWwgYXV0aGVudGljYXRpb24gcHJvdG9jb2xzLg0KICAgQmVjYXVz ZSBvZiBpbnRlcm9wZXJhYmlsaXR5IGNvbmNlcm5zIGFuZCB0aGUgaW5hYmlsaXR5IG9mIHRoZSB3 b3JraW5nDQogICBncm91cCBwcm9kdWNpbmcgdGhlbSB0byBjb252ZXJnZSBvbiBhIHNpbmdsZSBz cGVjaWZpY2F0aW9uLCB0aGUgSUVTRw0KICAgcmVxdWlyZWQgdGhlbSB0byBoYXZlIEV4cGVyaW1l bnRhbCBzdGF0dXMgYW5kIGludml0ZWQgdGhlIGNvbW11bml0eQ0KICAgdG8gb2JzZXJ2ZSB0aGVp ciBkZXBsb3ltZW50cyBmb3IgYSBwZXJpb2Qgb2YgdGltZSwgaG9waW5nIGNvbnZlcmdlbmNlDQog ICB3b3VsZCBiZSBwb3NzaWJsZSBsYXRlci4NCg0KICAgQWZ0ZXIgc2l4IHllYXJzLCBzdWZmaWNp ZW50IGV4cGVyaWVuY2UgYW5kIGV2aWRlbmNlIGhhdmUgYmVlbg0KICAgY29sbGVjdGVkIHRoYXQg dGhlIGV4cGVyaW1lbnQgdGh1cyBjcmVhdGVkIGNhbiBiZSBjb25zaWRlcmVkDQogICBjb25jbHVk ZWQsIGFuZCBhIGNvbW1vbiBwYXRoIHRvd2FyZCBjYW4gYmUgc2VsZWN0ZWQuICBUaGlzIG1lbW8N CiAgIHByZXNlbnRzIHRob3NlIGZpbmRpbmdzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From spf2@kitterman.com Fri Feb 17 15:20:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FE821F86F6 for ; Fri, 17 Feb 2012 15:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 xaQ28W6ORvlB for ; Fri, 17 Feb 2012 15:20:54 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AEFC521F86F5 for ; Fri, 17 Feb 2012 15:20:52 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C9F7C20E40BB; Fri, 17 Feb 2012 18:20:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329520850; bh=q+lNNVDSmGKRJedx5koYBqsbWiNH5zBelpZaR2HMKxk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=JuvYt+nwFtVgNNsN8cxqVUNKwAyDtY/v6yU85+3OnKdqll+iM08klGNqFTdjaR1bL OkD864E6BYTdnCN9CJIq6Ea08HSS5IrOTFbQ6yD3+FIgVp3k2pKPutyE04Km/aH4dy E1Hydrj5f5lssf0vvtEetEVbIa4IKkF0Vd22FidE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B080E20E4083; Fri, 17 Feb 2012 18:20:50 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 Feb 2012 18:20:49 -0500 Message-ID: <8470866.03tK8VdFBJ@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; 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] FW: New Version Notification for draft-kucherawy-spfbis-experiment-00.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: Fri, 17 Feb 2012 23:20:55 -0000 On Friday, February 17, 2012 11:42:32 AM Murray S. Kucherawy wrote: > In 2006 the IETF published a suite of protocol documents comprising > SPF and Sender-ID, two proposed email authentication protocols. > Because of interoperability concerns and the inability of the working > group producing them to converge on a single specification, the IESG > required them to have Experimental status and invited the community > to observe their deployments for a period of time, hoping convergence > would be possible later. I know we don't want to reopen old wounds, but I think that it's important to get the history correct. MARID had a single specification. It was shut down without warning by the IETF powers that be without a lot of public discussion in advance. This issues (that I believe) prevented a single result in the MARID working group were not technical. The controversial feature in Sender-ID of using SPF records was not part of the MARID design. It was added by Microsoft in post-MARID drafts. Scott K From msk@cloudmark.com Fri Feb 17 15:24:49 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B76411E809F for ; Fri, 17 Feb 2012 15:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuWyayc3aLRI for ; Fri, 17 Feb 2012 15:24:48 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A7F0811E808D for ; Fri, 17 Feb 2012 15:24:48 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Feb 2012 15:24:48 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 17 Feb 2012 15:24:47 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Fri, 17 Feb 2012 15:24:47 -0800 Thread-Topic: [spfbis] FW: New Version Notification for draft-kucherawy-spfbis-experiment-00.txt Thread-Index: Acztys9CtTefM6DMQuenXaYZ+OOYUQAADG1A Message-ID: References: <8470866.03tK8VdFBJ@scott-latitude-e6320> In-Reply-To: <8470866.03tK8VdFBJ@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] FW: New Version Notification for draft-kucherawy-spfbis-experiment-00.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: Fri, 17 Feb 2012 23:24:49 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Friday, February 17, 2012 3:21 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] FW: New Version Notification for draft-kucherawy-sp= fbis-experiment-00.txt >=20 > MARID had a single specification. It was shut down without warning by > the IETF powers that be without a lot of public discussion in advance. > This issues (that I believe) prevented a single result in the MARID > working group were not technical. >=20 > The controversial feature in Sender-ID of using SPF records was not > part of the MARID design. It was added by Microsoft in post-MARID > drafts. I was basing my text on the content of the IESG Note in each of the documen= ts. In fact, interestingly, the document history of RFC4408 suggests it too was= never a working group item, meaning all four of them were individual submi= ssions. I wasn't part of MARID so I'm learning this all after-the-fact. Anyway, it looks like you're saying deleting the clause about working group= convergence would suffice, correct? -MSK From spf2@kitterman.com Fri Feb 17 15:43:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457F021F852A for ; Fri, 17 Feb 2012 15:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 GiBmiHo-yKYv for ; Fri, 17 Feb 2012 15:43:01 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 86AB521F8523 for ; Fri, 17 Feb 2012 15:43:01 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1B3C720E40BB; Fri, 17 Feb 2012 18:43:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329522181; bh=54tOsRyYtSz00M7fcOmfAwYgjCPc6VgBL/jNV2RxxNs=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=OAFrwmVURJb2ZNIcFmoKe//dZn6eChdredKnJIjFgzrjpAtXLVt1JHF0bMJTj+H6k TDvNsk8pcMevOQP7N5P5K4UKjD8n3BbmqWZvQQHAzZRdvKdQ/CwPgLNQsKRg57Ffzv 8x2OgBq7CTZ4JrBgzzLmQzQQmAxyIbtMftBKs/Fg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id F260120E4083; Fri, 17 Feb 2012 18:43:00 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 Feb 2012 18:42:10 -0500 Message-ID: <4376009.yg8rvfaQ1c@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120217185617.GG31662@mail.yitter.info> References: <20120217185617.GG31662@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 23:43:02 -0000 On Friday, February 17, 2012 01:56:17 PM Andrew Sullivan wrote: > On Fri, Feb 17, 2012 at 10:48:04AM -0800, Murray S. Kucherawy wrote: > > Would it be helpful to prepare an interoperability report, or at > > least go through the exercise of doing so, even if we don't actually > > ask the IESG to publish it? > > This is an excellent suggestion, and I think it would be a wonderful > thing to do. Do we need to organize any formal testing, or do we have > the data we need? I have mentioned the SPF test suite before, but I think it bears mentioning again in this context: http://www.openspf.net/Test_Suite There are at least four open source libraries that pass all the mandatory requirements in the test suite and can be, on that basis, said to be interoperable (given the same input data they wiill produce the same result). http://www.openspf.net/Implementations I think it's probably worth some discussion about what is interoperability in an SPF context. It's not like DKIM where you have to verify messages signed by one impelementation are properly verified by another. SPF libraries consume SPF records and produce a result. Interoperability is, I believe, a function of getting the "same" output from the same input SPF records where "same" may not quite mean identical since there are corner cases that just aren't worth worrying about. Scott K From msk@cloudmark.com Fri Feb 17 15:46:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D502A21F854A for ; Fri, 17 Feb 2012 15:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcBov7up1tjJ for ; Fri, 17 Feb 2012 15:46:02 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7144321F8548 for ; Fri, 17 Feb 2012 15:46:02 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Feb 2012 15:46:01 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 17 Feb 2012 15:46:01 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Fri, 17 Feb 2012 15:46:01 -0800 Thread-Topic: [spfbis] A general cleanup strategy Thread-Index: AcztzenguuvTrverQ9aPTHr/ReDa6gAAB/kQ Message-ID: References: <20120217185617.GG31662@mail.yitter.info> <4376009.yg8rvfaQ1c@scott-latitude-e6320> In-Reply-To: <4376009.yg8rvfaQ1c@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 23:46:02 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Friday, February 17, 2012 3:42 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] A general cleanup strategy >=20 > I have mentioned the SPF test suite before, but I think it bears > mentioning again in this context: Yep, we'll likely need to use that. Thanks for the reminder. > I think it's probably worth some discussion about what is > interoperability in an SPF context. It's not like DKIM where you have > to verify messages signed by one impelementation are properly verified > by another. >=20 > SPF libraries consume SPF records and produce a result. > Interoperability is, I believe, a function of getting the "same" output > from the same input SPF records where "same" may not quite mean > identical since there are corner cases that just aren't worth worrying > about. If you add "same envelope and source IP address" to the mix, I'd agree that= this is probably what we're working with here. The other part of general = SPF interoperability is Received-SPF (use of it, is there anything that con= sumes it, etc.). -MSK From spf2@kitterman.com Fri Feb 17 15:51:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39A611E809F for ; Fri, 17 Feb 2012 15:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 Yt1WAk4Uzpps for ; Fri, 17 Feb 2012 15:51:58 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6E67F11E80AE for ; Fri, 17 Feb 2012 15:51:12 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EA3CD20E40BB; Fri, 17 Feb 2012 18:51:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329522672; bh=DVqZ1FOYAstH/l/ElI2zRYUgU5XjRNY7Uu8E8iYKTKo=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ekxGadsmo0qr6Ol7qYWCvOanv2yK6hHHQnXPEFRjJ9VQupsL0FrgC1Rjk6t811IG3 2HENVmt8Xk5TGFxmRoHVj1Ix+oH4EDSJ1hsgDNyqtxsZUSia0dmvGcnQHUSZ9+aY/b QS8+qs837gHlMGuwDrupTgnBqEiwmtC27GuuNlSI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D0FBF20E4083; Fri, 17 Feb 2012 18:51:11 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 Feb 2012 18:51:11 -0500 Message-ID: <189934391.vakAWxoNpo@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <8470866.03tK8VdFBJ@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] FW: New Version Notification for draft-kucherawy-spfbis-experiment-00.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: Fri, 17 Feb 2012 23:51:58 -0000 On Friday, February 17, 2012 03:24:47 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Scott Kitterman Sent: Friday, February 17, 2012 3:21 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] FW: New Version Notification for > > draft-kucherawy-spfbis-experiment-00.txt > > > > MARID had a single specification. It was shut down without warning by > > the IETF powers that be without a lot of public discussion in advance. > > This issues (that I believe) prevented a single result in the MARID > > working group were not technical. > > > > The controversial feature in Sender-ID of using SPF records was not > > part of the MARID design. It was added by Microsoft in post-MARID > > drafts. > > I was basing my text on the content of the IESG Note in each of the > documents. > > In fact, interestingly, the document history of RFC4408 suggests it too was > never a working group item, meaning all four of them were individual > submissions. I wasn't part of MARID so I'm learning this all > after-the-fact. > > Anyway, it looks like you're saying deleting the clause about working group > convergence would suffice, correct? I think that would make it not definitely wrong. Personally I don't think the interoperability concerns were the primary reason for what happened, but that's all speculation. Scott K From msk@cloudmark.com Fri Feb 17 15:56:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF98321F8605 for ; Fri, 17 Feb 2012 15:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2YHBFG5VsRZ for ; Fri, 17 Feb 2012 15:56:40 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6763521F8604 for ; Fri, 17 Feb 2012 15:56:40 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Feb 2012 15:56:39 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 17 Feb 2012 15:56:40 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Fri, 17 Feb 2012 15:56:38 -0800 Thread-Topic: [spfbis] FW: New Version Notification for draft-kucherawy-spfbis-experiment-00.txt Thread-Index: AcztzySYi4SPd8ohQGOvg8mnJFY42QAAIM5g Message-ID: References: <8470866.03tK8VdFBJ@scott-latitude-e6320> <189934391.vakAWxoNpo@scott-latitude-e6320> In-Reply-To: <189934391.vakAWxoNpo@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] FW: New Version Notification for draft-kucherawy-spfbis-experiment-00.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: Fri, 17 Feb 2012 23:56:40 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Friday, February 17, 2012 3:51 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] FW: New Version Notification for draft-kucherawy-sp= fbis-experiment-00.txt >=20 > > Anyway, it looks like you're saying deleting the clause about working > > group convergence would suffice, correct? >=20 > I think that would make it not definitely wrong. Personally I don't > think the interoperability concerns were the primary reason for what > happened, but that's all speculation. Done in my working copy. Thanks! -MSK From dotis@mail-abuse.org Fri Feb 17 16:34:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0C021F8649 for ; Fri, 17 Feb 2012 16:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 P+Sbb3ktKf0H for ; Fri, 17 Feb 2012 16:34:20 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8208121F8642 for ; Fri, 17 Feb 2012 16:34:11 -0800 (PST) Received: from us-sherryl-e64k.us.trendnet.org (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 6D5561740344 for ; Sat, 18 Feb 2012 00:34:11 +0000 (UTC) Message-ID: <4F3EF203.5080104@mail-abuse.org> Date: Fri, 17 Feb 2012 16:34:11 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> In-Reply-To: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] RFC 4408 issues local-part macro prep for deprecation X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 00:34:21 -0000 Dear S Moonesamy, Use of local-part macros in SPF record sets necessitates repeating all invoked DNS transactions. DNS caching only limits DNS overhead when no local-part macros are used within SPF record sets. It is not uncommon for the use of random local-part names in messages to be sent by malefactors. Such use significantly impacts the utility of SPF without burdening the authoritative servers employed by malefactors. Not only will local-part macros increase the gain of a reflected attack, it also prevents resolving addresses of a set of servers for a specific domain. Permitting local-part assessments will return results based upon entire email addresses and not just the email-address domain. It is common to use SPF to resolve the outbound addresses used by a domain to check reputation listings against these addresses. This use assumes a specific domain has not defined local-part macros in their record set or that it defaults to "postmaster". SPF local-part macros should not be used as a method to vet valid local-part names, as this would permit the use of high speed dictionary attacks to discover which are valid. A domain better protects confidentiality of valid local-parts by postponing acceptance or refusal to the Data command. A reasonable practice for recipients to use to ensure effective caching and to retain the desired utility is to supplant any local-part with that of "postmaster". Otherwise, when SPF processing follows other types of vetting, expansion of the local-part would leak its status via DNS requests. Add: A method for mitigating a reduction in utility or risks associated with local-part macros would be to replace any local-part with that of "postmaster". Regards, Douglas Otis From sm@elandsys.com Fri Feb 17 17:04:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE2D21F8587 for ; Fri, 17 Feb 2012 17:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qt61CgNQvdwF for ; Fri, 17 Feb 2012 17:04: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 001BE21F8585 for ; Fri, 17 Feb 2012 17:04:04 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.96]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1I13lXL015281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 17:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329527039; i=@elandsys.com; bh=4s8NXs74r9XUb/1WRMih48pdDTahC0jQYNa0LL+7mG0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=UpqyazBQgxpC4fvqnnUA6he1NNRxjtUjJFsvPYbpKK0sw5AYVA7rwZEdC7Z6YxkDX sfIejT8Na9ahX0Aa5SdLHc3qZERPjvFztdCJbB71y/ktUMzrMElR/R6jmIHinDe17C /23Fvrr2EAp9MGmXfvWOsu8yITfzkZjbVTf7Lzqk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329527039; i=@elandsys.com; bh=4s8NXs74r9XUb/1WRMih48pdDTahC0jQYNa0LL+7mG0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=d2QSUlEjs1MHbVbQr1SOUGdn842BKvxmS7/vE5+LpaMRR7NMAgbUuChYtvF9Mo6QC phRN1tgLwLTgp9DZJ0Vyob17In/0IZDGto8nWIDl5lFdFZJF1SeJ/iq7Dlsa5yNMt2 hHDyLB+jrA+IVKeQqY8VjmZO0Otv00mh2kom1O8I= Message-Id: <6.2.5.6.2.20120217165333.095235c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 Feb 2012 17:03:31 -0800 To: Douglas Otis From: S Moonesamy In-Reply-To: <4F3EF203.5080104@mail-abuse.org> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3EF203.5080104@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 issues local-part macro prep for deprecation X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 01:04:07 -0000 Hi Doug, At 16:34 17-02-2012, Douglas Otis wrote: >Use of local-part macros in SPF record sets necessitates repeating >all invoked DNS transactions. DNS caching only limits DNS overhead >when no local-part macros are used I added this to the tracker (Issue #14). Regards, S. Moonesamy SPFBIS WG co-chair From hsantos@isdg.net Fri Feb 17 17:29:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0190C11E80BF for ; Fri, 17 Feb 2012 17:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9mYG+JXKJ2H for ; Fri, 17 Feb 2012 17:29:05 -0800 (PST) Received: from mail.catinthebox.net (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 00D1711E80B7 for ; Fri, 17 Feb 2012 17:29:04 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1672; t=1329528542; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=a5GlRmX8mM9mxjcmMR5C3HKVCx8=; b=rwt6RVgEXsgyPGDmBtfP 11blGmdHYXA1AitMXPhZUBcLVq8nnto2RStheqlydMc9cvSQaafXU11SPcia/zO0 ZGy/qxECX9FEG4Z5KXRltnHuwpOJ06A1sw7TGOjj0yG/WC0GW4m/QA4LXkFH4P/2 hpUbfN3T5pKvyfn88bnEik8= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 17 Feb 2012 20:29:02 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2730391574.82094.4824; Fri, 17 Feb 2012 20:29:01 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1672; t=1329528308; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=/cRU5e5 awAhIsnoT2ewlWMZFmL12QzMQxpgxZNOgEns=; b=MV3diaYEZgvQeYLt6gamLaR EEHOqikZACwpQFJEX2QHiSUfO+Z4sW7Vgh5znBV216+YtAAkJQGN1auaQNj324GU 5aN8sxsdMzOtvH0jKVgyKHgz8qVBdN6ERRSxow4uKbXt1ubgrF86Zt7hinjScq7T BSP0STqrLyw8zAaGHFow= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 17 Feb 2012 20:25:08 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3329330001.17364.3520; Fri, 17 Feb 2012 20:25:06 -0500 Message-ID: <4F3EFF03.5040800@isdg.net> Date: Fri, 17 Feb 2012 20:29:39 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andrew Sullivan References: <20120217185617.GG31662@mail.yitter.info> In-Reply-To: <20120217185617.GG31662@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 01:29:06 -0000 Andrew Sullivan wrote: > On Fri, Feb 17, 2012 at 10:48:04AM -0800, Murray S. Kucherawy wrote: >> Would it be helpful to prepare an interoperability report, or at >> least go through the exercise of doing so, even if we don't actually >> ask the IESG to publish it? > > This is an excellent suggestion, and I think it would be a wonderful > thing to do. Do we need to organize any formal testing, or do we have > the data we need? > Please lets be very careful this. State your GOALS and PURPOSE first. There is 9 years of field, operations and customer support experiences, by millions of domains and its doesn't not serve any justice to have isolated subjective conclusions in this extremely small IETF new SPF-BIF working group coming to erroneous conclusions based on limited and isolated collections of data. Lets please understand the "BIG BOYS" do no have the copyright on SPF understanding and should be the principle decided on new SPF directions here. There are millions of small operations/domains and private operations supporting SPF. If you want 9 years worth of SPF log and data statistics, I have it. You can see the 2003 to current summary statistics here, including how SPF or more specifically see the notations on how new DNS based technology starting with LMAP solutions alter how our SMTP server operated: http://www.winserver.com/SpamStats If we are simply considering which SPF feature can be *deprecated*, that is something long time real field operations and customer support implementators should be able to chime on. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From sm@elandsys.com Fri Feb 17 18:55:34 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5947721E8029 for ; Fri, 17 Feb 2012 18:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiM2d67Mo42D for ; Fri, 17 Feb 2012 18:55:31 -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 43EEF21E8025 for ; Fri, 17 Feb 2012 18:55:31 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.96]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1I2tBYW001383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 18:55:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329533724; i=@elandsys.com; bh=SBCqgC+fRP+Np3Gqd03KNifAy4gnOJCaSi8QteTiQfk=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=deI/XhC0d2XCAbyqaFtuzVU9Yhd7pn9H+RGbzxK5j2srE6yKL6u99LT75lg3tedJT tLj1xwSdgRy/cheRDt5x4x+gHqIMt+jwX8srXp/KJpQGi22NPzkl+10KXQ97kNrdhG I0uLXl+WNyBNapFCwEchrLeMcYeLh6DSdjHBb300= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329533724; i=@elandsys.com; bh=SBCqgC+fRP+Np3Gqd03KNifAy4gnOJCaSi8QteTiQfk=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=DJUKY75k9suSHbqjjfiXg7C07Awvk5VI2xwtn7JNXVHg4+x/Wo01Skg7Pn9+rX23H pwX5wbce0lJ6+wVWHZyF6oiMsk6R9XdQ809KSmtowJRNrsTCD7xVzk+oAJKpNc0WVF VLGCSiXEmhznFDG56WoylGxCLd4jjGtiJJpgITWM= Message-Id: <6.2.5.6.2.20120217182541.0a5ab9c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 Feb 2012 18:54:58 -0800 To: Hector Santos From: S Moonesamy In-Reply-To: <4F3EFF03.5040800@isdg.net> References: <20120217185617.GG31662@mail.yitter.info> <4F3EFF03.5040800@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 02:55:34 -0000 Hi Hector, At 17:29 17-02-2012, Hector Santos wrote: >Please lets be very careful this. State your GOALS and PURPOSE >first. There is 9 years From the SPFBIS WG Charter ( http://tools.ietf.org/wg/spfbis/charters ), there is the following deliverable: "A document describing the SPF/Sender-ID experiment and its conclusions to the IESG for publication." The purpose of a working group is to produce its deliverables. The working group has not decided on what goes into the above draft. Andrew and I welcome suggestions and input from WG participants. >Lets please understand the "BIG BOYS" do no have the copyright on >SPF understanding and should be the principle decided on new SPF >directions here. There are millions of small operations/domains and >private operations supporting SPF. This working group is open to anyone who would like to participate. >If you want 9 years worth of SPF log and data statistics, I have it. >You can see the 2003 Thanks for the offer. Andrew posted a request for experimental evidence ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00285.html ). It is an open request to anyone who would like to help out. Philip Gladstone provided some data ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00287.html ). Regards, S. Moonesamy SPFBIS WG co-chair From msk@cloudmark.com Fri Feb 17 19:15:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732D221F8537 for ; Fri, 17 Feb 2012 19:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTrTjZeN9cuu for ; Fri, 17 Feb 2012 19:15:16 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id BC45C21F8531 for ; Fri, 17 Feb 2012 19:15:16 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Feb 2012 19:15:16 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 17 Feb 2012 19:15:15 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Fri, 17 Feb 2012 19:15:14 -0800 Thread-Topic: [spfbis] A general cleanup strategy Thread-Index: Aczt3Ldo9Eh/5+oaRQO+KgTZoAEliQADKwWg Message-ID: References: <20120217185617.GG31662@mail.yitter.info> <4F3EFF03.5040800@isdg.net> In-Reply-To: <4F3EFF03.5040800@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 03:15:17 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Hector Santos > Sent: Friday, February 17, 2012 5:30 PM > To: Andrew Sullivan > Cc: spfbis@ietf.org > Subject: Re: [spfbis] A general cleanup strategy >=20 > Please lets be very careful this. State your GOALS and PURPOSE first. The purpose of an IETF interoperability report is well-documented. RFC5657= is a good place to start if you're unfamiliar with their purpose or struct= ure in our context. There are also tons of implementation reports availabl= e here to show you what sort of thing we're talking about: http://www.ietf.org/iesg/implementation-report.html The one we did for DKIM is in that list. > If you want 9 years worth of SPF log and data statistics, I have it. > You can see the 2003 to current summary statistics here, including how > SPF or more specifically see the notations on how new DNS based > technology starting with LMAP solutions alter how our SMTP server > operated: >=20 > http://www.winserver.com/SpamStats I looked at a few of these, and at best what I found is a column that shows= how many messages were rejected based on SPF on a given day. The data app= ear to stop about four months ago. What we need for an interoperability re= port is more like what Phillip Gladstone already provided, such as a ratio = of sites that appear to have SPF policies published, what type of DNS RR th= ey used, which mechanisms are popular, which extensions are popular, common= errors, how many use macros, any information on false positives, etc. The= point is to evaluate how wide deployment is (or appears to be), what parts= of RFC4408 are actually implemented and which ones are not, how many peopl= e got them right or wrong, any unintended consequences or side effects of d= eployment, etc. And given the context in which RFC4408 is published, any a= ssociated data about Sender-ID would also be helpful. Do you have anything like that? Aggregate rejection counts can be interest= ing, but they don't answer the question an interoperability report presents= . > If we are simply considering which SPF feature can be *deprecated*, > that is something long time real field operations and customer support > implementators should be able to chime on. That is precisely what I believe has been requested. -MSK From spf2@kitterman.com Fri Feb 17 22:25:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6934221F86BD for ; Fri, 17 Feb 2012 22:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 7BNOXtwY9XqG for ; Fri, 17 Feb 2012 22:25:21 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAFF21F86B5 for ; Fri, 17 Feb 2012 22:25:21 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3773820E40BB; Sat, 18 Feb 2012 01:25:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329546321; bh=cQUM11JfETl2yMHCc+5quoWdm7mShKKG8XwYU2xj2mc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=bCGDN/Cr/FC7se59IiPadcJ0hOemJ3KxB8ScAkBXCbWPDXal65G9Xw/aNOegw3U43 Es+cDEiYfvBl22xPyAIBbJxMgLpStXrm/wJC7VuIH5jNAdDRnZhDComKuUSG4KcoTi +CA24vaH9N9CwHKcVmLYunYCdqLSZ5seZGp3lGzI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 293DF20E4083; Sat, 18 Feb 2012 01:25:21 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Feb 2012 01:25:20 -0500 Message-ID: <3675360.6GuuCQV6zP@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; 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] FW: New Version Notification for draft-kucherawy-spfbis-experiment-00.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, 18 Feb 2012 06:25:22 -0000 On Friday, February 17, 2012 11:42:32 AM Murray S. Kucherawy wrote: > As a straw man document for describing the experiment and its conclusions, I > offer this to the WG and volunteer to act as editor. It contains the data > we've seen on the list so far (thanks, Paul and Phillip!), and I believe is > an appropriate thing to submit given the posture we've seen from Pete about > what the IESG would accept as resolution to the experiment. > > I have deliberately avoided populating the Conclusions section on my own. > That's for the Working Group to do by consensus. > > I've polled a number of sources both on this list and off for data to > include in this memo, or whatever other memo we decide to advance. I'll > encourage them to post to this list, or I'll forward what they give me. > > As for my previous message, I did the interoperability report for DKIM so > I'm happy to do one for SPF as well, although I'd also be happy to have > another volunteer. :-) > > -MSK > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, February 17, 2012 11:39 AM > To: Murray S. Kucherawy > Cc: Murray S. Kucherawy > Subject: New Version Notification for > draft-kucherawy-spfbis-experiment-00.txt > > A new version of I-D, draft-kucherawy-spfbis-experiment-00.txt has been > successfully submitted by M. Kucherawy and posted to the IETF repository. > > Filename: draft-kucherawy-spfbis-experiment > Revision: 00 > Title: The SPF/Sender-ID Experiment > Creation date: 2012-02-17 > WG ID: Individual Submission > Number of pages: 6 I set out to review this document. Since it's an early draft, I'll give you general comments. Abstract: Already discussed. Introduction: As I discussed in my comments about the abstract, none of the drafts ultimately published related to SPF or Sender ID were MARID working group documents. The Sender ID documents are closest to the MARID documents, but significant post-MARID changes were made that affected interoperability. I think it's important that these weren't working group document (the SPF documents were developed in public with input handled in a manner very much like an IETF working group on spf-discuss and the Sender ID documents were developed in private by Microsoft). I think it's difficult to know what the IESG of the time was concerned with. Instead of guessing, I would recomend just copying the IESG note that was stamped on the front of all the RFCs without amplification. That's all we really know about what the IESG was concerned about. Finally, this working group wasn't formed to advance "a" protocol. It was formed to advance SPF. There's no point in pretending neutrality where it doesn't exist. "Need for convergence": There isn't any convergence going on, so I'm confused by the title. We're advancing SPF. We aren't folding any Sender ID functionality into SPF. That's out of scope, so I don't think we should be talking about convergence. Evidence of deployment: I think it's worth mentioning that given the paltry level of type SPF deployment there are multiple applications that don't even bother to query for it by default. It may be used in the sense that some small number of records are published, but it's not used in any way that confers interoperability. Appendix A: Since Hotmail doesn't do SPF checks (nor Sender ID mail from checks) I'm somewhat confused about how they could offer about the difference between SPF and Sender ID evaluations? Perhaps they offered data on the frequency of Mail From and From being the same? I suspect this is true for some of the other providers as well. I think we should be careful to call data, data and distinguish that from what we are inferring from this. Scott K From msk@cloudmark.com Fri Feb 17 23:33:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A3B21F86D3 for ; Fri, 17 Feb 2012 23:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ws22BvcAgeGQ for ; Fri, 17 Feb 2012 23:33:05 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC9321F86C8 for ; Fri, 17 Feb 2012 23:33:04 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Feb 2012 23:33:04 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 17 Feb 2012 23:33:03 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Fri, 17 Feb 2012 23:33:00 -0800 Thread-Topic: [spfbis] FW: New Version Notification for draft-kucherawy-spfbis-experiment-00.txt Thread-Index: AczuBhlr/tyBnmFAT7eYKqfjsbtlsAABOuJg Message-ID: References: <3675360.6GuuCQV6zP@scott-latitude-e6320> In-Reply-To: <3675360.6GuuCQV6zP@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] FW: New Version Notification for draft-kucherawy-spfbis-experiment-00.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, 18 Feb 2012 07:33:05 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Friday, February 17, 2012 10:25 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] FW: New Version Notification for draft-kucherawy-sp= fbis-experiment-00.txt >=20 > Introduction: As I discussed in my comments about the abstract, none of > the drafts ultimately published related to SPF or Sender ID were MARID > working group documents. The Sender ID documents are closest to the > MARID documents, but significant post-MARID changes were made that > affected interoperability. I think it's important that these weren't > working group document (the SPF documents were developed in public with > input handled in a manner very much like an IETF working group on spf- > discuss and the Sender ID documents were developed in private by > Microsoft). I've already made that correction in my working copy, at the same time I re= sponded to your comments about the Abstract. > I think it's difficult to know what the IESG of the time was concerned wi= th. > Instead of guessing, I would recomend just copying the IESG note that > was stamped on the front of all the RFCs without amplification. That's > all we really know about what the IESG was concerned about. OK, but rather than copying it, I'll simply refer to it with a "for more de= tail, go there" kind of thing. > Finally, this working group wasn't formed to advance "a" protocol. It > was formed to advance SPF. There's no point in pretending neutrality > where it doesn't exist. This document (or whichever version the WG adopts) is in essence a reply to= the IESG Note, which as I read it also (rightly) remained agnostic as to t= he eventual outcome. It doesn't need to declare the conclusion up top. It= also doesn't need to repeat the working group's charter, which already say= s exactly what you're saying. Essentially with the IESG Note, the IESG of the time posed a challenge. I = think this document is strongest when its reply follows this form or a simi= lar one: 1) This is what we understand the question to be. 2) This is the evidence we have collected since then to answer that questio= n. 3) Here, then, is our answer. > "Need for convergence": There isn't any convergence going on, so I'm > confused by the title. We're advancing SPF. We aren't folding any > Sender ID functionality into SPF. That's out of scope, so I don't > think we should be talking about convergence. I'm attempting to respond directly to the IESG Note, which called for "cons= ensus in the future". If you prefer, I can rename that section to "The Nee= d for Consensus", but it seems to me it says almost exactly the same thing.= Perhaps that's because you're reading it as convergence of technologies, = where I mean it as convergence of support or opinion in favour of one techn= ology. > Evidence of deployment: I think it's worth mentioning that given the > paltry level of type SPF deployment there are multiple applications > that don't even bother to query for it by default. It may be used in > the sense that some small number of records are published, but it's not > used in any way that confers interoperability. I don't think the SPF RR type is germane to the question of which of the tw= o proposals will advance. That's more a property of the implementation rep= ort being discussed on another thread, because it goes to the question of w= hether or not RFC4408bis should drop that part of the specification and dec= lare the use of the SPF RR type deprecated or historic. > Appendix A: Since Hotmail doesn't do SPF checks (nor Sender ID mail from > checks) I'm somewhat confused about how they could offer about the > difference between SPF and Sender ID evaluations? Perhaps they offered > data on the frequency of Mail From and From being the same? I suspect > this is true for some of the other providers as well. I think we > should be careful to call data, data and distinguish that from what we > are inferring from this. Unless I'm mistaken (Paul, please do correct me if I'm wrong), Hotmail prov= ided a statement that their data shows the RFC5322.From domain and the RFC5= 321.MailFrom domain are different in fewer than 5% of the cases they looked= at. Actual numbers are forthcoming. It was TDP's data that claimed that for messages where both results are ava= ilable (129,000 at the moment), they agreed (both pass or both fail) in ove= r 95% of the cases. -MSK From vesely@tana.it Sat Feb 18 01:55:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F38721F8674 for ; Sat, 18 Feb 2012 01:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=0.070, 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 GaTp9AAqyliy for ; Sat, 18 Feb 2012 01:55:54 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5937521F8575 for ; Sat, 18 Feb 2012 01:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1329558950; bh=M1ccwqpcEveIXmzVHqcRu3zQW+6RTgbyVw2a2DMcSDY=; l=292; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=WYnQC+xG2n5OfnOLh7rMGjBG+Jru3WwZ2BhNWxfow18cq9AlzdETDm3JDOo8U2fKd XCm3ACt7fCvXqETOaeiFef4kRGlT1g8z6/1+iVVsJ24JEbG5luGmdVjbno44O4zu5Z HOH2B2RywdH91xlMeOe4Hf1BaSBak1qe1qAy2Vzg= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 18 Feb 2012 10:55:50 +0100 id 00000000005DC035.000000004F3F75A6.0000668F Message-ID: <4F3F75A6.9030202@tana.it> Date: Sat, 18 Feb 2012 10:55:50 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] FW: New Version Notification for draft-kucherawy-spfbis-experiment-00.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, 18 Feb 2012 09:55:55 -0000 On 17/Feb/12 20:42, Murray S. Kucherawy wrote: > I have deliberately avoided populating the Conclusions section on > my own. That's for the Working Group to do by consensus. Is that going to get merged with draft-moonesamy-senderid-spf-conclusion or are they bound to stay separated? From spf2@kitterman.com Sat Feb 18 06:44:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7FE21F85D9 for ; Sat, 18 Feb 2012 06:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 oEUlWnSuGEXY for ; Sat, 18 Feb 2012 06:44:33 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 95B5921F8547 for ; Sat, 18 Feb 2012 06:44:33 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9937820E40BD; Sat, 18 Feb 2012 09:44:32 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329576272; bh=z8aq2g3oEa8x/FpVy+K+wSxe9STqYCOHR9BLJBu1H8Y=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=bKpjWaAehrlR5rpI5yQi3Y64AIEBlueDZ8WPEKyERUpn077Vpa5xE1Edg4xurTPa6 Ben7iKAy2n9R+CmdAh6+wP8XJOUWZh+RqPbgUzANTXymAce1REtY0J7b79BJ3yU71F 3GKF2ujVY5Q+plgtShz0sCgSHl042gPf4BrzJ39I= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7A94720E40BB; Sat, 18 Feb 2012 09:44:32 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Feb 2012 09:44:31 -0500 Message-ID: <3438178.Axq9C10ZnX@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <3675360.6GuuCQV6zP@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] FW: New Version Notification for draft-kucherawy-spfbis-experiment-00.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, 18 Feb 2012 14:44:35 -0000 On Friday, February 17, 2012 11:33:00 PM Murray S. Kucherawy wrote: > > Finally, this working group wasn't formed to advance "a" protocol. It > > was formed to advance SPF. There's no point in pretending neutrality > > where it doesn't exist. > > This document (or whichever version the WG adopts) is in essence a reply to > the IESG Note, which as I read it also (rightly) remained agnostic as to > the eventual outcome. It doesn't need to declare the conclusion up > top. It also doesn't need to repeat the working group's charter, which > already says exactly what you're saying. > > Essentially with the IESG Note, the IESG of the time posed a challenge. I > think this document is strongest when its reply follows this form or a > similar one: > > 1) This is what we understand the question to be. > 2) This is the evidence we have collected since then to answer that > question. 3) Here, then, is our answer. I think it's fair and reasonable to say that a task of the working group is to document the results of the IESG experiment. If I were writing this, I'd have something very much like an executive summary in the introduction, so I'd have the high level result up front, but that's an editorial preference. My major point is that if it's going to say anything about the work of the working group, it should say it correctly and the language I referenced doesn't do that. For this document though I'm not sure it needs to say anything about the working group beyone "this document is a product of the SPFbis working group". Scott K From hsantos@isdg.net Sat Feb 18 17:03:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B0E21E8019 for ; Sat, 18 Feb 2012 17:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.462, 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 PBhdubBpdH7Q for ; Sat, 18 Feb 2012 17:03:14 -0800 (PST) Received: from news.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1B20B21E8011 for ; Sat, 18 Feb 2012 17:03:13 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1482; t=1329613383; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=HCW7FuRM9uICZECaMHnvPgaRIr8=; b=rl/QvlgCMALY5dyl0Rg+ M442/V9vZyYuDX9M08qd1ACHKg2QaeQyTThad7YtRPlIajcLfycZ4mgDWd0ulY7a J2AAKePEkReDUZlRPzQTOSN153rulavF+WRs8msKxwhtthRCQk3g+96ziyJVcHkT 9TWNpEceqtKyJUWVyLOJaGA= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 18 Feb 2012 20:03:03 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2815232375.83943.5732; Sat, 18 Feb 2012 20:03:03 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1482; t=1329613151; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2PK+XYY DQiXjjhpRndGcYyG1dofodX0sjCZ4z2HMDg0=; b=igkGPHYkvrzC6e50knT/wCl jwgVMibSXuW4zQf33/HrJnr9upNQInwVKnLVS0OzLgdeX1F4X1nQsI6Bqll9jNSc is7elffnLl7uMIfS2uqsTV8fRxDpV//7RBohoFsOyosFkHGORz5hbMtQdowAWug2 LiXGtBY2vdWKUDLR+LLY= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 18 Feb 2012 19:59:11 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3414173298.17499.2264; Sat, 18 Feb 2012 19:59:09 -0500 Message-ID: <4F404A37.4030405@isdg.net> Date: Sat, 18 Feb 2012 20:02:47 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120217185617.GG31662@mail.yitter.info> <4F3EFF03.5040800@isdg.net> <6.2.5.6.2.20120217182541.0a5ab9c0@resistor.net> In-Reply-To: <6.2.5.6.2.20120217182541.0a5ab9c0@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 01:03:15 -0000 S Moonesamy wrote: > From the SPFBIS WG Charter ( http://tools.ietf.org/wg/spfbis/charters > ), there is the following deliverable: > > "A document describing the SPF/Sender-ID experiment and its > conclusions to the IESG for publication." > > The purpose of a working group is to produce its deliverables. The > working group has not decided on what goes into the above draft. Andrew > and I welcome suggestions and input from WG participants. It was probably a mistake to decide to refrain from commenting on the last charter writeup other than in the name of moving on, to basically give it +1. But there was items in the charter should needed clarification and had a few unproven conclusions and I did add issue #4 alluding to the one the conflicts. This is why I believe the only relationship is issue #4 and IMV, the above document is different than an Interop report unless the common "goal" of either report to is bring about a justification that SENDER-ID and by default SUBMITTER are no longer supported protocols that SPF implementations should be concern with. Overall, I am little confused with the charter if one the purposes of the SPF-BIF group is to make a conclusion on SENDER-ID/SUBMITTER. That doesn't seem right to me or fair to all current SENDER-ID/SUBMITTER supporters. (Note, the above is cut down version of a much longer message. ) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From SRS0=alDQS=A5==stuart@gathman.org Sat Feb 18 19:51:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB2811E8088 for ; Sat, 18 Feb 2012 19:51:28 -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 OCuBuaIfrDd2 for ; Sat, 18 Feb 2012 19:51:28 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id D6DD011E8075 for ; Sat, 18 Feb 2012 19:51:27 -0800 (PST) Received: from fairfax.gathman.org (gathman [192.168.10.1]) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q1J3oVMP027913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Feb 2012 22:50:33 -0500 Date: Sat, 18 Feb 2012 22:51:17 -0500 (EST) From: "Stuart D. Gathman" To: Hector Santos In-Reply-To: <4F404A37.4030405@isdg.net> Message-ID: References: <20120217185617.GG31662@mail.yitter.info> <4F3EFF03.5040800@isdg.net> <6.2.5.6.2.20120217182541.0a5ab9c0@resistor.net> <4F404A37.4030405@isdg.net> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 03:54:07 -0000 On Sat, 18 Feb 2012, Hector Santos wrote: > Overall, I am little confused with the charter if one the purposes of the > SPF-BIF group is to make a conclusion on SENDER-ID/SUBMITTER. That doesn't > seem right to me or fair to all current SENDER-ID/SUBMITTER supporters. You are correct, however there is the outstanding conflict that rfc4406 paragraph 3.4 has with 4408. A 4408bis should resolve this conflict somehow, although a simple errata for 4406 would be the simplest and least political: "v=spf1 SHOULD be treated as equivalent to spf2.0/mfrom". If an errata for 4406 is out of scope for this WG, then 4408bis should recommend (SHOULD) an "spf2.0/pra" record in addition to any v=spf1 record. This would also address the conflict (and cover existing implementations of 4406 as well). But if 4406 is not actually being used, then no such attention is necessary. -- Stuart D. Gathman "Confutatis maledictis, flamis acribus addictis" - background song for a Microsoft sponsored "Where do you want to go from here?" commercial. From hsantos@isdg.net Sat Feb 18 21:06:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8426211E808C for ; Sat, 18 Feb 2012 21:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.455, 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 EVjBhLXMkYN8 for ; Sat, 18 Feb 2012 21:06:07 -0800 (PST) Received: from news.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0437711E8075 for ; Sat, 18 Feb 2012 21:06:06 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2500; t=1329627964; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=xlmsKop26pVSuecijyVkDlcmsbo=; b=WLYuvGqOIi9WkDLIJzmR LyUovvggPS5ZvNkauSDyg5Q5TlHTci7jpqXDzmH7ifO01xMWOy4d7sJ2Y3yhirzq f/Wd7Z7At18PU+2+dBa022WHYOce7RO3/3InTbpTRE51eL1Oy3havuyBdChNQRJU birtsXzTjkDtZejjN9M9I/0= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 19 Feb 2012 00:06:04 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2829812525.85219.5804; Sun, 19 Feb 2012 00:06:03 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2500; t=1329627728; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=VC38RhV e1o1mHLN1gYMpzAi6TftoqsN5gh+R65yvfRU=; b=Jp+0zTI+nN+gxi8515Oa6G2 x34elUhfe2k+CP0iXweJxd9Tw1L3i70Afik43gs0xtdiBe+EKLdrGV06IWb2Xom7 TfEOecd5Gbb6NTzeHRGN59P/eaZfjdONPl1+QDCVNc30Aw2WCWrv1E1j21g+RZfi FsbA9UoUo9byppPpioCg= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 19 Feb 2012 00:02:08 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3428750626.17530.5476; Sun, 19 Feb 2012 00:02:07 -0500 Message-ID: <4F40833B.1050202@isdg.net> Date: Sun, 19 Feb 2012 00:06:03 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120217185617.GG31662@mail.yitter.info> <4F3EFF03.5040800@isdg.net> <6.2.5.6.2.20120217182541.0a5ab9c0@resistor.net> <4F404A37.4030405@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 05:06:08 -0000 Hi Stuart, In all honesty, since I never believed in SENDER-ID, didn't see how it resolved the "path independent" problem, I never directly supported it but I didn't deny it existence and used SUBMITTER as our indirect support. But what wasn't ever fully investigated if looking for SPF2.0 records was necessary since over 84% of the time, the 5321.MailFrom domain was the same as the PRA. So I agree this is very good material to get resolved. I claim no field experience expertise with SPF2.0 like records. I know there are stated conflicts, but I never got a real feel for that. I mostly focused that it was a payload technology and if you supported SPF, how did it change how a SMTP receiver operated in requiring it to do a payload download or acceptance. This is why I supported SUBMITTER as a indirect non-payload method to support SENDER-ID. In my view, for SPF-BIF, it should stay away from possible erroneous conclusions about the SENDER-ID experiment (let some other WG determine that) and just focus at the SPF codification and consider the optional indirect support for the SMTP extension solution SUBMITTER offers. The fact is this: Add the ESMTP keyword exposure of SUBMITTER to your ESMTP server EHLO response and you quickly will see clients adding the SUBMITTER= parameter to the MAIL FROM command. Any server that is not exposing the keyword can not be making a judgement about it over others that do. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Stuart D. Gathman wrote: > On Sat, 18 Feb 2012, Hector Santos wrote: > >> Overall, I am little confused with the charter if one the purposes of >> the SPF-BIF group is to make a conclusion on SENDER-ID/SUBMITTER. That >> doesn't seem right to me or fair to all current SENDER-ID/SUBMITTER >> supporters. > > You are correct, however there is the outstanding conflict that rfc4406 > paragraph 3.4 has with 4408. A 4408bis should resolve this conflict > somehow, although a simple errata for 4406 would be the simplest and > least political: "v=spf1 SHOULD be treated as equivalent to spf2.0/mfrom". > > If an errata for 4406 is out of scope for this WG, then 4408bis should > recommend (SHOULD) an "spf2.0/pra" record in addition to any v=spf1 record. > This would also address the conflict (and cover existing implementations of > 4406 as well). > > But if 4406 is not actually being used, then no such attention is > necessary. > From ajs@anvilwalrusden.com Mon Feb 20 07:25:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550D921F8796 for ; Mon, 20 Feb 2012 07:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fdgGuYSijkh for ; Mon, 20 Feb 2012 07:25:55 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C7FC121F8715 for ; Mon, 20 Feb 2012 07:25:55 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 18B321ECB422 for ; Mon, 20 Feb 2012 15:25:54 +0000 (UTC) Date: Mon, 20 Feb 2012 10:26:01 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120220152601.GI33344@crankycanuck.ca> References: <20120217185617.GG31662@mail.yitter.info> <4F3EFF03.5040800@isdg.net> <6.2.5.6.2.20120217182541.0a5ab9c0@resistor.net> <4F404A37.4030405@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F404A37.4030405@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 15:25:56 -0000 Dear colleagues, No hat. On Sat, Feb 18, 2012 at 08:02:47PM -0500, Hector Santos wrote: > Overall, I am little confused with the charter if one the purposes > of the SPF-BIF group is to make a conclusion on SENDER-ID/SUBMITTER. > That doesn't seem right to me or fair to all current > SENDER-ID/SUBMITTER supporters. Despite my previous grousing about the lack of success criteria in the IESG note making SPF and Sender-ID experimental, I cannot see any way to interpret the experiment as one other than having two slightly incompatible protocols using the same record from the DNS, only with different meanings. It seems to me therefore that any purported conclusion of the experiment necessarily has something to say about both technologies, even if the focus of that experiment conclusion is on only one of the technologies. If someone disagrees with that view, then I'd be very interested in hearing why. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From dhc2@dcrocker.net Mon Feb 20 08:54:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE7221F85D7 for ; Mon, 20 Feb 2012 08:54:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44DZ9I-2rL65 for ; Mon, 20 Feb 2012 08:54:50 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 333DB21F8738 for ; Mon, 20 Feb 2012 08:54:50 -0800 (PST) Received: from [10.101.2.93] (64.1.211.245.ptr.us.xo.net [64.1.211.245]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1KGshYa014873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Feb 2012 08:54:49 -0800 Message-ID: <4F427AD1.2090705@dcrocker.net> Date: Mon, 20 Feb 2012 08:54:41 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120217185617.GG31662@mail.yitter.info> <4F3EFF03.5040800@isdg.net> <6.2.5.6.2.20120217182541.0a5ab9c0@resistor.net> <4F404A37.4030405@isdg.net> <20120220152601.GI33344@crankycanuck.ca> In-Reply-To: <20120220152601.GI33344@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 20 Feb 2012 08:54:49 -0800 (PST) Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 16:54:54 -0000 On 2/20/2012 7:26 AM, Andrew Sullivan wrote: > It seems to me therefore that any purported > conclusion of the experiment necessarily has something to say about > both technologies, even if the focus of that experiment conclusion is > on only one of the technologies. The challenge is in the detail of "say something about both technologies". The premise that you offer, "slightly incompatible protocols using the same record from the DNS, only with different meanings" does seem terse and the essence of what's interesting. Perhaps the commentary worth reporting on can be limited to: 1. Statements about adoption levels of each 2. Statements about known conflicts by having the records shared. I actually suspect there is little objective data on the latter. Perhaps it can be argued that a sufficiently clear differential on #1 will eliminate the need for answering #2? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Mon Feb 20 09:01:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492A921F8792 for ; Mon, 20 Feb 2012 09:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJGTe+G1TDFB for ; Mon, 20 Feb 2012 09:01:01 -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 F31F421F8753 for ; Mon, 20 Feb 2012 09:01:00 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.237.154]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1KH0bDM001490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2012 09:00:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329757250; i=@elandsys.com; bh=eQ7F+cjpxLn04CCYeXQxh06X/6NFWXDt4fKsdCo4HDs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=rm8cMaj65RbdqKBVwklU9r8W1l5/4VLOT10QgOj7ksNgVym3BCILvTil1NaBuvo6v zlD9SY0WoeEyG+qqOD1S84FEyqLTGePHTdE69Ym29OybwTj9S5GlU6otcwMTt+AoZ1 x3AWvmlVPFPk745k9NthFpaga5t2PkDuvD1uuiBU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329757250; i=@elandsys.com; bh=eQ7F+cjpxLn04CCYeXQxh06X/6NFWXDt4fKsdCo4HDs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=RoaWI+qL8dbA04fnjCvxyr/Hi5TtZSZE2VQDi5ISdWMIim5yLO4CEXqkDLJvO9w64 /Filfc5WUaCjcF9nx87ZMmXxpnZFDzk+MMuWwFBMyVSXtPVHrgI1EEwnMZ4VnPLor9 9Xe8o8JJXrAfA1aVYl07MIi4bOZ6juUxiPjBUTQs= Message-Id: <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Feb 2012 09:00:39 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 17:01:06 -0000 Hello, We would like to start the discussions about the issues. Here are some points from the SPFBIS Charter as guidelines: Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language. Specifically out-of-scope for this working group: * Revisiting past technical arguments where consensus was reached in the MARID working group, except where review is reasonably warranted based on operational experience. * Discussion of the merits of SPF. * Discussion of the merits of Sender-ID in preference to SPF. * Extensions to the SPF protocols. * Removal of existing features that are in current use. Issue #9 is up for discussion. It is based on the following: "This may be a can of worms, but since we're chartered to tidy up where appropriate, I wonder if this might be such a spot. RFC4408 registered a new DNS RRtype, SPF, code 99. Are we able to tell how much deployment it's received? If only little (which is what I suspect, but I've no data to back that up), would it be appropriate to relegate its discussion to an appendix and call it "historic"?" The WG Chairs request your comments. Please keep the subject line so that it is easy for us to keep track of the discussion. Regards, Andrew Sullivan & S. Moonesamy, SPFBIS co-chairs From hsantos@isdg.net Mon Feb 20 10:00:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A064221F86D8 for ; Mon, 20 Feb 2012 10:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7zfqhQ9C4Xo for ; Mon, 20 Feb 2012 10:00:14 -0800 (PST) Received: from ntbbs.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8013D21F8693 for ; Mon, 20 Feb 2012 10:00:14 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3021; t=1329760807; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=GtyoavwcJOxppGgN6YoKXSr5Fyo=; b=juDNk8557PGx8d0TlqRq U2SykoDVYW5svgbi7ZstTYAmqEbJLl59jM7fWhL9DcMD+BKT7mRgLI91n346m4TI 7+bihVCifsrerILdr9Jlbfw2nHYJ62UeJVeErCzsJfUmdyhtGfaKA+MV/g+k1FS3 96X6QgDndjQkUoEl/ZbajF8= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 20 Feb 2012 13:00:07 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2962653897.86315.3840; Mon, 20 Feb 2012 13:00:06 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3021; t=1329760569; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=DcZMbqc cFCoSgMtX3D+ItgUNLPFTCk/WWxRwzXyRiRA=; b=quzx4gL3Am+wfh/A8J4UFj5 WSAEwERiRPp+xjPjJVnXYfrNCpzSDj+PU/44l2NzORgqzLjw+ekLhqDqfnH4wOcX +lT37/XJyuWV5UZRH5KIqTCfvxKB7YUNTCa8yC3cQRx4qZ3roPfA23NWureEtcQA DCHsfVoY1JqG5Ojpzy04= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 20 Feb 2012 12:56:09 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3561591876.17784.1192; Mon, 20 Feb 2012 12:56:08 -0500 Message-ID: <4F428A19.4030200@isdg.net> Date: Mon, 20 Feb 2012 12:59:53 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <20120217185617.GG31662@mail.yitter.info> <4F3EFF03.5040800@isdg.net> <6.2.5.6.2.20120217182541.0a5ab9c0@resistor.net> <4F404A37.4030405@isdg.net> <20120220152601.GI33344@crankycanuck.ca> In-Reply-To: <20120220152601.GI33344@crankycanuck.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 18:00:19 -0000 Hi Andrew, While I believe there is an "common" integrated aspect to it via the SUBMITTER protocol warranting SPF-BIS discussion, in principle I believe no (especially negatives) determination should be done on SENDER-ID (and SUBMITTER) without having input for the principal cogs involved with the protocol namely Microsoft. In addition, as a product vendor, I can't just decide to remove a feature just because the IETF subjectively came up with some conclusion and presumed there will not be an support "Hey what happen!?" repercussions. I'm sure many have experienced this numerous time when its seems some "legacy" item was not used and hence in the name of fine tuning, clean things up, etc, in fact find out it was used after the rugged as been pulled - a non-zero costly mistake. On the other hand, if there is something related to the suggestion that its authors have abandoned it and no longer support the technologies, then in my view, that should be one of the first questions to be answered. If there was still some utility and there is still domain support for it, but there many feel there is some conflicts and/or contention issues, then in my engineering opinion, a solution should be found that perhaps not just focuses on a singular abandonment option. If that indeed is the desire, then it also means a decision to abandon its companion SMTP level technology - SUBMITTER. This is what complicates it because there are more than one pieces of software that are altered, one that just needs to work with RFC5322 and one designed to work with RFC5321. Since its a complicated issue, my suggestion the IETF should not be making that decision until the people who put together SENDER-ID/SUBMITTER and the thousands, if not millions of domains who have long supported SENDER-ID/SUBMITTER are involved in this discussion and contributes to that decision. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Andrew Sullivan wrote: > Dear colleagues, > > No hat. > > On Sat, Feb 18, 2012 at 08:02:47PM -0500, Hector Santos wrote: >> Overall, I am little confused with the charter if one the purposes >> of the SPF-BIF group is to make a conclusion on SENDER-ID/SUBMITTER. >> That doesn't seem right to me or fair to all current >> SENDER-ID/SUBMITTER supporters. > > Despite my previous grousing about the lack of success criteria in the > IESG note making SPF and Sender-ID experimental, I cannot see any way > to interpret the experiment as one other than having two slightly > incompatible protocols using the same record from the DNS, only with > different meanings. It seems to me therefore that any purported > conclusion of the experiment necessarily has something to say about > both technologies, even if the focus of that experiment conclusion is > on only one of the technologies. > > If someone disagrees with that view, then I'd be very interested in > hearing why. > > Best regards, > > A > From john@jlc.net Mon Feb 20 10:09:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68FE21F87B1 for ; Mon, 20 Feb 2012 10:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.383 X-Spam-Level: X-Spam-Status: No, score=-106.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tW9wCFv+XlwM for ; Mon, 20 Feb 2012 10:09:36 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7F88021F87A9 for ; Mon, 20 Feb 2012 10:09:36 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 48EA533C20; Mon, 20 Feb 2012 13:09:36 -0500 (EST) Date: Mon, 20 Feb 2012 13:09:36 -0500 From: John Leslie To: Andrew Sullivan Message-ID: <20120220180936.GA3406@verdi> References: <20120217185617.GG31662@mail.yitter.info> <4F3EFF03.5040800@isdg.net> <6.2.5.6.2.20120217182541.0a5ab9c0@resistor.net> <4F404A37.4030405@isdg.net> <20120220152601.GI33344@crankycanuck.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120220152601.GI33344@crankycanuck.ca> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 18:09:37 -0000 Andrew Sullivan wrote: > > Despite my previous grousing about the lack of success criteria in the > IESG note making SPF and Sender-ID experimental, The IESG of that time wasn't thinking in terms of "success criteria" for Experimental RFCs. (IMHO, of course, there were no Narrative Scribes at the time.) The IESG has since started giving serious consideration to what might represent "success" or "failure" of an Experiment. So it is certainly fair game to try to satisfy that (vague) criterion. > I cannot see any way to interpret the experiment as one other than > having two slightly incompatible protocols using the same record > from the DNS, only with different meanings. This is an excellent way to look at it. (IMHO.) The trouble is, how can we tell which published v=spf1 records intend which meaning? Both SPF and Sender-ID specified algorithms for evaluating these records; and while the difference in meaning was usually slight, the difference in algorithms was significant. > It seems to me therefore that any purported conclusion of the experiment > necessarily has something to say about both technologies, I quite agree! > even if the focus of that experiment conclusion is on only one of the > technologies. I look at it a bit differently. This WG was created to "advance" SPF to Proposed Standard. The IESG (IMHO) agreed that an apparent obstacle to that was the existence of two Experimental protocols using the same DNS record differently. One way out of that would be to have the SPF Proposed Standard define a totally new DNS record, and avoid any confusion. (It appears that nobody liked that way.) Another way is to conclude both Experiments and declare a single meaning for the already-existing v=spf1 records. Enough people liked that that this WG was created. That means that this WG _must_ consider the opinions of those who prefer Sender-ID meanings; and IMHO the IESG wants the process of considering those documented in the first milestone: " " Aug 2012 A document describing the SPF/Sender-ID experiment and its " conclusions to the IESG for publication. > If someone disagrees with that view, then I'd be very interested in > hearing why. I really don't "disagree" -- but I think the focus should be on our obligation to consider any alleged benefits of the Sender-ID meaning. This does seem in discord with the "Specifically out-of-scope" " " * Discussion of the merits of Sender-ID in preference to SPF item; but I think we're safe to interpret the "describe the experiment" language as more-recently-added, and more binding. It is, IMHO, possible to "describe" an "experiment" without arguing the perceived "merits" of one approach. I hope the WGCs will be tolerant of discussion of the Sender-ID meaning for the v=spf1 records to the extent it contributes to the wording of our first milestone. Our progress will be easiest if we satisfy Sender-ID proponents that their opinions have been respected and considered _before_ that document goes to IETF LastCall. -- John Leslie From johnl@iecc.com Mon Feb 20 10:15:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AE221F8610 for ; Mon, 20 Feb 2012 10:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.89 X-Spam-Level: X-Spam-Status: No, score=-109.89 tagged_above=-999 required=5 tests=[AWL=1.309, 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 KjfL4Ge0Khna for ; Mon, 20 Feb 2012 10:14:56 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7463421F860D for ; Mon, 20 Feb 2012 10:14:55 -0800 (PST) Received: (qmail 72004 invoked from network); 20 Feb 2012 18:14:53 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Feb 2012 18:14:53 -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=4f42b7cd.xn--30v786c.k1202; i=johnl@user.iecc.com; bh=VW3TziMQTwJF3oKzQnGOcaTtgsHRwRI+/8Vtfh5XpVI=; b=iLjVrbBiNyyrlP3M3pw+716W/2mPs/hZZmIM9Tnip9m7tpQnIjcxNFdgUiNQUvSLZbU0vb2RysYY9SvvAf4ZkHD0g7oFCeKHGr4PcTA9lhZKzmRJlP+IbXB2Hy0RJ6l8P7LJMmfiFgR4UYE4fW5Vcbns8eieB9cC+WYn9qLxfOk= 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=4f42b7cd.xn--30v786c.k1202; olt=johnl@user.iecc.com; bh=VW3TziMQTwJF3oKzQnGOcaTtgsHRwRI+/8Vtfh5XpVI=; b=lw4xnHJQ8kcmpZ1+nk+2viAiClKqn6hsE327NlgL4+q1ozgpsX7+dTbwmW3sTf0S5CbBkF+sHNSADRQk92dwUaxjrpCX2SSrKoWyyB32pNd4ojTYiuzNX4XCbMzmhzemt6k+vmSyzEaw+wfpCxaYu0IM7yef7f505CESHkQ9sgQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 20 Feb 2012 21:14:30 -0000 Message-ID: <20120220211430.14741.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4F427AD1.2090705@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@bbiw.net Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 18:15:01 -0000 >1. Statements about adoption levels of each > >2. Statements about known conflicts by having the records shared. > >I actually suspect there is little objective data on the latter. > >Perhaps it can be argued that a sufficiently clear differential on #1 will >eliminate the need for answering #2? I'm not aware of anyone other than Hotmail who did a non-trivial deployment of Sender-ID, and I wouldn't expect them to publish their results. So I agree, there isn't likely to be enough data to say anything about #2. R's, John -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@iecc.com Mon Feb 20 10:24:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DFB21F8680 for ; Mon, 20 Feb 2012 10:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.906 X-Spam-Level: X-Spam-Status: No, score=-109.906 tagged_above=-999 required=5 tests=[AWL=1.293, 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 ZZFCxLPN9BCn for ; Mon, 20 Feb 2012 10:24:16 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 520D321F85A4 for ; Mon, 20 Feb 2012 10:24:10 -0800 (PST) Received: (qmail 75601 invoked from network); 20 Feb 2012 18:24:08 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Feb 2012 18:24:08 -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=4f42b9f8.xn--3zv.k1202; i=johnl@user.iecc.com; bh=gIMX1WPuFzX/5761j4y8rUeAoIThFE0mT8+H1gQoIEc=; b=f8yp8pw2BA2K7DijVR6JJubns3uJNDu58fXrv5ccWHItvhgM2m/D/uBMcgF07GLLDtxtGJeuGrp/OAiOty+cqMulg+7p2YbthQP2Y0nq+WvQ7SV4WJOrTZDKGjtoiCWo9MPCXSuXk6ggrdG/RU2wm9DW7A8LLZyCAKdu0xN6yLg= 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=4f42b9f8.xn--3zv.k1202; olt=johnl@user.iecc.com; bh=gIMX1WPuFzX/5761j4y8rUeAoIThFE0mT8+H1gQoIEc=; b=Odyumz0ZwPlvvLOqctFfXsGC4FU9uNw/DsYMuSB21crQaO8qZ7CzKYPpRplBke8nbMgudRY5VhAoW8ZF9gF8DosU+oxYQ6ShsxtpZtXSfTbJzdh9NFCAWiqi9iEsAbHVhH/RJ2MzwPtLt07bCxQe4qEL0hgH8SdNzDMW6HfLung= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 20 Feb 2012 21:23:46 -0000 Message-ID: <20120220212346.17006.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: sm+ietf@elandsys.com Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 18:24:21 -0000 I'm OK with the list. >RFC4408 registered a new DNS RRtype, SPF, code 99. I think it's worth looking at the SPF RR and deciding whether it provides an overall benefit. R's, John -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From WebMaster@Commerco.Net Mon Feb 20 10:53:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38B821F84DD for ; Mon, 20 Feb 2012 10:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zsQmPskDvse for ; Mon, 20 Feb 2012 10:53:54 -0800 (PST) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7680221F84D4 for ; Mon, 20 Feb 2012 10:53:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=M2gwH49XH8//K0jLkm8Sw4xGek6cF+4N7CiIrj/rFeBwRsjon5qSHdFzVFshBN0Nx+SzqeD67o8x1GNcLBO1rDpHoXmA8qnR/iLeXDEJujX1lq0jeJ7N+li97bRDCyuKnTIQSML2SaXrahWha9d/xDWH5qvxVlkXVL2bRog+k/0= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Mon, 20 Feb 2012 18:53:53 +0000 Message-ID: <4F4296BB.8060207@Commerco.Net> Date: Mon, 20 Feb 2012 11:53:47 -0700 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120220212346.17006.qmail@joyce.lan> In-Reply-To: <20120220212346.17006.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 18:53:58 -0000 John, Historical observation. I think you may find that the SPF RR was done in part to support version SPF V1 in addition to using the TXT RR, but the major perceived benefit of having the SPF RR in place and available was for any future SPF versions (e.g., V3 the next logical future version of SPF V1). As I recall, in those days there were some concerns about overusing the TXT RR, making a separate RR for SPF a logical step for both the applications developers and the user implementers (those who put the RRs in their DNS host files). As such, I think its existence does provide a benefit for both V1 and any future SPF implementations. Arguably, far less user implementers have added SPF RR records to their host files than TXT RR records, but then the V1 experimental does support both. My guess is that a future SPF V3 will probably have only want to support the SPF RR. Best, Alan M. On 2/20/2012 2:23 PM, John Levine wrote: > I'm OK with the list. > >> RFC4408 registered a new DNS RRtype, SPF, code 99. > > I think it's worth looking at the SPF RR and deciding whether it > provides an overall benefit. > > R's, > John > From spf2@kitterman.com Mon Feb 20 11:04:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F0521F8569 for ; Mon, 20 Feb 2012 11:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 BcQthdMibzGZ for ; Mon, 20 Feb 2012 11:04:35 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2A98721F8599 for ; Mon, 20 Feb 2012 11:04:35 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 09A6E20E40DA; Mon, 20 Feb 2012 14:04:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329764674; bh=GW8cIMzEoLugTAIjAgdEcZugrUOYRhGEEfVnebQoWYU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=W+7mlEMi4sQ/0h95WLQD7AVyyFotkzbNa0p3NLBDiuuUnRqdpvrybdqHwI5E7rGoG NJOwgJHmBgBxPor9JGiEcImOJchyzPDqAIhq9VX2DhWB4XB/rb9WxGzx5iZI5y5dEF n6oou2ylfwTNTzeE28P+rDzbSkWYiHeaKBpDAjQo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DFB8E20E408E; Mon, 20 Feb 2012 14:04:33 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Feb 2012 14:04:32 -0500 Message-ID: <2540299.gmSuznFx9K@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F428A19.4030200@isdg.net> References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 19:04:39 -0000 On Monday, February 20, 2012 12:59:53 PM Hector Santos wrote: > While I believe there is an "common" integrated aspect to it via the > SUBMITTER protocol warranting SPF-BIS discussion, ... Hector, I believe you are mistaken. SUBMITTER and SPF are unrelated. It's not about SPF/Sender-ID integration at all. It's about using body PRA Sender-ID results instead of SPF. I don't think SUBMITTER is on topic for this working group. Scott K From spf2@kitterman.com Mon Feb 20 11:19:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963D821F86E0 for ; Mon, 20 Feb 2012 11:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 58mzjx8CNYr8 for ; Mon, 20 Feb 2012 11:19:13 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4764621F85B1 for ; Mon, 20 Feb 2012 11:19:13 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BD56320E40DA; Mon, 20 Feb 2012 14:19:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329765552; bh=YZKi+liL3hybFJTuoL6fzgkq9B3n2ec0h/FhsST4HTc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=n41OSRZ4vXiusI2ET8ioXxTcU+pKMmpD1CQZYKRLdAaByWwFEZahyAS0uhYd3K2Sw 58FF2xZg9NSi7A64/l8/o/sHUEoukBxEr6gPZ4Q13bGVjrNcM3Vdw/ovWPkzytqM2+ fB849gWGkYA3v2PQAPIFMsvJQY9bM4PppW4nw19s= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9EB2B20E408E; Mon, 20 Feb 2012 14:19:12 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Feb 2012 14:19:11 -0500 Message-ID: <31663665.dhxMF5JUGp@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 19:19:17 -0000 On Monday, February 20, 2012 09:00:39 AM S Moonesamy wrote: > Hello, > > We would like to start the discussions about the issues. Here are > some points from the SPFBIS Charter as guidelines: > > Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any enhancements > that have already gained widespread support, and addition of > clarifying language. > > Specifically out-of-scope for this working group: > > * Revisiting past technical arguments where consensus was reached in > the MARID working group, except where review is reasonably > warranted based on operational experience. > > * Discussion of the merits of SPF. > > * Discussion of the merits of Sender-ID in preference to SPF. > > * Extensions to the SPF protocols. > > * Removal of existing features that are in current use. > > Issue #9 is up for discussion. It is based on the following: > > "This may be a can of worms, but since we're chartered to tidy up > where appropriate, I wonder if this might be such a spot. > > RFC4408 registered a new DNS RRtype, SPF, code 99. > > Are we able to tell how much deployment it's received? If only > little (which is what I suspect, but I've no data to back that up), > would it be appropriate to relegate its discussion to an appendix and > call it "historic"?" > > The WG Chairs request your comments. Please keep the subject line so > that it is easy for us to keep track of the discussion. I would like to suggest a nuance about the removal aspect of the charter. I think there is an implicit expectation in the way that the charter is drafted that removal of features that are in use will inevitably harm interoperability. In this one case, I don't think it does. We can tell based on DNS surveys that there is very little Type SPF deployment. In cases where there is a type SPF record, there are three possible cases: 1. Identical Type TXT record published 2. Non-identical type TXT record published 3. No TXT record published. Since virtually all SPF records are only published as Type TXT, there is no ineroperability benefit to also publishing Type SPF. If there is a non-identical record published the publishing domain will get inconsistent results since not all receivers of SPF records look up Type SPF. Publishing the same information in two places places an operational burden (not just the dual publishing, but also keeping the information in sync). If there is no TXT record and just a Type SPF record then the results are going to be poor. Only Type SPF checkers will see the record. The RFC 4408 language (SHOULD check SPF first) also causes additional DNS lookups that will almost always be fruitless. I think that Type SPF was created based on fear of what might happen if Type TXT were overused. Those fears have not come to pass and we should drop Type SPF as harmful to interopability. There is no operational case for a transition now and I think it's safe to assume there won't be. There is no reasonable case where dropping Type SPF will cause SPF record publishers to change their records (I don't consider publishing only a Type SPF record a reasonable case - it just doesn't work due to the predominance of Type TXT in SPF records). I don't object to reserving Type SPF for some future non-compatible SPFvX, but for v1, I think we can and should drop it. Scott K From msk@cloudmark.com Mon Feb 20 11:27:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BD721F87D0 for ; Mon, 20 Feb 2012 11:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnxxaYjWOp5T for ; Mon, 20 Feb 2012 11:27:31 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 45EF121F87C7 for ; Mon, 20 Feb 2012 11:27:31 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 20 Feb 2012 11:27:30 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 20 Feb 2012 11:27:30 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 20 Feb 2012 11:27:31 -0800 Thread-Topic: [spfbis] A general cleanup strategy Thread-Index: AczwAoBqP1gzClp3R2SMeO5qic2BkwAAwJIw Message-ID: References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> <2540299.gmSuznFx9K@scott-latitude-e6320> In-Reply-To: <2540299.gmSuznFx9K@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 19:27:31 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Monday, February 20, 2012 11:05 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] A general cleanup strategy >=20 > I don't think SUBMITTER is on topic for this working group. It is part of the cluster of documents that included Sender-ID, PRA and SPF= , insofar as the same IESG Note was attached to it.=20 I've been collecting data about SUBMITTER deployment as part of the interop= erability report idea, and the experiment closure. I can certainly stop an= d change that if we decide it's out of scope, but they look quite linked to= me. -MSK From ajs@anvilwalrusden.com Mon Feb 20 11:31:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF1521F8687 for ; Mon, 20 Feb 2012 11:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 NDzmG8-y6OPG for ; Mon, 20 Feb 2012 11:31:08 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB1821F85D7 for ; Mon, 20 Feb 2012 11:31:06 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EA0F81ECB420 for ; Mon, 20 Feb 2012 19:31:04 +0000 (UTC) Date: Mon, 20 Feb 2012 14:31:03 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120220193102.GD33775@crankycanuck.ca> References: <20120220212346.17006.qmail@joyce.lan> <4F4296BB.8060207@Commerco.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F4296BB.8060207@Commerco.Net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 19:31:09 -0000 No hat. On Mon, Feb 20, 2012 at 11:53:47AM -0700, Commerco WebMaster wrote: > As I recall, in those days there were some concerns about overusing > the TXT RR, making a separate RR for SPF a logical step for both the > applications developers and the user implementers (those who put the > RRs in their DNS host files). Not only "in those days". Some of us who have spent a little time working on the DNS continue to have reservations about overuse of the TXT RRTYPE on the grounds that the DNS is a typed database, and the overloading of TXT violates the typing system. I am aware of the reasons why people use TXT records, and I'm not the least bit surprised that the SPF RRTYPE turns out to have been a waste of bits. But TXT subtyping has its problems (IMO not least of which is that we're seeing three layers of underscore, with no principled reason why it shouldn't go deeper). Someone will accuse me of empty or, worse, academic formalism, I'm sure; but I still think the TXT records are a dirty hack that mostly works because there are still few enough of them that it doesn't hurt yet. I don't believe that will be true forever (although I've certainly been wrong before), and when there are enough TXT records with in-RNAME subtyping that we have a problem, it will be much harder to clean up. > RR records, but then the V1 experimental does support both. My > guess is that a future SPF V3 will probably have only want to > support the SPF RR. While I pray to the DNS fairy that your prediction comes true, I don't believe it will. SPF v3 will need to be backward compatible with v2 and v1, which means that it'll use TXT too. -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Mon Feb 20 11:37:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B99C21F879E for ; Mon, 20 Feb 2012 11:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 u7SGRWD2qK82 for ; Mon, 20 Feb 2012 11:37:34 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9921621F86E0 for ; Mon, 20 Feb 2012 11:37:34 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2216620E40DA; Mon, 20 Feb 2012 14:37:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329766654; bh=H6XQno1Ii/wDyGrrv9mWJNv/eeEobWyK44CFVdHafSc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=LNErgmR6w+e2j54o54bv7CFbinMg5ehEmjxbrl1aL0AjF9tZFZjuEhhG9IFOnmLQI ny1V+Lv0BX00EcUljghLK6eQMqSFzfXWF8s6xpSAI12W2XXsRgJ4u/We3GfGNWfni6 Ge9FCQkYW5lRRyCUZAvwahtLIxnabwuvPZmzapW8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0516C20E408E; Mon, 20 Feb 2012 14:37:33 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Feb 2012 14:37:32 -0500 Message-ID: <1511964.YRbWeFy5Z0@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <2540299.gmSuznFx9K@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] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 19:37:35 -0000 On Monday, February 20, 2012 11:27:31 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Scott Kitterman Sent: Monday, February 20, 2012 11:05 AM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] A general cleanup strategy > > > > I don't think SUBMITTER is on topic for this working group. > > It is part of the cluster of documents that included Sender-ID, PRA and SPF, > insofar as the same IESG Note was attached to it. > > I've been collecting data about SUBMITTER deployment as part of the > interoperability report idea, and the experiment closure. I can certainly > stop and change that if we decide it's out of scope, but they look quite > linked to me. I agree it's part of the experimental closeout. I don't the it's something that's in scope to consider for 4408bis itself. Scott K From msk@cloudmark.com Mon Feb 20 11:38:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E4B21F8792 for ; Mon, 20 Feb 2012 11:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwwrIQsRYNMO for ; Mon, 20 Feb 2012 11:38:08 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5EC21F86E0 for ; Mon, 20 Feb 2012 11:38:08 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 20 Feb 2012 11:38:07 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 20 Feb 2012 11:38:07 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 20 Feb 2012 11:38:08 -0800 Thread-Topic: [spfbis] #9: RFC 4408 SPF RR type Thread-Index: Aczv8UQLV2N/uDLSRyC+8YNgJDPwqgAFTwKg Message-ID: References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 19:38:08 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of S Moonesamy > Sent: Monday, February 20, 2012 9:01 AM > To: spfbis@ietf.org > Cc: Andrew Sullivan > Subject: Re: [spfbis] #9: RFC 4408 SPF RR type >=20 > Issue #9 is up for discussion. It is based on the following: >=20 > "This may be a can of worms, but since we're chartered to tidy up > where appropriate, I wonder if this might be such a spot. >=20 > RFC4408 registered a new DNS RRtype, SPF, code 99. >=20 > Are we able to tell how much deployment it's received? If only little > (which is what I suspect, but I've no data to back that up), would it > be appropriate to relegate its discussion to an appendix and call it > "historic"?" >=20 > The WG Chairs request your comments. Please keep the subject line so > that it is easy for us to keep track of the discussion. These data were submitted earlier by Philip Gladstone in response to this q= uestion: http://www.ietf.org/mail-archive/web/spfbis/current/msg00354.html Are there others on the list that can produce similar reports? My own data= roughly match the large number of SPF-publishing domains, but don't break = it down by RR type. I can work on creating such a report but it will take = me a week or two to do so due to other commitments. -MSK From msk@cloudmark.com Mon Feb 20 11:38:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB6D21F879E for ; Mon, 20 Feb 2012 11:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYVgOshfvkxr for ; Mon, 20 Feb 2012 11:38:35 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 20A8921F8792 for ; Mon, 20 Feb 2012 11:38:35 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 20 Feb 2012 11:38:34 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 20 Feb 2012 11:38:34 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 20 Feb 2012 11:38:35 -0800 Thread-Topic: [spfbis] A general cleanup strategy Thread-Index: AczwBxw3Di0A6IKFR/CscDqyFlMZ7wAABdbw Message-ID: References: <2540299.gmSuznFx9K@scott-latitude-e6320> <1511964.YRbWeFy5Z0@scott-latitude-e6320> In-Reply-To: <1511964.YRbWeFy5Z0@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 19:38:35 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Monday, February 20, 2012 11:38 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] A general cleanup strategy >=20 > I agree it's part of the experimental closeout. >=20 > I don't the it's something that's in scope to consider for 4408bis > itself. Ah. Check. -MSK From sm@elandsys.com Mon Feb 20 12:12:30 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20F021F87FC for ; Mon, 20 Feb 2012 12:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUtazpuLu8lB for ; Mon, 20 Feb 2012 12:12:29 -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 DF75021F87FB for ; Mon, 20 Feb 2012 12:12:29 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.237.154]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1KKC2ZF009868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2012 12:12:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329768742; i=@elandsys.com; bh=S4Yrw3fGdl3kDJ8GA79cAwHYeytoIq9nPu4vovNCLZY=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=S0+yZaZ0+JMuSsFTuJk1U6zFec128C3DppbNIk7kJOCp+kWAvXLfmY030S00CgS6o TiVVCGfnS7DWAwhNplepbK9EphG1URtvSytuPpTnvs0/9zYgfecAXvqerndXyyPiBI dlcGREFB5pXJRN+2ylihMlhGPIa0DBCbCsrAYdwk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329768742; i=@elandsys.com; bh=S4Yrw3fGdl3kDJ8GA79cAwHYeytoIq9nPu4vovNCLZY=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=VcePq+tw6ND/+/6vCIQd9aKZ/hswttRpyoJpEJUMPe66f5zKs0dfV3dEQU9m0z/Sl ovaJ+klej1ZPG9REl+vSs4Er79ULZ+8EmzQFOhET+nRBMrRI4Vo5u1ILWAXLfs5teB mtH6aCRScTd3CbMab5UT/jFTsIvxa9n5KMorWdvE= Message-Id: <6.2.5.6.2.20120220120125.08d4afe8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Feb 2012 12:04:22 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.c05ace881b9d1ba34bcbb6f922d09b7e@tools.ietf.org> References: <061.c05ace881b9d1ba34bcbb6f922d09b7e@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] #3: RFC 4408 - Errata #99 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 20:12:30 -0000 At 12:58 07-02-2012, spfbis issue tracker wrote: >#3: RFC 4408 - Errata #99 > > 1) On page 1, in the IESG notes, "aParticipants" should be > "Participants". > > 2) On page 40, the US-ASCII normative reference has an incorrectly > indented second paragraph. Instead of: > > [US-ASCII] American National Standards Institute (formerly United > States of America Standards Institute), "USA Code for > Information Interchange, X3.4", 1968. > > ANSI X3.4-1968 has been replaced by newer versions with slight > modifications, but the 1968 version remains definitive for > the Internet. > > it should be: > > [US-ASCII] American National Standards Institute (formerly United > States of America Standards Institute), "USA Code for > Information Interchange, X3.4", 1968. > > ANSI X3.4-1968 has been replaced by newer versions with > slight modifications, but the 1968 version remains > definitive for the Internet. [snip] >Ticket URL: I'll classify Errata #99 as editorial. If there are any objections, please post them to this mailing list. Regards, S. Moonesamy SPF WG co-chair From spf2@kitterman.com Mon Feb 20 12:25:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1836121F84DF for ; Mon, 20 Feb 2012 12:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 vzHbDuWMJoGH for ; Mon, 20 Feb 2012 12:25:53 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 78DDE21F84CF for ; Mon, 20 Feb 2012 12:25:53 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CEDD320E40DA; Mon, 20 Feb 2012 15:25:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329769552; bh=avM6cFIUKtvSIOFonpY5h8PZoU55Uc8/qrdg/AqqYOU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=mjXHEmrgsZfUVvVwhZkirsG1RJKiWEguhtjqml73NWB2JJ2djI4G1zka484QAakWy LAC1Lydhe2tuCJOfl+n2cumo6S4j5e/4Ty3VmhTaanjf+g+WtnMlK+ZxAm5shEmaIN KwWniPPVLbrQC/UeJSoQoiF2ntUPuFcSooUlqndk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B597F20E408E; Mon, 20 Feb 2012 15:25:52 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Feb 2012 15:25:51 -0500 Message-ID: <4541043.FAKVWqEuLc@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120220120125.08d4afe8@elandnews.com> References: <061.c05ace881b9d1ba34bcbb6f922d09b7e@tools.ietf.org> <6.2.5.6.2.20120220120125.08d4afe8@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #3: RFC 4408 - Errata #99 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 20:25:56 -0000 On Monday, February 20, 2012 12:04:22 PM S Moonesamy wrote: > At 12:58 07-02-2012, spfbis issue tracker wrote: > >#3: RFC 4408 - Errata #99 > > > > 1) On page 1, in the IESG notes, "aParticipants" should be > > > > "Participants". > > > > 2) On page 40, the US-ASCII normative reference has an incorrectly > > > > indented second paragraph. Instead of: > > > > [US-ASCII] American National Standards Institute (formerly > > United > > > > States of America Standards Institute), > > "USA Code for > > Information Interchange, X3.4", 1968. > > > > ANSI X3.4-1968 has been replaced by newer versions with slight > > > > modifications, but the 1968 version > > remains definitive for > > the Internet. > > > > it should be: > > > > [US-ASCII] American National Standards Institute (formerly > > United > > > > States of America Standards Institute), > > "USA Code for > > Information Interchange, X3.4", 1968. > > > > ANSI X3.4-1968 has been replaced by newer > > versions with > > slight modifications, but the 1968 version > > remains > > definitive for the Internet. > > [snip] > > >Ticket URL: > > I'll classify Errata #99 as editorial. If there are any objections, > please post them to this mailing list. The I.D. that I prepared as the input document for the working group has the editorial errata corrected already. It might be simpler to start from that. Scott K From sm@elandsys.com Mon Feb 20 12:28:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667DC21F85FC for ; Mon, 20 Feb 2012 12:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmVaGMCRUEfp for ; Mon, 20 Feb 2012 12:28:20 -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 CB63B21F84DF for ; Mon, 20 Feb 2012 12:28:20 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.237.154]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1KKS0NS003846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2012 12:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329769692; i=@elandsys.com; bh=nxKPxACjmbrwf/meiZhRVTDazYv4j25b595SMKNeM/s=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=YKVQJbnCOOK+ToM4ugfnfp4eMZJD3tfLnYx6fdr4YFlTEoQ6tJSsddCjGMFZVORcH MPSVU+dKozzcTzn2bbzGqPePk5rbSDYgif8j4TBZUf/ReolLBWzQ6/0sqDWI+MIgCM TRRaaL5Yx3MnkX5URkH3OgePMPzxZR3F6Gk1SJEU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329769692; i=@elandsys.com; bh=nxKPxACjmbrwf/meiZhRVTDazYv4j25b595SMKNeM/s=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=vau8vbC7c5XVmFkoib2WUPRpNCwkuJi4a9BTZsdTLvZlnn4vWcDoeZfW5mhyy9vtB 9p9Oj/7kse8N72Rj9F9uJfFdw6XWH8Aal7AvG7u90/+YC9J7x62iZPXNJbJLEwdIss 7wvUeJFlwR24X9QWxFCdwOKVyEXvuUE/xuL6lo/s= Message-Id: <6.2.5.6.2.20120220121328.09836200@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Feb 2012 12:16:11 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.ab475cb67717b7fa7169bfb593bbd82f@tools.ietf.org> References: <061.ab475cb67717b7fa7169bfb593bbd82f@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] #2: RFC 4408 Section B.3 - Errata #2250 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 20:28:23 -0000 At 12:57 07-02-2012, spfbis issue tracker wrote: >#2: RFC 4408 Section B.3 - Errata #2250 > > Section B.3 says: > > $ORIGIN _spf.example.com. mary.mobile-users A > 127.0.0.2 fred.mobile-users A 127.0.0.2 > 15.15.168.192.joel.remote-users A 127.0.0.2 > 16.15.168.192.joel.remote-users A 127.0.0.2 > > > It should say: > > $ORIGIN _spf.example.com. > mary.mobile-users A 127.0.0.2 > fred.mobile-users A 127.0.0.2 > 15.15.168.192.joel.remote-users A 127.0.0.2 > 16.15.168.192.joel.remote-users A 127.0.0.2 > > > Notes: > > The DNS zone file example has incorrect line breaks. [snip] >Ticket URL: I'll classify this issue as "hold for document update". When the 4408bis draft is opened, the working group can look into the above. Regards, S. Moonesamy SPFBIS WG co-chair From sm@elandsys.com Mon Feb 20 12:28:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D3021F87D7 for ; Mon, 20 Feb 2012 12:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nK77hSmjV+mx for ; Mon, 20 Feb 2012 12:28:27 -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 6DBFA21F85FC for ; Mon, 20 Feb 2012 12:28:27 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.237.154]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1KKS0NU003846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2012 12:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329769700; i=@elandsys.com; bh=XJZLBO+4Te6ZuO/ff7fYZg3CRjXJQCy1RUXPBlBPdaw=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Content-Transfer-Encoding; b=GfHb8U0Y+8gAjPbUR3ggCsLOp2UNLbP/e1Rp1I3P3tlTNlXv4OmjOv7keRv4mp2t8 46+Vygkqxfox+vkK3nLLqJF1YiYYI3wM8D4PAl1MOzJ4zj9/Aovo+BeEC7szxhShh/ Us2RDYUPvAhKqVAlu2E6AIOUYVxxBWQtBVAfp/5U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329769700; i=@elandsys.com; bh=XJZLBO+4Te6ZuO/ff7fYZg3CRjXJQCy1RUXPBlBPdaw=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Content-Transfer-Encoding; b=C4bbmz35IOysqybWyO6DLtuCzvLZ6FzyvP49Ut3aS5udPFrEy4+GLrqaAafRaPYmw E9OP/M9v/qDOKkbt9zLRNJu2M4tPJS+573AScDh/pprJ+Wu0fcMl+C9aT360P7Mro8 RDydr6nxMUW7ejU07q+U10KeD1kzPgWvCU0/9s+I= Message-Id: <6.2.5.6.2.20120220121621.09835f70@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Feb 2012 12:26:03 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.106923e4028c687741e1db9f5fb04a3a@tools.ietf.org> References: <061.106923e4028c687741e1db9f5fb04a3a@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Andrew Sullivan Subject: Re: [spfbis] #8: RFC 4408 Mixed use of RFC2119 words X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 20:28:28 -0000 At 13:06 07-02-2012, spfbis issue tracker wrote: >#8: RFC 4408 Mixed use of RFC2119 words > > Message from Murray Kucherawy on 6 Feb 2012: > > In scanning RFC4408, I see a number of places where may=9D is used, but= in > all-lowercase, presumably to avoid invoking its RFC2119 meaning. We have > other words like can=9D, might=9D, could=9D that do a better job of= avoiding > ambiguity. I suggest this be revisited in production of the =ADbis= version. > http://www.ietf.org/mail-archive/web/spfbis/current/msg00326.html [snip] >Ticket URL: I'll classify this issue as "hold for document=20 update". The discussion can wait until the 4408bis draft is opened. Regards, S. Moonesamy SPFBIS WG co-chair=20 From sm@elandsys.com Mon Feb 20 12:35:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF00621F85C9 for ; Mon, 20 Feb 2012 12:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x0M+4eBzVkv for ; Mon, 20 Feb 2012 12:35:44 -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 ED2C821F852A for ; Mon, 20 Feb 2012 12:35:43 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.237.154]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1KKS0NW003846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Feb 2012 12:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329769708; i=@elandsys.com; bh=70kEPDXoXP6ZliBwMEoXlIM9E7tdPKakI7vkT3bxHuc=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=lFzYDTjKNvqgUJGTy8BIGvlXfj4y4V7rNhljIww2705q9MKYovKLJ6Js6Zy45Hbk5 090rRzuVP4o10x5GEemKQ8J0WzfkszsBBed5+ntPhkPq1x6AnYUa1/4Bm+bQajb5VD FerWlyfBhrVj39YyoiuVWR3e/4zNv4pyfNEVLLew= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329769708; i=@elandsys.com; bh=70kEPDXoXP6ZliBwMEoXlIM9E7tdPKakI7vkT3bxHuc=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=fUJ3MUOwM8Yz6FXRVpZAZLBrHLG46mW00nyMjTRnH3KGrmBFQ/G8ThYtzynz2SKZz 75pGedC8PdJLXPJS+DBGi2bDXh1PPzNNe+cKhu5aOEPvEdvBf9dHLeKL+tegBoGj0B zGnQHft0S7ynBJQF1IqJ+237xtm8ja3R2Jnuai2I= Message-Id: <6.2.5.6.2.20120220122639.09835ce0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Feb 2012 12:27:50 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20120216170001.GB29243@mail.yitter.info> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <20120216170001.GB29243@mail.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 20:35:44 -0000 Hello, I cannot get the information for Errata #994. Could someone please post them to this mailing list so that they can be tracked as issues? Regards, S. Moonesamy From WebMaster@Commerco.Net Mon Feb 20 13:04:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F8D21F84A3 for ; Mon, 20 Feb 2012 13:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffBVEdXUTaaT for ; Mon, 20 Feb 2012 13:04:05 -0800 (PST) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 13AED21F84A0 for ; Mon, 20 Feb 2012 13:04:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=yPvwIiFOmzA2qZ5PG1ZRxvaDJBm3wPfvneWLor5BmJIBaQ+htVuwILjXMnfgR0UpwWscMvvaaZHExy6EUxd/cvJ6IQuVACa1tuZpfnqWxIwdA8HAgIaNDfO+yLjLIlwguZktGcsrU4zSuSKjlC2n8cB5h9Rvui2XnRQhEXacqvs= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Mon, 20 Feb 2012 21:04:02 +0000 Message-ID: <4F42B53C.6070508@Commerco.Net> Date: Mon, 20 Feb 2012 14:03:56 -0700 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120220212346.17006.qmail@joyce.lan> <4F4296BB.8060207@Commerco.Net> <20120220193102.GD33775@crankycanuck.ca> In-Reply-To: <20120220193102.GD33775@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 21:04:06 -0000 On 2/20/2012 12:31 PM, Andrew Sullivan wrote: > No hat. :-) > > On Mon, Feb 20, 2012 at 11:53:47AM -0700, Commerco WebMaster wrote: > >> As I recall, in those days there were some concerns about overusing >> the TXT RR, making a separate RR for SPF a logical step for both the >> applications developers and the user implementers (those who put the >> RRs in their DNS host files). > > Not only "in those days". Some of us who have spent a little time > working on the DNS continue to have reservations about overuse of the > TXT RRTYPE on the grounds that the DNS is a typed database, and the > overloading of TXT violates the typing system. I am aware of the > reasons why people use TXT records, and I'm not the least bit > surprised that the SPF RRTYPE turns out to have been a waste of bits. > But TXT subtyping has its problems (IMO not least of which is that > we're seeing three layers of underscore, with no principled reason why > it shouldn't go deeper). Someone will accuse me of empty or, worse, > academic formalism, I'm sure; but I still think the TXT records are a > dirty hack that mostly works because there are still few enough of > them that it doesn't hurt yet. I don't believe that will be true > forever (although I've certainly been wrong before), and when there > are enough TXT records with in-RNAME subtyping that we have a problem, > it will be much harder to clean up. > +1 agree entirely. >> RR records, but then the V1 experimental does support both. My >> guess is that a future SPF V3 will probably have only want to >> support the SPF RR. > > While I pray to the DNS fairy that your prediction comes true, I don't > believe it will. SPF v3 will need to be backward compatible with v2 > and v1, which means that it'll use TXT too. > Perhaps a way to get around the issue of TXT RRs backward compatibility with SPF V1 in future version may be found in how SPF V3 and other future versions will specify how they handle such requests. In other words, in any future versions, specify a check for SPF RR as the first request and then, failing an SPF RR, go look for a TXT RR for compatibility with V1 in yet another request. With enough requests for SPF RR preceding the TXT RR requests, as the newer implementation pattern become more frequently observed, hopefully most DNS administrators will get the hint and establish the new SPF RRs in their authoritative host zone files and ultimately be able to get rid of the SPF V1 TXT RRs. Best, Alan M From spf2@kitterman.com Mon Feb 20 13:10:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DB321F8596 for ; Mon, 20 Feb 2012 13:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAfEGIzv1iLW for ; Mon, 20 Feb 2012 13:10:36 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0A20921F858F for ; Mon, 20 Feb 2012 13:10:36 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 888BF20E40DA; Mon, 20 Feb 2012 16:10:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329772235; bh=h0Kz/ck87juCZhMlTfRFnwyjziCDMAhDtmSVEoz6tg8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Qt5lpZdxbKUn+Bk3hQw8LNdjVrRyZaUDZMSFxXYfhAvvhIhuva1LdhrxxANoSGoVV uFD5QedSspSbukyr2ADegDyvnknU/qbeNBQM9PqMeeatYHo7RQ52KeqNgJ1uJ+RInU wCZyDm5STj4703lTdAogRtj7kRRKb3qNbYzX6TfU= Received: from scott-latitude-e6320.localnet (unknown [209.144.63.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id AD57D20E408E; Mon, 20 Feb 2012 16:10:34 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Feb 2012 16:10:24 -0500 Message-ID: <2140478.AvMiToEcEc@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120220122639.09835ce0@resistor.net> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <20120216170001.GB29243@mail.yitter.info> <6.2.5.6.2.20120220122639.09835ce0@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] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 21:10:37 -0000 On Monday, February 20, 2012 12:27:50 PM S Moonesamy wrote: > Hello, > > I cannot get the information for Errata #994. Could someone please > post them to this mailing list so that they can be tracked as issues? > RFC4408, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E- Mail, Version 1", April 2006 Source of RFC: IETF - NON WORKING GROUP Area Assignment: app Errata ID: 994 Status: Held for Document Update Type: Technical Reported By: Frank Ellermann Date Reported: 2007-11-06 Held for Document Update by: Alexey Melnikov Date Held: 2010-07-01 See this page for discussion of errata for RFC 4408: Notes: Alexey: if there is interest in revising the document, then it should be updated to incorporate some changes suggested on the above web page. (not part of the errata from the IETF web site, but substitute openspf.net where it says openspf.org). Scott K From dhc2@dcrocker.net Mon Feb 20 13:13:25 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595A321F874A for ; Mon, 20 Feb 2012 13:13:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIQht4kKP52T for ; Mon, 20 Feb 2012 13:13:24 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A572821F8675 for ; Mon, 20 Feb 2012 13:13:24 -0800 (PST) Received: from [10.101.2.93] (64.1.211.245.ptr.us.xo.net [64.1.211.245]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1KLDJGh020463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Feb 2012 13:13:24 -0800 Message-ID: <4F42B76C.3080509@dcrocker.net> Date: Mon, 20 Feb 2012 13:13:16 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> <31663665.dhxMF5JUGp@scott-latitude-e6320> In-Reply-To: <31663665.dhxMF5JUGp@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]); Mon, 20 Feb 2012 13:13:24 -0800 (PST) Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 21:13:25 -0000 On 2/20/2012 11:19 AM, Scott Kitterman wrote: > Since virtually all SPF records are only published as Type TXT, there is no > interoperability benefit to also publishing Type SPF. This is probably the essential, objective observation. If correct, it means that there is both no benefit in retaining the record and no detriment in removing it.[1] Even better is that removing it makes the specification that much simpler. Considering how it "might" be used or how it "should" be used or any other hypothetical or preference is not productive. d/ [1] FWIW I both would expect it to be true and believe it actually is. -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Mon Feb 20 13:13:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF94F21F8793 for ; Mon, 20 Feb 2012 13:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4co2zT666+f for ; Mon, 20 Feb 2012 13:13:36 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BAC1521F876E for ; Mon, 20 Feb 2012 13:13:35 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3692D20E40DA; Mon, 20 Feb 2012 16:13:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329772415; bh=QOW8veAS2ktqiI08Ila48mB1RRljGG/Jaixksoj6gcs=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=R1XvlaSxfUatiDcWG3wX640CQQmFyBlygU2jgvgqJ6kUsCGahR+8xIkjo6ZRr7pAL IjUHDA3JwHAZul0HpXL4vowxQZa2nfo/SrRJoGXvMnfvycOYuxGZKehgEHB8wGR4yI CLB88/xqC6/i7SEV9MxUh2cPf4xvs8hO7+9IcbfI= Received: from scott-latitude-e6320.localnet (unknown [209.144.63.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2941620E408E; Mon, 20 Feb 2012 16:13:33 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Feb 2012 16:13:21 -0500 Message-ID: <2315228.TssiT3d69m@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F42B53C.6070508@Commerco.Net> References: <20120220212346.17006.qmail@joyce.lan> <20120220193102.GD33775@crankycanuck.ca> <4F42B53C.6070508@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] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 21:13:36 -0000 On Monday, February 20, 2012 02:03:56 PM Commerco WebMaster wrote: > On 2/20/2012 12:31 PM, Andrew Sullivan wrote: > > No hat. > : > :-) > : > > On Mon, Feb 20, 2012 at 11:53:47AM -0700, Commerco WebMaster wrote: > >> As I recall, in those days there were some concerns about overusing > >> the TXT RR, making a separate RR for SPF a logical step for both the > >> applications developers and the user implementers (those who put the > >> RRs in their DNS host files). > > > > Not only "in those days". Some of us who have spent a little time > > working on the DNS continue to have reservations about overuse of the > > TXT RRTYPE on the grounds that the DNS is a typed database, and the > > overloading of TXT violates the typing system. I am aware of the > > reasons why people use TXT records, and I'm not the least bit > > surprised that the SPF RRTYPE turns out to have been a waste of bits. > > But TXT subtyping has its problems (IMO not least of which is that > > we're seeing three layers of underscore, with no principled reason why > > it shouldn't go deeper). Someone will accuse me of empty or, worse, > > academic formalism, I'm sure; but I still think the TXT records are a > > dirty hack that mostly works because there are still few enough of > > them that it doesn't hurt yet. I don't believe that will be true > > forever (although I've certainly been wrong before), and when there > > are enough TXT records with in-RNAME subtyping that we have a problem, > > it will be much harder to clean up. > > +1 agree entirely. > > >> RR records, but then the V1 experimental does support both. My > >> guess is that a future SPF V3 will probably have only want to > >> support the SPF RR. > > > > While I pray to the DNS fairy that your prediction comes true, I don't > > believe it will. SPF v3 will need to be backward compatible with v2 > > and v1, which means that it'll use TXT too. > > Perhaps a way to get around the issue of TXT RRs backward compatibility > with SPF V1 in future version may be found in how SPF V3 and other > future versions will specify how they handle such requests. > > In other words, in any future versions, specify a check for SPF RR as > the first request and then, failing an SPF RR, go look for a TXT RR for > compatibility with V1 in yet another request. > > With enough requests for SPF RR preceding the TXT RR requests, as the > newer implementation pattern become more frequently observed, hopefully > most DNS administrators will get the hint and establish the new SPF RRs > in their authoritative host zone files and ultimately be able to get rid > of the SPF V1 TXT RRs. We aren't here to debate some theoretical future SPF version, but the one we have. Type 99 (SPF) is not serving a useful purpose right now, so we should mark it deprecated (don't use) and quit worrying about it. The DNS Type can't be reused for something else, so it can always be revived in the event there's some future effort that can effectively use it. Scott K From dhc2@dcrocker.net Mon Feb 20 13:17:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2460A21F86DF for ; Mon, 20 Feb 2012 13:17:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+mWsFJFeWuQ for ; Mon, 20 Feb 2012 13:17:25 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 252AF21F854E for ; Mon, 20 Feb 2012 13:17:25 -0800 (PST) Received: from [10.101.2.93] (64.1.211.245.ptr.us.xo.net [64.1.211.245]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1KLHJUk020595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Feb 2012 13:17:24 -0800 Message-ID: <4F42B85C.6020508@dcrocker.net> Date: Mon, 20 Feb 2012 13:17:16 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120220212346.17006.qmail@joyce.lan> <4F4296BB.8060207@Commerco.Net> <20120220193102.GD33775@crankycanuck.ca> In-Reply-To: <20120220193102.GD33775@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 20 Feb 2012 13:17:25 -0800 (PST) Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 21:17:26 -0000 On 2/20/2012 11:31 AM, Andrew Sullivan wrote: > Not only "in those days". Some of us who have spent a little time > working on the DNS continue to have reservations about overuse of the > TXT RRTYPE on the grounds that the DNS is a typed database, and the > overloading of TXT violates the typing system. Use of a TXT directly under the domain name doesn't scale, because it takes the equivalent of deep packet inspection to distinguish among different apps' use of the record.[1] It also means that all of those records get return together, potentially hitting some maximums. However, SPF uses the record already and doesn't use the new RR. No precedent is being set by acknowledging this reality. In spite of the fact that an SPF RR is a cleaner approach, enough time has passed to make clear that it's not being adopted and, therefore, won't be. d/ [1] Just to be thorough, it's worth noting that use of an underscore nodename fixes the scaling and ambiguity concerns, since it defines the /one/ application using the record. -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Mon Feb 20 13:29:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E811921F84E6 for ; Mon, 20 Feb 2012 13:29:05 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYZAvreIqTlG for ; Mon, 20 Feb 2012 13:29:05 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2C06321F84D2 for ; Mon, 20 Feb 2012 13:29:05 -0800 (PST) Received: from [10.101.2.93] (64.1.211.245.ptr.us.xo.net [64.1.211.245]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1KLSx7I020829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Feb 2012 13:29:04 -0800 Message-ID: <4F42BB18.6090500@dcrocker.net> Date: Mon, 20 Feb 2012 13:28:56 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <20120216170001.GB29243@mail.yitter.info> In-Reply-To: <20120216170001.GB29243@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 20 Feb 2012 13:29:05 -0800 (PST) Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 21:29:06 -0000 On 2/16/2012 9:00 AM, Andrew Sullivan wrote: > Please do draw this work to the attention of MAAWG participants. While yes, MAAWG needs to hear about current status, folks should be aware that the current IETF working group effort was actually triggered by a recent desire in MAAWG to get SPF standardized. It followed a circuitous path and took awhile, but that was the impetus that I observed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs@anvilwalrusden.com Mon Feb 20 13:34:59 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31B521E800F for ; Mon, 20 Feb 2012 13:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 YX1iWg2TxOve for ; Mon, 20 Feb 2012 13:34:58 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 876DE21E800C for ; Mon, 20 Feb 2012 13:34:58 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 959191ECB422 for ; Mon, 20 Feb 2012 21:34:57 +0000 (UTC) Date: Mon, 20 Feb 2012 16:34:55 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120220213455.GI33775@mail.yitter.info> References: <20120220212346.17006.qmail@joyce.lan> <4F4296BB.8060207@Commerco.Net> <20120220193102.GD33775@crankycanuck.ca> <4F42B85C.6020508@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F42B85C.6020508@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 21:34:59 -0000 On Mon, Feb 20, 2012 at 01:17:16PM -0800, Dave CROCKER wrote: > However, SPF uses the record already and doesn't use the new RR. No > precedent is being set by acknowledging this reality. Yes, I think that's what I was saying. > [1] Just to be thorough, it's worth noting that use of an > underscore nodename fixes the scaling and ambiguity concerns, since > it defines the /one/ application using the record. Only sort of, and it brings with it additional costs; but I don't think this is the right list on which to have that debate. We don't have to agree about why some dumb thing has managed to establish itself (or even whether it's dumb) in order to agree _that_ it has established itself, and the latter is the only question here. A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Mon Feb 20 13:39:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A982B21F84A1 for ; Mon, 20 Feb 2012 13:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfP8KrrBg4d5 for ; Mon, 20 Feb 2012 13:39:01 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id F421421F849A for ; Mon, 20 Feb 2012 13:39:00 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 20 Feb 2012 13:39:00 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 20 Feb 2012 13:39:00 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 20 Feb 2012 13:39:01 -0800 Thread-Topic: [spfbis] RFC 4408 issues list Thread-Index: AczwDznF8uK8u/B0S1uThDE2xKSNrgACIDwg Message-ID: References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <20120216170001.GB29243@mail.yitter.info> <6.2.5.6.2.20120220122639.09835ce0@resistor.net> In-Reply-To: <6.2.5.6.2.20120220122639.09835ce0@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 21:39:01 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of S Moonesamy > Sent: Monday, February 20, 2012 12:28 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] RFC 4408 issues list >=20 > Hello, >=20 > I cannot get the information for Errata #994. Could someone please > post them to this mailing list so that they can be tracked as issues? For systems reasons, openspf.org has been replaced (for now, at least) by o= penspf.net. The URL in that erratum can be accessed at that alternate doma= in. Thus, go here: http://www.openspf.net/RFC_4408/Errata. The page contains links to eight errata that were logged on that web site, = but not in the RFC Editor's errata tracking tool. Do we need to create IET= F errata instead? -MSK From dhc2@dcrocker.net Mon Feb 20 13:40:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159D921F859E for ; Mon, 20 Feb 2012 13:40:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzsB0fZ0zlcA for ; Mon, 20 Feb 2012 13:40:25 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5A63121F858E for ; Mon, 20 Feb 2012 13:40:25 -0800 (PST) Received: from [10.101.2.93] (64.1.211.245.ptr.us.xo.net [64.1.211.245]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1KLeIIR021020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2012 13:40:23 -0800 Message-ID: <4F42BDBF.7010708@dcrocker.net> Date: Mon, 20 Feb 2012 13:40:15 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Andrew Sullivan References: <20120220212346.17006.qmail@joyce.lan> <4F4296BB.8060207@Commerco.Net> <20120220193102.GD33775@crankycanuck.ca> <4F42B85C.6020508@dcrocker.net> <20120220213455.GI33775@mail.yitter.info> In-Reply-To: <20120220213455.GI33775@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 20 Feb 2012 13:40:24 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 21:40:26 -0000 On 2/20/2012 1:34 PM, Andrew Sullivan wrote: >> [1] Just to be thorough, it's worth noting that use of an >> underscore nodename fixes the scaling and ambiguity concerns, since >> it defines the /one/ application using the record. > > Only sort of, and it brings with it additional costs; but I don't > think this is the right list on which to have that debate. Agree that pursuing this isn't for this list; however in practical terms, that change in how the record has used seems to have fundamentally altered the acceptability of using TXT (and SRV) records. I'll also mention that I hadn't heard the "additional costs" concern as a serious concern. To the extent it has meaningful constituency, it would be worth finding the right venue for resolving it. -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Mon Feb 20 13:40:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0520F21F858E for ; Mon, 20 Feb 2012 13:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.922 X-Spam-Level: X-Spam-Status: No, score=-109.922 tagged_above=-999 required=5 tests=[AWL=1.277, 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 iv8hyk0tis1a for ; Mon, 20 Feb 2012 13:40:26 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C7D2E21F8595 for ; Mon, 20 Feb 2012 13:40:25 -0800 (PST) Received: (qmail 48329 invoked from network); 20 Feb 2012 21:40:24 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Feb 2012 21:40:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f42bdc8.xn--3zv.k1202; i=johnl@user.iecc.com; bh=3dIFDWGIncaCcyM2RNmufSCMksPsJUdbUgW/To4UKUU=; b=aofZJLkzSORx5+u+q0mkIOWdtLTYcHYYbO5uALKBaGcrj0icR6USm9M7k+b3JMuVqoLVnZ8Bt9APV1A9EJkpJFXu9iZW4+rXlXVZAA3hs4iDFK1kp0k5fIucISS+ua3LL7Lx931vnZ25gNkAM7T1uqcMOXTIQnEwYIQKkjy3PuY= 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=4f42bdc8.xn--3zv.k1202; olt=johnl@user.iecc.com; bh=3dIFDWGIncaCcyM2RNmufSCMksPsJUdbUgW/To4UKUU=; b=w4wvbwwnauD2CY7eHyQ52xsvVPS6t9unhEqAZi7Uf8xELVPlPR0abkkBpesqkoTEgnZKN2gpHDgg5XVKJBLBJRFnaDsGLHR8RkHVvgcgZ2lX58TW/ORpBXEQS4IH0PgNWoRUGGUohduKNBZQcgcM/5i02veKRG1OFsoG9ec6wJ8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 20 Feb 2012 21:40:02 -0000 Message-ID: <20120220214002.59167.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4F42B85C.6020508@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@bbiw.net Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 21:40:27 -0000 >However, SPF uses the record already and doesn't use the new RR. No precedent >is being set by acknowledging this reality. That was my thinking. But at the moment, all we need to do is to put the type 99 RR on the list of issues to settle before we're done. R's, John From spf2@kitterman.com Mon Feb 20 13:45:11 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437C821E800F for ; Mon, 20 Feb 2012 13:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A89AhvKWp+-q for ; Mon, 20 Feb 2012 13:45:10 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E420021F8573 for ; Mon, 20 Feb 2012 13:45:09 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 184CC20E40DA; Mon, 20 Feb 2012 16:44:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329774293; bh=yv6uwP1uKPIhXo3QDnU8jSzehQKxy0AsqqFfN4dvfF0=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=eA/3EfvJgGqaZtjwFoUasDvWwXVwSqjGlJL1Xg+IWX23XsNOPnP3KG2kXdqn1LyvZ 0fw8uDlz9RsXGpQf4XMEcoNRnc23YjfwcPUWwLhXNshBxhOhBO9hlSrm/A8JJ2jU7n pizmBgDBjyc/53OIXP7602yEXj7NrkrbE7lsUgI4= Received: from scott-latitude-e6320.localnet (unknown [209.144.63.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 79F0A20E408E; Mon, 20 Feb 2012 16:44:52 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Feb 2012 16:44:47 -0500 Message-ID: <1618345.7dPBqcXJlk@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 21:45:11 -0000 Sorry for being late. I forgot about this one. Paragraph 2.2, The MAIL FROM Identity, includes this statement: SPF clients MUST check the "MAIL FROM" identity. SPF clients check the "MAIL FROM" identity by applying the check_host() function to the "MAIL FROM" identity as the . There are applications that check HELO first and can reach a final conclusion about message disposition based on that check. In such a case, the Mail From check is a waste of resources. I'm recommend changing this to either: SPF clients MUST check the "MAIL FROM" identity unless a HELO check has already produced a definititive policy result. ... or SPF clients SHOULD check the "MAIL FROM" identity (e.g. unless a HELO check has already produced a definititive policy result). ... Scott K From spf2@kitterman.com Mon Feb 20 13:51:49 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5033421E8012 for ; Mon, 20 Feb 2012 13:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVovtkCIDCfe for ; Mon, 20 Feb 2012 13:51:45 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5D46321E800F for ; Mon, 20 Feb 2012 13:51:45 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E552F20E40EA; Mon, 20 Feb 2012 16:51:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329774704; bh=NsdrBSzhW338SLhVU21j4zEW5pAAfv5gN+WG96/G4+o=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=l7pCh6qsEgXGfKS0RmeAVyyvgVQGJUgzhh8n9jK5oHbcId0RVFhdShRbzVgLB16kj qa4ylWb8Ru8RHNRoApL4M8eiapQhHAr+RVLQ0cYJqF+YUfK2h7RGTsSziV7UVWNLGA NQO5AkPr7yc3b3ECN0fkgAFWcvZmu34PJO5nS3fw= Received: from scott-latitude-e6320.localnet (unknown [209.144.63.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9BCA720E408E; Mon, 20 Feb 2012 16:51:44 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Feb 2012 16:51:41 -0500 Message-ID: <1538117.qzxlIXHdov@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <6.2.5.6.2.20120220122639.09835ce0@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] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 21:51:49 -0000 On Monday, February 20, 2012 01:39:01 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of S Moonesamy Sent: Monday, February 20, 2012 12:28 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] RFC 4408 issues list > > > > Hello, > > > > I cannot get the information for Errata #994. Could someone please > > post them to this mailing list so that they can be tracked as issues? > > For systems reasons, openspf.org has been replaced (for now, at least) by > openspf.net. The URL in that erratum can be accessed at that alternate > domain. Thus, go here: http://www.openspf.net/RFC_4408/Errata. > > The page contains links to eight errata that were logged on that web site, > but not in the RFC Editor's errata tracking tool. Do we need to create > IETF errata instead? Please, let's not. They're all documented issues and that's all we need to consider them. Scott K From msk@cloudmark.com Mon Feb 20 14:09:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB92821E8010 for ; Mon, 20 Feb 2012 14:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTK6OV3B1WBR for ; Mon, 20 Feb 2012 14:09:23 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 78B1821F856C for ; Mon, 20 Feb 2012 14:09:23 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 20 Feb 2012 14:09:22 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 20 Feb 2012 14:09:22 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 20 Feb 2012 14:09:23 -0800 Thread-Topic: [spfbis] RFC 4408 issues list Thread-Index: AczwGdrOSj/EHgWzT4OG08vfKlBAtAAAk4gg Message-ID: References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <6.2.5.6.2.20120220122639.09835ce0@resistor.net> <1538117.qzxlIXHdov@scott-latitude-e6320> In-Reply-To: <1538117.qzxlIXHdov@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:09:24 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > Behalf Of Scott Kitterman > Sent: Monday, February 20, 2012 1:52 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] RFC 4408 issues list >=20 > Please, let's not. They're all documented issues and that's all we > need to consider them. I don't care either way, as long as procedure is followed. And I don't kno= w if there's anything formal about handling externally-tracked errata. I just don't want this to come back on us later. From sm@elandsys.com Mon Feb 20 14:15:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C845821E8011 for ; Mon, 20 Feb 2012 14:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yQbnaJ+sNaU for ; Mon, 20 Feb 2012 14:15:01 -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 62A8721E8010 for ; Mon, 20 Feb 2012 14:15:01 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1KMEcK3009318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2012 14:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329776091; i=@elandsys.com; bh=SEif2/w3kgiRTkWs/1saaORc2D2GuA2hWCdaVTpm8OI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=KgyzpSvGa1G4Vff+GA4QSXvaqMl+CuWvidDjGQRrU4ZasZCruH8DHRlfb0cOgHiZw aAsukt4r6JD6Nmz3N91eTSl/hHw9+ejAvoP3UFIx+2nRE8cag9vdi95AdTWpEh6RFh bxOo4ML7lrVWLek1AhWxxVJNbXlN2f6v2L7BJsVk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329776091; i=@elandsys.com; bh=SEif2/w3kgiRTkWs/1saaORc2D2GuA2hWCdaVTpm8OI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=vHSyv2nATdeIGnQm1oZxItLjcp0cizlaMkvGEojYkfD7t7+SRszm2BvLKBjplLWGA nBtV9KRjDBMslTh1rg6PToRWPOQtQkL+W/LCw3DBxE5Wu7B2aJKXIF66hFM2OoNqMj GvwMunG2ZrHYujTkBprkinaiACNj+TCUyuDL3YpU= Message-Id: <6.2.5.6.2.20120220131927.0909fc40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Feb 2012 14:07:28 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <2140478.AvMiToEcEc@scott-latitude-e6320> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <20120216170001.GB29243@mail.yitter.info> <6.2.5.6.2.20120220122639.09835ce0@resistor.net> <2140478.AvMiToEcEc@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:15:02 -0000 At 13:10 20-02-2012, Scott Kitterman wrote: >Notes: > >Alexey: if there is interest in revising the document, then it should be >updated to incorporate some changes suggested on the above web page. > >(not part of the errata from the IETF web site, but substitute openspf.net >where it says openspf.org). If anyone would like those changes to be discussed by the working group, could the person please post them to this mailing list so that I can put them into the tracker? If a change is already listed ( http://trac.tools.ietf.org/wg/spfbis/trac/report/1 ), there is no need to raise it again as it will be discussed. At 13:39 20-02-2012, Murray S. Kucherawy wrote: >For systems reasons, openspf.org has been replaced (for now, at >least) by openspf.net. The URL in that erratum can be accessed at >that alternate domain. Thus, go here: http://www.openspf.net/RFC_4408/Errata. > >The page contains links to eight errata that were logged on that web >site, but not in the RFC Editor's errata tracking tool. Do we need >to create IETF errata instead? No, it's easier to track them as issues as this working group will be working on 4408bis. See my comment above. Regards, S. Moonesamy SPFBIS WG co-chair From hsantos@isdg.net Mon Feb 20 14:16:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0802E21E8010 for ; Mon, 20 Feb 2012 14:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe96OFRdI609 for ; Mon, 20 Feb 2012 14:15:59 -0800 (PST) Received: from mail.catinthebox.net (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B72C221E800C for ; Mon, 20 Feb 2012 14:15:58 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1810; t=1329776148; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Ik5/6jWyCPMk1bzVY5l43Id/Xq8=; b=TgaehkCbcIPClOxZhsBi uH9fh9O91DRZkduoHqP4zYvJWx7AvfdJw5vhW+A5HDUlx90xS0sJgg6yjR/3/llG rYT9e1UlCtx6UqHcyG3UEQjRjGoTyFNDN23EuAJVygg8bmHr4pB/F5MUXav2EzlD l7EnImazHzEO3QFZRtsmyDY= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 20 Feb 2012 17:15:48 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2977994161.86315.3468; Mon, 20 Feb 2012 17:15:47 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1810; t=1329775908; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=pTfSFzz pfwNwHNJNlS2fBUzZDM6M4SqHt6lqTuEPbc8=; b=1Frx6L65b/qteL6AT3Ww3rD GXSYIS6VEKq191VSDYue6G0ukglae9B8OH5F++7N91sVoqFmWRccoLGvTNoG25L+ wcV426k2XIToczEpcK6B0U40/Xm0u7NuplqGtyWFj7mBfVWIjHpo4Mpup2hrBMKn ZzrCjNOFPKuiplM3W/88= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 20 Feb 2012 17:11:48 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3576931079.18043.3132; Mon, 20 Feb 2012 17:11:47 -0500 Message-ID: <4F42C605.9000907@isdg.net> Date: Mon, 20 Feb 2012 17:15:33 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> <2540299.gmSuznFx9K@scott-latitude-e6320> In-Reply-To: <2540299.gmSuznFx9K@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:16:00 -0000 Hi Scott, I disagree with your opinion I am mistaken. Rather than provide a lengthy background and evidence of reasoning why it is 100% related to SPF, I will suggest that we do not go down this route to make any critical decisions about SENDER-ID/SUBMITTER until there is clear KB and indication its lost of value, no longer significant, lost significant level of support from domains and we get some form of input and opinion from key authors, i.e. Katz, Lyon and Allman. Just consider any opinion that SUBMITTER is out of scope, would logically imply it is also out of scope for any final chartered product delivery, Interop Report or any decision about it. Its seems odd to me that claiming something is out of scope, somehow also justifies to have a non-discussed implication and conclusion it is no longer supported. I don't think we can have it both ways. Do you realize there are many clients that does support it? I stated that simply adding the ESMTP SUBMITTER keyword to your EHLO response will help measure it usage, which to me is significant. Scott Kitterman wrote: > On Monday, February 20, 2012 12:59:53 PM Hector Santos wrote: >> While I believe there is an "common" integrated aspect to it via the >> SUBMITTER protocol warranting SPF-BIS discussion, ... > > Hector, > > I believe you are mistaken. SUBMITTER and SPF are unrelated. It's not about > SPF/Sender-ID integration at all. It's about using body PRA Sender-ID results > instead of SPF. > > I don't think SUBMITTER is on topic for this working group. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Mon Feb 20 14:38:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5906621E8014 for ; Mon, 20 Feb 2012 14:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVBC5BmcJNPi for ; Mon, 20 Feb 2012 14:38:30 -0800 (PST) Received: from mail.catinthebox.net (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 438C421E800C for ; Mon, 20 Feb 2012 14:38:30 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3127; t=1329777503; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=sNFbFh7+2m9P1xfk0wf6Yd9J+9k=; b=sBYVRuICrHgArPhuEmQc WXb+ajRbWI2NAY0yd9nPG8EtsRtFmxwvmds7CIqC9GPsaqhw1I8+jfG6UqJJLP7H VUiLxJ3OZBmF4DCJ5/POl0ALMJ35jyrkbDqU/EcDNeOK8C9DZWRpEz9Ct7qAlbVo 8Vo8b1npv0X4N4hsjx7JwTg= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 20 Feb 2012 17:38:23 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2979349373.86315.3272; Mon, 20 Feb 2012 17:38:22 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3127; t=1329777266; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=lNenuiJ x/mCjwWxGVCtHx79CT+E6BFKzUmgr2rPSRM8=; b=bfFhnwvMM4VhRUDURx0wd9R NecOqPPs7z+1kVQjdSUiS5Qjxqzr3vWV8c6W+SW4cEmRhN0Zky1/0ltBF70rp7zF b51oWs8X6mQ/DD1HT89PnzNsCdH+0geTTjpz+MAbkuP2QVzX+und17U1cz/Jscqs J1p4U00CV4SNnmKoZeS4= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 20 Feb 2012 17:34:26 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3578289033.18047.4928; Mon, 20 Feb 2012 17:34:25 -0500 Message-ID: <4F42CB53.50505@isdg.net> Date: Mon, 20 Feb 2012 17:38:11 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 22:38:31 -0000 As I recall, the main MARID reason why we could just use a new RR was because around that time frame, there were still many DNS servers that did not support the recursion requirement to support new RR record SRV queries. That was the stated reason I recall and I believe there was general agreement about that. Microsoft DNS 4.0 was still a dominant server and it did not support recursion requirement nature, and if I recall, there was a patch but it as a hot request (not downloadble). Even AD suffered as well, as well as JABBER and other protocols that had a specific RR record but the fall back to common A/TXT was necessary Windows 2000 was still just 3 years old, and DNS 5.0 came with Windows 2003 so there was some migration period there. Today, I will state that we would be very or more successful as evidence of better operations with AD and XMPP/Jabber. FTR, there were also other non-MS DNS servers that also had issues so even if I got the patch for DNS 4.0 back then to explore new RR types (not just for SPF), it worked at the DNS 4.0 with manual updating of zone records and with direct queries in a LAN, but not always with queries across a WAN/internet. I gave up on these "create a SRV protocol" projects because of this fact - simply too early for prime time reliability. I think it is ready today. S Moonesamy wrote: > Hello, > > We would like to start the discussions about the issues. Here are some > points from the SPFBIS Charter as guidelines: > > Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any enhancements > that have already gained widespread support, and addition of > clarifying language. > > Specifically out-of-scope for this working group: > > * Revisiting past technical arguments where consensus was reached in > the MARID working group, except where review is reasonably > warranted based on operational experience. > > * Discussion of the merits of SPF. > > * Discussion of the merits of Sender-ID in preference to SPF. > > * Extensions to the SPF protocols. > > * Removal of existing features that are in current use. > > Issue #9 is up for discussion. It is based on the following: > > "This may be a can of worms, but since we're chartered to tidy up where > appropriate, I wonder if this might be such a spot. > > RFC4408 registered a new DNS RRtype, SPF, code 99. > > Are we able to tell how much deployment it's received? If only little > (which is what I suspect, but I've no data to back that up), would it be > appropriate to relegate its discussion to an appendix and call it > "historic"?" > > The WG Chairs request your comments. Please keep the subject line so > that it is easy for us to keep track of the discussion. > > Regards, > Andrew Sullivan & S. Moonesamy, SPFBIS co-chairs > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Mon Feb 20 14:57:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74A521F860F for ; Mon, 20 Feb 2012 14:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTzq0m3zwQlb for ; Mon, 20 Feb 2012 14:57:12 -0800 (PST) Received: from mail.catinthebox.net (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D148521F860E for ; Mon, 20 Feb 2012 14:57:11 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5288; t=1329778628; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=wLXQrnLFXUsrDHx7T/QJj2uqi0k=; b=Jb5usjft9h9QE4nTa5Vb 6oe2IVCzkvEX4UMrhhvhJa/R8I43dWfJQOLP2SRqA4BFutccpCYjYLBgR29zGfnt jLrbkS7/d61XQtMbQEwtuDBnDQ3jd9IIfrtJ+swei+3wdiyy/s+KBn/BWx3zfB0m miiodHmRJm0px0ypDoHl1ww= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 20 Feb 2012 17:57:08 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2980474515.86315.3568; Mon, 20 Feb 2012 17:57:07 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5288; t=1329778389; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=n0KVnt8 LXDJ4Tx/m8Blk5r9r9ra8zm3Dy0eK0FMVY0M=; b=ttURfyDBsnGPSRo/pYwV5JC NZoo3/51JpaiBUUpldbOZ4zUwRboFqvO+HRbLGLxTHe2+tXNzozw5pxhfFM31qih 1QRxdtddHmvk4yPDACE0DVf/hlBnELXQgTwfEwSUgzKbYs0TO7RN3GOg7NcyhpRI 2CnTDdbAcA1CDs6i+SSg= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 20 Feb 2012 17:53:09 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3579411345.18048.4488; Mon, 20 Feb 2012 17:53:07 -0500 Message-ID: <4F42CFB4.20308@isdg.net> Date: Mon, 20 Feb 2012 17:56:52 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> <31663665.dhxMF5JUGp@scott-latitude-e6320> In-Reply-To: <31663665.dhxMF5JUGp@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Feb 2012 22:57:12 -0000 I believe we could be jumping the guns because we need to consider the reasons why wasn't used and that include the fact that there was still a large population of DNS servers that didn't support the passthru/recursion requirements to make new RR named work without flaws and not requirement a fallback to common support record. I don't think that dearth of RR records is an issue today. The experience the same issue when I installed my Jabber Server a few years back. It had a SRV record for discovery and a fallback. I recall believing just using the SRV record was enough and depending on the query path, it works very nicely, but for other paths it didn't and I had no choice but the add the other records. And finally when I expanded the jabber network with peers, maybe 1.5/2 years ago, I recall how smoothly it all worked not with these other paths. Same experience with we installed a AD/LMAP server, but that was more successful because it was done more recently. I suggest we talk about it and if we believe and conclude that it technical feasible and will have a high reliability and it improve the SPF protocol existence within DNS for SPF-BIS era and years to come, we should not just blatantly abandon it the original ideas we had for it - which was a long term support concept. We all knew it wasn't going to be reliable back then - not all DNS servers were ready for it, but we want to get ready for it. Scott Kitterman wrote: > On Monday, February 20, 2012 09:00:39 AM S Moonesamy wrote: >> Hello, >> >> We would like to start the discussions about the issues. Here are >> some points from the SPFBIS Charter as guidelines: >> >> Changes to the SPF specification will be limited to the correction >> of errors, removal of unused features, addition of any enhancements >> that have already gained widespread support, and addition of >> clarifying language. >> >> Specifically out-of-scope for this working group: >> >> * Revisiting past technical arguments where consensus was reached in >> the MARID working group, except where review is reasonably >> warranted based on operational experience. >> >> * Discussion of the merits of SPF. >> >> * Discussion of the merits of Sender-ID in preference to SPF. >> >> * Extensions to the SPF protocols. >> >> * Removal of existing features that are in current use. >> >> Issue #9 is up for discussion. It is based on the following: >> >> "This may be a can of worms, but since we're chartered to tidy up >> where appropriate, I wonder if this might be such a spot. >> >> RFC4408 registered a new DNS RRtype, SPF, code 99. >> >> Are we able to tell how much deployment it's received? If only >> little (which is what I suspect, but I've no data to back that up), >> would it be appropriate to relegate its discussion to an appendix and >> call it "historic"?" >> >> The WG Chairs request your comments. Please keep the subject line so >> that it is easy for us to keep track of the discussion. > > I would like to suggest a nuance about the removal aspect of the charter. I > think there is an implicit expectation in the way that the charter is drafted > that removal of features that are in use will inevitably harm > interoperability. In this one case, I don't think it does. > > We can tell based on DNS surveys that there is very little Type SPF > deployment. In cases where there is a type SPF record, there are three > possible cases: > > 1. Identical Type TXT record published > > 2. Non-identical type TXT record published > > 3. No TXT record published. > > Since virtually all SPF records are only published as Type TXT, there is no > ineroperability benefit to also publishing Type SPF. > > If there is a non-identical record published the publishing domain will get > inconsistent results since not all receivers of SPF records look up Type SPF. > Publishing the same information in two places places an operational burden > (not just the dual publishing, but also keeping the information in sync). > > If there is no TXT record and just a Type SPF record then the results are > going to be poor. Only Type SPF checkers will see the record. > > The RFC 4408 language (SHOULD check SPF first) also causes additional DNS > lookups that will almost always be fruitless. > > I think that Type SPF was created based on fear of what might happen if Type > TXT were overused. Those fears have not come to pass and we should drop Type > SPF as harmful to interopability. There is no operational case for a > transition now and I think it's safe to assume there won't be. > > There is no reasonable case where dropping Type SPF will cause SPF record > publishers to change their records (I don't consider publishing only a Type > SPF record a reasonable case - it just doesn't work due to the predominance of > Type TXT in SPF records). > > I don't object to reserving Type SPF for some future non-compatible SPFvX, but > for v1, I think we can and should drop it. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Mon Feb 20 15:48:29 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1183521E8020 for ; Mon, 20 Feb 2012 15:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.792 X-Spam-Level: X-Spam-Status: No, score=-0.792 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1Zb3uTC1qW0 for ; Mon, 20 Feb 2012 15:48:28 -0800 (PST) Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id EA3EF21E8010 for ; Mon, 20 Feb 2012 15:48:27 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4573; t=1329781698; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=+Kf334ijqQxIK5p8mTdeF8kEhG8=; b=HBkLAzXZwn7OVSwPXJcU L4WSK/d2CD/oAEFbHUfV2tROcQXACJHAm9NOVFu3eMGVHSHiTWZLIUD74RBwRr0j bJjwi15dyv0OlU7slJBpHGycf2eu2y0WdJbyhpA3jteWkTe0i8Q+yMntTTp++eu/ iDpnSfceXOYLZB8wpjpqADM= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 20 Feb 2012 18:48:18 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2983544833.86315.4920; Mon, 20 Feb 2012 18:48:17 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4573; t=1329781459; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=VvTQVe9 hGX9VSjLNhQQV+sENlpTde4Tv6O+F7b7+Xug=; b=0gJ4is//4YXQoryRxZ7SdvG a3xr9HaN2segC92U3iC+lPvGBEhmXj7KDdK3i2vvsmz69ZeKTGMXGq5C/FnYKcc4 xcXR6mI/itlYyL4TEskpFxTuf/JhdFvbBnG/BOTCOEf79+amgrMLoLYmLGdz9NPW XU1gCFsEWHucibhGeGeo= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 20 Feb 2012 18:44:18 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3582481626.18055.5088; Mon, 20 Feb 2012 18:44:18 -0500 Message-ID: <4F42DBB1.8050102@isdg.net> Date: Mon, 20 Feb 2012 18:48:01 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <2540299.gmSuznFx9K@scott-latitude-e6320> <1511964.YRbWeFy5Z0@scott-latitude-e6320> In-Reply-To: <1511964.YRbWeFy5Z0@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 23:48:29 -0000 Scott Kitterman wrote: >> >> I've been collecting data about SUBMITTER deployment as part of the >> interoperability report idea, and the experiment closure. I can certainly >> stop and change that if we decide it's out of scope, but they look quite >> linked to me. > > I agree it's part of the experimental closeout. > > I don't the it's something that's in scope to consider for 4408bis itself. > How do you justify this when there evidence that it is well supported by MTA clients? You can not make SPF-BIF WG conclusions about SUBMITTER/SENDER-ID without make it a charter goal to prove this would the correction decision with minimal impact. You just don't know that and I believe your ESMTP server expose the SUBMITTER keyword and see how much traffic you get from clients supporting, you may (I hope) have a different opinion about it. Now, I disagree with you to suggest they are not related on the fundamental principle both SPF and SID have one thing in common - they are both LMAP solutions which provided the basic protocol theory of an authorized DOMAIN::IP association assertion. For the same reasons I encouraged Meng to add support for optional EHLO checking based on the LMAP analysis I did back in 2004: http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1.htm There is in fact, a 3rd domain PRA that Microsoft introduced with CEP (Caller Email Policy). All together for an total and full implementation, we have three domain::IP assertions: CLIENT-DOMAIN::IP RETURN-PATH-DOMAIN::IP PRA-DOMAIN::IP As a side and very important factor in the development was the fact that CEP offered its own DNS subdomain name space using the subdomain prefix ".ep" In fact, even today you can still see the old experimental Microsoft's Hotmail.com CEP record with its XML-based SPF record: nslookup -query=TXT _ep.hotmail.com Non-authoritative answer: _ep.hotmail.com text = " list1._ep.hotmail.com list2._ep.hotmail.com list3._ep.hotmail.com " What is important to remember was the fact the CEP had its own namespace and there would be no conflict with SPF record if it had indeed remained that way. But the interest in MARID was merge and produce a common open public standard and there were a few key issues we voted on: - Should we use a XML format? It was interesting as a "Direction", but XML was not deemed a good idea for DNS TXT based results with its obvious waste in its text overhead, - The desire to have a common format and language to support the already existing high and growing based of SPF domains with v=spf1 records, and - as stated about, CEP had its own DNS subdomain name space using the "_ep." subdomain prefix and if were to support two protocols, even after we agree they had the same record language, it meant there would be two different DNS TXT queries with the odds that they will have same context. One for SPF and one for CEP. There was a desire to able to read both records with one single TXT query under one name space. If this was the genesis of a unforeseen conflict, thats another story. Overall, in MARID we came to consensus of the deliverables that came with a technical acknowledgment there was interest in three different domains; two of them was covered with SPF with no payload requirement, and a 3rd domain based on the payload PRA. What was common between all of them was the IP. We can not dispense the idea that any vendor wanted to offer the best of all SPF-like worlds to their customers. The only beef I had was that SID promoted the payload in order to support that 3rd domain. So I fought hard to push this point it would be a very wasteful requirement when a major interest in SPF was in fact to address the accept/bounce problem that SORBIG highlighted as a major SMTP relaxed security issue. I communicated extensively with Harry offlist about this and was very happy to see that in the final Meng/Microsoft agreement of the new goals, SUBMITTER was among them to help address the PAYLOAD concern as the only way to get the PRA. So Scott, I fundamentally feel SPF-BIF can not ignore its relationship with SID/SUBMITTER especially when its now also is trying to make some decisions about the future of SID/SUBMITTER. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From pmidge@microsoft.com Mon Feb 20 17:29:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8680821F8545 for ; Mon, 20 Feb 2012 17:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-0.750, 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 40XXfHil4Smo for ; Mon, 20 Feb 2012 17:29:43 -0800 (PST) Received: from VA3EHSOBE002.bigfish.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 884CD21F84F7 for ; Mon, 20 Feb 2012 17:29:43 -0800 (PST) Received: from mail174-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Feb 2012 01:29:39 +0000 Received: from mail174-va3 (localhost [127.0.0.1]) by mail174-va3-R.bigfish.com (Postfix) with ESMTP id CB362401A6; Tue, 21 Feb 2012 01:29:38 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371I542M1432Nzz1202hzz8275ch1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail174-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail174-va3 (localhost.localdomain [127.0.0.1]) by mail174-va3 (MessageSwitch) id 132978777711594_18182; Tue, 21 Feb 2012 01:29:37 +0000 (UTC) Received: from VA3EHSMHS033.bigfish.com (unknown [10.7.14.246]) by mail174-va3.bigfish.com (Postfix) with ESMTP id F1DCF6004D; Tue, 21 Feb 2012 01:29:36 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS033.bigfish.com (10.7.99.43) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Feb 2012 01:29:37 +0000 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.110]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0247.005; Tue, 21 Feb 2012 01:29:37 +0000 From: Paul Midgen To: John Levine , "spfbis@ietf.org" Thread-Topic: [spfbis] A general cleanup strategy Thread-Index: AcztpK6En9zx3QfUTlOax95x5bPRqAARDOuAAA28+YAAAvrKAAAuX5uAAD+s+oAAAxi+gAAJEvEAAAgOtOA= Date: Tue, 21 Feb 2012 01:29:37 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204B2CA5@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4F427AD1.2090705@dcrocker.net> <20120220211430.14741.qmail@joyce.lan> In-Reply-To: <20120220211430.14741.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "dcrocker@bbiw.net" Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 01:29:44 -0000 Hotmail will indeed publish all relevant information, I can't see a good re= ason not to. ETA is mid to late March.=20 -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= John Levine Sent: Monday, February 20, 2012 1:15 PM To: spfbis@ietf.org Cc: dcrocker@bbiw.net Subject: Re: [spfbis] A general cleanup strategy >1. Statements about adoption levels of each > >2. Statements about known conflicts by having the records shared. > >I actually suspect there is little objective data on the latter. > >Perhaps it can be argued that a sufficiently clear differential on #1=20 >will eliminate the need for answering #2? I'm not aware of anyone other than Hotmail who did a non-trivial deployment= of Sender-ID, and I wouldn't expect them to publish their results. So I agree, there isn't likely to be enough data to say anything about #2. R's, John -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummi= es", Please consider the environment before reading this e-mail. http://jl.= ly _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From msk@cloudmark.com Mon Feb 20 18:01:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E1F21F84F9 for ; Mon, 20 Feb 2012 18:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvO-mX0lcx7f for ; Mon, 20 Feb 2012 18:01:26 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4A021F84F1 for ; Mon, 20 Feb 2012 18:01:26 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 20 Feb 2012 18:01:25 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 20 Feb 2012 18:01:24 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 20 Feb 2012 18:01:24 -0800 Thread-Topic: [spfbis] A general cleanup strategy Thread-Index: AczwHT7dJhi0EECWScOG0GvAYCSoSAAHlJKw Message-ID: References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> <2540299.gmSuznFx9K@scott-latitude-e6320> <4F42C605.9000907@isdg.net> In-Reply-To: <4F42C605.9000907@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 02:01:26 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Hector Santos > Sent: Monday, February 20, 2012 2:16 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] A general cleanup strategy >=20 > I disagree with your opinion I am mistaken. Rather than provide a > lengthy background and evidence of reasoning why it is 100% related to > SPF, I will suggest that we do not go down this route to make any > critical decisions about SENDER-ID/SUBMITTER until there is clear KB > and indication its lost of value, no longer significant, lost > significant level of support from domains and we get some form of input > and opinion from key authors, i.e. Katz, Lyon and Allman. We're in the process of collecting that information. > Just consider any opinion that SUBMITTER is out of scope, would > logically imply it is also out of scope for any final chartered product > delivery, Interop Report or any decision about it. Its seems odd to me > that claiming something is out of scope, somehow also justifies to have > a non-discussed implication and conclusion it is no longer supported. > I don't think we can have it both ways. Just to clarify my suggestion: The point of doing the implementation report= exercise (see RFC5657) about SPF is to determine what parts of the SPF spe= c itself have been deployed (and should stay), which have interoperability = problems (and should be clarified or fixed), and which are not in use (and = should be deprecated or even removed). I suggested this as a tool to makin= g the RFC4408bis document as strong and tight as possible. I'm not suggesting undertaking an interoperability report for Sender-ID, PR= A or SUBMITTER except as much as we need to do so to produce our "conclusio= n of the experiment" document. > Do you realize there are many clients that does support it? I stated > that simply adding the ESMTP SUBMITTER keyword to your EHLO response > will help measure it usage, which to me is significant. Do you have a list of these? I couldn't find one. -MSK From spf2@kitterman.com Mon Feb 20 19:01:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6121221F8528 for ; Mon, 20 Feb 2012 19:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 g87ZnnZ6hhJI for ; Mon, 20 Feb 2012 19:01:42 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C39F521F852D for ; Mon, 20 Feb 2012 19:01:40 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 711B520E40DA; Mon, 20 Feb 2012 22:01:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329793299; bh=Q5E0d7STHfJ5CaNs31r/FvaOnviACroPfSmjFT8pH4M=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=WRV9HiXu9sgDneC30jRhEhzXo/ldq9iRMYUXvaCrujRBUTOi2SyrYuf27/0PxzSjH UIbKnC6EwnpI7zX0/FwpZBM5SpuXtb+JIra2xlj9ebuiXcR+AAAJzYTh/5uAOHNjd+ vsWKuTqpsBX/h1cpyUEPRLuYoDB6hnpY5Xz90IOw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 57B7120E408E; Mon, 20 Feb 2012 22:01:39 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Feb 2012 22:01:38 -0500 Message-ID: <2893435.8UDY49DhTJ@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120220131927.0909fc40@resistor.net> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <2140478.AvMiToEcEc@scott-latitude-e6320> <6.2.5.6.2.20120220131927.0909fc40@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] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 03:01:43 -0000 On Monday, February 20, 2012 02:07:28 PM S Moonesamy wrote: > At 13:10 20-02-2012, Scott Kitterman wrote: > >Notes: > > > >Alexey: if there is interest in revising the document, then it should be > >updated to incorporate some changes suggested on the above web page. > > > >(not part of the errata from the IETF web site, but substitute openspf.net > >where it says openspf.org). > > If anyone would like those changes to be discussed by the working > group, could the person please post them to this mailing list so that > I can put them into the tracker? > > If a change is already listed ( > http://trac.tools.ietf.org/wg/spfbis/trac/report/1 ), there is no > need to raise it again as it will be discussed. I did already mention these errata in http://www.ietf.org/mail- archive/web/spfbis/current/msg00274.html - but they don't seem to have made it into the tracker. Do you want one mail per item? Scott K From spf2@kitterman.com Mon Feb 20 19:03:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DE721E802F for ; Mon, 20 Feb 2012 19:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 DaNo0srSLkS9 for ; Mon, 20 Feb 2012 19:03:35 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 209F321F852A for ; Mon, 20 Feb 2012 19:03:35 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id ABC8B20E40DA; Mon, 20 Feb 2012 22:03:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329793414; bh=oEgmPze/9XWiE7qrgYDzIDmOSsuyDGScZxL/4Kmu1dY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=QpERE1YgALPSkz8xlZeRDA1jgl9nwJT07CsNSYayl8slKz8b0Y/EdQ7Tw4koLklJr RCnIBpA0mkdAB4dDpAO9jfmm+hhPBfFuHUvkfrtQANGgY0UH17FOoyMx7jeW2TzY/A K6hBNsXH1K1h1SjlQQW8/saHlQsup+uDy1uHLrCU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8EA8F20E408E; Mon, 20 Feb 2012 22:03:34 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Feb 2012 22:03:33 -0500 Message-ID: <1568886.uE4vXc93Dg@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120220121328.09836200@elandnews.com> References: <061.ab475cb67717b7fa7169bfb593bbd82f@tools.ietf.org> <6.2.5.6.2.20120220121328.09836200@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #2: RFC 4408 Section B.3 - Errata #2250 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 03:03:36 -0000 On Monday, February 20, 2012 12:16:11 PM S Moonesamy wrote: ... > I'll classify this issue as "hold for document update". When the > 4408bis draft is opened, the working group can look into the above. ... I'm confused again. Isn't this what we are working on now? Scott K From pmidge@microsoft.com Mon Feb 20 19:09:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C9C21F8576 for ; Mon, 20 Feb 2012 19:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 qQ1o2+ugrcbM for ; Mon, 20 Feb 2012 19:09:05 -0800 (PST) Received: from AM1EHSOBE004.bigfish.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id CF99F21F8575 for ; Mon, 20 Feb 2012 19:09:04 -0800 (PST) Received: from mail27-am1-R.bigfish.com (10.3.201.237) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Feb 2012 03:08:59 +0000 Received: from mail27-am1 (localhost [127.0.0.1]) by mail27-am1-R.bigfish.com (Postfix) with ESMTP id CDE7A260396; Tue, 21 Feb 2012 03:08:58 +0000 (UTC) X-SpamScore: -31 X-BigFish: VS-31(zz9371I542Mc1dMzz1202hzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail27-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail27-am1 (localhost.localdomain [127.0.0.1]) by mail27-am1 (MessageSwitch) id 1329793735816313_5042; Tue, 21 Feb 2012 03:08:55 +0000 (UTC) Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.228]) by mail27-am1.bigfish.com (Postfix) with ESMTP id C3C7B1E0045; Tue, 21 Feb 2012 03:08:55 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Feb 2012 03:08:55 +0000 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.110]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0247.005; Tue, 21 Feb 2012 03:08:47 +0000 From: Paul Midgen To: Scott Kitterman , "spfbis@ietf.org" Thread-Topic: [spfbis] New Issue: Requirement to check mail from Thread-Index: AQHM8Bj0qTVnAEkFu0GZXRvXVtsCYJZGq3jA Date: Tue, 21 Feb 2012 03:08:47 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204B2E9A@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> In-Reply-To: <1618345.7dPBqcXJlk@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 03:09:05 -0000 Outside of the case where the envelope sender is empty (e.g. NDR), most of = the HELO domains we observe are garbage. Is there a reason why we do not recommend that HELO be checked only if Mail= From does not produce a definitive policy result? -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Scott Kitterman Sent: Monday, February 20, 2012 1:45 PM To: spfbis@ietf.org Subject: [spfbis] New Issue: Requirement to check mail from Sorry for being late. I forgot about this one. Paragraph 2.2, The MAIL FROM Identity, includes this statement: SPF clients MUST check the "MAIL FROM" identity. SPF clients check the "MAIL FROM" identity by applying the check_host() function to the "MAIL FROM" identity as the . There are applications that check HELO first and can reach a final conclusi= on about message disposition based on that check. In such a case, the Mail= From check is a waste of resources. I'm recommend changing this to either: SPF clients MUST check the "MAIL FROM" identity unless a HELO check has alr= eady produced a definititive policy result. ... or SPF clients SHOULD check the "MAIL FROM" identity (e.g. unless a HELO check= has already produced a definititive policy result). ... Scott K _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From johnl@iecc.com Mon Feb 20 18:11:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D54921F855A for ; Mon, 20 Feb 2012 18:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.327 X-Spam-Level: X-Spam-Status: No, score=-102.327 tagged_above=-999 required=5 tests=[AWL=0.273, 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 FPkqVzqjmqNu for ; Mon, 20 Feb 2012 18:11:04 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A8CB921F8562 for ; Mon, 20 Feb 2012 18:11:03 -0800 (PST) Received: (qmail 46375 invoked from network); 21 Feb 2012 02:11:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=b525.4f42fd36.k1202; bh=i+LC5u2i76wAsXSB4utan5i8lJHcsr0TKII1htbne7s=; b=OANtkAlg3Sks7xJnywbbLKK0hQFB1+EqPBYMbPfkQKdd3Fg1o0A8Tkn9zg3pF0GyQtCViwaziOnOvY78pfW7Oc4JnSM/gtdmuOowN6heL5WWRZoIkR71lpL++EgmkdRvoKlLv9vn12DdsO4CdD2gKqfcLzFw/tH0rjGwp/rCjxE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Feb 2012 02:10:40 -0000 Date: 20 Feb 2012 18:11:01 -0800 Message-ID: From: "John R. Levine" To: "Paul Midgen" In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E204B2CA5@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4F427AD1.2090705@dcrocker.net> <20120220211430.14741.qmail@joyce.lan> <7F7F36E50398F84DBAF25C9D51732F1E204B2CA5@TK5EX14MBXC203.redmond.corp.microsoft.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 20 Feb 2012 19:14:16 -0800 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 02:11:05 -0000 > Hotmail will indeed publish all relevant information, I can't see a good reason not to. ETA is mid to late March. That would be very helpful. Thanks. R's, John > > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of John Levine > Sent: Monday, February 20, 2012 1:15 PM > To: spfbis@ietf.org > Cc: dcrocker@bbiw.net > Subject: Re: [spfbis] A general cleanup strategy > >> 1. Statements about adoption levels of each >> >> 2. Statements about known conflicts by having the records shared. >> >> I actually suspect there is little objective data on the latter. >> >> Perhaps it can be argued that a sufficiently clear differential on #1 >> will eliminate the need for answering #2? > > I'm not aware of anyone other than Hotmail who did a non-trivial deployment of Sender-ID, and I wouldn't expect them to publish their results. > > So I agree, there isn't likely to be enough data to say anything about #2. > > R's, > John > -- > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > > Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From spf2@kitterman.com Mon Feb 20 19:15:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B0621E803B for ; Mon, 20 Feb 2012 19:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 Dl3obsiUDqrK for ; Mon, 20 Feb 2012 19:15:01 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2922521F8508 for ; Mon, 20 Feb 2012 19:14:38 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B0C2A20E40DA; Mon, 20 Feb 2012 22:14:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329794077; bh=hBRP/e7P99KFfP0n9SV5riHNMGB0eABpbnzYqKv+JPc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Faq2H3XXOo6EFDkW5Yc0IEoY60PV+0XXLhQWDJXrmOn+nonTg+RVNJXTHLYPXGy+L GShBDsLuAUoCkvkslI5MqbiVcayTTa2/yBzk/wXa7VxvDbi4eag8kaqJez5jrXDzHa JVgbmH3RUu73iW6IZzACuyKXMoxcI1WXdZs8/qvU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 923AE20E408E; Mon, 20 Feb 2012 22:14:37 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Feb 2012 22:14:36 -0500 Message-ID: <1587556.qvTAF6dvrE@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E204B2E9A@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2E9A@TK5EX14MBXC203.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 03:15:02 -0000 If you get a FQDN HELO checks can be useful. Generally the most complex HELO record you'll see is v=spf1 a -all. In my experience HELO records are much less expensive in DNS looksups, so even if it's less likely to be definitive (if it's not a FQDN, you just don't look it up, no harm done) it's less expensive so doing the HELO check first can be a resource saver. There's no interoperability benefit to doing one or the other check first. There's equally no point in trying to insist on software doing additional checks once it already has a definitive result. I don't think we want to specify either. Scott K On Tuesday, February 21, 2012 03:08:47 AM Paul Midgen wrote: > Outside of the case where the envelope sender is empty (e.g. NDR), most of > the HELO domains we observe are garbage. > > Is there a reason why we do not recommend that HELO be checked only if Mail > From does not produce a definitive policy result? > > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of > Scott Kitterman Sent: Monday, February 20, 2012 1:45 PM > To: spfbis@ietf.org > Subject: [spfbis] New Issue: Requirement to check mail from > > Sorry for being late. I forgot about this one. > > Paragraph 2.2, The MAIL FROM Identity, includes this statement: > > SPF clients MUST check the "MAIL FROM" identity. SPF clients check > the "MAIL FROM" identity by applying the check_host() function to the > "MAIL FROM" identity as the . > > There are applications that check HELO first and can reach a final > conclusion about message disposition based on that check. In such a case, > the Mail From check is a waste of resources. > > I'm recommend changing this to either: > > SPF clients MUST check the "MAIL FROM" identity unless a HELO check has > already produced a definititive policy result. ... > > or > > SPF clients SHOULD check the "MAIL FROM" identity (e.g. unless a HELO check > has already produced a definititive policy result). ... > > 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 pmidge@microsoft.com Mon Feb 20 19:30:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E179821E803B for ; Mon, 20 Feb 2012 19:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=-0.375, 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 E0ekWSAOVq-c for ; Mon, 20 Feb 2012 19:30:35 -0800 (PST) Received: from DB3EHSOBE006.bigfish.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 99F3E21E8016 for ; Mon, 20 Feb 2012 19:30:34 -0800 (PST) Received: from mail67-db3-R.bigfish.com (10.3.81.240) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Feb 2012 03:30:29 +0000 Received: from mail67-db3 (localhost [127.0.0.1]) by mail67-db3-R.bigfish.com (Postfix) with ESMTP id 6CB7B3402CD; Tue, 21 Feb 2012 03:30:29 +0000 (UTC) X-SpamScore: -40 X-BigFish: VS-40(zz9371I542M1432N98dKc1dMzz1202hzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail67-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail67-db3 (localhost.localdomain [127.0.0.1]) by mail67-db3 (MessageSwitch) id 1329795027951076_22937; Tue, 21 Feb 2012 03:30:27 +0000 (UTC) Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.250]) by mail67-db3.bigfish.com (Postfix) with ESMTP id E460A10004A; Tue, 21 Feb 2012 03:30:27 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Feb 2012 03:30:26 +0000 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.110]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0247.005; Tue, 21 Feb 2012 03:30:28 +0000 From: Paul Midgen To: Scott Kitterman , "spfbis@ietf.org" Thread-Topic: [spfbis] New Issue: Requirement to check mail from Thread-Index: AQHM8Bj0qTVnAEkFu0GZXRvXVtsCYJZGq3jAgAACNwCAAAB3EA== Date: Tue, 21 Feb 2012 03:30:28 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204B2EF8@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2E9A@TK5EX14MBXC203.redmond.corp.microsoft.com> <1587556.qvTAF6dvrE@scott-latitude-e6320> In-Reply-To: <1587556.qvTAF6dvrE@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 03:30:36 -0000 >From the point of view of defining the mechanism itself, that is probably t= he right thing to do. But: as a large-scale receiver, I am less concerned about conserving DNS qu= eries than getting a definitive authentication result the first time at bat= , especially when that authentication result will trigger a number of secon= dary actions associated with the authenticated identity - such as positive = identification UX, authentication policy, domain reputation, and so on. If the spec leaves it up to me, I will choose the entity statistically most= likely to yield the result I need. I just hope this freedom of choice does= n't hurt interoperability by not being prescriptive. -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Scott Kitterman Sent: Monday, February 20, 2012 7:15 PM To: spfbis@ietf.org Subject: Re: [spfbis] New Issue: Requirement to check mail from If you get a FQDN HELO checks can be useful. =20 Generally the most complex HELO record you'll see is v=3Dspf1 a -all. In m= y experience HELO records are much less expensive in DNS looksups, so even = if it's less likely to be definitive (if it's not a FQDN, you just don't lo= ok it up, no harm done) it's less expensive so doing the HELO check first c= an be a resource saver. There's no interoperability benefit to doing one or the other check first. = =20 There's equally no point in trying to insist on software doing additional c= hecks once it already has a definitive result. I don't think we want to sp= ecify either. Scott K On Tuesday, February 21, 2012 03:08:47 AM Paul Midgen wrote: > Outside of the case where the envelope sender is empty (e.g. NDR),=20 > most of the HELO domains we observe are garbage. >=20 > Is there a reason why we do not recommend that HELO be checked only if=20 > Mail From does not produce a definitive policy result? >=20 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On=20 > Behalf Of Scott Kitterman Sent: Monday, February 20, 2012 1:45 PM > To: spfbis@ietf.org > Subject: [spfbis] New Issue: Requirement to check mail from >=20 > Sorry for being late. I forgot about this one. >=20 > Paragraph 2.2, The MAIL FROM Identity, includes this statement: >=20 > SPF clients MUST check the "MAIL FROM" identity. SPF clients check > the "MAIL FROM" identity by applying the check_host() function to the > "MAIL FROM" identity as the . >=20 > There are applications that check HELO first and can reach a final=20 > conclusion about message disposition based on that check. In such a=20 > case, the Mail From check is a waste of resources. >=20 > I'm recommend changing this to either: >=20 > SPF clients MUST check the "MAIL FROM" identity unless a HELO check=20 > has already produced a definititive policy result. ... >=20 > or >=20 > SPF clients SHOULD check the "MAIL FROM" identity (e.g. unless a HELO=20 > check has already produced a definititive policy result). ... >=20 > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis >=20 >=20 > _______________________________________________ > 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 Feb 20 19:33:34 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947E821E803B for ; Mon, 20 Feb 2012 19:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 R1wNjWDtploi for ; Mon, 20 Feb 2012 19:33:33 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id ADAD421E8016 for ; Mon, 20 Feb 2012 19:33:33 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 31B1220E40DA; Mon, 20 Feb 2012 22:33:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329795213; bh=wRANmAgwiPw90lE+Lgf6sgZpKxrR6bjr6c3RkPVn4FY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=nHY4XVlrsPpqWxWrgOTIHMH90rqtI2dEWMK11dUHwJ2tEyrdtqqcYnt+L6GkCGquW ZpfRJyIL+7K9nC95JNrpS5DBa8oCNj2i7O74CjMnat/fuxQdiLDLiAkXiOhcOLtEGk 0J7jQOFLi1OfhKaXNjqE7ZIdomzazmyxycw2g7ig= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 13B0320E408E; Mon, 20 Feb 2012 22:33:32 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Feb 2012 22:33:32 -0500 Message-ID: <4044511.bhIdl0R2eS@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E204B2EF8@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <1587556.qvTAF6dvrE@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2EF8@TK5EX14MBXC203.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 03:33:34 -0000 As long as the working group stays out of trying to define local policy beyond what 4408 does, I think it's not a problem. In any case, I think that the HELO check first approach I described only makes sense if a site is doing SPF based rejection at SMTP time, I don't think it's your use case. Scott K On Tuesday, February 21, 2012 03:30:28 AM Paul Midgen wrote: > From the point of view of defining the mechanism itself, that is probably > the right thing to do. > > But: as a large-scale receiver, I am less concerned about conserving DNS > queries than getting a definitive authentication result the first time at > bat, especially when that authentication result will trigger a number of > secondary actions associated with the authenticated identity - such as > positive identification UX, authentication policy, domain reputation, and > so on. > > If the spec leaves it up to me, I will choose the entity statistically most > likely to yield the result I need. I just hope this freedom of choice > doesn't hurt interoperability by not being prescriptive. > > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of > Scott Kitterman Sent: Monday, February 20, 2012 7:15 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] New Issue: Requirement to check mail from > > If you get a FQDN HELO checks can be useful. > > Generally the most complex HELO record you'll see is v=spf1 a -all. In my > experience HELO records are much less expensive in DNS looksups, so even if > it's less likely to be definitive (if it's not a FQDN, you just don't look > it up, no harm done) it's less expensive so doing the HELO check first can > be a resource saver. > > There's no interoperability benefit to doing one or the other check first. > There's equally no point in trying to insist on software doing additional > checks once it already has a definitive result. I don't think we want to > specify either. > > Scott K > > On Tuesday, February 21, 2012 03:08:47 AM Paul Midgen wrote: > > Outside of the case where the envelope sender is empty (e.g. NDR), > > most of the HELO domains we observe are garbage. > > > > Is there a reason why we do not recommend that HELO be checked only if > > Mail From does not produce a definitive policy result? > > > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > > Behalf Of Scott Kitterman Sent: Monday, February 20, 2012 1:45 PM > > To: spfbis@ietf.org > > Subject: [spfbis] New Issue: Requirement to check mail from > > > > Sorry for being late. I forgot about this one. > > > > Paragraph 2.2, The MAIL FROM Identity, includes this statement: > > SPF clients MUST check the "MAIL FROM" identity. SPF clients > > check > > the "MAIL FROM" identity by applying the check_host() function to > > the > > "MAIL FROM" identity as the . > > > > There are applications that check HELO first and can reach a final > > conclusion about message disposition based on that check. In such a > > case, the Mail From check is a waste of resources. > > > > I'm recommend changing this to either: > > > > SPF clients MUST check the "MAIL FROM" identity unless a HELO check > > has already produced a definititive policy result. ... > > > > or > > > > SPF clients SHOULD check the "MAIL FROM" identity (e.g. unless a HELO > > check has already produced a definititive policy result). ... > > > > Scott K From hsantos@isdg.net Mon Feb 20 19:44:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0446721F84EC for ; Mon, 20 Feb 2012 19:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.458, 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 Ox80YZpTU-KV for ; Mon, 20 Feb 2012 19:44:00 -0800 (PST) Received: from listserv.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CA8D121F84EA for ; Mon, 20 Feb 2012 19:43:59 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=669; t=1329795833; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=E16k3/Hhcqw0GTFFNvFOCJQekGs=; b=qiDcygkj6kp5/simG6NN m0349TnLT12fyuhE1X8zWt+cnYmMSntKWcHnwEEps+3klLV/VfcBe33AHNr8RTk+ /V+MucKR+Yz6/u4HElytReM/HThH6ZFdXnTmw0zTQkgAwj4OpoGH/fg+kxslkAAf FbXg3BBRPU1R5Vd3qrijnGI= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 20 Feb 2012 22:43:53 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2997679959.86315.5004; Mon, 20 Feb 2012 22:43:53 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=669; t=1329795595; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=dyGm/Yw U+itDpOMPuXrSD+y4Ix95f4diBXxMNBdwNZM=; b=H3DGh1Iwy6AtuB4jlZkw0L5 hFx6cOuDTtnXjKrPkzLPo+onXfdXB3gcSdHq+nYeXUL0Py4Dk88gy2NgZvkx5Lh9 /5wxsSOf/FfpF/gDg5YEzVoHiewUAkkGMEztAXPi+DwHNODGaRNZDViALUK1MNct 5qdwXbbCAgGqDdFldT3M= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 20 Feb 2012 22:39:55 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3596618767.18075.6296; Mon, 20 Feb 2012 22:39:55 -0500 Message-ID: <4F4312EA.9080206@isdg.net> Date: Mon, 20 Feb 2012 22:43:38 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> <2540299.gmSuznFx9K@scott-latitude-e6320> <4F42C605.9000907@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 03:44:01 -0000 Murray S. Kucherawy wrote: >> -----Original Message----- >> Do you realize there are many clients that does support it? I stated >> that simply adding the ESMTP SUBMITTER keyword to your EHLO response >> will help measure it usage, which to me is significant. > > Do you have a list of these? I couldn't find one. Murray, I posted a report to your question in IETF-SMTP. http://www.imc.org/ietf-smtp/mail-archive/msg07117.html Note, this archive reference does masked out the domain data listed. So list copy of the submitted message would show the better info. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Mon Feb 20 20:29:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16BE21F8576 for ; Mon, 20 Feb 2012 20:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVNb0GNEaxni for ; Mon, 20 Feb 2012 20:29:43 -0800 (PST) Received: from listserv.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA4F21F8575 for ; Mon, 20 Feb 2012 20:29:42 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4175; t=1329798574; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=eLl+tY6S3blQ3+YD1HfKbwVLBRs=; b=vXPJywTj9/da21b35ymi khurpOeySc5Fpr3OuC8xbY+u3flsZ331dtyZW/b9S+Lye78c9qSXCmZMrQd9JN08 EqQ/m5CRa2Us3jmqcfT03gzIwWJsQr9FJD9UtSlOtXWAziGHJzrbyReUx7fRispu YJKAdKrj831GJHFXrF5IXS8= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 20 Feb 2012 23:29:34 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3000420132.86315.5552; Mon, 20 Feb 2012 23:29:33 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4175; t=1329798334; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=O4E8Zgp qTlRKOLKOs1DN+ODd/MnsA1mILwYMO5yAqY8=; b=rq+6xtdWSpHv+0tDkEJhOJ5 46q5WhotkKNf+5qOr3Fy039h5fJACU2dD0GZ+FnvvFDXY0e3z47MVc0lt4ek43M1 oKk9rKtVpQAxowoI9Mkx3robNzwS91ktVPHMTkSQqvZuSPQbY/3OUiRx2g2kleo0 342Reg7GFkH4BlAG6R1k= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 20 Feb 2012 23:25:34 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3599357048.18077.6468; Mon, 20 Feb 2012 23:25:33 -0500 Message-ID: <4F431D9B.6050200@isdg.net> Date: Mon, 20 Feb 2012 23:29:15 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2E9A@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E204B2E9A@TK5EX14MBXC203.redmond.corp.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 04:29:46 -0000 Paul Midgen wrote: > Outside of the case where the envelope sender is empty (e.g. NDR), most of the > HELO domains we observe are garbage. I don't think good guys will issue garbage, only bad guys, so what you observe if reflective of the amount of bad guys going your way. The different between the client domain and mail from, is there is historical precedence for incorrect configurations with requiring a valid domain, MUAs that do no have a public side domain name (hence why some use the NETBIOS computer name) or more accurately provide a domain that does not map with the the connection IP. Hence there is no requirement with the public port SMTP to validate the client domain since there is history of good guys erroneous failure. Only the private port SUBMISSION protocol enforces a proper client domain and allows for validation and canceling of a transaction on this basis. But there are rules that one can apply. If the client explicit issues a IP literal, then this MUST be match the connecting IP, a valid technical reason for enforcement. If the client issues a domain that is specifically own your network or perhaps LocalHost, this too offers strong triggers to do IP matching checks. The issue is when the domain is anonymous and has some form of a valid Domain format (at least one dot). What do you do then? With the MAIL FROM, SMTP requires this to be 100% valid, but no enforcement to check if that is true. But it MUST be valid, no room for errors, and this opens the door to do introduce validation methods like SPF or even a CBV. > Is there a reason why we do not recommend that HELO be checked only if Mail From > does not produce a definitive policy result? There was always a lot of talk that an client domain check is all one needed, like CSV/DNA idea was proposing. It followed the Chain of Trust concept from hop to hop, machine to machine. If one used the SUBMISSION (RFC4409( protocol, EHLO must be correct, so that was another point of validation. But then again, I always felt that since 4409 requires ESMTP AUTH (authentication), then perhaps any EHLO or even MAIL FROM SPF checking was redundant. In fact, with the growth of NATS and the SOHO's there was a growth of where the even usage of an EHLO IP literal no longer matched the Connection IP, i.e, an older version of Thunderbird used the private LAN machine [IP Address] but on the public side the server saw the NAT public address. So our SUBMISSION server offers operators an option to delay any EHLO checking until the ESMTP AUTH is completed. Anyway, with your question, I once felt this was probably the right way, but you have to always ask yourself what if one of them was a hard fail and the other PASS, which one has a stronger requirement to be correct? If the MAIL FROM check is valid, shouldn't the EHLO check be correct as well and vice versa? The LMAP analysis here tried to address some of these questions by looking all all possible combinations of input and logical results, including when it made sense or was impossible to occur in a valid system. http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1.htm If I recall, when this was discussed and it was at length, I think an answer was or rather one that was needed to be true, was that if you supported SPF (or a domain created SPF records to send mail), then SPF compliance reinforce SMTP compliancy by making sure the client domain was always using 100% valid EHLO/IP domains and not junk. This was to help systems that was doing EHLO SPF check reduce DNS NXDOMAIN delays. Not sure if this is answering the question, I am suggesting to look at the conditions and results and ask yourself which once make sense or doesn't. If the MAIL FROM SPF check is valid, why would an EHLO check not be done, and if so, what if its was invalid? Is it safe to suggest that valid MAIL FROM checks trumps the possibility of a EHLO check failure. I suggest that its an illogical condition under across the board compliant system. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From sm@elandsys.com Mon Feb 20 20:53:14 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87A721E803E for ; Mon, 20 Feb 2012 20:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIPJVbfc4iON for ; Mon, 20 Feb 2012 20:53:14 -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 1602121E802F for ; Mon, 20 Feb 2012 20:53:14 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.233.39]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1L4qkUc021461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Feb 2012 20:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329799987; i=@elandsys.com; bh=Xn7lngSAWc38guqkXiRAwfNLEVYSCRnBe0ZD48Jy/uA=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=VXooj40LuSGVrdpvJb+ZM0c4PgFGbM4XqoAMf314ltehr2K7TbP4e/LScr6fr/4qb l3tn1oABvht7dXn9dH/tC201RiufyROt2AuTrgJ8NOP2qZd0J4nbSbLJq66sAFXGWL U2H90iWgU2z+qrn8OBzzay3502zATWGUtXxXRXkE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329799987; i=@elandsys.com; bh=Xn7lngSAWc38guqkXiRAwfNLEVYSCRnBe0ZD48Jy/uA=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=2pR3of4CluNAirNTrrvO2lftbj8iFsVumbKqsj7hN5fqXy8n7fbwT0bo/Rxy7Q/Mp 28MhQqKGG3cRDLzxKZhJp1w7mhZrWwOIG6903dgfwhskXvbLRscKKcG6KLAmm1ioFj 8bPGhIUQIX5nOEB7m6/bLYwGgh05C4rrAjOP2wPk= Message-Id: <6.2.5.6.2.20120220192057.09251000@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Feb 2012 20:52:13 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1568886.uE4vXc93Dg@scott-latitude-e6320> References: <061.ab475cb67717b7fa7169bfb593bbd82f@tools.ietf.org> <6.2.5.6.2.20120220121328.09836200@elandnews.com> <1568886.uE4vXc93Dg@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] RFC 4408 issues list (was: #2: RFC 4408 Section B.3 - Errata #2250) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 04:53:14 -0000 At 19:03 20-02-2012, Scott Kitterman wrote: >I'm confused again. Isn't this what we are working on now? Andrew and I asked for participants to review RFC 4408 without getting into a discussion about the issues. The working group now has a list of open issues. The discussion on issue #9, #2, #3 and #8 started today. As Issue #2, #3 and #8 are editorial, they don't need to be addressed immediately. The group could wait until there is a working group Internet-Draft to discuss about editorial questions. We are not ignoring these issues; they are listed in the tracker and we will go through them in a few months. Issue #9 was opened for discussion as we don't know what to do about it. It's better to tackle issues such as that one now as it may be useful for the conclusion document. As the discussions evolves, we will have a clearer view of the direction the working group would like to take, what needs to be fixed, how to fix, etc. I understand that the way the work is being done is unusual. The group started without any idea about how to conclude the experiments or what should go in the conclusion document. Over the next few weeks, or more, the discussions should shape up that document. At 19:01 20-02-2012, Scott Kitterman wrote: >I did already mention these errata in http://www.ietf.org/mail- >archive/web/spfbis/current/msg00274.html - but they don't seem to >have made it >into the tracker. I went through http://www.rfc-editor.org/errata_search.php?rfc=4408 and opened tickets for each item. If the comments from http://www.openspf.net/RFC_4408/Errata which require discussion are posted to the mailing list, I don't have to figure out the Errata status or worry about process. >Do you want one mail per item? No, they can be posted to this mailing list as one message and I'll sort the items for tracking. Regards, S. Moonesamy From pmidge@microsoft.com Mon Feb 20 22:43:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D0B21F8623 for ; Mon, 20 Feb 2012 22:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FDbBYnaEXHa for ; Mon, 20 Feb 2012 22:43:21 -0800 (PST) Received: from TX2EHSOBE008.bigfish.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2466121F8621 for ; Mon, 20 Feb 2012 22:43:20 -0800 (PST) Received: from mail156-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Feb 2012 06:43:14 +0000 Received: from mail156-tx2 (localhost [127.0.0.1]) by mail156-tx2-R.bigfish.com (Postfix) with ESMTP id ABB2240301; Tue, 21 Feb 2012 06:43:14 +0000 (UTC) X-SpamScore: -45 X-BigFish: VS-45(zz9371I542M1432N1418M98dKc1dMzz1202hzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail156-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail156-tx2 (localhost.localdomain [127.0.0.1]) by mail156-tx2 (MessageSwitch) id 1329806593263978_4307; Tue, 21 Feb 2012 06:43:13 +0000 (UTC) Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.250]) by mail156-tx2.bigfish.com (Postfix) with ESMTP id 3C0ED140047; Tue, 21 Feb 2012 06:43:13 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Feb 2012 06:43:11 +0000 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.110]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0247.005; Mon, 20 Feb 2012 22:43:15 -0800 From: Paul Midgen To: Scott Kitterman , "spfbis@ietf.org" Thread-Topic: [spfbis] New Issue: Requirement to check mail from Thread-Index: AQHM8Bj0qTVnAEkFu0GZXRvXVtsCYJZGq3jAgAACNwCAAAB3EIAAiu8A//+u2RA= Date: Tue, 21 Feb 2012 06:43:14 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204B2FEA@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <1587556.qvTAF6dvrE@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2EF8@TK5EX14MBXC203.redmond.corp.microsoft.com> <4044511.bhIdl0R2eS@scott-latitude-e6320> In-Reply-To: <4044511.bhIdl0R2eS@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 06:43:22 -0000 How do you mean "not my use case"? -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Scott Kitterman Sent: Monday, February 20, 2012 7:34 PM To: spfbis@ietf.org Subject: Re: [spfbis] New Issue: Requirement to check mail from As long as the working group stays out of trying to define local policy bey= ond what 4408 does, I think it's not a problem. In any case, I think that the HELO check first approach I described only ma= kes sense if a site is doing SPF based rejection at SMTP time, I don't thin= k it's your use case. Scott K On Tuesday, February 21, 2012 03:30:28 AM Paul Midgen wrote: > From the point of view of defining the mechanism itself, that is=20 > probably the right thing to do. >=20 > But: as a large-scale receiver, I am less concerned about conserving=20 > DNS queries than getting a definitive authentication result the first=20 > time at bat, especially when that authentication result will trigger a=20 > number of secondary actions associated with the authenticated identity=20 > - such as positive identification UX, authentication policy, domain=20 > reputation, and so on. >=20 > If the spec leaves it up to me, I will choose the entity statistically=20 > most likely to yield the result I need. I just hope this freedom of=20 > choice doesn't hurt interoperability by not being prescriptive. >=20 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On=20 > Behalf Of Scott Kitterman Sent: Monday, February 20, 2012 7:15 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] New Issue: Requirement to check mail from >=20 > If you get a FQDN HELO checks can be useful. >=20 > Generally the most complex HELO record you'll see is v=3Dspf1 a -all. =20 > In my experience HELO records are much less expensive in DNS looksups,=20 > so even if it's less likely to be definitive (if it's not a FQDN, you=20 > just don't look it up, no harm done) it's less expensive so doing the=20 > HELO check first can be a resource saver. >=20 > There's no interoperability benefit to doing one or the other check first= . > There's equally no point in trying to insist on software doing=20 > additional checks once it already has a definitive result. I don't=20 > think we want to specify either. >=20 > Scott K >=20 > On Tuesday, February 21, 2012 03:08:47 AM Paul Midgen wrote: > > Outside of the case where the envelope sender is empty (e.g. NDR),=20 > > most of the HELO domains we observe are garbage. > >=20 > > Is there a reason why we do not recommend that HELO be checked only=20 > > if Mail From does not produce a definitive policy result? > >=20 > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On=20 > > Behalf Of Scott Kitterman Sent: Monday, February 20, 2012 1:45 PM > > To: spfbis@ietf.org > > Subject: [spfbis] New Issue: Requirement to check mail from > >=20 > > Sorry for being late. I forgot about this one. > >=20 > > Paragraph 2.2, The MAIL FROM Identity, includes this statement: > > SPF clients MUST check the "MAIL FROM" identity. SPF clients > > check > > the "MAIL FROM" identity by applying the check_host() function to > > the > > "MAIL FROM" identity as the . > >=20 > > There are applications that check HELO first and can reach a final=20 > > conclusion about message disposition based on that check. In such a=20 > > case, the Mail From check is a waste of resources. > >=20 > > I'm recommend changing this to either: > >=20 > > SPF clients MUST check the "MAIL FROM" identity unless a HELO check=20 > > has already produced a definititive policy result. ... > >=20 > > or > >=20 > > SPF clients SHOULD check the "MAIL FROM" identity (e.g. unless a=20 > > HELO check has already produced a definititive policy result). ... > >=20 > > Scott K _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Tue Feb 21 03:26:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F097421F85F6 for ; Tue, 21 Feb 2012 03:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.045, 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 vzxgDiC1bseT for ; Tue, 21 Feb 2012 03:26:35 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id DF44821F85F0 for ; Tue, 21 Feb 2012 03:26:34 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id CF158D0408D; Tue, 21 Feb 2012 05:26:33 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329823593; bh=gugrT2x2DxR8DVmpR4EiOibCq8B+8j7M4+TakLQj6l0=; h=References:In-Reply-To:MIME-Version:Content-Type:Subject:From: Date:To:Message-ID; b=Jg1boy5yb4FnYh0jXv6JjBHaPAz86PD9uvbNWrT/ZwddgpwufNWuqUyVRg43H5XkB YqZPrb+pezoS99TJH8p54XP7LzscXp+EhT6J+fZ32sIeTadfIqYVg/SJ4jP0RihEVX OA59NjuCYpxAsoipegNEBG1Prvu3dYlHv/uTirLs= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 955A8D04002; Tue, 21 Feb 2012 05:26:33 -0600 (CST) References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <1587556.qvTAF6dvrE@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2EF8@TK5EX14MBXC203.redmond.corp.microsoft.com> <4044511.bhIdl0R2eS@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2FEA@TK5EX14MBXC203.redmond.corp.microsoft.com> User-Agent: K-9 Mail for Android In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E204B2FEA@TK5EX14MBXC203.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----L1HNCYOVRSHM1Z3JL5095B7MX0O8YR" From: Scott Kitterman Date: Tue, 21 Feb 2012 06:26:42 -0500 To: "spfbis@ietf.org" Message-ID: <0031f8a4-a444-46aa-8f7c-9ab5aff41024@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 11:26:39 -0000 ------L1HNCYOVRSHM1Z3JL5095B7MX0O8YR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I'm expecting you won't do smtp time rejection based on SPF results. Scott K Paul Midgen wrote: How do you mean "not my use case"? -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Scott Kitterman Sent: Monday, February 20, 2012 7:34 PM To: spfbis@ietf.org Subject: Re: [spfbis] New Issue: Requirement to check mail from As long as the working group stays out of trying to define local policy beyond what 4408 does, I think it's not a problem. In any case, I think that the HELO check first approach I described only makes sense if a site is doing SPF based rejection at SMTP time, I don't think it's your use case. Scott K On Tuesday, February 21, 2012 03:30:28 AM Paul Midgen wrote: > From the point of view of defining the mechanism itself, that is > probably the right thing to do. > > But: as a large-scale receiver, I am less concerned about conserving > DNS queries than getting a definitive authentication result the first > time at bat, especially when that authentication result will trigger a > number of secondary actions associated with the authenticated identity > - such as positive identification UX, authentication policy, domain > reputation, and so on. > > If the spec leaves it up to me, I will choose the entity statistically > most likely to yield the result I need. I just hope this freedom of > choice doesn't hurt interoperability by not being prescriptive. > > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > Behalf Of Scott Kitterman Sent: Monday, February 20, 2012 7:15 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] New Issue: Requirement to check mail from > > If you get a FQDN HELO checks can be useful. > > Generally the most complex HELO record you'll see is v=spf1 a -all. > In my experience HELO records are much less expensive in DNS looksups, > so even if it's less likely to be definitive (if it's not a FQDN, you > just don't look it up, no harm done) it's less expensive so doing the > HELO check first can be a resource saver. > > There's no interoperability benefit to doing one or the other check first. > There's equally no point in trying to insist on software doing > additional checks once it already has a definitive result. I don't > think we want to specify either. > > Scott K > > On Tuesday, February 21, 2012 03:08:47 AM Paul Midgen wrote: > > Outside of the case where the envelope sender is empty (e.g. NDR), > > most of the HELO domains we observe are garbage. > > > > Is there a reason why we do not recommend that HELO be checked only > > if Mail From does not produce a definitive policy result? > > > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > > Behalf Of Scott Kitterman Sent: Monday, February 20, 2012 1:45 PM > > To: spfbis@ietf.org > > Subject: [spfbis] New Issue: Requirement to check mail from > > > > Sorry for being late. I forgot about this one. > > > > Paragraph 2.2, The MAIL FROM Identity, includes this statement: > > SPF clients MUST check the "MAIL FROM" identity. SPF clients > > check > > the "MAIL FROM" identity by applying the check_host() function to > > the > > "MAIL FROM" identity as the . > > > > There are applications that check HELO first and can reach a final > > conclusion about message disposition based on that check. In such a > > case, the Mail From check is a waste of resources. > > > > I'm recommend changing this to either: > > > > SPF clients MUST check the "MAIL FROM" identity unless a HELO check > > has already produced a definititive policy result. ... > > > > or > > > > SPF clients SHOULD check the "MAIL FROM" identity (e.g. unless a > > HELO check has already produced a definititive policy result). ... > > > > 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 ------L1HNCYOVRSHM1Z3JL5095B7MX0O8YR Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I'm expecting you won't do smtp time rejection based on SPF results.

Scott K

Paul Midgen <pmidge@microsoft.com> wrote:
How do you mean "not my use case"?

-----Original Message-----
From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Scott Kitterman
Sent: Monday, February 20, 2012 7:34 PM
To: spfbis@ietf.org
Subject: Re: [spfbis] New Issue: Requirement to check mail from

As long as the working group stays out of trying to define local policy beyond what 4408 does, I think it's not a problem.

In any case, I think that the HELO check first approach I described only makes sense if a site is doing SPF based rejection at SMTP time, I don't think it's your use case.

Scott K

On Tuesday, February 21, 2012 03:30:28 AM Paul Midgen wrote:
> From the point of view of defining the mechanism itself, that is 
> probably the right thing to do.
> 
> But: as a large-scale receiver, I am less concerned 
 about
conserving 
> DNS queries than getting a definitive authentication result the first 
> time at bat, especially when that authentication result will trigger a 
> number of secondary actions associated with the authenticated identity 
> - such as positive identification UX, authentication policy, domain 
> reputation, and so on.
> 
> If the spec leaves it up to me, I will choose the entity statistically 
> most likely to yield the result I need. I just hope this freedom of 
> choice doesn't hurt interoperability by not being prescriptive.
> 
> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On 
> Behalf Of Scott Kitterman Sent: Monday, February 20, 2012 7:15 PM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] New Issue: Requirement to check mail from
> 
> If you get a FQDN HELO checks can be useful.
>

> Generally the most complex HELO record you'll see is v=spf1 a -all.  
> In my experience HELO records are much less expensive in DNS looksups, 
> so even if it's less likely to be definitive (if it's not a FQDN, you 
> just don't look it up, no harm done) it's less expensive so doing the 
> HELO check first can be a resource saver.
> 
> There's no interoperability benefit to doing one or the other check first.
> There's equally no point in trying to insist on software doing 
> additional checks once it already has a definitive result.  I don't 
> think we want to specify either.
> 
> Scott K
> 
> On Tuesday, February 21, 2012 03:08:47 AM Paul Midgen wrote:
> > Outside of the case where the envelope sender is empty (e.g. NDR), 
> > most of the HELO domains we observe are garbage.
> > 
> > Is there a reason why we do not
recommend that HELO be checked only 
> > if Mail From does not produce a definitive policy result?
> > 
> > -----Original Message-----
> > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On 
> > Behalf Of Scott Kitterman Sent: Monday, February 20, 2012 1:45 PM
> > To: spfbis@ietf.org
> > Subject: [spfbis] New Issue: Requirement to check mail from
> > 
> > Sorry for being late.  I forgot about this one.
> > 
> > Paragraph 2.2, The MAIL FROM Identity, includes this statement:
> >    SPF clients MUST check the "MAIL FROM" identity.  SPF clients
> >    check
> >    the "MAIL FROM" identity by applying the check_host() function to
> >    the
> >    "MAIL FROM" identity as the <sender>.
> > 
> > There are applications that check HELO first and can reach a final 
>
> conclusion about message disposition based on that check.  In such a 
> > case, the Mail From check is a waste of resources.
> > 
> > I'm recommend changing this to either:
> > 
> > SPF clients MUST check the "MAIL FROM" identity unless a HELO check 
> > has already produced a definititive policy result. ...
> > 
> > or
> > 
> > SPF clients SHOULD check the "MAIL FROM" identity (e.g. unless a 
> > HELO check has already produced a definititive policy result). ...
> > 
> > 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
------L1HNCYOVRSHM1Z3JL5095B7MX0O8YR-- From spf2@kitterman.com Tue Feb 21 06:05:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A07E21F871D for ; Tue, 21 Feb 2012 06:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=1.045, 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 dCBiBUugAeXu for ; Tue, 21 Feb 2012 06:05:18 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 03EE921F8843 for ; Tue, 21 Feb 2012 06:05:17 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1262920E40CC; Tue, 21 Feb 2012 09:05:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329833117; bh=WNpN/nr+EQlsvfABXWmQcWWMhtKOcbh4Y9MlcfivyNc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=cZb5VPjBxqFx96r+B5RlCsw1zbk/PL+aRvzJWs/liiK+JyoINAFoznvp9Ol/W9JAE xQG+6f2pgWB6kyQk4YmQMn2rfWXWsr14gPXcrjVy62TcXH2ncA2703BvISSeyTKGYK BuiO1zR2AAOW60WbhDLE6DwZa8R2Wa9CLO6uIuNs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id EC49420E4099; Tue, 21 Feb 2012 09:05:16 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 21 Feb 2012 09:05:16 -0500 Message-ID: <16420273.5YeQbDGRyd@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120220192057.09251000@resistor.net> References: <061.ab475cb67717b7fa7169bfb593bbd82f@tools.ietf.org> <1568886.uE4vXc93Dg@scott-latitude-e6320> <6.2.5.6.2.20120220192057.09251000@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] RFC 4408 issues list (was: #2: RFC 4408 Section B.3 - Errata #2250) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 14:05:23 -0000 On Monday, February 20, 2012 08:52:13 PM S Moonesamy wrote: ... > At 19:01 20-02-2012, Scott Kitterman wrote: > >I did already mention these errata in http://www.ietf.org/mail- > >archive/web/spfbis/current/msg00274.html - but they don't seem to > >have made it > >into the tracker. > > I went through http://www.rfc-editor.org/errata_search.php?rfc=4408 > and opened tickets for each item. If the comments from > http://www.openspf.net/RFC_4408/Errata which require discussion are > posted to the mailing list, I don't have to figure out the Errata > status or worry about process. > > >Do you want one mail per item? > > No, they can be posted to this mailing list as one message and I'll > sort the items for tracking. Errata approved by the SPF council and/or by the RFC authors Add %v macro to ABNF grammar Undefined "uric" set Recommend an SMTP reply code for optional PermError rejections Received-SPF examples have incorrect syntax unknown-modifier is too greedy Empty domain spec on exp modifier PermError on invalid domains after macro expansion Miscellaneous confirmed typos Add %v macro to ABNF grammar Suggested wording: The ABNF grammar in section 8.1 and appendix A are missing the letter "v". The macro-letter production should look like this: macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / "c" / "r" / "t" / "v" Rationale: The %v macro is listed in the table of macros in section 8.1, and used in the examples. Undefined uric set Suggested wording: Replace "uric" by "unreserved" in section 8.1. Rationale: uric was defined in RFC 2396, but later removed in RFC 3986. Because RFC 4408 has a normative reference to RFC 3986 (AKA STD 66) uric has to be replaced by a modern set of characters affected by the URL escaping for uppercased macros. Reported by Julian and confirmed by Wayne. Recommend an SMTP reply code for optional PermError rejections Suggested wording: If the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 550 and, if supported, the 5.5.2 DSN code. (to be added at the end of 2.5.7 in the style of the wording at the end of 2.5.6) Rationale: The PermError section in Wayne's first SPF I-D stated: A PermError result means that the domain's published records couldn't be correctly interpreted. Checking software SHOULD reject the message. If rejecting during SMTP transaction time, it SHOULD use an SMTP reply code of 550 and, if supported, the 5.5.2 DSN code. This was removed later when the first SHOULD was identified as receiver policy. However the second SHOULD recommends an appropriate reply code for receivers wishing to reject PermError. The issue was resolved in an appeal to the SPF Council proposing to use a similar wording as for FAIL, but the missing status code didn't make it again into the final draft. Received-SPF examples use incorrect syntax Suggested wording: The examples in section 7 are incorrectly quoted, and should look like this: Received-SPF: Pass (mybox.example.org: domain of myname@example.com designates 192.0.2.1 as permitted sender) receiver=mybox.example.org; client-ip=192.0.2.1; envelope-from="myname@example.com"; helo=foo.example.com; Received-SPF: Fail (mybox.example.org: domain of myname@example.com does not designate 192.0.2.1 as permitted sender) identity=mailfrom; client-ip=192.0.2.1; envelope-from="myname@example.com"; Rationale: In RFC4408, key-value-pair is defined as: key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) However, the examples look like this: Received-SPF: Pass (mybox.example.org: domain of myname@example.com designates 192.0.2.1 as permitted sender) receiver=mybox.example.org; client-ip=192.0.2.1; envelope-from=; helo=foo.example.com; Notice that envelope-from in both cases is NOT a dot-atom or quoted-string. None of '<','>','@' are legal chars for dot-atom. unknown-modifier clause is too greedy in ABNF In section 4.6.1/2, unknown-modifier should be changed to: unknown-modifier = name "=" macro-string ; where name is not any known modifier Rationale: The unknown-modifier clause is too greedy, causing any syntax errors in redirect or explanation to simply become unknown-modifier. For instance, "exp=- all" would match unknown-modifier. This was not the intent. For a similar case see RFC 2822, where the field names of any optional-field MUST NOT be identical to any field name specified elsewhere in this standard. Empty domain-spec on exp modifier Problem statement: Section 6.2/4 says: If domain-spec is empty, or there are any DNS processing errors (any RCODE other than 0), or if no records are returned, or if more than one record is returned, or if there are syntax errors in the explanation string, then proceed as if no exp modifier was given. However, 6.2/1 gives the grammar for exp as: explanation = "exp" "=" domain-spec domain-spec = macro-string domain-end domain-end = ( "." toplabel [ "." ] ) / macro-expand Thus, domain-spec can never be empty. Syntax errors require a permerror result, which conflicts with the instruction to "proceed as if no exp modifier was given." Suggested fix and rationale: Section 6.2/4 should be changed to say: If there are any DNS processing errors (any RCODE other than 0), or if no records are returned, or if more than one record is returned, or if there are syntax errors in the explanation string, then proceed as if no exp modifier was given. The exp and redirect modifiers are special since they are included in the spec. They must be fully parsed, with any resulting Permerror, even when exp= is not otherwise supported. Clear syntax errors are supposed to be identified a.s.a.p. and reported as PermError, and supporting explanations in syntax isn't optional. The prose obviously wants that an empty and similar issues after the macro expansion of are ignored. It's more important to reject the FAIL than to deal with obscure explanation issues. PermError on invalid domains after macro expansion Problem statement: The Permerror definition ends with: Be aware that if the domain owner uses macros (Section 8), it is possible that this result is due to the checked identities having an unexpected format. A after macro expansion of can be invalid, i.e. a string not suited for DNS queries like foo..example (adjacent dots), a with overlong labels, or similar issues not permitted in the DNS syntax. Suggested fix (variant 1): The last sentence in the Permerror definition is misleading. A syntactically malformed can be also handled as no match. The specification should say: Be aware that if the domain owner uses macros (Section 8), it is possible that this result is due to the checked identities having an unexpected format. Please note that an unexpected can be also handled as no match, ideally implementations document how they handle such issues. The outcome for an unexpected without macros might differ from the outcome for an unexpected after macro expansion. Suggested fix (Variant 2): The last sentence in the Permerror definition is misleading. A syntactically malformed can be also handled as no match. The specification should say: Be aware that it is also possible that this result is generated by certain SPF clients due to the input arguments having an unexpected format; see Section 4.8. At the end of Section 4.8 add: Note: Historically, this document has made no provisions for how to handle s, or macro-expansions thereof, that are syntactically invalid per [RFC1035], such as names with empty labels (e.g., "foo..example.com") or overlong labels (more than 63 characters). Some implementations choose to treat as a no-match mechanisms, and ignore modifiers, with such names, whereas others throw a "PermError" exception. The outcome for an unexpected without macros might even differ from that for an unexpected after macro expansion. Rationale: Reporting a TempError in such cases is no option, the syntax problem won't go away for a given sender policy, HELO identity, envelope sender address, and sending IP combination with a try again later TempError approach. If anything else is as expected the sender policy might need to be fixed manually, supporting PermError. If the DNS syntax problem is caused by random net abuse, or intentionally by an attacker, a no match approach, eventually reaching a FAIL for -all or whatever the sender policy offers, is better. In common practice this problem is handled as no match OR PermError, like similar problems explicitly addressed in the specification. Miscellaneous typos Missing indentation for the second paragraph of the [US-ASCII] reference reported by Wayne. Missing line break on page 46 before mary.mobile-users reported by Wayne. Typo: "Danish" instead of "Danisch" in the references confirmed by Wayne and Frank. Missing words in the last sentence of the third paragraph of section 6.1: "The and arguments remain the same as in the current evaluation of check_host()." (reported by Julian) From dhc2@dcrocker.net Tue Feb 21 06:18:09 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D567F21F8844 for ; Tue, 21 Feb 2012 06:18:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJHjkKHRqq1Y for ; Tue, 21 Feb 2012 06:18:05 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 875A621F8865 for ; Tue, 21 Feb 2012 06:18:05 -0800 (PST) Received: from [192.168.10.110] (64.1.210.2.ptr.us.xo.net [64.1.210.2]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1LEI0YV009104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Feb 2012 06:18:05 -0800 Message-ID: <4F43A794.2020903@dcrocker.net> Date: Tue, 21 Feb 2012 06:17:56 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "spfbis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 21 Feb 2012 06:18:05 -0800 (PST) Subject: [spfbis] OT: RFC http://tools.ietf.org/rfc/rfc644.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 14:18:10 -0000 Given the topic of this working group, I thought folks might be interested in a bit of arcana I just came across: On the Problem of Signature Authentication for Network Mail B. Thomas, BBN RFC 644 July 1974 This belies the frequent claim that original efforts on email ignored security. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Tue Feb 21 06:18:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF0421F885A for ; Tue, 21 Feb 2012 06:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 JHpb8NkOESkg for ; Tue, 21 Feb 2012 06:18:16 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6366A21F8844 for ; Tue, 21 Feb 2012 06:18:16 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EF26E20E40CC; Tue, 21 Feb 2012 09:18:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329833896; bh=b1dejK7SFNWDb8tregPf8nYlpGGqzl28vmJfYcnaE1E=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=qJn4G56IvJYtwQ0VSDPxyTJkFugcaCfW0dm/ssCqvwJBBibm/q2wwpnTy7v3tnbXr +NqP2vG62LhwSIbv16Jd/D6k1zvBUApJk0KMsBVkbIUwzhgL62ndAlCQohsHTy5elh +FBuBQxJco5VRymbhT+mBPgy5ESRKcY6XS7spOvI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D167420E4099; Tue, 21 Feb 2012 09:18:15 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 21 Feb 2012 09:18:15 -0500 Message-ID: <3176408.7BSB2cjgvu@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120220192057.09251000@resistor.net> References: <061.ab475cb67717b7fa7169bfb593bbd82f@tools.ietf.org> <1568886.uE4vXc93Dg@scott-latitude-e6320> <6.2.5.6.2.20120220192057.09251000@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] RFC 4408 issues list (was: #2: RFC 4408 Section B.3 - Errata #2250) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 14:18:19 -0000 On Monday, February 20, 2012 08:52:13 PM S Moonesamy wrote: > At 19:03 20-02-2012, Scott Kitterman wrote: > >I'm confused again. Isn't this what we are working on now? > > Andrew and I asked for participants to review RFC 4408 without > getting into a discussion about the issues. The working group now > has a list of open issues. The discussion on issue #9, #2, #3 and #8 > started today. As Issue #2, #3 and #8 are editorial, they don't need > to be addressed immediately. The group could wait until there is a > working group Internet-Draft to discuss about editorial > questions. We are not ignoring these issues; they are listed in the > tracker and we will go through them in a few months. > > Issue #9 was opened for discussion as we don't know what to do about > it. It's better to tackle issues such as that one now as it may be > useful for the conclusion document. As the discussions evolves, we > will have a clearer view of the direction the working group would > like to take, what needs to be fixed, how to fix, etc. > > I understand that the way the work is being done is unusual. The > group started without any idea about how to conclude the experiments > or what should go in the conclusion document. Over the next few > weeks, or more, the discussions should shape up that document. Not understanding how to write a technical document that wraps up an "experiment" that was started for ill defined (and IMO non-technical) reasons is unrelated to what we understand about what needs to go into 4408bis, so I'm still confused. I fear that this process of discussing issues without a draft to document the consensus in is going to result in repetitive work. First we discuss an issue and reach some rough consensus and then later when we have to put words on paper in a draft we'll inevitably end up rehashing the issue. Every other IETF working group I've been involved in (which is admittedly not a large number) has started with a draft and then documented the results of their discussions in the draft as they went along (including groups that used an issue tracker). This doesn't eliminate the risk you'll get to the end and have to revisit issues, but the current process this group seems to be following guarantees it. Scott K From dhc2@dcrocker.net Tue Feb 21 06:45:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD7221F881D for ; Tue, 21 Feb 2012 06:45:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhkxcvrnQqna for ; Tue, 21 Feb 2012 06:45:21 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C8A2721F84CD for ; Tue, 21 Feb 2012 06:45:21 -0800 (PST) Received: from [192.168.10.110] (64.1.210.2.ptr.us.xo.net [64.1.210.2]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1LEjGHM010267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 06:45:21 -0800 Message-ID: <4F43ADF8.9070201@dcrocker.net> Date: Tue, 21 Feb 2012 06:45:12 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Scott Kitterman References: <061.ab475cb67717b7fa7169bfb593bbd82f@tools.ietf.org> <1568886.uE4vXc93Dg@scott-latitude-e6320> <6.2.5.6.2.20120220192057.09251000@resistor.net> <3176408.7BSB2cjgvu@scott-latitude-e6320> In-Reply-To: <3176408.7BSB2cjgvu@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 21 Feb 2012 06:45:21 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 14:45:26 -0000 On 2/21/2012 6:18 AM, Scott Kitterman wrote: > I fear that this process of discussing issues without a draft to document the > consensus in is going to result in repetitive work. First we discuss an issue > and reach some rough consensus and then later when we have to put words on > paper in a draft we'll inevitably end up rehashing the issue. You are likely correct. However I'll suggest that in this case it might be a Good Thing. Normally, revision efforts start with the group's having good context about the document being revised. The group typically has a significant number of folk who participated in the original writing effort and it typically has a significant number of people who have been "using" the document. My guess is that SPFbis does not enjoy quite as much of such shared context as is usual. Consequently, it might actually be helpful to take a "spiral" approach to the work; that is, visiting issues a couple of times, during different phases of the work. That said, there certainly is a danger of re-hashing settled issues -- a serious concern, since of course it rarely happens in other IETF efforts... There are two basic mechanisms that mitigate against inappropriate re-hashing (and yes, there are cases of 'appropriate' rehashing.) The first is making sure the the original process of resolving a point has a clear, consensus-based outcome. The second is wg management that enforces those decisions, absent explicit justification to re-open issues. I suspect this wg's management team is entirely up to both tasks... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Tue Feb 21 07:29:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CEE21F87FC for ; Tue, 21 Feb 2012 07:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 m5FdDR4c7FjR for ; Tue, 21 Feb 2012 07:29:33 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3244221F863B for ; Tue, 21 Feb 2012 07:29:31 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5E9AB20E40CC; Tue, 21 Feb 2012 10:29:31 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329838171; bh=80R81uXyDXrt7fQa1c9cfPuTlJgIBmsD+3A3wAAdWP4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=n4GorjAKL6V64iOK39SA+KZrylpop8NanI44xdr3J+PG+kEQfX60hhTVYtavxVWsR LODOVy2IEK4VNKR621hGkgNjyNSACDxWFbVwyKvVO34hWfj2c01Vc6fPTcpcUJ/ywy zSGumjCq/MNIvKaCailhQGHBGhcVwvUWWNEpGa1k= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3E7B220E4099; Tue, 21 Feb 2012 10:29:31 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 21 Feb 2012 10:29:30 -0500 Message-ID: <3511388.PH0ytCIYaP@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F43ADF8.9070201@dcrocker.net> References: <061.ab475cb67717b7fa7169bfb593bbd82f@tools.ietf.org> <3176408.7BSB2cjgvu@scott-latitude-e6320> <4F43ADF8.9070201@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 15:29:37 -0000 On Tuesday, February 21, 2012 06:45:12 AM Dave CROCKER wrote: > Normally, revision efforts start with the group's having good context about > the document being revised. The group typically has a significant number > of folk who participated in the original writing effort and it typically > has a significant number of people who have been "using" the document. > > My guess is that SPFbis does not enjoy quite as much of such shared context > as is usual. Consequently, it might actually be helpful to take a > "spiral" approach to the work; that is, visiting issues a couple of times, > during different phases of the work. There are quite a number of people here who have significant experience with the document and implementing SPF. I don't see any need to design WG process around the assumption this is not the case. There are a few significant issues that need discussion, but this isn't a case of something that's not working as designed that needs major overhaul. I feel like we're making this harder than it is. It would have been nice (IMO) for there to have been some discussion about how this is going to work. I keep having questions and I'm pretty sure the chairs know how they intend to proceed, but I don't think it's ever been completely explained. Scott K From ajs@anvilwalrusden.com Tue Feb 21 08:18:38 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE02721F8852 for ; Tue, 21 Feb 2012 08:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 bcuCk37x0zi3 for ; Tue, 21 Feb 2012 08:18:38 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFF721F8859 for ; Tue, 21 Feb 2012 08:18:37 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E42B31ECB447 for ; Tue, 21 Feb 2012 16:18:36 +0000 (UTC) Date: Tue, 21 Feb 2012 11:18:35 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120221161834.GC34608@mail.yitter.info> References: <061.ab475cb67717b7fa7169bfb593bbd82f@tools.ietf.org> <3176408.7BSB2cjgvu@scott-latitude-e6320> <4F43ADF8.9070201@dcrocker.net> <3511388.PH0ytCIYaP@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3511388.PH0ytCIYaP@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 16:18:38 -0000 Hi, On Tue, Feb 21, 2012 at 10:29:30AM -0500, Scott Kitterman wrote: > > There are quite a number of people here who have significant > experience with the document and implementing SPF. I don't see any > need to design WG process around the assumption this is not the > case. There are also people who do not have such experience, and there are people who have strong opinions about the topic. Finally, and maybe most importantly, there are several people who have extremely wide-ranging opinions about matters, and have a history of collapsing different issues and treating them as though they're all the same thing. We want to avoid all of that. You are correct in your impression that this will probably result in some issues being discussed more than once. The idea is precisely that it's up to the chairs to interrupt, if a discussion goes back over well-tilled ground, and ask what is different this time. > There are a few significant issues that need discussion, but this > isn't a case of something that's not working as designed that needs > major overhaul. Also, in any case, we're not chartered to do a major overhaul. But this is the classic bikeshed situation: everyone has a strong opinion about the details, and will argue about each of them, weaving in other details of the bikeshed's construction and colour scheme without regard for various distinctions. That's exactly what our methodology is intended to avoid. Once the more controversial questions have been addressed, we can integrate them into a candidate draft. It seems to me that there was an IETF contribution that someone thoughtfully provided that could be a good start for that, but before we commit to anything it seemed to me that it would be wise to clear away some of the controversy. > like we're making this harder than it is. It would have been nice > (IMO) for there to have been some discussion about how this is going > to work. When SM and I proposed taking this approach to the AD, the question of whether to discuss the methodology first was broached. I was, and remain, opposed to that; all it would do is turn the management of the WG's process itself into another bikeshed problem. It wouldn't be the first time, but I think the WG will be more productive the way we're going. I hope that explains things to your satisfaction. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Tue Feb 21 08:24:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE92A21F85A2 for ; Tue, 21 Feb 2012 08:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 IOrL1+ocyA5W for ; Tue, 21 Feb 2012 08:24:28 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D86EC21F84D1 for ; Tue, 21 Feb 2012 08:24:12 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 54D6B20E40CC; Tue, 21 Feb 2012 11:24:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329841452; bh=K84bVapOh5KTeZJjxEiqoi7VLvbjSjxrdvaRwgSrvGE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Wc4fZrDyI51uSRwwxYLJjqYPNvz3Jj3bC2750YLn3iAbvJmmODck4MWqLLgaOr6XI HPdzYClGKn4BOdkz0gAWq48lO2bG5Rn+WVg8qmv0TYXVt+IUy2Xqi0uOCUu1IdrWm/ uBkAIlU4snaQZeP0/qbsVVV0jevz4TDImHrLLSHY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 35F0C20E4099; Tue, 21 Feb 2012 11:24:11 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 21 Feb 2012 11:24:11 -0500 Message-ID: <2268068.OHZpIlfS5y@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120221161834.GC34608@mail.yitter.info> References: <061.ab475cb67717b7fa7169bfb593bbd82f@tools.ietf.org> <3511388.PH0ytCIYaP@scott-latitude-e6320> <20120221161834.GC34608@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] RFC 4408 issues list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 16:24:31 -0000 On Tuesday, February 21, 2012 11:18:35 AM Andrew Sullivan wrote: > ... It seems to > me that there was an IETF contribution that someone thoughtfully > provided that could be a good start for that ... Yes. That was me. https://datatracker.ietf.org/doc/draft-kitterman-4408bis/ > When SM and I proposed taking this approach to the AD, the question of > whether to discuss the methodology first was broached. I was, and > remain, opposed to that; all it would do is turn the management of the > WG's process itself into another bikeshed problem. It wouldn't be the > first time, but I think the WG will be more productive the way we're > going. > > I hope that explains things to your satisfaction. It doesn't, but at least I know it's on purpose now. I'll strive for patience. No promises. Scott K From vesely@tana.it Tue Feb 21 08:59:53 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A2321F8661 for ; Tue, 21 Feb 2012 08:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=0.070, 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 ieI42D5jAUmP for ; Tue, 21 Feb 2012 08:59:48 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C23A021F8620 for ; Tue, 21 Feb 2012 08:59:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1329843578; bh=uNce3VSRCTN4usSl1ptm9XxNAcJKsVnhwTh0b4lgqoc=; l=1119; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=VTSkWRYqTeMj12pvCSNvXs9+bpl39JbluY3JRtRio3vd5VOgyuJj6PfytsByb0l6O Vo0BWunUGgYmGzvg3ntnKODJmuXYpl5fPBhbfiKq7sm+Ek1l5SUHMXjweQN7SFvpsP fiH3MCDoJcjnwRSePwG3UCXvoJLoWO7XthNPDiF8= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 21 Feb 2012 17:59:38 +0100 id 00000000005DC035.000000004F43CD7A.00001C4A Message-ID: <4F43CD7A.7070605@tana.it> Date: Tue, 21 Feb 2012 17:59:38 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120220212346.17006.qmail@joyce.lan> <20120220193102.GD33775@crankycanuck.ca> <4F42B53C.6070508@Commerco.Net> <2315228.TssiT3d69m@scott-latitude-e6320> In-Reply-To: <2315228.TssiT3d69m@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 16:59:53 -0000 On 20/Feb/12 22:13, Scott Kitterman wrote: > On Monday, February 20, 2012 02:03:56 PM Commerco WebMaster wrote: >> >> With enough requests for SPF RR preceding the TXT RR requests, as the >> newer implementation pattern become more frequently observed, hopefully >> most DNS administrators will get the hint and establish the new SPF RRs >> in their authoritative host zone files and ultimately be able to get rid >> of the SPF V1 TXT RRs. Grepping "view external: query: $helo_name IN SPF", I found their count came out at 85% of the corresponding TXT. Yet I have no SPF RR, so 85% is obviously not enough. > We aren't here to debate some theoretical future SPF version, but the one we > have. Type 99 (SPF) is not serving a useful purpose right now, so we should > mark it deprecated (don't use) and quit worrying about it. +1, although we should praise those who were so clever to use SPF, and suggest to concede plenty of compatibility support. However, as it's already possible that a 4408-compliant checker ignores the SPF RR type, we should recommend that new applications ignore it too. From pmidge@microsoft.com Tue Feb 21 09:04:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C6021F8863 for ; Tue, 21 Feb 2012 09:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.501, 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 JtUI5qLj1LGv for ; Tue, 21 Feb 2012 09:04:44 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id EE65921F861E for ; Tue, 21 Feb 2012 09:04:43 -0800 (PST) Received: from mail83-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Feb 2012 17:04:38 +0000 Received: from mail83-ch1 (localhost [127.0.0.1]) by mail83-ch1-R.bigfish.com (Postfix) with ESMTP id B8C91200381; Tue, 21 Feb 2012 17:04:38 +0000 (UTC) X-SpamScore: -45 X-BigFish: VS-45(zz9371Ic89bh542M1432N1418Mc857h98dKc1dMzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail83-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail83-ch1 (localhost.localdomain [127.0.0.1]) by mail83-ch1 (MessageSwitch) id 1329843876798409_29336; Tue, 21 Feb 2012 17:04:36 +0000 (UTC) Received: from CH1EHSMHS021.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail83-ch1.bigfish.com (Postfix) with ESMTP id BD0A7E004C; Tue, 21 Feb 2012 17:04:36 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Feb 2012 17:04:35 +0000 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.110]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0247.005; Tue, 21 Feb 2012 17:04:31 +0000 From: Paul Midgen To: Scott Kitterman , "spfbis@ietf.org" Thread-Topic: [spfbis] New Issue: Requirement to check mail from Thread-Index: AQHM8Bj0qTVnAEkFu0GZXRvXVtsCYJZGq3jAgAACNwCAAAB3EIAAiu8A//+u2RCAAE8+AIAAXRjA Date: Tue, 21 Feb 2012 17:04:30 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204B3307@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <1587556.qvTAF6dvrE@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2EF8@TK5EX14MBXC203.redmond.corp.microsoft.com> <4044511.bhIdl0R2eS@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2FEA@TK5EX14MBXC203.redmond.corp.microsoft.com> <0031f8a4-a444-46aa-8f7c-9ab5aff41024@email.android.com> In-Reply-To: <0031f8a4-a444-46aa-8f7c-9ab5aff41024@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_7F7F36E50398F84DBAF25C9D51732F1E204B3307TK5EX14MBXC203r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 17:04:48 -0000 --_000_7F7F36E50398F84DBAF25C9D51732F1E204B3307TK5EX14MBXC203r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgdGhlIHBvbGljeSBpcyB0aGVyZSwgd2XigJlsbCBkbyBpdC4NCg0KVW5sZXNzIHlvdeKAmXJl IHJhaXNpbmcgdGhlIHBvaW50IHRoYXQgSG90bWFpbCBjdXJyZW50bHkgZXZhbHVhdGVzIFNlbmRl cklEIOKAkyB0aGF0IGlzIGN1cnJlbnRseSBzdGlsbCB0cnVlLCBob3dldmVyIGluIG9yZGVyIHRv IGZ1bGx5IHN1cHBvcnQgRE1BUkMgd2Ugd2lsbCBiZSBzd2l0Y2hpbmcgdG8gU1BGIGp1c3QgYXMg c29vbiBhcyBJIGNhbiBtYWtlIGl0IGhhcHBlbi4NCg0KSSBkb27igJl0IHRoaW5rIHRoYXQgY2hh bmdlcyBhbnl0aGluZyB0aG91Z2gsIHdl4oCZbGwgc3RpbGwgY2hvb3NlIGEgY29uc2lzdGVudCBt b2RlbCBmb3IgZXZhbHVhdGlvbiB0aGF0IG1heSBiZSBiYWNrd2FyZHMgZnJvbSB3aGF0IGlzIGN1 cnJlbnRseSB3cml0dGVuLiBUaGUgYXNzdW1wdGlvbnMgdW5kZXJseWluZyB0aGUgd2F5IGl0IGlz IGN1cnJlbnRseSB3cml0dGVuIGFyZSBpbXBvcnRhbnQgaW5zb2ZhciBhcyB0aGV5IHJlcHJlc2Vu dCBzb21ldGhpbmcgbm90IGltbWVkaWF0ZWx5IG9idmlvdXMg4oCTIOKAnGNoZWFwZXLigJ0gRE5T IHF1ZXJpZXMgaXMgdGhlIG9ubHkgcmVhc29uIHByb3ZpZGVkIHNvIGZhciwgYW5kIGluIG15IHVz ZSBjYXNlIOKAnEROUyBxdWVyeSBjaGVhcG5lc3PigJ0gaXMgbm90IGEgY29uY2Vybi4NCg0KU28g YmV5b25kIHRoYXQsIGlmIEkgYWx3YXlzIGNoZWNrIE1haWwgRnJvbSBmaXJzdCAod2hlbiBwcmVz ZW50KSB0aGVuIHN0b3AgaWYgc2F0aXNmaWVkLCB3aWxsIHRoYXQgY3JlYXRlIHNvbWUgb2J2aW91 cyBwcm9ibGVtPyBJZiBub3QsIGdyZWF0ISBJZiB0aGVyZeKAmXMgYW55IGRvdWJ0LCBpdCBzaG91 bGQgYmUgZXhhbWluZWQuDQoNCkZyb206IHNwZmJpcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 c3BmYmlzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTY290dCBLaXR0ZXJtYW4NClNl bnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDIxLCAyMDEyIDM6MjcgQU0NClRvOiBzcGZiaXNAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbc3BmYmlzXSBOZXcgSXNzdWU6IFJlcXVpcmVtZW50IHRvIGNoZWNr IG1haWwgZnJvbQ0KDQpJJ20gZXhwZWN0aW5nIHlvdSB3b24ndCBkbyBzbXRwIHRpbWUgcmVqZWN0 aW9uIGJhc2VkIG9uIFNQRiByZXN1bHRzLg0KDQpTY290dCBLDQpQYXVsIE1pZGdlbiA8cG1pZGdl QG1pY3Jvc29mdC5jb208bWFpbHRvOnBtaWRnZUBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoNCkhv dyBkbyB5b3UgbWVhbiAibm90IG15IHVzZSBjYXNlIj8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IHNwZmJpcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcGZiaXMtYm91bmNl c0BpZXRmLm9yZz4gW21haWx0bzpzcGZiaXMtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRvOlttYWls dG86c3BmYmlzLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgU2NvdHQgS2l0dGVybWFu DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDIwLCAyMDEyIDc6MzQgUE0NClRvOiBzcGZiaXNAaWV0 Zi5vcmc8bWFpbHRvOnNwZmJpc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3BmYmlzXSBOZXcg SXNzdWU6IFJlcXVpcmVtZW50IHRvIGNoZWNrIG1haWwgZnJvbQ0KDQpBcyBsb25nIGFzIHRoZSB3 b3JraW5nIGdyb3VwIHN0YXlzIG91dCBvZiB0cnlpbmcgdG8gZGVmaW5lIGxvY2FsIHBvbGljeSBi ZXlvbmQgd2hhdCA0NDA4IGRvZXMsIEkgdGhpbmsgaXQncyBub3QgYSBwcm9ibGVtLg0KDQpJbiBh bnkgY2FzZSwgSSB0aGluayB0aGF0IHRoZSBIRUxPIGNoZWNrIGZpcnN0IGFwcHJvYWNoIEkgZGVz Y3JpYmVkIG9ubHkgbWFrZXMgc2Vuc2UgaWYgYSBzaXRlIGlzIGRvaW5nIFNQRiBiYXNlZCByZWpl Y3Rpb24gYXQgU01UUCB0aW1lLCBJIGRvbid0IHRoaW5rIGl0J3MgeW91ciB1c2UgY2FzZS4NCg0K U2NvdHQgSw0KDQpPbiBUdWVzZGF5LCBGZWJydWFyeSAyMSwgMjAxMiAwMzozMDoyOCBBTSBQYXVs IE1pZGdlbiB3cm90ZToNCj4gRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBkZWZpbmluZyB0aGUg bWVjaGFuaXNtIGl0c2VsZiwgdGhhdCBpcw0KPiBwcm9iYWJseSB0aGUgcmlnaHQgdGhpbmcgdG8g ZG8uDQo+DQo+IEJ1dDogYXMgYSBsYXJnZS1zY2FsZSByZWNlaXZlciwgSSBhbSBsZXNzIGNvbmNl cm5lZA0KDQogYWJvdXQNCg0KY29uc2VydmluZw0KPiBETlMgcXVlcmllcyB0aGFuIGdldHRpbmcg YSBkZWZpbml0aXZlIGF1dGhlbnRpY2F0aW9uIHJlc3VsdCB0aGUgZmlyc3QNCj4gdGltZSBhdCBi YXQsIGVzcGVjaWFsbHkgd2hlbiB0aGF0IGF1dGhlbnRpY2F0aW9uIHJlc3VsdCB3aWxsIHRyaWdn ZXIgYQ0KPiBudW1iZXIgb2Ygc2Vjb25kYXJ5IGFjdGlvbnMgYXNzb2NpYXRlZCB3aXRoIHRoZSBh dXRoZW50aWNhdGVkIGlkZW50aXR5DQo+IC0gc3VjaCBhcyBwb3NpdGl2ZSBpZGVudGlmaWNhdGlv biBVWCwgYXV0aGVudGljYXRpb24gcG9saWN5LCBkb21haW4NCj4gcmVwdXRhdGlvbiwgYW5kIHNv IG9uLg0KPg0KPiBJZiB0aGUgc3BlYyBsZWF2ZXMgaXQgdXAgdG8gbWUsIEkgd2lsbCBjaG9vc2Ug dGhlIGVudGl0eSBzdGF0aXN0aWNhbGx5DQo+IG1vc3QgbGlrZWx5IHRvIHlpZWxkIHRoZSByZXN1 bHQgSSBuZWVkLiBJIGp1c3QgaG9wZSB0aGlzIGZyZWVkb20gb2YNCj4gY2hvaWNlIGRvZXNuJ3Qg aHVydCBpbnRlcm9wZXJhYmlsaXR5IGJ5IG5vdCBiZWluZyBwcmVzY3JpcHRpdmUuDQo+DQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNwZmJpcy1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpzcGZiaXMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpzcGZiaXMtYm91bmNlc0Bp ZXRmLm9yZ108bWFpbHRvOlttYWlsdG86c3BmYmlzLWJvdW5jZXNAaWV0Zi5vcmddPiBPbg0KPiBC ZWhhbGYgT2YgU2NvdHQgS2l0dGVybWFuIFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjAsIDIwMTIg NzoxNSBQTQ0KPiBUbzogc3BmYmlzQGlldGYub3JnPG1haWx0bzpzcGZiaXNAaWV0Zi5vcmc+DQo+ IFN1YmplY3Q6IFJlOiBbc3BmYmlzXSBOZXcgSXNzdWU6IFJlcXVpcmVtZW50IHRvIGNoZWNrIG1h aWwgZnJvbQ0KPg0KPiBJZiB5b3UgZ2V0IGEgRlFETiBIRUxPIGNoZWNrcyBjYW4gYmUgdXNlZnVs Lg0KPg0KDQo+IEdlbmVyYWxseSB0aGUgbW9zdCBjb21wbGV4IEhFTE8gcmVjb3JkIHlvdSdsbCBz ZWUgaXMgdj1zcGYxIGEgLWFsbC4NCj4gSW4gbXkgZXhwZXJpZW5jZSBIRUxPIHJlY29yZHMgYXJl IG11Y2ggbGVzcyBleHBlbnNpdmUgaW4gRE5TIGxvb2tzdXBzLA0KPiBzbyBldmVuIGlmIGl0J3Mg bGVzcyBsaWtlbHkgdG8gYmUgZGVmaW5pdGl2ZSAoaWYgaXQncyBub3QgYSBGUUROLCB5b3UNCj4g anVzdCBkb24ndCBsb29rIGl0IHVwLCBubyBoYXJtIGRvbmUpIGl0J3MgbGVzcyBleHBlbnNpdmUg c28gZG9pbmcgdGhlDQo+IEhFTE8gY2hlY2sgZmlyc3QgY2FuIGJlIGEgcmVzb3VyY2Ugc2F2ZXIu DQo+DQo+IFRoZXJlJ3Mgbm8gaW50ZXJvcGVyYWJpbGl0eSBiZW5lZml0IHRvIGRvaW5nIG9uZSBv ciB0aGUgb3RoZXIgY2hlY2sgZmlyc3QuDQo+IFRoZXJlJ3MgZXF1YWxseSBubyBwb2ludCBpbiB0 cnlpbmcgdG8gaW5zaXN0IG9uIHNvZnR3YXJlIGRvaW5nDQo+IGFkZGl0aW9uYWwgY2hlY2tzIG9u Y2UgaXQgYWxyZWFkeSBoYXMgYSBkZWZpbml0aXZlIHJlc3VsdC4gIEkgZG9uJ3QNCj4gdGhpbmsg d2Ugd2FudCB0byBzcGVjaWZ5IGVpdGhlci4NCj4NCj4gU2NvdHQgSw0KPg0KPiBPbiBUdWVzZGF5 LCBGZWJydWFyeSAyMSwgMjAxMiAwMzowODo0NyBBTSBQYXVsIE1pZGdlbiB3cm90ZToNCj4gPiBP dXRzaWRlIG9mIHRoZSBjYXNlIHdoZXJlIHRoZSBlbnZlbG9wZSBzZW5kZXIgaXMgZW1wdHkgKGUu Zy4gTkRSKSwNCj4gPiBtb3N0IG9mIHRoZSBIRUxPIGRvbWFpbnMgd2Ugb2JzZXJ2ZSBhcmUgZ2Fy YmFnZS4NCj4gPg0KPiA+IElzIHRoZXJlIGEgcmVhc29uIHdoeSB3ZSBkbyBub3QNCg0KcmVjb21t ZW5kIHRoYXQgSEVMTyBiZSBjaGVja2VkIG9ubHkNCj4gPiBpZiBNYWlsIEZyb20gZG9lcyBub3Qg cHJvZHVjZSBhIGRlZmluaXRpdmUgcG9saWN5IHJlc3VsdD8NCj4gPg0KPiA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogc3BmYmlzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnNwZmJpcy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnNwZmJpcy1ib3VuY2VzQGlldGYub3Jn XTxtYWlsdG86W21haWx0bzpzcGZiaXMtYm91bmNlc0BpZXRmLm9yZ10+IE9uDQo+ID4gQmVoYWxm IE9mIFNjb3R0IEtpdHRlcm1hbiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDIwLCAyMDEyIDE6NDUg UE0NCj4gPiBUbzogc3BmYmlzQGlldGYub3JnPG1haWx0bzpzcGZiaXNAaWV0Zi5vcmc+DQo+ID4g U3ViamVjdDogW3NwZmJpc10gTmV3IElzc3VlOiBSZXF1aXJlbWVudCB0byBjaGVjayBtYWlsIGZy b20NCj4gPg0KPiA+IFNvcnJ5IGZvciBiZWluZyBsYXRlLiAgSSBmb3Jnb3QgYWJvdXQgdGhpcyBv bmUuDQo+ID4NCj4gPiBQYXJhZ3JhcGggMi4yLCBUaGUgTUFJTCBGUk9NIElkZW50aXR5LCBpbmNs dWRlcyB0aGlzIHN0YXRlbWVudDoNCj4gPiAgICBTUEYgY2xpZW50cyBNVVNUIGNoZWNrIHRoZSAi TUFJTCBGUk9NIiBpZGVudGl0eS4gIFNQRiBjbGllbnRzDQo+ID4gICAgY2hlY2sNCj4gPiAgICB0 aGUgIk1BSUwgRlJPTSIgaWRlbnRpdHkgYnkgYXBwbHlpbmcgdGhlIGNoZWNrX2hvc3QoKSBmdW5j dGlvbiB0bw0KPiA+ICAgIHRoZQ0KPiA+ICAgICJNQUlMIEZST00iIGlkZW50aXR5IGFzIHRoZSA8 c2VuZGVyPi4NCj4gPg0KPiA+IFRoZXJlIGFyZSBhcHBsaWNhdGlvbnMgdGhhdCBjaGVjayBIRUxP IGZpcnN0IGFuZCBjYW4gcmVhY2ggYSBmaW5hbA0KPg0KDQo+IGNvbmNsdXNpb24gYWJvdXQgbWVz c2FnZSBkaXNwb3NpdGlvbiBiYXNlZCBvbiB0aGF0IGNoZWNrLiAgSW4gc3VjaCBhDQo+ID4gY2Fz ZSwgdGhlIE1haWwgRnJvbSBjaGVjayBpcyBhIHdhc3RlIG9mIHJlc291cmNlcy4NCj4gPg0KPiA+ IEknbSByZWNvbW1lbmQgY2hhbmdpbmcgdGhpcyB0byBlaXRoZXI6DQo+ID4NCj4gPiBTUEYgY2xp ZW50cyBNVVNUIGNoZWNrIHRoZSAiTUFJTCBGUk9NIiBpZGVudGl0eSB1bmxlc3MgYSBIRUxPIGNo ZWNrDQo+ID4gaGFzIGFscmVhZHkgcHJvZHVjZWQgYSBkZWZpbml0aXRpdmUgcG9saWN5IHJlc3Vs dC4gLi4uDQo+ID4NCj4gPiBvcg0KPiA+DQo+ID4gU1BGIGNsaWVudHMgU0hPVUxEIGNoZWNrIHRo ZSAiTUFJTCBGUk9NIiBpZGVudGl0eSAoZS5nLiB1bmxlc3MgYQ0KPiA+IEhFTE8gY2hlY2sgaGFz IGFscmVhZHkgcHJvZHVjZWQgYSBkZWZpbml0aXRpdmUgcG9saWN5IHJlc3VsdCkuIC4uLg0KPiA+ DQo+ID4gU2NvdHQgSw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpzcGZi aXMgbWFpbGluZyBsaXN0DQpzcGZiaXNAaWV0Zi5vcmc8bWFpbHRvOnNwZmJpc0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3BmYmlzDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0Kc3BmYmlzIG1haWxpbmcgbGlzdA0Kc3BmYmlz QGlldGYub3JnPG1haWx0bzpzcGZiaXNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NwZmJpcw0KDQoNCg0K --_000_7F7F36E50398F84DBAF25C9D51732F1E204B3307TK5EX14MBXC203r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYg dGhlIHBvbGljeSBpcyB0aGVyZSwgd2XigJlsbCBkbyBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlVubGVzcyB5b3Xi gJlyZSByYWlzaW5nIHRoZSBwb2ludCB0aGF0IEhvdG1haWwgY3VycmVudGx5IGV2YWx1YXRlcyBT ZW5kZXJJRCDigJMgdGhhdCBpcyBjdXJyZW50bHkgc3RpbGwgdHJ1ZSwgaG93ZXZlciBpbiBvcmRl ciB0byBmdWxseSBzdXBwb3J0IERNQVJDIHdlIHdpbGwgYmUNCiBzd2l0Y2hpbmcgdG8gU1BGIGp1 c3QgYXMgc29vbiBhcyBJIGNhbiBtYWtlIGl0IGhhcHBlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB0 aGluayB0aGF0IGNoYW5nZXMgYW55dGhpbmcgdGhvdWdoLCB3ZeKAmWxsIHN0aWxsIGNob29zZSBh IGNvbnNpc3RlbnQgbW9kZWwgZm9yIGV2YWx1YXRpb24gdGhhdCBtYXkgYmUgYmFja3dhcmRzIGZy b20gd2hhdCBpcyBjdXJyZW50bHkgd3JpdHRlbi4gVGhlIGFzc3VtcHRpb25zDQogdW5kZXJseWlu ZyB0aGUgd2F5IGl0IGlzIGN1cnJlbnRseSB3cml0dGVuIGFyZSBpbXBvcnRhbnQgaW5zb2ZhciBh cyB0aGV5IHJlcHJlc2VudCBzb21ldGhpbmcgbm90IGltbWVkaWF0ZWx5IG9idmlvdXMg4oCTIOKA nGNoZWFwZXLigJ0gRE5TIHF1ZXJpZXMgaXMgdGhlIG9ubHkgcmVhc29uIHByb3ZpZGVkIHNvIGZh ciwgYW5kIGluIG15IHVzZSBjYXNlIOKAnEROUyBxdWVyeSBjaGVhcG5lc3PigJ0gaXMgbm90IGEg Y29uY2Vybi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIGJleW9uZCB0aGF0LCBpZiBJIGFsd2F5cyBjaGVjayBNYWls IEZyb20gZmlyc3QgKHdoZW4gcHJlc2VudCkgdGhlbiBzdG9wIGlmIHNhdGlzZmllZCwgd2lsbCB0 aGF0IGNyZWF0ZSBzb21lIG9idmlvdXMgcHJvYmxlbT8gSWYgbm90LCBncmVhdCEgSWYgdGhlcmXi gJlzIGFueQ0KIGRvdWJ0LCBpdCBzaG91bGQgYmUgZXhhbWluZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc3BmYmlzLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpzcGZiaXMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U2Nv dHQgS2l0dGVybWFuPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDIxLCAyMDEy IDM6MjcgQU08YnI+DQo8Yj5Ubzo8L2I+IHNwZmJpc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3NwZmJpc10gTmV3IElzc3VlOiBSZXF1aXJlbWVudCB0byBjaGVjayBtYWlsIGZy b208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPkknbSBleHBlY3RpbmcgeW91IHdvbid0IGRvIHNtdHAgdGlt ZSByZWplY3Rpb24gYmFzZWQgb24gU1BGIHJlc3VsdHMuPGJyPg0KPGJyPg0KU2NvdHQgSzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhdWwgTWlkZ2VuICZsdDs8 YSBocmVmPSJtYWlsdG86cG1pZGdlQG1pY3Jvc29mdC5jb20iPnBtaWRnZUBtaWNyb3NvZnQuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpw cmUtd3JhcDt3b3JkLXdyYXA6YnJlYWstd29yZCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhvdyBkbyB5b3UgbWVhbiAm cXVvdDtub3QgbXkgdXNlIGNhc2UmcXVvdDs/PGJyPjxicj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj5Gcm9tOiA8YSBocmVmPSJtYWlsdG86c3BmYmlzLWJvdW5jZXNAaWV0Zi5vcmciPnNw ZmJpcy1ib3VuY2VzQGlldGYub3JnPC9hPiA8YSBocmVmPSJtYWlsdG86W21haWx0bzpzcGZiaXMt Ym91bmNlc0BpZXRmLm9yZ10iPlttYWlsdG86c3BmYmlzLWJvdW5jZXNAaWV0Zi5vcmddPC9hPiBP biBCZWhhbGYgT2YgU2NvdHQgS2l0dGVybWFuPGJyPlNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjAs IDIwMTIgNzozNCBQTTxicj5UbzogPGEgaHJlZj0ibWFpbHRvOnNwZmJpc0BpZXRmLm9yZyI+c3Bm YmlzQGlldGYub3JnPC9hPjxicj5TdWJqZWN0OiBSZTogW3NwZmJpc10gTmV3IElzc3VlOiBSZXF1 aXJlbWVudCB0byBjaGVjayBtYWlsIGZyb208YnI+PGJyPkFzIGxvbmcgYXMgdGhlIHdvcmtpbmcg Z3JvdXAgc3RheXMgb3V0IG9mIHRyeWluZyB0byBkZWZpbmUgbG9jYWwgcG9saWN5IGJleW9uZCB3 aGF0IDQ0MDggZG9lcywgSSB0aGluayBpdCdzIG5vdCBhIHByb2JsZW0uPGJyPjxicj5JbiBhbnkg Y2FzZSwgSSB0aGluayB0aGF0IHRoZSBIRUxPIGNoZWNrIGZpcnN0IGFwcHJvYWNoIEkgZGVzY3Jp YmVkIG9ubHkgbWFrZXMgc2Vuc2UgaWYgYSBzaXRlIGlzIGRvaW5nIFNQRiBiYXNlZCByZWplY3Rp b24gYXQgU01UUCB0aW1lLCBJIGRvbid0IHRoaW5rIGl0J3MgeW91ciB1c2UgY2FzZS48YnI+PGJy PlNjb3R0IEs8YnI+PGJyPk9uIFR1ZXNkYXksIEZlYnJ1YXJ5IDIxLCAyMDEyIDAzOjMwOjI4IEFN IFBhdWwgTWlkZ2VuIHdyb3RlOjxicj4mZ3Q7IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgZGVm aW5pbmcgdGhlIG1lY2hhbmlzbSBpdHNlbGYsIHRoYXQgaXMgPGJyPiZndDsgcHJvYmFibHkgdGhl IHJpZ2h0IHRoaW5nIHRvIGRvLjxicj4mZ3Q7IDxicj4mZ3Q7IEJ1dDogYXMgYSBsYXJnZS1zY2Fs ZSByZWNlaXZlciwgSSBhbSBsZXNzIGNvbmNlcm5lZCA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwO2Fib3V0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5jb25zZXJ2aW5nIDxicj4mZ3Q7IEROUyBxdWVyaWVzIHRoYW4gZ2V0dGluZyBh IGRlZmluaXRpdmUgYXV0aGVudGljYXRpb24gcmVzdWx0IHRoZSBmaXJzdCA8YnI+Jmd0OyB0aW1l IGF0IGJhdCwgZXNwZWNpYWxseSB3aGVuIHRoYXQgYXV0aGVudGljYXRpb24gcmVzdWx0IHdpbGwg dHJpZ2dlciBhIDxicj4mZ3Q7IG51bWJlciBvZiBzZWNvbmRhcnkgYWN0aW9ucyBhc3NvY2lhdGVk IHdpdGggdGhlIGF1dGhlbnRpY2F0ZWQgaWRlbnRpdHkgPGJyPiZndDsgLSBzdWNoIGFzIHBvc2l0 aXZlIGlkZW50aWZpY2F0aW9uIFVYLCBhdXRoZW50aWNhdGlvbiBwb2xpY3ksIGRvbWFpbiA8YnI+ Jmd0OyByZXB1dGF0aW9uLCBhbmQgc28gb24uPGJyPiZndDsgPGJyPiZndDsgSWYgdGhlIHNwZWMg bGVhdmVzIGl0IHVwIHRvIG1lLCBJIHdpbGwgY2hvb3NlIHRoZSBlbnRpdHkgc3RhdGlzdGljYWxs eSA8YnI+Jmd0OyBtb3N0IGxpa2VseSB0byB5aWVsZCB0aGUgcmVzdWx0IEkgbmVlZC4gSSBqdXN0 IGhvcGUgdGhpcyBmcmVlZG9tIG9mIDxicj4mZ3Q7IGNob2ljZSBkb2Vzbid0IGh1cnQgaW50ZXJv cGVyYWJpbGl0eSBieSBub3QgYmVpbmcgcHJlc2NyaXB0aXZlLjxicj4mZ3Q7IDxicj4mZ3Q7IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOnNw ZmJpcy1ib3VuY2VzQGlldGYub3JnIj5zcGZiaXMtYm91bmNlc0BpZXRmLm9yZzwvYT4gPGEgaHJl Zj0ibWFpbHRvOlttYWlsdG86c3BmYmlzLWJvdW5jZXNAaWV0Zi5vcmddIj5bbWFpbHRvOnNwZmJp cy1ib3VuY2VzQGlldGYub3JnXTwvYT4gT24gPGJyPiZndDsgQmVoYWxmIE9mIFNjb3R0IEtpdHRl cm1hbiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDIwLCAyMDEyIDc6MTUgUE08YnI+Jmd0OyBUbzog PGEgaHJlZj0ibWFpbHRvOnNwZmJpc0BpZXRmLm9yZyI+c3BmYmlzQGlldGYub3JnPC9hPjxicj4m Z3Q7IFN1YmplY3Q6IFJlOiBbc3BmYmlzXSBOZXcgSXNzdWU6IFJlcXVpcmVtZW50IHRvIGNoZWNr IG1haWwgZnJvbTxicj4mZ3Q7IDxicj4mZ3Q7IElmIHlvdSBnZXQgYSBGUUROIEhFTE8gY2hlY2tz IGNhbiBiZSB1c2VmdWwuPGJyPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxicj4mZ3Q7IEdlbmVyYWxseSB0aGUgbW9zdCBjb21wbGV4IEhFTE8gcmVjb3JkIHlv dSdsbCBzZWUgaXMgdj1zcGYxIGEgLWFsbC4mbmJzcDsgPGJyPiZndDsgSW4gbXkgZXhwZXJpZW5j ZSBIRUxPIHJlY29yZHMgYXJlIG11Y2ggbGVzcyBleHBlbnNpdmUgaW4gRE5TIGxvb2tzdXBzLCA8 YnI+Jmd0OyBzbyBldmVuIGlmIGl0J3MgbGVzcyBsaWtlbHkgdG8gYmUgZGVmaW5pdGl2ZSAoaWYg aXQncyBub3QgYSBGUUROLCB5b3UgPGJyPiZndDsganVzdCBkb24ndCBsb29rIGl0IHVwLCBubyBo YXJtIGRvbmUpIGl0J3MgbGVzcyBleHBlbnNpdmUgc28gZG9pbmcgdGhlIDxicj4mZ3Q7IEhFTE8g Y2hlY2sgZmlyc3QgY2FuIGJlIGEgcmVzb3VyY2Ugc2F2ZXIuPGJyPiZndDsgPGJyPiZndDsgVGhl cmUncyBubyBpbnRlcm9wZXJhYmlsaXR5IGJlbmVmaXQgdG8gZG9pbmcgb25lIG9yIHRoZSBvdGhl ciBjaGVjayBmaXJzdC48YnI+Jmd0OyBUaGVyZSdzIGVxdWFsbHkgbm8gcG9pbnQgaW4gdHJ5aW5n IHRvIGluc2lzdCBvbiBzb2Z0d2FyZSBkb2luZyA8YnI+Jmd0OyBhZGRpdGlvbmFsIGNoZWNrcyBv bmNlIGl0IGFscmVhZHkgaGFzIGEgZGVmaW5pdGl2ZSByZXN1bHQuJm5ic3A7IEkgZG9uJ3QgPGJy PiZndDsgdGhpbmsgd2Ugd2FudCB0byBzcGVjaWZ5IGVpdGhlci48YnI+Jmd0OyA8YnI+Jmd0OyBT Y290dCBLPGJyPiZndDsgPGJyPiZndDsgT24gVHVlc2RheSwgRmVicnVhcnkgMjEsIDIwMTIgMDM6 MDg6NDcgQU0gUGF1bCBNaWRnZW4gd3JvdGU6PGJyPiZndDsgJmd0OyBPdXRzaWRlIG9mIHRoZSBj YXNlIHdoZXJlIHRoZSBlbnZlbG9wZSBzZW5kZXIgaXMgZW1wdHkgKGUuZy4gTkRSKSwgPGJyPiZn dDsgJmd0OyBtb3N0IG9mIHRoZSBIRUxPIGRvbWFpbnMgd2Ugb2JzZXJ2ZSBhcmUgZ2FyYmFnZS48 YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgSXMgdGhlcmUgYSByZWFzb24gd2h5IHdlIGRvIG5v dDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cmVjb21tZW5kIHRoYXQg SEVMTyBiZSBjaGVja2VkIG9ubHkgPGJyPiZndDsgJmd0OyBpZiBNYWlsIEZyb20gZG9lcyBub3Qg cHJvZHVjZSBhIGRlZmluaXRpdmUgcG9saWN5IHJlc3VsdD88YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7 ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyAmZ3Q7IEZyb206IDxhIGhy ZWY9Im1haWx0bzpzcGZiaXMtYm91bmNlc0BpZXRmLm9yZyI+c3BmYmlzLWJvdW5jZXNAaWV0Zi5v cmc8L2E+IDxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOnNwZmJpcy1ib3VuY2VzQGlldGYub3JnXSI+ W21haWx0bzpzcGZiaXMtYm91bmNlc0BpZXRmLm9yZ108L2E+IE9uIDxicj4mZ3Q7ICZndDsgQmVo YWxmIE9mIFNjb3R0IEtpdHRlcm1hbiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDIwLCAyMDEyIDE6 NDUgUE08YnI+Jmd0OyAmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86c3BmYmlzQGlldGYub3JnIj5z cGZiaXNAaWV0Zi5vcmc8L2E+PGJyPiZndDsgJmd0OyBTdWJqZWN0OiBbc3BmYmlzXSBOZXcgSXNz dWU6IFJlcXVpcmVtZW50IHRvIGNoZWNrIG1haWwgZnJvbTxicj4mZ3Q7ICZndDsgPGJyPiZndDsg Jmd0OyBTb3JyeSBmb3IgYmVpbmcgbGF0ZS4mbmJzcDsgSSBmb3Jnb3QgYWJvdXQgdGhpcyBvbmUu PGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IFBhcmFncmFwaCAyLjIsIFRoZSBNQUlMIEZST00g SWRlbnRpdHksIGluY2x1ZGVzIHRoaXMgc3RhdGVtZW50Ojxicj4mZ3Q7ICZndDsmbmJzcDsmbmJz cDsmbmJzcDsgU1BGIGNsaWVudHMgTVVTVCBjaGVjayB0aGUgJnF1b3Q7TUFJTCBGUk9NJnF1b3Q7 IGlkZW50aXR5LiZuYnNwOyBTUEYgY2xpZW50czxicj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJz cDsgY2hlY2s8YnI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSAmcXVvdDtNQUlMIEZS T00mcXVvdDsgaWRlbnRpdHkgYnkgYXBwbHlpbmcgdGhlIGNoZWNrX2hvc3QoKSBmdW5jdGlvbiB0 bzxicj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlPGJyPiZndDsgJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyAmcXVvdDtNQUlMIEZST00mcXVvdDsgaWRlbnRpdHkgYXMgdGhlICZsdDtzZW5k ZXImZ3Q7Ljxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBUaGVyZSBhcmUgYXBwbGljYXRpb25z IHRoYXQgY2hlY2sgSEVMTyBmaXJzdCBhbmQgY2FuIHJlYWNoIGEgZmluYWwgPGJyPiZndDs8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jmd0OyBjb25jbHVzaW9uIGFib3V0IG1lc3NhZ2UgZGlzcG9zaXRpb24gYmFzZWQg b24gdGhhdCBjaGVjay4mbmJzcDsgSW4gc3VjaCBhIDxicj4mZ3Q7ICZndDsgY2FzZSwgdGhlIE1h aWwgRnJvbSBjaGVjayBpcyBhIHdhc3RlIG9mIHJlc291cmNlcy48YnI+Jmd0OyAmZ3Q7IDxicj4m Z3Q7ICZndDsgSSdtIHJlY29tbWVuZCBjaGFuZ2luZyB0aGlzIHRvIGVpdGhlcjo8YnI+Jmd0OyAm Z3Q7IDxicj4mZ3Q7ICZndDsgU1BGIGNsaWVudHMgTVVTVCBjaGVjayB0aGUgJnF1b3Q7TUFJTCBG Uk9NJnF1b3Q7IGlkZW50aXR5IHVubGVzcyBhIEhFTE8gY2hlY2sgPGJyPiZndDsgJmd0OyBoYXMg YWxyZWFkeSBwcm9kdWNlZCBhIGRlZmluaXRpdGl2ZSBwb2xpY3kgcmVzdWx0LiAuLi48YnI+Jmd0 OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgb3I8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgU1BGIGNs aWVudHMgU0hPVUxEIGNoZWNrIHRoZSAmcXVvdDtNQUlMIEZST00mcXVvdDsgaWRlbnRpdHkgKGUu Zy4gdW5sZXNzIGEgPGJyPiZndDsgJmd0OyBIRUxPIGNoZWNrIGhhcyBhbHJlYWR5IHByb2R1Y2Vk IGEgZGVmaW5pdGl0aXZlIHBvbGljeSByZXN1bHQpLiAuLi48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7 ICZndDsgU2NvdHQgSzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0idGV4dC1h bGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJj ZW50ZXIiPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGJyPnNwZmJpcyBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOnNwZmJp c0BpZXRmLm9yZyI+c3BmYmlzQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwZmJpcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zcGZiaXM8L2E+PGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGhyIHNpemU9IjIiIHdp ZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 YnI+c3BmYmlzIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86c3BmYmlzQGlldGYub3Jn Ij5zcGZiaXNAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3BmYmlzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NwZmJpczwvYT48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_7F7F36E50398F84DBAF25C9D51732F1E204B3307TK5EX14MBXC203r_-- From spf2@kitterman.com Tue Feb 21 09:12:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2810121F8879 for ; Tue, 21 Feb 2012 09:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 iIqfUeXTDXBy for ; Tue, 21 Feb 2012 09:11:54 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BFD1521F887F for ; Tue, 21 Feb 2012 09:11:53 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C523920E40CC; Tue, 21 Feb 2012 12:11:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329844312; bh=N6Vdrrds3NYOJ0+RGVRtox7I6zMp1AxvvEnForfaR50=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=GFv7l8i56xSoEV/w0oz2657jN78m4eB/0ASq8kqd5Gn5G/WqrIO87Fh8n9mPJeQ4d R6dpw6MFjRgxa/p9oQ0ZPPThgR8ouaL4d0cFckZOXIZ/gv6L68grZYV4X1nb45EwRJ k2sGRZtLCI+hZSJuCManHKagnNmWSDMqtsPxt5L0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A72F920E4099; Tue, 21 Feb 2012 12:11:52 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 21 Feb 2012 12:11:51 -0500 Message-ID: <6019976.Fz5VxMIxC7@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E204B3307@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <0031f8a4-a444-46aa-8f7c-9ab5aff41024@email.android.com> <7F7F36E50398F84DBAF25C9D51732F1E204B3307@TK5EX14MBXC203.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 17:12:00 -0000 I think the checks can be done in either order. I think it's OK to che= ck Mail=20 >From only and just do HELO for Null Mail From. I'm not proposing we sp= ecify=20 more policy, but that we back off a bit from over-specifying a check th= at in=20 some cases will have no value. For DMARC you'll need to go to the end of DATA before you can make a po= licy=20 evaluation to reject, so the consideration I'm bringing up won't come i= nto=20 play. Scott K On Tuesday, February 21, 2012 05:04:30 PM Paul Midgen wrote: > If the policy is there, we=E2=80=99ll do it. >=20 > Unless you=E2=80=99re raising the point that Hotmail currently evalua= tes SenderID =E2=80=93 > that is currently still true, however in order to fully support DMARC= we > will be switching to SPF just as soon as I can make it happen. =20 > I don=E2=80=99t think that changes anything though, we=E2=80=99ll sti= ll choose a consistent > model for evaluation that may be backwards from what is currently wri= tten. > The assumptions underlying the way it is currently written are import= ant > insofar as they represent something not immediately obvious =E2=80=93= =E2=80=9Ccheaper=E2=80=9D DNS > queries is the only reason provided so far, and in my use case =E2=80= =9CDNS query > cheapness=E2=80=9D is not a concern. =20 > So beyond that, if I always check Mail From first (when present) then= stop > if satisfied, will that create some obvious problem? If not, great! I= f > there=E2=80=99s any doubt, it should be examined. =20 > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Beh= alf Of > Scott Kitterman Sent: Tuesday, February 21, 2012 3:27 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] New Issue: Requirement to check mail from >=20 > I'm expecting you won't do smtp time rejection based on SPF results. >=20 > Scott K > Paul Midgen > wrote= : >=20 > How do you mean "not my use case"? >=20 > -----Original Message----- > From: spfbis-bounces@ietf.org > [mailto:spfbis-bounces@ietf.org] > On Behalf Of Scott Kitterman Sent: Monday, February 20, 2012 7:34 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] New Issue: Requirement to check mail from >=20 > As long as the working group stays out of trying to define local poli= cy > beyond what 4408 does, I think it's not a problem. =20 > In any case, I think that the HELO check first approach I described o= nly > makes sense if a site is doing SPF based rejection at SMTP time, I do= n't > think it's your use case. =20 > Scott K >=20 > On Tuesday, February 21, 2012 03:30:28 AM Paul Midgen wrote: >=20 > > From the point of view of defining the mechanism itself, that is > > probably the right thing to do. > > > > > > > > But: as a large-scale receiver, I am less concerned >=20 >=20 > about >=20 > conserving >=20 > > DNS queries than getting a definitive authentication result the fir= st > > time at bat, especially when that authentication result will trigge= r a > > number of secondary actions associated with the authenticated ident= ity > > - such as positive identification UX, authentication policy, domain= > > reputation, and so on. > > > > > > > > If the spec leaves it up to me, I will choose the entity statistica= lly > > most likely to yield the result I need. I just hope this freedom of= > > choice doesn't hurt interoperability by not being prescriptive. > > > > > > > > -----Original Message----- > > From: spfbis-bounces@ietf.org > > [mailto:spfbis-bounces@ietf.org] > ]> On Behalf Of Scott Kitterman Sent: Monday, February 20, 2012 7:15 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] New Issue: Requirement to check mail from > > > > > > > > If you get a FQDN HELO checks can be useful. > > > > >=20 >=20 >=20 > > Generally the most complex HELO record you'll see is v=3Dspf1 a -al= l. > > In my experience HELO records are much less expensive in DNS looksu= ps, > > so even if it's less likely to be definitive (if it's not a FQDN, y= ou > > just don't look it up, no harm done) it's less expensive so doing t= he > > HELO check first can be a resource saver. > > > > > > > > There's no interoperability benefit to doing one or the other check= > > first. There's equally no point in trying to insist on software doing > > additional checks once it already has a definitive result. I don't= > > think we want to specify either. > > > > > > > > Scott K > > > > > > > > On Tuesday, February 21, 2012 03:08:47 AM Paul Midgen wrote: > >=20 > > > Outside of the case where the envelope sender is empty (e.g. NDR)= , > > > most of the HELO domains we observe are garbage. > > > > > > > > > > > > Is there a reason why we do not >=20 >=20 > recommend that HELO be checked only >=20 > > > if Mail From does not produce a definitive policy result? > > > > > > > > > > > > -----Original Message----- > > > From: spfbis-bounces@ietf.org > > > [mailto:spfbis-bounces@ietf.org] > > .org]> On Behalf Of Scott Kitterman Sent: Monday, February 20, 2012 > > > 1:45 PM To: spfbis@ietf.org > > > Subject: [spfbis] New Issue: Requirement to check mail from > > > > > > > > > > > > Sorry for being late. I forgot about this one. > > > > > > > > > > > > Paragraph 2.2, The MAIL FROM Identity, includes this statement: > > >=20 > > > SPF clients MUST check the "MAIL FROM" identity. SPF clients > > > check > > > the "MAIL FROM" identity by applying the check_host() function= > > > to > > > the > > > "MAIL FROM" identity as the . > > > > > > > > > > > > There are applications that check HELO first and can reach a fina= l > > > > >=20 >=20 >=20 > > conclusion about message disposition based on that check. In such = a > >=20 > > > case, the Mail From check is a waste of resources. > > > > > > > > > > > > I'm recommend changing this to either: > > > > > > > > > > > > SPF clients MUST check the "MAIL FROM" identity unless a HELO che= ck > > > has already produced a definititive policy result. ... > > > > > > > > > > > > or > > > > > > > > > > > > SPF clients SHOULD check the "MAIL FROM" identity (e.g. unless a > > > HELO check has already produced a definititive policy result). ..= . > > > > > > > > > > > > Scott K >=20 >=20 > ________________________________ >=20 > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis >=20 >=20 > ________________________________ >=20 > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis >=20 >=20 >=20 From dotzero@gmail.com Tue Feb 21 11:29:29 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2CF21E8057 for ; Tue, 21 Feb 2012 11:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WdvrPlx+r8a for ; Tue, 21 Feb 2012 11:29:25 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6C921F8732 for ; Tue, 21 Feb 2012 11:29:25 -0800 (PST) Received: by dakl33 with SMTP id l33so7539284dak.31 for ; Tue, 21 Feb 2012 11:29:25 -0800 (PST) Received-SPF: pass (google.com: domain of dotzero@gmail.com designates 10.68.218.231 as permitted sender) client-ip=10.68.218.231; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dotzero@gmail.com designates 10.68.218.231 as permitted sender) smtp.mail=dotzero@gmail.com; dkim=pass header.i=dotzero@gmail.com Received: from mr.google.com ([10.68.218.231]) by 10.68.218.231 with SMTP id pj7mr78720320pbc.63.1329852565064 (num_hops = 1); Tue, 21 Feb 2012 11:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rW5VUJ5a/EJ3xSL3QraeiYtrsl78oUzEadTCroQL8mY=; b=rtx23fRuFwxagenF1JsfAiAwB2iZIrEBvVDwZXxfRkL4WTp9WgEZIyWsjvX1xWeuQl OHbwLs/kZlyuYlAYe6+sGzMgF4H8HH9dMRd4620yvDx6V2HH5bI3/4kTcz6Zo26UCEHA e4HYjN8ObUREaCd+6CpB3SfRDH4v19Bejw1fc= MIME-Version: 1.0 Received: by 10.68.218.231 with SMTP id pj7mr64811811pbc.63.1329852564997; Tue, 21 Feb 2012 11:29:24 -0800 (PST) Received: by 10.68.1.137 with HTTP; Tue, 21 Feb 2012 11:29:24 -0800 (PST) In-Reply-To: <4F43A794.2020903@dcrocker.net> References: <4F43A794.2020903@dcrocker.net> Date: Tue, 21 Feb 2012 14:29:24 -0500 Message-ID: From: Dotzero To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" Subject: Re: [spfbis] OT: RFC http://tools.ietf.org/rfc/rfc644.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: Tue, 21 Feb 2012 19:29:30 -0000 On Tue, Feb 21, 2012 at 9:17 AM, Dave CROCKER wrote: > Given the topic of this working group, I thought folks might be intereste= d > in a bit of arcana I just came across: > > > =A0 On the Problem of Signature Authentication for Network Mail > > =A0 B. Thomas, BBN > =A0 RFC 644 > =A0 July 1974 > > =A0 > > This belies the frequent claim that original efforts on email ignored > security. > > d/ > -- Thanks for sharing Dave. An interesting blast from the past. From msk@cloudmark.com Tue Feb 21 14:50:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208B711E80E4 for ; Tue, 21 Feb 2012 14:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmANuX2WwPdV for ; Tue, 21 Feb 2012 14:50:39 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id F108111E80D1 for ; Tue, 21 Feb 2012 14:50:38 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Feb 2012 14:50:38 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 21 Feb 2012 14:50:38 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Tue, 21 Feb 2012 14:50:39 -0800 Thread-Topic: [spfbis] A general cleanup strategy Thread-Index: AczwSw5u5qeD+TvwTla6BWF7jjPyiwAnnSsg Message-ID: References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> <2540299.gmSuznFx9K@scott-latitude-e6320> <4F42C605.9000907@isdg.net> <4F4312EA.9080206@isdg.net> In-Reply-To: <4F4312EA.9080206@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] A general cleanup strategy X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 22:50:40 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Hector Santos > Sent: Monday, February 20, 2012 7:44 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] A general cleanup strategy >=20 > > Do you have a list of these? I couldn't find one. >=20 > Murray, I posted a report to your question in IETF-SMTP. >=20 > http://www.imc.org/ietf-smtp/mail-archive/msg07117.html >=20 > Note, this archive reference does masked out the domain data listed. > So list copy of the submitted message would show the better info. Somehow I never got your message on ietf-smtp. Thanks for the link. As you said over there, it's hard to tell just how much of this is from spa= m clients and how much is from ESPs that are using SUBMITTER because your M= TA offers it. There's no doubt that you're seeing the traffic, but it's un= fortunate that we can't tell which specific clients are doing it. Regardle= ss, I agree that it's unclear whether these are spammers or ESPs. I think = the interesting fact is that there are so few spf2.0/pra records out there = tells me this is indeed opportunistic use of SUBMITTER rather than an indic= ation of intended use of Sender-ID. A survey of MTAs and their spam and virus accuracy plugins has reported tha= t of over 20 MTA solutions that they test, only one implements SUBMITTER. = Surprisingly, that MTA is not MS Exchange. It also raises an interesting procedural question: If we can categorize a t= echnology like SUBMITTER as only ever having been deployed primarily by spa= mmers, how does that figure into the questions of an interoperability repor= t? -MSK From msk@cloudmark.com Tue Feb 21 15:33:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FB221E804E for ; Tue, 21 Feb 2012 15:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf2Mmrt-B12r for ; Tue, 21 Feb 2012 15:33:34 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2B82621E8048 for ; Tue, 21 Feb 2012 15:33:34 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Feb 2012 15:33:33 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 21 Feb 2012 15:33:33 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Tue, 21 Feb 2012 15:33:34 -0800 Thread-Topic: Experiments in progress Thread-Index: Aczw8Tq3I2rwXCsfRiGtwrblUUdlUA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C9A7DE5FEXCHC2corpclo_" MIME-Version: 1.0 Subject: [spfbis] Experiments in progress X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 23:33:35 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DE5FEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just as an update on experiment data collection: I have a report running on domains that publish SPF (TXT and RR, "spf1" and= "spf2.0") records to see if my data agree with Phillip's. Also, John Levi= ne is running some experiments on how many sources are querying his nameser= vers for TXT vs. SPF records. This will give us more in terms of deploymen= t rates, which feeds into both of our deliverables. We'll post our results= when we have them, and I can update my "experiment" draft as well. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7DE5FEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just as an updat= e on experiment data collection:

&n= bsp;

I have a report running on domains that = publish SPF (TXT and RR, “spf1” and “spf2.0”) recor= ds to see if my data agree with Phillip’s.  Also, John Levine is= running some experiments on how many sources are querying his nameservers = for TXT vs. SPF records.  This will give us more in terms of deploymen= t rates, which feeds into both of our deliverables.  We’ll post = our results when we have them, and I can update my “experiment”= draft as well.

 

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DE5FEXCHC2corpclo_-- From dhc2@dcrocker.net Tue Feb 21 15:46:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B7521E805A for ; Tue, 21 Feb 2012 15:46:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxCPz0N1+Yfd for ; Tue, 21 Feb 2012 15:46:22 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D506421E8033 for ; Tue, 21 Feb 2012 15:46:22 -0800 (PST) Received: from [10.101.2.93] (64.1.211.245.ptr.us.xo.net [64.1.211.245]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1LNkGEm024152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Feb 2012 15:46:22 -0800 Message-ID: <4F442CC4.4050701@dcrocker.net> Date: Tue, 21 Feb 2012 15:46:12 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "spfbis@ietf.org" References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2E9A@TK5EX14MBXC203.redmond.corp.microsoft.com> <1587556.qvTAF6dvrE@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2EF8@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E204B2EF8@TK5EX14MBXC203.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 21 Feb 2012 15:46:22 -0800 (PST) Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 23:46:27 -0000 On 2/20/2012 7:30 PM, Paul Midgen wrote: > But: as a large-scale receiver, I am less concerned about conserving DNS queries than getting a definitive authentication result the first time at bat, especially when that authentication result will trigger a number of secondary actions associated with the authenticated identity - such as positive identification UX, authentication policy, domain reputation, and so on. > > If the spec leaves it up to me, I will choose the entity statistically most likely to yield the result I need. I just hope this freedom of choice doesn't hurt interoperability by not being prescriptive. Heuristics are essential for many aspects of practical applications in this space. But they have no place in a protocol standard. Protocols are for interoperability and this requires that both sides of the exchange rely on deterministic behaviors. For the current discussion, that means the protocol needs to strictly dictate one of: 1. Do this one thing 2. Do these two things 3. Do this one thing; if it doesn't work, do this other thing. Specifically: 1. One thing: a) EHLO MUST be checked; MAILFROM MUST be ignored, or b) MAILFROM MUST be checked; EHLO is ignored 2. Two things: EHLO and MAILFROM MUST be checked every time. 3. Sequence a) EHLO MUST be checked first; if it succeeds, you are done; if it fails, MAILFROM MUST then be checked; b) MAILFROM MUST be checked first; if it succeeds, you are done; if it fails, EHLO MUST then be checked Once this validation step is completed, the receiver moves into "local policy" and all sorts of heuristics might come into play, but have nothing to do with the SPF spec. I suggest that the working group should determine the relative values of EHLO and MAILFROM domain checking. If either of them has proved to be sufficiently useless, we should drop it and specify Alternative 1, from above. If they are both deemed essential to retain, we should decide an #2 or #3a or #3b. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Tue Feb 21 15:52:53 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1AD21E8067 for ; Tue, 21 Feb 2012 15:52:53 -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 2xE9NSi9Gkkf for ; Tue, 21 Feb 2012 15:52:49 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3D37121E8033 for ; Tue, 21 Feb 2012 15:52:49 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 60E26D0408D; Tue, 21 Feb 2012 17:52:48 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329868368; bh=SWO0GI1XK6yjnWwfoqnKR0yUhzpzGoYPL04LU9MzHjU=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=MP70BvZuw9qjz2f+ffBfQmKvvc9IxbwaTFVAr1FX9UomC/LEuSuWHkAm7k+8c3f1v pTkD3WlHwgQsmq1J7MM8m6FBdILZsb6T4u0pPRhra08Tyozl8MlX8snlAmLCwub+/h mmOPQzUluQSfdUiS0fEaskuSH1B/Q3TBjif2ooNY= Received: from 154.sub-97-242-180.myvzw.com (154.sub-97-242-180.myvzw.com [97.242.180.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CD2DFD04002; Tue, 21 Feb 2012 17:52:47 -0600 (CST) References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2E9A@TK5EX14MBXC203.redmond.corp.microsoft.com> <1587556.qvTAF6dvrE@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2EF8@TK5EX14MBXC203.redmond.corp.microsoft.com> <4F442CC4.4050701@dcrocker.net> User-Agent: K-9 Mail for Android In-Reply-To: <4F442CC4.4050701@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 21 Feb 2012 18:52:53 -0500 To: "spfbis@ietf.org" Message-ID: <3474124f-0b17-4990-b757-731d760be8cf@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Feb 2012 23:52:53 -0000 Dave CROCKER wrote: > > >On 2/20/2012 7:30 PM, Paul Midgen wrote: >> But: as a large-scale receiver, I am less concerned about conserving >DNS queries than getting a definitive authentication result the first >time at bat, especially when that authentication result will trigger a >number of secondary actions associated with the authenticated identity >- such as positive identification UX, authentication policy, domain >reputation, and so on. >> >> If the spec leaves it up to me, I will choose the entity >statistically most likely to yield the result I need. I just hope this >freedom of choice doesn't hurt interoperability by not being >prescriptive. > > >Heuristics are essential for many aspects of practical applications in >this space. > >But they have no place in a protocol standard. Protocols are for >interoperability and this requires that both sides of the exchange rely >on >deterministic behaviors. > >For the current discussion, that means the protocol needs to strictly >dictate >one of: > > 1. Do this one thing > > 2. Do these two things > > 3. Do this one thing; if it doesn't work, do this other thing. > > >Specifically: > >1. One thing: > > a) EHLO MUST be checked; MAILFROM MUST be ignored, or > > b) MAILFROM MUST be checked; EHLO is ignored > > >2. Two things: > > EHLO and MAILFROM MUST be checked every time. > > >3. Sequence > >a) EHLO MUST be checked first; if it succeeds, you are done; if it >fails, >MAILFROM MUST then be checked; > >b) MAILFROM MUST be checked first; if it succeeds, you are done; if it >fails, EHLO MUST then be checked > > >Once this validation step is completed, the receiver moves into "local >policy" >and all sorts of heuristics might come into play, but have nothing to >do with >the SPF spec. > >I suggest that the working group should determine the relative values >of EHLO >and MAILFROM domain checking. If either of them has proved to be >sufficiently >useless, we should drop it and specify Alternative 1, from above. > >If they are both deemed essential to retain, we should decide an #2 or >#3a or #3b. There's no interoperability benefit to adding this complexity to the specified requirements. Scott K From dhc2@dcrocker.net Tue Feb 21 16:21:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35ACE21F8878 for ; Tue, 21 Feb 2012 16:21:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bz4P224YEqNo for ; Tue, 21 Feb 2012 16:21:11 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0484021F886E for ; Tue, 21 Feb 2012 16:21:11 -0800 (PST) Received: from [10.101.2.93] (64.1.211.245.ptr.us.xo.net [64.1.211.245]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1M0L4Tl024929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Feb 2012 16:21:10 -0800 Message-ID: <4F4434EC.2000101@dcrocker.net> Date: Tue, 21 Feb 2012 16:21:00 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2E9A@TK5EX14MBXC203.redmond.corp.microsoft.com> <1587556.qvTAF6dvrE@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2EF8@TK5EX14MBXC203.redmond.corp.microsoft.com> <4F442CC4.4050701@dcrocker.net> <3474124f-0b17-4990-b757-731d760be8cf@email.android.com> In-Reply-To: <3474124f-0b17-4990-b757-731d760be8cf@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]); Tue, 21 Feb 2012 16:21:10 -0800 (PST) Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 00:21:17 -0000 On 2/21/2012 3:52 PM, Scott Kitterman wrote: > There's no interoperability benefit to adding this complexity to the specified requirements. Perhaps I wasn't clear that I was describing an exercise to /reduce/ the ambiguity and complexity currently in the spec? The exercise is to have the spec contain only /one/ of the choices I outlined. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From john@jlc.net Tue Feb 21 16:23:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348DF21F889B for ; Tue, 21 Feb 2012 16:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.388 X-Spam-Level: X-Spam-Status: No, score=-106.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otppjckIStk3 for ; Tue, 21 Feb 2012 16:23:20 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 41AEE21E801A for ; Tue, 21 Feb 2012 16:23:18 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 898BA33C24; Tue, 21 Feb 2012 19:23:18 -0500 (EST) Date: Tue, 21 Feb 2012 19:23:18 -0500 From: John Leslie To: Scott Kitterman Message-ID: <20120222002318.GE3406@verdi> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <1587556.qvTAF6dvrE@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2EF8@TK5EX14MBXC203.redmond.corp.microsoft.com> <4044511.bhIdl0R2eS@scott-latitude-e6320> <7F7F36E50398F84DBAF25C9D51732F1E204B2FEA@TK5EX14MBXC203.redmond.corp.microsoft.com> <0031f8a4-a444-46aa-8f7c-9ab5aff41024@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0031f8a4-a444-46aa-8f7c-9ab5aff41024@email.android.com> User-Agent: Mutt/1.4.1i Cc: "spfbis@ietf.org" Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 00:23:21 -0000 Scott Kitterman wrote: > > I'm expecting you won't do smtp time rejection based on SPF results. (I hope I'm taking this out of context!) This scares me. MAIL-FROM checks that return "This domain never sends email" certainly _should_ lead to SMTP-time rejects. Otherwise you're almost guaranteeing that any later problems will cause black-holing the email (and complicating the resolution of honest problems). (What happens in lesser cases of SPF result on MAIL-FROM seems to be an open issue which I would like to see discussed on this list.) -- John Leslie From spf2@kitterman.com Tue Feb 21 16:30:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB6E21F8732 for ; Tue, 21 Feb 2012 16:30: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 pjKyqrS-rSRL for ; Tue, 21 Feb 2012 16:30:02 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E91FD21F86F2 for ; Tue, 21 Feb 2012 16:29:56 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2500720E40CC; Tue, 21 Feb 2012 19:29:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329870596; bh=b2qw2OCSLwiuFJgaWKd4XPRk01eIFYIdWf6nz2njzNA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=FCMRrbBa0huyCSUKn39hqW02ETb3Z+/U21Z69Xg0UEvRuAqs5RzXjYPeUgDiT77+k uZeAZqrqEe74cCG3m8shjnrIrJzEyINpKNzWig06oHb9GSYYCVmvSqlMCMfrQiatjo mKu+dFUQccb2h2iBBYRq2i+DC7Whsf7Zmewp/OxQ= Received: from scott-latitude-e6320.localnet (140.239.105.162.ptr.us.xo.net [140.239.105.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D9DB920E4099; Tue, 21 Feb 2012 19:29:55 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 21 Feb 2012 19:29:48 -0500 Message-ID: <1696683.8Vzz03ho5d@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120222002318.GE3406@verdi> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <0031f8a4-a444-46aa-8f7c-9ab5aff41024@email.android.com> <20120222002318.GE3406@verdi> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 00:30:03 -0000 On Tuesday, February 21, 2012 07:23:18 PM John Leslie wrote: > Scott Kitterman wrote: > > I'm expecting you won't do smtp time rejection based on SPF results. > > (I hope I'm taking this out of context!) > > This scares me. > > MAIL-FROM checks that return "This domain never sends email" certainly > _should_ lead to SMTP-time rejects. Otherwise you're almost guaranteeing > that any later problems will cause black-holing the email (and complicating > the resolution of honest problems). > > (What happens in lesser cases of SPF result on MAIL-FROM seems to be > an open issue which I would like to see discussed on this list.) The 'you' in this case was limited to Hotmail. I know they are planning on supporting DMARC (see dmarc.org) so they will need both SPF and DKIM results to reach a policy decision. That means they need to get to the end of DATA. I agree with you in the general case, although I think we need to be careful not to specify too much about required receiver policy in 4408bis. Once 4408bis is done though, I think it would be beneficial to recharter for a BCP or AS deliverable to get more into such recommendations. Scott K From spf2@kitterman.com Tue Feb 21 16:33:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53F121E8013 for ; Tue, 21 Feb 2012 16:33:50 -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 3QqOnmDHBbrf for ; Tue, 21 Feb 2012 16:33:50 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E906F21F8427 for ; Tue, 21 Feb 2012 16:33:49 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7DD9820E40CC; Tue, 21 Feb 2012 19:33:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329870829; bh=zh3EAYZGi6Zeg6195T4bx6UqrWt4tmoda3QixnoMKRY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=B/Z2VbRpBApHYE/LT/L9YE73J2FybFtICZwbGrvrMeE4uWb6rYDEGfuV8WrJMjOO0 nq4nxqJqr8rkTvfVUece881S0fqLSf2+6DINC2Ag/ecQxvL3w4PM4/rSGDnO2kS8YA GeR+yVKQcp4aP4kIoE1cu14L6wX1IeSuKleSBANc= Received: from scott-latitude-e6320.localnet (140.239.105.162.ptr.us.xo.net [140.239.105.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 483A720E4099; Tue, 21 Feb 2012 19:33:49 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 21 Feb 2012 19:33:47 -0500 Message-ID: <2356334.hRHxVFBgpV@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F4434EC.2000101@dcrocker.net> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <3474124f-0b17-4990-b757-731d760be8cf@email.android.com> <4F4434EC.2000101@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 00:33:51 -0000 On Tuesday, February 21, 2012 04:21:00 PM Dave CROCKER wrote: > On 2/21/2012 3:52 PM, Scott Kitterman wrote: > > There's no interoperability benefit to adding this complexity to the > > specified requirements. > Perhaps I wasn't clear that I was describing an exercise to /reduce/ the > ambiguity and complexity currently in the spec? > > The exercise is to have the spec contain only /one/ of the choices I > outlined. I understood that. That's the opposite direction of what I was trying to go with this issue. I am assuming that we are not moving away from RFC 4408's perspective that recevier policy should generally not be specified. Given that we aren't doing to specify what to do with SPF results, there's no benefit to specifying processing order. RFC 4408 specifies that one SHOULD check HELO and MUST check Mail From. If a HELO result is dispositive then the Mail From result is pointless. Doing it doesn't help interoperability, it's just a waste of resources. Whether doing 3a or 3b (or any of your other options) makes the most sense is a function of receiver policy. There is also 4: Only check HELO if Mail From is Null. I don't think trying to hard code any of these choices into 4408bis is helpful. In SPF terms I think interoperabliity is defined in terms of "If I publish record A and send mail from server B, receivers will get SPF result C". How receivers use that result is not something we should take on. Scott K Scott K From dhc2@dcrocker.net Tue Feb 21 16:54:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F6221F85C3 for ; Tue, 21 Feb 2012 16:54:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5MudCNJb-99 for ; Tue, 21 Feb 2012 16:53:56 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D0E6421E801E for ; Tue, 21 Feb 2012 16:53:54 -0800 (PST) Received: from [10.101.2.93] (64.1.211.245.ptr.us.xo.net [64.1.211.245]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1M0rm3V025541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 16:53:54 -0800 Message-ID: <4F443C98.2070905@dcrocker.net> Date: Tue, 21 Feb 2012 16:53:44 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Scott Kitterman References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <3474124f-0b17-4990-b757-731d760be8cf@email.android.com> <4F4434EC.2000101@dcrocker.net> <2356334.hRHxVFBgpV@scott-latitude-e6320> In-Reply-To: <2356334.hRHxVFBgpV@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 21 Feb 2012 16:53:54 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 00:54:01 -0000 On 2/21/2012 4:33 PM, Scott Kitterman wrote: > On Tuesday, February 21, 2012 04:21:00 PM Dave CROCKER wrote: >> The exercise is to have the spec contain only /one/ of the choices I >> outlined. > > I understood that. > > That's the opposite direction of what I was trying to go with this issue. > I am assuming that we are not moving away from RFC 4408's perspective that > recevier policy should generally not be specified. Given that we aren't doing > to specify what to do with SPF results, there's no benefit to specifying > processing order. And nothing I am proposing disagrees with that... policy. What I am proposed is to clarify and refine those SPF results. Random choices about processing order can produce differing assessments of the objective, authentication information. That's a definition of non-interoperability. SPF publishers need to know how their records will be interpreted, at the validation level. This is quite different from the next layer up, where the validated information is used -- and, yes, subject to receiver-side local poliy and no, not known to the publisher. > RFC 4408 specifies that one SHOULD check HELO and MUST check Mail From. If a > HELO result is dispositive then the Mail From result is pointless. Doing it > doesn't help interoperability, it's just a waste of resources. We were just given data to suggest that checking the EHLO is a waste of effort. If it is a waste, we should drop it. The current requirements of the specification means that the client SMTP cannot know what the basic validation will be. We need to remove that non-determinacy. > Whether doing 3a or 3b (or any of your other options) makes the most sense is > a function of receiver policy. So you think it is ok that the basic validation results will vary depending upon the whims of the receiver? > There is also 4: Only check HELO if Mail From > is Null. I don't think trying to hard code any of these choices into 4408bis > is helpful. I mean this to be covered by 3b. > In SPF terms I think interoperabliity is defined in terms of "If I publish > record A and send mail from server B, receivers will get SPF result C". How > receivers use that result is not something we should take on. We agree on that goal. Where we seem to be disagreeing is on the fact that letting the receiver decide what fields to validate makes result C unpredictable. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From john@jlc.net Tue Feb 21 16:58:04 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7960C21E801E for ; Tue, 21 Feb 2012 16:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.393 X-Spam-Level: X-Spam-Status: No, score=-106.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTxWm1EuWik1 for ; Tue, 21 Feb 2012 16:58:00 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id E23E521E804F for ; Tue, 21 Feb 2012 16:57:59 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 12C5D33C23; Tue, 21 Feb 2012 19:58:00 -0500 (EST) Date: Tue, 21 Feb 2012 19:58:00 -0500 From: John Leslie To: Scott Kitterman Message-ID: <20120222005800.GF3406@verdi> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <0031f8a4-a444-46aa-8f7c-9ab5aff41024@email.android.com> <20120222002318.GE3406@verdi> <1696683.8Vzz03ho5d@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1696683.8Vzz03ho5d@scott-latitude-e6320> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 00:58:04 -0000 Scott Kitterman wrote: > On Tuesday, February 21, 2012 07:23:18 PM John Leslie wrote: >> Scott Kitterman wrote: >> >>> I'm expecting you won't do smtp time rejection based on SPF results. >> >> (I hope I'm taking this out of context!) >> >> This scares me. >> >> MAIL-FROM checks that return "This domain never sends email" certainly >> _should_ lead to SMTP-time rejects. Otherwise you're almost guaranteeing >> that any later problems will cause black-holing the email (and complicating >> the resolution of honest problems). > > The 'you' in this case was limited to Hotmail. I know they are planning on > supporting DMARC (see dmarc.org) so they will need both SPF and DKIM results > to reach a policy decision. That means they need to get to the end of DATA. The proper context _does_ help... But I fail to grok why hotmail shouldn't do an SMTP-time reject for MAIL-FROM that returns SPF "This domain never sends email." Usless I misunderstand DMARC, it is based off of a DNS lookup based on a From: header (in the DATA) -- which of course will often return nothing at all. >> (What happens in lesser cases of SPF result on MAIL-FROM seems to be >> an open issue which I would like to see discussed on this list.) > > I agree with you in the general case, although I think we need to be > careful not to specify too much about required receiver policy in 4408bis. I also dislike "required receiver policy"; but we should be able to discuss "meaning" of SPF records without requiring a particular policy; and we should be able to highlight SPF's strength at reducing the blowback/blackhole problem. > Once 4408bis is done though, I think it would be beneficial to recharter > for a BCP or AS deliverable to get more into such recommendations. It feels premature to me to assume that we can produce a good BCP after the fact without laying the basis in the Proposed Standard. -- John Leslie From dotis@mail-abuse.org Tue Feb 21 17:11:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDA021F876E for ; Tue, 21 Feb 2012 17:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 9OZ7h9SyeGKO for ; Tue, 21 Feb 2012 17:11:29 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id BAEE621F8763 for ; Tue, 21 Feb 2012 17:11:28 -0800 (PST) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id B159D17404F5 for ; Wed, 22 Feb 2012 01:11:27 +0000 (UTC) Message-ID: <4F4440BF.7060600@mail-abuse.org> Date: Tue, 21 Feb 2012 17:11:27 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3D8640.9090300@mail-abuse.org> <20120216231603.GV29243@mail.yitter.info> <4F3DBC2F.7080004@mail-abuse.org> <0FA62C5E-9C62-45C2-B206-3EDA175FD9F5@anvilwalrusden.com> In-Reply-To: <0FA62C5E-9C62-45C2-B206-3EDA175FD9F5@anvilwalrusden.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] RFC 4408 issue Reasonable DNS error limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 01:11:31 -0000 On 2/16/12 6:41 PM, Andrew Sullivan wrote: > No, no need for different mails. I'll take this as agreement. Dear Andrew, Sorry for the delay, but where is addressing excessive No Data or Name errors listed in the issues tracker? The issue of squelching subsequent TXT or SPF record queries is only part of an amplification concern. Should I resubmit these issues separately? Regards, Douglas Otis From pmidge@microsoft.com Tue Feb 21 17:24:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E2B21F8747 for ; Tue, 21 Feb 2012 17:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.527 X-Spam-Level: X-Spam-Status: No, score=-5.527 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yU5yPJyXLhJl for ; Tue, 21 Feb 2012 17:24:49 -0800 (PST) Received: from TX2EHSOBE006.bigfish.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id CD44421F8742 for ; Tue, 21 Feb 2012 17:24:47 -0800 (PST) Received: from mail10-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 22 Feb 2012 01:24:42 +0000 Received: from mail10-tx2 (localhost [127.0.0.1]) by mail10-tx2-R.bigfish.com (Postfix) with ESMTP id 43C6E3E03C1; Wed, 22 Feb 2012 01:24:42 +0000 (UTC) X-SpamScore: -40 X-BigFish: VS-40(zz9371I542M1432N98dKc1dMzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail10-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail10-tx2 (localhost.localdomain [127.0.0.1]) by mail10-tx2 (MessageSwitch) id 132987388184723_23800; Wed, 22 Feb 2012 01:24:41 +0000 (UTC) Received: from TX2EHSMHS017.bigfish.com (unknown [10.9.14.239]) by mail10-tx2.bigfish.com (Postfix) with ESMTP id 0F6DC380049; Wed, 22 Feb 2012 01:24:41 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS017.bigfish.com (10.9.99.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 22 Feb 2012 01:24:40 +0000 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.110]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0247.005; Wed, 22 Feb 2012 01:24:44 +0000 From: Paul Midgen To: Scott Kitterman , "spfbis@ietf.org" Thread-Topic: [spfbis] New Issue: Requirement to check mail from Thread-Index: AQHM8Bj0qTVnAEkFu0GZXRvXVtsCYJZGq3jAgAACNwCAAAB3EIAAiu8A//+u2RCAAE8+AIAA2PsAgAAB0QCAAA5C4A== Date: Wed, 22 Feb 2012 01:24:43 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204B3A50@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <0031f8a4-a444-46aa-8f7c-9ab5aff41024@email.android.com> <20120222002318.GE3406@verdi> <1696683.8Vzz03ho5d@scott-latitude-e6320> In-Reply-To: <1696683.8Vzz03ho5d@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 01:24:50 -0000 SPF evaluation at Hotmail will not be limited to domains publishing a DMARC= record. Domains publishing an SPF record but not supplying a DKIM signatur= e or publishing a DMARC record will simply be evaluated per SPF(bis) as one= would expect. -p -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Scott Kitterman Sent: Tuesday, February 21, 2012 4:30 PM To: spfbis@ietf.org Subject: Re: [spfbis] New Issue: Requirement to check mail from On Tuesday, February 21, 2012 07:23:18 PM John Leslie wrote: > Scott Kitterman wrote: > > I'm expecting you won't do smtp time rejection based on SPF results. >=20 > (I hope I'm taking this out of context!) >=20 > This scares me. >=20 > MAIL-FROM checks that return "This domain never sends email"=20 > certainly _should_ lead to SMTP-time rejects. Otherwise you're almost=20 > guaranteeing that any later problems will cause black-holing the email=20 > (and complicating the resolution of honest problems). >=20 > (What happens in lesser cases of SPF result on MAIL-FROM seems to=20 > be an open issue which I would like to see discussed on this list.) The 'you' in this case was limited to Hotmail. I know they are planning on= supporting DMARC (see dmarc.org) so they will need both SPF and DKIM resul= ts to reach a policy decision. That means they need to get to the end of D= ATA. I agree with you in the general case, although I think we need to be carefu= l not to specify too much about required receiver policy in 4408bis. Once = 4408bis is done though, I think it would be beneficial to recharter for a B= CP or AS deliverable to get more into such recommendations. Scott K _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From pmidge@microsoft.com Tue Feb 21 17:36:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B4721E8016 for ; Tue, 21 Feb 2012 17:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[AWL=0.938, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7qZcz816I52 for ; Tue, 21 Feb 2012 17:36:07 -0800 (PST) Received: from TX2EHSOBE007.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id BDA6621E800C for ; Tue, 21 Feb 2012 17:36:07 -0800 (PST) Received: from mail121-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Wed, 22 Feb 2012 01:36:02 +0000 Received: from mail121-tx2 (localhost [127.0.0.1]) by mail121-tx2-R.bigfish.com (Postfix) with ESMTP id 2E87E2028A; Wed, 22 Feb 2012 01:36:02 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzz8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail121-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail121-tx2 (localhost.localdomain [127.0.0.1]) by mail121-tx2 (MessageSwitch) id 132987456079860_7603; Wed, 22 Feb 2012 01:36:00 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.240]) by mail121-tx2.bigfish.com (Postfix) with ESMTP id 0DABD3A004C; Wed, 22 Feb 2012 01:36:00 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 22 Feb 2012 01:35:58 +0000 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.110]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0247.005; Wed, 22 Feb 2012 01:36:02 +0000 From: Paul Midgen To: John Leslie , Scott Kitterman Thread-Topic: [spfbis] New Issue: Requirement to check mail from Thread-Index: AQHM8Bj0qTVnAEkFu0GZXRvXVtsCYJZGq3jAgAACNwCAAAB3EIAAiu8A//+u2RCAAE8+AIAA2PsAgAAB0QCAAAfhAIAACLGQ Date: Wed, 22 Feb 2012 01:36:01 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204B3A75@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <0031f8a4-a444-46aa-8f7c-9ab5aff41024@email.android.com> <20120222002318.GE3406@verdi> <1696683.8Vzz03ho5d@scott-latitude-e6320> <20120222005800.GF3406@verdi> In-Reply-To: <20120222005800.GF3406@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "spfbis@ietf.org" Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 01:36:08 -0000 > Unless I misunderstand DMARC, it is based off of a DNS lookup based on a = From: header (in the DATA) --=20 > which of course will often return nothing at all. Correction (and clearly outside the scope of this list): Unless you are referring to *where* the _dmarc record is found, the underly= ing authentication mechanisms are operated as they normally would. - SPF using the RFC5321.MailFrom - DKIM using d=3D Producing as many results as the receiver cares to check signatures and ide= ntities. DMARC selects only the SPF/DKIM results associated with an identit= y that aligns to the RFC5322.From domain as configured in the sender's DMAR= C record. Those interested can refer to: http://dmarc.org/draft-dmarc-base-00-01.txt -p From john@jlc.net Tue Feb 21 17:56:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C1421F88CA for ; Tue, 21 Feb 2012 17:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.398 X-Spam-Level: X-Spam-Status: No, score=-106.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Urdsvo0D58pg for ; Tue, 21 Feb 2012 17:56:51 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7118121F88BC for ; Tue, 21 Feb 2012 17:56:46 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id D47E433C23; Tue, 21 Feb 2012 20:56:46 -0500 (EST) Date: Tue, 21 Feb 2012 20:56:46 -0500 From: John Leslie To: dcrocker@bbiw.net Message-ID: <20120222015646.GG3406@verdi> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <3474124f-0b17-4990-b757-731d760be8cf@email.android.com> <4F4434EC.2000101@dcrocker.net> <2356334.hRHxVFBgpV@scott-latitude-e6320> <4F443C98.2070905@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F443C98.2070905@dcrocker.net> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 01:56:52 -0000 Dave CROCKER wrote: > On 2/21/2012 4:33 PM, Scott Kitterman wrote: >> On Tuesday, February 21, 2012 04:21:00 PM Dave CROCKER wrote: >> >>> The exercise is to have the spec contain only /one/ of the choices I >>> outlined. I think I smell straw... ;^) >> I am assuming that we are not moving away from RFC 4408's perspective >> that recevier policy should generally not be specified. Given that we >> aren't doing to specify what to do with SPF results, there's no benefit >> to specifying processing order. I agree. > What I am proposed is to clarify and refine those SPF results. ... which would be commendable -- but it's hard to read Dave to actually _say_ anything about that. > Random choices about processing order can produce differing assessments > of the objective, authentication information. That's a definition of > non-interoperability. No, actually, processing order has little or nothing to do with the final result unless actions to be taken are required in real-time. > SPF publishers need to know how their records will be interpreted, at the > validation level. This is quite different from the next layer up, where > the validated information is used -- and, yes, subject to receiver-side > local poliy and no, not known to the publisher. I know Dave understands the distinction between EHLO and MAIL-FROM, because he and I talked about it at length during MARID. But let me state a difference for the rest of our readers: - EHLO SPF results give an authentication of the EHLO string (or not) - MAIL-FROM SPF results give an assurance that NDN responses are appropriate (or not, or maybe) Neither of these gives any assurance that what will be visible to the eventual reader is valid. EHLO results give a basis for a reputation query which Dave and I used to agree was more useful than the IP address of the sending SMTP client. MAIL-FROM results give an assurance that returning NDNs _after_ SMTP time is appropriate. The order in which these are done matters little. I would do the EHLO query at the time I get the EHLO (and proceed with a reputation check), and the MAIL-FROM check when I receive the MAIL-FROM (in hopes that it would show no danger of blowback/blackhole). If I get a useful reputation response (quite outside the SPF spec!) I might return a "Get thee behind me, spammer!" result during the SMTP session. If I get a "this domain never sends email", I'd return a policy error during the SMTP session. Dave sounds as if he's claiming that which of these comes first should be required in an SPF spec: I think that's silly. Other folks want to remove the EHLO check entirely because it's not useful to them yet. While this isn't "silly", it is ill-advised IMHO. >> RFC 4408 specifies that one SHOULD check HELO and MUST check Mail From. >> If a HELO result is dispositive then the Mail From result is pointless. Scott ignores timing issues. And, of course, the EHLO result is rather seldom clearly "dispositive". >> Doing it doesn't help interoperability, it's just a waste of resources. It's a waste of DNS resources in the few cases where the results of an EHLO SPF check are available before a MAIL-FROM SPF check can be started. That feels rare to me, and optimizing for rare cases in a Proposed Standard isn't usually a good idea. > We were just given data to suggest that checking the EHLO is a waste of > effort. > > If it is a waste, we should drop it. No -- we should leave that option for future users of SPF to judge. We can reasonably argue whether an EHLO SPF check should be MUST, SHOULD, or MAY; but there's no justification to go to MUST NOT. > The current requirements of the specification means that the client SMTP > cannot know what the basic validation will be. We need to remove that > non-determinacy. I don't understand that statement. (Neither EHLO nor MAIL-FROM give a final validation in the "ordinary" case.) >> Whether doing 3a or 3b (or any of your other options) makes the most >> sense is a function of receiver policy. > > So you think it is ok that the basic validation results will vary > depending upon the whims of the receiver? I've given up tilting at such windmills. >> There is also 4: Only check HELO if Mail From is Null. I don't think >> trying to hard code any of these choices into 4408bis is helpful. I agree. >> In SPF terms I think interoperabliity is defined in terms of "If I >> publish record A and send mail from server B, receivers will get >> SPF result C". s/will/may/ We can't force receivers to even initiate the checks, least of all to receive and act on the results. >> How receivers use that result is not something we should take on. > > We agree on that goal. (What are we arguing about then?) > Where we seem to be disagreeing is on the fact that letting the receiver > decide what fields to validate makes result C unpredictable. There are so many other sources of unpredictability that I decline to get worked up over that one. -- John Leslie From dotis@mail-abuse.org Tue Feb 21 18:45:53 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6D821E800F for ; Tue, 21 Feb 2012 18:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 XuudJqANsGad for ; Tue, 21 Feb 2012 18:45:51 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id C1E5F21E8033 for ; Tue, 21 Feb 2012 18:45:51 -0800 (PST) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 7E50E17400BA for ; Wed, 22 Feb 2012 02:45:51 +0000 (UTC) Message-ID: <4F4456DF.9040500@mail-abuse.org> Date: Tue, 21 Feb 2012 18:45:51 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3D8640.9090300@mail-abuse.org> <20120216231603.GV29243@mail.yitter.info> <4F3DBC2F.7080004@mail-abuse.org> <0FA62C5E-9C62-45C2-B206-3EDA175FD9F5@anvilwalrusden.com> <4F4440BF.7060600@mail-abuse.org> In-Reply-To: <4F4440BF.7060600@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] RFC 4408 issue Reasonable DNS error limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 02:45:53 -0000 On 2/21/12 5:11 PM, Douglas Otis wrote: > On 2/16/12 6:41 PM, Andrew Sullivan wrote: >> No, no need for different mails. I'll take this as agreement. > Dear Andrew, > > Sorry for the delay, but where is addressing excessive No Data or Name > errors listed in the issues tracker? > > The issue of squelching subsequent TXT or SPF record queries is only > part of an amplification concern. > > Should I resubmit these issues separately? Dear Andrew, Perhaps further clarification was needed. 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. Regards, Douglas Otis From sm@elandsys.com Tue Feb 21 19:01:29 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C52221F8890 for ; Tue, 21 Feb 2012 19:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.647 X-Spam-Level: X-Spam-Status: No, score=-102.647 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 TC5OARckh5LU for ; Tue, 21 Feb 2012 19:01:27 -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 4A7E121F8881 for ; Tue, 21 Feb 2012 19:01:27 -0800 (PST) Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1M31HZE008410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 19:01:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329879684; i=@elandsys.com; bh=JacdYQrEBm+w/NLRt0h5mfXvx0HsmKsSiRnDnCDqZSQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=FavwMl5+XE5TO6QaBUugDt9l7pxMKS65uzP0aHCfyeWTWeFa0HsY57mjMT10xnKmx B3GtrvXtIiJMnANl2H31PqLPPfHBppPsr72m81D1fyR/u/nFqB1m0mUfH+VvbKQJhT DlO8AnGevYosa5UdNisCRl7AIdT7mJfobv2/Lcns= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329879684; i=@elandsys.com; bh=JacdYQrEBm+w/NLRt0h5mfXvx0HsmKsSiRnDnCDqZSQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=a+CpKTET3MRBtWSmhMWcbGQeT4CCebQE90w2XuHMRpsajVWA/49kdsotr+9t9C2SB JNsMj1iF9stJMdaJn2+rDlmWQBBdPQNM8MY8Ux9jCSshognKqJu3770s/RKYQVI1Ag MVtvoJymplfRItsgBWYVrP4HkeHLGnJsFv4N4UFI= Message-Id: <6.2.5.6.2.20120221185905.0a104cc8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 21 Feb 2012 19:01:14 -0800 To: Douglas Otis From: S Moonesamy In-Reply-To: <4F4456DF.9040500@mail-abuse.org> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F3D8640.9090300@mail-abuse.org> <20120216231603.GV29243@mail.yitter.info> <4F3DBC2F.7080004@mail-abuse.org> <0FA62C5E-9C62-45C2-B206-3EDA175FD9F5@anvilwalrusden.com> <4F4440BF.7060600@mail-abuse.org> <4F4456DF.9040500@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 issue Reasonable DNS error limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 03:01:29 -0000 Hi Doug, At 18:45 21-02-2012, Douglas Otis wrote: >Perhaps further clarification was needed. Each of 10 SPF mechanisms >may require 10 This is being tracked as Issue #24. Regards, S. Moonesamy From spf2@kitterman.com Tue Feb 21 20:29:34 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F51121E804A for ; Tue, 21 Feb 2012 20:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 UVloza0PF+KG for ; Tue, 21 Feb 2012 20:29:33 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6F01821F867A for ; Tue, 21 Feb 2012 20:29:19 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B77AD20E40CC; Tue, 21 Feb 2012 23:29:18 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329884958; bh=JhijS9hVSG+oynKSVcL3mcD34moofmd4SahhE/+tZ7Y=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=I/MvhJQ7gMIAaQTr73KUhK2R9g8TBzxU7zebZHINiPCifRlJcSFwXtlZZKDuMA5SG CmrL4vlDl/qo/YMipIPJVnpj5SRRJgfjXH1jl4wpiWGPt9GAdgwwrCbhNOsd0UnDWA ZHubu7jai609XBNELE1H5l1d6IBjOsDJwH00zzBA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9866020E4099; Tue, 21 Feb 2012 23:29:18 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 21 Feb 2012 23:29:17 -0500 Message-ID: <1547162.dq6EdtT5Jz@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F4456DF.9040500@mail-abuse.org> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F4440BF.7060600@mail-abuse.org> <4F4456DF.9040500@mail-abuse.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] RFC 4408 issue Reasonable DNS error limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 04:29:34 -0000 On Tuesday, February 21, 2012 06:45:51 PM Douglas Otis wrote: > This risk can be significantly mitigated by simply > imposing reasonable No Data limits. This or something very similar is implemented in the Mail::SPF Perl module as max_void_dns_lookups. From the Mail::SPF documentation: An I denoting the maximum number of "void" DNS look-ups per SPF check, i.e. the number of DNS look-ups that were caused by DNS-interactive terms and macros (as defined in RFC 4408, 10.1, paragraphs 6 and 7) and that are allowed to return an empty answer with RCODE 0 or RCODE 3 (C) before processing is aborted with a C result. If B is specified, there is no stricter limit on the number of void DNS look-ups beyond the usual processing limits. Defaults to B<2>. Specifically, the DNS look-ups that are subject to this limit are those caused by the C, C, C, and C mechanisms and the C

macro. A value of B<2> is likely to prevent effective DoS attacks against third-party victim domains. However, a definite limit may cause C results even with certain (overly complex) innocent sender policies where useful results would normally be returned. Scott K From spf2@kitterman.com Tue Feb 21 20:53:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771B921F88CA for ; Tue, 21 Feb 2012 20:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 pAsi8ePonzeI for ; Tue, 21 Feb 2012 20:53:34 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 44D4321F88C4 for ; Tue, 21 Feb 2012 20:53:34 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7225420E40CC; Tue, 21 Feb 2012 23:52:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329886368; bh=lIjlyCiuVaRcGAsbstct4Lpiw7x3dvUbbsE29J20OZ0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=EAOmoTLnlSTDAzcvsuzv0IVO/sKHBeovIeVjeKQwB7PSYf5tf4zH6mVK7g4SKBctM hHfUOxfh+1fxYfuluU3okC1RynP3j0yDFaNZYyPp/SSmZykrL3DCUuNFLfHStvS1K1 jLL5krTbvqhXUTLgah8Z/j172WPDV4PhSxSnoaP4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3152620E4099; Tue, 21 Feb 2012 23:52:18 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 21 Feb 2012 23:52:12 -0500 Message-ID: <2339815.CSJoMZRfUQ@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F443C98.2070905@dcrocker.net> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <2356334.hRHxVFBgpV@scott-latitude-e6320> <4F443C98.2070905@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 04:53:35 -0000 On Tuesday, February 21, 2012 04:53:44 PM Dave CROCKER wrote: > On 2/21/2012 4:33 PM, Scott Kitterman wrote: > > On Tuesday, February 21, 2012 04:21:00 PM Dave CROCKER wrote: > >> The exercise is to have the spec contain only /one/ of the choices I > >> outlined. > > > > I understood that. > > > > That's the opposite direction of what I was trying to go with this > > issue. > > > > > > > > I am assuming that we are not moving away from RFC 4408's perspective > > that recevier policy should generally not be specified. Given that we > > aren't doing to specify what to do with SPF results, there's no benefit > > to specifying processing order. > > And nothing I am proposing disagrees with that... policy. > > What I am proposed is to clarify and refine those SPF results. > > Random choices about processing order can produce differing assessments of > the objective, authentication information. That's a definition of > non-interoperability. > > SPF publishers need to know how their records will be interpreted, at the > validation level. This is quite different from the next layer up, where the > validated information is used -- and, yes, subject to receiver-side local > poliy and no, not known to the publisher. Yes, but there isn't one input and output here. There is a potential HELO check and a Mail From check each with their own results. Two inputs, two outputs. How they are evaluated (either separately or in tandem) is a matter for local policy. I agree as far as "If I publish this SPF record and use this name in HELO I should get SPF Pass for HELO checks for this machine." That must be reliable. What order I run the code that produces the SPF results doesn't change what those results are, so there's no interoperability need to specify the order. Since the receiver knows what the local policy is the receiver will know when, as an efficiency, it's not necessary to perform one of the checks. We should let them decide that. The current MUST for Mail From checks (which is where this started) doesn't make sense. > > RFC 4408 specifies that one SHOULD check HELO and MUST check Mail From. > > If a HELO result is dispositive then the Mail From result is pointless. > > Doing it doesn't help interoperability, it's just a waste of > > resources. > > We were just given data to suggest that checking the EHLO is a waste of > effort. I think we were given an opinion. Here's another set of data ... I run the mail test service listed on http://www.openspf.net/Tools (spf- test@openspf.net). I have a small script that parses the current log file to see the distribution of results. Note that these are generally very error prone since the people who generally use this are trying to initially deploy SPF. There are probably duplicates in here from people that tried more than once (I didn't check). Messages in current log file - 274 Mail From Pass - 109 Mail From None - 63 Mail From Fail - 66 Mail From Softfail - 15 Mail From Neutral - 11 Mail From Temperror - 0 Mail From Permerror - 10 HELO Pass - 43 HELO Fail - 7 HELO None - 214 HELO Softfail - 2 HELO Neutral - 1 HELO Temperror - 0 HELO Permerror - 7 So in this data set there's ~25% coverage of one kind of another for HELO (compared to ~75% for Mail From). While this is significantly less deployment than for Mail From, it's hardly trivial. It is, of course, a statistically insignificant sample, but I suspect it is at least generally representative of initial deployment efforts. > If it is a waste, we should drop it. It's not. > The current requirements of the specification means that the client SMTP > cannot know what the basic validation will be. We need to remove that > non-determinacy. We can't. The non-determinacy is about local policy. We aren't going to remove that. The SPF results are quite deterministic. > > Whether doing 3a or 3b (or any of your other options) makes the most > > sense is a function of receiver policy. > > So you think it is ok that the basic validation results will vary depending > upon the whims of the receiver? No, I think that the need to doing them in some cases is a function of receiver policy. I have an open source implementation for Postfix that has, for years, rejected messages with SPF HELO results of Fail, Softfail, Permerror by default before I even start to check Mail From. I've never had a complaint. https://launchpad.net/pypolicyd-spf > > There is also 4: Only check HELO if Mail From > > > > is Null. I don't think trying to hard code any of these choices into > > 4408bis is helpful. > > I mean this to be covered by 3b. OK. > > In SPF terms I think interoperabliity is defined in terms of "If I > > publish record A and send mail from server B, receivers will get SPF > > result C". How receivers use that result is not something we should > > take on. > > We agree on that goal. > > Where we seem to be disagreeing is on the fact that letting the receiver > decide what fields to validate makes result C unpredictable. No it doesn't. The only thing I'm looking for is changing a MUST to a SHOULD so that in cases where, due to local policy, the reciever knows the check won't affect the message disposition there's no requirement for a pointless check. Fundamentally, I think any MUST MUST be a true requirement for interoperability. I'm confident this isn't one of those. Scott K From sm@elandsys.com Tue Feb 21 21:13:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3B321F855F for ; Tue, 21 Feb 2012 21:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.644 X-Spam-Level: X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YskLnrwwuug1 for ; Tue, 21 Feb 2012 21:13:50 -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 E9DD521F867A for ; Tue, 21 Feb 2012 21:13:48 -0800 (PST) Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1M5DYSD020534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 21:13:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329887625; i=@elandsys.com; bh=DgwP1V42fa8v7xowwBnHUkwaG9zVf0+p0tCFaAP++OQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=L+5kH9O3GHacrYpoD4OYTkntYzvtgjZa0BbGFOHUcuNyLLva+IWqOelmj+Woq1T+9 igTkGDzbIVFyMtusqG3DeAl2SlEJ8OANCdaF6lBqmTR3MCsiLo7Mr2Cfn8ro9JxPuB hqDhqyjcCWORSjKzQuSwkQlh8hTgAEY4B7VtYgZ4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329887625; i=@elandsys.com; bh=DgwP1V42fa8v7xowwBnHUkwaG9zVf0+p0tCFaAP++OQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=KDL1Z7JQ5oTgTVyIHCdwgESAMYt0FK0NXTfcFUnUgI8urxzlpwNKFpebgRLrlZiEG A/+7aQMBkz30Qc03e74AF8eH4LMy3DmPlfeYIjM5gQY88LQ7vGwHqq8SqB28O6ewq6 D9V+yiEeBat6RULuqcwZesxmAmkdq1HU1R820E88= Message-Id: <6.2.5.6.2.20120221211216.0a0d38d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 21 Feb 2012 21:13:32 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <2339815.CSJoMZRfUQ@scott-latitude-e6320> References: <1618345.7dPBqcXJlk@scott-latitude-e6320> <2356334.hRHxVFBgpV@scott-latitude-e6320> <4F443C98.2070905@dcrocker.net> <2339815.CSJoMZRfUQ@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 05:13:55 -0000 Hello, This thread is off-topic at the moment. Please do not comment on issues which have not been opened yet. Thank you, S. Moonesamy SPF WG co-chair From sm@elandsys.com Tue Feb 21 21:13:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509D821F8566 for ; Tue, 21 Feb 2012 21:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtOiT+ZZhe+4 for ; Tue, 21 Feb 2012 21:13:50 -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 E9D6421F8663 for ; Tue, 21 Feb 2012 21:13:49 -0800 (PST) Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1M5DYSB020534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 21:13:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329887621; i=@elandsys.com; bh=DgwP1V42fa8v7xowwBnHUkwaG9zVf0+p0tCFaAP++OQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Bglf2nQSkB1GptMc6/4rH6ILP6PShmtHdWgU8wDSHR5umNmoexydlGnUOPu8STFaq uwM+ZAS3VFAYV3jvJnErRFHNylOHsPkZj3GTXngV8VWVMrhpyQsIeZY3m8S9SMZm4i 7ugaBkbrMNkh07jaGJKuFdmkj53RHS8sD1g0Jjus= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329887621; i=@elandsys.com; bh=DgwP1V42fa8v7xowwBnHUkwaG9zVf0+p0tCFaAP++OQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=3SwbwedKLwaTm9CeuOtkbLweiSvhI0qqKXws/nFMidgTBM+nZbh1uBSdS2sqNg/vC I/i4RiR4//P6kX/hPS+1h3Q/G9qEK76gKrh9IA6YnKpZgEd4vXILxxwkNUDc5olbkb cxBDhJ4i2UbfbSJlhpblySHjeWut8owae7mbvg2c= Message-Id: <6.2.5.6.2.20120221210752.0a0ed938@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 21 Feb 2012 21:10:59 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1547162.dq6EdtT5Jz@scott-latitude-e6320> References: <6.2.5.6.2.20120214100806.064015a8@elandnews.com> <4F4440BF.7060600@mail-abuse.org> <4F4456DF.9040500@mail-abuse.org> <1547162.dq6EdtT5Jz@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] RFC 4408 issue Reasonable DNS error limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 05:13:55 -0000 Hello, This thread is off-topic at the moment. Please do not comment on issues which have not been opened yet. Thank you, S. Moonesamy SPF WG co-chair From hsantos@isdg.net Tue Feb 21 22:27:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3BB21E8067 for ; Tue, 21 Feb 2012 22:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_05=-1.11, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0p01hU5kwb2 for ; Tue, 21 Feb 2012 22:27:47 -0800 (PST) Received: from ntbbs.santronics.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4FC21E806F for ; Tue, 21 Feb 2012 22:27:47 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3499; t=1329892056; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=lpWC6t52WUd5jUikLZRtXYMO7H4=; b=iIcXyYlhwM6/Ri8ZCML3 Tt6J7Fn+JXy95T6LzvaBmdPvbH/2R2w4/aFrbVpgYSdI9L05E6sc/MKyip3Y3LpR aS8BeFMS9+k+FcZdTlmNaO43NfQmFO3bvNBNth6iJH7FF0WfPADErP6yPYhuxsz0 wLmBgKeyt9hJkNLt+/4doZA= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 01:27:36 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3093901048.88546.2168; Wed, 22 Feb 2012 01:27:35 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3499; t=1329891816; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=PePNKnp gSLS4udExa51Z6OezTLPDbU7prlWbTS84oso=; b=LtbdWIF68qdBpVWQx1Jospx THkwoNz8nGQKGb7cA6WncwzDmL78azbsPAmdJvwMHFRljO8Ptn1SZGvDYskiAikF zxdQAGKxuXm9pHF0d/fZKPWNvbUUobJaE7d0dQo7TOG1ZhCa70ozNeXCuCCEfwxZ zUuju7iwmrL3oIJSV4ZU= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 01:23:36 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3692839345.18678.6740; Wed, 22 Feb 2012 01:23:35 -0500 Message-ID: <4F448AE6.5000605@isdg.net> Date: Wed, 22 Feb 2012 01:27:50 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> <2540299.gmSuznFx9K@scott-latitude-e6320> <4F42C605.9000907@isdg.net> <4F4312EA.9080206@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] SUBMITTER usage X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 06:27:48 -0000 Murray S. Kucherawy wrote: >> >> http://www.imc.org/ietf-smtp/mail-archive/msg07117.html > > Somehow I never got your message on ietf-smtp. Thanks for the link. > > There's no doubt that you're seeing the traffic, but it's unfortunate that we can't > tell which specific clients are doing it. Regardless, I agree that it's unclear > whether these are spammers or ESPs. It wasn't a surprise for high eMarketer usage. Like DKIM, SPF/SIDF became part of eMarketer and DMA recommendations for a BCP "Good Guy" behavior in PR efforts to lower its market negative image and especially promoting SIDF because of its industry standard and corporate endorsement image it brought. Doing a quick search for "DMA SENDER-ID RECOMMENDATIONS"... first google link. http://www.the-dma.org/antispam/EmailBPFINAL.pdf Looks like good stuff there, but do check out others too since this PDF seem to be more recent. > I think the interesting fact is that there are so few spf2.0/pra records out there tells > me this is indeed opportunistic use of SUBMITTER rather than an indication of > intended use of Sender-ID. I'll check out our cached DNS data soon and focus on that on that question. I should note however, I am not part of the school of thought to believe a low usage is enough justification from remove it from a standard which for all intent, it is already considered a standard in the eyes of long time implementators of product code. > A survey of MTAs and their spam and virus accuracy plugins has reported that of > over 20 MTA solutions that they test, only one implements SUBMITTER. Surprisingly, > that MTA is not MS Exchange. I don't think this is justification nor the role of SPF-BIS to make that SIDF/SUBMITTER decision. I would suggest since MARID there was two different groups starting with the fact SPF was growing on its own without the IETF. It was Microsoft with intro of the XML version of its SPF clone (CEP) that force the creation of MARID to solidify a common standard. And with the many contentions, including "Hate MS" camp, it is not a surprise at all to find the API resources at SPF web site to include software that doesn't support SENDER-ID, yet along SUBMITTER. To get a better measurement, a look of the commercial MTA software vendors who even if they doubted SIDF value, like most things, a feature is added for corporate and marketing value anyway. But despite all that, there is something inherently wrong using high probable mis-read for a low usage threshold criteria to remove something with a disregard it may harm existing implementator business or customers. When a BIG vs SMALL boys position is used to brush away the small boys, the small boys made just use ANTI=TRUST claims against the IETF if it endorses protocol changes with BIS work for established, well-entrenched implementors of these protocols. > It also raises an interesting procedural question: If we can categorize a technology > like SUBMITTER as only ever having been deployed primarily by spammers, how does > that figure into the questions of an interoperability report? I think the SPF-BIF group is playing with fire. Just for the record, and in all honesty, why even go there. Why all this obvious friction and contention when it doesn't have to be. Until Microsoft views are seen here, I will stay away from this. Sorry. :) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From pmidge@microsoft.com Tue Feb 21 23:18:24 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE46B21F88E1 for ; Tue, 21 Feb 2012 23:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.466 X-Spam-Level: X-Spam-Status: No, score=-5.466 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyzTNqoOgpsP for ; Tue, 21 Feb 2012 23:18:24 -0800 (PST) Received: from TX2EHSOBE006.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id DF73C21E8067 for ; Tue, 21 Feb 2012 23:18:23 -0800 (PST) Received: from mail67-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 22 Feb 2012 07:18:18 +0000 Received: from mail67-tx2 (localhost [127.0.0.1]) by mail67-tx2-R.bigfish.com (Postfix) with ESMTP id 2243340378; Wed, 22 Feb 2012 07:18:18 +0000 (UTC) X-SpamScore: -43 X-BigFish: VS-43(zz9371I1447M542M1432N98dKzz1202hzz1033IL8275bh8275dh5eeeKz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail67-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail67-tx2 (localhost.localdomain [127.0.0.1]) by mail67-tx2 (MessageSwitch) id 1329895096571516_24241; Wed, 22 Feb 2012 07:18:16 +0000 (UTC) Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.251]) by mail67-tx2.bigfish.com (Postfix) with ESMTP id 86EBC20122; Wed, 22 Feb 2012 07:18:16 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 22 Feb 2012 07:18:24 +0000 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.110]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0247.005; Wed, 22 Feb 2012 07:18:20 +0000 From: Paul Midgen To: Hector Santos , "spfbis@ietf.org" Thread-Topic: [spfbis] SUBMITTER usage Thread-Index: AQHM8SsdzjJpsX+d6kmbNrMN7BZYLpZIfEPA Date: Wed, 22 Feb 2012 07:18:20 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204B3CB4@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> <2540299.gmSuznFx9K@scott-latitude-e6320> <4F42C605.9000907@isdg.net> <4F4312EA.9080206@isdg.net> <4F448AE6.5000605@isdg.net> In-Reply-To: <4F448AE6.5000605@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] SUBMITTER usage X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 07:18:25 -0000 As concerns SUBMITTER: this group is reviewing things that have been publis= hed for 6+ years. If by now there isn't a vocal and deployed base prepared = to share data and operational experience that supports the inclusion of a g= iven thing, that should carry a bit of weight. For 2.5 of those 6 years I've been responsible for Hotmail's inbound infras= tructure, and haven't received a single request to implement SUBMITTER. -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Hector Santos Sent: Tuesday, February 21, 2012 10:28 PM To: spfbis@ietf.org Subject: [spfbis] SUBMITTER usage Murray S. Kucherawy wrote: >> >> http://www.imc.org/ietf-smtp/mail-archive/msg07117.html >=20 > Somehow I never got your message on ietf-smtp. Thanks for the link. >=20 > There's no doubt that you're seeing the traffic, but it's unfortunate=20 > that we can't tell which specific clients are doing it. Regardless, I=20 > agree that it's unclear whether these are spammers or ESPs. It wasn't a surprise for high eMarketer usage. Like DKIM, SPF/SIDF became p= art of eMarketer and DMA recommendations for a BCP "Good Guy"=20 behavior in PR efforts to lower its market negative image and especially pr= omoting SIDF because of its industry standard and corporate endorsement ima= ge it brought. Doing a quick search for "DMA SENDER-ID RECOMMENDATIONS"...= first google link. http://www.the-dma.org/antispam/EmailBPFINAL.pdf Looks like good stuff there, but do check out others too since this PDF see= m to be more recent. > I think the interesting fact is that there are so few spf2.0/pra=20 > records out there tells me this is indeed opportunistic use of=20 > SUBMITTER rather than an indication of intended use of Sender-ID. I'll check out our cached DNS data soon and focus on that on that question.= I should note however, I am not part of the school of thought to believe = a low usage is enough justification from remove it from a standard which fo= r all intent, it is already considered a standard in the eyes of long time = implementators of product code. > A survey of MTAs and their spam and virus accuracy plugins has=20 > reported that of over 20 MTA solutions that they test, only one=20 > implements SUBMITTER. Surprisingly, that MTA is not MS Exchange. I don't think this is justification nor the role of SPF-BIS to make that SI= DF/SUBMITTER decision. I would suggest since MARID there was two different= groups starting with the fact SPF was growing on its own without the IETF.= It was Microsoft with intro of the XML version of its SPF clone (CEP) that= force the creation of MARID to solidify a common standard. And with the ma= ny contentions, including "Hate MS"=20 camp, it is not a surprise at all to find the API resources at SPF web site= to include software that doesn't support SENDER-ID, yet along SUBMITTER. To get a better measurement, a look of the commercial MTA software vendors = who even if they doubted SIDF value, like most things, a feature is added f= or corporate and marketing value anyway. But despite all that, there is something inherently wrong using high probab= le mis-read for a low usage threshold criteria to remove something with a d= isregard it may harm existing implementator business=20 or customers. When a BIG vs SMALL boys position is used to brush=20 away the small boys, the small boys made just use ANTI=3DTRUST claims again= st the IETF if it endorses protocol changes with BIS work for established, = well-entrenched implementors of these protocols. > It also raises an interesting procedural question: If we can=20 > categorize a technology like SUBMITTER as only ever having been=20 > deployed primarily by spammers, how does that figure into the questions o= f an interoperability report? I think the SPF-BIF group is playing with fire. Just for the record, and in= all honesty, why even go there. Why all this obvious friction and contenti= on when it doesn't have to be. Until Microsoft views are seen here, I will stay away from this. Sorry. :) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From msk@cloudmark.com Tue Feb 21 23:29:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736FD21E8043 for ; Tue, 21 Feb 2012 23:29:19 -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 HWs9Bl8+9vdv for ; Tue, 21 Feb 2012 23:29:18 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id ACA5021E8065 for ; Tue, 21 Feb 2012 23:29:18 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Tue, 21 Feb 2012 23:29:17 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] SUBMITTER usage Thread-Index: AQHM8SsaN6mQMzFXk0GSWYTYWbMJx5ZJCBUA//98S7A= Date: Wed, 22 Feb 2012 07:29:16 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392803B991@exch-mbx901.corp.cloudmark.com> References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> <2540299.gmSuznFx9K@scott-latitude-e6320> <4F42C605.9000907@isdg.net> <4F4312EA.9080206@isdg.net> <4F448AE6.5000605@isdg.net> <7F7F36E50398F84DBAF25C9D51732F1E204B3CB4@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E204B3CB4@TK5EX14MBXC203.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SUBMITTER usage X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 07:29:19 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Paul Midgen > Sent: Tuesday, February 21, 2012 11:18 PM > To: Hector Santos; spfbis@ietf.org > Subject: Re: [spfbis] SUBMITTER usage >=20 > As concerns SUBMITTER: this group is reviewing things that have been > published for 6+ years. If by now there isn't a vocal and deployed base > prepared to share data and operational experience that supports the > inclusion of a given thing, that should carry a bit of weight. >=20 > For 2.5 of those 6 years I've been responsible for Hotmail's inbound > infrastructure, and haven't received a single request to implement > SUBMITTER. Thanks, Paul. If I could ask a bit more of you and your data: While you're gearing up ano= ther SPF/Sender-ID efficacy comparison, is there a way to determine whether= or not your Sender-ID implementation checks type 99 (SPF) DNS records, typ= e 16 (TXT) records, or both? And, if both, can you gauge what the percenta= ges are for each? "No" is a perfectly valid answer if that would be a pain. We already have = one report done and one pending with this information, but a third data set= can't hurt if we can get one. :-) -MSK From hsantos@isdg.net Wed Feb 22 00:32:11 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B12621F8971 for ; Wed, 22 Feb 2012 00:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.414 X-Spam-Level: X-Spam-Status: No, score=-1.414 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li1OwliNrKPh for ; Wed, 22 Feb 2012 00:32:09 -0800 (PST) Received: from pop3.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7230021F896F for ; Wed, 22 Feb 2012 00:32:09 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6621; t=1329899526; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=bTiiWz8TK45RFJio01QYCU6Rr6Y=; b=DnCdERCemBQctL8Qu3NE 6y0AUEYGS2MYLOHl1jIe440zUTiaiYQ3dTyy0XJDddOR1HtyVSe1R615LieFfOgM e1G3zr9TRYxVv4LrJt2GFEGwUkbd5Vlbr2M7ojCQh7V2TTdrxIiMZrEwWiFP9A1E /y7bxFrXYnstCVGJB6qmprs= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 03:32:06 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3101371327.88546.3308; Wed, 22 Feb 2012 03:32:05 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6621; t=1329899287; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=5R8M8mz HMLd52B7dZwyVpIAZJqbTWMSkXIt54WAUqBU=; b=vI3Pz6pnr2vndNfaNOtj2jP +RxvJoNz58KD1frX5Gfog0OXDD758k6jQyltnZq5qpO4ATJrJYkWmKGNJMyZbHWu D+70XP2LX/lfGSqp6UGQYpNvqPRUctmuoZSybKzMUf1y0yn+gyArqw5Vi7DNT9Ci fSdWaAZnXNr+cWqxZgDg= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 03:28:07 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3700310408.18843.3592; Wed, 22 Feb 2012 03:28:07 -0500 Message-ID: <4F44A815.7080208@isdg.net> Date: Wed, 22 Feb 2012 03:32:21 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> <2540299.gmSuznFx9K@scott-latitude-e6320> <4F42C605.9000907@isdg.net> <4F4312EA.9080206@isdg.net> <4F448AE6.5000605@isdg.net> <7F7F36E50398F84DBAF25C9D51732F1E204B3CB4@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E204B3CB4@TK5EX14MBXC203.redmond.corp.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SUBMITTER usage X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 08:32:11 -0000 Paul Midgen wrote: > As concerns SUBMITTER: this group is reviewing things that have been published for > 6+ years. If by now there isn't a vocal and deployed base prepared to share data > and operational experience that supports the inclusion of a given thing, that > should carry a bit of weight. This is BIS work. It has always been my IETF understanding BIS work is not work designed and only under special and rare circumstances, to change current or harm any existing implementations at any level. This particular item is not one of items to be considered lightly for abandonment. > For 2.5 of those 6 years I've been responsible for Hotmail's inbound > infrastructure, and haven't received a single request to implement SUBMITTER. With all due respect and don't fall trap to disliking me, so don't - so what? What you stated has no correlation whatsoever to a true reflection if its used or not. In addition, and very importantly, hotmail.com is not a commercial service bureau. In other words, you don't sell hotmail.com for others to use on their own server or network. What you didn't measure is when the HOTMAIL.COM receivers would expose the SUBMITTER keyword, and now you will measure the possible million of clients connecting to hotmail.com and use the MAIL FROM SUBMITTER= keyword in order to support the PRA option in their messages. What you seem to be suggesting in reality is that HOTMAIL.COM either A) does not support SENDER-ID at all, or B) does support SENDER-ID via SUBMITTER? Sounds like A to me. I don't you can voice a lack of support at hotmail.com if it never supported SENDER-ID or the SUBMITTER SMTP extension. Thats like saying my SMTP server never needed to support the BITMIME SMTP extension and never got any request or market pressure to add ESMTP support and thus never got any feel for it in its transactions and believed it was also not supported by others - because you didn't. But once you simply add the BITMIME Keyword to your server EHLO responses, just to measure it, you will quickly see how widely supported it is, negating all the erroneous impressions you had that its an unpopular protocol. Its not. I say that because that is what happen with us - I erroneously had the believe BITMIME was not a well supported SMTP extension until we finally explored it and added it and BEHOLD, you find how wrong you were believing it was low support extension. > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Hector Santos > Sent: Tuesday, February 21, 2012 10:28 PM > To: spfbis@ietf.org > Subject: [spfbis] SUBMITTER usage > > Murray S. Kucherawy wrote: >>> http://www.imc.org/ietf-smtp/mail-archive/msg07117.html >> Somehow I never got your message on ietf-smtp. Thanks for the link. >> >> There's no doubt that you're seeing the traffic, but it's unfortunate >> that we can't tell which specific clients are doing it. Regardless, I >> agree that it's unclear whether these are spammers or ESPs. > > It wasn't a surprise for high eMarketer usage. Like DKIM, SPF/SIDF became part of eMarketer and DMA recommendations for a BCP "Good Guy" > behavior in PR efforts to lower its market negative image and especially promoting SIDF because of its industry standard and corporate endorsement image it brought. Doing a quick search for "DMA SENDER-ID RECOMMENDATIONS"... first google link. > > http://www.the-dma.org/antispam/EmailBPFINAL.pdf > > Looks like good stuff there, but do check out others too since this PDF seem to be more recent. > >> I think the interesting fact is that there are so few spf2.0/pra >> records out there tells me this is indeed opportunistic use of >> SUBMITTER rather than an indication of intended use of Sender-ID. > > I'll check out our cached DNS data soon and focus on that on that question. I should note however, I am not part of the school of thought to believe a low usage is enough justification from remove it from a standard which for all intent, it is already considered a standard in the eyes of long time implementators of product code. > > >> A survey of MTAs and their spam and virus accuracy plugins has >> reported that of over 20 MTA solutions that they test, only one >> implements SUBMITTER. Surprisingly, that MTA is not MS Exchange. > > I don't think this is justification nor the role of SPF-BIS to make that SIDF/SUBMITTER decision. I would suggest since MARID there was two different groups starting with the fact SPF was growing on its own without the IETF. It was Microsoft with intro of the XML version of its SPF clone (CEP) that force the creation of MARID to solidify a common standard. And with the many contentions, including "Hate MS" > camp, it is not a surprise at all to find the API resources at SPF web site to include software that doesn't support SENDER-ID, yet along SUBMITTER. > > To get a better measurement, a look of the commercial MTA software vendors who even if they doubted SIDF value, like most things, a feature is added for corporate and marketing value anyway. > > But despite all that, there is something inherently wrong using high probable mis-read for a low usage threshold criteria to remove something with a disregard it may harm existing implementator business > or customers. When a BIG vs SMALL boys position is used to brush > away the small boys, the small boys made just use ANTI=TRUST claims against the IETF if it endorses protocol changes with BIS work for established, well-entrenched implementors of these protocols. > >> It also raises an interesting procedural question: If we can >> categorize a technology like SUBMITTER as only ever having been >> deployed primarily by spammers, how does that figure into the questions of an interoperability report? > > I think the SPF-BIF group is playing with fire. Just for the record, and in all honesty, why even go there. Why all this obvious friction and contention when it doesn't have to be. > > Until Microsoft views are seen here, I will stay away from this. > > Sorry. :) > > -- > Hector Santos, CTO > http://www.santronics.com > http://santronics.blogspot.com > > > _______________________________________________ > 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 > > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Wed Feb 22 01:05:13 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF67C21F8960 for ; Wed, 22 Feb 2012 01:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+xiI-DuwgV0 for ; Wed, 22 Feb 2012 01:05:12 -0800 (PST) Received: from pop3.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 08B1521F894B for ; Wed, 22 Feb 2012 01:05:11 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1811; t=1329901501; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=KZlQq4QKsa5DmcUJ4a3xo6BvTGA=; b=p+ZMHlAbPTby/n3Kht41 TzMgd6WE9ZrPcaHJvIYoRBLUsC4csM4YlDIXVjK1o5ZJrvX0fJzTJ4IAjvQgPLw6 1T8InvGV99Gv1r3MJnAIqzuCUKkhqucIrqBnknip2g0hsB7zmd06i8d8icWV8H+J xabY3ABOTw/PKfXAQ5cnYOs= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 04:05:01 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3103346456.88546.3832; Wed, 22 Feb 2012 04:05:00 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1811; t=1329901261; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=gsdV6dT MImeU0xPBUYhAxxoiXB8bwiF3SlYO/SWAuAE=; b=gtyqhRKYJoN6aCP4C/LPjGI DIqJ75myPG0z27/rkeS/7hQQR/XRNkZ1iptTWLyjw8+YoB1p9e+/tR/cI1WDy+OM pShdSJuXBuZrhPZfLBHTIBwSpJSvlovRTEhN1/fKMTIk7BkH6BLFJ0Wv6LL28MkQ JhxonBA5I31XFOB21L3c= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 04:01:01 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3702284767.18845.7180; Wed, 22 Feb 2012 04:01:01 -0500 Message-ID: <4F44AFCB.2070603@isdg.net> Date: Wed, 22 Feb 2012 04:05:15 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> <2540299.gmSuznFx9K@scott-latitude-e6320> <4F42C605.9000907@isdg.net> <4F4312EA.9080206@isdg.net> <4F448AE6.5000605@isdg.net> <7F7F36E50398F84DBAF25C9D51732F1E204B3CB4@TK5EX14MBXC203.redmond.corp.microsoft.com> <4F44A815.7080208@isdg.net> In-Reply-To: <4F44A815.7080208@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SUBMITTER usage X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 09:05:13 -0000 Follow up and clarification: Hector Santos wrote: > Paul Midgen wrote: > >> For 2.5 of those 6 years I've been responsible for Hotmail's inbound >> infrastructure, and haven't received a single request to implement >> SUBMITTER. > > What you seem to be suggesting in reality is that HOTMAIL.COM either A) > does not support SENDER-ID at all, or B) does [not] support SENDER-ID via > SUBMITTER? > > Sounds like A to me. Paul, I think you don't understand what the purpose was and why SUBMITTER was invented. Using SUBMITTER is an server decision to order to optimize server and system performance and improved transaction throughput. It is also a way to better trap redundant fraud by spoofers. That was the whole purpose of it so if indeed hotmail.com supports SENDER-ID it would be for the benefit of the your server operations in terms of system performance, lower payload overhead to allow clients to issue the PRA at the SMTP level via the SUBMITTER protocol. Otherwise, you are inherently requirement the payload at all times if SPF does not does the job for you. No one is going to request that you support it. That doesn't make sense unless there were situations perhaps where hotmail.com was always rejection based on a Payload SENDER-ID PRA violation and the client was saying: "Hey, why you are wasting my bandwidth with transforming the payload when you are rejecting base on the PRA. I can give that PRA via SUBMITTER to save in the payload transfer." Doesn't make sense, does it? No, you would add it to save in payload overhead and improve system performance and if the there is good measure rejecting based on the PRA, then you benefit by supporting it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Wed Feb 22 01:42:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2945621F8949 for ; Wed, 22 Feb 2012 01:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YL0IWmayH6rq for ; Wed, 22 Feb 2012 01:42:47 -0800 (PST) Received: from news.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BCAEC21F882E for ; Wed, 22 Feb 2012 01:42:45 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1643; t=1329903762; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Y2kW0b8i71l189FHAielR3c8wdg=; b=fCXHfvy5TzNDkdPm2LmL mAyOksXjQ4e4ye6fuONHOAY3ytA42pZ6NflxEjqsYs7qp35Rmto2vMoBXXon3+6M b+vEavENvM+HPIu9tkCv/JAE2AYvuGBWcmuxTKzB7M2eqdQpC2oQuU7i7eCS6w5V neaR5G4zy9k3/G/KrrvM+jA= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 04:42:42 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3105606630.88546.5272; Wed, 22 Feb 2012 04:42:41 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1643; t=1329903519; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=gNKrDMk vPaaP/RUY/Glo6KgNFewC2VVWvuszqODJJOY=; b=VD9H0t70kMHQc/MMFW2EVFP SmyaXclQ0uGZsTp54JjtjAr0PzQ/sTNQDwBfkzAH3zAGNOqHNarkcLHTjVlgRICj ks26/PejeaitdZDJuksfF02Xtb/YgIJrWxdPpvCe72T5KIchzROmtI11fRWmPR81 8s5ty7C5EfXKApl/aw9I= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 04:38:39 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3704541970.18849.1916; Wed, 22 Feb 2012 04:38:38 -0500 Message-ID: <4F44B89C.9040803@isdg.net> Date: Wed, 22 Feb 2012 04:42:52 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> <2540299.gmSuznFx9K@scott-latitude-e6320> <4F42C605.9000907@isdg.net> <4F4312EA.9080206@isdg.net> <4F448AE6.5000605@isdg.net> <7F7F36E50398F84DBAF25C9D51732F1E204B3CB4@TK5EX14MBXC203.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E00392803B991@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392803B991@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SUBMITTER usage X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 09:42:48 -0000 Murray S. Kucherawy wrote: >> >> For 2.5 of those 6 years I've been responsible for Hotmail's inbound >> infrastructure, and haven't received a single request to implement >> SUBMITTER. > > Thanks, Paul. > > If I could ask a bit more of you and your data: While you're gearing up another > SPF/Sender-ID efficacy comparison, is there a way to determine whether or not > your Sender-ID implementation checks type 99 (SPF) DNS records, type 16 (TXT) > records, or both? And, if both, can you gauge what the percentages are for each? > > "No" is a perfectly valid answer if that would be a pain. We already have one report > done and one pending with this information, but a third data set can't hurt if we > can get one. :-) This buddy-buddy system at the exclusion of others has got to stop. Quick review of the cached DNS queries I have: 3426 : cached TXT records (request) 2783 : with v=spf1 82 : with spf2.0 include INVALID ones (I believe, see below) 10 spf2.0/mfrom 72 spf2.0/pra These were among the totals that I think are invalid syntax. Don't know off hand if v=spf2 is valid v=spf2 v=spf2.0/pra v=spf2.0/pra v=spf2.0/pra v=spf2.0/pra v=spf2.0/pra mx v=spf2.0/pra mx v=spf2/mfrom,pra v=spf2.0/mfrom v=spf2.0/mfrom v=spf2.0/mfrom v=spf2.0/mfrom v=spf2/mfrom,pra Even as I sure you will label me as a SMALL system, even as a small system there is over 80% usage of spf2.0/pra for SIDF. To continue contemplating getting rid of it in SPF-BIS, would represent a serious problem. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Wed Feb 22 04:18:24 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB95721F87E9 for ; Wed, 22 Feb 2012 04:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 bkSHrZIntg4N for ; Wed, 22 Feb 2012 04:18:17 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id BB77D21F87E2 for ; Wed, 22 Feb 2012 04:18:16 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id E2C5FD0408D; Wed, 22 Feb 2012 06:18:15 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329913095; bh=JMYSsXDnlkVqREI2QTeZwn6ABF12MPoTfrwoRZFAlPU=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=p6aeo82RwDDqEketxcx4w/s65NJdHKv5aISlZiIocq/RWvfs5f0DerccdXwlNhWBV iwa4LiRPjRD7fRuLXMR4UVqw/eF60tKq1rt+px7rWAed9m5uP3lU9ndasJgmHPmdJX fVoy+kQdnT6kt4QcXUS3Mwgdupc4Mj8WMTemFcaw= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A9C68D04002; Wed, 22 Feb 2012 06:18:15 -0600 (CST) References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> <2540299.gmSuznFx9K@scott-latitude-e6320> <4F42C605.9000907@isdg.net> <4F4312EA.9080206@isdg.net> <4F448AE6.5000605@isdg.net> <7F7F36E50398F84DBAF25C9D51732F1E204B3CB4@TK5EX14MBXC203.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E00392803B991@exch-mbx901.corp.cloudmark.com> <4F44B89C.9040803@isdg.net> User-Agent: K-9 Mail for Android In-Reply-To: <4F44B89C.9040803@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 22 Feb 2012 07:18:24 -0500 To: "spfbis@ietf.org" Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SUBMITTER usage X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 12:18:25 -0000 Hector Santos wrote: > >Murray S. Kucherawy wrote: >>> >>> For 2.5 of those 6 years I've been responsible for Hotmail's inbound >>> infrastructure, and haven't received a single request to implement >>> SUBMITTER. >> >> Thanks, Paul. >> >> If I could ask a bit more of you and your data: While you're gearing >up another >> SPF/Sender-ID efficacy comparison, is there a way to determine >whether or not >> your Sender-ID implementation checks type 99 (SPF) DNS records, type >16 (TXT) >> records, or both? And, if both, can you gauge what the percentages >are for each? >> >> "No" is a perfectly valid answer if that would be a pain. We already >have one report >> done and one pending with this information, but a third data set >can't hurt if we >> can get one. :-) > >This buddy-buddy system at the exclusion of others has got to stop. > >Quick review of the cached DNS queries I have: > > 3426 : cached TXT records (request) > 2783 : with v=spf1 > 82 : with spf2.0 include INVALID ones (I believe, see below) > 10 spf2.0/mfrom > 72 spf2.0/pra > >These were among the totals that I think are invalid syntax. Don't >know off hand if v=spf2 is valid It's not. > v=spf2 > v=spf2.0/pra > v=spf2.0/pra > v=spf2.0/pra > v=spf2.0/pra > v=spf2.0/pra mx > v=spf2.0/pra mx > v=spf2/mfrom,pra > v=spf2.0/mfrom > v=spf2.0/mfrom > v=spf2.0/mfrom > v=spf2.0/mfrom > v=spf2/mfrom,pra > >Even as I sure you will label me as a SMALL system, even as a small >system there is over 80% usage of spf2.0/pra for SIDF. To continue >contemplating getting rid of it in SPF-BIS, would represent a serious >problem. Since v=spf1 records are considered valid for PRA evaluations by Sender ID you can't conclude anything based on your data. The fact that Sender ID is forced on SPF record publishers confuses things further. To gauge actual interest in Sender ID, you have to have some mechanism for determining what fraction of the participation is based on consensual interest. I've no idea how to do that. You can't separate SUBMITTER from PRA, so absent some groundswell of support for some future working group to deal with Sender ID, there's no point in worrying about SUBMITTER. FWIW, I don't think anyone is ignoring anyone, but I do think you're venturing beyond the charter regularly, so it's no surprise such excursions don't generate a lot of positive feedback. Scott K From msk@cloudmark.com Wed Feb 22 06:49:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E8621F8709 for ; Wed, 22 Feb 2012 06:49:46 -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 WogxRK1Vubsb for ; Wed, 22 Feb 2012 06:49:46 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 72B7D21F865A for ; Wed, 22 Feb 2012 06:49:46 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Wed, 22 Feb 2012 06:49:45 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] SUBMITTER usage Thread-Index: AQHM8SsaN6mQMzFXk0GSWYTYWbMJx5ZJCBUA//98S7CAAKwWAP//zcYw Date: Wed, 22 Feb 2012 14:49:45 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392803E458@exch-mbx901.corp.cloudmark.com> References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> <2540299.gmSuznFx9K@scott-latitude-e6320> <4F42C605.9000907@isdg.net> <4F4312EA.9080206@isdg.net> <4F448AE6.5000605@isdg.net> <7F7F36E50398F84DBAF25C9D51732F1E204B3CB4@TK5EX14MBXC203.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E00392803B991@exch-mbx901.corp.cloudmark.com> <4F44B89C.9040803@isdg.net> In-Reply-To: <4F44B89C.9040803@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SUBMITTER usage X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 14:49:47 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Hector Santos > Sent: Wednesday, February 22, 2012 1:43 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] SUBMITTER usage >=20 > This buddy-buddy system at the exclusion of others has got to stop. Your data haven't been excluded. They're already in the report. > Quick review of the cached DNS queries I have: >=20 > 3426 : cached TXT records (request) > 2783 : with v=3Dspf1 > 82 : with spf2.0 include INVALID ones (I believe, see below) > 10 spf2.0/mfrom > 72 spf2.0/pra So that's over 97% SPF, with fewer than 3% using spf2.0, and even less than= that doing PRA. That's consistent with the other data that have been coll= ected so far. Since SUBMITTER is only input to Sender-ID, as Scott pointed out, its meani= ngful use is quite small. But your data also point out that there's some b= lind opportunistic use of it, which is also worth reporting. > Even as I sure you will label me as a SMALL system, even as a small > system there is over 80% usage of spf2.0/pra for SIDF. > To continue contemplating getting rid of it in SPF-BIS, would represent a= serious > problem. That's not what your data say. They say that among spf2.0 records, there's= substantial use of PRA. But that's only within a very small fraction of y= our overall DNS observations, which vastly favour SPF. -MSK From hsantos@isdg.net Wed Feb 22 07:03:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEF821F87CA for ; Wed, 22 Feb 2012 07:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8vH-9Ld1eBI for ; Wed, 22 Feb 2012 07:03:07 -0800 (PST) Received: from mail.santronics.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 490CF21F87B9 for ; Wed, 22 Feb 2012 07:03:07 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2895; t=1329922978; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=9CfspTf/tiqkB2qf2OwWE9H5iVQ=; b=SzrL6uCTkOdixgkKqjLy CFQ8MAndbmmsB3TAOTvK1iLwTUAKVPVrmNLS7uw8rbmA3ryII5mgCLL2JsOGCljw cZ//HzapRkqwFQY7Rum9SI/fbVek1fFFHFxQfaXhVzjD02aDAyeXq0KIpNltFZQT H5V6B4pJ8//xn3WmEnfS/6k= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 10:02:58 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3124822802.88546.2716; Wed, 22 Feb 2012 10:02:57 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2895; t=1329922738; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=gQhIJLu V9nq88YXxqHRzov5NbGw49v1SkeibiCj943U=; b=kRYNEbbf76F+FjUoik/tvBA ENVbS+xlRVo+TsjDQ5frBH5PiRvULiSTW1eyWszm75fvnyj4hj7ihDyg2Y9Nggc5 Ty7o66vnGCFQ3AtGRBsFw/Ip0+n/r4dwz65cA/IBKgln/yH6eV64PnctDm7fN21V xXbnms8xO+LH0UovFHX8= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 09:58:58 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3723761626.18876.6164; Wed, 22 Feb 2012 09:58:58 -0500 Message-ID: <4F4503B1.6000202@isdg.net> Date: Wed, 22 Feb 2012 10:03:13 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> <2540299.gmSuznFx9K@scott-latitude-e6320> <4F42C605.9000907@isdg.net> <4F4312EA.9080206@isdg.net> <4F448AE6.5000605@isdg.net> <7F7F36E50398F84DBAF25C9D51732F1E204B3CB4@TK5EX14MBXC203.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E00392803B991@exch-mbx901.corp.cloudmark.com> <4F44B89C.9040803@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SUBMITTER usage X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 15:03:13 -0000 > FWIW, I don't think anyone is ignoring anyone, but I do think you're venturing > beyond the charter regularly, so it's no surprise such excursions don't generate > a lot of positive feedback. > Seem to be wrong on several levels and its unfortunate, that you found it very convenient to state this ad nauseam attack. Its unfortunate but perfectly understood why you would be part of this conflict of interest chorus. It only puts one on the defensive.. Damn if you, damn if you don't. You are not very convincing just say "Forget about it." 1) You are assuming the chartered was correct to begin with, yet it has conflict of interest problems and voicing this concern is used against you. 2) You have an unproven belief for a lack of interest in SIDF/SUBMITTER and that there never existed any well conceived integrated association since MARID with SPF and SIDF/SUBMITTER, and 3) You have critical presumptuous this belief will not have any repercussions. > Since v=spf1 records are considered valid for PRA evaluations by Sender ID you > can't conclude anything based on your data. Sure we can. I didn't include v=spf1 and your you over 80% of the SPF2.0 records are indeed PRA, a false claim you made that it isn't support. But even better to lump v=spf1 and that means even clearer you have no right to be dictating abandonment. > The fact that Sender ID is forced on SPF record publishers confuses things further. So getting right it is your solution? > To gauge actual interest in Sender ID, you have to have some > mechanism for determining what fraction of the participation is based > on consensual interest. I've no idea how to do that. Huh? You can clearly measure it just look by seeing what multiple strings are included in TXT records. If it has only a SPF2.0 string then the INTENT and INTEREST is quite clear, > You can't separate SUBMITTER from PRA, Again HUH? > so absent some groundswell of support for some future working group to deal with > Sender ID, there's no point in worrying about SUBMITTER. Sorry to disagree with this sort of subjective mandate to ignore what exist in practice simply because you have what appears to be a lack of feel for its adoption. Thats simply not right. I stand ethical principles and whats going is here is a conflict on my principles. You have absolute no right to be dictating what existing implementations should do, they can't just "Forget about it", including to support a belief no cost and support burden will not exist, all when you seem to be doing this purely on conjecture and no real feel for its support. No amount of data isn't convince you or others wanting to get rid of it, and certainly proof of support shown by me is thrown by the waste side. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Wed Feb 22 07:09:30 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FBA21F8707 for ; Wed, 22 Feb 2012 07:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 ykIHh8Z6vzpK for ; Wed, 22 Feb 2012 07:09:25 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B07D521F86E0 for ; Wed, 22 Feb 2012 07:09:23 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DE8EF20E40CC; Wed, 22 Feb 2012 10:09:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329923362; bh=ZwA7+KTLtpsSrGQvJtZ7FARdm04f4ZGKgZ1yB0bPWg0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=XPMnqCAUYnIdha3QwxdcXO4hej1xXLY79oaiP8DRjs/nUfiRoz1GWqAXPmJ81ahWz lkJ+aoS7WAvNj5eYr/jmvEUyicbS/cpBSVcccdUZhKgtYSJgFqiTXe39BfrhBGTXMD ZnibTZM2SSOCMDvDvYJGOeRnK3f+H/AmHgWTQJpI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BF4CD20E4064; Wed, 22 Feb 2012 10:09:22 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Feb 2012 10:09:21 -0500 Message-ID: <1421922.FmWU0zJib9@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F4503B1.6000202@isdg.net> References: <4F4503B1.6000202@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SUBMITTER usage X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 15:09:30 -0000 On Wednesday, February 22, 2012 10:03:13 AM Hector Santos wrote: > > You can't separate SUBMITTER from PRA, > > Again HUH? Have you read RFC 4405? See paragraph 4.1 of that document. It starts: The purpose of the SUBMITTER parameter is to allow the SMTP client to indicate to the server the purported responsible address of the message directly in the RFC 2821 protocol. That's it's only purpose. It is absolutely and completely unrelated to SPF. It is, in fact, a mechanism assist in not doing SPF. End of discussion from my POV. Scott K From hsantos@isdg.net Wed Feb 22 07:50:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E0121F8808 for ; Wed, 22 Feb 2012 07:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.440, 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 5iXzq6P8bm7x for ; Wed, 22 Feb 2012 07:50:01 -0800 (PST) Received: from mail.santronics.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 50C7A21F8518 for ; Wed, 22 Feb 2012 07:50:01 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3649; t=1329925798; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=HrBBTMy4wgcrqaqzyi3Ox0pH6Qk=; b=Jiui3tzTnqnc693+giT0 +NrUPFHvNvFEMve4L/x71Oga+W1Rdsig4HQOkB4gjjt4DlkD4ti1zBZQiQHJMVzb CoOV/Fcz+Ov7ZHCmEGVOZyAUlS3lXdHmFQN1sl/eGGTGDbAmQT1FZy/3JvawvCe2 PLHRHXBKHdw1l1BSetTX61g= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 10:49:58 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3127642863.88546.3080; Wed, 22 Feb 2012 10:49:57 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3649; t=1329925556; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=qlmo0F0 5eJS+r/yMGRweF0xzmBWh5LqCDWGfpjVtWTE=; b=RmDM1NbyGkSUPOxbcnGg4Ok lPJp+GM3a1dtRZZY0FmeaGVZ7WeWwIKz2Ok4zC82Q1kQETBCW0dkpQMAX02IiFWn eByWuJhbd5gx6mCv1Zmtfd4aQUk1YNTb4wKbPjWhQMCh4b4j7TfL6FYdiUAMGQw0 Z9lN9LypKuFmAvcZCpPU= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 10:45:56 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3726579361.18878.3732; Wed, 22 Feb 2012 10:45:55 -0500 Message-ID: <4F450EB2.4040305@isdg.net> Date: Wed, 22 Feb 2012 10:50:10 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <4F4503B1.6000202@isdg.net> <1421922.FmWU0zJib9@scott-latitude-e6320> In-Reply-To: <1421922.FmWU0zJib9@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] SUBMITTER usage X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 15:50:07 -0000 Scott Kitterman wrote: > On Wednesday, February 22, 2012 10:03:13 AM Hector Santos wrote: >>> You can't separate SUBMITTER from PRA, >> Again HUH? > > Have you read RFC 4405? > > See paragraph 4.1 of that document. It starts: > > The purpose of the SUBMITTER parameter is to allow the SMTP client to > indicate to the server the purported responsible address of the > message directly in the RFC 2821 protocol. > > That's it's only purpose. It is absolutely and completely unrelated to SPF. How you jump to this conclusion is breath taken. > It is, in fact, a mechanism assist in not doing SPF. > > End of discussion from my POV. HA! Consensus by Osmosis! Wonderful! Its only the beginning too! Sorry, absolutely not, your POV is ignorant of its origins. Shows a lack of understand of the protocol and reasons for implementation. To conveniently avoid key points, including this: 6. Security Considerations This extension provides an optimization to allow an SMTP client to identify the responsible submitter of an e-mail message in the SMTP protocol, and to enable SMTP servers to perform efficient validation of that identity before the message contents are transmitted. Providing feedback of a major concern in MARID on the PAYLOAD burden SIDF promoted on SPF supported systems, but more importantly section 4.2 describing the mechanism peppered with SENDER-ID methods information: 4.2. Processing the SUBMITTER Parameter Receivers of e-mail messages sent with the SUBMITTER parameter SHOULD select the domain part of the SUBMITTER address value as the purported responsible domain of the message, and SHOULD perform such tests, including those defined in [SENDER-ID], as are deemed necessary to determine whether the connecting SMTP client is authorized to transmit e-mail messages on behalf of that domain. If these tests indicate that the connecting SMTP client is not authorized to transmit e-mail messages on behalf of the SUBMITTER domain, the receiving SMTP server SHOULD reject the message and when rejecting MUST use "550 5.7.1 Submitter not allowed." If the receiving SMTP server allows the connecting SMTP client to transmit message data, then the server SHOULD determine the purported responsible address of the message by examining the RFC 2822 message headers as described in [PRA]. If this purported responsible address does not match the address appearing in the SUBMITTER parameter, the receiving SMTP server MUST reject the message and when rejecting MUST use "550 5.7.1 Submitter does not match header." If no purported responsible address is found according to the procedure defined in [PRA], the SMTP server SHOULD reject the message and when rejecting MUST use "554 5.7.7 Cannot verify submitter address." All and all, you still use SENDER-ID logic but now at the SMTP level. This SENDER-ID method is fundamentally the same method as SPF, same namespace, but a different tag, just a set of different rule. How anyone can say the two technologies are not related when SPF2.0 is basically the same SPF1 under certain conditions, is very odd to me. With SUBMITTER, it simply does the same but without needing the payload. To suggest is "completely unrelated" is patently technical false and your desire to avoid the issue by ignoring it, is just not right if you intent is to kill SIDF/SUBMITTER. All I am reading from you is a lack of feel for the protocols that you probably never supported before. So no feel for it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From sm@elandsys.com Wed Feb 22 08:14:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B4021F8809 for ; Wed, 22 Feb 2012 08:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywgUaabd5Yl8 for ; Wed, 22 Feb 2012 08:14:33 -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 E57DB21F86E0 for ; Wed, 22 Feb 2012 08:14:31 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.232.96]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1MGEAKc025238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 08:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329927263; i=@elandsys.com; bh=ZlzTHcAND8no/W0rWy6DbqtUhQvEVbtNX1X5ytyZt10=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=2XkQ/jCQJuDcaK+9Qb46AqD8epDXZWEwRcOjF9gZWH+YPLrYpf8JL4CJHydu8EuKS 6DnwoO4AYFlBLbXBG7cdECbGPfiKK2k2OjcymWAzFEaI3L3ipPi+CE7YCwaafU/nCx DYc7vmO1JcOwxfyR0XVU8rRDeaw3c9NUI5itOhJE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329927263; i=@elandsys.com; bh=ZlzTHcAND8no/W0rWy6DbqtUhQvEVbtNX1X5ytyZt10=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=MU0f3vdNO3JSltfbOnRudqc7IBL5EgXEASjCBIATIeQpvfsk7YIKC8I108+stRV1W Ycb3Uiy/VQk+D3lWQMYrqma/aTLPpNt88SeJKScBKDTygHjyww6/X+yFo8zLDNEGRj q2WiYATTF5V2/htNW+96xJwo4atntIywZw0gswyw= Message-Id: <6.2.5.6.2.20120222074316.0a813b90@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Feb 2012 08:14:08 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1421922.FmWU0zJib9@scott-latitude-e6320> References: <4F4503B1.6000202@isdg.net> <1421922.FmWU0zJib9@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: [spfbis] Off-topic threads (was: SUBMITTER usage) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 16:14:40 -0000 Hello, The thread about "SUBMITTER usage" is off-topic. Discussing about Issues #2, #3, #8, and #9 is on-topic: http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html http://www.ietf.org/mail-archive/web/spfbis/current/msg00439.html http://www.ietf.org/mail-archive/web/spfbis/current/msg00441.html http://www.ietf.org/mail-archive/web/spfbis/current/msg00442.html Requests for data relevant to the SPFBIS work and providing data is on-topic. I recommend that Working Group participants read the SPFBIS Charter ( https://datatracker.ietf.org/wg/spfbis/charter/ ). The issues in the tracker can be read at http://trac.tools.ietf.org/wg/spfbis/trac/report/1 Please do not start any off-topic thread as it is a distraction from the threads on which the WG Chairs have requested input. If you have any questions about the above, please email the WG Chairs. Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Wed Feb 22 08:33:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788F721F8826 for ; Wed, 22 Feb 2012 08:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 yaTXxReIJYJp for ; Wed, 22 Feb 2012 08:33:06 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 24E3421F881A for ; Wed, 22 Feb 2012 08:33:05 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 618B120E40CC; Wed, 22 Feb 2012 11:33:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329928385; bh=3AAnhMlVtg7TzCARVR1yyebo0dHR+3wvjsMeg6h3PEU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=APhp8I8+l3wUagBLL09AohyLeoOA+NfaSUwYKB7/yEnuM88CJ2hx1pzb1wTicZ6fz jZfcU605CjjHF+YvLwpsAmEx9AM7L1ClSmxzI/rDbBCmQIQ6rF3A6vDQr+mgaNKGi0 6UVmPz4mO0Hx7kSxO6v90eVnYypgX8lXOpjetk98= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 44AED20E408E; Wed, 22 Feb 2012 11:33:05 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Feb 2012 11:32:59 -0500 Message-ID: <16837068.SztWxPR6Id@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 16:33:10 -0000 On Monday, February 20, 2012 09:00:39 AM S Moonesamy wrote: ... > "This may be a can of worms, but since we're chartered to tidy up > where appropriate, I wonder if this might be such a spot. > > RFC4408 registered a new DNS RRtype, SPF, code 99. > > Are we able to tell how much deployment it's received? If only > little (which is what I suspect, but I've no data to back that up), > would it be appropriate to relegate its discussion to an appendix and > call it "historic"?" ... Since discussion on this seems to have died down and we've a dearth of other on topic topics to talk about, I'll attempt a summary (I know there is still data collection going on, but I think it's reasonable to assume that they will confirm the current sense that deployment is miminal). It seems to me that the group is in favor of deprecating type SPF. We can call it historic, but since the RRtype will still be assigned, it could be used if there were ever a non-backward compatible update to SPF. Any objections to that as a sense of the group? Scott K From ajs@crankycanuck.ca Wed Feb 22 08:28:53 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F9521F8830 for ; Wed, 22 Feb 2012 08:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344, 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 KS8j5CnXp3xl for ; Wed, 22 Feb 2012 08:28:53 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id DE4D721F8802 for ; Wed, 22 Feb 2012 08:28:52 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B69D31ECB41D for ; Wed, 22 Feb 2012 16:28:51 +0000 (UTC) Date: Wed, 22 Feb 2012 11:28:41 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120222162826.GA36084@crankycanuck.ca> References: <4F4503B1.6000202@isdg.net> <1421922.FmWU0zJib9@scott-latitude-e6320> <4F450EB2.4040305@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F450EB2.4040305@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 22 Feb 2012 08:35:21 -0800 Subject: [spfbis] WG comportment (was: SUBMITTER usage) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 16:28:53 -0000 Dear colleagues, This message is about WG operation. It is a reminder about how we will comport ourselves on this list. I'm hanging this on Hector's message, but it's a general reminder. On Wed, Feb 22, 2012 at 10:50:10AM -0500, Hector Santos wrote: > > HA! Consensus by Osmosis! Wonderful! Its only the beginning too! The moderators of this list are not going to tolerate rants and sarcastic comments. Please restrain yourselves. > Providing feedback of a major concern in MARID on the PAYLOAD burden As an official matter, we don't know what MARID concluded because none of the RFCs were in fact output of the WG. Claims about MARID and what that WG was interested in are completely off-topic here: that was another WG at another time, and this WG does not have the same charter. Please do not attempt to use claims about what MARID wanted, said, thought, or whatever in these discussions. One can have a legitimate discussion about whether SUBMITTER is relevant to ending the SPF experiment. But one has to stay on-topic to do it, please. For this WG to be productive, we must all discipline ourselves to ensure that our emotions do not get the better of us, and your chairs will step in at the first sign that the conversation is crossing that line. Remember, too, that email does not come with all of the additional clues that in-person communication does; please write accordingly. If you are inclined to send a message, consider it twice before sending: sometimes an argument can be made at once more neutral and technically stronger. Finally, we very strongly oppose direct personalization of the discussion; please don't do it. Thanks and best regards, A (as moderator) -- Andrew Sullivan ajs@crankycanuck.ca From hsantos@isdg.net Wed Feb 22 08:47:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF62121F862B for ; Wed, 22 Feb 2012 08:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.704 X-Spam-Level: X-Spam-Status: No, score=-1.704 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EQAbxTEmbih for ; Wed, 22 Feb 2012 08:47:17 -0800 (PST) Received: from catinthebox.net (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2398E21F854B for ; Wed, 22 Feb 2012 08:47:17 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1443; t=1329929228; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=W1418p2YcIuL2GHxeEXSg+7/Vck=; b=J+JOyYjXx2E+qAhlO+Mm ilIZU1W2jDuvkaYuuspTa6+nAdZ5lOs1lP0B290IfEVSF6Mcj28N2ajpmWaazs1P mnpN1PIX0hmnuyqoxgMg/Eg21N2Q2Ub9UlShOqrRe55qXOxYOTOfDQelPSmG1bjR zJEJjlXEtx47zCKjQcqczZg= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 11:47:08 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3131072966.88546.3392; Wed, 22 Feb 2012 11:47:07 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1443; t=1329928986; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=aXz9x+i 8iy4/etAjgKkUsa7uLQGeNJt4s65KYQ3W89Q=; b=N761cuJIFfNkpGKI4QXtYEt PIz9qJtxQoWhEQ8sM9dSKKv4iotTasCKNYrfN2x6JyjT44NnF2GeCBAr2i1INMT/ YF3QaYOc/C0n1AFPZn76hfc2ElYqWIyXSq8anqe4Kv4Pzeen258zg8w+fwkveR+l n1oltKSpvvKJHtv9PM8o= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 11:43:06 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3730008658.18881.6368; Wed, 22 Feb 2012 11:43:05 -0500 Message-ID: <4F451C18.8010109@isdg.net> Date: Wed, 22 Feb 2012 11:47:20 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> <16837068.SztWxPR6Id@scott-latitude-e6320> In-Reply-To: <16837068.SztWxPR6Id@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 16:47:21 -0000 Scott Kitterman wrote: > On Monday, February 20, 2012 09:00:39 AM S Moonesamy wrote: > ... >> "This may be a can of worms, but since we're chartered to tidy up >> where appropriate, I wonder if this might be such a spot. >> >> RFC4408 registered a new DNS RRtype, SPF, code 99. >> >> Are we able to tell how much deployment it's received? If only >> little (which is what I suspect, but I've no data to back that up), >> would it be appropriate to relegate its discussion to an appendix and >> call it "historic"?" > ... > > Since discussion on this seems to have died down and we've a dearth of other > on topic topics to talk about, I'll attempt a summary (I know there is still > data collection going on, but I think it's reasonable to assume that they will > confirm the current sense that deployment is miminal). > > It seems to me that the group is in favor of deprecating type SPF. We can > call it historic, but since the RRtype will still be assigned, it could be > used if there were ever a non-backward compatible update to SPF. > > Any objections to that as a sense of the group? > Then why bother marking as deprecated and cause more work in the future? I object to the idea SPF can not use a special RR nor the idea it can't be further explored with high reliability that will exist today. -1 on dropping it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From dhc2@dcrocker.net Wed Feb 22 08:58:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74A221F88BB for ; Wed, 22 Feb 2012 08:58:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3sb3pu4qwdC for ; Wed, 22 Feb 2012 08:58:15 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 79E1221F88CE for ; Wed, 22 Feb 2012 08:58:15 -0800 (PST) Received: from [10.101.2.93] (64.1.211.245.ptr.us.xo.net [64.1.211.245]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1MGw975013575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Feb 2012 08:58:15 -0800 Message-ID: <4F451E9C.6070308@dcrocker.net> Date: Wed, 22 Feb 2012 08:58:04 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> <16837068.SztWxPR6Id@scott-latitude-e6320> In-Reply-To: <16837068.SztWxPR6Id@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]); Wed, 22 Feb 2012 08:58:15 -0800 (PST) Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 16:58:19 -0000 On 2/22/2012 8:32 AM, Scott Kitterman wrote: > It seems to me that the group is in favor of deprecating type SPF. We can > call it historic, but since the RRtype will still be assigned, it could be > used if there were ever a non-backward compatible update to SPF. I think the summary is accurate. I don't know whether the registry can be changed to deprecate the type, but I suspect it can. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Wed Feb 22 09:00:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6249621F8711 for ; Wed, 22 Feb 2012 09:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 c4RqliHMQ+xS for ; Wed, 22 Feb 2012 09:00:18 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B7FBF21F869A for ; Wed, 22 Feb 2012 09:00:15 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4EEFF20E40CC; Wed, 22 Feb 2012 12:00:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329930015; bh=HE4ZUj9bWY1O60thrDQIpNKub7cuZF44rPmBSURmEkQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=f8r3rb08L2yGss/pTuxfTw9Mq4TzdMfPpFqvR+E9lrASbvd7c0OgAKvq3GEPv/LF6 J4OqpYDdWGfzts/+ArZwk+/WN9mXj2LrbGO4581gNVQ54+DfRPvAjkdnJh1kirX/Mg dxVy9CoKoRCLG9Z1YNDAPsf2AF6b5PMeR43vCS+g= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3523220E408E; Wed, 22 Feb 2012 12:00:15 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Feb 2012 12:00:14 -0500 Message-ID: <1513816.AxASRzrfi1@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F451E9C.6070308@dcrocker.net> References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <16837068.SztWxPR6Id@scott-latitude-e6320> <4F451E9C.6070308@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 17:00:23 -0000 On Wednesday, February 22, 2012 08:58:04 AM Dave CROCKER wrote: > On 2/22/2012 8:32 AM, Scott Kitterman wrote: > > It seems to me that the group is in favor of deprecating type SPF. We > > can call it historic, but since the RRtype will still be assigned, it > > could be used if there were ever a non-backward compatible update to > > SPF. > I think the summary is accurate. > > I don't know whether the registry can be changed to deprecate the type, but > I suspect it can. Even if it can't, we can mark it SHOULD NOT use in 4408bis. Scott K From spf2@kitterman.com Wed Feb 22 09:00:34 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD2921F8683 for ; Wed, 22 Feb 2012 09:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 mSXNKCKwPKJo for ; Wed, 22 Feb 2012 09:00:30 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id F207521F85B1 for ; Wed, 22 Feb 2012 09:00:29 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8A61520E40CC; Wed, 22 Feb 2012 12:00:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329930029; bh=Ak1vd3v2CMxXVvRve/VmoJEX4AZHA2T5ifmucefC4mc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=n/Xi4M1Or5RBGbkDNTQqbTd+5pggEgm8trAZcStOo1452nJ/FGoXIPelMwHFCC+i2 jX34wI+AR6QybJD9XfI1mvh/IEMCunwHfcvwKNqT+rQY1KIzh65dX7s3DnhBoTZBjM 4b5+TmJsnGxyx3ciywKAXxIf4lgEcWmMzYaG0xpc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7E5D420E408E; Wed, 22 Feb 2012 12:00:29 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Feb 2012 12:00:29 -0500 Message-ID: <6246334.FqMxilYyF0@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F451C18.8010109@isdg.net> References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <16837068.SztWxPR6Id@scott-latitude-e6320> <4F451C18.8010109@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 17:00:34 -0000 On Wednesday, February 22, 2012 11:47:20 AM Hector Santos wrote: > Scott Kitterman wrote: > > On Monday, February 20, 2012 09:00:39 AM S Moonesamy wrote: > > ... > > > >> "This may be a can of worms, but since we're chartered to tidy up > >> where appropriate, I wonder if this might be such a spot. > >> > >> RFC4408 registered a new DNS RRtype, SPF, code 99. > >> > >> Are we able to tell how much deployment it's received? If only > >> little (which is what I suspect, but I've no data to back that up), > >> would it be appropriate to relegate its discussion to an appendix and > >> call it "historic"?" > > > > ... > > > > Since discussion on this seems to have died down and we've a dearth of > > other on topic topics to talk about, I'll attempt a summary (I know > > there is still data collection going on, but I think it's reasonable to > > assume that they will confirm the current sense that deployment is > > miminal). > > > > It seems to me that the group is in favor of deprecating type SPF. We > > can call it historic, but since the RRtype will still be assigned, it > > could be used if there were ever a non-backward compatible update to > > SPF. > > > > Any objections to that as a sense of the group? > > Then why bother marking as deprecated and cause more work in the future? > > I object to the idea SPF can not use a special RR nor the idea it > can't be further explored with high reliability that will exist today. > -1 on dropping it. The reason to mark it deprecated is there's no value in using it and retaining it adds complexity. There's no "high reliability that will exist today". Many implementations either default to not checking RRtype SPF by default or don't support it at all. I took a quick look at pyspf and dropping type SPF only saves about 3 dozen lines of code. Most of the complexity that's avoided by removing it is the operational complexity of having to maintain identical data in two different DNS records. Scott K From dhc2@dcrocker.net Wed Feb 22 09:31:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10ED21F87E8 for ; Wed, 22 Feb 2012 09:31:05 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qwbLfEOaAyo for ; Wed, 22 Feb 2012 09:31:01 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C08CD21F87DA for ; Wed, 22 Feb 2012 09:31:01 -0800 (PST) Received: from [10.101.2.93] (64.1.211.245.ptr.us.xo.net [64.1.211.245]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1MHUtoT014199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Feb 2012 09:31:01 -0800 Message-ID: <4F45264A.50106@dcrocker.net> Date: Wed, 22 Feb 2012 09:30:50 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <16837068.SztWxPR6Id@scott-latitude-e6320> <4F451C18.8010109@isdg.net> <6246334.FqMxilYyF0@scott-latitude-e6320> In-Reply-To: <6246334.FqMxilYyF0@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]); Wed, 22 Feb 2012 09:31:01 -0800 (PST) Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 17:31:06 -0000 On 2/22/2012 9:00 AM, Scott Kitterman wrote: > The reason to mark it deprecated is there's no value in using it and retaining > it adds complexity. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Wed Feb 22 09:34:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721C221F8610 for ; Wed, 22 Feb 2012 09:34:58 -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 faQ1KqWRTGNe for ; Wed, 22 Feb 2012 09:34:57 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id C586F21F8602 for ; Wed, 22 Feb 2012 09:34:57 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 22 Feb 2012 09:34:57 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #9: RFC 4408 SPF RR type Thread-Index: Aczv8UQLV2N/uDLSRyC+8YNgJDPwqgB0W1qAAACATAAAAHWSgAAPkgkw Date: Wed, 22 Feb 2012 17:34:57 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392803ECD6@exch-mbx901.corp.cloudmark.com> References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <16837068.SztWxPR6Id@scott-latitude-e6320> <4F451C18.8010109@isdg.net> <6246334.FqMxilYyF0@scott-latitude-e6320> In-Reply-To: <6246334.FqMxilYyF0@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.1.211.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 17:34:58 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Wednesday, February 22, 2012 9:00 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #9: RFC 4408 SPF RR type >=20 > The reason to mark it deprecated is there's no value in using it and > retaining it adds complexity. +1. -MSK From pmidge@microsoft.com Wed Feb 22 09:40:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BCE21F8663 for ; Wed, 22 Feb 2012 09:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.819 X-Spam-Level: X-Spam-Status: No, score=-5.819 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQQywNRzXWpm for ; Wed, 22 Feb 2012 09:40:42 -0800 (PST) Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id DA3E821F8648 for ; Wed, 22 Feb 2012 09:40:41 -0800 (PST) Received: from mail108-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 22 Feb 2012 17:40:35 +0000 Received: from mail108-tx2 (localhost [127.0.0.1]) by mail108-tx2-R.bigfish.com (Postfix) with ESMTP id 7FE471803AA; Wed, 22 Feb 2012 17:40:35 +0000 (UTC) X-SpamScore: -33 X-BigFish: VS-33(zz9371I542M1432N4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail108-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail108-tx2 (localhost.localdomain [127.0.0.1]) by mail108-tx2 (MessageSwitch) id 1329932431368750_19295; Wed, 22 Feb 2012 17:40:31 +0000 (UTC) Received: from TX2EHSMHS042.bigfish.com (unknown [10.9.14.249]) by mail108-tx2.bigfish.com (Postfix) with ESMTP id 4DCAD26004F; Wed, 22 Feb 2012 17:40:31 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS042.bigfish.com (10.9.99.142) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 22 Feb 2012 17:40:29 +0000 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.110]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0247.005; Wed, 22 Feb 2012 17:40:17 +0000 From: Paul Midgen To: "Murray S. Kucherawy" , "spfbis@ietf.org" Thread-Topic: [spfbis] SUBMITTER usage Thread-Index: AQHM8SsdzjJpsX+d6kmbNrMN7BZYLpZIfEPAgAAIwwCAAKkuYA== Date: Wed, 22 Feb 2012 17:40:16 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204B3FD2@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <20120220152601.GI33344@crankycanuck.ca> <4F428A19.4030200@isdg.net> <2540299.gmSuznFx9K@scott-latitude-e6320> <4F42C605.9000907@isdg.net> <4F4312EA.9080206@isdg.net> <4F448AE6.5000605@isdg.net> <7F7F36E50398F84DBAF25C9D51732F1E204B3CB4@TK5EX14MBXC203.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E00392803B991@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392803B991@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] SUBMITTER usage X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 17:40:46 -0000 All our systems that work with SPF records exclusively use TXT queries, the= re are no logged sender support requests, that I'm aware of, asking for typ= e 99 query support. -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: Tuesday, February 21, 2012 11:29 PM To: spfbis@ietf.org Subject: Re: [spfbis] SUBMITTER usage > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On=20 > Behalf Of Paul Midgen > Sent: Tuesday, February 21, 2012 11:18 PM > To: Hector Santos; spfbis@ietf.org > Subject: Re: [spfbis] SUBMITTER usage >=20 > As concerns SUBMITTER: this group is reviewing things that have been=20 > published for 6+ years. If by now there isn't a vocal and deployed=20 > base prepared to share data and operational experience that supports=20 > the inclusion of a given thing, that should carry a bit of weight. >=20 > For 2.5 of those 6 years I've been responsible for Hotmail's inbound=20 > infrastructure, and haven't received a single request to implement=20 > SUBMITTER. Thanks, Paul. If I could ask a bit more of you and your data: While you're gearing up ano= ther SPF/Sender-ID efficacy comparison, is there a way to determine whether= or not your Sender-ID implementation checks type 99 (SPF) DNS records, typ= e 16 (TXT) records, or both? And, if both, can you gauge what the percenta= ges are for each? "No" is a perfectly valid answer if that would be a pain. We already have = one report done and one pending with this information, but a third data set= can't hurt if we can get one. :-) -MSK _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From pmidge@microsoft.com Wed Feb 22 09:43:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46AE21F8621 for ; Wed, 22 Feb 2012 09:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[AWL=-0.791, 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 jXwaG9Tj+XpO for ; Wed, 22 Feb 2012 09:43:33 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 0722121E8034 for ; Wed, 22 Feb 2012 09:43:28 -0800 (PST) Received: from mail189-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Wed, 22 Feb 2012 17:43:22 +0000 Received: from mail189-ch1 (localhost [127.0.0.1]) by mail189-ch1-R.bigfish.com (Postfix) with ESMTP id DD1792A03C4; Wed, 22 Feb 2012 17:43:21 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371I542M1432Nzz1202hzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail189-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail189-ch1 (localhost.localdomain [127.0.0.1]) by mail189-ch1 (MessageSwitch) id 1329932599222249_28843; Wed, 22 Feb 2012 17:43:19 +0000 (UTC) Received: from CH1EHSMHS010.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail189-ch1.bigfish.com (Postfix) with ESMTP id 327A3200045; Wed, 22 Feb 2012 17:43:19 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 22 Feb 2012 17:43:18 +0000 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.110]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0247.005; Wed, 22 Feb 2012 17:43:12 +0000 From: Paul Midgen To: "Murray S. Kucherawy" , "spfbis@ietf.org" Thread-Topic: [spfbis] #9: RFC 4408 SPF RR type Thread-Index: AQHM7/FBRPhDdCzpDkKRLzIkx3pBDpZJH2SAgAAEAgCAAAOtgIAACaGAgAACFkA= Date: Wed, 22 Feb 2012 17:43:12 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204B3FF6@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <16837068.SztWxPR6Id@scott-latitude-e6320> <4F451C18.8010109@isdg.net> <6246334.FqMxilYyF0@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392803ECD6@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392803ECD6@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 17:43:37 -0000 +1 -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: Wednesday, February 22, 2012 9:35 AM To: spfbis@ietf.org Subject: Re: [spfbis] #9: RFC 4408 SPF RR type > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On=20 > Behalf Of Scott Kitterman > Sent: Wednesday, February 22, 2012 9:00 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #9: RFC 4408 SPF RR type >=20 > The reason to mark it deprecated is there's no value in using it and=20 > retaining it adds complexity. +1. -MSK _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From ajs@anvilwalrusden.com Wed Feb 22 10:23:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F91C21F86B8 for ; Wed, 22 Feb 2012 10:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.347 X-Spam-Level: *** X-Spam-Status: No, score=3.347 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, MIME_QP_LONG_LINE=1.396, RCVD_IN_SBL=1.551, RDNS_NONE=0.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 N8X2hIFYWfgW for ; Wed, 22 Feb 2012 10:23:42 -0800 (PST) Received: from pdx-1.yitter.info (unknown [174.140.166.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEF521F86DB for ; Wed, 22 Feb 2012 10:23:40 -0800 (PST) Received: from [10.10.81.69] (216-75-171-32.ded.execulink.com [216.75.171.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ajs@anvilwalrusden.com) by pdx-1.yitter.info (Postfix) with ESMTPSA id 79E71A358086; Wed, 22 Feb 2012 10:23:36 -0800 (PST) References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> <16837068.SztWxPR6Id@scott-latitude-e6320> <4F451E9C.6070308@dcrocker.net> In-Reply-To: <4F451E9C.6070308@dcrocker.net> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <4EAA612F-4C10-4AF7-BF35-BD5052ECF5E0@anvilwalrusden.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9A405) From: Andrew Sullivan Date: Wed, 22 Feb 2012 13:23:28 -0500 To: "dcrocker@bbiw.net" Cc: "spfbis@ietf.org" Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 18:23:46 -0000 Colleagues, With all due respect, I think people might reign in their enthusiasm for mak= ing peremptory consensus calls. Thanks.=20 --=20 Andrew Sullivan=20 Please excuse my clumsy thumbs.=20 On 2012-02-22, at 11:58, Dave CROCKER wrote: >=20 >=20 > On 2/22/2012 8:32 AM, Scott Kitterman wrote: >> It seems to me that the group is in favor of deprecating type SPF. We ca= n >> call it historic, but since the RRtype will still be assigned, it could b= e >> used if there were ever a non-backward compatible update to SPF. >=20 >=20 > I think the summary is accurate. >=20 > I don't know whether the registry can be changed to deprecate the type, bu= t I suspect it can. >=20 > d/ > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From john@jlc.net Wed Feb 22 10:33:24 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA7A21F86E4 for ; Wed, 22 Feb 2012 10:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.406 X-Spam-Level: X-Spam-Status: No, score=-106.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6H0PYehDvnQk for ; Wed, 22 Feb 2012 10:33:24 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id E29B521F86F8 for ; Wed, 22 Feb 2012 10:33:23 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id DEF2A33C27; Wed, 22 Feb 2012 13:33:23 -0500 (EST) Date: Wed, 22 Feb 2012 13:33:23 -0500 From: John Leslie To: Andrew Sullivan Message-ID: <20120222183323.GC5226@verdi> References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> <16837068.SztWxPR6Id@scott-latitude-e6320> <4F451E9C.6070308@dcrocker.net> <4EAA612F-4C10-4AF7-BF35-BD5052ECF5E0@anvilwalrusden.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EAA612F-4C10-4AF7-BF35-BD5052ECF5E0@anvilwalrusden.com> User-Agent: Mutt/1.4.1i Cc: "spfbis@ietf.org" Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 18:33:24 -0000 Andrew Sullivan wrote: > > Colleagues, > > With all due respect, I think people might reign in their enthusiasm > for making peremptory consensus calls. Thanks. +1 We should trust our WGCs to make consensus calls: it's not helpful for others to usurp that role. (BTW, I disagree with calling type 99 "deprecated" or "historic", though I'm perfectly happy for it to be "MAY" status on both publishing and checking.) -- John Leslie From sm@elandsys.com Wed Feb 22 11:07:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DAD21F8652 for ; Wed, 22 Feb 2012 11:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvtgmRP+nr2C for ; Wed, 22 Feb 2012 11:07:08 -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 0CC4221F8637 for ; Wed, 22 Feb 2012 11:07:06 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.232.96]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1MJ6nQa019663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 11:07:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329937622; i=@elandsys.com; bh=GI/DQLC2DwLDSYhAqRBV1vckX1/x0v4kMYoSSAgRIIs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=BhZlXuw/vc2UZIH8anuA8wz+/pZLifZkhP0TYxYaUDe8FOOEcJalG5nulAzhADuet IaCb39Rgw81FpKx1GgzFxwWuAEsJ9dw2eF7Mjn/Mh8Hop4ySs2M1M0euNd0rxzo2Xa ikWcAm69JdueXVMi0PAHzKNEpncPsqs6Zv3mlM10= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329937622; i=@elandsys.com; bh=GI/DQLC2DwLDSYhAqRBV1vckX1/x0v4kMYoSSAgRIIs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=zXcHG5W1k4bUtyB1ts26MJITCRfXOfwBBNRaHIwnRF1qT9GXGeq/svyBgEOGjZm+p v74zO6IxqMFCyeWjtkxBgPmA1cRfL7BilQodRH2B+GiCISAVJOBkMmhVMtYp1wMI78 laQNgKrVLEyqaazRLf4GgbJ3REfIWs1CS+nCUUyA= Message-Id: <6.2.5.6.2.20120222100740.0a701c90@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Feb 2012 10:36:32 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <16837068.SztWxPR6Id@scott-latitude-e6320> References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> <16837068.SztWxPR6Id@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 19:07:12 -0000 Hello, In case there is any confusion, I would like it to be clear that the SPFBIS WG Chairs have not made any determination of consensus about Issue #9. It is premature to draw any conclusion at the moment. We are here to listen to the views expressed by all WG participants. The working group will be given ample time to think about the issues and provide comments. When there is a consensus call on this issue, or any other issue, the message about it will be sent by the SPFBIS WG Chairs. If you have any objections about a determination of consensus, you are welcome to raise them. Issue #9 remains open. If you have not commented on it, please do so. If you have already provided comments on Issue #9, there is no need to restate them again as Andrew and I will read all the messages that have been posted about this issue. Regards, S. Moonesamy SPFBIS WG Chair From msk@cloudmark.com Wed Feb 22 11:20:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B143C21F85AE for ; Wed, 22 Feb 2012 11:20:12 -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 pCnphke5t65G for ; Wed, 22 Feb 2012 11:20:11 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id C94B321E8010 for ; Wed, 22 Feb 2012 11:20:11 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 22 Feb 2012 11:20:11 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #9: RFC 4408 SPF RR type Thread-Index: Aczv8UQLV2N/uDLSRyC+8YNgJDPwqgB0W1qAAADgQwAAAvuJAAAAWKmAAA8t1pA= Date: Wed, 22 Feb 2012 19:20:11 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928040741@exch-mbx901.corp.cloudmark.com> References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> <16837068.SztWxPR6Id@scott-latitude-e6320> <4F451E9C.6070308@dcrocker.net> <4EAA612F-4C10-4AF7-BF35-BD5052ECF5E0@anvilwalrusden.com> <20120222183323.GC5226@verdi> In-Reply-To: <20120222183323.GC5226@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.1.211.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 19:20:12 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of John Leslie > Sent: Wednesday, February 22, 2012 10:33 AM > To: Andrew Sullivan > Cc: spfbis@ietf.org > Subject: Re: [spfbis] #9: RFC 4408 SPF RR type >=20 > We should trust our WGCs to make consensus calls: it's not helpful > for others to usurp that role. Yes, that's right of course. Apologies for contributing. There's an apparent undercurrent of being in a hurry to progress or complet= e this work. I'm not sure why. -MSK From johnl@iecc.com Wed Feb 22 11:37:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD61721F86F2 for ; Wed, 22 Feb 2012 11:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.952 X-Spam-Level: X-Spam-Status: No, score=-109.952 tagged_above=-999 required=5 tests=[AWL=1.247, 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 Uhk1YLX2sy7p for ; Wed, 22 Feb 2012 11:37:10 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 17F6B21F86D1 for ; Wed, 22 Feb 2012 11:37:05 -0800 (PST) Received: (qmail 87131 invoked from network); 22 Feb 2012 19:37:04 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Feb 2012 19:37:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f4543df.xn--3zv.k1202; i=johnl@user.iecc.com; bh=bD/6iQ+b30QU2mVWxxymyHrsXX1Q03safHNaWY1HHmk=; b=mxwb03hrX8ZCfXBjfim4c9d9QNTfnnZz4xEYasAZ0puuuIF93eG1ZhaXhJPRL5KhDKEorGUdWLjeQjPk6LFQMj/CeZnMn6i45pR6vBs2jLjJbSrr9F9IdwZuN1c/n7fkD4cYIcBdSmjt02BbFeLxr85NaegmS++MWUUR2msihbU= 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=4f4543df.xn--3zv.k1202; olt=johnl@user.iecc.com; bh=bD/6iQ+b30QU2mVWxxymyHrsXX1Q03safHNaWY1HHmk=; b=0uaC2GsNwAB0D3Qv1AT6CRF5ajouUbo459T8eh/adVLcxjYxXOS0SYCPffZjAhBRBiKViAR35+DstOh6tTez+n0d3/a1O40s7rr9p6BlaZRTDhNpDrEf/EtiKG5Pnl4v/xnChfVPAeaGdVA+/+oe7aAj9SYcFthhmgFzclIG3lI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 22 Feb 2012 19:36:41 -0000 Message-ID: <20120222193641.73783.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E003928040741@exch-mbx901.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: msk@cloudmark.com Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 19:37:10 -0000 Looking at my DNS server logs, I am surprised to see nearly as many requests for type 99 records as for SPF TXT records. I'm collecting data, we can talk about it once we're done putting the issues list together. I am NOT arguing that there's any particular value in publishing type 99 records, but the common perception that nobody checks them seems to be wrong. R's, John From spf2@kitterman.com Wed Feb 22 11:41:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D179D21F862F for ; Wed, 22 Feb 2012 11:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 4R6oza8tjIDk for ; Wed, 22 Feb 2012 11:41:21 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0004721F8569 for ; Wed, 22 Feb 2012 11:41:20 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 646CB20E40CC; Wed, 22 Feb 2012 14:41:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329939680; bh=Lm6SLuKi4nH3z9EpewWx30JnerVDEYFUo7/pt9PSlGU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=J0YiZtz8+WQVSoqltzHD6v3IfNSmz0hpE+R4E5oZNIfNlHPCcHLtBsOEQBwZI4jPk 6oRqt9sa+TOWlLAGgkCMgGpNnWfzF1oK41T5hVjWA7rDanIYFPuDsruCnZz9s5lv9S RwAzAtmKi4YbGvE9YebJ4iSxN/pwAHkrJmulCoM8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4B14E20E408E; Wed, 22 Feb 2012 14:41:20 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Feb 2012 14:41:19 -0500 Message-ID: <2096925.c5NMhqV2Wo@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120222193641.73783.qmail@joyce.lan> References: <20120222193641.73783.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 19:41:22 -0000 On Wednesday, February 22, 2012 07:36:41 PM John Levine wrote: > Looking at my DNS server logs, I am surprised to see nearly as many > requests for type 99 records as for SPF TXT records. I'm collecting > data, we can talk about it once we're done putting the issues list > together. > > I am NOT arguing that there's any particular value in publishing type > 99 records, but the common perception that nobody checks them seems to > be wrong. Mail::SPF (which is used by Spamassassin) checks for Type SPF first by default. I would imagine that accounts for a large fraction of what you're seeing. Myself I've never argued (or never intended to) that no one checked it. I know they are. I also know that they are not consistently checked, so they can't be relied on. The "almost no" arguement I've made is about publishing. I think the fact that there are so many pointless queries for Type SPF argues for getting rid of it. It's a waste. Scott K From msk@cloudmark.com Wed Feb 22 11:50:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F4021F86DC for ; Wed, 22 Feb 2012 11:50:22 -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 2Faj1x3aNtSL for ; Wed, 22 Feb 2012 11:50:21 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A688F21F86DB for ; Wed, 22 Feb 2012 11:50:21 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Wed, 22 Feb 2012 11:50:20 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #9: RFC 4408 SPF RR type Thread-Index: Aczv8UQLV2N/uDLSRyC+8YNgJDPwqgB0W1qAAADgQwAAAvuJAAAAWKmAAA8t1pD//5hAgIAAAUyAgACFHxA= Date: Wed, 22 Feb 2012 19:50:19 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928040A58@exch-mbx901.corp.cloudmark.com> References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> In-Reply-To: <2096925.c5NMhqV2Wo@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.1.211.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 19:50:22 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Wednesday, February 22, 2012 11:41 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #9: RFC 4408 SPF RR type >=20 > Myself I've never argued (or never intended to) that no one checked it. > I know they are. I also know that they are not consistently checked, > so they can't be relied on. >=20 > The "almost no" arguement I've made is about publishing. >=20 > I think the fact that there are so many pointless queries for Type SPF > argues for getting rid of it. It's a waste. My data so far agree with this. There's lots of software that checks, but = fewer than 5% of the SPF or Sender-ID records out there actually publish th= em. If for example the world was full of DKIM verifiers but nobody ever signed,= I think it would be reasonable to conclude that DKIM is also, effectively,= unused. To use another DKIM example, when we revised DKIM to Draft Standa= rd, we dropped the "g=3D" tag because our data showed almost nobody was usi= ng it, even though most or all DKIM verification software knew how to apply= it. -MSK From dhc2@dcrocker.net Wed Feb 22 11:52:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBFB21F86DF for ; Wed, 22 Feb 2012 11:52:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHL1RbMskICl for ; Wed, 22 Feb 2012 11:52:39 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CB72721F86DE for ; Wed, 22 Feb 2012 11:52:39 -0800 (PST) Received: from [10.101.2.93] (64.1.211.245.ptr.us.xo.net [64.1.211.245]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1MJqXco017252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 11:52:38 -0800 Message-ID: <4F45477B.9070502@dcrocker.net> Date: Wed, 22 Feb 2012 11:52:27 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John Levine References: <20120222193641.73783.qmail@joyce.lan> In-Reply-To: <20120222193641.73783.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 22 Feb 2012 11:52:38 -0800 (PST) Cc: spfbis@ietf.org, msk@cloudmark.com Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:52:40 -0000 If it's not to much trouble, it will probably help to have empirical data like this correlate sources and timing. That is, is a query for a type 99 coupled to (and preceding) a query to the corresponding SPF TXT? d/ On 2/22/2012 11:36 AM, John Levine wrote: > Looking at my DNS server logs, I am surprised to see nearly as many > requests for type 99 records as for SPF TXT records. I'm collecting > data, we can talk about it once we're done putting the issues list > together. > > I am NOT arguing that there's any particular value in publishing type > 99 records, but the common perception that nobody checks them seems to > be wrong. > > R's, > John > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Wed Feb 22 11:57:53 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F1621E8010 for ; Wed, 22 Feb 2012 11:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.966 X-Spam-Level: X-Spam-Status: No, score=-109.966 tagged_above=-999 required=5 tests=[AWL=1.233, 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 ZqX9JsB++uIJ for ; Wed, 22 Feb 2012 11:57:52 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 39DB021E800E for ; Wed, 22 Feb 2012 11:57:52 -0800 (PST) Received: (qmail 1164 invoked from network); 22 Feb 2012 19:57:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Feb 2012 19:57:51 -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=4f4548bf.xn--yuvv84g.k1202; i=johnl@user.iecc.com; bh=Lk1O1FyCZcgTNgBg79yU/3pQqjRV61D0LfCjLQZdzkI=; b=Kv4a1UQgIr27js/M2ISAJfShG6ZKDhyvCWC7OlCbb7Rg6kEUETrIaBdyBLAmj9UiMccY3qxyPrN8dgY3GHR4GEdEXZHSu7x1fSAB5pz8wFp0EdofEyUoG7adgtBP+i89CUvAkZak4jw0Qw2p439ibfHNeyO0zk782mga34a5Dnw= 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=4f4548bf.xn--yuvv84g.k1202; olt=johnl@user.iecc.com; bh=Lk1O1FyCZcgTNgBg79yU/3pQqjRV61D0LfCjLQZdzkI=; b=CTEA3Q6YymQVFXrinKACpfghVnGOsU1kKRNEc27HRI3YeypnspXR/4HsudpWHPsUJwG0VLJQaYhfzfNmYf6jKEC2cXaMXFQsMBmfzq/4F0JTzUZAFIHpRuuflrgBQqM1ASGVhLi8+ixRMr3T4/UzOL8UPm9HY0N/OMKYB/P3Tps= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 22 Feb 2012 19:57:29 -0000 Message-ID: <20120222195729.78873.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4F45477B.9070502@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@bbiw.net Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 19:57:53 -0000 In article <4F45477B.9070502@dcrocker.net> you write: >If it's not to much trouble, it will probably help to have empirical data like >this correlate sources and timing. > >That is, is a query for a type 99 coupled to (and preceding) a query to the >corresponding SPF TXT? Give me a few days, I'll see what I can find. Many of my domains actually do publish type 99 records, so I'll have to separate the ones that do and the ones that don't. R's, John From sm@elandsys.com Wed Feb 22 12:05:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D1B21E803F for ; Wed, 22 Feb 2012 12:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJb-t+3L0a0s for ; Wed, 22 Feb 2012 12:04:55 -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 CD0DB21E803D for ; Wed, 22 Feb 2012 12:04:55 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.232.96]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1MK4aNu024001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Feb 2012 12:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329941090; i=@elandsys.com; bh=KK3fzF4gwXr+csavnED+tKsyV1zmmns/f0JWISa8Zk8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=g8KwdV74O85/fvySZzwBjDykLh27R8hD7rADexhnpjFqmIHKeACWexU2wGd4Dc2es LQuUNram4WsCJNvM3KrOGdeBhvOhc3C/QFQQ0lpUQi/i7ccFOohiCuyNwayn3mLVQn vtaZrS89VdzCWQ+6bLdEeSanhm4Mfxhj3PHixE+E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329941090; i=@elandsys.com; bh=KK3fzF4gwXr+csavnED+tKsyV1zmmns/f0JWISa8Zk8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=VkFIRsUdt+y/skbiDnSSLd8fm83A/2UKTTGY3GriIbSFkfWcP47kwlWyQdVTtbNJ9 maQ4fZghgg+r8OIKXod+X/H0jQ815hnvQzQTj8jGEcT+Cm4TDlv6TAXG3pvJy4a2An UuZK9TguJJXlKpbn9yKkmJ9Ryrjpyah4cT9UyUok= Message-Id: <6.2.5.6.2.20120222115949.08f70548@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Feb 2012 12:04:24 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.455654aa40583da61895c644f7120a55@tools.ietf.org> References: <061.455654aa40583da61895c644f7120a55@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 20:05:01 -0000 At 12:56 07-02-2012, spfbis issue tracker wrote: >#1: RFC 4408 Section 2.5.6 - Temporary errors > > Message from Scott Kitterman on 3 Feb 2012: > > TempError is defined in RFC 4408 as: > > 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 DSN > code. > > This is further specified in the check_host() definition: > > 4.4. Record Lookup > > > In accordance with how the records are published (see Section 3.1 > above), a DNS query needs to be made for the name, querying > for either RR type TXT, SPF, or both. If both SPF and TXT RRs are > looked up, the queries MAY be done in parallel. > > If all DNS lookups that are made return a server failure (RCODE 2), > or other error (RCODE other than 0 or 3), or time out, then > check_host() exits immediately with the result "TempError". > > Particularly when querying for SPF records of type SPF, persistent 2 > ServFail > results are not rare. It is my impression that ServFail is a condition > that > generally will require operator intervention to correct. > > The definition of PermError is (partly): > > 2.5.7. PermError > > > A "PermError" result means that the domain's published records could > not be correctly interpreted. This signals an error condition that > requires manual intervention to be resolved, as opposed to the > TempError result. > > I think that RCODE 2 replies should be considered PermError instead of > TempError. > > The operational impact of this is that messages are deferred (4xx) instead > of > rejected (5xx) so they sit in a deferral queue and are retried for however > long the sending MTA is configured to attempt it. The user of the message > isn't notified of the non-delivery until it expires out of the queue, > generally > after several days. > > In the SPF policy server for Postfix that I maintain, I changed the > default > action on TempError from defer as a result of this issue. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00259.html >Ticket URL: Issue #1 is open for discussion. Please review the above and post your comments to this mailing list. As a reminder, please keep the subject line so that it is easier to track the discussion. Regards, S. Moonesamy SPFBIS WG Chair From ajs@anvilwalrusden.com Wed Feb 22 12:08:29 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD67221E803F for ; Wed, 22 Feb 2012 12:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 hQb+AuFYd366 for ; Wed, 22 Feb 2012 12:08:29 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB6321E803D for ; Wed, 22 Feb 2012 12:08:29 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 346BD1ECB41D for ; Wed, 22 Feb 2012 20:08:28 +0000 (UTC) Date: Wed, 22 Feb 2012 15:08:26 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120222200826.GF36315@mail.yitter.info> References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2096925.c5NMhqV2Wo@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 20:08:29 -0000 No hat. On Wed, Feb 22, 2012 at 02:41:19PM -0500, Scott Kitterman wrote: > > The "almost no" arguement I've made is about publishing. > > I think the fact that there are so many pointless queries for Type SPF argues > for getting rid of it. It's a waste. > That would be as strong an argument in favour of _promoting_ the SPF record and saying that implementations SHOULD check for the SPF record unless they already know there is no SPF record present. After all, lots of people didn't used to use MX records either. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Wed Feb 22 12:21:25 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A171F21E804A for ; Wed, 22 Feb 2012 12:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 0bXkzvjup2U3 for ; Wed, 22 Feb 2012 12:21:24 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CBE3121F85E4 for ; Wed, 22 Feb 2012 12:21:24 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4527F20E40CC; Wed, 22 Feb 2012 15:21:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329942084; bh=PbJDWrp1GDVAaftbdhQn13DAuuSYPpsrQdKec0ZLHLo=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=kpO6gCo55WEAKgi8QBxRPAVLFnqWVl3yPKBlGZYZCEbnRI8UtwZHiyb8rsTI1Qdo/ JTyYVClw2o7vumktbBkgmLfcmYSlBC7UBULPkn7zu3ZjbDNhY/IZvpCImMEaeWX363 jjCnXC0OQwp1saAX2Gl+pyfOYiBfCIWDu6/MA8Po= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2C67C20E408E; Wed, 22 Feb 2012 15:21:24 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Feb 2012 15:21:23 -0500 Message-ID: <1393684.knylKaz50c@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120222200826.GF36315@mail.yitter.info> References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 20:21:25 -0000 On Wednesday, February 22, 2012 03:08:26 PM Andrew Sullivan wrote: > No hat. > > On Wed, Feb 22, 2012 at 02:41:19PM -0500, Scott Kitterman wrote: > > The "almost no" arguement I've made is about publishing. > > > > I think the fact that there are so many pointless queries for Type SPF > > argues for getting rid of it. It's a waste. > > That would be as strong an argument in favour of _promoting_ the SPF > record and saying that implementations SHOULD check for the SPF record > unless they already know there is no SPF record present. > > After all, lots of people didn't used to use MX records either. RFC 4408 already says that type SPF should be checked and that it should be published. Despite doubts about if a transition to type SPF could ever be made (IMO both those SHOULD statements were statements of bold optimism) the SPF community has solidly supported type SPF. Within a week of Type 99 being allocated to Type SPF there were open source implementations of SPF checking libraries that would check it. In fact, community testing between the IANA assignment and the author's 48 hour review prior to RFC 4408 publication identified some interoperability issues with multiple DNS RR types carrying the same information that were corrected prior to RFC 4408's publication. Even with this support, Type SPF has little traction operationally and there is no basis to expect this to change. Given that, the best thing we can do is encourage receivers not to do these pointless queries. There is an operational benefit to using MX records. As we've discussed, there isn't one for Type SPF. Scott K From ajs@anvilwalrusden.com Wed Feb 22 12:44:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CB821E800F for ; Wed, 22 Feb 2012 12:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 Rajp+r-38NV3 for ; Wed, 22 Feb 2012 12:44:03 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 324E021E800E for ; Wed, 22 Feb 2012 12:44:03 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7EE751ECB41D for ; Wed, 22 Feb 2012 20:44:02 +0000 (UTC) Date: Wed, 22 Feb 2012 15:44:00 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120222204359.GH36315@mail.yitter.info> References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <1393684.knylKaz50c@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1393684.knylKaz50c@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 20:44:03 -0000 No hat. On Wed, Feb 22, 2012 at 03:21:23PM -0500, Scott Kitterman wrote: > There is an operational benefit to using MX records. As we've discussed, there > isn't one for Type SPF. That was actually not the conclusion I reached from that discussion. What I recall concluding was that, in the absence of people actually doing the lookup, it was going to be pretty hard to argue that there was any benefit to it. If the actual deployed software does the SPF lookup first, then there certainly is an operational benefit from deploying SPF records: you cut your negative queries out dramatically. DNS admins like to cut needless queries. Moreover, if the bulk of the deployed code sends SPF first, then just adding an SPF record would be a pain-free way to cut down all those extra queries. You'd reduce the pointless SPF validation queries that your consumers send, too. And you'd have a guarantee that other semantics couldn't trample on your RR's semantics. Seems like operational benefit to me. What do you see differently? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Wed Feb 22 12:49:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5585021F8637 for ; Wed, 22 Feb 2012 12:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 5W9TE+orfSHt for ; Wed, 22 Feb 2012 12:49:51 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECC121F862D for ; Wed, 22 Feb 2012 12:49:51 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AEADC20E40CC; Wed, 22 Feb 2012 15:49:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329943790; bh=Emy+RSU3irUd2aYsVp+zxgb1yeHcHsAYQbf7q+Ucrls=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Bu3fVzGCmlzpUi3IaAumYpbebRjIP7gDxp2dAiiCl1nnmZ/0uS/HaJBRyvTGzNFny xcMOl5x2sLt8IDDPaIIMARzBSIPgtBKp7y9xkbsdtH5i8H5I3lHZKiOW3m3CsIWlcn u21J2uafnWOnh/aSPZ9CsErRg8HNMqHiGKAUIh/U= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9039220E408E; Wed, 22 Feb 2012 15:49:50 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Feb 2012 15:49:49 -0500 Message-ID: <2727826.6qhuk3IDji@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120222204359.GH36315@mail.yitter.info> References: <20120222193641.73783.qmail@joyce.lan> <1393684.knylKaz50c@scott-latitude-e6320> <20120222204359.GH36315@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 20:49:52 -0000 On Wednesday, February 22, 2012 03:44:00 PM Andrew Sullivan wrote: > No hat. > > On Wed, Feb 22, 2012 at 03:21:23PM -0500, Scott Kitterman wrote: > > There is an operational benefit to using MX records. As we've > > discussed, there isn't one for Type SPF. > > That was actually not the conclusion I reached from that discussion. > What I recall concluding was that, in the absence of people actually > doing the lookup, it was going to be pretty hard to argue that there > was any benefit to it. > > If the actual deployed software does the SPF lookup first, then there > certainly is an operational benefit from deploying SPF records: you > cut your negative queries out dramatically. DNS admins like to cut > needless queries. Moreover, if the bulk of the deployed code sends > SPF first, then just adding an SPF record would be a pain-free way to > cut down all those extra queries. You'd reduce the pointless SPF > validation queries that your consumers send, too. And you'd have a > guarantee that other semantics couldn't trample on your RR's > semantics. > > Seems like operational benefit to me. What do you see differently? I was looking at it from the other end. There's no operational benefit to doing the query and so the fact that a lot of software does it wastes resources on both ends since so few records are published. Even if one has the necessary infrastructure support for publishing type SPF records (I'm not aware of any commercial DNS providers that support or nor do I think standard control panel packages support it) there is the added complexity of managing two sets of records that have to be kept identical. I think, from a record publisher POV that more than offsets not having the additional TXT lookup. In any case, I think the market has spoken. Despite broad support for the new RR type, it just hasn't caught on and I don't think it's going to. Scott K From dhc2@dcrocker.net Wed Feb 22 12:54:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A97E21F85D5 for ; Wed, 22 Feb 2012 12:54:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aygsQOna05Tk for ; Wed, 22 Feb 2012 12:54:29 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3299921F85D1 for ; Wed, 22 Feb 2012 12:54:25 -0800 (PST) Received: from [10.101.2.93] (64.1.211.245.ptr.us.xo.net [64.1.211.245]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1MKsIgB018500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Feb 2012 12:54:24 -0800 Message-ID: <4F4555F5.1090301@dcrocker.net> Date: Wed, 22 Feb 2012 12:54:13 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> In-Reply-To: <20120222200826.GF36315@mail.yitter.info> 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]); Wed, 22 Feb 2012 12:54:24 -0800 (PST) Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 20:54:32 -0000 On 2/22/2012 12:08 PM, Andrew Sullivan wrote: > No hat. > > On Wed, Feb 22, 2012 at 02:41:19PM -0500, Scott Kitterman wrote: >> >> The "almost no" arguement I've made is about publishing. >> >> I think the fact that there are so many pointless queries for Type SPF argues >> for getting rid of it. It's a waste. >> > > That would be as strong an argument in favour of _promoting_ the SPF > record and saying that implementations SHOULD check for the SPF record > unless they already know there is no SPF record present. > > After all, lots of people didn't used to use MX records either. A history of non-use rarely provides a strong argument for coercive legislation. (The OSI folks misunderstood this.) Adoption is driven by need. The MX record and port 587 are good examples of this. Their adoption increased when the community started seeing benefits. The record has yet to show a benefit in adoption of the special SPF RR and, hence, failed to gain that adoption. The questions should be: what will make that change, and it that change viable? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs@anvilwalrusden.com Wed Feb 22 13:13:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0125A21F857F for ; Wed, 22 Feb 2012 13:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 GIzD2dN6WH+C for ; Wed, 22 Feb 2012 13:13:50 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0840421F8532 for ; Wed, 22 Feb 2012 13:13:49 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5EDC21ECB41D for ; Wed, 22 Feb 2012 21:13:49 +0000 (UTC) Date: Wed, 22 Feb 2012 16:13:47 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120222211346.GI36315@mail.yitter.info> References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <4F4555F5.1090301@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F4555F5.1090301@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 21:13:51 -0000 No hat. On Wed, Feb 22, 2012 at 12:54:13PM -0800, Dave CROCKER wrote: > The record has yet to show a benefit in adoption of the special SPF > RR and, hence, failed to gain that adoption. We agree about this. > The questions should be: what will make that change, and it that change viable? > I was suggesting that the question should be, "Why make this change if already-available operational benefit depends on not making the change?" According to what people have said lately in this thread, all of the following things appear to be true (some are waiting on data for confirmation): 1. The bulk of the clients send SPF queries first. 2. SPF records and the SPF-use TXT records, when they are maintained correctly (and in the latter case maintained to the exclusion of other things), have the same use value. 3. Not putting an SPF record in your zone causes you to experience extra query traffic. 4. Not putting an SPF record in your zone causes your clients to have to send extra traffic. Those who are arguing, "SPF records should be deprecated," are effectively arguing that all the client software ought to be upgraded in order to make the extra traffic go away. I was merely noting that people could get an immediate operational benefit to themselves simply by adding the SPF record to their zone; this requires no change in software in at least a large number of cases, and causes a reduction in needless DNS traffic. Seems to me like an operational benefit available this afternoon to anyone who cared to do it. Those who want to deprecate the RRTYPE are arguing that greater operational benefit would come if we made a specification change and everybody on the Internet using SPF upgraded their software. From my perspective, this sounds like the burden of proof is being put on the wrong party. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From hsantos@isdg.net Wed Feb 22 13:27:25 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131CE21E801F for ; Wed, 22 Feb 2012 13:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wk36+B1P2d-r for ; Wed, 22 Feb 2012 13:27:24 -0800 (PST) Received: from news.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B306321E802D for ; Wed, 22 Feb 2012 13:27:23 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3382; t=1329946039; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=+nRbCR8AmB9UT5yEeU+a8iZTQ9U=; b=hi7UpSxBfU8Ak/zXUhMb LtGg9U3k01AzcJhAl5kHjMmmlEudSQV7uMDfrCS+nwMr16+4BWgzsbMKopAe+kp9 qow2DS4DWrbJzB565hlox3KtG9VOuaAHPDZjY3fYsaNvCzXjvwxyoRi+TIBArWyu gXLZDUDnpzQH4CFlEee1YSs= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 16:27:19 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3147883213.88546.4628; Wed, 22 Feb 2012 16:27:18 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3382; t=1329945795; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=FbvOqWK RJu7T6xQzT0TtOStxDKZrTAonPyC2jkhkgqk=; b=blPkLhZ4iWK85uw/n2PZ6zD 0kxPWMz2eaBEt+VnRiskvbKwXTcfcAzZBmd6RAff7qHm/KFlU/PUyfOfQsCGDw2H IIhVbX55i8lEagkIobQjt9q/rscgW/FDDD8Z595ARGj5OcCZrGD8yKWAcAWmUEs7 5mzuDThCbHDiRGibmhOg= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 16:23:15 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3746817501.18899.4248; Wed, 22 Feb 2012 16:23:14 -0500 Message-ID: <4F455DC0.5090401@isdg.net> Date: Wed, 22 Feb 2012 16:27:28 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <1393684.knylKaz50c@scott-latitude-e6320> In-Reply-To: <1393684.knylKaz50c@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 21:27:25 -0000 Scott, we adding the type to our DNS resolver and script base SPF software. The only reason it was disabled by default was 100% because their was still a large network of DNS servers that simply did not support it. Do you dispute this was not the issue when it was first proposed for any protocol pushing a new RR type? See RFC3597 "Handling of Unknown DNS Resource Record (RR) Types" Abstract Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires *changes to name server software.* This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. It well known it would not work well back then at least in the short term until DNS server were updated, especially the Microsoft DNS 4.0 to 5.0 level. The SPF type was added to the spec with what I believe was a full knowledge it had a low reliable to start and an expectation to be used in the future as these DNS servers were updated. So it is by now surprise the early testing after it was tested would have a high failure rate. Am I off base? Besides the point evidence is arriving showing the type is already used, I suspect people just didn't bother for no other reason perhaps their infrastructure was already setup around TXT records. But with SPF-BIS and knowing today, DNS servers do handle this, I believe it is worth a short. Scott Kitterman wrote: > On Wednesday, February 22, 2012 03:08:26 PM Andrew Sullivan wrote: >> No hat. >> >> On Wed, Feb 22, 2012 at 02:41:19PM -0500, Scott Kitterman wrote: >>> The "almost no" arguement I've made is about publishing. >>> >>> I think the fact that there are so many pointless queries for Type SPF >>> argues for getting rid of it. It's a waste. >> That would be as strong an argument in favour of _promoting_ the SPF >> record and saying that implementations SHOULD check for the SPF record >> unless they already know there is no SPF record present. >> >> After all, lots of people didn't used to use MX records either. > > RFC 4408 already says that type SPF should be checked and that it should be > published. Despite doubts about if a transition to type SPF could ever be > made (IMO both those SHOULD statements were statements of bold optimism) the > SPF community has solidly supported type SPF. > > Within a week of Type 99 being allocated to Type SPF there were open source > implementations of SPF checking libraries that would check it. In fact, > community testing between the IANA assignment and the author's 48 hour review > prior to RFC 4408 publication identified some interoperability issues with > multiple DNS RR types carrying the same information that were corrected prior > to RFC 4408's publication. > > Even with this support, Type SPF has little traction operationally and there > is no basis to expect this to change. Given that, the best thing we can do is > encourage receivers not to do these pointless queries. > > There is an operational benefit to using MX records. As we've discussed, there > isn't one for Type SPF. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Wed Feb 22 13:34:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B7621F85D5 for ; Wed, 22 Feb 2012 13:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMuL3SBzsl-W for ; Wed, 22 Feb 2012 13:34:53 -0800 (PST) Received: from news.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF1C21F84F6 for ; Wed, 22 Feb 2012 13:34:53 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2832; t=1329946484; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=QhiCRdOF+E6P5xZai/egRz2I/do=; b=EXaw8AukbSTHI4t5PNjX GCHQq4b5zgA/LCnBvmkzuGdP7bL3QPvt6AEdDGKxFABapeomsFI8N9Fs6ip1T0bf MS79I8FNpNDtr7bGYJRaBlnh6zXtbyH2u5kp33Fdlsr2BqQLIB+wL3zdGmajpMyT QRUdbPrE69e2VXOnbt6ZX9A= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 16:34:44 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3148328315.88546.4256; Wed, 22 Feb 2012 16:34:43 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2832; t=1329946241; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=NFc6p00 jTWTkDJNKI1IKuVBjFFJv0PnEzNv1ZeI6BlM=; b=NLylZwZzFlY6MxQIxWVedlw mvks2gxzxF70c04SF46nnHgreDgJY8U7tDxds3W23HM2pbykIp5gevQiFnoa414e DsleAV93YsKGKqMa1Qmbxk8i1MndeoeXG/fBWuI4jH6dQy1z3yzCxGOPb0qYNv55 gNiEiuc+fYx+bNnLKI4A= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 16:30:41 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3747264079.18901.1968; Wed, 22 Feb 2012 16:30:40 -0500 Message-ID: <4F455F80.6070609@isdg.net> Date: Wed, 22 Feb 2012 16:34:56 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <4F4555F5.1090301@dcrocker.net> <20120222211346.GI36315@mail.yitter.info> In-Reply-To: <20120222211346.GI36315@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 21:34:54 -0000 Why isn't RFC3597 relevant here? Handling of Unknown DNS Resource Record (RR) Types Abstract Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. It was well known when the decision to the type, it would be to prepare it for the future as the DNS servers get updated. If anything, the industry got established and comfortable with TXT but IMO, the original ideals should not be lost. Only with a SPF-BIS recommendation, would I go back to the software and being enabling it with a high expectation that it will be reliable today to a high degree. Andrew Sullivan wrote: > No hat. > > On Wed, Feb 22, 2012 at 12:54:13PM -0800, Dave CROCKER wrote: >> The record has yet to show a benefit in adoption of the special SPF >> RR and, hence, failed to gain that adoption. > > We agree about this. > >> The questions should be: what will make that change, and it that change viable? >> > > I was suggesting that the question should be, "Why make this change if > already-available operational benefit depends on not making the > change?" > > According to what people have said lately in this thread, all of the > following things appear to be true (some are waiting on data for confirmation): > > 1. The bulk of the clients send SPF queries first. > > 2. SPF records and the SPF-use TXT records, when they are > maintained correctly (and in the latter case maintained to the > exclusion of other things), have the same use value. > > 3. Not putting an SPF record in your zone causes you to > experience extra query traffic. > > 4. Not putting an SPF record in your zone causes your clients to > have to send extra traffic. > > Those who are arguing, "SPF records should be deprecated," are > effectively arguing that all the client software ought to be upgraded > in order to make the extra traffic go away. I was merely noting that > people could get an immediate operational benefit to themselves simply > by adding the SPF record to their zone; this requires no change in > software in at least a large number of cases, and causes a reduction > in needless DNS traffic. Seems to me like an operational benefit > available this afternoon to anyone who cared to do it. Those who want > to deprecate the RRTYPE are arguing that greater operational benefit > would come if we made a specification change and everybody on the > Internet using SPF upgraded their software. From my perspective, this > sounds like the burden of proof is being put on the wrong party. > > Best, > > A > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Wed Feb 22 13:44:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D9421F8514 for ; Wed, 22 Feb 2012 13:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 ZUg0Irfpb3Xz for ; Wed, 22 Feb 2012 13:44:04 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D5D0F21E8020 for ; Wed, 22 Feb 2012 13:44:03 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 618CE20E40CC; Wed, 22 Feb 2012 16:44:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329947043; bh=2sNRcXLoJlIh0mLQ51irAdrUMTHKk+yz6yu/7Di49wI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Jw+6pDVIIZZ1dvtxrAooTpU5hUyCfbdYPVsaxRaR29ifd/MFrbCiNcvIyornr3PHT wMs+HsD5hYUufuN+OPOj8tiwVl+3W6FCo2r2LBd950oXoLi5pPTw8ZBOz2/hMH9hy9 npp/sK/hnO8VMi69eId+sYJupx6t+NUGlYjKoeMo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4328920E408E; Wed, 22 Feb 2012 16:44:03 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Feb 2012 16:44:02 -0500 Message-ID: <4769367.fJYZXf1raF@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120222211346.GI36315@mail.yitter.info> References: <20120222193641.73783.qmail@joyce.lan> <4F4555F5.1090301@dcrocker.net> <20120222211346.GI36315@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 21:44:06 -0000 On Wednesday, February 22, 2012 04:13:47 PM Andrew Sullivan wrote: > No hat. > > On Wed, Feb 22, 2012 at 12:54:13PM -0800, Dave CROCKER wrote: > > The record has yet to show a benefit in adoption of the special SPF > > RR and, hence, failed to gain that adoption. > > We agree about this. > > > The questions should be: what will make that change, and it that change > > viable? > I was suggesting that the question should be, "Why make this change if > already-available operational benefit depends on not making the > change?" > > According to what people have said lately in this thread, all of the > following things appear to be true (some are waiting on data for > confirmation): > > 1. The bulk of the clients send SPF queries first. > > 2. SPF records and the SPF-use TXT records, when they are > maintained correctly (and in the latter case maintained to the > exclusion of other things), have the same use value. > > 3. Not putting an SPF record in your zone causes you to > experience extra query traffic. > > 4. Not putting an SPF record in your zone causes your clients to > have to send extra traffic. > > Those who are arguing, "SPF records should be deprecated," are > effectively arguing that all the client software ought to be upgraded > in order to make the extra traffic go away. I was merely noting that > people could get an immediate operational benefit to themselves simply > by adding the SPF record to their zone; this requires no change in > software in at least a large number of cases, and causes a reduction > in needless DNS traffic. Seems to me like an operational benefit > available this afternoon to anyone who cared to do it. Those who want > to deprecate the RRTYPE are arguing that greater operational benefit > would come if we made a specification change and everybody on the > Internet using SPF upgraded their software. From my perspective, this > sounds like the burden of proof is being put on the wrong party. If it's all so obvious that it makes sense to publish SPF records, why aren't more people doing it? My main argument for removing the type is that it simplifies things and does no harm. What's the benefit of not doing away with it? Nothing as far as I can tell. I guarantee you that as soon as there's an RFC that deprecates use of type SPF I'll be simplifying some code. Scott K From sm@resistor.net Wed Feb 22 13:46:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FFB21E8039 for ; Wed, 22 Feb 2012 13:46:48 -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 oTuzdXU28ElR for ; Wed, 22 Feb 2012 13:46: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 4B9C221F8534 for ; Wed, 22 Feb 2012 13:46:36 -0800 (PST) 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 q1MLkV6J010626 for ; Wed, 22 Feb 2012 13:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329947196; i=@resistor.net; bh=y4HKSwAXo/uS/1mlNcs0R7Lf/pDq8vWiQmcVT0VP7H0=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=QBA7BB8l4VXy+IUE48bEes9skXyrbT6k4GadmQi5HvEs8CTrVnqkcJ48cedG6IFGo EqFERakYezjHX8UTdRlpvOvitw4Zk4vTI+13fSVW/VTyCTSwvSBVrjhMgH0WYENmWl vdaGKucsK4LpOciCOcLV9HemI02XGq9ngGjYHmsw= Message-Id: <6.2.5.6.2.20120222124752.09f0d510@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Feb 2012 13:45:35 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1393684.knylKaz50c@scott-latitude-e6320> References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <1393684.knylKaz50c@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 21:46:48 -0000 Hello, I have been following the discussion about SPF RR Type. It seems that the issue is being read as a binary question, i.e. should the SPR RR record be kept or not. Some of the questions that come to my mind are: (a) How many domains are publishing SPF RR records? (b) How many domains are publishing SPT TXT records? (c) How many domains are querying for SPR RR records? (d) How many domains are querying for SPR TXT records? (e) What are the implementations out there? (f) What DNS records do the implementations query for? The above is not an exhaustive list of questions. If I missed any questions, let me know. Without empirical data, it is not possible to answer these questions. Is there anyone who would like to volunteer to find the answers to these questions? Regards S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Wed Feb 22 13:48:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4E921E8039 for ; Wed, 22 Feb 2012 13:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 4UB9wS7pXEli for ; Wed, 22 Feb 2012 13:48:17 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8025921E8020 for ; Wed, 22 Feb 2012 13:48:17 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1757920E40CC; Wed, 22 Feb 2012 16:48:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329947297; bh=EnHgFWNgWaKIRsrCdbB+bIh4sR1q21QlzIYZlYv+VEo=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=SuC1Hqap0AzyBx+RdyLAAZXi/KYrhtOa5Xk3NQMx41awxqKixGZKKG8BmU/xyiJjS sHpeDnETpy0HcSmHaI74iyMa7Vek49SxqgFXAGFpc988CSR2ms77IlYpm1QcW4ilt2 R0rTu3pOLkbivKqZdBqEA3Oo7yIcOQjW/DZOBMQI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id EDF5720E408E; Wed, 22 Feb 2012 16:48:16 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Feb 2012 16:48:16 -0500 Message-ID: <2064465.PMzIPqdBEe@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F455DC0.5090401@isdg.net> References: <20120222193641.73783.qmail@joyce.lan> <1393684.knylKaz50c@scott-latitude-e6320> <4F455DC0.5090401@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 21:48:18 -0000 On Wednesday, February 22, 2012 04:27:28 PM Hector Santos wrote: > Scott, we adding the type to our DNS resolver and script base SPF > software. > > The only reason it was disabled by default was 100% because their was > still a large network of DNS servers that simply did not support it. > Do you dispute this was not the issue when it was first proposed for > any protocol pushing a new RR type? It was certainly an issue in 2005. I've seen no evidence to indicate it's not an issue now. > See RFC3597 "Handling of Unknown DNS Resource Record (RR) Types" > > Abstract > > Extending the Domain Name System (DNS) with new Resource Record (RR) > types currently requires *changes to name server software.* This > document specifies the changes necessary to allow future DNS > implementations to handle new RR types transparently. > > It well known it would not work well back then at least in the short > term until DNS server were updated, especially the Microsoft DNS 4.0 > to 5.0 level. The SPF type was added to the spec with what I believe > was a full knowledge it had a low reliable to start and an expectation > to be used in the future as these DNS servers were updated. > > So it is by now surprise the early testing after it was tested would > have a high failure rate. > > Am I off base? > > Besides the point evidence is arriving showing the type is already > used, I suspect people just didn't bother for no other reason perhaps > their infrastructure was already setup around TXT records. > > But with SPF-BIS and knowing today, DNS servers do handle this, I > believe it is worth a short. I've not seen any evidence to support the notion that it's reliable now. It may be. In the code I support where it's not enabled by default, I've gotten zero complaints. The reverse is not true. So you think that if 4408bis retains the recommendation to use type SPF, adoption would suddenly take off? I don't. Scott K > Scott Kitterman wrote: > > On Wednesday, February 22, 2012 03:08:26 PM Andrew Sullivan wrote: > >> No hat. > >> > >> On Wed, Feb 22, 2012 at 02:41:19PM -0500, Scott Kitterman wrote: > >>> The "almost no" arguement I've made is about publishing. > >>> > >>> I think the fact that there are so many pointless queries for Type > >>> SPF > >>> argues for getting rid of it. It's a waste. > >> > >> That would be as strong an argument in favour of _promoting_ the SPF > >> record and saying that implementations SHOULD check for the SPF record > >> unless they already know there is no SPF record present. > >> > >> After all, lots of people didn't used to use MX records either. > > > > RFC 4408 already says that type SPF should be checked and that it should > > be published. Despite doubts about if a transition to type SPF could > > ever be made (IMO both those SHOULD statements were statements of bold > > optimism) the SPF community has solidly supported type SPF. > > > > Within a week of Type 99 being allocated to Type SPF there were open > > source implementations of SPF checking libraries that would check it. > > In fact, community testing between the IANA assignment and the author's > > 48 hour review prior to RFC 4408 publication identified some > > interoperability issues with multiple DNS RR types carrying the same > > information that were corrected prior to RFC 4408's publication. > > > > Even with this support, Type SPF has little traction operationally and > > there is no basis to expect this to change. Given that, the best thing > > we can do is encourage receivers not to do these pointless queries. > > > > There is an operational benefit to using MX records. As we've > > discussed, there isn't one for Type SPF. > > > > Scott K > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Wed Feb 22 13:55:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A18121E8062 for ; Wed, 22 Feb 2012 13:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 9VkvB2nzqeKM for ; Wed, 22 Feb 2012 13:55:57 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5F421E8046 for ; Wed, 22 Feb 2012 13:55:57 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DF7BB20E40CC; Wed, 22 Feb 2012 16:55:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329947756; bh=+GiJpNswOEK0y/DAz0BhHrvaqAB5WRtvwW39mPZqk/o=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=jIzTM4l3DkxqSYDUS87Ylx9oyRfgn/8vhgKbLCILFXCm6GhcU9SvfFrIz/H4nsxlw oxy1lslGMv9i8Ynu9JEDdqDQ4RJJtgjWiDAnFF2wkt25L34zTraijsF/3RqOojsX1v ddEFcSoWivfEHI4BNI/1QrrmH41RlIYq3i4p8kXE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C4F8B20E408E; Wed, 22 Feb 2012 16:55:56 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Feb 2012 16:55:56 -0500 Message-ID: <5567166.I4xfqSWBX7@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120222124752.09f0d510@resistor.net> References: <20120222193641.73783.qmail@joyce.lan> <1393684.knylKaz50c@scott-latitude-e6320> <6.2.5.6.2.20120222124752.09f0d510@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] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 21:55:58 -0000 On Wednesday, February 22, 2012 01:45:35 PM S Moonesamy wrote: > Hello, > > I have been following the discussion about SPF RR Type. It seems > that the issue is being read as a binary question, i.e. should the > SPR RR record be kept or not. Some of the questions that come to my mind > are: > > (a) How many domains are publishing SPF RR records? > > (b) How many domains are publishing SPT TXT records? > > (c) How many domains are querying for SPR RR records? > > (d) How many domains are querying for SPR TXT records? > > (e) What are the implementations out there? > > (f) What DNS records do the implementations query for? > > The above is not an exhaustive list of questions. If I missed any > questions, let me know. Without empirical data, it is not possible > to answer these questions. Is there anyone who would like to > volunteer to find the answers to these questions? I think questions a and b have to be linked to some degree. I'd ask them this way: 1. How many domains publish only Type TXT SPF records 2. How man domains publish only Type SPF SPF records 3. How many domains publish both Type SPF and Type TXT SPF records 4. Of the domains in question 3, how many have identical records. WIthout knowing the degree of overlap/non-overlap you won't be able to draw conclusions about the effect of deprecating support for Type SPF. Also, I'd be interested in the list of domains publishing only Type SPF since I doubt they understand what they are doing. Scott K From ajs@anvilwalrusden.com Wed Feb 22 14:14:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A406F21F84DA for ; Wed, 22 Feb 2012 14:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 G4waMXPu9svG for ; Wed, 22 Feb 2012 14:14:06 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id F18D221F84D6 for ; Wed, 22 Feb 2012 14:14:05 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E63BD1ECB41D for ; Wed, 22 Feb 2012 22:14:04 +0000 (UTC) Date: Wed, 22 Feb 2012 17:14:03 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120222221402.GK36315@mail.yitter.info> References: <20120222193641.73783.qmail@joyce.lan> <1393684.knylKaz50c@scott-latitude-e6320> <4F455DC0.5090401@isdg.net> <2064465.PMzIPqdBEe@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2064465.PMzIPqdBEe@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 22:14:06 -0000 No hat. On Wed, Feb 22, 2012 at 04:48:16PM -0500, Scott Kitterman wrote: > > still a large network of DNS servers that simply did not support it. > It was certainly an issue in 2005. I've seen no evidence to indicate it's not > an issue now. I think that's oversimplifying things some. There remain difficulties in some systems with managing unknown RRTYPEs. This includes some widely-deployed ones, including at least some Microsoft libraries. But any DNS _server_, including any caches, that has any business responding to queries on the Internet today can certainly cope with unknown RRTYPEs. If they couldn't, we'd almost certainly have heard loud noises when the root of the DNS was signed last year, and we didn't. Unlike many people in the DNS community -- a community that is sometimes tarred with a broad brush -- I believe quite strongly that there remain serious practical difficulties in some cases with new RRTYPEs, and I have no interest in pretending otherwise. But I don't think it does anyone any service to pretend that it's impossible to add new RRTYPEs. The question is one of costs and benefits. You are arguing that the benefit here isn't worth the additional cost. I'm pointing out that, where the DNS is concerned, it takes years to upgrade software -- indeed, this is exactly the problem that you're using as a premise. Therefore, if you say, "Didn't work, rip it out," you're effectively saying that you'll need to support it for some period of time -- more than 10 years, is my guess -- anyway. If we have at least a 10 year horizon, it's anyone's guess which direction would be preferable. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Wed Feb 22 14:22:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517A121E804B for ; Wed, 22 Feb 2012 14:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg++i3Ru3GF8 for ; Wed, 22 Feb 2012 14:22:26 -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 8E4B221E8015 for ; Wed, 22 Feb 2012 14:22:25 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.232.96]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1MMM6Y4012558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 14:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329949339; i=@elandsys.com; bh=KhzWXEto/OoHWnke2z4RvUxjbpxwVNyfgm/nE9O9R2A=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=O2JHteetL54nLpzmptV75h9KcMD8grIaJNN/bQpxdMgFdFwpe5DRKEpHFUatj0ky1 O09EJ0LepN/4uYyace0NjIChhhqtRZ2nc+Nq8MLjTWRGTOhrfBnCEgkXpFwrlnW0n3 SFkjVE9jRCqZUlBlaXJA0u+7BYmLIxXSOop3pOhY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329949339; i=@elandsys.com; bh=KhzWXEto/OoHWnke2z4RvUxjbpxwVNyfgm/nE9O9R2A=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Ep4K+P56roKPK3a2zy27PcsU4L4A3HWA94KWGwVZ004ZphA4sDNmpKIKxxk1D/28q oj5kNLvkfYd0778rjn24hCqOau3oVvPem6VjDl2AIij72igZVjwsqGWb/9hJ5GOh6G FbdZCFJ7ANqJJ4kvpnMPIlf1jJDPn1+oEdofJavg= Message-Id: <6.2.5.6.2.20120222140245.0a9d0978@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Feb 2012 14:20:09 -0800 To: Scott Kitterman From: S Moonesamy In-Reply-To: <5567166.I4xfqSWBX7@scott-latitude-e6320> References: <20120222193641.73783.qmail@joyce.lan> <1393684.knylKaz50c@scott-latitude-e6320> <6.2.5.6.2.20120222124752.09f0d510@resistor.net> <5567166.I4xfqSWBX7@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 22:22:27 -0000 Hi Scott, At 13:55 22-02-2012, Scott Kitterman wrote: >I think questions a and b have to be linked to some degree. I'd ask them this Ok. >WIthout knowing the degree of overlap/non-overlap you won't be able to draw >conclusions about the effect of deprecating support for Type >SPF. Also, I'd be I am not drawing any conclusions about the effects of deprecating support for Type SPF. What I am looking for is people who can come to the working group with data that answers the questions. The more data the working group can get (e.g. to answer the questions you mentioned), the better. Would you like to volunteer? Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Wed Feb 22 14:22:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1145B21E8062 for ; Wed, 22 Feb 2012 14:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 gl6X4cGAyItZ for ; Wed, 22 Feb 2012 14:22:36 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4658121E8061 for ; Wed, 22 Feb 2012 14:22:36 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B680E20E40CC; Wed, 22 Feb 2012 17:22:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329949355; bh=7zJK5mUsCfJZbZqY/n7Xy3sckJofcSugGYEouxypbiE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=BNPAFaEUK40lp4bh/ZqtbZQN+OIIfnuWBdAtj7NF5y9p7gmQz05ZCBLJE1w0TlH8o ivdG7oE57GOqBiKJSizSN8ZIs4i6uY6yj0OiCtlVpnxHu8jaIEgID2CrKn6CxoXF7X VAUPIXKWDFYw+c37XGH45Hes1f7MCVXHPSmC430k= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 99CA620E408E; Wed, 22 Feb 2012 17:22:35 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Feb 2012 17:22:34 -0500 Message-ID: <1462410.QgBydMzgQK@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120222221402.GK36315@mail.yitter.info> References: <20120222193641.73783.qmail@joyce.lan> <2064465.PMzIPqdBEe@scott-latitude-e6320> <20120222221402.GK36315@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 22:22:37 -0000 On Wednesday, February 22, 2012 05:14:03 PM Andrew Sullivan wrote: > No hat. > > On Wed, Feb 22, 2012 at 04:48:16PM -0500, Scott Kitterman wrote: > > > still a large network of DNS servers that simply did not support it. > > > > It was certainly an issue in 2005. I've seen no evidence to indicate > > it's not an issue now. > > I think that's oversimplifying things some. > > There remain difficulties in some systems with managing unknown > RRTYPEs. This includes some widely-deployed ones, including at least > some Microsoft libraries. But any DNS _server_, including any caches, > that has any business responding to queries on the Internet today can > certainly cope with unknown RRTYPEs. If they couldn't, we'd almost > certainly have heard loud noises when the root of the DNS was signed > last year, and we didn't. > > Unlike many people in the DNS community -- a community that is > sometimes tarred with a broad brush -- I believe quite strongly that > there remain serious practical difficulties in some cases with new > RRTYPEs, and I have no interest in pretending otherwise. But I don't > think it does anyone any service to pretend that it's impossible to > add new RRTYPEs. The question is one of costs and benefits. > > You are arguing that the benefit here isn't worth the additional > cost. I'm pointing out that, where the DNS is concerned, it takes > years to upgrade software -- indeed, this is exactly the problem that > you're using as a premise. Therefore, if you say, "Didn't work, rip > it out," you're effectively saying that you'll need to support it for > some period of time -- more than 10 years, is my guess -- anyway. If > we have at least a 10 year horizon, it's anyone's guess which > direction would be preferable. I don't think I am. All I said is I don't know, because I don't. There is an added operational complexity associated with publishing the same information multiple places, so there is a transitional cost to support both. I don't think that SPF record publishers are going to accept that cost without a worthwhile benefit. I believe the evidence we've seen shows that even with widespread SPF checking, people aren't publishing. What's going to change? Scott K From presnick@qualcomm.com Wed Feb 22 14:24:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A90721F84F6 for ; Wed, 22 Feb 2012 14:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uC40FevgVjfU for ; Wed, 22 Feb 2012 14:24:30 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 989CA21F84F1 for ; Wed, 22 Feb 2012 14:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1329949470; x=1361485470; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F456B1B.6060508@qualcomm.com>|Date:=20We d,=2022=20Feb=202012=2016:24:27=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Scott=20Kitterman=20|CC:=20|Subject:=20Re:=20[spfb is]=20#9:=20RFC=204408=20SPF=20RR=20type|References:=20<2 0120222193641.73783.qmail@joyce.lan>=09<4F4555F5.1090301@ dcrocker.net>=09<20120222211346.GI36315@mail.yitter.info> =20<4769367.fJYZXf1raF@scott-latitude-e6320>|In-Reply-To: =20<4769367.fJYZXf1raF@scott-latitude-e6320> |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.48.1]; bh=NfZluMhdufVZZPMC/cnvVxaranD/wHeCiKD2ZNh6XqY=; b=Z6Nqmr9njl2WCFkCjsbPfxgGnPQIsX/gNA+PcLLt0txmUmq0N5vpjMNU e+518eiFzxYJuE7rAguvWABJlVnuA7pM2pNCqde1GAGWOj4e5CHUhlLM3 XdfZpSC0GT+hcAdAufZSvc3jnW2O+g0poFEeIQYzSDySZWUd3qGvYcejr A=; X-IronPort-AV: E=McAfee;i="5400,1158,6628"; a="165459499" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 22 Feb 2012 14:24:30 -0800 X-IronPort-AV: E=Sophos;i="4.73,464,1325491200"; d="scan'208";a="186282872" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 22 Feb 2012 14:24:30 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 22 Feb 2012 14:24:29 -0800 Message-ID: <4F456B1B.6060508@qualcomm.com> Date: Wed, 22 Feb 2012 16:24:27 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Scott Kitterman References: <20120222193641.73783.qmail@joyce.lan> <4F4555F5.1090301@dcrocker.net> <20120222211346.GI36315@mail.yitter.info> <4769367.fJYZXf1raF@scott-latitude-e6320> In-Reply-To: <4769367.fJYZXf1raF@scott-latitude-e6320> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: spfbis@ietf.org Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 22:24:31 -0000 Hatless. On 2/22/12 3:44 PM, Scott Kitterman wrote: > If it's all so obvious that it makes sense to publish SPF records, why aren't > more people doing it? > Maybe they set them up long ago when software wasn't available to create SPF records and they could easily create TXT records. Maybe they don't realize that failure to set them up causes extra traffic because the cost is non-obvious or externalized (i.e., the folks who deploy SPF are not the ones that see the cost). It would be good to start asking these questions to find out why. > My main argument for removing the type is that it simplifies things and does no > harm. > The harm is that everyone has to upgrade they're querying software to stop querying for the SPF record. > What's the benefit of not doing away with it? Nothing as far as I can tell. > No software upgrades, and *if* people (due to the publication of the standards track document) realize that they should be deploying the SPF record, they will and that will cut down DNS traffic. > I guarantee you that as soon as there's an RFC that deprecates use of type SPF > I'll be simplifying some code. > New code (even if it is simplifying code) is always risky code. Not a huge risk, but a risk nonetheless. Anyway, I'm pretty sure that you are one of the more motivated SPF developers. :-) Now that I know about this issue, I'm going to go check my own server and add a 99 record, since I don't think I have one. But I think that's because I did it so long ago and never looked to see how to enter a new record type into my little server. But I'm pretty sure I'm not an average SPF deployer myself. More questions to be asked. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From spf2@kitterman.com Wed Feb 22 14:34:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE9A21F85D2 for ; Wed, 22 Feb 2012 14:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 Srz0ADo4cyiN for ; Wed, 22 Feb 2012 14:34:34 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0C50721F854D for ; Wed, 22 Feb 2012 14:34:34 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9649620E40CC; Wed, 22 Feb 2012 17:34:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329950073; bh=sk6jU5voErHAJU1+hawi9rph4xO4DGogLvGghVKv6+g=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=caqFR31rDVzVYyZ6N63gNFC7pVdrIB2/HfHdVu1Thg2TkxnaPhYSP6TWBKOpDHgCz QkgF2bv87vA7xhDjbI1sS+jrDlftANRwG0OY0h5E0L6U6xlMmQU0ijQ3Y9qU5B5seQ EcxyADOCH5TBQoNZvxW7X6gUCI4PrMlPYJLwpnnI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7735420E408E; Wed, 22 Feb 2012 17:34:33 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Feb 2012 17:34:32 -0500 Message-ID: <10993854.JWKf1lscXd@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120222140245.0a9d0978@resistor.net> References: <20120222193641.73783.qmail@joyce.lan> <5567166.I4xfqSWBX7@scott-latitude-e6320> <6.2.5.6.2.20120222140245.0a9d0978@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] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 22:34:35 -0000 On Wednesday, February 22, 2012 02:20:09 PM S Moonesamy wrote: > Hi Scott, > > At 13:55 22-02-2012, Scott Kitterman wrote: > >I think questions a and b have to be linked to some degree. I'd ask them > >this > Ok. > > >WIthout knowing the degree of overlap/non-overlap you won't be able to > >draw conclusions about the effect of deprecating support for Type > >SPF. Also, I'd be > > I am not drawing any conclusions about the effects of deprecating > support for Type SPF. What I am looking for is people who can come > to the working group with data that answers the questions. The more > data the working group can get (e.g. to answer the questions you > mentioned), the better. > > Would you like to volunteer? You also asked about the appropriateness of the questions. If you don't ask questions in a way that will allow you to answer the question that's being asked, there's no point in collecting the data. A couple of people have already volunteered to do surveys of published DNS records. I could do it, but I don't know that we need more. If we do, I can help out. I don't have access to a good way of helping out with the questions about how many domains are doing queries. I can tell you that the major FOSS SPF libraries that I'm familiar with (libspf2 (C), Mail::SPF (Perl), and pyspf (Python)) all support Type SPF 99 (although it's disabled by default in pyspf and Mail::SPF provides a way for applications to avoid calling it - I'm not a C programmer, so I'm not sure exactly what libspf2 does). Scott K From sm@elandsys.com Wed Feb 22 14:59:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F7021F861E for ; Wed, 22 Feb 2012 14:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiPl59C1CBIR for ; Wed, 22 Feb 2012 14:59:02 -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 9B99A21F861D for ; Wed, 22 Feb 2012 14:58:33 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.232.96]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1MMwKot019280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 14:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329951512; i=@elandsys.com; bh=33vsSKLRsNlZ0QG0GOpSdbN7oWedJ22WHgpdRPQfBUg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=tvibbI1bq/8K7vuIUNbWUm0WYoXcK/fPBoLy8oaHxnNE0reu8TiVSD8JvR/NtboKb mJSvCbFY6ADeiCMa/e5Oy1jnPlY9f5RhCZUqryJ020DWg3sS+QqKqRhzjw4rRM8YL5 AE6HFqNUliGxAEe78DVhiWSVdeYNi/FOM5lw9PfM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329951512; i=@elandsys.com; bh=33vsSKLRsNlZ0QG0GOpSdbN7oWedJ22WHgpdRPQfBUg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=xBXEr851/aFBc+IyKKCe/RrUQAnqKFQYfGRe6hQsHuzZaZ2883G9o2tOcye+mjXL1 j9stm6PtlKxXtSeYUspCJtgtKY8pd+9JScCyLOxJQyWX6V7zrgBqDAXxcqHQyIv+Ib 4nXACg/C544TDZ0yFUuGfvWOfrAzelCTHAQyTSYE= Message-Id: <6.2.5.6.2.20120222143942.0aeadae8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Feb 2012 14:57:32 -0800 To: Scott Kitterman From: S Moonesamy In-Reply-To: <10993854.JWKf1lscXd@scott-latitude-e6320> References: <20120222193641.73783.qmail@joyce.lan> <5567166.I4xfqSWBX7@scott-latitude-e6320> <6.2.5.6.2.20120222140245.0a9d0978@resistor.net> <10993854.JWKf1lscXd@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 22:59:03 -0000 Hi Scott, At 14:34 22-02-2012, Scott Kitterman wrote: >A couple of people have already volunteered to do surveys of published DNS >records. I could do it, but I don't know that we need more. If we do, I can >help out. The data that have been posted to this mailing list does not answer all the questions I had in mind. >I don't have access to a good way of helping out with the questions about how >many domains are doing queries. Ok. >I can tell you that the major FOSS SPF libraries that I'm familiar with >(libspf2 (C), Mail::SPF (Perl), and pyspf (Python)) all support Type SPF 99 >(although it's disabled by default in pyspf and Mail::SPF provides a way for >applications to avoid calling it - I'm not a C programmer, so I'm not sure >exactly what libspf2 does). Thanks for the input. That is not enough for "implementations out there". We need to cover as much as possible and that includes non-"FOSS" implementations. Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Wed Feb 22 15:16:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7551B21F85DF for ; Wed, 22 Feb 2012 15:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 qEAenw6p8lgU for ; Wed, 22 Feb 2012 15:16:21 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AB0AB21F85DD for ; Wed, 22 Feb 2012 15:16:21 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E267920E40CC; Wed, 22 Feb 2012 18:16:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329952580; bh=/H7+Y2ofEn7Itdk4GDffghJ8FIvIxVIO84d9dftbO9A=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=O8xL5m8Qy8sIroSS6vMD59GNmPcMBafj+gkE+TXWfiZxOzLmIzYjOQ57lPSTQG9Rx EPNnsNyHY4Iie68OfvHtuZDbDR4GbEv7j1PMLTvSjT+ekZ0HlQUWqw4IhdAhLUwhM2 SGC9+UoKPkCu5wT4QmceMwryZxOodiEWjj5KJGkI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C9A8E20E408E; Wed, 22 Feb 2012 18:16:20 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Feb 2012 18:16:20 -0500 Message-ID: <2474562.CvDAcOR3cO@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120222143942.0aeadae8@resistor.net> References: <20120222193641.73783.qmail@joyce.lan> <10993854.JWKf1lscXd@scott-latitude-e6320> <6.2.5.6.2.20120222143942.0aeadae8@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] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Feb 2012 23:16:22 -0000 On Wednesday, February 22, 2012 02:57:32 PM S Moonesamy wrote: > >I can tell you that the major FOSS SPF libraries that I'm familiar with > >(libspf2 (C), Mail::SPF (Perl), and pyspf (Python)) all support Type SPF > >99 (although it's disabled by default in pyspf and Mail::SPF provides a > >way for applications to avoid calling it - I'm not a C programmer, so I'm > >not sure exactly what libspf2 does). > > Thanks for the input. That is not enough for "implementations out > there". We need to cover as much as possible and that includes > non-"FOSS" implementations. Of course. I'm just giving you what I have. Scott K From dhc2@dcrocker.net Wed Feb 22 15:28:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50F921E803C for ; Wed, 22 Feb 2012 15:28:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXHD73OzHQVb for ; Wed, 22 Feb 2012 15:28:55 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F033A21E801D for ; Wed, 22 Feb 2012 15:28:54 -0800 (PST) Received: from [10.101.2.93] (64.1.211.245.ptr.us.xo.net [64.1.211.245]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1MNSmQe024036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 15:28:54 -0800 Message-ID: <4F457A2A.6050802@dcrocker.net> Date: Wed, 22 Feb 2012 15:28:42 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Pete Resnick References: <20120222193641.73783.qmail@joyce.lan> <4F4555F5.1090301@dcrocker.net> <20120222211346.GI36315@mail.yitter.info> <4769367.fJYZXf1raF@scott-latitude-e6320> <4F456B1B.6060508@qualcomm.com> In-Reply-To: <4F456B1B.6060508@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 22 Feb 2012 15:28:54 -0800 (PST) Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 23:28:55 -0000 On 2/22/2012 2:24 PM, Pete Resnick wrote: >> My main argument for removing the type is that it simplifies things and does no >> harm. > > The harm is that everyone has to upgrade they're querying software to stop > querying for the SPF record. They do not have to. The /may/ do it, if they want the benefit. >> What's the benefit of not doing away with it? Nothing as far as I can tell. > > No software upgrades, and *if* people (due to the publication of the standards > track document) realize that they should be deploying the SPF record, they will > and that will cut down DNS traffic. Right. No software upgrade and no reduction in wasted queries. An expectation that people will "realize" they "should" do the SPF RR establishes a technical requirement based on hypothetical human behavior, rather than established community need. On the average, the track record for such adoption predicates is quite poor. >> I guarantee you that as soon as there's an RFC that deprecates use of type SPF >> I'll be simplifying some code. > > New code (even if it is simplifying code) is always risky code. Not a huge risk, > but a risk nonetheless. Anyway, I'm pretty sure that you are one of the more > motivated SPF developers. :-) That invokes a rather unusual argument, for -bis efforts, namely to retain everything that is not known to be highly problematic. Whereas typical -bis efforts are encouraged to drop unused features, to simplify the spec and simply implementations and -- often -- simplify operations. > Now that I know about this issue, I'm going to go check my own server and add a > 99 record, since I don't think I have one. But I think that's because I did it > so long ago and never looked to see how to enter a new record type into my > little server. But I'm pretty sure I'm not an average SPF deployer myself. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Wed Feb 22 16:10:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AB421F8517 for ; Wed, 22 Feb 2012 16:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1v5quhfh2Vd for ; Wed, 22 Feb 2012 16:10:16 -0800 (PST) Received: from catinthebox.net (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 56E3821F8522 for ; Wed, 22 Feb 2012 16:10:05 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3339; t=1329955789; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=Gwa78i64+iQeHZw18m3S98NPA9c=; b=YU3Q2NwZwO0QFUjzXlzG k/Hmc/gWOYYMH5uyiTJkuzCePuhDS24fYrN5BWvOezt03mlpD2xXVZjlQtCcKuhN b8KjVsfoqH+MKci9VbXWkQSssyp45YHQ+f0P61Abk3sSNuIQnAg1EbaeT80eR0o6 2xqWPBJpuOureED66Wl69DU= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 19:09:49 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3157633587.88546.5924; Wed, 22 Feb 2012 19:09:48 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3339; t=1329955548; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=8Lq3Avz g4Eqjc04SYyM7iCAkrnWKAA4rFYOOSU3y1IM=; b=MPulKciiTbyncVgoSIYCLYR yyIr9KA6a8uUtmSmyoU8WrCSeBWAeNsPSrAoqciIPuG4+lN4cgkxPwXWSBvnO0qa HJkYgn0QXqpotzBMDr+6VpDEtaaofEjG9jgDH2pF1qUftbfhNKrF+0MM+Iw/Ccff gXEalsxXaq14GX9wczoY= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 22 Feb 2012 19:05:48 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3756571736.18914.1720; Wed, 22 Feb 2012 19:05:48 -0500 Message-ID: <4F4583DB.6090005@isdg.net> Date: Wed, 22 Feb 2012 19:10:03 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <20120222193641.73783.qmail@joyce.lan> <1393684.knylKaz50c@scott-latitude-e6320> <4F455DC0.5090401@isdg.net> <2064465.PMzIPqdBEe@scott-latitude-e6320> <20120222221402.GK36315@mail.yitter.info> In-Reply-To: <20120222221402.GK36315@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 00:10:19 -0000 Knicks/J-LIN cap on. Andrew Sullivan wrote: > No hat. > > On Wed, Feb 22, 2012 at 04:48:16PM -0500, Scott Kitterman wrote: >>> still a large network of DNS servers that simply did not support it. > >> It was certainly an issue in 2005. I've seen no evidence to indicate it's not >> an issue now. > > I think that's oversimplifying things some. > > There remain difficulties in some systems with managing unknown > RRTYPEs. This includes some widely-deployed ones, including at least > some Microsoft libraries. But any DNS _server_, including any caches, > that has any business responding to queries on the Internet today can > certainly cope with unknown RRTYPEs. If they couldn't, we'd almost > certainly have heard loud noises when the root of the DNS was signed > last year, and we didn't. > > Unlike many people in the DNS community -- a community that is > sometimes tarred with a broad brush -- I believe quite strongly that > there remain serious practical difficulties in some cases with new > RRTYPEs, and I have no interest in pretending otherwise. But I don't > think it does anyone any service to pretend that it's impossible to > add new RRTYPEs. The question is one of costs and benefits. > > You are arguing that the benefit here isn't worth the additional > cost. I'm pointing out that, where the DNS is concerned, it takes > years to upgrade software -- indeed, this is exactly the problem that > you're using as a premise. Therefore, if you say, "Didn't work, rip > it out," you're effectively saying that you'll need to support it for > some period of time -- more than 10 years, is my guess -- anyway. If > we have at least a 10 year horizon, it's anyone's guess which > direction would be preferable. > The SRV type also had its similar issues with DNS server support. The server might have supported the record, but there potentially were recursion issues along the path. Testament of increasing protocols usage with successful SRV discovery supports will suggest that the 3597 issues are must less than in 2005 and prior. But protocols still required to have a fallback for those paths that have a legacy DNS server. Related to SPF, what was interesting to me with my Jabber Server installation (OpenFire) was noticing how they also went about the same question with DNS record installations for discovery and noticing that they hung on to the idea that using a SRV record would be preferable and even though it may be duplicate record setup, eventually the SRV record will be begin to work more reliability. It really help with networking a few in faster and less query discoveries. Felt more "snappier." I think we should hang on to ours :) Point is, unlike circa 2005, today, I would not be hesitant to use new RR types for SPF and any new protocol work we do. But I think for SPF, we still need the fallback until more type 99 records are published and I think people will start to published them if we sell it to them that its better, more reliable today and it does seem faster - might be an illusion. :) But technical people also know it will help with DNS network wide overhead as well and I think that is a big plus for helping its standardization. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From dotis@mail-abuse.org Wed Feb 22 17:03:33 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F130F21F8467 for ; Wed, 22 Feb 2012 17:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 XkfXvceNO1ka for ; Wed, 22 Feb 2012 17:03:32 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id EB8CD21F8464 for ; Wed, 22 Feb 2012 17:03:31 -0800 (PST) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 1D9B71740337 for ; Thu, 23 Feb 2012 01:03:28 +0000 (UTC) Message-ID: <4F459060.1070208@mail-abuse.org> Date: Wed, 22 Feb 2012 17:03:28 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> <16837068.SztWxPR6Id@scott-latitude-e6320> In-Reply-To: <16837068.SztWxPR6Id@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 01:03:33 -0000 On 2/22/12 8:32 AM, Scott Kitterman wrote: > On Monday, February 20, 2012 09:00:39 AM S Moonesamy wrote: > ... >> "This may be a can of worms, but since we're chartered to tidy up >> where appropriate, I wonder if this might be such a spot. >> >> RFC4408 registered a new DNS RRtype, SPF, code 99. >> >> Are we able to tell how much deployment it's received? If only >> little (which is what I suspect, but I've no data to back that up), >> would it be appropriate to relegate its discussion to an appendix and >> call it "historic"?" > ... > > Since discussion on this seems to have died down and we've a dearth of other > on topic topics to talk about, I'll attempt a summary (I know there is still > data collection going on, but I think it's reasonable to assume that they will > confirm the current sense that deployment is miminal). > > It seems to me that the group is in favor of deprecating type SPF. We can > call it historic, but since the RRtype will still be assigned, it could be > used if there were ever a non-backward compatible update to SPF. > > Any objections to that as a sense of the group? > Dear Scott, Don't know what calling SPF RR Historic would mean. It would have made sense to deprecate (ab)use of TXT RR, but that opportunity was lost with termination of Marid. :^( Deprecating SPF RR is logical, although not having this alternative means TXT RR collisions with other uses can not be avoided. TXT RR at the base domain is a logical location for many uses that must be shared with various versions of SPF and Sender-ID. Regards, Douglas Otis From presnick@qualcomm.com Wed Feb 22 17:21:24 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5461821E8020 for ; Wed, 22 Feb 2012 17:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSfCj26tS6pk for ; Wed, 22 Feb 2012 17:21:23 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB2B21E801D for ; Wed, 22 Feb 2012 17:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1329960083; x=1361496083; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F45948F.6030809@qualcomm.com>|Date:=20We d,=2022=20Feb=202012=2019:21:19=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20|CC:=20Dave =20CROCKER=20,=20,=20 Scott=20Kitterman=0D=0A=09|Subject: =20Re:=20[spfbis]=20#9:=20RFC=204408=20SPF=20RR=20type |References:=20<20120222193641.73783.qmail@joyce.lan>=09< 4F4555F5.1090301@dcrocker.net>=09<20120222211346.GI36315@ mail.yitter.info>=09<4769367.fJYZXf1raF@scott-latitude-e6 320>=09<4F456B1B.6060508@qualcomm.com>=20<4F457A2A.605080 2@dcrocker.net>|In-Reply-To:=20<4F457A2A.6050802@dcrocker .net>|Content-Type:=20text/plain=3B=20charset=3D"ISO-8859 -1"=3B=20format=3Dflowed|Content-Transfer-Encoding:=207bi t|X-Originating-IP:=20[172.30.39.5]; bh=lIijiT8tCgAbJdEGsgXNnUlNF9npqd+Tmjs1omjIDok=; b=ujKJEB7Etll3CNGFb33edJx+OthkMa7CcaHuhlyB8vUy8a8fNXlGjuex krDxntB6YW7fP7ZVFtkLpfriZ6xuDdZ12nGMgKO7xGBEYbfmoeTjaXgcM Hy0//RhO+8oCdmDRLwtzSN4YG+xMjKJ//2KhoZHM/SqlMWa7tWRwp0mE3 o=; X-IronPort-AV: E=McAfee;i="5400,1158,6628"; a="163206235" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 22 Feb 2012 17:21:22 -0800 X-IronPort-AV: E=Sophos;i="4.73,464,1325491200"; d="scan'208";a="201670598" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 22 Feb 2012 17:21:22 -0800 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 22 Feb 2012 17:21:21 -0800 Message-ID: <4F45948F.6030809@qualcomm.com> Date: Wed, 22 Feb 2012 19:21:19 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <20120222193641.73783.qmail@joyce.lan> <4F4555F5.1090301@dcrocker.net> <20120222211346.GI36315@mail.yitter.info> <4769367.fJYZXf1raF@scott-latitude-e6320> <4F456B1B.6060508@qualcomm.com> <4F457A2A.6050802@dcrocker.net> In-Reply-To: <4F457A2A.6050802@dcrocker.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org, Dave CROCKER , Scott Kitterman Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 01:21:24 -0000 Let me open by saying: I am absolutely fine with either outcome on this particular issue. My only reason for posting was because I thought Andrew and Scott were talking past each other, and this is an important issue to decide one way or the other. Do take whatever I say here as trying to elucidate; I am absolutely ambivalent about the outcome. So, still trying to be hatless: On 2/22/12 5:28 PM, Dave CROCKER wrote: > On 2/22/2012 2:24 PM, Pete Resnick wrote: > >> The harm is that everyone has to upgrade they're querying software to >> stop >> querying for the SPF record. > > They do not have to. The /may/ do it, if they want the benefit. Well, the query for 99 would then be "out of spec", but yes, you are correct. >>> What's the benefit of not doing away with it? Nothing as far as I >>> can tell. >> >> No software upgrades, and *if* people (due to the publication of the >> standards >> track document) realize that they should be deploying the SPF record, >> they will >> and that will cut down DNS traffic. > > Right. No software upgrade and no reduction in wasted queries. :) I take your point that my "if" might be equivalent to "if the moon is made of green cheese." > An expectation that people will "realize" they "should" do the SPF RR > establishes a technical requirement based on hypothetical human > behavior, rather than established community need. On the average, the > track record for such adoption predicates is quite poor. Yup. The reason to keep it would be entirely *if* you think there's a chance that people might start using it. If not, the change to client software to eliminate the second query would be reasonable. >> New code (even if it is simplifying code) is always risky code. Not a >> huge risk, >> but a risk nonetheless. Anyway, I'm pretty sure that you are one of >> the more >> motivated SPF developers. :-) > > That invokes a rather unusual argument, for -bis efforts, namely to > retain everything that is not known to be highly problematic. > > Whereas typical -bis efforts are encouraged to drop unused features, > to simplify the spec and simply implementations and -- often -- > simplify operations. Actually, I think both are true: In moves along the standards track, we get rid of unused things, but we also don't dork with things that are used if they're not causing problems. My only point was this is an unusual situation in that the client side of this piece protocol *is* demonstrably used, in that clients *are* sending the queries, and the server side is excruciatingly minimally used, meaning that the clients are not getting any use out of doing so. Add to that the unusualness of the fact that this is *not* progress along the standards track (which is what we normally think of as the -bis effort), but getting something onto the standards track. If we decide that the feature is essentially unused except for some outliers who won't be bothered if we remove the feature, peachy, we should remove it. If we decide that there is some use, but it's complicating the protocol and possibly causing problems, also peachy. If we decide that it is getting at least some use *and* there is a reasonable possibility that increased use will occur and that will improve things, the we should go the other way. I think those are the sorts of things folks should be looking at. Back to watching from the corner. :-) pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From spf2@kitterman.com Wed Feb 22 19:16:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13C321E8052 for ; Wed, 22 Feb 2012 19:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQQPhgasFVdX for ; Wed, 22 Feb 2012 19:16:34 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8052021E8020 for ; Wed, 22 Feb 2012 19:16:34 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 87B6A20E40CC; Wed, 22 Feb 2012 22:16:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329966993; bh=jl72uv+8ESwUv2+6XqwRokTUK/3sIN0SOw5z4ybLHzQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Dx2PCjupiAN7pJ9/zjtStA3INqWnyYsOvhL2F0nNYEQY0DQDYMuwhShqtYNYHZCof 5gpEf4K2E9M/8nKosZN0UQwAc0Gc8EPABr/SN2s6G1px5rfC9KbHPPuqlNM8FzH2g2 dAsjHoyRBl/DGUszlqUsVxHJS6qqgdWNZX8CpieI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6E7C720E408E; Wed, 22 Feb 2012 22:16:33 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Feb 2012 22:16:32 -0500 Message-ID: <1692451.EA81FzBU3m@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F45948F.6030809@qualcomm.com> References: <20120222193641.73783.qmail@joyce.lan> <4F457A2A.6050802@dcrocker.net> <4F45948F.6030809@qualcomm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 03:16:35 -0000 On Wednesday, February 22, 2012 07:21:19 PM Pete Resnick wrote: > Let me open by saying: I am absolutely fine with either outcome on this > particular issue. My only reason for posting was because I thought > Andrew and Scott were talking past each other, and this is an important > issue to decide one way or the other. Do take whatever I say here as > trying to elucidate; I am absolutely ambivalent about the outcome. > > So, still trying to be hatless: > > On 2/22/12 5:28 PM, Dave CROCKER wrote: > > On 2/22/2012 2:24 PM, Pete Resnick wrote: > >> The harm is that everyone has to upgrade they're querying software to > >> stop > >> querying for the SPF record. > > > > They do not have to. The /may/ do it, if they want the benefit. > > Well, the query for 99 would then be "out of spec", but yes, you are > correct. > > >>> What's the benefit of not doing away with it? Nothing as far as I > >>> can tell. > >> > >> No software upgrades, and *if* people (due to the publication of the > >> standards > >> track document) realize that they should be deploying the SPF record, > >> they will > >> and that will cut down DNS traffic. > > > > Right. No software upgrade and no reduction in wasted queries. > : > :) I take your point that my "if" might be equivalent to "if the moon is > made of green cheese." > > > An expectation that people will "realize" they "should" do the SPF RR > > establishes a technical requirement based on hypothetical human > > behavior, rather than established community need. On the average, the > > track record for such adoption predicates is quite poor. > > Yup. The reason to keep it would be entirely *if* you think there's a > chance that people might start using it. If not, the change to client > software to eliminate the second query would be reasonable. > > >> New code (even if it is simplifying code) is always risky code. Not a > >> huge risk, > >> but a risk nonetheless. Anyway, I'm pretty sure that you are one of > >> the more > >> motivated SPF developers. :-) > > > > That invokes a rather unusual argument, for -bis efforts, namely to > > retain everything that is not known to be highly problematic. > > > > Whereas typical -bis efforts are encouraged to drop unused features, > > to simplify the spec and simply implementations and -- often -- > > simplify operations. > > Actually, I think both are true: In moves along the standards track, we > get rid of unused things, but we also don't dork with things that are > used if they're not causing problems. My only point was this is an > unusual situation in that the client side of this piece protocol *is* > demonstrably used, in that clients *are* sending the queries, and the > server side is excruciatingly minimally used, meaning that the clients > are not getting any use out of doing so. Add to that the unusualness of > the fact that this is *not* progress along the standards track (which is > what we normally think of as the -bis effort), but getting something > onto the standards track. > > If we decide that the feature is essentially unused except for some > outliers who won't be bothered if we remove the feature, peachy, we > should remove it. > If we decide that there is some use, but it's complicating the protocol > and possibly causing problems, also peachy. > If we decide that it is getting at least some use *and* there is a > reasonable possibility that increased use will occur and that will > improve things, the we should go the other way. > > I think those are the sorts of things folks should be looking at. > > Back to watching from the corner. :-) I think this is an important, but not absolutely critical, issue for the WG. I've made my preference clear (I'm sure), but I'm not going to get extraordinarily worked up over it. This is a nice opportunity to simplify the protocol with no interoperability harm, but it doesn't touch on the critical issues such as backward compatiblity. One additional data point that might be of interest ... I suspect a large fraction of the Type SPF queries people are seeing are due to Spamassassin using Mail::SPF and Mail::SPF has Type SPF queries enabled by default. The reason they are enabled by default is that the Mail::SPF author aimed it to be suitable to be a reference implementation for RFC 4408, so he followed it's guidance as closely as he could. I believe it's his intent to do the same for 4408bis. It's a configuration option to disable and a one liner to change the default, so I suspect the estimates of ten years to change this are a bit long. Scott K From msk@cloudmark.com Wed Feb 22 20:20:34 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C766C21E801B for ; Wed, 22 Feb 2012 20:20:34 -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=[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 J3ViqRG0d+UG for ; Wed, 22 Feb 2012 20:20:34 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 227EE21E8013 for ; Wed, 22 Feb 2012 20:20:34 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Wed, 22 Feb 2012 20:20:33 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #9: RFC 4408 SPF RR type Thread-Index: Aczv8UQLV2N/uDLSRyC+8YNgJDPwqgB0W1qAABHUEwAACeYrIA== Date: Thu, 23 Feb 2012 04:20:32 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280411EB@exch-mbx901.corp.cloudmark.com> References: <061.ee61a991cb4a8d6f551a12d6371a2491@tools.ietf.org> <6.2.5.6.2.20120220083104.0a5207d0@elandnews.com> <16837068.SztWxPR6Id@scott-latitude-e6320> <4F459060.1070208@mail-abuse.org> In-Reply-To: <4F459060.1070208@mail-abuse.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 04:20:35 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Douglas Otis > Sent: Wednesday, February 22, 2012 5:03 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] #9: RFC 4408 SPF RR type >=20 > Deprecating SPF RR is logical, although not having this alternative > means TXT RR collisions with other uses can not be avoided. TXT RR at > the base domain is a logical location for many uses that must be shared > with various versions of SPF and Sender-ID. What collision problem is not solved by discarding those TXT records in the= reply that don't start with "v=3Dspf1"? From msk@cloudmark.com Wed Feb 22 20:30:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A448D21E8016 for ; Wed, 22 Feb 2012 20:30:31 -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 Has0GgyO9YUA for ; Wed, 22 Feb 2012 20:30:31 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0A721E8013 for ; Wed, 22 Feb 2012 20:30:31 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Wed, 22 Feb 2012 20:30:30 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #9: RFC 4408 SPF RR type Thread-Index: Aczv8UQLV2N/uDLSRyC+8YNgJDPwqgB0W1qAAADgQwAAAvuJAAAAWKmAAA8t1pD//5hAgIAAAUyAgAAHkwCAAAOfgIAAF4aAgAAWgEA= Date: Thu, 23 Feb 2012 04:30:30 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392804121D@exch-mbx901.corp.cloudmark.com> References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <1393684.knylKaz50c@scott-latitude-e6320> <6.2.5.6.2.20120222124752.09f0d510@resistor.net> In-Reply-To: <6.2.5.6.2.20120222124752.09f0d510@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 04:30:31 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of S Moonesamy > Sent: Wednesday, February 22, 2012 1:46 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] #9: RFC 4408 SPF RR type >=20 > Hello, >=20 > I have been following the discussion about SPF RR Type. It seems that > the issue is being read as a binary question, i.e. should the SPR RR > record be kept or not. Some of the questions that come to my mind are: >=20 > (a) How many domains are publishing SPF RR records? >=20 > (b) How many domains are publishing SPT TXT records? >=20 > (c) How many domains are querying for SPR RR records? >=20 > (d) How many domains are querying for SPR TXT records? >=20 > (e) What are the implementations out there? >=20 > (f) What DNS records do the implementations query for? >=20 > The above is not an exhaustive list of questions. If I missed any > questions, let me know. Without empirical data, it is not possible to > answer these questions. Is there anyone who would like to volunteer to > find the answers to these questions? We can get answers to (a) and (b) just by querying some large list of domai= ns. Philip from Cisco did one batch and I'm running another which can at l= east answer those two, and I'm running my own similar report. To do (c) and (d) we need to look at nameserver logs. John Levine is condu= cting that experiment. I don't know how we could come up with an exhaustive list of (e) for Sender= -ID, but it seems that OpenSPF has a fairly comprehensive list for SPF. For (f), again we're split between the two proposals, and now we need docum= entation and/or source code for each. I suggest that the answers to (e) and (f) might reasonably be approximated = by the answers to (c) and (d). -MSK From dhc2@dcrocker.net Wed Feb 22 22:09:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6490B21F8601 for ; Wed, 22 Feb 2012 22:09:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeNf9-FdPoUv for ; Wed, 22 Feb 2012 22:09:40 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 68F4521F855B for ; Wed, 22 Feb 2012 22:09:39 -0800 (PST) Received: from [192.168.10.110] (64.1.210.2.ptr.us.xo.net [64.1.210.2]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1N69XkV029096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 22:09:38 -0800 Message-ID: <4F45D817.5040400@dcrocker.net> Date: Wed, 22 Feb 2012 22:09:27 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Pete Resnick References: <20120222193641.73783.qmail@joyce.lan> <4F4555F5.1090301@dcrocker.net> <20120222211346.GI36315@mail.yitter.info> <4769367.fJYZXf1raF@scott-latitude-e6320> <4F456B1B.6060508@qualcomm.com> <4F457A2A.6050802@dcrocker.net> <4F45948F.6030809@qualcomm.com> In-Reply-To: <4F45948F.6030809@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 22 Feb 2012 22:09:39 -0800 (PST) Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 06:09:41 -0000 On 2/22/2012 5:21 PM, Pete Resnick wrote: >>> The harm is that everyone has to upgrade they're querying software to stop >>> querying for the SPF record. >> >> They do not have to. The /may/ do it, if they want the benefit. > > Well, the query for 99 would then be "out of spec", but yes, you are correct. 1. They'd perceive no change. No added overhead. No change in error message. Nothing. 2. In formal terms, yes, the behavior would no longer be conformant, but I guess my reaction is, so what? What's unusual and quite nice about the current opportunity is that dropping this has no (new) downside for those who happen to publish the record or do the query. >> An expectation that people will "realize" they "should" do the SPF RR >> establishes a technical requirement based on hypothetical human behavior, >> rather than established community need. On the average, the track record for >> such adoption predicates is quite poor. > > Yup. The reason to keep it would be entirely *if* you think there's a chance > that people might start using it. If not, the change to client software to > eliminate the second query would be reasonable. If there were any indication of an adoption vector or a change in incentives (or value proposition or anything else that would drive an adopter pull) I'd say keep it. But we've had plenty of time for the trajectory to be established and nothing that I know of is happening that changes where things currently are. >>> New code (even if it is simplifying code) is always risky code. Not a huge risk, >>> but a risk nonetheless. Anyway, I'm pretty sure that you are one of the more >>> motivated SPF developers. :-) >> >> That invokes a rather unusual argument, for -bis efforts, namely to retain >> everything that is not known to be highly problematic. >> >> Whereas typical -bis efforts are encouraged to drop unused features, to >> simplify the spec and simply implementations and -- often -- simplify operations. > > Actually, I think both are true: In moves along the standards track, we get rid > of unused things, but we also don't dork with things that are used if they're > not causing problems. So, in this case, there's some ambiguity to the use of what it means to be "used". We have almost no one publishing the record; this means "unused". We have a significant number of failed queries being made for the record; querying is a form of "being used". Mumble. Querying and having no problems falling back to the alternative record means "/trying/ to be used, but fine with failing". Foo. > My only point was this is an unusual situation in that the > client side of this piece protocol *is* demonstrably used, in that clients *are* > sending the queries, and the server side is excruciatingly minimally used, > meaning that the clients are not getting any use out of doing so. Add to that > the unusualness of the fact that this is *not* progress along the standards > track (which is what we normally think of as the -bis effort), but getting > something onto the standards track. Well, not surprisingly, we agree this is an odd one, for analysis. If one takes an end-to-end view of things -- and I realize that's an unusual perspective these days -- it has no real-world, system-level end-to-end utility. > If we decide that the feature is essentially unused except for some outliers who > won't be bothered if we remove the feature, peachy, we should remove it. There is not evidence that it will magically become useful. So even though this is a perspective from which it can legitimately be claimed it it is used, there is not current perspective from which it can be claimed to be useful. In the face of that, I find the benefit of simplification to be a strong argument in favor of dropping it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Wed Feb 22 22:35:25 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BB821F8566 for ; Wed, 22 Feb 2012 22:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXRxVg9kV1B4 for ; Wed, 22 Feb 2012 22:35:22 -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 C9D4421F85A3 for ; Wed, 22 Feb 2012 22:35:22 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.232.96]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1N6Z12e004540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 22:35:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329978915; i=@elandsys.com; bh=baSekO7P6+d7qyOqP0bDup2fDBTkMGDQ2Xh8ggPOogg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=2i6lwwn/gpM0QjeGIgZCvuJQ2CG5LSfcAMrJ4aNdeGt9jvSj/nOn7b3m6hh5okuTI MgT0lXvkEZikiNkAqvfbUB1XjYNgsyQ8zv1VzkV/OJKMdERsyOIKNOJubX0etrDUHy 7aBOaLXBENrLrWqI2wfcPfDD71S5XXGcGNR3h9Ho= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329978915; i=@elandsys.com; bh=baSekO7P6+d7qyOqP0bDup2fDBTkMGDQ2Xh8ggPOogg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=O5z7Tco62GjtWnsT/mlTsbTSL8CID+HO1Bi+WoT/Nds/4rIv3QiSI9LJQHWUJOq+g 0ErtQHNN3v52ivOgJO0YdCm3OYVQ2yy74BQ1rJECur1VTDCqfl9wI3Ol3u28kJ3SGV 6OcxVtqNCF6wUakRLZ2foowe1vgKE+chkjRst7a0= Message-Id: <6.2.5.6.2.20120222214109.0a82ab48@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Feb 2012 22:20:20 -0800 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: <9452079D1A51524AA5749AD23E00392804121D@exch-mbx901.corp.cl oudmark.com> References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <1393684.knylKaz50c@scott-latitude-e6320> <6.2.5.6.2.20120222124752.09f0d510@resistor.net> <9452079D1A51524AA5749AD23E00392804121D@exch-mbx901.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 06:35:25 -0000 Hi Murray, At 20:30 22-02-2012, Murray S. Kucherawy wrote: >We can get answers to (a) and (b) just by querying some large list >of domains. Philip from Cisco did one batch and I'm running another >which can at least answer those two, and I'm running my own similar report. Ok. >To do (c) and (d) we need to look at nameserver logs. John Levine >is conducting that experiment. > >I don't know how we could come up with an exhaustive list of (e) for >Sender-ID, but it seems that OpenSPF has a fairly comprehensive list for SPF. It's a best effort. It is not be possible to come up with a list of every implementation out there. >For (f), again we're split between the two proposals, and now we >need documentation and/or source code for each. Ok. >I suggest that the answers to (e) and (f) might reasonably be >approximated by the answers to (c) and (d). The WG decisions will be reviewed by the IETF Community during the IETF Last Call. I would like to see some effort on (e) and (f) so that the SPFBIS WG can say that it carefully considered the issue. Would you like to volunteer? Regards, S. Moonesamy SPFBIS WG co-chair From johnl@iecc.com Wed Feb 22 22:46:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6944811E8085 for ; Wed, 22 Feb 2012 22:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.981 X-Spam-Level: X-Spam-Status: No, score=-109.981 tagged_above=-999 required=5 tests=[AWL=1.218, 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 dhHCf6rai8B0 for ; Wed, 22 Feb 2012 22:46:39 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8A20311E807F for ; Wed, 22 Feb 2012 22:46:39 -0800 (PST) Received: (qmail 62391 invoked from network); 23 Feb 2012 06:46:38 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Feb 2012 06:46:38 -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=4f45e0cd.xn--hew.k1202; i=johnl@user.iecc.com; bh=eAv5V/u+jPFLpBvzWWFOVvtX99ZpZBNraRbL7lR8xZ0=; b=Sv/7VL4dG00DUN8jsUaM9HSvEgw5KM5eyc1pfPYxg6+8OL02KMKVpLyi5V8ABVwu7e2bHO9FEPY2lbaCJgFC4pWMqVrUfLlPoCyz2HjNfqnk0bXnRBfNCL0FRkyzT+0+Nv8K9SaAt/pnwhba6Bl2TViElxbhbV/6SGEQuf0tBBc= 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=4f45e0cd.xn--hew.k1202; olt=johnl@user.iecc.com; bh=eAv5V/u+jPFLpBvzWWFOVvtX99ZpZBNraRbL7lR8xZ0=; b=Y2nAHqa7hH+A+o94X59zIUAFOM2Cluj2HXaYATnba2prDX90fjQGaHPxr4Da3G8CuLdm0kdLojGudDuTyufG9l+QVAPAuacf4fwP9GMxXbtZah23+qCdBGfIh6BBSgBt9mbNpq80CkB6QOKn8RpTnyEFl0BcwZatid25DViXXus= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 23 Feb 2012 06:46:15 -0000 Message-ID: <20120223064615.33784.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E0039280411EB@exch-mbx901.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: msk@cloudmark.com Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 06:46:40 -0000 >What collision problem is not solved by discarding those TXT records in the reply >that don't start with "v=spf1"? The "so many text records that the response doesn't fit in a UDP packet" problem, I guess, although I must admit I haven't run into that one in practice. There are other reasons to want a specific record type such as playing nicely with wildcards, but that is, shall we say, water under the dam in this particular case where the practice is well established. R's, John From spf@jubileegroup.co.uk Wed Feb 22 23:50:09 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A8F21E802E for ; Wed, 22 Feb 2012 23:50:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOWi-pAy+si6 for ; Wed, 22 Feb 2012 23:50:08 -0800 (PST) Received: from mail.jubileegroup.co.uk (jubileegroup.co.uk [217.147.177.250]) by ietfa.amsl.com (Postfix) with ESMTP id 986B321E8016 for ; Wed, 22 Feb 2012 23:50:08 -0800 (PST) Received-SPF: pass (mail5: domain of spf@jubileegroup.co.uk designates 127.0.0.1 as permitted sender) receiver=mail5; client-ip=127.0.0.1; helo=mail5.jubileegroup.co.uk; envelope-from=spf@jubileegroup.co.uk; x-software=spfmilter 0.98-gwh with libspf2-1.2.9; X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3-exp at mail5 Received: from mail5.jubileegroup.co.uk (localhost [127.0.0.1]) by mail5.jubileegroup.co.uk (8.14.5/8.14.5) with ESMTP id q1N7o4Lj024420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Feb 2012 07:50:05 GMT Received: from localhost (ged@localhost) by mail5.jubileegroup.co.uk (8.14.5/8.14.3/Submit) with ESMTP id q1N7o37n024417 for ; Thu, 23 Feb 2012 07:50:04 GMT X-Authentication-Warning: mail5.jubileegroup.co.uk: ged owned process doing -bs Date: Thu, 23 Feb 2012 07:50:03 +0000 (GMT) From: "G.W. Haywood" X-X-Sender: ged@mail5.jubileegroup.co.uk To: spfbis@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mail5 [0.0.0.0]); Thu, 23 Feb 2012 07:50:05 +0000 (GMT) X-Originating-Country: localhost X-Scanned-By: MIMEDefang 2.72 on 192.168.44.246 Subject: Re: [spfbis] New Issue: Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 07:50:09 -0000 Hi there, On Mon, 20 Feb 2012, Scott Kitterman wrote: > Paragraph 2.2, The MAIL FROM Identity, includes this statement: > > SPF clients MUST check the "MAIL FROM" identity. SPF clients check > the "MAIL FROM" identity by applying the check_host() function to the > "MAIL FROM" identity as the . > > There are applications that check HELO first and can reach a final conclusion > about message disposition based on that check. In such a case, the Mail From > check is a waste of resources. > > I'm recommend changing this to either: > > SPF clients MUST check the "MAIL FROM" identity unless a HELO check has > already produced a definititive policy result. ... I'd question the wording "definititive policy result" (and not just because of the spelling. :) The word 'policy' in this case might be taken to mean "SPF policy", yet a rejection at the HELO stage can be made for a number of reasons, some of which require very little processing and no DNS lookups. Most of the garbage HELOs we see result in immediate rejection before an SPF check has been made, so in a sense it is a 'policy' decision e.g. because we don't accept mail from home routers, but it isn't SPF policy. -- 73, Ged. From msk@cloudmark.com Thu Feb 23 00:02:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4841921F855B for ; Thu, 23 Feb 2012 00:02:56 -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=[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 0btkppeH4NKK for ; Thu, 23 Feb 2012 00:02:55 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id AFA4521F855A for ; Thu, 23 Feb 2012 00:02:55 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Thu, 23 Feb 2012 00:02:47 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors Thread-Index: AQHM8Z1H6I5T9g0T0E20useE1cLBoZZKHlgA Date: Thu, 23 Feb 2012 08:02:46 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280417A3@exch-mbx901.corp.cloudmark.com> References: <061.455654aa40583da61895c644f7120a55@tools.ietf.org> <6.2.5.6.2.20120222115949.08f70548@elandnews.com> In-Reply-To: <6.2.5.6.2.20120222115949.08f70548@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 08:02:56 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of S Moonesamy > Sent: Wednesday, February 22, 2012 12:04 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors >=20 > > I think that RCODE 2 replies should be considered PermError instead > > of TempError. > > > > The operational impact of this is that messages are deferred (4xx) > > instead of rejected (5xx) so they sit in a deferral queue and are > > retried for however long the sending MTA is configured to attempt it. > > The user of the message isn't notified of the non-delivery until it > > expires out of the queue, generally after several days. > > > > In the SPF policy server for Postfix that I maintain, I changed the > > default action on TempError from defer as a result of this issue. I'm not sure I agree with this. The definition of SERVFAIL (which is RCODE= 2) from RFC1035 is: 2 Server failure - The name server was unable to process this query due to a problem with the name server. That's plenty general. Absent a list of specific reasons why a nameserver = might return that error, I'm left not knowing whether the error is transien= t (resources, perhaps) or one that does indeed require operator interventio= n. So perhaps Andrew is in a good position to answer this, hatless of course: = Has there ever been more specific guidance about the use of SERVFAIL, or pe= rhaps the introduction of other RCODEs, to make this less ambiguous? -MSK From hsantos@isdg.net Thu Feb 23 03:59:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9CB21F863C for ; Thu, 23 Feb 2012 03:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.442, 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 72d7sdPZpjhG for ; Thu, 23 Feb 2012 03:59:55 -0800 (PST) Received: from ntbbs.santronics.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA9521F8618 for ; Thu, 23 Feb 2012 03:59:54 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2703; t=1329998390; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=LioRrQSFii2ZdGVEA37t6PFE0HU=; b=O3pk1bjqpRQE3DalDl4W 0IwtKZne4myTX/3lrDj6Hblaqf1Nj75kNmnQ5P9mSw7moieNIuX0ZMMeSBZhuZ7J 3x1IraKktomVUzGh3DmOUNh1znH6IA1agoRgGZbJPc6X4toQ74/KQ3Br6QVG5P1y TxYKLmR6XZhzluG+k/kePRM= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 23 Feb 2012 06:59:50 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3200234044.89717.2628; Thu, 23 Feb 2012 06:59:49 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2703; t=1329998150; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=qV6XnyZ a3FbDyw4BNxijCiBaBWlc1/dymbTF8HfoOpU=; b=d7/CgOq87hYPWQG5rFhsYOO rFxrt8tC2mkb7Ral6SBm8TJV3OKneEu+gJuS2EN10M5S9xt3ci/yzlXxJgNIwOxN YJfRv5KJIS6777mu59+6nL2aP0SDKrPuyQXGp1dvPHNSdP5P+w8DmEgHzGf61fC0 xDmQP3daCeS2MaF87Scc= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 23 Feb 2012 06:55:50 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3799172470.19003.944; Thu, 23 Feb 2012 06:55:49 -0500 Message-ID: <4F462A21.50404@isdg.net> Date: Thu, 23 Feb 2012 06:59:29 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Pete Resnick References: <20120222193641.73783.qmail@joyce.lan> <4F4555F5.1090301@dcrocker.net> <20120222211346.GI36315@mail.yitter.info> <4769367.fJYZXf1raF@scott-latitude-e6320> <4F456B1B.6060508@qualcomm.com> <4F457A2A.6050802@dcrocker.net> <4F45948F.6030809@qualcomm.com> In-Reply-To: <4F45948F.6030809@qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 11:59:56 -0000 Hi Pete, Don't wish to fall trap to generalization, a 'No Surprise Principle' , perhaps a conservative approach is probably a good (specific) BIS policy model for SPF/SIDF/SUBMITTER. Optional reading below. Pete Resnick wrote: > > ... > > If we decide that the feature is essentially unused except for some > outliers who won't be bothered if we remove the feature, peachy, we > should remove it. > If we decide that there is some use, but it's complicating the protocol > and possibly causing problems, also peachy. > If we decide that it is getting at least some use *and* there is a > reasonable possibility that increased use will occur and that will > improve things, the we should go the other way. > > I think those are the sorts of things folks should be looking at. There is much conflict of interest (and not all in negative sense) but in end goals; IETF desires, the Technology Leader (SPF Council) desires, existing implementations desires which include: - Pure SPF advocates, - Pure SIDF advocates (the corporate image), - And system integrators of both. A historical fact is that SPF was fast becoming a widely adopted NON-IETF protocol in all market segments. I generally never use non-standard technology, and it was only when AOL announced SPF support, did I finally stop other work and began to support it as well. Soon Microsoft came with its XML version of SPF (CEP) and throw in the SPF wench with the suggestion and use cases for the existence of a 3rd payload based Identity - Purported Responsible Author (PRA) or Submitter. Yet too many, including myself, believed it was just not going to past IETF reviews. Of course, with all its DNS dependency, higher overhead and usage of TXT - yet still an less preferred idea to many to use for policies, the limits concerns, etc. I only point this out because the only way to fast track the consolidation effort into IETF controlled RFCs was to give it a Experimental Status. That is want people wanted - IETF based open source once MS came. But I would be among those that would suggest, this (at least SPF) was already well beyond an "Experiment", already added and part of production vender code and operations, and today, IMV, IETF needs to consider that its not something that will offer a lot of room to drastically change it which can be very easy to do from a pure IETF "Experimental Status" perspective. I am just saying, IMV, this is just one of those well entrenched fast tracked protocols less open to typical and valid "Experiment Status" stripped down efforts. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Thu Feb 23 06:29:11 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1B821F8518 for ; Thu, 23 Feb 2012 06:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5pXxuCmtogj for ; Thu, 23 Feb 2012 06:29:10 -0800 (PST) Received: from winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D281621F87C8 for ; Thu, 23 Feb 2012 06:29:08 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3918; t=1330007340; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=vlxUscdwe4qo9BqD1yNi6O5L2UY=; b=IcAOaYfZCQTVEvxmYAc3 ERfreOIqs3QI6EjEEF2FUHZSIUFJPLE2Rb9+Siy5ci8q7bzNlWttPzcpTDtRdnSr dsmexBzpjJhZ/DZApt1CpqL+CFa1ozxcOtL/J/dGKoEFsk2trFlme9cC1qKLxbIX 4r7BkGpaJ/01LCCkSd0bsM4= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 23 Feb 2012 09:29:00 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3209184336.89717.2112; Thu, 23 Feb 2012 09:28:59 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3918; t=1330007096; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=wNKMDka 1D06+hoHYsNX004VdUrMggR3t1vaz+30RR2M=; b=MvugDDFbXXehbiXvD1MDYDP DN4kmyoPFfVzaJjVoVYoO8oCxOpEOlsL2bucv+AqeLVzKY0lNfQ5tTm6aT7/lQtO 4WnF482IHLZgm6jDvgQUWVouWr9kXF+81nDe2WB+NqnTwEBqaaO+uHsssGmElisG kqhcjxBn2G6TTUHzwsR4= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 23 Feb 2012 09:24:56 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3808118611.19015.4900; Thu, 23 Feb 2012 09:24:55 -0500 Message-ID: <4F464D25.80606@isdg.net> Date: Thu, 23 Feb 2012 09:28:53 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <061.455654aa40583da61895c644f7120a55@tools.ietf.org> <6.2.5.6.2.20120222115949.08f70548@elandnews.com> <9452079D1A51524AA5749AD23E0039280417A3@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280417A3@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 14:29:11 -0000 Murray S. Kucherawy wrote: >> Scott Kitterman >> >>> I think that RCODE 2 replies should be considered PermError instead >>> of TempError. >>> >>> The operational impact of this is that messages are deferred (4xx) >>> instead of rejected (5xx) so they sit in a deferral queue and are >>> retried for however long the sending MTA is configured to attempt it. >>> The user of the message isn't notified of the non-delivery until it >>> expires out of the queue, generally after several days. >>> >>> In the SPF policy server for Postfix that I maintain, I changed the >>> default action on TempError from defer as a result of this issue. > > I'm not sure I agree with this. The definition of SERVFAIL (which is RCODE 2) > from RFC1035 is: > > 2 Server failure - The name server was > unable to process this query due to a > problem with the name server. > > That's plenty general. Absent a list of specific reasons why a > nameserver might return that error, I'm left not knowing whether the > error is transient (resources, perhaps) or one that does indeed > require operator intervention. +1, SERVFAIL is not always a "permanent" failure concept and it could just mean the DNS resolver was just not available for whatever reasons, including for smaller system being throttled by their ISP. It could be self-correcting as well. But one thing I have learned (across the board for all DNS related application level protocols) is that results and application protocol translations of results was a fine tuning concept for the default configuration and for the most part, items initially prepared as too restrictive changed to a more relaxed translation. I view this as prudent design for SPF systems deployed for SMTP level policy based failure detection for instant rejection. For these modes of operations, it needs to be watchful of using restrictive results that are not really zero false positive. I believe SPF-BIS (if not already written somewhere), it should add text that recommends flexibility for SPF. For example: SPF implementators MUST|SHOULD|MAY make the translation and interpretation of results configurable and flexible for operators. SPF implementation SHOULD|MAY be watchful repeated error conditions from a domain and MAY use repeatably failure to translate temporary errors to permanent errors. IMV, this issue falls in the category of Implementators design offerings, but I think it would not be improper to have the above like text added to section because I believe you will get different valid views on how check_host() is designed Murray. For example, check_host() does require a internal "results" in order to generate the returned result. For me, because I do have a very strong deterministic framework philosophy looking for the definitive domain declared policy violation, anything less than 100% definitive internal results due to NXDOMAIN, SERVFAIL or other unexpected exception, our check_host() will basically return a "Unknown" or "Nothing here" translation. Hence a "I don't know" go ahead 250 for the most part, but perhaps even 45x - it depends. This note, how to translated repeated errors that is was always something on my mind, hence why I already asked for the protocols that had a testing bit in its policy to either remove it in the spec spec or add monitoring logic semantics. I don't recall if SPF had one, seem to remember it did but I may be confusing that with the same request I did for DKIM, and why it says: y .... Verifiers MAY wish to track testing mode results to assist the Signer. but I wasn't thinking about assisting the sender, but assisting the #1 victim, the receiver, in this case the SPF receiver, who would be getting these redundant errors, including temporary ones. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From vesely@tana.it Thu Feb 23 08:40:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A39E21F87E5 for ; Thu, 23 Feb 2012 08:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[AWL=0.068, 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 mZtmNdIREd8Y for ; Thu, 23 Feb 2012 08:40:38 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE7121F86E0 for ; Thu, 23 Feb 2012 08:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1330015236; bh=WKIekXh6ZBTH5g+A+36VoTFP6WnuIwAYciuobx6xXto=; l=771; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=gP5yNlB5VIf3mIuWC70cbdLZPs7LseXrftkfNBckcEn09WUYdHjKRq210L3s0QQF1 gi0ecar5988XJAxKhfrMgphcF+DgFB5TsfSMTaSSF9P9t/KMOycwWoBqq/Z9sYvUEZ y0NeK4oRt6jFNKUH3c6GZL+SkL7aurPyXt8VgY4w= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 23 Feb 2012 17:40:36 +0100 id 00000000005DC039.000000004F466C04.000043BB Message-ID: <4F466C04.2040603@tana.it> Date: Thu, 23 Feb 2012 17:40:36 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120222193641.73783.qmail@joyce.lan> <4F4555F5.1090301@dcrocker.net> <20120222211346.GI36315@mail.yitter.info> <4769367.fJYZXf1raF@scott-latitude-e6320> <4F456B1B.6060508@qualcomm.com> In-Reply-To: <4F456B1B.6060508@qualcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 16:40:39 -0000 On 22/Feb/12 23:24, Pete Resnick wrote: > Now that I know about this issue, I'm going to go check my own server > and add a 99 record, since I don't think I have one. But I think > that's because I did it so long ago and never looked to see how to > enter a new record type into my little server. But I'm pretty sure I'm > not an average SPF deployer myself. IMHO, cycles available for SPF maintenance would be better spent adding SPF records for helo names, than keeping SPF and TXT types in sync. If, after a seven-year experiment, we think we are going to need two different RR types for another ten years or so, perhaps we should offer some CTYPE directive that allows a DNS server to send /that/ TXT record in response to SPF queries, or vice-versa. From pgladsto@cisco.com Thu Feb 23 10:42:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AE421F8861 for ; Thu, 23 Feb 2012 10:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AWL=3.000, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdsxJhwwe9XU for ; Thu, 23 Feb 2012 10:42:45 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA8921F885F for ; Thu, 23 Feb 2012 10:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladsto@cisco.com; l=6955; q=dns/txt; s=iport; t=1330022565; x=1331232165; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=CquxiIUWnd84aczr7VosQe5Jima7BUxQc2TW4fAabCs=; b=UfDR19HyXpSaOvRdFkJ8IycvEoJxpxEUmL+FhzMw59S+By33hgp/sTO4 6+TISYarI6MN4PjmixiMum0FqVoy8FPBoQWt/ThPwwjNknG0JIWB6zcNY NuX84tvPwkBe9oWJ+PObpgAECyyeaRUKM6Me17Mn0FghP8emRdHgG8DA7 E=; X-Files: smime.p7s : 3707 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALmHRk+tJXG8/2dsb2JhbABBA4UwrSCBB4FzAQEBBBIBEFUPAgsYCRYLAgICBwMCAQIBCTwTBgIBAR6iMAGMZZIFBI1nEAEKAgUDAoUcZA8KBYIIgRYEiE+GAIEbhU6FXY0ugT4 X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="p7s'?scan'208";a="61330188" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 23 Feb 2012 18:42:44 +0000 Received: from [161.44.112.16] ([161.44.112.16]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1NIgi3V017800 for ; Thu, 23 Feb 2012 18:42:44 GMT Message-ID: <4F4688A1.5070206@cisco.com> Date: Thu, 23 Feb 2012 13:42:41 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <1393684.knylKaz50c@scott-latitude-e6320> <6.2.5.6.2.20120222124752.09f0d510@resistor.net> <9452079D1A51524AA5749AD23E00392804121D@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392804121D@exch-mbx901.corp.cloudmark.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010305010108010506090309" X-Mailman-Approved-At: Thu, 23 Feb 2012 10:45:48 -0800 Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 18:42:46 -0000 This is a cryptographically signed message in MIME format. --------------ms010305010108010506090309 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2/22/2012 11:30 PM, Murray S. Kucherawy wrote: > We can get answers to (a) and (b) just by querying some large list of d= omains. Philip from Cisco did one batch and I'm running another which ca= n at least answer those two, and I'm running my own similar report. > > To do (c) and (d) we need to look at nameserver logs. John Levine is c= onducting that experiment. > I did a quick check over my logs. Over the last 24 hours or so, 372 name = servers have requested SPF or TXT records. 278 requested TXT records.=20 238 requested SPF records. I.e. 144 requested both. I serve up the same=20 data in both the SPF record and the TXT record. These name servers were=20 in 122 different IPv4 /24 networks. [It seems that my nameserver doesn't = have ipv6 connectivity] The /24 with the most DNS servers in it ( 216.69.186.* -- 26 dns=20 servers) was also one which requested both SPF and TXT records the same=20 number of times. This network happens to belong to godaddy (their=20 secureserver.net email service). This is a small sample, but I think it indicates that the deployment of=20 implementations that request SPF records is significant. Philip --=20 Philip Gladstone Distinguished Engineer Product Development pgladstone@cisco.com Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Google: +1 978 800 1010 Ham radio: N1DQ --------------ms010305010108010506090309 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILpjCC BGIwggNKoAMCAQICCmECBKkAAAAAAAowDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTExMDYxNjE3Mjc1 M1oXDTI5MDUxNDIwMjU0MlowIDEOMAwGA1UEChMFQ2lzY28xDjAMBgNVBAMTBW5zYWNhMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsPW3TgI6dWLws7jPhCHFu76rH+hNOBMR pOcjWDKMJLJjd0lP33cD6tYBOzI9bos25Ps4LCKCMtyKTOctsekJ2T+Qc049qSZQbrBP9a75 gq15JvXci5uavSHOXfB2LaVQSNLhEL3q2nvWHmAQsO3RF0r/qqbElUTa7eKV+sOWYBrW3q9g /8Oc4vjpNqVjPydeuHYprYPPAoaX7unIFkgvhfRyQZUJfytTNzF0/AiSdJ/kiCPeJGasH4U7 Eh4kMegdIqF6ETNr7DAXR0bz98g2PIYgmiaXfVdi+yA7hZel7UD+jJ2CEcZp6+jI7RkMQcsc Jw+QoGrrRv2MIq22mZO0YwIDAQABo4IBhzCCAYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0O BBYEFCGmVdkgzOGaWA9OlCFoV0XrZtDoMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsG A1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFCfzyBUebpoCCRat K6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93d3cuY2lzY28uY29tL3NlY3Vy aXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQwQjBABggrBgEFBQcwAoY0 aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2NyY2EyMDQ4LmNlcjBc BgNVHSAEVTBTMFEGCisGAQQBCRUBCAAwQzBBBggrBgEFBQcCARY1aHR0cDovL3d3dy5jaXNj by5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcNAQEFBQAD ggEBAHlcc70Ed/jhBbI90cLUXv37uHT/Qfa/g5FGjp6ZwbW70axDRx9jc4RUJMy/h5zmMuqX 7jheqVuMYzt6yU7rwlMnSCdHYg42hDvHlywhvgAhopA6krjQ9DZ+WCkzn43dXXF+9NqHYQ6W BwgZDpMUM/JT0x0gepqQfyyZxpRsUCaaQEJLxlztcnNVQI3EPh657gaAtgMEZVBOZOewRo4v eVLaHnUmZEwhR/3kB7eCR3iX+CodVBnfQ1EZkOK7SwcO/xXBFPtIKz4bXSzhkUd1hjYCRLn6 +M4NvPnV7AU08751chP63G8amolwCbJCY9gsJsLV9vmzof+gjax165Lvz7Mwggc8MIIGJKAD AgECAgprsDlsAAAAAACfMA0GCSqGSIb3DQEBCwUAMCAxDjAMBgNVBAoTBUNpc2NvMQ4wDAYD VQQDEwVuc2FjYTAeFw0xMTEyMTIxNjA3NTFaFw0yMTEyMDkxNjA3NTFaME4xDjAMBgNVBAoT BUNpc2NvMRkwFwYDVQQDExBQaGlsaXAgR2xhZHN0b25lMSEwHwYJKoZIhvcNAQkBFhJwZ2xh ZHN0b0BjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBuY5IMik+ FVX3/qa/pPWQemXOdJw9FjcHj304v+WS6061QVFYcaY98ydIATjWCMjdx0UzB0aQkHbsuTU6 9ozjIHpdd5GCkSMN2qCjmmEMf1Mk0X7MtsHJ3HDrIn9CYQntnT8lE42E6sD1Ijj2bFCwJwYZ 48ncOT4Br+REDigB5906tZRztKzYL4uRuZrJBD+dNqTv9LuhhBj7vNaoR4Xe1aNokj4XN9Ic bDfy5leMTr2hFN/7dtWLK4HBppMs5rgVcnwG9WGeUWOjBO4hijlNHjW5MWGEe8LDbpd0aChL F+U1zMfsQVVGkloBPSCylBP3BQQQjVscA1L0MEQ8mBN7AgMBAAGjggRIMIIERDAdBgNVHREE FjAUgRJwZ2xhZHN0b0BjaXNjby5jb20wHQYDVR0OBBYEFLcF6Uyi3Kvp6go59Ve/Xm9fBpA/ MB8GA1UdIwQYMBaAFCGmVdkgzOGaWA9OlCFoV0XrZtDoMIHrBgNVHR8EgeMwgeAwgd2ggdqg gdeGgahsZGFwOi8vL0NOPW5zYWNhLENOPU5TQUNBLENOPUNEUCxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNpc2NvLERDPWNv bT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJp YnV0aW9uUG9pbnSGKmh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9maWxlL25zYWNhLmNy bDCB7QYIKwYBBQUHAQEEgeAwgd0wgaIGCCsGAQUFBzAChoGVbGRhcDovLy9DTj1uc2FjYSxD Tj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz1jaXNjbyxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNz PWNlcnRpZmljYXRpb25BdXRob3JpdHkwNgYIKwYBBQUHMAKGKmh0dHA6Ly9jaXNjb2NlcnRz LmNpc2NvLmNvbS9maWxlL25zYWNhLmNlcjALBgNVHQ8EBAMCBeAwOwYJKwYBBAGCNxUHBC4w LAYkKwYBBAGCNxUI7o8kgs6sTYKFhRSRxkSB9p5dgTaC+dcWpNBjAgFkAgEMMHsGA1UdJQR0 MHIGCisGAQQBgjcUAgIGCCsGAQUFBwMEBggrBgEFBQcDBwYIKwYBBQUHAwYGCCsGAQUFCAIC BggrBgEFBQcDBQYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDDAYKKwYBBAGCNwoFAQYIKwYBBQUH AwIGBFUdJQAwXAYDVR0gBFUwUzBRBgorBgEEAQkVAQgAMEMwQQYIKwYBBQUHAgEWNWh0dHA6 Ly93d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9wb2xpY2llcy9pbmRleC5odG1sMIGZBgkr BgEEAYI3FQoEgYswgYgwDAYKKwYBBAGCNxQCAjAKBggrBgEFBQcDBDAKBggrBgEFBQcDBzAK BggrBgEFBQcDBjAKBggrBgEFBQgCAjAKBggrBgEFBQcDBTAMBgorBgEEAYI3CgMEMAwGCisG AQQBgjcKAwwwDAYKKwYBBAGCNwoFATAKBggrBgEFBQcDAjAGBgRVHSUAMEQGCSqGSIb3DQEJ DwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG 9w0DBzANBgkqhkiG9w0BAQsFAAOCAQEAcgHxAMvOX8aMWP3Lr0nO3fcaOcvZKCwykbY386UC lTZfmrGJ03aoCMBikBw7FUg8dhbo9nIPpjlpqaUhTARDvuSSjGKXRP5gvzwSrsnGrxRmBEeL jrKdGKA+KoVN+1/owHDEq/oPHYLd5gbImeGkyg5NIMYm4lyFGxptT3QS/hvAp0VH3ivDh4/N VCQPVvxHHLNh6H1YGq6u3Gd4IDM+ZSRkoh06w+K7Y0nYV+rDb6jPYVWPkM2YUl1RRXyUvIz5 tzIJ44wc8aGfVd+oNdKXIPTqQn+Ag0zIHtBt3mfMjewoKLc5p5A7l3qFXTknRtJBccSs/GBV /ebpSek2s1lJmTGCApcwggKTAgEBMC4wIDEOMAwGA1UEChMFQ2lzY28xDjAMBgNVBAMTBW5z YWNhAgprsDlsAAAAAACfMAkGBSsOAwIaBQCgggE+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIyMzE4NDI0MVowIwYJKoZIhvcNAQkEMRYEFHZYL5wr 0fAxyNWFDWrh91cNhQlGMD0GCSsGAQQBgjcQBDEwMC4wIDEOMAwGA1UEChMFQ2lzY28xDjAM BgNVBAMTBW5zYWNhAgprsDlsAAAAAACfMD8GCyqGSIb3DQEJEAILMTCgLjAgMQ4wDAYDVQQK EwVDaXNjbzEOMAwGA1UEAxMFbnNhY2ECCmuwOWwAAAAAAJ8wXwYJKoZIhvcNAQkPMVIwUDAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBALwwCa0G3RYAzjTS wtJ+0e+CDy0/xOTZEwpcZ0JUIHA+cLj6D1T+LC7xvP1tbtbZ6JUlLCMqVWOFI9MH+pIUu+KC mtmdzh2U+yVaTHQ72+nJREVSZDpUqp24uQvS0AhsuND0eHLGYN2Iy9Q3aFzcMIK/GHPmambp GEsKe9BONoTVD3U3FmoTyLOXZC6+rLdhr1M6GmZEyP9XxydT73gUidZ1rs40dTmrtSyVb0ZT rrvjHPxMh0VlcLcbZCsM39qWLiDhRqTE18/fhpqnwWWkEuz58XAORyToYW4IBWpp4n/S5ghI xPSYeEz1PA8H8CA/gbhlfNiczmu/x9REjkt+noMAAAAAAAA= --------------ms010305010108010506090309-- From spf2@kitterman.com Thu Feb 23 11:02:13 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C4821F87BF for ; Thu, 23 Feb 2012 11:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joFwSo63ZrcA for ; Thu, 23 Feb 2012 11:02:11 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1968821F87AA for ; Thu, 23 Feb 2012 11:02:10 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4B18320E40CC; Thu, 23 Feb 2012 14:02:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330023730; bh=j+5pvxqfRsvUHrLLYya2nJfDTprhOTUcQQzjR9SxW1s=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=WxzIRoD5N3nKkJ4hcy9EjcJu+NcOVnIn62KRpLxkfTmKs+MAnpUqHAL4BweMCm06F EHoAhm7UylfT0ymrbgGHaV7nhhCh3eWjlh5Vsbeq1B/bz9YQpE10FvO2FOPSij7n5h tOrWy2d477BEnoMroTbGt4o2s5ChJELa6i07PRFk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2CD4E20E406C; Thu, 23 Feb 2012 14:02:09 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 23 Feb 2012 14:02:09 -0500 Message-ID: <39120876.7e8QO4qu0j@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F4688A1.5070206@cisco.com> References: <20120222193641.73783.qmail@joyce.lan> <9452079D1A51524AA5749AD23E00392804121D@exch-mbx901.corp.cloudmark.com> <4F4688A1.5070206@cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 19:02:13 -0000 On Thursday, February 23, 2012 01:42:41 PM Philip Gladstone wrote: > On 2/22/2012 11:30 PM, Murray S. Kucherawy wrote: > > We can get answers to (a) and (b) just by querying some large list of > > domains. Philip from Cisco did one batch and I'm running another which > > can at least answer those two, and I'm running my own similar report. > > > > To do (c) and (d) we need to look at nameserver logs. John Levine is > > conducting that experiment. > I did a quick check over my logs. Over the last 24 hours or so, 372 name > servers have requested SPF or TXT records. 278 requested TXT records. > 238 requested SPF records. I.e. 144 requested both. I serve up the same > data in both the SPF record and the TXT record. These name servers were > in 122 different IPv4 /24 networks. [It seems that my nameserver doesn't > have ipv6 connectivity] > > The /24 with the most DNS servers in it ( 216.69.186.* -- 26 dns > servers) was also one which requested both SPF and TXT records the same > number of times. This network happens to belong to godaddy (their > secureserver.net email service). > > This is a small sample, but I think it indicates that the deployment of > implementations that request SPF records is significant. I think it's interesting that even if you send a Type SPF answer some implementation(s) is/are requesting the Type TXT record anyway (that's how I read you note). I wonder if they are asynchronously requesting both and then applying whatever answer they get? For the ones that request both, can you tell if the sequence is consistent (e.g. SPF then TXT)? Scott K From dhc2@dcrocker.net Thu Feb 23 11:08:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EC421F8709 for ; Thu, 23 Feb 2012 11:08:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOhsm5WWeEAg for ; Thu, 23 Feb 2012 11:08:06 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6054C21F87AD for ; Thu, 23 Feb 2012 11:08:06 -0800 (PST) Received: from [10.101.2.93] (64.1.211.245.ptr.us.xo.net [64.1.211.245]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1NJ807Y013765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Feb 2012 11:08:06 -0800 Message-ID: <4F468E8A.80303@dcrocker.net> Date: Thu, 23 Feb 2012 11:07:54 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <1393684.knylKaz50c@scott-latitude-e6320> <6.2.5.6.2.20120222124752.09f0d510@resistor.net> <9452079D1A51524AA5749AD23E00392804121D@exch-mbx901.corp.cloudmark.com> <4F4688A1.5070206@cisco.com> In-Reply-To: <4F4688A1.5070206@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 23 Feb 2012 11:08:06 -0800 (PST) Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 19:08:07 -0000 On 2/23/2012 10:42 AM, Philip Gladstone wrote: > This is a small sample, but I think it indicates that the deployment of > implementations that request SPF records is significant. While it's important to have empirical of data of this, I think there is not debate about this specific fact. I believe the question is about the penetration of published SPF records, and their relevance to the overall system. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Thu Feb 23 11:08:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D0D21F87AD for ; Thu, 23 Feb 2012 11:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiQCGdxEirVG for ; Thu, 23 Feb 2012 11:08:25 -0800 (PST) Received: from catinthebox.net (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2197521F8709 for ; Thu, 23 Feb 2012 11:08:24 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1864; t=1330024101; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=9F+cD5nz3DE9tc8I7q1YsgUjKk4=; b=imBm9q0uYj0JAcuudjGY AjKGbGGs2e5KPp+OZzMuK643SZi3w46YrBzpAtqVpARRx0lkcuO5ixzzAu1n4k+M YCbj06on96MKRvZBFAZTbx5wQTiRyQKXER6g9Au9Uve4xZoYcTDveo59MOjzzWU2 +RU3XRyLTON/h7VpE8GGmT0= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 23 Feb 2012 14:08:21 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3225944709.89717.5332; Thu, 23 Feb 2012 14:08:20 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1864; t=1330023857; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0oUbhlj zYNCUiJ2ZRSp19KRUCgiX+3qsLfFCXNk7sYM=; b=1Tic4HUq+1mIDrOxpsczY7Y Od2nzem4lSplEQIoECi3w/KpHABQJr1VPXFleA/KOIdqjuBaHZBConAGh5UMOxQQ AdWRWWOT3GAX1lD76kINdjE3a9apOdCnngNFH7+wyCOP2EazpECpN7Yy99gpEZyc YIOOf1KwZQUURQL+xHaI= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 23 Feb 2012 14:04:17 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3824879173.19041.1756; Thu, 23 Feb 2012 14:04:15 -0500 Message-ID: <4F468EB0.8070700@isdg.net> Date: Thu, 23 Feb 2012 14:08:32 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Philip Gladstone References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <1393684.knylKaz50c@scott-latitude-e6320> <6.2.5.6.2.20120222124752.09f0d510@resistor.net> <9452079D1A51524AA5749AD23E00392804121D@exch-mbx901.corp.cloudmark.com> <4F4688A1.5070206@cisco.com> In-Reply-To: <4F4688A1.5070206@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 19:08:26 -0000 Thanks Philip. Hopefully the chairs and SK can put this issue to bed. If we drop support, this will cause a a surprise and new waste on SPF clients supporting the SPF RR. Dropping would of gone against what was the original intention with initial expected but short term faults, but as long as we had a TXT fall back, it will still functionally work. This should help SPF within DNS. This was always an implementation decision anyway. I have great interest now to start a project to enabled it and begin a gamma field testing cycle. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Philip Gladstone wrote: > > > On 2/22/2012 11:30 PM, Murray S. Kucherawy wrote: >> We can get answers to (a) and (b) just by querying some large list of >> domains. Philip from Cisco did one batch and I'm running another >> which can at least answer those two, and I'm running my own similar >> report. >> >> To do (c) and (d) we need to look at nameserver logs. John Levine is >> conducting that experiment. >> > I did a quick check over my logs. Over the last 24 hours or so, 372 name > servers have requested SPF or TXT records. 278 requested TXT records. > 238 requested SPF records. I.e. 144 requested both. I serve up the same > data in both the SPF record and the TXT record. These name servers were > in 122 different IPv4 /24 networks. [It seems that my nameserver doesn't > have ipv6 connectivity] > > The /24 with the most DNS servers in it ( 216.69.186.* -- 26 dns > servers) was also one which requested both SPF and TXT records the same > number of times. This network happens to belong to godaddy (their > secureserver.net email service). > > This is a small sample, but I think it indicates that the deployment of > implementations that request SPF records is significant. > > Philip > From johnl@iecc.com Thu Feb 23 11:44:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC96B21F8887 for ; Thu, 23 Feb 2012 11:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.994 X-Spam-Level: X-Spam-Status: No, score=-109.994 tagged_above=-999 required=5 tests=[AWL=1.205, 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 DB-ZdGB8lyMr for ; Thu, 23 Feb 2012 11:44:02 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 622F921F8867 for ; Thu, 23 Feb 2012 11:44:01 -0800 (PST) Received: (qmail 76429 invoked from network); 23 Feb 2012 19:43:58 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Feb 2012 19:43:58 -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=4f4696fd.xn--i8sz2z.k1202; i=johnl@user.iecc.com; bh=dvwc1mpvjcIzk0da0jvtDQd+Lv617q88Sv2HQidT/3U=; b=L1TP/vOVnmzcPgaluFMs+02bt5qwr4cw5N90JlJ/jHwV6cU6hud2h9mirNFz7t9LoCjMoRRe7sgny9gnG1+obvdcEkSnQcH14rkl6G3R3XWicyUZZHAMD92bXd2vNWKKdg0onZF+obQC16i4XP0YP10qw2P3n7g2/eD5/04FkUA= 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=4f4696fd.xn--i8sz2z.k1202; olt=johnl@user.iecc.com; bh=dvwc1mpvjcIzk0da0jvtDQd+Lv617q88Sv2HQidT/3U=; b=fauKb32dEtB8zZyTnbcHMtP5gt/M3rwW9tqI7ID615OiagSJpcG8rnnkblV2Z2t6FDsr1FhypCK7SWPCVP+OBTYk+CNH1a9oHNAMaPnQfBdy8TUxdi4zpzQ7xUouHF5evypAhU4NfWeE0jHGsKhJaeHCCguW6hU/aJAN0HAf+ac= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 23 Feb 2012 19:43:35 -0000 Message-ID: <20120223194335.24197.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <39120876.7e8QO4qu0j@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 19:44:02 -0000 >I wonder if they are asynchronously requesting both and then applying whatever >answer they get? Eyeballing my log extracts, I see a lot of queries for both records at the same time. Places like Yahoo frequently ask for both via different DNS caches, so it's hard to tell mechanically that they're the same query. But just off the top of my head, I'd say it's between 1/4 and 1/3 of the queries. From pgladstone@cisco.com Thu Feb 23 12:06:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F5421F8849 for ; Thu, 23 Feb 2012 12:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.087 X-Spam-Level: X-Spam-Status: No, score=-7.087 tagged_above=-999 required=5 tests=[AWL=3.513, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK0hZidTXPtY for ; Thu, 23 Feb 2012 12:06:06 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id E8E0121F87AB for ; Thu, 23 Feb 2012 12:06:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=2609; q=dns/txt; s=iport; t=1330027566; x=1331237166; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=vIkuFOaYHb4XQ2DSEV2qFJVNVNC+CrbL3+V8Ojq12AQ=; b=Zi2VzG++5bY6/Yb4ZF1aQisD7WiWvVkw08F7mwp6bDeVpImHcZ4ADbTU +xpofvOX4YSMLTrhe/CVXy53hZfHfCUxgqhKt8sWx8vRWoQUMFZcTqX/S iezXOm6wIimfdg0YHxmvfWdFP5biHV+qPZEnyHnKMWx6La24MIQPF4Ddn c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAB6bRk+rRDoI/2dsb2JhbABEhTSqPoJhgQeBcwEBAQQSARAEEUARCxgCAgUWCwICCQMCAQIBRRMIAQEep3IBjGWKIYEvi0c0BwECCwQFCgMDBwMCBQIQAQoCCAKFHIECggiBFgSIT4xphV2NLg X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="31930154" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 23 Feb 2012 20:06:05 +0000 Received: from [161.44.112.16] ([161.44.112.16]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1NK65R5006626 for ; Thu, 23 Feb 2012 20:06:05 GMT Message-ID: <4F469C2D.3070500@cisco.com> Date: Thu, 23 Feb 2012 15:06:05 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120222193641.73783.qmail@joyce.lan> <9452079D1A51524AA5749AD23E00392804121D@exch-mbx901.corp.cloudmark.com> <4F4688A1.5070206@cisco.com> <39120876.7e8QO4qu0j@scott-latitude-e6320> In-Reply-To: <39120876.7e8QO4qu0j@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 20:06:07 -0000 On 2/23/2012 2:02 PM, Scott Kitterman wrote: > > I think it's interesting that even if you send a Type SPF answer some > implementation(s) is/are requesting the Type TXT record anyway (that's how I > read you note). > > I wonder if they are asynchronously requesting both and then applying whatever > answer they get? It might be worth running the experiment and returning subtly different records and seeing which they execute. Putting exists:inspfrecord.%{d} in one and exists:intxtrecord.%{d} in the other would allow one to determine what they were doing. > > For the ones that request both, can you tell if the sequence is consistent > (e.g. SPF then TXT)? There are certainly some implementations which do asynchronous requests and request both at the same time, and the order that the requests arrive is not consistent. For example: 216.69.186.13: TXT -> SPF: 0.000032 secs 216.69.186.14: SPF -> TXT: 0.000010 secs 216.69.186.15: SPF -> TXT: 0.000007 secs 216.69.186.16: SPF -> TXT: 0.000007 secs 216.69.186.16: SPF -> TXT: 0.000031 secs 216.69.186.17: SPF -> TXT: 0.000018 secs 216.69.186.18: TXT -> SPF: 0.038848 secs 216.69.186.19: SPF -> TXT: 0.000007 secs This shows a particular set of name servers. The first line means that 216.69.186.13 requested a TXT record and then an SPF record and that these requests arrived 32usecs apart (much less than the RTT). WIth this nameserver set it is less clear what is going on: 74.6.109.17: SPF -> TXT: 2.239237 secs 74.6.109.17: TXT -> SPF: 3.206624 secs 74.6.109.18: SPF -> TXT: 0.106386 secs 74.6.109.18: TXT -> SPF: 2.930859 secs 74.6.109.20: SPF -> TXT: 0.014469 secs 74.6.109.20: SPF -> TXT: 0.038548 secs 74.6.109.20: SPF -> TXT: 0.043084 secs 74.6.109.20: SPF -> TXT: 3.557841 secs 74.6.109.20: TXT -> SPF: 0.021898 secs 74.6.109.20: TXT -> SPF: 0.042948 secs 74.6.109.20: TXT -> SPF: 0.125548 secs 74.6.109.25: SPF -> TXT: 0.000187 secs 74.6.109.25: SPF -> TXT: 0.104728 secs 74.6.109.25: SPF -> TXT: 0.114294 secs 74.6.109.25: SPF -> TXT: 0.318294 secs 74.6.109.25: TXT -> SPF: 0.000081 secs 74.6.109.26: SPF -> TXT: 0.109614 secs 74.6.109.27: SPF -> TXT: 0.107179 secs 74.6.109.27: TXT -> SPF: 2.477460 secs The RTT to this nameserver is around 100ms. I *suspect* that the large time intervals are actually from separate messages (I have a cutoff of 5 seconds for this log). Philip p.s. I'm actually quite impressed how quickly this can serve a request. This particular server is written in perl and uses mysql as the backend. I guess that the caching works! From R.E.Sonneveld@sonnection.nl Thu Feb 23 12:40:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AC021F87E3 for ; Thu, 23 Feb 2012 12:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNzA1+PthjwW for ; Thu, 23 Feb 2012 12:40:50 -0800 (PST) Received: from mx11.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id B2AF521F87A2 for ; Thu, 23 Feb 2012 12:40:49 -0800 (PST) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LZV00F004V1GT00@hydrogen.mailtransaction.com>; Thu, 23 Feb 2012 21:40:48 +0100 (CET) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LZV00D505FZCK00@hydrogen.mailtransaction.com>; Thu, 23 Feb 2012 21:40:47 +0100 (CET) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [192.168.10.9] (161-74-223.ftth.xms.internl.net [85.223.74.161]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LZV00O0G5FWP600@lion.sonnection.nl> for spfbis@ietf.org; Thu, 23 Feb 2012 21:40:47 +0100 (CET) Message-id: <4F46A44B.1030405@sonnection.nl> Date: Thu, 23 Feb 2012 21:40:43 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 To: "Murray S. Kucherawy" References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <1393684.knylKaz50c@scott-latitude-e6320> <6.2.5.6.2.20120222124752.09f0d510@resistor.net> <9452079D1A51524AA5749AD23E00392804121D@exch-mbx901.corp.cloudmark.com> In-reply-to: <9452079D1A51524AA5749AD23E00392804121D@exch-mbx901.corp.cloudmark.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1330029647; bh=8R7TBiZ8jhwElfVHDINU2LBYmIk6l9qVtW4ZA+y5Fpc=; h=MIME-version:Content-transfer-encoding:Content-type:Message-id: Date:From:To:Cc:Subject:References:In-reply-to; b=mHhPyQ7/3AIYD7oDj8hOlqWVQI5EKY6rI0v7hW+GV+9+7uS5L7bfvrnk+5bZ4dIdS uycEAUlkWODEGxmZ/X7Itp5ODQ10aS+bWY5CpZ/wCzU9hogMvauvAwKo6UkehQhVqX Zh98yFKyFP9XjfodvyWfxkRgpzIvcpGwhPPDwda4= X-DKIM: OpenDKIM Filter v2.1.3 hydrogen.mailtransaction.com 0LZV00F004V1GT00 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 20:40:51 -0000 Op 23-02-12 05:30, Murray S. Kucherawy schreef: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of S Moonesamy >> Sent: Wednesday, February 22, 2012 1:46 PM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] #9: RFC 4408 SPF RR type >> >> Hello, >> >> I have been following the discussion about SPF RR Type. It seems that >> the issue is being read as a binary question, i.e. should the SPR RR >> record be kept or not. Some of the questions that come to my mind are: >> >> (a) How many domains are publishing SPF RR records? >> >> (b) How many domains are publishing SPT TXT records? >> >> (c) How many domains are querying for SPR RR records? >> >> (d) How many domains are querying for SPR TXT records? >> >> (e) What are the implementations out there? >> >> (f) What DNS records do the implementations query for? >> >> The above is not an exhaustive list of questions. If I missed any >> questions, let me know. Without empirical data, it is not possible to >> answer these questions. Is there anyone who would like to volunteer to >> find the answers to these questions? > We can get answers to (a) and (b) just by querying some large list of domains. Philip from Cisco did one batch and I'm running another which can at least answer those two, and I'm running my own similar report. as sets (a) and (b) may overlap, and as RFC4408 uses a SHOULD for publishing both types, the interesting question here is: how many domains are publishing SPF but no TXT. /rolf From hsantos@isdg.net Thu Feb 23 12:59:38 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B30E21F86C4 for ; Thu, 23 Feb 2012 12:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.438, 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 Fnkq8NoA-abS for ; Thu, 23 Feb 2012 12:59:37 -0800 (PST) Received: from ntbbs.santronics.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id EBB9F21F86CE for ; Thu, 23 Feb 2012 12:59:35 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2533; t=1330030771; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Xmfwa6eBjISHeJxfFdnd+JWXUqY=; b=B4UefQ67EyiwrLi8EKq+ uh2r18WP3d9nzdi6BdYfOz+usRk+g2biiI1SjMoVOJK/jlQYUPKmoifX3at/8GY+ 6ffUjLCokRtQ2qc8F1nVug4MovUEjGlMA8CL+wiV2Lb7B1pYmBj67I8/LwwrB+Oo xMRYzr5LD6sVWqDz8RZcZbg= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 23 Feb 2012 15:59:31 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3232614812.89717.5232; Thu, 23 Feb 2012 15:59:30 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2533; t=1330030526; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=WfMjKae Q7QJYPLRgmDOtJrdeSTcPmWsWOI8jGIzCSv8=; b=VBtsFLnf+bZh2xJohaHL4Nc jUJS3F/fj1raH9KRGL100FfuyU2tPTEs+6OIUESyz+mSc3KB6WkHr4WPkjE2x+RP Zv1snevrIu0zvMUwQYAhJdapTksI+Lag39+vIqd4XS7+UfNy/ThisnzVbOxx+904 WEVbrtdVqqb1JoCNJKwA= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 23 Feb 2012 15:55:26 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3831549220.19055.5300; Thu, 23 Feb 2012 15:55:25 -0500 Message-ID: <4F46A8BF.2060507@isdg.net> Date: Thu, 23 Feb 2012 15:59:43 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] new issue: Section 4.4 Parallel Query X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 20:59:38 -0000 In question: 4.4. Record Lookup In accordance with how the records are published (see Section 3.1 above), a DNS query needs to be made for the name, querying for either RR type TXT, SPF, or both. If both SPF and TXT RRs are looked up, the queries MAY be done in parallel. I have seen this before and was very curious about how literal is that in term of the technical methods used to perform "parallel" queries. But with the group postings today related to type SPF and TXT queries and terms like "asynchronous" or "Same time" made me think this might an item to be clarified. The statement "the queries MAY be done in parallel" should be expanded to - Explain what "Parallel"" means, - The reasons whe on MAY wish to do this, and - What are the possible issues and considerations with it. The term "Parallel" has a specific meaning (in terms of computers and software) which correlates to time independent concurrency of different thread, process, task, etc. To the SPF implementator, this may mean using two different threads, fibers, task each doing a DNS query - SPF and TXT, or in DNS parley, it can a batch of multiple query packets. This should be perhaps be explained. The reasons is to lower overhead, I suppose, which may implies the "Multiple Query Packets" method, to help avoid the need to do two separate queries. The possible issues as I basically understand it: - Multiple Query Packets (MQP) is not a universally support feature and in some reported - broken and unreliable, and Now, the main issue starts with the idea that the end result of a parallel or MQP query MUST be the same for the result of two sequential queries. In theory, the sequential order would be SPF type first, then TXT type as a fall back. The current text offer a functional spec requirement. What is needed is a technical specification description. That should be done as if there as no parallelism or MQP capability, only sequential. The parallel or MQP is essentially an DNS overhead optimization of the sequential method. No question, the ideal query of two related types would be to batch it as one call. But the reality is it is not an universal DNS server supported feature and since it must be described using the lowest common denominator method, this section should expand how the SPF and TXT queries should are done sequentially with translations of results. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Thu Feb 23 13:11:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CC621E800E for ; Thu, 23 Feb 2012 13:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 HzMRtUHAfiJi for ; Thu, 23 Feb 2012 13:11:11 -0800 (PST) Received: from ntbbs.santronics.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8D45B11E807F for ; Thu, 23 Feb 2012 13:11:06 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=816; t=1330031457; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=roplqg62xx+eYV4xFJYyPffN4SA=; b=hHSddbjOOK1JMmDxnRJD bCLwl28uPfOXgcNejADNol0+7lQ0DXJlE41AMQG1OxZvZE3rrBHphy/AG2QQBRIL 4tv4+uYpeVLVlll6n9BBuLDUln2/dW6ia0akFQG1OoF0CWq9H7JPDs095mibw24o 46ZGhPWFGG3lNw6MuSFL4Iw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 23 Feb 2012 16:10:57 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3233300109.89717.6096; Thu, 23 Feb 2012 16:10:55 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=816; t=1330031213; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=REDBW5r 3OMO296B5KCGPzj+o6HQnXXsSOc4pOHcZHpM=; b=GcPLHkP8ScQSn5ZUj70uUJx eMO480IC7I+rvkZlECdQ2qSQrL+OdP0VXrlawpA/GNVE9i2vTZaXQnFmjRvNCWF3 wouVNrPNYKWU+GSfCT8Gc0ixrc+KYQ8aD52XStTML0Q4OTPypuaieurf/hFoSups KexHyiTncURpztQO8Mtc= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 23 Feb 2012 16:06:53 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3832236267.19058.4292; Thu, 23 Feb 2012 16:06:52 -0500 Message-ID: <4F46AB6E.6000600@isdg.net> Date: Thu, 23 Feb 2012 16:11:10 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Rolf E. Sonneveld" References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <1393684.knylKaz50c@scott-latitude-e6320> <6.2.5.6.2.20120222124752.09f0d510@resistor.net> <9452079D1A51524AA5749AD23E00392804121D@exch-mbx901.corp.cloudmark.com> <4F46A44B.1030405@sonnection.nl> In-Reply-To: <4F46A44B.1030405@sonnection.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , "Murray S. Kucherawy" Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 21:11:17 -0000 Rolf E. Sonneveld wrote: > > as sets (a) and (b) may overlap, and as RFC4408 uses a SHOULD for > publishing both types, the interesting question here is: how many > domains are publishing SPF but no TXT. Good question and I'll be surprise if anyone doing this since it may show a lack of understanding there was an high unreliability factor just using a new named type. You know, I suspect withing the reported DNS analysis, it includes a factor of what DNS query path was taken or perhaps dominate with a PCN (Personal Community Network) or BCN (Business Community Network). I am a firm believer that every one of us has a unique PCB or BCN, with many perhaps a common subset, but nonetheless each is unique. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From msk@cloudmark.com Thu Feb 23 13:13:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264BB21F888B for ; Thu, 23 Feb 2012 13:13:35 -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=[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 q7X5kdAWanvQ for ; Thu, 23 Feb 2012 13:13:34 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 783BA21F8878 for ; Thu, 23 Feb 2012 13:13:34 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Thu, 23 Feb 2012 13:13:33 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #9: RFC 4408 SPF RR type Thread-Index: Aczv8UQLV2N/uDLSRyC+8YNgJDPwqgB0W1qAAADgQwAAAvuJAAAAWKmAAA8t1pD//5hAgIAAAUyAgAAHkwCAAAOfgIAAF4aAgAAWgECAAWm1gIAAfRXA Date: Thu, 23 Feb 2012 21:13:33 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392804356F@exch-mbx901.corp.cloudmark.com> References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <1393684.knylKaz50c@scott-latitude-e6320> <6.2.5.6.2.20120222124752.09f0d510@resistor.net> <9452079D1A51524AA5749AD23E00392804121D@exch-mbx901.corp.cloudmark.com> <4F46A44B.1030405@sonnection.nl> In-Reply-To: <4F46A44B.1030405@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.1.211.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 21:13:35 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Rolf E. Sonneveld > Sent: Thursday, February 23, 2012 12:41 PM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] #9: RFC 4408 SPF RR type >=20 > as sets (a) and (b) may overlap, and as RFC4408 uses a SHOULD for > publishing both types, the interesting question here is: how many > domains are publishing SPF but no TXT. Phillip's data and mine attempt to answer that question. (His data are ava= ilable, my report is still churning.) From johnl@iecc.com Thu Feb 23 13:40:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C09221F879A for ; Thu, 23 Feb 2012 13:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.008 X-Spam-Level: X-Spam-Status: No, score=-110.008 tagged_above=-999 required=5 tests=[AWL=1.191, 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 vUuXOUmv0fIG for ; Thu, 23 Feb 2012 13:40:49 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 72C3F21F8740 for ; Thu, 23 Feb 2012 13:40:36 -0800 (PST) Received: (qmail 26248 invoked from network); 23 Feb 2012 21:40:35 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Feb 2012 21:40: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=4f46b250.xn--hew.k1202; i=johnl@user.iecc.com; bh=18+N88ZPxrsRV85inhr/FXlkduBYSDKvefkRxc7LwBs=; b=FHXWK7oJEKBcyqo899NdHK1ppbn0V4CxwT1STSAKpgWTobMAldJfvYJQ0jwHmtZkBpkX6ujk1zxVby8TFtslRktNh/mPmWUqLBDz8qLYB61VzOLGQGrrTmQWbnl2Ppi/InvIxiDIOG3z2Ke6/uFhGJiBuHilJiWSC63ZnAyXAzo= 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=4f46b250.xn--hew.k1202; olt=johnl@user.iecc.com; bh=18+N88ZPxrsRV85inhr/FXlkduBYSDKvefkRxc7LwBs=; b=W88QaQMSgJakCdQk1T1pW1DRkiaoI0hXEjEEWSgwlXYjlBN1NXNh8nB4C2nOnT6sjBLnujMwD1vzxftva8+NVxLaWilGdd9Dp9RVYLNLNZDq2pyiyMnSbVYgM0ZSV6KpNUnBEqRbQITe9IZuu56y7INg3K1Mgq14oxBHC4c0UeQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 23 Feb 2012 21:40:10 -0000 Message-ID: <20120223214010.52026.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4F469C2D.3070500@cisco.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: pgladstone@cisco.com Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Feb 2012 21:40:50 -0000 >WIth this nameserver set it is less clear what is going on: > >74.6.109.17: SPF -> TXT: 2.239237 secs >74.6.109.17: TXT -> SPF: 3.206624 secs >74.6.109.18: SPF -> TXT: 0.106386 secs >74.6.109.18: TXT -> SPF: 2.930859 secs >74.6.109.20: SPF -> TXT: 0.014469 secs >74.6.109.20: SPF -> TXT: 0.038548 secs >74.6.109.20: SPF -> TXT: 0.043084 secs >74.6.109.20: SPF -> TXT: 3.557841 secs >74.6.109.20: TXT -> SPF: 0.021898 secs >74.6.109.20: TXT -> SPF: 0.042948 secs >74.6.109.20: TXT -> SPF: 0.125548 secs >74.6.109.25: SPF -> TXT: 0.000187 secs >74.6.109.25: SPF -> TXT: 0.104728 secs >74.6.109.25: SPF -> TXT: 0.114294 secs >74.6.109.25: SPF -> TXT: 0.318294 secs >74.6.109.25: TXT -> SPF: 0.000081 secs >74.6.109.26: SPF -> TXT: 0.109614 secs >74.6.109.27: SPF -> TXT: 0.107179 secs >74.6.109.27: TXT -> SPF: 2.477460 secs Those are all Yahoo. I have other logs that strongly suggest they're intending to do simultaneous queries. R's, John From sm@elandsys.com Thu Feb 23 13:57:24 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D95121E801A for ; Thu, 23 Feb 2012 13:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.584 X-Spam-Level: X-Spam-Status: No, score=-101.584 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, 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 aMFGaniSnG3s for ; Thu, 23 Feb 2012 13:57:22 -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 36C6F21E8018 for ; Thu, 23 Feb 2012 13:57:22 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.236.103]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1NLv2VU012910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Feb 2012 13:57:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330034239; i=@elandsys.com; bh=CS/EDMMe+EnHgeyF+Y8QjvnxJFZAbK7PXq/jUbYClXM=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=aZ2SARQ2OBivsltEGkYF7ah/bRjm8Mevyj9mQd/M8lefUwS5d2A58fo82frRRSpUN TfSs3G9ocj49+C5uCMLnaZderE+idPjfV2hnylVjBMjxbyHvngg2S4XR/isYgZhXvv tWFn/wkR9FYMNrrLw55MzF0kzycvEUss0bpWiNcM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330034239; i=@elandsys.com; bh=CS/EDMMe+EnHgeyF+Y8QjvnxJFZAbK7PXq/jUbYClXM=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=avZK3HbRjO0Z7E8tnnwGZxYAzEwgNZP0CXrFyXciMuMIWdcShVtHAEHJJcmu+oPTM ODgR8z/3hSQfAd5DJlQ6eb2SeJlj81e/uSBLtg+iJLIcwlMDYLL98WZ+VazLWK4WPw 1qa00Xjsal2Qm3rieP+65XTee3cynCwcJBTw2/cY= Message-Id: <6.2.5.6.2.20120223135213.09295ff0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 Feb 2012 13:54:57 -0800 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] spfbis - Requested session has been scheduled for IETF 83 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 21:57:24 -0000 The following session has been scheduled for IETF 83: spfbis Session 1 (2 hours) Friday, Morning Session I 0900-1100 Room Name: 252A Regards, S. Moonesamy From sm@elandsys.com Thu Feb 23 17:17:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C05C21F871C for ; Thu, 23 Feb 2012 17:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWkp-T3PCLTy for ; Thu, 23 Feb 2012 17:17:36 -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 AE5CF21F8716 for ; Thu, 23 Feb 2012 17:17:36 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.237.129]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1O1HMBB007318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2012 17:17:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330046255; i=@elandsys.com; bh=JydoSwKlV83iLq0qBfjN6eyUez/rep0SGzeKzuSr8ZI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=SI/MPT4bLgFGdWAvn4t1nxA+Ej9o6Nxow94qXmcf51E1p6uUCGTqToS1exyYj5HNC f16a7xQdOVpbTpVKa4ZYhZ6544ze0DZ++DJjWZRTsRHnsdrgSuuAzz+m/r0zVQiQjA OUMZfb6MzrXyTrczlUgVJMh/iSkgNFaiVcaoJe1Q= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330046255; i=@elandsys.com; bh=JydoSwKlV83iLq0qBfjN6eyUez/rep0SGzeKzuSr8ZI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=PM3BoAQ5JiMBNrycHOCxMM9/uMDzuDZn5asjpwp/+p9wQBfC7RU08KAEzUzWgk+Ae 1CCaLASBER8sr1xRTKClbiQ3/BIt8iRJSZ1YwvuVMfQ0+OsOulJoIylUSvphd9sd7U 1Fase2qaUPi/JbfgRlLWpROtBRRvnR7DChVOLO5s= Message-Id: <6.2.5.6.2.20120223171037.0ab73808@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 Feb 2012 17:16:33 -0800 To: Hector Santos From: S Moonesamy In-Reply-To: <4F46A8BF.2060507@isdg.net> References: <4F46A8BF.2060507@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] new issue: Section 4.4 Parallel Query X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 01:17:37 -0000 Hi Hector, At 12:59 23-02-2012, Hector Santos wrote: >I have seen this before and was very curious about how literal is >that in term of the technical methods used to perform "parallel" >queries. But with the group postings today related to type SPF and >TXT queries and terms like "asynchronous" or "Same time" made me >think this might an item to be clarified. The issue which you posted is being tracked as Issue #25. Were these group postings about Issue #1? Regards, S. Moonesamy SPFBIS WG co-chair From hsantos@isdg.net Thu Feb 23 18:25:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EBB11E80A2 for ; Thu, 23 Feb 2012 18:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.428, 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 aMelwCqSN4Mb for ; Thu, 23 Feb 2012 18:25:42 -0800 (PST) Received: from secure.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9FC11E80A0 for ; Thu, 23 Feb 2012 18:25:40 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=978; t=1330050332; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=CuQihpi9VEkR2j/1w/gLAoWGoMk=; b=XP5ohuvwB4snxx7uTkrP bXV91BklFg5U/ni2MLrfIv9z6BlszeCPtdcxLt0ypC5jjHaokxStojgi2Z0iqJmg JiyEJ+dwpxMv7KqT+HGdjLSk4tqUbyJFdcyA2dXYYq+/GAGAGxNfP21aEo9jTrlN DiPk04Uotgx0ZY/UNFwAscg= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 23 Feb 2012 21:25:32 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3252175497.89717.2616; Thu, 23 Feb 2012 21:25:31 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=978; t=1330050089; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=yKnWi1N 3lJcdp7bYcxACrQZyQM4M30OWa0yblQNqSRQ=; b=BN3732tECWeegncCIDdDOS3 0EL7uIJF32pyZEoYNHVd453lXsISe0Tfqs58OPqWYCsMl5ykDMcQBJmE0il/Mj8s aqbsVLLpWhN6z5uNzZCWEW1/lsTtrytY07/QL8BLhOVxRtPjwwl4ismgsyyqQ4KA 8znrLAcDZyFJMVYGCgT4= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 23 Feb 2012 21:21:29 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3851111658.19087.3648; Thu, 23 Feb 2012 21:21:28 -0500 Message-ID: <4F46F530.9020803@isdg.net> Date: Thu, 23 Feb 2012 21:25:52 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <4F46A8BF.2060507@isdg.net> <6.2.5.6.2.20120223171037.0ab73808@resistor.net> In-Reply-To: <6.2.5.6.2.20120223171037.0ab73808@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] new issue: Section 4.4 Parallel Query X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 02:25:43 -0000 S Moonesamy wrote: > Hi Hector, > At 12:59 23-02-2012, Hector Santos wrote: >> I have seen this before and was very curious about how literal is that >> in term of the technical methods used to perform "parallel" queries. >> But with the group postings today related to type SPF and TXT queries >> and terms like "asynchronous" or "Same time" made me think this might >> [be] an item to be clarified. > > The issue which you posted is being tracked as Issue #25. Were these > group postings about Issue #1? Thanks. They were among the issue #9 thread, subject: [spfbis] #9: RFC 4408 SPF RR type. Starting with Philip's data posting: http://www.ietf.org/mail-archive/web/spfbis/current/msg00573.html Scott's and Levine's follow up: http://www.ietf.org/mail-archive/web/spfbis/current/msg00574.html http://www.ietf.org/mail-archive/web/spfbis/current/msg00577.html -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From SRS0=VUeob=BC==stuart@gathman.org Fri Feb 24 06:24:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790E621F86BD for ; Fri, 24 Feb 2012 06:24:12 -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 ee0CB9jnFj54 for ; Fri, 24 Feb 2012 06:24:12 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id D389321F86BB for ; Fri, 24 Feb 2012 06:24:11 -0800 (PST) Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q1OENItl014726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Feb 2012 09:23:19 -0500 Message-ID: <4F479D71.9020203@gathman.org> Date: Fri, 24 Feb 2012 09:23:45 -0500 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F46A8BF.2060507@isdg.net> In-Reply-To: <4F46A8BF.2060507@isdg.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] new issue: Section 4.4 Parallel Query X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 14:29:32 -0000 Long ago, Nostradamus foresaw that on 02/23/2012 03:59 PM, Hector Santos would write: > > Now, the main issue starts with the idea that the end result of a > parallel or MQP query MUST be the same for the result of two > sequential queries. > > In theory, the sequential order would be SPF type first, then TXT type > as a fall back. The current text offer a functional spec requirement. > What is needed is a technical specification description. That should > be done as if there as no parallelism or MQP capability, only > sequential. The parallel or MQP is essentially an DNS overhead > optimization of the sequential method. I disagree. An implementation MAY query TXT only, or SPF only. So a parallel implementation could query both in parallel, then use whichever comes back first. The implementation can be thought of as a quantum superposition of TXT only and SPF only, which resolves to a specific choice when the first response packet arrives. This is important, because a common problem is DNS servers that ignore SPF queries (no reply at all) rather than returning "no such record". Checking for SPF first sequentially is impractical because of this DNS server bug. But querying in parallel and using the first response works in all cases. From SRS0=VUeob=BC==stuart@gathman.org Fri Feb 24 06:37:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5FF21F87B5 for ; Fri, 24 Feb 2012 06:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 c4SQyKcsZsjt for ; Fri, 24 Feb 2012 06:37:11 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9FF21F8655 for ; Fri, 24 Feb 2012 06:37:01 -0800 (PST) Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q1OEZwGQ015026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Feb 2012 09:36:00 -0500 Message-ID: <4F47A069.30500@gathman.org> Date: Fri, 24 Feb 2012 09:36:25 -0500 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120220212346.17006.qmail@joyce.lan> <4F4296BB.8060207@Commerco.Net> <20120220193102.GD33775@crankycanuck.ca> <4F42B85C.6020508@dcrocker.net> In-Reply-To: <4F42B85C.6020508@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 14:37:12 -0000 Long ago, Nostradamus foresaw that on 02/20/2012 04:17 PM, Dave CROCKER would write: > > However, SPF uses the record already and doesn't use the new RR. No > precedent is being set by acknowledging this reality. In spite of the > fact that an SPF RR is a cleaner approach, enough time has passed to > make clear that it's not being adopted and, therefore, won't be. > The SPF RR will likely never be widely adopted for SPFv1. However, the SPF RR should remain reserved for the next generation protocol (v=spf3 or whatever). In the meantime, we should encourage publishing both RR types for v=spf1, if for no other reason than so we can keep complaining to operators of braindead DNS servers (that timeout with no response on SPF queries) so they will eventually get fixed in time for v=spf3 - so the next generation is not force to roll back to TXT records again. From spf2@kitterman.com Fri Feb 24 07:33:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09CA21F867C for ; Fri, 24 Feb 2012 07:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhsjJVrnRZwH for ; Fri, 24 Feb 2012 07:33:17 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBAC21F85B7 for ; Fri, 24 Feb 2012 07:33:04 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3C70920E40CC; Fri, 24 Feb 2012 10:33:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330097583; bh=fdCC3NJeY8NgjE6EzV8QMgOwNjxjiFppitY2pNTNo6k=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=OQ6bTgQWN0I/mUTL2baPH80NP4NexC92aQfZ2cPBDxwmXG7PB7efd3lpamRlbUl06 EH4q19aBMnbJRlPlHX5ema0hClPHvLxEzUK7Um/1MLmAti1LqxdwwZ0Akp7Id93QOl 92Y5RTxwhEsx24KuPR+Zeqf92B0bjhQYYq6whvmU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1F02720E4083; Fri, 24 Feb 2012 10:33:02 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 24 Feb 2012 10:33:02 -0500 Message-ID: <1775995.RF6pGKfp5q@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280417A3@exch-mbx901.corp.cloudmark.com> References: <061.455654aa40583da61895c644f7120a55@tools.ietf.org> <6.2.5.6.2.20120222115949.08f70548@elandnews.com> <9452079D1A51524AA5749AD23E0039280417A3@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 15:33:19 -0000 On Thursday, February 23, 2012 08:02:46 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of S Moonesamy Sent: Wednesday, February 22, 2012 12:04 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors > > > > > I think that RCODE 2 replies should be considered PermError > > > instead of TempError. > > > > > > The operational impact of this is that messages are deferred (4xx) > > > instead of rejected (5xx) so they sit in a deferral queue and are > > > retried for however long the sending MTA is configured to attempt > > > it. > > > The user of the message isn't notified of the non-delivery until it > > > expires out of the queue, generally after several days. > > > > > > In the SPF policy server for Postfix that I maintain, I changed the > > > default action on TempError from defer as a result of this issue. > > I'm not sure I agree with this. The definition of SERVFAIL (which is RCODE > 2) from RFC1035 is: > > 2 Server failure - The name server was > unable to process this query due to a > problem with the name server. > > That's plenty general. Absent a list of specific reasons why a nameserver > might return that error, I'm left not knowing whether the error is > transient (resources, perhaps) or one that does indeed require operator > intervention. > > So perhaps Andrew is in a good position to answer this, hatless of course: > Has there ever been more specific guidance about the use of SERVFAIL, or > perhaps the introduction of other RCODEs, to make this less ambiguous? In order to try and get a handle on this question, I asked an associate who is very familiar with BIND internals about when it would return SERVFAIL. It turns out it is a mix of temporary (self-resolving) and permanent (needs operator resolution) conditions, so SERVFAIL doesn't neatly map into either SPF result. Examples of temporary SERVFAIL are: Unable to connect with the authoritative resolver due to a network outage. A difference in TTL between glue A records and NS records in a delegation. If the A records are /all/ required glue (ends with the zone name) and the TTL on them is shorter than the NS records, they will get flushed from cache before the NS records and thus give SERVFAIL until the NS records timeout. So in that scenario, resolution by others will experience SERVFAIL for periods of time regularly. Examples of more permenant SERVFAIL are: Firewall misconfiguration (permanently preventing access to an authoritative resolver). Name server misconfiguration (e.g. broken zone file) Failed to pay bill for DNS services Based on that feedback, I don't think it's appropriate to call SERVFAIL a permanent error on a general basis as I originally proposed. OTOH, the operational problem with permanent (long term) SERVFAIL is a real one. I don't know what the best solution is, but perhaps it can be addressed. My initial thought is to allow (but not require) receivers to track SERVFAIL based temperrors and if they persist for more than $PERIOD (let's start the bidding at 24 hours) then future consectutive SERVFAIL responses for that domain MAY be considered permanent errors. I would also say that receivers that are going to defer message acceptance based on SPF temperror SHOULD do this (the spec should not take a position on the decision to implement defer on SPF temperror or not, just on how to do it if that's the receiver policy). I propose it as a MAY because I think it's only really important for the defer on temperror case and I don't think we want to force additional complexity into the mandatory parts of the protocol without a strong reason. If this (or something like it) were included in 4408bis, I would implement it because it would allow me to restore defer on temperror as a system default (I disabled it by default in 2007 after user complaints about long duration temperrors due to SERVFAIL). Scott K From ajs@anvilwalrusden.com Fri Feb 24 08:33:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B30D21F87F7 for ; Fri, 24 Feb 2012 08:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 TtBsaqkqz6nK for ; Fri, 24 Feb 2012 08:33:16 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACD221F87F4 for ; Fri, 24 Feb 2012 08:33:16 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 96C051ECB41D for ; Fri, 24 Feb 2012 16:33:15 +0000 (UTC) Date: Fri, 24 Feb 2012 11:33:17 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120224163316.GG48576@mail.yitter.info> References: <061.455654aa40583da61895c644f7120a55@tools.ietf.org> <6.2.5.6.2.20120222115949.08f70548@elandnews.com> <9452079D1A51524AA5749AD23E0039280417A3@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9452079D1A51524AA5749AD23E0039280417A3@exch-mbx901.corp.cloudmark.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 16:33:17 -0000 No hat. On Thu, Feb 23, 2012 at 08:02:46AM +0000, Murray S. Kucherawy wrote: > > -----Original Message----- > > > I think that RCODE 2 replies should be considered PermError instead > > > of TempError. > I'm not sure I agree with this. The definition of SERVFAIL (which is RCODE 2) from RFC1035 is: > > 2 Server failure - The name server was > unable to process this query due to a > problem with the name server. I agree with Murray: RCODE=2 is not a permanent error in the DNS. > That's plenty general. Absent a list of specific reasons why a > nameserver might return that error, I'm left not knowing whether the > error is transient (resources, perhaps) or one that does indeed > require operator intervention. > > So perhaps Andrew is in a good position to answer this, hatless of > course: Has there ever been more specific guidance about the use of > SERVFAIL, or perhaps the introduction of other RCODEs, to make this > less ambiguous? The reason it's not specific is because there could be just about _any_ reason why you get RCODE=2. Scott mentioned downthread the case where you have an in-cache NS set and no glue records to get you there. But there are lots of other cases. For instance, some authoritative servers will respond SERVFAIL while loading a zone. Different implementations respond with SERVFAIL for different reasons. A validating resolver will respond with SERVFAIL if the DNS response is not validatable and CD=1 is not set on the query. And so on. Some of these could be transitory (many are) and some could be permanent (the server is broken, for instance). When dealing with DNS, I'm usually very reluctant to call an error permanent. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From hsantos@isdg.net Fri Feb 24 09:29:11 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9233021F87E9 for ; Fri, 24 Feb 2012 09:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpvf7TkpStcT for ; Fri, 24 Feb 2012 09:29:10 -0800 (PST) Received: from pop3.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5102E21F87CC for ; Fri, 24 Feb 2012 09:29:09 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=696; t=1330104543; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=u5XmHGjq2c29wqx0FB2ftjvbG7w=; b=qo9m9lycaPIwliVHIVZH ajVRNTTCtaKOLz9i+dkb/E7ijZpn2Dn82YxI6mEeHMwEMgbPj0JzrOaUq4IXrBlE lTPowgKAAVMOkpcZ7+JMJcEfOKcGirPqRy6dSznPDB9u0/3mi/9ocYU+EzBbt91n wfuhcnkjAqF17o9qeDlmWeA= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 24 Feb 2012 12:29:03 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3306386266.90415.2612; Fri, 24 Feb 2012 12:29:02 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=696; t=1330104299; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=G8GbQF0 yd256ASMSJ4RvdrP2X7AX2B1sliQCSCLqyJ0=; b=ejqioA6UfMkCl/dnOYcPNrc jx6y5qyvJpFwXgUWRV0/vb0Z06cV9mDLV1vpGTU6TlRtbswQb+Ys31KSGzGKh7fv L186Tb9YbrdJKlZcqCep3ftQwveEGnMnzsYWHwO29qGLgcSL25pq0lFGpSoP37S9 xcdLs/K3vtzOu+vb56LE= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 24 Feb 2012 12:24:59 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3905321329.19139.1232; Fri, 24 Feb 2012 12:24:57 -0500 Message-ID: <4F47C8F9.3080902@isdg.net> Date: Fri, 24 Feb 2012 12:29:29 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andrew Sullivan References: <061.455654aa40583da61895c644f7120a55@tools.ietf.org> <6.2.5.6.2.20120222115949.08f70548@elandnews.com> <9452079D1A51524AA5749AD23E0039280417A3@exch-mbx901.corp.cloudmark.com> <20120224163316.GG48576@mail.yitter.info> In-Reply-To: <20120224163316.GG48576@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 17:29:11 -0000 Andrew Sullivan wrote: > When dealing with DNS, I'm usually very reluctant to call an error > permanent. +1. Yet, for the same reasons why SMTP outbound mail queuing and retry methods vary to a wide agree, the translation of all result should be a local policy and IMV codified in the SPF-BIS spec as an item for flexible configuration for implementation to consider. A principle reason is the idea of controlling redundancy. i.e. a domain is exhibiting a history of perpetual temporary errors. At some point, a local policy may include a rule to translate this to to a permanent condition. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From pgladstone@cisco.com Fri Feb 24 10:19:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB87021F8838 for ; Fri, 24 Feb 2012 10:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.877 X-Spam-Level: X-Spam-Status: No, score=-6.877 tagged_above=-999 required=5 tests=[AWL=2.522, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKzdJFhd+jWB for ; Fri, 24 Feb 2012 10:19:08 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D1DE021F8914 for ; Fri, 24 Feb 2012 10:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=956; q=dns/txt; s=iport; t=1330107545; x=1331317145; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PifwNW+fAVBGWGFlFDlZ+2Jic+6C/YP/StEgbtYGVwo=; b=CvsXuOLDYCELa9ZzvMjMCeqJx9hV/vXT/4Jd5vg+Jb/7KV5y+xAMcU84 0e+Ol9L+nr5mfO1hr1Ezc6TX+Aa+mNi+IqovwAD6F1bQ9pLmZsuWFEYsH sYHsan0oOArVW1L2hEpCMx7K9Ar4E/l6A8M/kKwFVzu6NwAZwl2xawH9N 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPnTR0+tJXHB/2dsb2JhbABAA4U6rWCBB4FzAQEBBBIBEBVAAQ4CCxgCAgUWCwICCQMCAQIBCTwGDQEFAgEBHodkoD0BjGWKEwSBK4tcKgMBAgsEBQoDAwcDAgUCEAEKAgIDAwKFHGQPCoINgRYEiE+MbIVdjTA X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="61617486" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 24 Feb 2012 18:19:05 +0000 Received: from [161.44.106.143] (dhcp-161-44-106-143.cisco.com [161.44.106.143]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q1OIJ49M010768; Fri, 24 Feb 2012 18:19:05 GMT Message-ID: <4F47D498.9030208@cisco.com> Date: Fri, 24 Feb 2012 13:19:04 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John Levine References: <20120223214010.52026.qmail@joyce.lan> In-Reply-To: <20120223214010.52026.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 18:19:08 -0000 On 2/23/2012 4:40 PM, John Levine wrote: > Those are all Yahoo. I have other logs that strongly suggest they're > intending to do simultaneous queries. > > The data from a bunch of nameservers in 72.167.238.* which are doing (apparently) simultaneous lookups indicates that they then pick whichever record comes back first. I modified my TXT/SPF records by adding a 'exists:SPF.qtype.%{d}' to the SPF record and TXT.qtype to the TXT record. This allows me to tell (by the subsequent lookup) which they process. Indeed, whichever query I process first (TXT or SPF), this is the record that they actually process as shown by their processing of the exists: mechanism (these domains returns NXDOMAIN so as not to interfere with processing). Philip -- Philip Gladstone Distinguished Engineer Product Development pgladstone@cisco.com Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Google: +1 978 800 1010 Ham radio: N1DQ From hsantos@isdg.net Fri Feb 24 10:55:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0070721F87C3 for ; Fri, 24 Feb 2012 10:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+nLteU6Ur13 for ; Fri, 24 Feb 2012 10:55:19 -0800 (PST) Received: from mail.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D3BEC21F87B0 for ; Fri, 24 Feb 2012 10:55:18 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2507; t=1330109709; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Mn7XQXKaket4IeS5japI0RMnraM=; b=uDET2h3fimsrV/eF9URG Pv4t+3VJgFwjVH7B9ee2dXK1ZN847EekgdY7de+f82/aKXlRg7wu0CUZp7XPmCh4 ygLqljMSQ7jtxjZzeV2h87IFZlXcxWY4a+9to8JD8iS7mXGZiGf3QjTznl0LSxtM 9ybYFyZn3yQhtjkWDJ0oRP4= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 24 Feb 2012 13:55:09 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3311551396.90415.4596; Fri, 24 Feb 2012 13:55:08 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2507; t=1330109465; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=sHHT0dg tSFcDUXHAGY9KY5KSahershr4C01wqYrjDcU=; b=I3lCrXD4s0wRPqZ4zk/T7R7 E7idGnme0iF0z7M0bzQJSusl+S3l5rpFXrmAgtKQ9QQkBiZ1ygnv+NlAODtfdJCC r3WgDRhgw1QBp6LJnquSWQWQcG4XaIsb282yCih3hIeY8O2hoNhQfXxyc+e3RN66 Dr/bZ/qbsCmmAeObKic8= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 24 Feb 2012 13:51:05 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3910488033.19152.7012; Fri, 24 Feb 2012 13:51:04 -0500 Message-ID: <4F47DD28.2040904@isdg.net> Date: Fri, 24 Feb 2012 13:55:36 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4F46A8BF.2060507@isdg.net> <4F479D71.9020203@gathman.org> In-Reply-To: <4F479D71.9020203@gathman.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] new issue: Section 4.4 Parallel Query X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 18:55:20 -0000 Stuart Gathman wrote: >> In theory, the sequential order would be SPF type first, then TXT type >> as a fall back. The current text offer a functional spec requirement. >> What is needed is a technical specification description. That should >> be done as if there as no parallelism or MQP capability, only >> sequential. The parallel or MQP is essentially an DNS overhead >> optimization of the sequential method. > I disagree. An implementation MAY query TXT only, or SPF only. Agree. I did not intend to suggest otherwise. Speaking of the dual type support only. > So a > parallel implementation could query both in parallel, then use whichever > comes back first. The implementation can be thought of as a quantum > superposition of TXT only and SPF only, which resolves to a specific > choice when the first response packet arrives. and may I add... successful first response or first response satisfying the query, necessary to signal, abort, ignore the first pending response. > This is important, because a common problem is DNS servers that ignore > SPF queries (no reply at all) rather than returning "no such record". > Checking for SPF first sequentially is impractical because of this DNS > server bug. Well bug (not supported), yes, the RFC3597 issue was long understood. > But querying in parallel and using the first response works > in all cases. My point is that its just a method, so unless you are noting it SHOULD be the only recommended method, it needs to be expanded and explained. Primarily because A) it comes with an inherent design assumption about the SPF software integrated method for DNS client operations, and B) in lieu of A, the end result MUST|SHOULD match the most common possible, easier to do, synchronous sequential method. What is implies the SPF-BIS assumes the DNS resolver component of an SPF package is expected to have an asynchronous DNSQuery solution already embedded in its API. I don't think this technical requirement for the DNS API should be assumed, not assumed that the SPF software can be written to support asynchronous callback, event or messaging based frameworks. It can be 100% procedural or functional programming based with a synchronous programming model. In any case, it should explained anyway. :) -- Sincerely Hector Santos http://www.santronics.com jabber: hector@jabber.isdg.net -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From sm@elandsys.com Fri Feb 24 11:48:38 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6634521F8762 for ; Fri, 24 Feb 2012 11:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUQLbDUH+WrV for ; Fri, 24 Feb 2012 11:48:36 -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 0A10F21F8740 for ; Fri, 24 Feb 2012 11:48:35 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.233.90]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1OJmLX4025356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2012 11:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330112914; i=@elandsys.com; bh=8fXew0oG+xC9ZK7jblheTOZz+KGf7jdJ1Ro6N+yJEuI=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=b8fIZqxeU3LRpRXeLsgZZ9vGLXthfCpepTXmT8LJHSu28VP8KSFtcRRUVnQW6OWLx niD2qkZZRFp1qF/HWeoSSK2c4wFVC7swbGtghlc4Uf6i4E2Y2H3LeXrrOQW6SvUWX2 Y95yEJh/kKH0EJIU5jHRbl3tKdY1ThuPDcvHboak= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330112914; i=@elandsys.com; bh=8fXew0oG+xC9ZK7jblheTOZz+KGf7jdJ1Ro6N+yJEuI=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=qA3gJEAODHDnMzDWw5rk53kEfsuqyqvFQZMElZcJSrhqyKnUE8EIZgMoDis0ujAsT AiseA68TKoNXbvS4tos1I3E1rE8JGkN7NZnMZ3BzeahXqzJXpU4SZLlBn1xwD4DyU1 +gFmfZO7SG7D2TwKX9lnhLFzMRFTKL5XnkPRqQo8= Message-Id: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 24 Feb 2012 11:47:37 -0800 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org Subject: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 19:48:38 -0000 Hello, Empirical evidence so far seems to indicate that there is a significant amount of DNS queries for the SPF RR (TYPE 99) and some sites publish it. We have seen arguments in favour of removing the feature, and in favour of retaining it. Our charter says this: Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language. Therefore, the WG Chairs would like to close Issue #9 with the conclusion that the SPFBIS WG does not have consensus to remove the feature. Objections to this determination of consensus need to produce evidence that the feature is not used, or that the removal of TYPE 99 is an enhancement that has already gained widespread support. Please remember that the desirability of the removal of the feature is not enough: the charter restricts our freedom to do what we want here. Best regards, Andrew Sullivan & S. Moonesamy, SPFBIS WG Chairs From spf2@kitterman.com Fri Feb 24 12:17:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EE021F8806 for ; Fri, 24 Feb 2012 12:17:45 -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 0eICvb7FmD0F for ; Fri, 24 Feb 2012 12:17:45 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5181821F8790 for ; Fri, 24 Feb 2012 12:17:45 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 2F16DD0408D; Fri, 24 Feb 2012 14:17:44 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330114664; bh=6dZm+K9HtnDf0MODmEwVbq7i/hdDVUy8ZMW7EV5XZ4w=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:CC:Message-ID; b=a6EQa4orLvCQQ5eK8VUsgdwVe4MueILRt1vsime1P/69fsySIzwK6c8dxtPDkgoQz plDjA3TkR6FHwj43bNVvJb9lcvfq093eVBMaVX0fWnIYUEfRv8TIRhcP/Fvc/th5ow UbEfuO20Bl9aY7Ivuu4AdsSs/FW9AEPwKrK8esiI= Received: from 108.sub-97-1-14.myvzw.com (108.sub-97-1-14.myvzw.com [97.1.14.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 15BEAD04002; Fri, 24 Feb 2012 14:17:41 -0600 (CST) References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 24 Feb 2012 15:17:52 -0500 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Cc: spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 20:17:46 -0000 S Moonesamy wrote: >Hello, > >Empirical evidence so far seems to indicate that there is a >significant amount of DNS queries for the SPF RR (TYPE 99) and some >sites publish it. We have seen arguments in favour of removing the >feature, and in favour of retaining it. > >Our charter says this: > > Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any enhancements > that have already gained widespread support, and addition of > clarifying language. > >Therefore, the WG Chairs would like to close Issue #9 with the >conclusion that the SPFBIS WG does not have consensus to remove the >feature. > >Objections to this determination of consensus need to produce >evidence that the feature is not used, or that the removal of TYPE 99 >is an enhancement that has already gained widespread support. Please >remember that the desirability of the removal of the feature is not >enough: the charter restricts our freedom to do what we want here. Personally, I think Type SPF could be removed as a mistake, so I don't think we are inherently limited by the charter. If it stays in, there will be a derivative issue about query order. 4408 says SHOULD do Type SPF queries first if they are done sequentially. It should be the other way around. The query most likely to be successful should be done first. Scott K From dotzero@gmail.com Fri Feb 24 12:24:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521B521F864C for ; Fri, 24 Feb 2012 12:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbnDKcvXlHZ7 for ; Fri, 24 Feb 2012 12:24:26 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53D6021F8648 for ; Fri, 24 Feb 2012 12:24:26 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so3118162pbc.31 for ; Fri, 24 Feb 2012 12:24:26 -0800 (PST) Received-SPF: pass (google.com: domain of dotzero@gmail.com designates 10.68.218.228 as permitted sender) client-ip=10.68.218.228; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dotzero@gmail.com designates 10.68.218.228 as permitted sender) smtp.mail=dotzero@gmail.com; dkim=pass header.i=dotzero@gmail.com Received: from mr.google.com ([10.68.218.228]) by 10.68.218.228 with SMTP id pj4mr11713707pbc.167.1330115066152 (num_hops = 1); Fri, 24 Feb 2012 12:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=w0ce6859p9RqSG5E1JDIN4zvhYf8LU6Q0apQQxsTCzE=; b=KaBmP3GauhBS3sWUyPOYyrSQeTK8mSGdPz95kmxcnRkDCc5UiEHjS/vDOgGIba2ADS YGdPxxRyWeeuFQDlUM8dpnSwiRV1wllW98ayBFAW84Gqr4yG02SlPKAbwosMh5UWDauV ZxkODczgtPbK07VqHdVbtPv+66DPxPScwt1rE= MIME-Version: 1.0 Received: by 10.68.218.228 with SMTP id pj4mr9716846pbc.167.1330115066019; Fri, 24 Feb 2012 12:24:26 -0800 (PST) Received: by 10.68.35.198 with HTTP; Fri, 24 Feb 2012 12:24:25 -0800 (PST) In-Reply-To: References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> Date: Fri, 24 Feb 2012 15:24:25 -0500 Message-ID: From: Dotzero To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 20:24:27 -0000 On Fri, Feb 24, 2012 at 3:17 PM, Scott Kitterman wrote= : > > > S Moonesamy wrote: > >>Hello, >> >>Empirical evidence so far seems to indicate that there is a >>significant amount of DNS queries for the SPF RR (TYPE 99) and some >>sites publish it. =A0We have seen arguments in favour of removing the >>feature, and in favour of retaining it. >> >>Our charter says this: >> >> =A0 =A0 Changes to the SPF specification will be limited to the correcti= on >> =A0 =A0of errors, removal of unused features, addition of any enhancemen= ts >> =A0 =A0 =A0 that have already gained widespread support, and addition of >> =A0 =A0 =A0 clarifying language. >> >>Therefore, the WG Chairs would like to close Issue #9 with the >>conclusion that the SPFBIS WG does not have consensus to remove the >>feature. >> >>Objections to this determination of consensus need to produce >>evidence that the feature is not used, or that the removal of TYPE 99 >>is an enhancement that has already gained widespread support. =A0Please >>remember that the desirability of the removal of the feature is not >>enough: the charter restricts our freedom to do what we want here. > > Personally, I think Type SPF could be removed as a mistake, so I don't th= ink we are inherently limited by the charter. > > If it stays in, there will be a derivative issue about query order. 4408 = says SHOULD do Type SPF queries first if they are done sequentially. It sho= uld be the other way around. The query most likely to be successful should = be done first. > > Scott K > I don't have a strong position about keeping itor dropping it but I agree with Scott that if we keep it we should minimize overhead by specifying the query most likely to be successful (TXT) should be done first. Mike From msk@cloudmark.com Fri Feb 24 12:29:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DE621F85E4 for ; Fri, 24 Feb 2012 12:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmvXWUuQff8P for ; Fri, 24 Feb 2012 12:29:49 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 51F0721F85DA for ; Fri, 24 Feb 2012 12:29:49 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 12:29:48 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors Thread-Index: AQHM8Z1H6I5T9g0T0E20useE1cLBoZZKHlgAgAKXugD//8uEoA== Date: Fri, 24 Feb 2012 20:29:48 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392804543B@exch-mbx901.corp.cloudmark.com> References: <061.455654aa40583da61895c644f7120a55@tools.ietf.org> <6.2.5.6.2.20120222115949.08f70548@elandnews.com> <9452079D1A51524AA5749AD23E0039280417A3@exch-mbx901.corp.cloudmark.com> <1775995.RF6pGKfp5q@scott-latitude-e6320> In-Reply-To: <1775995.RF6pGKfp5q@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 20:29:50 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Friday, February 24, 2012 7:33 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors >=20 > My initial thought is to allow (but not require) receivers to track > SERVFAIL based temperrors and if they persist for more than $PERIOD > (let's start the bidding at 24 hours) then future consectutive SERVFAIL > responses for that domain MAY be considered permanent errors. Given that the IESG recently approved publication of the V6OPS working grou= p's draft known as "Happy Eyeballs", which provides guidance for an applica= tion to remember the results of simultaneous IPv4 and IPv6 operations and o= ptimize based on that, this seems like something worth considering. I don'= t know about normative guidance, but an informative-only appendix might be = useful. -MSK From ajs@anvilwalrusden.com Fri Feb 24 12:31:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B373A21F8668 for ; Fri, 24 Feb 2012 12:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 zsHihQ+KkHDG for ; Fri, 24 Feb 2012 12:31:37 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBEE21F8665 for ; Fri, 24 Feb 2012 12:31:37 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7DA3C1ECB41D for ; Fri, 24 Feb 2012 20:31:36 +0000 (UTC) Date: Fri, 24 Feb 2012 15:31:34 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120224203134.GX48576@crankycanuck.ca> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 20:31:37 -0000 Dear colleagues, On Fri, Feb 24, 2012 at 03:17:52PM -0500, Scott Kitterman wrote: > > Changes to the SPF specification will be limited to the > > correction of errors, > Personally, I think Type SPF could be removed as a mistake, so I > don't think we are inherently limited by the charter. Speaking with my hat on, I think the meaning of "correction of errors" in the charter means corrections of errors in the specification and not in the design. That is, this is the basis for incorporation of errata. I believe the charter is designed precisely to limit changes in functionality. I'd be very much interested if people disagree with that interpretation, and would like to hear as much if so. If my interpretation is right, then "mistake" in your sense wouldn't qualify, because you're arguing that it was a mistake in the design, and not a mistake in the way the RFC describes things. > If it stays in, there will be a derivative issue about query > order. 4408 says SHOULD do Type SPF queries first if they are done > sequentially. It should be the other way around. The query most > likely to be successful should be done first. Do you think (or not think) that that is also a substantive change in functionality, and therefore would qualify as an "enhancement"? Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Fri Feb 24 12:32:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476A821F8665 for ; Fri, 24 Feb 2012 12:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkxVi9COUvdZ for ; Fri, 24 Feb 2012 12:32:09 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D8F0421F8673 for ; Fri, 24 Feb 2012 12:32:09 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 12:32:07 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM8zFhNwxGRlP/oEacj/zQIUmnUJZNBFOA//97xdA= Date: Fri, 24 Feb 2012 20:32:06 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928045457@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 20:32:10 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dotzero > Sent: Friday, February 24, 2012 12:24 PM > To: Scott Kitterman > Cc: spfbis@ietf.org; spfbis-chairs@tools.ietf.org > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issu= e #9) >=20 > > If it stays in, there will be a derivative issue about query order. > > 4408 says SHOULD do Type SPF queries first if they are done > > sequentially. It should be the other way around. The query most likely > > to be successful should be done first. >=20 > I don't have a strong position about keeping itor dropping it but I > agree with Scott that if we keep it we should minimize overhead by > specifying the query most likely to be successful (TXT) should be done > first. I agree that this is at least worthy of discussion. Please open it as a ne= w issue so we can discuss it at some point. -MSK From msk@cloudmark.com Fri Feb 24 12:34:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C7A21F85D5 for ; Fri, 24 Feb 2012 12:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjx2niY9tnRu for ; Fri, 24 Feb 2012 12:34:38 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 200E221F85D2 for ; Fri, 24 Feb 2012 12:34:38 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 12:34:37 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM8zFhNwxGRlP/oEacj/zQIUmnUJZNBlIA//96dHA= Date: Fri, 24 Feb 2012 20:34:36 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392804546F@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> In-Reply-To: <20120224203134.GX48576@crankycanuck.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 20:34:39 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Andrew Sullivan > Sent: Friday, February 24, 2012 12:32 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issu= e #9) >=20 > > If it stays in, there will be a derivative issue about query order. > > 4408 says SHOULD do Type SPF queries first if they are done > > sequentially. It should be the other way around. The query most likely > > to be successful should be done first. >=20 > Do you think (or not think) that that is also a substantive change in > functionality, and therefore would qualify as an "enhancement"? I think it qualifies under the clause "addition of any enhancements that ha= ve already gained widespread support", if we can show that most of the SPF = record publications use TXT. We are thus guided by the implementation we o= bserve. -MSK From msk@cloudmark.com Fri Feb 24 12:47:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE6021F84C4 for ; Fri, 24 Feb 2012 12:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.266 X-Spam-Level: X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id retY+lIiVjF1 for ; Fri, 24 Feb 2012 12:47:16 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8B90121F84C3 for ; Fri, 24 Feb 2012 12:47:16 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 12:47:16 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors Thread-Index: AQHM8Z1H6I5T9g0T0E20useE1cLBoZZKHlgAgAKXugD//8uEoIAABf7g Date: Fri, 24 Feb 2012 20:47:15 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392804549E@exch-mbx901.corp.cloudmark.com> References: <061.455654aa40583da61895c644f7120a55@tools.ietf.org> <6.2.5.6.2.20120222115949.08f70548@elandnews.com> <9452079D1A51524AA5749AD23E0039280417A3@exch-mbx901.corp.cloudmark.com> <1775995.RF6pGKfp5q@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392804543B@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392804543B@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 20:47:17 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > Behalf Of Murray S. Kucherawy > Sent: Friday, February 24, 2012 12:30 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors >=20 > Given that the IESG recently approved publication of the V6OPS working > group's draft known as "Happy Eyeballs", which provides guidance for an > application to remember the results of simultaneous IPv4 and IPv6 > operations and optimize based on that, this seems like something worth > considering. I don't know about normative guidance, but an > informative-only appendix might be useful. In case someone wants to see what I'm referencing: http://datatracker.ietf.org/doc/draft-ietf-v6ops-happy-eyeballs/ -MSK From hsantos@isdg.net Fri Feb 24 13:01:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C5721F874C for ; Fri, 24 Feb 2012 13:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2MZUbMtNCHh for ; Fri, 24 Feb 2012 13:01:50 -0800 (PST) Received: from ftp.catinthebox.net (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 996A621F874F for ; Fri, 24 Feb 2012 13:01:50 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1824; t=1330117304; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Az3rMrJSYahvtyiI1hH1pGkUexY=; b=n1foMz73+SP/aNNEdTV6 eHFrEkVKqq0p+lwgaD1BiMw9Rg+B3yCpGGqm/Va+pOr3ePIUNmgPEKhJ98whIgnp R8KJCNXQ1AzKl7ALqdLmL9KrgWwx9J93GCbaWvtJveWcOqVi/Yv4WRBrifoKZI0q oIfhgxxTaPrVCEaha+GYoQc= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 24 Feb 2012 16:01:44 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3319146804.90415.1432; Fri, 24 Feb 2012 16:01:43 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1824; t=1330117061; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=iAKIptA PsG76we4EWUxM6Eh8XNBSGWD6a0N0gdExER8=; b=DSbloAmi1Cr7q9bk4fynfOS dDw5vm5uHtT670+jLrDzUaNUl/bwFLFxJtYsAhE1KE40A12DankYxc9ct5pfeW1W c1R6b2zKEdodYdrjYBGX6fN0c/SouU73qo3lQDFteSQonFT/LXY4r0Wx3I/QHmn6 GYpLjTYKLqulsY4K3z7I= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 24 Feb 2012 15:57:41 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3918083767.19167.6936; Fri, 24 Feb 2012 15:57:40 -0500 Message-ID: <4F47FA98.4080200@isdg.net> Date: Fri, 24 Feb 2012 16:01:12 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dotzero References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Scott Kitterman Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 21:01:55 -0000 Dotzero wrote: >> Scott wrote: > >> Personally, I think Type SPF could be removed as a mistake, so I don't think we >> are inherently limited by the charter. >> >> If it stays in, there will be a derivative issue about query order. 4408 says >> SHOULD do Type SPF queries first if they are done sequentially. It should be >> the other way around. The query most likely to be successful should be done first. >> >> Scott K >> > > I don't have a strong position about keeping itor dropping it but I > agree with Scott that if we keep it we should minimize overhead by > specifying the query most likely to be successful (TXT) should be done > first. > > Mike I think it would be a mistake if we do not consider these are extremely important points with was always a common design goal to reduce and minimize all DNS related overhead concerns. I believe the original intent which included short term concerns and long term expectations for adoption was right on and the time spent to measure it now has shown the correct RFC engineering expectations has materialized. SPF always had several thorns on it side within the IETF and one of them was its high DNS dependency and the "Kludge Effect" of using a TXT record. Personally, this is one of those "feel good" outcomes that took a long time to see it done right. I believe what is important now, could be viewed at the 2nd phase which is to begin to study and recommend the methods available from the worst to the ideal and preferred method for dual type queries. The 2nd phase also includes moving towards the publishing of SPF type only records which will also take many years, but it will never happen unless SPF-BIS prepares and encourages it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Fri Feb 24 13:05:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5F921F87AF for ; Fri, 24 Feb 2012 13:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, SARE_SUB_ENC_UTF8x2=0.246] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sq0Z+w7iF1ua for ; Fri, 24 Feb 2012 13:05:22 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 42EE921F8769 for ; Fri, 24 Feb 2012 13:05:22 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 64860D0408D; Fri, 24 Feb 2012 15:05:15 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330117515; bh=UP0LkjkjjjQErK9wO+OFL8TIptrKVzbGi2R79Dh1rBQ=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=hUYQSzlwR8Encb3X8jxO/Y0xHacmexKtIjHrXVPXqOGo5Kd6B/wzts4qu15QifCc0 +Ex2xAZMKpuT/UE5BzdJXoH8Q6H8cCEJVFjbD63DK8VOnK9zaJMqv5mOT1/N20r6pL wgKI7e0muhq0DKQqT21yd0jVxk577hnEXah6Y9fE= Received: from 108.sub-97-1-14.myvzw.com (108.sub-97-1-14.myvzw.com [97.1.14.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E0C17D04002; Fri, 24 Feb 2012 15:05:14 -0600 (CST) References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> User-Agent: K-9 Mail for Android In-Reply-To: <20120224203134.GX48576@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 24 Feb 2012 16:05:15 -0500 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] =?utf-8?q?Call_for_intermediate_consensus_on_SPF_RRTYPE_?= =?utf-8?b?KGlzc3VlCSM5KQ==?= X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 21:05:23 -0000 Andrew Sullivan wrote: >Dear colleagues, > >On Fri, Feb 24, 2012 at 03:17:52PM -0500, Scott Kitterman wrote: >> > Changes to the SPF specification will be limited to the >> > correction of errors, > >> Personally, I think Type SPF could be removed as a mistake, so I >> don't think we are inherently limited by the charter. > >Speaking with my hat on, I think the meaning of "correction of errors" >in the charter means corrections of errors in the specification and >not in the design. That is, this is the basis for incorporation of >errata. I believe the charter is designed precisely to limit changes >in functionality. I'd be very much interested if people disagree with >that interpretation, and would like to hear as much if so. > >If my interpretation is right, then "mistake" in your sense wouldn't >qualify, because you're arguing that it was a mistake in the design, >and not a mistake in the way the RFC describes things. > >> If it stays in, there will be a derivative issue about query >> order. 4408 says SHOULD do Type SPF queries first if they are done >> sequentially. It should be the other way around. The query most >> likely to be successful should be done first. > >Do you think (or not think) that that is also a substantive change in >functionality, and therefore would qualify as an "enhancement"? The maturity level of the design related to Type SPF and it's interaction with Type TXT SPF records was substantially less than the rest of RFC 4408. The rest of the SPF design was built on years of running code and operational experience. The Type SPF parts were a paper design with literally days to do minimal experimentation. As long as we aren't changing the design in an incompatible way, there ought to be more wiggle room for changes due to error in this area. Scott K From barryleiba.mailing.lists@gmail.com Fri Feb 24 13:08:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7B721F8796 for ; Fri, 24 Feb 2012 13:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.988 X-Spam-Level: X-Spam-Status: No, score=-102.988 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aucTOmFkkBzP for ; Fri, 24 Feb 2012 13:08:58 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E889A21F87DE for ; Fri, 24 Feb 2012 13:08:57 -0800 (PST) Received: by yenm3 with SMTP id m3so1537813yen.31 for ; Fri, 24 Feb 2012 13:08:53 -0800 (PST) Received-SPF: pass (google.com: domain of barryleiba.mailing.lists@gmail.com designates 10.236.145.230 as permitted sender) client-ip=10.236.145.230; Authentication-Results: mr.google.com; spf=pass (google.com: domain of barryleiba.mailing.lists@gmail.com designates 10.236.145.230 as permitted sender) smtp.mail=barryleiba.mailing.lists@gmail.com; dkim=pass header.i=barryleiba.mailing.lists@gmail.com Received: from mr.google.com ([10.236.145.230]) by 10.236.145.230 with SMTP id p66mr8027189yhj.27.1330117733948 (num_hops = 1); Fri, 24 Feb 2012 13:08:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=ZFyM98QcqPdZcmVclQ62CUiivleEP1U6H1UcyAZXhoI=; b=Ke8QQMM5xaknxblhAzoWDunNpvpeuD0l5FXUfbO9aAsxafF1NNfp73GjOpv73lQCmZ GsIPOl4MQewnYLs01eqQ5yj1Uqb4mzQBwj/WCHWkvIGvZpUEU8w6NeQ/VoC8xSi/wBwt wZUwrYDKlkNu0bVeSP2/8V85V4mS2bbPkdguA= MIME-Version: 1.0 Received: by 10.236.145.230 with SMTP id p66mr6085666yhj.27.1330117733866; Fri, 24 Feb 2012 13:08:53 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.106.16 with HTTP; Fri, 24 Feb 2012 13:08:53 -0800 (PST) In-Reply-To: <20120224203134.GX48576@crankycanuck.ca> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> Date: Fri, 24 Feb 2012 16:08:53 -0500 X-Google-Sender-Auth: tK8Vx82rhwMAxEzTYPtdqbiOE7Y Message-ID: From: Barry Leiba To: spfbis@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 21:08:58 -0000 >> Personally, I think Type SPF could be removed as a mistake, so I >> don't think we are inherently limited by the charter. Pete is the AD responsible for this WG, so I'll defer to him, at least for now, if he disagrees with me, but I think the situation is as Andrew said, and that trying to declare the definition of an SPF RR an "error" in order to remove it is an attempt to sneak past the charter restrictions. Not acceptable. >> If it stays in, there will be a derivative issue about query >> order. 4408 says SHOULD do Type SPF queries first if they are done >> sequentially. It should be the other way around. The query most >> likely to be successful should be done first. > > Do you think (or not think) that that is also a substantive change in > functionality, and therefore would qualify as an "enhancement"? If "nearly all" existing implementations query TXT first, then the charter allows this change, as an enhancement that has gained widespread support. I would also be willing to be convinced that it's a "clarification", though it would take some convincing. (And I don't see where RFC 4408 says anything at all about which "SHOULD" be queried first; perhaps someone can point to the section and paragraph they think says that.) Let's please tread carefully here, lest someone win this one, and then find himself on the losing end of a different issue wherein people are trying to tweak the spec beyond what the charter was meant to allow. I suggest that we stick to the intent of the charter, which is to move what's currently there to standards track, and to consider these sorts of changes afterward, as an update at PS or during advancement to IS. Barry, incoming App AD From WebMaster@Commerco.Net Fri Feb 24 13:21:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ADF21F8548 for ; Fri, 24 Feb 2012 13:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDNOWMMrMj1E for ; Fri, 24 Feb 2012 13:21:00 -0800 (PST) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 17D2921F8545 for ; Fri, 24 Feb 2012 13:21:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=ybPt7sxCYF7R5sJzvSL4wHMbQhI4DsuVU40a444FEa/MklsP0Fh5WIKzq75MxKpo3loaJkOj/HcACa5S0NAMso8c5KZnf6tNMVotHRXKRtHQpN2I39A2sz78VH+IyHjkEALlc+9F8dkfBFnTAiXWtM3DKwoiZFa4gOmPiYiHPhc= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Fri, 24 Feb 2012 21:20:58 +0000 Message-ID: <4F47FF34.9020808@Commerco.Net> Date: Fri, 24 Feb 2012 14:20:52 -0700 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> In-Reply-To: <20120224203134.GX48576@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 21:21:01 -0000 On 2/24/2012 1:31 PM, Andrew Sullivan wrote: > Dear colleagues, > > On Fri, Feb 24, 2012 at 03:17:52PM -0500, Scott Kitterman wrote: >>> Changes to the SPF specification will be limited to the >>> correction of errors, > >> Personally, I think Type SPF could be removed as a mistake, so I >> don't think we are inherently limited by the charter. > > Speaking with my hat on, I think the meaning of "correction of errors" > in the charter means corrections of errors in the specification and > not in the design. That is, this is the basis for incorporation of > errata. I believe the charter is designed precisely to limit changes > in functionality. I'd be very much interested if people disagree with > that interpretation, and would like to hear as much if so. > > If my interpretation is right, then "mistake" in your sense wouldn't > qualify, because you're arguing that it was a mistake in the design, > and not a mistake in the way the RFC describes things. > >> If it stays in, there will be a derivative issue about query >> order. 4408 says SHOULD do Type SPF queries first if they are done >> sequentially. It should be the other way around. The query most >> likely to be successful should be done first. > > Do you think (or not think) that that is also a substantive change in > functionality, and therefore would qualify as an "enhancement"? > > Thanks, > > A > I agree with your interpretation as regards specification documentation errors vs. design refinements. In SPF v1, there seems at least a case for keeping and supporting the RR specifically allocated for SPF by the good folks who shepherd the DNS RR allocations. While others argue that the TXT record is currently the most widely published and that the SPF is not always selected first, perhaps that comes from the history of the implementation of SPF, which started before the SPF RR was ever approved and implemented in BIND DNS and later in other such DNS server software. Going forward, I think that it makes sense to keep to the implementation recommendations in the SPF experimental draft (i.e., one should check for SPF RR then TXT RR). Over time, I think it was the hope of the earlier group working on the specification that folks would transition to the SPF RRs when that recommendation was made. While that may not have happened in a broad sense as quickly as had been hoped within the SPF publishing or implementer community, perhaps with this SPFbis, we are reinforcing what we think is a best practice behavior in implementing SPF as a publisher. Another point brought forward is that often it takes time to get folks to move forward on upgrading software versions and making changes to DNS authoritative host zone files. While that is true, it should not negate the responsibility of those putting together specifications to point folks in the right direction as regards the implementation of SPF RRs in their DNS host zone files. Operationally, I think that keeping the TXT and SPF RRs in sync is not really all that hard to do. Best, Alan M. From msk@cloudmark.com Fri Feb 24 13:22:09 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC0C21F8753 for ; Fri, 24 Feb 2012 13:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 1Qug+YJq+t5m for ; Fri, 24 Feb 2012 13:22:08 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 914AB21F87C7 for ; Fri, 24 Feb 2012 13:22:07 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 13:22:06 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM8zFhNwxGRlP/oEacj/zQIUmnUJZNBlIAgAAKbYD//3wQ8A== Date: Fri, 24 Feb 2012 21:22:06 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392804555D@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 21:22:09 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Barry Leiba > Sent: Friday, February 24, 2012 1:09 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issu= e #9) >=20 > >> If it stays in, there will be a derivative issue about query order. > >> 4408 says SHOULD do Type SPF queries first if they are done > >> sequentially. It should be the other way around. The query most > >> likely to be successful should be done first. > > > > Do you think (or not think) that that is also a substantive change in > > functionality, and therefore would qualify as an "enhancement"? >=20 > If "nearly all" existing implementations query TXT first, then the > charter allows this change, as an enhancement that has gained > widespread support. I would also be willing to be convinced that it's > a "clarification", though it would take some convincing. (And I don't > see where RFC 4408 says anything at all about which "SHOULD" be queried > first; perhaps someone can point to the section and paragraph they > think says that.) My own read of the accumulated data to date (which I don't assert is the co= nsensus view, though it might be) is that most implementations query SPF an= d then TXT, or query them approximately simultaneously; meanwhile, most SPF= records that exist are of type TXT. This at least lends support to advoca= ting a client optimization that takes advantage of this, perhaps in an info= rmative statement. We are, after all, basing this advancement on interoper= ability experience gained in the last six years. I think the charter permi= ts that. One could also acknowledge that that's just how things appear today, and th= ere could be some shift in the direction of publishing type SPF records for= some reason as this work and related work evolve. But that's pretty hard = to predict. -MSK From msk@cloudmark.com Fri Feb 24 13:24:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE5C21F87B1 for ; Fri, 24 Feb 2012 13:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 gJIsZ1P7Qe71 for ; Fri, 24 Feb 2012 13:24:10 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 17CE121F8650 for ; Fri, 24 Feb 2012 13:24:10 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 13:24:09 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM8zo3qm5Toirri0OwQXkGIh4zbJZMjmfA Date: Fri, 24 Feb 2012 21:24:09 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928045579@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> In-Reply-To: <4F47FF34.9020808@Commerco.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 21:24:10 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Commerco WebMaster > Sent: Friday, February 24, 2012 1:21 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issu= e #9) >=20 > Operationally, I think that keeping the TXT and SPF RRs in sync is not > really all that hard to do. This brings up an interesting question: Although we (as experienced folk) f= ind doing so operationally easy, there are examples of cases where this isn= 't done. It is of course hard to determine whether those operators did so = intentionally. Nevertheless, we might think it's hard, but maybe the laype= rson disagrees. The question, then, is how that should influence what we p= roduce here. -MSK From dotis@mail-abuse.org Fri Feb 24 13:35:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C1C21F86D9 for ; Fri, 24 Feb 2012 13:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFw0aAfY2kpc for ; Fri, 24 Feb 2012 13:35:05 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9AF21F86B8 for ; Fri, 24 Feb 2012 13:35:04 -0800 (PST) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 9A691174037D for ; Fri, 24 Feb 2012 21:35:02 +0000 (UTC) Message-ID: <4F480284.10800@mail-abuse.org> Date: Fri, 24 Feb 2012 13:35:00 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <9452079D1A51524AA5749AD23E003928045579@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928045579@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 21:35:06 -0000 On 2/24/12 1:24 PM, Murray S. Kucherawy wrote: > > On Friday, February 24, 2012 1:21 PM, Commerco WebMaster wrote: > > > > Operationally, I think that keeping the TXT and SPF RRs in sync is > > not really all that hard to do. > > This brings up an interesting question: Although we (as experienced > folk) find doing so operationally easy, there are examples of cases > where this isn't done. It is of course hard to determine whether > those operators did so intentionally. Nevertheless, we might think > it's hard, but maybe the layperson disagrees. The question, then, is > how that should influence what we produce here. Dear Murray, The suggestion of creating recommendations similar to those found in Dan Wing's and Andrew Yourtchenko's draft is good. This type of advice could cover Name and No Data errors generally, while addressing resource type selection. Regards, Douglas Otis From ajs@anvilwalrusden.com Fri Feb 24 13:41:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0762721F8637 for ; Fri, 24 Feb 2012 13:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 9Cb+8EREAVxB for ; Fri, 24 Feb 2012 13:41:25 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF5421F8638 for ; Fri, 24 Feb 2012 13:41:25 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 91FF91ECB41D for ; Fri, 24 Feb 2012 21:41:24 +0000 (UTC) Date: Fri, 24 Feb 2012 16:41:22 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120224214122.GA48576@mail.yitter.info> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <9452079D1A51524AA5749AD23E003928045579@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9452079D1A51524AA5749AD23E003928045579@exch-mbx901.corp.cloudmark.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Dirgression about DNS maintenance (was: Call for intermediate consensus on SPF RRTYPE (issue #9)) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 21:41:26 -0000 No hat, and this is not strictly on topic. On Fri, Feb 24, 2012 at 09:24:09PM +0000, Murray S. Kucherawy wrote: > > This brings up an interesting question: Although we (as experienced > folk) find doing so operationally easy, there are examples of cases > where this isn't done. It is of course hard to determine whether > those operators did so intentionally. Nevertheless, we might think > it's hard, but maybe the layperson disagrees. The question, then, > is how that should influence what we produce here. Frankly, a lot of the reason for difficulty with DNS administration (in this case, keeping SPF and the corresponding TXT records in sync, but there are lots of other issues, such as proper zone transfer hygeine, SOA serial handling -- anything you like) just comes down to the same miserable toolchain that people have for maintaining DNS zones. Large numbers of operators still, as far as I can tell, use manual entry and cut and paste and so on as the main tools for maintaining their zones. A surprising number of people don't even have automatic check-ins to revision control in order to go back if something is broken. And a terrible number of DNS interfaces are just web pages with forms in them: you _couldn't_ do good change control even if you wanted to. With that being the way zones are maintained, it is no wonder that people don't use the SPF (or any other specialized) record. It is, however, also a possible reason why just falling back to TXT records are dangerous: because TXT can't possibly have strong error-checking rules attached to it in a general-purpose DNS maintenance system, it's easy to break things with TXT where it should be hard if you have well-defined data types. The overall situation for "layperson" DNS operators is, frankly, depressing no matter which way you turn. Boo hiss. A -- Andrew Sullivan ajs@anvilwalrusden.com From pgladstone@cisco.com Fri Feb 24 14:01:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1331721F8734 for ; Fri, 24 Feb 2012 14:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.449 X-Spam-Level: X-Spam-Status: No, score=-8.449 tagged_above=-999 required=5 tests=[AWL=2.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9tdheFJFPzR for ; Fri, 24 Feb 2012 14:01:15 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA4421F8720 for ; Fri, 24 Feb 2012 14:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=1182; q=dns/txt; s=iport; t=1330120852; x=1331330452; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=6DLr8T5wpz1et7y6jnCfqPOCn8RGCR+xHZHJuTK/oFs=; b=T039tBV+eXPrBfUICUPt46mCSttsKRvhXOuX8YTyj3QYbNus10Ps8RIp 54YJItewkRit1b/VIPCATfBfAeXhuIsK3p7lA7JF5u+GNsnDNaTqF0D4r QHIItcW0K0v+rue9teLvbazHqEP84u12DZus0JZ7XhA8CDIXLCQZCT3xU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4HANgHSE+tJXG//2dsb2JhbABCgwGCJ6pjgwWBB4FzAQEBBBIBCgYVNAwRCxgCAgUWCwICCQMCAQIBRRMIAQEeh2SZLQGMZZFtgS+IRIMaKwECCwQFCgMDBwMCBQIQAQoCBQMChRwTAgILAgUGU4IIgRYEiE+MbIVdjTCBNQ X-IronPort-AV: E=Sophos;i="4.73,478,1325462400"; d="scan'208";a="61657580" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 24 Feb 2012 22:00:51 +0000 Received: from [10.117.107.24] (rtp-pgladsto-8917.cisco.com [10.117.107.24]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1OM0pfB016316 for ; Fri, 24 Feb 2012 22:00:51 GMT Message-ID: <4F480892.8000409@cisco.com> Date: Fri, 24 Feb 2012 17:00:50 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 22:01:18 -0000 On 2/24/2012 2:47 PM, S Moonesamy wrote: > Hello, > > Empirical evidence so far seems to indicate that there is a > significant amount of DNS queries for the SPF RR (TYPE 99) and some > sites publish it. We have seen arguments in favour of removing the > feature, and in favour of retaining it. > > Our charter says this: > > Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any enhancements > that have already gained widespread support, and addition of > clarifying language. > > Therefore, the WG Chairs would like to close Issue #9 with the > conclusion that the SPFBIS WG does not have consensus to remove the > feature. > > Objections to this determination of consensus need to produce evidence > that the feature is not used, or that the removal of TYPE 99 is an > enhancement that has already gained widespread support. Please > remember that the desirability of the removal of the feature is not > enough: the charter restricts our freedom to do what we want here. > > I agree with the conclusion as it is based on real data. Philip From spf2@kitterman.com Fri Feb 24 14:42:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33ACE21F8755 for ; Fri, 24 Feb 2012 14:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq0n+gSaNIRA for ; Fri, 24 Feb 2012 14:42:21 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5958821F8768 for ; Fri, 24 Feb 2012 14:42:21 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8C88120E40CC; Fri, 24 Feb 2012 17:42:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330123340; bh=wg5tw/DcQl10pDJcx2Ow8AddS4mMqVOD9jXTDe6Lg2A=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=g5dFPcjmGqQisEsSHH/2O8gTOQGZXfxVIWTHM8uiIPTejy+z+BquM5z9wnASuU5Qo qXLYylhwXahkYaR9zJLTkKvaiYCmzvXjZwFEqu7dFtVoSsX19vkGOn9bMSRadnKwMj m50GhmkKL5O0lDablz0+RAp4TtOikRH6oIrluy18= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6F76C20E4083; Fri, 24 Feb 2012 17:42:20 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 24 Feb 2012 17:42:16 -0500 Message-ID: <4947273.LJoS51zXER@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E00392804546F@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <9452079D1A51524AA5749AD23E00392804546F@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 22:42:22 -0000 On Friday, February 24, 2012 08:34:36 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Andrew Sullivan Sent: Friday, February 24, 2012 12:32 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE > > (issue #9)> > > > If it stays in, there will be a derivative issue about query order. > > > 4408 says SHOULD do Type SPF queries first if they are done > > > sequentially. It should be the other way around. The query most > > > likely > > > to be successful should be done first. > > > > Do you think (or not think) that that is also a substantive change in > > functionality, and therefore would qualify as an "enhancement"? > > I think it qualifies under the clause "addition of any enhancements that > have already gained widespread support", if we can show that most of the > SPF record publications use TXT. We are thus guided by the implementation > we observe. I think we've already established that. Scott K From spf2@kitterman.com Fri Feb 24 14:47:29 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC2E21E8011 for ; Fri, 24 Feb 2012 14:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzKAce7OkJDq for ; Fri, 24 Feb 2012 14:47:28 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BB27021E800E for ; Fri, 24 Feb 2012 14:47:28 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 50F4320E40CC; Fri, 24 Feb 2012 17:47:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330123648; bh=iU8XsJFX5k+H8QzzUBOEHTa6Q2mN1GMKCgBjbbgQuNQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=j5z0/EL55lq2lErVohGX24HE1iudT7VR+OAk+Ivp+elcDBmQSevSLTp8zNi/riwu9 KwcqOe/7iH2o8K6O/u8fZ4zA3BzG2mv7FIlWX5Pul8g9KR9qDS8DP+fSORpDrSrlf1 Ixj2AyuKlr5v5CNl7PQa8aBcTKZpFDQBKqc1B7s8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3379D20E4083; Fri, 24 Feb 2012 17:47:28 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 24 Feb 2012 17:47:27 -0500 Message-ID: <11274811.MESzFagJMh@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 22:47:29 -0000 On Friday, February 24, 2012 04:08:53 PM Barry Leiba wrote: > >> Personally, I think Type SPF could be removed as a mistake, so I > >> don't think we are inherently limited by the charter. > > Pete is the AD responsible for this WG, so I'll defer to him, at least > for now, if he disagrees with me, but I think the situation is as > Andrew said, and that trying to declare the definition of an SPF RR an > "error" in order to remove it is an attempt to sneak past the charter > restrictions. Not acceptable. > > >> If it stays in, there will be a derivative issue about query > >> order. 4408 says SHOULD do Type SPF queries first if they are done > >> sequentially. It should be the other way around. The query most > >> likely to be successful should be done first. > > > > Do you think (or not think) that that is also a substantive change in > > functionality, and therefore would qualify as an "enhancement"? > > If "nearly all" existing implementations query TXT first, then the > charter allows this change, as an enhancement that has gained > widespread support. I would also be willing to be convinced that it's > a "clarification", though it would take some convincing. (And I don't > see where RFC 4408 says anything at all about which "SHOULD" be > queried first; perhaps someone can point to the section and paragraph > they think says that.) There aren't any. The ones that query TXT "first" query only TXT because there's no point in a second query for Type SPF. Domains that don't publish Type TXT won't be publishing Type SPF, so to expend remote resources to respond to such pointless queries borders on abusive. > Let's please tread carefully here, lest someone win this one, and then > find himself on the losing end of a different issue wherein people are > trying to tweak the spec beyond what the charter was meant to allow. > I suggest that we stick to the intent of the charter, which is to move > what's currently there to standards track, and to consider these sorts > of changes afterward, as an update at PS or during advancement to IS. I think this one is unique because it has no negative interoperability impacts. Scott K From spf2@kitterman.com Fri Feb 24 14:49:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72C721F8545 for ; Fri, 24 Feb 2012 14:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9sWvzJyygD5 for ; Fri, 24 Feb 2012 14:49:41 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4919421F8540 for ; Fri, 24 Feb 2012 14:49:41 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CFE9620E40CC; Fri, 24 Feb 2012 17:49:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330123780; bh=pLlUWKy+6HY0EJWj46AGgCxCTUC/B8WsRHgzTGnHCxU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=BhnfPw83Zw8aG+MRZMSfaDE3b7nvD9bT1510+1Seos6zLwyk3eYxz0D/PNgM66ndn Ojjnna3msngJEf5DxpXsdym7qk0YJVFz//tXNEq3kvz41tcUWtthsDlXEDOqv77WjC qm1D+eJ5YrEMeLqLnuSqo0aEQoyWGKvGPTRyKWjo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B29C320E4083; Fri, 24 Feb 2012 17:49:40 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 24 Feb 2012 17:49:40 -0500 Message-ID: <2130775.pmXu51Ebxp@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E00392804555D@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <9452079D1A51524AA5749AD23E00392804555D@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 22:49:42 -0000 On Friday, February 24, 2012 09:22:06 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Barry Leiba Sent: Friday, February 24, 2012 1:09 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE > > (issue #9)> > > >> If it stays in, there will be a derivative issue about query > > >> order. > > >> 4408 says SHOULD do Type SPF queries first if they are done > > >> sequentially. It should be the other way around. The query most > > >> likely to be successful should be done first. > > > > > > Do you think (or not think) that that is also a substantive change > > > in > > > functionality, and therefore would qualify as an "enhancement"? > > > > If "nearly all" existing implementations query TXT first, then the > > charter allows this change, as an enhancement that has gained > > widespread support. I would also be willing to be convinced that it's > > a "clarification", though it would take some convincing. (And I don't > > see where RFC 4408 says anything at all about which "SHOULD" be queried > > first; perhaps someone can point to the section and paragraph they > > think says that.) > > My own read of the accumulated data to date (which I don't assert is the > consensus view, though it might be) is that most implementations query SPF > and then TXT, or query them approximately simultaneously; meanwhile, most > SPF records that exist are of type TXT. This at least lends support to > advocating a client optimization that takes advantage of this, perhaps in > an informative statement. We are, after all, basing this advancement on > interoperability experience gained in the last six years. I think the > charter permits that. > > One could also acknowledge that that's just how things appear today, and > there could be some shift in the direction of publishing type SPF records > for some reason as this work and related work evolve. But that's pretty > hard to predict. This is why I suggest specifying the query most likely to succeed be done first if they are done is series. Today that would clearly be the TXT query, but it is not impossible that this would change in the future. Scott K From spf2@kitterman.com Fri Feb 24 14:50:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F7421F8599 for ; Fri, 24 Feb 2012 14:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qoyQItGrBT8 for ; Fri, 24 Feb 2012 14:50:52 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id F178521F8597 for ; Fri, 24 Feb 2012 14:50:50 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8B5F420E40CC; Fri, 24 Feb 2012 17:50:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330123850; bh=n7nU6ujqUDhPFhwXZ4KLK5K3+bGWRYevfzitUoWJdEI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=BwldVaOKgag7b2g9to2gG+FbzgxY1HpJh78tUhfSdh7OHYNop12YVe4vH2VbC4i7r eBXq6P4trHMeRL7vGieTBf2Tpsg0TrGm/C5dW4Swt99lLAH4ypb40gSvfIbhduk5we A25AMd2bfq/LEZ11tZLuJwlFA9yx/B5go+PZxXbs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7F8A820E4083; Fri, 24 Feb 2012 17:50:50 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 24 Feb 2012 17:50:50 -0500 Message-ID: <6522791.5cKdp8k4Kv@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E003928045579@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F47FF34.9020808@Commerco.Net> <9452079D1A51524AA5749AD23E003928045579@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 22:50:55 -0000 On Friday, February 24, 2012 09:24:09 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Commerco WebMaster Sent: Friday, February 24, 2012 1:21 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE > > (issue #9) > > > > Operationally, I think that keeping the TXT and SPF RRs in sync is not > > really all that hard to do. > > This brings up an interesting question: Although we (as experienced folk) > find doing so operationally easy, there are examples of cases where this > isn't done. It is of course hard to determine whether those operators did > so intentionally. Nevertheless, we might think it's hard, but maybe the > layperson disagrees. The question, then, is how that should influence what > we produce here. It depends on the goal of the working group. Do we want something that's architecturally pure or something that can reasonably be deployed at internet scale? Scott K From ajs@anvilwalrusden.com Fri Feb 24 14:57:29 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AD021F8683 for ; Fri, 24 Feb 2012 14:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 TpuTxCtoItCc for ; Fri, 24 Feb 2012 14:57:29 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 19E0D21F8681 for ; Fri, 24 Feb 2012 14:57:29 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 66E901ECB41D for ; Fri, 24 Feb 2012 22:57:28 +0000 (UTC) Date: Fri, 24 Feb 2012 17:57:26 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120224225726.GF48576@mail.yitter.info> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <11274811.MESzFagJMh@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11274811.MESzFagJMh@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 22:57:29 -0000 On Fri, Feb 24, 2012 at 05:47:27PM -0500, Scott Kitterman wrote: > there's no point in a second query for Type SPF. Domains that don't > publish Type TXT won't be publishing Type SPF, so to expend remote > resources to respond to such pointless queries borders on abusive. As a matter of clarification: by "won't be publishing", do you mean to be predicting the future, to be claiming what they do now (which seems to be the evidence we have), or to be claiming what they ought to do? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Fri Feb 24 15:00:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA5921E8010 for ; Fri, 24 Feb 2012 15:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUSEtDgtrJk5 for ; Fri, 24 Feb 2012 15:00:03 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E8F3121E800E for ; Fri, 24 Feb 2012 15:00:02 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7EDAF20E40DA; Fri, 24 Feb 2012 18:00:02 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330124402; bh=ZekewRobsInjYkO7j+Y6UH7VdRV5g3QAmScdcSE2qPI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=LwYTkLcU96seaJbP0AFUWl2oJkbxGorBxGS0uy32G4LA8lJaaQx4BWIMeioBYKTlf K1sqOVecq068yPDlj/rTRxl76EXKCzcHYAuj64x1ZovbS14O0ggGM/DYskdcEDj/Jv XvKiGSAGMpz8lkyuI8HO+GZWtbmSzwpjiUltZXzc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5D79520E40CC; Fri, 24 Feb 2012 18:00:02 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 24 Feb 2012 18:00 -0500 Message-ID: <3578180.tTUURtAZYA@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120224225726.GF48576@mail.yitter.info> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <11274811.MESzFagJMh@scott-latitude-e6320> <20120224225726.GF48576@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 23:00:03 -0000 On Friday, February 24, 2012 05:57:26 PM Andrew Sullivan wrote: > On Fri, Feb 24, 2012 at 05:47:27PM -0500, Scott Kitterman wrote: > > there's no point in a second query for Type SPF. Domains that don't > > publish Type TXT won't be publishing Type SPF, so to expend remote > > resources to respond to such pointless queries borders on abusive. > > As a matter of clarification: by "won't be publishing", do you mean to > be predicting the future, to be claiming what they do now (which seems > to be the evidence we have), or to be claiming what they ought to do? I'm trying to describe present practive. There's zero value in a Type SPF query after a Type TXT query. Scott K From pmidge@microsoft.com Fri Feb 24 15:27:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579CC21F85CF for ; Fri, 24 Feb 2012 15:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.324 X-Spam-Level: X-Spam-Status: No, score=-4.324 tagged_above=-999 required=5 tests=[AWL=-0.725, 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 Pr4NXnGcqdKT for ; Fri, 24 Feb 2012 15:27:18 -0800 (PST) Received: from VA3EHSOBE010.bigfish.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7473821F85C9 for ; Fri, 24 Feb 2012 15:27:18 -0800 (PST) Received: from mail132-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Fri, 24 Feb 2012 23:27:17 +0000 Received: from mail132-va3 (localhost [127.0.0.1]) by mail132-va3-R.bigfish.com (Postfix) with ESMTP id C589A1604D8; Fri, 24 Feb 2012 23:27:17 +0000 (UTC) X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail132-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail132-va3 (localhost.localdomain [127.0.0.1]) by mail132-va3 (MessageSwitch) id 1330126037308166_4016; Fri, 24 Feb 2012 23:27:17 +0000 (UTC) Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.248]) by mail132-va3.bigfish.com (Postfix) with ESMTP id 3BBD2140046; Fri, 24 Feb 2012 23:27:17 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 24 Feb 2012 23:27:16 +0000 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.110]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0247.005; Fri, 24 Feb 2012 23:27:14 +0000 From: Paul Midgen To: S Moonesamy , "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM8y1RU7YMwN3alUeqUtF92kjEk5ZMrTuw Date: Fri, 24 Feb 2012 23:27:13 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "spfbis-chairs@tools.ietf.org" Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 23:27:19 -0000 If I take the meaning of "unused features" to be applied to an aspect of SP= F that does not factor materially into the successful daily operation of SP= F, having had 6+ years to establish such a presence, a preliminary survey o= f 1000 domains randomly chosen from Hotmail's SPF record cache does not fin= d a single DNS type 99 record. In the interest of being thorough, I'm running three tests: - two sets of 10,000 domains chosen at random from a Sept'11 snapshot of th= e SenderID cache, and one from today's snapshot - the top 10,000 domains by sending volume as seen by Hotmail today Where the test consists of identifying which domains publish TXT, SPF, or b= oth. It should be done by Monday (I have to fly under the radar or corp IT = will boot me off the network). Regardless of software support for querying type 99 records, if they aren't= published I have a hard time qualifying the feature as "used". -p -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= S Moonesamy Sent: Friday, February 24, 2012 11:48 AM To: spfbis@ietf.org Cc: spfbis-chairs@tools.ietf.org Subject: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Hello, Empirical evidence so far seems to indicate that there is a significant amo= unt of DNS queries for the SPF RR (TYPE 99) and some sites publish it. We = have seen arguments in favour of removing the feature, and in favour of ret= aining it. Our charter says this: Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language. Therefore, the WG Chairs would like to close Issue #9 with the conclusion t= hat the SPFBIS WG does not have consensus to remove the feature. Objections to this determination of consensus need to produce evidence that= the feature is not used, or that the removal of TYPE 99 is an enhancement = that has already gained widespread support. Please remember that the desir= ability of the removal of the feature is not enough: the charter restricts our freedom to do what we want here. Best regards, Andrew Sullivan & S. Moonesamy, SPFBIS WG Chairs _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From hsantos@isdg.net Fri Feb 24 15:51:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1903D21F8679 for ; Fri, 24 Feb 2012 15:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.429, 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 PvdpqUzaWBUQ for ; Fri, 24 Feb 2012 15:51:37 -0800 (PST) Received: from mail.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CC60721F84B5 for ; Fri, 24 Feb 2012 15:51:26 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4095; t=1330127484; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ty7hZ2LqUHNpy7eu1XQ3G2a6Mwk=; b=pcZdpfap7rk/iyZpTMN7 U+9FUU6ynol3HxyV8WkLlIq2WfpnY6eYcRWqpgGsjNRucTy3JKPEps3pjHjTiOOe wGTY4DoNebOFXNxXs/TuzdSUUQNqYLjAZ5ozy4d7MLy2ER9ZVrYifzzdiQDTJm4U T/l6+PRngePTExWvEzF10vc= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 24 Feb 2012 18:51:24 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3329327273.90415.5148; Fri, 24 Feb 2012 18:51:24 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4095; t=1330127241; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=7NXM7g6 nWgm4/w/hiEtyi1P3h98aQylRPSMhgZ9IZ8E=; b=bNo/TyUlv1RO6+QuGYpP+dz 8aECCAvTaJ6Y5dRAKUQYCuPO1ompTDCJupKOtqlsiyQhwxezTZJickHiZ77ph75F a3Hb0e1Rt/nO5Z7NKwu4Ex6RQvIW4Dm8SkhAUzR/LmcvIrLmjymFA9uDDkx+TciT 4HyzB6yYLribiI9szYpk= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 24 Feb 2012 18:47:21 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3928264298.19182.3080; Fri, 24 Feb 2012 18:47:20 -0500 Message-ID: <4F482262.2080802@isdg.net> Date: Fri, 24 Feb 2012 18:50:58 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Paul Midgen References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , "spfbis-chairs@tools.ietf.org" , S Moonesamy Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Feb 2012 23:51:39 -0000 A major point missing is that there was a period where it wasn't feasible to do type 99, not because their not be a record behind it, but simply because it just won't get through! See RFC3597. This issue was well known and guess what? Microsoft was a major part of volume of servers that did not support SRV, IXFR needed for AD or any new RR types in DNS 4.0. AD would not taken off until DNS 5.0 came and people started to migrate it. Ask any of the MVP for DNS/AD like Ace Fekay about it. Even if we wanted to use SPF type with SPF published records, it just wouldn't work - period. What I am missing here? Not until DNS servers updated would it can conceivable to work, and in the Windows world people needed to move from DNS 4.0 to 5.0 and even then, nor SRV or AD force the issue until one of the past infamous port 445 DoS attacks occurred and with no MS answer for 4.0, only then did you many DNS 4.0 operators, perhaps reluctantly, finally make the switch - I was one of them. No DoS. No Switch. But after the switch, only then was it possible to consider AD, XMPP installation worked better now. Only then did the ideas of once again exploring new protocols with SRV and other types did it become more feasible to consider. If it wasn't for the DoS, I just guessing, we might be having a different set of events here. :) Paul Midgen wrote: > If I take the meaning of "unused features" to be applied to an aspect of SPF that does not factor materially into the successful daily operation of SPF, having had 6+ years to establish such a presence, a preliminary survey of 1000 domains randomly chosen from Hotmail's SPF record cache does not find a single DNS type 99 record. > > In the interest of being thorough, I'm running three tests: > > - two sets of 10,000 domains chosen at random from a Sept'11 snapshot of the SenderID cache, and one from today's snapshot > > - the top 10,000 domains by sending volume as seen by Hotmail today > > Where the test consists of identifying which domains publish TXT, SPF, or both. It should be done by Monday (I have to fly under the radar or corp IT will boot me off the network). > > Regardless of software support for querying type 99 records, if they aren't published I have a hard time qualifying the feature as "used". > > -p > > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of S Moonesamy > Sent: Friday, February 24, 2012 11:48 AM > To: spfbis@ietf.org > Cc: spfbis-chairs@tools.ietf.org > Subject: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) > > Hello, > > Empirical evidence so far seems to indicate that there is a significant amount of DNS queries for the SPF RR (TYPE 99) and some sites publish it. We have seen arguments in favour of removing the feature, and in favour of retaining it. > > Our charter says this: > > Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any enhancements > that have already gained widespread support, and addition of > clarifying language. > > Therefore, the WG Chairs would like to close Issue #9 with the conclusion that the SPFBIS WG does not have consensus to remove the feature. > > Objections to this determination of consensus need to produce evidence that the feature is not used, or that the removal of TYPE 99 is an enhancement that has already gained widespread support. Please remember that the desirability of the removal of the feature is not > enough: the charter restricts our freedom to do what we want here. > > Best regards, > Andrew Sullivan & S. Moonesamy, SPFBIS WG 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 > > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From pmidge@microsoft.com Fri Feb 24 16:42:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD09521E8027 for ; Fri, 24 Feb 2012 16:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.268 X-Spam-Level: X-Spam-Status: No, score=-4.268 tagged_above=-999 required=5 tests=[AWL=-0.669, 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 ZE1aI9U+-dj7 for ; Fri, 24 Feb 2012 16:42:26 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 96D1821E8021 for ; Fri, 24 Feb 2012 16:42:26 -0800 (PST) Received: from mail197-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Sat, 25 Feb 2012 00:42:26 +0000 Received: from mail197-ch1 (localhost [127.0.0.1]) by mail197-ch1-R.bigfish.com (Postfix) with ESMTP id 2050D120576; Sat, 25 Feb 2012 00:42:26 +0000 (UTC) X-SpamScore: -35 X-BigFish: VS-35(zz9371I542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h93fh) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail197-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail197-ch1 (localhost.localdomain [127.0.0.1]) by mail197-ch1 (MessageSwitch) id 1330130544467423_21633; Sat, 25 Feb 2012 00:42:24 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail197-ch1.bigfish.com (Postfix) with ESMTP id 6DE02460045; Sat, 25 Feb 2012 00:42:24 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 25 Feb 2012 00:42:23 +0000 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.110]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0247.005; Sat, 25 Feb 2012 00:42:22 +0000 From: Paul Midgen To: Hector Santos Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM8y1RU7YMwN3alUeqUtF92kjEk5ZMrTuwgAAKuQCAAAndMA== Date: Sat, 25 Feb 2012 00:42:21 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204B65C2@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> <4F482262.2080802@isdg.net> In-Reply-To: <4F482262.2080802@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "spfbis@ietf.org" , "spfbis-chairs@tools.ietf.org" , S Moonesamy Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 00:42:27 -0000 VGhlIHNhbGllbnQgcG9pbnQgaXMgdGhhdCBsYWNraW5nIHdpZGVzcHJlYWQgY3VzdG9tZXIgZGVt YW5kLCBzb21lIGVudGVycHJpc2Ugc29mdHdhcmUgdmVuZG9ycyB3aWxsIG5vdCBpbXBsZW1lbnQg YSB0aGluZy4gVGhhdCBpcyBjb3JyZWN0LCBidXQgdGhhdCBpc24ndCB0aGUgcG9pbnQuDQoNCklm IHRoZSBmZWF0dXJlIGlzIHRydWx5IHVudXNlZCwgaXQgbWF5IHN0aWxsIG1ha2Ugc2Vuc2UgdG8g aW5jbHVkZSBhIHByb3Zpc2lvbiBmb3IgYSBwcm9wZXIgU1BGIHJlY29yZCBiZWNhdXNlIGl0IGlz IGFyY2hpdGVjdHVyYWxseSBjb3JyZWN0L3JpZ2h0L3Jlc3BvbnNpYmxlIHRvIGRvIHNvLCBhbmQg dGhhdCB3aWxsIGltcGx5IHRoZSBuZWVkIGZvciBsYW5ndWFnZSBpbiB0aGUgc3BlYyByZWZsZWN0 aW5nIHRoZSBXR3Mgb3BpbmlvbiBvbiB0aGUgbWF0dGVyLCBob3cgdG8gcHJvcGVybHkgcXVlcnkg Ym90aCB0eXBlcywgYW5kIHNvIG9uLg0KDQpCeSBteSBwcm9mZmVyZWQgZGVmaW5pdGlvbiBvZiAi dW51c2VkIiwgdGhlIGRhdGEgSSd2ZSBzZWVuIHNvIGZhciBkb2Vzbid0IHN1cHBvcnQgaW5jbHVz aW9uLiBJIGxlYXZlIGl0IHRvIHRob3NlIHdpdGggbW9yZSBleHBlcmllbmNlL3N1YmplY3QgbWF0 dGVyIGV4cGVydGlzZSB0byBtYWtlIHRoZSBhcHByb3ByaWF0ZSBhcmNoaXRlY3R1cmUgKEROUywg aW50ZXJuZXQsIGV0Yy4pIGJhc2VkIGNhbGwuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBIZWN0b3IgU2FudG9zIFttYWlsdG86aHNhbnRvc0Bpc2RnLm5ldF0gDQpTZW50OiBG cmlkYXksIEZlYnJ1YXJ5IDI0LCAyMDEyIDM6NTEgUE0NClRvOiBQYXVsIE1pZGdlbg0KQ2M6IFMg TW9vbmVzYW15OyBzcGZiaXNAaWV0Zi5vcmc7IHNwZmJpcy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbc3BmYmlzXSBDYWxsIGZvciBpbnRlcm1lZGlhdGUgY29uc2Vuc3VzIG9u IFNQRiBSUlRZUEUgKGlzc3VlICM5KQ0KDQpBIG1ham9yIHBvaW50IG1pc3NpbmcgaXMgdGhhdCB0 aGVyZSB3YXMgYSBwZXJpb2Qgd2hlcmUgaXQgd2Fzbid0IGZlYXNpYmxlIHRvIGRvIHR5cGUgOTks IG5vdCBiZWNhdXNlIHRoZWlyIG5vdCBiZSBhIHJlY29yZCBiZWhpbmQgaXQsIGJ1dCBzaW1wbHkg YmVjYXVzZSBpdCBqdXN0IHdvbid0IGdldCB0aHJvdWdoIQ0KDQpTZWUgUkZDMzU5Ny4gIFRoaXMg aXNzdWUgd2FzIHdlbGwga25vd24gYW5kIGd1ZXNzIHdoYXQ/IE1pY3Jvc29mdCB3YXMgYSBtYWpv ciBwYXJ0IG9mIHZvbHVtZSBvZiBzZXJ2ZXJzIHRoYXQgZGlkIG5vdCBzdXBwb3J0IFNSViwgSVhG UiBuZWVkZWQgZm9yIEFEIG9yIGFueSBuZXcgUlIgdHlwZXMgaW4gRE5TIDQuMC4gIEFEIHdvdWxk IG5vdCB0YWtlbiBvZmYgdW50aWwgRE5TIDUuMCBjYW1lIGFuZCBwZW9wbGUgc3RhcnRlZCB0byBt aWdyYXRlIGl0LiAgQXNrIGFueSBvZiB0aGUgTVZQIGZvciBETlMvQUQgbGlrZSBBY2UgRmVrYXkg YWJvdXQgaXQuDQoNCkV2ZW4gaWYgd2Ugd2FudGVkIHRvIHVzZSBTUEYgdHlwZSB3aXRoIFNQRiBw dWJsaXNoZWQgcmVjb3JkcywgaXQganVzdCB3b3VsZG4ndCB3b3JrIC0gcGVyaW9kLiBXaGF0IEkg YW0gbWlzc2luZyBoZXJlPw0KDQpOb3QgdW50aWwgRE5TIHNlcnZlcnMgdXBkYXRlZCB3b3VsZCBp dCBjYW4gY29uY2VpdmFibGUgdG8gd29yaywgYW5kIGluIHRoZSBXaW5kb3dzIHdvcmxkIHBlb3Bs ZSBuZWVkZWQgdG8gbW92ZSBmcm9tIEROUyA0LjAgdG8gNS4wIGFuZCBldmVuIHRoZW4sIG5vciBT UlYgb3IgQUQgZm9yY2UgdGhlIGlzc3VlIHVudGlsIG9uZSBvZiB0aGUgcGFzdCBpbmZhbW91cyBw b3J0IDQ0NSBEb1MgYXR0YWNrcyBvY2N1cnJlZCBhbmQgd2l0aCBubyBNUyBhbnN3ZXIgZm9yIDQu MCwgb25seSB0aGVuIGRpZCB5b3UgbWFueSBETlMgNC4wIG9wZXJhdG9ycywgcGVyaGFwcyByZWx1 Y3RhbnRseSwgZmluYWxseSBtYWtlIHRoZSBzd2l0Y2ggLSBJIHdhcyBvbmUgb2YgdGhlbS4gTm8g RG9TLiBObyBTd2l0Y2guDQoNCkJ1dCBhZnRlciB0aGUgc3dpdGNoLCBvbmx5IHRoZW4gd2FzIGl0 IHBvc3NpYmxlIHRvIGNvbnNpZGVyIEFELCBYTVBQIGluc3RhbGxhdGlvbiB3b3JrZWQgYmV0dGVy IG5vdy4gT25seSB0aGVuIGRpZCB0aGUgaWRlYXMgb2Ygb25jZSBhZ2FpbiBleHBsb3JpbmcgbmV3 IHByb3RvY29scyB3aXRoIFNSViBhbmQgb3RoZXIgdHlwZXMgZGlkIGl0IGJlY29tZSBtb3JlIGZl YXNpYmxlIHRvIGNvbnNpZGVyLg0KDQpJZiBpdCB3YXNuJ3QgZm9yIHRoZSBEb1MsIEkganVzdCBn dWVzc2luZywgd2UgbWlnaHQgYmUgaGF2aW5nIGEgZGlmZmVyZW50IHNldCBvZiBldmVudHMgaGVy ZS4gOikNCg0KDQpQYXVsIE1pZGdlbiB3cm90ZToNCj4gSWYgSSB0YWtlIHRoZSBtZWFuaW5nIG9m ICJ1bnVzZWQgZmVhdHVyZXMiIHRvIGJlIGFwcGxpZWQgdG8gYW4gYXNwZWN0IG9mIFNQRiB0aGF0 IGRvZXMgbm90IGZhY3RvciBtYXRlcmlhbGx5IGludG8gdGhlIHN1Y2Nlc3NmdWwgZGFpbHkgb3Bl cmF0aW9uIG9mIFNQRiwgaGF2aW5nIGhhZCA2KyB5ZWFycyB0byBlc3RhYmxpc2ggc3VjaCBhIHBy ZXNlbmNlLCBhIHByZWxpbWluYXJ5IHN1cnZleSBvZiAxMDAwIGRvbWFpbnMgcmFuZG9tbHkgY2hv c2VuIGZyb20gSG90bWFpbCdzIFNQRiByZWNvcmQgY2FjaGUgZG9lcyBub3QgZmluZCBhIHNpbmds ZSBETlMgdHlwZSA5OSByZWNvcmQuDQo+IA0KPiBJbiB0aGUgaW50ZXJlc3Qgb2YgYmVpbmcgdGhv cm91Z2gsIEknbSBydW5uaW5nIHRocmVlIHRlc3RzOg0KPiANCj4gLSB0d28gc2V0cyBvZiAxMCww MDAgZG9tYWlucyBjaG9zZW4gYXQgcmFuZG9tIGZyb20gYSBTZXB0JzExIHNuYXBzaG90IG9mIHRo ZSBTZW5kZXJJRCBjYWNoZSwgYW5kIG9uZSBmcm9tIHRvZGF5J3Mgc25hcHNob3QNCj4gDQo+IC0g dGhlIHRvcCAxMCwwMDAgZG9tYWlucyBieSBzZW5kaW5nIHZvbHVtZSBhcyBzZWVuIGJ5IEhvdG1h aWwgdG9kYXkNCj4gDQo+IFdoZXJlIHRoZSB0ZXN0IGNvbnNpc3RzIG9mIGlkZW50aWZ5aW5nIHdo aWNoIGRvbWFpbnMgcHVibGlzaCBUWFQsIFNQRiwgb3IgYm90aC4gSXQgc2hvdWxkIGJlIGRvbmUg YnkgTW9uZGF5IChJIGhhdmUgdG8gZmx5IHVuZGVyIHRoZSByYWRhciBvciBjb3JwIElUIHdpbGwg Ym9vdCBtZSBvZmYgdGhlIG5ldHdvcmspLg0KPiANCj4gUmVnYXJkbGVzcyBvZiBzb2Z0d2FyZSBz dXBwb3J0IGZvciBxdWVyeWluZyB0eXBlIDk5IHJlY29yZHMsIGlmIHRoZXkgYXJlbid0IHB1Ymxp c2hlZCBJIGhhdmUgYSBoYXJkIHRpbWUgcXVhbGlmeWluZyB0aGUgZmVhdHVyZSBhcyAidXNlZCIu DQo+IA0KPiAtcA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc3Bm YmlzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzcGZiaXMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFMgTW9vbmVzYW15DQo+IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjQsIDIwMTIg MTE6NDggQU0NCj4gVG86IHNwZmJpc0BpZXRmLm9yZw0KPiBDYzogc3BmYmlzLWNoYWlyc0B0b29s cy5pZXRmLm9yZw0KPiBTdWJqZWN0OiBbc3BmYmlzXSBDYWxsIGZvciBpbnRlcm1lZGlhdGUgY29u c2Vuc3VzIG9uIFNQRiBSUlRZUEUgKGlzc3VlICM5KQ0KPiANCj4gSGVsbG8sDQo+IA0KPiBFbXBp cmljYWwgZXZpZGVuY2Ugc28gZmFyIHNlZW1zIHRvIGluZGljYXRlIHRoYXQgdGhlcmUgaXMgYSBz aWduaWZpY2FudCBhbW91bnQgb2YgRE5TIHF1ZXJpZXMgZm9yIHRoZSBTUEYgUlIgKFRZUEUgOTkp IGFuZCBzb21lIHNpdGVzIHB1Ymxpc2ggaXQuICBXZSBoYXZlIHNlZW4gYXJndW1lbnRzIGluIGZh dm91ciBvZiByZW1vdmluZyB0aGUgZmVhdHVyZSwgYW5kIGluIGZhdm91ciBvZiByZXRhaW5pbmcg aXQuDQo+IA0KPiBPdXIgY2hhcnRlciBzYXlzIHRoaXM6DQo+IA0KPiAgICAgICAgQ2hhbmdlcyB0 byB0aGUgU1BGIHNwZWNpZmljYXRpb24gd2lsbCBiZSBsaW1pdGVkIHRvIHRoZSBjb3JyZWN0aW9u DQo+ICAgICAgICBvZiBlcnJvcnMsIHJlbW92YWwgb2YgdW51c2VkIGZlYXR1cmVzLCBhZGRpdGlv biBvZiBhbnkgZW5oYW5jZW1lbnRzDQo+ICAgICAgICB0aGF0IGhhdmUgYWxyZWFkeSBnYWluZWQg d2lkZXNwcmVhZCBzdXBwb3J0LCBhbmQgYWRkaXRpb24gb2YNCj4gICAgICAgIGNsYXJpZnlpbmcg bGFuZ3VhZ2UuDQo+IA0KPiBUaGVyZWZvcmUsIHRoZSBXRyBDaGFpcnMgd291bGQgbGlrZSB0byBj bG9zZSBJc3N1ZSAjOSB3aXRoIHRoZSBjb25jbHVzaW9uIHRoYXQgdGhlIFNQRkJJUyBXRyBkb2Vz IG5vdCBoYXZlIGNvbnNlbnN1cyB0byByZW1vdmUgdGhlIGZlYXR1cmUuDQo+IA0KPiBPYmplY3Rp b25zIHRvIHRoaXMgZGV0ZXJtaW5hdGlvbiBvZiBjb25zZW5zdXMgbmVlZCB0byBwcm9kdWNlIGV2 aWRlbmNlIHRoYXQgdGhlIGZlYXR1cmUgaXMgbm90IHVzZWQsIG9yIHRoYXQgdGhlIHJlbW92YWwg b2YgVFlQRSA5OSBpcyBhbiBlbmhhbmNlbWVudCB0aGF0IGhhcyBhbHJlYWR5IGdhaW5lZCB3aWRl c3ByZWFkIHN1cHBvcnQuICBQbGVhc2UgcmVtZW1iZXIgdGhhdCB0aGUgZGVzaXJhYmlsaXR5IG9m IHRoZSByZW1vdmFsIG9mIHRoZSBmZWF0dXJlIGlzIG5vdA0KPiBlbm91Z2g6IHRoZSBjaGFydGVy IHJlc3RyaWN0cyBvdXIgZnJlZWRvbSB0byBkbyB3aGF0IHdlIHdhbnQgaGVyZS4NCj4gDQo+IEJl c3QgcmVnYXJkcywNCj4gQW5kcmV3IFN1bGxpdmFuICYgUy4gTW9vbmVzYW15LCBTUEZCSVMgV0cg Q2hhaXJzDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBzcGZiaXMgbWFpbGluZyBsaXN0DQo+IHNwZmJpc0BpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwZmJpcw0KPiANCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNwZmJpcyBtYWlsaW5n IGxpc3QNCj4gc3BmYmlzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc3BmYmlzDQo+IA0KPiANCg0KLS0gDQpIZWN0b3IgU2FudG9zLCBDVE8NCmh0dHA6 Ly93d3cuc2FudHJvbmljcy5jb20NCmh0dHA6Ly9zYW50cm9uaWNzLmJsb2dzcG90LmNvbQ0KDQoN Cg0K From pgladstone@cisco.com Fri Feb 24 16:54:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1186221F867F for ; Fri, 24 Feb 2012 16:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.866 X-Spam-Level: X-Spam-Status: No, score=-8.866 tagged_above=-999 required=5 tests=[AWL=1.133, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPvsTo4dLNhc for ; Fri, 24 Feb 2012 16:54:06 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6274821F867B for ; Fri, 24 Feb 2012 16:54:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=695; q=dns/txt; s=iport; t=1330131246; x=1331340846; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=4LW2q0cidbH3c/XgEpUxNowHs4V8PN0KwcJxFm2xxts=; b=eR+tB1f1SYgmNuCQ0KNNBSf9dEHLqgEiVj8SDCQw3S783SyYiwVNmywl F1oSJb1BthOa/z2wNpIv/AeawwUHLRaOxconkkHGa1uBdH93sMCYvXIX2 srxv4XY11DfGsTNNNmoBX0UXrlXim8et4GtUs2ca/jOtHYeJIXgvFEmpR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsHAAswSE+tJXG//2dsb2JhbABBA4MTgietZ4EHgXMBAQEEEgEKBhVPAgsYAgIFIQICDwIKPBMGAgEBHodkoFcBjGWKCgSBK4tcLA8EBQoDAwcDAgUCEAEKAgIDAQIChRwTAgILAgUGNQ8KBYIIgRYEiE+MbIVdjTA X-IronPort-AV: E=Sophos;i="4.73,479,1325462400"; d="scan'208";a="61680922" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 25 Feb 2012 00:54:06 +0000 Received: from [10.117.107.24] (rtp-pgladsto-8917.cisco.com [10.117.107.24]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1P0s5lB004927 for ; Sat, 25 Feb 2012 00:54:05 GMT Message-ID: <4F48312D.80304@cisco.com> Date: Fri, 24 Feb 2012 19:54:05 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 00:54:07 -0000 On 2/24/2012 6:27 PM, Paul Midgen wrote: > > Where the test consists of identifying which domains publish TXT, SPF, = or both. It should be done by Monday (I have to fly under the radar or co= rp IT will boot me off the network). When I did my tests, I didn't fly under the corporate radar and I got=20 asked by our IT guys whether I was doing some DNS testing or whether my=20 machine was infected with malware (I was looking up records belonging to = malware C&C domains). Philip > > --=20 > Philip Gladstone > Distinguished Engineer > Product Development > pgladstone@cisco.com > Phone: +1 978-ZEN-TOAD (+1 978 936 8623) > Google: +1 978 800 1010 > Ham radio: N1DQ From hsantos@isdg.net Fri Feb 24 18:55:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496DD21E802B for ; Fri, 24 Feb 2012 18:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5zMsqCWvTVK for ; Fri, 24 Feb 2012 18:55:14 -0800 (PST) Received: from secure.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4A60521E8029 for ; Fri, 24 Feb 2012 18:55:13 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1780; t=1330138505; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=It85bTpopDnUA41dLdKX4pot9nc=; b=tGRDiOaFesNqgoWlNEsZ OAgFl02PKx6VCd3hU4fjJoLokstCD2AejQmlWPwUOUWLmB7Bfwz42ap2Y5vWVuuh O2GBABfrFSeKzg1cN1PPABv9u4CZbvfgu6fZUjOxv4XCA4/cyNF4hc50KAklbxpG fT2LFqBts3Gr3FT4eJ65wEk= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 24 Feb 2012 21:55:05 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3340347668.90415.3544; Fri, 24 Feb 2012 21:55:04 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1780; t=1330138258; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=aaivNqQ GEL156d+pjZ3Us0MkvLv1ZGsyTB3OS00NKFE=; b=Qryil+TENblOKTORSH/jvOS mbytNPCz4uwaXHSgfSzJuZiQL4+2YVABWYaaYeSFfvhx34gCMZ0ezgQfsA8XzsLS 7OHe7rZf7YGXzbewP445sYfiOBtohDUL8N65pLVPyZW5rot7qPJoF1OaaAKTG5PR E4ajTGSpQMDoRZh5TqA0= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 24 Feb 2012 21:50:58 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3939280626.19203.4508; Fri, 24 Feb 2012 21:50:57 -0500 Message-ID: <4F484D6C.9080802@isdg.net> Date: Fri, 24 Feb 2012 21:54:36 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Paul Midgen References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> <4F482262.2080802@isdg.net> <7F7F36E50398F84DBAF25C9D51732F1E204B65C2@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E204B65C2@TK5EX14MBXC203.redmond.corp.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , "spfbis-chairs@tools.ietf.org" , S Moonesamy Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 02:55:15 -0000 Paul Midgen wrote: > The salient point is that lacking widespread customer demand, some enterprise software vendors will not implement a thing. That is correct, but that isn't the point. > > If the feature is truly unused, it may still make sense to include a provision for a proper SPF record because it is architecturally correct/right/responsible to do so, and that will imply the need for language in the spec reflecting the WGs opinion on the matter, how to properly query both types, and so on. > > By my proffered definition of "unused", the data I've seen so far doesn't support inclusion. I leave it to those with more experience/subject matter expertise to make the appropriate architecture (DNS, internet, etc.) based call. That would be pretty much be all of us. The infrastructure based call was made to help lower the impact SPF received may have by using TXT records by using its own RR record. All the short term hiccups were acknowledged and long term engineering considerations were made. All done in the name of improvement its implications on DNS, and I don't mind saying, to help win IETF endorsement where there was and probably still is much resistance with whats considered a "Kludge" solution. So all the engineering was considered and what we are finding out now, we were right on. So I have a sense that if we negate all these infrastructure goals by dropping type 99, I somehow feel we are not doing SPF a service come the IETF/IESG reviews and endorsement among the DNS community. I don't know, how to read these guys these days. People change, more empathetic, settle on thing and may just feel - don't break what seems to be working. :) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From msk@cloudmark.com Fri Feb 24 19:28:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507F621E8015 for ; Fri, 24 Feb 2012 19:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 FopqL-EsH5CP for ; Fri, 24 Feb 2012 19:28:55 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id CF92111E8072 for ; Fri, 24 Feb 2012 19:28:55 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 19:28:55 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM8y1W2VNI8D1siUmvUKuKkD2KZZZNN26AgAAGogCAAA5cgIAAJPMA//+BPjA= Date: Sat, 25 Feb 2012 03:28:54 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928045DBF@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> <4F482262.2080802@isdg.net> <7F7F36E50398F84DBAF25C9D51732F1E204B65C2@TK5EX14MBXC203.redmond.corp.microsoft.com> <4F484D6C.9080802@isdg.net> In-Reply-To: <4F484D6C.9080802@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 03:28:56 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Hector Santos > Sent: Friday, February 24, 2012 6:55 PM > To: Paul Midgen > Cc: spfbis@ietf.org; spfbis-chairs@tools.ietf.org; S Moonesamy > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issu= e #9) >=20 > > By my proffered definition of "unused", the data I've seen so far > > doesn't support inclusion. I leave it to those with more > > experience/subject matter expertise to make the appropriate > > architecture (DNS, internet, etc.) based call. >=20 > That would be pretty much be all of us. I'm sorry, but this is two things: false and rude. Let's all take a moment to re-read the co-chairs' "comportment" message, pl= ease. -MSK From msk@cloudmark.com Fri Feb 24 19:30:14 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C02A21E8015 for ; Fri, 24 Feb 2012 19:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0T9JBjKVcZi for ; Fri, 24 Feb 2012 19:30:13 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id B177311E8072 for ; Fri, 24 Feb 2012 19:30:13 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 19:30:13 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM8y1W2VNI8D1siUmvUKuKkD2KZZZNN26AgAAYRYD//6U4QA== Date: Sat, 25 Feb 2012 03:30:13 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928045DD7@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> <4F48312D.80304@cisco.com> In-Reply-To: <4F48312D.80304@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 03:30:14 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Philip Gladstone > Sent: Friday, February 24, 2012 4:54 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issu= e #9) >=20 > > Where the test consists of identifying which domains publish TXT, > > SPF, or both. It should be done by Monday (I have to fly under the > > radar or corp IT will boot me off the network). >=20 > When I did my tests, I didn't fly under the corporate radar and I got > asked by our IT guys whether I was doing some DNS testing or whether my > machine was infected with malware (I was looking up records belonging > to malware C&C domains). Funny; in running mine, I've noticed that after the first chunk of the test= space is run, it gets a lot slower. I wonder if somewhere upstream I'm be= ing DNS rate-limited. Slightly off-topic, I know, but curious that we all have the same issue. -MSK From hsantos@isdg.net Fri Feb 24 19:44:29 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02D421F84DA for ; Fri, 24 Feb 2012 19:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.427, 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 nHbvR+9fGSuv for ; Fri, 24 Feb 2012 19:44:29 -0800 (PST) Received: from secure.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEE021F84D9 for ; Fri, 24 Feb 2012 19:44:28 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1217; t=1330141460; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=eiGA+P+D3WS1RR2EshDszosU5y8=; b=B2t5+y3MACgIvrwVQL3x tCMbQyXTs9LmAPChPEYvguCF5FLsJSTzN4NlIKzLoGGlEX/3Bla997zDjM8Pjv53 sAObiJSbaUan99diUYpeiJ/dlzoOyidLI9YhoFbd4L8a0K3UIreDCT66A4sYsOPb nVEg1G+GklYjfo+k3Rr6jEk= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 24 Feb 2012 22:44:20 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3343302997.90415.4072; Fri, 24 Feb 2012 22:44:20 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1217; t=1330141217; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=4yYtDJQ zF/rcMZOi7xb+GyYsntmv7bmClyG1toXOoek=; b=3aZ2Vkjy61RQ7eKI7pdyesN aYFQplu0aaC6cwyAP6uA7S4vqRqwvpE6vEOCPSwD8fwWf4JciUOYkopdXkLeQCyU TQeylJVef2Y7xln1ho7bkSDAl3A3YKSgyKJPy1Yw/3NfCrtO/ljbE0ohw4bb46mC cHYa91yar5f4z+1RUI3I= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 24 Feb 2012 22:40:17 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3942239673.19213.7440; Fri, 24 Feb 2012 22:40:16 -0500 Message-ID: <4F4858FB.7020809@isdg.net> Date: Fri, 24 Feb 2012 22:43:55 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> <4F482262.2080802@isdg.net> <7F7F36E50398F84DBAF25C9D51732F1E204B65C2@TK5EX14MBXC203.redmond.corp.microsoft.com> <4F484D6C.9080802@isdg.net> <9452079D1A51524AA5749AD23E003928045DBF@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928045DBF@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 03:44:30 -0000 Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Hector Santos >> Sent: Friday, February 24, 2012 6:55 PM >> To: Paul Midgen >> Cc: spfbis@ietf.org; spfbis-chairs@tools.ietf.org; S Moonesamy >> Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) >> >>> By my proffered definition of "unused", the data I've seen so far >>> doesn't support inclusion. I leave it to those with more >>> experience/subject matter expertise to make the appropriate >>> architecture (DNS, internet, etc.) based call. >> That would be pretty much be all of us. > > I'm sorry, but this is two things: false and rude. > > Let's all take a moment to re-read the co-chairs' "comportment" message, please. Wow. I must completely stupid because I didn't think it was false nor rude. I really don't and I would like to hear it from people like Barry Leiba to explain to off list how I was rude. I seriously and honestly don't see how I was out of line with that. I am sorry to see that I continue to be a target of yours. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From msk@cloudmark.com Fri Feb 24 22:09:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA8221F8691 for ; Fri, 24 Feb 2012 22:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOdKi9jNzuDR for ; Fri, 24 Feb 2012 22:09:01 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8D86A21F860D for ; Fri, 24 Feb 2012 22:08:57 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 22:08:56 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM8y1W2VNI8D1siUmvUKuKkD2KZZZNN26A///pOdA= Date: Sat, 25 Feb 2012 06:08:56 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928045EAC@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 06:09:02 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Paul Midgen > Sent: Friday, February 24, 2012 3:27 PM > To: S Moonesamy; spfbis@ietf.org > Cc: spfbis-chairs@tools.ietf.org > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issu= e #9) >=20 > If I take the meaning of "unused features" to be applied to an aspect > of SPF that does not factor materially into the successful daily > operation of SPF, having had 6+ years to establish such a presence, a > preliminary survey of 1000 domains randomly chosen from Hotmail's SPF > record cache does not find a single DNS type 99 record. That sample size might be enough to avoid seeing any instances. The active= polling I'm doing has checked 29088 domains so far and found only 29 type = 99 records, so as luck would have it your ratio is approximately such that = one more might've found a single hit. :-) Can you characterize the cache at all in terms of size or duration caps? O= r is it basically a DNS cache? -MSK From msk@cloudmark.com Fri Feb 24 22:43:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878D021F8668 for ; Fri, 24 Feb 2012 22:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWuVpB-jkeub for ; Fri, 24 Feb 2012 22:43:22 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0503221F8666 for ; Fri, 24 Feb 2012 22:43:22 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 22:43:21 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM80aZcFfuy6syhEOYOOSUdospxpZNKctg Date: Sat, 25 Feb 2012 06:43:21 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928045EED@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <9452079D1A51524AA5749AD23E00392804555D@exch-mbx901.corp.cloudmark.com> <2130775.pmXu51Ebxp@scott-latitude-e6320> In-Reply-To: <2130775.pmXu51Ebxp@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 06:43:22 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Friday, February 24, 2012 2:50 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issu= e #9) >=20 > This is why I suggest specifying the query most likely to succeed be done= first > if they are done is series. Today that would clearly be the TXT query, b= ut it > is not impossible that this would change in the future. I'd prefer to see it removed. I agree with the idea of trying to advance a= cleaner specification, and removing something only half of the installed b= ase (and a very specific half at that) is using after all this time seems t= o me like it should qualify. However, if the ruling is that even client-only use of a feature "counts" i= n terms of being in use, or if in any case we don't have consensus to make = that change, then I think adding some good operational advice like this in = an appendix is a reasonable path forward on this issue. -MSK From msk@cloudmark.com Fri Feb 24 22:55:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9168821E803A for ; Fri, 24 Feb 2012 22:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19M1a0btSpwh for ; Fri, 24 Feb 2012 22:55:02 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id E3B8611E8072 for ; Fri, 24 Feb 2012 22:55:01 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 22:55:01 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: Garbage TXT records (more on Issue #9) Thread-Index: AczzimRbXvZLp2ugRO+Va8hUfVrmdg== Date: Sat, 25 Feb 2012 06:55:00 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928045F10@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E003928045F10exchmbx901corpclo_" MIME-Version: 1.0 Subject: [spfbis] Garbage TXT records (more on Issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 06:55:03 -0000 --_000_9452079D1A51524AA5749AD23E003928045F10exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While running some more query reports about deployed SPF records, I came ac= ross a few interesting cases. My favourite two examples are ut.edu and aar= online.com. Do a TXT query of both to see what I'm looking at. The ut.edu= one actually triggered truncation in my tests. So for the sake of discussion, let me toss out this straw man argument: An SPF client that queries SPF first and actually gets answers is far less = likely to need hardening against this kind of junk. It's thus less likely= to break. Therefore, enabling the isolation of SPF data into its own RRty= pe is actually beneficial, and so we should keep it and re-emphasize its va= lue. (Yes, I know it's easy to cycle through a TXT RRset and only extract stuff = that starts "v=3Dspf1". That doesn't mean everyone will get it right.) For another example, look at zagat.com. The Google Apps site ownership ver= ification record is one example of how TXT is overloaded for numerous purpo= ses for which SPF clients need to be prepared if they're querying TXT, but = would very unlikely be a concern for an SPF RRset. Again, just a straw man that might end up being useful when considering the= merits of the proposal to remove type 99 vs. keeping it. I don't know tha= t I agree with it. For that matter, is the fear of unsupported RRtypes that was obviously arou= nd six years ago still an issue today? Could we actually go the other way = and slap a SHOULD NOT on TXT records because support is now relatively avai= lable? -MSK --_000_9452079D1A51524AA5749AD23E003928045F10exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While running some more query reports about deployed= SPF records, I came across a few interesting cases.  My favourite two= examples are ut.edu and aaronline.com.  Do a TXT query of both to see= what I’m looking at.  The ut.edu one actually triggered truncation in my tests.

 

So for the sake of discussion, let me toss out this = straw man argument:

 

An SPF client that queries SPF first and actually ge= ts answers is far less likely to need hardening against this kind of junk.&= nbsp;  It’s thus less likely to break.  Therefore, enabling= the isolation of SPF data into its own RRtype is actually beneficial, and so we should keep it and re-emphasize its value.

 

(Yes, I know it’s easy to cycle through a TXT = RRset and only extract stuff that starts “v=3Dspf1”.  That= doesn’t mean everyone will get it right.)

 

For another example, look at zagat.com.  The Go= ogle Apps site ownership verification record is one example of how TXT is o= verloaded for numerous purposes for which SPF clients need to be prepared i= f they’re querying TXT, but would very unlikely be a concern for an SPF RRset.

 

Again, just a straw man that might end up being usef= ul when considering the merits of the proposal to remove type 99 vs. keepin= g it.  I don’t know that I agree with it.

 

For that matter, is the fear of unsupported RRtypes = that was obviously around six years ago still an issue today?  Could w= e actually go the other way and slap a SHOULD NOT on TXT records because su= pport is now relatively available?

 

-MSK

--_000_9452079D1A51524AA5749AD23E003928045F10exchmbx901corpclo_-- From spf2@kitterman.com Fri Feb 24 23:10:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62ABF21F8594 for ; Fri, 24 Feb 2012 23:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeX3NJGOfz43 for ; Fri, 24 Feb 2012 23:10:48 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B862421F85FD for ; Fri, 24 Feb 2012 23:10:47 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AEA4720E40CC; Sat, 25 Feb 2012 02:10:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330153840; bh=1GDyUeOwpjkOd2IqqeXonKl6WYVfLQ2LFtvl0dz+ZHw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=d6YxxkSrJT72Q8cqwDWgJuhjZg2Fyqra8Z6zsFBuZKLFmcfXes52xJUhQct7TSAqK Kjzcx/+ti0wfRQfY+ZS+zOWdLApS8jM8DVOgH5aMDjyThElGhRdtYGft9RrHcGTmbM dzgyIIUn5oNAsZqb574njiwGvIq0avDyB9WUpmpA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9523220E4043; Sat, 25 Feb 2012 02:10:40 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 25 Feb 2012 02:10:39 -0500 Message-ID: <1930336.MRkvvWfOum@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E003928045F10@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E003928045F10@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Garbage TXT records (more on Issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 07:10:51 -0000 On Saturday, February 25, 2012 06:55:00 AM Murray S. Kucherawy wrote: > While running some more query reports about deployed SPF records, I came > across a few interesting cases. My favourite two examples are ut.edu and > aaronline.com. Do a TXT query of both to see what I'm looking at. The > ut.edu one actually triggered truncation in my tests. I got SERVFAIL from aaronline.com. > So for the sake of discussion, let me toss out this straw man argument: > > An SPF client that queries SPF first and actually gets answers is far less > likely to need hardening against this kind of junk. It's thus less likely > to break. Therefore, enabling the isolation of SPF data into its own > RRtype is actually beneficial, and so we should keep it and re-emphasize > its value. Contrarywise, an SPF client that queries for TXT under any circumstances needs to be prepared to deal with it, so there's still no benefit. > (Yes, I know it's easy to cycle through a TXT RRset and only extract stuff > that starts "v=spf1". That doesn't mean everyone will get it right.) This isn't a new type of concern and I think it's safe to assume implementations can at least pick the right record. There are other ways that things that aren't valid SPF records can get published that would also apply to Type SPF (one of my favorites being the ones that have no spaces) so Type SPF really doesn't avoid anything. > For another example, look at zagat.com. The Google Apps site ownership > verification record is one example of how TXT is overloaded for numerous > purposes for which SPF clients need to be prepared if they're querying TXT, > but would very unlikely be a concern for an SPF RRset. That doesn't excuse an SPF client from having to do basic input validation on Type SPF record and it's trivial to do. > Again, just a straw man that might end up being useful when considering the > merits of the proposal to remove type 99 vs. keeping it. I don't know that > I agree with it. > > For that matter, is the fear of unsupported RRtypes that was obviously > around six years ago still an issue today? Could we actually go the other > way and slap a SHOULD NOT on TXT records because support is now relatively > available? Publishing Type SPF is fine for people that run their own DNS servers. I'm not aware of any commercial host that supports it. Given the chairs comments on WG scope, I think slapping a SHOULD NOT on something because we thing it might be a good idea is out of scope anyway. Scott K From johnl@iecc.com Fri Feb 24 23:21:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3487921F869A for ; Fri, 24 Feb 2012 23:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.021 X-Spam-Level: X-Spam-Status: No, score=-110.021 tagged_above=-999 required=5 tests=[AWL=1.178, 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 EV8NaT-eXYy0 for ; Fri, 24 Feb 2012 23:21:51 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB0121F8677 for ; Fri, 24 Feb 2012 23:21:38 -0800 (PST) Received: (qmail 81329 invoked from network); 25 Feb 2012 07:21:37 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Feb 2012 07:21:37 -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=4f488c01.xn--hew.k1202; i=johnl@user.iecc.com; bh=I4Zb31AfEERwnQPTggXUGDIOd/AbRW3vZ7U30unOtd0=; b=UENM+KWPV1V8/oAUZS2Rd2d5NA9gaow1xwfAoX5iFhdnwBv6UzQDHKy0NYwdNuwzHtD2pVb32Rbg/DxqiLoEo79QwYuIkVrKB4schBbyNOlywlz5D/uz7M8u3Z/eVZ7OQRS+SCBQYQogPjowWa11ytIi+6P2zBCFk/3xSmeRZgc= 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=4f488c01.xn--hew.k1202; olt=johnl@user.iecc.com; bh=I4Zb31AfEERwnQPTggXUGDIOd/AbRW3vZ7U30unOtd0=; b=RTyjJ3WzAU1O53MTWoeEioMwCeJ6OPzZwhZ3q6MqpGT0wMzdmJpz4FLIYiyMlrfx8wWM7/yu9PO+ybNj/qzkFXga7+nnph0hFQNc26MbufMKWB+8j0YcCupq/A9jJG7c+ty/exqZZAct1a9VOltTgBIXXv6h+X6H0UNcRlzropQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Feb 2012 07:21:15 -0000 Message-ID: <20120225072115.2228.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: spf2@kitterman.com Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 07:21:52 -0000 >Personally, I think Type SPF could be removed as a mistake, so I don't >think we are inherently limited by the charter. I agree. Looking at my logs, most queries for type SPF records come from a handful of large mail systems which also look for TXT, notably Yahoo and Godaddy. I see no evidence that anyone queries SPF who doesn't also query for TXT, either at the same time or or if the type 99 fails. We know of two bad things about type 99 records: they offer an opportunity to screw things up if somone's SPF and TXT records don't match, and for many clients they double the DNS traffic. We don't know of anything good about them in practice, since everyone has to publish TXT records anyway. My preference would be to deprecate them. You can publish them or query them if you really want, but our new advice is that you SHOULD just publish TXT and you SHOULD just query for TXT. R's, John From msk@cloudmark.com Fri Feb 24 23:24:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BEC21F869A for ; Fri, 24 Feb 2012 23:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 fDUtSlmLJFyr for ; Fri, 24 Feb 2012 23:24:17 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E59D521F8677 for ; Fri, 24 Feb 2012 23:24:16 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 23:24:16 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors Thread-Index: AQHM8Z1H6I5T9g0T0E20useE1cLBoZZKHlgAgAKXugCAAILC4A== Date: Sat, 25 Feb 2012 07:24:15 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928045F40@exch-mbx901.corp.cloudmark.com> References: <061.455654aa40583da61895c644f7120a55@tools.ietf.org> <6.2.5.6.2.20120222115949.08f70548@elandnews.com> <9452079D1A51524AA5749AD23E0039280417A3@exch-mbx901.corp.cloudmark.com> <1775995.RF6pGKfp5q@scott-latitude-e6320> In-Reply-To: <1775995.RF6pGKfp5q@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 07:24:18 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Friday, February 24, 2012 7:33 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors >=20 > My initial thought is to allow (but not require) receivers to track > SERVFAIL based temperrors and if they persist for more than $PERIOD > (let's start the bidding at 24 hours) then future consectutive SERVFAIL > responses for that domain MAY be considered permanent errors. > [...] Happy eyeballs aside, has anyone in the SPF community, or any similar appli= cation for that matter, tried something like this? Any results from which = we can learn? If so, it seems like we should consider adding some informative guidance ba= sed on experience. I contend that's within charter, because it's not chang= ing the specification itself, and is aimed at providing improved interopera= bility. If not, then perhaps the collected experience about this and the RR type di= scussion might be input to an applicability statement that someone writes s= omewhere down the road, either individually or after a re-charter. -MSK From spf2@kitterman.com Fri Feb 24 23:29:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E26521F86CB for ; Fri, 24 Feb 2012 23:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JY+lil3fzYBE for ; Fri, 24 Feb 2012 23:29:51 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2D521F86C5 for ; Fri, 24 Feb 2012 23:29:51 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id F212D20E40CC; Sat, 25 Feb 2012 02:29:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330154991; bh=NgGL7e66UsN0pRbRBNICQSO2IB3PUgXOid0MV5W0+hs=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=SucvTlJozJAOX4t/2ZizQtBIKkXXRsRP5CVQ4GQBCGqUVny63GdiwOjDn8Oj+sDwX 5D64w79lGNfiFVVbiy1zOhj1S+N3k9FLEAlkINFxMR+AyuxOomEeZDlkNK/oHvlt03 UBIcJmAVFLka/4OMwfL0cO7YGbd4K7CLh1RwHzz4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D3E6020E4043; Sat, 25 Feb 2012 02:29:50 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 25 Feb 2012 02:29:50 -0500 Message-ID: <1987882.xVSqvW7a1T@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E003928045F40@exch-mbx901.corp.cloudmark.com> References: <061.455654aa40583da61895c644f7120a55@tools.ietf.org> <1775995.RF6pGKfp5q@scott-latitude-e6320> <9452079D1A51524AA5749AD23E003928045F40@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 07:29:52 -0000 On Saturday, February 25, 2012 07:24:15 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Scott Kitterman Sent: Friday, February 24, 2012 7:33 AM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors > > > > My initial thought is to allow (but not require) receivers to track > > SERVFAIL based temperrors and if they persist for more than $PERIOD > > (let's start the bidding at 24 hours) then future consectutive SERVFAIL > > responses for that domain MAY be considered permanent errors. > > [...] > > Happy eyeballs aside, has anyone in the SPF community, or any similar > application for that matter, tried something like this? Any results from > which we can learn? > > If so, it seems like we should consider adding some informative guidance > based on experience. I contend that's within charter, because it's not > changing the specification itself, and is aimed at providing improved > interoperability. > > If not, then perhaps the collected experience about this and the RR type > discussion might be input to an applicability statement that someone writes > somewhere down the road, either individually or after a re-charter. I'm not aware of anyone trying it. I know I got complaints about emails being stuck in a mail queue for 5 days when I was doing defer on temperror. This seems like a reasonable way around that problem. Due to long term temperror the general view in the community was that we couldn't recommend defer on temperror. Up until this discussion, I thought the solution was treating SERVFAIL as a permanent error, but now I see that isn't a good idea, so I proposed this as a conceptually straightforward (if someone complex to implement) method for solving the problem. I can take a stab at code if it would help with getting it accepted. Scott K From johnl@iecc.com Fri Feb 24 23:54:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603D721F866D for ; Fri, 24 Feb 2012 23:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.017 X-Spam-Level: X-Spam-Status: No, score=-109.017 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, SARE_URI_EQUALS=1.666, URI_HEX=0.368, USER_IN_WHITELIST=-100, WEIRD_PORT=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 Px3VpYKdQo3I for ; Fri, 24 Feb 2012 23:54:36 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 41BD221F8656 for ; Fri, 24 Feb 2012 23:54:36 -0800 (PST) Received: (qmail 96707 invoked from network); 25 Feb 2012 07:54:34 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Feb 2012 07:54:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f4893ba.xn--btvx9d.k1202; i=johnl@user.iecc.com; bh=YGuxjDRATM9qxiQhJ6MdXSDkrfO7E1I2Tvkqp2aZ1x0=; b=rIVqY0oWfhIkoeT1aUP/I0S7mKho/XHeBCO7yuMRjUdhuthhGNMQ1yXQMLIufZ3twLJubqsKOv/r8+O5U4tpK3EJu/D10OPwI2O6m9PYgvb07QPLu0P92sx/RTFH58IoDXHU3LLa3H86nxkemP4MED5KqkucxqGxhnjIZyjZreQ= 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=4f4893ba.xn--btvx9d.k1202; olt=johnl@user.iecc.com; bh=YGuxjDRATM9qxiQhJ6MdXSDkrfO7E1I2Tvkqp2aZ1x0=; b=0q2KzLjywPSlZD4LpnRWlm9LGWxgZ3ResMILaB3nH91+mpl4KskWkrf7jIT1QfOBdesqpv/m4UIUIuY7EaCBhVYgyQbJPz3Z3UeofGXsdaRUyi8X2jH9MpZqZr5SBD3tTsKFY/ZPdyJoOEv9E4gO+btaOdGRiKE4j20Sy5JA/sU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Feb 2012 07:54:12 -0000 Message-ID: <20120225075412.2330.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E003928045F10@exch-mbx901.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: msk@cloudmark.com Subject: Re: [spfbis] Garbage TXT records (more on Issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 07:54:37 -0000 >An SPF client that queries SPF first and actually gets answers is far >less likely to need hardening against this kind of junk. The sanity check for SPF records is identical to that for TXT records, so why wouldn't you do the same thing either way? Also, SPF records offer their own exciting failure modes. See, for example, the mail on the dmarc-discuss list a few weeks ago from the guy who insists on returning NOTIMP in response to type 99 queries, which Yahoo interpreted as a soft failure it should retry. >For that matter, is the fear of unsupported RRtypes that was obviously >around six years ago still an issue today? I'm not sure fear is the right word, but there's vast amounts of DNS provisioning* software that only support a fixed set of RRs, and SPF inevitably isn't one of them. Or they only support them via ugly escape codes. Here, for example, is the source form of one of my SPF records: :taugh.com:99:\072v=spf1\040ip4\07264.57.183.0\05726\040ip6\0722001\072470\0721f07\0721126\072\072\05764\040~all:7200 (That was generated by a perl script, but not all provisioning systems are run by perl weenies.) A few months ago I sent a proposal to the dnsext group for a simple DNS extension language that would make it easier to add new RRs to both servers and provisioning software, but although a few people expressed interest, it looks like dnsext will shut down without doing anything about it. R's, John * - I said provisioning software, not DNS servers From vesely@tana.it Sat Feb 25 02:08:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C16821F862D for ; Sat, 25 Feb 2012 02:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.653 X-Spam-Level: X-Spam-Status: No, score=-4.653 tagged_above=-999 required=5 tests=[AWL=0.066, 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 Mi1fy+P8MjOo for ; Sat, 25 Feb 2012 02:08:35 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4A44F21F8559 for ; Sat, 25 Feb 2012 02:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1330164514; bh=jwg2ElLpxdLrhJfnfzqkF3d9K4xYac9rCGVW+j8RMZ8=; l=1091; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=PU1OY9xiYZK/3LdlBRBzt+DZ843VSAivX3shW9utjqOTsgeyeXLbopiL440/DPUaX Uo2qhe+E9ksAqTs+iDGGhIrdUBsnYQbhR0l7Iv3v44AVirskXoprwnWeVgECNNng87 WQwczzqOjyD97XYEFK2OLa4O+3NgNBo0dbzMGqcU= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 25 Feb 2012 11:08:34 +0100 id 00000000005DC039.000000004F48B322.000001CE Message-ID: <4F48B322.2030809@tana.it> Date: Sat, 25 Feb 2012 11:08:34 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> In-Reply-To: <4F47FF34.9020808@Commerco.Net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 10:08:36 -0000 On 24/Feb/12 22:20, Commerco WebMaster wrote: > Another point brought forward is that often it takes time to get folks > to move forward on upgrading software versions and making changes to > DNS authoritative host zone files. While that is true, it should not > negate the responsibility of those putting together specifications to > point folks in the right direction as regards the implementation of > SPF RRs in their DNS host zone files. We should realize that seven years has been plenty of time for the real world out there to give a response. Actually, it did. The outcome of this experiment was already clear to those who specified DKIM, ADSP, VBR, and similar, based on SPF experience. SPF is not famous for its ease at getting standardized, and I see no reason why it should be the one protocol that takes upon itself the burden of questing this DNS conundrum, most likely at the expenses of its own success. > Operationally, I think that keeping the TXT and SPF RRs in sync is not > really all that hard to do. Defining RRs for helo names is even easier. From R.E.Sonneveld@sonnection.nl Sat Feb 25 10:33:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0549C21F8616 for ; Sat, 25 Feb 2012 10:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.665 X-Spam-Level: X-Spam-Status: No, score=-3.665 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 HbMtP91Kblnn for ; Sat, 25 Feb 2012 10:33:01 -0800 (PST) Received: from mx11.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id 10BB721F8607 for ; Sat, 25 Feb 2012 10:33:01 -0800 (PST) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LZY00500OV0YZ00@hydrogen.mailtransaction.com>; Sat, 25 Feb 2012 19:33:00 +0100 (CET) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LZY0082NOUZ3F00@hydrogen.mailtransaction.com>; Sat, 25 Feb 2012 19:33:00 +0100 (CET) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LZY00I02OUZVA00@lion.sonnection.nl> for spfbis@ietf.org; Sat, 25 Feb 2012 19:32:59 +0100 (CET) Message-id: <4F492AD2.7090302@sonnection.nl> Date: Sat, 25 Feb 2012 19:39:14 +0100 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E003928045EAC@exch-mbx901.corp.cloudmark.com> In-reply-to: <9452079D1A51524AA5749AD23E003928045EAC@exch-mbx901.corp.cloudmark.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1330194780; bh=HEpW6HATv9EuxrCHl3BoFkjBKuJppyOUjig/VggZ/nM=; h=MIME-version:Content-transfer-encoding:Content-type:Message-id: Date:From:To:Cc:Subject:References:In-reply-to; b=SAzxT/UUDqNTP4gUe8c6ljHyS4/eB27lkOY3ybxeIvWKlS5wRjbvc3bxQIY6gIRer 1OY1Kmltm85+xyXbBBKJc2Xqbh8TR1xZlU/qHJowzmilFSSm1uKZIpV1x2VFZcXf+I qy0iqg7pqLCyh7WGUPepIp7aOBHQUMJsldYxdDTU= X-DKIM: OpenDKIM Filter v2.1.3 hydrogen.mailtransaction.com 0LZY00500OV0YZ00 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 18:33:02 -0000 Hi, Murray, On 2/25/12 7:08 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Paul Midgen >> Sent: Friday, February 24, 2012 3:27 PM >> To: S Moonesamy; spfbis@ietf.org >> Cc: spfbis-chairs@tools.ietf.org >> Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) >> >> If I take the meaning of "unused features" to be applied to an aspect >> of SPF that does not factor materially into the successful daily >> operation of SPF, having had 6+ years to establish such a presence, a >> preliminary survey of 1000 domains randomly chosen from Hotmail's SPF >> record cache does not find a single DNS type 99 record. > That sample size might be enough to avoid seeing any instances. The active polling I'm doing has checked 29088 domains so far and found only 29 type 99 records, and all 29 have both type 99 _and_ TXT records, I presume? /rolf From dhc2@dcrocker.net Sat Feb 25 11:19:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735AD21F8581 for ; Sat, 25 Feb 2012 11:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.915 X-Spam-Level: X-Spam-Status: No, score=-5.915 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPzyBVi6uiEG for ; Sat, 25 Feb 2012 11:19:27 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CBF8721F857A for ; Sat, 25 Feb 2012 11:19:27 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1PJJKXr009936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Feb 2012 11:19:26 -0800 Message-ID: <4F493431.5040107@dcrocker.net> Date: Sat, 25 Feb 2012 11:19:13 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> <4F482262.2080802@isdg.net> <7F7F36E50398F84DBAF25C9D51732F1E204B65C2@TK5EX14MBXC203.redmond.corp.microsoft.com> <4F484D6C.9080802@isdg.net> <9452079D1A51524AA5749AD23E003928045DBF@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928045DBF@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 25 Feb 2012 11:19:26 -0800 (PST) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) 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, 25 Feb 2012 19:19:28 -0000 On 2/24/2012 7:28 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Hector Santos >> Sent: Friday, February 24, 2012 6:55 PM >> To: Paul Midgen >> Cc: spfbis@ietf.org; spfbis-chairs@tools.ietf.org; S Moonesamy >> Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) >> >>> By my proffered definition of "unused", the data I've seen so far >>> doesn't support inclusion. I leave it to those with more >>> experience/subject matter expertise to make the appropriate >>> architecture (DNS, internet, etc.) based call. >> >> That would be pretty much be all of us. > > I'm sorry, but this is two things: false and rude. > > Let's all take a moment to re-read the co-chairs' "comportment" message, please. I'd rather see a moment taken to enforce it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Sat Feb 25 11:23:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64C021F8619 for ; Sat, 25 Feb 2012 11:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVjL4RHZTITb for ; Sat, 25 Feb 2012 11:23:41 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id ADB5021F85B9 for ; Sat, 25 Feb 2012 11:23:41 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CB05120E40CC; Sat, 25 Feb 2012 14:23:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330197820; bh=TQe6OWEYReGavhewm3fnWY1yQVIXWV8tRhHBdqHorI4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=D7GUOge3jm7rM1MxRKcBXCPs5hP/LgC1Kek686T9pac/FFUtl19GzlUltZYSGwlsi aENNDcqSkh53umEDr7NCex7NLEsBGGQ/xhtZCyShwk95hJRmt72Nr2hEm9fnuXo4Nv sKtI2UphKO/YGSrzm6YO1EvMVDQVrJeEU/Om3rGM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id ABDA620E40BB; Sat, 25 Feb 2012 14:23:40 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 25 Feb 2012 14:23:40 -0500 Message-ID: <2272539.BUPalJ031A@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F493431.5040107@dcrocker.net> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <9452079D1A51524AA5749AD23E003928045DBF@exch-mbx901.corp.cloudmark.com> <4F493431.5040107@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 19:23:43 -0000 On Saturday, February 25, 2012 11:19:13 AM Dave CROCKER wrote: > On 2/24/2012 7:28 PM, Murray S. Kucherawy wrote: > >> -----Original Message----- > >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > >> Behalf Of Hector Santos Sent: Friday, February 24, 2012 6:55 PM > >> To: Paul Midgen > >> Cc: spfbis@ietf.org; spfbis-chairs@tools.ietf.org; S Moonesamy > >> Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE > >> (issue #9)>> > >>> By my proffered definition of "unused", the data I've seen so far > >>> doesn't support inclusion. I leave it to those with more > >>> experience/subject matter expertise to make the appropriate > >>> architecture (DNS, internet, etc.) based call. > >> > >> That would be pretty much be all of us. > > > > I'm sorry, but this is two things: false and rude. > > > > Let's all take a moment to re-read the co-chairs' "comportment" message, > > please. > I'd rather see a moment taken to enforce it. I think it was unintentional. I didn't interpret it in a negative way when I first read it. Scott K From dhc2@dcrocker.net Sat Feb 25 11:24:25 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2CA21F8462 for ; Sat, 25 Feb 2012 11:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSwOyAL1xx6O for ; Sat, 25 Feb 2012 11:24:25 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EB6A121F845C for ; Sat, 25 Feb 2012 11:24:24 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1PJOJaK010045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Feb 2012 11:24:24 -0800 Message-ID: <4F49355B.1010809@dcrocker.net> Date: Sat, 25 Feb 2012 11:24:11 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E003928045EAC@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928045EAC@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 25 Feb 2012 11:24:24 -0800 (PST) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) 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, 25 Feb 2012 19:24:25 -0000 On 2/24/2012 10:08 PM, Murray S. Kucherawy wrote: > That sample size might be enough to avoid seeing any instances. The active polling I'm doing has checked 29088 domains so far and found only 29 type 99 records, I'm not very good at math, but I do think yours and Paul's research involves sufficiently large sample size to be reasonably suggestive of what is true for the "population" of relevant DNS names. (As I recall, for regular surveys about a single objective, binary characteristic, a sufficiently random sampling only needs about 113 data points to represent the population of the US.) I believe the summary of your findings is that the SPF record is present in: 0.0 - 0.1% of the domains. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Sat Feb 25 11:31:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4400121F85E3 for ; Sat, 25 Feb 2012 11:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 j+8w-ChJnbNL for ; Sat, 25 Feb 2012 11:31:39 -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 47AA821F85DD for ; Sat, 25 Feb 2012 11:31:39 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.238.18]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1PJVPjS002936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 25 Feb 2012 11:31:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330198297; i=@elandsys.com; bh=sw/JSvqIWeYW01d0KeWwexEFo7GcimTmwCDGIzkLhhY=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=niNGKBxF+9Toa0hreo1KxkM/rW2RA3Q1/3K7Aizr8UZBJhEWNMG2Y2alvHM9Fwe/6 nZFrZKLd21Cf5pfRmGUNiIZ4lyNeoPdx8AX11agf7ZqgUhTfEUQ1lMMjxbX5R5EcKW ssjBusP4hZT3kE2Lt2txnqZHc4XH9tWRABnbihCE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330198297; i=@elandsys.com; bh=sw/JSvqIWeYW01d0KeWwexEFo7GcimTmwCDGIzkLhhY=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=TMo7REEzFd2TXKoczg5XBe6r+Lm+Wxgp6AFxUVvOSfEtQfzReNbMlnh4GkcmlnezM ztE3l/6VTImcNGmzwcroRWtcJYiFDQMcJ4LXwceRm5inhAv9E3UKWoYOrICwAM4YxZ lhBsfl0k1AwWeHOvExEBVNcgoRh/5LWyiKijGR88= Message-Id: <6.2.5.6.2.20120225103447.09eefc78@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 25 Feb 2012 11:27:02 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4F48B322.2030809@tana.it> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 19:31:41 -0000 Hello, This case is unusual. There has been comments about what is an unused feature. (i) Is the DNS RR of type SPF, code 99, an optional feature in implementations of RFC 4408? (ii) Is the DNS RR of type SPF, code 99, optional for a SPF-compliant domain name? (iii) Is there an interoperability problem when the DNS RR of type SPF, code 99, is used? Regards, S. Moonesamy SPFBIS WG co-chair From pmidge@microsoft.com Sat Feb 25 12:10:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6013B21F855F for ; Sat, 25 Feb 2012 12:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.72 X-Spam-Level: X-Spam-Status: No, score=-5.72 tagged_above=-999 required=5 tests=[AWL=0.879, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j476UKgALV20 for ; Sat, 25 Feb 2012 12:10:11 -0800 (PST) Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCE721F8499 for ; Sat, 25 Feb 2012 12:10:10 -0800 (PST) Received: from mail168-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Sat, 25 Feb 2012 20:10:05 +0000 Received: from mail168-tx2 (localhost [127.0.0.1]) by mail168-tx2-R.bigfish.com (Postfix) with ESMTP id CE52B4204C3; Sat, 25 Feb 2012 20:10:05 +0000 (UTC) X-SpamScore: -30 X-BigFish: VS-30(zzbb2dI9371I542M98dKzz1202hzz8275ch1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail168-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail168-tx2 (localhost.localdomain [127.0.0.1]) by mail168-tx2 (MessageSwitch) id 1330200603429183_27834; Sat, 25 Feb 2012 20:10:03 +0000 (UTC) Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.238]) by mail168-tx2.bigfish.com (Postfix) with ESMTP id 57D1B440106; Sat, 25 Feb 2012 20:10:03 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 25 Feb 2012 20:10:02 +0000 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.110]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0247.005; Sat, 25 Feb 2012 20:10:01 +0000 From: Paul Midgen To: "dcrocker@bbiw.net" , "Murray S. Kucherawy" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM8y1RU7YMwN3alUeqUtF92kjEk5ZMrTuwgAB0UwCAAN4xgIAABXzQ Date: Sat, 25 Feb 2012 20:10:01 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204B6A00@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E003928045EAC@exch-mbx901.corp.cloudmark.com> <4F49355B.1010809@dcrocker.net> In-Reply-To: <4F49355B.1010809@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 20:10:12 -0000 For what it's worth, and not intending to contradict the 113 data-points st= atement, we've learned (internally) that the minimum bar for a statisticall= y reliable sample is 10,000 messages, where 100,000 is viewed as unimpeacha= ble but generally total overkill. Two of my queries completed overnight and support your conclusion. Of 19729 domains surveyed: Neither : 8174 SPF-only : 14 TXT-only : 11332 Both : 209 In terms of percentages: Neither : 41.43% of surveyed domains SPF-only : 0.07% of surveyed domains; 0.12% of publishing domains TXT-only : 57.44% of surveyed domains; 98.07% of publishing domains Both : 1.06% of surveyed domains; 1.81% of publishing domains Given the nature of this sample (randomly chosen domains, no additional bia= s) the "publishing domains" values should be given more weight. The potential errors in the data are that the domain list was not scrubbed = to remove long-tail or "bad" senders such as low-volume, spam hosts, bots,= etc., and there is no comparison (yet - hoping the chairs leave this open = long enough to get that data) with a top-10k domain list based on delivered= volume (e.g. "mail that matters"). -p -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Dave CROCKER Sent: Saturday, February 25, 2012 11:24 AM To: Murray S. Kucherawy Cc: spfbis@ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue = #9) On 2/24/2012 10:08 PM, Murray S. Kucherawy wrote: > That sample size might be enough to avoid seeing any instances. The=20 > active polling I'm doing has checked 29088 domains so far and found=20 > only 29 type 99 records, I'm not very good at math, but I do think yours and Paul's research involve= s sufficiently large sample size to be reasonably suggestive of what is tru= e for the "population" of relevant DNS names. (As I recall, for regular su= rveys about a single objective, binary characteristic, a sufficiently rando= m sampling only needs about 113 data points to represent the population of = the US.) I believe the summary of your findings is that the SPF record is present in= : 0.0 - 0.1% of the domains. d/ --=20 Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From dhc2@dcrocker.net Sat Feb 25 12:22:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887EC21F85E6 for ; Sat, 25 Feb 2012 12:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edbaKf-aHgB8 for ; Sat, 25 Feb 2012 12:22:39 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id DBD0D21F85D4 for ; Sat, 25 Feb 2012 12:22:39 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1PKMYsf011798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 25 Feb 2012 12:22:39 -0800 Message-ID: <4F494302.9060004@dcrocker.net> Date: Sat, 25 Feb 2012 12:22:26 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "spfbis@ietf.org" References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E003928045EAC@exch-mbx901.corp.cloudmark.com> <4F49355B.1010809@dcrocker.net> <7F7F36E50398F84DBAF25C9D51732F1E204B6A00@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E204B6A00@TK5EX14MBXC203.redmond.corp.microsoft.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, 25 Feb 2012 12:22:39 -0800 (PST) Subject: [spfbis] sampling (was: Re: Call for intermediate consensus on SPF RRTYPE (issue #9)) 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, 25 Feb 2012 20:22:40 -0000 i've changed the Subject since this at least somewhat off topic. On 2/25/2012 12:10 PM, Paul Midgen wrote: > For what it's worth, and not intending to contradict the 113 data-points statement, we've learned (internally) that the minimum bar for a statistically reliable sample is 10,000 messages, where 100,000 is viewed as unimpeachable but generally total overkill. My training was for psych experimentation and I can't find a citation that says anything like the 113 number I quoted. I did find something with numbers of the /type/ I meant: where psych research tends towards the 5% margin of error. The URL points to 381 for that. But I'm more interested that it says 9600 for 1%. That sounds suspiciously like 10,000... On the other hand, it does not really permit reporting fractions of a percent for the result. Maybe halves of percent, but not, IMO, as fine as tenths of a percent. I suspect that requires a sample size of at least 30,000, if I'm reading the trending on the table correctly... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Sat Feb 25 13:31:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DED21F85DD for ; Sat, 25 Feb 2012 13:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 MEimn+yhADCj for ; Sat, 25 Feb 2012 13:31:39 -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 B378E21F85DB for ; Sat, 25 Feb 2012 13:31:39 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.238.18]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1PLVNsm003182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 25 Feb 2012 13:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330205495; i=@elandsys.com; bh=+3TImaRK/0a64Ttb0EAa4y9FIieAvDUuGqg/UPUbDSo=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=qJ0AOKGJURHFN9tLVdz1bwZ8+UclX42ivGsmdFvVf+7WCRcqyDruIr682CtD6OxfQ wMsqvpAw3lF9IQjNIIPXJIsNZRt8u5yi2zefR9ClmKFx6U4LCYZ+U9fBRnQ+sVp9pQ CE9pk3oet2adbpacJfDyuuoaMhx4q3qCTEFIr7+0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330205495; i=@elandsys.com; bh=+3TImaRK/0a64Ttb0EAa4y9FIieAvDUuGqg/UPUbDSo=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=ZuR/qxBZV/UqPy7bXNYAkeEm7hRBt52N/s2qz2XirEuPj99gTdZjyCwrr/eS6sJv8 E9J3hEVfAr8jqEEv//q+M6sB95pOkPDrUNkhDf/GcjazzI2GB9JuNaBOKGs72O/Zxz zBgRIZB5RsY14Ua7XQdLS4TPgQLJwGkrY23bTWV8= Message-Id: <6.2.5.6.2.20120225122607.09ea0c90@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 25 Feb 2012 13:27:18 -0800 To: spfbis@ietf.org From: SM In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E204B6A00@TK5EX14MBXC203.re dmond.corp.microsoft.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E003928045EAC@exch-mbx901.corp.cloudmark.com> <4F49355B.1010809@dcrocker.net> <7F7F36E50398F84DBAF25C9D51732F1E204B6A00@TK5EX14MBXC203.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Feb 2012 21:31:41 -0000 At 12:10 25-02-2012, Paul Midgen wrote: >The potential errors in the data are that the domain list was not >scrubbed to remove long-tail or "bad" senders such as low-volume, >spam hosts, bots, etc., and there is no comparison (yet - hoping the >chairs leave this open long enough to get that data) with a top-10k >domain list based on delivered volume (e.g. "mail that matters"). Thanks for the data. Even if an issue is closed, it can be reopened if there is new data which points to an incorrect conclusion. It's up to the WG participants to consider the data and draw their conclusions. I try to get a sense of the consensus. As an off-topic note, I have seen some comments on this thread which are non-technical. If you consider a comment as inappropriate, you can send a private message to the WG Chairs (spfbis-chairs@tools.ietf.org). Regards, S. Moonesamy SPFBIS WG co-chair From hsantos@isdg.net Sat Feb 25 17:29:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7E021F8440 for ; Sat, 25 Feb 2012 17:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.422, 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 YtSyhYWh4+ie for ; Sat, 25 Feb 2012 17:29:20 -0800 (PST) Received: from ntbbs.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0789421F858A for ; Sat, 25 Feb 2012 17:29:12 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1403; t=1330219747; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=DWntqV/p3qRBEQeASXBPa+AI9os=; b=uomRnhriaKS6KLGQdSO4 GgQrBroiY0WVCE15YlCOpig9fDZzY2fuP0VmqlI67OGC9oQiHeLoZgryMbzxXdy+ Y/q0U+AlFlvot7TKKpFlzYHTj3MfGBcrvvH/EROD5AMFZ/OfjAGjrKT+NvlQ/AtR /usJBH+GPdVKTEsbv3GOF2s= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 25 Feb 2012 20:29:07 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3421588745.91150.4804; Sat, 25 Feb 2012 20:29:06 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1403; t=1330219499; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=srNUoyr xStL1Es3dguTacHIOdklDYG/ZMcyrKrO3wt0=; b=uYpn2XjZt3YhZ+vovr3cm2w guNtZQfR2/jGsJBKdAzh/QkGbhkv7S4PgjTRweynKqOK6T3QfblXCMwbapkHSRwW IznHBdPFUoFHIHNcjMr5esUw8MHqgcs+Oob4qMABlkfF4/nARWLIsIw/WT/Ewmk/ 9blFmHeFQaFJMSprKw3M= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 25 Feb 2012 20:24:59 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4020521564.19445.3396; Sat, 25 Feb 2012 20:24:58 -0500 Message-ID: <4F498AC4.3060903@isdg.net> Date: Sat, 25 Feb 2012 20:28:36 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E003928045EAC@exch-mbx901.corp.cloudmark.com> <4F49355B.1010809@dcrocker.net> <7F7F36E50398F84DBAF25C9D51732F1E204B6A00@TK5EX14MBXC203.redmond.corp.microsoft.com> <6.2.5.6.2.20120225122607.09ea0c90@resistor.net> In-Reply-To: <6.2.5.6.2.20120225122607.09ea0c90@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 01:29:21 -0000 My opinion: Since type 99 is still now part of the SPF-BIS process, I believe it promotes any issue (currently cataloged or needs to be created) that relates to the SPF-BIS recommended dual type look up algorithm to be codified in the spec. I think issue #25 currently comes close to that, but it may need a new issue proposal for a new specific section. SM wrote: > At 12:10 25-02-2012, Paul Midgen wrote: >> The potential errors in the data are that the domain list was not >> scrubbed to remove long-tail or "bad" senders such as low-volume, >> spam hosts, bots, etc., and there is no comparison (yet - hoping the >> chairs leave this open long enough to get that data) with a top-10k >> domain list based on delivered volume (e.g. "mail that matters"). > > Thanks for the data. Even if an issue is closed, it can be reopened if > there is new data which points to an incorrect conclusion. It's up to > the WG participants to consider the data and draw their conclusions. I > try to get a sense of the consensus. > > As an off-topic note, I have seen some comments on this thread which are > non-technical. If you consider a comment as inappropriate, you can send > a private message to the WG Chairs (spfbis-chairs@tools.ietf.org). > > Regards, > S. Moonesamy > SPFBIS WG co-chair > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From msk@cloudmark.com Sat Feb 25 17:39:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A55321F8616 for ; Sat, 25 Feb 2012 17:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 qJ-H0+LNAtzj for ; Sat, 25 Feb 2012 17:39:16 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB2D21F8613 for ; Sat, 25 Feb 2012 17:39:16 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Sat, 25 Feb 2012 17:39:15 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM8+vqHCxKihNXg0249dHxACH9PJZOZVAA Date: Sun, 26 Feb 2012 01:39:15 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928046F50@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E003928045EAC@exch-mbx901.corp.cloudmark.com> <4F492AD2.7090302@sonnection.nl> In-Reply-To: <4F492AD2.7090302@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 01:39:17 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Rolf E. Sonneveld > Sent: Saturday, February 25, 2012 10:39 AM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issu= e #9) >=20 > Hi, Murray, Hi Rolf, > > That sample size might be enough to avoid seeing any instances. The > > active polling I'm doing has checked 29088 domains so far and found > > only 29 type 99 records, >=20 > and all 29 have both type 99 _and_ TXT records, I presume? With over 87000 domains checked in this run, so far I have 47970 publishing= type 16 and 83 publishing type 99, with zero publishing both. At this rate it'll probably take a few more days to check all of the domain= s it plans to check. The interesting thing I forgot to mention thus far is that the set of domai= ns it's checking is basically "any domain for which at some point in the la= st 18 months I got an SPF 'Pass' result." It's curious that about half of = them now aren't showing records at all. (Well, maybe it's spammers, in which case it's not that curious.) -MSK From hsantos@isdg.net Sat Feb 25 20:23:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A70C21F861B for ; Sat, 25 Feb 2012 20:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, SARE_FWDLOOK=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 Btz7VKZKk+Mb for ; Sat, 25 Feb 2012 20:23:09 -0800 (PST) Received: from pop3.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E80DC21F8613 for ; Sat, 25 Feb 2012 20:23:08 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4161; t=1330230182; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=awfnK4+cRMilDxeDMrGibWw3Y2k=; b=MKThPIV0wUuSeuatm40P 17LIq5v+3t6ZcoGumlWh1QjjcQsVjh6j9cnvmagnRdO0zXMFMpjyDbH3jmDHtle7 CV3XwQOcgd7MRsekbg74X+kFdFHeuH2O+jZA0fyFWrHW1poAynck3PLMCMrcEQqV JXP6n0NeM/xh+Eu/nd1iKy0= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 25 Feb 2012 23:23:02 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3432023917.91150.3516; Sat, 25 Feb 2012 23:23:02 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4161; t=1330229937; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=9UyU0Co ibhFaWipo9JvwmdZhEX1Ib8TI0pMl5/AS1rE=; b=XUnsKwF1rWRdBBqvplFYqNF kn9hF4Gdt6QMLUlgFYtTfNAGrETE2AFIKQVIFQLBomu80FA0QwQVnaXvDsYfjQn9 /WJsRyQxb6kyMM6aXGvBm3eKRJx0Ek3KLhVCuI+Sz8YxzI2NcmhaBSiYVOk+u7Ah SaXVcW5C5isOQAHkdcJ0= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 25 Feb 2012 23:18:57 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4030959908.19533.8120; Sat, 25 Feb 2012 23:18:56 -0500 Message-ID: <4F49B393.2060305@isdg.net> Date: Sat, 25 Feb 2012 23:22:43 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <9452079D1A51524AA5749AD23E003928045F10@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928045F10@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Garbage TXT records (more on Issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 04:23:10 -0000 My Opinion: Interesting records. The first one, ut.edu, there is no v=SPF1 "string" that I can see, so even though we may view this as "junk", in SPF terms with a proper expected parsing, there is no v=SPF1, so no issue here. (Extra comment about this below). The 2nd one, arronline.com, this one had a bunch of v=spf1 strings. IMO, the technical question for SPF-BIS is which one should be valid. I would think "software wise" the first one is the one that should honor and the logic SHOULD stop to continue looking for any more. Regarding the ut.edu record, I think the issue here is how TXT records are/were used to EXPLORE many different ideas to expose domain information. Look up winserver.com to see the some different ideas were explored. Regarding the arronline.com and zagat.com, lookup _dsap.isdg.net and see the ideas here exploring the merging of multiple v=dsap1 records to deal with different domains and wildcarding. The old DMP experimental LMAP protocol was similar with using multiple strings. So its all part of the DNS infrastructure concerns debated with using TXT records in different ways. The evidence you provide shows these efforts. In My view: using type 99 PRO: helps with isolating a protocol framework data, less conflicts. (Note: CEP (prior to SENDER-ID) had its own namespace). PRO: Helps with IETF/DNS community endorsement CON: RFC 3597 related issue, higher CON yesteryears, lesser CON today. using TXT PRO: Helps for multiple protocols to share the same namespace (i.e. 1 query vs multiple queries) PRO: Probably view as simpler CON: Does not helps with IETF endorsement CON: More complex, no standard set to separate them except for looking for specific start tags I think a forward looking consideration is the idea of clients having to use different query formats for different protocols where perhaps maybe there should be all part of a single call. This will have with long term scaling of DNS storage usage. Does a focus on reliable wildcarding helps here? Perhaps there is a need to propose a BATCH Multiple Query Packet concept for DNS that is now emulated using async methods. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Murray S. Kucherawy wrote: > While running some more query reports about deployed SPF records, I came across a few interesting cases. My favourite two examples are ut.edu and aaronline.com. Do a TXT query of both to see what I'm looking at. The ut.edu one actually triggered truncation in my tests. > > So for the sake of discussion, let me toss out this straw man argument: > > An SPF client that queries SPF first and actually gets answers is far less likely to need hardening against this kind of junk. It's thus less likely to break. Therefore, enabling the isolation of SPF data into its own RRtype is actually beneficial, and so we should keep it and re-emphasize its value. > > (Yes, I know it's easy to cycle through a TXT RRset and only extract stuff that starts "v=spf1". That doesn't mean everyone will get it right.) > > For another example, look at zagat.com. The Google Apps site ownership verification record is one example of how TXT is overloaded for numerous purposes for which SPF clients need to be prepared if they're querying TXT, but would very unlikely be a concern for an SPF RRset. > > Again, just a straw man that might end up being useful when considering the merits of the proposal to remove type 99 vs. keeping it. I don't know that I agree with it. > > For that matter, is the fear of unsupported RRtypes that was obviously around six years ago still an issue today? Could we actually go the other way and slap a SHOULD NOT on TXT records because support is now relatively available? > > -MSK > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From msk@cloudmark.com Sat Feb 25 22:48:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70E621F8545 for ; Sat, 25 Feb 2012 22:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqRO7PnozWry for ; Sat, 25 Feb 2012 22:48:51 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2D521F852C for ; Sat, 25 Feb 2012 22:48:36 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Sat, 25 Feb 2012 22:48:35 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM8zo3qm5Toirri0OwQXkGIh4zbJZN6oUAgACcCACAADJCkA== Date: Sun, 26 Feb 2012 06:48:35 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> <6.2.5.6.2.20120225103447.09eefc78@resistor.net> In-Reply-To: <6.2.5.6.2.20120225103447.09eefc78@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 06:48:51 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of S Moonesamy > Sent: Saturday, February 25, 2012 11:27 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issu= e #9) >=20 > Hello, >=20 > This case is unusual. There has been comments about what is an unused > feature. >=20 > (i) Is the DNS RR of type SPF, code 99, an optional feature in > implementations of RFC 4408? The implementation I did with a colleague back in about 2006-2008 never che= cked type 99 records because the "T_SPF" mnemonic in the UNIX include file = wasn't defined. At the time we chose only to query things= for which the nameserver code apparently included native support. RFC4408= says you do one, the other, or both, and if doing both, you MAY do them in= parallel. Thus, this choice was compliant with the specification. A quick look at the online source repository for FreeBSD and a recent Linux= installation shows they still don't define T_SPF or the newer variant (ns_= t_spf), years later. > (ii) Is the DNS RR of type SPF, code 99, optional for a SPF-compliant > domain name? Section 3.1.1 of RFC4408 says: An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at least one type. If a domain has records of both types, they MUST have identical content. =20 Your question used "optional", which of course is an RFC2119 word. :-) Us= ing it in its English sense and not that sense, yes, it's optional; you're = still compliant if you don't use it. > (iii) Is there an interoperability problem when the DNS RR of type SPF, > code 99, is used? Barring errors, clients that query for them almost always get an RCODE 3 re= ply. This causes them to add a negative cache entry, whether or not the TX= T query was done in parallel. This seems wasteful since we know it's almos= t never there; such cache entries would better serve other purposes. The c= lients then fall back to TXT queries, which works fine and is actually ther= e in all the other cases where the domain publishes something. The few servers that do post them do get good interoperability, of course, = but apparently this is very unusual, probably because of the weak provision= ing systems Andrew and John alluded to earlier. -MSK From msk@cloudmark.com Sat Feb 25 22:55:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD5421F864D for ; Sat, 25 Feb 2012 22:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnWqZVqgiaqI for ; Sat, 25 Feb 2012 22:55:40 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 288C621F8555 for ; Sat, 25 Feb 2012 22:55:40 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Sat, 25 Feb 2012 22:55:39 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM8zo3qm5Toirri0OwQXkGIh4zbJZN6oUAgACcCACAADJCkIAABuqw Date: Sun, 26 Feb 2012 06:55:39 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> <6.2.5.6.2.20120225103447.09eefc78@resistor.net> <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 06:55:40 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Murray S. Kucherawy > Sent: Saturday, February 25, 2012 10:49 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issu= e #9) >=20 > The implementation I did with a colleague back in about 2006-2008 never > checked type 99 records because the "T_SPF" mnemonic in the UNIX > include file wasn't defined. At the time we chose > only to query things for which the nameserver code apparently included > native support. RFC4408 says you do one, the other, or both, and if > doing both, you MAY do them in parallel. Thus, this choice was > compliant with the specification. This raises an interesting question, now that I think of it. RFC4408 (Section 3.1.1) says the server side SHOULD use both types, and MUS= T use at least one type. It also (Section 4.4) says that clients can query= one type, the other type, or both. Doesn't that mean that a server that publishes only TXT, and a client that = queries only for SPF, or vice-versa for that matter, are both fully complia= nt but will never actually interoperate? -MSK From msk@cloudmark.com Sat Feb 25 22:59:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA0B21F84AA for ; Sat, 25 Feb 2012 22:59: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ+qSJ-QLN-b for ; Sat, 25 Feb 2012 22:59:47 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7668821F84A7 for ; Sat, 25 Feb 2012 22:59:47 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Sat, 25 Feb 2012 22:59:47 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM8y1W2VNI8D1siUmvUKuKkD2KZZZOtGUw Date: Sun, 26 Feb 2012 06:59:46 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280471DE@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 06:59:48 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of S Moonesamy > Sent: Friday, February 24, 2012 11:48 AM > To: spfbis@ietf.org > Cc: spfbis-chairs@tools.ietf.org > Subject: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9= ) >=20 > Objections to this determination of consensus need to produce evidence > that the feature is not used, or that the removal of TYPE 99 is an > enhancement that has already gained widespread support. Please > remember that the desirability of the removal of the feature is not > enough: the charter restricts our freedom to do what we want here. Respectfully, I think we need a little more time to talk about this. The curious thing is that the question of "used" in our processes is ambigu= ous. Type 99 is very clearly used widely by clients and very clearly not u= sed widely by servers. Does it count as "used" when clients are asking but= the servers aren't answering? Is the relatively tiny intersection of the = two enough to establish a statement of interoperability and sufficient depl= oyment to warrant keeping it? I'm trying to think of any examples of other protocols that have faced this= question in the past and use them to guide our own resolution, but I can't= come up with any yet. I believe Dave pointed out that if we were to try to advance a protocol fro= m Proposed Standard under those conditions, there would likely be some chal= lenges raised. Whatever we decide, we should be prepared to answer them. I just brought up a couple of related issues elsewhere in this thread as we= ll. Thanks, -MSK From hsantos@isdg.net Sun Feb 26 00:11:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C030921F8598 for ; Sun, 26 Feb 2012 00:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wb6MKLANfpLV for ; Sun, 26 Feb 2012 00:11:53 -0800 (PST) Received: from secure.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 81C1721F8433 for ; Sun, 26 Feb 2012 00:11:50 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3169; t=1330243902; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=KHEXEyOJX6CYdpDXV3qXP9is0y4=; b=L8YeA71Iadcn6NphLPjh QGR7/O6Hjl6pz7HT47JSVKMsuhSiHqo22fGOw5NPZY3ywQsvo5kmXTGuZsCYIrBY FA9iup9IeO4muk4H1amZvWlVfRWAKelOc4JKX7vziDHviohjZsCPXbZmrJwSC/Z0 kfxyI4LihD8l7Qthzxo7v0g= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 26 Feb 2012 03:11:42 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3445744127.92507.4736; Sun, 26 Feb 2012 03:11:42 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3169; t=1330243656; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=lRFqR07 umm/IcqMaLKo2n1998h0Oskmi9xo3tKWjJ+k=; b=0cGGxy0qhG1LPZLfbi4LQeW d7NRkYMR1AQ4BPE+wiIYiN/u6OaKx6LVcQDY1hU6p8RGxtBOug1aXpVtEu3TCBPa 6J85NgOX+2Ov7Y+7oSwhryYSZogiZXOpfcDfDKAQYwoula44cf3v+RRweVpldu6K lETBRH8nZcu+KpQyRL28= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 26 Feb 2012 03:07:36 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4044679111.19549.4180; Sun, 26 Feb 2012 03:07:35 -0500 Message-ID: <4F49E931.6000902@isdg.net> Date: Sun, 26 Feb 2012 03:11:29 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> <6.2.5.6.2.20120225103447.09eefc78@resistor.net> <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 08:11:54 -0000 My opinion: This is the sort of items that needs to be cleared up in SPF-BIS. I always thought it was well understood is was a migration issue. If its not already stated somewhere in the spec, a domain using SPF type published records only would not get widest support due the well known RFC3597 issues. It will surprising to me to see if there are a high number of SPF type only records. It would be similar with DKIM's SHA1 vs SHA256 migration issue and we will need the same type of language. Technically, a signer that only used SHA256 did not reach the widest support because some early desktop OSes like Windows XP with the CAPI API, did not offer it (SHA256) until much later after the chinese SHA1 exploit was published and Microsoft finally added SHA256 support under a security patch. Regardless, I think the same type of migration language as you have in DKIM is needed for SPF-BIS for the dual type supported client. Borrowing DKIM text: SPF Publishers MUST implement and SHOULD use SPF RR Type SPF Verifiers MUST implement both SPF and TXT RR type queries. I think you get the idea and you would be better at structuring the text with the recommended order and perhaps expanding a little about using async or parallel methods but I believe async needs to match how two sync sequential calls should work. The query MUSH|SHOULD start with SPF type first. If it fails (what is fail here?) fall back to TXT. Whether its done sync or async, IMO, the end result we want needs to be the same. Finally, on the flip side, like DKIM, because of this, some just don't bother and just use SHA1 and that will give 100% verifier support. Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Murray S. Kucherawy >> Sent: Saturday, February 25, 2012 10:49 PM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) >> >> The implementation I did with a colleague back in about 2006-2008 never >> checked type 99 records because the "T_SPF" mnemonic in the UNIX >> include file wasn't defined. At the time we chose >> only to query things for which the nameserver code apparently included >> native support. RFC4408 says you do one, the other, or both, and if >> doing both, you MAY do them in parallel. Thus, this choice was >> compliant with the specification. > > This raises an interesting question, now that I think of it. > > RFC4408 (Section 3.1.1) says the server side SHOULD use both types, and MUST use at least one type. It also (Section 4.4) says that clients can query one type, the other type, or both. > > Doesn't that mean that a server that publishes only TXT, and a client that queries only for SPF, or vice-versa for that matter, are both fully compliant but will never actually interoperate? > > -MSK > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Sun Feb 26 00:15:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A500021F853E for ; Sun, 26 Feb 2012 00:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.421, 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 ymCYavi6D6zn for ; Sun, 26 Feb 2012 00:15:53 -0800 (PST) Received: from secure.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 50B1E21F84D9 for ; Sun, 26 Feb 2012 00:15:53 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2194; t=1330244143; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=1t80+kwFuAffYdb90M2+bXtPxlg=; b=KsDr/9c5DFrd+WtAkNVl VPjpmgd0qycfv3Rzsq3pr983Wn3K90vyPXIbKC98A602KUbN1hBvgXogTEkZyihW Blz31p72LVWY94HCnyzZziMrqHHBnragfVbUgf09gLSyYlAv8OLSlZjopJ560w0K otQiperK3yjPdJnKdufhwtU= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 26 Feb 2012 03:15:43 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3445984228.92507.972; Sun, 26 Feb 2012 03:15:42 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2194; t=1330243894; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=0+XuLm0 OzqId4CIYXrNGmrJyBuHZgRH3SXxgi7GJ2QY=; b=La23DNSxPT8WgWUucqZoQ1e uiTa5atMHrhl/3pvBEBFC7Bg1KRgKn6Yc7x/GTt2vnURS1ykuNBxcZdwjidiMhpO X/oGBseMzYXZIp/iqBnLoSNmN3r2tT6NGYjs7kXlD4HMu+Uw4JTlKtwLLi/xneLK fuyXcx9CwJZBHTJUEPPg= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 26 Feb 2012 03:11:34 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4044916673.19551.5028; Sun, 26 Feb 2012 03:11:33 -0500 Message-ID: <4F49EA21.7020302@isdg.net> Date: Sun, 26 Feb 2012 03:15:29 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: "spfbis@ietf.org" References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <9452079D1A51524AA5749AD23E0039280471DE@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280471DE@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 08:15:54 -0000 This is and always was a migration consideration in my opinion. I will treat the issue in the same way done with DKIM in regards to SHA1 vs 256. The publisher is expect to do the most optimal thing for migration and the client need to be prepared for both. Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of S Moonesamy >> Sent: Friday, February 24, 2012 11:48 AM >> To: spfbis@ietf.org >> Cc: spfbis-chairs@tools.ietf.org >> Subject: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) >> >> Objections to this determination of consensus need to produce evidence >> that the feature is not used, or that the removal of TYPE 99 is an >> enhancement that has already gained widespread support. Please >> remember that the desirability of the removal of the feature is not >> enough: the charter restricts our freedom to do what we want here. > > Respectfully, I think we need a little more time to talk about this. > > The curious thing is that the question of "used" in our processes is ambiguous. Type 99 is very clearly used widely by clients and very clearly not used widely by servers. Does it count as "used" when clients are asking but the servers aren't answering? Is the relatively tiny intersection of the two enough to establish a statement of interoperability and sufficient deployment to warrant keeping it? > > I'm trying to think of any examples of other protocols that have faced this question in the past and use them to guide our own resolution, but I can't come up with any yet. > > I believe Dave pointed out that if we were to try to advance a protocol from Proposed Standard under those conditions, there would likely be some challenges raised. Whatever we decide, we should be prepared to answer them. > > I just brought up a couple of related issues elsewhere in this thread as well. > > Thanks, > -MSK > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Sun Feb 26 00:20:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CE821F856A for ; Sun, 26 Feb 2012 00:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2jLo5FgujgU for ; Sun, 26 Feb 2012 00:20:43 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 63E2D21F8514 for ; Sun, 26 Feb 2012 00:20:43 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 9D2A2D0408D; Sun, 26 Feb 2012 02:20:42 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330244442; bh=jcvy9Zru8Yz2aq4JPFVVBOHCFjnCNaT1v9Rf69TNElU=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=l9gZz91KnDx4nbpnxhN5ugyLrON5puJoQXCoMLuZzLEiGTy+7OgIA4BBaAA7ed7Tb Q2wPvClIPG0Sloa1q1gBbSnGNjyYtHnT/oQys2shvOKm7b+gTpPvIAHQZM6M6kWRSt DSB/Cw2rlt6vmWcDLt2az/jLMbDQFAU4VbmUGG3Q= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5FC8AD04002; Sun, 26 Feb 2012 02:20:42 -0600 (CST) References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> <6.2.5.6.2.20120225103447.09eefc78@resistor.net> <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> User-Agent: K-9 Mail for Android In-Reply-To: <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 26 Feb 2012 03:20:50 -0500 To: "spfbis@ietf.org" Message-ID: <9d1d4eac-d003-4ff7-9a45-eaf6b31a0861@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 08:20:45 -0000 "Murray S. Kucherawy" wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On >Behalf Of Murray S. Kucherawy >> Sent: Saturday, February 25, 2012 10:49 PM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE >(issue #9) >> >> The implementation I did with a colleague back in about 2006-2008 >never >> checked type 99 records because the "T_SPF" mnemonic in the UNIX >> include file wasn't defined. At the time we chose >> only to query things for which the nameserver code apparently >included >> native support. RFC4408 says you do one, the other, or both, and if >> doing both, you MAY do them in parallel. Thus, this choice was >> compliant with the specification. > >This raises an interesting question, now that I think of it. > >RFC4408 (Section 3.1.1) says the server side SHOULD use both types, and >MUST use at least one type. It also (Section 4.4) says that clients >can query one type, the other type, or both. > >Doesn't that mean that a server that publishes only TXT, and a client >that queries only for SPF, or vice-versa for that matter, are both >fully compliant but will never actually interoperate? > That is exactly what it means. Scott K From spf2@kitterman.com Sun Feb 26 00:32:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E4B21F8573 for ; Sun, 26 Feb 2012 00:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4seAMRM9v4uo for ; Sun, 26 Feb 2012 00:32:00 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id B6AB421F8571 for ; Sun, 26 Feb 2012 00:32:00 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 3BA1DD0408D; Sun, 26 Feb 2012 02:32:00 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330245120; bh=AI+718U1Nuda/ZTMUDhUaKrdPivBQi3aV+zHAJbfkvI=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=KBVhwFjd1iUt8ZCrLA53ufsrEvt1oSVTFuSPPue4IabdnXQrZHdvW7OhYXdrlpI2z hEuIksHiTefwgqX5YXV1qF8lQL19BiNB6yb1SNufUc7tdRpEy8OW2I/4DcUl/t+68v SmLi/1TP98EuQe74pG8dctkMyUJSxK5Qe3PZ+C8g= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 0380AD04002; Sun, 26 Feb 2012 02:31:59 -0600 (CST) References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> <6.2.5.6.2.20120225103447.09eefc78@resistor.net> <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> <4F49E931.6000902@isdg.net> User-Agent: K-9 Mail for Android In-Reply-To: <4F49E931.6000902@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 26 Feb 2012 03:31:54 -0500 To: "spfbis@ietf.org" Message-ID: <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 08:32:01 -0000 Hector Santos wrote: >My opinion: > >This is the sort of items that needs to be cleared up in SPF-BIS. I >always thought it was well understood is was a migration issue. If its >not already stated somewhere in the spec, a domain using SPF type >published records only would not get widest support due the well known >RFC3597 issues. It will surprising to me to see if there are a high >number of SPF type only records. > >It would be similar with DKIM's SHA1 vs SHA256 migration issue and we >will need the same type of language. Technically, a signer that only >used SHA256 did not reach the widest support because some early >desktop OSes like Windows XP with the CAPI API, did not offer it >(SHA256) until much later after the chinese SHA1 exploit was published >and Microsoft finally added SHA256 support under a security patch. > >Regardless, I think the same type of migration language as you have in >DKIM is needed for SPF-BIS for the dual type supported client. > >Borrowing DKIM text: > > SPF Publishers MUST implement and SHOULD use SPF RR Type > SPF Verifiers MUST implement both SPF and TXT RR type queries. > >I think you get the idea and you would be better at structuring the >text with the recommended order and perhaps expanding a little about >using async or parallel methods but I believe async needs to match how >two sync sequential calls should work. > >The query MUSH|SHOULD start with SPF type first. If it fails (what is >fail here?) fall back to TXT. Whether its done sync or async, IMO, >the end result we want needs to be the same. This is based on wishful thinking. MUST/SHOULD Type SPF first is a wasteful design approach meant use a spec to push people to do something operationally suboptimal in order to satisfy some theoretical architectural construct. The reason some domains publish Type SPF only is that RFC 4408 gives them absolutely no hint that's a bad idea. For 4408bis we should be honest and provide realistic guidance. Scott K From spf2@kitterman.com Sun Feb 26 00:40:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7AE21F84FB for ; Sun, 26 Feb 2012 00:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 lSXgXWRMojPH for ; Sun, 26 Feb 2012 00:40:05 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0929D21F84EF for ; Sun, 26 Feb 2012 00:40:05 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 62B09D0408D; Sun, 26 Feb 2012 02:40:04 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330245604; bh=OWVF+YKS8qUZWvU7FCBMRAevVMOtI0PgB2kmwdA0P9U=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=nkZIspbYb2h+JlMqdrMQH9xCV+A+yYBqMFGqzdtRJQ33Q/P1WfgdoLADhws4AjdzS 2u2lQso/Sb4yt6UAq2zL3cGnXPue956Z2FJlZrsecNeX/+KLSXZRjGltWKXkQXRhdJ cZW7KDhp5sa1wr4lGO7BZkuiweRUcy7YUaYGLxl0= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 27A66D04002; Sun, 26 Feb 2012 02:40:03 -0600 (CST) References: <9452079D1A51524AA5749AD23E003928045F10@exch-mbx901.corp.cloudmark.com> <4F49B393.2060305@isdg.net> User-Agent: K-9 Mail for Android In-Reply-To: <4F49B393.2060305@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 26 Feb 2012 03:40:08 -0500 To: "spfbis@ietf.org" Message-ID: <0e054e96-2aae-494a-8a06-560f72af9f2b@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Garbage TXT records (more on Issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 08:40:08 -0000 Hector Santos wrote: >My Opinion: > >Interesting records. > ... >The 2nd one, arronline.com, this one had a bunch of v=spf1 strings. >IMO, the technical question for SPF-BIS is which one should be valid. > I would think "software wise" the first one is the one that should >honor and the logic SHOULD stop to continue looking for any more. ... Since the order the various strings will be returned varies, that would mean a different result on subsequent queries. That kind of stochastic behavior is something we need to avoid. Under RFC 4408 multiple SPF records like this is a permanent error and that should not change for 4408bis. Scott K From hsantos@isdg.net Sun Feb 26 01:36:49 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D0421F8534 for ; Sun, 26 Feb 2012 01:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.417, 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 LjP4a4SK7n10 for ; Sun, 26 Feb 2012 01:36:48 -0800 (PST) Received: from mail.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7D15C21F8535 for ; Sun, 26 Feb 2012 01:36:48 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=937; t=1330248998; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=HLFm/5NXsS/xzJAvhG28fbmiy3A=; b=u7qcgzu+MoMULUyMede4 cd5Fr+wFpxHgX8PYdCJQ14PY+Y0sEjefw38S62NRQ8+zGf36O5gokFi14LepJrah gMCMDVHD5IlQydJYavZVOLm2O1fxfMxYdXwwpG/6pYxj/2Zh9AwJN3slIa7Y/g0/ eLf95u2CD/CE1E6wm7kDWwo= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 26 Feb 2012 04:36:38 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3450839354.92507.1436; Sun, 26 Feb 2012 04:36:37 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=937; t=1330248753; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=amvvjwj imgmAJrGH3AdqkXuNkHGj6TYm3KdtAQBxP+Y=; b=pg6CmyjLCGDUITs3N1Zi8ol 2j8IwcC0eUHsD8foYWnwzYuzWiRXT4MdrbiWI212wVFeIfekWZnrSRLV2yHZLHaa dmia3LeL4rzuXfdqvBunCdb61xRtKjaBun93yx47Dv6SDGxGcO1o2Wc3KvTu3lv0 KP3AxSiRdakhAF/sWC7U= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 26 Feb 2012 04:32:33 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4049775829.19556.4896; Sun, 26 Feb 2012 04:32:32 -0500 Message-ID: <4F49FD1B.3090508@isdg.net> Date: Sun, 26 Feb 2012 04:36:27 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: "spfbis@ietf.org" References: <9452079D1A51524AA5749AD23E003928045F10@exch-mbx901.corp.cloudmark.com> <4F49B393.2060305@isdg.net> <0e054e96-2aae-494a-8a06-560f72af9f2b@email.android.com> In-Reply-To: <0e054e96-2aae-494a-8a06-560f72af9f2b@email.android.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] Garbage TXT records (more on Issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 09:36:49 -0000 Scott Kitterman wrote: > > Hector Santos wrote: > ... >> The 2nd one, arronline.com, this one had a bunch of v=spf1 strings. >> IMO, the technical question for SPF-BIS is which one should be valid. >> I would think "software wise" the first one is the one that should >> honor and the logic SHOULD stop to continue looking for any more. > ... > > Since the order the various strings will be returned varies, that would mean > a different result on subsequent queries. That kind of stochastic behavior is > something we need to avoid. Under RFC 4408 multiple SPF records like this is > a permanent error and that should not change for 4408bis. You are referring to 4.5 If there are two or more records remaining, then check_host() exits immediately with the result of "PermError". Right? Ok, +1. Bad record. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From barryleiba.mailing.lists@gmail.com Sun Feb 26 07:49:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC39321F8534 for ; Sun, 26 Feb 2012 07:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.988 X-Spam-Level: X-Spam-Status: No, score=-102.988 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-hlaR2SzKOc for ; Sun, 26 Feb 2012 07:49:18 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42E6721F8523 for ; Sun, 26 Feb 2012 07:49:18 -0800 (PST) Received: by ghbg16 with SMTP id g16so1946904ghb.31 for ; Sun, 26 Feb 2012 07:49:17 -0800 (PST) Received-SPF: pass (google.com: domain of barryleiba.mailing.lists@gmail.com designates 10.101.179.38 as permitted sender) client-ip=10.101.179.38; Authentication-Results: mr.google.com; spf=pass (google.com: domain of barryleiba.mailing.lists@gmail.com designates 10.101.179.38 as permitted sender) smtp.mail=barryleiba.mailing.lists@gmail.com; dkim=pass header.i=barryleiba.mailing.lists@gmail.com Received: from mr.google.com ([10.101.179.38]) by 10.101.179.38 with SMTP id g38mr4873840anp.64.1330271357835 (num_hops = 1); Sun, 26 Feb 2012 07:49:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Gi9eBFMRKdit++CP/sCILpih+/+zXLjwwIwO7liClrs=; b=tf9C/a+CPOREAgviPnjyhaDc9BErvwDDfiRCU+udGFQT8t2HXdN3Qle5SYecccwZhn 1OEhkBmqmgFSPSIm8IGFc8LLE2vMJnnMMm4Xim3M+c9tX21YDVbV82hsz6IGSuqKWPnT 3MSkHQ0ZJ8GLvYJ04Prgt9dal/k8Pyv/SDV3I= MIME-Version: 1.0 Received: by 10.101.179.38 with SMTP id g38mr3648330anp.64.1330271357784; Sun, 26 Feb 2012 07:49:17 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.106.16 with HTTP; Sun, 26 Feb 2012 07:49:17 -0800 (PST) In-Reply-To: <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> <6.2.5.6.2.20120225103447.09eefc78@resistor.net> <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> <4F49E931.6000902@isdg.net> <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> Date: Sun, 26 Feb 2012 10:49:17 -0500 X-Google-Sender-Auth: VYzcES-9oQAN-Nv7vIX7zZXgHKE Message-ID: From: Barry Leiba To: spfbis@ietf.org Content-Type: multipart/alternative; boundary=001636c925e8bc536404b9dfef5b Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 15:49:18 -0000 --001636c925e8bc536404b9dfef5b Content-Type: text/plain; charset=ISO-8859-1 Murray says... > > RFC4408 (Section 3.1.1) says the server side SHOULD use both types, and > MUST use at least one type. It also (Section 4.4) says that clients can > query one type, the other type, or both. > > Doesn't that mean that a server that publishes only TXT, and a client that > queries only for SPF, or vice-versa for that matter, are both fully > compliant but will never actually interoperate? > Scott says... > The reason some domains publish Type SPF only is that RFC 4408 gives them > absolutely no hint that's a bad idea. For 4408bis we should be honest and > provide realistic guidance. > These two statements make a pretty compelling case that there is, indeed, an error in RFC4408. There are, of course, multiple ways to resolve it, and I have no immediate opinion on which is best. Barry, participant --001636c925e8bc536404b9dfef5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Murray says...=A0
RFC4408 (Section 3.1.1) says the server side SHOULD= use both types, and MUST use at least one type. =A0It also (Section 4.4) s= ays that clients can query one type, the other type, or both.

Doesn't that mean that a server that publishes only= TXT, and a client that queries only for SPF, or vice-versa for that matter= , are both fully compliant but will never actually interoperate?

=A0Scott says...
Th= e reason some domains publish Type SPF only is that RFC 4408 gives them abs= olutely no hint that's a bad idea. =A0For 4408bis we should be honest a= nd provide realistic guidance.

These two statements make a pretty compell= ing case that there is, indeed, an error in RFC4408. =A0There are, of cours= e, multiple ways to resolve it, and I have no immediate opinion on which is= best.

Barry, participant=A0
--001636c925e8bc536404b9dfef5b-- From dotzero@gmail.com Sun Feb 26 08:10:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A3421F85AA for ; Sun, 26 Feb 2012 08:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epmgWUUZThPK for ; Sun, 26 Feb 2012 08:10:17 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id F083421F8598 for ; Sun, 26 Feb 2012 08:10:14 -0800 (PST) Received: by dakl33 with SMTP id l33so4417535dak.31 for ; Sun, 26 Feb 2012 08:10:14 -0800 (PST) Received-SPF: pass (google.com: domain of dotzero@gmail.com designates 10.68.239.229 as permitted sender) client-ip=10.68.239.229; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dotzero@gmail.com designates 10.68.239.229 as permitted sender) smtp.mail=dotzero@gmail.com; dkim=pass header.i=dotzero@gmail.com Received: from mr.google.com ([10.68.239.229]) by 10.68.239.229 with SMTP id vv5mr30656507pbc.125.1330272614683 (num_hops = 1); Sun, 26 Feb 2012 08:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ru2Yn0d5F8gcc4+17RPqBU2WxzsRTpvHeHgEbpAjHfI=; b=xuuuLDCyrXd3HDtqnaZlUd5zQfN2+0MAVMMJcxsPHYLT/dvCIkkdDALCU56jD9quVY 1S7FyU28+2kE22JFxurrSdRBuZFRs5CFipnqh/y5Z+ZYYzQxljJJ6FcIQR8HIiwU0fX0 aE2i0qGPP12YmdOB0Z/Ji524G7kjkI4b/YxLA= MIME-Version: 1.0 Received: by 10.68.239.229 with SMTP id vv5mr26031695pbc.125.1330272614622; Sun, 26 Feb 2012 08:10:14 -0800 (PST) Received: by 10.68.35.198 with HTTP; Sun, 26 Feb 2012 08:10:14 -0800 (PST) In-Reply-To: References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> <6.2.5.6.2.20120225103447.09eefc78@resistor.net> <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> <4F49E931.6000902@isdg.net> <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> Date: Sun, 26 Feb 2012 11:10:14 -0500 Message-ID: From: Dotzero To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 16:10:18 -0000 On Sun, Feb 26, 2012 at 10:49 AM, Barry Leiba wro= te: > Murray says... >> >> RFC4408 (Section 3.1.1) says the server side SHOULD use both types, and >> MUST use at least one type. =A0It also (Section 4.4) says that clients c= an >> query one type, the other type, or both. >> >> Doesn't that mean that a server that publishes only TXT, and a client th= at >> queries only for SPF, or vice-versa for that matter, are both fully >> compliant but will never actually interoperate? > > > =A0Scott says... >> >> The reason some domains publish Type SPF only is that RFC 4408 gives the= m >> absolutely no hint that's a bad idea. =A0For 4408bis we should be honest= and >> provide realistic guidance. > > > These two statements make a pretty compelling case that there is, indeed,= an > error in RFC4408. =A0There are, of course, multiple ways to resolve it, a= nd I > have no immediate opinion on which is best. > > Barry, participant > +1 From msk@cloudmark.com Sun Feb 26 08:23:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A159521F8516 for ; Sun, 26 Feb 2012 08:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.27 X-Spam-Level: X-Spam-Status: No, score=-102.27 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xiXOl+9pwaN for ; Sun, 26 Feb 2012 08:23:35 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id B2ADF21F8514 for ; Sun, 26 Feb 2012 08:23:35 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Sun, 26 Feb 2012 08:23:35 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM9GEhgW7KfGf6bU6SwZXEWCVulZZPWrqg Date: Sun, 26 Feb 2012 16:23:32 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928047950@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> <6.2.5.6.2.20120225103447.09eefc78@resistor.net> <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> <4F49E931.6000902@isdg.net> <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> In-Reply-To: <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 16:23:36 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Sunday, February 26, 2012 12:32 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issu= e #9) >=20 > >The query MUSH|SHOULD start with SPF type first. If it fails (what is > >fail here?) fall back to TXT. Whether its done sync or async, IMO, the > >end result we want needs to be the same. >=20 > This is based on wishful thinking. >=20 > MUST/SHOULD Type SPF first is a wasteful design approach meant use a > spec to push people to do something operationally suboptimal in order > to satisfy some theoretical architectural construct. It is indeed the case that the DKIM SHA1/SHA256 stuff was intended a transi= tion mechanism. We've also seen that even newer signers use the old way (g= mail.com, for instance, uses rsa-sha1 last I checked). But also I don't think the DKIM analogy works because both variants of DKIM= signing are contained within a single communication mechanism, i.e., the s= ignature header field. A verifier always gets the signature, and then in a= nalyzing the signature parameters, decides it can't complete the action. B= ut some interoperability did occur, because there was information exchange = at least to that point. The same is not true for the SPF vs. TXT discussio= n, where the answer waiting is never seen because a different question is a= sked. Changing the normative text but keeping both types would also not address t= he problem of DNS provisioning systems that can't handle type 99 records. > The reason some domains publish Type SPF only is that RFC 4408 gives > them absolutely no hint that's a bad idea. For 4408bis we should be > honest and provide realistic guidance. Any solution we select should include at least that, in my opinion. -MSK From johnl@iecc.com Sun Feb 26 09:11:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A311F21F85FD for ; Sun, 26 Feb 2012 09:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.036 X-Spam-Level: X-Spam-Status: No, score=-110.036 tagged_above=-999 required=5 tests=[AWL=1.163, 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 AMkmiBQsDNbM for ; Sun, 26 Feb 2012 09:11:18 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id F0AB621F85CC for ; Sun, 26 Feb 2012 09:11:07 -0800 (PST) Received: (qmail 6559 invoked from network); 26 Feb 2012 17:11:06 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Feb 2012 17:11:06 -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=4f4a67aa.xn--9vv.k1202; i=johnl@user.iecc.com; bh=maJdkdzG1cAETy6ua97PkAqL9PWXF048OYmKxAI2bvo=; b=J3YGtSR5e2fmtTm0yfNKsoWWxY2ewDA1hXKxq3SaGsvwwrSlhbl8n0wr+b5duSNip4v6ht6aYTIdQxDuoNMTnHnTgaqiOsHsBn0ygXWP3/ncXwgPLojb5DR0IbFPKtPDVaQ/3YOkwYpldIwthvuCrpAdB58WWwfY5OCtF1gMlJM= 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=4f4a67aa.xn--9vv.k1202; olt=johnl@user.iecc.com; bh=maJdkdzG1cAETy6ua97PkAqL9PWXF048OYmKxAI2bvo=; b=EclseohP4tvoiOslq20hEin+di62LVmjpXjdkeF4Lcc6XZLD1a18rcwEin2hfRYyYaJ0kfKYrBScwun/XnUpAe2EjrQ157iP+WBtwyFxvkFdPnEu3YJECggVG4uxDfkP0SAs2xzg4g28oaT9HJArEkjB2y5ylUrfEZjlcyZhas4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 26 Feb 2012 17:10:44 -0000 Message-ID: <20120226171044.47320.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: msk@cloudmark.com Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 17:11:18 -0000 >Doesn't that mean that a server that publishes only TXT, and a client that queries only for SPF, or vice-versa for >that matter, are both fully compliant but will never actually interoperate? Sounds like a bug in the spec to me. I'd suggest opening an issue, but the fix is obvious once we decide about type 99. R's, John From dhc2@dcrocker.net Sun Feb 26 09:20:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EBE21F8543 for ; Sun, 26 Feb 2012 09:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.004 X-Spam-Level: X-Spam-Status: No, score=-6.004 tagged_above=-999 required=5 tests=[AWL=0.595, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpvbgkZAm4Ql for ; Sun, 26 Feb 2012 09:20:01 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8A121F84FC for ; Sun, 26 Feb 2012 09:20:01 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1QHJshH011091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Feb 2012 09:19:59 -0800 Message-ID: <4F4A69B1.6010802@dcrocker.net> Date: Sun, 26 Feb 2012 09:19:45 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org X-Priority: 2 (High) References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 26 Feb 2012 09:20:00 -0800 (PST) Cc: spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2012 17:20:01 -0000 On 2/24/2012 11:47 AM, S Moonesamy wrote: > Empirical evidence so far seems to indicate that there is a significant amount > of DNS queries for the SPF RR (TYPE 99) and some sites publish it. We have seen > arguments in favour of removing the feature, and in favour of retaining it. ... > Therefore, the WG Chairs would like to close Issue #9 with the conclusion that > the SPFBIS WG does not have consensus to remove the feature. > > Objections to this determination of consensus need to produce evidence that the > feature is not used, or that the removal of TYPE 99 is an enhancement that has > already gained widespread support. Please remember that the desirability of the > removal of the feature is not enough: the charter restricts our freedom to do > what we want here. The charter permits removal of unused features. SPF is widely deployed and has become integral to anti-abuse activities. It is a successful service. However the SPF RR feature is unused. Empirical data is consistently showing that it is widely used by clients (queriers) but virtually unused by servers (publishers). A protocol that has essentially nothing but clients is not a 'used' protocol. It takes two to tango for this mechanism. A protocol that has been unused after 6 years and is showing no signs of becoming used is not a viable protocol. Whatever problems are feared about the use of the TXT form of SPF record, they have not been demonstrated in six years. A widely used service, with six years of history, is a stable service. There is no evidence that its current form of use will change, nor any factors encouraging that change. The SPF RR is an unused capability. Removing it is a simplification that is straightforward and entirely justified. Having two mechanisms for the same purpose encourages bugs in code and variability in responses. I object to the characterization that the feature is used. I object to the form of the consensus call. Remove the feature. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Sun Feb 26 09:44:25 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AF321F84D4 for ; Sun, 26 Feb 2012 09:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.413, 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 jxTnNHfp3+XS for ; Sun, 26 Feb 2012 09:44:24 -0800 (PST) Received: from mail.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B8DAB21F84B5 for ; Sun, 26 Feb 2012 09:44:23 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2374; t=1330278259; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=bWXZ2cuQ3/uufGKavaDi6VWwA8s=; b=F0CBaVmY5dHji0a8eFBO Nk7AH9v+E4KK1bR3yZXasDoYjrNpD7RY49hBu4ISAi9Zd0JEzm02P/nThxKQRXBW tsjQu1PVKnP2T9XqTiJcUG7+Zll+sSbFqnW75D8efPYsbEOHTGcwKT/HOOgZRLjd VnSlDC9OdgxZKFg75oAF3uY= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 26 Feb 2012 12:44:19 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3480099822.92507.3928; Sun, 26 Feb 2012 12:44:18 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2374; t=1330278010; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=qOpRtnt OhSaFFRYsC2GxtKuNav97wTJXme0deZZWB00=; b=qK1s/mY8PW5Ea+aju9KuzJl lvE4FZvN/LIGrOh8wzxqNxZRIXulbcb53yDpLuTHl/STz87h7ABDW9WqrMNZho4W sIFEJlygsrqv3kx9t0PNIgdmmwigqURtxXbQpD+4sNPWR7DWhPont47T1QL9WUL2 ZwAiIGt93355Ko/59m7c= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 26 Feb 2012 12:40:10 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4079032564.19596.5908; Sun, 26 Feb 2012 12:40:09 -0500 Message-ID: <4F4A6F63.8050802@isdg.net> Date: Sun, 26 Feb 2012 12:44:03 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Barry Leiba References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> <6.2.5.6.2.20120225103447.09eefc78@resistor.net> <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> <4F49E931.6000902@isdg.net> <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 17:44:25 -0000 John Levine wrote: >> Doesn't that mean that a server that publishes only TXT, and a client that queries >> only for SPF, or vice-versa for that matter, are both fully compliant but >> will never actually interoperate? > > Sounds like a bug in the spec to me. I'd suggest opening an issue, > but the fix is obvious once we decide about type 99. +1. Barry Leiba wrote: > Murray says... >> RFC4408 (Section 3.1.1) says the server side SHOULD use both types, and >> MUST use at least one type. It also (Section 4.4) says that clients can >> query one type, the other type, or both. >> >> Doesn't that mean that a server that publishes only TXT, and a client that >> queries only for SPF, or vice-versa for that matter, are both fully >> compliant but will never actually interoperate? >> > > Scott says... > >> The reason some domains publish Type SPF only is that RFC 4408 gives them >> absolutely no hint that's a bad idea. For 4408bis we should be honest and >> provide realistic guidance. >> > > These two statements make a pretty compelling case that there is, indeed, > an error in RFC4408. There are, of course, multiple ways to resolve it, > and I have no immediate opinion on which is best. I don't quite see the error part of this, but rather the spec left it open ended in how to apply the new "infrastructure based decision" RR type being considered. Seems to be like the right SPF-BIS material to write But right now, I think the question is related to the DNS "optimization" decision to even consider it in the first place and whether if we should continue to consider it. I don't agree it should be solely based on "goal searching" basis of low usage where there is clear evidence it is. In other words, I personally would like to see what the overall IETF and DNS community mindset is regarding the general consideration of using specific RR types. It seems the mindset has changed to one that using TXT records is perfectly ok to use, coupled with concerns that using RR types is just too problematic (not seeing myself how outside RFC3597) If that is the case, then I personally agree, go for the simplicity and nix it. But if the ideal is still there, then I think the maturity of using it should continue. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Sun Feb 26 10:08:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E834F21F85DA for ; Sun, 26 Feb 2012 10:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.409, 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 adkuYFycymMk for ; Sun, 26 Feb 2012 10:08:46 -0800 (PST) Received: from mail.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 90AC621F853A for ; Sun, 26 Feb 2012 10:08:45 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=812; t=1330279719; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=nsp+DunJDnzUFsqe3hCZP9UOi3s=; b=JaSJWjo4dTAWBWpwD+yx oJG2xgyRdfMvVh3dEjmZYP20p1xngTGS8eMjGlj7Dc7hDQVSgz53NTe5FS7bwgRF uSXyePfuc+VnKT5S+25VHqTmHvBqu2cNbSAieG7ctIdhZ9UZa30fby6zLCIP41BB G7ragLHfVRKgjIbm5cCeh18= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 26 Feb 2012 13:08:39 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3481559944.92507.3932; Sun, 26 Feb 2012 13:08:38 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=812; t=1330279470; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=nV7QlRQ 2LhNgHGsNmwTHZp0LSg+/9Kz2cHgehyI7qwI=; b=LE0pXBqEFY17G5QZ6sVCqdU JPhOwUkRezp5FeLZiKwAVF1pqFoidyf4F83VjRu/N7iBAPxP0PIyIUWgay7r62OE Kh5s0IZoB9x1wxrcC8AzNuJQ3hjSNZHX3EUjdfn4Cm0nuE0oyiuoum4Jl+B+UhrU P2WWph7cSaKYur2zeK1Y= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 26 Feb 2012 13:04:30 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4080492314.19598.2764; Sun, 26 Feb 2012 13:04:28 -0500 Message-ID: <4F4A7517.40909@isdg.net> Date: Sun, 26 Feb 2012 13:08:23 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A69B1.6010802@dcrocker.net> In-Reply-To: <4F4A69B1.6010802@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 18:08:47 -0000 Dave CROCKER wrote: > > The charter permits removal of unused features. > > SPF is widely deployed and has become integral to anti-abuse > activities. It is a successful service. > > However the SPF RR feature is unused. > > Empirical data is consistently showing that it is widely used by clients > (queriers) but virtually unused by servers (publishers). > > A protocol that has essentially nothing but clients is not a 'used' > protocol. It takes two to tango for this mechanism. If this is the case, then the migration expected is on par; first get clients to support it and then declare it safe for publishers to drive the (new) road: "Ok Folks, the BAR is OPEN, start publishing SPF type records." -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From sm@elandsys.com Sun Feb 26 10:23:09 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF16621F8584 for ; Sun, 26 Feb 2012 10:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 8STw2gAjVcHF for ; Sun, 26 Feb 2012 10:23:08 -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 3D13D21F855B for ; Sun, 26 Feb 2012 10:23:08 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.234.238]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1QIMgXS025670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Feb 2012 10:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330280577; i=@elandsys.com; bh=ZzhW0Nez3yGOX20IOijMaYS+XQlO6kmmKNuvGshUqfg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=R3kJDK40I5BWOQSqWCXitRfFwOna4PGmwjVCSbp3AWn8rK5Mt0tTwpEOlTlNCRBoN 0g5t+5n7QGTLxxrhhVMHPbVyW2hUdjx8DK0ZlTvk75BOjm3YqlyS7Gf8IJZmcxvjcm zdIoVUyRzvEqNr37IjJ2UdFoqxSZknfY5pxfq3Zs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330280577; i=@elandsys.com; bh=ZzhW0Nez3yGOX20IOijMaYS+XQlO6kmmKNuvGshUqfg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=IRjdXX6TBVsAHBMvld8zvQbfgnmHyTo6kY6+PnTqDpnwmkLeLgM+VZ+J/b4rh2vFD dQ8YQR3B7fhcec+xvKPf8dW8V7cyDk54VDuNf5q1qNsn1W4NCuOJQHtTHSStSGjx2g XJ+FuDIsggBnjal3H1d83h0dyco2uXyG8WDXAdG4= Message-Id: <6.2.5.6.2.20120226095636.0a2ce360@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 X-Priority: 2 (High) Date: Sun, 26 Feb 2012 10:17:42 -0800 To: dcrocker@bbiw.net From: S Moonesamy In-Reply-To: <4F4A6721.50901@dcrocker.net> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A6721.50901@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan , spfbis@ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 18:23:10 -0000 Hi Dave, At 09:08 26-02-2012, Dave CROCKER wrote: >The charter permits removal of unused features. > >SPF is widely deployed and has become integral to anti-abuse >activities. It is a successful service. > >However the SPF RR feature is unused. > >Empirical data is consistently showing that it is widely used by >clients (queriers) but virtually unused by servers (publishers). > >A protocol that has essentially nothing but clients is not a 'used' >protocol. It takes two to tango for this mechanism. > >A protocol that has been unused after 6 years and is showing no >signs of becoming used is not a viable protocol. > >Whatever problems are feared about the use of the TXT form of SPF >record, they have not been demonstrated in six years. > >A widely used service, with six years of history, is a stable >service. There is no evidence that its current form of use will >change, nor any factors encouraging that change. > >The SPF RR is an unused capability. Removing it is a simplification >that is straightforward and entirely justified. > >Having two mechanisms for the same purpose encourages bugs in code >and variability in responses. > >I object to the characterization that the feature is used. I object >to the form of the consensus call. > >Remove the feature. Andrew and I will discuss about the objections you raised above. Regards, S. Moonesamy SPFBIS WG co-chair From agthisell@yahoo.com Sat Feb 25 19:39:11 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D794A21F85CD for ; Sat, 25 Feb 2012 19:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.316 X-Spam-Level: X-Spam-Status: No, score=0.316 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+em9UM05moC for ; Sat, 25 Feb 2012 19:39:11 -0800 (PST) Received: from nm18-vm0.bullet.mail.ne1.yahoo.com (nm18-vm0.bullet.mail.ne1.yahoo.com [98.138.91.37]) by ietfa.amsl.com (Postfix) with SMTP id 1111921F8507 for ; Sat, 25 Feb 2012 19:39:10 -0800 (PST) Received: from [98.138.90.52] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 26 Feb 2012 03:39:07 -0000 Received: from [98.138.89.161] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 26 Feb 2012 03:39:07 -0000 Received: from [127.0.0.1] by omp1017.mail.ne1.yahoo.com with NNFMP; 26 Feb 2012 03:39:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 835689.8409.bm@omp1017.mail.ne1.yahoo.com Received: (qmail 59143 invoked by uid 60001); 26 Feb 2012 03:39:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1330227547; bh=NLzQj9psa1j0oxptgySxMtloCriJh9LMIxQc63eQMIo=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=SGwDdp+U3JFWcH+6tQDKl1rkIl2eA2KWtqKRhvEVTZat7ahCXfETdzSk42wWeIU1q6aXbe0GxlZt3oAS6ajWmAHyezRl5jsEeWnkBlUymr/OKvZJSVgSUt+qtCfVvt2Uol+oG2hmMw4IZBUy+rDwxshmg0Rd1Kt8I7dn9O4DJ4I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=Cu9oLk6InBX0XKXWkJ9p3yVqUwrKrtdlopoqyBPUnUsWkJh3VctHWWZ2uEKVaPb3eQZ1Ho3meUBYKAs9bp3J0UYtEr3fPpFgI1cKPRBEf8vmy+7gmL75ePTb3K10R2dYT85ndAq34tCNsjpYEjLissak/w4hPOPMZSFDeBkVf6o=; X-YMail-OSG: xHs8loQVM1mAedkRrRKeJe43WsOS_2RadlCf4yPy45Ecak_ oDsGePkXNR6CWI1wzH4IEcAsnjRv.FbhzdfTHWzjIBqCIzsK4nmKolypR1CY movFBWGRpfiB.Mi9.duDFvRM1X7jo3FZ8QuoxFRRHzFze1gDffytE_GwILfh 1uQgDZlcE94ALVoBCjzsOygygXBdg6THy6o1Y.i0A1lmRPQQ6uSxkiBNJIZf DV247QkwMRLYsPwuvlYMbYyqk98.jWlzx.Sls_I6OGTvipDEPI4LBO7eF07h VSxcxC73q3uUH.rZvAUYGcVr0Euq70NxC6fj0pXEb80MjTvHgjRuhJbMSghs N0cUI3kqndQ58H927Q1DL3M5KEDvVty8wWFAOqc3_ERkHcw48sXKeTEbb9zp 3qWHftYeSc40ygXubAVmEP7xFPHqcfCBOK_frAsUNJbQEXFc9TOlPQN3HASA 0Tji4fPlk75Nx4svX6gcFQPnP0IBaTQBfvFPiQtBhnbzAVkC9uNOvDDYTDGU 66yIfrLT9WhB5j1brmA-- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Sat, 25 Feb 2012 19:39:07 PST X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.116.338427 Message-ID: <1330227547.58790.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Sat, 25 Feb 2012 19:39:07 -0800 (PST) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 19:57:53 -0000 If a tree falls in the middle of a forest, does it make a sound? SPF is a protocol, a way of communicating between people. SPF uses two channels for this communication, TXT and type 99 records. It doesn't matter if there are giga-packets per second querying type 99 records, if there are very few type 99 records published, then that channel isn't being used to communicate. There may be noise on that channel, but that's irrelevant. It doesn't matter if there are millions of SPF records publish (TXT and type 99) and millions of queries for SPF records. If all the queries actually go to domains that do not publish SPF records, then there isn't any communication going on and the whole SPF experiment is a failure and should be abandoned. I'm not being flippant here. One of the original complaints about SPF (even before MARID was created) was that there would be a lot of extra DNS traffic with no real way of even opting out, let alone opting in. The worst case is some small domain gets joe-jobbed to a very wide number of other domains and all these domains do SPF queries, swamping the small domain. There isn't anything the small domain can really do either, caching doesn't help because all the requests are coming from different sources. Based on everything I've seen posted, the type 99 record is not used, it is just noise As far published records, I'm surprised no one has mentioned the results on http://www.openspf.net/Statistics and The Masurement Factory in particular. There newest survey of SPF records is from Oct 2010, but it documents rates of changes in publishing over the years. From msk@cloudmark.com Sun Feb 26 12:58:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6C221F8542 for ; Sun, 26 Feb 2012 12:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 D5rZIJjJqTii for ; Sun, 26 Feb 2012 12:58:56 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 46D7721F8534 for ; Sun, 26 Feb 2012 12:58:56 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Sun, 26 Feb 2012 12:58:55 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM9GEhgW7KfGf6bU6SwZXEWCVulZZP2b6AgAAF2gD//8l0IA== Date: Sun, 26 Feb 2012 20:58:54 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928047BAB@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> <6.2.5.6.2.20120225103447.09eefc78@resistor.net> <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> <4F49E931.6000902@isdg.net> <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 20:58:56 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dotzero > Sent: Sunday, February 26, 2012 8:10 AM > To: Barry Leiba > Cc: spfbis@ietf.org > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issu= e #9) >=20 > > These two statements make a pretty compelling case that there is, > > indeed, an error in RFC4408. =A0There are, of course, multiple ways to > > resolve it, and I have no immediate opinion on which is best. >=20 > +1 Assuming we agree on that, then is it reasonable to assume the argument aga= inst changing due to the need to touch the installed base is no longer vali= d? That is, if we agree there's a bug, then we agree they'll need to upgra= de (once we decide what the fix is). From spf2@kitterman.com Sun Feb 26 14:20:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F5221F84F2 for ; Sun, 26 Feb 2012 14:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8x2=0.246] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhjvhG2Fzm7x for ; Sun, 26 Feb 2012 14:20:36 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCD221F84F8 for ; Sun, 26 Feb 2012 14:20:35 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id A112AD04083; Sun, 26 Feb 2012 16:20:32 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330294832; bh=OhcI0FcVg0ABxYzi8OY1D8AF2RBkCQEP0YwEfu40y50=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=KzB7L1bPCapHPUJ65G7c2DeaGOuTYp+kAr3xnM5vvbIHkbcohWlZPfhaFsx/+zLY8 uMjYsxD0tuvlKZYAAgwsOupQ1JTDo4z/3RgyfBwFRlW+xGjb+n1CSyQQsQsMnR7hF9 8GSaxSh0g1J2bitMxY4J7LM1Onkfk7RlTINEkf7Q= Received: from 164.sub-97-243-67.myvzw.com (164.sub-97-243-67.myvzw.com [97.243.67.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6C2B7D04062; Sun, 26 Feb 2012 16:20:31 -0600 (CST) References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> <6.2.5.6.2.20120225103447.09eefc78@resistor.net> <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> <4F49E931.6000902@isdg.net> <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> <9452079D1A51524AA5749AD23E003928047BAB@exch-mbx901.corp.cloudmark.com> User-Agent: K-9 Mail for Android In-Reply-To: <9452079D1A51524AA5749AD23E003928047BAB@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 26 Feb 2012 17:20:38 -0500 To: "spfbis@ietf.org" Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] =?utf-8?q?Call_for_intermediate_consensus_on_SPF_RRTYPE?= =?utf-8?b?CShpc3N1ZQkjOSk=?= X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 22:20:37 -0000 "Murray S. Kucherawy" wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On >Behalf Of Dotzero >> Sent: Sunday, February 26, 2012 8:10 AM >> To: Barry Leiba >> Cc: spfbis@ietf.org >> Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE >(issue #9) >> >> > These two statements make a pretty compelling case that there is, >> > indeed, an error in RFC4408.  There are, of course, multiple ways >to >> > resolve it, and I have no immediate opinion on which is best. >> >> +1 > >Assuming we agree on that, then is it reasonable to assume the argument >against changing due to the need to touch the installed base is no >longer valid? That is, if we agree there's a bug, then we agree >they'll need to upgrade (once we decide what the fix is). It's clear there's a bug. I don't think there's any basis for assuming the fix will affect the installed base that have published records that can be expected to be interpreted reliably. I think anyone publishing Type SPF only is doing it wrong. They were likely led astray by this bug in the spec. That's not at all the same as removing features that are in use and working as designed. Scott K From hsantos@isdg.net Sun Feb 26 15:13:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C706B21F8554 for ; Sun, 26 Feb 2012 15:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=-0.947, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_46=0.6, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0apkr-tF8zT9 for ; Sun, 26 Feb 2012 15:13:35 -0800 (PST) Received: from secure.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6E04C21F84FD for ; Sun, 26 Feb 2012 15:13:35 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3965; t=1330298010; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=75e/bAjM+LtonoX0ZywYOCbfS7M=; b=A5yisL8B8kv3oCE68RDM /VkqA+gaOZhnDcFBLIdfnkxRZbWBlrnapWHEJOZ5692ytheWwYB9WwMpcE/SbNc2 yQci2i/Jujhkae3+Y8xpyxifj1PPtaseETBhrn0VyK34SbV4bZKCkKVCuhCGj4Q/ EAOuMuL6eDFcP4stoUZkd6s= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 26 Feb 2012 18:13:30 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3499850219.92507.4116; Sun, 26 Feb 2012 18:13:29 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3965; t=1330297763; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=CEhs6kw K6T0B24vEEY3kN6ybjlvSQ6mnWXPzhYPH4PY=; b=TltHGyYFhZEZ8OrU5hPUFpZ rcGWoInLh64yQ/7nSGKIvobLbVSPonk9XxslXoNC3c1m5CXQ8QxfNWx2vrjbZUyA ChFlm08WNCAmdRUZgMzp61JbrZH199T1DXbDsdc4Xq+qfjyfPSKTUdXkzIn2BWTB aDmr2riBBDo42zi+sMAs= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 26 Feb 2012 18:09:23 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4098785454.19632.6932; Sun, 26 Feb 2012 18:09:22 -0500 Message-ID: <4F4ABC8C.4090004@isdg.net> Date: Sun, 26 Feb 2012 18:13:16 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: "spfbis@ietf.org" References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> <6.2.5.6.2.20120225103447.09eefc78@resistor.net> <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> <4F49E931.6000902@isdg.net> <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> <9452079D1A51524AA5749AD23E003928047950@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928047950@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Feb 2012 23:13:36 -0000 Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Scott Kitterman >> Sent: Sunday, February 26, 2012 12:32 AM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) >> >>> The query MUSH|SHOULD start with SPF type first. If it fails (what is >>> fail here?) fall back to TXT. Whether its done sync or async, IMO, the >>> end result we want needs to be the same. >> This is based on wishful thinking. >> >> MUST/SHOULD Type SPF first is a wasteful design approach meant use a >> spec to push people to do something operationally suboptimal in order >> to satisfy some theoretical architectural construct. > > It is indeed the case that the DKIM SHA1/SHA256 stuff was intended a transition > mechanism. We've also seen that even newer signers use the old way (gmail.com, > for instance, uses rsa-sha1 last I checked). Yes, and so have many others as well. SHA1 has the widest (guaranteed?) support, but overall simpler, lesser overhead. > But also I don't think the DKIM analogy works because both variants of DKIM > signing are contained within a single communication mechanism, i.e., the > signature header field. The similarity I believe is the idea of a publisher just using SHA256 signatures. For the same concerns regarding the expected short term dearth of supportive clients , DKIM had a less than desirable "higher bandwidth and complexity overhead" consideration for using two signatures for operations that looked for the highest security with the widest backward compatible lower security support. Only with direct targeting could the single SHA256 signature be effective. > Changing the normative text but keeping both types would also not address > the problem of DNS provisioning systems that can't handle type 99 records. Would help if you can take a moment to explain this. Does this relate to the known RFC3597 issues, more probable and expected in yesteryears? Is the known early short term issue to be corrected with the expected updating of DNS server still a problem today, at the same numbers? If so, then to me, this is a no brainer. If no one expects or believes there would also be a significant # of DNS servers that will never support the passthru processing of unnamed types, then I believe it makes this idea of nixing it much more plausible. >> The reason some domains publish Type SPF only is that RFC 4408 gives >> them absolutely no hint that's a bad idea. For 4408bis we should be >> honest and provide realistic guidance. > > Any solution we select should include at least that, in my opinion. Isn't this what SPF-BIS is looking for? To codified the parts that isn't well understood or needs to better explain all trade offs? For me Murray, I would like to see if you can find out what is the general IETF/DNS community attitude today about using specific RR types for new protocols because I thought one of the reasons for considering it was to help with the IETF/DNS endorsement with the "presumed, perceived" idea it would fit better for large scale DNS usage. Has that changed? Just seems to me what we expected has materialized, getting the clients to support both new and old types first was a prerequisite because the spec can comfortable begin suggesting that using SPF type published record was technically feasible. I was really surprise to even see there was significant dual type support by the client. But what expected had materialized and I believe SPF-BIS should now go to the next step to prepare for the publishing migration. For the record, I go with either way. Just wish to see a reason that is no longer preferred as opposed that no one expected to published SPF type records at this point. Thanks -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From julian@mehnle.net Sun Feb 26 16:48:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B42D21F8595 for ; Sun, 26 Feb 2012 16:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93fPM82eGF2h for ; Sun, 26 Feb 2012 16:48:27 -0800 (PST) Received: from io.link-m.de (io.link-m.de [82.135.8.34]) by ietfa.amsl.com (Postfix) with ESMTP id 56AEF21F8594 for ; Sun, 26 Feb 2012 16:48:27 -0800 (PST) Received: from [10.0.2.15] (50-0-128-85.dsl.dynamic.sonic.net [::ffff:50.0.128.85]) (AUTH: CRAM-MD5 julian@mehnle.net, TLS: TLSv1/SSLv3, 256bits, AES256-SHA) by io.link-m.de with esmtp; Mon, 27 Feb 2012 00:48:25 +0000 id 0000000000226863.000000004F4AD2D9.0000079F From: Julian Mehnle To: spf-discuss@listbox.com, spfbis@ietf.org Date: Mon, 27 Feb 2012 00:39:34 +0000 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart26089436.3J9k43AyX1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201202270039.39954.julian@mehnle.net> Subject: [spfbis] FYI: openspf.org working again X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 00:48:28 -0000 --nextPart26089436.3J9k43AyX1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, just a quick notice: A couple of months ago the SPF project's website at=20 went down and got temporarily replaced with a=20 copy at . We have now managed to restore the=20 site under the original domain, openspf.org. =2DJulian --nextPart26089436.3J9k43AyX1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAk9K0McACgkQwL7PKlBZWjtFDACg+Hlvr6tgrILTkF9yblM8kB1V EpoAnRAe/P79fV91KCEp5SRtd+tsJ/+f =HAPU -----END PGP SIGNATURE----- --nextPart26089436.3J9k43AyX1-- From SRS0=7LKyr=BF==stuart@gathman.org Sun Feb 26 17:10:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C581821F84FD for ; Sun, 26 Feb 2012 17:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 n5BZESOGRb-k for ; Sun, 26 Feb 2012 17:10:21 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [24.248.44.156]) by ietfa.amsl.com (Postfix) with ESMTP id A24D421F8504 for ; Sun, 26 Feb 2012 17:10:21 -0800 (PST) Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q1R17VQR028798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Feb 2012 20:07:32 -0500 Message-ID: <4F4AD783.5060402@gathman.org> Date: Sun, 26 Feb 2012 20:08:19 -0500 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A69B1.6010802@dcrocker.net> In-Reply-To: <4F4A69B1.6010802@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 01:15:25 -0000 Long ago, Nostradamus foresaw that on 02/26/2012 12:19 PM, Dave CROCKER would write: > > A protocol that has been unused after 6 years and is showing no signs > of becoming used is not a viable protocol. > You are correct about prospects of active use in v=spf1. However, I support keeping it in spfbis for two reasons: 1) those 1% of publishing domains (including mine) help to keep the record type healthy and working for v=spf3. 2) minimal changes to the SPEC From dotzero@gmail.com Sun Feb 26 17:40:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78B221F84EA for ; Sun, 26 Feb 2012 17:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkwWMDV3z7Q5 for ; Sun, 26 Feb 2012 17:40:58 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 37A1021F84CD for ; Sun, 26 Feb 2012 17:40:58 -0800 (PST) Received: by pbcwz17 with SMTP id wz17so172532pbc.31 for ; Sun, 26 Feb 2012 17:40:58 -0800 (PST) Received-SPF: pass (google.com: domain of dotzero@gmail.com designates 10.68.190.8 as permitted sender) client-ip=10.68.190.8; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dotzero@gmail.com designates 10.68.190.8 as permitted sender) smtp.mail=dotzero@gmail.com; dkim=pass header.i=dotzero@gmail.com Received: from mr.google.com ([10.68.190.8]) by 10.68.190.8 with SMTP id gm8mr34114690pbc.146.1330306858122 (num_hops = 1); Sun, 26 Feb 2012 17:40:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BEmLVlXPwguFc/7RQjX84jVNNNiLv1q+Wc0PPBYCdbM=; b=Opu9hdXzU5VVKsQGaUiF2WLAbeNLe6yzGQsAjEcbGIOzr8cuork6BVKAxHXHf7CQ14 Tw2F9IbCo5EJWXf7SvJ5NWOLvG7BszTVQ+irWk+CBgVkHjOTiXIIaaIPMXRawUhhuN76 iDkzSpc4wkCSiaeo+tlOQrmc1YDGX3dGgHPXw= MIME-Version: 1.0 Received: by 10.68.190.8 with SMTP id gm8mr29122465pbc.146.1330306858045; Sun, 26 Feb 2012 17:40:58 -0800 (PST) Received: by 10.68.35.198 with HTTP; Sun, 26 Feb 2012 17:40:57 -0800 (PST) In-Reply-To: <9452079D1A51524AA5749AD23E003928047BAB@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> <6.2.5.6.2.20120225103447.09eefc78@resistor.net> <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> <4F49E931.6000902@isdg.net> <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> <9452079D1A51524AA5749AD23E003928047BAB@exch-mbx901.corp.cloudmark.com> Date: Sun, 26 Feb 2012 20:40:57 -0500 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 01:40:58 -0000 On Sun, Feb 26, 2012 at 3:58 PM, Murray S. Kucherawy wr= ote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf= Of Dotzero >> Sent: Sunday, February 26, 2012 8:10 AM >> To: Barry Leiba >> Cc: spfbis@ietf.org >> Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (iss= ue #9) >> >> > These two statements make a pretty compelling case that there is, >> > indeed, an error in RFC4408. =A0There are, of course, multiple ways to >> > resolve it, and I have no immediate opinion on which is best. >> >> +1 > > Assuming we agree on that, then is it reasonable to assume the argument a= gainst changing due to the need to touch the installed base is no longer va= lid? =A0That is, if we agree there's a bug, then we agree they'll need to u= pgrade (once we decide what the fix is). > > I think it would be reasonable to make this assumption. It would also be reasonable to assume that we will see un-upgraded implementations for quite some time. Mike From dhc@dcrocker.net Sun Feb 26 18:30:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0B921E8010 for ; Sun, 26 Feb 2012 18:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2e+aiugvUng for ; Sun, 26 Feb 2012 18:30:03 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE4221E800F for ; Sun, 26 Feb 2012 18:30:03 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1R2TpC1018435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Feb 2012 18:29:56 -0800 Message-ID: <4F4AEA95.2000400@dcrocker.net> Date: Sun, 26 Feb 2012 18:29:41 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Stuart Gathman References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A69B1.6010802@dcrocker.net> <4F4AD783.5060402@gathman.org> In-Reply-To: <4F4AD783.5060402@gathman.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 26 Feb 2012 18:29:56 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 02:30:04 -0000 On 2/26/2012 5:08 PM, Stuart Gathman wrote: > Long ago, Nostradamus foresaw that on 02/26/2012 12:19 PM, Dave CROCKER > would write: >> >> A protocol that has been unused after 6 years and is showing no signs >> of becoming used is not a viable protocol. >> > You are correct about prospects of active use in v=spf1. However, I > support keeping it in spfbis for two reasons: Just to establish a stable platform: you are agreeing that the RR is (essentially) unused. > 1) those 1% of publishing domains (including mine) help to keep the > record type healthy and working for v=spf3. I've no idea what you mean by "keep the record type healthy". Absent some indication that this small usage is actually essential to some market segment, the nearly-nil adoption means it is not healthy now. As for v=spf3, there is no such work envisioned, and nothing need be done now, to permit adding it later. Keeping the current SPF RR does not "reserve" or "preserve" anything substantive. > 2) minimal changes to the SPEC You are invoking a rule that would mean only making changes to things that are causing serious problems. Sometimes, such a rule is appropriate, but this is not one of them. Making the specification cleaner and clearer, by removing (essentially) unused features is at least as beneficial as minimizing changes. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From SRS0=7LKyr=BF==stuart@gathman.org Sun Feb 26 19:43:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB38B21F849D for ; Sun, 26 Feb 2012 19:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-GL1fZ8W975 for ; Sun, 26 Feb 2012 19:43:47 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [24.248.44.156]) by ietfa.amsl.com (Postfix) with ESMTP id 0C20121F849C for ; Sun, 26 Feb 2012 19:43:46 -0800 (PST) Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q1R3et7T030127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Feb 2012 22:40:56 -0500 Message-ID: <4F4AFB77.3040607@gathman.org> Date: Sun, 26 Feb 2012 22:41:43 -0500 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A69B1.6010802@dcrocker.net> <4F4AD783.5060402@gathman.org> <4F4AEA95.2000400@dcrocker.net> In-Reply-To: <4F4AEA95.2000400@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 03:43:47 -0000 Long ago, Nostradamus foresaw that on 02/26/2012 09:29 PM, Dave CROCKER would write: > > > On 2/26/2012 5:08 PM, Stuart Gathman wrote: >> Long ago, Nostradamus foresaw that on 02/26/2012 12:19 PM, Dave CROCKER >> would write: >>> >>> A protocol that has been unused after 6 years and is showing no signs >>> of becoming used is not a viable protocol. >>> >> You are correct about prospects of active use in v=spf1. However, I >> support keeping it in spfbis for two reasons: > > Just to establish a stable platform: you are agreeing that the RR is > (essentially) unused. > > >> 1) those 1% of publishing domains (including mine) help to keep the >> record type healthy and working for v=spf3. > > I've no idea what you mean by "keep the record type healthy". Absent > some indication that this small usage is actually essential to some > market segment, the nearly-nil adoption means it is not healthy now. > > As for v=spf3, there is no such work envisioned, and nothing need be > done now, to permit adding it later. Keeping the current SPF RR does > not "reserve" or "preserve" anything substantive. Support for SPF RR has just appeared in RHEL6 in the last year. Adoption of support in server platforms has been slow. (Yes, you could use the kludgy TYPE99 in earlier bind versions and code the bytes in HEX, and I've been doing that with a script to copy SPF TXT records - but no production shop is likely to do that.) If you stop the pressure now, then when we get around to v=spf3, there will *still* be no supported RR available, and it will be back to TXT records again. I would really like to have v=spf3 specify MUST use SPF RR and MUST NOT use TXT record. Given that server support is just now appearing in conservative platforms, it is only now that publishing support could start to pick up. And if we drop the RR, all the progress is for naught. So I support keeping the SPF RR in spfbis, even if the main benefit is to have it ready and SUPPORTED for v=spf3. From johnl@iecc.com Sun Feb 26 20:20:11 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CA621E8019 for ; Sun, 26 Feb 2012 20:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.072 X-Spam-Level: X-Spam-Status: No, score=-110.072 tagged_above=-999 required=5 tests=[AWL=1.127, 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 zvbzOFbAjIlT for ; Sun, 26 Feb 2012 20:20:10 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E41A121E800F for ; Sun, 26 Feb 2012 20:20:09 -0800 (PST) Received: (qmail 10787 invoked from network); 27 Feb 2012 04:20:07 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 Feb 2012 04:20:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f4b0477.xn--i8sz2z.k1202; i=johnl@user.iecc.com; bh=bsz7opykC6ZqVHfoSsbYjGB534ZOK65UmXPiUijTfJI=; b=OLDnRCL6EjYDIfKfusjYlZfzKCtof7ILkVkgBUuD4/1vfNH4ZQGSHWinTP0ZKrBObz604Gh17421HJd5hj/MTtCtdGEYJ6ptdSLtRSMErr0sNh4XC1ArbGB6gxwSe5n+p9Kc1X3DDhomL5DePkddC0PIUgE56ikDbJ4buYr3j4A= 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=4f4b0477.xn--i8sz2z.k1202; olt=johnl@user.iecc.com; bh=bsz7opykC6ZqVHfoSsbYjGB534ZOK65UmXPiUijTfJI=; b=yom0Kp97wU68t/LMG3Dzq1IuJYcn8BTxAPaQr8sqWoJy8z3lX4jaRbrzlMSI7npsLl6H7iHdrN4eC+5CQ2dHIbSTpmBBIpwCQFvYjXQ/KF/Tdh2T2yoJGsmp7C7LYMEFAt0P/CbKrNQOH/kyRjcd36OdxqC0IBcrOc7LZzCw4ko= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 27 Feb 2012 04:19:45 -0000 Message-ID: <20120227041945.74394.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4F4AFB77.3040607@gathman.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: stuart@gathman.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 04:20:11 -0000 >Given that server support is just now appearing in conservative >platforms, it is only now that publishing support could start to pick >up. And if we drop the RR, all the progress is for naught. You're right, but so what? There are a lot more important RRs than SPF for the DNS crowd to worry about. And as I noted several messages ago, even if your DNS server has type 99 support, your provisioning system probably doesn't. In any event, I thought we were still making the list of issues. I know what I think the right thing to do about type 99 is (deprecate it), but I don't see us coming to agreement now. R's, John From sm@elandsys.com Sun Feb 26 23:27:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3144A21F8526 for ; Sun, 26 Feb 2012 23:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 5FbN0XwpUPPD for ; Sun, 26 Feb 2012 23:27:13 -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 EBF7A21F851D for ; Sun, 26 Feb 2012 23:27:12 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.238.109]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1R7Qtxp028411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Feb 2012 23:27:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330327630; i=@elandsys.com; bh=+BDNmhccQpPjJlib09m81D64KPSHpRq23XXSnxIc19g=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=bbv1x6jvat3DpUZqhIHDja7VsrTVWixQdeRxWA2vt8/SuD2YKxKf5RtEVI8RfTnib /aIrZfsBEkrSPyF7JtGCK0pxKcoDZXgUHmDCk41eBDNRiPkQFT4aPIxjOJKRpnLGu5 sr9/7EHek54imh9WkJJSp9FCxsyvLWqwTliUJM6I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330327630; i=@elandsys.com; bh=+BDNmhccQpPjJlib09m81D64KPSHpRq23XXSnxIc19g=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=luxXbGX1IXMt7Jwn+mGffCvVLhzUFmoNV8o1qSF2eVUmpsGknTL4UXNKJxMZeUny9 W3YzLgPN19ETRoIFFcmzdXdfGRxgZ0fq6A1Yy6R4AvCWLNwNdnbcUIxpsETlROm0cd qEoZpCa9dROi7QauMEfU8HBbv60nMFOKqOiBoL64= Message-Id: <6.2.5.6.2.20120226194659.08fe26e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 26 Feb 2012 23:18:48 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> <6.2.5.6.2.20120225103447.09eefc78@resistor.net> <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> <4F49E931.6000902@isdg.net> <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 07:27:15 -0000 Hello, There are 65 messages posted on this thread. Let me give you some feedback of what I see from the quoted text. This message is not intended to say that X is wrong or Y is right or that argument A is correct or B is incorrect. At 07:49 26-02-2012, Barry Leiba wrote: >Murray says... >RFC4408 (Section 3.1.1) says the server side SHOULD use both types, >and MUST use at least one type. It also (Section 4.4) says that >clients can query one type, the other type, or both. > >Doesn't that mean that a server that publishes only TXT, and a >client that queries only for SPF, or vice-versa for that matter, are >both fully compliant but will never actually interoperate? > > > Scott says... >The reason some domains publish Type SPF only is that RFC 4408 gives >them absolutely no hint that's a bad idea. For 4408bis we should be >honest and provide realistic guidance. > > >These two statements make a pretty compelling case that there is, >indeed, an error in RFC4408. There are, of course, multiple ways to >resolve it, and I have no immediate opinion on which is best. I read the errata posted for RFC 4408 and I added them to the tracker as issues. I did not see any report of an error in Section 3.1.1 of RFC 4408. It is up to this working group to make a compelling case that there is, indeed, an error in RFC 4408. I read the comments posted by Murray [1][2] in reply to the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg00638.html The message by John Levine [3] mentions: "Sounds like a bug in the spec to me. I'd suggest opening an issue, but the fix is obvious once we decide about type 99." Reading that over again, I see that I should have asked him whether to open an issue from the above. I read the message posted by Scott Kitterman [4]. For what it is worth, there is also Issue #25 [5] where SPF and TXT RRs are mentioned. As I don't have the faintest idea at the moment about Issue #25 (it is not open yet), I cannot provide any feedback. There are some parts of the quoted text on which I cannot provide feedback on for now due to the pending objections [6]. Pete Resnick posted a message on February 1 which had an interesting line: "Please review the below and see if there is anything that makes your head explode." I should have asked him about that. :-) He also mentioned [7]: "The fact of the matter is that if you all come up with an interpretation of this sentence: The working group will produce a document describing the course of the SPF/Sender-ID experiment, thus bringing that experiment to a formal conclusion." "If we come up with a reasonable interpretation of that deliverable, we'll be fine and I will defend it to the hilt." "with the caveat that the shepherd and/or I will be doing a document writeup, and (like the rest of the WG and the chairs, I hope) we will want to be able to document that the WG did its due diligence to come up with a justification for the conclusion of the experiment." My task, in collaboration with Andrew, is to determine consensus not override it. If it is the consensus of this working group that the sky is green, that's what goes in the document. I would like to be able to ask for a justification for that conclusion so as to be prepared for the questions which will be asked. If you see me asking a question, it is not because I doubt what you are saying. Regards, S. Mooneamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00645.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00646.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00657.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00651.html 5. http://trac.tools.ietf.org/wg/spfbis/trac/ticket/25 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg00658.html 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg00331.html From vesely@tana.it Mon Feb 27 04:37:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7D821F86EE for ; Mon, 27 Feb 2012 04:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.646 X-Spam-Level: X-Spam-Status: No, score=-4.646 tagged_above=-999 required=5 tests=[AWL=0.073, 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 cbZGYcxuovf0 for ; Mon, 27 Feb 2012 04:37:50 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4110E21F86EC for ; Mon, 27 Feb 2012 04:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1330346269; bh=wrwlx5CKCz40+yNJX7ULo1e2OUQmkX5ZP3X5fBWKqM8=; l=1463; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=iC3mEKFUSTeELj1u4vITLMlcc8A/hH3YloIDSS2/QfOr0ZR9u2P7RfaR+zlaK3coY chgOnncoJXa3+wGbC0xRt+apefX1ZqJHiZkpo3ESLNCPkT+YjbDhfvCnlwrtj0az6n 8Quw3hTbGFoV4b+vzBQjbosijh5zC8ZDUO1kaou0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 27 Feb 2012 13:37:49 +0100 id 00000000005DC039.000000004F4B791D.00002826 Message-ID: <4F4B791C.6020405@tana.it> Date: Mon, 27 Feb 2012 13:37:48 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A69B1.6010802@dcrocker.net> <4F4AD783.5060402@gathman.org> <4F4AEA95.2000400@dcrocker.net> <4F4AFB77.3040607@gathman.org> In-Reply-To: <4F4AFB77.3040607@gathman.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 12:37:51 -0000 On 27/Feb/12 04:41, Stuart Gathman wrote: > > Support for SPF RR has just appeared in RHEL6 in the last year. > Adoption of support in server platforms has been slow. (Yes, you > could use the kludgy TYPE99 in earlier bind versions and code the > bytes in HEX, and I've been doing that with a script to copy SPF > TXT records - but no production shop is likely to do that.) I'd guess they followed the rule to not fix something that is not broken. And the protocol works quite well without type 99. > If you stop the pressure now, then when we get around to v=spf3, > there will *still* be no supported RR available, and it will be > back to TXT records again. I would really like to have v=spf3 > specify MUST use SPF RR and MUST NOT use TXT record. Or will spf3 use _spf labels? Possibly, next version of DKIM will save space by letting data have binary format in its own RR type as well. Or maybe not. That is a DNS issue, not an SPF or DKIM one. > Given that server support is just now appearing in conservative > platforms, it is only now that publishing support could start to pick > up. And if we drop the RR, all the progress is for naught. > > So I support keeping the SPF RR in spfbis, even if the main benefit is > to have it ready and SUPPORTED for v=spf3. If DNS will have been fixed by then, it will be easier and more joyful to conceive a newborn type than to resuscitate a dead one. (That's a fact of nature :-) From hsantos@isdg.net Mon Feb 27 07:49:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2048721F879D for ; Mon, 27 Feb 2012 07:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBjx0H6k+wIK for ; Mon, 27 Feb 2012 07:49:09 -0800 (PST) Received: from groups.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D3DD121F879A for ; Mon, 27 Feb 2012 07:49:08 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3652; t=1330357741; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=LERXnNmc8FFuaWtySWz0Z6zpHC4=; b=lMct8JCVS7F9zhHYbh/k QPwdZ2oSgmsNMFUyxXg996IK0iSw/JwsXUpCMxkIcy7tdDg5pp5PN9kdTmWv5fFk TUOmzZXgaAoliYWnAIJUn+n5yqPHUhgZljB2tU5IBXK4uP7wuCXO+H1h7N97Etxy IB04rsOnzOkdYkZAsBqnoyY= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 10:49:01 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3559580834.93496.5072; Mon, 27 Feb 2012 10:49:00 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3652; t=1330357493; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=X/3OlzE pUjNW1P7VrCPjrDjtAvKt5oq6TdZyd9DsJio=; b=0cnBGRcymuI2217RvZGPSX/ bq5SdvVVYAnsRCENAFgJ1mxsBXNUIMxIgM5ULWwaMP6hyKV28rCuAFE1WetlkCDa 5HvYU666glPPi5B+XNHuRUK3zzCKgSbKxb4O5++tnxXsH+NddRxys+ba9z+R+VMc T91b5YVkcyJM7D5x4mY0= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 10:44:53 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4158515704.19719.7196; Mon, 27 Feb 2012 10:44:52 -0500 Message-ID: <4F4BA5E1.9060305@isdg.net> Date: Mon, 27 Feb 2012 10:48:49 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A69B1.6010802@dcrocker.net> <4F4AD783.5060402@gathman.org> <4F4AEA95.2000400@dcrocker.net> <4F4AFB77.3040607@gathman.org> <4F4B791C.6020405@tana.it> In-Reply-To: <4F4B791C.6020405@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: [spfbis] Is using new RR types still a valid consideration? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 15:49:10 -0000 From what I see, the question is really about if we deem the original consensus of exploring a new RR type was valid to begin with as an IETF/DNS Community endorsement appeasing and technologically better fit for DNS large scale usage. If we still don't believe that goal is no longer valid, that DNS is very robust today to any all the TXT junk and the reality is seen as such that there are too many RFC3597 servers out there, then perhaps we should nix type 99 on this basis. But the current view is to use highly subjective "Low Usage" and "Right Set of Users" and predictions "No one will use SPF type records" reasons to nix it. Thats will always be a form of friction. Either way, removal means change - moving it into a new state of unknowns, chaos, and new instability - using the "right set of users" concept to determine the triage impact. I don't think that will be a proper measurement here. SPF has gain world wide support as a NON-IETF developed protocol and its influent is strongly due to the super wide support by hobbiest to small operations. It was the bigger outfit that got on the bandwagon, not the other way around and I suspect that any decision based on "Who's Who" in the SPF world, well, is going to create a tremendous amount of bad PR for the IETF and contention with the SPF Council. Its going to be very tough to change and also mandate change by trying to retrofit SPF via SPF-BIS to work with AUTH-RES, DMARC, DKIM, REPORTING stuff, etc. Its already a tough challenge to attempt to integrate all of this. So I recognize the challenge it presents. In regards to the new RR type, I would like to know if that is still a valid approach for the sake of lowering SPF impact on DNS and also for getting IETF/DNS community endorsement. If not, then nixing it make its more plausible and comfortable to consider, for me. Alessandro Vesely wrote: > On 27/Feb/12 04:41, Stuart Gathman wrote: >> Support for SPF RR has just appeared in RHEL6 in the last year. >> Adoption of support in server platforms has been slow. (Yes, you >> could use the kludgy TYPE99 in earlier bind versions and code the >> bytes in HEX, and I've been doing that with a script to copy SPF >> TXT records - but no production shop is likely to do that.) > > I'd guess they followed the rule to not fix something that is not > broken. And the protocol works quite well without type 99. > >> If you stop the pressure now, then when we get around to v=spf3, >> there will *still* be no supported RR available, and it will be >> back to TXT records again. I would really like to have v=spf3 >> specify MUST use SPF RR and MUST NOT use TXT record. > > Or will spf3 use _spf labels? Possibly, next version of DKIM will > save space by letting data have binary format in its own RR type as > well. Or maybe not. That is a DNS issue, not an SPF or DKIM one. > >> Given that server support is just now appearing in conservative >> platforms, it is only now that publishing support could start to pick >> up. And if we drop the RR, all the progress is for naught. >> >> So I support keeping the SPF RR in spfbis, even if the main benefit is >> to have it ready and SUPPORTED for v=spf3. > > If DNS will have been fixed by then, it will be easier and more joyful > to conceive a newborn type than to resuscitate a dead one. > (That's a fact of nature :-) > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From sm@elandsys.com Mon Feb 27 10:25:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E0321F87FD for ; Mon, 27 Feb 2012 10:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.641 X-Spam-Level: X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7s6IXBKgGz7E for ; Mon, 27 Feb 2012 10:24:48 -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 3EB7B21F868C for ; Mon, 27 Feb 2012 10:24:48 -0800 (PST) Received: from SUBMAN.elandsys.com (ADSL-202-138.myt.mu [41.212.202.138] (may be forged)) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1RIOSsf017383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2012 10:24:38 -0800 (PST) Message-Id: <6.2.5.6.2.20120227102005.0aa56d18@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 27 Feb 2012 10:24:04 -0800 To: dcrocker@bbiw.net From: S Moonesamy In-Reply-To: <4F4A6721.50901@dcrocker.net> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A6721.50901@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 18:25:21 -0000 Hi Dave, There are currently 25 issues listed in the SPFBIS tracker ( http://trac.tools.ietf.org/wg/spfbis/trac/report/1 ). It would take at least 50 weeks to process the issues if there is a two-weeks consensus call on each and every issue. The Chairs are of the opinion that the working group would not meet the first milestone mentioned in the Charter if that path was followed. However, as the Chairs are also responsible to ensure that the working group operates in an open and fair manner, we can run a Consensus Call to determine whether the working group would like to proceed with a consensus call on each issue in the tracker. Does the above address your objection about "the form of the consensus call"? Regards. Andrew Sullivan & S. Moonesamy, SPFBIS WG Chairs From spf2@kitterman.com Mon Feb 27 10:36:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A15D21F87EC for ; Mon, 27 Feb 2012 10:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 qokTcnYsBPAm for ; Mon, 27 Feb 2012 10:36:19 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D56EB21F87E9 for ; Mon, 27 Feb 2012 10:36:19 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 00F5320E40E0; Mon, 27 Feb 2012 13:36:19 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330367779; bh=FXY484/X1MSYLKvKbg5FhSSZQseDChCKDRjRlNWz6Wk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=CUMAs7VrhUDWREmtI31VQmNRmLVVoh8m/XOtC6enaOvoUfYHauWZdJIImPLTaSOKJ aP3UFIZ7lzWFIXZXJbZ72FGQ2a9KBwWd+tsxkXnc7nYN3MO77cAOivc4FISuZO+/7T 3W58R2eFs8+gOaR79vRaJ7TWUT2MqOZDHzaAAojc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BFC1D20E40A4; Mon, 27 Feb 2012 13:36:18 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 27 Feb 2012 13:36:18 -0500 Message-ID: <1350366.UKdUXUDbyf@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120227102005.0aa56d18@elandnews.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A6721.50901@dcrocker.net> <6.2.5.6.2.20120227102005.0aa56d18@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 18:36:20 -0000 On Monday, February 27, 2012 10:24:04 AM S Moonesamy wrote: > Hi Dave, > > There are currently 25 issues listed in the SPFBIS tracker ( > http://trac.tools.ietf.org/wg/spfbis/trac/report/1 ). It would take > at least 50 weeks to process the issues if there is a two-weeks > consensus call on each and every issue. The Chairs are of the > opinion that the working group would not meet the first milestone > mentioned in the Charter if that path was followed. However, as the > Chairs are also responsible to ensure that the working group operates > in an open and fair manner, we can run a Consensus Call to determine > whether the working group would like to proceed with a consensus call > on each issue in the tracker. > > Does the above address your objection about "the form of the consensus > call"? You've arranged the way the group is to work by serializing the discussion of issues. There are only a handful that are likely to have serious discussion or doubt about where the consensus lies, but if the current process is too slow for you, have a look in the mirror. Scott K From john@jlc.net Mon Feb 27 11:26:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C22E21F87AF for ; Mon, 27 Feb 2012 11:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.421 X-Spam-Level: X-Spam-Status: No, score=-106.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-+b3dsXvcaU for ; Mon, 27 Feb 2012 11:26:43 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id B0CC321F857A for ; Mon, 27 Feb 2012 11:26:43 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2E14533C9A; Mon, 27 Feb 2012 14:26:43 -0500 (EST) Date: Mon, 27 Feb 2012 14:26:43 -0500 From: John Leslie To: Scott Kitterman Message-ID: <20120227192643.GC42092@verdi> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A6721.50901@dcrocker.net> <6.2.5.6.2.20120227102005.0aa56d18@elandnews.com> <1350366.UKdUXUDbyf@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1350366.UKdUXUDbyf@scott-latitude-e6320> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 19:26:44 -0000 Scott Kitterman wrote: > On Monday, February 27, 2012 10:24:04 AM S Moonesamy wrote: >> >> There are currently 25 issues listed in the SPFBIS tracker ( >> http://trac.tools.ietf.org/wg/spfbis/trac/report/1 ). It would take >> at least 50 weeks to process the issues if there is a two-weeks >> consensus call on each and every issue. (Actually, I'd be happy if I believed this issue would take _only_ two weeks...) >> The Chairs are of the opinion that the working group would not meet >> the first milestone mentioned in the Charter if that path was followed. That logic _seems_ unassailable... >> However, as the Chairs are also responsible to ensure that the working >> group operates in an open and fair manner, we can run a Consensus Call >> to determine whether the working group would like to proceed with a >> consensus call on each issue in the tracker. Please don't!!! >> Does the above address your objection about "the form of the consensus >> call"? That is for Dave to say. > You've arranged the way the group is to work by serializing the discussion > of issues. (This would appear to be addressed to the WGCs, but it might as well be addressed to Dave, or many of us.) > There are only a handful that are likely to have serious discussion > or doubt about where the consensus lies, Speaking for myself, I not merely doubt _where_ consensus on issue #9 lies -- I doubt there _is_ a consensus. Understand, I do not doubt how a _vote_ would go: I doubt there is a "consensus" in the IETF sense -- roughly speaking, "that all opinions have been fairly presented and considered". I continue to hear new material presented, and I continue to see many folk claiming it's not worth considering ideas contrary to their own. We can, of course, continue this until we reach "consensus by exhaustion". IMHO, consensus-by-exhaustion this early in a WG's work is a recipe for disaster, but I suppose YMMV. Or we could move on. I have a very simple suggestion for moving on. I've even shared it with the WGCs, who had no problem with it. I was expecting to post it today. But it doesn't look like we're _willing_ to move on. We seem to believe that this issue is so important that the other 24 will fall in place if we just resolve this one. I don't understand that belief. Please feel free to enlighten me -- but in private email please. > but if the current process is too slow for you, have a look in the mirror. Again, I suggest it's not only the WGCs that should look in the mirror. -- John Leslie From hsantos@isdg.net Mon Feb 27 11:53:14 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF61C21F871D for ; Mon, 27 Feb 2012 11:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.449, 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 FqMq7qvKO9wO for ; Mon, 27 Feb 2012 11:53:13 -0800 (PST) Received: from pop3.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5796221F8709 for ; Mon, 27 Feb 2012 11:53:12 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3830; t=1330372382; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=CuYtrguRONCUdNXC86fLuii5nTc=; b=m749RSWOxfCn5GOTo1fE 7sApIbdFO/8P1OCqL1EGTr1L65Kx/pEDznGcYOuP/O67FCGwgah3x9TO6taoSpnx qNX+xJMmgRx57q04kKO+JHD/1UCXksOB/dmFny7C2OrNoqiAzyRKkS8TkgR3c547 iJ3UH2LU8Kl5birNtV2dKbk= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 14:53:02 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3574221543.93496.920; Mon, 27 Feb 2012 14:53:01 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3830; t=1330372133; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Lx/LhtD yTw2VnW9YoFkyboDWumh2x9Unrmg0ihNpmQM=; b=CaYl63hvS7HrMr6wfn0IqWU 6oc2m41un98UTxeJVXzaV/odMbOZ+Wx284rRe8Wkb8bj8W1lc+NoW6gg4vQchiPS 1VpQ7TrfflQPtmc6Od2Da39+aAs/YLpzHzsBnovKeKUc7GZmtP+vAkgkYkVBq9zS 8Kpk9ACXdhOXyo80875E= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 14:48:53 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4173155970.19760.6104; Mon, 27 Feb 2012 14:48:52 -0500 Message-ID: <4F4BDF15.5090703@isdg.net> Date: Mon, 27 Feb 2012 14:52:53 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: John Leslie References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A6721.50901@dcrocker.net> <6.2.5.6.2.20120227102005.0aa56d18@elandnews.com> <1350366.UKdUXUDbyf@scott-latitude-e6320> <20120227192643.GC42092@verdi> In-Reply-To: <20120227192643.GC42092@verdi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 19:53:14 -0000 Well said Mr. Leslie. It seems to me what is in conflict is the "criteria" used to make a decision. - Evidence of usage, keep it. - The Wrong set of people using it, drop it. and what appears to be a lonely opinion: - Does DNS say its no longer necessary to consider as envisioned in MARID with the idea to lower SPF impact on DNS and increase IETF/DNS community endorsement. I would like see this based on DNS based technical merit rather than highly subjective ideas that its not used by the right "who's who" in the SPF market. Before the evidence was provided in the WG, I was all for dropping it because I thought it was still a RFC3597 problem. Now, with the evidence I am very eager to support it, but if the DNS community believes special RR types is still a problem and will always be problem, then lets drop it. John Leslie wrote: > Scott Kitterman wrote: >> On Monday, February 27, 2012 10:24:04 AM S Moonesamy wrote: >>> There are currently 25 issues listed in the SPFBIS tracker ( >>> http://trac.tools.ietf.org/wg/spfbis/trac/report/1 ). It would take >>> at least 50 weeks to process the issues if there is a two-weeks >>> consensus call on each and every issue. > > (Actually, I'd be happy if I believed this issue would take _only_ > two weeks...) > >>> The Chairs are of the opinion that the working group would not meet >>> the first milestone mentioned in the Charter if that path was followed. > > That logic _seems_ unassailable... > >>> However, as the Chairs are also responsible to ensure that the working >>> group operates in an open and fair manner, we can run a Consensus Call >>> to determine whether the working group would like to proceed with a >>> consensus call on each issue in the tracker. > > Please don't!!! > >>> Does the above address your objection about "the form of the consensus >>> call"? > > That is for Dave to say. > >> You've arranged the way the group is to work by serializing the discussion >> of issues. > > (This would appear to be addressed to the WGCs, but it might as well > be addressed to Dave, or many of us.) > >> There are only a handful that are likely to have serious discussion >> or doubt about where the consensus lies, > > Speaking for myself, I not merely doubt _where_ consensus on issue #9 > lies -- I doubt there _is_ a consensus. > > Understand, I do not doubt how a _vote_ would go: I doubt there is a > "consensus" in the IETF sense -- roughly speaking, "that all opinions > have been fairly presented and considered". I continue to hear new > material presented, and I continue to see many folk claiming it's not > worth considering ideas contrary to their own. > > We can, of course, continue this until we reach "consensus by > exhaustion". IMHO, consensus-by-exhaustion this early in a WG's work > is a recipe for disaster, but I suppose YMMV. > > Or we could move on. > > I have a very simple suggestion for moving on. I've even shared it > with the WGCs, who had no problem with it. I was expecting to post it > today. > > But it doesn't look like we're _willing_ to move on. We seem to > believe that this issue is so important that the other 24 will fall in > place if we just resolve this one. > > I don't understand that belief. Please feel free to enlighten me -- > but in private email please. > >> but if the current process is too slow for you, have a look in the mirror. > > Again, I suggest it's not only the WGCs that should look in the mirror. > > -- > John Leslie > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Mon Feb 27 12:09:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B4B21F8845 for ; Mon, 27 Feb 2012 12:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 j6gz8I5TyS0s for ; Mon, 27 Feb 2012 12:09:16 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 52DC121F8842 for ; Mon, 27 Feb 2012 12:09:16 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9B2CA20E40E0; Mon, 27 Feb 2012 15:09:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330373355; bh=l/NB2M30VTmSO4th/FSOVkaz/0QnfgE+kBNRUXsf3Dw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=o3L6C7aISt7sUTinxUsFuo61PNRCWmUorMKYlXcdnRrHFBzLGymaCHOOpQYE8dgn7 yJJ7lzXF1J5ro7Vgz9mmSELVVgovsCJVFqzlnlSnhbu7sUOs6bwanLe6OXIXEPsEH4 ahJqqPRC+3u8gCNoI4ApmI2bozAUgr+PQVDGHG4c= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7C34520E40A4; Mon, 27 Feb 2012 15:09:15 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 27 Feb 2012 15:09:14 -0500 Message-ID: <1536932.NfzgJrdCcM@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F4BDF15.5090703@isdg.net> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120227192643.GC42092@verdi> <4F4BDF15.5090703@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 20:09:17 -0000 On Monday, February 27, 2012 02:52:53 PM Hector Santos wrote: > Well said Mr. Leslie. > > It seems to me what is in conflict is the "criteria" used to make a > decision. > > - Evidence of usage, keep it. > - The Wrong set of people using it, drop it. I don't know what this means. I think that it's reasonably clearly established that the current usage of Type SPF records is effectively zero and there would be no interoperability impact for dropping it. I think it's fair to argue that it should be kept because we haven't waited long enough and that eventually it will get deployment, but I don't think there's an argument for an impact to the current SPF userbase. > and what appears to be a lonely opinion: > > - Does DNS say its no longer necessary to consider as envisioned in MARID > with the idea to lower SPF impact on DNS and increase IETF/DNS > community endorsement. MARID is irrelevant. It ended without producing any output. If MARID consensus counted for anything, Microsoft would not have been able to push a Sender ID design through the IESG that used SPF records for PRA assessment (the MARID consensus was not to do that, but to use it from mfrom only). The appeals of the Sender ID RFCs made it clear even then, that MARID consensus is irrelevant. It hasn't gotten more relevant with age. > I would like see this based on DNS based technical merit rather than > highly subjective ideas that its not used by the right "who's who" in > the SPF market. > > Before the evidence was provided in the WG, I was all for dropping it > because I thought it was still a RFC3597 problem. Now, with the > evidence I am very eager to support it, but if the DNS community > believes special RR types is still a problem and will always be > problem, then lets drop it. There is no support in the commercial DNS market (as far as I know) for publishing Type SPF records. Even though most DNS resolvers support it, the provisioning tools that most domains use to manage DNS don't. That makes it effectively not useful on a broad scale. I think Type SPF is stuck with a Catch 22. There won't be broad support in provisioning tools until it's broadly deployed and there won't be broad deployment until it's in the tools. Scott K From msk@cloudmark.com Mon Feb 27 12:10:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE9621F87B9 for ; Mon, 27 Feb 2012 12:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0LfBiSGGb+f for ; Mon, 27 Feb 2012 12:10:39 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 02E8F21F86BE for ; Mon, 27 Feb 2012 12:10:39 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Mon, 27 Feb 2012 12:10:37 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM9X60rqgqt5sS2UCujsT9Si1gLpZRppiA//+FGbA= Date: Mon, 27 Feb 2012 20:10:36 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280492D3@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A6721.50901@dcrocker.net> <6.2.5.6.2.20120227102005.0aa56d18@elandnews.com> <1350366.UKdUXUDbyf@scott-latitude-e6320> <20120227192643.GC42092@verdi> In-Reply-To: <20120227192643.GC42092@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 20:10:40 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of John Leslie > Sent: Monday, February 27, 2012 11:27 AM > To: Scott Kitterman > Cc: spfbis@ietf.org > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issu= e #9) >=20 > Speaking for myself, I not merely doubt _where_ consensus on issue > #9 lies -- I doubt there _is_ a consensus. This is why I think we need more time to discuss it. This is a complicated= topic deserving consideration from many angles. I think we might have eno= ugh data, but it's unclear that we've considered fully all the implications= of it yet. If the intent of the "intermediate consensus" call (a new term to me, at le= ast) is to say "OK, let's park this topic and come back to it", I'd be fine= with that, but that's not how I read the chairs' message. -MSK From ajs@anvilwalrusden.com Mon Feb 27 12:35:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C9921F86EB for ; Mon, 27 Feb 2012 12:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 AL-WUUBFmrEN for ; Mon, 27 Feb 2012 12:35:40 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id EAE7121F8686 for ; Mon, 27 Feb 2012 12:35:39 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4F42C1ECB41C for ; Mon, 27 Feb 2012 20:35:39 +0000 (UTC) Date: Mon, 27 Feb 2012 15:35:37 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120227203537.GZ48576@mail.yitter.info> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120227192643.GC42092@verdi> <4F4BDF15.5090703@isdg.net> <1536932.NfzgJrdCcM@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1536932.NfzgJrdCcM@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 20:35:41 -0000 Dear colleagues, On Mon, Feb 27, 2012 at 03:09:14PM -0500, Scott Kitterman wrote: > > MARID is irrelevant. This is exactly right, and I think we've said it before. The outcome of MARID and the feelings that led to it are just not topics for this WG, please. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Mon Feb 27 12:37:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C9121F86B2 for ; Mon, 27 Feb 2012 12:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 YuJirTuy96Mu for ; Mon, 27 Feb 2012 12:37:50 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C373721F8698 for ; Mon, 27 Feb 2012 12:37:50 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 25A681ECB41C for ; Mon, 27 Feb 2012 20:37:50 +0000 (UTC) Date: Mon, 27 Feb 2012 15:37:48 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120227203747.GA48576@mail.yitter.info> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A6721.50901@dcrocker.net> <6.2.5.6.2.20120227102005.0aa56d18@elandnews.com> <1350366.UKdUXUDbyf@scott-latitude-e6320> <20120227192643.GC42092@verdi> <9452079D1A51524AA5749AD23E0039280492D3@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9452079D1A51524AA5749AD23E0039280492D3@exch-mbx901.corp.cloudmark.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 20:37:52 -0000 On Mon, Feb 27, 2012 at 08:10:36PM +0000, Murray S. Kucherawy wrote: > > If the intent of the "intermediate consensus" call (a new term to me, at least) is to say "OK, let's park this topic and come back to it", I'd be fine with that, but that's not how I read the chairs' message. > I'm sorry that that wasn't clear. That was exactly what was intended. We can't determine consensus right now, so the state of consensus is indeterminate. It seems clear that the issue requires more time, especially since there appears to be a serious interoperability issue in the text as it stands in RFC 4408. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Mon Feb 27 12:44:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D7911E8074 for ; Mon, 27 Feb 2012 12:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 D6Ng8JO9KjC7 for ; Mon, 27 Feb 2012 12:44:26 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B2ABB11E8072 for ; Mon, 27 Feb 2012 12:44:26 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3980C20E40E0; Mon, 27 Feb 2012 15:44:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330375466; bh=Xc8xNfoeRk4JwYNG398zzlH2OwMY8boJtDbrfZzpARY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=p16jGS28JgpMOpLoo35v55KJVJX8MUJCS1XPCIlkDu7z48bbG6vy9LftEFd/AjHid skVMMXGgb1byttLEMXTIcTFHgH/6s44DG9s2OC6pc9yI3tjbivbTBamf4vaqfV+bTg foYR3v+I3kwU6cnRqr8fcv2C/1gkg8UILS+DLtIg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1B13D20E40A4; Mon, 27 Feb 2012 15:44:25 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 27 Feb 2012 15:44:25 -0500 Message-ID: <2336468.3QMqZCxQXh@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120227203747.GA48576@mail.yitter.info> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <9452079D1A51524AA5749AD23E0039280492D3@exch-mbx901.corp.cloudmark.com> <20120227203747.GA48576@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 20:44:27 -0000 On Monday, February 27, 2012 03:37:48 PM Andrew Sullivan wrote: > On Mon, Feb 27, 2012 at 08:10:36PM +0000, Murray S. Kucherawy wrote: > > If the intent of the "intermediate consensus" call (a new term to me, at > > least) is to say "OK, let's park this topic and come back to it", I'd > > be fine with that, but that's not how I read the chairs' message. > I'm sorry that that wasn't clear. That was exactly what was intended. > We can't determine consensus right now, so the state of consensus is > indeterminate. It seems clear that the issue requires more time, > especially since there appears to be a serious interoperability issue > in the text as it stands in RFC 4408. I think that's reasonable. I totally didn't get that either. Scott K From hsantos@isdg.net Mon Feb 27 13:22:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC46321E8042 for ; Mon, 27 Feb 2012 13:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSOIrZGBt2Nx for ; Mon, 27 Feb 2012 13:22:01 -0800 (PST) Received: from winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6D00021E803A for ; Mon, 27 Feb 2012 13:22:00 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1118; t=1330377717; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=EUrIP5Tv1yZdqxAAz+ryd+BrmJo=; b=NVN0xepSWPhHy0+QwbXp y37j4DKz3PfUP8KKRr2xUnVS/mGQiizz1oW99l6unybW83uNa4KuA8V2ySeEupLe snL7kkRq25yctGxRF8aazBVk7pC6lOckxWRb/jB1hmLG6plRBpOApy3yfmrJ1wlv MAWoyWuOAx4oYnDBcl90ZvM= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 16:21:57 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3579556762.93496.5432; Mon, 27 Feb 2012 16:21:56 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1118; t=1330377467; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=DlkDH9W 7ALTCmJtEcEx+QwZGdPsAB4fvW9C3wAiP40U=; b=kYpQWBD6QIlezatkLTW2rDe fhE2djANpqu+PXe22GurIatT+WlGch5lV4QLQdS4BlrjF8S5vmnLTBWG5r0hAJ5a /cE9glyJs+BdlgO/qKiCGjD8EFteyoBh+Qm5UvngdOT5st5IYpGgcmQUHtA/UGCk eINMtQBBnWrA4WwwSqz8= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 16:17:47 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4178490486.19768.5220; Mon, 27 Feb 2012 16:17:47 -0500 Message-ID: <4F4BF3EA.7060504@isdg.net> Date: Mon, 27 Feb 2012 16:21:46 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andrew Sullivan References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120227192643.GC42092@verdi> <4F4BDF15.5090703@isdg.net> <1536932.NfzgJrdCcM@scott-latitude-e6320> <20120227203537.GZ48576@mail.yitter.info> In-Reply-To: <20120227203537.GZ48576@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 21:22:02 -0000 Andrew Sullivan wrote: > Dear colleagues, > > On Mon, Feb 27, 2012 at 03:09:14PM -0500, Scott Kitterman wrote: >> MARID is irrelevant. > > This is exactly right, and I think we've said it before. The outcome > of MARID and the feelings that led to it are just not topics for this > WG, please. This is not helping. Please do not focus on reference MARID, but rather what the GUTS was in regards of what the main point was. The ORIGINAL GOAL and INTENT of using a new RR type. Before you can even consider abandoning this, it is PRUDENT that original intent was in fact wrong. Its ashame that you wish to FOCUS on something, ignoring what the fundamental point being stated to use continue to use this as a form of DISSEMINATION. Please look at what was STATED and answer that fundamental question. It was a MARID decision to produce what we have now - RFC4408, to ignore all the engineering insight, time and energy put into it is well, I can't described nothing short but fundamentally wrong. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Mon Feb 27 13:28:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F311B21E8042 for ; Mon, 27 Feb 2012 13:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 6N3tQjx74ZQU for ; Mon, 27 Feb 2012 13:28:55 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3570621E803B for ; Mon, 27 Feb 2012 13:28:55 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 87A2920E40E0; Mon, 27 Feb 2012 16:28:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330378134; bh=ZlAYhdbz1D/mo+7Sv0JHacWMFvGIXuA7tqcnH8iqXrQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=CDWH6O1sRuw5cQmOTKyXWgoovs4oOpHCCDhU91+wdPsadWu2gkCp7h7LIdgMac8b5 8CS/QihgBAD/Koq0RBRTB1zkFmVCWboMUNFaWMcVU8FaQ9I+S7U+Z9lOltnX1q0VHm 24RwJgZLb8snxR3hhoAKDLtbR6/gyfaI+3WKmpfg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 69C5C20E40A4; Mon, 27 Feb 2012 16:28:54 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 27 Feb 2012 16:28:53 -0500 Message-ID: <2886130.xBf1F0kJq9@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F4BF3EA.7060504@isdg.net> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120227203537.GZ48576@mail.yitter.info> <4F4BF3EA.7060504@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 21:28:56 -0000 On Monday, February 27, 2012 04:21:46 PM Hector Santos wrote: > Andrew Sullivan wrote: > > Dear colleagues, > > > > On Mon, Feb 27, 2012 at 03:09:14PM -0500, Scott Kitterman wrote: > >> MARID is irrelevant. > > > > This is exactly right, and I think we've said it before. The outcome > > of MARID and the feelings that led to it are just not topics for this > > WG, please. > > This is not helping. > > Please do not focus on reference MARID, but rather what the GUTS was > in regards of what the main point was. > > The ORIGINAL GOAL and INTENT of using a new RR type. > > Before you can even consider abandoning this, it is PRUDENT that > original intent was in fact wrong. > > Its ashame that you wish to FOCUS on something, ignoring what the > fundamental point being stated to use continue to use this as a form > of DISSEMINATION. > > Please look at what was STATED and answer that fundamental question. > It was a MARID decision to produce what we have now - RFC4408, to > ignore all the engineering insight, time and energy put into it is > well, I can't described nothing short but fundamentally wrong. No. It wasn't. RFC 4408 was an individual submission. The only reason Type SPF was included was the DNS mafia of the day would have prevented the RFC from being published otherwise. AFAIK there was not detailed analysis or other engineering effort to determine if it was needed. Reusing TXT was architecturally impure, so we got RFC 4408 approve by pretending the use of TXT was merely transitional. If we have to play let's pretend about Type SPF again to get 4408bis approved, I'm OK with that, but let's be honest amongst ourselves about what's going on. There is not and never was a case to make the transition happen. Despite tons of effort going into code to support transition, no transition is happening and there's no reason to believe that will change. Scott K From hsantos@isdg.net Mon Feb 27 13:33:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161C321F8712 for ; Mon, 27 Feb 2012 13:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.395 X-Spam-Level: X-Spam-Status: No, score=0.395 tagged_above=-999 required=5 tests=[AWL=-2.104, BAYES_00=-2.599, FRT_PROFIT1=3.858, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xadFjsT4669M for ; Mon, 27 Feb 2012 13:33:51 -0800 (PST) Received: from ftp.catinthebox.net (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9EC21F8710 for ; Mon, 27 Feb 2012 13:33:50 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=986; t=1330378422; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=PPA7VfJzYlDg09QrLbykPQgi5J0=; b=H/5MdLPIQI9DmeSgzHfq KuneDjX1NTR1WUF5nqecrxCz1HSoflywe0fLflImAG1v7MkN8YgwVnGIe9XHay5x 8iV9ftZuOh1NKERasUhh2/jRNFRlwmZ8Qvi5KdJVSJGNEvBinwa6w9r5A/9bKBPT HYhmVknfoa58+7pswkljxQ0= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 16:33:42 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3580261964.93496.4828; Mon, 27 Feb 2012 16:33:41 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=986; t=1330378172; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=U4zanic 4X/ZSJXkNhpMRuDj6gfVspuoZhnay1ffwkPQ=; b=VEG3O+ZOU6NkHP7dyKTF9/V TbreUO+2zVnw982vnpifN4I3HC4Ko5r8uu5+I+e92SjAyHSZT1C6zJ+eG/KuX2Nd XIKwqBKW8XBbOMLrW+QvsYg26owF06h1i+rPiwEXtUpXmvGsZDV5VHFpcezAFD3a 7RMt70R6TsnSUPhDSXvA= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 16:29:32 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4179195298.19769.3324; Mon, 27 Feb 2012 16:29:31 -0500 Message-ID: <4F4BF6AB.9070302@isdg.net> Date: Mon, 27 Feb 2012 16:33:31 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120227192643.GC42092@verdi> <4F4BDF15.5090703@isdg.net> <1536932.NfzgJrdCcM@scott-latitude-e6320> In-Reply-To: <1536932.NfzgJrdCcM@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 21:33:52 -0000 Scott Kitterman wrote: >> - Does DNS say its no longer necessary to consider as envisioned in MARID >> with the idea to lower SPF impact on DNS and increase IETF/DNS >> community endorsement. > > MARID is irrelevant. It ended without producing any output. Not true, but less forget MARID. Read what I stated. The fundamental issue is: The original goal and intent to consider new RR type. You are totally ignoring that fundamental and extremely important consideration and until you show IETF/DNS community universal proof it is no longer desirable, your criteria for abandoning type 99 is highly subjective with no evidence it is correct, when in fact the MARID generated decision to include it with all its expected short term migration path issues has 100% materialized. To ignore this extremely important point, well, is exclusion of input you don't wish to consider. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From ajs@anvilwalrusden.com Mon Feb 27 13:39:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D75321E8029 for ; Mon, 27 Feb 2012 13:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 VfvhWB+4iR0n for ; Mon, 27 Feb 2012 13:39:54 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C326121E8028 for ; Mon, 27 Feb 2012 13:39:53 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D0E2E1ECB41C for ; Mon, 27 Feb 2012 21:39:52 +0000 (UTC) Date: Mon, 27 Feb 2012 16:39:51 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120227213950.GC48576@mail.yitter.info> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120227192643.GC42092@verdi> <4F4BDF15.5090703@isdg.net> <1536932.NfzgJrdCcM@scott-latitude-e6320> <20120227203537.GZ48576@mail.yitter.info> <4F4BF3EA.7060504@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F4BF3EA.7060504@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] (Ir)relevance of MARID (was: Call for intermediate consensus on SPF RRTYPE (issue #9)) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 21:39:54 -0000 Hector, On Mon, Feb 27, 2012 at 04:21:46PM -0500, Hector Santos wrote: > It was a MARID decision to produce what we have now - RFC4408 No, it was not. That's exactly why we chairs determined that discussion of what went on in MARID is not on-topic for this discussion. We are _not_ doing a -bis on a WG document. RFC 4408 is not the product of any WG. It's true that MARID did some work on something similar to what became RFC 4408, but the RFC is not the product of the working group, as a formal matter of history. If you don't believe me, please examine the IETF datatracker data: https://datatracker.ietf.org/doc/rfc4408/history/. I understand the temptation to draw analogies with discussions that happened in MARID. In my capacity as co-chair, I'm asking you and every other participant in this WG not to give into that temptation. If people can't heed that request, I will have to take it up more formally; but I would prefer that people govern themselves. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From hsantos@isdg.net Mon Feb 27 13:43:53 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F04921F8487 for ; Mon, 27 Feb 2012 13:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.674 X-Spam-Level: X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D3yxfXEUOdA for ; Mon, 27 Feb 2012 13:43:52 -0800 (PST) Received: from ftp.catinthebox.net (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 59CB321F8478 for ; Mon, 27 Feb 2012 13:43:52 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1552; t=1330379027; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=FN3mD6peN/BjNck6K7GkbbAeLyU=; b=vWXfxxD8iDDH+SdJqKvj bD0olW9iqzNwD438Ds+TYYM30TzyLLJ/AaYumT0uk+NOMiuR85m0EQ4dY1MvILYP KaRhlYKAA/336VKhMzR3RL08BT+MGIv+87fiTA40UMpJ+wm3OtXGUkvcUz4KxxUX d7QyumTrG73Fllxvnot69lE= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 16:43:47 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3580867201.93496.3268; Mon, 27 Feb 2012 16:43:47 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1552; t=1330378776; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=pb6kX7E gwQfsixLgdW3lkNxvajcOLJoxGTG6YkXAAt0=; b=FaN8nQ7H2rrODo964Yd/4W4 lmLOZtArbq4riVEN+NHyE8WwOicn1vp6ehKSVHvt+dvpYUMi1dK/SRQMf001ZjSz L8oGT7xK4jsTU5ovCNV72EuMRagthxgofnMGBSYNGoY6cx6L6Khz3oNMrcUVKtVL b39zUlROJgRYPGepWSfk= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 16:39:36 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4179799064.19772.2116; Mon, 27 Feb 2012 16:39:35 -0500 Message-ID: <4F4BF906.1040106@isdg.net> Date: Mon, 27 Feb 2012 16:43:34 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120227203537.GZ48576@mail.yitter.info> <4F4BF3EA.7060504@isdg.net> <2886130.xBf1F0kJq9@scott-latitude-e6320> In-Reply-To: <2886130.xBf1F0kJq9@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 21:43:53 -0000 Scott Kitterman wrote: >> Please do not focus on reference MARID, but rather what the GUTS was >> in regards of what the main point was. >> >> The ORIGINAL GOAL and INTENT of using a new RR type. >> >> Before you can even consider abandoning this, it is PRUDENT that >> original intent was in fact wrong. >> >> Its ashame that you wish to FOCUS on something, ignoring what the >> fundamental point being stated to use continue to use this as a form >> of DISSEMINATION. >> >> Please look at what was STATED and answer that fundamental question. >> It was a MARID decision to produce what we have now - RFC4408, to >> ignore all the engineering insight, time and energy put into it is >> well, I can't described nothing short but fundamentally wrong. > > No. It wasn't. RFC 4408 was an individual submission. > > The only reason Type SPF was included was the DNS mafia of the day would have > prevented the RFC from being published otherwise. And where did the DNS "MAFIA" exist? - MARID! Please, this is getting really shamefully chaotic with this denial going on. To suggest MARID did not have a direct influence in all the RFC delivery is simply not true, including, as you admit the "DNS MAFIA" force the issue. So again, forget MARID if you wish, but lets NOT forget the fundamental technical valid reasons and considerations was added in the first place. What you are saying it was ALL wrong and flawed to be begin with. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Mon Feb 27 13:46:29 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A7C21E8027 for ; Mon, 27 Feb 2012 13:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 xZEaGkd8i1W5 for ; Mon, 27 Feb 2012 13:46:29 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1112A21E800C for ; Mon, 27 Feb 2012 13:46:29 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 83A8920E40E0; Mon, 27 Feb 2012 16:46:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330379188; bh=lp6IMnD421bFAMuQgZ/mLIwJrE6J2HM66bcxR3EIUsY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=dk8Kqvzm5sD/ce0OYcIQiLUgHup59QN5UREJgV8ucMNU5b2YbvaCWSJBimae35y9a ECSYfkdAIRcVF1GXXbDgg/wdhRWjOrCitry4Uj5qEu1C5VfRxQp8x+x7spw7Y/maMK u56TBQ62BOeXQ8lUhmavpNYD8F1a7Aylkog75bwo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6A94E20E40A4; Mon, 27 Feb 2012 16:46:28 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 27 Feb 2012 16:46:27 -0500 Message-ID: <1574935.ekRAFExGcO@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F4BF906.1040106@isdg.net> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <2886130.xBf1F0kJq9@scott-latitude-e6320> <4F4BF906.1040106@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 21:46:30 -0000 On Monday, February 27, 2012 04:43:34 PM Hector Santos wrote: > Scott Kitterman wrote: > >> Please do not focus on reference MARID, but rather what the GUTS was > >> in regards of what the main point was. > >> > >> The ORIGINAL GOAL and INTENT of using a new RR type. > >> > >> Before you can even consider abandoning this, it is PRUDENT that > >> original intent was in fact wrong. > >> > >> Its ashame that you wish to FOCUS on something, ignoring what the > >> fundamental point being stated to use continue to use this as a form > >> of DISSEMINATION. > >> > >> Please look at what was STATED and answer that fundamental question. > >> It was a MARID decision to produce what we have now - RFC4408, to > >> ignore all the engineering insight, time and energy put into it is > >> well, I can't described nothing short but fundamentally wrong. > > > > No. It wasn't. RFC 4408 was an individual submission. > > > > The only reason Type SPF was included was the DNS mafia of the day would > > have prevented the RFC from being published otherwise. > > And where did the DNS "MAFIA" exist? - MARID! Please, this is getting > really shamefully chaotic with this denial going on. > > To suggest MARID did not have a direct influence in all the RFC > delivery is simply not true, including, as you admit the "DNS MAFIA" > force the issue. > > So again, forget MARID if you wish, but lets NOT forget the > fundamental technical valid reasons and considerations was added in > the first place. > > What you are saying it was ALL wrong and flawed to be begin with. It was theoretically correct, but of little to no practical utility. I think that's still the case. I do agree with the statement elsewhere in the thread that we're making little progress on this issue and we might better spend out time on others and come back to this later. Scott K From hsantos@isdg.net Mon Feb 27 13:52:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A55B21E8032 for ; Mon, 27 Feb 2012 13:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.674 X-Spam-Level: X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI1zcZJPXacP for ; Mon, 27 Feb 2012 13:52:31 -0800 (PST) Received: from ftp.catinthebox.net (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3293C21E802F for ; Mon, 27 Feb 2012 13:52:31 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1747; t=1330379533; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=paRH2il+8CULwuuoc+ISHp/lEIQ=; b=AEvIn3yEC53svD3Uj3bu FcXWwO9ota1MbxQlHGbL0Ao+NV/qPGgeHtke7KryDPv8Wuu2AH+9J/9olMR+GUM5 9M/2RaoScBt4fjtUfLRN5s79OCTFqmmWn5zfnCK5yTT/1u20XosIqbLV8RivOPoS JLnUVScD8uvvW2veBhBj0d8= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 16:52:13 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3581372239.93496.4792; Mon, 27 Feb 2012 16:52:12 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1747; t=1330379281; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=HyuuR42 n04GRobGodutjwfQbcn5MpWvjlakOpOs+Vzw=; b=xJkQwRMpZiXtDMwH7mlIgH4 qwb+sc+mMdvhGQ/oBag6kXdsFDezy0h1AnvdL1DaH2k6o8pwFfatiIThowACFUdJ Do/5LjV9zTOLVwJq7YICM4Fljew4oGt9jZ5BTHNbM1uJze5z31Wg7G4aw4nTIwQt EsD9VpmDJ4oLwchrg3GA= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 16:48:01 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4180304236.19773.760; Mon, 27 Feb 2012 16:48:00 -0500 Message-ID: <4F4BFB00.9030808@isdg.net> Date: Mon, 27 Feb 2012 16:52:00 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120227192643.GC42092@verdi> <4F4BDF15.5090703@isdg.net> <1536932.NfzgJrdCcM@scott-latitude-e6320> <20120227203537.GZ48576@mail.yitter.info> <4F4BF3EA.7060504@isdg.net> <20120227213950.GC48576@mail.yitter.info> In-Reply-To: <20120227213950.GC48576@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] (Ir)relevance of MARID X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 21:52:32 -0000 Again, you are ignoring what was stated and I stated it again, this way: There is an ORIGINAL RFC 4408 GOAL and INTENT to consider type 99 that fundamental was based on WG concerns regarding its impact on DNS. You have ignored this point and the only reason to even reference M A R I D, is we are forgetting all the wrong done to even thing about ideas like type 99. Please stop using threats of excommunications when ignorance is quite clear on these critical points. Rather than ignore it, address it. Its not my fault you prefer a position of ignoring input. Andrew Sullivan wrote: > Hector, > > On Mon, Feb 27, 2012 at 04:21:46PM -0500, Hector Santos wrote: > >> It was a MARID decision to produce what we have now - RFC4408 > > No, it was not. That's exactly why we chairs determined that > discussion of what went on in MARID is not on-topic for this > discussion. > > We are _not_ doing a -bis on a WG document. RFC 4408 is not the > product of any WG. It's true that MARID did some work on something > similar to what became RFC 4408, but the RFC is not the product of > the working group, as a formal matter of history. If you don't > believe me, please examine the IETF datatracker data: > https://datatracker.ietf.org/doc/rfc4408/history/. > > I understand the temptation to draw analogies with discussions that > happened in MARID. In my capacity as co-chair, I'm asking you and > every other participant in this WG not to give into that temptation. > If people can't heed that request, I will have to take it up more > formally; but I would prefer that people govern themselves. > > Thanks, > > A > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Mon Feb 27 14:04:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA0321F853A for ; Mon, 27 Feb 2012 14:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.674 X-Spam-Level: X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J9jCfk0DhB5 for ; Mon, 27 Feb 2012 14:04:45 -0800 (PST) Received: from ftp.catinthebox.net (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D521521F8531 for ; Mon, 27 Feb 2012 14:04:44 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1943; t=1330380283; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=NwJc2c1F1Y0vFcHlj/7KMzOUAW4=; b=U+EPBnkKf7nWLekOJe1c xhn1HuDJjaJnxKzCge0RZq3YFccGTsA8XqgyYBWV8zSCtNDxoxA7bJM83jhagIKH DsbHwp0xW1RdLvvitC2qTn9AqJRq3NeO+YHSKmeIe8aL/SvSSpKmkQ0UCu/SkzYZ FF0z/oinC0q6e5VVC74Ctx8= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 17:04:43 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3582122526.93496.4472; Mon, 27 Feb 2012 17:04:42 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1943; t=1330380035; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=PDK8YUA RCVXoCb30QifI6IJSSqtl+kuxrZDLrrF3D1s=; b=QqfoXmz+ZMFhySc2v2PPKtO mz1z4l1E0YB6gRozptKp4GtCtmCGwsFQYgImSYS5FK1p2Q10DrO8xl9WNc7SljG2 J4rSnthWl8/B3GNygmUEYYRuqPcQc3XR+5r7YwC+rUvcN4WaHII4fkjacxtrSmfZ mpEiAwCHezRKmNBcI9Wc= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 17:00:35 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4181058314.19778.5836; Mon, 27 Feb 2012 17:00:34 -0500 Message-ID: <4F4BFDF1.1030704@isdg.net> Date: Mon, 27 Feb 2012 17:04:33 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <2886130.xBf1F0kJq9@scott-latitude-e6320> <4F4BF906.1040106@isdg.net> <1574935.ekRAFExGcO@scott-latitude-e6320> In-Reply-To: <1574935.ekRAFExGcO@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 22:04:45 -0000 Scott Kitterman wrote: >> And where did the DNS "MAFIA" exist? - MARID! Please, this is getting >> really shamefully chaotic with this denial going on. >> >> To suggest MARID did not have a direct influence in all the RFC >> delivery is simply not true, including, as you admit the "DNS MAFIA" >> force the issue. >> >> So again, forget MARID if you wish, but lets NOT forget the >> fundamental technical valid reasons and considerations was added in >> the first place. >> >> What you are saying it was ALL wrong and flawed to be begin with. > > It was theoretically correct, but of little to no practical utility. I think > that's still the case. Ok, great! Now I think that should be the central debate because this idea of using "Who's Who" is a terrible rat smelling imposition on others that don't agree. Especially if they are not on the "Who's Who" list! If type 99 was originally a bad idea, then it would be a more plausible reason to get rid of it. But if you are following input from Patrick on the IETF list, and RFC 5507, I agree with it, a decision to abandon it is not only premature, based on subjective isolated input. Again I was all ready to to abandon it, until the evidence has shown the that OLD GROUP engineering and migration path thinking was 100% on par - to negate this is really an odd thing. > I do agree with the statement elsewhere in the thread that we're making little > progress on this issue and we might better spend out time on others and come > back to this later. Fine, but it has to be decided at some point and I hope it doesn't fall trap to a final situation like in DKIM where people started to say about the charted delivery goal for ADSP, - "We are tired, just forgot about and let someone else worry about it" If that is what you hope, you might just get it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From sm@elandsys.com Mon Feb 27 14:43:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495DC21F8670 for ; Mon, 27 Feb 2012 14:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.639 X-Spam-Level: X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kI2+gLHZo0H for ; Mon, 27 Feb 2012 14:43:26 -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 6405321F8666 for ; Mon, 27 Feb 2012 14:43:26 -0800 (PST) Received: from SUBMAN.elandsys.com (ADSL-202-138.myt.mu [41.212.202.138] (may be forged)) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1RMh3U6002781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2012 14:43:13 -0800 (PST) Message-Id: <6.2.5.6.2.20120227124225.0a1ed6d8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 27 Feb 2012 12:48:16 -0800 To: dcrocker@bbiw.net From: S Moonesamy In-Reply-To: <4F4A6721.50901@dcrocker.net> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A6721.50901@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 22:43:27 -0000 Hi Dave, There appears to be a wide variety of opinion about Issue #9. Moreover, the discussion has revealed an interoperability concern in the existing RFC. It seems additional discussion is going to be needed to determine what to do about that interoperability concern, and therefore we cannot conclude anything right now. We are therefore suspending discussion for the moment on Issue #9. Regards, Andrew Sullivan & S. Moonesamy, SPFBIS WG Chairs From msk@cloudmark.com Mon Feb 27 15:49:29 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B69121F857A for ; Mon, 27 Feb 2012 15:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEsxnbZLKODI for ; Mon, 27 Feb 2012 15:49:28 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id A7C4121F853B for ; Mon, 27 Feb 2012 15:49:28 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 27 Feb 2012 15:49:28 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM9Y+u5OTuQpZeaUqGLNSk/9xZWJZRaNvw Date: Mon, 27 Feb 2012 23:49:27 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928049E9A@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A6721.50901@dcrocker.net> <6.2.5.6.2.20120227102005.0aa56d18@elandnews.com> <1350366.UKdUXUDbyf@scott-latitude-e6320> <20120227192643.GC42092@verdi> <9452079D1A51524AA5749AD23E0039280492D3@exch-mbx901.corp.cloudmark.com> <20120227203747.GA48576@mail.yitter.info> In-Reply-To: <20120227203747.GA48576@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Feb 2012 23:49:29 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Andrew Sullivan > Sent: Monday, February 27, 2012 12:38 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issu= e #9) >=20 > I'm sorry that that wasn't clear. That was exactly what was intended. > We can't determine consensus right now, so the state of consensus is > indeterminate. It seems clear that the issue requires more time, > especially since there appears to be a serious interoperability issue > in the text as it stands in RFC 4408. Thanks for the clarification. Next topic, please. :-) (I understand 1, 2, 3, and 8 are open, but SM mentioned that the latter thr= ee are chiefly editorial "hold for document update" issues, and it seems to= me as if we've already converged on the first.) -MSK From sm@elandsys.com Mon Feb 27 16:29:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9575921F853A for ; Mon, 27 Feb 2012 16:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XLcsgd4pe4l for ; Mon, 27 Feb 2012 16:29:43 -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 D7AD421F852C for ; Mon, 27 Feb 2012 16:29:43 -0800 (PST) Received: from SUBMAN.elandsys.com (ADSL-202-138.myt.mu [41.212.202.138] (may be forged)) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1S0TVvG022047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Feb 2012 16:29:41 -0800 (PST) Message-Id: <6.2.5.6.2.20120227162220.095a2df8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 27 Feb 2012 16:26:22 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.51b6a8e6dda4b21b455cca692d4b547b@tools.ietf.org> References: <061.51b6a8e6dda4b21b455cca692d4b547b@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 00:29:44 -0000 At 13:01 07-02-2012, spfbis issue tracker wrote: >#4: RFC 4408 Section 4.1 > > Message from Hector Santos on 5 Feb 2012: > > This may need a charter change/adjustment, but I would like to proposed > section 4.1 be updated to support RFC 4405 by adding an optional > [submitter] argument to the check_host() function model: > > 4.1. Arguments > > The check_host() function takes these arguments: > > - the IP address of the SMTP client that is emitting the > mail, either IPv4 or IPv6. > > - the domain that provides the sought-after authorization > information; initially, the domain portion of the "MAIL > FROM" or "HELO" identity. > > | [submitter] - RFC4409, SUBMITTER keyword passed to the "MAIL FROM" > > > > Our SMTP server does not directly support SENDER-ID. However, our SPF > implementation indirectly supports SENDER-ID via the RFC4405 SUBMITTER > keyword, if any. Our SPF check_host() process model is: > > result = check_host(ip, domain [, submitter]) > > > IMO, while we may not to get into SENDER-ID discussions for SPFBIS, the WG > should not exclude the possibility for any industry support for SUBMITTER > and it should be discussed as as realistic possibility to be part of the > check_host() arguments. If you agree, it should be included in updating > SPF-BIF. [snip] >Ticket URL: Please comment on the above issue. Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Mon Feb 27 16:38:33 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A70921E8026 for ; Mon, 27 Feb 2012 16:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 Anj+ufcAEnKt for ; Mon, 27 Feb 2012 16:38:32 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4975221E8024 for ; Mon, 27 Feb 2012 16:38:32 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 83B7C20E40E0; Mon, 27 Feb 2012 19:38:31 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330389511; bh=W/o2Lhpgcc0vk9zPL+vpOMxxzcEKaq2k4OTHYozGMo4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Sdq6JEEDzLf/Lc3sofYMgXgZTB9/UiysVDhadFgAOifR2vIKwpYQ5aSEzTFzlZ35l hSMM543gt/c5HTxsIAgroZRdbvCPinacdUkfMQkUjys1jlmxBgJW3GbUWEbFKjigWx 5nU+tIJerQl44/YwHe42JerNoEOMicEkp138Sun0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6509920E40A4; Mon, 27 Feb 2012 19:38:31 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 27 Feb 2012 19:38:30 -0500 Message-ID: <3787744.eFobIWbcY8@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120227162220.095a2df8@elandnews.com> References: <061.51b6a8e6dda4b21b455cca692d4b547b@tools.ietf.org> <6.2.5.6.2.20120227162220.095a2df8@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 00:38:33 -0000 On Monday, February 27, 2012 04:26:22 PM S Moonesamy wrote: > At 13:01 07-02-2012, spfbis issue tracker wrote: > >#4: RFC 4408 Section 4.1 > > > > Message from Hector Santos on 5 Feb 2012: > > > > This may need a charter change/adjustment, but I would like to > > proposed > > section 4.1 be updated to support RFC 4405 by adding an optional > > > > [submitter] argument to the check_host() function model: > > 4.1. Arguments > > > > The check_host() function takes these arguments: > > > > - the IP address of the SMTP client that is emitting > > the > > > > mail, either IPv4 or IPv6. > > > > - the domain that provides the sought-after > > authorization > > > > information; initially, the domain > > portion of the "MAIL > > FROM" or "HELO" identity. > > | > > | [submitter] - RFC4409, SUBMITTER keyword passed to the "MAIL > > | FROM" > > > > Our SMTP server does not directly support SENDER-ID. However, our SPF > > implementation indirectly supports SENDER-ID via the RFC4405 SUBMITTER > > > > keyword, if any. Our SPF check_host() process model is: > > result = check_host(ip, domain [, submitter]) > > > > IMO, while we may not to get into SENDER-ID discussions for SPFBIS, > > the WG should not exclude the possibility for any industry support > > for SUBMITTER and it should be discussed as as realistic possibility > > to be part of the check_host() arguments. If you agree, it should be > > included in updating SPF-BIF. > > [snip] > > >Ticket URL: > > Please comment on the above issue. It's out of scope. SUBMITTER is a Sender ID concept unrelated to SPF. The only purpose SUBMITTER serves is to give an advance look at PRA prior to going to DATA. It's inextricably linked to Sender ID and has no purpose in an SPF context. While there are no doubt proprietary systems that support SUBMITTER, AFAIK there's no open source implementation which suggests to me that the interest in it was very narrow in any case. Scott K From msk@cloudmark.com Mon Feb 27 16:52:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191D021E8015 for ; Mon, 27 Feb 2012 16:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFIZ2SkDXLRS for ; Mon, 27 Feb 2012 16:52:39 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 35B1821E800C for ; Mon, 27 Feb 2012 16:52:39 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Mon, 27 Feb 2012 16:52:38 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #4: RFC 4408 Section 4.1 Thread-Index: AQHM9bASsUlHNgOq+ECYdMs9Ra10P5ZR/VEA//97KLA= Date: Tue, 28 Feb 2012 00:52:37 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928049FA5@exch-mbx901.corp.cloudmark.com> References: <061.51b6a8e6dda4b21b455cca692d4b547b@tools.ietf.org> <6.2.5.6.2.20120227162220.095a2df8@elandnews.com> <3787744.eFobIWbcY8@scott-latitude-e6320> In-Reply-To: <3787744.eFobIWbcY8@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 00:52:40 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Monday, February 27, 2012 4:39 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 >=20 > It's out of scope. +1. So sayeth the charter: Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language. Adding SUBMITTER as an optional parameter to check_host() falls within none= of those clauses. (The SUBMITTER data we have so far is, however, important to the eventual "= conclusion of the experiment" discussion we need to have.) -MSK From dotzero@gmail.com Mon Feb 27 17:14:38 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3787821F85FB for ; Mon, 27 Feb 2012 17:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zjgfz0IYX7S for ; Mon, 27 Feb 2012 17:14:37 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id EC4D621F85F2 for ; Mon, 27 Feb 2012 17:14:36 -0800 (PST) Received: by dakl33 with SMTP id l33so1457924dak.31 for ; Mon, 27 Feb 2012 17:14:36 -0800 (PST) Received-SPF: pass (google.com: domain of dotzero@gmail.com designates 10.68.218.228 as permitted sender) client-ip=10.68.218.228; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dotzero@gmail.com designates 10.68.218.228 as permitted sender) smtp.mail=dotzero@gmail.com; dkim=pass header.i=dotzero@gmail.com Received: from mr.google.com ([10.68.218.228]) by 10.68.218.228 with SMTP id pj4mr47796694pbc.167.1330391676846 (num_hops = 1); Mon, 27 Feb 2012 17:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=qqW28j048icqjW5fza/gXlJfn7OMNuYLo7hxnwMqvxk=; b=YUhiGz5L9ahXdELxa6hBfKP67ICbkPSsHwk6ld5rc9rAwfPp7l89mh8uJ2VuyeHsRQ XnMpy+Rfl9UAGPn37cElS7KfMsOj9Za8GBPgY66oG8ddBZvMOtBF7ZfE5Ysw+JB5YxYb 9NcszWi8kJgKYKMIkZpN8qa6rQfvfjyMSBC18= MIME-Version: 1.0 Received: by 10.68.218.228 with SMTP id pj4mr40404959pbc.167.1330391676614; Mon, 27 Feb 2012 17:14:36 -0800 (PST) Received: by 10.68.35.198 with HTTP; Mon, 27 Feb 2012 17:14:36 -0800 (PST) In-Reply-To: <9452079D1A51524AA5749AD23E003928049FA5@exch-mbx901.corp.cloudmark.com> References: <061.51b6a8e6dda4b21b455cca692d4b547b@tools.ietf.org> <6.2.5.6.2.20120227162220.095a2df8@elandnews.com> <3787744.eFobIWbcY8@scott-latitude-e6320> <9452079D1A51524AA5749AD23E003928049FA5@exch-mbx901.corp.cloudmark.com> Date: Mon, 27 Feb 2012 20:14:36 -0500 Message-ID: From: Dotzero To: "spfbis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 01:14:38 -0000 On Mon, Feb 27, 2012 at 7:52 PM, Murray S. Kucherawy wr= ote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf= Of Scott Kitterman >> Sent: Monday, February 27, 2012 4:39 PM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 >> >> It's out of scope. > > +1. =A0So sayeth the charter: > > =A0 =A0 =A0 =A0Changes to the SPF specification will be limited to the co= rrection > =A0 =A0 =A0 =A0of errors, removal of unused features, addition of any enh= ancements > =A0 =A0 =A0 =A0that have already gained widespread support, and addition = of > =A0 =A0 =A0 =A0clarifying language. > > Adding SUBMITTER as an optional parameter to check_host() falls within no= ne of those clauses. > > (The SUBMITTER data we have so far is, however, important to the eventual= "conclusion of the experiment" discussion we need to have.) > > -MSK > I agree with others that this should be considered out of scope (ruling from the chairs please). Mike From hsantos@isdg.net Mon Feb 27 17:32:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F9521E8024 for ; Mon, 27 Feb 2012 17:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.464, 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 9NSrgoTh3iQF for ; Mon, 27 Feb 2012 17:32:45 -0800 (PST) Received: from pop3.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BB58921E800C for ; Mon, 27 Feb 2012 17:32:44 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1586; t=1330392763; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=HdpLuewnqI3v488/oPdtgkWsl2o=; b=qyga/fqvLnoClYhr+kxk WBpxey9K5R/8PBcu6vn6wcbYKkrLrr4T/ArmzHQMjo7ZSZu1tLr3y1YemereWf23 M4aug9ji7108iHcAE1lRJV7Hgn8xoPs87/MXHBryAW4Zl2Nul5VPcyT8Itden6Mk OzXPQpdT137vmpc3bm77wmw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 20:32:43 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3594602699.93496.2612; Mon, 27 Feb 2012 20:32:42 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1586; t=1330392516; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=/ixlRsh wQ8DVElBT8+U1RZp1w1FTguaEynk4vQbNl4I=; b=XwN2xW+PkZH0/6j3sMPIAwn gcrbIu1306ZiBOiB7ZLTu2y1FS/1d4pmfHn2uFx2j8dc61ZFPnnHWBeWxzXLY861 xZ411wyy7n8Cd4T1pvEInkhwODSJQVw8ZGY1rj6EEjcnWiiUAcEko5c5crqwJcml NAlvQATK8Gl34imVe2Bc= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 27 Feb 2012 20:28:36 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4193538704.19806.1860; Mon, 27 Feb 2012 20:28:35 -0500 Message-ID: <4F4C2EAC.40609@isdg.net> Date: Mon, 27 Feb 2012 20:32:28 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <061.51b6a8e6dda4b21b455cca692d4b547b@tools.ietf.org> <6.2.5.6.2.20120227162220.095a2df8@elandnews.com> <3787744.eFobIWbcY8@scott-latitude-e6320> In-Reply-To: <3787744.eFobIWbcY8@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 01:32:48 -0000 Scott Kitterman wrote: > On Monday, February 27, 2012 04:26:22 PM S Moonesamy wrote: >> At 13:01 07-02-2012, spfbis issue tracker wrote: >> Please comment on the above issue. > > It's out of scope. SUBMITTER is a Sender ID concept unrelated to SPF. The > only purpose SUBMITTER serves is to give an advance look at PRA prior to going > to DATA. It's inextricably linked to Sender ID and has no purpose in an SPF > context. -1, see below. > While there are no doubt proprietary systems that support SUBMITTER, AFAIK > there's no open source implementation which suggests to me that the interest > in it was very narrow in any case. Enable the SUBMITTER SMTP extension in your SMTP server and there is clear evidence of wide client support. To integrators, when both identities are presented and both are different, a query is done either 5321.MAILFROM done and/or for 5321.MAILFROM SUBMITTER domain. Actions possible in SPF-BIS: 1) Provide semantics for clients to IGNORE SUBMITTER domains presented. 2) Provide logic to described how to handle it when they are different. If #1 is chosen, then the fate of the 4405/4406 protocols has been predetermined for abandonment. If abandonment is the charter goal, then #1 or nothing needs be stated which the latter leaving it ambiguous form for system integrators of both protocols. In other words, if there is a possibility 4405/4406 is not going to be abandoned, then SPF-BIS has a clear role to consider it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From pmidge@microsoft.com Mon Feb 27 17:37:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5654D21E8024 for ; Mon, 27 Feb 2012 17:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.279 X-Spam-Level: X-Spam-Status: No, score=-4.279 tagged_above=-999 required=5 tests=[AWL=-0.680, 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 54ALdpXn2moI for ; Mon, 27 Feb 2012 17:37:54 -0800 (PST) Received: from DB3EHSOBE005.bigfish.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 3B53E21E800C for ; Mon, 27 Feb 2012 17:37:54 -0800 (PST) Received: from mail9-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 28 Feb 2012 01:37:53 +0000 Received: from mail9-db3 (localhost [127.0.0.1]) by mail9-db3-R.bigfish.com (Postfix) with ESMTP id 274FC3004B8; Tue, 28 Feb 2012 01:37:53 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371I542M1432Nzz1202hzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail9-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail9-db3 (localhost.localdomain [127.0.0.1]) by mail9-db3 (MessageSwitch) id 1330393071284817_13310; Tue, 28 Feb 2012 01:37:51 +0000 (UTC) Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.247]) by mail9-db3.bigfish.com (Postfix) with ESMTP id 381BE22004C; Tue, 28 Feb 2012 01:37:51 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 28 Feb 2012 01:37:50 +0000 Received: from TK5EX14MBXC208.redmond.corp.microsoft.com ([169.254.1.239]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0247.005; Tue, 28 Feb 2012 01:37:39 +0000 From: Paul Midgen To: "Murray S. Kucherawy" , "spfbis@ietf.org" Thread-Topic: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) Thread-Index: AQHM8y1RU7YMwN3alUeqUtF92kjEk5ZMrTuwgAB0UwCABGae0A== Date: Tue, 28 Feb 2012 01:37:38 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E204D3153@TK5EX14MBXC208.redmond.corp.microsoft.com> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <7F7F36E50398F84DBAF25C9D51732F1E204B63FA@TK5EX14MBXC203.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E003928045EAC@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928045EAC@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Feb 2012 01:37:55 -0000 The cache contains about 450k domains based on their sending volume and a f= ew other criteria. It is refreshed every 24 hours. It doesn't strictly mirr= or DNS; records are stored fully expanded (e.g. A & MX are converted to ip4= ), and some information is dropped - e.g. spf2.0/mfrom, macros, PTR, etc. Does that help? Note that the cache is being replaced with live DNS by the end of March. -p -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: Friday, February 24, 2012 10:09 PM To: spfbis@ietf.org Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue = #9) > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On=20 > Behalf Of Paul Midgen > Sent: Friday, February 24, 2012 3:27 PM > To: S Moonesamy; spfbis@ietf.org > Cc: spfbis-chairs@tools.ietf.org > Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE=20 > (issue #9) >=20 > If I take the meaning of "unused features" to be applied to an aspect=20 > of SPF that does not factor materially into the successful daily=20 > operation of SPF, having had 6+ years to establish such a presence, a=20 > preliminary survey of 1000 domains randomly chosen from Hotmail's SPF=20 > record cache does not find a single DNS type 99 record. That sample size might be enough to avoid seeing any instances. The active= polling I'm doing has checked 29088 domains so far and found only 29 type = 99 records, so as luck would have it your ratio is approximately such that = one more might've found a single hit. :-) Can you characterize the cache at all in terms of size or duration caps? O= r is it basically a DNS cache? -MSK _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From johnl@iecc.com Mon Feb 27 17:43:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD0021E8026 for ; Mon, 27 Feb 2012 17:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.106 X-Spam-Level: X-Spam-Status: No, score=-110.106 tagged_above=-999 required=5 tests=[AWL=1.093, 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 yMLBiYS4qRds for ; Mon, 27 Feb 2012 17:43:43 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DB9EB21E800C for ; Mon, 27 Feb 2012 17:43:42 -0800 (PST) Received: (qmail 41757 invoked from network); 28 Feb 2012 01:43:37 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Feb 2012 01:43:37 -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=4f4c3149.xn--9vv.k1202; i=johnl@user.iecc.com; bh=8iUklyfrHkTuUz0/UpjKPBMwGU5EPfPAPHuie5XJFB8=; b=soPfNxt/ekH/2xYUJjOLiTo+YcXdNQLDTUxpeeDoo489+M0WgWVgufEmcZ3ELv4JuSVrxW9m9ZSnDzSUbmg531TYJeWWiGNy7M0849K3/WUf2fdR5IC9l3tc+HPgdCXtRkZhOvkuiqUv/kBxM/7xOjAv9TNju3lVp5JjmwwfzBU= 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=4f4c3149.xn--9vv.k1202; olt=johnl@user.iecc.com; bh=8iUklyfrHkTuUz0/UpjKPBMwGU5EPfPAPHuie5XJFB8=; b=wvno/6CGR3pTHFj+cLSEudYDHi5NE2kkqwLyVFjwb453CXlPUBhy7a7Rl+U5oiDINAQmHftTjeyTnO+I5nVTz5W7ZWHiMq+WAkUer7HEaXKTmb8JLn61m0WSR9hvQEhghMvRCxUxWH3/MhqvQiBErAtQovG8BUcqzhyss6BZ4+A= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 28 Feb 2012 01:43:15 -0000 Message-ID: <20120228014315.2100.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20120227162220.095a2df8@elandnews.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: sm+ietf@elandsys.com Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 01:43:43 -0000 >>Ticket URL: > >Please comment on the above issue. It's a terrible idea. I encourage you to close the ticket. R's, John From R.E.Sonneveld@sonnection.nl Tue Feb 28 00:07:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024E521F871D for ; Tue, 28 Feb 2012 00:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 OPHJ215r9OIa for ; Tue, 28 Feb 2012 00:07:46 -0800 (PST) Received: from mx11.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id C89A121F8718 for ; Tue, 28 Feb 2012 00:07:44 -0800 (PST) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0M0300A00FWV2700@hydrogen.mailtransaction.com>; Tue, 28 Feb 2012 09:07:43 +0100 (CET) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0M0300O93FWU8P00@hydrogen.mailtransaction.com>; Tue, 28 Feb 2012 09:07:43 +0100 (CET) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0M0300I2LFWUAM00@lion.sonnection.nl> for spfbis@ietf.org; Tue, 28 Feb 2012 09:07:42 +0100 (CET) Message-id: <4F4C8CC8.5090409@sonnection.nl> Date: Tue, 28 Feb 2012 09:14:00 +0100 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: S Moonesamy References: <061.51b6a8e6dda4b21b455cca692d4b547b@tools.ietf.org> <6.2.5.6.2.20120227162220.095a2df8@elandnews.com> In-reply-to: <6.2.5.6.2.20120227162220.095a2df8@elandnews.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1330416463; bh=UZzujxLRwX3/aFRbcaCnb+v9wLbQAQ8/RgF8zmtTn4M=; h=MIME-version:Content-transfer-encoding:Content-type:Message-id: Date:From:To:Cc:Subject:References:In-reply-to; b=al4oMbWBeQ8tEnj+xLJLwFBADhfbeSSl319rf3MsqTF6e/9SIFSXYEZZWAz43kesa eWY160CsDR02LwaSpbr0BraPr1LvOW3Y3MbrL42d9e5NRMpcfkj1b5j7eEha+iFcTf BQUAH3hq6u3S5Oh2sXKNIuLrCI/r8D+7PeYDUZHs= X-DKIM: OpenDKIM Filter v2.1.3 hydrogen.mailtransaction.com 0M0300A00FWV2700 Cc: spfbis@ietf.org Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 08:07:47 -0000 On 2/28/12 1:26 AM, S Moonesamy wrote: [...] >> Ticket URL: > > Please comment on the above issue. Out of scope. /rolf From vesely@tana.it Tue Feb 28 00:40:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D507F21F8712 for ; Tue, 28 Feb 2012 00:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.647 X-Spam-Level: X-Spam-Status: No, score=-4.647 tagged_above=-999 required=5 tests=[AWL=0.072, 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 LJ0NfTjnvYxB for ; Tue, 28 Feb 2012 00:40:27 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 22CD721F8710 for ; Tue, 28 Feb 2012 00:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1330418423; bh=VN84NdrnSFahigOFBfoZFyTZ1lpRqqanGYyXDlYDeHc=; l=539; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=N58k+9M2uk3Jq5X/Zn9+7KEqEDdgr8CX/mBoRg8+Ba22elY2/9gCcnlfogVRXEWeY Rc//AmCwvoBDZJyJrO3v2+fYCKPN6s+xFTEk+ED20X12m/BnXp616suL04w70R9bVn QdVDTZy7xfAtCojzttzLJfTUfuU+sGD5Sb4OQKx4= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 28 Feb 2012 09:40:23 +0100 id 00000000005DC035.000000004F4C92F7.000040EB Message-ID: <4F4C92F7.9000208@tana.it> Date: Tue, 28 Feb 2012 09:40:23 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.51b6a8e6dda4b21b455cca692d4b547b@tools.ietf.org> <6.2.5.6.2.20120227162220.095a2df8@elandnews.com> <3787744.eFobIWbcY8@scott-latitude-e6320> In-Reply-To: <3787744.eFobIWbcY8@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 08:40:28 -0000 On 28/Feb/12 01:38, Scott Kitterman wrote: > On Monday, February 27, 2012 04:26:22 PM S Moonesamy wrote: >> >>> Ticket URL: >> >> Please comment on the above issue. > > [...] The only purpose SUBMITTER serves is to give an advance look > at PRA prior to going to DATA. It's inextricably linked to Sender > ID and has no purpose in an SPF context. +1, SPF already has two identities --mfrom and helo-- that may complement one another. (By analogy, DKIM has SDID and AUID.) From hsantos@isdg.net Tue Feb 28 02:10:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2D521F8629 for ; Tue, 28 Feb 2012 02:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.460, 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 qc9DGGlOJDIP for ; Tue, 28 Feb 2012 02:10:43 -0800 (PST) Received: from secure.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7FA21F8628 for ; Tue, 28 Feb 2012 02:10:43 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1295; t=1330423838; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=XTQeHUxMa0ZyEYtOvSFn8wQUTck=; b=HCGCLn6agqY0jJy7Qp6+ wfGtsEgU+Yx2Dw8fqOrwUX+xEvCFO43vE6tiuhkcV27UfktlNpDDIU7zq+8MCZSX /WntiuF0LQjXpF1AGWJLJkClrg9Q5Sv8G1tGTtllnfkGC5OFWK6Jb6mWIJSiQUMe TXBSd7ZTonjZ/VpRTcuQbEw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 28 Feb 2012 05:10:38 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3625678036.94651.3816; Tue, 28 Feb 2012 05:10:38 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1295; t=1330423588; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=pl6nJ7f kEbY+tLJsY7X4gtAz98jXlIW946pbcoEeuGk=; b=UH94cvvVoNRWSI71Z+cb4Xl FERPtnrRjLxK3HM2/yxWVOSLhqwLBj4x+R91eS8shd1BIuCp4kF5OGNM8fZVoEVE QqiNjR8tQ07D8TKCho0U+RCAn5YAnPAcr9rZslrJ6aWwLX3sPZo4VBfStIAGmnQP cHFaHRLMvytCjHVM8Mug= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 28 Feb 2012 05:06:28 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4224610158.19846.7888; Tue, 28 Feb 2012 05:06:26 -0500 Message-ID: <4F4CA807.8030106@isdg.net> Date: Tue, 28 Feb 2012 05:10:15 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <061.51b6a8e6dda4b21b455cca692d4b547b@tools.ietf.org> <6.2.5.6.2.20120227162220.095a2df8@elandnews.com> <3787744.eFobIWbcY8@scott-latitude-e6320> <4F4C92F7.9000208@tana.it> In-Reply-To: <4F4C92F7.9000208@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 10:10:44 -0000 Alessandro Vesely wrote: > On 28/Feb/12 01:38, Scott Kitterman wrote: >> On Monday, February 27, 2012 04:26:22 PM S Moonesamy wrote: >>>> Ticket URL: >>> Please comment on the above issue. >> [...] The only purpose SUBMITTER serves is to give an advance look >> at PRA prior to going to DATA. It's inextricably linked to Sender >> ID and has no purpose in an SPF context. > > +1, SPF already has two identities --mfrom and helo-- that may > complement one another. (By analogy, DKIM has SDID and AUID.) SIDF/SUBMITTER offered the 3rd identity - PRA. I don't see it as out of scope if the charter includes consideration for the fate of 4405/4406/4407. FYI, I found this section on Google Book "Microsoft Exchange Server 2010 Unleashed" http://books.google.com/books?id=8VC9LKT4rrwC&pg=PT501&lpg=PT501&ots=z3jeJ1ltR5&dq=SMTP+Servers+supporting+RFC+4405 SPF only need three piece of information to work: o The domain in the From address in the message headers o The purported IP address of the email server that sent the message o The HELO or EHLO parameter of the server that sent the message This is pretty wide spread. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From dhc@dcrocker.net Tue Feb 28 09:17:49 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4ED21F8705 for ; Tue, 28 Feb 2012 09:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.62 X-Spam-Level: X-Spam-Status: No, score=-6.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTYkNWIQPCa1 for ; Tue, 28 Feb 2012 09:17:49 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC5821F86FA for ; Tue, 28 Feb 2012 09:17:49 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1SHHSbw007704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Feb 2012 09:17:34 -0800 Message-ID: <4F4D0C28.2070309@dcrocker.net> Date: Tue, 28 Feb 2012 09:17:28 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A6721.50901@dcrocker.net> <6.2.5.6.2.20120227124225.0a1ed6d8@elandnews.com> In-Reply-To: <6.2.5.6.2.20120227124225.0a1ed6d8@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 28 Feb 2012 09:17:34 -0800 (PST) Cc: spfbis@ietf.org, Andrew Sullivan Subject: [spfbis] Issue 9: SPF RR X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 17:17:49 -0000 On 2/27/2012 12:48 PM, S Moonesamy wrote: > There appears to be a wide variety of opinion about Issue #9. Moreover, the > discussion has revealed an interoperability concern in the existing RFC. It > seems additional discussion is going to be needed to determine what to do about > that interoperability concern, and therefore we cannot conclude anything right > now. We are therefore suspending discussion for the moment on Issue #9. SM, Thanks for the followup. I should note that my message was really meant to do two different things. One was the process concern, which you've resolved. Of course the deeper issue is getting adequate wg discussion and consensus about this part of SPF. The sequence of brief assertions that my note contained are meant to assert specific objective facts and link them in a way that produces a conclusion. The form of that was/is meant to get reactions to each piece, in the hope that that could be more tractable to resolve discrete questions of fact. For example, I asserted the simple (and intentionally simplistic) view that the RR is unused. Absent data about segmented demographics or indications of wider use, I view a usage level of (at best) 1%, with no added functional benefit, to be pragmtically equivalent to "unused". I chose not to add qualifiers, such as "effectively unused", primarily to require those who see things differently to argue for the details they see differently. I'm still hoping that this is pursued. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From schlitt@world.std.com Tue Feb 28 09:55:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2C521F8699 for ; Tue, 28 Feb 2012 09:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 xBhwtyL6Efn3 for ; Tue, 28 Feb 2012 09:55:45 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 744E021F8551 for ; Tue, 28 Feb 2012 09:55:45 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id q1SHtVbW020519; Tue, 28 Feb 2012 12:55:34 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q1SHtVow4976130; Tue, 28 Feb 2012 12:55:31 -0500 (EST) Received: from localhost (schlitt@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) with ESMTP id q1SHtVbc4965105; Tue, 28 Feb 2012 12:55:31 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: schlitt owned process doing -bs Date: Tue, 28 Feb 2012 12:55:30 -0500 From: Dan Schlitt X-X-Sender: schlitt@shell01.TheWorld.com To: Andrew Sullivan In-Reply-To: <20120222211346.GI36315@mail.yitter.info> Message-ID: References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <4F4555F5.1090301@dcrocker.net> <20120222211346.GI36315@mail.yitter.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 28 Feb 2012 10:56:07 -0800 Cc: spfbis@ietf.org Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Feb 2012 17:55:46 -0000 It seems to me that Andrew has the reasonable analysis of the situation here. It seems that some of the disfunction that surrounded the initial work in this area has persisted. That is really unfortunate. Reading the discussion brings to mind the disfunction of the usenet WG. It would be good to avoid that. I was not a participant in the earlier work but I did have some private discussion with some folks about the overloading to the TXT record. I think it was a bad idea then and still is. Having a record like the TXT record that has no defined proptocol function was a good idea on the part of the designers of the DNS. Back in the dark past there were suggestions about how to use the TXT record for keeping useful information about the network in the DNS. I used it for that kind of thing in the network I managed. I wouldn't do it in that way in today's Internet, but that is another discussion. There are people that still use the TXT record for that purpose today. My understanding of why it was used as it was had three parts. It was hard to get a new RRTYPE requiring lots of effort and delay. Some servers in use curled up and died when they encountered a "unknown" record type. And folks wanted to get on with using spf right away. If one was starting out with the design of spf today it might use a different approach for the function that the SPF RR and the specially designed TXT RR fill. But we need to deal with the way things are now. /dan -- Dan Schlitt schlitt@world.std.com On Wed, 22 Feb 2012, Andrew Sullivan wrote: > No hat. > > On Wed, Feb 22, 2012 at 12:54:13PM -0800, Dave CROCKER wrote: >> The record has yet to show a benefit in adoption of the special SPF >> RR and, hence, failed to gain that adoption. > > We agree about this. > >> The questions should be: what will make that change, and it that change viable? >> > > I was suggesting that the question should be, "Why make this change if > already-available operational benefit depends on not making the > change?" > > According to what people have said lately in this thread, all of the > following things appear to be true (some are waiting on data for confirmation): > > 1. The bulk of the clients send SPF queries first. > > 2. SPF records and the SPF-use TXT records, when they are > maintained correctly (and in the latter case maintained to the > exclusion of other things), have the same use value. > > 3. Not putting an SPF record in your zone causes you to > experience extra query traffic. > > 4. Not putting an SPF record in your zone causes your clients to > have to send extra traffic. > > Those who are arguing, "SPF records should be deprecated," are > effectively arguing that all the client software ought to be upgraded > in order to make the extra traffic go away. I was merely noting that > people could get an immediate operational benefit to themselves simply > by adding the SPF record to their zone; this requires no change in > software in at least a large number of cases, and causes a reduction > in needless DNS traffic. Seems to me like an operational benefit > available this afternoon to anyone who cared to do it. Those who want > to deprecate the RRTYPE are arguing that greater operational benefit > would come if we made a specification change and everybody on the > Internet using SPF upgraded their software. From my perspective, this > sounds like the burden of proof is being put on the wrong party. > > Best, > > A > > From agthisell@yahoo.com Tue Feb 28 11:49:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81C721F86B1 for ; Tue, 28 Feb 2012 11:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.105 X-Spam-Level: X-Spam-Status: No, score=-0.105 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPk64Q-0QIpK for ; Tue, 28 Feb 2012 11:49:08 -0800 (PST) Received: from nm13-vm4.bullet.mail.ne1.yahoo.com (nm13-vm4.bullet.mail.ne1.yahoo.com [98.138.91.173]) by ietfa.amsl.com (Postfix) with SMTP id 52E5E21F8674 for ; Tue, 28 Feb 2012 11:49:08 -0800 (PST) Received: from [98.138.90.48] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 28 Feb 2012 19:49:05 -0000 Received: from [98.138.88.236] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 28 Feb 2012 19:49:05 -0000 Received: from [127.0.0.1] by omp1036.mail.ne1.yahoo.com with NNFMP; 28 Feb 2012 19:49:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 374718.25254.bm@omp1036.mail.ne1.yahoo.com Received: (qmail 62620 invoked by uid 60001); 28 Feb 2012 19:49:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1330458545; bh=DsJjsM9UpZs7k6LG1GX1gx4LzBWYijKWpSCTcj9mpcA=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=v2zxL8/lYZVtRBnoRiX9uyT33eCLsE6zL2wxxYUGcfTtObtCIIe9iME9gVs4euZG8rHE5vTQ97wZ+9omBTRElB4bsXe7vJQb9YcQ+1xnQVZKvbxkXvy1KBf4mrjYD4cyirI2l11Q/2hgP9WEEEmWkDPJTmpJqkj3b5JpP5a0Ba8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=iot0csteq/yBRAC6NzdkbwqF/N9ZgDVUbhDtGa/f0trEpSbDJ6vXVir1XAnMz5WTBUBVrwRkPLw2kLHKChGk1CTsIZMRoGCSQ2J2CujAMkhBmSpRZONjP/mr241kBsMylfbO2ZfPiLzNdiDNkxQOimM8ymBDojx0Y7CHLTDoUGo=; X-YMail-OSG: nGyTdVoVM1nnDoFmY7Wzw40tDaBMPyowC2X5cqPjX7xumHR 9jvo96lbRTmZTjdG58QqxhDneZPSKDSC65xeRUG3Jy_5vj8Bd1Yy1_SMHKr2 a6SkZmeYkpwpz7wPvMqBsb_ICvYwSIzAYNlwIRIjKOFnopeMMsn1DxYoEx3A Wc.kIQuWWAm8tKlHfxIfoCfPJhWgOQFjbNiOvvCypAb5nSEVa7pOIO_Owa15 h7gSw6mq1yM6M7Uc4qW01AbZMWAGm5u_93HPKCt8IHozGFE7LwdDE0piarkD etfpC3FshEfBqNsrrvRa.APDOG2onmHIVv7lemIg_R4IgV2QU7v5VdGpIa9x yNMPUhvSSV4SsedmiziR5tDSNqcqddNnLmEs171UgkAdeHFPZxMoT5k9BXHs UhvtS83okPwgVOpeM2uNBs1zxycmk6KdJ1j8kHzhdsrcS.LQK.YWInfs2W.q b35g- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Tue, 28 Feb 2012 11:49:05 PST X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.116.338427 Message-ID: <1330458545.56033.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Tue, 28 Feb 2012 11:49:05 -0800 (PST) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #4: RFC 4408 Section 4.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 19:49:09 -0000 The change to add submitter to check_hosts is, in itself, obviously bogus since it adds a term that is not defined or used anywhere else in the document. Clearly, to make a useful change, more work on RFC 4408-bis would have to be done. It isn't clear at all to me what exactly Hector wants with this change. I suspect it would be clearer if Hector would give us a (very rough) draft of all the changes to the document that he sees to be related to this. As far as the previous submitter RFCs being obsoleted or whatever, I don't see how that affects anyone using the submitter option. You don't need RFCs to add SMTP options, anyone can create them. From dhc@dcrocker.net Tue Feb 28 11:58:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DAD21E804B for ; Tue, 28 Feb 2012 11:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.62 X-Spam-Level: X-Spam-Status: No, score=-6.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DFUnDgslUsZ for ; Tue, 28 Feb 2012 11:58:38 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 956F021E803B for ; Tue, 28 Feb 2012 11:58:38 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1SJwXkf011652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Feb 2012 11:58:38 -0800 Message-ID: <4F4D31E9.2000601@dcrocker.net> Date: Tue, 28 Feb 2012 11:58:33 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <4F4555F5.1090301@dcrocker.net> <20120222211346.GI36315@mail.yitter.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 28 Feb 2012 11:58:38 -0800 (PST) Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 19:58:39 -0000 On 2/28/2012 9:55 AM, Dan Schlitt wrote: > If one was starting out with the design of spf today but we aren't. the issue today is not what should have been or what was/is a good or bad idea. the constraints imposed by the charter are quite clear. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From agthisell@yahoo.com Tue Feb 28 12:03:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B717621E8052 for ; Tue, 28 Feb 2012 12:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.07 X-Spam-Level: X-Spam-Status: No, score=-0.07 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtFMyhTBG6tQ for ; Tue, 28 Feb 2012 12:03:48 -0800 (PST) Received: from nm39-vm4.bullet.mail.ne1.yahoo.com (nm39-vm4.bullet.mail.ne1.yahoo.com [98.138.229.164]) by ietfa.amsl.com (Postfix) with SMTP id 1E3B121E804B for ; Tue, 28 Feb 2012 12:03:48 -0800 (PST) Received: from [98.138.90.55] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 28 Feb 2012 20:03:44 -0000 Received: from [98.138.87.9] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 28 Feb 2012 20:03:44 -0000 Received: from [127.0.0.1] by omp1009.mail.ne1.yahoo.com with NNFMP; 28 Feb 2012 20:03:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 810703.49130.bm@omp1009.mail.ne1.yahoo.com Received: (qmail 86577 invoked by uid 60001); 28 Feb 2012 20:03:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1330459424; bh=h4nseR/RU1OogzUSGukGcYvTsrtVRn/khJupRS5KcU4=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=k7q54yP4zJZyos95Rw0p1S/Z5M5AiCJCJxiPDkT2ULzWyDPnPaJbG2in1eEbXBNIddlnZNPMOUtil+pq9JDjxT53IgkmULggihSY4t7rNE2sBHeQleLBsSTU0Rx17AWrqfWeUZ9c3J8I21JQ7diJTgjGq/UsjLzY7wx+U4eJ3UA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=EEvHrkvUzK+fRG3DCcIYiKqxPCjw/9GQ7F026IVdtuU6OIIrZTWlANdKuoxqdfTe47Znd9xOzYQ64dWDyjblInmGe4hgH64O3DIz1Bl3C/Ljs6VHo8ZBwNG79qVKm9m0VJ9c6REqsTSKDkmlg0yawFXSIMH3w8jpoHGUB9AOAT4=; X-YMail-OSG: pNZpz7YVM1l_v3ZgKQD1HRJQgh3kGpiVV1ZE6pPIcJ76xXB isY.l5_BhoOLLW0PSR73HwN.2sI0ySASuUxJ124wSlvyTpCYFBl3.tfFU.Ud _PjMdHEjwbeVL_fn5hVmuUBxl96MCOOniW7n71L8uk9H3xpspIXk4BGRtFiy 64AozWZ1kCULOh4fVfStLVtYzaDzM6e8f405J8gaGizDyQw0.Jqdch7AY16m SVS88tXXpymq9a3czM3yeqbqr1pgnpbeEPXJpeQk7AQvrRNqXg.KID5CPbqN z_ahheYg2KkX37p_vDbTI_IvhsCa8uGYP3JxXsrvH_m8xTap8g8Ei1WTyRmC KKHtNEuGc6tG.P.b2EgJzOCUaszdAMXt0kdd9gGvm.lGh2WsxwKA3vCJ2xe4 WrWlz.HYEQint9F0ceuRASKjemesiEStqD2soGog_Fbxp.TYRofYrUEqhRSt USNLVjJzGEXt2BYR72ST9QoUATZ0eBYLIpiXPAhu3VyvO2tJJORtRjTpcUkW XPnZs5gLlXLtLA7jxtAJnOcbyEnHqwYXr75k2t4VdwA4BiV8SCQ70gWaj Received: from [71.61.133.134] by web125405.mail.ne1.yahoo.com via HTTP; Tue, 28 Feb 2012 12:03:44 PST X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.116.338427 Message-ID: <1330459424.68259.YahooMailClassic@web125405.mail.ne1.yahoo.com> Date: Tue, 28 Feb 2012 12:03:44 -0800 (PST) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Feb 2012 20:03:48 -0000 Too much hand waving debates, not enough data. Again,the measurement factory's surveys give some information: Note, these percentages appear to be of domains that responded to them 2006-08 5% have TXT SPF, 0 (not just 0% rounded) have type 99 SPF 2007-10 12.5% of working zones have TXT SPF, 46 (0.0022%) have type 99 SPF 2008-10 16.72% have some form of SPF record, the type was not broken down 2009-10 12.0% have TXT, 0.2% have SPF 2010-10 15.9% have TXT, 0.4% have SPF in http://www.ietf.org/mail-archive/web/spfbis/current/msg00617.html a preliminary survey of 1000 domains randomly chosen from Hotmail's SPF record cache does not find a single DNS type 99 record. I seem to recall other stats posted, but I could not find them easily. The measurement factory surveys change quite a bit from year to year in what they choose to look at, and the results bounce around a lot more than I would expect. This might be explained by differences in methodology that I didn't notice, or that the random set of domain names resulted in a larger margin of error than I would expect. In any case, the measurement factory's results show that type 99 records are a couple of percent of the TXT records. If the results people are seeing now are only 1% or less, that gives evidence that deployment of type 99 records may be decreasing. Or, maybe the people who publish type 99 records aren't really active in email and show up in great numbers of random domains than random emails. No matter what, I can't see any evidence that the percentage of type 99 records is making enough of an increase to close the gap in the next several decades. From dhc@dcrocker.net Tue Feb 28 12:51:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B9321E8056 for ; Tue, 28 Feb 2012 12:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.619 X-Spam-Level: X-Spam-Status: No, score=-6.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BuMUfgECRDU for ; Tue, 28 Feb 2012 12:50:59 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCED21E8054 for ; Tue, 28 Feb 2012 12:50:58 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1SKoUlA012867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Feb 2012 12:50:35 -0800 Message-ID: <4F4D3E16.8050807@dcrocker.net> Date: Tue, 28 Feb 2012 12:50:30 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4F4A6721.50901@dcrocker.net> <6.2.5.6.2.20120227124225.0a1ed6d8@elandnews.com> In-Reply-To: <6.2.5.6.2.20120227124225.0a1ed6d8@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 28 Feb 2012 12:50:36 -0800 (PST) Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 20:51:01 -0000 On 2/27/2012 12:48 PM, S Moonesamy wrote: > Hi Dave, > > There appears to be a wide variety of opinion about Issue #9. Moreover, the > discussion has revealed an interoperability concern in the existing RFC. It > seems additional discussion is going to be needed to determine what to do about > that interoperability concern, and therefore we cannot conclude anything right > now. We are therefore suspending discussion for the moment on Issue #9. Responding directly: I'm a bit chagrined that I missed the basic interoperability flaw in the spec. However identifying it will probably require that the wg be more clear about basic requirements for interoperability. I'm hoping that that helps us make the details simpler. In any event, thanks for the followup. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From SRS0=vacs7=BH==stuart@gathman.org Tue Feb 28 18:02:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE84721F879C for ; Tue, 28 Feb 2012 18:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHs8Tjty+8At for ; Tue, 28 Feb 2012 18:02:54 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [24.248.44.156]) by ietfa.amsl.com (Postfix) with ESMTP id 1025C21F8796 for ; Tue, 28 Feb 2012 18:02:53 -0800 (PST) Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q1T1xv2b010666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Feb 2012 20:59:58 -0500 Message-ID: <4F4D86CD.70407@gathman.org> Date: Tue, 28 Feb 2012 21:00:45 -0500 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <20120224203134.GX48576@crankycanuck.ca> <4F47FF34.9020808@Commerco.Net> <4F48B322.2030809@tana.it> <6.2.5.6.2.20120225103447.09eefc78@resistor.net> <9452079D1A51524AA5749AD23E0039280471A5@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280471CD@exch-mbx901.corp.cloudmark.com> <4F49E931.6000902@isdg.net> <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> In-Reply-To: <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Feb 2012 02:06:43 -0000 Long ago, Nostradamus foresaw that on 02/26/2012 03:31 AM, Scott Kitterman would write: > The reason some domains publish Type SPF only is that RFC 4408 gives them absolutely no hint that's a bad idea. For 4408bis we should be honest and provide realistic guidance. > Why is it a bad idea? 1) We've established that most clients query for SPF, so you don't lose much by not publishing TXT. 2) You simplify administration because you don't have to keep the two records in sync. 3) And you satisfy all those SPF queries instead of wasting them, saving bandwidth. At this point, publishing SPF RR only is a *good* idea! (And I was planning to do so as soon as I upgrade my name server platform to RHEL6 - currently I use a script to generate TYPE99 syntax from TXT for older bind). It is only this year that publishing SPF RR became convenient for RHEL and clones! Hector tells us that MS platforms have only recently migrated to DNS 5 which can easily support the SPF RR. The clients are on board - the server side was slow in coming, but is now on ready. It would truly be a shame to tell people to just forget about it. It would be tragic if the SPF RR was then *still* not ready for SPFng as a result. From spf2@kitterman.com Tue Feb 28 19:02:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE9521E8113 for ; Tue, 28 Feb 2012 19:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 kzxdPysrAkaX for ; Tue, 28 Feb 2012 19:02:42 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CC49B21E8037 for ; Tue, 28 Feb 2012 19:02:42 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 02D1020E40E0; Tue, 28 Feb 2012 22:02:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330484562; bh=fqcopXNjXpVS9JbIK5knMamQqZEcFFRG6zCjVeH69n8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=k2HCzNDlMbZ2qry4pezqhPv/AaUwRbWLYHfWaaNyBYwHXxXsA2m1LYTig9uDeihed VuZYOxlvN0r2I7w8BqL3oxql26zLuuCCldwUekqzwreKJpSfKMKU3gpGb/pBuoiKIA lJAvbWqUuDhYDF2bbxT45oE9FPbRaQ4z1jHiScWY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D8CA220E4099; Tue, 28 Feb 2012 22:02:41 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 28 Feb 2012 22:02:37 -0500 Message-ID: <2536814.MpLNf5Cn9g@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F4D86CD.70407@gathman.org> References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> <4F4D86CD.70407@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] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Feb 2012 03:02:43 -0000 On Tuesday, February 28, 2012 09:00:45 PM Stuart Gathman wrote: > Long ago, Nostradamus foresaw that on 02/26/2012 03:31 AM, Scott > > Kitterman would write: > > The reason some domains publish Type SPF only is that RFC 4408 gives > > them absolutely no hint that's a bad idea. For 4408bis we should be > > honest and provide realistic guidance. > Why is it a bad idea? > > 1) We've established that most clients query for SPF, so you don't lose > much by not publishing TXT. > 2) You simplify administration because you don't have to keep the two > records in sync. > 3) And you satisfy all those SPF queries instead of wasting them, saving > bandwidth. > > At this point, publishing SPF RR only is a *good* idea! (And I was > planning to do so as soon as I upgrade my name server platform to RHEL6 > - currently I use a script to generate TYPE99 syntax from TXT for older > bind). > > It is only this year that publishing SPF RR became convenient for RHEL > and clones! Hector tells us that MS platforms have only recently > migrated to DNS 5 which can easily support the SPF RR. The clients are > on board - the server side was slow in coming, but is now on ready. It > would truly be a shame to tell people to just forget about it. It would > be tragic if the SPF RR was then *still* not ready for SPFng as a result. As long as there are clients that don't query for Type SPF (and there are) your record gets less exposure in Type SPF than Type TXT. That is a bad thing. I think using TXT only for v=spf1 and using Type SPF only for some future incompatible update makes perfect sense. For this new future version, now that we've spent half a decade laying the groundwork, there would be relatively few (compared to 2005/2006) deployment barriers and with no pre- existing mass of Type TXT records no need to support both. I don't propose getting rid of the type, just making it SHOULD NOT publish and SHOULD NOT check for v=spf1. Scott K From johnl@iecc.com Tue Feb 28 19:06:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9C621E8037 for ; Tue, 28 Feb 2012 19:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.128 X-Spam-Level: X-Spam-Status: No, score=-110.128 tagged_above=-999 required=5 tests=[AWL=1.071, 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 AilajzmEMAcM for ; Tue, 28 Feb 2012 19:06:38 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEF821E8025 for ; Tue, 28 Feb 2012 19:06:38 -0800 (PST) Received: (qmail 8305 invoked from network); 29 Feb 2012 03:06:35 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Feb 2012 03:06: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=4f4d963b.xn--hew.k1202; i=johnl@user.iecc.com; bh=zlwL5KkIyQQL4LHPva+VsXGED+RfhaRJMGGfC4VNbrM=; b=caBosexNL13tGK49iGuKETf9Nor0Vx69hirkzdX5Lw7+dvjlAoQULMvxbqwa5LW9tsmGFX5tfhg1lMl18oHQIMqW77nDzYzrl0vtBm2WuCknCB20qW7JZP3XxjAB7kbX5VbdEaA1xVamDGKPikGWD9ERb6/h4DZ86kBXcWcd4gY= 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=4f4d963b.xn--hew.k1202; olt=johnl@user.iecc.com; bh=zlwL5KkIyQQL4LHPva+VsXGED+RfhaRJMGGfC4VNbrM=; b=Kqx00ZabB8bASLcT0ZdrKTg6bZLHnRU+rR6ce6qX/VghFqEe+nMODeeaecIoKlAijaVwSRfjK/NyClHmnW2bdBJ87qA6Kk+O7vQ3x6htK9YyxAJymnkJ0hRdzlFF6ihs5pAgfOUBtFvj3h3RFHkNLFICekfPKBHJZAnIW8ELubQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 29 Feb 2012 03:06:12 -0000 Message-ID: <20120229030612.76337.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <2536814.MpLNf5Cn9g@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Feb 2012 03:06:39 -0000 >I don't propose getting rid of the type, just making it SHOULD NOT publish and >SHOULD NOT check for v=spf1. I'd also be OK with MAY publish but SHOULD NOT check. R's, John From spf2@kitterman.com Tue Feb 28 19:08:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03E821E8025 for ; Tue, 28 Feb 2012 19:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 dTaD0ZBS9v9E for ; Tue, 28 Feb 2012 19:08:00 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0914021E8037 for ; Tue, 28 Feb 2012 19:08:00 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9A20020E40E0; Tue, 28 Feb 2012 22:07:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330484879; bh=RzocApYY23JVFvoC8JalEfecx3Cnok6S2hh8FyNUSWA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=dod7XRSM+vtZcxwXdiShwjCkbtHqq8TpTZGlCXbw7V9uA9zEuvobqMRHBtk1ag1mB MRzgIcDquV3zP+HRq3o7UETw6Njw8MCKPAiQI9ZU1JJKuDWT8r+zZiamp4LpLhk2Tq 8ANShmfD+4vi2ECEzO4VgNvlKRhowu4qWn0qhsLE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8E34820E4099; Tue, 28 Feb 2012 22:07:59 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 28 Feb 2012 22:07:59 -0500 Message-ID: <1822646.T91qqFc4bP@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120229030612.76337.qmail@joyce.lan> References: <20120229030612.76337.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Feb 2012 03:08:00 -0000 On Wednesday, February 29, 2012 03:06:12 AM John Levine wrote: > >I don't propose getting rid of the type, just making it SHOULD NOT publish > >and SHOULD NOT check for v=spf1. > > I'd also be OK with MAY publish but SHOULD NOT check. Yes. That'd be fine. Scott K From WebMaster@Commerco.Net Tue Feb 28 20:02:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0753B21F8731 for ; Tue, 28 Feb 2012 20:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvv-9uF6HMgW for ; Tue, 28 Feb 2012 20:01:59 -0800 (PST) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6B821F872D for ; Tue, 28 Feb 2012 20:01:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=CXPa0X0eJuy/aSgxzyQmPQKQnu3DfZPwwuIjIoR+WDG02ufzr15shWaoRKpQZrfZcXvdFhub5ElMcECUFL1TUdd4d+4xP/1WK+LmYfa9F1cqv8CioqKNClmyT2PSWvdSeRzd43Y2zLbKIDgC5JDVL5Sa57DkndBXiNiIwDjCsqo= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Wed, 29 Feb 2012 04:01:56 +0000 Message-ID: <4F4DA32D.8020102@Commerco.Net> Date: Tue, 28 Feb 2012 21:01:49 -0700 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120224114427.0a6adcc0@elandnews.com> <4d908ff5-a435-4022-ad8c-5fefe2c55dbe@email.android.com> <4F4D86CD.70407@gathman.org> <2536814.MpLNf5Cn9g@scott-latitude-e6320> In-Reply-To: <2536814.MpLNf5Cn9g@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 Subject: Re: [spfbis] Call for intermediate consensus on SPF RRTYPE (issue #9) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Feb 2012 04:02:00 -0000 On 2/28/2012 8:02 PM, Scott Kitterman wrote: > On Tuesday, February 28, 2012 09:00:45 PM Stuart Gathman wrote: >> Long ago, Nostradamus foresaw that on 02/26/2012 03:31 AM, Scott >> >> Kitterman would write: >>> The reason some domains publish Type SPF only is that RFC 4408 gives >>> them absolutely no hint that's a bad idea. For 4408bis we should be >>> honest and provide realistic guidance. >> Why is it a bad idea? >> >> 1) We've established that most clients query for SPF, so you don't lose >> much by not publishing TXT. >> 2) You simplify administration because you don't have to keep the two >> records in sync. >> 3) And you satisfy all those SPF queries instead of wasting them, saving >> bandwidth. >> >> At this point, publishing SPF RR only is a *good* idea! (And I was >> planning to do so as soon as I upgrade my name server platform to RHEL6 >> - currently I use a script to generate TYPE99 syntax from TXT for older >> bind). >> >> It is only this year that publishing SPF RR became convenient for RHEL >> and clones! Hector tells us that MS platforms have only recently >> migrated to DNS 5 which can easily support the SPF RR. The clients are >> on board - the server side was slow in coming, but is now on ready. It >> would truly be a shame to tell people to just forget about it. It would >> be tragic if the SPF RR was then *still* not ready for SPFng as a result. > > As long as there are clients that don't query for Type SPF (and there are) > your record gets less exposure in Type SPF than Type TXT. That is a bad > thing. > > I think using TXT only for v=spf1 and using Type SPF only for some future > incompatible update makes perfect sense. For this new future version, now > that we've spent half a decade laying the groundwork, there would be > relatively few (compared to 2005/2006) deployment barriers and with no pre- > existing mass of Type TXT records no need to support both. > > I don't propose getting rid of the type, just making it SHOULD NOT publish and > SHOULD NOT check for v=spf1. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > +1. And, if this all makes sense to the rest of the list, it actually solves the apparently dicey problem of getting rid of or not getting rid of the SPF RR rather nicely - especially with John Levine's MAY publish suggestion. Essentially, it puts SPF RR into a kind of stasis, leaving the lives or retires call to the future rather than an absolutely something that needs addressing in the SPFbis today. Alan M. From sm@elandsys.com Wed Feb 29 10:24:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C22121F85B9 for ; Wed, 29 Feb 2012 10:24:23 -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 kB16L0SSKyW7 for ; Wed, 29 Feb 2012 10:24:20 -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 CFCB421F846A for ; Wed, 29 Feb 2012 10:24:20 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1TIO8TG019180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Feb 2012 10:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330539859; i=@elandsys.com; bh=FNLZLsbiV9zJug7nMQ65qeVFKzc3swXNySrpSwA+nAQ=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=r4D5saZ3PJyPK3cbk8b1MR9+WWLzH9txxocDngmPJ2ljSuMXShA7YhytYq7TPypEE /lj2PQ/MTPU2PIfo3ro2OqsXmFk4+9GX8P59aqq0+PlMfHKOaIBLFHvfAByqvWNsMm EE0zeQjYrnFCVGD9bwh1Tch8xEU4wTit3iHf646o= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330539859; i=@elandsys.com; bh=FNLZLsbiV9zJug7nMQ65qeVFKzc3swXNySrpSwA+nAQ=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Y1p7WZ4RqRHNI+s38wVPbbR/oZJmqacXfGQOL6x6l5aYVYkLe1jrJBC/iDaIf9vpl CTGmS9CMgmkg0r3WNbPMqSzQ5Yu+m55Zx/HNf85zdgFxvDi85rV4cKPQhUYe7keNjI t9eSsDyPwAKChGYIQwr3E2laDxijcyTJiYwBazbI= Message-Id: <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Feb 2012 09:32:59 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 18:24:23 -0000 At 20:02 16-02-2012, spfbis issue tracker wrote: >#13: RFC 4408: Best-Guess SPF > > Message posted by Murray Kucherawy on 26 Feb 2012: > > I'd like to have a section, or at least an appendix, that talks about > best-guess SPF: What it is, why/when it is or isn't a good idea, etc. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00398.html [snip] >Ticket URL: I am going to classify Issue #13 as "Hold for document update". If there are any objections, please post them to this mailing list. BTW, the issue may be opened for discussion if an open issue is related to this issue. Please let me know if it occurs. Regards, S. Moonesamy SPFBIS WG co-chair From sm@elandsys.com Wed Feb 29 10:24:24 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D8B21F8622 for ; Wed, 29 Feb 2012 10:24:24 -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 68HRRVfO1ZkM for ; Wed, 29 Feb 2012 10:24:24 -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 53A7221F85EC for ; Wed, 29 Feb 2012 10:24:24 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1TIO8TI019180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Feb 2012 10:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330539863; i=@elandsys.com; bh=OIfuJm6dJz8B/cxBJUritY1ZDLginmKgZqir7xexFus=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=h1GMoRbO4O0Zclq1g/8irjZQ1FSi/bCtAVV1+5gPdP6ecTiAS3/oL2Z0PHvyqzo6O i6G7yMyYhQqiJU6dM8J4PIzEJWF2KiCAjK7Nxgx8SgIeyxAYoWPMmf5EHgMErFP1p1 OGLrzUJEYvaVUmyNrWsI3wm3E5xU6OFTppJbE4g8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330539863; i=@elandsys.com; bh=OIfuJm6dJz8B/cxBJUritY1ZDLginmKgZqir7xexFus=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=3RzqMcwCDyMt+Nm1aSlU3q0ncXo6ykQqeYdGoxkuk3SlKKYqCNm0ltOX2zeryBM1u VAxyf6VsvBmStxgCsm1eH3Mv01fBKk4CoDFHLlIGjfuCFxsKNgKNIi4MBvGZK0xA95 5yb/rm2Kns3mBymZmkdm0b4dts0YiWno3RKJ+oUA= Message-Id: <6.2.5.6.2.20120229093632.0aa76cd0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Feb 2012 09:38:49 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.64b0ba6d75582bbe683c5919ea3513b2@tools.ietf.org> References: <061.64b0ba6d75582bbe683c5919ea3513b2@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #19: RFC 4408: Section 7 Received-SPF examples use incorrect syntax X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 18:24:25 -0000 At 07:12 21-02-2012, spfbis issue tracker wrote: >#19: RFC 4408: Section 7 Received-SPF examples use incorrect syntax > > Received-SPF examples use incorrect syntax > > Suggested wording: > > The examples in section 7 are incorrectly quoted, and should look like > this: > > Received-SPF: Pass (mybox.example.org: domain of > myname@example.com designates 192.0.2.1 as permitted sender) > receiver=mybox.example.org; client-ip=192.0.2.1; > envelope-from="myname@example.com"; helo=foo.example.com; > > Received-SPF: Fail (mybox.example.org: domain of > myname@example.com does not designate > 192.0.2.1 as permitted sender) > identity=mailfrom; client-ip=192.0.2.1; > envelope-from="myname@example.com"; > > Rationale: > > In RFC4408, key-value-pair is defined as: > > key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) > > However, the examples look like this: > > Received-SPF: Pass (mybox.example.org: domain of > myname@example.com designates 192.0.2.1 as permitted sender) > receiver=mybox.example.org; client-ip=192.0.2.1; > envelope-from=; helo=foo.example.com; > > Notice that envelope-from in both cases is NOT a dot-atom or quoted- > string. > > None of '<','>','@' are legal chars for dot-atom. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00476.html [snip] >Ticket URL: I am going to classify Issue #19 as "Hold for document update". If there are any objections, please post them to this mailing list. BTW, the issue may be opened for discussion if an open issue is related to this issue. Please let me know if it occurs. Regards, S. Moonesamy SPFBIS WG co-chair From sm@elandsys.com Wed Feb 29 10:30:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C81621F86BB for ; Wed, 29 Feb 2012 10:30:03 -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=[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 dBsvFJFcK0kX for ; Wed, 29 Feb 2012 10:30:01 -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 0491F21F869D for ; Wed, 29 Feb 2012 10:30:00 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1TIO8TK019180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Feb 2012 10:24:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330539867; i=@elandsys.com; bh=XmEv5xRJqGoN8l8ubwprRgjv2zmqUb3FZe/YsKJKfUQ=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=MbNkY89MEMm+Whm/Kq9dadme2Sn6zxIoi5lJTISbBOyYFceEY0oy3mznV3z0ofEd4 ZcUozOzPUvBg6obAW07rQbWei7S3NhndwesROczzfDdRiS+3ceSOgU0QoROyGJKvpT 00F3V6HWgDxUPhY7mliQBiWNIcJeNSLXdeVTLGZM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330539867; i=@elandsys.com; bh=XmEv5xRJqGoN8l8ubwprRgjv2zmqUb3FZe/YsKJKfUQ=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=ATuImXlIpjdaG1FMhsPGf9LOCdtb1b4pK/MHo0fK2+5rwYTpM97vHg/UtzQD9Fnp/ uuPch7reHJ7QqzZ0mv2CVScYLfRIPKI8rliFRqVik7LkhwHMdxbAhvHuVLsuU10a++ yOMGw/+T5lDKJTXTa9v5QgpBWiRcxSpO+qKWmh6I= Message-Id: <6.2.5.6.2.20120229094019.0aa76a40@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Feb 2012 09:41:19 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.3a7be166b4161bed289082563f6dd187@tools.ietf.org> References: <061.3a7be166b4161bed289082563f6dd187@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #23: RFC 4408: Typos X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Feb 2012 18:30:03 -0000 At 07:22 21-02-2012, spfbis issue tracker wrote: >#23: RFC 4408: Typos > > Miscellaneous typos > > Missing indentation for the second paragraph of the [US-ASCII] > reference reported by Wayne. > Missing line break on page 46 before mary.mobile-users reported by > Wayne. > Typo: "Danish" instead of "Danisch" in the references confirmed by > Wayne and Frank. > Missing words in the last sentence of the third paragraph of section > 6.1: > "The and arguments remain the same as in the current > evaluation of check_host()." (reported by Julian) > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00476.html [snip] >Ticket URL: I am going to classify Issue #23 as editorial. If there are any objections, please post them to this mailing list. Regards, S. Moonesamy SPFBIS WG co-chair From sm@elandsys.com Wed Feb 29 10:30:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4BD21F869D for ; Wed, 29 Feb 2012 10:30:03 -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 e3ryG717cHxs for ; Wed, 29 Feb 2012 10:30:01 -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 21FA921F86A7 for ; Wed, 29 Feb 2012 10:30:01 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1TIO8TM019180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Feb 2012 10:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330539871; i=@elandsys.com; bh=ag5sWX4i0UU4TwUFe2TX1MajukWS8B4gc/d0028vVuk=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=wNodCOjwa6jBE6zQll6jgToiWgpT/LvVVM38cvUsro5BcRqelhDqPVpCDSBAMbw9y MfdoqDAF/8kxdI4Im/CSko8gp6hTiwwvlGS5n2x4b2EruORViBq0NF5RWDo1iwGeXy JEjV6Bj4fjQBcwEcgDTeqrHCGGgiXmaKmukT6t7Q= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330539871; i=@elandsys.com; bh=ag5sWX4i0UU4TwUFe2TX1MajukWS8B4gc/d0028vVuk=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=Z+myjgo5O4Gw+a7ovKw1fd0Nm/oPsHHZ2ElY2jLObDJ42FHbN1o6ELjLXPT8o4Uv8 o7/rOafwbo12ybXWusN9o270VY6JNXihaOFWaEoEp1OBH79ol3TuWpD9tuod8AAhCg fVDNk9WkqQbmNxcFOp397/1ABP/w5gQWcpfleMtE= Message-Id: <6.2.5.6.2.20120229094232.0aab6668@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Feb 2012 09:42:50 -0800 To: spfbis@ietf.org From: S Moonesamy Cc: spfbis@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #17: RFC 4408: Section 8.1 Undefined "uric" set X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Feb 2012 18:30:03 -0000 At 07:08 21-02-2012, spfbis issue tracker wrote: >#17: RFC 4408: Section 8.1 Undefined "uric" set > > Undefined uric set > > Suggested wording: > > Replace "uric" by "unreserved" in section 8.1. > > Rationale: > > uric was defined in RFC 2396, but later removed in RFC 3986. Because RFC > 4408 has a normative reference to RFC 3986 (AKA STD 66) uric has to be > replaced by a modern set of characters affected by the URL escaping for > uppercased macros. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00476.html [snip] >Ticket URL: I am going to classify Issue #17 as "Hold for document update". If there are any objections, please post them to this mailing list. BTW, the issue may be opened for discussion if an open issue is related to this issue. Please let me know if it occurs. Regards, S. Moonesamy SPFBIS WG co-chair From sm@elandsys.com Wed Feb 29 12:57:34 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0384321E809B for ; Wed, 29 Feb 2012 12:57:34 -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=[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 qg2qxxYh3saU for ; Wed, 29 Feb 2012 12:57:32 -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 C51B421E8097 for ; Wed, 29 Feb 2012 12:57:32 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1TKvGsj017415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Feb 2012 12:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330549050; i=@elandsys.com; bh=B9R4hleHAnvsMHfC67OefXT5V9cH6oMJGlzrzz620D0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=K3B0btL27XENBtsisGdjC/DrwLPsF5CETLloB8krjSEazWOUhlxN2odYxbb7wbUsL uYqIBjymRToxZFDr7bo/nwMGGvxm9z5RPTZXMKkgUgPFiJY2il50mbsvZjCztpn0Q4 6C6jTIUBbX3XVxEDSNgIpmOFCHSt8MmQsiH7VD+k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330549050; i=@elandsys.com; bh=B9R4hleHAnvsMHfC67OefXT5V9cH6oMJGlzrzz620D0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=HcIiN7oqqxboeMx04Mje1CAi8bJqqI1swialIgWRc2ek1KLyIaBj85m8L0JQYNLd9 9VAyiTzQ4HKQ58inUA74EkR0SHi9r+g1cxNgAtyk8/wSW5M9TzrriQAZhh78uJSNkB EC/mvHvEHb/+nFUWe4Pid5p8MRO9MJYIU7wqM9qE= Message-Id: <6.2.5.6.2.20120229120024.0b0d1e28@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Feb 2012 12:56:55 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1987882.xVSqvW7a1T@scott-latitude-e6320> References: <061.455654aa40583da61895c644f7120a55@tools.ietf.org> <1775995.RF6pGKfp5q@scott-latitude-e6320> <9452079D1A51524AA5749AD23E003928045F40@exch-mbx901.corp.cloudmark.com> <1987882.xVSqvW7a1T@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Feb 2012 20:57:34 -0000 Hello, I'll attempt to summarize the discussion of Issue #1. If I misinterpreted or misunderstood your comments, please let me know. Murray S. Kucherawy mentioned not knowing whether the (SERVFAIL) error is transient (resources, perhaps) or one that does indeed require operator intervention [1]. Andrew Sullivan, as a participant, agrees that RCODE=2 is not a permanent error in the DNS [2]. Hector Santos agreed with Andrew Sullivan [3] Scott Kitterman mentioned that he would like to allow (but not require) receivers to track SERVFAIL based temperrors and if they persist for more than $PERIOD (let's start the bidding at 24 hours) then future consectutive SERVFAIL responses for that domain MAY be considered permanent errors [4]. He also mentioned that until this discussion, I thought the solution was treating SERVFAIL as a permanent error, but now I see that isn't a good idea, so I proposed this as a conceptually straightforward (if someone complex to implement) method for solving the problem [5]. The issue was open based on the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg00259.html My opinion is that we can come to an intermediate conclusion on this issue based on what we know at this point in time. I will read the entire messages (some of them are not referenced in this message) posted about Issue #1 again and any feedback you provide before discussing the question with my co-chair and reaching a conclusion. Any conclusion is intermediate in the sense that the working group will be asked to comment on the WG drafts listed as deliverables and there will be ample opportunity to review the conclusion. I have been asked what "Hold for document update" means. The working group does not have any WG draft up for discussion yet. When there is a WG draft, the working group can discuss about the exact text that goes into it. Regards, S. Moonesamy SPFBIS WG co-chair 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00569.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00590.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00591.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00589.html 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg00631.html From msk@cloudmark.com Wed Feb 29 13:00:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D9221E80A1 for ; Wed, 29 Feb 2012 13:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUzBwKT8Q+t6 for ; Wed, 29 Feb 2012 13:00:58 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8682721E80A0 for ; Wed, 29 Feb 2012 13:00:58 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 29 Feb 2012 13:00:58 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors Thread-Index: AQHM8Z1H6I5T9g0T0E20useE1cLBoZZKHlgAgAKXugCAAILC4IAAiJEAgAcq04D//3qJQA== Date: Wed, 29 Feb 2012 21:00:57 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392806D8F2@exch-mbx901.corp.cloudmark.com> References: <061.455654aa40583da61895c644f7120a55@tools.ietf.org> <1775995.RF6pGKfp5q@scott-latitude-e6320> <9452079D1A51524AA5749AD23E003928045F40@exch-mbx901.corp.cloudmark.com> <1987882.xVSqvW7a1T@scott-latitude-e6320> <6.2.5.6.2.20120229120024.0b0d1e28@resistor.net> In-Reply-To: <6.2.5.6.2.20120229120024.0b0d1e28@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Feb 2012 21:00:59 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of S Moonesamy > Sent: Wednesday, February 29, 2012 12:57 PM > To: spfbis@ietf.org > Cc: Andrew Sullivan > Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors >=20 > I'll attempt to summarize the discussion of Issue #1. If I > misinterpreted or misunderstood your comments, please let me know. > [...] Your summary seems right to me. I would also point out that this is probab= ly going to be at best a MAY, and also suggest we include a reference to th= e Happy Eyeballs draft out of the v6ops WG because they proposed something = similar to what Scott suggested, and it's in the RFC Editor queue now, so i= t appears to have precedent for not being a completely crazy idea. -MSK From msk@cloudmark.com Wed Feb 29 13:05:24 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F60021E80A6 for ; Wed, 29 Feb 2012 13:05:24 -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=[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 LEmOPX3D7r0o for ; Wed, 29 Feb 2012 13:05:24 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAAD21E80A0 for ; Wed, 29 Feb 2012 13:05:23 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Wed, 29 Feb 2012 13:05:23 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" , "spf-discuss@v2.listbox.com" Thread-Topic: [marf] Last Call: (SPF Authentication Failure Reporting using the Abuse Report Format) to Proposed Standard Thread-Index: AQHM9vKoH2IAJxfUa0qNXkqWnOC96ZZUXaOQ Date: Wed, 29 Feb 2012 21:05:22 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392806D90A@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [spfbis] FW: [marf] Last Call: (SPF Authentication Failure Reporting using the Abuse Report Format) to Proposed Standard X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 21:05:24 -0000 FYI, in case anyone wants to comment. -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of The= IESG Sent: Wednesday, February 29, 2012 6:59 AM To: IETF-Announce Cc: marf@ietf.org Subject: [marf] Last Call: (SPF Auth= entication Failure Reporting using the Abuse Report Format) to Proposed Sta= ndard The IESG has received a request from the Messaging Abuse Reporting Format W= G (marf) to consider the following document: - 'SPF Authentication Failure Reporting using the Abuse Report Format' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final= comments on this action. Please send substantive comments to the ietf@ietf= .org mailing lists by 2012-03-14. Exceptionally, comments may be sent to ie= sg@ietf.org instead. In either case, please retain the beginning of the Sub= ject line to allow automated sorting. Abstract This memo presents extensions to the Abuse Reporting Format (ARF), and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion. This memo updates RFC4408 by providing an IANA registry for SPF modifiers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-spf-reporting/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-spf-reporting/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From spf2@kitterman.com Wed Feb 29 13:10:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A73821F86AD for ; Wed, 29 Feb 2012 13:10:15 -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 9QExe74Z3xZ1 for ; Wed, 29 Feb 2012 13:10:14 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2E61821F8677 for ; Wed, 29 Feb 2012 13:10:14 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 55DD4D04083; Wed, 29 Feb 2012 15:10:13 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330549813; bh=N/1OOK16NJd9MY6ZZXUuyWIaf2PvZOTKJ/WMwr7V08M=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=kH03YGOPnzb/aRRG9aQlDwcTewRxV6zhMg1GBSYTZrUr44842EWmZarBCo1C8iAU4 LjgzUMCfqdUDnZJ19XCbw1kWmJObiCDHA/5WgLVdQHt/PrgJZtBNewXRrZEdCP+IeN /YeW8C2bQMmjQE8AkO4HJf+oOtvu3zj6Hm3Cfm68= Received: from 171.sub-97-21-44.myvzw.com (171.sub-97-21-44.myvzw.com [97.21.44.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B7E68D0400C; Wed, 29 Feb 2012 15:10:12 -0600 (CST) References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 29 Feb 2012 16:10:20 -0500 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 21:10:15 -0000 S Moonesamy wrote: >At 20:02 16-02-2012, spfbis issue tracker wrote: >>#13: RFC 4408: Best-Guess SPF >> >> Message posted by Murray Kucherawy on 26 Feb 2012: >> >> I'd like to have a section, or at least an appendix, that talks >about >> best-guess SPF: What it is, why/when it is or isn't a good idea, >etc. >> >> http://www.ietf.org/mail-archive/web/spfbis/current/msg00398.html > >[snip] > >>Ticket URL: > >I am going to classify Issue #13 as "Hold for document update". If >there are any objections, please post them to this mailing >list. BTW, the issue may be opened for discussion if an open issue >is related to this issue. Please let me know if it occurs. This is not in RFC 4408, so it's only in scope if it's widely deployed. If we are going to consider it in scope, there should be some evidence of widespread use. Personally, I think the most we should do is say MUST NOT (we can't stop people from doing so, but we can make it clear it's wrong to call a best guess result an SPF result). Scott K From msk@cloudmark.com Wed Feb 29 13:18:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15BC21E8097 for ; Wed, 29 Feb 2012 13:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ddmJ79fUEzr for ; Wed, 29 Feb 2012 13:18:57 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id F401021E8083 for ; Wed, 29 Feb 2012 13:18:56 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 29 Feb 2012 13:18:56 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #13: RFC 4408: Best-Guess SPF Thread-Index: AQHM9w9gv5LdotHEQE+MDxPo9jLb7pZU5RMA//97qHA= Date: Wed, 29 Feb 2012 21:18:55 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392806D969@exch-mbx901.corp.cloudmark.com> References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 21:18:57 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > Behalf Of Scott Kitterman > Sent: Wednesday, February 29, 2012 1:10 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF >=20 > This is not in RFC 4408, so it's only in scope if it's widely deployed. > If we are going to consider it in scope, there should be some evidence > of widespread use. The question of "widely deployed" is as interesting as the question of whet= her something is "used" if only clients query for it. Does Gmail doing Bes= t Guess SPF count as widespread use because of the percentage of global ema= il traffic they receive, or only count as a single implementation? I agree with HFDU. I haven't formed an opinion on what we should say about= it yet, but I think we should say something about it either way. -MSK From spf2@kitterman.com Wed Feb 29 13:31:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64DF21F8681 for ; Wed, 29 Feb 2012 13:31:46 -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 uAMLkVpqrM8B for ; Wed, 29 Feb 2012 13:31:45 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id ADC9721F8678 for ; Wed, 29 Feb 2012 13:31:45 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 06CA7D04083; Wed, 29 Feb 2012 15:31:45 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330551105; bh=AgmkFQo/JJYLWrOq+6TOxdWOi0lR8QcGUGYD3IXYd1c=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=CKDmv2N/k47n+V39APPu/TFTGSVzPLw718FGXCal2L/JNjCERHVZGVm3VE5F1iGRV UObxarJjDqCtLZ5sug4zSzmkkiBTs4H3FvaUG3gJlX417SEfjwxW3NOOi7CVVpSU3N 6NAWZjbGnzN2wcOt8rcjMVywQz5ihEb0tb5qWiFk= Received: from 171.sub-97-21-44.myvzw.com (171.sub-97-21-44.myvzw.com [97.21.44.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id BB63BD0400C; Wed, 29 Feb 2012 15:31:43 -0600 (CST) References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <9452079D1A51524AA5749AD23E00392806D969@exch-mbx901.corp.cloudmark.com> User-Agent: K-9 Mail for Android In-Reply-To: <9452079D1A51524AA5749AD23E00392806D969@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 29 Feb 2012 16:29:51 -0500 To: "spfbis@ietf.org" Message-ID: <610324ff-efea-4337-b400-a968a8020079@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 21:31:46 -0000 "Murray S. Kucherawy" wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On >> Behalf Of Scott Kitterman >> Sent: Wednesday, February 29, 2012 1:10 PM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF >> >> This is not in RFC 4408, so it's only in scope if it's widely >deployed. >> If we are going to consider it in scope, there should be some >evidence >> of widespread use. > >The question of "widely deployed" is as interesting as the question of >whether something is "used" if only clients query for it. Does Gmail >doing Best Guess SPF count as widespread use because of the percentage >of global email traffic they receive, or only count as a single >implementation? > >I agree with HFDU. I haven't formed an opinion on what we should say >about it yet, but I think we should say something about it either way. Just FYI, it wasn't left out of RFC 4408 by accident. It was considered too crazy a concept for standardization. I'm not sure what that suggests for 4408bis. Scott K From sm@elandsys.com Wed Feb 29 13:34:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB4421F86A5 for ; Wed, 29 Feb 2012 13:34:45 -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=[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 ZHt8Np3qdy64 for ; Wed, 29 Feb 2012 13:34:44 -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 8708D21F86A4 for ; Wed, 29 Feb 2012 13:34:44 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1TLYVTT019610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Feb 2012 13:34:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330551283; i=@elandsys.com; bh=PUX/6Xj3ZfAOxmINaFTUTl1wN2eIjRnDpa3s+N+TrMw=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=CNS7Ku3cUZzwTw6hsrPIFlnPwZNZiXTmAKzCphVNY80NW6MePQ0Kfl0YkTPVHmEjG RlN6h9m2VeI3o+SgqbxwBt+OkyQ3C4kA+b0NdvfBOyBXtqdGh5kwouB75ZZmc6kKL9 80xmkeMpcKx56qF+lk83omqxaWhcbBJVbpus7dzU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330551283; i=@elandsys.com; bh=PUX/6Xj3ZfAOxmINaFTUTl1wN2eIjRnDpa3s+N+TrMw=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=36/FuIPtR+FOfqnWYNhzXUvrQTKwD9rmBKlMYi+HU4nJG6wAZ2XJF5QTyd5Gf6Iyr diAgKN3HQCpQQuQsBI09Zfjep1Uax5IeqbgXeOgIxoQl9SfmG60g3RWConr1HF2kJ+ HOwLVO9rWFvbvLXIFrBLCAPqLy3IJUnVqaPBIv9A= Message-Id: <6.2.5.6.2.20120229132320.0b45dd78@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Feb 2012 13:26:34 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <9452079D1A51524AA5749AD23E00392806D969@exch-mbx901.corp.cl oudmark.com> References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <9452079D1A51524AA5749AD23E00392806D969@exch-mbx901.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Widely deployed (was: #13: RFC 4408: Best-Guess SPF) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 21:34:45 -0000 Hello, I opened this thread so that the WG can comment on the question of "widely deployed". Regards, S. Moonesamy SPFBIS WG co-chair From msk@cloudmark.com Wed Feb 29 13:45:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD6221F85FD for ; Wed, 29 Feb 2012 13:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm6W1G8q68SG for ; Wed, 29 Feb 2012 13:45:19 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id DECE221F85F6 for ; Wed, 29 Feb 2012 13:45:19 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 29 Feb 2012 13:45:19 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #13: RFC 4408: Best-Guess SPF Thread-Index: AQHM9w9gv5LdotHEQE+MDxPo9jLb7pZU5RMA//97qHCAAInMgP//fZyQ Date: Wed, 29 Feb 2012 21:45:18 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392806DAC0@exch-mbx901.corp.cloudmark.com> References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <9452079D1A51524AA5749AD23E00392806D969@exch-mbx901.corp.cloudmark.com> <610324ff-efea-4337-b400-a968a8020079@email.android.com> In-Reply-To: <610324ff-efea-4337-b400-a968a8020079@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 21:45:20 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > Behalf Of Scott Kitterman > Sent: Wednesday, February 29, 2012 1:30 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF >=20 > Just FYI, it wasn't left out of RFC 4408 by accident. It was considered > too crazy a concept for standardization. I'm not sure what that > suggests for 4408bis. Fair enough. I think the charter allows addition of pedagogy based on experience. There= 's this thing out there that's document in several places now (JFGI) which = might leave some readers wondering if it's a good idea or not. This is an = opportunity to say something about it one way or another. Unless we want t= o make a normative statement that it's a bad idea, an informative appendix = that actually writes down what the pre-IETF people felt about it, along wit= h some anecdotal experience from parties that tried, would be just fine wit= h me. -MSK From msk@cloudmark.com Wed Feb 29 13:51:38 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1925921E8035 for ; Wed, 29 Feb 2012 13:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puYfGMsSAK1w for ; Wed, 29 Feb 2012 13:51:37 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 23D3C21E8026 for ; Wed, 29 Feb 2012 13:51:37 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Wed, 29 Feb 2012 13:51:36 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Widely deployed (was: #13: RFC 4408: Best-Guess SPF) Thread-Index: AQHM9yn43dXyFtWi50y3/BPCopXTg5ZUaJsg Date: Wed, 29 Feb 2012 21:51:35 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392806DAE7@exch-mbx901.corp.cloudmark.com> References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <9452079D1A51524AA5749AD23E00392806D969@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120229132320.0b45dd78@resistor.net> In-Reply-To: <6.2.5.6.2.20120229132320.0b45dd78@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Widely deployed (was: #13: RFC 4408: Best-Guess SPF) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 21:51:38 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of S Moonesamy > Sent: Wednesday, February 29, 2012 1:27 PM > To: spfbis@ietf.org > Subject: [spfbis] Widely deployed (was: #13: RFC 4408: Best-Guess SPF) >=20 > I opened this thread so that the WG can comment on the question of > "widely deployed". Both the "How many implementations?" and "How much exercise does it get?" a= re interesting. It amounts to a depth vs. breadth argument in my view. Bu= t I think sometimes it can be more general: Just look at how much input div= ersity there is, regardless of how many installations there are. In the case of a domain authentication technology like SPF, I think the mor= e salient question is "How many domains has it checked?" I can't see much = of a difference between, say, a thousand sites each evaluating a single dom= ain versus one site that checks a thousand domains. So even if only Gmail implements Best Guess SPF, I would call that widely d= eployed, because it sees enough of a diversity of inbound mail to make mean= ingful observations about its efficacy. Also, Best Guess SPF is not itself a protocol; it's more of an applicabilit= y statement of SPF. -MSK From dhc@dcrocker.net Wed Feb 29 14:25:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CED21E8098 for ; Wed, 29 Feb 2012 14:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.618 X-Spam-Level: X-Spam-Status: No, score=-6.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oldNvshO8926 for ; Wed, 29 Feb 2012 14:25:39 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 843E621E807C for ; Wed, 29 Feb 2012 14:25:39 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1TMPXxN023017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Feb 2012 14:25:39 -0800 Message-ID: <4F4EA5DC.9040204@dcrocker.net> Date: Wed, 29 Feb 2012 14:25:32 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 29 Feb 2012 14:25:39 -0800 (PST) Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 22:25:40 -0000 On 2/29/2012 1:10 PM, Scott Kitterman wrote: > This is not in RFC 4408, so it's only in scope if it's widely deployed. This strikes me as an impressively dangerous feature. At a minimum, we should see a specification for it, rather than discuss it merely as an idea. My guess is that this has narrow application and currently very limited deployment, at best. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Wed Feb 29 14:27:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F13121F86D3 for ; Wed, 29 Feb 2012 14:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSe0xcjzBX4n for ; Wed, 29 Feb 2012 14:27:28 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id EBC4221F86C7 for ; Wed, 29 Feb 2012 14:27:27 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Wed, 29 Feb 2012 14:27:27 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #13: RFC 4408: Best-Guess SPF Thread-Index: AQHM9w9gv5LdotHEQE+MDxPo9jLb7pZU5RMAgAAVAwD//3oycA== Date: Wed, 29 Feb 2012 22:27:26 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392806DBE8@exch-mbx901.corp.cloudmark.com> References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <4F4EA5DC.9040204@dcrocker.net> In-Reply-To: <4F4EA5DC.9040204@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 22:27:28 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dave Crocker > Sent: Wednesday, February 29, 2012 2:26 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF >=20 > On 2/29/2012 1:10 PM, Scott Kitterman wrote: > > This is not in RFC 4408, so it's only in scope if it's widely > > deployed. >=20 > This strikes me as an impressively dangerous feature. I'd be fine with us saying just that if that's consensus. > At a minimum, we should see a specification for it, rather than discuss > it merely as an idea. http://www.openspf.org/FAQ/Best_guess_record We could also include that text or something similar, just so everyone know= s what it is. > My guess is that this has narrow application and currently very limited > deployment, at best. What's that mean, exactly? :-) -MSK From spf2@kitterman.com Wed Feb 29 14:47:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F0A21F855B for ; Wed, 29 Feb 2012 14:47:00 -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 IJ2Qv1z5YSCc for ; Wed, 29 Feb 2012 14:46:59 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2C17E21F8542 for ; Wed, 29 Feb 2012 14:46:59 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 552C0D04083; Wed, 29 Feb 2012 16:46:58 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330555618; bh=MvUy540QrKx1e73W+biIeQ2t28snyZUe9mpVztpHq8U=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=Mkb0q9igY8COZNQg8clu7YgVdDSFjQxN+oz7nh2a3PH8NO76H9Syqw/7DCekSxxHC fkp5edYJyPIqezddycdScf5AB0GHGMxHDqAri1qCK1Yt7iz1NXwdAAaBME9p4FIky6 675A/+1TYfxPoXrzfQzcR7jq68CwICv8v4wBI0DE= Received: from 171.sub-97-21-44.myvzw.com (171.sub-97-21-44.myvzw.com [97.21.44.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6BF49D04062; Wed, 29 Feb 2012 16:46:54 -0600 (CST) References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <9452079D1A51524AA5749AD23E00392806D969@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120229132320.0b45dd78@resistor.net> <9452079D1A51524AA5749AD23E00392806DAE7@exch-mbx901.corp.cloudmark.com> User-Agent: K-9 Mail for Android In-Reply-To: <9452079D1A51524AA5749AD23E00392806DAE7@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 29 Feb 2012 17:46:56 -0500 To: "spfbis@ietf.org" Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Widely deployed (was: #13: RFC 4408: Best-Guess SPF) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 22:47:00 -0000 "Murray S. Kucherawy" wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On >Behalf Of S Moonesamy >> Sent: Wednesday, February 29, 2012 1:27 PM >> To: spfbis@ietf.org >> Subject: [spfbis] Widely deployed (was: #13: RFC 4408: Best-Guess >SPF) >> >> I opened this thread so that the WG can comment on the question of >> "widely deployed". > >Both the "How many implementations?" and "How much exercise does it >get?" are interesting. It amounts to a depth vs. breadth argument in >my view. But I think sometimes it can be more general: Just look at >how much input diversity there is, regardless of how many installations >there are. > >In the case of a domain authentication technology like SPF, I think the >more salient question is "How many domains has it checked?" I can't >see much of a difference between, say, a thousand sites each evaluating >a single domain versus one site that checks a thousand domains. > >So even if only Gmail implements Best Guess SPF, I would call that >widely deployed, because it sees enough of a diversity of inbound mail >to make meaningful observations about its efficacy. I think that's reasonable. To cover (once again) the open source implementations with which I'm familiar: Mail::SPF - No best guess at all pyspf - Not enabled by default libspf2 - Not enabled by default Scott K From msk@cloudmark.com Wed Feb 29 15:04:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB6D21F8631 for ; Wed, 29 Feb 2012 15:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo-Es6fPX4tH for ; Wed, 29 Feb 2012 15:04:02 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 69B3A21F8630 for ; Wed, 29 Feb 2012 15:04:02 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 29 Feb 2012 15:04:01 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Widely deployed (was: #13: RFC 4408: Best-Guess SPF) Thread-Index: AQHM9yn43dXyFtWi50y3/BPCopXTg5ZUaJsggACXQAD//35EEA== Date: Wed, 29 Feb 2012 23:04:01 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392806DCCF@exch-mbx901.corp.cloudmark.com> References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <9452079D1A51524AA5749AD23E00392806D969@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120229132320.0b45dd78@resistor.net> <9452079D1A51524AA5749AD23E00392806DAE7@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Widely deployed (was: #13: RFC 4408: Best-Guess SPF) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 23:04:03 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Wednesday, February 29, 2012 2:47 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Widely deployed (was: #13: RFC 4408: Best-Guess SPF= ) >=20 > To cover (once again) the open source implementations with which I'm > familiar: >=20 > Mail::SPF - No best guess at all > pyspf - Not enabled by default > libspf2 - Not enabled by default One more: The sid-milter package can do it, but it's off by default. -MSK From pgladstone@cisco.com Wed Feb 29 15:24:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D666021E8035 for ; Wed, 29 Feb 2012 15:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.149 X-Spam-Level: X-Spam-Status: No, score=-9.149 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK0WXgLPUiva for ; Wed, 29 Feb 2012 15:24:08 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 482C321E8026 for ; Wed, 29 Feb 2012 15:24:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=1023; q=dns/txt; s=iport; t=1330557848; x=1331767448; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=t5F/h6Wg18+RWzR9ex5YhB7uySIY2izln4KQpEoVaVg=; b=JKj2bVLpesOCe1fpW0EklrDa8LBMnmybdnxAYguQH/ogNKPHIcFV4Cxu +qK0JpQ5Y47HRDoMh+4SC6UcdweDyg4Utro/hl3IaTNrorcXioo63gMGb f7fKYZn4SrM7SJMNk7bI9zUyeZrjbDk1jUFfucWe1jy8Fd3u9MQ2xUuoL g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAHAC+zTk+tJXHA/2dsb2JhbABBA4MBgiauQIEHgXoBAQEEEgEQFUAPAgsYAgIFFgsCAgkDAgECAQk8EwYCAQEeh2eaTAGMZZI0BIEri08DCBMBAQ8CCgYEBwMFAwUJCA4BCQEGAwKFCjoOFR4FggiBFgSIT4xwhV+NMIE+ X-IronPort-AV: E=Sophos;i="4.73,506,1325462400"; d="scan'208";a="62841485" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 29 Feb 2012 23:24:08 +0000 Received: from [10.117.107.24] (rtp-pgladsto-8917.cisco.com [10.117.107.24]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q1TNO7qd001306 for ; Wed, 29 Feb 2012 23:24:07 GMT Message-ID: <4F4EB396.8040100@cisco.com> Date: Wed, 29 Feb 2012 18:24:06 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <9452079D1A51524AA5749AD23E00392806D969@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392806D969@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 23:24:09 -0000 On 2/29/2012 4:18 PM, Murray S. Kucherawy wrote: > The question of "widely deployed" is as interesting as the question of = whether something is "used" if only clients query for it. Does Gmail doi= ng Best Guess SPF count as widespread use because of the percentage of gl= obal email traffic they receive, or only count as a single implementation= ? > > I agree with HFDU. I haven't formed an opinion on what we should say a= bout it yet, but I think we should say something about it either way. > > -MSK I think that the result from the 'best guess SPF record' evaluation=20 should not be a formal SPF result. However, an anti-spam system might=20 well use the result of the evaluation of the best guess spf record as=20 part of the input to its algorithm. I think that the concept is useful=20 in that context. Philip --=20 Philip Gladstone Distinguished Engineer Product Development pgladstone@cisco.com Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Google: +1 978 800 1010 Ham radio: N1DQ From hsantos@isdg.net Wed Feb 29 15:54:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD00821F84EC for ; Wed, 29 Feb 2012 15:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ow8S3Brs6Oi4 for ; Wed, 29 Feb 2012 15:54:36 -0800 (PST) Received: from groups.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B6CE421F84E2 for ; Wed, 29 Feb 2012 15:54:35 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=308; t=1330559667; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=wgmv/CisqSgYALLZe6JFIX9zO8A=; b=IGrAQTEcm/LZjWdOOMrl 8PFaS9pvHhVO4mVEucN06A2vu9Sz4Qc/uy8HZpAugPDZveF6vdt22XyK5sfYB6g2 671CgJ6TZpbaRt8+w5sbd96lZ1FWP7Wh4P6u1kVzg1jsio+BwFHy5MwLT1uY8v3a TuIWRfpaeusqlDDy35WVE28= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 29 Feb 2012 18:54:27 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3761504597.95668.828; Wed, 29 Feb 2012 18:54:26 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=308; t=1330559413; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=gQOEjKB BNPttWSlvOgYCvwQoR/f3bAeZH1+j3sHE7zo=; b=2KdyyCVh99SLPMcokgocOgz G1H8wRGDOnl4ka1YUy5WBnQvlj9z0x7cs69WK9hvOT3I7qw/aK3tDP8W9V8r/Qb2 cJiX9pczaK9EATPl8RF2c52lzLfm2PYN5RLa2xSnLLd58XEt4P4Ou4r3WtylrT7n cfn4rmfKADObOoWx1rvc= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 29 Feb 2012 18:50:13 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 65467987.20038.3508; Wed, 29 Feb 2012 18:50:11 -0500 Message-ID: <4F4EBAB1.8020507@isdg.net> Date: Wed, 29 Feb 2012 18:54:25 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <9452079D1A51524AA5749AD23E00392806D969@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120229132320.0b45dd78@resistor.net> In-Reply-To: <6.2.5.6.2.20120229132320.0b45dd78@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] Widely deployed X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Feb 2012 23:54:37 -0000 S Moonesamy wrote: > Hello, > > I opened this thread so that the WG can comment on the question of > "widely deployed". Dog with fleas, ticks, worms... I side with all three of Dave Crocker's input and advice. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Wed Feb 29 16:46:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D02521E801C for ; Wed, 29 Feb 2012 16:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.456, 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 cCwekAN3Vtjs for ; Wed, 29 Feb 2012 16:46:30 -0800 (PST) Received: from groups.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCDE21E8026 for ; Wed, 29 Feb 2012 16:46:30 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2811; t=1330562782; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=soPTGjUWqv79+OfCoX5SO+cXQNM=; b=ZBDaVh97eEHrf8nbUzrD ZMjjxrHbGxBGqLqGGrKiSg1iPr8Bj1WOYZwX7xH2T9ThBXTsd670o46YdTJ78xMg rGOss9lBi3Gv6UWfCYR2veGSvf/gN1iDdJR/J8uQ8dvpN/smc3rHfKMj8gr/t2tN /DZHganxbdHshkP1SIZ1Ruw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 29 Feb 2012 19:46:22 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3764619765.95668.6020; Wed, 29 Feb 2012 19:46:21 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2811; t=1330562531; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=JepfdAD 0YWW0g1B6ih9BPJ9iut/HRVSwztzKNxm1GPQ=; b=BLfyCnd7mda4pdV7upLEx+f z421/XF8p8+bG2ini4IOld53sEWooB8bCehs5oRGksIGcild36xIS5QF0p6SINFO osAJP+infwkfSJ02aAflLY8EIZIVkNGUREyUYEjhPlPTHryqYOhbq7d2TMeTtLiG MNA/XjJskT6R8+1ZRd5I= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 29 Feb 2012 19:42:11 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 68587346.20045.2868; Wed, 29 Feb 2012 19:42:11 -0500 Message-ID: <4F4EC6E0.5030905@isdg.net> Date: Wed, 29 Feb 2012 19:46:24 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <4F4EA5DC.9040204@dcrocker.net> <9452079D1A51524AA5749AD23E00392806DBE8@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392806DBE8@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 00:46:31 -0000 My Opinion. Widely deployed doesn't correlate to the idea of success if its purpose has shown to be of low value, shown to have little to no payoff, perhaps complex, expensive to implement, comes with with list of other compliancy dependencies, etc. It could just be a marketing value at this point. Some may validly suggest Widely Deployed is good because it has a trickle down effect and realized benefit for all once others begin to "follow the leaders." Some may argue DKIM falls in that category where high investments has yet to materialize or trickle down with a payoff. I prefer to see worth, show the What it is, how it works and why this Best Guess has a value to be considered as a new SPF consideration. I can see it perhaps as just another test data point factor (i.e, Sender and purported MX Receiver live in the same ADMD or computer box) as input to some external antispam evaluator or algorithm, but don't see that an enforcible concept since there is no SMTP requirement for the sender and receivers be part of the same ADMD or computer box. As it relates to Google, in lieu of any information in how they use it, I can clearly see it as part of Google's BI to see what the patterns of sender/receivers operations and network connectivity associations are - the "Google World Mail Connectivity Map" perhaps. I would consider it strategic business intelligence data banking. But then again, it could be another AVS secret formula. Explain it. I personally don't think it should included in SPF-BIF, but like to know more above the Sender/Receiver, same box/owner network data point. Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Dave Crocker >> Sent: Wednesday, February 29, 2012 2:26 PM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF >> >> On 2/29/2012 1:10 PM, Scott Kitterman wrote: >>> This is not in RFC 4408, so it's only in scope if it's widely >>> deployed. >> This strikes me as an impressively dangerous feature. > > I'd be fine with us saying just that if that's consensus. > >> At a minimum, we should see a specification for it, rather than discuss >> it merely as an idea. > > http://www.openspf.org/FAQ/Best_guess_record > > We could also include that text or something similar, just so everyone knows what it is. > >> My guess is that this has narrow application and currently very limited >> deployment, at best. > > What's that mean, exactly? :-) > > -MSK > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From johnl@iecc.com Wed Feb 29 17:00:13 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3479721E8038 for ; Wed, 29 Feb 2012 17:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.16 X-Spam-Level: X-Spam-Status: No, score=-110.16 tagged_above=-999 required=5 tests=[AWL=1.039, 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 NCT9s6PwcVZy for ; Wed, 29 Feb 2012 17:00:12 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 74ED421E801F for ; Wed, 29 Feb 2012 17:00:12 -0800 (PST) Received: (qmail 51115 invoked from network); 1 Mar 2012 01:00:11 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 1 Mar 2012 01:00:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f4eca1b.xn--3zv.k1202; i=johnl@user.iecc.com; bh=37fMo9AX5eCakrdoR8dO+2ONO2iDXi9qrYgHn0nVK88=; b=r8MO73HLYBQyR9FaEqQrIMx1pfRrOOkElOxqcL//yk16dM6F279ZIZNyrb0OY3DyJEIrVUJ1F3vvsbbYFMzGCs11YRhCvBf8y8zsaVYJn9VGyQP/re9DD5eZeNyctuoW/Btzo3G+EsGaVXmqXR7IBMR7nMb6/OadTyfdin3m7xA= 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=4f4eca1b.xn--3zv.k1202; olt=johnl@user.iecc.com; bh=37fMo9AX5eCakrdoR8dO+2ONO2iDXi9qrYgHn0nVK88=; b=CXdJm9oVxV0967fQ+q5Tcb/KwzhsAFgJOofz2gululrrx6/TbtZ/LvBzc4cHqAS07nKnYMHUExqBjp6hjvyKifWTxT5SDEtBSnHOd19jURSOdQruQxDkYYhXOO7iWqBa4YOZm3d96WfO3r3wk+Y9+DczfqPPviOqPNX3LO4iifQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 1 Mar 2012 00:59:49 -0000 Message-ID: <20120301005949.65607.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: spf2@kitterman.com Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 01:00:13 -0000 >Personally, I think the most we should do is say MUST NOT (we can't stop people from doing so, >but we can make it clear it's wrong to call a best guess result an SPF result). I wouldn't disagree. Also, if we do an AS, discussion of it might better go in there. R's, John From johnl@iecc.com Wed Feb 29 17:22:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671B321E8033 for ; Wed, 29 Feb 2012 17:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.17 X-Spam-Level: X-Spam-Status: No, score=-110.17 tagged_above=-999 required=5 tests=[AWL=1.029, 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 DmgzmJy2Gv7D for ; Wed, 29 Feb 2012 17:22:55 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9D01921E801F for ; Wed, 29 Feb 2012 17:22:55 -0800 (PST) Received: (qmail 73302 invoked from network); 1 Mar 2012 01:22:53 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 1 Mar 2012 01:22:53 -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=4f4ecf6d.xn--btvx9d.k1202; i=johnl@user.iecc.com; bh=d+4WEvqlvvsWoPQLPmjjvJDhoia0IjWRQUGCTXW+Rmk=; b=YC7A4rHtgFDazdGgMBdhZ3X5uWqvSHwmyj+1Yj1H1p/MyteClnnClu9CufWFtsBUUBvlI1+rzJtW9AYV2rVtDzd5agOV2JSShcOwkJNJUg88fSZY8AJh5k6uBuY1XZvQEXGPjLNzew0rLCzZqo6cq7W9y+pxPrzD+MsQVS/+5WU= 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=4f4ecf6d.xn--btvx9d.k1202; olt=johnl@user.iecc.com; bh=d+4WEvqlvvsWoPQLPmjjvJDhoia0IjWRQUGCTXW+Rmk=; b=f1tVhQxLGYv2kD+4ZfOCIpyJtDP55DLM/8XhOA77kz/T9Pk+8vSF1rJLQCLDwokxSLf3OX+rIJv/8ruT6J4Ghs77m3/zaeXyCQiyflB8Is0W7mp30y/s5mB/yDVOLOtcZPmn5Seq2GqSB63HBCh74NKAfoHgEMwG1lif+mfPuNM= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 1 Mar 2012 01:22:31 -0000 Message-ID: <20120301012231.79470.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4F4EB396.8040100@cisco.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: pgladstone@cisco.com Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 01:22:56 -0000 >I think that the result from the 'best guess SPF record' evaluation >should not be a formal SPF result. However, an anti-spam system might >well use the result of the evaluation of the best guess spf record as >part of the input to its algorithm. I think that the concept is useful >in that context. It might be useful, but it's not SPF. Another possibility would be a separate informational document called something like heuristic mail sender validation. R's, John From agthisell@yahoo.com Wed Feb 29 19:51:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6851821F85A1 for ; Wed, 29 Feb 2012 19:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_50=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoWbhJn52sRT for ; Wed, 29 Feb 2012 19:51:56 -0800 (PST) Received: from nm6.bullet.mail.ne1.yahoo.com (nm6.bullet.mail.ne1.yahoo.com [98.138.90.69]) by ietfa.amsl.com (Postfix) with SMTP id C360021F85A0 for ; Wed, 29 Feb 2012 19:51:55 -0800 (PST) Received: from [98.138.90.51] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 01 Mar 2012 03:51:51 -0000 Received: from [98.138.87.3] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 01 Mar 2012 03:51:51 -0000 Received: from [127.0.0.1] by omp1003.mail.ne1.yahoo.com with NNFMP; 01 Mar 2012 03:51:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 703788.26929.bm@omp1003.mail.ne1.yahoo.com Received: (qmail 27356 invoked by uid 60001); 1 Mar 2012 03:51:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1330573911; bh=UmWcgr5b9KKjhSHRWjAOkBmiiWqgMoccWAgYLS5k5+M=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=PSDty2JiB51xOR51h9K2rxMF0nE01lg7mq+q6Ufyzm3slKRLEJF1AKiJlVi1qhzoTCbsdRe6KxhmCau+zQB7JyN4CM3PLtANQ/wkCSGFwiEpr1fQeyJ77m4GJfzdWIDHQ4/2m0+esBwVMNSOci/xyiPD9kMX9y/8b2d53QRdhSU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=36DbkrXy9o1DbiQuJ+aKzl2NWKifvsfJj+2RPjOBvl/zO00JIc4ur0hsBd8kqC71uMkK3xw3GHExdBncP5hA5DlJAaMu7t8SWpJrVYZ5+h5676e+Ehn9X+HuvCEixbX6AHYQZD2QVuXf9Nkitil6AL092Ecj3tX+pGAeZjSlA40=; X-YMail-OSG: 5aVHIMEVM1n.RzdycJVSHWOjQcMeyDz1qbxPUDD15ewLeQ7 7cWGRKAlN2sOUn.vwZT7zaLV4Y7Yf6HwkirBAplHCzA5C7VXlnj1oSsTLIYe OewQWrwkSq.QBBxRJJQPtIcRiR6AwJMzZZdW5GzcoMyjTf8DiQ5gswKccwrg s5x8bhxkzLIkUO31MSMVgcTU7kI7U7srIWjVMWXROLGezkbY21e1zE5cveJ_ 6VYqcbtIiDscwnTVcXoKA_kwW9S7Gfqa3iD7Ttz_tfCq.Ir5dk.KpGbkkrYq 2CnmoX0Yrqc3gXq1WMU3CFXGlQnULdwSd6D9OfNJfMQPfxjgnSJY6QWI085M oX817_nShi25ph8exE8zoqh2CVQVD2rZlEcZorDpIM7TE3gacAfoKwdXqGhK XRVI3MfT3LPMYP.4N34EnF2JouhJ6jw6hwufdD14mnAq9SLrYWOQf0DLh__8 Umns- Received: from [71.61.133.134] by web125404.mail.ne1.yahoo.com via HTTP; Wed, 29 Feb 2012 19:51:51 PST X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1330573911.21577.YahooMailClassic@web125404.mail.ne1.yahoo.com> Date: Wed, 29 Feb 2012 19:51:51 -0800 (PST) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 03:51:56 -0000 I feel that any discussion of "best-guess" is out of scope. The machinery of SPF can be fed a variety of data and it will return a variety of answers, but these are not SPF, they are extensions. Trying to document "best-guess" or "sender-id" in RFC 4408 would be like requiring the DNS RFCs to talk about DNSBL or SPF usage of the DNS machinery. I agree with John Levine, the proper place, if any,to discuss "best-guess" is in another RFC, or in the documentation of implementations, or a website somewhere. From msk@cloudmark.com Wed Feb 29 19:55:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E285A21E801E for ; Wed, 29 Feb 2012 19:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 TSpJeXzE-J+7 for ; Wed, 29 Feb 2012 19:55:43 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 78B4521E8017 for ; Wed, 29 Feb 2012 19:55:43 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Wed, 29 Feb 2012 19:55:42 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #13: RFC 4408: Best-Guess SPF Thread-Index: AQHM9w9gv5LdotHEQE+MDxPo9jLb7pZU5RMAgABAHoD//6rWQA== Date: Thu, 1 Mar 2012 03:55:42 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392806E633@exch-mbx901.corp.cloudmark.com> References: <20120301005949.65607.qmail@joyce.lan> In-Reply-To: <20120301005949.65607.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 03:55:44 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of John Levine > Sent: Wednesday, February 29, 2012 5:00 PM > To: spfbis@ietf.org > Cc: spf2@kitterman.com > Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF >=20 > >Personally, I think the most we should do is say MUST NOT (we can't > >stop people from doing so, but we can make it clear it's wrong to call > a best guess result an SPF result). >=20 > I wouldn't disagree. Also, if we do an AS, discussion of it might > better go in there. That's outside the current charter, but I'd be amenable to working on that = if others are (whether a post-rechartering project or an individual submiss= ion). -MSK From dhc@dcrocker.net Wed Feb 29 23:00:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4762021E802F for ; Wed, 29 Feb 2012 23:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HTML_MESSAGE=0.001, 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 7XwcQlQMHfAr for ; Wed, 29 Feb 2012 23:00:39 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3592A21E800C for ; Wed, 29 Feb 2012 23:00:39 -0800 (PST) Received: from [192.168.1.3] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2170Cjp001463 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 29 Feb 2012 23:00:23 -0800 References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----WEXHJ1UUWONAZ0DRVHVI9I0846MJE3" From: Dave Crocker Date: Wed, 29 Feb 2012 10:33:54 -0800 To: S Moonesamy , spfbis@ietf.org Message-ID: <233d984c-214e-4ae5-ab1c-73649018fd47@email.android.com> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 29 Feb 2012 23:00:27 -0800 (PST) Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 07:00:40 -0000 ------WEXHJ1UUWONAZ0DRVHVI9I0846MJE3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit S Moonesamy wrote: At 20:02 16-02-2012, spfbis issue tracker wrote: >#13: RFC 4408: Best-Guess SPF > > Message posted by Murray Kucherawy on 26 Feb 2012: > > I'd like to have a section, or at least an appendix, that talks about > best-guess SPF: What it is, why/when it is or isn't a good idea, etc. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00398.html [snip] >Ticket URL: ; I am going to classify Issue #13 as "Hold for document update". If there are any objections, please post them to this mailing list. BTW, the issue may be opened for discussion if an open issue is related to this issue. Please let me know if it occurs. Regards, S. Moonesamy SPFBIS WG co-chair _____________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis wtf? please at leat define it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ------WEXHJ1UUWONAZ0DRVHVI9I0846MJE3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
S Moonesamy <sm+ietf@elandsys.com> wrote:
At 20:02 16-02-2012, spfbis issue tracker wrote:
>#13: RFC 4408: Best-Guess SPF
>
>  Message posted by Murray Kucherawy on 26 Feb 2012:
>
>  I'd like to have a section, or at least an appendix, that talks about
>  best-guess SPF: What it is, why/when it is or isn't a good idea, etc.
>
>  http://www.ietf.org/mail-archive/web/spfbis/current/msg00398.html

[snip]

>Ticket URL: <http://trac.tools.ietf.org/wg/spfbis/trac/ticket/13>;

I am going to classify Issue #13 as "Hold for document update".  If 
there are any objections, please post them to this mailing 
list.  BTW, the issue may be opened for discussion if an open issue 
is related !
 to this
issue.  Please let me know if it occurs.

Regards,
S. Moonesamy
SPFBIS WG co-chair  


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

wtf?

please at leat define it.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net ------WEXHJ1UUWONAZ0DRVHVI9I0846MJE3-- From sm@elandsys.com Wed Feb 29 23:16:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2387021F850D for ; Wed, 29 Feb 2012 23:16:39 -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 4y3-3aGIXXwS for ; Wed, 29 Feb 2012 23:16:38 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D7621F8503 for ; Wed, 29 Feb 2012 23:16:37 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.232.174]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q217GJkD013130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Feb 2012 23:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330586191; i=@elandsys.com; bh=u9SIt/elJZeuGXVOjLs7FG+P8YadIlrFjx8EWeyorfg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=AOvUkpRj9JWUJYE9J4XbuYhAYL7LSHie0Jp9kNP+978AakyCCtD/3v2h1xYE3zbwG w+SM4vh71FI2PXnnov5hINFAHSb86bvgC3DgBKMkO88tbxkhNU8WAmPg1xdN/Sj/i6 gTSGrSWHdoozy54lxRmMb+A7UH2H3N3Mv7wNSA3U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330586191; i=@elandsys.com; bh=u9SIt/elJZeuGXVOjLs7FG+P8YadIlrFjx8EWeyorfg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Z587ykaSGKzk+IHZJ2X/LRDLL/V84HicN8FSyj/pKdEcW2tsBvXuAmjBttmz2QYK0 TZx5x6TEe5DnY806bdf9seQvnVC7cSJ2NA8cAQ+fOdAINI6I26Lhzxj5CpA6Usy/9j CMeA8tACmM05iKTrhlt/ni2Sc1DN+XJInPhjq/1k= Message-Id: <6.2.5.6.2.20120229231251.0add09a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Feb 2012 23:14:34 -0800 To: Dave Crocker From: S Moonesamy In-Reply-To: <233d984c-214e-4ae5-ab1c-73649018fd47@email.android.com> References: <061.719f414678a2a3c3c3d2dc6e92664f49@tools.ietf.org> <6.2.5.6.2.20120229092526.0aa771f0@elandnews.com> <233d984c-214e-4ae5-ab1c-73649018fd47@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 07:16:39 -0000 Hi Dave, At 10:33 29-02-2012, Dave Crocker wrote: >please at leat define it. I have been asked what "Hold for document update" means. The working group does not have any WG draft up for discussion yet. When there is a WG draft, the working group can discuss about the exact text that goes into it. Regards, S. Moonesamy SPFBIS WG co-chair